Re: [coreboot] Rettungsboot

[Zoran Stojsavljevic]

amusement value:

How long was the minimum time to cross USA from East Coast (NYC) to West
Coast (SF) back then in 1880s (Vayat Erp and Dock Holiday time: by horse or
carriage)?

And how long for the same distance Today/Present time (by plane or shuttle)?

Ron, technology advances... Doesn't it??? ;-)

Zoran

On Wed, Nov 30, 2016 at 10:18 PM, ron minnich  wrote:

> amusement value:
>
> The 512 bytes used for MBR is about .04% of the 8" floppy disk that
> shipped with the original IBM PC. For 128 MB to be that fraction of a new
> disk, the disk would have to be 256 GiB. That's about $40 worth of disk.
>
> Geez.
>
>
> On Wed, Nov 30, 2016 at 11:00 AM Zoran Stojsavljevic <
> zoran.stojsavlje...@gmail.com> wrote:
>
>> > Or do you want to do the full EFI "let's waste 128MB of *every** disk*
>> on
>> > a special FAT32 partition" madness (which still requires bootloaders to
>> > include one specific FS driver they might otherwise not want)?
>>
>> YES, you do. Accent on: "every disk" .
>>
>> Zoran
>> On Tue, Nov 29, 2016 at 10:53 PM, Julius Werner 
>> wrote:
>>
>> > To sum it up, I want something that is lean and clean enough so it could
>> be added to any bootloader. Even if that boot loader is not of the
>> let's build a tiny OS type.
>>
>> I don't really see how you could reach this goal with anything that
>> requires reading a file from the boot media? There are billions of
>> different file systems out there... do you want to require your
>> "minimal" bootloader to include drivers for all of them? (There are
>> bootloaders that don't contain any file system drivers at all, like
>> depthcharge.) Or do you want to do the full EFI "let's waste 128MB of
>> every disk on a special FAT32 partition" madness (which still requires
>> bootloaders to include one specific FS driver they might otherwise not
>> want)?
>>
>> I think if you want to do anything truly minimal and compatible with
>> everything, you can't rely on files (and you should try to rely on
>> partitions as little as possible, e.g. no full GPT parsing). Which
>> probably means putting it in the first sector. And once you have that,
>> you can create some fancy text-based format (or Go source file /
>> node.js script / whatever the cool kids use these days) to describe
>> the target sector, load address etc. of the fallback kernel... but
>> you're really just exemplifying the XKCD Igor mentioned because you've
>> just reinvented the MBR. (And let's face it... no coreboot bootloader
>> has the pull to sufficiently promote adoption of some completely new
>> fallback boot descriptor format right now, even if it doesn't require
>> a Go compiler in your bootloader.)
>>
>> So, really, I think what you want is just the MBR. It is the deadest
>> simple design possible (just load a sector and jump), it is as
>> infinitely flexible as code itself, and it coexists perfectly with all
>> partitioning schemes relevant today (MBR and GPT). Yes, it requires a
>> software interrupt BIOS interface, but if the recovery kernel code is
>> cleverly written you really only need the disk access part (and you
>> know your bootloader already has that driver because that's how it
>> loaded the MBR in the first place). And yes, on x86 it requires real
>> mode (for non-x86 I'd just make up an as equivalent as possible system
>> with your software interrupt solution of choice), but that's a small
>> price you pay with a few files worth of shim code in exchange for
>> automatic compatibility with 35 years worth of existing BIOSes. I'd
>> say that's a better deal than any new dead-on-arrival scheme you could
>> make up out of thin air.
>>
>> (If you really can't stand the idea of BIOS interrupts and real mode,
>> I think your next best option would be to try to cram an
>> as-small-as-possible binary recovery descriptor and the real mode code
>> to parse/load/execute it together into the 446 bytes of MBR space you
>> have. This way, your new payloads can just find and parse/load/execute
>> the descriptor itself without having to provide any BIOS interface,
>> but the thing is still compatible with existing legacy BIOSes as
>> well.)
>>
>> --
>> coreboot mailing list: coreboot@coreboot.org
>> https://www.coreboot.org/mailman/listinfo/coreboot
>>
>>
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [RFC] Explicitly use C11/GNU11

