All of lore.kernel.org
 help / color / mirror / Atom feed
From: Frediano Ziglio <freddyz77@tin.it>
To: Matt Domsch <Matt_Domsch@dell.com>
Cc: Andrew Morton <akpm@osdl.org>,
	linux-kernel@vger.kernel.org,
	Bartlomiej Zolnierkiewicz <B.Zolnierkiewicz@elka.pw.edu.pl>,
	"Patrick J. LoPresti" <patl@users.sourceforge.net>
Subject: Re: Fw: EDD enhanchement patch
Date: Wed, 07 Jul 2004 09:41:22 +0200	[thread overview]
Message-ID: <1089186082.3458.76.camel@freddy> (raw)
In-Reply-To: <Pine.LNX.4.44.0407062248040.19141-100000@humbolt.us.dell.com>

Il mer, 2004-07-07 alle 06:45, Matt Domsch ha scritto:
> > Date: Tue, 06 Jul 2004 18:53:28 +0200
> > From: Frediano Ziglio <freddyz77@tin.it>
> > 
> > This patch add support for DTPE data in EDD and mbr_signature. This
> > patch do not solve fdisk problems but can help these programs to compute
> > correct head count.
> 
> Thanks Frediano.  I don't think this is quite ready to include yet,
> but I'm not philosophically opposed to it, so let's work it out.
> 
> First, I want to understand what information in the DPTE you need.  I
> assume byte offset 4, bit 6 (LBA enable), and bytes 10-11 bit 3 (CHS
> translation enabled) and bit 4 (LBA translation enabled), yes?  How
> are you expecting tools like fdisk to use this information?
> 

My idea it's base/control port and flags. In this way you are able to
say that disk it's a slave ide. Just issue a command like

$ cat /proc/ioports | grep ide
0170-0177 : ide1
01f0-01f7 : ide0
0376-0376 : ide1
03f6-03f6 : ide0
  f000-f007 : ide0
  f008-f00f : ide1
And you know which ide controller it's connected your disk.

> Second, your timing is unfortunate, as the patch won't apply given the
> mbr_signature capture routines I submitted and were committed to BK in
> the past week.  It'll have to be reworked against BK-current.
> 

