Re: CloverEFIBoot (was Re: Call for Testing: UEFI Changes)

On 11/04/2018 11:53, Lucas Holt wrote: Machines don’t need to be old to have issues. I have a two year old asus am3+ board that cant boot from gpt without secure boot enabled and is hard coded for Microsoft keys Lucas Holt Interesting. Not sure Clover would help there though, secure boot

Re: CloverEFIBoot (was Re: Call for Testing: UEFI Changes)

Machines don’t need to be old to have issues. I have a two year old asus am3+ board that cant boot from gpt without secure boot enabled and is hard coded for Microsoft keys Lucas Holt > On Apr 11, 2018, at 12:04 PM, Ryan Stone wrote: > >> On Wed, Apr 11, 2018 at 11:14 AM,

Re: CloverEFIBoot (was Re: Call for Testing: UEFI Changes)

On 11/04/2018 11:04, Ryan Stone wrote: On Wed, Apr 11, 2018 at 11:14 AM, Pedro Giffuni wrote: Hi; FWIW, I use a very old PC of the type where the processor will not be fixed by Intel and that still needs support for the traditional BIOS. I also bought a 3TB HD (they were

Re: CloverEFIBoot (was Re: Call for Testing: UEFI Changes)

On Wed, Apr 11, 2018 at 11:14 AM, Pedro Giffuni wrote: > Hi; > > FWIW, I use a very old PC of the type where the processor will not be fixed > by Intel and that still needs support for the traditional BIOS. I also > bought a 3TB HD (they were easier to find that 2T). > > If I

CloverEFIBoot (was Re: Call for Testing: UEFI Changes)

Hi; FWIW, I use a very old PC of the type where the processor will not be fixed by Intel and that still needs support for the traditional BIOS. I also bought a 3TB HD (they were easier to find that 2T). If I leave the disk dedicated to FreeBSD it recognizes the complete 3TB and will happily

Re: Call for Testing: UEFI Changes

On Thu, Apr 5, 2018 at 7:23 PM, Zaphod Beeblebrox wrote: > As I said I would, I put the contents of /boot onto the FAT-formated EFI > partition. This is suboptimal. The default is to use "kernel.old" ... etc > ... which cannot be done on a FAT partition... at least not with

Re: Call for Testing: UEFI Changes

As I said I would, I put the contents of /boot onto the FAT-formated EFI partition. This is suboptimal. The default is to use "kernel.old" ... etc ... which cannot be done on a FAT partition... at least not with our filesystem driver ... ... but with all of /boot on the EFI partition, simply

Re: Call for Testing: UEFI Changes

On Wed, Mar 21, 2018 at 7:45 PM, Kyle Evans wrote: > Hello! > > A number of changes have gone in recently pertaining to UEFI booting > and UEFI runtime services. The changes with the most damaging > potential are: > > We now put UEFI runtime services into virtual address mode,

Re: Call for Testing: UEFI Changes

If you're thinking on it, you should know that the DVD version works. The difference, AFAICT, is that it simply calls loader.efi directly. Ie: bootx64.efi is loader.efi, not boot1.efi. Loader.efi doesn't seem to change the screen mode when it starts. When the kernel starts afterwards, this

Re: Call for Testing: UEFI Changes

On Tue, Apr 3, 2018 at 3:17 PM, Kyle Evans wrote: > Hi, > > Right- so, `gop set 0` should've immediately cleared your screen and > put it into 1920x1080, full stop. If it did not, I think that's > indicative of some kind of interestingly broken firmware... > > Regardless!

Re: Call for Testing: UEFI Changes

Hi, Right- so, `gop set 0` should've immediately cleared your screen and put it into 1920x1080, full stop. If it did not, I think that's indicative of some kind of interestingly broken firmware... Regardless! We're clearly bad at trying to set a mode before the kernel starts, so r331904 sets the

Re: Call for Testing: UEFI Changes

I did as you asked. You can see the result at: https://owncloud.towernet.ca/s/6K3pGknCyGTi7du ... but the long and short of it is that even though the loader is printing in the center of the screen (text mode?), it sees the 1920x1080 mode as the "mode 0" ... I even tried "gop set 0" ... which it

Re: Call for Testing: UEFI Changes

On Mon, Apr 2, 2018 at 5:51 PM, Zaphod Beeblebrox wrote: > On Sun, Apr 1, 2018 at 7:41 PM, David NewHamlet > wrote: >> >> Fixed in: FreeBSD-12.0-CURRENT-amd64-20180329-r331740-disc1.iso >> >> >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=176694

Re: Call for Testing: UEFI Changes

I've booted that image on my zbook 15. I show in the boot that I can deliberately load efirt.ko ... and it doesn't help. I also show that I can "type blind" after the system boots ... so everything but the screen is working. In case you can't quite make it out, I hit right cursor twice (move to

Re: Call for Testing: UEFI Changes

On Sun, Apr 1, 2018 at 7:38 AM, Tomoaki AOKI wrote: > Confirmed both loader (with boot1) part and efirt.ko part. > Working OK on my ThinkPad420 (with nvidia GPU) at r331864. > > No benefit (VGA resolution) but no new harm (no panic nor silent > reboot). > > *Maybe

Re: Call for Testing: UEFI Changes

Fixed in: FreeBSD-12.0-CURRENT-amd64-20180329-r331740-disc1.iso https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=176694 On Mon, Apr 2, 2018 at 12:38 AM, Tomoaki AOKI wrote: > Confirmed both loader (with boot1) part and efirt.ko part. > Working OK on my ThinkPad420

Re: Call for Testing: UEFI Changes

Confirmed both loader (with boot1) part and efirt.ko part. Working OK on my ThinkPad420 (with nvidia GPU) at r331864. No benefit (VGA resolution) but no new harm (no panic nor silent reboot). *Maybe gracefully falling back to mode 0. As I'm on x11/nvidia-driver, completely no test is done with

Re: Call for Testing: UEFI Changes

On 2018-03-25 14:52, Sheda wrote: >> >> I've tested on two different computers, my ThinkPad x230 and my desktop >> with a Intel DQ77MK motherboard. I've only done light testing such as >> loading efirt.ko and running efibootmgr to check the boot settings, but it >> has worked fine. >> I also

Re: Call for Testing: UEFI Changes

> > I've tested on two different computers, my ThinkPad x230 and my desktop > with a Intel DQ77MK motherboard. I've only done light testing such as > loading efirt.ko and running efibootmgr to check the boot settings, but it > has worked fine. > I also haven't seen any issues with console

Re: Call for Testing: UEFI Changes

On 03/22/18 01:45, Kyle Evans wrote: Hello! A number of changes have gone in recently pertaining to UEFI booting and UEFI runtime services. The changes with the most damaging potential are: We now put UEFI runtime services into virtual address mode, fixing runtime services with U-Boot/UEFI as

Re: Call for Testing: UEFI Changes

On Thu, Mar 22, 2018 at 11:56 AM, Renato Botelho wrote: > On 21/03/18 21:45, Kyle Evans wrote: >> Hello! >> >> A number of changes have gone in recently pertaining to UEFI booting >> and UEFI runtime services. The changes with the most damaging >> potential are: >> >> We now

Re: Call for Testing: UEFI Changes

On 21/03/18 21:45, Kyle Evans wrote: > Hello! > > A number of changes have gone in recently pertaining to UEFI booting > and UEFI runtime services. The changes with the most damaging > potential are: > > We now put UEFI runtime services into virtual address mode, fixing > runtime services with

Re: Call for Testing: UEFI Changes

On Thu, Mar 22, 2018 at 10:16 AM, Peter Lei wrote: > On 3/22/18 8:56 AM, Tomoaki AOKI wrote: >> Hi. >> For problem 2, try reverting r331241 alone. >> This worked for my ThinkPad T420. > > > I also hit this after updating to latest and was about to post when I > saw this thread

Re: Call for Testing: UEFI Changes

On Thu, Mar 22, 2018 at 10:18 AM, Kyle Evans wrote: > On Thu, Mar 22, 2018 at 10:16 AM, Peter Lei wrote: >> On 3/22/18 8:56 AM, Tomoaki AOKI wrote: >>> Hi. >>> For problem 2, try reverting r331241 alone. >>> This worked for my ThinkPad T420. >> >> >> I

Re: Call for Testing: UEFI Changes

On 3/22/18 8:56 AM, Tomoaki AOKI wrote: > Hi. > For problem 2, try reverting r331241 alone. > This worked for my ThinkPad T420. I also hit this after updating to latest and was about to post when I saw this thread - I build efirt into the kernel and it's now doing a panic on boot. It appears to

Re: Call for Testing: UEFI Changes

Hi. For problem 2, try reverting r331241 alone. This worked for my ThinkPad T420. On Thu, 22 Mar 2018 08:22:13 -0500 Kyle Evans wrote: > On Thu, Mar 22, 2018 at 5:13 AM, Jakob Alvermark wrote: > > Hi! > > > > > > Just updated to r331345. > > > > Two

Re: Call for Testing: UEFI Changes

On Thu, Mar 22, 2018 at 5:13 AM, Jakob Alvermark wrote: > Hi! > > > Just updated to r331345. > > Two problems: > > 1. boot/efi.4th is added to /usr/src/ObsoleteFiles.inc but still included in > loader.rc. Loader fails to load it and subsequently fails to load modules. >

Re: Call for Testing: UEFI Changes

52 >> Címzett: FreeBSD Current >> Tárgy: Re: Call for Testing: UEFI Changes >> >> >> >>> On 22 Mar 2018, at 12:13, Jakob Alvermark <ja...@alvermark.net> wrote: >>> >>> Hi! >>> >>> >>> Just updated to r331345. &

RE: Call for Testing: UEFI Changes

-freebsd-curr...@freebsd.org [mailto:owner-freebsd-curr...@freebsd.org] Meghatalmazó Toomas Soome Küldve: 2018. március 22. 11:52 Címzett: FreeBSD Current Tárgy: Re: Call for Testing: UEFI Changes > On 22 Mar 2018, at 12:13, Jakob Alvermark <ja...@alvermark.net> wrote: > > Hi! >

Re: Call for Testing: UEFI Changes

> On 22 Mar 2018, at 12:13, Jakob Alvermark wrote: > > Hi! > > > Just updated to r331345. > > Two problems: > > 1. boot/efi.4th is added to /usr/src/ObsoleteFiles.inc but still included in > loader.rc. Loader fails to load it and subsequently fails to load modules. >

Re: Call for Testing: UEFI Changes

Hi! Just updated to r331345. Two problems: 1. boot/efi.4th is added to /usr/src/ObsoleteFiles.inc but still included in loader.rc. Loader fails to load it and subsequently fails to load modules. Reinstalling efi.4th problem 2 appears. 2. Fixing problem 1 and adding efirt_load="YES" to

Call for Testing: UEFI Changes

Hello! A number of changes have gone in recently pertaining to UEFI booting and UEFI runtime services. The changes with the most damaging potential are: We now put UEFI runtime services into virtual address mode, fixing runtime services with U-Boot/UEFI as well as the firmware implementation in