On Mon, 16 Oct 2017 20:08:19 +0300 Toomas Soome <tso...@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 <and...@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 <i...@bsdimp.com > >> <mailto:i...@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 <and...@fubar.geek.nz > >> <mailto:and...@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 <i...@bsdimp.com > >>> <mailto:i...@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" <and...@fubar.geek.nz > >>> <mailto:and...@fubar.geek.nz>> wrote: > >>> > >>> > On 16 Oct 2017, at 04:59, Warner Losh <i...@freebsd.org > >>> > <mailto:i...@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 <m...@bidouilliste.com> <m...@freebsd.org> _______________________________________________ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
