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

[Pedro Giffuni]

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 is a  
different issue:


https://wiki.freebsd.org/SecureBoot

Cheers,

Pedro.


On Apr 11, 2018, at 12:04 PM, 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 easier to find that 2T).

If I leave the disk dedicated to FreeBSD it recognizes the complete 3TB and
will happily use ZFS for everything, however I want to dual boot so after
lots of testing I ended up ignoring 1 TB of HD :(.

It does happen that there is a really nice boot loader that could have saved
the day but it is very difficult to install standalone:

https://sourceforge.net/projects/cloverefiboot

Just in case someone has the time and inclination to play with it :)

Pedro.

Is the issue due to using MBR partitioning?  FreeBSD supports booting
from a GPT partition from a traditional BIOS; you don't need EFI.  Is
this machine so old that its BIOS doesn't support booting from GPT?
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

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

[Lucas Holt]

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, 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 leave the disk dedicated to FreeBSD it recognizes the complete 3TB and
>> will happily use ZFS for everything, however I want to dual boot so after
>> lots of testing I ended up ignoring 1 TB of HD :(.
>> 
>> It does happen that there is a really nice boot loader that could have saved
>> the day but it is very difficult to install standalone:
>> 
>> https://sourceforge.net/projects/cloverefiboot
>> 
>> Just in case someone has the time and inclination to play with it :)
>> 
>> Pedro.
> 
> Is the issue due to using MBR partitioning?  FreeBSD supports booting
> from a GPT partition from a traditional BIOS; you don't need EFI.  Is
> this machine so old that its BIOS doesn't support booting from GPT?
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

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

[Pedro Giffuni]

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 easier to find that 2T).

If I leave the disk dedicated to FreeBSD it recognizes the complete 3TB and
will happily use ZFS for everything, however I want to dual boot so after
lots of testing I ended up ignoring 1 TB of HD :(.

It does happen that there is a really nice boot loader that could have saved
the day but it is very difficult to install standalone:

https://sourceforge.net/projects/cloverefiboot

Just in case someone has the time and inclination to play with it :)

Pedro.

Is the issue due to using MBR partitioning?  FreeBSD supports booting
from a GPT partition from a traditional BIOS; you don't need EFI.  Is
this machine so old that its BIOS doesn't support booting from GPT?


It's a Dell Optiplex 760 (refurbished). I don't remember the details but 
FreeBSD supports booting just fine if I dedicate all the HD to 
FreeBSD/GPT, but the Windows bootloader wont so I needed a bootloader 
with it's own EFI implementation that would. Clover comes from the 
Apple/Darwin world and does this but I never managed to install it in a 
HD; ideally you have to figure out how to install it before installing 
the OS so I had to install it later in a thumbdrive.


FWIW, the only documentation I could find on the gory details for dual 
booting (with linux) is here:


https://www.rodsbooks.com/gdisk/bios.html

Cheers,

Pedro.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

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

[Ryan Stone]

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 leave the disk dedicated to FreeBSD it recognizes the complete 3TB and
> will happily use ZFS for everything, however I want to dual boot so after
> lots of testing I ended up ignoring 1 TB of HD :(.
>
> It does happen that there is a really nice boot loader that could have saved
> the day but it is very difficult to install standalone:
>
> https://sourceforge.net/projects/cloverefiboot
>
> Just in case someone has the time and inclination to play with it :)
>
> Pedro.

Is the issue due to using MBR partitioning?  FreeBSD supports booting
from a GPT partition from a traditional BIOS; you don't need EFI.  Is
this machine so old that its BIOS doesn't support booting from GPT?
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

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

[Pedro Giffuni]

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 use ZFS for everything, however I want to dual boot so 
after lots of testing I ended up ignoring 1 TB of HD :(.


It does happen that there is a really nice boot loader that could have 
saved the day but it is very difficult to install standalone:


https://sourceforge.net/projects/cloverefiboot

Just in case someone has the time and inclination to play with it :)

Pedro.


___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Call for Testing: UEFI Changes

[Kyle Evans]

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 our
> filesystem driver ...
>
> ... but with all of /boot on the EFI partition, simply starting loader.efi
> works.
>

Hi,

Can you try a standard setup with the patch at [1] applied to your
boot1.efi? Standard setup being /boot/loader.efi in place and
boot1.efi copied over to your ESP.

I *think* this might help your situation, but I've no real idea. If I
know what I'm doing (which I don't), then this patch should (maybe?)
force your screen down into a lower resolution prior to drawing the
menu then reset it once more before it prints resolution information
and executes the kernel.

Maybe it'll fix it?

Thanks,

Kyle Evans

[1] https://people.freebsd.org/~kevans/loader.diff
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Call for Testing: UEFI Changes

[Zaphod Beeblebrox]

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 starting loader.efi
works.

On Wed, Apr 4, 2018 at 11:57 AM, Kyle Evans  wrote:

