ARM at the Cambridge DevSummit

[Warner Losh]

On Jul 11, 2012, at 8:13 PM, Tim Kientzle wrote:

> 
> On Jul 11, 2012, at 6:10 AM, David Chisnall wrote:
> 
>> Hello all of the FreeBSD/ARM flavoured people,
>> 
>> The Cambridge DevSummit in August will be attended by some people from ARM, so it would be good to have as many FreeBSD/ARM developers there as possible.  If you haven't signed up yet, please do.
>> 
>> Please also let me have a list of topics that you'd like to discuss with people from ARM so that I can try to make sure that relevant people attend.
> 
> I won't be able to attend, but after some recent work on
> ARM booting, I'm very curious if there are emerging
> conventions (I hesitate to use the word "standards")
> for how ARM systems boot.

There's two standards that we can/should follow.  First, there's uldr, which is the uboot + /boot/loader path.  This works well enough, but has a weak point here and there.  The FDT stuff is the future for most ARM platforms, but currently is limited to the Marvel SoCs (where it is pretty much mandatory).  I believe we should adapt this for the new armv6 families that are coming in, since new Linux platforms have to support it, and these are "new" by that definition.

The second is a more direct interface to uboot.  Or rather a more direct interface to the Linux standard booting protocol.  I've made some sketches on the wall, and filled in a few things here.  However, it is very incomplete.  I've been unable to test it because I've been unable to build a bootm compatible image yet, and uboot only uses the Linux ABI when you boot with bootm.  For the 'go' interface that's documented on the FreeBSDAtmel wiki page, args are passed in another way.  I can boot with that, but not bootm.  To be honest, I've not tracked the problem much yet, other than to notice it...

> Warner's been talking about working towards a true
> GENERIC kernel on ARM.  That looks almost feasible,
> but we still seem a long ways from being able to build
> a generic bootloader.

Yes.  There's the whole point of the boot args stuff I've done: to try to have a standardish interface to the kernel.  All the boot loader interfaces would parse the goo from the boot loader and set variables/structures in the kernel that the rest of the kernel interfaces to.

> Is this likely to change?

I'd like it to, but it is a lot of work, and there's a lot of rototilling to do in the Atmel area...

Warner