Re: [PATCH v1 edk2-platfoms 0/2] Platform/Broadcom: Add Raspberry Pi 3 support

[Ard Biesheuvel <ard.biesheuvel@linaro.org>]

On Fri, 7 Dec 2018 at 15:33, Pete Batard <pete@akeo.ie> wrote:
>
> Hi Ard,
>
> On 2018.12.07 14:08, Ard Biesheuvel wrote:
> > On Fri, 7 Dec 2018 at 13:13, Pete Batard <pete@akeo.ie> wrote:
> >>
> >> Preamble:
> >>
> >> Because of its price point, ease of use and availability, the Raspberry Pi is
> >> undeniably one of the most successful ARM platform in existence today. Its
> >> widespread adoption therefore makes it a perfect fit as an EDK2 platform.
> >>
> >> However, up until now, the Raspberry Pi hasn't been supported as a bona fide
> >> platform in our repository. This series of patches remedies that by introducing
> >> the Raspberry Pi 3 Model B and Model B+ as a viable EDK2 platforms.
> >>
> >
> > Thanks Pete, this is excellent work
>
> Well, most of it is based on your initial work for that platform... ;)
>

That was just the easy part :-)

> >> Patch Breakdown:
> >>
> >> Since this is a platform introduction, we simply chose to break the commits
> >> into edk2-platforms and edk2-non-osi components, as we see little point in
> >> splitting the series into further subcomponents, when the structure would be
> >> similar to the overall subdirectory layout and of course, one needs to apply
> >> all components at once to be able to test the firmware.
> >>
> >
> > You will have to split it up, or i won't be able to review it.
>
> Do you have a preference with regards to breaking it down?
>
> Would a 4-way ACPI / Drivers / Library / Non-OSI work for you, or do you
> want to go more fine grained?
>

Each module as a separate patch, preferably, and a patch that adds the
.dsc/.fdf at the end.

> I'm not sure what will make the reviewing process easier, so if you have
> guidance as to how you'd prefer to see things split, I'll take it.
>

Well, I want to be able to reply inline in my email client, and a
22000 line patch does not let me do that ...

> > BTW I managed to build the code with GCC 6 just fine - are you sure
> > the GCC 5.5 limitation still exists?
>
> Well, the problem we've seen isn't with building the firmware itself,
> but with getting sporadic (but not systematic) Synchronous Exceptions
> during early boot, when using GCC 6 or later.
>
> After switching to GCC 5.5, I have not seen any of these exceptions
> occur, so, even if we have applied other changes that may have helped
> since, I prefer erring on the side of caution for the time being...
>

Yikes. So no meaningful backtraces were produced that narrow it down?