On 29 August 2014 09:53, Ard Biesheuvel <[email protected]> wrote: > On 29 August 2014 04:20, Laszlo Ersek <[email protected]> wrote: >> Apologies, I have some updates here: >> >> On 08/29/14 01:17, Laszlo Ersek wrote: >>> On 08/28/14 17:40, Ard Biesheuvel wrote: >>> >> >>>> + APRIORI DXE { >>>> + INF MdeModulePkg/Universal/PCD/Dxe/Pcd.inf >>>> + } >>>> + INF MdeModulePkg/Core/Dxe/DxeMain.inf >>>> + INF MdeModulePkg/Universal/PCD/Dxe/Pcd.inf >>>> + INF ArmPlatformPkg/ArmVirtualizationPkg/VirtFdtDxe/VirtFdtDxe.inf >>>> + >>>> + # >>>> + # PI DXE Drivers producing Architectural Protocols (EFI Services) >>>> + # >>>> + INF ArmPkg/Drivers/CpuDxe/CpuDxe.inf >>>> + INF MdeModulePkg/Core/RuntimeDxe/RuntimeDxe.inf >>>> + INF MdeModulePkg/Universal/SecurityStubDxe/SecurityStubDxe.inf >>>> + INF MdeModulePkg/Universal/CapsuleRuntimeDxe/CapsuleRuntimeDxe.inf >>>> + INF >>>> MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteDxe.inf >>>> + INF MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf >>> >>> from the prev. norflash patch, ok... >>> >>>> + INF >>>> MdeModulePkg/Universal/MonotonicCounterRuntimeDxe/MonotonicCounterRuntimeDxe.inf >>>> + INF EmbeddedPkg/ResetRuntimeDxe/ResetRuntimeDxe.inf >>>> + INF EmbeddedPkg/RealTimeClockRuntimeDxe/RealTimeClockRuntimeDxe.inf >>>> + INF EmbeddedPkg/MetronomeDxe/MetronomeDxe.inf >>>> + INF MdeModulePkg/Universal/HiiDatabaseDxe/HiiDatabaseDxe.inf >>>> + >>>> + # >>>> + # Multiple Console IO support >>>> + # >>>> + INF MdeModulePkg/Universal/Console/ConPlatformDxe/ConPlatformDxe.inf >>>> + INF MdeModulePkg/Universal/Console/ConSplitterDxe/ConSplitterDxe.inf >>>> + INF >>>> MdeModulePkg/Universal/Console/GraphicsConsoleDxe/GraphicsConsoleDxe.inf >>>> + INF MdeModulePkg/Universal/Console/TerminalDxe/TerminalDxe.inf >>>> + INF EmbeddedPkg/SerialDxe/SerialDxe.inf >>>> + >>>> + INF ArmPkg/Drivers/ArmGic/ArmGicDxe.inf >>>> + INF ArmPkg/Drivers/TimerDxe/TimerDxe.inf >>>> + INF ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashDxe.inf >>> >>> ditto, OK >>> >>>> + INF MdeModulePkg/Universal/WatchdogTimerDxe/WatchdogTimer.inf >>>> + >>>> + # >>>> + # FAT filesystem + GPT/MBR partitioning >>>> + # >>>> + INF MdeModulePkg/Universal/Disk/DiskIoDxe/DiskIoDxe.inf >>>> + INF MdeModulePkg/Universal/Disk/PartitionDxe/PartitionDxe.inf >>>> + INF FatBinPkg/EnhancedFatDxe/Fat.inf >>>> + INF >>>> MdeModulePkg/Universal/Disk/UnicodeCollation/EnglishDxe/EnglishDxe.inf >>>> + >>>> + # >>>> + # Platform Driver >>>> + # >>>> + INF OvmfPkg/VirtioBlkDxe/VirtioBlk.inf >>>> + INF OvmfPkg/VirtioNetDxe/VirtioNet.inf >>>> + INF OvmfPkg/VirtioScsiDxe/VirtioScsi.inf >>>> + >>>> + # >>>> + # UEFI application (Shell Embedded Boot Loader) >>>> + # >>>> + INF ShellBinPkg/UefiShell/UefiShell.inf >>>> + >>>> + # >>>> + # Bds >>>> + # >>>> + INF MdeModulePkg/Universal/DevicePathDxe/DevicePathDxe.inf >>>> + INF ArmPlatformPkg/Bds/Bds.inf >> >> I. >> >> So, VirtFdtDxe sets the following PCDs, keying off the DTB: >> >> - PcdGicDistributorBase >> - PcdGicInterruptInterfaceBase >> - PcdPL031RtcBase >> - PcdArmArchTimerSecIntrNum >> - PcdArmArchTimerIntrNum >> - PcdArmArchTimerVirtIntrNum >> - PcdArmArchTimerHypIntrNum >> >> It is imperative that DXE drivers that depend on these PCDs run *after* >> VirtFdtDxe. >> >> Ordering between DXE drivers can be ensured in several ways: >> - the APRIORI DXE file >> - Depex (some drivers produce protocols, and others depend on them) >> - protocol installation callbacks (gBS->RegisterProtocolNotify()) >> - theoretically, PcdSetXX() callbacks (I've never seen any use of this) >> >> Of these, I recommend the APRIORI DXE file, because >> - there are no suitable protocols here, >> - we're delaying cross-ARM-platform drivers, ie. nothing that's >> specific to virt >> >> Please squash the first attached patch. >> >> I tested it. It makes no difference *in practice*, right now. The first >> DXE driver that is loaded is PcdDxe.efi, the 2nd one is VirtFdtDxe.efi, >> anyway. >> >> But that only happens because you placed the VirtFdtDxe line in the FDF >> file quite "high". The ordering of the module lines in the FDF file, in >> an [FV] section, has unspecified effect; you just got lucky that it >> ended up creating a load order that you wanted. >> >> Again, this is not guaranteed, plus module lines can be reshuffled any >> time in the [FV] section of the FDF. If you want to prescribe a dispatch >> order, you must use the APRIORI file. Whatever drivers you reference >> there will be dispatched first from the firmware volume, in the order >> you listed them in the APRIORI file, and then the rest will be >> dispatched, in unspecified order (subject to Depexes of course). >> >> Please refer to "2.4.4 APRIORI Scoping" in the FDF spec. >> >> So, please squash this patch -- it has no effect right now (luckily), >> but it's needed for safety down the road. You can keep my Reviewed-by of >> course. >> > > OK. > > I did have it in the APRIORI section at some point, and noticed it > didn't make a difference. It did for dynamic PCDs (none of the ARM > platform use them), so I thought I couid drop it. But I will put it > back > >> II. >> >> I compared the list of modules you build in the DSC file(s) against the >> modules you include in the flash image with the FDF file. There are two >> discrepancies: >> >> - EmbeddedPkg/SimpleTextInOutSerial/SimpleTextInOutSerial.inf is built >> uselessly (simply drop it from the DSC) >> - the networking modules that are built through the dsc.inc are not >> included by the FDF. They should be. >> >> IOW, please squash the 2nd patch too. >> > > OK > >> III. >> >> Notes about testing: >> >> - this series doesn't apply on current edk2 master; please rebase it for >> v6. For testing, I applied it on git commit 421ccda3. >> > > Yes, that is the branch point I used after rebasing the v1. > Unfortunately, I am now seeing this > > build.py... > /home/ard/build/uefi-next/ArmPlatformPkg/ArmVirtualizationPkg/ArmVirtualizationQemu.dsc(...): > error 1001: Module type [SEC] is not supported by library instance > [/home/ard/build/uefi-next/MdePkg/Library/UefiBootServicesTableLib/UefiBootServicesTableLib.inf] > consumed by > [/home/ard/build/uefi-next/ArmPlatformPkg/PrePeiCore/PrePeiCoreUniCore.inf] > > which i am trying to bisect now. >
OK, it turns out Olivier has submitted an incompatible change here: af16798ef77da84487ed8e64bc955fbd12ac9b1f [EmbeddedPkg/FdtLib: Added support to load Fdt from Semihosting] which adds functionality to FdtLib which makes it depend on the boot services table. I am going to go ahead and split that into two libraries, hopefully Olivier will be ok with that once he gets around to looking into this stuff >> - the first QEMU patch that you link in >> <https://wiki.linaro.org/LEG/UEFIforQEMU> doesn't apply on current QEMU >> master (git-am can't cope with the context changes); I'm attaching a >> forward-ported version. Maybe you can add it to the wiki page. >> >> IV. >> >> More notes about testing -- try this (if you haven't yet): >> >> (a) as root, on your host: >> >> G=$(id -g $YOUR_NORMAL_USER) >> sysctl -w net.ipv4.ping_group_range="$G $G" >> >> (b) as your normal user: >> >> qemu-system-aarch64 \ >> -m 1024 \ >> -cpu cortex-a57 \ >> -M virt \ >> -bios Build/ArmVirtualizationQemu/DEBUG_GCC48/FV/QEMU_EFI.fd \ >> -serial stdio \ >> -netdev user,id=netdev0,hostname=aarch64-guest \ >> -device virtio-net-device,netdev=netdev0 >> >> (c) drop to the UEFI shell >> >> (d) Shell> ifconfig -s eth0 dhcp >> >> (e) Shell> ping FAVORITE_PUBLIC_IPv4_ADDRESS >> > > Shell> ifconfig -s eth0 dhcp > Create an IP and start to get the default address > Please wait, your console may stop responding for a while ... > Default: 10.0.2.15 > Shell> ping 8.8.8.8 > Ping 8.8.8.8 16 data bytes > 16 bytes from 8.8.8.8 : icmp_seq=1 ttl=0 time<0ms > 16 bytes from 8.8.8.8 : icmp_seq=2 ttl=0 time<0ms > 16 bytes from 8.8.8.8 : icmp_seq=3 ttl=0 time<0ms > 16 bytes from 8.8.8.8 : icmp_seq=4 ttl=0 time<0ms > 16 bytes from 8.8.8.8 : icmp_seq=5 ttl=0 time<0ms > > >> This is what I've been wanting to see for months! :) >> >> - side note: backspace works perfectly for me in my xterm (my erase >> character has been ^H for ~15 yrs) >> > > I got used to it, and don't use the shell that much, so it doesn't bother me > > -- > Ard. ------------------------------------------------------------------------------ Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/ _______________________________________________ edk2-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/edk2-devel