[Julius Werner]

> Thank you for the elaborate explanation. I never intended to take on
> that task, but if I had, you would have convinced me.
>
> I hope using GNU11 suits everyone.

Yes, just to be clear (this has split into so many different threads
that I'm no longer sure what the latest decision is?), I only
(prematurely) objected to forbidding GNU extensions. Otherwise, I'm
totally in favor of switching to C11 and not aware of any difference
between the versions that would cause a problem for us.

-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Rettungsboot

[ron minnich]

OK, then someone just asked me: how long does it take to rewrite that 128
MiB vs. the 512 byte sector on the floppy. :-)

On Wed, Nov 30, 2016 at 1:18 PM ron minnich  wrote:

> amusement value:
>
> The 512 bytes used for MBR is about .04% of the 8" floppy disk that
> shipped with the original IBM PC. For 128 MB to be that fraction of a new
> disk, the disk would have to be 256 GiB. That's about $40 worth of disk.
>
> Geez.
>
>
> On Wed, Nov 30, 2016 at 11:00 AM Zoran Stojsavljevic <
> zoran.stojsavlje...@gmail.com> wrote:
>
>> > Or do you want to do the full EFI "let's waste 128MB of *every** disk*
>> on
>> > a special FAT32 partition" madness (which still requires bootloaders to
>> > include one specific FS driver they might otherwise not want)?
>>
>> YES, you do. Accent on: "every disk" .
>>
>> Zoran
>> On Tue, Nov 29, 2016 at 10:53 PM, Julius Werner 
>> wrote:
>>
>> > To sum it up, I want something that is lean and clean enough so it could
>> be added to any bootloader. Even if that boot loader is not of the
>> let's build a tiny OS type.
>>
>> I don't really see how you could reach this goal with anything that
>> requires reading a file from the boot media? There are billions of
>> different file systems out there... do you want to require your
>> "minimal" bootloader to include drivers for all of them? (There are
>> bootloaders that don't contain any file system drivers at all, like
>> depthcharge.) Or do you want to do the full EFI "let's waste 128MB of
>> every disk on a special FAT32 partition" madness (which still requires
>> bootloaders to include one specific FS driver they might otherwise not
>> want)?
>>
>> I think if you want to do anything truly minimal and compatible with
>> everything, you can't rely on files (and you should try to rely on
>> partitions as little as possible, e.g. no full GPT parsing). Which
>> probably means putting it in the first sector. And once you have that,
>> you can create some fancy text-based format (or Go source file /
>> node.js script / whatever the cool kids use these days) to describe
>> the target sector, load address etc. of the fallback kernel... but
>> you're really just exemplifying the XKCD Igor mentioned because you've
>> just reinvented the MBR. (And let's face it... no coreboot bootloader
>> has the pull to sufficiently promote adoption of some completely new
>> fallback boot descriptor format right now, even if it doesn't require
>> a Go compiler in your bootloader.)
>>
>> So, really, I think what you want is just the MBR. It is the deadest
>> simple design possible (just load a sector and jump), it is as
>> infinitely flexible as code itself, and it coexists perfectly with all
>> partitioning schemes relevant today (MBR and GPT). Yes, it requires a
>> software interrupt BIOS interface, but if the recovery kernel code is
>> cleverly written you really only need the disk access part (and you
>> know your bootloader already has that driver because that's how it
>> loaded the MBR in the first place). And yes, on x86 it requires real
>> mode (for non-x86 I'd just make up an as equivalent as possible system
>> with your software interrupt solution of choice), but that's a small
>> price you pay with a few files worth of shim code in exchange for
>> automatic compatibility with 35 years worth of existing BIOSes. I'd
>> say that's a better deal than any new dead-on-arrival scheme you could
>> make up out of thin air.
>>
>> (If you really can't stand the idea of BIOS interrupts and real mode,
>> I think your next best option would be to try to cram an
>> as-small-as-possible binary recovery descriptor and the real mode code
>> to parse/load/execute it together into the 446 bytes of MBR space you
>> have. This way, your new payloads can just find and parse/load/execute
>> the descriptor itself without having to provide any BIOS interface,
>> but the thing is still compatible with existing legacy BIOSes as
>> well.)
>>
>> --
>> coreboot mailing list: coreboot@coreboot.org
>> https://www.coreboot.org/mailman/listinfo/coreboot
>>
>>
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Rettungsboot

