From: Ben E. <be...@cy...> - 2006-05-30 12:48:53
|
I am trying to update the uboot loader but I want to know if something goes wrong how do I install a known good uboot image if the update goes dies for some reason. Thanks, Ben Erridge |
From: Alexandre P. N. <al...@om...> - 2006-05-30 13:03:55
|
Ben Erridge escreveu: > I am trying to update the uboot loader but I want to know if something > goes wrong how do I install a known good uboot image if the update > goes dies for some reason. > Thanks, > Ben Erridge Use address 0xA2000000 to download u-boot to memory, then type go 0xA2000000 to test it from ram before upgrading (I think the syntax is like that, I'm typing from memory). Run the reset command to load your original u-boot, then download the new one again to the same address. That's for safety. The steps for upgrading are un-protecting, erasing and writing the new u-boot to flash. After that, you can compare the flash version to the in-memory version, and if it's ok, you can reboot. Otherwise, you have one last chance to restore or something, if you disable or reboot it and it's not ok, the only known way to recover is by attaching a jtag debugger and having it erase and reprogram the flash. Please follow the directions on gumstix's wiki and perhaps on the mailing list archives, the directions on u-boot sites are too generic and specially load addresses may do the wrong thing when used with gumstix's memory map. Also only use the u-boot from the gumstix's buildroot, you can download pre-compiled binary versions if you lack that. I have sucessfully upgraded u-boot almost everytime I tried, however at least once I forgot to erase the flash before recording on it, transforming a gumstix on an expensive brick. The jtag restore procedure is a pain in the ass, and sending it back to gumstix, inc. so to do a reflash service may be a pain in your pocket as well if you live outside US. I must warn you that AFAIK there's an issue with latest u-boot and some mmc cards, I've seen people complaining about being unable to read them after upgrading. Not sure if that was solved. Good luck, Alexandre |
From: Ben E. <be...@cy...> - 2006-05-30 13:12:29
|
That is a lot of very good information, Thanks alot! You mentioned direction on the gumstix wiki.. although I've looked and can only find directions for installing new filesystem images, unless that procedure also installs a new uboot boot loader but it didn't sound like it. Anyway if it is there can you point me at it? The problem I am trying to fix is 1: ethernet mac address on all my connex are identical and 2 the cpu serial numbers are identical and I need to track a lot of these in the field and must have a way to uniquely ID each. Craig Hughes said the ether MAC was fixed in new uboot dists so I am wearily preparing to load the latest one. Alexandre Pereira Nunes wrote: > Ben Erridge escreveu: > >> I am trying to update the uboot loader but I want to know if >> something goes wrong how do I install a known good uboot image if the >> update goes dies for some reason. >> Thanks, >> Ben Erridge > > > Use address 0xA2000000 to download u-boot to memory, then type go > 0xA2000000 to test it from ram before upgrading (I think the syntax is > like that, I'm typing from memory). Run the reset command to load your > original u-boot, then download the new one again to the same address. > That's for safety. > > The steps for upgrading are un-protecting, erasing and writing the new > u-boot to flash. After that, you can compare the flash version to the > in-memory version, and if it's ok, you can reboot. Otherwise, you have > one last chance to restore or something, if you disable or reboot it > and it's not ok, the only known way to recover is by attaching a jtag > debugger and having it erase and reprogram the flash. > > Please follow the directions on gumstix's wiki and perhaps on the > mailing list archives, the directions on u-boot sites are too generic > and specially load addresses may do the wrong thing when used with > gumstix's memory map. Also only use the u-boot from the gumstix's > buildroot, you can download pre-compiled binary versions if you lack > that. > > I have sucessfully upgraded u-boot almost everytime I tried, however > at least once I forgot to erase the flash before recording on it, > transforming a gumstix on an expensive brick. The jtag restore > procedure is a pain in the ass, and sending it back to gumstix, inc. > so to do a reflash service may be a pain in your pocket as well if you > live outside US. > > I must warn you that AFAIK there's an issue with latest u-boot and > some mmc cards, I've seen people complaining about being unable to > read them after upgrading. Not sure if that was solved. > > Good luck, > > Alexandre > > > > ------------------------------------------------------- > All the advantages of Linux Managed Hosting--Without the Cost and Risk! > Fully trained technicians. The highest number of Red Hat > certifications in > the hosting industry. Fanatical Support. Click to learn more > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642 > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users |
From: Alexandre P. N. <al...@om...> - 2006-05-30 13:58:09
|
Ben Erridge escreveu: > That is a lot of very good information, Thanks alot! You mentioned > direction on the gumstix wiki.. although I've looked and can only find > directions for installing new filesystem images, unless that procedure > also installs a new uboot boot loader but it didn't sound like it. > Anyway if it is there can you point me at it? > > The problem I am trying to fix is 1: ethernet mac address on all my > connex are identical and 2 the cpu serial numbers are identical and I > need to track a lot of these in the field and must have a way to > uniquely ID each. > Craig Hughes said the ether MAC was fixed in new uboot dists so I am > wearily preparing to load the latest one. > > The procedure for upgrading u-boot is comparable to the rootfs. First load the u-boot image to 0xa2000000 as you would with the rootfs image. Then follow this (copyed from an e-mail by Craig Huges posted here on the list): > Now -- beware. If you write a bad u-boot.bin, then you'll hose your > gumstix. A better way of doing this is through u-boot, where you can > load the new u-boot to RAM and execute it before you try and write it > to flash: > > [assuming you loaded u-boot.bin to RAM at a2000000] > GUM> go a2000000 > [now the new u-boot will be running from RAM] > ... > GUM> reset > [if the new u-boot ran OK, then reset to get back to the u-boot from > flash] > ... > [now back at the original u-boot from flash prompt, re-load u-boot to > a2000000 in RAM] > GUM> crc a2000000 $filesize > [check CRC against the CRC for u-boot.bin from your host] > GUM> pro off 1:0-1 && era 1:0-1 && cp.b a2000000 0 $filesize && res > [hold your breath] > > If you're lucky, the new u-boot will now load and execute from > flash. It will automatically re-protect itself, so you don't need to > do that. > > C |
From: Simon de B. <si...@v2...> - 2006-05-30 13:23:22
|
To test your u-boot from ram you probalbly want to #define CONFIG_SKIP_LOWLEVEL_INIT and CONFIG_SKIP_RELOCATE_UBOOT. Also you want to set TEXT_BASE to the memory location you load the image to. Chrs! Simon Alexandre Pereira Nunes wrote: > Ben Erridge escreveu: > >> I am trying to update the uboot loader but I want to know if something >> goes wrong how do I install a known good uboot image if the update >> goes dies for some reason. >> Thanks, >> Ben Erridge > > > Use address 0xA2000000 to download u-boot to memory, then type go > 0xA2000000 to test it from ram before upgrading (I think the syntax is > like that, I'm typing from memory). Run the reset command to load your > original u-boot, then download the new one again to the same address. > That's for safety. > > The steps for upgrading are un-protecting, erasing and writing the new > u-boot to flash. After that, you can compare the flash version to the > in-memory version, and if it's ok, you can reboot. Otherwise, you have > one last chance to restore or something, if you disable or reboot it and > it's not ok, the only known way to recover is by attaching a jtag > debugger and having it erase and reprogram the flash. > > Please follow the directions on gumstix's wiki and perhaps on the > mailing list archives, the directions on u-boot sites are too generic > and specially load addresses may do the wrong thing when used with > gumstix's memory map. Also only use the u-boot from the gumstix's > buildroot, you can download pre-compiled binary versions if you lack that. > > I have sucessfully upgraded u-boot almost everytime I tried, however at > least once I forgot to erase the flash before recording on it, > transforming a gumstix on an expensive brick. The jtag restore procedure > is a pain in the ass, and sending it back to gumstix, inc. so to do a > reflash service may be a pain in your pocket as well if you live outside > US. > > I must warn you that AFAIK there's an issue with latest u-boot and some > mmc cards, I've seen people complaining about being unable to read them > after upgrading. Not sure if that was solved. > > Good luck, > > Alexandre > > > > ------------------------------------------------------- > All the advantages of Linux Managed Hosting--Without the Cost and Risk! > Fully trained technicians. The highest number of Red Hat certifications in > the hosting industry. Fanatical Support. Click to learn more > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642 > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > |
From: Alexandre P. N. <al...@om...> - 2006-05-30 13:38:30
|
Simon de Bakker escreveu: >To test your u-boot from ram you probalbly want to #define >CONFIG_SKIP_LOWLEVEL_INIT and CONFIG_SKIP_RELOCATE_UBOOT. >Also you want to set TEXT_BASE to the memory location you load the image >to. > >Chrs! >Simon > > For gumstix's default build, that's not necessary: if loading from flash, it relocates itself to ram, otherwise it runs from there. It works fine at least when loading it to 0xa2000000 (but I suspect it maybe position independent, or perhaps, it always relocates to a well-know address; All I know is that it runs fine for me on both scenarios). - Alexandre |
From: Simon de B. <si...@v2...> - 2006-05-30 14:05:13
|
Alexandre Pereira Nunes wrote: > Simon de Bakker escreveu: > >> To test your u-boot from ram you probalbly want to #define >> CONFIG_SKIP_LOWLEVEL_INIT and CONFIG_SKIP_RELOCATE_UBOOT. >> Also you want to set TEXT_BASE to the memory location you load the image >> to. >> >> Chrs! >> Simon >> >> > > For gumstix's default build, that's not necessary: if loading from > flash, it relocates itself to ram, otherwise it runs from there. It > works fine at least when loading it to 0xa2000000 (but I suspect it > maybe position independent, or perhaps, it always relocates to a > well-know address; All I know is that it runs fine for me on both > scenarios). > > - Alexandre > You can omit defining CONFIG_SKIP_RELOCATE_UBOOT, but it doesn't make much sense to relocate while it is already loaded into ram. CONFIG_SKIP_LOWLEVEL_INIT as it says make u-boot skip low level initializations already done by 'real' u-boot. Apparently it works without these but it seemed safer to me to do it the tidy way ;) And when adding a menu option to kbuild it is just a matter of a simple selection. Chrs! Simon |
From: Craig H. <cr...@gu...> - 2006-05-31 00:16:53
|
On May 30, 2006, at 6:03 AM, Alexandre Pereira Nunes wrote: > Ben Erridge escreveu: > >> I am trying to update the uboot loader but I want to know if >> something goes wrong how do I install a known good uboot image if >> the update goes dies for some reason. >> Thanks, >> Ben Erridge > > > Use address 0xA2000000 to download u-boot to memory, then type go > 0xA2000000 to test it from ram before upgrading (I think the syntax > is like that, I'm typing from memory). Run the reset command to > load your original u-boot, then download the new one again to the > same address. That's for safety. That's not 100% foolproof, since running from RAM doesn't go through the memsetup code; so running that same code from flash will behave differently than running it from RAM. If you're not modifying the memsetup part of the code though, then this is generally a good thing to do before flashing a new u-boot. > The steps for upgrading are un-protecting, erasing and writing the > new u-boot to flash. After that, you can compare the flash version > to the in-memory version, and if it's ok, you can reboot. > Otherwise, you have one last chance to restore or something, if you > disable or reboot it and it's not ok, the only known way to recover > is by attaching a jtag debugger and having it erase and reprogram > the flash. > > Please follow the directions on gumstix's wiki and perhaps on the > mailing list archives, the directions on u-boot sites are too > generic and specially load addresses may do the wrong thing when > used with gumstix's memory map. Also only use the u-boot from the > gumstix's buildroot, you can download pre-compiled binary versions > if you lack that. > > I have sucessfully upgraded u-boot almost everytime I tried, > however at least once I forgot to erase the flash before recording > on it, transforming a gumstix on an expensive brick. The jtag > restore procedure is a pain in the ass, and sending it back to > gumstix, inc. so to do a reflash service may be a pain in your > pocket as well if you live outside US. > > I must warn you that AFAIK there's an issue with latest u-boot and > some mmc cards, I've seen people complaining about being unable to > read them after upgrading. Not sure if that was solved. I haven't been able to reproduce the problem, but I might just need to be a bit more thorough in trying more different MMC cards. C |
From: Ben E. <be...@cy...> - 2006-05-30 13:50:38
|
alright I am trying to load the u-boot image from nfs I have had success loading the filesystem by setting the ipaddr and serverip env variable. and copying the filesystem image to the default name and directory. GUM> nfs *** Warning: no boot file name; using '/nfsroot/2802A8C0.img' Using SMC91C1111-0 device File transfer via NFS from server 192.168.2.1; our IP address is 192.168.2.40 Filename '/nfsroot/2802A8C0.img'. Load address: 0xa2000000 Loading: ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ######################################### done Bytes transferred = 3869448 (3b0b08 hex) can I do the same with the u-boot.bin file? Just copy it to /nfsroot/2802A8C0.img on the nfs server and proceed with instructions on the wiki? Also this is the help for nfs on uboot. mostly self explanitory except the last arg [host ip addr:bootfilename] can anyone give me an example of usage for this command nfs [loadAddress] [host ip addr:bootfilename] Alexandre Pereira Nunes wrote: > Simon de Bakker escreveu: > >> To test your u-boot from ram you probalbly want to #define >> CONFIG_SKIP_LOWLEVEL_INIT and CONFIG_SKIP_RELOCATE_UBOOT. >> Also you want to set TEXT_BASE to the memory location you load the image >> to. >> >> Chrs! >> Simon >> >> > > For gumstix's default build, that's not necessary: if loading from > flash, it relocates itself to ram, otherwise it runs from there. It > works fine at least when loading it to 0xa2000000 (but I suspect it > maybe position independent, or perhaps, it always relocates to a > well-know address; All I know is that it runs fine for me on both > scenarios). > > - Alexandre > > > > ------------------------------------------------------- > All the advantages of Linux Managed Hosting--Without the Cost and Risk! > Fully trained technicians. The highest number of Red Hat > certifications in > the hosting industry. Fanatical Support. Click to learn more > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642 > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users |
From: ken s. <ken...@gm...> - 2006-05-30 15:13:03
|
On 5/30/06, Ben Erridge <be...@cy...> wrote: > alright I am trying to load the u-boot image from nfs I have had success > loading the filesystem by setting the ipaddr and serverip env variable. > and copying the filesystem image to the default name and directory. you should configure nfs on your server. > Also this is the help for nfs on uboot. mostly self explanitory except > the last arg [host ip addr:bootfilename] can anyone give me an example > of usage for this command > nfs [loadAddress] [host ip addr:bootfilename] > nfs a2000000 192.168.2.1:/path/to/image regards, ken |
From: Craig H. <cr...@gu...> - 2006-05-31 00:35:42
|
On May 30, 2006, at 7:05 AM, Simon de Bakker wrote: > Alexandre Pereira Nunes wrote: >> Simon de Bakker escreveu: >> >>> To test your u-boot from ram you probalbly want to #define >>> CONFIG_SKIP_LOWLEVEL_INIT and CONFIG_SKIP_RELOCATE_UBOOT. >>> Also you want to set TEXT_BASE to the memory location you load >>> the image >>> to. >>> >>> Chrs! >>> Simon >>> >>> >> >> For gumstix's default build, that's not necessary: if loading from >> flash, it relocates itself to ram, otherwise it runs from there. It >> works fine at least when loading it to 0xa2000000 (but I suspect it >> maybe position independent, or perhaps, it always relocates to a >> well-know address; All I know is that it runs fine for me on both >> scenarios). >> >> - Alexandre >> > > You can omit defining CONFIG_SKIP_RELOCATE_UBOOT, but it doesn't make > much sense to relocate while it is already loaded into ram. > CONFIG_SKIP_LOWLEVEL_INIT as it says make u-boot skip low level > initializations already done by 'real' u-boot. Apparently it works > without these but it seemed safer to me to do it the tidy way ;) And > when adding a menu option to kbuild it is just a matter of a simple > selection. I would say it's almost certainly safer *not* to change the defines, but just use the u-boot as is. It will relocate itself automatically to where the linker stuff expects it to be (ie from one part of RAM to another, where it should be). It will skip the low-level init stuff if it detects that it's already in RAM, rather than being loaded from flash -- so the skip low level thing is completely moot. Making changes in the configs for those 2 params just makes it more likely that you'll hose things in a way which turns your stix into a doorstop. Particularly if you go messing with TEXT_BASE and such stuff. C |
From: Simon de B. <si...@v2...> - 2006-06-01 09:44:32
|
Craig Hughes wrote: > I would say it's almost certainly safer *not* to change the defines, but > just use the u-boot as is. It will relocate itself automatically to > where the linker stuff expects it to be (ie from one part of RAM to > another, where it should be). It will skip the low-level init stuff if > it detects that it's already in RAM, rather than being loaded from flash > -- so the skip low level thing is completely moot. Making changes in > the configs for those 2 params just makes it more likely that you'll > hose things in a way which turns your stix into a doorstop. > Particularly if you go messing with TEXT_BASE and such stuff. > > C > Well, based on the u-boot README and cpu/pxa/start.S it seemed the correct thing to do, maybe other ARM based boards are less easy on this stuff? At least i don't think it is unsafe to do as long as you remember to change back when done testing and ready to reflash (otherwise you would indeed end up with a nice doorstop). But if all works just the same without i will be happy to leave it out myself next time :) Cheers, Simon |
From: Craig H. <cr...@gu...> - 2006-06-01 20:07:15
|
On Jun 1, 2006, at 2:44 AM, Simon de Bakker wrote: > At least i don't think it is unsafe to do as long as you remember > to change back when done testing and ready to reflash (otherwise you > would indeed end up with a nice doorstop) Yup -- that's the key! My memory is terrible, so I just try to avoid getting myself into those situations to begin with. C |