Hi Mike-
I followed this method:
http://failverse.com/creating-a-non-standard-size-bootable-floppy-image-for-pxe-boot/
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
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
increas
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:
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/c
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 o
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
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
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
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
Sect
>
> 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 wrote:
> Could you please calculate, wh
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,
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 base
> "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
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
wrote:
> Mike-
> The p
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:
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
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_INITR
> 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 t
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 installe
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_f
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 schrieb am Di., 16. Apr. 2019, 01:39:
> You need to build a co
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
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
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 KolibriO
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 c
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 real
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 schrieb am Fr., 12. Apr. 2019, 22
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 la
28 matches
Mail list logo
