>
> 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 <mikeb...@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 <flyingfishfin...@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 <mikeb...@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 <flyingfishfin...@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 <
> flyingfishfin...@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 <mikeb...@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.
>
_______________________________________________
SeaBIOS mailing list -- seabios@seabios.org
To unsubscribe send an email to seabios-le...@seabios.org
