[coreboot] [GSoC-2015] ARM SoC Mainboard Support (was: AMD native graphics init (was: Interested in Participating - Discussing Ideas))

[Varad Gautam]

On 03/06/15 at 11:33 PM Paul Menzel <paulepanter at users.sourceforge.net> wrote:
> Dear Felix, dear Varad,
> 
> 
> Varad, welcome to coreboot!
> 
> Am Freitag, den 06.03.2015, 21:50 +0100 schrieb Felix Held:
> > > I dumped the BIOS binary for a Radeon GPU and am trying to make sense of
> > > it
> > > using the atombios kernel header [1] - are there any resources on
> > > ATOMBIOS
> > > internals I can use? I believe the GPU initialization can be done by
> > > tracing the dump contents as suggested in this thread [2], but cannot
> > > figure how new ATOMBIOS tables would be created and used. I also need
> > > to check the coreboot source to plan how this can be implemented.
> > 
> > If you plan to work on native gfx init for AMD, talk to mrnuke; he
> > already did quite some work on that.
> 
> Alexandru has already pushed change sets for review [1][2][3].
> Additionally he wrote some posts touching this topic, which you can read
> in the coreboot blog [4].
> 
> Additionally there are several threads on this mailing list, where this
> topic was discussed.
> 
> I wish you the best of luck with your application!
> 

Thanks - in that case I would like to work on adding coreboot support to an 
ARM platform, later adding Tianocore as a payload. Here is my view of the 
idea, please suggest if I am on the right track:

The board specific lowlevel code would be placed at src/mainboard/<mainboard> 
and the SoC (gpio, uart, clock, pinmux) initialization at src/soc/<soc>. The 
implementation details can be taken from the SoC reference manuals, U-Boot 
source and the mainboard specs.

UEFI would be the second stage loader - the SoC support can be added by 
extending the existing ArmPkg framework, and the boot flow would look like 
Reset -> Coreboot lowlevel init -> UEFI Pre-PI* -> UEFI DXE.

Can the UEFI HOBs be constructed by coreboot so that Pre-PI can be removed? I 
also need some help figuring where libpayload fits in - Tianocore has its own 
implementation of C library routines (edk2/StdLib), and once UEFI takes 
control, these can directly be used by the FD.

I am tracing the existing ARM code. Which mainboard would be the preferred 
target? Also, please suggest any 'easy' patches I could send in to get 
comfortable with the development process.

Thanks,
Varad

> 
> Thanks,
> 
> Paul
> 
> 
> [1] http://review.coreboot.org/8281
> [2] http://review.coreboot.org/8281
> [3] http://review.coreboot.org/8281
> [4] http://blogs.coreboot.org/blog/author/mrnuke/