Peripheral boot of x-loader

120 views
Skip to first unread message

Steve Sakoman

unread,
Sep 2, 2011, 1:01:44 PM9/2/11
to x-lo...@googlegroups.com
Has anyone been successful doing a peripheral boot using the current
x-loader head?

I tried this on Overo today using Nishanth's omap u-boot utilities
with no success.

I have an ancient x-load binary from 2009 that works just fine with
these tools, but it seems something has broken since then.

Any ideas?

Steve

Aneesh V

unread,
Sep 4, 2011, 5:34:02 AM9/4/11
to x-lo...@googlegroups.com, Steve Sakoman
Hi Steve,

On Friday 02 September 2011 10:31 PM, Steve Sakoman wrote:
> Has anyone been successful doing a peripheral boot using the current
> x-loader head?

Are you trying to use x-loader as the 2nd image for a peripheral boot
OR are you trying to download x-loader to SDRAM using OmapFlash or some
other tool and run it from there?

best regards,
Aneesh

Steve Sakoman

unread,
Sep 4, 2011, 9:53:46 AM9/4/11
to Aneesh V, x-lo...@googlegroups.com

The former -- USB peripheral boot using Nishanth's pusb tool.

As I mentioned, I have an old x-load binary that I built in 2009 that
works just fine. However an x-load built from the current head does
not.

Just wondering whether anyone else has been successful.

Steve

chris...@gentex.com

unread,
Mar 30, 2012, 2:42:03 PM3/30/12
to x-lo...@googlegroups.com, Aneesh V
The current head of X-loader isn't setup for being loaded via peripheral boot without modification. Booting from USB using the ROM bootloader will place the code at the start of the internal RAM, which is 0x40200000 on the Beagle and 0x40300000 on the Panda. Therefore, you must change TEXT_BASE in config.mk for the the board you're using to match the correct address. However, that won't be the end of the problems. I traced it through with CCS debug and found that the stack gets set to an invalid RAM location (below the internal RAM range) and so the core hangs because of this. X-loader is setup by default to put the run-time stack and globals below the code in memory, which causes invalid memory to be accessed when TEXT_BASE is set to the start of RAM. Booting the unaltered MLO file from the SD card works fine since the header on that file can specify which address in RAM to copy itself to, which reserves the lower memory for the stack. So you'll need to do some other editing, in the start.S file for instance, to get X-loader working via USB boot.

chris...@gentex.com

unread,
Mar 30, 2012, 2:52:07 PM3/30/12
to x-lo...@googlegroups.com, Aneesh V
See this post for a patch with will show you a way to make the changes (for the stack).


On Sunday, September 4, 2011 9:53:46 AM UTC-4, sakoman wrote:

chris...@gentex.com

unread,
Apr 2, 2012, 8:17:14 AM4/2/12
to x-lo...@googlegroups.com, Aneesh V
Actually, there's one more change to make for the BeagleBoard. It's in s_init(). Like the PandaBoard, if the chip is booted via the USB peripheral, the clocks and prcm must be configured before the pin mux is configured, otherwise it will hang. Once you do this, and incorporate the stack fix referenced in my previous post, X-loader works (from Gitorious) on both the Beagle (3430) and Panda (4430) boards when booted via the USB peripheral from the onchip ROM bootloader.
Reply all
Reply to author
Forward
0 new messages