[ron minnich]

amusement value:

The 512 bytes used for MBR is about .04% of the 8" floppy disk that shipped
with the original IBM PC. For 128 MB to be that fraction of a new disk, the
disk would have to be 256 GiB. That's about $40 worth of disk.

Geez.


On Wed, Nov 30, 2016 at 11:00 AM Zoran Stojsavljevic <
zoran.stojsavlje...@gmail.com> wrote:

> > Or do you want to do the full EFI "let's waste 128MB of *every** disk*
> on
> > a special FAT32 partition" madness (which still requires bootloaders to
> > include one specific FS driver they might otherwise not want)?
>
> YES, you do. Accent on: "every disk" .
>
> Zoran
> On Tue, Nov 29, 2016 at 10:53 PM, Julius Werner 
> wrote:
>
> > To sum it up, I want something that is lean and clean enough so it could
> be added to any bootloader. Even if that boot loader is not of the
> let's build a tiny OS type.
>
> I don't really see how you could reach this goal with anything that
> requires reading a file from the boot media? There are billions of
> different file systems out there... do you want to require your
> "minimal" bootloader to include drivers for all of them? (There are
> bootloaders that don't contain any file system drivers at all, like
> depthcharge.) Or do you want to do the full EFI "let's waste 128MB of
> every disk on a special FAT32 partition" madness (which still requires
> bootloaders to include one specific FS driver they might otherwise not
> want)?
>
> I think if you want to do anything truly minimal and compatible with
> everything, you can't rely on files (and you should try to rely on
> partitions as little as possible, e.g. no full GPT parsing). Which
> probably means putting it in the first sector. And once you have that,
> you can create some fancy text-based format (or Go source file /
> node.js script / whatever the cool kids use these days) to describe
> the target sector, load address etc. of the fallback kernel... but
> you're really just exemplifying the XKCD Igor mentioned because you've
> just reinvented the MBR. (And let's face it... no coreboot bootloader
> has the pull to sufficiently promote adoption of some completely new
> fallback boot descriptor format right now, even if it doesn't require
> a Go compiler in your bootloader.)
>
> So, really, I think what you want is just the MBR. It is the deadest
> simple design possible (just load a sector and jump), it is as
> infinitely flexible as code itself, and it coexists perfectly with all
> partitioning schemes relevant today (MBR and GPT). Yes, it requires a
> software interrupt BIOS interface, but if the recovery kernel code is
> cleverly written you really only need the disk access part (and you
> know your bootloader already has that driver because that's how it
> loaded the MBR in the first place). And yes, on x86 it requires real
> mode (for non-x86 I'd just make up an as equivalent as possible system
> with your software interrupt solution of choice), but that's a small
> price you pay with a few files worth of shim code in exchange for
> automatic compatibility with 35 years worth of existing BIOSes. I'd
> say that's a better deal than any new dead-on-arrival scheme you could
> make up out of thin air.
>
> (If you really can't stand the idea of BIOS interrupts and real mode,
> I think your next best option would be to try to cram an
> as-small-as-possible binary recovery descriptor and the real mode code
> to parse/load/execute it together into the 446 bytes of MBR space you
> have. This way, your new payloads can just find and parse/load/execute
> the descriptor itself without having to provide any BIOS interface,
> but the thing is still compatible with existing legacy BIOSes as
> well.)
>
> --
> coreboot mailing list: coreboot@coreboot.org
> https://www.coreboot.org/mailman/listinfo/coreboot
>
>
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Execute Linux on AMD DB-FT3b-LC through GRUB2

[Zoran Stojsavljevic]

Hello Grigore,