> 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, fixing
> > runtime services with U-Boot/UEFI as well as the firmware
> > implementation in many Lenovos. The previously observed behavior was a
> > kernel panic upon invocation of efibootmgr/efivar, or a kernel panic
> > just loading efirt.ko or compiling EFIRT into the kernel.
> >
> > Graphics mode selection is now done differently to avoid regression
> > caused by r327058 while still achieving the same effect. The observed
> > regression was that the kernel would usually end up drawing
> > incorrectly at the old resolution on a subset of the screen, due to
> > incorrect framebuffer information.
> >
> > Explicit testing of these changes, the latest of which happened in
> > r331326, and any feedback from this testing would be greatly
> > appreciated. Testing should be done with either `options EFIRT` in
> > your kernel config or efirt.ko loaded along with updated bootloader
> > bits.
> >
> > I otherwise plan to MFC commits involved with the above-mentioned
> > changes by sometime in the first week of April, likely no earlier than
> > two (2) weeks from now on April 4th.
> >
> > Thanks,
> >
> > Kyle Evans
>
> As partially promised, the non-graphics related changes have been
> MFC'd to stable/11 today as r332028.
>
> The graphics related changes are going to simmer longer and probably
> get ripped out, because we're bad at this.
>
> Thanks,
>
> Kyle Evans
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Call for Testing: UEFI Changes

[Kyle Evans]

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, fixing
> runtime services with U-Boot/UEFI as well as the firmware
> implementation in many Lenovos. The previously observed behavior was a
> kernel panic upon invocation of efibootmgr/efivar, or a kernel panic
> just loading efirt.ko or compiling EFIRT into the kernel.
>
> Graphics mode selection is now done differently to avoid regression
> caused by r327058 while still achieving the same effect. The observed
> regression was that the kernel would usually end up drawing
> incorrectly at the old resolution on a subset of the screen, due to
> incorrect framebuffer information.
>
> Explicit testing of these changes, the latest of which happened in
> r331326, and any feedback from this testing would be greatly
> appreciated. Testing should be done with either `options EFIRT` in
> your kernel config or efirt.ko loaded along with updated bootloader
> bits.
>
> I otherwise plan to MFC commits involved with the above-mentioned
> changes by sometime in the first week of April, likely no earlier than
> two (2) weeks from now on April 4th.
>
> Thanks,
>
> Kyle Evans

As partially promised, the non-graphics related changes have been
MFC'd to stable/11 today as r332028.

The graphics related changes are going to simmer longer and probably
get ripped out, because we're bad at this.

Thanks,

Kyle Evans
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Call for Testing: UEFI Changes

[Zaphod Beeblebrox]

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 all just works.

I assume loader.efi works here because CD9660 is a format supported by
EFI.  Thus loader.efi can directly read it.  That and/or loader can work
with the device is was started from.

When I start boot1.efi on this system, it changes mode, then it continues.

... so if you've got a boot1.efi that doesn't change mode, can you post
that binary for me to try ... ?

On Tue, Apr 3, 2018 at 4:48 PM, Kyle Evans  wrote:

> 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! We're clearly bad at trying to set a mode before the
> > kernel starts, so r331904 sets the default max resolution in such a
> > way that we just don't change the resolution by default anymore and
> > interested parties can bump that up if they want to try it. This
> > Thursday's snapshots should have this included.
>
> After reviewing the video again and discussing it with manu, I don't
> think that commit's going to solve your problem at all... we'll need
> to re-think this one a bit more.
>
> > I think if we're going to change modes as a default, we should have
> > some way for vt/efifb to use EFIRT or be notified by EFIRT of
> > supported resolutions so that vt/efifb can hopefully just handle it
> > all and do it properly. This approach would be more similar I guess to
> > how KMS drivers operate, and less fragile than what we're seeing with
> > these different approaches we've taken.
> >
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Call for Testing: UEFI Changes

[Kyle Evans]

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! We're clearly bad at trying to set a mode before the
> kernel starts, so r331904 sets the default max resolution in such a
> way that we just don't change the resolution by default anymore and
> interested parties can bump that up if they want to try it. This
> Thursday's snapshots should have this included.

After reviewing the video again and discussing it with manu, I don't
think that commit's going to solve your problem at all... we'll need
to re-think this one a bit more.

> I think if we're going to change modes as a default, we should have
> some way for vt/efifb to use EFIRT or be notified by EFIRT of
> supported resolutions so that vt/efifb can hopefully just handle it
> all and do it properly. This approach would be more similar I guess to
> how KMS drivers operate, and less fragile than what we're seeing with
> these different approaches we've taken.
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Call for Testing: UEFI Changes

[Kyle Evans]

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 default max resolution in such a
way that we just don't change the resolution by default anymore and
interested parties can bump that up if they want to try it. This
Thursday's snapshots should have this included.

I think if we're going to change modes as a default, we should have
some way for vt/efifb to use EFIRT or be notified by EFIRT of
supported resolutions so that vt/efifb can hopefully just handle it
all and do it properly. This approach would be more similar I guess to
how KMS drivers operate, and less fragile than what we're seeing with
these different approaches we've taken.

