Custom-sized, large floppy images?

[Rafael Send]

      Hi,
I'm working on stuffing a bootable Linux distro into coreboot.  In QEMU I
already succeded by using coreboot's built-in kernel loading mechanism, but
that's without SeaBIOS.

I'd love to have it as a SeaBIOS payload so I can also boot other things,
but I guess I'd have to create a custom-sized floppy image for this or
figure out how to create an ELF payload out of a Linux kernel (I'm open to
either, but I wasn't able to find any documentation on the ELF method).

The guy who put Win 3.1 in coreboot attempted the floppy method, but
according to his article he did not find success with this method due to
unknown and complex issues in the floppy-side logic of SeaBIOS.

So, I'm making the question explicit: What would it take to support
custom-sized floppy images? In particular, I'm thinking of a 16MB device...

Alternatively, would it be possible to create an ELF file out of a Linux
kernel+initrd / bootable image?

Cheers,
Rafael

[Mike Banon]

      Hi Rafael,

I believe that, with a little more effort, this guy would have
succeeded at adding a new floppy format. A bit later I'm going to
extend KolibriOS floppy with more cool stuff, and it could go from
1.44MB to beyond 2.88MB even with the compression is used (so wouldn't
fit even into the largest currently supported floppy). However I'm not
afraid and think it could be done easily. And you could quickly debug
it using QEMU, maybe he was trying it only at real hardware and this
was time consuming... Just make a special coreboot+SeaBIOS build for
QEMU and add a floppy there.

Best regards,
Mike Banon

On Fri, Apr 12, 2019 at 9:39 PM Rafael Send <flyingfishfinger(a)gmail.com> wrote:
>
> Hi,
> I'm working on stuffing a bootable Linux distro into coreboot.  In QEMU I already
succeded by using coreboot's built-in kernel loading mechanism, but that's without
SeaBIOS.
>
> I'd love to have it as a SeaBIOS payload so I can also boot other things, but I
guess I'd have to create a custom-sized floppy image for this or figure out how to
create an ELF payload out of a Linux kernel (I'm open to either, but I wasn't able
to find any documentation on the ELF method).
>
> The guy who put Win 3.1 in coreboot attempted the floppy method, but according to his
article he did not find success with this method due to unknown and complex issues in the
floppy-side logic of SeaBIOS.
>
> So, I'm making the question explicit: What would it take to support custom-sized
floppy images? In particular, I'm thinking of a 16MB device...
>
> Alternatively, would it be possible to create an ELF file out of a Linux
kernel+initrd / bootable image?
>
> Cheers,
> Rafael
> _______________________________________________
> SeaBIOS mailing list -- seabios(a)seabios.org
> To unsubscribe send an email to seabios-leave(a)seabios.org

[Rafael Send]

      Hi,
Thanks for the encouragement.
I already "practised" building both coreboot and SeaBIOS separately, albeit
with no modifications.
I'm not a software engineer so it'll be like taking shots in the dark, but
I'll see what I can come up with.

Cheers,
R

Mike Banon <mikebdp2(a)gmail.com> schrieb am Fr., 12. Apr. 2019, 22:52:

  Hi Rafael,

 I believe that, with a little more effort, this guy would have
 succeeded at adding a new floppy format. A bit later I'm going to
 extend KolibriOS floppy with more cool stuff, and it could go from
 1.44MB to beyond 2.88MB even with the compression is used (so wouldn't
 fit even into the largest currently supported floppy). However I'm not
 afraid and think it could be done easily. And you could quickly debug
 it using QEMU, maybe he was trying it only at real hardware and this
 was time consuming... Just make a special coreboot+SeaBIOS build for
 QEMU and add a floppy there.

 Best regards,
 Mike Banon

 On Fri, Apr 12, 2019 at 9:39 PM Rafael Send <flyingfishfinger(a)gmail.com>
 wrote:
 
 Hi,
 I'm working on stuffing a bootable Linux distro into coreboot.  In QEMU
 I
already succeded by using coreboot's built-in kernel loading mechanism,
 but that's without SeaBIOS.
 
 I'd love to have it as a SeaBIOS payload so I can also boot other
 things, but
I guess I'd have to create a custom-sized floppy image for this
 or figure out how to create an ELF payload out of a Linux kernel (I'm open
 to either, but I wasn't able to find any documentation on the ELF method).
 
 The guy who put Win 3.1 in coreboot attempted the floppy method, but
 according to
his article he did not find success with this method due to
 unknown and complex issues in the floppy-side logic of SeaBIOS.
 
 So, I'm making the question explicit: What would it take to support
custom-sized floppy images? In particular, I'm thinking of a 16MB device...
 
 Alternatively, would it be possible to create an ELF file out of a Linux
kernel+initrd / bootable image?
 
 Cheers,
 Rafael
 _______________________________________________
 SeaBIOS mailing list -- seabios(a)seabios.org
 To unsubscribe send an email to seabios-leave(a)seabios.org

[Mike Banon]

      I haven't investigated yet, perhaps it would be easier introducing the
custom floppy sizes that are the multiple of 1.44MB. For example
23,04MB mega floppy (16x floppy) - I think it could be bigger than
your 16MB chip because it will be LZMA compressed (and the remaining
empty space compressed really good). Good luck Rafael.

On Sat, Apr 13, 2019 at 6:58 PM Rafael Send <flyingfishfinger(a)gmail.com> wrote:
>
> Hi,
> Thanks for the encouragement.
> I already "practised" building both coreboot and SeaBIOS separately, albeit
with no modifications.
> I'm not a software engineer so it'll be like taking shots in the dark, but
I'll see what I can come up with.
>
> Cheers,
> R
>
> Mike Banon <mikebdp2(a)gmail.com> schrieb am Fr., 12. Apr. 2019, 22:52:
>>
>> Hi Rafael,
>>
>> I believe that, with a little more effort, this guy would have
>> succeeded at adding a new floppy format. A bit later I'm going to
>> extend KolibriOS floppy with more cool stuff, and it could go from
>> 1.44MB to beyond 2.88MB even with the compression is used (so wouldn't
>> fit even into the largest currently supported floppy). However I'm not
>> afraid and think it could be done easily. And you could quickly debug
>> it using QEMU, maybe he was trying it only at real hardware and this
>> was time consuming... Just make a special coreboot+SeaBIOS build for
>> QEMU and add a floppy there.
>>
>> Best regards,
>> Mike Banon
>>
>> On Fri, Apr 12, 2019 at 9:39 PM Rafael Send <flyingfishfinger(a)gmail.com>
wrote:
>> >
>> > Hi,
>> > I'm working on stuffing a bootable Linux distro into coreboot.  In QEMU
I already succeded by using coreboot's built-in kernel loading mechanism, but
that's without SeaBIOS.
>> >
>> > I'd love to have it as a SeaBIOS payload so I can also boot other
things, but I guess I'd have to create a custom-sized floppy image for this or figure
out how to create an ELF payload out of a Linux kernel (I'm open to either, but I
wasn't able to find any documentation on the ELF method).
>> >
>> > The guy who put Win 3.1 in coreboot attempted the floppy method, but
according to his article he did not find success with this method due to unknown and
complex issues in the floppy-side logic of SeaBIOS.
>> >
>> > So, I'm making the question explicit: What would it take to support
custom-sized floppy images? In particular, I'm thinking of a 16MB device...
>> >
>> > Alternatively, would it be possible to create an ELF file out of a Linux
kernel+initrd / bootable image?
>> >
>> > Cheers,
>> > Rafael
>> > _______________________________________________
>> > SeaBIOS mailing list -- seabios(a)seabios.org
>> > To unsubscribe send an email to seabios-leave(a)seabios.org

[Kevin O'Connor]

      On Fri, Apr 12, 2019 at 11:38:52AM -0700, Rafael Send wrote:
  Hi,
 I'm working on stuffing a bootable Linux distro into coreboot.  In QEMU I
 already succeded by using coreboot's built-in kernel loading mechanism, but
 that's without SeaBIOS.
 
 I'd love to have it as a SeaBIOS payload so I can also boot other things,
 but I guess I'd have to create a custom-sized floppy image for this or
 figure out how to create an ELF payload out of a Linux kernel (I'm open to
 either, but I wasn't able to find any documentation on the ELF method).
 
 The guy who put Win 3.1 in coreboot attempted the floppy method, but
 according to his article he did not find success with this method due to
 unknown and complex issues in the floppy-side logic of SeaBIOS.
 
 So, I'm making the question explicit: What would it take to support
 custom-sized floppy images? In particular, I'm thinking of a 16MB device...
My vague recollection is that various OSes had hard coded expectations
on the types of floppy drives supported.  I did not think it would be
easy to support a floppy size larger than 2.8MB.

It is possible to emulate a hard drive in memory.  However, that would
require code changes.

Cheers,
-Kevin

[Mike Banon]

      Personally I think that either this guy did something incorrectly or
there's a Windows 3.1 bug. Meanwhile, Rafael's Linux-based OS is going
to boot from this floppy like it's a ramdisk, so hopefully should be
indifferent to the custom floppy sizes and would work. I share the
same hopes for KolibriOS: although its' 1.44MB floppy contains really
a LOT of stuff, some cool things like console emulators didn't fit -
so I'm going to create the extended Kolibri floppy version, which will
be either 2.88MB or some custom ( 1.44MB * X ) size.

On Sun, Apr 14, 2019 at 6:12 PM Kevin O'Connor <kevin(a)koconnor.net> wrote:
>
> On Fri, Apr 12, 2019 at 11:38:52AM -0700, Rafael Send wrote:
> > Hi,
> > I'm working on stuffing a bootable Linux distro into coreboot.  In QEMU I
> > already succeded by using coreboot's built-in kernel loading mechanism, but
> > that's without SeaBIOS.
> >
> > I'd love to have it as a SeaBIOS payload so I can also boot other things,
> > but I guess I'd have to create a custom-sized floppy image for this or
> > figure out how to create an ELF payload out of a Linux kernel (I'm open to
> > either, but I wasn't able to find any documentation on the ELF method).
> >
> > The guy who put Win 3.1 in coreboot attempted the floppy method, but
> > according to his article he did not find success with this method due to
> > unknown and complex issues in the floppy-side logic of SeaBIOS.
> >
> > So, I'm making the question explicit: What would it take to support
> > custom-sized floppy images? In particular, I'm thinking of a 16MB device...
>
> My vague recollection is that various OSes had hard coded expectations
> on the types of floppy drives supported.  I did not think it would be
> easy to support a floppy size larger than 2.8MB.
>
> It is possible to emulate a hard drive in memory.  However, that would
> require code changes.
>
> Cheers,
> -Kevin
> _______________________________________________
> SeaBIOS mailing list -- seabios(a)seabios.org
> To unsubscribe send an email to seabios-leave(a)seabios.org

[Rafael Send]

      I haven't gotten around to poking at SeaBIOS yet, I'm still wondering how
to test my large floppies.

Syslinux appears to install to them fine, but QEMU doesn't seem to like
booting them with -fda.

Do you guys have any suggestions on how to test booting the large floppy
images?

Cheers,
R



Mike Banon <mikebdp2(a)gmail.com> schrieb am Mo., 15. Apr. 2019, 05:35:

  Personally I think that either this guy did something
incorrectly or
 there's a Windows 3.1 bug. Meanwhile, Rafael's Linux-based OS is going
 to boot from this floppy like it's a ramdisk, so hopefully should be
 indifferent to the custom floppy sizes and would work. I share the
 same hopes for KolibriOS: although its' 1.44MB floppy contains really
 a LOT of stuff, some cool things like console emulators didn't fit -
 so I'm going to create the extended Kolibri floppy version, which will
 be either 2.88MB or some custom ( 1.44MB * X ) size.

 On Sun, Apr 14, 2019 at 6:12 PM Kevin O'Connor <kevin(a)koconnor.net> wrote:
 
 On Fri, Apr 12, 2019 at 11:38:52AM -0700, Rafael Send wrote:
 > Hi,
 > I'm working on stuffing a bootable Linux distro into coreboot.  In
 QEMU
I
  > already succeded by using coreboot's
built-in kernel loading
 mechanism, but
  > that's without SeaBIOS.
 >
 > I'd love to have it as a SeaBIOS payload so I can also boot other
things,
  > but I guess I'd have to create a
custom-sized floppy image for this or
 > figure out how to create an ELF payload out of a Linux kernel (I'm
 open
to
  > either, but I wasn't able to find any
documentation on the ELF method).
 >
 > The guy who put Win 3.1 in coreboot attempted the floppy method, but
 > according to his article he did not find success with this method due
 to
  > unknown and complex issues in the
floppy-side logic of SeaBIOS.
 >
 > So, I'm making the question explicit: What would it take to support
 > custom-sized floppy images? In particular, I'm thinking of a 16MB
device...
 
 My vague recollection is that various OSes had hard coded expectations
 on the types of floppy drives supported.  I did not think it would be
 easy to support a floppy size larger than 2.8MB.

 It is possible to emulate a hard drive in memory.  However, that would
 require code changes.

 Cheers,
 -Kevin
 _______________________________________________
 SeaBIOS mailing list -- seabios(a)seabios.org
 To unsubscribe send an email to seabios-leave(a)seabios.org

[Mike Banon]

      You need to build a coreboot image for QEMU with SeaBIOS (master)
selected as the default payload. CBFS size should be increased to a
size large enough to contain your floppy (or floppies, btw here's a
patch to support multiple floppies at CBFS -
https://review.coreboot.org/c/coreboot/+/32238 , and you could install
it with this script - https://pastebin.com/raw/hv9sSuMU , more details
here -
https://mail.coreboot.org/hyperkitty/list/[e-mail]/thread/CKWLNT…
) . After it will be compiled, you could use cbfstool to add/remove
floppies to/from CBFS of coreboot.rom, with LZMA compression to reduce
their size:
1) Add: ./build/cbfstool ./build/coreboot.rom add -f
./path_to/myfloppy.img -n floppyimg/myfloppy.lzma -t raw -c lzma
2) Remove (e.g. to add a new version later): ./build/cbfstool
./build/coreboot.rom remove -n floppyimg/myfloppy.lzma
3) Print a memory map: ./build/cbfstool ./build/coreboot.rom print
Run this coreboot.rom by executing this QEMU command: (some floppies are 64-bit)
qemu-system-x86_64 -L . -m 768 -localtime -vga vmware -net nic,model=rtl8139 \
 -net user -soundhw ac97 -bios ./coreboot.rom -boot menu=on -serial stdio
Best regards,
Mike Banon

On Mon, Apr 15, 2019 at 6:12 PM Rafael Send <flyingfishfinger(a)gmail.com> wrote:
>
> I haven't gotten around to poking at SeaBIOS yet, I'm still wondering how to
test my large floppies.
>
> Syslinux appears to install to them fine, but QEMU doesn't seem to like booting
them with -fda.
>
> Do you guys have any suggestions on how to test booting the large floppy images?
>
> Cheers,
> R
>
>
>
> Mike Banon <mikebdp2(a)gmail.com> schrieb am Mo., 15. Apr. 2019, 05:35:
>>
>> Personally I think that either this guy did something incorrectly or
>> there's a Windows 3.1 bug. Meanwhile, Rafael's Linux-based OS is going
>> to boot from this floppy like it's a ramdisk, so hopefully should be
>> indifferent to the custom floppy sizes and would work. I share the
>> same hopes for KolibriOS: although its' 1.44MB floppy contains really
>> a LOT of stuff, some cool things like console emulators didn't fit -
>> so I'm going to create the extended Kolibri floppy version, which will
>> be either 2.88MB or some custom ( 1.44MB * X ) size.
>>
>> On Sun, Apr 14, 2019 at 6:12 PM Kevin O'Connor <kevin(a)koconnor.net>
wrote:
>> >
>> > On Fri, Apr 12, 2019 at 11:38:52AM -0700, Rafael Send wrote:
>> > > Hi,
>> > > I'm working on stuffing a bootable Linux distro into coreboot.  In
QEMU I
>> > > already succeded by using coreboot's built-in kernel loading
mechanism, but
>> > > that's without SeaBIOS.
>> > >
>> > > I'd love to have it as a SeaBIOS payload so I can also boot other
things,
>> > > but I guess I'd have to create a custom-sized floppy image for this
or
>> > > figure out how to create an ELF payload out of a Linux kernel (I'm
open to
>> > > either, but I wasn't able to find any documentation on the ELF
method).
>> > >
>> > > The guy who put Win 3.1 in coreboot attempted the floppy method, but
>> > > according to his article he did not find success with this method due
to
>> > > unknown and complex issues in the floppy-side logic of SeaBIOS.
>> > >
>> > > So, I'm making the question explicit: What would it take to
support
>> > > custom-sized floppy images? In particular, I'm thinking of a 16MB
device...
>> >
>> > My vague recollection is that various OSes had hard coded expectations
>> > on the types of floppy drives supported.  I did not think it would be
>> > easy to support a floppy size larger than 2.8MB.
>> >
>> > It is possible to emulate a hard drive in memory.  However, that would
>> > require code changes.
>> >
>> > Cheers,
>> > -Kevin
>> > _______________________________________________
>> > SeaBIOS mailing list -- seabios(a)seabios.org
>> > To unsubscribe send an email to seabios-leave(a)seabios.org

[Rafael Send]

      Thanks,
I had already played with building SeaBIOS+coreboot in the "default"
configuration for QEMU with various common payloads.

I meant I haven't gotten around to poking at the SeaBIOS code for larger
floppies yet :)

R

Mike Banon <mikebdp2(a)gmail.com> schrieb am Di., 16. Apr. 2019, 01:39:

  You need to build a coreboot image for QEMU with
SeaBIOS (master)
 selected as the default payload. CBFS size should be increased to a
 size large enough to contain your floppy (or floppies, btw here's a
 patch to support multiple floppies at CBFS -
 https://review.coreboot.org/c/coreboot/+/32238 , and you could install
 it with this script - https://pastebin.com/raw/hv9sSuMU , more details
 here -

https://mail.coreboot.org/hyperkitty/list/[e-mail]/thread/CKWLNT…
 ) . After it will be compiled, you could use cbfstool to add/remove
 floppies to/from CBFS of coreboot.rom, with LZMA compression to reduce
 their size:
 1) Add: ./build/cbfstool ./build/coreboot.rom add -f
 ./path_to/myfloppy.img -n floppyimg/myfloppy.lzma -t raw -c lzma
 2) Remove (e.g. to add a new version later): ./build/cbfstool
 ./build/coreboot.rom remove -n floppyimg/myfloppy.lzma
 3) Print a memory map: ./build/cbfstool ./build/coreboot.rom print
 Run this coreboot.rom by executing this QEMU command: (some floppies are
 64-bit)
 qemu-system-x86_64 -L . -m 768 -localtime -vga vmware -net
 nic,model=rtl8139 \
  -net user -soundhw ac97 -bios ./coreboot.rom -boot menu=on -serial stdio
 Best regards,
 Mike Banon

 On Mon, Apr 15, 2019 at 6:12 PM Rafael Send <flyingfishfinger(a)gmail.com>
 wrote:
 
 I haven't gotten around to poking at SeaBIOS yet, I'm still wondering
 how
