svn commit: r324646 - in head/sys/boot/efi: boot1 libefi loader

[Emmanuel Vadot]

On Mon, 16 Oct 2017 20:08:19 +0300
Toomas Soome <tsoome at me.com> wrote:

> 
> The arm (uboot) has a bit different approach on block device(s), see efipart_hdinfo_add_filepath() in efipart.c; the code needs to check for MEDIA_FILEPATH_DP, I think.
> 
> rgds,
> toomas

 I'm pretty sure that qemu doesn't use u-boot but EDK2 directly.

> 
> > On 16 Oct 2017, at 19:07, Andrew Turner <andrew at fubar.geek.nz> wrote:
> > 
> > Correct, it is aarch64. It runs a similar qemu command, however I also see it under the ARM Foundation model so it seems to not be simulator specific.
> > 
> > Andrew
> > 
> >> On 16 Oct 2017, at 16:56, Warner Losh <imp at bsdimp.com <mailto:imp at bsdimp.com>> wrote:
> >> 
> >> So this is on aarch64? Is this running a standardish qemu setup as documented on https://wiki.freebsd.org/arm64/QEMU <https://wiki.freebsd.org/arm64/QEMU> ? Or are there tricks that we need to cope with...
> >> 
> >> If we can't get good resoltuion on this today, I plan on backing out the entire change.
> >> 
> >> Warner
> >> 
> >> On Mon, Oct 16, 2017 at 9:38 AM, Andrew Turner <andrew at fubar.geek.nz <mailto:andrew at fubar.geek.nz>> wrote:
> >> I have a local Jenkins setup that builds images & tries to run under various simulators. The final image is built with mkimg. I?m running it under qemu.
> >> 
> >> Andrew
> >> 
> >>> On 16 Oct 2017, at 13:19, Warner Losh <imp at bsdimp.com <mailto:imp at bsdimp.com>> wrote:
> >>> 
> >>> I'll take a look, but I've also ccd Eric so he can figure out what went wrong with is code in your environment. What env is That?
> >>> 
> >>> Warnee
> >>> 
> >>> On Oct 16, 2017 3:26 AM, "Andrew Turner" <andrew at fubar.geek.nz <mailto:andrew at fubar.geek.nz>> wrote:
> >>> 
> >>> > On 16 Oct 2017, at 04:59, Warner Losh <imp at FreeBSD.org <mailto:imp at FreeBSD.org>> wrote:
> >>> >
> >>> > Author: imp
> >>> > Date: Mon Oct 16 03:59:11 2017
> >>> > New Revision: 324646
> >>> > URL: https://svnweb.freebsd.org/changeset/base/324646 <https://svnweb.freebsd.org/changeset/base/324646>
> >>> >
> >>> > Log:
> >>> >  Unify boot1 with loader
> >>> >
> >>> >  Refactor boot1 to use the same I/O code as /boot/loader uses. Refactor
> >>> >  to use the common efi_main.c.
> >>> >
> >>> >  Submitted by: Eric McCorkle
> >>> >  Differential Revision: https://reviews.freebsd.org/D10447 <https://reviews.freebsd.org/D10447>
> >>> >
> >>> > Added:
> >>> >  head/sys/boot/efi/libefi/efi_main.c   (contents, props changed)
> >>> >     - copied, changed from r324645, head/sys/boot/efi/loader/efi_main.c
> >>> > Deleted:
> >>> >  head/sys/boot/efi/boot1/boot_module.h
> >>> >  head/sys/boot/efi/boot1/ufs_module.c
> >>> >  head/sys/boot/efi/boot1/zfs_module.c
> >>> >  head/sys/boot/efi/loader/efi_main.c
> >>> > Modified:
> >>> >  head/sys/boot/efi/boot1/Makefile
> >>> >  head/sys/boot/efi/boot1/boot1.c
> >>> >  head/sys/boot/efi/libefi/Makefile
> >>> >  head/sys/boot/efi/loader/Makefile
> >>> 
> >>> Hello Warner,
> >>> 
> >>> After this change I?m getting the following panic on various test VMs.
> >>> 
> >>> Andrew
> >>> 
> >>> >> FreeBSD EFI boot block
> >>> 
> >>>    Loader path: /boot/loader.efi
> >>> 
> >>>    Load Path: \EFI\BOOT\BOOTAA64.EFI
> >>>    Load Device: VenHw(837DCA9E-E874-4D82-B29A-23FE0E23D1E2,003C000A00000000)/HD(1,GPT,DD40E9C6-B247-11E7-AA0A-15EFE1BBB7CF,0x3,0x640)
> >>> panic: Couldn't trim device path
> >>> --> Press a key on the console to reboot <--
> >>> 
> >> 
> >> 
> > 
> 


-- 
Emmanuel Vadot <manu at bidouilliste.com> <manu at freebsd.org>