On Tue, Apr 3, 2018 at 3:05 PM, Zaphod Beeblebrox  wrote:
> 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 accepted, but then
> continuing to boot produced what you see in the video.
>
> I think, since it's in the cetner of the screen, that we're looking at 80x25
> text... which is ... 800 x 600 -ish?  The kernel definately wants graphics
> again ... but ... I dunno ... is it getting it?  Is the 80x25 text mode
> emulated on a bitmapped screen?
>
>
> On Mon, Apr 2, 2018 at 9:07 PM, Kyle Evans  wrote:
>>
>> 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
>> >>
>> >> 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 (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
>> >> > drm-next.
>> >> >
>> >> > One more to mention.
>> >> > I've cherry-picked r330868, r331241 and r331361 on stable/11 after
>> >> > r331114, amd64 and works OK as on head.
>> >> > Additional cherry-picking of r331365 is OK, too.
>> >> >
>> >> > Without r330868, my ThinkPad silently reboots within about 10-60
>> >> > minutes range, maybe by actual access to UEFI RS.
>> >> > With r331241 without r331361 causes instant panic on loading
>> >> > efirt.ko.
>> >> > So all 3 (4) revs should be MFC'ed together.
>> >> >
>> >> > Sorry for delay.
>> >> >
>> >> >
>> >> > On Thu, 22 Mar 2018 10:34:33 -0500
>> >> > Kyle Evans  wrote:
>> >> >
>> >> > > 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 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 be due to this recent addition in dev/efidev/efirt.c
>> >> > > >> by
>> >> > r331241:
>> >> > > >>
>> >> > > >>> if (!efi_is_in_map(map, efihdr->memory_size /
>> >> > efihdr->descriptor_size,
>> >> > > >>> efihdr->descriptor_size,
>> >> > > >>> (vm_offset_t)efi_runtime->rt_gettime))
>> >> > {
>> >> > > >>
>> >> > > >> The faulting address is for "efi_runtime->rt_gettime" (and is
>> >> > > >> still
>> >> > > >> a
>> >> > > >> phys addr here).
>> >> > > >>
>> >> > > >
>> >> > > > The following patch [1] (I can't guarantee how long he'll keep it
>> >> > > > available there) should fix this class of problems.
>> >> > > >
>> >> > > > [1] https://people.freebsd.org/~andrew/0001-Enter-into-the-
>> >> > EFI-environment-before-check-the-GetT.patch
>> >> > >
>> >> > > Now committed as of r331361.
>> >> > > ___
>> >> > > freebsd-current@freebsd.org mailing list
>> >> > > https://lists.freebsd.org/mailman/listinfo/freebsd-current
>> >> > > To unsubscribe, send any mail to "freebsd-current-unsubscribe@
>> >> > freebsd.org"
>> >> > >
>> >> >
>> >> >
>> >> > --
>> >> > Tomoaki AOKI

Re: Call for Testing: UEFI Changes

[Zaphod Beeblebrox]

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 accepted, but then
continuing to boot produced what you see in the video.

I think, since it's in the cetner of the screen, that we're looking at
80x25 text... which is ... 800 x 600 -ish?  The kernel definately wants
graphics again ... but ... I dunno ... is it getting it?  Is the 80x25 text
mode emulated on a bitmapped screen?


On Mon, Apr 2, 2018 at 9:07 PM, Kyle Evans  wrote:

> 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
> >>
> >> On Mon, Apr 2, 2018 at 12:38 AM, Tomoaki AOKI <
> junch...@dec.sakura.ne.jp>
> >> 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 gracefully falling back to mode 0.
> >> >
> >> > As I'm on x11/nvidia-driver, completely no test is done with
> >> > drm-next.
> >> >
> >> > One more to mention.
> >> > I've cherry-picked r330868, r331241 and r331361 on stable/11 after
> >> > r331114, amd64 and works OK as on head.
> >> > Additional cherry-picking of r331365 is OK, too.
> >> >
> >> > Without r330868, my ThinkPad silently reboots within about 10-60
> >> > minutes range, maybe by actual access to UEFI RS.
> >> > With r331241 without r331361 causes instant panic on loading efirt.ko.
> >> > So all 3 (4) revs should be MFC'ed together.
> >> >
> >> > Sorry for delay.
> >> >
> >> >
> >> > On Thu, 22 Mar 2018 10:34:33 -0500
> >> > Kyle Evans  wrote:
> >> >
> >> > > 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 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 be due to this recent addition in dev/efidev/efirt.c
> by
> >> > r331241:
> >> > > >>
> >> > > >>> if (!efi_is_in_map(map, efihdr->memory_size /
> >> > efihdr->descriptor_size,
> >> > > >>> efihdr->descriptor_size,
> >> > > >>> (vm_offset_t)efi_runtime->rt_gettime))
> >> > {
> >> > > >>
> >> > > >> The faulting address is for "efi_runtime->rt_gettime" (and is
> still
> >> > > >> a
> >> > > >> phys addr here).
> >> > > >>
> >> > > >
> >> > > > The following patch [1] (I can't guarantee how long he'll keep it
> >> > > > available there) should fix this class of problems.
> >> > > >
> >> > > > [1] https://people.freebsd.org/~andrew/0001-Enter-into-the-
> >> > EFI-environment-before-check-the-GetT.patch
> >> > >
> >> > > Now committed as of r331361.
> >> > > ___
> >> > > freebsd-current@freebsd.org mailing list
> >> > > https://lists.freebsd.org/mailman/listinfo/freebsd-current
> >> > > To unsubscribe, send any mail to "freebsd-current-unsubscribe@
> >> > freebsd.org"
> >> > >
> >> >
> >> >
> >> > --
> >> > Tomoaki AOKI
> >> > ___
> >> > freebsd-current@freebsd.org mailing list
> >> > https://lists.freebsd.org/mailman/listinfo/freebsd-current
> >> > To unsubscribe, send any mail to
> >> > "freebsd-current-unsubscr...@freebsd.org"
> >> >
> >> ___
> >> freebsd-current@freebsd.org mailing list
> >> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@
> freebsd.org"
> >
> > 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
> the
> > "live cd" choice) and hit enter.  Then I type "root" enter and then
> "reboot"
> > ...
>
> That is interesting indeed... that's perhaps the polar opposite of
> what was being experienced before- it looks like it's setting a higher
> resolution but the firmware isn't 

Re: Call for Testing: UEFI Changes

[Kyle Evans]

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
>>
>> 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 (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
>> > drm-next.
>> >
>> > One more to mention.
>> > I've cherry-picked r330868, r331241 and r331361 on stable/11 after
>> > r331114, amd64 and works OK as on head.
>> > Additional cherry-picking of r331365 is OK, too.
>> >
>> > Without r330868, my ThinkPad silently reboots within about 10-60
>> > minutes range, maybe by actual access to UEFI RS.
>> > With r331241 without r331361 causes instant panic on loading efirt.ko.
>> > So all 3 (4) revs should be MFC'ed together.
>> >
>> > Sorry for delay.
>> >
>> >
>> > On Thu, 22 Mar 2018 10:34:33 -0500
>> > Kyle Evans  wrote:
>> >
>> > > 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 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 be due to this recent addition in dev/efidev/efirt.c by
>> > r331241:
>> > > >>
>> > > >>> if (!efi_is_in_map(map, efihdr->memory_size /
>> > efihdr->descriptor_size,
>> > > >>> efihdr->descriptor_size,
>> > > >>> (vm_offset_t)efi_runtime->rt_gettime))
>> > {
>> > > >>
>> > > >> The faulting address is for "efi_runtime->rt_gettime" (and is still
>> > > >> a
>> > > >> phys addr here).
>> > > >>
>> > > >
>> > > > The following patch [1] (I can't guarantee how long he'll keep it
>> > > > available there) should fix this class of problems.
>> > > >
>> > > > [1] https://people.freebsd.org/~andrew/0001-Enter-into-the-
>> > EFI-environment-before-check-the-GetT.patch
>> > >
>> > > Now committed as of r331361.
>> > > ___
>> > > freebsd-current@freebsd.org mailing list
>> > > https://lists.freebsd.org/mailman/listinfo/freebsd-current
>> > > To unsubscribe, send any mail to "freebsd-current-unsubscribe@
>> > freebsd.org"
>> > >
>> >
>> >
>> > --
>> > Tomoaki AOKI
>> > ___
>> > freebsd-current@freebsd.org mailing list
>> > https://lists.freebsd.org/mailman/listinfo/freebsd-current
>> > To unsubscribe, send any mail to
>> > "freebsd-current-unsubscr...@freebsd.org"
>> >
>> ___
>> freebsd-current@freebsd.org mailing list
>> https://lists.freebsd.org/mailman/listinfo/freebsd-current
>> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
>
> 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 the
> "live cd" choice) and hit enter.  Then I type "root" enter and then "reboot"
> ...

That is interesting indeed... that's perhaps the polar opposite of
what was being experienced before- it looks like it's setting a higher
resolution but the firmware isn't actually putting it into the higher
resolution. The firmware then lies to us about what resolution it's
actually in, so we tell the kernel the wrong thing.

You should be able to confirm this, as I recall, by bumping into the
loader prompt and inspecting the output of `gop get`. That should
report a higher resolution than it's actually in.

> https://youtu.be/tlmaVJ-3aq0
>
> (The rock sound track is just free audio to mask a barking dog and a radio
> in the background.)
>

This was a most enjoyable soundtrack.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Call for Testing: UEFI Changes

[Zaphod Beeblebrox]

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 the
"live cd" choice) and hit enter.  Then I type "root" enter and then
"reboot" ...

https://youtu.be/tlmaVJ-3aq0

(The rock sound track is just free audio to mask a barking dog and a radio
in the background.)


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
>
> 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 (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
> > drm-next.
> >
> > One more to mention.
> > I've cherry-picked r330868, r331241 and r331361 on stable/11 after
> > r331114, amd64 and works OK as on head.
> > Additional cherry-picking of r331365 is OK, too.
> >
> > Without r330868, my ThinkPad silently reboots within about 10-60
> > minutes range, maybe by actual access to UEFI RS.
> > With r331241 without r331361 causes instant panic on loading efirt.ko.
> > So all 3 (4) revs should be MFC'ed together.
> >
> > Sorry for delay.
> >
> >
> > On Thu, 22 Mar 2018 10:34:33 -0500
> > Kyle Evans  wrote:
> >
> > > 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 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 be due to this recent addition in dev/efidev/efirt.c by
> > r331241:
> > > >>
> > > >>> if (!efi_is_in_map(map, efihdr->memory_size /
> > efihdr->descriptor_size,
> > > >>> efihdr->descriptor_size, (vm_offset_t)efi_runtime->rt_
> gettime))
> > {
> > > >>
> > > >> The faulting address is for "efi_runtime->rt_gettime" (and is still
> a
> > > >> phys addr here).
> > > >>
> > > >
> > > > The following patch [1] (I can't guarantee how long he'll keep it
> > > > available there) should fix this class of problems.
> > > >
> > > > [1] https://people.freebsd.org/~andrew/0001-Enter-into-the-
> > EFI-environment-before-check-the-GetT.patch
> > >
> > > Now committed as of r331361.
> > > ___
> > > freebsd-current@freebsd.org mailing list
> > > https://lists.freebsd.org/mailman/listinfo/freebsd-current
> > > To unsubscribe, send any mail to "freebsd-current-unsubscribe@
> > freebsd.org"
> > >
> >
> >
> > --
> > Tomoaki AOKI
> > ___
> > freebsd-current@freebsd.org mailing list
> > https://lists.freebsd.org/mailman/listinfo/freebsd-current
> > To unsubscribe, send any mail to "freebsd-current-unsubscribe@
> freebsd.org"
> >
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Call for Testing: UEFI Changes

[Kyle Evans]

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 gracefully falling back to mode 0.
>

Did you pick up the change on head that calls maybe-efi-resizecons?

On my X220, this bumps my resolution up to 1024x768.

> As I'm on x11/nvidia-driver, completely no test is done with
> drm-next.

This is ok. =)

> One more to mention.
> I've cherry-picked r330868, r331241 and r331361 on stable/11 after
> r331114, amd64 and works OK as on head.
> Additional cherry-picking of r331365 is OK, too.
>
> Without r330868, my ThinkPad silently reboots within about 10-60
> minutes range, maybe by actual access to UEFI RS.
> With r331241 without r331361 causes instant panic on loading efirt.ko.
> So all 3 (4) revs should be MFC'ed together.

Good to hear! We've marked all four of these to be MFC'd in one batch
anyways, just to make sure we don't horribly break things. We seem to
be in a pretty stable state at the moment on head from what I'm
hearing.

> Sorry for delay.

No worries. =)
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Call for Testing: UEFI Changes

[David NewHamlet]

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 (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
> drm-next.
>
> One more to mention.
> I've cherry-picked r330868, r331241 and r331361 on stable/11 after
> r331114, amd64 and works OK as on head.
> Additional cherry-picking of r331365 is OK, too.
>
> Without r330868, my ThinkPad silently reboots within about 10-60
> minutes range, maybe by actual access to UEFI RS.
> With r331241 without r331361 causes instant panic on loading efirt.ko.
> So all 3 (4) revs should be MFC'ed together.
>
> Sorry for delay.
>
>
> On Thu, 22 Mar 2018 10:34:33 -0500
> Kyle Evans  wrote:
>
> > 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 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 be due to this recent addition in dev/efidev/efirt.c by
> r331241:
> > >>
> > >>> if (!efi_is_in_map(map, efihdr->memory_size /
> efihdr->descriptor_size,
> > >>> efihdr->descriptor_size, 
> > >>> (vm_offset_t)efi_runtime->rt_gettime))
> {
> > >>
> > >> The faulting address is for "efi_runtime->rt_gettime" (and is still a
> > >> phys addr here).
> > >>
> > >
> > > The following patch [1] (I can't guarantee how long he'll keep it
> > > available there) should fix this class of problems.
> > >
> > > [1] https://people.freebsd.org/~andrew/0001-Enter-into-the-
> EFI-environment-before-check-the-GetT.patch
> >
> > Now committed as of r331361.
> > ___
> > freebsd-current@freebsd.org mailing list
> > https://lists.freebsd.org/mailman/listinfo/freebsd-current
> > To unsubscribe, send any mail to "freebsd-current-unsubscribe@
> freebsd.org"
> >
>
>
> --
> Tomoaki AOKI
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Call for Testing: UEFI Changes

[Tomoaki AOKI]

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

One more to mention.
I've cherry-picked r330868, r331241 and r331361 on stable/11 after
r331114, amd64 and works OK as on head.
Additional cherry-picking of r331365 is OK, too.

Without r330868, my ThinkPad silently reboots within about 10-60
minutes range, maybe by actual access to UEFI RS.
With r331241 without r331361 causes instant panic on loading efirt.ko.
So all 3 (4) revs should be MFC'ed together.

Sorry for delay.


On Thu, 22 Mar 2018 10:34:33 -0500
Kyle Evans  wrote:

> 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 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 be due to this recent addition in dev/efidev/efirt.c by r331241:
> >>
> >>> if (!efi_is_in_map(map, efihdr->memory_size / 
> >>> efihdr->descriptor_size,
> >>> efihdr->descriptor_size, 
> >>> (vm_offset_t)efi_runtime->rt_gettime)) {
> >>
> >> The faulting address is for "efi_runtime->rt_gettime" (and is still a
> >> phys addr here).
> >>
> >
> > The following patch [1] (I can't guarantee how long he'll keep it
> > available there) should fix this class of problems.
> >
> > [1] 
> > https://people.freebsd.org/~andrew/0001-Enter-into-the-EFI-environment-before-check-the-GetT.patch
> 
> Now committed as of r331361.
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
> 


-- 
Tomoaki AOKI
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Call for Testing: UEFI Changes

[Niclas Zeising]

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 haven't seen any issues with console graphics on either machine.
>> Both computers are running CURRENT from yesterday, the desktop is on
>> r331481 and the laptop probably somewhere around that as well.
>>
> 
> ​Hi,
> 
> I also would like to test the changes on my X230 but looking at ​
> https://download.freebsd.org/ftp/snapshots/ISO-IMAGES/12.0/, the most
> recent snapshot seems to be r331345. How did you get r331481?
> 

Hi!
I updated my FreeBSD system from source.  There are instructions here
https://www.freebsd.org/doc/handbook/current-stable.html and here
https://www.freebsd.org/doc/handbook/makeworld.html on how to do it.
Regards
-- 
Niclas
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Call for Testing: UEFI Changes

[Sheda]

>
> 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 graphics on either machine.
> Both computers are running CURRENT from yesterday, the desktop is on
> r331481 and the laptop probably somewhere around that as well.
>

​Hi,

I also would like to test the changes on my X230 but looking at ​
https://download.freebsd.org/ftp/snapshots/ISO-IMAGES/12.0/, the most
recent snapshot seems to be r331345. How did you get r331481?

Regards,

-S
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Call for Testing: UEFI Changes

[Niclas Zeising]

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 well as the firmware
implementation in many Lenovos. The previously observed behavior was a
kernel panic upon invocation of efibootmgr/efivar, or a kernel panic
just loading efirt.ko or compiling EFIRT into the kernel.

Graphics mode selection is now done differently to avoid regression
caused by r327058 while still achieving the same effect. The observed
regression was that the kernel would usually end up drawing
incorrectly at the old resolution on a subset of the screen, due to
incorrect framebuffer information.

Explicit testing of these changes, the latest of which happened in
r331326, and any feedback from this testing would be greatly
appreciated. Testing should be done with either `options EFIRT` in
your kernel config or efirt.ko loaded along with updated bootloader
bits.

I otherwise plan to MFC commits involved with the above-mentioned
changes by sometime in the first week of April, likely no earlier than
two (2) weeks from now on April 4th.



Hi!
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 graphics on either machine.
Both computers are running CURRENT from yesterday, the desktop is on 
r331481 and the laptop probably somewhere around that as well.


Please let me know if you want me to test anything else!
Regards
--
Niclas

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Call for Testing: UEFI Changes

[Kyle Evans]

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 put UEFI runtime services into virtual address mode, fixing
>> runtime services with U-Boot/UEFI as well as the firmware
>> implementation in many Lenovos. The previously observed behavior was a
>> kernel panic upon invocation of efibootmgr/efivar, or a kernel panic
>> just loading efirt.ko or compiling EFIRT into the kernel.
>>
>> Graphics mode selection is now done differently to avoid regression
>> caused by r327058 while still achieving the same effect. The observed
>> regression was that the kernel would usually end up drawing
>> incorrectly at the old resolution on a subset of the screen, due to
>> incorrect framebuffer information.
>>
>> Explicit testing of these changes, the latest of which happened in
>> r331326, and any feedback from this testing would be greatly
>> appreciated. Testing should be done with either `options EFIRT` in
>> your kernel config or efirt.ko loaded along with updated bootloader
>> bits.
>>
>> I otherwise plan to MFC commits involved with the above-mentioned
>> changes by sometime in the first week of April, likely no earlier than
>> two (2) weeks from now on April 4th.
>
> Just FYI,
>
> After upgrade to r331350 on a Thinkpad X230 using drm-next-kmod
> trackpoint stopped working and touchpad worked but 3 buttons above it
> didn't. Removing drm-next-kmod and start using i915kms.ko from
> /boot/kernel fixed it.
>

I tend to think that's probably unrelated to the things I've poked- I
can't quite imagine how I might have broken it =/. Any chance you can
bissect that to the exact commit?

Thanks!

Kyle Evans
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Call for Testing: UEFI Changes

[Renato Botelho]

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 U-Boot/UEFI as well as the firmware
> implementation in many Lenovos. The previously observed behavior was a
> kernel panic upon invocation of efibootmgr/efivar, or a kernel panic
> just loading efirt.ko or compiling EFIRT into the kernel.
> 
> Graphics mode selection is now done differently to avoid regression
> caused by r327058 while still achieving the same effect. The observed
> regression was that the kernel would usually end up drawing
> incorrectly at the old resolution on a subset of the screen, due to
> incorrect framebuffer information.
> 
> Explicit testing of these changes, the latest of which happened in
> r331326, and any feedback from this testing would be greatly
> appreciated. Testing should be done with either `options EFIRT` in
> your kernel config or efirt.ko loaded along with updated bootloader
> bits.
> 
> I otherwise plan to MFC commits involved with the above-mentioned
> changes by sometime in the first week of April, likely no earlier than
> two (2) weeks from now on April 4th.

Just FYI,

After upgrade to r331350 on a Thinkpad X230 using drm-next-kmod
trackpoint stopped working and touchpad worked but 3 buttons above it
didn't. Removing drm-next-kmod and start using i915kms.ko from
/boot/kernel fixed it.

-- 
Renato Botelho
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Call for Testing: UEFI Changes

[Kyle Evans]

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 -
>
> I build efirt into the kernel and it's now doing a panic on boot. It
> appears to be due to this recent addition in dev/efidev/efirt.c by r331241:
>
>> if (!efi_is_in_map(map, efihdr->memory_size / 
>> efihdr->descriptor_size,
>> efihdr->descriptor_size, (vm_offset_t)efi_runtime->rt_gettime)) {
>
> The faulting address is for "efi_runtime->rt_gettime" (and is still a
> phys addr here).
>

The following patch [1] (I can't guarantee how long he'll keep it
available there) should fix this class of problems.

[1] 
https://people.freebsd.org/~andrew/0001-Enter-into-the-EFI-environment-before-check-the-GetT.patch
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Call for Testing: UEFI Changes

[Kyle Evans]

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 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 be due to this recent addition in dev/efidev/efirt.c by r331241:
>>
>>> if (!efi_is_in_map(map, efihdr->memory_size / 
>>> efihdr->descriptor_size,
>>> efihdr->descriptor_size, (vm_offset_t)efi_runtime->rt_gettime)) 
>>> {
>>
>> The faulting address is for "efi_runtime->rt_gettime" (and is still a
>> phys addr here).
>>
>
> The following patch [1] (I can't guarantee how long he'll keep it
> available there) should fix this class of problems.
>
> [1] 
> https://people.freebsd.org/~andrew/0001-Enter-into-the-EFI-environment-before-check-the-GetT.patch

Now committed as of r331361.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Call for Testing: UEFI Changes

[Peter Lei]

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 be due to this recent addition in dev/efidev/efirt.c by r331241:

> if (!efi_is_in_map(map, efihdr->memory_size / efihdr->descriptor_size,
> efihdr->descriptor_size, (vm_offset_t)efi_runtime->rt_gettime)) {

The faulting address is for "efi_runtime->rt_gettime" (and is still a
phys addr here).

--peter


> 
> 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 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 /boot/loader.conf makes
>>> the kernel panic instantly. Photo of panic:
>>> https://photos.app.goo.gl/ph3yQukOAUdQpsvK2
>>>
>>>
>>> Jakob
>>>
>>>
>>
>> Hi,
>>
>> The efi.4th removal has been reverted in r331353. A couple of inquiries for 
>> you:
>>
>> 1.) Before loading efirt, can you show me what `sysctl
>> machdep.efi_map` looks like?
>>
>> 2.) After `kldload efirt` and getting a panic, can you show me what
>> `show registers` looks like?
>>
>> 3.) Have you used efirt successfully before?
>>
>> Thanks,
>>
>> Kyle Evans
>> ___
>> freebsd-current@freebsd.org mailing list
>> https://lists.freebsd.org/mailman/listinfo/freebsd-current
>> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
>>
> 
> 



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Call for Testing: UEFI Changes

[Tomoaki AOKI]

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 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 /boot/loader.conf makes
> > the kernel panic instantly. Photo of panic:
> > https://photos.app.goo.gl/ph3yQukOAUdQpsvK2
> >
> >
> > Jakob
> >
> >
> 
> Hi,
> 
> The efi.4th removal has been reverted in r331353. A couple of inquiries for 
> you:
> 
> 1.) Before loading efirt, can you show me what `sysctl
> machdep.efi_map` looks like?
> 
> 2.) After `kldload efirt` and getting a panic, can you show me what
> `show registers` looks like?
> 
> 3.) Have you used efirt successfully before?
> 
> Thanks,
> 
> Kyle Evans
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
> 


-- 
Tomoaki AOKI
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Call for Testing: UEFI Changes

[Kyle Evans]

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.
> Reinstalling efi.4th problem 2 appears.
>
>
> 2. Fixing problem 1 and adding efirt_load="YES" to /boot/loader.conf makes
> the kernel panic instantly. Photo of panic:
> https://photos.app.goo.gl/ph3yQukOAUdQpsvK2
>
>
> Jakob
>
>

Hi,

The efi.4th removal has been reverted in r331353. A couple of inquiries for you:

1.) Before loading efirt, can you show me what `sysctl
machdep.efi_map` looks like?

2.) After `kldload efirt` and getting a panic, can you show me what
`show registers` looks like?

