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.