I thought I'd give the release a try (up to now I've always copied the kernel over serial and used nfs root) but it appears that I have some bad blocks in the NAND on my device: Found ldr.img Erasing /dev/mtd3 Erasing 16 Kibyte @ 0 -- 0 % complete. Skipping bad block at 0x00004000 Skipping bad block at 0x00008000 Erasing 16 Kibyte @ c000 -- 18 % complete.Erasing 16 Kibyte @ 10000 -- 25 % complete.Erasing 16 Kibyte @ 14000 -- 31 % complete.Erasing 16 Kibyte @ 18000 -- 37 % complete.Erasing 16 Kibyte @ 1c000 -- 43 % complete.Erasing 16 Kibyte @ 20000 -- 50 % complete.Erasing 16 Kibyte @ 24000 -- 56 % complete.Erasing 16 Kibyte @ 28000 -- 62 % complete.Erasing 16 Kibyte @ 2c000 -- 68 % complete.Erasing 16 Kibyte @ 30000 -- 75 % complete.Erasing 16 Kibyte @ 34000 -- 81 % complete.Erasing 16 Kibyte @ 38000 -- 87 % complete.Erasing 16 Kibyte @ 3c000 -- 93 % complete. Writing ldr.img to /dev/mtd3 end_request: I/O error, dev mtdblock3, sector 32 dd: /dev/mtdblock3: Input/output error Is it possible to move ldr further down in /dev/mtd3 ? I tried this using dd if=/media/sda1/ldr.img of=/dev/mtdblock3 bs=16384 seek=3 that seemed to write OK, but the e3 wont boot of the nand yet. I get an error about missing kernel params, which repeats continuously. Anyone got any ideas? Matt
On Fri, Sep 29, 2006 at 11:27:34AM +0100, Matt Callow wrote:
I thought I'd give the release a try (up to now I've always copied the kernel over serial and used nfs root) but it appears that I have some bad blocks in the NAND on my device: ... Is it possible to move ldr further down in /dev/mtd3 ? I tried this using
dd if=/media/sda1/ldr.img of=/dev/mtdblock3 bs=16384 seek=3
that seemed to write OK, but the e3 wont boot of the nand yet. I get an error about missing kernel params, which repeats continuously.
Anyone got any ideas?
Moving !LDR should work fine, but if you're getting an error about missing params then you still haven't wiped the old Amstrad LDR. ISTR that PBL will do remapping in the NAND using the area that ends up as mtd5 (last 192k of NAND), so it might be worth trying to erase that area of NAND and see if that causes your !LDR image to be seen instead? J. -- Black Cat Networks Ltd. - UK Domain, Web and Email hosting. If I follow you home, will you keep me? Email: sales@blackcatnetworks.co.uk Web: http://www.blackcatnetworks.co.uk/
Jonathan McDowell wrote:
Moving !LDR should work fine, but if you're getting an error about missing params then you still haven't wiped the old Amstrad LDR. ISTR that PBL will do remapping in the NAND using the area that ends up as mtd5 (last 192k of NAND), so it might be worth trying to erase that area of NAND and see if that causes your !LDR image to be seen instead?
J.
I think the write to mtdblock3 didn't work. Although it didn't report an error when I added the seek=3, it still read back the old data. So you're right, I hadn't removed the amstrad LDR. In the end, I re-arranged the mtd partition table and moved mtd3 down by 1M and built a new kernel. That fixed the problem (once I found the post re: CONFIG_DEBUG_MUTEXES) So now I've got my E3 booting of the nand :-) Matt
Hi all, I was wondering how you were doing this development work for the E3s.. Are you using a crosscompiler or do you have GCC running on the E3 itself? -- Luke
Luke Schneider wrote:
Hi all,
I was wondering how you were doing this development work for the E3s.. Are you using a crosscompiler or do you have GCC running on the E3 itself?
Well, I've had Debian running on the E3, and for a stunt I tried compiling a kernel; it took about four hours. (Look in the list archives for "Debian report" for the exact figures.) While it's still faster than the Sun workstations I learnt to program on, personally I'd be happier cross-compiling. Incidentally, I also have an NSLU2, which is a similar specced ARM device with 32MB and a USB 2 disk. Trying to compile C++ on that more or less kills it stone dead. Trying to compile a 4000 line C++ program took, basically, all day; I think this is because the C++ compiler's working set is too big to fit in RAM, which means its thrashing the swap continuously. So given that the E3 has a USB 1 connection, making for ludicrously slow swap, things would be even worse on it. -- +- David Given --McQ-+ "Gaping from its single obling socket was | dg@cowlark.com | scintillating, many fauceted scarlet emerald..." | (dg@tao-group.com) | --- Jim Theis, _The Eye of Argon_ (spelling +- www.cowlark.com --+ original)
(performance engineer hat engaged) On 4 Oct 2006, at 01:30, David Given wrote:
Incidentally, I also have an NSLU2, which is a similar specced ARM device with 32MB and a USB 2 disk. Trying to compile C++ on that more or less kills it stone dead. Trying to compile a 4000 line C++ program took, basically, all day; I think this is because the C++ compiler's working set is too big to fit in RAM, which means its thrashing the swap continuously. So given that the E3 has a USB 1 connection, making for ludicrously slow swap, things would be even worse on it.
Were you running gcc from flash, or from disc? If it's running from flash, I would expect that to be faster than (at least USB1) disc. Since program text pages do not change appreciably during the run, they do not need to be copied into writable swap, and so the rapid access of Flash can be a big boost when you're short on RAM pages. (Linux will discard pages of program without saving them into swap, so you effectively get a free page of swap for every text page). Compiling with -O3 -fomit-stack-frame also helps ARM a lot more than you might expect, since the optimizer can make serious gains there- might want to check which flags your gcc was built with. -J.
Jasmine Strong wrote: [...]
Were you running gcc from flash, or from disc? If it's running from flash, I would expect that to be faster than (at least USB1) disc. [...] Compiling with -O3 -fomit-stack-frame also helps ARM a lot more than you might expect, since the optimizer can make serious gains there-
*nods* Back then there was no flash driver, so everything was coming off the disk; and given that I was really doing it as a stunt, there was no special configuration done. If I ever figure out OpenEmbedded I might play with the compilation options --- that optimisation trick definitely sounds worth trying. (It may also be worth experimenting with using Thumb code. It's technically slower, but the higher code density might improve overall performance by reducing I/O.) It's a shame building a Linux distro from scratch is such a pain... I *knew* we should have gone for BSD! [1] (The new EABI stuff looks interesting, too.) [1] That was a joke. -- +- David Given --McQ-+ "Wizards get cranky, / Dark days dawn, / Riders | dg@cowlark.com | smell manky, / The road goes on. / Omens are | (dg@tao-group.com) | lowering, / Elves go West; / The Shire needs +- www.cowlark.com --+ scouring, / You may as well quest." - John M. Ford
On 4 Oct 2006, at 11:45, David Given wrote:
. (It may also be worth experimenting with using Thumb code. It's technically slower, but the higher code density might improve overall performance by reducing I/O.)
Having been the engineer responsible for determining the performance difference between OMAP1510's Thumb and ARM modes, I can safely tell you that until the advent of Thumb2, there's no way this is even close to true. Restrictions on the available operations (and, later, on the branch predictor in ARM11) stop Thumb from approaching the sorts of gains you might hope to see. Sorry :-) -J.
Jasmine Strong wrote: [...]
Having been the engineer responsible for determining the performance difference between OMAP1510's Thumb and ARM modes, I can safely tell you that until the advent of Thumb2, there's no way this is even close to true. Restrictions on the available operations (and, later, on the branch predictor in ARM11) stop Thumb from approaching the sorts of gains you might hope to see.
What, you mean ARM's public relations department have been lying to me? I can't believe it! At least it saves me some work... -- +- David Given --McQ-+ "Wizards get cranky, / Dark days dawn, / Riders | dg@cowlark.com | smell manky, / The road goes on. / Omens are | (dg@tao-group.com) | lowering, / Elves go West; / The Shire needs +- www.cowlark.com --+ scouring, / You may as well quest." - John M. Ford
On 4 Oct 2006, at 15:22, David Given wrote:
What, you mean ARM's public relations department have been lying to me? I can't believe it!
Well, to be fair, ARM's public relations department says that Thumb code is denser than ARM (which is true) and that it's only a little slower on ARM9E (which is true) and is about as fast on Cortex (true again). Then again, with the advent of Thumb2EE, we don't have a lot of choice any more. -J.
Since you CAN compile code on the E3, where would I get gcc for use on the E3? I'm going to be getting an E3 especially for use with linux (to sit next to my actual E3 which I use as a phone). I don't have any experience setting up a cross compiler, so if there is any instructions for setting up a cross compiler under linux I'd like that too :) Thanks, Luke
Well, I've had Debian running on the E3, and for a stunt I tried compiling a kernel; it took about four hours. (Look in the list archives for "Debian report" for the exact figures.) While it's still faster than the Sun workstations I learnt to program on, personally I'd be happier cross-compiling.
Incidentally, I also have an NSLU2, which is a similar specced ARM device with 32MB and a USB 2 disk. Trying to compile C++ on that more or less kills it stone dead. Trying to compile a 4000 line C++ program took, basically, all day; I think this is because the C++ compiler's working set is too big to fit in RAM, which means its thrashing the swap continuously. So given that the E3 has a USB 1 connection, making for ludicrously slow swap, things would be even worse on it.
----- Original Message ----- From: "David Given" <dg@cowlark.com> To: "Discussion of the Amstrad E3 emailer hardware/software" <e3-hacking@earth.li> Sent: Wednesday, October 04, 2006 12:30 AM Subject: Re: [E3-hacking] Compiling Apps
_______________________________________________ e3-hacking mailing list e3-hacking@earth.li http://www.earth.li/cgi-bin/mailman/listinfo/e3-hacking
participants (6)
-
David Given -
Jasmine Strong -
Jonathan McDowell -
Luke Schneider -
Matt Callow -
Matt Callow