3.) Have you used efirt successfully before?

Thanks,

Kyle Evans
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Call for Testing: UEFI Changes

[Kyle Evans]

On Thu, Mar 22, 2018 at 6:09 AM, M - Krasznai András
<krasznai.and...@mands.hu> wrote:
>> -Eredeti üzenet-
>> Feladó: owner-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!
>>>
>>>
>>> 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 /boot/loader.conf
>>> makes the kernel panic instantly. Photo of panic:
>>> https://photos.app.goo.gl/ph3yQukOAUdQpsvK2
>>>
>>>
>>> Jakob
>>
>> The efi.4th was introduced and later removed by Warner, a bit too hastily 
>> perhaps… but perhaps it is better to note the partial revert of the removal 
>> or something like that:)
>>
>> rgds,
>> toomas
>
> Hi
>
> I found this problem today morning. Fortunately I can copy the efi.4th file 
> back to /boot from /usr/src/stand/forth
>
> On the other hand, removing the reference to efi.4th from loader.rc causes 
> the boot stop at the loader prompt
>
> rgds
> András Krasznai
>

Hi,

efi.4th has been reinstated as of r331353- things should work a little
more smoothly now.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

RE: Call for Testing: UEFI Changes

[M - Krasznai András]

Hi

I found this problem today morning. Fortunately I can copy the efi.4th file 
back to /boot from /usr/src/stand/forth

