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,

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.