Hi Wolfgang
On Wed, May 11, 2011 at 4:03 AM, Wolfgang Denk <w...@denx.de> wrote:
> Dear Graeme Russ,
>
> In message <4dc94cd4.2050...@gmail.com> you wrote:
>>
>> So coreboot and U-Boot are a good complement to each other so bringing
>> U-Boot to x86 PC mainboards via coreboot looks like a good idea - Now the
>> politics ;)
>> - The U-Boot source 'must' be self contained - No external libraries.
>> Incorporating license compatible source is OK
>
> The same is probably true for coreboot.
>
>> - coreboot payloads should be in ELF (linked to libpayload)
>
> Is this really necessary, assuming we have a self-contained payload
> that does not request any services from the tool that was used to
> start it?
Question for the coreboot guys. I think the linkage to libpayload can be
omitted, but include enough of libpayload to get to the coreboot data
structures which can tell U-Boot vital information regarding the hardware.
Also see below - If it's loading an ELF image, can't it just pass a
parameter which points to the tables?
>> - How much of libpayload would we need to bring into U-Boot to provide
>> bare minimal payload delivery? U-Boot already contains it's own minimal
>> libc routines.
>
> Right. See above - eventually such linking is not really necessary if
> the U-Boot ELF image is really self-contained.
Yes
>> - How do we get VGA and USB keyboard support working? Do other U-Boot
>> boards implement console on anything other than serial?
>
> Yes, we do support output on LCD and other video adapters, and we
> support input from USB keyboard (not to mentione netconsole, or
> netconsole over ethernet over USB and similar fancy stuff).
Nice :)
>> - Can we add relocation support to the coreboot ELF loader?
>
> Do we have to?
If we want U-Boot at top-of RAM and avoid a second memcpy then yes,
but as we know, it is not as simple as that. U-Boot relocates after it
has determined how much upper memory to reserve which isn't known until
U-Boot has enumerated it's hardware environment. Hence the reason U-Boot
will always have to suffer the penalty of the extra memcpy (the bootstrap
loader does not have enough information to reserve this memory for U-Boot)
>> - Does coreboot relocate into RAM? If so, what is the target address? What
>> guarantee is there that the target address is valid?
>
> Do we have to care? I would expect that we consider both coreboot and
> U-Boot as isolated entities, each performing it's own task. Coreboot
> will initialize the RAM and load and start U-Boot, similar to what a
> first stage loader does on systems that boot from NAND. Once U-Bootis
> running, it does so completely on its own.
>
>> - Could coreboot benefit from U-Boot's 'load to top of RAM' philosophy?
>
> Is there any need for this? Don't make things more complex than
> needed.
No, I don't think there is
>> - Is it worth playing around with segment registers to 'relocate' U-Boot
>
> That's a U-Boot question, right? Let's solve this independently.
Not really - If we want coreboot to place U-Boot at top-of-RAM then
coreboot would have to figure this out. But I think this is now a moot
point (see my other email)
>> - What hardware should be initialised in coreboot and what should be
>> initialised in U-Boot? (political question ;)
>
> No, that's a very practical; question. Coreboot should do as many of
> the x86 specific stuff as it can, and as it already does to load and
> start other payloads. And probably not more, at least not for now.
Yes - As I mentioned in my other post, coreboot should do as much as it
needs to (and not more) to load (arbitrary) payloads. The rest should
be up to U-Boot using the U-Boot principle of initialising only what
needs to be initialised.
> I think the best way to make this undertaking a success is to make it
> as unintrusive to both involved projects as possible.
Agree
>> I think a good start would be to create a new U-Boot target which includes
>> a stripped down libpayload in the U-Boot source. This target can exclude
>
> Why would we need that? I can understand that this may make initial
> porting and debugging easier ("early console output" etc.), but we
> should try to do without this.
Even more stripped than that - Just enough to get access to the coreboot
tables. Actually, if coreboot is launching an ELF payload, surely it
could pass a pointer to the tables as a argument to main()
>> We can start with U-Boot linked to a fixed location in RAM and skip
>> relocations then work on either extending coreboot to perform relocation
>> fixups or have U-Boot perform the fixups based on RAM information read from
>> cbtable
>
> I strongly recommend not to request changes to coreboot, and not to
> deviate from standard U-Boot methods.
Agree and Agree
> We are not re-inventing the wheel here. We have many similar
> situations where some ROM boot loader or xload or nand_spl code or
> onenand_ipl code is loading an U-Boot image into a halfway initialized
> system, and U-Boot starts there. I see no need to make coreboot use a
> different method.
Except the coreboot can load ELF images and if we can avoid a memcpy by
having coreboot do the relocation, we eek out that little bit more boot
speed ;)
>> P.S. Please keep both U-Boot and coreboot mailing lists Cc'd - Note: If you
>> are not on the coreboot ml, you emails will get bounced to a moderator :(
>
> I hope he is tolerant enough...
Regards,
Graeme
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