On the other hand, removing the reference to efi.4th from loader.rc causes the 
boot stop at the loader prompt

rgds
András Krasznai


-Eredeti üzenet-
Feladó: owner-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!
> 
> 
> 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 /boot/loader.conf 
> makes the kernel panic instantly. Photo of panic: 
> https://photos.app.goo.gl/ph3yQukOAUdQpsvK2
> 
> 
> Jakob

The efi.4th was introduced and later removed by Warner, a bit too hastily 
perhaps… but perhaps it is better to note the partial revert of the removal or 
something like that:)

rgds,
toomas


> 
> 
> 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 well as the firmware 
>> implementation in many Lenovos. The previously observed behavior was 
>> a kernel panic upon invocation of efibootmgr/efivar, or a kernel 
>> panic just loading efirt.ko or compiling EFIRT into the kernel.
>> 
>> Graphics mode selection is now done differently to avoid regression 
>> caused by r327058 while still achieving the same effect. The observed 
>> regression was that the kernel would usually end up drawing 
>> incorrectly at the old resolution on a subset of the screen, due to 
>> incorrect framebuffer information.
>> 
>> Explicit testing of these changes, the latest of which happened in 
>> r331326, and any feedback from this testing would be greatly 
>> appreciated. Testing should be done with either `options EFIRT` in 
>> your kernel config or efirt.ko loaded along with updated bootloader 
>> bits.
>> 
>> I otherwise plan to MFC commits involved with the above-mentioned 
>> changes by sometime in the first week of April, likely no earlier 
>> than two (2) weeks from now on April 4th.
>> 
>> Thanks,
>> 
>> Kyle Evans
>> ___
>> freebsd-current@freebsd.org  mailing list 
>> https://lists.freebsd.org/mailman/listinfo/freebsd-current
>> To unsubscribe, send any mail to"freebsd-current-unsubscr...@freebsd.org"
> 
> ___
> freebsd-current@freebsd.org mailing list 
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

