[parisc-linux] iodc call and HPMC: dump driver.

[parisc-linux] iodc call and HPMC: dump driver.

[Bruno Vidal]

[-- Attachment #1: Type: text/plain, Size: 1473 bytes --]

	Hi all.
Do you know a guy who is a guru of iodc calls ?
I'm still stuck with this. I think I was really near the
solution. Now my iodc call create beatifull HPMC.
Take a look to this call, I was thinking that it
was all right, but there is still something wrong.
now i'm able to retrieve hpa,
I based this on palo code:

ret =  real32_call(PAGE0->mem_boot.iodc_io, (unsigned long)PAGE0->mem_boot.hpa, DUMPDEV_WRITE,
  PAGE0->mem_boot.spa, __pa(PAGE0->mem_boot.dp.layers), __pa(pdc_result), devaddr, __pa(iodc_dbuf), 2048);

DUMPDEV_WRITE = 1
static unsigned long pdc_result[32] __attribute__ ((aligned (8))); 
static char __attribute__((aligned(64))) iodc_dbuf[DUMP_PAGE_SZ];

and devaddr=191889408

Disk /dev/sda: 64 heads, 32 sectors, 17366 cylinders
Units = cylinders of 2048 * 512 bytes

/dev/sda1   *         1        61     62448   f0  Linux/PA-RISC boot
/dev/sda2            62       183    124928   83  Linux
/dev/sda3           184      1648   1500160   82  Linux swap
/dev/sda4          1649     17366  16095232    5  Extended
/dev/sda5          1649      5554   3999728   83  Linux
/dev/sda6          5555      9460   3999728   82  Linux swap
/dev/sda7          9461     13366   3999728   83  Linux
/dev/sda8         13367     17366   4095984   83  Linux

Do you know someone who is well aware of iodc calls ?
I want to discuss a bit about this.

	Thanks.

-- 
	Vidal Bruno, (770-4271)
        SSD-HA Team, HP-UX & LINUX Support
	bruno_vidal@admin.france.hp.com

[-- Attachment #2: Card for Bruno Vidal --]
[-- Type: text/x-vcard, Size: 386 bytes --]

begin:vcard 
n:Bruno;VIDAL
tel;fax:01-69-82-60-14
tel;work:01-69-29-42-71
x-mozilla-html:TRUE
url:www.france.hp.com
org:Solution Center
version:2.1
email;internet:bruno_vidal@hp.com
title:Expert Logiciel Environnement Haute Disponibilité
adr;quoted-printable:;;HP France=0D=0A;Z.A de Courtaboeuf;1 Av. du Canada;91947 Les Ulis cedex;France
x-mozilla-cpt:;26208
fn:VIDAL Bruno
end:vcard

Re: [parisc-linux] iodc call and HPMC: dump driver.

[Grant Grundler]

Bruno Vidal wrote:
> 	Hi all.
> Do you know a guy who is a guru of iodc calls ?

I'm not expert, but I've mucked with it abit.

> I'm still stuck with this. I think I was really near the
> solution. Now my iodc call create beatifull HPMC.

Which platform are you testing on?
32 or 64-bit kernel?

> Take a look to this call, I was thinking that it
> was all right, but there is still something wrong.
> now i'm able to retrieve hpa,
> I based this on palo code:
> 
> ret =  real32_call(PAGE0->mem_boot.iodc_io, (unsigned long)PAGE0->mem_boot.hp
>   a, DUMPDEV_WRITE,
>   PAGE0->mem_boot.spa, __pa(PAGE0->mem_boot.dp.layers), __pa(pdc_result), dev
>   addr, __pa(iodc_dbuf), 2048);

Can you dump the values for the call that HPMCs?
I'm not sure what is supposed to be passed as arguments to IODC.
I'm trying to find it in the documentation I have and then I
can verify the values are sane.

Note that all IODC is 32-bit.
And earlier IODC versions don't like byte addresses greater than 2GB.
Not sure when that got fixed but it certainly wasn't on 712
or similar workstations/servers. It wasn't even noticed as a problem
until HP started shipping 4GB disk drives (ie 1997 or so).

later IODC included a "block" interface which use block address
instead of byte address. I'll try to find documentation on this.

> DUMPDEV_WRITE = 1
> static unsigned long pdc_result[32] __attribute__ ((aligned (8))); 
> static char __attribute__((aligned(64))) iodc_dbuf[DUMP_PAGE_SZ];
> 
> and devaddr=191889408

191889408 == 0xB7000000
If this is the target byte address on the block device, it's too big.


> Disk /dev/sda: 64 heads, 32 sectors, 17366 cylinders
> Units = cylinders of 2048 * 512 bytes
> 
> /dev/sda1   *         1        61     62448   f0  Linux/PA-RISC boot
> /dev/sda2            62       183    124928   83  Linux
> /dev/sda3           184      1648   1500160   82  Linux swap
> /dev/sda4          1649     17366  16095232    5  Extended
> /dev/sda5          1649      5554   3999728   83  Linux
> /dev/sda6          5555      9460   3999728   82  Linux swap
> /dev/sda7          9461     13366   3999728   83  Linux
> /dev/sda8         13367     17366   4095984   83  Linux

which of these are you trying to write to?
sda3?

> Do you know someone who is well aware of iodc calls ?
> I want to discuss a bit about this.

hmm...inside HP there are a few people who've mucked with IODC.
Let's see if we can figure it out here first.

thanks,
grant

Re: [parisc-linux] iodc call and HPMC: dump driver.

[Grant Grundler]

Bruno Vidal wrote:
> DUMPDEV_WRITE = 1

I've found the right set of constants and argument parameters.
Those are now committed to include/asm-parisc/pdc.h.

I just realized the comments are incomplete...I only
included ARG0-ARG5 - there can be 8 args depending on
the call...hmm...I'll omit and document in the code
where it's used.

thanks,
grant

Re: [parisc-linux] iodc call and HPMC: dump driver.

[Grant Grundler]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2183 bytes --]

Bruno Vidal wrote:
> ret =  real32_call(PAGE0->mem_boot.iodc_io,
	ARG0	(unsigned long)PAGE0->mem_boot.hpa,
	ARG1	DUMPDEV_WRITE,
	ARG2	PAGE0->mem_boot.spa
	ARG3	__pa(PAGE0->mem_boot.dp.layers)
	ARG4	__pa(pdc_result)
	ARG5	devaddr
	ARG6	__pa(iodc_dbuf)
	ARG7	2048);

The parameters "look" ok.

> DUMPDEV_WRITE = 1
> static unsigned long pdc_result[32] __attribute__ ((aligned (8))); 
> static char __attribute__((aligned(64))) iodc_dbuf[DUMP_PAGE_SZ];
> 
> and devaddr=191889408

except the value of this one. I'm pretty sure now it's wrong.

IO ACD, page 520 of 646 (aka 13-48) says:
Description:    The argument reqsize specifies the amount of data that the
	caller would like to write. It must be a multiple of 2 Kbytes, but
	is otherwise unconstrained. The data to write is in memory at the
	address specified by memaddr. The value of memaddr must be a multiple
	of 64 bytes. The address on the device medium, devaddr, must be 2
	Kbyte aligned. If the call returns a nonnegative status, the return
	parameter count is the number of bytes actually output; it must be a
	multiple of 2 Kbytes. If the call returns a negative status, the
	value of count and the data written are HVERSION dependent.

IO ACD, page 491 of 646 (aka 13-19) says:
13.3.8  Data Types
The data types of the standard arguments and return parameters are as follows:
· All signed integers are represented in two's complement (32-bit) format.
· The status value returned by all IODC entry points in GR28 is a signed integer.
· All addresses, which are passed as arguments, or returned as parameters, are 32-bit unsigned integers.
· The data type of ARG0 in all IODC entry points is a 32-bit unsigned integer.
· The data type of ARG1 in all IODC entry points is a 32-bit unsigned integer.

One might assume devaddr is treated as an "unsigned" integer.
But most older IODC are broken and treat it as a signed value.
(ie anything shipped before ~1996-1998)

I wouldn't trust newer boxes to get it right either.
Once you get ENTRY_IO_BOOT_OUT working, I suggest trying to
use ENTRY_IO_BBLOCK_OUT that's now defined in <asm/pdc.h> first
and if that fails (not implemented), fall back to ENTRY_IO_BOOT_OUT.

hth,
grant

Re: [parisc-linux] iodc call and HPMC: dump driver.

[Bruno Vidal]

[-- Attachment #1: Type: text/plain, Size: 668 bytes --]

	Hi
I'm really surprised, I take a look at HPMC trace, and I was really
surprised of the faulty address. So I try to write on console.
And I m really surprised by the result:
PAGE0->mem_cons.hpa: 0x2000
PAGE0->mem_boot.hpa: 0x900
PAGE0->mem_kbd.hpa: 0xffffffff 

It is not good at all !!! It seems to be completly wrong hpa !!!!
The good one for mem_boot.hpa must be: 0xfffffffffed30000 (in my case
according to dmesg and mapio). But the system has boot,
so it was correct a few time ago. I'll retry by using my own
hpa and I'll don't trust anymore PAGE0.

	Bye.

-- 
	Vidal Bruno, (770-4271)
        SSD-HA Team, HP-UX & LINUX Support
	bruno_vidal@admin.france.hp.com

[-- Attachment #2: Card for Bruno Vidal --]
[-- Type: text/x-vcard, Size: 386 bytes --]

begin:vcard 
n:Bruno;VIDAL
tel;fax:01-69-82-60-14
tel;work:01-69-29-42-71
x-mozilla-html:TRUE
url:www.france.hp.com
org:Solution Center
version:2.1
email;internet:bruno_vidal@hp.com
title:Expert Logiciel Environnement Haute Disponibilité
adr;quoted-printable:;;HP France=0D=0A;Z.A de Courtaboeuf;1 Av. du Canada;91947 Les Ulis cedex;France
x-mozilla-cpt:;26208
fn:VIDAL Bruno
end:vcard

Re: [parisc-linux] iodc call and HPMC: dump driver.

[Grant Grundler]

Bruno Vidal wrote:
> This is a multi-part message in MIME format.
> --------------9FA0B36E1D5BF1A98D31930A
> Content-Type: text/plain; charset=us-ascii
> Content-Transfer-Encoding: 7bit
> 
> 	Hi
> I'm really surprised, I take a look at HPMC trace, and I was really
> surprised of the faulty address. So I try to write on console.
> And I m really surprised by the result:
> PAGE0->mem_cons.hpa: 0x2000
> PAGE0->mem_boot.hpa: 0x900
> PAGE0->mem_kbd.hpa: 0xffffffff 

Which model machine is this from?

> It is not good at all !!! It seems to be completly wrong hpa !!!!

Note that "hpa" might just be a "handle" and not a real physical address.
It depends on the firmware. Usually it's the physical address though.
I think something else is wrong with your definition or something.

PAGE0 is used in arch/parisc/kernel/firmware.c, inventory.c, pdc_cons.c
and it works in those locations.

> The good one for mem_boot.hpa must be: 0xfffffffffed30000 (in my case
> according to dmesg and mapio). But the system has boot,

No - it doesn't have to be.

> so it was correct a few time ago. I'll retry by using my own
> hpa and I'll don't trust anymore PAGE0.

Well, modify palo to dump interesting page zero values and then
you'll know what they are supposed to be. I'm pretty sure
firmware sets that up.

hth,
grant