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. > - 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