___
freebsd-current@freebsd.org mailing list 
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Call for Testing: UEFI Changes

[Toomas Soome]

> 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. 
> Reinstalling efi.4th problem 2 appears.
> 
> 
> 2. Fixing problem 1 and adding efirt_load="YES" to /boot/loader.conf makes 
> the kernel panic instantly. Photo of panic: 
> https://photos.app.goo.gl/ph3yQukOAUdQpsvK2
> 
> 
> Jakob

The efi.4th was introduced and later removed by Warner, a bit too hastily 
perhaps… but perhaps it is better to note the partial revert of the removal or 
something like that:)

rgds,
toomas


> 
> 
> 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 well as the firmware
>> implementation in many Lenovos. The previously observed behavior was a
>> kernel panic upon invocation of efibootmgr/efivar, or a kernel panic
>> just loading efirt.ko or compiling EFIRT into the kernel.
>> 
>> Graphics mode selection is now done differently to avoid regression
>> caused by r327058 while still achieving the same effect. The observed
>> regression was that the kernel would usually end up drawing
>> incorrectly at the old resolution on a subset of the screen, due to
>> incorrect framebuffer information.
>> 
>> Explicit testing of these changes, the latest of which happened in
>> r331326, and any feedback from this testing would be greatly
>> appreciated. Testing should be done with either `options EFIRT` in
>> your kernel config or efirt.ko loaded along with updated bootloader
>> bits.
>> 
>> I otherwise plan to MFC commits involved with the above-mentioned
>> changes by sometime in the first week of April, likely no earlier than
>> two (2) weeks from now on April 4th.
>> 
>> Thanks,
>> 
>> Kyle Evans
>> ___
>> freebsd-current@freebsd.org  mailing list
>> https://lists.freebsd.org/mailman/listinfo/freebsd-current
>> To unsubscribe, send any mail to"freebsd-current-unsubscr...@freebsd.org"
> 
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Call for Testing: UEFI Changes

