From: David H. <da...@sw...> - 2007-09-17 16:13:10
|
I have a U-boot standalone app which I want to run at boot time. I don't have any use for Linux on this board (Connex/Basix running U-Boot 1.2.0) rather want my app to be loaded at power up once U-boot is loaded, just like Linux normally is run. Is there any easy way to write this app to flash from within U-boot itself? I'd prefer not to completely blitz Linux (in case I need to use this board for other things) - although if this is not possible then that's fine. Boot time is a bit of an issue. I do find that the time U-boot takes to scan the JFFS2 file system is quite slow, and I'd prefer my app to start quicker if possible. I don't know if that's related to the size of the JFFS2 image and making a smaller one would be faster. Any suggestions about what I need to do to get this to work? Thanks David |
From: Dave H. <dhy...@gm...> - 2007-09-17 18:03:03
|
Hi David, On 9/17/07, David Hearn <da...@sw...> wrote: > I have a U-boot standalone app which I want to run at boot time. I > don't have any use for Linux on this board (Connex/Basix running U-Boot > 1.2.0) rather want my app to be loaded at power up once U-boot is > loaded, just like Linux normally is run. > > Is there any easy way to write this app to flash from within U-boot > itself? I'd prefer not to completely blitz Linux (in case I need to use > this board for other things) - although if this is not possible then > that's fine. Since all of the sectors except for u-boot are used for the JFFS2 partition, nuking linux is probably the only way to go. You should just be able to create an image which is wrapped in the appropriate u-boot header and execute it, or just load your app from flash into RAM and run it. You just need to adjust the bootcmd environment variable in u-boot to change what it does. u-boot doesn't really know or care what program it runs, it just does what it's told. If that program happens to be linux, then linux will start. If it happens to be something else, then that will be run. You could even store different versions of your app at different flash locations. You app doesn't need to be in a file system either, which will dramatically speed up the process. About your load address problem, why not add a new command to u-boot and have the new command call the function where ever it happens to be, then you don't care. I know Craig added katload and katinstall commands ti u-boot. -- Dave Hylands Vancouver, BC, Canada http://www.DaveHylands.com/ |
From: Craig H. <cr...@gu...> - 2007-09-17 23:05:45
|
On Sep 17, 2007, at 9:13 AM, David Hearn wrote: > Boot time is a bit of an issue. I do find that the time U-boot > takes to > scan the JFFS2 file system is quite slow, and I'd prefer my app to > start > quicker if possible. I don't know if that's related to the size of > the > JFFS2 image and making a smaller one would be faster. > > Any suggestions about what I need to do to get this to work? The best thing to do will be to remove the JFFS2/uImage and just write your app directly into flash. If you need to rewrite it a lot (ie thousands of times per board) then you'll probably want to implement some kind of wear-leveling so you don't wear the flash out prematurely. C |
From: David H. <da...@sw...> - 2007-09-19 12:05:04
|
Craig Hughes wrote: > On Sep 17, 2007, at 9:13 AM, David Hearn wrote: > > >> Boot time is a bit of an issue. I do find that the time U-boot >> takes to >> scan the JFFS2 file system is quite slow, and I'd prefer my app to >> start >> quicker if possible. I don't know if that's related to the size of >> the >> JFFS2 image and making a smaller one would be faster. >> >> Any suggestions about what I need to do to get this to work? >> > > The best thing to do will be to remove the JFFS2/uImage and just > write your app directly into flash. If you need to rewrite it a lot > (ie thousands of times per board) then you'll probably want to > implement some kind of wear-leveling so you don't wear the flash out > prematurely. > > C Yes, that sounds like the best way. How do I go about removing the JFFS2/uImage? Should I just erase everything except the boot loader and then just write my app to somewhere in flast - just like I'd write u-boot? Thanks David |
From: Dave H. <dhy...@gm...> - 2007-09-19 15:17:34
|
HI David, > > The best thing to do will be to remove the JFFS2/uImage and just > > write your app directly into flash. If you need to rewrite it a lot > > (ie thousands of times per board) then you'll probably want to > > implement some kind of wear-leveling so you don't wear the flash out > > prematurely. > > > > C > Yes, that sounds like the best way. > > How do I go about removing the JFFS2/uImage? You don't really need to remove it, but if you want to, just do: protect on 1:0-1 && erase all Make sure you use erase and not jerase > Should I just erase > everything except the boot loader and then just write my app to > somewhere in flast - just like I'd write u-boot? Pretty much. Except I'd leave sectors 0 & 1 protected so you don't accidentally erase u-boot. -- Dave Hylands Vancouver, BC, Canada http://www.DaveHylands.com/ |
From: Craig H. <cr...@gu...> - 2007-09-19 17:16:54
|
On Sep 19, 2007, at 5:04 AM, David Hearn wrote: > How do I go about removing the JFFS2/uImage? Should I just erase > everything except the boot loader and then just write my app to > somewhere in flast - just like I'd write u-boot? Yup. GUM> protect on 1:0-1&&erase all&&cp.b $my_app_ram_location 40000 $filesize Now do the math on what $filesize/4 (rounded up, in hex) is, and then do GUM> set bootcmd icache on\;cp.l 40000 a2000000 <calculated number here>\;go a2000000 Or instead of a2000000 whatever RAM location you want to run from. The "cp.l" will make a big difference over cp.b if your app is of any substantial size, and is why you need to divide by 4. C |
From: David H. <da...@sw...> - 2007-09-20 12:40:59
|
Craig Hughes wrote: > On Sep 19, 2007, at 5:04 AM, David Hearn wrote: > >> How do I go about removing the JFFS2/uImage? Should I just erase >> everything except the boot loader and then just write my app to >> somewhere in flast - just like I'd write u-boot? > > Yup. > > GUM> protect on 1:0-1&&erase all&&cp.b $my_app_ram_location 40000 > $filesize > > Now do the math on what $filesize/4 (rounded up, in hex) is, and then do > > GUM> set bootcmd icache on\;cp.l 40000 a2000000 <calculated number > here>\;go a2000000 > > Or instead of a2000000 whatever RAM location you want to run from. > The "cp.l" will make a big difference over cp.b if your app is of any > substantial size, and is why you need to divide by 4. The .bin file is only 7k, so I think using cp.b would be fine. Thanks for that info, I've now got it all working. David |