Did not abandon you ("Dr. House" lookalike, same age, same attitude). I
though about the issue... Gave it hard try/thought! At least, I have tried.
And here is what I came with...

> Differences on GRUB2 environment:
> AMI BIOS + *GRUB2.02beta2-36ubuntu3.1* => terminal_output=*gfxterm*, see
USB-SATA SSD as (*hd0*), (*hd0*, gpt0).., works
> both on USB2.0 and USB3.0.
> Coreboot + *GRUB2.02beta3* => terminal_output=*vga_text*, see USB-SATA
SSD as (*usb0*), (*usb0*, gpt0).., works only on USB2.0.

So... Here are bullet points:
[1] Above: you are telling/writing to me that Coreboot has newest GRUB2 SW
than Ubuntu 16.04 LTS, Linux ft3b-lc 4.4.0-31-generic??? Question to you:
are you sure? Please, check again?
[2] *VERY/CRITICALLY important:* Are you sure that in BOTH cases above you
are using *THE SAME vBIOS *component?
In other words, you should go to:
https://ami.com/products/bios-uefi-tools-and-utilities/bios-uefi-utilities/...
And try to extract vBIOS out of your AMI BIOS you are alternately using to
test... And replace/swap one (you are using currently) in Coreboot.

Good luck! :-)
Zoran
___

On Tue, Nov 29, 2016 at 2:44 PM, Grigore Lupescu  wrote:

> Hello Zoran,
> First of all thank you very much for your feedback - any idea would be
> worth trying.
>
> I am sorry about the mixup by putting the 3.13 commands there (it was 4.4
> actually). I use TAB press to get the actual version on the SSD drive
> (4.4.0-31) and those exact commands. So my bad on the last email, these are
> the actual ones:
>
> grub> set root=(hd0,gpt2)
> grub> linux /boot/vmlinuz-4.4...-generic root=/dev/sda2
> grub> initrd /boot/initrd.img-4.4...-generic
> grub> boot
>
> So I am trying to boot from an SSD with Linux connected to a USB port -
> why I am doing this ? :) because the board has a dedicated embedded style
> power supply and 1 SATA cable, hence even though I can connect the SSD
> directly I cannot power it - so I use a USB to SATA drive where I have the
> SSD plugged in (and legacy Ubuntu Linux x64 4.4 on it).
>
> Below are the full details of the AMI BIOS, Linux OS, Coreboot I am trying
> to boot over Coreboot (latest). So looking at these ++ previous ones it
> looks like vBIOS is in both.
>
> AMI BIOS 2.17.1246 Copyright 2015
> Core Version 4.6.5.4
> UEFI 2.3.1; PI 1.2
> Project Version 1ASNG 0.02 x64
> Chipset->GFX Configuration
> IGD VBIOS Version ATOMBIOSBK-AMD VERO15.042.000.002.000
> Advanced->CPU Configuration
> AGESA Version 1.0.0.5
> terminal_output: *gfxterm*
>
> Ubuntu 16.04 LTS, Linux ft3b-lc 4.4.0-31-generic #50 Ubuntu SMP Wed Jul 13
> UTC 2016 x86_64
> GNU GRUB 2.02~beta2-36ubuntu3.1
>
> Coreboot (latest branch)
> I have the latest Coreboot sources, have set config accordingly (e.g.
> CONFIG_MAINBOARD_SMBIOS_PRODUCT_NAME="DB-FT3b-LC"...), getting an image
> on HDMI and the GRUB2 payload is executing. In GRUB2 payload I seem to have
> an overflow issue possibly related to the *vga_text* mode.
> terminal_output: *vga_text*
> GRUB 2.02 beta3
>
> Differences on GRUB2 environment:
> AMI BIOS + GRUB2.02beta2-36ubuntu3.1 => terminal_output=*gfxterm*, see
> USB-SATA SSD as (*hd0*), (*hd0*, gpt0).., works both on USB2.0 and USB3.0.
> Coreboot + GRUB2.02beta3 => terminal_output=*vga_text*, see USB-SATA SSD
> as (*usb0*), (*usb0*, gpt0).., works only on USB2.0.
>
> Thank you,
> Grigore
>
> On Mon, Nov 28, 2016 at 10:40 PM, Zoran Stojsavljevic <
> zoran.stojsavlje...@gmail.com> wrote:
>
>> Grigore,
>>
>> Here are my comments to what you wrote to me:
>>
>> On Mon, Nov 28, 2016 at 7:59 PM, Grigore Lupescu 
>> wrote:
>>
>>> Hello Zoran,
>>>
>>> [1-3] I am using the latest Ubuntu 16.04 LTS x64 desktop, 4.4 kernel.
>>>
>>
>> Perfect. Got it. Good to know. 16.04 LTS support back-ports to kernel 4.4
>> APIs most of the newer features exceeding 4.4 version for some time (this
>> is very important info to/for me, never mind).
>>
>>
>>> [4] I don't know exactly if it's x64 or x86. I have no control over AMI
>>> BIOS since it's just a binary I flash into the SPI ROM, which supports the
>>> board.
>>>
>>
>> Even if it is a binary, you should be able to enter it (CMOS) pressing at
>> the very beginning of the boot  or  (maybe , Lenovo 420T
>> supports , as example), or simultaneously - alternately both of them,
>> one after another (NOT both at the same time). Then you can read the BIOS
>> version from system BIOS page. Maybe version says what is the architecture.
>> Other that that, it is bloody hard to tell what BIOS (32 or 64) you have.
>> It is easier if you do have UEFI BIOS, but you must have/gain access to EFI
>> shell, which is another problem, another dimension.
>>
>>
>>> [5] I boot Linux using legacy mode (in AMI, the Linux was installed for
>>> legacy boot on the HDD/SSD which connects via USB - USBtoSATA)
>>>
>>
>> You see... BIOS is a beast. With BIOS, if you have already attached HDMI
>> monitor, BIOS should/must detect this and record, and pass such info 