to test my large floppies.
 
 Syslinux appears to install to them fine, but QEMU doesn't seem to like
booting them with -fda.
 
 Do you guys have any suggestions on how to test booting the large floppy
 images?
 
 Cheers,
 R



 Mike Banon <mikebdp2(a)gmail.com> schrieb am Mo., 15. Apr. 2019, 05:35:
>
> Personally I think that either this guy did something incorrectly or
> there's a Windows 3.1 bug. Meanwhile, Rafael's Linux-based OS is going
> to boot from this floppy like it's a ramdisk, so hopefully should be
> indifferent to the custom floppy sizes and would work. I share the
> same hopes for KolibriOS: although its' 1.44MB floppy contains really
> a LOT of stuff, some cool things like console emulators didn't fit -
> so I'm going to create the extended Kolibri floppy version, which will
> be either 2.88MB or some custom ( 1.44MB * X ) size.
>
> On Sun, Apr 14, 2019 at 6:12 PM Kevin O'Connor <kevin(a)koconnor.net>
wrote:
 > >
> > On Fri, Apr 12, 2019 at 11:38:52AM -0700, Rafael Send wrote:
> > > Hi,
> > > I'm working on stuffing a bootable Linux distro into coreboot.  In
 QEMU I
 > > > already succeded by using
