Re: gpt+uefi boot+openbsd+linux

[kelly]

I dual boot Arch Linux and OpenBSD off the same hard drive (GPT/UEFI) on my 
Thinkpad X395, and found this very helpful when I
was setting up:
https://functionallyparanoid.com/2017/06/30/boot-all-the-things/

Basically, you set up Arch first, install and configure rEFInd, and then try 
installing OpenBSD on just the remaining partition.
There are some really helpful instructions here on how to get rEFInd to 
recognize the OpenBSD partition that rescued me from the
pit of despair.

Hope this helps you,
Kelly

On Tue, May 24, 2022 at 07:28:26PM -0300, Gustavo Rios wrote:

May some one here suggest a documentation the explains this scenario ? I am
in needof this.

Thanks in advance!

Gustavo.

--
The lion and the tiger may be more powerful, but the wolves do not perform
in the circus

Re: gpt+uefi boot+openbsd+linux

[Stuart Henderson]

On 2022-05-24, Nick Holland  wrote:
> On 5/24/22 6:28 PM, Gustavo Rios wrote:
>> May some one here suggest a documentation the explains this scenario ? I am
>> in needof this.
>> 
>> Thanks in advance!
>
> I've actually been experimenting with the UEFI OpenBSD and Windows combo,
> though I suspect it is applicable to Linux, as well.
>
> Warning: I'm trying to avoid GRUB as my boot selector.  UEFI is supposed
> to be able to do this for us.  So I would rather just use it.  I don't
> trust grub to do anything other than Windows and Linux (which is just
> Windows re-invented badly).
>
> Short version: wow...there's a lot variety out there on machines.  If you
> want one answer for all hardware, that's not gonna happen. :-/
> That's about the only certainty I have at this point.  Many UEFI systems
> are only designed to boot Windows it seems, the idea of multiple OSs on
> one disk didn't occur to some people..

rEFInd works pretty well - it's just a boot manager and still uses the
standard OS boot loader to boot the kernel. I didn't like the icons so set
it to "textonly", with it set to autoboot OpenBSD after a short timeout,
which I found much more convenient than the built-in boot manager on the
machine I wanted to dual-boot. Good information about the EFI boot process
(and especially about CSM) on the website - https://www.rodsbooks.com/refind/

Re: gpt+uefi boot+openbsd+linux

[Nathaniel Nigro]

I  mount the ntfs partition with the firmware, and hide and unhide
Microsoft's as needed

On Tue, May 24, 2022, 6:31 PM Gustavo Rios  wrote:

> May some one here suggest a documentation the explains this scenario ? I am
> in needof this.
>
> Thanks in advance!
>
> Gustavo.
>
> --
> The lion and the tiger may be more powerful, but the wolves do not perform
> in the circus
>

Re: gpt+uefi boot+openbsd+linux

[flint pyrite]

off topic:

I used to do that myself. Now I just run openbsd on two laptops. I have a
box with FreeBSD and bhyve where I run Windows and Linux variations. I wish
OpenBSD had a better hypervisor or at least port byhve.

I use WIndows for porting my applications too. Not the other way around. I
rely on OpenBSD not WIndows.

On Tue, May 24, 2022 at 8:01 PM Courtney  wrote:

> Not sure what your hardware situation is, but I have been able to dual
> boot Linux and OpenBSD no problem. I have Linux on 1 drive and OpenBSD
> on another. At boot I default to my OpenBSD drive. However, to get to
> Linux I use my motherboard's boot menu and select the Linux drive.
> Hasn't been an issue. I'm sure things get muddy when you want them both
> on the same drive..I don't like attempting that anymore for any OS
> combination. Too many headaches.
>
> Courtney
>
> On 5/24/22 15:28, Gustavo Rios wrote:
> > May some one here suggest a documentation the explains this scenario ? I
> am
> > in needof this.
> >
> > Thanks in advance!
> >
> > Gustavo.
> >
>
>

Re: gpt+uefi boot+openbsd+linux

[Courtney]

Not sure what your hardware situation is, but I have been able to dual 
boot Linux and OpenBSD no problem. I have Linux on 1 drive and OpenBSD 
on another. At boot I default to my OpenBSD drive. However, to get to 
Linux I use my motherboard's boot menu and select the Linux drive. 
Hasn't been an issue. I'm sure things get muddy when you want them both 
on the same drive..I don't like attempting that anymore for any OS 
combination. Too many headaches.


Courtney

On 5/24/22 15:28, Gustavo Rios wrote:

May some one here suggest a documentation the explains this scenario ? I am
in needof this.

Thanks in advance!

Gustavo.

Re: gpt+uefi boot+openbsd+linux

[Nick Holland]

On 5/24/22 6:28 PM, Gustavo Rios wrote:

May some one here suggest a documentation the explains this scenario ? I am
in needof this.

Thanks in advance!


I've actually been experimenting with the UEFI OpenBSD and Windows combo,
though I suspect it is applicable to Linux, as well.

Warning: I'm trying to avoid GRUB as my boot selector.  UEFI is supposed
to be able to do this for us.  So I would rather just use it.  I don't
trust grub to do anything other than Windows and Linux (which is just
Windows re-invented badly).

Short version: wow...there's a lot variety out there on machines.  If you
want one answer for all hardware, that's not gonna happen. :-/
That's about the only certainty I have at this point.  Many UEFI systems
are only designed to boot Windows it seems, the idea of multiple OSs on
one disk didn't occur to some people..

I don't want to use the Windows 10 boot selection process IF I have
another option.  Unlike Windows 7 and before, it seems to boot
95% of Windows, then gives you the menu.  If you pick OpenBSD, it then
totally reboots the machine -- back to the firmware and back up, but
this time to OpenBSD. If you pick Windows, the last 5% loads in a couple
seconds.

IF you install OpenBSD first, you need to puff-out the GPT boot
partition before install.  OpenBSD's default is really tiny, just
enough to boot OpenBSD (as you would expect).  Boot bsd.rd, drop
to shell, MAKEDEV your disk, "fdisk -gb20 sd0" or similar, iirc,
for a 100MB GPT UEFI boot partition.  The default Windows one is
big enough for OpenBSD to share, I'm guessing Linux, as well.