Re: [coreboot] Rettungsboot

[Zoran Stojsavljevic]

> Or do you want to do the full EFI "let's waste 128MB of *every** disk* on
> a special FAT32 partition" madness (which still requires bootloaders to
> include one specific FS driver they might otherwise not want)?

YES, you do. Accent on: "every disk" .

Zoran

On Tue, Nov 29, 2016 at 10:53 PM, Julius Werner 
wrote:

> > To sum it up, I want something that is lean and clean enough so it could
> be added to any bootloader. Even if that boot loader is not of the
> let's build a tiny OS type.
>
> I don't really see how you could reach this goal with anything that
> requires reading a file from the boot media? There are billions of
> different file systems out there... do you want to require your
> "minimal" bootloader to include drivers for all of them? (There are
> bootloaders that don't contain any file system drivers at all, like
> depthcharge.) Or do you want to do the full EFI "let's waste 128MB of
> every disk on a special FAT32 partition" madness (which still requires
> bootloaders to include one specific FS driver they might otherwise not
> want)?
>
> I think if you want to do anything truly minimal and compatible with
> everything, you can't rely on files (and you should try to rely on
> partitions as little as possible, e.g. no full GPT parsing). Which
> probably means putting it in the first sector. And once you have that,
> you can create some fancy text-based format (or Go source file /
> node.js script / whatever the cool kids use these days) to describe
> the target sector, load address etc. of the fallback kernel... but
> you're really just exemplifying the XKCD Igor mentioned because you've
> just reinvented the MBR. (And let's face it... no coreboot bootloader
> has the pull to sufficiently promote adoption of some completely new
> fallback boot descriptor format right now, even if it doesn't require
> a Go compiler in your bootloader.)
>
> So, really, I think what you want is just the MBR. It is the deadest
> simple design possible (just load a sector and jump), it is as
> infinitely flexible as code itself, and it coexists perfectly with all
> partitioning schemes relevant today (MBR and GPT). Yes, it requires a
> software interrupt BIOS interface, but if the recovery kernel code is
> cleverly written you really only need the disk access part (and you
> know your bootloader already has that driver because that's how it
> loaded the MBR in the first place). And yes, on x86 it requires real
> mode (for non-x86 I'd just make up an as equivalent as possible system
> with your software interrupt solution of choice), but that's a small
> price you pay with a few files worth of shim code in exchange for
> automatic compatibility with 35 years worth of existing BIOSes. I'd
> say that's a better deal than any new dead-on-arrival scheme you could
> make up out of thin air.
>
> (If you really can't stand the idea of BIOS interrupts and real mode,
> I think your next best option would be to try to cram an
> as-small-as-possible binary recovery descriptor and the real mode code
> to parse/load/execute it together into the 446 bytes of MBR space you
> have. This way, your new payloads can just find and parse/load/execute
> the descriptor itself without having to provide any BIOS interface,
> but the thing is still compatible with existing legacy BIOSes as
> well.)
>
> --
> coreboot mailing list: coreboot@coreboot.org
> https://www.coreboot.org/mailman/listinfo/coreboot
>
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Rettungsboot