[Jakob Alvermark]

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 /boot/loader.conf 
makes the kernel panic instantly. Photo of panic: 
https://photos.app.goo.gl/ph3yQukOAUdQpsvK2



Jakob


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 well as the firmware
implementation in many Lenovos. The previously observed behavior was a
kernel panic upon invocation of efibootmgr/efivar, or a kernel panic
just loading efirt.ko or compiling EFIRT into the kernel.

Graphics mode selection is now done differently to avoid regression
caused by r327058 while still achieving the same effect. The observed
regression was that the kernel would usually end up drawing
incorrectly at the old resolution on a subset of the screen, due to
incorrect framebuffer information.

Explicit testing of these changes, the latest of which happened in
r331326, and any feedback from this testing would be greatly
appreciated. Testing should be done with either `options EFIRT` in
your kernel config or efirt.ko loaded along with updated bootloader
bits.

I otherwise plan to MFC commits involved with the above-mentioned
changes by sometime in the first week of April, likely no earlier than
two (2) weeks from now on April 4th.

Thanks,

Kyle Evans
___
freebsd-current@freebsd.org  mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to"freebsd-current-unsubscr...@freebsd.org"


___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Call for Testing: UEFI Changes

[Kyle Evans]

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 many Lenovos. The previously observed behavior was a
kernel panic upon invocation of efibootmgr/efivar, or a kernel panic
just loading efirt.ko or compiling EFIRT into the kernel.

Graphics mode selection is now done differently to avoid regression
caused by r327058 while still achieving the same effect. The observed
regression was that the kernel would usually end up drawing
incorrectly at the old resolution on a subset of the screen, due to
incorrect framebuffer information.

Explicit testing of these changes, the latest of which happened in
r331326, and any feedback from this testing would be greatly
appreciated. Testing should be done with either `options EFIRT` in
your kernel config or efirt.ko loaded along with updated bootloader
bits.

I otherwise plan to MFC commits involved with the above-mentioned
changes by sometime in the first week of April, likely no earlier than
two (2) weeks from now on April 4th.

Thanks,

Kyle Evans
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"