coreboot's built-in kernel loading
 mechanism, but
 > > > that's without SeaBIOS.
> > >
> > > I'd love to have it as a SeaBIOS payload so I can also boot other
 things,
 > > > but I guess I'd have to create
a custom-sized floppy image for this
 or
 > > > figure out how to create an ELF
payload out of a Linux kernel (I'm
 open to
 > > > either, but I wasn't able to
find any documentation on the ELF
 method).
 > > >
> > > The guy who put Win 3.1 in coreboot attempted the floppy method, but
> > > according to his article he did not find success with this method
due to
 > > > unknown and complex issues in the
floppy-side logic of SeaBIOS.
> > >
> > > So, I'm making the question explicit: What would it take to support
> > > custom-sized floppy images? In particular, I'm thinking of a 16MB
 device...
 > >
> > My vague recollection is that various OSes had hard coded expectations
> > on the types of floppy drives supported.  I did not think it would be
> > easy to support a floppy size larger than 2.8MB.
> >
> > It is possible to emulate a hard drive in memory.  However, that would
> > require code changes.
> >
> > Cheers,
> > -Kevin
> > _______________________________________________
> > SeaBIOS mailing list -- seabios(a)seabios.org
> > To unsubscribe send an email to seabios-leave(a)seabios.org

[Mike Banon]

      Hopefully, simply inserting some stuff to
./payloads/external/SeaBIOS/seabios/src/hw/floppy.c (lines 80-108)
should be enough, but I haven't tried ;-) By the way, at my
"multiple_floppies.patch" I'm doing this:

+ // Find the max floppy size
+ for (;;) {
+ // Find the next image.
+ file = romfile_findprefix("floppyimg/", file);
+ if (!file)
+ break;
+ filename = file->name;
+ size = file->size;
+ dprintf(3, "Found floppy file %s of size %d\n", filename, size);
+ // Check if this size is valid.
+ ftype = find_floppy_type(size);
+ if (ftype < 0) {
+ dprintf(3, "No floppy type found for ramdisk size\n");
+ } else {
+ if (size > max_size)
+ max_size = size;
+ }
+ }

That's to determine, how much memory we should allocate for the
purpose of loading the selected floppy there (allocate the maximum
floppy size - so that any selected floppy will fit there). This code
should be compatible with any new sizes as well, but let me know if
there are any problems. When you're running QEMU with -serial stdio ,
it should output those debug messages into your console, if the debug
level of these messages is higher than what's set at your SeaBIOS
config.

Best regards,
Mike Banon

On Tue, Apr 16, 2019 at 6:49 PM Rafael Send &lt;flyingfishfinger(a)gmail.com&gt; wrote:
>
> Thanks,
> I had already played with building SeaBIOS+coreboot in the "default"
configuration for QEMU with various common payloads.
>
> I meant I haven't gotten around to poking at the SeaBIOS code for larger floppies
yet :)
>
> R
>
> Mike Banon &lt;mikebdp2(a)gmail.com&gt; schrieb am Di., 16. Apr. 2019, 01:39:
>>
>> You need to build a coreboot image for QEMU with SeaBIOS (master)
>> selected as the default payload. CBFS size should be increased to a
>> size large enough to contain your floppy (or floppies, btw here's a
>> patch to support multiple floppies at CBFS -
>> https://review.coreboot.org/c/coreboot/+/32238 , and you could install
>> it with this script - https://pastebin.com/raw/hv9sSuMU , more details
>> here -
https://mail.coreboot.org/hyperkitty/list/[e-mail]/thread/CKWLNT…
>> ) . After it will be compiled, you could use cbfstool to add/remove
>> floppies to/from CBFS of coreboot.rom, with LZMA compression to reduce
>> their size:
>> 1) Add: ./build/cbfstool ./build/coreboot.rom add -f
>> ./path_to/myfloppy.img -n floppyimg/myfloppy.lzma -t raw -c lzma
>> 2) Remove (e.g. to add a new version later): ./build/cbfstool
>> ./build/coreboot.rom remove -n floppyimg/myfloppy.lzma
>> 3) Print a memory map: ./build/cbfstool ./build/coreboot.rom print
>> Run this coreboot.rom by executing this QEMU command: (some floppies are 64-bit)
>> qemu-system-x86_64 -L . -m 768 -localtime -vga vmware -net nic,model=rtl8139 \
>>  -net user -soundhw ac97 -bios ./coreboot.rom -boot menu=on -serial stdio
>> Best regards,
>> Mike Banon
>>
>> On Mon, Apr 15, 2019 at 6:12 PM Rafael Send &lt;flyingfishfinger(a)gmail.com&gt;
wrote:
>> >
>> > I haven't gotten around to poking at SeaBIOS yet, I'm still
wondering how to test my large floppies.
>> >
>> > Syslinux appears to install to them fine, but QEMU doesn't seem to like
booting them with -fda.
>> >
>> > Do you guys have any suggestions on how to test booting the large floppy
images?
>> >
>> > Cheers,
>> > R
>> >
>> >
>> >
>> > Mike Banon &lt;mikebdp2(a)gmail.com&gt; schrieb am Mo., 15. Apr. 2019, 05:35:
>> >>
>> >> Personally I think that either this guy did something incorrectly or
>> >> there's a Windows 3.1 bug. Meanwhile, Rafael's Linux-based OS is
going
>> >> to boot from this floppy like it's a ramdisk, so hopefully should
be
>> >> indifferent to the custom floppy sizes and would work. I share the
>> >> same hopes for KolibriOS: although its' 1.44MB floppy contains
really
>> >> a LOT of stuff, some cool things like console emulators didn't fit
-
>> >> so I'm going to create the extended Kolibri floppy version, which
will
>> >> be either 2.88MB or some custom ( 1.44MB * X ) size.
>> >>
>> >> On Sun, Apr 14, 2019 at 6:12 PM Kevin O'Connor
&lt;kevin(a)koconnor.net&gt; wrote:
>> >> >
>> >> > On Fri, Apr 12, 2019 at 11:38:52AM -0700, Rafael Send wrote:
>> >> > > Hi,
>> >> > > I'm working on stuffing a bootable Linux distro into
coreboot.  In QEMU I
>> >> > > already succeded by using coreboot's built-in kernel
loading mechanism, but
>> >> > > that's without SeaBIOS.
>> >> > >
>> >> > > I'd love to have it as a SeaBIOS payload so I can also
boot other things,
>> >> > > but I guess I'd have to create a custom-sized floppy image
for this or
>> >> > > figure out how to create an ELF payload out of a Linux kernel
(I'm open to
>> >> > > either, but I wasn't able to find any documentation on the
ELF method).
>> >> > >
>> >> > > The guy who put Win 3.1 in coreboot attempted the floppy
method, but
>> >> > > according to his article he did not find success with this
method due to
>> >> > > unknown and complex issues in the floppy-side logic of
SeaBIOS.
>> >> > >
>> >> > > So, I'm making the question explicit: What would it take
to support
>> >> > > custom-sized floppy images? In particular, I'm thinking of
a 16MB device...
>> >> >
>> >> > My vague recollection is that various OSes had hard coded
expectations
>> >> > on the types of floppy drives supported.  I did not think it would
be
>> >> > easy to support a floppy size larger than 2.8MB.
>> >> >
>> >> > It is possible to emulate a hard drive in memory.  However, that
would
>> >> > require code changes.
>> >> >
>> >> > Cheers,
>> >> > -Kevin
>> >> > _______________________________________________
>> >> > SeaBIOS mailing list -- seabios(a)seabios.org
>> >> > To unsubscribe send an email to seabios-leave(a)seabios.org

[Rafael Send]

      Hi,
I got close.

Using a 16MB floppy image, I added a size with 8 heads, 32 sectors and 128
tracks to SeaBIOS, which adds up to the right size.

After adding it to coreboot / SeaBIOS, I was able to select it as a Ramdisk
with its correct name.

I got the Syslinux boot logo (that is what's installed on my floppy image),
so I'm assuming that SeaBIOS found my image correctly and didn't barf
(Yay?).

However, it hangs after that and doesn't boot my kernel. I tested this
image successfully with memdisk / GRUB, so it should work. Since I don't
get a syslinux prompt either, I'm not sure how to continue.

Any ideas?

Cheers,
R

On Tue, Apr 16, 2019 at 9:35 AM Mike Banon <mikebdp2(a)gmail.com> wrote:

  Hopefully, simply inserting some stuff to
 ./payloads/external/SeaBIOS/seabios/src/hw/floppy.c (lines 80-108)
 should be enough, but I haven't tried ;-) By the way, at my
 "multiple_floppies.patch" I'm doing this:

 + // Find the max floppy size
 + for (;;) {
 + // Find the next image.
 + file = romfile_findprefix("floppyimg/", file);
 + if (!file)
 + break;
 + filename = file->name;
 + size = file->size;
 + dprintf(3, "Found floppy file %s of size %d\n", filename, size);
 + // Check if this size is valid.
 + ftype = find_floppy_type(size);
 + if (ftype < 0) {
 + dprintf(3, "No floppy type found for ramdisk size\n");
 + } else {
 + if (size > max_size)
 + max_size = size;
 + }
 + }

 That's to determine, how much memory we should allocate for the
 purpose of loading the selected floppy there (allocate the maximum
 floppy size - so that any selected floppy will fit there). This code
 should be compatible with any new sizes as well, but let me know if
 there are any problems. When you're running QEMU with -serial stdio ,
 it should output those debug messages into your console, if the debug
 level of these messages is higher than what's set at your SeaBIOS
 config.

 Best regards,
 Mike Banon

 On Tue, Apr 16, 2019 at 6:49 PM Rafael Send &lt;flyingfishfinger(a)gmail.com&gt;
 wrote:
 
 Thanks,
 I had already played with building SeaBIOS+coreboot in the "default"
configuration for QEMU with various common payloads.
 
 I meant I haven't gotten around to poking at the SeaBIOS code for larger
floppies yet :)
 
 R

 Mike Banon &lt;mikebdp2(a)gmail.com&gt; schrieb am Di., 16. Apr. 2019, 01:39:
>
> You need to build a coreboot image for QEMU with SeaBIOS (master)
> selected as the default payload. CBFS size should be increased to a
> size large enough to contain your floppy (or floppies, btw here's a
> patch to support multiple floppies at CBFS -
> https://review.coreboot.org/c/coreboot/+/32238 , and you could install
> it with this script - https://pastebin.com/raw/hv9sSuMU , more details
> here -
https://mail.coreboot.org/hyperkitty/list/[e-mail]/thread/CKWLNT…
 > ) . After it will be compiled, you could use
cbfstool to add/remove
> floppies to/from CBFS of coreboot.rom, with LZMA compression to reduce
> their size:
> 1) Add: ./build/cbfstool ./build/coreboot.rom add -f
> ./path_to/myfloppy.img -n floppyimg/myfloppy.lzma -t raw -c lzma
> 2) Remove (e.g. to add a new version later): ./build/cbfstool
> ./build/coreboot.rom remove -n floppyimg/myfloppy.lzma
> 3) Print a memory map: ./build/cbfstool ./build/coreboot.rom print
> Run this coreboot.rom by executing this QEMU command: (some floppies
 are
64-bit)
 > qemu-system-x86_64 -L . -m 768 -localtime
-vga vmware -net
 nic,model=rtl8139 \
 >  -net user -soundhw ac97 -bios ./coreboot.rom
-boot menu=on -serial
 stdio
 > Best regards,
> Mike Banon
>
> On Mon, Apr 15, 2019 at 6:12 PM Rafael Send &lt;flyingfishfinger(a)gmail.com&gt;
wrote:
 > >
> > I haven't gotten around to poking at SeaBIOS yet, I'm still wondering
 how to test my large floppies.
 > >
> > Syslinux appears to install to them fine, but QEMU doesn't seem to
like booting them with -fda.
 > >
> > Do you guys have any suggestions on how to test booting the large
 floppy
images?
 > >
> > Cheers,
> > R
> >
> >
> >
> > Mike Banon &lt;mikebdp2(a)gmail.com&gt; schrieb am Mo., 15. Apr. 2019, 05:35:
> >>
> >> Personally I think that either this guy did something incorrectly or
> >> there's a Windows 3.1 bug. Meanwhile, Rafael's Linux-based OS is
 going
 > >> to boot from this floppy like
it's a ramdisk, so hopefully should be
> >> indifferent to the custom floppy sizes and would work. I share the
> >> same hopes for KolibriOS: although its' 1.44MB floppy contains really
> >> a LOT of stuff, some cool things like console emulators didn't fit -
> >> so I'm going to create the extended Kolibri floppy version, which
will
 > >> be either 2.88MB or some custom (
1.44MB * X ) size.
> >>
> >> On Sun, Apr 14, 2019 at 6:12 PM Kevin O'Connor
&lt;kevin(a)koconnor.net&gt;
 wrote:
 > >> >
> >> > On Fri, Apr 12, 2019 at 11:38:52AM -0700, Rafael Send wrote:
> >> > > Hi,
> >> > > I'm working on stuffing a bootable Linux distro into coreboot.
 In QEMU I
 > >> > > already succeded by using
coreboot's built-in kernel loading
 mechanism, but
 > >> > > that's without
SeaBIOS.
> >> > >
> >> > > I'd love to have it as a SeaBIOS payload so I can also boot
 other things,
 > >> > > but I guess I'd have
to create a custom-sized floppy image for
 this or
 > >> > > figure out how to create
an ELF payload out of a Linux kernel
 (I'm open to
 > >> > > either, but I wasn't
able to find any documentation on the ELF
 method).
 > >> > >
> >> > > The guy who put Win 3.1 in coreboot attempted the floppy method,
 but
 > >> > > according to his article
he did not find success with this
 method due to
 > >> > > unknown and complex issues
in the floppy-side logic of SeaBIOS.
> >> > >
> >> > > So, I'm making the question explicit: What would it take to
 support
 > >> > > custom-sized floppy
images? In particular, I'm thinking of a
 16MB device...
 > >> >
> >> > My vague recollection is that various OSes had hard coded
expectations
 > >> > on the types of floppy drives
supported.  I did not think it would
 be
 > >> > easy to support a floppy size
larger than 2.8MB.
> >> >
> >> > It is possible to emulate a hard drive in memory.  However, that
would
 > >> > require code changes.
> >> >
> >> > Cheers,
> >> > -Kevin
> >> > _______________________________________________
> >> > SeaBIOS mailing list -- seabios(a)seabios.org
> >> > To unsubscribe send an email to seabios-leave(a)seabios.org

[Mike Banon]

  However, it hangs after that and doesn't boot my