[ron minnich]

hey, peter, code wins :-) go for it

On Wed, Nov 30, 2016 at 10:08 AM Peter Stuge  wrote:

> Julius Werner wrote:
> > If you really can't stand the idea of BIOS interrupts and real mode,
>
> I for one can't.
>
>
> > I think your next best option would be to try to cram an
> > as-small-as-possible binary recovery descriptor and the real mode
> > code to parse/load/execute it together into the 446 bytes of MBR
> > space you have.
>
> I like this idea a lot. Backwards compatible is hugely important.
>
>
> > This way, your new payloads can just find and parse/load/execute
> > the descriptor itself without having to provide any BIOS interface,
> > but the thing is still compatible with existing legacy BIOSes as
> > well.)
>
> I am sold.
>
>
> Ron, I will make you a deal: If we use Concise Binary Object Representation
> (CBOR, RFC 7049) for the MBR data then its working format can be JSON.
>
> I'd be interested in writing the x86 code.
>
>
> //Peter
>
> --
> coreboot mailing list: coreboot@coreboot.org
> https://www.coreboot.org/mailman/listinfo/coreboot
>
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Rettungsboot

[Peter Stuge]

Julius Werner wrote:
> If you really can't stand the idea of BIOS interrupts and real mode,

I for one can't.


> I think your next best option would be to try to cram an
> as-small-as-possible binary recovery descriptor and the real mode
> code to parse/load/execute it together into the 446 bytes of MBR
> space you have.

I like this idea a lot. Backwards compatible is hugely important.


> This way, your new payloads can just find and parse/load/execute
> the descriptor itself without having to provide any BIOS interface,
> but the thing is still compatible with existing legacy BIOSes as
> well.)

I am sold.


Ron, I will make you a deal: If we use Concise Binary Object Representation
(CBOR, RFC 7049) for the MBR data then its working format can be JSON.

I'd be interested in writing the x86 code.


//Peter

-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [RFC] Explicitly use C89 (was: Setting C99 by default)

[Gerd Hoffmann]

On Di, 2016-11-29 at 22:40 +0100, Stefan Tauner wrote:
> On Tue, 29 Nov 2016 09:09:48 +0100
> Gerd Hoffmann  wrote:
> 
> > On Di, 2016-11-29 at 00:41 +0100, Stefan Tauner wrote:
> > > Paul can you please - without looking it up - name two new features of
> > > C99 compared to C89?  
> > 
> > Named initializers.
> > That alone is reason enough to prefer c99 over c89 IMHO.
> 
> You are not Paul. I was asking him specifically because I don't think
> that he could name them but still tries to argue about such things
> although he is not proficient enough to evaluate the implications of
> such decisions (and I can't stand that at all). Even with good
> intentions this is a dangerous approach on improving code quality and
> needs to be countered.

I think switching to a more modern C standard is a good approach on
improving code quality.

But, yes, taking the "just flip the switch and see what happens"
approach is dangerous as it can introduce subtle bugs due to language
changes (aliasing rules for example, don't remember whenever that was in
c99 or in c11 though).

cheers,
  Gerd


-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot