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/
signature.asc
Description: This is a digitally signed message part
_______________________________________________ U-Boot mailing list [email protected] http://lists.denx.de/mailman/listinfo/u-boot
