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.