[syslinux] Support for 4kb disks

Frediano Ziglio frediano.ziglio at citrix.com
Wed Oct 3 07:16:12 PDT 2012


On Wed, 2012-08-01 at 08:22 +0100, Frediano Ziglio wrote:
> Thanks Peter for advices.
> 
> I managed now to load the second step (loading ldlinux.sys on ram) and
> it seems to get the configuration file (hitting tab show me the two
> entries I have in extlinux.conf). However kernel does not load.
> 
> Not that easy to debug, do you have some advice? Currently I enabled
> debugging of BIOS (SeaBIOS) and I look for calls. Calling printf in
> core/fs/diskio.c seems to not work.
> 

I fixed this problem, was a problem with my BIOS emulator, nothing to do
with syslinux. Also tested with a real machine and confirmed it works
correctly

> In many places rdwr_sectors get called assuming that sectors are 512
> (for instance to read BPB or boot sector) so I changed to assume sectors
> calling rdwr_sectors are 512 however there are other places (like
> getoneblk) where this assumption is wrong. Also in iso9660.c you shift
> from iso blocks (2k) to disk one (4k) loosing precision. I would
> personally write a rdwr_bytes to couple with this problems leading
> rdwr_sectors as a low level functions.
> 
> Another problem I'm facing is ADV "sectors". There is a string
> assumption that ADV sectors are 512 bytes long. Currently I align
> initial ldlinux and ADV sectors to 4k but I didn't tested if all works
> correctly (I think not...). Writing into a single sectors have problems
> if write fails (you corrupt both), aligning to sector size is a waste of
> space for systems like btrfs (they would occupy 8kb out of 64kb).
> 

Fixed even this issue, I'm going to post patches again.

Regards,
  Frediano

> 
> On Mon, 2012-07-30 at 07:17 -0700, H. Peter Anvin wrote:
> > Partition tables are invalid when moving disk sizes anyway.  As far as removing legacy int13 support that is a non-option, although it probably is not necessary for those to work with larger sector sizes.
> > 
> > Frediano Ziglio <frediano.ziglio at citrix.com> wrote:
> > 
> > >On Wed, 2012-07-18 at 18:59 -0700, H. Peter Anvin wrote:
> > >> On 07/17/2012 01:37 AM, Frediano Ziglio wrote:
> > >> >
> > >> > It's a physical machine with a beta firmware on it. I wrote a small
> > >> > program to read/write two sectors and I can confirm that each
> > >sector is
> > >> > 4kb.
> > >> >
> > >> 
> > >> Support for non-512-byte logical sectors is sparse since such support
> > >in 
> > >> actual systems is scant to nonexistent.  Most of the pieces are there
> > >
> > >> but as you have noticed there are bits still missing.
> > >> 
> > >> 	-hpa
> > >> 
> > >
> > >I finally got a repro using Qemu and patched SeaBIOS (just changed the
> > >check in src/blockcmd.c for DISK_SECTOR_SIZE adding 4096).
> > >
> > >After some though I think there are 2 way to make it work:
> > >1- patch extlinux installer in order to detect and use sector > 512
> > >2- make extlinux code assume that sectors specified are 512 but handle
> > >case where BIOS use bigger sizes
> > >
> > >1 make simpler extlinux code (probably code is already there) but it
> > >could be a problem if a user wants to switch the disk from 512 to 4096
> > >(this can happen changing jumpers on disk or firmware on some disk
> > >controller).
> > >
> > >2 however require more code on extlinux (it's hard to make it works
> > >only
> > >using 512 bytes).
> > >
> > >I'd vote for 2 and I think there are some options to avoid the 512
> > >bytes
> > >problems:
> > >- as sectors are bigger mbr code load more code, ext2/3/4 let us 1024
> > >bytes so we can use entire 1kb, just check on first 512 bytes we can
> > >use
> > >entire kb
> > >- remove old floppy and no int13x code and use only int13x.
> > >
> > >In this case I would vote for first.
> > >
> > >Any suggestion?
> > >
> > >Regards
> > >  Frediano
> > 
> 
> 
> _______________________________________________
> Syslinux mailing list
> Submissions to Syslinux at zytor.com
> Unsubscribe or set options at:
> http://www.zytor.com/mailman/listinfo/syslinux
> Please do not send private replies to mailing list traffic.
> 





More information about the Syslinux mailing list