From: James W. <ji...@ho...> - 2007-06-06 20:02:43
|
Can you use u-boot to load and test a customised uboot? What would be the best way to test a custom build u-boot leaving the original in its flash space protected? james _________________________________________________________________ Need a break? Find your escape route with Live Search Maps. http://maps.live.com/default.aspx?ss=Restaurants~Hotels~Amusement%20Park&cp=33.832922~-117.915659&style=r&lvl=13&tilt=-90&dir=0&alt=-1000&scene=1118863&encType=1&FORM=MGAC01 |
From: Dave H. <dhy...@gm...> - 2007-06-07 02:47:28
|
Hi James, On 6/6/07, James Wilson <ji...@ho...> wrote: > Can you use u-boot to load and test a customised uboot? > What would be the best way to test a custom build u-boot leaving the > original in its flash space protected? Yes. You would load the test u-boot from some other location (you can read files from the JFFS2 filesystem, or you can load it over serial, TFTP, from MMC, or CF. Now - which address to use is interesting. On the connex, and on the 1.1.4 version of u-boot on the verdex, u-boot is loaded to A3F00000. On the verdex for u-boot-1.2.0, it's loaded to 5c000000 (which appears to 256k of internal RAM). I performed the following test on my verdex, with the following two files in my /root directory on the gumstix: 1321-u-boot.bin (which is 1.1.4) 1352-u-boot.bin (which is 1.2.0) Runnng 1.1.4 (which executes from A3F00000), I tried the following: fsload a2000000 1321-u-boot.bin go a2000000 which worked fine. fsload a2000000 /root/1352-u-boot.bin go a2000000 failed, however fsload 5c000000 /root/1352-u-boot.bin go 5c000000 worked fine. While running the 1352 version of u-boot (which executes from 5c000000) fsloading to a2000000 works fine. u-boot checks the address it's currently running at and if it's not at the correct address, it relocates itself and runs from the relocated address. So, you don't want to load to the address that the current u-boot is runnung from, and the only address I could use with u-boot-1.1.4 to load 1.2.0 was 5c000000 -- Dave Hylands Vancouver, BC, Canada http://www.DaveHylands.com/ |
From: Craig H. <cr...@gu...> - 2007-06-07 14:15:25
|
Note that loading a new u-boot into 5c000000 while running u-boot from that location will 99.999% likely break, since you're executing that code. Replacing code in RAM while the PC is pointing in there somewhere is probably not going to work. I think with the u-boot running at 5c000000, the only way to test a new u-boot would be to build it to load itself somewhere else (say, a3f00000) and execute that using go. Once it works, then rebuild with the load address at 5c000000 and flash it, then reboot. C On Jun 6, 2007, at 7:47 PM, Dave Hylands wrote: > Hi James, > > On 6/6/07, James Wilson <ji...@ho...> wrote: >> Can you use u-boot to load and test a customised uboot? >> What would be the best way to test a custom build u-boot leaving the >> original in its flash space protected? > > Yes. You would load the test u-boot from some other location (you can > read files from the JFFS2 filesystem, or you can load it over serial, > TFTP, from MMC, or CF. > > Now - which address to use is interesting. > > On the connex, and on the 1.1.4 version of u-boot on the verdex, > u-boot is loaded to A3F00000. On the verdex for u-boot-1.2.0, it's > loaded to 5c000000 (which appears to 256k of internal RAM). > > I performed the following test on my verdex, with the following two > files in my /root directory on the gumstix: > > 1321-u-boot.bin (which is 1.1.4) > 1352-u-boot.bin (which is 1.2.0) > > Runnng 1.1.4 (which executes from A3F00000), I tried the following: > > fsload a2000000 1321-u-boot.bin > go a2000000 > > which worked fine. > > fsload a2000000 /root/1352-u-boot.bin > go a2000000 > > failed, however > > fsload 5c000000 /root/1352-u-boot.bin > go 5c000000 > > worked fine. > > While running the 1352 version of u-boot (which executes from > 5c000000) > > fsloading to a2000000 works fine. > > u-boot checks the address it's currently running at and if it's not at > the correct address, it relocates itself and runs from the relocated > address. > > So, you don't want to load to the address that the current u-boot is > runnung from, and the only address I could use with u-boot-1.1.4 to > load 1.2.0 was 5c000000 > > -- > Dave Hylands > Vancouver, BC, Canada > http://www.DaveHylands.com/ > > ---------------------------------------------------------------------- > --- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users |
From: Dave H. <dhy...@gm...> - 2007-06-07 14:23:02
|
Hi Craig, On 6/7/07, Craig Hughes <cr...@gu...> wrote: > Note that loading a new u-boot into 5c000000 while running u-boot > from that location will 99.999% likely break, since you're executing > that code. Replacing code in RAM while the PC is pointing in there > somewhere is probably not going to work. > > I think with the u-boot running at 5c000000, the only way to test a > new u-boot would be to build it to load itself somewhere else (say, > a3f00000) and execute that using go. Once it works, then rebuild > with the load address at 5c000000 and flash it, then reboot. So,with the 1.2.0 u-boot running at 5c000000 I was able to load either the 1.1.4 or the 1.2.0 version by loading to Axxxxxx and doing a go to that address. The running u-boot should transfer to the "go" address, detect that it's not at 5c000000, copy itself into 5c000000 (overwriting the old u-boot) and life should be fine. The part I couldn't figure out is why the 1.1.4 u-boot couldn't load the 1.2.0 u-boot from any Axxxxxxx address. it always failed. -- Dave Hylands Vancouver, BC, Canada http://www.DaveHylands.com/ |
From: James W. <ji...@ho...> - 2007-06-07 19:39:04
|
Guys, thanks for the info , will be sure to give it a go when I get my V6LP back. HEH..... damn i need to learn patience. james >From: "Dave Hylands" <dhy...@gm...> >Reply-To: "General mailing list for gumstix users." ><gum...@li...> >To: "General mailing list for gumstix users." ><gum...@li...> >Subject: Re: [Gumstix-users] uboot testing >Date: Thu, 7 Jun 2007 07:22:41 -0700 > >Hi Craig, > >On 6/7/07, Craig Hughes <cr...@gu...> wrote: > > Note that loading a new u-boot into 5c000000 while running u-boot > > from that location will 99.999% likely break, since you're executing > > that code. Replacing code in RAM while the PC is pointing in there > > somewhere is probably not going to work. > > > > I think with the u-boot running at 5c000000, the only way to test a > > new u-boot would be to build it to load itself somewhere else (say, > > a3f00000) and execute that using go. Once it works, then rebuild > > with the load address at 5c000000 and flash it, then reboot. > >So,with the 1.2.0 u-boot running at 5c000000 I was able to load either >the 1.1.4 or the 1.2.0 version by loading to Axxxxxx and doing a go to >that address. > >The running u-boot should transfer to the "go" address, detect that >it's not at 5c000000, copy itself into 5c000000 (overwriting the old >u-boot) and life should be fine. > >The part I couldn't figure out is why the 1.1.4 u-boot couldn't load >the 1.2.0 u-boot from any Axxxxxxx address. it always failed. > >-- >Dave Hylands >Vancouver, BC, Canada >http://www.DaveHylands.com/ > >------------------------------------------------------------------------- >This SF.net email is sponsored by DB2 Express >Download DB2 Express C - the FREE version of DB2 express and take >control of your XML. No limits. Just data. Click to get it now. >http://sourceforge.net/powerbar/db2/ >_______________________________________________ >gumstix-users mailing list >gum...@li... >https://lists.sourceforge.net/lists/listinfo/gumstix-users _________________________________________________________________ Make every IM count. Download Messenger and join the im Initiative now. Its free. http://im.live.com/messenger/im/home/?source=TAGHM_June07 |