Custom-sized, large floppy images?
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
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@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@seabios.org To unsubscribe send an email to seabios-leave@seabios.org
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@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@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@seabios.org To unsubscribe send an email to seabios-leave@seabios.org
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@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@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@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@seabios.org To unsubscribe send an email to seabios-leave@seabios.org
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
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@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@seabios.org To unsubscribe send an email to seabios-leave@seabios.org
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@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@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@seabios.org To unsubscribe send an email to seabios-leave@seabios.org
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/seabios@seabios.org/thread/CKWLNTZ... ) . 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@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@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@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@seabios.org To unsubscribe send an email to seabios-leave@seabios.org
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@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/seabios@seabios.org/thread/CKWLNTZ... ) . 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@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@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@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@seabios.org To unsubscribe send an email to seabios-leave@seabios.org
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 <flyingfishfinger@gmail.com> 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 <mikebdp2@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/seabios@seabios.org/thread/CKWLNTZ... ) . 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@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@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@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@seabios.org To unsubscribe send an email to seabios-leave@seabios.org
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@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 <flyingfishfinger@gmail.com> 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 <mikebdp2@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/seabios@seabios.org/thread/CKWLNTZ...
) . 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@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@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@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@seabios.org To unsubscribe send an email to seabios-leave@seabios.org
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- 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@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.
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@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@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.
"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@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@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@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- 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@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@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@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@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.
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@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@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@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@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@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.
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@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@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@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@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@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@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.
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@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@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@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@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@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@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@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 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
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
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@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@seabios.org To unsubscribe send an email to seabios-leave@seabios.org
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
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@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@seabios.org To unsubscribe send an email to seabios-leave@seabios.org
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@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@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@seabios.org To unsubscribe send an email to seabios-leave@seabios.org
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).
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@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).
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@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@seabios.org To unsubscribe send an email to seabios-leave@seabios.org
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-payloa... //Peter
participants (4)
-
Kevin O'Connor -
Mike Banon -
Peter Stuge -
Rafael Send