[U-Boot] U-Boot SPL on OMAP3 and peripheral boot and LG Optimus Black P970 (sniper) support

[Paul Kocialkowski]

Greetings, as this is my first post to the list, I'll quickly introduce
myself. I'm Paul Kocialkowski, lead developer of Replicant: a fully free
version of Android running on several mobile devices. I'm very
interested in embedded devices that can run with fully free software,
hence my interest in U-Boot for the bootloader part.

I am currently working on adding support for the LG Optimus Black
(P970), codename sniper to upstream U-Boot. This device comes with a GP
OMAP3630 and has old X-Loader and U-Boot sources available. In addition,
very precise schematics of the device are available online.

In order to start developing on the device, I was able to change the
boot order to USB first (by removing a resistor) and get UART3 out of
the UART switch IC. I will soon provide more details on that via my
personal blog and the Replicant wiki.

Over the past few months (I've been busy with other things), I managed
to get X-Loader running to a point where it can load a secondary
bootloader such as U-Boot, only to realize that X-Loader is a deprecated
minimized copy of U-Boot. Hence I believe that using the U-Boot SPL is
what really makes sense.

I faced a few interesting issues today while bringing up that device on
U-Boot SPL. First, CONFIG_SPL_TEXT_BASE is usually set to 0x40200800 on
other OMAP3 devices, which is perfectly fine, except in the case of
peripheral boot. In all other modes, there is a header on the image
(e.g. MLO) to tell the bootrom where to load the image. But in the case
of peripheral booting, it is loaded at a fixed address: 0x40200000 (SRAM
start). Hence, all the images for other OMAP3 devices cannot be booted
via peripheral boot (that is, UART or USB).

Setting CONFIG_SPL_TEXT_BASE to 0x40200000 makes U-Boot SPL start
properly with peripheral booting. It may be worth applying that change
to other devices as well so that peripheral booting can be used.

The second, more important issue, is the boot device selection.
save_boot_params stores the booting parameter structure, which holds the
current booting device, as provided by the bootrom. In the case of
peripheral booting, that information cannot be used to determine which
device to boot U-Boot from. How do you think that should be handled?

In addition, the current SPL code will only try one device and hang if
it didn't work. It would be more useful if it could try a few options
before giving up. In particular, my use case would be the following:
having the SPL installed on MMC2 or loaded via USB and having it to try
and boot from MMC1 (sdcard) first and fallback to MMC2 (emmc) when e.g.
the file was not found on the sdcard. This makes the development process
rather painless, as it allows testing new builds of U-Boot from sdcard,
without any risk of bricking the device.

What do you think?

-- 
Paul Kocialkowski, Replicant developer

Replicant is a fully free Android distribution

Website:        http://www.replicant.us/
Wiki/Tracker:   http://redmine.replicant.us/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20141027/590134d6/attachment-0001.pgp>