V2 RC10 via OE cross compile to OMAP3
Marc Kleine-Budde
mkl at pengutronix.de
Sat Dec 12 16:19:41 EST 2009
Freeman P. Pascal IV wrote:
> On Sat, 2009-12-12 at 12:54 +0100, Sascha Hauer wrote:
>> On Thu, Dec 10, 2009 at 10:50:49PM -0700, Freeman P. Pascal IV wrote:
>>> Hello,
>>>
>>> I'm trying to build RC10 for use on an Archos 7 internet media
>>> tablet. The idea is to load u-boot V2 during the stage 3 boot
>>> instead of the original modified initramfs image from flash.
>>> I could then select which kernel and root file-system I use to
>>> boot the rest of the way.
>>>
>>> On top of this, I am trying to use an OpenEmbedded overlay
>>> that is based on the SDE (Special Developer Edition) release
>>> provided by Archos. I want to use the cross compiler
>>> generated by the OE image in preparation for generating a
>>> recipe for doing the same when building my release images.
>>>
>>> With a bit tweaking, I have been able to generate binaries for
>>> RC10 for my Archos 7 and my BeagleBoard. Both using the their
>>> own cross compiler tools generated by their separate OE
>>> projects. This is using the patches for the OMAP3 found on
>>> this list.
>>>
>>> From what I have read, I should be able to copy the
>>> executable
>>> ELF binary (not the .bin file) on to my respective devices and
>>> run it to test if it works. When I do this, I get an "Illegal
>>> instruction" error.
>>>
>>> Could I get someone to confirm or deny my assumption about
>>> being able to test the elf binary on my devices? Should I be
>>> compiling the sandbox version for my devices instead of the
>>> platform/board specific versions?
>> You cannot run the ELF file on your devices, you have to use the bin
>> file for this. The ELF file is only usable for the sandbox target in
>> which case you run it on the machine you compiled it on.
>>
>> Sascha
>>
>
> Using the elf executable was really only a test to see if I had the
> compiler settings correct. If it started up and got to a prompt I was
> going to be satisfied. If it ran I could have some confidence it would
> do so once I moved into flash where my existing boot-load could execute
> it.
>
> The problem is that the Archos 5 and Archos 7 are consumer devices with
> no exposed JTAG and no obvious serial port. There is a recovery chain,
> but it requires that the original stage 0 boot-loader, stage 1
> boot-loader, and recovery flash image are all functional. I want to
> preserve the original boot-loader, but use V2 to intercept loading the
> normal kernel and allow for pre-boot operations (such as selecting an
> alternate kernel, rootfs, or kernel arguments). The whole idea is to
> try avoid bricking the device while still allowing some pre-boot
> flexibility.
>
> Does anyone have any suggestions how to test and possibly debug without
> GDB support within the restrictions I listed above? Qemu-omap3 could be
> an alternative, but I would have to emulate enough of the Archos
> hardware to make it possible.
If it's possible within your existing boot environment to load the
u-boot-v2.bin into your RAM and start it, then try it. The same
u-boot-v2 image can be started from RAM, NOR and NAND.
Cheers, Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Linux Solutions for Science and Industry | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 260 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/barebox/attachments/20091212/43796558/attachment.sig>
More information about the u-boot-v2
mailing list