[U-Boot] Running vanilla u-boot v2012.10 on Guruplug
Hello,
I have compiled u-boot v2012.10 for my Guruplug and would like to test it from RAM before I write it to flash. So following instructions I found via internet search I load the u-boot.kwb from SATA disk into RAM at address 0x800000 (ext2load ide 0:1 0x800000 u-boot.kwb) and then start it with "go 0x800200".
Unfortunately, this only restarts the running u-boot (v2012.04.01 from Debian) instead of starting the new one.
So my questions are:
1) Does running from RAM this way work at all? 2) If I can't test it from RAM, is it save to write it to flash anyway?
Thanks...
Dirk
Dear Dirk Heinrichs,
In message 1457183.WG9k8kxG45@moria you wrote:
- Does running from RAM this way work at all?
- If I can't test it from RAM, is it save to write it to flash anyway?
Did you read the FAQ? Especially http://www.denx.de/wiki/view/DULG/CanUBootBeConfiguredSuchThatItCanBeStarted... ?
Best regards,
Wolfgang Denk
Am Samstag 12 Januar 2013, 16:51:51 schrieb Wolfgang Denk:
Did you read the FAQ? Especially http://www.denx.de/wiki/view/DULG/CanUBootBeConfiguredSuchThatItCanBeStarted InRAM ?
Now I did :) Thanx a lot.
Interesting that [1] states it's possible, though...
Bye...
Dirk
[1]: https://doukki.net/doku.php?id=wiki:tutoriels:uboot.howto
On Sat, Jan 12, 2013 at 08:41:36PM +0100, Dirk Heinrichs wrote:
Am Samstag 12 Januar 2013, 16:51:51 schrieb Wolfgang Denk:
Did you read the FAQ? Especially http://www.denx.de/wiki/view/DULG/CanUBootBeConfiguredSuchThatItCanBeStarted InRAM ?
Now I did :) Thanx a lot.
Interesting that [1] states it's possible, though...
With the dreamplug, I often load u-boot into RAM via the JTAG (0x0600000 and 0x0800000), and then 'resume 0x0600000'. Then use the u-boot running from 0x0600000 to burn the image to SPI flash from 0x0800000. But that's loaded via the JTAG, not from a running u-boot.
I think I posted instructions to this mailinglist a while ago about this. If you have the JTAG (it's only $35US), I would advise trying that.
thx,
Jason.
On 01/12/2013 09:41 PM, Jason wrote:
On Sat, Jan 12, 2013 at 08:41:36PM +0100, Dirk Heinrichs wrote:
Am Samstag 12 Januar 2013, 16:51:51 schrieb Wolfgang Denk:
Did you read the FAQ? Especially http://www.denx.de/wiki/view/DULG/CanUBootBeConfiguredSuchThatItCanBeStarted InRAM ?
Now I did :) Thanx a lot.
Interesting that [1] states it's possible, though...
With the dreamplug, I often load u-boot into RAM via the JTAG (0x0600000 and 0x0800000), and then 'resume 0x0600000'. Then use the u-boot running from 0x0600000 to burn the image to SPI flash from 0x0800000. But that's loaded via the JTAG, not from a running u-boot.
I think I posted instructions to this mailinglist a while ago about this. If you have the JTAG (it's only $35US), I would advise trying that.
For what is worth, I can confirm above for the dreamplug.. I wrote this down a once...:
cd /where/uboot_is sudo openocd -f /usr/share/openocd/scripts/board/sheevaplug.cfg
# other console telnet localhost 4444 sheevaplug_init load_image u-boot load_image u-boot.kwb 0x0800000
resume 0x0600000 # and hit stop in the serial terminal
no Idea about the guruplug though..
Regards, Jeroen
On Sat, Jan 12, 2013 at 10:30:58PM +0100, Jeroen Hofstee wrote:
On 01/12/2013 09:41 PM, Jason wrote:
On Sat, Jan 12, 2013 at 08:41:36PM +0100, Dirk Heinrichs wrote:
Am Samstag 12 Januar 2013, 16:51:51 schrieb Wolfgang Denk:
Did you read the FAQ? Especially http://www.denx.de/wiki/view/DULG/CanUBootBeConfiguredSuchThatItCanBeStarted InRAM ?
Now I did :) Thanx a lot.
Interesting that [1] states it's possible, though...
With the dreamplug, I often load u-boot into RAM via the JTAG (0x0600000 and 0x0800000), and then 'resume 0x0600000'. Then use the u-boot running from 0x0600000 to burn the image to SPI flash from 0x0800000. But that's loaded via the JTAG, not from a running u-boot.
I think I posted instructions to this mailinglist a while ago about this. If you have the JTAG (it's only $35US), I would advise trying that.
For what is worth, I can confirm above for the dreamplug.. I wrote this down a once...:
cd /where/uboot_is sudo openocd -f /usr/share/openocd/scripts/board/sheevaplug.cfg
# other console telnet localhost 4444 sheevaplug_init load_image u-boot load_image u-boot.kwb 0x0800000
resume 0x0600000 # and hit stop in the serial terminal
Yep, this is exactly what I have.
no Idea about the guruplug though..
It should work fine (unless you broke something, but that's the whole point of this exercise, isn't it ;-) ). If you get a u-boot command prompt in your serial window after 'resume 0x0600000', then you just successfully tested your u-boot.
hth,
Jason.
On Sat, Jan 12, 2013 at 10:30:58PM +0100, Jeroen Hofstee wrote:
On 01/12/2013 09:41 PM, Jason wrote:
On Sat, Jan 12, 2013 at 08:41:36PM +0100, Dirk Heinrichs wrote:
Am Samstag 12 Januar 2013, 16:51:51 schrieb Wolfgang Denk:
Did you read the FAQ? Especially http://www.denx.de/wiki/view/DULG/CanUBootBeConfiguredSuchThatItCanBeStarted InRAM ?
Now I did :) Thanx a lot.
Interesting that [1] states it's possible, though...
With the dreamplug, I often load u-boot into RAM via the JTAG (0x0600000 and 0x0800000), and then 'resume 0x0600000'. Then use the u-boot running from 0x0600000 to burn the image to SPI flash from 0x0800000. But that's loaded via the JTAG, not from a running u-boot.
I think I posted instructions to this mailinglist a while ago about this. If you have the JTAG (it's only $35US), I would advise trying that.
For what is worth, I can confirm above for the dreamplug.. I wrote this down a once...:
cd /where/uboot_is sudo openocd -f /usr/share/openocd/scripts/board/sheevaplug.cfg
# other console telnet localhost 4444 sheevaplug_init load_image u-boot load_image u-boot.kwb 0x0800000
resume 0x0600000 # and hit stop in the serial terminal
Yep, this is exactly what I have.
no Idea about the guruplug though..
It should work fine (unless you broke something, but that's the whole point of this exercise, isn't it ;-) ). If you get a u-boot command prompt in your serial window after 'resume 0x0600000', then you just successfully tested your u-boot.
hth,
Jason.
Am Samstag 12 Januar 2013, 15:41:54 schrieb Jason:
Interesting that [1] states it's possible, though...
With the dreamplug, I often load u-boot into RAM via the JTAG (0x0600000 and 0x0800000), and then 'resume 0x0600000'. Then use the u-boot running from 0x0600000 to burn the image to SPI flash from 0x0800000. But that's loaded via the JTAG, not from a running u-boot.
Yes, I do have a JTAG. And I have used openocd in the past to recover the plug, so I will try that method.
I think I posted instructions to this mailinglist a while ago about this. If you have the JTAG (it's only $35US), I would advise trying that.
Yes, I've seen that, too. However, I've also seen the instructions for doing it from within u-boot in the link I posted. Since they didn't work I thought it might be bug. Never thought that it wasn't supported and not supposed to work at all :)
Bye...
Dirk
Hi Dirk,
On Sat, 12 Jan 2013 20:41:36 +0100, Dirk Heinrichs dirk.heinrichs@altum.de wrote:
Am Samstag 12 Januar 2013, 16:51:51 schrieb Wolfgang Denk:
Did you read the FAQ? Especially http://www.denx.de/wiki/view/DULG/CanUBootBeConfiguredSuchThatItCanBeStarted InRAM ?
Now I did :) Thanx a lot.
Interesting that [1] states it's possible, though...
Bye...
Dirk
My experience with starting U-Boot from RAM is that it's usually impossible when U-Boot is meant to start directly from FLASH, mostly (but not only) because the code at some point will rely on being able to keep on running even through access to DRAM is not possible.
Now, starting U-Boot *may* be possible when U-Boot is loaded in DRAM before starting it, but is a very tricky and undependable process. For instance, on the Wireless Space target I am maintaining, and which is supposed to be preloaded from FLASH into DRAM by a ROM monitor, if I start the OpenOCD server, then in the console, do a break and / or a reset halt, I won't be able to load_image u-boot; whereas if I do the same actions as -c options when launching OpenOCD. And I have checked countless times that the DRAM init sequence in the config file is bit-for-bit identical to that used by the KWB which wraps the U-Boot image, and which boots fine on its own.
Amicalement,
Hi Dirk,
Am 13.01.2013 10:25, schrieb Albert ARIBAUD:
On Sat, 12 Jan 2013 20:41:36 +0100, Dirk Heinrichs dirk.heinrichs@altum.de wrote:
Am Samstag 12 Januar 2013, 16:51:51 schrieb Wolfgang Denk:
Did you read the FAQ? Especially http://www.denx.de/wiki/view/DULG/CanUBootBeConfiguredSuchThatItCanBeStarted InRAM ?
Now I did :) Thanx a lot.
Interesting that [1] states it's possible, though...
Bye...
Dirk
My experience with starting U-Boot from RAM is that it's usually impossible when U-Boot is meant to start directly from FLASH, mostly (but not only) because the code at some point will rely on being able to keep on running even through access to DRAM is not possible.
You can use the kwboot tool from the tools directory to boot a Marvell Kirkwood SoC via UART0.
Kind regards, Stefan
Hello,
thanks a lot for all your helpful replies. I have tested v2012.10 succesfully using the OpenOCD method and wrote it to nand from within itself afterwards.
I wasn't sure where Debians 2012.04.01 came from (Denx or Marvell), so I needed the test. Now that I'm confident that vanilla versions will work w/o problems, I will flash future versions directly from the running Linux system again.
Bye...
Dirk
participants (7)
-
Albert ARIBAUD -
Dirk Heinrichs -
Jason -
Jason Cooper -
Jeroen Hofstee -
Stefan Herbrechtsmeier -
Wolfgang Denk