kernel.
This looks like for some reason SeaBIOS might have loaded only some
beginning part of your floppy image instead of it whole. Do you use
any of my unofficial patches currently or just the SeaBIOS master? You
could insert some debug prints to the floppy loading / memory
allocation functions, or simply enable the max debug level at SeaBIOS
(I think that could be configured at coreboot's menuconfig as well)
and see if that would be enough debug info to understand what's going
on.

[Rafael Send]

      Mike-
The print statements didn't really help too much (so far).
However, I did get a TINY bit further by playing with the disk geometry.
Now I get:

"Loading vmlinuz...CHS: Error 0101 reading sector 18277 (8/59/6)
Loading core.gz...CHS: Error 0101 reading sector 457 (0/16/1)
Booting kernel failed: Invalid argument"

It seems to me that those numbers aren't near any of the values I set
(64/16/32).

I'll keep poking at it and see if I can get any further improvements...

R

On Wed, Apr 17, 2019 at 9:14 PM Mike Banon <mikebdp2(a)gmail.com> wrote:

  However, it
hangs after that and doesn't boot my kernel.
 This looks like for some reason SeaBIOS might have loaded only some
 beginning part of your floppy image instead of it whole. Do you use
 any of my unofficial patches currently or just the SeaBIOS master? You
 could insert some debug prints to the floppy loading / memory
 allocation functions, or simply enable the max debug level at SeaBIOS
 (I think that could be configured at coreboot's menuconfig as well)
 and see if that would be enough debug info to understand what's going
 on.

[Rafael Send]

      FWIW, for my large floppy the size is detected correctly, as in the
following output:

"phys_alloc zone=0x07f41ea8 size=16777216 align =1000 ret=6f2f000
(detail=0x07f315b0)"

It LOOKS like it's also being assigned correctly...

R

On Thu, Apr 18, 2019 at 1:49 PM Rafael Send <flyingfishfinger(a)gmail.com>
wrote:

  Mike-
 The print statements didn't really help too much (so far).
 However, I did get a TINY bit further by playing with the disk geometry.
 Now I get:

 "Loading vmlinuz...CHS: Error 0101 reading sector 18277 (8/59/6)
 Loading core.gz...CHS: Error 0101 reading sector 457 (0/16/1)
 Booting kernel failed: Invalid argument"

 It seems to me that those numbers aren't near any of the values I set
 (64/16/32).

 I'll keep poking at it and see if I can get any further improvements...

 R

 On Wed, Apr 17, 2019 at 9:14 PM Mike Banon <mikebdp2(a)gmail.com> wrote:

  However,
it hangs after that and doesn't boot my kernel.
 This looks like for some reason SeaBIOS might have loaded only some
 beginning part of your floppy image instead of it whole. Do you use
 any of my unofficial patches currently or just the SeaBIOS master? You
 could insert some debug prints to the floppy loading / memory
 allocation functions, or simply enable the max debug level at SeaBIOS
 (I think that could be configured at coreboot's menuconfig as well)
 and see if that would be enough debug info to understand what's going
 on.

[Mike Banon]

  "Loading vmlinuz...CHS: Error 0101 reading sector
18277 (8/59/6)
 Loading core.gz...CHS: Error 0101 reading sector 457 (0/16/1)
 Booting kernel failed: Invalid argument"
What is the sector size here? If you could somehow check that e.g. it
can't read any sectors beyond X - so can't access any memory after X
KB or MB - that should tell us more about this problem.

  It seems to me that those numbers aren't near any
of the values I set (64/16/32).
Where do you set these values and what do they mean? E.g. when I
checked the structure at floppy.c , there is stuff like

      // 5 - 2.88MB, 3.5" - 2 heads, 80 tracks, 36
sectors
    { {2, 80, 36}, FLOPPY_SIZE_350, FLOPPY_RATE_1M},
- {2, 80, 36} group of values, so I'm going to introduce something like

#define FLOPPY_RATE_1M   0x04
...
    // 6 - 14.4MB, 3.5" - 2 heads, 80 tracks, 180 sectors
    { {2, 80, 180}, FLOPPY_SIZE_350, FLOPPY_RATE_8M},

because I just realized that, following the difference between 1.44MB
and 2.88MB floppies, the floppy's data_rate should be increased as
well! In this case, somewhere below in the same floppy.c I should look
how the existing data_rate are handled and do something similar.

Alternatively, it may be easier to increase the number of tracks:

    // 6 - 14.4MB, 3.5" - 2 heads, 800 tracks, 18 sectors
    { {2, 800, 18}, FLOPPY_SIZE_350, FLOPPY_RATE_1M}, (not sure if I
should do something with floppy's data_rate in this case, maybe just
leave it as 1M)

However it seems I'll have to increase the max_track value at line 69
from 79 to 799 . (also, why at line 61 there's "18" sectors and not
"36" ? (the number of sectors at the largest 2.88MB floppy)) ...

So I'm sure that a larger floppy format is doable, just need to play
with this stuff for a while...

Best regard,
Mike Banon

On Fri, Apr 19, 2019 at 1:45 AM Rafael Send <flyingfishfinger(a)gmail.com> wrote:
>
> FWIW, for my large floppy the size is detected correctly, as in the following
output:
>
> "phys_alloc zone=0x07f41ea8 size=16777216 align =1000 ret=6f2f000 
(detail=0x07f315b0)"
>
> It LOOKS like it's also being assigned correctly...
>
> R
>
> On Thu, Apr 18, 2019 at 1:49 PM Rafael Send <flyingfishfinger(a)gmail.com>
wrote:
>>
>> Mike-
>> The print statements didn't really help too much (so far).
>> However, I did get a TINY bit further by playing with the disk geometry. Now I
get:
>>
>> "Loading vmlinuz...CHS: Error 0101 reading sector 18277 (8/59/6)
>> Loading core.gz...CHS: Error 0101 reading sector 457 (0/16/1)
>> Booting kernel failed: Invalid argument"
>>
>
  It seems to me that those numbers aren't near any
of the values I set (64/16/32).
>>
>> I'll keep poking at it and see if I can get any further improvements...
>>
>> R
>>
>> On Wed, Apr 17, 2019 at 9:14 PM Mike Banon <mikebdp2(a)gmail.com> wrote:
>>>
>>> > However, it hangs after that and doesn't boot my kernel.
>>>
>>> This looks like for some reason SeaBIOS might have loaded only some
>>> beginning part of your floppy image instead of it whole. Do you use
>>> any of my unofficial patches currently or just the SeaBIOS master? You
>>> could insert some debug prints to the floppy loading / memory
>>> allocation functions, or simply enable the max debug level at SeaBIOS
>>> (I think that could be configured at coreboot's menuconfig as well)
>>> and see if that would be enough debug info to understand what's going
>>> on.

[Rafael Send]

      Mike-
I left the datarate as is, but I did introduce a new line for a new "type"
of floppy in the area you mention, yes.

Sector size should still be 512, I didn't touch anything I didn't feel like
I needed to.

According to my research, the maximum number of tracks can never be more
than 1024 based on the bit width of that field, but I stuck with less than
79 because of the max_track value. I did try increasing it once, and it
failed completely.

For the heads, the bit field / BIOS limit is 16, and the sector count
should be allowed to go up to 63.

That gives only a few possible combinations to arrive at 16MB. I've tried
some of them that result in the same error, and some don't work at all.

The issue is it always fails to read at the same CHS values, so I don't
know how to tell how "high" it really can get

I can try building an 8MB image and see if that's any better I guess.

Thanks for the suggestions thus far,

R

On Thu, Apr 18, 2019 at 9:59 PM Mike Banon <mikebdp2(a)gmail.com> wrote:

  "Loading
vmlinuz...CHS: Error 0101 reading sector 18277 (8/59/6)
 Loading core.gz...CHS: Error 0101 reading sector 457 (0/16/1)
 Booting kernel failed: Invalid argument"
 What is the sector size here? If you could somehow check that e.g. it
 can't read any sectors beyond X - so can't access any memory after X
 KB or MB - that should tell us more about this problem.

  It seems to me that those numbers aren't near
any of the values I set
 (64/16/32).

 Where do you set these values and what do they mean? E.g. when I
 checked the structure at floppy.c , there is stuff like

      // 5 - 2.88MB, 3.5" - 2 heads, 80
tracks, 36 sectors
    { {2, 80, 36}, FLOPPY_SIZE_350, FLOPPY_RATE_1M},
 - {2, 80, 36} group of values, so I'm going to introduce something like

 #define FLOPPY_RATE_1M   0x04
 ...
     // 6 - 14.4MB, 3.5" - 2 heads, 80 tracks, 180 sectors
     { {2, 80, 180}, FLOPPY_SIZE_350, FLOPPY_RATE_8M},

 because I just realized that, following the difference between 1.44MB
 and 2.88MB floppies, the floppy's data_rate should be increased as
 well! In this case, somewhere below in the same floppy.c I should look
 how the existing data_rate are handled and do something similar.

 Alternatively, it may be easier to increase the number of tracks:

     // 6 - 14.4MB, 3.5" - 2 heads, 800 tracks, 18 sectors
     { {2, 800, 18}, FLOPPY_SIZE_350, FLOPPY_RATE_1M}, (not sure if I
 should do something with floppy's data_rate in this case, maybe just
 leave it as 1M)

 However it seems I'll have to increase the max_track value at line 69
 from 79 to 799 . (also, why at line 61 there's "18" sectors and not
 "36" ? (the number of sectors at the largest 2.88MB floppy)) ...

 So I'm sure that a larger floppy format is doable, just need to play
 with this stuff for a while...

 Best regard,
 Mike Banon

 On Fri, Apr 19, 2019 at 1:45 AM Rafael Send <flyingfishfinger(a)gmail.com>
 wrote:
 
 FWIW, for my large floppy the size is detected correctly, as in the
 following
output:
 
 "phys_alloc zone=0x07f41ea8 size=16777216 align =1000 ret=6f2f000
(detail=0x07f315b0)"
 
 It LOOKS like it's also being assigned correctly...

 R

 On Thu, Apr 18, 2019 at 1:49 PM Rafael Send <flyingfishfinger(a)gmail.com>
wrote:
 >
> Mike-
> The print statements didn't really help too much (so far).
> However, I did get a TINY bit further by playing with the disk
 geometry. Now I
get:
 >
> "Loading vmlinuz...CHS: Error 0101 reading sector 18277 (8/59/6)
> Loading core.gz...CHS: Error 0101 reading sector 457 (0/16/1)
> Booting kernel failed: Invalid argument"
>
> It seems to me that those numbers aren't near any of the values I set
(64/16/32).
 >
> I'll keep poking at it and see if I can get any further improvements...
>
> R
>
> On Wed, Apr 17, 2019 at 9:14 PM Mike Banon <mikebdp2(a)gmail.com> wrote:
>>
>> > However, it hangs after that and doesn't boot my kernel.
>>
>> This looks like for some reason SeaBIOS might have loaded only some
>> beginning part of your floppy image instead of it whole. Do you use
>> any of my unofficial patches currently or just the SeaBIOS master? You
>> could insert some debug prints to the floppy loading / memory
>> allocation functions, or simply enable the max debug level at SeaBIOS
>> (I think that could be configured at coreboot's menuconfig as well)
>> and see if that would be enough debug info to understand what's going
>> on.

[Mike Banon]

      Could you please calculate, where's a memory area which is matching
these CHS values? Also, if the sector count value is limited by 63, I
wonder if this data type could be expanded by a couple of bits to make
it limited by 255 instead - to ensure that my proposed "180 sectors"
fits there.

On Fri, Apr 19, 2019 at 8:19 AM Rafael Send <flyingfishfinger(a)gmail.com> wrote:
>
> Mike-
> I left the datarate as is, but I did introduce a new line for a new "type"
of floppy in the area you mention, yes.
>
> Sector size should still be 512, I didn't touch anything I didn't feel like I
needed to.
>
> According to my research, the maximum number of tracks can never be more than 1024
based on the bit width of that field, but I stuck with less than 79 because of the
max_track value. I did try increasing it once, and it failed completely.
>
> For the heads, the bit field / BIOS limit is 16, and the sector count should be
allowed to go up to 63.
>
> That gives only a few possible combinations to arrive at 16MB. I've tried some of
them that result in the same error, and some don't work at all.
>
> The issue is it always fails to read at the same CHS values, so I don't know how
to tell how "high" it really can get
>
> I can try building an 8MB image and see if that's any better I guess.
>
> Thanks for the suggestions thus far,
>
> R
>
> On Thu, Apr 18, 2019 at 9:59 PM Mike Banon <mikebdp2(a)gmail.com> wrote:
>>
>> > "Loading vmlinuz...CHS: Error 0101 reading sector 18277 (8/59/6)
>> > Loading core.gz...CHS: Error 0101 reading sector 457 (0/16/1)
>> > Booting kernel failed: Invalid argument"
>>
>> What is the sector size here? If you could somehow check that e.g. it
>> can't read any sectors beyond X - so can't access any memory after X
>> KB or MB - that should tell us more about this problem.
>>
>> > It seems to me that those numbers aren't near any of the values I set
(64/16/32).
>>
>> Where do you set these values and what do they mean? E.g. when I
>> checked the structure at floppy.c , there is stuff like
>>
>> >     // 5 - 2.88MB, 3.5" - 2 heads, 80 tracks, 36 sectors
>> >    { {2, 80, 36}, FLOPPY_SIZE_350, FLOPPY_RATE_1M},
>>
>> - {2, 80, 36} group of values, so I'm going to introduce something like
>>
>> #define FLOPPY_RATE_1M   0x04
>> ...
>>     // 6 - 14.4MB, 3.5" - 2 heads, 80 tracks, 180 sectors
>>     { {2, 80, 180}, FLOPPY_SIZE_350, FLOPPY_RATE_8M},
>>
>> because I just realized that, following the difference between 1.44MB
>> and 2.88MB floppies, the floppy's data_rate should be increased as
>> well! In this case, somewhere below in the same floppy.c I should look
>> how the existing data_rate are handled and do something similar.
>>
>> Alternatively, it may be easier to increase the number of tracks:
>>
>>     // 6 - 14.4MB, 3.5" - 2 heads, 800 tracks, 18 sectors
>>     { {2, 800, 18}, FLOPPY_SIZE_350, FLOPPY_RATE_1M}, (not sure if I
>> should do something with floppy's data_rate in this case, maybe just
>> leave it as 1M)
>>
>> However it seems I'll have to increase the max_track value at line 69
>> from 79 to 799 . (also, why at line 61 there's "18" sectors and
not
>> "36" ? (the number of sectors at the largest 2.88MB floppy)) ...
>>
>> So I'm sure that a larger floppy format is doable, just need to play
>> with this stuff for a while...
>>
>> Best regard,
>> Mike Banon
>>
>> On Fri, Apr 19, 2019 at 1:45 AM Rafael Send <flyingfishfinger(a)gmail.com>
wrote:
>> >
>> > FWIW, for my large floppy the size is detected correctly, as in the
following output:
>> >
>> > "phys_alloc zone=0x07f41ea8 size=16777216 align =1000 ret=6f2f000 
(detail=0x07f315b0)"
>> >
>> > It LOOKS like it's also being assigned correctly...
>> >
>> > R
>> >
>> > On Thu, Apr 18, 2019 at 1:49 PM Rafael Send
<flyingfishfinger(a)gmail.com> wrote:
>> >>
>> >> Mike-
>> >> The print statements didn't really help too much (so far).
>> >> However, I did get a TINY bit further by playing with the disk geometry.
Now I get:
>> >>
>> >> "Loading vmlinuz...CHS: Error 0101 reading sector 18277 (8/59/6)
>> >> Loading core.gz...CHS: Error 0101 reading sector 457 (0/16/1)
>> >> Booting kernel failed: Invalid argument"
>> >>
>> >> It seems to me that those numbers aren't near any of the values I
set (64/16/32).
>> >>
>> >> I'll keep poking at it and see if I can get any further
improvements...
>> >>
>> >> R
>> >>
>> >> On Wed, Apr 17, 2019 at 9:14 PM Mike Banon <mikebdp2(a)gmail.com>
wrote:
>> >>>
>> >>> > However, it hangs after that and doesn't boot my kernel.
>> >>>
>> >>> This looks like for some reason SeaBIOS might have loaded only some
>> >>> beginning part of your floppy image instead of it whole. Do you use
>> >>> any of my unofficial patches currently or just the SeaBIOS master?
You
>> >>> could insert some debug prints to the floppy loading / memory
>> >>> allocation functions, or simply enable the max debug level at
SeaBIOS
>> >>> (I think that could be configured at coreboot's menuconfig as
well)
>> >>> and see if that would be enough debug info to understand what's
going
>> >>> on.

[Rafael Send]

 Could you please calculate, where's a memory area which is matching
 these CHS values?

Hm, I either don't follow or don't know enough about how this stuff works
to know what you're asking here, sorry...

R

On Thu, Apr 18, 2019 at 10:28 PM Mike Banon <mikebdp2(a)gmail.com> wrote:

  Could you please calculate, where's a memory area
which is matching
 these CHS values? Also, if the sector count value is limited by 63, I
 wonder if this data type could be expanded by a couple of bits to make
 it limited by 255 instead - to ensure that my proposed "180 sectors"
 fits there.

 On Fri, Apr 19, 2019 at 8:19 AM Rafael Send <flyingfishfinger(a)gmail.com>
 wrote:
 
 Mike-
 I left the datarate as is, but I did introduce a new line for a new
"type" of floppy in the area you mention, yes.
 
 Sector size should still be 512, I didn't touch anything I didn't feel
like I needed to.
 
 According to my research, the maximum number of tracks can never be more
 than 1024
based on the bit width of that field, but I stuck with less than
 79 because of the max_track value. I did try increasing it once, and it
 failed completely.
 
 For the heads, the bit field / BIOS limit is 16, and the sector count
 should be
allowed to go up to 63.
 
 That gives only a few possible combinations to arrive at 16MB. I've
 tried some
of them that result in the same error, and some don't work at
 all.
 
 The issue is it always fails to read at the same CHS values, so I don't
 know
how to tell how "high" it really can get
 
 I can try building an 8MB image and see if that's any better I guess.

 Thanks for the suggestions thus far,

 R

 On Thu, Apr 18, 2019 at 9:59 PM Mike Banon <mikebdp2(a)gmail.com> wrote:
>
> > "Loading vmlinuz...CHS: Error 0101 reading sector 18277 (8/59/6)
> > Loading core.gz...CHS: Error 0101 reading sector 457 (0/16/1)
> > Booting kernel failed: Invalid argument"
>
> What is the sector size here? If you could somehow check that e.g. it
> can't read any sectors beyond X - so can't access any memory after X
> KB or MB - that should tell us more about this problem.
>
> > It seems to me that those numbers aren't near any of the values I set
(64/16/32).
 >
> Where do you set these values and what do they mean? E.g. when I
> checked the structure at floppy.c , there is stuff like
>
> >     // 5 - 2.88MB, 3.5" - 2 heads, 80 tracks, 36 sectors
> >    { {2, 80, 36}, FLOPPY_SIZE_350, FLOPPY_RATE_1M},
>
> - {2, 80, 36} group of values, so I'm going to introduce something like
>
> #define FLOPPY_RATE_1M   0x04
> ...
>     // 6 - 14.4MB, 3.5" - 2 heads, 80 tracks, 180 sectors
>     { {2, 80, 180}, FLOPPY_SIZE_350, FLOPPY_RATE_8M},
>
> because I just realized that, following the difference between 1.44MB
> and 2.88MB floppies, the floppy's data_rate should be increased as
> well! In this case, somewhere below in the same floppy.c I should look
> how the existing data_rate are handled and do something similar.
>
> Alternatively, it may be easier to increase the number of tracks:
>
>     // 6 - 14.4MB, 3.5" - 2 heads, 800 tracks, 18 sectors
>     { {2, 800, 18}, FLOPPY_SIZE_350, FLOPPY_RATE_1M}, (not sure if I
> should do something with floppy's data_rate in this case, maybe just
> leave it as 1M)
>
> However it seems I'll have to increase the max_track value at line 69
> from 79 to 799 . (also, why at line 61 there's "18" sectors and not
> "36" ? (the number of sectors at the largest 2.88MB floppy)) ...
>
> So I'm sure that a larger floppy format is doable, just need to play
> with this stuff for a while...
>
> Best regard,
> Mike Banon
>
> On Fri, Apr 19, 2019 at 1:45 AM Rafael Send <flyingfishfinger(a)gmail.com>
wrote:
 > >
> > FWIW, for my large floppy the size is detected correctly, as in the
following output:
 > >
> > "phys_alloc zone=0x07f41ea8 size=16777216 align =1000 ret=6f2f000
(detail=0x07f315b0)"
 > >
> > It LOOKS like it's also being assigned correctly...
> >
> > R
> >
> > On Thu, Apr 18, 2019 at 1:49 PM Rafael Send <
flyingfishfinger(a)gmail.com&gt; wrote:
 > >>
> >> Mike-
> >> The print statements didn't really help too much (so far).
> >> However, I did get a TINY bit further by playing with the disk
geometry. Now I get:
 > >>
> >> "Loading vmlinuz...CHS: Error 0101 reading sector 18277 (8/59/6)
> >> Loading core.gz...CHS: Error 0101 reading sector 457 (0/16/1)
> >> Booting kernel failed: Invalid argument"
> >>
> >> It seems to me that those numbers aren't near any of the values I
set (64/16/32).
 > >>
> >> I'll keep poking at it and see if I can get any further
improvements...
 > >>
> >> R
> >>
> >> On Wed, Apr 17, 2019 at 9:14 PM Mike Banon &lt;mikebdp2(a)gmail.com&gt;
wrote:
 > >>>
> >>> > However, it hangs after that and doesn't boot my kernel.
> >>>
> >>> This looks like for some reason SeaBIOS might have loaded only some
> >>> beginning part of your floppy image instead of it whole. Do you use
> >>> any of my unofficial patches currently or just the SeaBIOS master?
 You
 > >>> could insert some debug prints
to the floppy loading / memory
> >>> allocation functions, or simply enable the max debug level at
SeaBIOS
 > >>> (I think that could be
configured at coreboot's menuconfig as well)
> >>> and see if that would be enough debug info to understand what's
 going
 > >>> on.

[Mike Banon]

      I was asking about

"Loading vmlinuz...CHS: Error 0101 reading sector 18277 (8/59/6) ---
that sector is situated at X kilobytes since the beginning of floppy
Loading core.gz...CHS: Error 0101 reading sector 457 (0/16/1)" ---
that sector is situated at Y kilobytes since the beginning of floppy

Sector size is 512 , yes, so X is 9138.5 KB and Y is 228.5 KB . I
don't understand why the Y error happened, since 228.5 KB is smaller
than any 3.5" floppy (FLOPPY_SIZE_350).

Sadly I have too many things to do and haven't found the time to play
more with KolibriOS (where I expect that in order to add more cool
stuff I'll have to go from 1.44MB to beyond 2.88MB so will also need
to come up with a new floppy format) , so hopefully you can do this
and I'm helping as much as possible - partially because I like this
floppy approach and think that with a little more luck it could be
successful.

Best regards,
Mike Banon

On Fri, Apr 19, 2019 at 8:50 AM Rafael Send <flyingfishfinger(a)gmail.com> wrote:
>>
>> Could you please calculate, where's a memory area which is matching
>> these CHS values?
>
>
> Hm, I either don't follow or don't know enough about how this stuff works to
know what you're asking here, sorry...
>
> R
>
> On Thu, Apr 18, 2019 at 10:28 PM Mike Banon <mikebdp2(a)gmail.com> wrote:
>>
>> Could you please calculate, where's a memory area which is matching
>> these CHS values? Also, if the sector count value is limited by 63, I
>> wonder if this data type could be expanded by a couple of bits to make
>> it limited by 255 instead - to ensure that my proposed "180 sectors"
>> fits there.
>>
>> On Fri, Apr 19, 2019 at 8:19 AM Rafael Send <flyingfishfinger(a)gmail.com>
wrote:
>> >
>> > Mike-
>> > I left the datarate as is, but I did introduce a new line for a new
"type" of floppy in the area you mention, yes.
>> >
>> > Sector size should still be 512, I didn't touch anything I didn't
feel like I needed to.
>> >
>> > According to my research, the maximum number of tracks can never be more
than 1024 based on the bit width of that field, but I stuck with less than 79 because of
the max_track value. I did try increasing it once, and it failed completely.
>> >
>> > For the heads, the bit field / BIOS limit is 16, and the sector count should
be allowed to go up to 63.
>> >
>> > That gives only a few possible combinations to arrive at 16MB. I've
tried some of them that result in the same error, and some don't work at all.
>> >
>> > The issue is it always fails to read at the same CHS values, so I don't
know how to tell how "high" it really can get
>> >
>> > I can try building an 8MB image and see if that's any better I guess.
>> >
>> > Thanks for the suggestions thus far,
>> >
>> > R
>> >
>> > On Thu, Apr 18, 2019 at 9:59 PM Mike Banon <mikebdp2(a)gmail.com>
wrote:
>> >>
>> >> > "Loading vmlinuz...CHS: Error 0101 reading sector 18277
(8/59/6)
>> >> > Loading core.gz...CHS: Error 0101 reading sector 457 (0/16/1)
>> >> > Booting kernel failed: Invalid argument"
>> >>
>> >> What is the sector size here? If you could somehow check that e.g. it
>> >> can't read any sectors beyond X - so can't access any memory
after X
>> >> KB or MB - that should tell us more about this problem.
>> >>
>> >> > It seems to me that those numbers aren't near any of the values
I set (64/16/32).
>> >>
>> >> Where do you set these values and what do they mean? E.g. when I
>> >> checked the structure at floppy.c , there is stuff like
>> >>
>> >> >     // 5 - 2.88MB, 3.5" - 2 heads, 80 tracks, 36 sectors
>> >> >    { {2, 80, 36}, FLOPPY_SIZE_350, FLOPPY_RATE_1M},
>> >>
>> >> - {2, 80, 36} group of values, so I'm going to introduce something
like
>> >>
>> >> #define FLOPPY_RATE_1M   0x04
>> >> ...
>> >>     // 6 - 14.4MB, 3.5" - 2 heads, 80 tracks, 180 sectors
>> >>     { {2, 80, 180}, FLOPPY_SIZE_350, FLOPPY_RATE_8M},
>> >>
>> >> because I just realized that, following the difference between 1.44MB
>> >> and 2.88MB floppies, the floppy's data_rate should be increased as
>> >> well! In this case, somewhere below in the same floppy.c I should look
>> >> how the existing data_rate are handled and do something similar.
>> >>
>> >> Alternatively, it may be easier to increase the number of tracks:
>> >>
>> >>     // 6 - 14.4MB, 3.5" - 2 heads, 800 tracks, 18 sectors
>> >>     { {2, 800, 18}, FLOPPY_SIZE_350, FLOPPY_RATE_1M}, (not sure if I
>> >> should do something with floppy's data_rate in this case, maybe
just
>> >> leave it as 1M)
>> >>
>> >> However it seems I'll have to increase the max_track value at line
69
>> >> from 79 to 799 . (also, why at line 61 there's "18"
sectors and not
>> >> "36" ? (the number of sectors at the largest 2.88MB floppy))
...
>> >>
>> >> So I'm sure that a larger floppy format is doable, just need to
play
>> >> with this stuff for a while...
>> >>
>> >> Best regard,
>> >> Mike Banon
>> >>
>> >> On Fri, Apr 19, 2019 at 1:45 AM Rafael Send
<flyingfishfinger(a)gmail.com> wrote:
>> >> >
>> >> > FWIW, for my large floppy the size is detected correctly, as in the
following output:
>> >> >
>> >> > "phys_alloc zone=0x07f41ea8 size=16777216 align =1000
ret=6f2f000  (detail=0x07f315b0)"
>> >> >
>> >> > It LOOKS like it's also being assigned correctly...
>> >> >
>> >> > R
>> >> >
>> >> > On Thu, Apr 18, 2019 at 1:49 PM Rafael Send
<flyingfishfinger(a)gmail.com> wrote:
>> >> >>
>> >> >> Mike-
>> >> >> The print statements didn't really help too much (so far).
>> >> >> However, I did get a TINY bit further by playing with the disk
geometry. Now I get:
>> >> >>
>> >> >> "Loading vmlinuz...CHS: Error 0101 reading sector 18277
(8/59/6)
>> >> >> Loading core.gz...CHS: Error 0101 reading sector 457 (0/16/1)
>> >> >> Booting kernel failed: Invalid argument"
>> >> >>
>> >> >> It seems to me that those numbers aren't near any of the
values I set (64/16/32).
>> >> >>
>> >> >> I'll keep poking at it and see if I can get any further
improvements...
>> >> >>
>> >> >> R
>> >> >>
>> >> >> On Wed, Apr 17, 2019 at 9:14 PM Mike Banon
<mikebdp2(a)gmail.com> wrote:
>> >> >>>
>> >> >>> > However, it hangs after that and doesn't boot my
kernel.
>> >> >>>
>> >> >>> This looks like for some reason SeaBIOS might have loaded
only some
>> >> >>> beginning part of your floppy image instead of it whole. Do
you use
>> >> >>> any of my unofficial patches currently or just the SeaBIOS
master? You
>> >> >>> could insert some debug prints to the floppy loading /
memory
>> >> >>> allocation functions, or simply enable the max debug level
at SeaBIOS
>> >> >>> (I think that could be configured at coreboot's
menuconfig as well)
>> >> >>> and see if that would be enough debug info to understand
what's going
>> >> >>> on.

[Peter Stuge]

      Mike Banon wrote:
  "Loading vmlinuz...CHS: Error 0101 reading sector
18277 (8/59/6) ---
Don't spend too much time on the arcane CHS concept, it is really
obsolete and that's for the better.

You're trying to hack a data structure and interface to do what you
want, which is something I can respect and appreciate.

But it's important to still choose battles wisely, and I think this
particular battle is better won by asymmetry; don't bother trying to
play by the rules of the CHS game - instead play another game,
or even change the game, to make the rules fit you.

Ideally you will move beyond BIOS and interrupt services. (Not to UEFI.)

But at the very least focus on LBA instead of CHS. Please. Thank you.


//Peter

[Peter Stuge]

      Rafael Send wrote:
  Alternatively, would it be possible to create an ELF
file out of a Linux
 kernel+initrd / bootable image?
Sure, and I find it far more attractive than arcane floppies, charming
as they are.

Build your kernel to include your initramfs, the kernel config option
is CONFIG_INITRAMFS_SOURCE.

Then use that kernel as payload. This page may be useful:

https://www.coreboot.org/Payloads#Linux

Note that using Linux as payload was the very origin of coreboot.


This may also be useful, though AFAIK nobody has confirmed that it works:

https://www.coreboot.org/Initramfs


//Peter

[Rafael Send]

      Hi Peter-
I had already testes the coreboot + Linux kernel without SeaBIOS, that
works fine. But I do want the rest of the boot menu presented by SeaBIOS
because I usually use Windoze as well.

Even if I put the initrd inside the kernel, that can't be loaded by SeaBIOS
unless the whole thing is an ELF file, right?

How would that step go (vmlinuz -> ELF)?

R

Peter Stuge <peter(a)stuge.se> schrieb am Do., 18. Apr. 2019, 06:06:

  Rafael Send wrote:
  Alternatively, would it be possible to create an
ELF file out of a Linux
 kernel+initrd / bootable image?
 Sure, and I find it far more attractive than arcane floppies, charming
 as they are.

 Build your kernel to include your initramfs, the kernel config option
 is CONFIG_INITRAMFS_SOURCE.

 Then use that kernel as payload. This page may be useful:

 https://www.coreboot.org/Payloads#Linux

 Note that using Linux as payload was the very origin of coreboot.


 This may also be useful, though AFAIK nobody has confirmed that it works:

 https://www.coreboot.org/Initramfs


 //Peter
 _______________________________________________
 SeaBIOS mailing list -- seabios(a)seabios.org
 To unsubscribe send an email to seabios-leave(a)seabios.org

[Peter Stuge]

      Rafael Send wrote:
  I had already testes the coreboot + Linux kernel
without SeaBIOS,
 that works fine.
That's a great start! So did you look into what happens under the
hood when you do that, to learn?

The original common case for coreboot payloads was also ELF files, so
there is much overlap with what you want to achieve.

You probably already noticed the tool mkelfimage in the pages I linked to.
Did you look into what it does, and why it's needed in the first place?
(Hint: Linux is a bit needy.)


  But I do want the rest of the boot menu presented by
SeaBIOS
 because I usually use Windoze as well.
SeaBIOS creates a BIOS environment when there isn't one. That is its
key feature. This is a coffin for Windows to lie in.

BIOS environments are just inadequate in general, and supremely ill
equipped in particular for what you want to accomplish.

Consider using SeaBIOS exclusively for what it was made; Windows coffin.

Consider another payload before (time wise) SeaBIOS to provide the menu.


  Even if I put the initrd inside the kernel, that
can't be loaded by
 SeaBIOS unless the whole thing is an ELF file, right?
I guess so.

The true-to-form BIOS way would probably be to put FreeDOS,
loadlin.exe, kernel and initramfs into a disk image. So please don't do
that. If you really want to, please be rational: Ask yourself why you
want to first start the wrong OS in order to then start the right OS.


  How would that step go (vmlinuz -> ELF)?
I'd recommend to study what coreboot does. It's not trivial, but also
not super complicated. The key point is that Linux needs a loader stub
(code and data) to be generated. It's not possible to just jump right
into the kernel and have it start. Unfortunately.


//Peter

[Mike Banon]

      Peter, I believe we shouldn't put it like "ELF versus Floppy" because
these ways are not mutually exclusive: they could be tried in
parallel, especially since Rafael's pursuit towards a working solution
also involves waiting for helpful replies from the mailing lists ;-)
Also, regarding SeaBIOS: I haven't observed any downsides from SeaBIOS
providing the BIOS environment. It may be arcane and not modern
anough, however it does not prevent anything from working: it either
helps something to work (e.g. some wonderful floppy-based OS which
relies on the BIOS calls) or simply being inactive if the OS is not
using this environment.

On Fri, Apr 19, 2019 at 3:12 PM Peter Stuge <peter(a)stuge.se> wrote:
>
> Rafael Send wrote:
> > I had already testes the coreboot + Linux kernel without SeaBIOS,
> > that works fine.
>
> That's a great start! So did you look into what happens under the
> hood when you do that, to learn?
>
> The original common case for coreboot payloads was also ELF files, so
> there is much overlap with what you want to achieve.
>
> You probably already noticed the tool mkelfimage in the pages I linked to.
> Did you look into what it does, and why it's needed in the first place?
> (Hint: Linux is a bit needy.)
>
>
> > But I do want the rest of the boot menu presented by SeaBIOS
> > because I usually use Windoze as well.
>
> SeaBIOS creates a BIOS environment when there isn't one. That is its
> key feature. This is a coffin for Windows to lie in.
>
> BIOS environments are just inadequate in general, and supremely ill
> equipped in particular for what you want to accomplish.
>
> Consider using SeaBIOS exclusively for what it was made; Windows coffin.
>
> Consider another payload before (time wise) SeaBIOS to provide the menu.
>
>
> > Even if I put the initrd inside the kernel, that can't be loaded by
> > SeaBIOS unless the whole thing is an ELF file, right?
>
> I guess so.
>
> The true-to-form BIOS way would probably be to put FreeDOS,
> loadlin.exe, kernel and initramfs into a disk image. So please don't do
> that. If you really want to, please be rational: Ask yourself why you
> want to first start the wrong OS in order to then start the right OS.
>
>
> > How would that step go (vmlinuz -> ELF)?
>
> I'd recommend to study what coreboot does. It's not trivial, but also
> not super complicated. The key point is that Linux needs a loader stub
> (code and data) to be generated. It's not possible to just jump right
> into the kernel and have it start. Unfortunately.
>
>
> //Peter
> _______________________________________________
> SeaBIOS mailing list -- seabios(a)seabios.org
> To unsubscribe send an email to seabios-leave(a)seabios.org

[Rafael Send]

      Guys-
I actually succeeded with the direct kernel method. I think I didn't fully
clean my coreboot build before. I do want to get the floppy method working
too as a learning experience next, but here's what I did so far:

- Build coreboot with the built-in SeaBIOS
- Add my kernel to the cbfs with:

"./build/cbfstool build/coreboot.rom add-payload -f payloads/vmlinuz -n
img/Linux -I payloads/rootfs.gz"

That's actually all it took!

I did not know that SeaBIOS can actually boot kernels without them being
ELF files, but the stuff Peter pointed me to got me on the right track.

Now, to the floppy method!

R


On Fri, Apr 19, 2019 at 6:09 AM Mike Banon <mikebdp2(a)gmail.com> wrote:

  Peter, I believe we shouldn't put it like
"ELF versus Floppy" because
 these ways are not mutually exclusive: they could be tried in
 parallel, especially since Rafael's pursuit towards a working solution
 also involves waiting for helpful replies from the mailing lists ;-)
 Also, regarding SeaBIOS: I haven't observed any downsides from SeaBIOS
 providing the BIOS environment. It may be arcane and not modern
 anough, however it does not prevent anything from working: it either
 helps something to work (e.g. some wonderful floppy-based OS which
 relies on the BIOS calls) or simply being inactive if the OS is not
 using this environment.

 On Fri, Apr 19, 2019 at 3:12 PM Peter Stuge <peter(a)stuge.se> wrote:
 
 Rafael Send wrote:
  I had already testes the coreboot + Linux kernel
without SeaBIOS,
 that works fine.
 That's a great start! So did you look into what happens under the
 hood when you do that, to learn?

 The original common case for coreboot payloads was also ELF files, so
 there is much overlap with what you want to achieve.

 You probably already noticed the tool mkelfimage in the pages I linked
 to.
  Did you look into what it does, and why it's
needed in the first place?
 (Hint: Linux is a bit needy.)


  But I do want the rest of the boot menu presented
by SeaBIOS
 because I usually use Windoze as well.
 SeaBIOS creates a BIOS environment when there isn't one. That is its
 key feature. This is a coffin for Windows to lie in.

 BIOS environments are just inadequate in general, and supremely ill
 equipped in particular for what you want to accomplish.

 Consider using SeaBIOS exclusively for what it was made; Windows coffin.

 Consider another payload before (time wise) SeaBIOS to provide the menu.


  Even if I put the initrd inside the kernel, that
can't be loaded by
 SeaBIOS unless the whole thing is an ELF file, right?
 I guess so.

 The true-to-form BIOS way would probably be to put FreeDOS,
 loadlin.exe, kernel and initramfs into a disk image. So please don't do
 that. If you really want to, please be rational: Ask yourself why you
 want to first start the wrong OS in order to then start the right OS.


  How would that step go (vmlinuz -> ELF)?
 I'd recommend to study what coreboot does. It's not trivial, but also
 not super complicated. The key point is that Linux needs a loader stub
 (code and data) to be generated. It's not possible to just jump right
 into the kernel and have it start. Unfortunately.


 //Peter
 _______________________________________________
 SeaBIOS mailing list -- seabios(a)seabios.org
 To unsubscribe send an email to seabios-leave(a)seabios.org

[Rafael Send]

      Hi Peter-
I actually had NOT come across mkelfimage!
It may have to do with the fact that this page appears to be a stub:

https://www.coreboot.org/Mkelfimage

and searching on the new documentation site yields no hits.

Interestingly, the Google result for that page does show some text. Maybe
an old version has it? I'll investigate.

Thanks for the hints so far, either way!

R

Peter Stuge <peter(a)stuge.se> schrieb am Fr., 19. Apr. 2019, 05:12:

  Rafael Send wrote:
  I had already testes the coreboot + Linux kernel
without SeaBIOS,
 that works fine.
 That's a great start! So did you look into what happens under the
 hood when you do that, to learn?

 The original common case for coreboot payloads was also ELF files, so
 there is much overlap with what you want to achieve.

 You probably already noticed the tool mkelfimage in the pages I linked to.
 Did you look into what it does, and why it's needed in the first place?
 (Hint: Linux is a bit needy.)


  But I do want the rest of the boot menu presented
by SeaBIOS
 because I usually use Windoze as well.
 SeaBIOS creates a BIOS environment when there isn't one. That is its
 key feature. This is a coffin for Windows to lie in.

 BIOS environments are just inadequate in general, and supremely ill
 equipped in particular for what you want to accomplish.

 Consider using SeaBIOS exclusively for what it was made; Windows coffin.

 Consider another payload before (time wise) SeaBIOS to provide the menu.


  Even if I put the initrd inside the kernel, that
can't be loaded by
 SeaBIOS unless the whole thing is an ELF file, right?
 I guess so.

 The true-to-form BIOS way would probably be to put FreeDOS,
 loadlin.exe, kernel and initramfs into a disk image. So please don't do
 that. If you really want to, please be rational: Ask yourself why you
 want to first start the wrong OS in order to then start the right OS.


  How would that step go (vmlinuz -> ELF)?
 I'd recommend to study what coreboot does. It's not trivial, but also
 not super complicated. The key point is that Linux needs a loader stub
 (code and data) to be generated. It's not possible to just jump right
 into the kernel and have it start. Unfortunately.


 //Peter
 _______________________________________________
 SeaBIOS mailing list -- seabios(a)seabios.org
 To unsubscribe send an email to seabios-leave(a)seabios.org

[Peter Stuge]

      Rafael Send wrote:
  I actually had NOT come across mkelfimage!
I see. The old wiki pages I linked to in a previous mail show it
being used. It's a very old tool from LinuxBIOS v1 times, since
replaced by functionality built into cbfstool.

https://review.coreboot.org/cgit/coreboot.git/tree/util/cbfstool/cbfs-paylo…


//Peter

[Mike Banon]

      Rafael, please could you share a working method of expanding a floppy
from 1.44MB to i.e. 2.88MB ?

I'm back to this issue and noticed that popular Linux tools (i.e.
gparted with libparted, fatresize, etc.) weirdly do not support
resizing a FAT12 filesystem which the floppies have. Manually
increasing the number or sectors with a hexedit - 0x13/0x14 bytes from
0x0B40 to 0x1680 and 0x18 byte from 0x12 to 0x24 - also didn't work
for me (but I just learned about FAT structure and may be missing
something).

[Rafael Send]

      Hi Mike-
I followed this method:
http://failverse.com/creating-a-non-standard-size-bootable-floppy-image-for…

That worked, the rest was just making SeaBIOS (at the time) try to read
them, as per the discussion.

FWIW I managed to increase my ROM chip size from 8 to 16MB and stuff it
with coreboot + Grub (which loads either SeaBIOS, Tianocore or a
stripped-down TinyCore Linux). Works great, no need for floppies.

Good luck, please update with your results once you find something
interesting / useful!

R

On Fri, Apr 3, 2020 at 10:34 AM Mike Banon <mikebdp2(a)gmail.com> wrote:

  Rafael, please could you share a working method of
expanding a floppy
 from 1.44MB to i.e. 2.88MB ?

 I'm back to this issue and noticed that popular Linux tools (i.e.
 gparted with libparted, fatresize, etc.) weirdly do not support
 resizing a FAT12 filesystem which the floppies have. Manually
 increasing the number or sectors with a hexedit - 0x13/0x14 bytes from
 0x0B40 to 0x1680 and 0x18 byte from 0x12 to 0x24 - also didn't work
 for me (but I just learned about FAT structure and may be missing
 something).