[Macchiato] Current UEFI firmware stack?

[Jeremy Linton]

On 4/1/19 9:47 PM, Marcin Wojtas wrote:
> Hi Jeremy,
> 
> pon., 1 kwi 2019 o 23:32 Jeremy Linton <jeremy.linton at arm.com> napisał(a):
>>
>> On 3/31/19 4:33 AM, Marcin Wojtas wrote:
>>> Hi Jeremy,
>>>
>>> I think you can safely use the mainline branches:
>>> https://github.com/ARM-software/arm-trusted-firmware/commits/master
>>> https://github.com/tianocore/edk2/commits/master
>>> https://github.com/tianocore/edk2-platforms/commits/master
>>> https://github.com/MarvellEmbeddedProcessors/mv-ddr-marvell/tree/mv_ddr-armada-atf-mainline
>>> https://github.com/MarvellEmbeddedProcessors/binaries-marvell/tree/binaries-marvell-armada-18.12
>>>
>>> I built the latter from the top of today's branches, and my
>>> MacchiatoBin works properly with all peripherals. Here's the log:
>>> https://pastebin.com/b2a0r7Kw
>>>
>>> Please try above and share your log, so that we can figure out, what is wrong.
>>
>> Well, as crazy as this sounds, I started some basic debugging of this error:
>>
>> add-symbol-file
>> /home/jlinton/marvell/Build/Armada80x0McBin-AARCH64/DEBUG_GCC5/AARCH64/Silicon/Marvell/Drivers/BoardDesc/MvBoardDescDxe/DEBUG/BoardDescDxe.dll
>> 0xBF800000
>> Loading driver at 0x000BF7FF000 EntryPoint=0x000BF8024CC BoardDescDxe.efi
>> Error: Image at 000BF7FF000 start failed: Invalid Parameter
>>
>> by changing he PcdDebugPrintErrorLevel to 0x80000008F and sprinkling
>> some prints around MvBoardDescEntryPoint() and now it boots to grub
>> using a sata disk.
>>
>> The MvBoardDescDxe starts ok, and I don't see any apparent difference in
>> the output when all the dispatch log messages are removed. Also, as a
>> FYI, that pastebin I previously posted had an older SCP binary in it,
>> but that itself didn't make any difference either.
> 
> Let's stop here, I also noticed MvBoardDescDxe failing - as a result
> in SerDes and USB2.0 PHYs could not be properly initialized, hence the
> hangs. The problem is - I rebuilt with DEBUG flag and I still boot
> successfully (https://pastebin.com/vKmtfkwb)
> 
> MvBoardDescEntryPoint () is very simple one (allocate / assign
> callbacks / install protocol), so it all looks really strange. Could
> it be a gcc version then? Which one are you using? I use
> gcc-linaro-7.3.1-2018.05-x86_64_aarch64-linux-gnu.

I'm using linaro 6.2.1, which is fairly old, but I've generally had good 
luck claiming its GCC5 for edk2, and last time I tried using a newer GCC 
it caused further problems (that was more than a year ago and a 
different platform).


> 
>>
>> So, now i'm debugging booting 5.0/fedora again. There has been some kind
>> of "race" in the sata/sd/xenon probe logic for a while. Periodically it
>> hangs doing a sata reset during the normal boot flow (others have
>> reported this as well and I've seen it on/off). If the machine is
>> rd.break=pre-udev and those three drivers are modprobed by hand, it's
>> been booting pretty consistently. Before spending to much time on it I
>> decided to get the most bleeding edge firmware I could find. Now this
>> version seems to be hanging probing PCIe. I saw there was a dtb patch
>> recently for pcie reset.
> 
> I checked and indeed seems a PCIE reset problem. After longer time
> being too busy with other stuff I'm working on the upstream of PCIE in
> edk2. I succeeded to boot mainline when I the reset is done during
> UEFI, so I'll keep you posted, when submitting patches. Please check
> ACPI below.
> 
>> Although, I also flipped it to ACPI, which i'm
>> more motivated to debug, but that is hanging really early and 'earlycon'
>> by itself doesn't appear to be working.
>>
> 
> ACPI works with 5.1-rc2 (and earlier). In boot manager pick ACPI in
> 'Device Manager' -> 'O/S Hardware Description Selection'.
> 
> 1. It is enough to add 'console=ttyS0,115200' when booting - log
> https://pastebin.com/me7uzSu9
> 
> 2. If you want earlycon, please use
> earlycon=uart8250,mmio32,0xf0512000. Anyway, here's ACPI bootlog with
> mounting nfs via eth2: https://pastebin.com/jXskc5t3

Yes, I figured out the earlycon/etc parameters, that was the problem. It 
is ACPI booting. I've got a DBG2 table I hacked together that I need to 
verify fixes the need for the console parms.

Just as a FYI, it would be really helpful if a basic/tested UEFI binary 
were provided in the software download section. I've gotten a number of 
questions from assorted people on how to get a functional UEFI+distro 
working. Pointing people at the build instructions hasn't always gone 
over well.