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
Sector size is 512 , yes, so X is 9138.5 KB and Y is 228.5 KB . I
don't understand why the Y error happened, since 228.5 KB is smaller
than any 3.5" floppy (FLOPPY_SIZE_350).
Sadly I have too many things to do and haven't found the time to play
more with KolibriOS (where I expect that in order to add more cool
stuff I'll have to go from 1.44MB to beyond 2.88MB so will also need
to come up with a new floppy format) , so hopefully you can do this
and I'm helping as much as possible - partially because I like this
floppy approach and think that with a little more luck it could be
successful.
Best regards,
Mike Banon
On Fri, Apr 19, 2019 at 8:50 AM Rafael Send <flyingfishfin...@gmail.com> wrote:
>>
>> 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