A couple Dell laptops I have with UEFI actually don't suck.  In the BIOS,
there's an option to select various boot targets.  One is "Windows Boot
Manager" or something like that, the others can be loaders pulled out of
the UEFI boot partition.  This ends up working really slickly for dual
booting, and it looks like it would easily extend to multiple OSs.
Basically put each option in your boot list, make the first one your
primary OS (the "no hands" boot).  If you want to boot a different OS,
you hit the boot selection key at the right time (F12? I mark mine with
a bit of paint, so I can't remember what it is).  This brings up a
menu, the menu selections can be readable to humans...  May not be
the ultimate solution for all people, but ... works really well for
me.

I've got a couple older HP systems, not so impressive.  If you to hit
the magic key (F9, iirc) at the right moment, you can poke around
in the boot partition.  Otherwise, it wants to boot a particular OS, and
if I recall properly, I got one booting OpenBSD by default, the other
windows by default, and I have NO IDEA how the default was chosen (or
is it just the firmware on this machine prefers ...?).  One one of them,
I found a 16MB (yes, MB, not GB) SD card, came with an old digicam
(flashback to 12 exposure rolls of film!).  I dropped minirootXX.img
on it, created a /etc/boot.conf file that pointed to pulling the
kernel off hd1a:/bsd and called it done.  Want to run OpenBSD, leave
the SD card in place, want to boot windows, eject the card a little, push
it back in when it's booted.  This is cheesy, doesn't scale to a third OS,
but it works for me in this laptop.

I'm working on a better write-up (with fewer "IIRC"s :) ), but this might
be enough to get you started.

Nick.

gpt+uefi boot+openbsd+linux

[Gustavo Rios]

May some one here suggest a documentation the explains this scenario ? I am
in needof this.

Thanks in advance!

Gustavo.

-- 
The lion and the tiger may be more powerful, but the wolves do not perform
in the circus

Re: iPXE and UEFI boot

[Christer Solskogen]

On Mon, Dec 2, 2019 at 6:06 AM c0nnax  wrote:

> Maybe this helps.
> https://github.com/antonym/netboot.xyz/blob/master/src/openbsd.ipxe
>
>
That's for "legacy" mbr booting. And that  works just great, it's that
fsck-ing UEFI thing that messes stuff up.

Re: iPXE and UEFI boot

[Christian Weisgerber]

Christer Solskogen:

> > With UEFI and PXE I have successfully netbooted
> > * amd64 (Thinkpad X1C5) with BOOTX64.EFI after bluhm@'s recent
> >   bootdev_dip fix
> 
> Is that already in current?

Yes, it was committed five days ago.

> I now tried having bsd.rd in tftp root
> directory, and BOOTX.EFI does find it (renamed bsd.rd to bsd, just to use
> the default settings)
> It loads the kernel but I only get a black screen. No kernel messages, what
> so ever.

I guess there are more bugs waiting to be found. :-(

-- 
Christian "naddy" Weisgerber  na...@mips.inka.de

Re: iPXE and UEFI boot

[Christer Solskogen]

On Sun, Dec 1, 2019 at 4:26 PM Christian Weisgerber 
wrote:

>
> With UEFI and PXE I have successfully netbooted
> * amd64 (Thinkpad X1C5) with BOOTX64.EFI after bluhm@'s recent
>   bootdev_dip fix
>

Is that already in current? I now tried having bsd.rd in tftp root
directory, and BOOTX.EFI does find it (renamed bsd.rd to bsd, just to use
the default settings)
It loads the kernel but I only get a black screen. No kernel messages, what
so ever.

Re: iPXE and UEFI boot

[Christian Weisgerber]

On 2019-12-01, Christer Solskogen  wrote:

> I've tried sanboot for iso, but it fails. I *can* get BOOTX64.EFI to start,
> but it cant find bsd.rd (perhaps BOOTX64.EFI requires tftpd?),

No "perhaps". BOOTX64.EFI uses TFTP to load the kernel, just like
pxeboot does.

With UEFI and PXE I have successfully netbooted
* arm64 (OverDrive 1000) with BOOTAA64.EFI
* amd64 (Thinkpad X1C5) with BOOTX64.EFI after bluhm@'s recent
  bootdev_dip fix

-- 
Christian "naddy" Weisgerber  na...@mips.inka.de

iPXE and UEFI boot

[Christer Solskogen]

Hi!

Does anyone have a working setup / script for iPXE and UEFI boot of
OpenBSD? I think I've tried anything, but there might some someone who has
a trick of their sleeve that I havent tried.

I've tried sanboot for iso, but it fails. I *can* get BOOTX64.EFI to start,
but it cant find bsd.rd (perhaps BOOTX64.EFI requires tftpd?), but I was
hoping I could go all http://.

-- 
chs

Re: Crypto softraid is supported on GPT/UEFI boot and not just on BIOS/MBR boot, right?

[Janne Johansson]

2017-09-29 3:31 GMT+02:00 Nick Holland :

>
> By that logic, we should have quit using cheap disks when they went over
> 32MB.  Or 120MB.  Or 504MB.  Or 128GB.  Or ...
> I have MBRs on 4TB SoftRaid volumes, works fine.
>
> fdisk, make the "entire" disk (welllthe first 2TB) OpenBSD.
> disklabel, change the boundaries of the OpenBSD part to be the entire
> disk.  Done.
>
>
I seem to recall that "trick" on the 2G boundary, or if it was the 8G IDE
limit, or the 33G.
disklabel being "better" than fdisk at accepting
larger-than-some-artificial-limit seems to
be a tradition. ;)


-- 
May the most significant bit of your life be positive.

Re: Crypto softraid is supported on GPT/UEFI boot and not just on BIOS/MBR boot, right?

[Nick Holland]

On 09/28/17 05:58, ti...@openmailbox.org wrote:
>> On Wed, Sep 27, 2017 at 05:02:06PM -, ti...@openmailbox.org
>> wrote:
> ..
>>> What am I doing wrong, are there actually any installboot
>>> arguments that could help me make it work?
>> 
>> It looks like you're using GPT on both the physical and the 
>> softraid disk, correct?
>> 
>> In my setup, I have GPT on the physical disk (sd0) but an MBR on
>> the softraid volume. So perhaps try using an MBR on sd1 and see if
>> that helps? I am poking in the dark here. No idea if that will work
>> for you.
> 
> An MBR has a max of 2TB so over time the whole MBR thing needs to be
> discontinued, right, however this is a smaller disk so having MBR
> inside the softraid would work indeed.

By that logic, we should have quit using cheap disks when they went over
32MB.  Or 120MB.  Or 504MB.  Or 128GB.  Or ...
I have MBRs on 4TB SoftRaid volumes, works fine.

fdisk, make the "entire" disk (welllthe first 2TB) OpenBSD.
disklabel, change the boundaries of the OpenBSD part to be the entire
disk.  Done.

Nick.

Re: Crypto softraid is supported on GPT/UEFI boot and not just on BIOS/MBR boot, right?

[tinkr]

> On Wed, Sep 27, 2017 at 05:02:06PM -, ti...@openmailbox.org wrote:
..
>> What am I doing wrong, are there actually any installboot arguments that 
>> could help me make it work?
> 
> It looks like you're using GPT on both the physical and the
> softraid disk, correct?
> 
> In my setup, I have GPT on the physical disk (sd0) but an MBR
> on the softraid volume. So perhaps try using an MBR on sd1 and
> see if that helps?
> I am poking in the dark here. No idea if that will work for you.

An MBR has a max of 2TB so over time the whole MBR thing needs to be 
discontinued, right, however this is a smaller disk so having MBR inside the 
softraid would work indeed.

I mostly chose softraid in the first place for symmetry.

I'll try make the softraid contain an MBR and let you know.


Indeed I'm on 6.1, so I see that's why I run BOOTX64 3.32 rather than the 
newest BOOTX64 3.33 of -current. As soon as I try -current (or 6.2) I'll retry 
the whole installation and let you know too.

Thanks again,
Tinker

Re: Crypto softraid is supported on GPT/UEFI boot and not just on BIOS/MBR boot, right?

[Stefan Sperling]

On Wed, Sep 27, 2017 at 05:02:06PM -, ti...@openmailbox.org wrote:
> > On Wed, Sep 27, 2017 at 10:31:22AM -, ti...@openmailbox.org wrote:
> >>  >> OpenBSD/amd64 BOOTX64 3.32

Are you running -current?
(We would already know that if you had included a dmesg -- tsk tsk).

In -current, boot is version "3.33", not "3.32".

> I then booted the machine (by typing "boot sr0a:/bsd" in the boot console 
> again of course) and did "installboot -v sd1", and it gave:
> 
>  Using / as root
>  installing bootstrap on /dev/rsd0c
>  using first-stage /usr/mdec/biosboot, second-stage /usr/mdec/boot
>  sd1: softraid volume with 1 disk(s)
>  sd1: installing boot loader on softraid volume
>  /usr/mdec/boot is 6 blocks x 16384 bytes
>  copying /usr/mdec/BOOTIA32.EFI to 
> /tmp/installboot.1lt1hgtQYa/efi/BOOT/BOOTIA32.EFI
>  copying /usr/mdec/BOOTIX64.EFI to 
> /tmp/installboot.1lt1hgtQYa/efi/BOOT/BOOTIX64.EFI
> 
> Rebooting, that also did not help.

That looks OK, though. Passing the softraid disk is correct.

> I tried with "fdisk -e sd1" and disabling the 1 (EFI) partition by setting 
> its type to 0 (so that installboot would not try to install any EFI files to 
> sd1i) and then doing "installboot sd1", and that did not help too.
> 
> What am I doing wrong, are there actually any installboot arguments that 
> could help me make it work?

It looks like you're using GPT on both the physical and the
softraid disk, correct?

In my setup, I have GPT on the physical disk (sd0) but an MBR
on the softraid volume. So perhaps try using an MBR on sd1 and
see if that helps?
I am poking in the dark here. No idea if that will work for you.

Re: Crypto softraid is supported on GPT/UEFI boot and not just on BIOS/MBR boot, right?

[tinkr]

> On Wed, Sep 27, 2017 at 10:31:22AM -, ti...@openmailbox.org wrote:
>>  probing: pc0 mem[572K 56K 495M 1455M 5M 6144M]
>>  disk: hd0* hd1* hd2 sr0*
>>  >> OpenBSD/amd64 BOOTX64 3.32
>>  open(hd0a:/etc/boot.conf): Invalid Argument
>>  boot>
>> 
>> 
>> This error may be because OpenBSD creating "boot.conf" within the FAT32 EFI 
>> system boot volume actually crates "bo~1.con", which is not resolved as 
>> "boot.conf" by OpenBSD's BOOTX64 EFI loader program? -
> 
> boot.conf has nothing to do with it.
> softraid boot is handled independently from boot.conf.
> 
>> How do I instruct BOOTX64 to boot from sr0a:/boot ?
> 
> What's odd is that you have a bootable sr0 but the boot loader still
> tries hd0 instead. That looks like a bug. Usually sr0 should be tried
> in this situation.
>  
> I don't know the solution. Perhaps try re-running installboot?
> 
> FWIW, this all works fine for me on a thinkpad helix2.

Hi Stefan,

I first tried booting the machine (by typing "boot sr0a:/bsd" in the boot 
console of course), and doing "installboot -v sd0". It says:

 Using / as root
 installing bootstrap on /dev/rsd0c
 using first-stage /usr/mdec/biosboot, second-stage /usr/mdec/boot
 copying /usr/mdec/BOOTIA32.EFI to 
/tmp/installboot.MjdT8BAY8o/efi/BOOT/BOOTIA32.EFI
 copying /usr/mdec/BOOTIX64.EFI to 
/tmp/installboot.MjdT8BAY8o/efi/BOOT/BOOTIX64.EFI


..and after rebooting the machine, booting was still not automatic.

I then booted the machine (by typing "boot sr0a:/bsd" in the boot console again 
of course) and did "installboot -v sd1", and it gave:

 Using / as root
 installing bootstrap on /dev/rsd0c
 using first-stage /usr/mdec/biosboot, second-stage /usr/mdec/boot
 sd1: softraid volume with 1 disk(s)
 sd1: installing boot loader on softraid volume
 /usr/mdec/boot is 6 blocks x 16384 bytes
 copying /usr/mdec/BOOTIA32.EFI to 
/tmp/installboot.1lt1hgtQYa/efi/BOOT/BOOTIA32.EFI
 copying /usr/mdec/BOOTIX64.EFI to 
/tmp/installboot.1lt1hgtQYa/efi/BOOT/BOOTIX64.EFI

Rebooting, that also did not help.

I tried with "fdisk -e sd1" and disabling the 1 (EFI) partition by setting its 
type to 0 (so that installboot would not try to install any EFI files to sd1i) 
and then doing "installboot sd1", and that did not help too.

What am I doing wrong, are there actually any installboot arguments that could 
help me make it work?


Would I need to add some debug output lines to installboot? Actually, it would 
be nice if installboot's verbose mode would clarify which configuration the 
boot code is actually set up with, so the user is a bit more saved from the 
wild-guessing-by-a-large-number-of-reboots-hoping-for-the-best kind of method 
I'm refered to right now. Please let me know what I should do now to fix it -

Thanks,
Tinker

Re: Crypto softraid is supported on GPT/UEFI boot and not just on BIOS/MBR boot, right?

[Stefan Sperling]

On Wed, Sep 27, 2017 at 10:31:22AM -, ti...@openmailbox.org wrote:
>  probing: pc0 mem[572K 56K 495M 1455M 5M 6144M]
>  disk: hd0* hd1* hd2 sr0*
>  >> OpenBSD/amd64 BOOTX64 3.32
>  open(hd0a:/etc/boot.conf): Invalid Argument
>  boot>
> 
> 
> This error may be because OpenBSD creating "boot.conf" within the FAT32 EFI 
> system boot volume actually crates "bo~1.con", which is not resolved as 
> "boot.conf" by OpenBSD's BOOTX64 EFI loader program? -

boot.conf has nothing to do with it.
softraid boot is handled independently from boot.conf.

> How do I instruct BOOTX64 to boot from sr0a:/boot ?

What's odd is that you have a bootable sr0 but the boot loader still
tries hd0 instead. That looks like a bug. Usually sr0 should be tried
in this situation.
 
I don't know the solution. Perhaps try re-running installboot?

FWIW, this all works fine for me on a thinkpad helix2.

Re: Crypto softraid is supported on GPT/UEFI boot and not just on BIOS/MBR boot, right?

[tinkr]

>> On Wed, Sep 27, 2017 at 08:06:15AM -, ti...@openmailbox.org wrote:
[..]
> How do I instruct BOOTX64 to boot from sr0a:/boot ?
(Sorry typo, this should read "How do I instruct BOOTX64 to boot from sr0a:/bsd 
?", however sr0a:/bsd was spelled correctly above so it was clear enough 
already.)

Re: Crypto softraid is supported on GPT/UEFI boot and not just on BIOS/MBR boot, right?

[tinkr]

> On Wed, Sep 27, 2017 at 08:06:15AM -, ti...@openmailbox.org wrote:
>> Hi!
>> 
>> Crypto softraid is supported on GPT/UEFI boot and not just on BIOS/MBR boot, 
>> right?
>> 
>> It's supposed to work exactly the same way, just out of the box, the boot 
>> code will ask for typed password or keydisk, right?
>> 
>> Thanks,
>> Tinker
> 
> http://www.openbsd.org/faq/faq14.html#softraid

Dear Stefan,

Thanks for responding - yes thanks for the obvious reference. For making GPT 
booting work at all with OpenBSD, the "-b 960" argument to "fdisk -ig" that's 
mentioned on the FAQ page, is instrumental, as "fdisk -ig" only creates a GPT 
partitioning table whereas booting requires an EFI system boot partition too, 
and fdisk creates that one only when "-b 960" is specified.


About automatic softraid unpacking on boot, the answer I found was that: Yes, 
it is supported, but I think the boot order when booting softraid crypto on 
GPT/UEFI is different from on MBR/boot.

I think on MBR/BIOS boot, the setup is that OpenBSD's MBR sector reads some 
reserved subsequent sectors, which contain the unpacking code which ask you for 
password/keydisk, and then unpacks the softraid, which will in turn contain the 
boot code, which reads boot.conf .

In GPT/UEFI boot, OpenBSD's boot sequence is different: The host system's UEFI 
firmware will load the /efi/boot/bootx64.efi file, which tries to load the 
boot.conf file and then boot the system.


Unfortunately, bootx.64.efi does not get the idea of trying to boot sr0a:/bsd , 
but just tries hd0a:/bsd and then fails.

I tried to feed it with a boot.conf file by doing mount /dev/sd0i /mnt; mkdir 
-p /mnt/etc; echo "boot sr0a:/bsd" >> /mnt/etc/boot.conf , however this has no 
effect on the boot process, it still says the same as when the file was not 
there:

 probing: pc0 mem[572K 56K 495M 1455M 5M 6144M]
 disk: hd0* hd1* hd2 sr0*
 >> OpenBSD/amd64 BOOTX64 3.32
 open(hd0a:/etc/boot.conf): Invalid Argument
 boot>


This error may be because OpenBSD creating "boot.conf" within the FAT32 EFI 
system boot volume actually crates "bo~1.con", which is not resolved as 
"boot.conf" by OpenBSD's BOOTX64 EFI loader program? -

How do I instruct BOOTX64 to boot from sr0a:/boot ?

Also is this in the manual yet, where?

Thanks!
Tinker

Re: Crypto softraid is supported on GPT/UEFI boot and not just on BIOS/MBR boot, right?

[Stefan Sperling]

On Wed, Sep 27, 2017 at 08:06:15AM -, ti...@openmailbox.org wrote:
> Hi!
> 
> Crypto softraid is supported on GPT/UEFI boot and not just on BIOS/MBR boot, 
> right?
> 
> It's supposed to work exactly the same way, just out of the box, the boot 
> code will ask for typed password or keydisk, right?
> 
> Thanks,
> Tinker

http://www.openbsd.org/faq/faq14.html#softraid

Crypto softraid is supported on GPT/UEFI boot and not just on BIOS/MBR boot, right?

[tinkr]

Hi!

Crypto softraid is supported on GPT/UEFI boot and not just on BIOS/MBR boot, 
right?

It's supposed to work exactly the same way, just out of the box, the boot code 
will ask for typed password or keydisk, right?

Thanks,
Tinker

Re: Install UEFI with softraid: How do I create the UEFI boot partition in the installer? And sth quirky in /install .

[Thomas Bohl]

> The standard way to install crypto is to go with the "(S)hell" option at boot.
> 
> In the MBR days it would be "fdisk -i sd0", now should be with the GPT option 
> on so "fdisk -ig sd0".
> 
> Doing this, importantly, no "EFI Sys" partition is created.

# dd if=/dev/zero of=/dev/sd0c bs=1m count=10
# fdisk -igy -b 960 sd0

Does that change anything?



smime.p7s
Description: S/MIME Cryptographic Signature

Install UEFI with softraid: How do I create the UEFI boot partition in the installer? And sth quirky in /install .

[tinkr]

Dear misc@,

The standard way to install crypto is to go with the "(S)hell" option at boot.

In the MBR days it would be "fdisk -i sd0", now should be with the GPT option 
on so "fdisk -ig sd0".

Doing this, importantly, no "EFI Sys" partition is created.

Am I supposed to know how to add that one, or is there some magic argument to 
fdisk, or some system tool, that I missed, that would do that for me?


Then, disklabel -E sd0 to add a RAID, bioctl it going, and proceed with 
/install .


In my installation, sd0 is the physical harddrive, sd1 is the installation 
media, and sd2 is the softraid.

In the installation, I instruct the installer script that I want to install on 
sd2 .

Its first question is how I want its non-BSD partitioning to be - that is 
"(M)BR, (G)PT or (E)dit". (E)dit takes you into fdisk , pointless.

(G)PT seems to be the right thing, but.. it creates an "EFI Sys" partition 
*within the logical softraid disk* and not on the root partition - obviously.

Therefore I naturally remove the EFI Sys partition (offset 64, size 960, fstype 
MSDOS), which got BSD disklabel designation "i".

I find this behavior of how (G)PT works quirky, though maybe the 
softraid-disklabel logics and the GPT partitioning logics are so deeply 
intertwined, that it still makes sense to run the ordinary GPT initialization 
also on softraids, and then just let the user remove the redundant EFI Sys 
partition that is created within the softraid. Or? Quirky anyhow. Did I 
understand this right?


At the end of the installer, the installer tells me there is no boot partition 
so therefore couldn't install boot code so therefore boot will fail. And boot 
does fail.


Your instruction for how to get this going would be much appreciated.

Thanks!
Tinker

Re: uefi boot

[YASUOKA Masahiko]

Hi,

On Tue, 12 Jul 2016 21:17:20 -0300
Friedrich Locke <friedrich.lo...@gmail.com> wrote:
> I wonder if that's possible to boot obsd amd64 5.9 CD on a computer whose
> bios is setted to boot UEFI secure mode off.

5.9 CD doesn't support UEFI boot.  If the computer doesn't have legacy
mode BIOS, you need to use an USB memory stick and install59.fs for
this moment.

--yasuoka

uefi boot

[Friedrich Locke]

Hi folks!

I wonder if that's possible to boot obsd amd64 5.9 CD on a computer whose
bios is setted to boot UEFI secure mode off.

Thanks a lot.

Re: UEFI boot-looping on Asus M5A97 LE R2.0 motherboard

[Joe Gidi]

[big snip]
>> The newly installed system boots successfully, but then it seems to fail
>> to initialize video properly at the end of the boot process. My monitor
>> goes into an endless cycle of trying to sync up. I can ssh in and see
>> this
>> in /var/log/messages:
>>
>> Nov 26 11:45:55 opteron /bsd: root on sd0a (ef051b8fc18f2fbe.a) swap on
>> sd0b dump on sd0b
>> Nov 26 11:45:55 opteron /bsd: ttm_bo_ioremap bus_space_map failed
>> Nov 26 11:45:55 opteron /bsd: drm:pid0:evergreen_init *ERROR* disabling
>> GPU acceleration
>> Nov 26 11:45:55 opteron /bsd: drm:pid0:radeon_bo_unpin *WARNING*
>> 0x802922c0 unpin not necessary
>> Nov 26 11:45:55 opteron /bsd: drm:pid0:radeon_bo_unpin *WARNING*
>> 0x802922c0 unpin not necessary
>> Nov 26 11:45:55 opteron /bsd: ttm_bo_ioremap bus_space_map failed
>> Nov 26 11:45:55 opteron /bsd: error: [drm:pid0:radeonfb_create] *ERROR*
>> failed to create fbcon object -12
>> Nov 26 11:45:55 opteron ntpd[27846]: /var/db/ntpd.drift is empty
>> Nov 26 11:45:55 opteron savecore: no core dump
>>
>> My video card is:
>> radeondrm0 at pci1 dev 0 function 0 "ATI Radeon HD 5450" rev 0x00
>> drm0 at radeondrm0
>> radeondrm0: msi
>>
>> And the radeondrm-firmware-20150927 package is installed.
>>
>> Thanks again for all your help.

I had a few more minutes to play around with this today. Disabling
radeondrm in ukc results in a usable console. Here's a dmesg:

OpenBSD 5.8-current (GENERIC.MP) #1666: Thu Nov 26 00:22:53 MST 2015
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 8470441984 (8078MB)
avail mem = 8209608704 (7829MB)
User Kernel Config
UKC> disable radeondrm
214 radeondrm* disabled
UKC> quit
Continuing...
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xbc41b018 (58 entries)
bios0: vendor American Megatrends Inc. version "2601" date 03/24/2015
bios0: ASUSTeK COMPUTER INC. M5A97 LE R2.0
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP APIC FPDT MCFG HPET SSDT BGRT
acpi0: wakeup devices SBAZ(S4) PS2K(S3) PS2M(S3) UAR1(S4) P0PC(S4)
UHC1(S4) UHC2(S4) UHC4(S4) UHC6(S4) UHC7(S4) PC02(S4) PC03(S4) PC04(S4)
PC05(S4) PC06(S4) PC07(S4) [...]
acpitimer0 at acpi0: 3579545 Hz, 32 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 16 (boot processor)
cpu0: AMD Opteron(tm) Processor 3350 HE, 2809.74 MHz
cpu0:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS
H,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,POPCN
T,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR
8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,XOP,SKINIT,WDT,FMA4,NODEID,TBM,TOPEXT,ITSC,
BMI1
cpu0: 64KB 64b/line 2-way I-cache, 16KB 64b/line 4-way D-cache, 2MB
64b/line 16-way L2 cache, 8MB 64b/line 64-way L3 cache
cpu0: ITLB 48 4KB entries fully associative, 24 4MB entries fully associative
cpu0: DTLB 64 4KB entries fully associative, 64 4MB entries fully associative
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 200MHz
cpu0: mwait min=64, max=64, IBE
cpu1 at mainbus0: apid 17 (application processor)
cpu1: AMD Opteron(tm) Processor 3350 HE, 2809.37 MHz
cpu1:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS
H,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,POPCN
T,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR
8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,XOP,SKINIT,WDT,FMA4,NODEID,TBM,TOPEXT,ITSC,
BMI1
cpu1: 64KB 64b/line 2-way I-cache, 16KB 64b/line 4-way D-cache, 2MB
64b/line 16-way L2 cache, 8MB 64b/line 64-way L3 cache
cpu1: ITLB 48 4KB entries fully associative, 24 4MB entries fully associative
cpu1: DTLB 64 4KB entries fully associative, 64 4MB entries fully associative
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 18 (application processor)
cpu2: AMD Opteron(tm) Processor 3350 HE, 2809.37 MHz
cpu2:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS
H,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,POPCN
T,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR
8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,XOP,SKINIT,WDT,FMA4,NODEID,TBM,TOPEXT,ITSC,
BMI1
cpu2: 64KB 64b/line 2-way I-cache, 16KB 64b/line 4-way D-cache, 2MB
64b/line 16-way L2 cache, 8MB 64b/line 64-way L3 cache
cpu2: ITLB 48 4KB entries fully associative, 24 4MB entries fully associative
cpu2: DTLB 64 4KB entries fully associative, 64 4MB entries fully associative
cpu2: smt 0, core 2, package 0
cpu3 at mainbus0: apid 19 (application processor)
cpu3: AMD Opteron(tm) Processor 3350 HE, 2809.37 MHz
cpu3:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS
H,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,POPCN
T,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR

Re: UEFI boot-looping on Asus M5A97 LE R2.0 motherboard

[Jonathan Gray]

On Thu, Nov 26, 2015 at 11:51:03AM -0500, Joe Gidi wrote:
> The newly installed system boots successfully, but then it seems to fail
> to initialize video properly at the end of the boot process. My monitor
> goes into an endless cycle of trying to sync up. I can ssh in and see this
> in /var/log/messages:
> 
> Nov 26 11:45:55 opteron /bsd: root on sd0a (ef051b8fc18f2fbe.a) swap on
> sd0b dump on sd0b
> Nov 26 11:45:55 opteron /bsd: ttm_bo_ioremap bus_space_map failed
> Nov 26 11:45:55 opteron /bsd: drm:pid0:evergreen_init *ERROR* disabling
> GPU acceleration
> Nov 26 11:45:55 opteron /bsd: drm:pid0:radeon_bo_unpin *WARNING*
> 0x802922c0 unpin not necessary
> Nov 26 11:45:55 opteron /bsd: drm:pid0:radeon_bo_unpin *WARNING*
> 0x802922c0 unpin not necessary
> Nov 26 11:45:55 opteron /bsd: ttm_bo_ioremap bus_space_map failed
> Nov 26 11:45:55 opteron /bsd: error: [drm:pid0:radeonfb_create] *ERROR*
> failed to create fbcon object -12
> Nov 26 11:45:55 opteron ntpd[27846]: /var/db/ntpd.drift is empty
> Nov 26 11:45:55 opteron savecore: no core dump
> 
> My video card is:
> radeondrm0 at pci1 dev 0 function 0 "ATI Radeon HD 5450" rev 0x00
> drm0 at radeondrm0
> radeondrm0: msi
> 
> And the radeondrm-firmware-20150927 package is installed.

Can you include a full dmesg when booted via uefi with radeondrm
still enabled? pcidump -v output would be helpful as well.

We may have to read the video bios out of the acpi VFCT table
when booting via efi and the radeondrm code doesn't do that currently.

Re: UEFI boot-looping on Asus M5A97 LE R2.0 motherboard

[Joe Gidi]

On Thu, November 26, 2015 10:13 pm, Jonathan Gray wrote:
> Can you include a full dmesg when booted via uefi with radeondrm
> still enabled? pcidump -v output would be helpful as well.
>
> We may have to read the video bios out of the acpi VFCT table
> when booting via efi and the radeondrm code doesn't do that currently.

Sure, here you go:

OpenBSD 5.8-current (GENERIC.MP) #1666: Thu Nov 26 00:22:53 MST 2015
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 8470441984 (8078MB)
avail mem = 8209608704 (7829MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xbc41b018 (58 entries)
bios0: vendor American Megatrends Inc. version "2601" date 03/24/2015
bios0: ASUSTeK COMPUTER INC. M5A97 LE R2.0
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP APIC FPDT MCFG HPET SSDT BGRT
acpi0: wakeup devices SBAZ(S4) PS2K(S3) PS2M(S3) UAR1(S4) P0PC(S4)
UHC1(S4) UHC2(S4) UHC4(S4) UHC6(S4) UHC7(S4) PC02(S4) PC03(S4) PC04(S4)
PC05(S4) PC06(S4) PC07(S4) [...]
acpitimer0 at acpi0: 3579545 Hz, 32 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 16 (boot processor)
cpu0: AMD Opteron(tm) Processor 3350 HE, 2809.72 MHz
cpu0:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS
H,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,POPCN
T,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR
8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,XOP,SKINIT,WDT,FMA4,NODEID,TBM,TOPEXT,ITSC,
BMI1
cpu0: 64KB 64b/line 2-way I-cache, 16KB 64b/line 4-way D-cache, 2MB
64b/line 16-way L2 cache, 8MB 64b/line 64-way L3 cache
cpu0: ITLB 48 4KB entries fully associative, 24 4MB entries fully associative
cpu0: DTLB 64 4KB entries fully associative, 64 4MB entries fully associative
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 200MHz
cpu0: mwait min=64, max=64, IBE
cpu1 at mainbus0: apid 17 (application processor)
cpu1: AMD Opteron(tm) Processor 3350 HE, 2809.37 MHz
cpu1:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS
H,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,POPCN
T,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR
8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,XOP,SKINIT,WDT,FMA4,NODEID,TBM,TOPEXT,ITSC,
BMI1
cpu1: 64KB 64b/line 2-way I-cache, 16KB 64b/line 4-way D-cache, 2MB
64b/line 16-way L2 cache, 8MB 64b/line 64-way L3 cache
cpu1: ITLB 48 4KB entries fully associative, 24 4MB entries fully associative
cpu1: DTLB 64 4KB entries fully associative, 64 4MB entries fully associative
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 18 (application processor)
cpu2: AMD Opteron(tm) Processor 3350 HE, 2809.37 MHz
cpu2:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS
H,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,POPCN
T,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR
8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,XOP,SKINIT,WDT,FMA4,NODEID,TBM,TOPEXT,ITSC,
BMI1
cpu2: 64KB 64b/line 2-way I-cache, 16KB 64b/line 4-way D-cache, 2MB
64b/line 16-way L2 cache, 8MB 64b/line 64-way L3 cache
cpu2: ITLB 48 4KB entries fully associative, 24 4MB entries fully associative
cpu2: DTLB 64 4KB entries fully associative, 64 4MB entries fully associative
cpu2: smt 0, core 2, package 0
cpu3 at mainbus0: apid 19 (application processor)
cpu3: AMD Opteron(tm) Processor 3350 HE, 2809.37 MHz
cpu3:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS
H,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,POPCN
T,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR
8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,XOP,SKINIT,WDT,FMA4,NODEID,TBM,TOPEXT,ITSC,
BMI1
cpu3: 64KB 64b/line 2-way I-cache, 16KB 64b/line 4-way D-cache, 2MB
64b/line 16-way L2 cache, 8MB 64b/line 64-way L3 cache
cpu3: ITLB 48 4KB entries fully associative, 24 4MB entries fully associative
cpu3: DTLB 64 4KB entries fully associative, 64 4MB entries fully associative
cpu3: smt 0, core 3, package 0
ioapic0 at mainbus0: apid 5 pa 0xfec0, version 21, 24 pins
ioapic1 at mainbus0: apid 6 pa 0xfec2, version 21, 32 pins
acpimcfg0 at acpi0 addr 0xe000, bus 0-255
acpihpet0 at acpi0: 14318180 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 4 (P0PC)
acpiprt2 at acpi0: bus 1 (PC02)
acpiprt3 at acpi0: bus -1 (PC03)
acpiprt4 at acpi0: bus 2 (PC04)
acpiprt5 at acpi0: bus -1 (PC05)
acpiprt6 at acpi0: bus -1 (PC06)
acpiprt7 at acpi0: bus 3 (PC07)
acpiprt8 at acpi0: bus -1 (PC09)
acpiprt9 at acpi0: bus -1 (PC0A)
acpiprt10 at acpi0: bus -1 (PC0B)
acpiprt11 at acpi0: bus -1 (PC0C)
acpiprt12 at acpi0: bus -1 (PC0D)
acpiprt13 at acpi0: bus -1 (PE20)
acpiprt14 at acpi0: bus -1 (PE21)
acpiprt15 at acpi0: bus -1 (PE22)
acpiprt16 at acpi0: bus -1 (PE23)
acpiec0 

Re: UEFI boot-looping on Asus M5A97 LE R2.0 motherboard

[YASUOKA Masahiko]

On Wed, 11 Nov 2015 15:33:06 -0500
"Joe Gidi"  wrote:
> I recently installed a UEFI-capable Asus M5A97 LE R2.0 motherboard in one
> of my systems and tried to boot the November 11th amd64 miniroot58.fs
> image to test UEFI booting. I get to the bootloader, but it appears to
> fail while loading the kernel and goes into a reboot loop. Here's
> everything I see on screen before it reboots:
> 
> probing: pc0 mem[640K 2984M 4M 48K 5103M]
> disk: hd0 hd1 hd2*
>>> OpenBSD/amd64 EFIBOOT 3.29
> boot>
> cannot open hd0a:/etc/random.seed: No such file or directory
> booting hd0a:/bsd:3273216+1394144+2409472+0+569344=0x74d238

I'd like to figure out where the efiboot is stopping.  Can you replace
the BOOTX64.EFI in the miniroot58.fs and check the output?

compiled version:

  http://yasuoka.net/~yasuoka/BOOTX64.EFI

diff:

Index: efiboot/efiboot.c
===
RCS file: /disk/cvs/openbsd/src/sys/arch/amd64/stand/efiboot/efiboot.c,v
retrieving revision 1.9
diff -u -p -r1.9 efiboot.c
--- efiboot/efiboot.c   8 Nov 2015 00:17:29 -   1.9
+++ efiboot/efiboot.c   26 Nov 2015 09:15:17 -
@@ -569,7 +569,7 @@ efi_makebootargs(void)
 void
 _rtt(void)
 {
-#ifdef EFI_DEBUG
+#if defined(EFI_DEBUG) || 1
printf("Hit any key to reboot\n");
efi_cons_getc(0);
 #endif
Index: libsa/exec_i386.c
===
RCS file: /disk/cvs/openbsd/src/sys/arch/amd64/stand/libsa/exec_i386.c,v
retrieving revision 1.15
diff -u -p -r1.15 exec_i386.c
--- libsa/exec_i386.c   5 Oct 2015 22:59:39 -   1.15
+++ libsa/exec_i386.c   26 Nov 2015 09:15:17 -
@@ -123,6 +123,7 @@ run_loadfile(u_long *marks, int howto)
 * This code may be used both for 64bit and 32bit.  Make sure the
 * bootarg is 32bit always on even on amd64.
 */
+   printf("%s() calling makebootargs32()\n", __func__);
 #ifdef __amd64__
makebootargs32(av, );
 #else
@@ -134,6 +135,10 @@ run_loadfile(u_long *marks, int howto)
printf("entry point at 0x%lx [%x, %x, %x, %x]\n", entry,
((int *)entry)[0], ((int *)entry)[1],
((int *)entry)[2], ((int *)entry)[3]);
+
+   printf("Hit any key to continue\n");
+   efi_cons_getc(0);
+
 #ifndef EFIBOOT
/* stack and the gung is ok at this point, so, no need for asm setup */
(*(startfuncp)entry)(howto, bootdev, BOOTARG_APIVER, marks[MARK_END],

Re: UEFI boot-looping on Asus M5A97 LE R2.0 motherboard

[Joe Gidi]

On Thu, November 26, 2015 5:20 am, YASUOKA Masahiko wrote:
> On Wed, 11 Nov 2015 15:33:06 -0500
> "Joe Gidi"  wrote:
>> I recently installed a UEFI-capable Asus M5A97 LE R2.0 motherboard in
>> one
>> of my systems and tried to boot the November 11th amd64 miniroot58.fs
>> image to test UEFI booting. I get to the bootloader, but it appears to
>> fail while loading the kernel and goes into a reboot loop. Here's
>> everything I see on screen before it reboots:
>>
>> probing: pc0 mem[640K 2984M 4M 48K 5103M]
>> disk: hd0 hd1 hd2*
 OpenBSD/amd64 EFIBOOT 3.29
>> boot>
>> cannot open hd0a:/etc/random.seed: No such file or directory
>> booting hd0a:/bsd:3273216+1394144+2409472+0+569344=0x74d238
>
> I'd like to figure out where the efiboot is stopping.  Can you replace
> the BOOTX64.EFI in the miniroot58.fs and check the output?

Sure, I now get these two lines after the 'booting' line:

GOP setmode failed(7)
Hit any key to reboot

Please let me know if I can do any further testing, and thank you for
looking into this.

Thanks,

--
Joe Gidi
j...@entropicblur.com

"You cannot buy skill." -- Ross Seyfried

Re: UEFI boot-looping on Asus M5A97 LE R2.0 motherboard

[YASUOKA Masahiko]

Hi,

On Thu, 26 Nov 2015 09:57:12 -0500
"Joe Gidi"  wrote:
> On Thu, November 26, 2015 5:20 am, YASUOKA Masahiko wrote:
>> On Wed, 11 Nov 2015 15:33:06 -0500
>> "Joe Gidi"  wrote:
>>> I recently installed a UEFI-capable Asus M5A97 LE R2.0 motherboard in
>>> one
>>> of my systems and tried to boot the November 11th amd64 miniroot58.fs
>>> image to test UEFI booting. I get to the bootloader, but it appears to
>>> fail while loading the kernel and goes into a reboot loop. Here's
>>> everything I see on screen before it reboots:
>>>
>>> probing: pc0 mem[640K 2984M 4M 48K 5103M]
>>> disk: hd0 hd1 hd2*
> OpenBSD/amd64 EFIBOOT 3.29
>>> boot>
>>> cannot open hd0a:/etc/random.seed: No such file or directory
>>> booting hd0a:/bsd:3273216+1394144+2409472+0+569344=0x74d238
>>
>> I'd like to figure out where the efiboot is stopping.  Can you replace
>> the BOOTX64.EFI in the miniroot58.fs and check the output?
> 
> Sure, I now get these two lines after the 'booting' line:
> 
> GOP setmode failed(7)
> Hit any key to reboot

The bootloader changs the video resolution before start the kernel.
It seems to fail.  "GOP", Graphic Output Protocol, returns an error.
7 means EFI_DEVICE_ERROR.

> Please let me know if I can do any further testing, and thank you for
> looking into this.

Can you provide the result of "machine video" and try to change the
video mode to the best and some others.


And also please try the diff below.

compiled:

  http://yasuoka.net/~yasuoka/BOOTX64.EFI (updated)

diff:

Index: efiboot/efiboot.c
===
RCS file: /cvs/src/sys/arch/amd64/stand/efiboot/efiboot.c,v
retrieving revision 1.9
diff -u -p -r1.9 efiboot.c
--- efiboot/efiboot.c   8 Nov 2015 00:17:29 -   1.9
+++ efiboot/efiboot.c   26 Nov 2015 15:57:56 -
@@ -528,8 +528,10 @@ efi_makebootargs(void)
}
if (bestmode >= 0) {
status = EFI_CALL(gop->SetMode, gop, bestmode);
+#if 0
if (EFI_ERROR(status))
panic("GOP setmode failed(%d)", status);
+#endif
}
 
gopi = gop->Mode->Info;
@@ -569,7 +571,7 @@ efi_makebootargs(void)
 void
 _rtt(void)
 {
-#ifdef EFI_DEBUG
+#if defined(EFI_DEBUG) || 1
printf("Hit any key to reboot\n");
efi_cons_getc(0);
 #endif
Index: libsa/exec_i386.c
===
RCS file: /cvs/src/sys/arch/amd64/stand/libsa/exec_i386.c,v
retrieving revision 1.16
diff -u -p -r1.16 exec_i386.c
--- libsa/exec_i386.c   26 Nov 2015 10:52:40 -  1.16
+++ libsa/exec_i386.c   26 Nov 2015 15:57:56 -
@@ -123,6 +123,7 @@ run_loadfile(u_long *marks, int howto)
 * This code may be used both for 64bit and 32bit.  Make sure the
 * bootarg is 32bit always on even on amd64.
 */
+   printf("%s() calling makebootargs32()\n", __func__);
 #ifdef __amd64__
makebootargs32(av, );
 #else
@@ -134,6 +135,10 @@ run_loadfile(u_long *marks, int howto)
printf("entry point at 0x%lx [%x, %x, %x, %x]\n", entry,
((int *)entry)[0], ((int *)entry)[1],
((int *)entry)[2], ((int *)entry)[3]);
+
+   printf("Hit any key to continue\n");
+   efi_cons_getc(0);
+
 #ifndef EFIBOOT
/* stack and the gung is ok at this point, so, no need for asm setup */
(*(startfuncp)entry)(howto, bootdev, BOOTARG_APIVER, marks[MARK_END],

Re: UEFI boot-looping on Asus M5A97 LE R2.0 motherboard

[Joe Gidi]

On Thu, November 26, 2015 10:59 am, YASUOKA Masahiko wrote:
> Hi,
>
> On Thu, 26 Nov 2015 09:57:12 -0500
> "Joe Gidi"  wrote:
>> On Thu, November 26, 2015 5:20 am, YASUOKA Masahiko wrote:
>>> On Wed, 11 Nov 2015 15:33:06 -0500
>>> "Joe Gidi"  wrote:
 I recently installed a UEFI-capable Asus M5A97 LE R2.0 motherboard in
 one
 of my systems and tried to boot the November 11th amd64 miniroot58.fs
 image to test UEFI booting. I get to the bootloader, but it appears to
 fail while loading the kernel and goes into a reboot loop. Here's
 everything I see on screen before it reboots:

 probing: pc0 mem[640K 2984M 4M 48K 5103M]
 disk: hd0 hd1 hd2*
>> OpenBSD/amd64 EFIBOOT 3.29
 boot>
 cannot open hd0a:/etc/random.seed: No such file or directory
 booting hd0a:/bsd:3273216+1394144+2409472+0+569344=0x74d238
>>>
>>> I'd like to figure out where the efiboot is stopping.  Can you replace
>>> the BOOTX64.EFI in the miniroot58.fs and check the output?
>>
>> Sure, I now get these two lines after the 'booting' line:
>>
>> GOP setmode failed(7)
>> Hit any key to reboot
>
> The bootloader changs the video resolution before start the kernel.
> It seems to fail.  "GOP", Graphic Output Protocol, returns an error.
> 7 means EFI_DEVICE_ERROR.
>
>> Please let me know if I can do any further testing, and thank you for
>> looking into this.
>
> Can you provide the result of "machine video" and try to change the
> video mode to the best and some others.
>
>
> And also please try the diff below.

This appears to fix it. I did not have to change the video mode. Output
from the bootloader:

boot> machine video
Mode 0: 80 x 25
Mode 1: 80 x 50
Mode 2: 100 x 31

Current Mode = 2
boot>
cannot open hd0a:/etc/random.seed: No such file or directory
booting hd0a:/bsd: 3263848+1395072+2409472+0+569344=74a238
run_loadfile() calling makebootargs32()
entry point at 0xf000160 [7205c766, 3404, 24448b12, 680a304]
Hit any key to continue

After hitting any key, the kernel loads successfully and takes me into the
installer.

Thanks!

--
Joe Gidi
j...@entropicblur.com

"You cannot buy skill." -- Ross Seyfried

Re: UEFI boot-looping on Asus M5A97 LE R2.0 motherboard

[YASUOKA Masahiko]

On Thu, 26 Nov 2015 11:10:33 -0500
"Joe Gidi"  wrote:
> On Thu, November 26, 2015 10:59 am, YASUOKA Masahiko wrote:
>> On Thu, 26 Nov 2015 09:57:12 -0500
>> "Joe Gidi"  wrote:
>>> On Thu, November 26, 2015 5:20 am, YASUOKA Masahiko wrote:
 On Wed, 11 Nov 2015 15:33:06 -0500
 "Joe Gidi"  wrote:
> I recently installed a UEFI-capable Asus M5A97 LE R2.0 motherboard in
> one
> of my systems and tried to boot the November 11th amd64 miniroot58.fs
> image to test UEFI booting. I get to the bootloader, but it appears to
> fail while loading the kernel and goes into a reboot loop. Here's
> everything I see on screen before it reboots:
>
> probing: pc0 mem[640K 2984M 4M 48K 5103M]
> disk: hd0 hd1 hd2*
>>> OpenBSD/amd64 EFIBOOT 3.29
> boot>
> cannot open hd0a:/etc/random.seed: No such file or directory
> booting hd0a:/bsd:3273216+1394144+2409472+0+569344=0x74d238

 I'd like to figure out where the efiboot is stopping.  Can you replace
 the BOOTX64.EFI in the miniroot58.fs and check the output?
>>>
>>> Sure, I now get these two lines after the 'booting' line:
>>>
>>> GOP setmode failed(7)
>>> Hit any key to reboot
>>
>> The bootloader changs the video resolution before start the kernel.
>> It seems to fail.  "GOP", Graphic Output Protocol, returns an error.
>> 7 means EFI_DEVICE_ERROR.
>>
>>> Please let me know if I can do any further testing, and thank you for
>>> looking into this.
>>
>> Can you provide the result of "machine video" and try to change the
>> video mode to the best and some others.
>>
>>
>> And also please try the diff below.
> 
> This appears to fix it. I did not have to change the video mode. Output
> from the bootloader:

UEFI seems to have refused changing the video mode since it
isn't to change.

Can you try this again?  (I'd like to verify whether the assumption
above is correct).

compiled:

  http://yasuoka.net/~yasuoka/BOOTX64.EFI (updated)

diff:

Index: efiboot/efiboot.c
===
RCS file: /cvs/src/sys/arch/amd64/stand/efiboot/efiboot.c,v
retrieving revision 1.9
diff -u -p -r1.9 efiboot.c
--- efiboot/efiboot.c   8 Nov 2015 00:17:29 -   1.9
+++ efiboot/efiboot.c   26 Nov 2015 16:21:23 -
@@ -526,10 +526,10 @@ efi_makebootargs(void)
bestsiz = gopsiz;
}
}
-   if (bestmode >= 0) {
+   if (bestmode >= 0 && conout->Mode->Mode != bestmode) {
status = EFI_CALL(gop->SetMode, gop, bestmode);
if (EFI_ERROR(status))
-   panic("GOP setmode failed(%d)", status);
+   printf("GOP setmode failed(%d)\n", status);
}
 
gopi = gop->Mode->Info;

--yasuoka

Re: UEFI boot-looping on Asus M5A97 LE R2.0 motherboard

[Joe Gidi]

On Thu, November 26, 2015 11:27 am, YASUOKA Masahiko wrote:
> On Thu, 26 Nov 2015 11:10:33 -0500
> "Joe Gidi"  wrote:
>> On Thu, November 26, 2015 10:59 am, YASUOKA Masahiko wrote:
>>> On Thu, 26 Nov 2015 09:57:12 -0500
>>> "Joe Gidi"  wrote:
 On Thu, November 26, 2015 5:20 am, YASUOKA Masahiko wrote:
> On Wed, 11 Nov 2015 15:33:06 -0500
> "Joe Gidi"  wrote:
>> I recently installed a UEFI-capable Asus M5A97 LE R2.0 motherboard
>> in
>> one
>> of my systems and tried to boot the November 11th amd64
>> miniroot58.fs
>> image to test UEFI booting. I get to the bootloader, but it appears
>> to
>> fail while loading the kernel and goes into a reboot loop. Here's
>> everything I see on screen before it reboots:
>>
>> probing: pc0 mem[640K 2984M 4M 48K 5103M]
>> disk: hd0 hd1 hd2*
 OpenBSD/amd64 EFIBOOT 3.29
>> boot>
>> cannot open hd0a:/etc/random.seed: No such file or directory
>> booting hd0a:/bsd:3273216+1394144+2409472+0+569344=0x74d238
>
> I'd like to figure out where the efiboot is stopping.  Can you
> replace
> the BOOTX64.EFI in the miniroot58.fs and check the output?

 Sure, I now get these two lines after the 'booting' line:

 GOP setmode failed(7)
 Hit any key to reboot
>>>
>>> The bootloader changs the video resolution before start the kernel.
>>> It seems to fail.  "GOP", Graphic Output Protocol, returns an error.
>>> 7 means EFI_DEVICE_ERROR.
>>>
 Please let me know if I can do any further testing, and thank you for
 looking into this.
>>>
>>> Can you provide the result of "machine video" and try to change the
>>> video mode to the best and some others.
>>>
>>>
>>> And also please try the diff below.
>>
>> This appears to fix it. I did not have to change the video mode. Output
>> from the bootloader:
>
> UEFI seems to have refused changing the video mode since it
> isn't to change.
>
> Can you try this again?  (I'd like to verify whether the assumption
> above is correct).

Is there something specific you want me to test?

With the latest bootloader you provided, the 'machine video' output is
still the same:

boot> machine video
Mode 0: 80 x 25
Mode 1: 80 x 50
Mode 2: 100 x 31

Current Mode = 2

I am able to boot successfully from miniroot.fs and run through a UEFI
install as described by jasper@ here:
https://blog.jasper.la/openbsd-uefi-bootloader-howto/

The only thing I did differently from his blog post was to use the
bootloader you provided, rather than copying in the one from
/mnt/usr/mdec.

The newly installed system boots successfully, but then it seems to fail
to initialize video properly at the end of the boot process. My monitor
goes into an endless cycle of trying to sync up. I can ssh in and see this
in /var/log/messages:

Nov 26 11:45:55 opteron /bsd: root on sd0a (ef051b8fc18f2fbe.a) swap on
sd0b dump on sd0b
Nov 26 11:45:55 opteron /bsd: ttm_bo_ioremap bus_space_map failed
Nov 26 11:45:55 opteron /bsd: drm:pid0:evergreen_init *ERROR* disabling
GPU acceleration
Nov 26 11:45:55 opteron /bsd: drm:pid0:radeon_bo_unpin *WARNING*
0x802922c0 unpin not necessary
Nov 26 11:45:55 opteron /bsd: drm:pid0:radeon_bo_unpin *WARNING*
0x802922c0 unpin not necessary
Nov 26 11:45:55 opteron /bsd: ttm_bo_ioremap bus_space_map failed
Nov 26 11:45:55 opteron /bsd: error: [drm:pid0:radeonfb_create] *ERROR*
failed to create fbcon object -12
Nov 26 11:45:55 opteron ntpd[27846]: /var/db/ntpd.drift is empty
Nov 26 11:45:55 opteron savecore: no core dump

My video card is:
radeondrm0 at pci1 dev 0 function 0 "ATI Radeon HD 5450" rev 0x00
drm0 at radeondrm0
radeondrm0: msi

And the radeondrm-firmware-20150927 package is installed.

Thanks again for all your help.

--
Joe Gidi
j...@entropicblur.com

"You cannot buy skill." -- Ross Seyfried

Re: UEFI boot-looping on Asus M5A97 LE R2.0 motherboard

[YASUOKA Masahiko]

On Thu, 26 Nov 2015 11:51:03 -0500
"Joe Gidi"  wrote:
> On Thu, November 26, 2015 11:27 am, YASUOKA Masahiko wrote:
>> On Thu, 26 Nov 2015 11:10:33 -0500
>> "Joe Gidi"  wrote:
>>> On Thu, November 26, 2015 10:59 am, YASUOKA Masahiko wrote:
 On Thu, 26 Nov 2015 09:57:12 -0500
 "Joe Gidi"  wrote:
> On Thu, November 26, 2015 5:20 am, YASUOKA Masahiko wrote:
>> On Wed, 11 Nov 2015 15:33:06 -0500
>> "Joe Gidi"  wrote:
>>> I recently installed a UEFI-capable Asus M5A97 LE R2.0 motherboard
>>> in
>>> one
>>> of my systems and tried to boot the November 11th amd64
>>> miniroot58.fs
>>> image to test UEFI booting. I get to the bootloader, but it appears
>>> to
>>> fail while loading the kernel and goes into a reboot loop. Here's
>>> everything I see on screen before it reboots:
>>>
>>> probing: pc0 mem[640K 2984M 4M 48K 5103M]
>>> disk: hd0 hd1 hd2*
> OpenBSD/amd64 EFIBOOT 3.29
>>> boot>
>>> cannot open hd0a:/etc/random.seed: No such file or directory
>>> booting hd0a:/bsd:3273216+1394144+2409472+0+569344=0x74d238
>>
>> I'd like to figure out where the efiboot is stopping.  Can you
>> replace
>> the BOOTX64.EFI in the miniroot58.fs and check the output?
>
> Sure, I now get these two lines after the 'booting' line:
>
> GOP setmode failed(7)
> Hit any key to reboot

 The bootloader changs the video resolution before start the kernel.
 It seems to fail.  "GOP", Graphic Output Protocol, returns an error.
 7 means EFI_DEVICE_ERROR.

> Please let me know if I can do any further testing, and thank you for
> looking into this.

 Can you provide the result of "machine video" and try to change the
 video mode to the best and some others.


 And also please try the diff below.
>>>
>>> This appears to fix it. I did not have to change the video mode. Output
>>> from the bootloader:
>>
>> UEFI seems to have refused changing the video mode since it
>> isn't to change.
>>
>> Can you try this again?  (I'd like to verify whether the assumption
>> above is correct).
> 
> Is there something specific you want me to test?

I had wanted to know the latest one can boot successfuly.
Since I'd like to fix it on the tree.  Thanks for your reports.

> With the latest bootloader you provided, the 'machine video' output is
> still the same:
> 
> boot> machine video
> Mode 0: 80 x 25
> Mode 1: 80 x 50
> Mode 2: 100 x 31
> 
> Current Mode = 2
> 
> I am able to boot successfully from miniroot.fs and run through a UEFI
> install as described by jasper@ here:
> https://blog.jasper.la/openbsd-uefi-bootloader-howto/
> 
> The only thing I did differently from his blog post was to use the
> bootloader you provided, rather than copying in the one from
> /mnt/usr/mdec.
> 
> The newly installed system boots successfully, but then it seems to fail
> to initialize video properly at the end of the boot process. My monitor
> goes into an endless cycle of trying to sync up. I can ssh in and see this
> in /var/log/messages:
> 
> Nov 26 11:45:55 opteron /bsd: root on sd0a (ef051b8fc18f2fbe.a) swap on
> sd0b dump on sd0b
> Nov 26 11:45:55 opteron /bsd: ttm_bo_ioremap bus_space_map failed
> Nov 26 11:45:55 opteron /bsd: drm:pid0:evergreen_init *ERROR* disabling
> GPU acceleration
> Nov 26 11:45:55 opteron /bsd: drm:pid0:radeon_bo_unpin *WARNING*
> 0x802922c0 unpin not necessary
> Nov 26 11:45:55 opteron /bsd: drm:pid0:radeon_bo_unpin *WARNING*
> 0x802922c0 unpin not necessary
> Nov 26 11:45:55 opteron /bsd: ttm_bo_ioremap bus_space_map failed
> Nov 26 11:45:55 opteron /bsd: error: [drm:pid0:radeonfb_create] *ERROR*
> failed to create fbcon object -12
> Nov 26 11:45:55 opteron ntpd[27846]: /var/db/ntpd.drift is empty
> Nov 26 11:45:55 opteron savecore: no core dump
> 
> My video card is:
> radeondrm0 at pci1 dev 0 function 0 "ATI Radeon HD 5450" rev 0x00
> drm0 at radeondrm0
> radeondrm0: msi
> 
> And the radeondrm-firmware-20150927 package is installed.
> 
> Thanks again for all your help.
> 
> --
> Joe Gidi
> j...@entropicblur.com
> 
> "You cannot buy skill." -- Ross Seyfried

UEFI boot-looping on Asus M5A97 LE R2.0 motherboard

[Joe Gidi]

Hello,

I recently installed a UEFI-capable Asus M5A97 LE R2.0 motherboard in one
of my systems and tried to boot the November 11th amd64 miniroot58.fs
image to test UEFI booting. I get to the bootloader, but it appears to
fail while loading the kernel and goes into a reboot loop. Here's
everything I see on screen before it reboots:

probing: pc0 mem[640K 2984M 4M 48K 5103M]
disk: hd0 hd1 hd2*
>> OpenBSD/amd64 EFIBOOT 3.29
boot>
cannot open hd0a:/etc/random.seed: No such file or directory
booting hd0a:/bsd:3273216+1394144+2409472+0+569344=0x74d238

This is with the latest available UEFI version for this board (version
2601). All BIOS/UEFI options are default values except for setting the
Secure Boot option to "Other OS". I am able to boot normally in BIOS mode.
Full dmesg of a regular BIOS-mode install follows at the end of this
email.

I understand that UEFI support is still a work in progress, so if there's
any way I can provide further info or test new code, please let me know.

OpenBSD 5.8-current (GENERIC.MP) #1591: Wed Nov 11 09:38:33 MST 2015
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 8470441984 (8078MB)
avail mem = 8209600512 (7829MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xbc41b018 (58 entries)
bios0: vendor American Megatrends Inc. version "2601" date 03/24/2015
bios0: ASUSTeK COMPUTER INC. M5A97 LE R2.0
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP APIC FPDT MCFG HPET SSDT BGRT
acpi0: wakeup devices SBAZ(S4) PS2K(S3) PS2M(S3) UAR1(S4) P0PC(S4)
UHC1(S4) UHC2(S4) UHC4(S4) UHC6(S4) UHC7(S4) PC02(S4) PC03(S4) PC04(S4)
PC05(S4) PC06(S4) PC07(S4) [...]
acpitimer0 at acpi0: 3579545 Hz, 32 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 16 (boot processor)
cpu0: AMD Opteron(tm) Processor 3350 HE, 2809.75 MHz
cpu0:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS
H,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,POPCN
T,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR
8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,XOP,SKINIT,WDT,FMA4,NODEID,TBM,TOPEXT,ITSC,
BMI1
cpu0: 64KB 64b/line 2-way I-cache, 16KB 64b/line 4-way D-cache, 2MB
64b/line 16-way L2 cache, 8MB 64b/line 64-way L3 cache
cpu0: ITLB 48 4KB entries fully associative, 24 4MB entries fully associative
cpu0: DTLB 64 4KB entries fully associative, 64 4MB entries fully associative
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 200MHz
cpu0: mwait min=64, max=64, IBE
cpu1 at mainbus0: apid 17 (application processor)
cpu1: AMD Opteron(tm) Processor 3350 HE, 2809.37 MHz
cpu1:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS
H,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,POPCN
T,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR
8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,XOP,SKINIT,WDT,FMA4,NODEID,TBM,TOPEXT,ITSC,
BMI1
cpu1: 64KB 64b/line 2-way I-cache, 16KB 64b/line 4-way D-cache, 2MB
64b/line 16-way L2 cache, 8MB 64b/line 64-way L3 cache
cpu1: ITLB 48 4KB entries fully associative, 24 4MB entries fully associative
cpu1: DTLB 64 4KB entries fully associative, 64 4MB entries fully associative
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 18 (application processor)
cpu2: AMD Opteron(tm) Processor 3350 HE, 2809.37 MHz
cpu2:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS
H,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,POPCN
T,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR
8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,XOP,SKINIT,WDT,FMA4,NODEID,TBM,TOPEXT,ITSC,
BMI1
cpu2: 64KB 64b/line 2-way I-cache, 16KB 64b/line 4-way D-cache, 2MB
64b/line 16-way L2 cache, 8MB 64b/line 64-way L3 cache
cpu2: ITLB 48 4KB entries fully associative, 24 4MB entries fully associative
cpu2: DTLB 64 4KB entries fully associative, 64 4MB entries fully associative
cpu2: smt 0, core 2, package 0
cpu3 at mainbus0: apid 19 (application processor)
cpu3: AMD Opteron(tm) Processor 3350 HE, 2809.37 MHz
cpu3:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS
H,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,POPCN
T,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR
8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,XOP,SKINIT,WDT,FMA4,NODEID,TBM,TOPEXT,ITSC,
BMI1
cpu3: 64KB 64b/line 2-way I-cache, 16KB 64b/line 4-way D-cache, 2MB
64b/line 16-way L2 cache, 8MB 64b/line 64-way L3 cache
cpu3: ITLB 48 4KB entries fully associative, 24 4MB entries fully associative
cpu3: DTLB 64 4KB entries fully associative, 64 4MB entries fully associative
cpu3: smt 0, core 3, package 0
ioapic0 at mainbus0: apid 5 pa 0xfec0, version 21, 24 pins
ioapic1 at mainbus0: apid 6 pa 0xfec2, version 21, 32 

Re: UEFI boot attempt on AM1 platform with logs (9/16 snapshot)

[Brian Conway]

(Re-adding misc@ for the thrilling conclusion.)

Success! It boots to installer without issue. EFI-enabled dmesg follows.

Thanks again for your work.

Brian

OpenBSD 5.8-current (RAMDISK_CD) #1254: Tue Sep 22 19:46:40 MDT 2015
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/RAMDISK_CD
real mem = 7979794432 (7610MB)
avail mem = 7736233984 (7377MB)
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xebe50 (48 entries)
bios0: vendor American Megatrends Inc. version "V10.2" date 12/24/2014
bios0: MSI MS-7865
acpi0 at bios0: rev 2
acpi0: tables DSDT FACP APIC FPDT MCFG HPET SSDT SSDT CRAT SSDT
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: AMD Athlon(tm) 5350 APU with Radeon(tm) R3, 2046.44 MHz
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TOPEXT,ITSC,BMI1
cpu0: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 2MB
64b/line 16-way L2 cache
cpu0: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative
cpu0: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative
cpu0: apic clock running at 99MHz
cpu0: mwait min=64, max=64, IBE
cpu at mainbus0: not configured
cpu at mainbus0: not configured
cpu at mainbus0: not configured
ioapic0 at mainbus0: apid 5 pa 0xfec0, version 21, 24 pins
ioapic1 at mainbus0: apid 6 pa 0xfec01000, version 21, 32 pins
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus -1 (GPP0)
acpiprt2 at acpi0: bus -1 (GPP3)
acpiprt3 at acpi0: bus 1 (BR11)
acpiprt4 at acpi0: bus -1 (GPP2)
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "AMD AMD64 16h Host" rev 0x00
vendor "ATI", unknown product 0x9830 (class display subclass VGA, rev
0x00) at pci0 dev 1 function 0 not configured
vendor "ATI", unknown product 0x9840 (class multimedia subclass
hdaudio, rev 0x00) at pci0 dev 1 function 1 not configured
pchb1 at pci0 dev 2 function 0 vendor "AMD", unknown product 0x1538 rev 0x00
ppb0 at pci0 dev 2 function 1 "AMD AMD64 16h PCIE" rev 0x00: msi
pci1 at ppb0 bus 1
em0 at pci1 dev 0 function 0 "Intel 82574L" rev 0x00: msi, address
68:05:ca:24:f3:3e
xhci0 at pci0 dev 16 function 0 vendor "AMD", unknown product 0x7814
rev 0x01: msi
usb0 at xhci0: USB revision 3.0
uhub0 at usb0 "AMD xHCI root hub" rev 3.00/1.00 addr 1
ahci0 at pci0 dev 17 function 0 "AMD Hudson-2 SATA" rev 0x40: msi, AHCI 1.3
ahci0: port 0: 3.0Gb/s
ahci0: port 1: 3.0Gb/s
scsibus0 at ahci0: 32 targets
sd0 at scsibus0 targ 0 lun 0:  SCSI3
0/direct fixed naa.5000cca221f7a107
sd0: 1907729MB, 512 bytes/sector, 3907029168 sectors
sd1 at scsibus0 targ 1 lun 0:  SCSI3
0/direct fixed naa.5000cca221f2c7aa
sd1: 1907729MB, 512 bytes/sector, 3907029168 sectors
ohci0 at pci0 dev 18 function 0 "AMD Hudson-2 USB" rev 0x39: apic 5
int 18, version 1.0, legacy support
ehci0 at pci0 dev 18 function 2 "AMD Hudson-2 USB2" rev 0x39: apic 5 int 17
usb1 at ehci0: USB revision 2.0
uhub1 at usb1 "AMD EHCI root hub" rev 2.00/1.00 addr 1
ohci1 at pci0 dev 19 function 0 "AMD Hudson-2 USB" rev 0x39: apic 5
int 18, version 1.0, legacy support
ehci1 at pci0 dev 19 function 2 "AMD Hudson-2 USB2" rev 0x39: apic 5 int 17
usb2 at ehci1: USB revision 2.0
uhub2 at usb2 "AMD EHCI root hub" rev 2.00/1.00 addr 1
"AMD Hudson-2 SMBus" rev 0x3a at pci0 dev 20 function 0 not configured
"AMD Hudson-2 LPC" rev 0x11 at pci0 dev 20 function 3 not configured
pchb2 at pci0 dev 24 function 0 "AMD AMD64 16h Link Cfg" rev 0x00
pchb3 at pci0 dev 24 function 1 "AMD AMD64 16h Address Map" rev 0x00
pchb4 at pci0 dev 24 function 2 "AMD AMD64 16h DRAM Cfg" rev 0x00
pchb5 at pci0 dev 24 function 3 "AMD AMD64 16h Misc Cfg" rev 0x00
pchb6 at pci0 dev 24 function 4 "AMD AMD64 16h CPU Power" rev 0x00
pchb7 at pci0 dev 24 function 5 vendor "AMD", unknown product 0x1535 rev 0x00
usb3 at ohci0: USB revision 1.0
uhub3 at usb3 "AMD OHCI root hub" rev 1.00/1.00 addr 1
usb4 at ohci1: USB revision 1.0
uhub4 at usb4 "AMD OHCI root hub" rev 1.00/1.00 addr 1
isa0 at mainbus0
com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
com0: probed fifo depth: 15 bytes
pckbc0 at isa0 port 0x60/5 irq 1 irq 12
pckbd0 at pckbc0 (kbd slot)
wskbd0 at pckbd0: console keyboard
efifb0 at mainbus0
wsdisplay0 at efifb0 mux 1: console (std, vt100 emulation), using wskbd0
uhidev0 at uhub0 port 4 configuration 1 interface 0 "Microsoft Comfort
Curve Keyboard 3000" rev 2.00/1.70 addr 2
uhidev0: iclass 3/1
ukbd0 at uhidev0
wskbd1 at ukbd0 mux 1
wskbd1: connecting to wsdisplay0
uhidev1 at uhub0 port 4 configuration 1 interface 1 "Microsoft Comfort
Curve Keyboard 3000" rev 2.00/1.70 addr 2
uhidev1: iclass 3/0, 1 report id
uhid at uhidev1 reportid 1 not configured
umass0 at uhub2 port 2 configuration 1 interface 0 " Patriot Memory"
rev 

Re: UEFI boot attempt on AM1 platform with logs (9/16 snapshot)

[YASUOKA Masahiko]

Thank you for your report and test.  Next snapshot will include the fix.

On Mon, 5 Oct 2015 15:35:34 -0500
Brian Conway  wrote:
> (Re-adding misc@ for the thrilling conclusion.)
> 
> Success! It boots to installer without issue. EFI-enabled dmesg follows.
> 
> Thanks again for your work.
> 
> Brian
> 
> OpenBSD 5.8-current (RAMDISK_CD) #1254: Tue Sep 22 19:46:40 MDT 2015
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/RAMDISK_CD
> real mem = 7979794432 (7610MB)
> avail mem = 7736233984 (7377MB)
> mainbus0 at root
> bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xebe50 (48 entries)
> bios0: vendor American Megatrends Inc. version "V10.2" date 12/24/2014
> bios0: MSI MS-7865
> acpi0 at bios0: rev 2
> acpi0: tables DSDT FACP APIC FPDT MCFG HPET SSDT SSDT CRAT SSDT
> acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
> cpu0 at mainbus0: apid 0 (boot processor)
> cpu0: AMD Athlon(tm) 5350 APU with Radeon(tm) R3, 2046.44 MHz
> cpu0: 
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TOPEXT,ITSC,BMI1
> cpu0: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 2MB
> 64b/line 16-way L2 cache
> cpu0: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative
> cpu0: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative
> cpu0: apic clock running at 99MHz
> cpu0: mwait min=64, max=64, IBE
> cpu at mainbus0: not configured
> cpu at mainbus0: not configured
> cpu at mainbus0: not configured
> ioapic0 at mainbus0: apid 5 pa 0xfec0, version 21, 24 pins
> ioapic1 at mainbus0: apid 6 pa 0xfec01000, version 21, 32 pins
> acpiprt0 at acpi0: bus 0 (PCI0)
> acpiprt1 at acpi0: bus -1 (GPP0)
> acpiprt2 at acpi0: bus -1 (GPP3)
> acpiprt3 at acpi0: bus 1 (BR11)
> acpiprt4 at acpi0: bus -1 (GPP2)
> pci0 at mainbus0 bus 0
> pchb0 at pci0 dev 0 function 0 "AMD AMD64 16h Host" rev 0x00
> vendor "ATI", unknown product 0x9830 (class display subclass VGA, rev
> 0x00) at pci0 dev 1 function 0 not configured
> vendor "ATI", unknown product 0x9840 (class multimedia subclass
> hdaudio, rev 0x00) at pci0 dev 1 function 1 not configured
> pchb1 at pci0 dev 2 function 0 vendor "AMD", unknown product 0x1538 rev 0x00
> ppb0 at pci0 dev 2 function 1 "AMD AMD64 16h PCIE" rev 0x00: msi
> pci1 at ppb0 bus 1
> em0 at pci1 dev 0 function 0 "Intel 82574L" rev 0x00: msi, address
> 68:05:ca:24:f3:3e
> xhci0 at pci0 dev 16 function 0 vendor "AMD", unknown product 0x7814
> rev 0x01: msi
> usb0 at xhci0: USB revision 3.0
> uhub0 at usb0 "AMD xHCI root hub" rev 3.00/1.00 addr 1
> ahci0 at pci0 dev 17 function 0 "AMD Hudson-2 SATA" rev 0x40: msi, AHCI 1.3
> ahci0: port 0: 3.0Gb/s
> ahci0: port 1: 3.0Gb/s
> scsibus0 at ahci0: 32 targets
> sd0 at scsibus0 targ 0 lun 0:  SCSI3
> 0/direct fixed naa.5000cca221f7a107
> sd0: 1907729MB, 512 bytes/sector, 3907029168 sectors
> sd1 at scsibus0 targ 1 lun 0:  SCSI3
> 0/direct fixed naa.5000cca221f2c7aa
> sd1: 1907729MB, 512 bytes/sector, 3907029168 sectors
> ohci0 at pci0 dev 18 function 0 "AMD Hudson-2 USB" rev 0x39: apic 5
> int 18, version 1.0, legacy support
> ehci0 at pci0 dev 18 function 2 "AMD Hudson-2 USB2" rev 0x39: apic 5 int 17
> usb1 at ehci0: USB revision 2.0
> uhub1 at usb1 "AMD EHCI root hub" rev 2.00/1.00 addr 1
> ohci1 at pci0 dev 19 function 0 "AMD Hudson-2 USB" rev 0x39: apic 5
> int 18, version 1.0, legacy support
> ehci1 at pci0 dev 19 function 2 "AMD Hudson-2 USB2" rev 0x39: apic 5 int 17
> usb2 at ehci1: USB revision 2.0
> uhub2 at usb2 "AMD EHCI root hub" rev 2.00/1.00 addr 1
> "AMD Hudson-2 SMBus" rev 0x3a at pci0 dev 20 function 0 not configured
> "AMD Hudson-2 LPC" rev 0x11 at pci0 dev 20 function 3 not configured
> pchb2 at pci0 dev 24 function 0 "AMD AMD64 16h Link Cfg" rev 0x00
> pchb3 at pci0 dev 24 function 1 "AMD AMD64 16h Address Map" rev 0x00
> pchb4 at pci0 dev 24 function 2 "AMD AMD64 16h DRAM Cfg" rev 0x00
> pchb5 at pci0 dev 24 function 3 "AMD AMD64 16h Misc Cfg" rev 0x00
> pchb6 at pci0 dev 24 function 4 "AMD AMD64 16h CPU Power" rev 0x00
> pchb7 at pci0 dev 24 function 5 vendor "AMD", unknown product 0x1535 rev 0x00
> usb3 at ohci0: USB revision 1.0
> uhub3 at usb3 "AMD OHCI root hub" rev 1.00/1.00 addr 1
> usb4 at ohci1: USB revision 1.0
> uhub4 at usb4 "AMD OHCI root hub" rev 1.00/1.00 addr 1
> isa0 at mainbus0
> com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
> com0: probed fifo depth: 15 bytes
> pckbc0 at isa0 port 0x60/5 irq 1 irq 12
> pckbd0 at pckbc0 (kbd slot)
> wskbd0 at pckbd0: console keyboard
> efifb0 at mainbus0
> wsdisplay0 at efifb0 mux 1: console (std, vt100 emulation), using wskbd0
> uhidev0 at uhub0 port 4 configuration 1 interface 0 "Microsoft Comfort
> Curve Keyboard 3000" rev 2.00/1.70 addr 2
> uhidev0: 

Re: UEFI boot attempt on AM1 platform with logs (9/16 snapshot)

[Brian Conway]

> This picture shows
>
>   Load address: Loader Data (2) 0xd0 for 4096KB FATAL
>
> This is what I want to know.  0xd0 + 4M is overlapping the kernel
> area.
>
> I think the following diff or
>
>   http://yasuoka.net/~yasuoka/BOOTX64.EFI
>   (updated)
>
> will fix the problem.

Great, thanks. I grabbed the updated binary. `machine memory` is
looking better, but no improvement on the boot situation, yet. This is
with the latest install58.fs from 9/23 with BOOTX64.EFI replaced.

http://i.imgur.com/oiEO3fr.jpg

http://i.imgur.com/adwNcnk.jpg

Re: UEFI boot attempt on AM1 platform with logs (9/16 snapshot)

[YASUOKA Masahiko]

On Wed, 23 Sep 2015 14:40:52 -0500
Brian Conway  wrote:
>> This picture shows
>>
>>   Load address: Loader Data (2) 0xd0 for 4096KB FATAL
>>
>> This is what I want to know.  0xd0 + 4M is overlapping the kernel
>> area.
>>
>> I think the following diff or
>>
>>   http://yasuoka.net/~yasuoka/BOOTX64.EFI
>>   (updated)
>>
>> will fix the problem.
> 
> Great, thanks. I grabbed the updated binary. `machine memory` is
> looking better,

Thanks.  The test code for `machine memory' was removed from that
binary.. Sorry.

> but no improvement on the boot situation, yet.

Umm.  I reverted the test code.  Can you try "machine memory" with

  http://yasuoka.net/~yasuoka/BOOTX64.EFI

again?  This will not fix the problem, but I'd like to verify my
assumption is correct.

--yasuoka

Re: UEFI boot attempt on AM1 platform with logs (9/16 snapshot)

[Brian Conway]

> Can you try the diff following or
>
>   http://yasuoka.net/~yasuoka/BOOTX64.EFI
>
> ?  Then enter "machine memory" on "boot> " prompt and check the last line.
> It shows whether the memory area for kernel is free or not.  Like
>
>   Load address: Conventional(7) 0x for KB
>
> is good sign.

Great, thanks. I grabbed the binary.

machine memory:

http://i.imgur.com/gtiAIxc.jpg

Another boot attempt, with hang (hd0d is intentional):

http://i.imgur.com/tcVm4r6.jpg

>> boot> machine disk
>> DiskBIOS#   TypeCylsHeads   SecsFlags   Checksum
>> hd0 0x80label   956 64  32  0x2 0xe4afa028
>> hd1 0x81label   1023255 63  0x0 0x0
>> boot>
>
> Isn't this a result of BIOS boot?

Yes, my bad.

Thanks.

Brian

Re: UEFI boot attempt on AM1 platform with logs (9/16 snapshot)

[YASUOKA Masahiko]

On Tue, 22 Sep 2015 14:20:22 -0500
Brian Conway  wrote:
>> Can you try the diff following or
>>
>>   http://yasuoka.net/~yasuoka/BOOTX64.EFI
>>
>> ?  Then enter "machine memory" on "boot> " prompt and check the last line.
>> It shows whether the memory area for kernel is free or not.  Like
>>
>>   Load address: Conventional(7) 0x for KB
>>
>> is good sign.
> 
> Great, thanks. I grabbed the binary.

Thanks,

> machine memory:
> 
> http://i.imgur.com/gtiAIxc.jpg

This picture shows

  Load address: Loader Data (2) 0xd0 for 4096KB FATAL

This is what I want to know.  0xd0 + 4M is overlapping the kernel
area.

I think the following diff or

  http://yasuoka.net/~yasuoka/BOOTX64.EFI
  (updated)

will fix the problem.

Index: sys/arch/amd64/stand/efiboot/Makefile.common
===
RCS file: /disk/cvs/openbsd/src/sys/arch/amd64/stand/efiboot/Makefile.common,v
retrieving revision 1.1
diff -u -p -u -p -r1.1 Makefile.common
--- sys/arch/amd64/stand/efiboot/Makefile.common2 Sep 2015 01:52:25 
-   1.1
+++ sys/arch/amd64/stand/efiboot/Makefile.common23 Sep 2015 02:45:52 
-
@@ -7,6 +7,8 @@ EFIDIR= ${.CURDIR}/../../efi
 OBJCOPY?=  objcopy
 OBJDUMP?=  objdump
 
+EFI_HEAP_LIMIT=0xc0
+
 LDFLAGS+=  -nostdlib -T${.CURDIR}/../${LDSCRIPT} -Bsymbolic -shared
 
 COPTS+=-DEFIBOOT -DNEEDS_HEAP_H -DLINKADDR=${LINKADDR} 
-I${.CURDIR}/..
@@ -65,6 +67,7 @@ ${PROG}: ${PROG.so}
 .include 
 CFLAGS+=   -Wno-pointer-sign
 CPPFLAGS+= -DSMALL -DSLOW -DNOBYFOUR -D__INTERNAL_LIBSA_CREAD
+CPPFLAGS+= -DHEAP_LIMIT=${EFI_HEAP_LIMIT}
 
 ${PROG.so}: ${OBJS}
${LD} ${LDFLAGS} -o ${.TARGET}.tmp ${OBJS} ${LDADD}
Index: sys/arch/amd64/stand/efiboot/efiboot.c
===
RCS file: /disk/cvs/openbsd/src/sys/arch/amd64/stand/efiboot/efiboot.c,v
retrieving revision 1.3
diff -u -p -u -p -r1.3 efiboot.c
--- sys/arch/amd64/stand/efiboot/efiboot.c  3 Sep 2015 09:22:40 -   
1.3
+++ sys/arch/amd64/stand/efiboot/efiboot.c  23 Sep 2015 02:45:53 -
@@ -42,7 +42,7 @@ EFI_RUNTIME_SERVICES  *RS;
 EFI_HANDLE  IH, efi_bootdp = NULL;
 EFI_PHYSICAL_ADDRESSheap;
 EFI_LOADED_IMAGE   *loadedImage;
-UINTN   heapsiz = 3 * 1024 * 1024;
+UINTN   heapsiz = 1 * 1024 * 1024;
 UINTN   mmap_key;
 static EFI_GUID imgdp_guid = { 0xbc62157e, 0x3e33, 0x4fec,
  { 0x99, 0x20, 0x2d, 0x3b, 0x36, 0xd7, 0x50, 0xdf }};
@@ -199,7 +199,7 @@ efi_heap_init(void)
 {
EFI_STATUS   status;
 
-   heap = 0x100;   /* Below kernel base address */
+   heap = HEAP_LIMIT;
status = EFI_CALL(BS->AllocatePages, AllocateMaxAddress, EfiLoaderData,
EFI_SIZE_TO_PAGES(heapsiz), );
if (status != EFI_SUCCESS)

Re: UEFI boot attempt on AM1 platform with logs (9/16 snapshot)

[YASUOKA Masahiko]

Hi,

On Thu, 17 Sep 2015 20:47:22 -0500
Brian Conway <bcon...@rcesoftware.com> wrote:
> The NUC 2820 I was previously testing snapshots with has moved on to a
> better place (and lacked any meaningful serial console support), but
> here are some logs from an MSI AM1I motherboard, both the attempted
> UEFI boot and the successful BIOS boot. It also appears to hang during
> kernel load. Let me know if I can provide any more info.

Can you try the diff following or

  http://yasuoka.net/~yasuoka/BOOTX64.EFI

?  Then enter "machine memory" on "boot> " prompt and check the last line.
It shows whether the memory area for kernel is free or not.  Like

  Load address: Conventional(7) 0x for KB

is good sign.

> Side note: Is com0 console not yet support by EFIBOOT? I got an error
> along those lines when attempting 'set tty com0', I assume this is
> already known.

No, it's not supported yet.

> boot> machine disk
> DiskBIOS#   TypeCylsHeads   SecsFlags   Checksum
> hd0 0x80label   956 64  32  0x2 0xe4afa028
> hd1 0x81label   1023255 63  0x0 0x0
> boot>

Isn't this a result of BIOS boot?

Index: sys/arch/amd64/stand/efiboot/efiboot.c
===
RCS file: /disk/cvs/openbsd/src/sys/arch/amd64/stand/efiboot/efiboot.c,v
retrieving revision 1.3
diff -u -p -u -p -r1.3 efiboot.c
--- sys/arch/amd64/stand/efiboot/efiboot.c  3 Sep 2015 09:22:40 -   
1.3
+++ sys/arch/amd64/stand/efiboot/efiboot.c  22 Sep 2015 10:35:40 -
@@ -193,6 +193,7 @@ next:
  * Memory
  ***/
 bios_memmap_t   bios_memmap[64];
+static int  efi_badloadaddr = 0;
 
 static void
 efi_heap_init(void)
@@ -224,6 +225,8 @@ efi_memprobe(void)
printf("%uK", bm->size / 1024);
}
}
+   if (efi_badloadaddr)
+   printf(" BAD");
printf("]");
 }
 
@@ -233,9 +236,10 @@ efi_memprobe_internal(void)
EFI_STATUS   status;
UINTNmapkey, mmsiz, siz;
UINT32   mmver;
+   UINT64   pend;
EFI_MEMORY_DESCRIPTOR   *mm0, *mm;
int  i, n;
-   bios_memmap_t*bm, bm0;
+   bios_memmap_t   *bm, bm0;
 
cnvmem = extmem = 0;
bios_memmap[0].type = BIOS_MAP_END;
@@ -255,6 +259,11 @@ efi_memprobe_internal(void)
bm0.type = BIOS_MAP_END;
bm0.addr = mm->PhysicalStart;
bm0.size = mm->NumberOfPages * EFI_PAGE_SIZE;
+   pend = mm->PhysicalStart + mm->NumberOfPages * EFI_PAGE_SIZE;
+   if (!(pend <= 0x100 || 0x200 < mm->PhysicalStart) &&
+   mm->Type != EfiConventionalMemory)
+   efi_badloadaddr = 1;
+
if (mm->Type == EfiReservedMemoryType ||
mm->Type == EfiUnusableMemory ||
mm->Type == EfiRuntimeServicesCode ||
@@ -614,5 +623,49 @@ int
 Xpoweroff_efi(void)
 {
EFI_CALL(RS->ResetSystem, EfiResetShutdown, EFI_SUCCESS, 0, NULL);
+   return (0);
+}
+
+int
+Xmemory_efi(void)
+{
+   EFI_STATUS   status;
+   UINTNmapkey, mmsiz, siz;
+   UINT32   mmver;
+   UINT64   pend;
+   EFI_MEMORY_DESCRIPTOR   *mm0, *mm;
+   int  i, n;
+   const char  *typestr;
+
+   siz = 0;
+   status = EFI_CALL(BS->GetMemoryMap, , NULL, , ,
+   );
+   if (status != EFI_BUFFER_TOO_SMALL)
+   panic("cannot get the size of memory map");
+   mm0 = alloc(siz);
+   status = EFI_CALL(BS->GetMemoryMap, , mm0, , , );
+   if (status != EFI_SUCCESS)
+   panic("cannot get the memory map");
+   n = siz / mmsiz;
+   mmap_key = mapkey;
+
+   for (i = 0, mm = mm0; i < n; i++, mm = NextMemoryDescriptor(mm, mmsiz)){
+   pend = mm->PhysicalStart + mm->NumberOfPages * EFI_PAGE_SIZE;
+   if (pend <= 0x100 || 0x200 < mm->PhysicalStart)
+   continue;
+   typestr = 
+   (mm->Type == EfiLoaderCode)? "Loader Code " :
+   (mm->Type == EfiLoaderData)? "Loader Data " :
+   (mm->Type == EfiBootServicesCode)? "BS Code " :
+   (mm->Type == EfiBootServicesData)? "BS Data " :
+   (mm->Type == EfiConventionalMemory)? "Conventional" :
+   "Other";
+   printf("Load a

UEFI boot attempt on AM1 platform with logs (9/16 snapshot)

[Brian Conway]

The NUC 2820 I was previously testing snapshots with has moved on to a
better place (and lacked any meaningful serial console support), but
here are some logs from an MSI AM1I motherboard, both the attempted
UEFI boot and the successful BIOS boot. It also appears to hang during
kernel load. Let me know if I can provide any more info.

Side note: Is com0 console not yet support by EFIBOOT? I got an error
along those lines when attempting 'set tty com0', I assume this is
already known.

Thanks.

UEFI-booted:

>> OpenBSD/amd64 EFIBOOT 3.29
boot> machine memory
Region 0: type 1 at 0x0 for 634KB
Region 1: type 2 at 0x9e800 for 6KB
Region 2: type 2 at 0xe for 128KB
Region 3: type 1 at 0x10 for 2577304KB
Region 4: type 2 at 0x9d5e6000 for 192KB
Region 5: type 1 at 0x9d616000 for 236KB
Region 6: type 4 at 0x9d651000 for 760KB
Region 7: type 2 at 0x9d70f000 for 13440KB
Region 8: type 1 at 0x9e42f000 for 4KB
Region 9: type 4 at 0x9e43 for 32KB
Region 10: type 1 at 0x9e438000 for 4328KB
Region 11: type 2 at 0x9e872000 for 7684KB
Region 12: type 1 at 0x9eff3000 for 52KB
Region 13: type 1 at 0x1 for 5226496KB
Region 14: type 2 at 0xfec0 for 8KB
Region 15: type 2 at 0xfec1 for 4KB
Region 16: type 2 at 0xfed0 for 4KB
Region 17: type 2 at 0xfed4 for 20KB
Region 18: type 2 at 0xfed8 for 64KB
Region 19: type 2 at 0xff00 for 16384KB
Low ram: 634KB  High ram: 2577304KB
Total free memory: 7809054KB
boot> machine disk
DiskBIOS#   TypeCylsHeads   SecsFlags   Checksum
hd0 0x80label   956 64  32  0x2 0xe4afa028
hd1 0x81label   1023255 63  0x0 0x0
boot>
cannot open hd0a:/etc/random.seed: No such file or directory
booting hd0a:/5.8/amd64/bsd.rd: 3271588|

BIOS-booted:

>> OpenBSD/amd64 BOOT 3.29
boot>
cannot open hd0a:/etc/random.seed: No such file or directory
booting hd0a:/5.8/amd64/bsd.rd: 3271588+1393616+2409472+0+569344
[72+363552+237211]=0x7ded88
entry point at 0x1000160 [7205c766, 3404, 24448b12, 2680a304]
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California.  All rights reserved.
Copyright (c) 1995-2015 OpenBSD. All rights reserved.  http://www.OpenBSD.org

OpenBSD 5.8-current (RAMDISK_CD) #1249: Wed Sep 16 21:19:28 MDT 2015
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/RAMDISK_CD
real mem = 7979794432 (7610MB)
avail mem = 7736233984 (7377MB)
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xebe50 (48 entries)
bios0: vendor American Megatrends Inc. version "V10.2" date 12/24/2014
bios0: MSI MS-7865
acpi0 at bios0: rev 2
acpi0: tables DSDT FACP APIC FPDT MCFG HPET SSDT SSDT CRAT SSDT
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: AMD Athlon(tm) 5350 APU with Radeon(tm) R3, 2046.43 MHz
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TOPEXT,ITSC,BMI1
cpu0: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 2MB
64b/line 16-way L2 cache
cpu0: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative
cpu0: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative
cpu0: apic clock running at 99MHz
cpu0: mwait min=64, max=64, IBE
cpu at mainbus0: not configured
cpu at mainbus0: not configured
cpu at mainbus0: not configured
ioapic0 at mainbus0: apid 5 pa 0xfec0, version 21, 24 pins
ioapic1 at mainbus0: apid 6 pa 0xfec01000, version 21, 32 pins
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus -1 (GPP0)
acpiprt2 at acpi0: bus -1 (GPP3)
acpiprt3 at acpi0: bus 1 (BR11)
acpiprt4 at acpi0: bus -1 (GPP2)
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "AMD AMD64 16h Host" rev 0x00
vga1 at pci0 dev 1 function 0 vendor "ATI", unknown product 0x9830 rev 0x00
vga1: aperture needed
wsdisplay1 at vga1 mux 1: console (80x25, vt100 emulation)
vendor "ATI", unknown product 0x9840 (class multimedia subclass
hdaudio, rev 0x00) at pci0 dev 1 function 1 not configured
pchb1 at pci0 dev 2 function 0 vendor "AMD", unknown product 0x1538 rev 0x00
ppb0 at pci0 dev 2 function 1 "AMD AMD64 16h PCIE" rev 0x00: msi
pci1 at ppb0 bus 1
em0 at pci1 dev 0 function 0 "Intel 82574L" rev 0x00: msi, address
68:05:ca:24:f3:3e
xhci0 at pci0 dev 16 function 0 vendor "AMD", unknown product 0x7814
rev 0x01: msi
usb0 at xhci0: USB revision 3.0
uhub0 at usb0 "AMD xHCI root hub" rev 3.00/1.00 addr 1
ahci0 at pci0 dev 17 function 0 "AMD Hudson-2 SATA" rev 0x40: msi, AHCI 1.3
ahci0: port 0: 6.0Gb/s
scsibus0 at ahci0: 32 targets
sd0 at scsibus0 targ 0 lun 0: <ATA, WDC WD10EZEX-00R, 80.0> SCSI3
0/direct fixed naa.50014ee058ae4af4
sd0: 953869MB, 512 bytes/

Re: microsoft and UEFI boot

[Paolo Aglialoro]

This article is really great, thanks a lot!
Also, I already support that repair culture, not only for ecology or
better savings, the need for GHz-booze is just marketing, my old P3 700MHz
openbsd laptop still does quite a lot.

It just comes to my mind what a guy I knew told me about the RD dept of a
very famous home devices brand: they design products which, within 5 years,
will suffer from a hardware failure which won't be economically savvy to
repair, compared to buying a new device: this is the only way to keep
selling in an overloaded market...



On Mon, Sep 26, 2011 at 11:55 AM, Tomas Bodzar tomas.bod...@gmail.comwrote:

 On Mon, Sep 26, 2011 at 11:09 AM, Paolo Aglialoro paol...@gmail.com
 wrote:
  Actually I'm way more optimist about OEM motherboard manufacturers rather
  than PC companies.
  The weak spot will in fact be laptops and other portable equipment, as
 these
  are all proprietary design.

 There's new article related to that
 http://www.bunniestudios.com/blog/?p=1863

 
  Considering that laptop sales have overdone standard fixed PCs ones
 since
  years, the ecosystem, unless some heavyweight authority will strike hard,
  could be severely affected
 
  Plus: is this crap going to fit the TPM chip onboard? Or just something
 that
  can be got around by flashing bios/firmware? And how many firmwares will
  there be? It's not realistic to think that any single one of them can be
  hacked... plus with the danger of bricking the box any time or making it
  behave dizzy
 
 
 
  On Sat, Sep 24, 2011 at 7:09 PM, Marc Smith marc_sm...@gmx.com wrote:
 
  Well, yes. You're right. Apparently only EU commission can help and
  let me tell you that: EU is really good with those kind of
  regulations. It usually cares for customer's privacy and fights
  monopoly of particular companies. Let's hope it would make next move.
 
  Anyway, there are [still] some custom PC sets that remains open and
  non-restrictive. Let's count on that so it will remain active on the
  market.
 
  W dniu 24.09.2011 18:57, Paolo Aglialoro pisze:
   Unfortunately, just a tiny percentage of sold X86 boxes is no-OS,
   and also dell has stopped selling linux PCs. The last no-OS one I
   bought was an HP laptop (HP 360) with suse 11 onboard. Drops within
   an ocean. Unless EU Commission helps, it'll be a hell of a
   scenery
  
  
  
   On Sat, Sep 24, 2011 at 4:13 PM, Marc Smith marc_sm...@gmx.com
   wrote:
  
   This has been already explained in multiple articles, really. It
   looks like it's OEMs stuff. They decide whether they give the end
   user an option to disable secure boot or not. It's probobly the
   best to buy only No OS computers anyway. You can also support
   various open BIOS initiatives.
  
   Dnia sob, 24 wrz 2011, 15:36:21 Amit Kulkarni pisze:
   http://mjg59.dreamwidth.org/5850.html
  
   in the future how will we have access to OpenBSD if Microsoft
   get away with it? right now most of us buy Windows enabled PCs
   and either dual boot or wipe it out...
  
   thanks

Re: microsoft and UEFI boot

[Paolo Aglialoro]

Actually I'm way more optimist about OEM motherboard manufacturers rather
than PC companies.
The weak spot will in fact be laptops and other portable equipment, as these
are all proprietary design.

Considering that laptop sales have overdone standard fixed PCs ones since
years, the ecosystem, unless some heavyweight authority will strike hard,
could be severely affected

Plus: is this crap going to fit the TPM chip onboard? Or just something that
can be got around by flashing bios/firmware? And how many firmwares will
there be? It's not realistic to think that any single one of them can be
hacked... plus with the danger of bricking the box any time or making it
behave dizzy



On Sat, Sep 24, 2011 at 7:09 PM, Marc Smith marc_sm...@gmx.com wrote:

 Well, yes. You're right. Apparently only EU commission can help and
 let me tell you that: EU is really good with those kind of
 regulations. It usually cares for customer's privacy and fights
 monopoly of particular companies. Let's hope it would make next move.

 Anyway, there are [still] some custom PC sets that remains open and
 non-restrictive. Let's count on that so it will remain active on the
 market.

 W dniu 24.09.2011 18:57, Paolo Aglialoro pisze:
  Unfortunately, just a tiny percentage of sold X86 boxes is no-OS,
  and also dell has stopped selling linux PCs. The last no-OS one I
  bought was an HP laptop (HP 360) with suse 11 onboard. Drops within
  an ocean. Unless EU Commission helps, it'll be a hell of a
  scenery
 
 
 
  On Sat, Sep 24, 2011 at 4:13 PM, Marc Smith marc_sm...@gmx.com
  wrote:
 
  This has been already explained in multiple articles, really. It
  looks like it's OEMs stuff. They decide whether they give the end
  user an option to disable secure boot or not. It's probobly the
  best to buy only No OS computers anyway. You can also support
  various open BIOS initiatives.
 
  Dnia sob, 24 wrz 2011, 15:36:21 Amit Kulkarni pisze:
  http://mjg59.dreamwidth.org/5850.html
 
  in the future how will we have access to OpenBSD if Microsoft
  get away with it? right now most of us buy Windows enabled PCs
  and either dual boot or wipe it out...
 
  thanks

Re: microsoft and UEFI boot

[Tomas Bodzar]

On Mon, Sep 26, 2011 at 11:09 AM, Paolo Aglialoro paol...@gmail.com wrote:
 Actually I'm way more optimist about OEM motherboard manufacturers rather
 than PC companies.
 The weak spot will in fact be laptops and other portable equipment, as these
 are all proprietary design.

There's new article related to that http://www.bunniestudios.com/blog/?p=1863


 Considering that laptop sales have overdone standard fixed PCs ones since
 years, the ecosystem, unless some heavyweight authority will strike hard,
 could be severely affected

 Plus: is this crap going to fit the TPM chip onboard? Or just something that
 can be got around by flashing bios/firmware? And how many firmwares will
 there be? It's not realistic to think that any single one of them can be
 hacked... plus with the danger of bricking the box any time or making it
 behave dizzy



 On Sat, Sep 24, 2011 at 7:09 PM, Marc Smith marc_sm...@gmx.com wrote:

 Well, yes. You're right. Apparently only EU commission can help and
 let me tell you that: EU is really good with those kind of
 regulations. It usually cares for customer's privacy and fights
 monopoly of particular companies. Let's hope it would make next move.

 Anyway, there are [still] some custom PC sets that remains open and
 non-restrictive. Let's count on that so it will remain active on the
 market.

 W dniu 24.09.2011 18:57, Paolo Aglialoro pisze:
  Unfortunately, just a tiny percentage of sold X86 boxes is no-OS,
  and also dell has stopped selling linux PCs. The last no-OS one I
  bought was an HP laptop (HP 360) with suse 11 onboard. Drops within
  an ocean. Unless EU Commission helps, it'll be a hell of a
  scenery
 
 
 
  On Sat, Sep 24, 2011 at 4:13 PM, Marc Smith marc_sm...@gmx.com
  wrote:
 
  This has been already explained in multiple articles, really. It
  looks like it's OEMs stuff. They decide whether they give the end
  user an option to disable secure boot or not. It's probobly the
  best to buy only No OS computers anyway. You can also support
  various open BIOS initiatives.
 
  Dnia sob, 24 wrz 2011, 15:36:21 Amit Kulkarni pisze:
  http://mjg59.dreamwidth.org/5850.html
 
  in the future how will we have access to OpenBSD if Microsoft
  get away with it? right now most of us buy Windows enabled PCs
  and either dual boot or wipe it out...
 
  thanks

Re: microsoft and UEFI boot

[Rudolf Leitgeb]

Am Montag, den 26.09.2011, 11:09 +0200 schrieb Paolo Aglialoro:
 Actually I'm way more optimist about OEM motherboard manufacturers rather
 than PC companies.
 The weak spot will in fact be laptops and other portable equipment, as these
 are all proprietary design.
 
 Considering that laptop sales have overdone standard fixed PCs ones since
 years, the ecosystem, unless some heavyweight authority will strike hard,
 could be severely affected

Since the early days of open source operating systems there is 
a continuous flow of scare messages that some hardware innovation
will kill open source operating systems. Remember I2O anyone?

No serious motherboard manufacturer except maybe at the very bottom end
can afford to lock out open source operating systems in the long run.
Way too many businesses, even those which appear to be 100.0% Microsoft
from the outside, depend on linux and *BSD. If anyone wanted to kill
FOSS unixes, 1995 would have been the right time. It's way too late for
that now and let's please not spread FUD about this issue.

Re: microsoft and UEFI boot

[Mike.]

On 9/24/2011 at 6:57 PM Paolo Aglialoro wrote:

|Unfortunately, just a tiny percentage of sold X86 boxes is no-OS, and
also
|dell has stopped selling linux PCs.
|The last no-OS one I bought was an HP laptop (HP 360) with suse 11
|onboard. Drops within an ocean.
|Unless EU Commission helps, it'll be a hell of a scenery
 =


Interesting that all this is happening just after Microsoft comes out
from under the auspices of the DoJ for anti-trust violations.

microsoft and UEFI boot

[Amit Kulkarni]

http://mjg59.dreamwidth.org/5850.html

in the future how will we have access to OpenBSD if Microsoft get away
with it? right now most of us buy Windows enabled PCs and either dual
boot or wipe it out...

thanks

Re: microsoft and UEFI boot

[Marc Smith]

This has been already explained in multiple articles, really. It looks 
like it's OEMs stuff. They decide whether they give the end user an 
option to disable secure boot or not.
It's probobly the best to buy only No OS computers anyway. You can 
also support various open BIOS initiatives.

Dnia sob, 24 wrz 2011, 15:36:21 Amit Kulkarni pisze:
 http://mjg59.dreamwidth.org/5850.html

 in the future how will we have access to OpenBSD if Microsoft get away
 with it? right now most of us buy Windows enabled PCs and either dual
 boot or wipe it out...

 thanks

Re: microsoft and UEFI boot

[Paren Thetic]

On Sat, 24 Sep 2011 08:36:21 -0500
Amit Kulkarni amitk...@gmail.com wrote:

 http://mjg59.dreamwidth.org/5850.html
 
 in the future how will we have access to OpenBSD if Microsoft get away
 with it? right now most of us buy Windows enabled PCs and either dual
 boot or wipe it out...
 
 thanks

Don't buy IBM PCs if they do this.

Fairly simple.

Re: microsoft and UEFI boot

[Paolo Aglialoro]

Unfortunately, just a tiny percentage of sold X86 boxes is no-OS, and also
dell has stopped selling linux PCs.
The last no-OS one I bought was an HP laptop (HP 360) with suse 11
onboard. Drops within an ocean.
Unless EU Commission helps, it'll be a hell of a scenery



On Sat, Sep 24, 2011 at 4:13 PM, Marc Smith marc_sm...@gmx.com wrote:

 This has been already explained in multiple articles, really. It looks
 like it's OEMs stuff. They decide whether they give the end user an
 option to disable secure boot or not.
 It's probobly the best to buy only No OS computers anyway. You can
 also support various open BIOS initiatives.

 Dnia sob, 24 wrz 2011, 15:36:21 Amit Kulkarni pisze:
  http://mjg59.dreamwidth.org/5850.html
 
  in the future how will we have access to OpenBSD if Microsoft get away
  with it? right now most of us buy Windows enabled PCs and either dual
  boot or wipe it out...
 
  thanks

Re: microsoft and UEFI boot

[Marc Smith]

Well, yes. You're right. Apparently only EU commission can help and
let me tell you that: EU is really good with those kind of
regulations. It usually cares for customer's privacy and fights
monopoly of particular companies. Let's hope it would make next move.

Anyway, there are [still] some custom PC sets that remains open and
non-restrictive. Let's count on that so it will remain active on the
market.

W dniu 24.09.2011 18:57, Paolo Aglialoro pisze:
 Unfortunately, just a tiny percentage of sold X86 boxes is no-OS,
 and also dell has stopped selling linux PCs. The last no-OS one I
 bought was an HP laptop (HP 360) with suse 11 onboard. Drops within
 an ocean. Unless EU Commission helps, it'll be a hell of a
 scenery
 
 
 
 On Sat, Sep 24, 2011 at 4:13 PM, Marc Smith marc_sm...@gmx.com
 wrote:
 
 This has been already explained in multiple articles, really. It
 looks like it's OEMs stuff. They decide whether they give the end
 user an option to disable secure boot or not. It's probobly the
 best to buy only No OS computers anyway. You can also support
 various open BIOS initiatives.
 
 Dnia sob, 24 wrz 2011, 15:36:21 Amit Kulkarni pisze:
 http://mjg59.dreamwidth.org/5850.html
 
 in the future how will we have access to OpenBSD if Microsoft
 get away with it? right now most of us buy Windows enabled PCs
 and either dual boot or wipe it out...
 
 thanks