Re: GPT boot has less features than legacy MBR-based one (Was: UEFI, loader.efi and /boot.config)
Hello Rebecca, Saturday, January 19, 2019, 6:06:52 PM, you wrote: > Ok, I've checked my desktop Asus Z170-A, but it is graphical and I could > not find or understand anything in this home-rown UI with crazy-fast mouse. > On ASUS systems you normally press F8 during POST to bring up the boot menu, > and F11 on Supermicro systems. Yes, I know. But what should I do next? There is no "Set UEFI Boot Var" item in it. You could select different physical drives (but not partitions of the drives) and network cards (if PXE is enabled), and, sometimes, "EFI Shell" which is not documented anywhere, and it doesn't work always. When I google "ASUS EFI Shell", for example, all results says about preparing USB stick with EFI shell and such, not about commands and variables of EFI shell. I don't say, that it is impossible, I only could not find good (or any) documentation. -- Best regards, Levmailto:l...@freebsd.org ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: GPT boot has less features than legacy MBR-based one (Was: UEFI, loader.efi and /boot.config)
On Sat, Jan 19, 2019 at 9:32 AM Rodney W. Grimes < freebsd-...@pdx.rh.cn85.dnsmgr.net> wrote: > > On Sat, Jan 19, 2019 at 9:00 AM Rodney W. Grimes < > > freebsd-...@pdx.rh.cn85.dnsmgr.net> wrote: > > > > > > > > > > On January 19, 2019 at 2:52:28 AM, Lev Serebryakov (l...@freebsd.org > > > (mailto:l...@freebsd.org)) wrote: > > > > > > > > > I have never seen such item in BIOS Setup. I've checked two MoBos > now > > > (one is > > > > > Supermicro X9something and other is brand-new Goldmont-based > Chinese > > > MiniPC > > > > > like Intel NUK): both have one knob in setup about boot type > > > > > (Legacy/UEFI/Auto) and if UEFI is selected, Supermicro MoBo (but > not > > > Chinese > > > > > one) could be booted to "UEFI Console" which is not documented > > > anywhere. > > > > > > > > > > Ok, I've checked my desktop Asus Z170-A, but it is graphical and I > > > could > > > > > not find or understand anything in this home-rown UI with > crazy-fast > > > mouse. > > > > > > > > > > > > > On ASUS systems you normally press F8 during POST to bring up the > boot > > > menu, and F11 on Supermicro systems. > > > > > > ASUS should learn to put that stuff on screen... like everyone else. > > > I've been hitting the delete and going to the bios/boot tap which > > > also has a boot selection screen on one of my machines because I > > > did not know F8 existed. > > > > > > > I've been generally reluctant to add old-style boot0 selection to UEFI > > stuff. The BIOS already does it, so we don't need to. I've not needed it > at > > all. > > The BIOS does NOT do what our boot0 does, I have seen no BIOS that > well allow me to select a partition on a drive, you can only select > the drive. > True, but you need more than knowing which partition to boot from with UEFI. Sadly, it's no longer that simple for multiple partition setups. UEFI knows how to boot the primary loader (our boot1.efi or loader.efi), but from there there's no standard way to tell how to select from multiple different notions. I've created a standard for FreeBSD (which is what each OS is supposed to do), but making it happen is tricky as you somehow have to know which of several options you want to use. There's several ways to do this in FreeBSD, but they aren't super easy (if you get to the loader prompt, you can set anything to boot there). > I think this is the feature that Lev is missing, and I am sure > others shall miss it to. > > IIRC whistle used a version of this so you could install a new system > to partion 2, keeping your current system in partion 1, and changing the > active back and forth. If we have lost that basic functionality with > the growth of GPT and UEFI that is a sad day. > If you set it up properly, that's trivial to do. We do it all the time at Netflix. Most of the changes I made to loader.efi was to make this possible, regular and easy. > However, we start the boot in lua. We already allow an interruption of > > loader.efi, so it would be super easy (assuming we got the lua bindings > > right) to implement something that would show you all the Boot envs > and > > let you select one to boot instead. We already have the ability to > > interupt the boot loader. It would also be trivial to implement a > 'efiboot > > ' command to give that to you in cli mode. Both would set BootNext to > > and exit. We already have a menu, we could just add it to that. This > > would solve the hassles people are having with their BIOS (either because > > it's incomplete or hides the functionality too well) and would obviate > the > > need to make boot1.efi do the selection (which has issues of its own due > to > > boot1's limited scope). > > Loader and such is far too late... as part of what the boot0 mbr gets you > around is when your loader in the new partition is what is stopping you > from getting booted because it got screwed up. > In UEFI land, this is handled by the UEFI shell or the BIOS. It's a fundamentally different environment where /boot/loader.efi is not too late. In UEFI your primary loader lives on the ESP and is responsible for getting the rest of the OS running. If you just want to boot FreeBSD, it's plenty sophisticated to boot any bootable FreeBSD partition by setting currdev to the right value and reloading the kernel. If you want to boot another OS, however, you'll need to slot into the standard UEFI stuff, which is setting up a boot variable and telling UEFI to use it instead of what you just booted (which is what we can't do today: we can't set BootNext and then exit the boot loader). All the functionality that used to be in mbr has moved into the BIOS. The bootstrap has gone from "read this one block from location 0" to "read this file from this FAT partition and pass it this extra goo". We are an imperfect fit into that now, I won't deny. We're closer to being not a terrible fit than we have been in the past, but we have a ways to go. But to get there, we have to stop thinking MBR-ly and start thinking
Re: Multiport serial card Exsys EX-44388, where are the devices ?
> Hi! > > > uart is the new thing. sio info should be ignored. > > > > Chances are good that this device doesn't have the proper entries in the > > puc driver. Do you have any pci devices that show up as unclaimed? > > In a different box, I got this: > > none1@pci0:7:4:0: class=0x070002 card=0x000814a1 chip=0x000814a1 > rev=0xb0 hdr=0x00 > vendor = 'Systembase Co Ltd' > class = simple comms > subclass = UART > bar [10] = type I/O Port, range 32, base 0x1040, size 64, enabled > bar [14] = type I/O Port, range 32, base 0x1000, size 64, enabled > > and: > > pcib7@pci0:6:0:0: class=0x060400 card=0x chip=0x10801b21 > rev=0x04 hdr=0x01 > vendor = 'ASMedia Technology Inc.' > device = 'ASM1083/1085 PCIe to PCI Bridge' > class = bridge > subclass = PCI-PCI > > The chips on the card are: > > ASMedia asm1083 b0bk4911b3 1543 (?) > SystemBase SB16C1058PCI 1624 > > It only detects four (or six?) serials... Are perhaps 2 of them being consumed by sio? > > So I think I found a 'somehow' working setup and have to add stuff to > sys/dev/puc/pucdata.c to match it. Thanks for the pointer! Ok, heading in the right direction, try pciconf -lB that should show the hierarchy with the simple comms connected behind the pci-pci bridge. More readable without the -v your using above. Please do post the complete output of exactly: pciconf -lB -- Rod Grimes rgri...@freebsd.org ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Multiport serial card Exsys EX-44388, where are the devices ?
> Hi! > > > uart2: <16550 or compatible> port 0x3e8-0x3ef irq 10 on acpi0 > > Ah, that is a false lead. > > I compared it to a second, similar hardware and there I found the same uart2, > even if no card was installed 8-( > > So it seems the card is not detected at all 8-( Need to find out why it is not showing up in the PCI listings. Can you post the output from pciconf -l -- Rod Grimes rgri...@freebsd.org ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: GPT boot has less features than legacy MBR-based one (Was: UEFI, loader.efi and /boot.config)
On 1/19/2019 10:32, Rodney W. Grimes wrote: >> .. > The BIOS does NOT do what our boot0 does, I have seen no BIOS that > well allow me to select a partition on a drive, you can only select > the drive. > > I think this is the feature that Lev is missing, and I am sure > others shall miss it to. > > IIRC whistle used a version of this so you could install a new system > to partion 2, keeping your current system in partion 1, and changing the > active back and forth. If we have lost that basic functionality with > the growth of GPT and UEFI that is a sad day. It is indeed, especially for embedded applications. I really, really like the fact that NanoBSD (on an MBR boot) can have two partitions and mark the "other one" as active; this then lets you update the code "in place" and as long as you are paying attention to what goes into the volatile overlays (specifically although not exclusively don't let /etc/fstab with a hard-coded filesystem reference get into there!) then you can "warm update" a running system and reboot into the new code. If something goes wrong re-marking the old partition active is not terribly hard, so there's a *reasonable* recovery path available. I've not found a reliable way to do that sort of thing with many of the "newer" small-board devices and I really like it on, for example, my apu2 firewall appliances that I and others are using all over the place in that being able to put together a code-fix update is of material value. -- Karl Denninger k...@denninger.net /The Market Ticker/ smime.p7s Description: S/MIME Cryptographic Signature
Re: GPT boot has less features than legacy MBR-based one (Was: UEFI, loader.efi and /boot.config)
> On 19 Jan 2019, at 11:52, Lev Serebryakov wrote: > > Hello Warner, > > Saturday, January 19, 2019, 12:17:29 AM, you wrote: > >> Also most UEFI BIOSes I've used (which isn't a lot) allow one to choose >> which Boot variable to use to boot. Some will even create new Boot >> variables that they use when you choose a raw device to boot from. > I have never seen such item in BIOS Setup. I've checked two MoBos now (one is > Supermicro X9something and other is brand-new Goldmont-based Chinese MiniPC > like Intel NUK): both have one knob in setup about boot type > (Legacy/UEFI/Auto) and if UEFI is selected, Supermicro MoBo (but not Chinese > one) could be booted to "UEFI Console" which is not documented anywhere. > > Ok, I've checked my desktop Asus Z170-A, but it is graphical and I could > not find or understand anything in this home-rown UI with crazy-fast mouse. > > I have never seen documentation in MoBo manuals about such features, BTW. > > And, again, GPT/Legacy still left behind, and it could be very useful for > small systems, as sometimes 4 partitions of MBR is not enough (2 code > partitions + 1 config partition + 1 persistent data partition, and > SOMETIMES, there is place for swap, for example, but MBR is full already). > you can always create BSD label inside MBR slice. Also you can add chain_disk=devicename: into loader.conf and get same one key selection in boot menu (or Boot Enviroments for that matter). There is no need to struggle with 446 byte asm code when you have full power from your boot loader. rgds, toomas ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Multiport serial card Exsys EX-44388, where are the devices ?
> On Sat, Jan 19, 2019 at 2:52 AM Kurt Jaeger wrote: > > > Hi! > > > > > uart is the new thing. sio info should be ignored. > > > > > > Chances are good that this device doesn't have the proper entries in the > > > puc driver. Do you have any pci devices that show up as unclaimed? > > > > In a different box, I got this: > > > > none1@pci0:7:4:0: class=0x070002 card=0x000814a1 chip=0x000814a1 > > rev=0xb0 hdr=0x00 > > vendor = 'Systembase Co Ltd' > > class = simple comms > > subclass = UART > > bar [10] = type I/O Port, range 32, base 0x1040, size 64, enabled > > bar [14] = type I/O Port, range 32, base 0x1000, size 64, enabled > > > > This is the one you want. You'll need to add vendor 14a1 device 8 to the > puc tables. Do you need help with this? It will be a bit tricky because > each of these defines several ports, I think. > > and: > > > > pcib7@pci0:6:0:0: class=0x060400 card=0x chip=0x10801b21 > > rev=0x04 hdr=0x01 > > vendor = 'ASMedia Technology Inc.' > > device = 'ASM1083/1085 PCIe to PCI Bridge' > > class = bridge > > subclass = PCI-PCI > > > > This is something else. I believe this is the PCI-PCI bridge that he clearly says is on the board just a few lines below here. > > > > The chips on the card are: > > > > ASMedia asm1083 b0bk4911b3 1543 (?) > > SystemBase SB16C1058PCI 1624 > > > > It only detects four (or six?) serials... > > > > So I think I found a 'somehow' working setup and have to add stuff to > > sys/dev/puc/pucdata.c to match it. Thanks for the pointer! > > > That's right. Ask me if you need help. There's several different ways that > hardware vendors slice and dice the UARTs, and there's no standard. Clock > rate may be an issue too, since newer cards have faster baud clocks to > support higher rates, but this means to get the right right you have to > use a different divisor than the older 16550A typically needed. Luckily > this is well supported. I am also wondering if the reason he only saw 4 or 6 ports is that some of them have been presented to the system in a way that they look like standard uart0 and uart1, that is why I asked for the full non verbose pciconf -lB output, it would clear some of that up. -- Rod Grimes rgri...@freebsd.org ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: GPT boot has less features than legacy MBR-based one (Was: UEFI, loader.efi and /boot.config)
> On Sat, Jan 19, 2019 at 9:00 AM Rodney W. Grimes < > freebsd-...@pdx.rh.cn85.dnsmgr.net> wrote: > > > > > > > On January 19, 2019 at 2:52:28 AM, Lev Serebryakov (l...@freebsd.org > > (mailto:l...@freebsd.org)) wrote: > > > > > > > I have never seen such item in BIOS Setup. I've checked two MoBos now > > (one is > > > > Supermicro X9something and other is brand-new Goldmont-based Chinese > > MiniPC > > > > like Intel NUK): both have one knob in setup about boot type > > > > (Legacy/UEFI/Auto) and if UEFI is selected, Supermicro MoBo (but not > > Chinese > > > > one) could be booted to "UEFI Console" which is not documented > > anywhere. > > > > > > > > Ok, I've checked my desktop Asus Z170-A, but it is graphical and I > > could > > > > not find or understand anything in this home-rown UI with crazy-fast > > mouse. > > > > > > > > > > On ASUS systems you normally press F8 during POST to bring up the boot > > menu, and F11 on Supermicro systems. > > > > ASUS should learn to put that stuff on screen... like everyone else. > > I've been hitting the delete and going to the bios/boot tap which > > also has a boot selection screen on one of my machines because I > > did not know F8 existed. > > > > I've been generally reluctant to add old-style boot0 selection to UEFI > stuff. The BIOS already does it, so we don't need to. I've not needed it at > all. The BIOS does NOT do what our boot0 does, I have seen no BIOS that well allow me to select a partition on a drive, you can only select the drive. I think this is the feature that Lev is missing, and I am sure others shall miss it to. IIRC whistle used a version of this so you could install a new system to partion 2, keeping your current system in partion 1, and changing the active back and forth. If we have lost that basic functionality with the growth of GPT and UEFI that is a sad day. > > However, we start the boot in lua. We already allow an interruption of > loader.efi, so it would be super easy (assuming we got the lua bindings > right) to implement something that would show you all the Boot envs and > let you select one to boot instead. We already have the ability to > interrupt the boot loader. It would also be trivial to implement a 'efiboot > ' command to give that to you in cli mode. Both would set BootNext to > and exit. We already have a menu, we could just add it to that. This > would solve the hassles people are having with their BIOS (either because > it's incomplete or hides the functionality too well) and would obviate the > need to make boot1.efi do the selection (which has issues of its own due to > boot1's limited scope). Loader and such is far too late... as part of what the boot0 mbr gets you around is when your loader in the new partition is what is stopping you from getting booted because it got screwed up. > The only drawback here is that we'd not be able to create new boot envs in > the loader, or you'd need to create a new one if you haven't yet run > efibootmgr(8), but if that's really an issue, someone will write code to > cope. > > Warner -- Rod Grimes rgri...@freebsd.org ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Multiport serial card Exsys EX-44388, where are the devices ?
On Sat, Jan 19, 2019 at 2:52 AM Kurt Jaeger wrote: > Hi! > > > uart is the new thing. sio info should be ignored. > > > > Chances are good that this device doesn't have the proper entries in the > > puc driver. Do you have any pci devices that show up as unclaimed? > > In a different box, I got this: > > none1@pci0:7:4:0: class=0x070002 card=0x000814a1 chip=0x000814a1 > rev=0xb0 hdr=0x00 > vendor = 'Systembase Co Ltd' > class = simple comms > subclass = UART > bar [10] = type I/O Port, range 32, base 0x1040, size 64, enabled > bar [14] = type I/O Port, range 32, base 0x1000, size 64, enabled > This is the one you want. You'll need to add vendor 14a1 device 8 to the puc tables. Do you need help with this? It will be a bit tricky because each of these defines several ports, I think. and: > > pcib7@pci0:6:0:0: class=0x060400 card=0x chip=0x10801b21 > rev=0x04 hdr=0x01 > vendor = 'ASMedia Technology Inc.' > device = 'ASM1083/1085 PCIe to PCI Bridge' > class = bridge > subclass = PCI-PCI > This is something else. > The chips on the card are: > > ASMedia asm1083 b0bk4911b3 1543 (?) > SystemBase SB16C1058PCI 1624 > > It only detects four (or six?) serials... > > So I think I found a 'somehow' working setup and have to add stuff to > sys/dev/puc/pucdata.c to match it. Thanks for the pointer! That's right. Ask me if you need help. There's several different ways that hardware vendors slice and dice the UARTs, and there's no standard. Clock rate may be an issue too, since newer cards have faster baud clocks to support higher rates, but this means to get the right right you have to use a different divisor than the older 16550A typically needed. Luckily this is well supported. Warner ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: GPT boot has less features than legacy MBR-based one (Was: UEFI, loader.efi and /boot.config)
On Sat, Jan 19, 2019 at 9:00 AM Rodney W. Grimes < freebsd-...@pdx.rh.cn85.dnsmgr.net> wrote: > > > > On January 19, 2019 at 2:52:28 AM, Lev Serebryakov (l...@freebsd.org > (mailto:l...@freebsd.org)) wrote: > > > > > I have never seen such item in BIOS Setup. I've checked two MoBos now > (one is > > > Supermicro X9something and other is brand-new Goldmont-based Chinese > MiniPC > > > like Intel NUK): both have one knob in setup about boot type > > > (Legacy/UEFI/Auto) and if UEFI is selected, Supermicro MoBo (but not > Chinese > > > one) could be booted to "UEFI Console" which is not documented > anywhere. > > > > > > Ok, I've checked my desktop Asus Z170-A, but it is graphical and I > could > > > not find or understand anything in this home-rown UI with crazy-fast > mouse. > > > > > > > On ASUS systems you normally press F8 during POST to bring up the boot > menu, and F11 on Supermicro systems. > > ASUS should learn to put that stuff on screen... like everyone else. > I've been hitting the delete and going to the bios/boot tap which > also has a boot selection screen on one of my machines because I > did not know F8 existed. > I've been generally reluctant to add old-style boot0 selection to UEFI stuff. The BIOS already does it, so we don't need to. I've not needed it at all. However, we start the boot in lua. We already allow an interruption of loader.efi, so it would be super easy (assuming we got the lua bindings right) to implement something that would show you all the Boot envs and let you select one to boot instead. We already have the ability to interrupt the boot loader. It would also be trivial to implement a 'efiboot ' command to give that to you in cli mode. Both would set BootNext to and exit. We already have a menu, we could just add it to that. This would solve the hassles people are having with their BIOS (either because it's incomplete or hides the functionality too well) and would obviate the need to make boot1.efi do the selection (which has issues of its own due to boot1's limited scope). The only drawback here is that we'd not be able to create new boot envs in the loader, or you'd need to create a new one if you haven't yet run efibootmgr(8), but if that's really an issue, someone will write code to cope. Warner ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: GPT boot has less features than legacy MBR-based one (Was: UEFI, loader.efi and /boot.config)
> > On January 19, 2019 at 2:52:28 AM, Lev Serebryakov > (l...@freebsd.org(mailto:l...@freebsd.org)) wrote: > > > I have never seen such item in BIOS Setup. I've checked two MoBos now (one > > is > > Supermicro X9something and other is brand-new Goldmont-based Chinese MiniPC > > like Intel NUK): both have one knob in setup about boot type > > (Legacy/UEFI/Auto) and if UEFI is selected, Supermicro MoBo (but not Chinese > > one) could be booted to "UEFI Console" which is not documented anywhere. > > > > Ok, I've checked my desktop Asus Z170-A, but it is graphical and I could > > not find or understand anything in this home-rown UI with crazy-fast mouse. > > > > On ASUS systems you normally press F8 during POST to bring up the boot menu, > and F11 on Supermicro systems. ASUS should learn to put that stuff on screen... like everyone else. I've been hitting the delete and going to the bios/boot tap which also has a boot selection screen on one of my machines because I did not know F8 existed. Thank you! -- Rod Grimes rgri...@freebsd.org ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Multiport serial card Exsys EX-44388, where are the devices ?
Hi! > uart is the new thing. sio info should be ignored. > > Chances are good that this device doesn't have the proper entries in the > puc driver. Do you have any pci devices that show up as unclaimed? In a different box, I got this: none1@pci0:7:4:0: class=0x070002 card=0x000814a1 chip=0x000814a1 rev=0xb0 hdr=0x00 vendor = 'Systembase Co Ltd' class = simple comms subclass = UART bar [10] = type I/O Port, range 32, base 0x1040, size 64, enabled bar [14] = type I/O Port, range 32, base 0x1000, size 64, enabled and: pcib7@pci0:6:0:0: class=0x060400 card=0x chip=0x10801b21 rev=0x04 hdr=0x01 vendor = 'ASMedia Technology Inc.' device = 'ASM1083/1085 PCIe to PCI Bridge' class = bridge subclass = PCI-PCI The chips on the card are: ASMedia asm1083 b0bk4911b3 1543 (?) SystemBase SB16C1058PCI 1624 It only detects four (or six?) serials... So I think I found a 'somehow' working setup and have to add stuff to sys/dev/puc/pucdata.c to match it. Thanks for the pointer! -- p...@opsec.eu+49 171 3101372One year to go ! ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: GPT boot has less features than legacy MBR-based one (Was: UEFI, loader.efi and /boot.config)
Hello Tomoaki, Saturday, January 19, 2019, 4:42:21 AM, you wrote: > I should note that 512-bytes boot0 doesn't have that feature. > What had it WAS larger boot0ext, which has already gone on stable/11 > and later. IIRC, sysinstall let me select which to install on MBR. It has, look at src/stand/i386/boot0/boot0.S It works :-) -- Best regards, Levmailto:l...@freebsd.org ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: GPT boot has less features than legacy MBR-based one (Was: UEFI, loader.efi and /boot.config)
On January 19, 2019 at 2:52:28 AM, Lev Serebryakov (l...@freebsd.org(mailto:l...@freebsd.org)) wrote: > I have never seen such item in BIOS Setup. I've checked two MoBos now (one is > Supermicro X9something and other is brand-new Goldmont-based Chinese MiniPC > like Intel NUK): both have one knob in setup about boot type > (Legacy/UEFI/Auto) and if UEFI is selected, Supermicro MoBo (but not Chinese > one) could be booted to "UEFI Console" which is not documented anywhere. > > Ok, I've checked my desktop Asus Z170-A, but it is graphical and I could > not find or understand anything in this home-rown UI with crazy-fast mouse. > On ASUS systems you normally press F8 during POST to bring up the boot menu, and F11 on Supermicro systems. — Rebecca ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: GPT boot has less features than legacy MBR-based one (Was: UEFI, loader.efi and /boot.config)
Hello Emmanuel, Saturday, January 19, 2019, 12:10:13 AM, you wrote: > With UEFI Boot* variable you could do : > - Update previous partition and set BootNext to it > - If it fail next boot will be on current partition due to BootOrder > - If it succeed, change the BootOrder to have the new partition first. It will not work with GPT/Legacy, but looks like it is solution for UEFI. Thank you. -- Best regards, Levmailto:l...@freebsd.org ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Multiport serial card Exsys EX-44388, where are the devices ?
Hi! > uart2: <16550 or compatible> port 0x3e8-0x3ef irq 10 on acpi0 Ah, that is a false lead. I compared it to a second, similar hardware and there I found the same uart2, even if no card was installed 8-( So it seems the card is not detected at all 8-( -- p...@opsec.eu+49 171 3101372One year to go ! ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: GPT boot has less features than legacy MBR-based one (Was: UEFI, loader.efi and /boot.config)
Hello Warner, Saturday, January 19, 2019, 12:17:29 AM, you wrote: > Also most UEFI BIOSes I've used (which isn't a lot) allow one to choose > which Boot variable to use to boot. Some will even create new Boot > variables that they use when you choose a raw device to boot from. I have never seen such item in BIOS Setup. I've checked two MoBos now (one is Supermicro X9something and other is brand-new Goldmont-based Chinese MiniPC like Intel NUK): both have one knob in setup about boot type (Legacy/UEFI/Auto) and if UEFI is selected, Supermicro MoBo (but not Chinese one) could be booted to "UEFI Console" which is not documented anywhere. Ok, I've checked my desktop Asus Z170-A, but it is graphical and I could not find or understand anything in this home-rown UI with crazy-fast mouse. I have never seen documentation in MoBo manuals about such features, BTW. And, again, GPT/Legacy still left behind, and it could be very useful for small systems, as sometimes 4 partitions of MBR is not enough (2 code partitions + 1 config partition + 1 persistent data partition, and SOMETIMES, there is place for swap, for example, but MBR is full already). > But this whole thread tells me we need to rewrite the boot section of our > handbook. Oh, yes, please! -- Best regards, Levmailto:l...@freebsd.org ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Multiport serial card Exsys EX-44388, where are the devices ?
Hi! > > Trying to get a 8-port serial PCIe card into operation (Exsys EX-44388). > > After reboot, dmesg shows: > > > > uart2: <16550 or compatible> port 0x3e8-0x3ef irq 10 on acpi0 [...] > uart is the new thing. sio info should be ignored. > > Chances are good that this device doesn't have the proper entries in the > puc driver. Do you have any pci devices that show up as unclaimed? One, but it does not look like a match ? none0@pci0:0:31:3: class=0x0c0500 card=0x062415d9 chip=0x1c228086 rev=0x05 hdr=0x00 vendor = 'Intel Corporation' device = '6 Series/C200 Series Chipset Family SMBus Controller' class = serial bus subclass = SMBus bar [10] = type Memory, range 64, base 0xdfa21000, size 256, enabled bar [20] = type I/O Port, range 32, base 0x580, size 32, enabled It's a PCIe card, not PCI, does that matter ? -- p...@opsec.eu+49 171 3101372One year to go ! ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: GPT boot has less features than legacy MBR-based one (Was: UEFI, loader.efi and /boot.config)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Am Fri, 18 Jan 2019 14:17:29 -0700 Warner Losh schrieb: > On Fri, Jan 18, 2019 at 2:11 PM Emmanuel Vadot > wrote: > > > On Fri, 18 Jan 2019 22:50:31 +0300 > > Lev Serebryakov wrote: > > > > > On 18.01.2019 22:35, Rodney W. Grimes wrote: > > > > > > >>> errm.. you press a key and enter device and or loader path. if it is > > not working - the code is there to be fixed. > > > >> And loader looks to "bootme" attribute and try to boot from partition > > > >> which has one, even if it is loaded from other partition itself. > > > >> > > > >>> GPT does not have the concept of active partition. > > > >> It has "bootme" / "bootonce" attributes. And [zfs]gptboot doesn't > > have > > > >> any tools to set these attributes, AFAIK. Same for UEFI boot code. > > > > > > > > The gpart(8) command is used to set/unset these. > > > gpart need booted system. NanoBSD typically have two "system" > > > partitions, "old" (previous) and "new" (current). After upgrade they > > > switched (new code is written to "previos" partition and bootable > > > atteibute is set to it, "active" in case of MBR and "bootme" in case of > > > GPT). > > > > > > If this new partition has problems and could not be booted, it is hard > > > to boot from "old" (previous) one. MBR + boot0 could (interactively) > > > change active partition before system is booted, and this problem could > > > be solved with one keypress: you select old partition on boot. > > > > > > -- > > > // Lev Serebryakov > > > > > > > With UEFI Boot* variable you could do : > > > > - Update previous partition and set BootNext to it > > - If it fail next boot will be on current partition due to BootOrder > > - If it succeed, change the BootOrder to have the new partition first. > > > > Also most UEFI BIOSes I've used (which isn't a lot) allow one to choose > which Boot variable to use to boot. Some will even create new Boot > variables that they use when you choose a raw device to boot from. > > There's other people that have efi programs that will pop up a menu for you > to select a particular Boot to use. They then set BootNext and exit. > I've not used any of these personally. > > But this whole thread tells me we need to rewrite the boot section of our > handbook. Oh, yes, please, please! Thanks in advance! oh > > Warner > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" - -- O. Hartmann Ich widerspreche der Nutzung oder Übermittlung meiner Daten für Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG). -BEGIN PGP SIGNATURE- iHUEARYIAB0WIQSy8IBxAPDkqVBaTJ44N1ZZPba5RwUCXELOUgAKCRA4N1ZZPba5 R7PWAP9zDKuReIghEeO3UNUOPLldsjH0Zr8Ez0DVtaRt0F2WrwD/cWXjOOu5SLD2 NxHq0pKZ5oH0K7NC/4lA45j0Ir9C3wo= =Y3j1 -END PGP SIGNATURE- ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: UEFI, loader.efi and /boot.config
On Thursday, 17 January 2019 20:02:46 MST David Wolfskill wrote: > Does the above only apply to UEFI booting, or also to booting from > BIOS/MBR? It's only for UEFI booting. -- Rebecca Cran signature.asc Description: This is a digitally signed message part.
Re: UEFI, loader.efi and /boot.config
On Friday, 18 January 2019 00:48:02 MST Kurt Jaeger wrote: > > With a recent change I made for UEFI, we now install loader.efi onto the > > ESP and don???t run boot1. That means that /boot.config is no longer > > read, and so console settings need to be put in /boot/loader.conf > Which change is that ? The change is https://svnweb.freebsd.org/base?view=revision=342283 . -- Rebecca Cran signature.asc Description: This is a digitally signed message part.
Re: GPT boot has less features than legacy MBR-based one (Was: UEFI, loader.efi and /boot.config)
On Fri, 18 Jan 2019 22:44:28 +0300 Lev Serebryakov wrote: > On 18.01.2019 22:27, Warner Losh wrote: > > > > errm.. you press a key and enter device and or loader path. if it > > is not working - the code is there to be fixed. > > 〓And loader looks to "bootme" attribute and try to boot from partition > > which has one, even if it is loaded from other partition itself. > > Correct. > And system crashes, because "bootme" partition has broken installation. > > With MBR + boot0/boot0sio it is solved with one keypress. > > > > GPT does not have the concept of active partition. > > 〓It has "bootme" / "bootonce" attributes. And [zfs]gptboot doesn't have > > any tools to set these attributes, AFAIK. Same for UEFI boot code. > > > > gpart can set these. > You need live, booted system (at least single-user) to use gpart. > > > UEFI completely ignores them, though, because getting to that data is > > hard in the UEFI environment. But in UEFI, you're supposed to use > > Boot and BootOrder/BootNext as managed by efibootmgr. > Again, you need booted system to use efibootmgr. > > boot0/boot0sio works before system and could switch boot partition in > case of MBR. It is why I write, that GPT/Legacy and GPT/UEFI miss > important feature which is present for MBR boot for ages. Which is sad & > funny at same time, as GPT/UEFI has much more code than 512 bytes of boot0. > > -- > // Lev Serebryakov > Hi. I should note that 512-bytes boot0 doesn't have that feature. What had it WAS larger boot0ext, which has already gone on stable/11 and later. IIRC, sysinstall let me select which to install on MBR. It could be larger than 512 bytes as no partition could be mapped on 1st cylinder because USUAL partition editors aligns partition by cylinder on ancient CHS days. But IIUC, it was trivial, NOT assured by any spec. So preparing 512-bytes (single sector) boot0 IS mandatory for MBR, while boot0ext is not. One good news is that boot1.efi having boot-time partition selection by Naomichi Nonaka exists on bugzilla.[1] The latest ones includes my quick and ugly hack to get back deleted but needed functions, though. "boot1.c patch rev4 for stable/11 after MFC of r332751" would be applicable to stable/11 (not tested recently), and "boot1.c patch rev4 for stable/12 and head after r332751" would be applicable to stable/12 and head. *I've uploaded long-forgotton ones just before this mail. They should be cleaned-up to use currently-available functions instead of re-adding deleted functions but I have not enough time to do, and Naomichi, the original auther of the patche, already switched to use grub and would not maintain it further. And a bad news is that [1] would never be committed, and non-UEFI GPT-based installation doesn't have any alternatives. [1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207940 -- Tomoaki AOKI ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