:(
I think this it's the right place to download the patch
http://www.kernel.org/pub/linux/kernel/v2.6/testing/cset/

> Now, for the patch:
> 
> diff -U10 -r linux-2.6.7.orig/arch/i386/boot/edd.S linux-2.6.7/arch/i386/boot/edd.S
> +++ linux-2.6.7/arch/i386/boot/edd.S	2004-07-06 17:07:02.000000000 +0200
>  #if defined(CONFIG_EDD) || defined(CONFIG_EDD_MODULE)
> -# Read the first sector of device 80h and store the 4-byte signature
> -	movl	$0xFFFFFFFF, %eax
> -	movl	%eax, (DISK80_SIG_BUFFER)	# assume failure
> -	movb	$READ_SECTORS, %ah
> -	movb	$1, %al				# read 1 sector
> -	movb	$0x80, %dl			# from device 80
> -	movb	$0, %dh				# at head 0
> -	movw	$1, %cx				# cylinder 0, sector 0
> -	pushw	%es
> -	pushw	%ds
> -	popw	%es
> -	movw	$EDDBUF, %bx
> -	pushw   %dx             # work around buggy BIOSes
> -	stc                     # work around buggy BIOSes
> -	int     $0x13
> -	sti                     # work around buggy BIOSes
> -	popw    %dx
> -	jc	disk_sig_done
> -	movl	(EDDBUF+MBR_SIG_OFFSET), %eax
> -	movl	%eax, (DISK80_SIG_BUFFER)	# store success
> -disk_sig_done:
> -	popw	%es
> 
> You whack obtaining the mbr_signature for the disk here, it'll come
> back later...  OK.
> 
> -	movb	%dl, %ds:-8(%si)		# store device number
> -	movb	%ah, %ds:-7(%si)		# store version
> -	movw	%cx, %ds:-6(%si)		# store extensions
> +	movb	%dl, %ds:-12(%si)		# store device number
> +	movb	%ah, %ds:-11(%si)		# store version
> +	movw	%cx, %ds:-10(%si)		# store extensions
> 
> Just at different offsets now, OK.
> 
> -	movw	$EDDPARMSIZE, %ds:(%si)		# put size
> +	movw	$EDDPARMSIZE-16, %ds:(%si)		# put size
> 
> OK, though I dislike the magic value 16 there, would prefer a #define.
> 

You are right. Perhaps it's better to define
- DPTE structure (dtpe_info)
- DPTESIZE (used in asm and C code)
- put dpte_info as a member of edd_info

> 
> +	# copy EDD 2.0 informations
> +	pushw	%ds
> +	pushw	%es
> +	pushw	%ds
> +	popw	%es
> +	pushw	%si
> +	leaw	EDD2_OFFSET(%si), %di
> +	ldsw	%ds:0x1a(%si), %si
> +	movw	$8, %cx
> +	rep
> +	movsw
> +	popw	%si
> +	popw	%es
> +	popw	%ds
> 
> This looks like it's copying 16 bytes, the whole DPTE, right?
> 

Yes.

> -	movw    %ax, %ds:-4(%si)
> -	movw    %ax, %ds:-2(%si)
> +	movw    %ax, %ds:-8(%si)
> +	movw    %ax, %ds:-6(%si)
> 
> OK.
> 
> -	movb	%al, %ds:-1(%si)                # Record max sect
> -	movb    %dh, %ds:-2(%si)                # Record max head number
> +	movb	%al, %ds:-5(%si)                # Record max sect
> +	movb    %dh, %ds:-6(%si)                # Record max head number
> 
> OK.
> 
> -	movw    %ax, %ds:-4(%si)
> +	movw    %ax, %ds:-8(%si)
> 
> OK.
>  
> -	movw	%si, %ax			# increment si
> -	addw	$EDDPARMSIZE+EDDEXTSIZE, %ax
> -	movw	%ax, %si

Here would be

addw	$EDDPARMSIZE+EDDEXTSIZE+DPTESIZE, %ax

> +
> +# Read the first sector of device and store the 4-byte signature
> +	movl	$0xFFFFFFFF, %eax
> +	movl	%eax, %ds:-4(%si)		# assume failure
> +	movb	$READ_SECTORS, %ah
> +	movb	$1, %al				# read 1 sector
> +	movb	$0, %dh				# at head 0
> +	movw	$1, %cx				# cylinder 0, sector 0
> +	pushw	%es
> +	pushw	%ss
> +	popw	%es
> +	subw	$0x200, %sp
> +	movw	%sp, %bx
> 
> Ahh, using the stack rather than empty_zero_page to read the sector
> into.  That's clever.  How large is the stack though?
> 

I don't know but usually it's some Kb.. I didn't know how large was
empty_zero_page...

> +	pushw	%bx
> +	pushw   %dx             # work around buggy BIOSes
> +	stc                     # work around buggy BIOSes
> +	int     $0x13
> +	sti                     # work around buggy BIOSes
> +	popw    %dx
> +	popw	%bx
> +	jc	disk_sig_done
> +	movl	MBR_SIG_OFFSET(%bx), %eax
> +	movl	%eax, %ds:-4(%si)		# store success
> +disk_sig_done:
> +	addw	$0x200, %sp
> +	popw	%es
> +
> +
> +	addw	$EDDPARMSIZE+EDDEXTSIZE, %si	# increment si
> 
> 
> The only problem I have with the above is that you're limited by the
> space in empty_zero_page set aside for the edd info structures, which
> is presently 6, though with your additions, I think should drop to 5.  My
> latest in BK keeps mbr_signatures for the first 16 devices.
> 
> diff -U10 -r linux-2.6.7.orig/Documentation/i386/zero-page.txt linux-2.6.7/Documentation/i386/zero-page.txt
> --- linux-2.6.7.orig/Documentation/i386/zero-page.txt	2004-06-01 11:49:45.000000000 +0200
> +++ linux-2.6.7/Documentation/i386/zero-page.txt	2004-06-05 12:57:44.000000000 +0200
> @@ -65,14 +65,13 @@
>  0x211	char		loadflags:
>  			bit0 = 1: kernel is loaded high (bzImage)
>  			bit7 = 1: Heap and pointer (see below) set by boot
>  				  loader.
>  0x212	unsigned short	(setup.S)
>  0x214	unsigned long	KERNEL_START, where the loader started the kernel
>  0x218	unsigned long	INITRD_START, address of loaded ramdisk image
>  0x21c	unsigned long	INITRD_SIZE, size in bytes of ramdisk image
>  0x220	4 bytes		(setup.S)
>  0x224	unsigned short	setup.S heap end pointer
> -0x2cc	4 bytes		DISK80_SIG_BUFFER (setup.S)
> +0x2cc	4 bytes		unused (old DISK80_SIG_BUFFER, setup.S)
> 
> I think we can just remove the note if it's not used anymore.
> 
>  0x2d0 - 0x600		E820MAP
> -0x600 - 0x7ff		EDDBUF (setup.S) for disk signature read sector
> -0x600 - 0x7eb		EDDBUF (setup.S) for edd data
> +0x600 - 0x863		EDDBUF (setup.S) for edd data
> 
> I believe the empty_zero_page ends at 0x7ff.  If I'm right, then we
> need to reduce the number of devices probed by one such that we don't
> overflow this space.
> 

:( quite short... Another way to reduce space it's to use dynamic sizes.
Must BIOS did not fill all edd_device_params but just some bytes...

>  static ssize_t
>  edd_show_raw_data(struct edd_device *edev, char *buf)
>  {
>  	struct edd_info *info;
> -	ssize_t len = sizeof (info->params);
> +	ssize_t len = sizeof (info->params) - 16;
> 
> Again, the magic 16.  Let's fix up the structure such that its members
> are rightly sized, and use those lengths.
> 
> -	if (len > (sizeof(info->params)))
> -		len = sizeof(info->params);
> +	if (len > (sizeof(info->params)-16))
> +		len = sizeof(info->params)-16;
> 
> ditto
>  
> +static ssize_t
> +edd_show_dpte(struct edd_device *edev, char *buf)
> +{
> +	struct edd_info *info;
> +	if (!edev)
> +		return -EINVAL;
> +	info = edd_dev_get_info(edev);
> +	if (!info || !buf)
> +		return -EINVAL;
> +
> +	memcpy(buf, &info->params.port_base, 16);
> +	return 16;
> +}
> 
> Ok, this'll get gregkh's attention.  I was lazy with
> edd_show_raw_data() returning raw data like this, and *not* using the
> sysfs binary blob interface.  Rather than add another nonconformant
> use, let's fix both of these to use this, and name it "raw_dpte"
> instead.
> 

Ok.

> +	
> +	/* EDD 2.0 infos */
> +	u16 port_base;
> +	u16 port_command;
> +	u8 drive_flags;
> +	u8 proprietary_informations;
> +	u8 irq;
> +	u8 multi_sector_count;
> +	u8 dma_control;
> +	u8 programmed_io;
> +	u16 drive_options;
> +	u16 reserved5;
> +	u8 extension_level;
> +	u8 edd2_checksum;
>  } __attribute__ ((packed));
> 
> The DPTE data needs to be in its own struct, not in edd_device_params
> (which is only fn48 data), then tacked into the end of struct edd_info.
> 

Ok

> I'm out this week on vacation, and the next few weeks are busy with
> OLS coming.  If you care to rework this against current BK, leaving
> the mbr_signature list in its new place so we can keep 16 rather than
> 5 (I think those will be more useful than EDD in the near future given how
> poor nearly all the BIOS implementations of EDD are still), then we
> can review on the list again.
> 
> Thanks,
> Matt

There are different level of EDD. EDD 1.0 is supported by most BIOSes.
I don't understand why using DOS my BIOS seems to return correctly DPTE
info while running Linux DPTE are not filled...

freddy77



  reply	other threads:[~2004-07-07  7:41 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20040706171234.4b0462e1.akpm@osdl.org>
2004-07-07  4:45 ` Fw: EDD enhanchement patch Matt Domsch
2004-07-07  7:41   ` Frediano Ziglio [this message]
2004-07-07 10:05   ` Frediano Ziglio
2004-07-08 12:56     ` Matt Domsch

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1089186082.3458.76.camel@freddy \
    --to=freddyz77@tin.it \
    --cc=B.Zolnierkiewicz@elka.pw.edu.pl \
    --cc=Matt_Domsch@dell.com \
    --cc=akpm@osdl.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=patl@users.sourceforge.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.