spitz (zaurus sl-c3000) support

spitz (zaurus sl-c3000) support

[Pavel Machek]

Hi!

I got spitz machine today. I thought oz3.5.3 for spitz would be
2.6-based, but found out that I'm not _that_ fortunate.

What's the status of spitz? I see log from 2.6.12-rc boot, and pages
at http://www.orca.cx/zaurus/ seem to be old...

Is there simple way to tell spitz and tosa apart (like without opening
the machine)?

Aha, I realized that spitz support came into 2.6.14-rc2, so something
definitely _is_ happening. Are there newer patches than orca.cx
somewhere?

								Pavel
-- 
Thanks, Sharp!

Re: spitz (zaurus sl-c3000) support

[Richard Purdie]

On Thu, 2005-10-13 at 00:30 +0200, Pavel Machek wrote:
> Hi!
> 
> I got spitz machine today. I thought oz3.5.3 for spitz would be
> 2.6-based, but found out that I'm not _that_ fortunate.

oz 3.5.4 is due for release soon and will hopefully have a 2.6 option
for spitz.

> What's the status of spitz? I see log from 2.6.12-rc boot, and pages
> at http://www.orca.cx/zaurus/ seem to be old...

Its outdated now.

> Is there simple way to tell spitz and tosa apart (like without opening
> the machine)?

At what level? machine_is_spitz() and machine_is_tosa()? There are some
checks in the sharpsl head file to auto detect all the Zaurus machines
and set the machine numbers. For those two machines the difference is
the presence of the tc6393 chip in tosa. See head-sharpsl.S

> Aha, I realized that spitz support came into 2.6.14-rc2, so something
> definitely _is_ happening. Are there newer patches than orca.cx
> somewhere?

I got a spitz recently which moved 2.6 for it forwards a lot. Have a
look at:

http://www.rpsys.net/openzaurus/

This file should give you an idea of which patches to apply in what
order:
http://www.rpsys.net/openzaurus/temp/linux-openzaurus_2.6.14-rc1.bb

With my patch series applied, we're missing usb client (usb host works)
and sound support.

Mainline is missing power management and currently fails to compile
without my patch series but I'm working on that.

Richard

Re: spitz (zaurus sl-c3000) support

[Pavel Machek]

Hi!

> > I got spitz machine today. I thought oz3.5.3 for spitz would be
> > 2.6-based, but found out that I'm not _that_ fortunate.
> 
> oz 3.5.4 is due for release soon and will hopefully have a 2.6 option
> for spitz.

Is there chance to get preview version somewhere? 2.6-capable userland
would be very nice (and zImage would help, too, just for a demo :-).

> > Is there simple way to tell spitz and tosa apart (like without opening
> > the machine)?
> 
> At what level? machine_is_spitz() and machine_is_tosa()? There are some
> checks in the sharpsl head file to auto detect all the Zaurus machines
> and set the machine numbers. For those two machines the difference is
> the presence of the tc6393 chip in tosa. See head-sharpsl.S

I was thinking about "huh, is this machine tosa or spitz", but it is
labeled SL-C3000, so it should be spitz.

> > Aha, I realized that spitz support came into 2.6.14-rc2, so something
> > definitely _is_ happening. Are there newer patches than orca.cx
> > somewhere?
> 
> I got a spitz recently which moved 2.6 for it forwards a lot. Have a
> look at:
> 
> http://www.rpsys.net/openzaurus/

Wildly offtopic... I got poweradapter with spitz (with funny design)
that says 100V (and lot of japanese letters).. I guess it would be
very bad idea to try it at 240V?

> This file should give you an idea of which patches to apply in what
> order:
> http://www.rpsys.net/openzaurus/temp/linux-openzaurus_2.6.14-rc1.bb

Quite a long list; what is $RPSRC -- that is where are those patches
really placed? Is there some way I can help you (besides obviously
testing)?

> With my patch series applied, we're missing usb client (usb host works)
> and sound support.
> 
> Mainline is missing power management and currently fails to compile
> without my patch series but I'm working on that.

Yes, asm/arch/ohci.h seems to be missing... But I should probably do
update, I'm at rc2 with my zaurus hacks now.

								Pavel
-- 
Thanks, Sharp!

Re: spitz (zaurus sl-c3000) support

[Richard Purdie]

On Thu, 2005-10-13 at 01:39 +0200, Pavel Machek wrote:
> Hi!
> 
> > > I got spitz machine today. I thought oz3.5.3 for spitz would be
> > > 2.6-based, but found out that I'm not _that_ fortunate.
> > 
> > oz 3.5.4 is due for release soon and will hopefully have a 2.6 option
> > for spitz.
> 
> Is there chance to get preview version somewhere? 2.6-capable userland
> would be very nice (and zImage would help, too, just for a demo :-).

I'm no sure offical preview images exist but here's something I built
myself recently:

http://www.rpsys.net/openzaurus/temp/spitz/

Rename the gpe or opie file "hdimage1.tgz" to flash depending on what
flavoured image you'd like. You need the other files including gnu-tar.
You don't need an initrd.bin file as under 2.6 we can boot directly from
the microdrive.

I'm hoping these work - I'm not sure I've tried one of them... :)

> I was thinking about "huh, is this machine tosa or spitz", but it is
> labeled SL-C3000, so it should be spitz.

Correct. Tosa is SL-C6000.

> Wildly offtopic... I got poweradapter with spitz (with funny design)
> that says 100V (and lot of japanese letters).. I guess it would be
> very bad idea to try it at 240V?

Trust me, its a very bad idea...

> > This file should give you an idea of which patches to apply in what
> > order:
> > http://www.rpsys.net/openzaurus/temp/linux-openzaurus_2.6.14-rc1.bb
> 
> Quite a long list; what is $RPSRC -- that is where are those patches
> really placed? 

Its declared in:
http://www.rpsys.net/openzaurus/temp/linux-openzaurus.inc

so $RPSRC = http://www.rpsys.net/openzaurus/patches

You probably don't need the ipaq hx2750 or tosa patches, they're just
part of my tree. The top 15 patches have been merged since -rc1 came out
(they were in the process of being merged at the time).

> Yes, asm/arch/ohci.h seems to be missing... But I should probably do
> update, I'm at rc2 with my zaurus hacks now.

That's still a problem although a patch queued for 2.6.15 will add that
file so I'm in two minds as to what to do with it. There's also an issue
with struct pxafb_device which I've agreed a solution to, just need to
write the patch and I think a reference to the battery device sneaked
into mainline when it shouldn't have done.

> Is there some way I can help you (besides obviously testing)?

I'm open to any help in getting the none ipaq/tosa things merged with
mainline. Have a look through them patch series and see if there's
anything you fancy taking on. Most of them are simple fixes although
some are nasty hacks we need to find some way of doing nicely.

The biggest thing is the battery/power management patch. I've just
agreed some changes to enable it to stand a chance of making mainline.
It probably needs more coding style cleanup.

There's also sound to get working although so code arrived yesterday
which should help with that. The usb client code exists in
handheld.org's kernel26 cvs tree. We need to extract it, fix any bugs
and talk to the usb developers about it.

Its a shame you don't have a C1000 as there's a nasty bit of coding
someone with such a device needs to do to complete mainline 2.6 support
(I2C driver for its IO Expander to enable access to its extra GPIOs).

Richard

Re: spitz (zaurus sl-c3000) support

[Pavel Machek]

Hi!

> > > > I got spitz machine today. I thought oz3.5.3 for spitz would be
> > > > 2.6-based, but found out that I'm not _that_ fortunate.
> > > 
> > > oz 3.5.4 is due for release soon and will hopefully have a 2.6 option
> > > for spitz.
> > 
> > Is there chance to get preview version somewhere? 2.6-capable userland
> > would be very nice (and zImage would help, too, just for a demo :-).
> 
> I'm no sure offical preview images exist but here's something I built
> myself recently:
> 
> http://www.rpsys.net/openzaurus/temp/spitz/

Thanks. Kernel works, even with 3.5.3 opie. [But touchscreen gets
extremely interesting, you have to click top-right corner to get it to
register click in bottom-left].

> Rename the gpe or opie file "hdimage1.tgz" to flash depending on what
> flavoured image you'd like. You need the other files including gnu-tar.
> You don't need an initrd.bin file as under 2.6 we can boot directly from
> the microdrive.

You mean I should place tar binary on flashcard, because updater.sh
needs it? [What is updater.sh anyway, xor 0x5e encrypted shell
script?!]

> > Wildly offtopic... I got poweradapter with spitz (with funny design)
> > that says 100V (and lot of japanese letters).. I guess it would be
> > very bad idea to try it at 240V?
> 
> Trust me, its a very bad idea...

Oh, okay, one more question. Do you trust your battery charging code
enough to leave spitz overnight in charger? I would hate to be awaken
by angry lithium ;-).

								Pavel
-- 
Thanks, Sharp!

Re: spitz (zaurus sl-c3000) support

[Richard Purdie]

On Fri, 2005-10-14 at 00:44 +0200, Pavel Machek wrote:
> Thanks. Kernel works, even with 3.5.3 opie. [But touchscreen gets
> extremely interesting, you have to click top-right corner to get it to
> register click in bottom-left].

Yes, there's a bug in the opie (qte specifically) calibration code which
is fixed in 3.5.4 (I fixed it). I ended up replacing qte's algorithm
with a decent 5 point one.

> > Rename the gpe or opie file "hdimage1.tgz" to flash depending on what
> > flavoured image you'd like. You need the other files including gnu-tar.
> > You don't need an initrd.bin file as under 2.6 we can boot directly from
> > the microdrive.
> 
> You mean I should place tar binary on flashcard, because updater.sh
> needs it? [What is updater.sh anyway, xor 0x5e encrypted shell
> script?!]

Yes, place the file as gnu.tar on the flashcard with updater.sh.
updater.sh is indeed an "encrypted" shell script! There are tools around
to decode/encode it.

> Oh, okay, one more question. Do you trust your battery charging code
> enough to leave spitz overnight in charger? I would hate to be awaken
> by angry lithium ;-).

My spitz has been left plugged in all the time with my charging code and
has yet to explode. ;-) Its very similar to the c7x0 code which people
have happily been using for a while in OpenZaurus c7x0 2.6. Spitz does
contain a charging chip which should prevent major damage to the
battery. The software just tries to help it along...

Cheers,

Richard

Re: spitz (zaurus sl-c3000) support

[Pavel Machek]

Hi!

> > Thanks. Kernel works, even with 3.5.3 opie. [But touchscreen gets
> > extremely interesting, you have to click top-right corner to get it to
> > register click in bottom-left].
> 
> Yes, there's a bug in the opie (qte specifically) calibration code which
> is fixed in 3.5.4 (I fixed it). I ended up replacing qte's algorithm
> with a decent 5 point one.
...
> Yes, place the file as gnu.tar on the flashcard with updater.sh.
> updater.sh is indeed an "encrypted" shell script! There are tools around
> to decode/encode it.

Yes, now it updated correctly. Thanks!

> > Oh, okay, one more question. Do you trust your battery charging code
> > enough to leave spitz overnight in charger? I would hate to be awaken
> > by angry lithium ;-).
> 
> My spitz has been left plugged in all the time with my charging code and
> has yet to explode. ;-) Its very similar to the c7x0 code which people
> have happily been using for a while in OpenZaurus c7x0 2.6. Spitz does
> contain a charging chip which should prevent major damage to the
> battery. The software just tries to help it along...

Charge led does not go off, but pavouk (has c7x0) told me that's
pretty much normal. It made me a bit nervous.
								Pavel
-- 
Boycott Kodak -- for their patent abuse against Java.

Re: spitz (zaurus sl-c3000) support

[Richard Purdie]

On Tue, 2005-10-18 at 10:15 +0200, Pavel Machek wrote:
> > > Oh, okay, one more question. Do you trust your battery charging code
> > > enough to leave spitz overnight in charger? I would hate to be awaken
> > > by angry lithium ;-).
> > 
> > My spitz has been left plugged in all the time with my charging code and
> > has yet to explode. ;-) Its very similar to the c7x0 code which people
> > have happily been using for a while in OpenZaurus c7x0 2.6. Spitz does
> > contain a charging chip which should prevent major damage to the
> > battery. The software just tries to help it along...
> 
> Charge led does not go off, but pavouk (has c7x0) told me that's
> pretty much normal. It made me a bit nervous.

The charge LED should go off but it won't if the device isn't suspended
as when running, the device draws enough current to keep the charger
active.

Help on improving the charging code is of course welcome ;-)

Richard

Re: spitz (zaurus sl-c3000) support

[Pavel Machek]

Hi!

> > > > Oh, okay, one more question. Do you trust your battery charging code
> > > > enough to leave spitz overnight in charger? I would hate to be awaken
> > > > by angry lithium ;-).
> > > 
> > > My spitz has been left plugged in all the time with my charging code and
> > > has yet to explode. ;-) Its very similar to the c7x0 code which people
> > > have happily been using for a while in OpenZaurus c7x0 2.6. Spitz does
> > > contain a charging chip which should prevent major damage to the
> > > battery. The software just tries to help it along...
> > 
> > Charge led does not go off, but pavouk (has c7x0) told me that's
> > pretty much normal. It made me a bit nervous.
> 
> The charge LED should go off but it won't if the device isn't suspended
> as when running, the device draws enough current to keep the charger
> active.
> 
> Help on improving the charging code is of course welcome ;-)

Of course :-). Question: is there some reasonable way to get the spitz
patches, or maybe to just get all of your patches? I was doing

#!/bin/bash
# # >
#http://www.rpsys.net/openzaurus/temp/linux-openzaurus_2.6.14-rc1.bb
# #
# # Quite a long list; what is $RPSRC -- that is where are those
#patches
# # really placed?
#
#Its declared in:
#http://www.rpsys.net/openzaurus/temp/linux-openzaurus.inc

RPSRC=http://www.rpsys.net/openzaurus/patches

# You probably don't need the ipaq hx2750 or tosa patches, they're
just
# part of my tree. The top 15 patches have been merged since -rc1 came
out
# (they were in the process of being merged at the time).

for A in pxa_i2c_fixes-r0.patch pxa_ohci_platform-r1.patch
pxa_ohci_suspend-r0.patch poodle_irda-r0.patch
ide_not_removable-r0.patch sharpsl_pm-r8.patch corgi_pm-r4.patch
spitz_base_extras-r2.patch spitz_pm-r4.patch spitz_kbd_fix1-r0.patch
spitzcf-r3.patch pxa_timerfix-r0.patch pxa_remove_static-r0.patch
pxa_irda-r4.patch corgi_irda-r3.patch pxa_rtc-r1.patch
input_power-r2.patch jffs2_longfilename-r0.patch
sharpsl_bl_kick-r1.patch corgi_snd-r10.patch pxa2xx-ir-dma-r0.patch
tc6393-device-r5.patch tc6393_nand-r6.patch pcmcia_dev_ids-r2.patch
mmc_timeout-r0.patch pxa_cf_initorder_hack-r1.patch; do
#       wget $RPSRC/$A
    cat /data/l/zaurus/spitz.patches/$A | cg-patch
    pshell
done

.... but that's ather poor trick. Few patches broke the download (slow
line here), and few of them broke compilation later...

								Pavel
-- 
Thanks, Sharp!

[MTD patch] Make sharp.c compile

[Richard Purdie]

[MTD] Update the pre-CFI Sharp driver sharps.c so it compiles.
map_read32 / map_write32 no longer exist in the kernel so the driver is
totally broken as it stands. The replacement functions use different
parameters resulting in the other changes.

Change collie to use this driver until someone works out why the cfi
driver fails on that machine.

Signed-off-by: Richard Purdie <rpurdie@rpsys.net>
Tested-by: Pavel Machek <pavel@suse.cz>

Index: linux-2.6.14/arch/arm/mach-sa1100/collie.c
===================================================================
--- linux-2.6.14.orig/arch/arm/mach-sa1100/collie.c	2005-11-09 19:20:08.000000000 +0000
+++ linux-2.6.14/arch/arm/mach-sa1100/collie.c	2005-11-09 19:25:40.000000000 +0000
@@ -119,7 +119,7 @@
 }
 
 static struct flash_platform_data collie_flash_data = {
-	.map_name	= "cfi_probe",
+	.map_name	= "sharp",
 	.set_vpp	= collie_set_vpp,
 	.parts		= collie_partitions,
 	.nr_parts	= ARRAY_SIZE(collie_partitions),
Index: linux-2.6.14/drivers/mtd/chips/sharp.c
===================================================================
--- linux-2.6.14.orig/drivers/mtd/chips/sharp.c	2005-11-09 19:20:10.000000000 +0000
+++ linux-2.6.14/drivers/mtd/chips/sharp.c	2005-11-09 20:26:15.000000000 +0000
@@ -160,22 +160,28 @@
 	return mtd;
 }
 
+static inline void sharp_send_cmd(struct map_info *map, unsigned long cmd, unsigned long adr)
+{
+	map_word map_cmd;
+	map_cmd.x[0] = cmd;
+	map_write(map, map_cmd, adr);
+}
+
 static int sharp_probe_map(struct map_info *map,struct mtd_info *mtd)
 {
-	unsigned long tmp;
+	map_word tmp, read0, read4;
 	unsigned long base = 0;
-	u32 read0, read4;
 	int width = 4;
 
-	tmp = map_read32(map, base+0);
+	tmp = map_read(map, base+0);
 
-	map_write32(map, CMD_READ_ID, base+0);
+	sharp_send_cmd(map, CMD_READ_ID, base+0);
 
-	read0=map_read32(map, base+0);
-	read4=map_read32(map, base+4);
-	if(read0 == 0x89898989){
+	read0 = map_read(map, base+0);
+	read4 = map_read(map, base+4);
+	if(read0.x[0] == 0x89898989){
 		printk("Looks like sharp flash\n");
-		switch(read4){
+		switch(read4.x[0]){
 		case 0xaaaaaaaa:
 		case 0xa0a0a0a0:
 			/* aa - LH28F016SCT-L95 2Mx8, 32 64k blocks*/
@@ -197,16 +203,16 @@
 			return width;
 #endif
 		default:
-			printk("Sort-of looks like sharp flash, 0x%08x 0x%08x\n",
-				read0,read4);
+			printk("Sort-of looks like sharp flash, 0x%08lx 0x%08lx\n",
+				read0.x[0], read4.x[0]);
 		}
-	}else if((map_read32(map, base+0) == CMD_READ_ID)){
+	}else if((map_read(map, base+0).x[0] == CMD_READ_ID)){
 		/* RAM, probably */
 		printk("Looks like RAM\n");
-		map_write32(map, tmp, base+0);
+		map_write(map, tmp, base+0);
 	}else{
-		printk("Doesn't look like sharp flash, 0x%08x 0x%08x\n",
-			read0,read4);
+		printk("Doesn't look like sharp flash, 0x%08lx 0x%08lx\n",
+			read0.x[0], read4.x[0]);
 	}
 
 	return 0;
@@ -215,7 +221,8 @@
 /* This function returns with the chip->mutex lock held. */
 static int sharp_wait(struct map_info *map, struct flchip *chip)
 {
-	int status, i;
+	int i;
+	map_word status;
 	unsigned long timeo = jiffies + HZ;
 	DECLARE_WAITQUEUE(wait, current);
 	int adr = 0;
@@ -225,12 +232,12 @@
 
 	switch(chip->state){
 	case FL_READY:
-		map_write32(map,CMD_READ_STATUS,adr);
+		sharp_send_cmd(map, CMD_READ_STATUS, adr);
 		chip->state = FL_STATUS;
 	case FL_STATUS:
 		for(i=0;i<100;i++){
-			status = map_read32(map,adr);
-			if((status & SR_READY)==SR_READY)
+			status = map_read(map, adr);
+			if((status.x[0] & SR_READY)==SR_READY)
 				break;
 			udelay(1);
 		}
@@ -254,7 +261,7 @@
 		goto retry;
 	}
 
-	map_write32(map,CMD_RESET, adr);
+	sharp_send_cmd(map, CMD_RESET, adr);
 
 	chip->state = FL_READY;
 
@@ -351,37 +358,39 @@
 	int timeo;
 	int try;
 	int i;
-	int status = 0;
+	map_word data, status;
 
+	status.x[0] = 0;
 	ret = sharp_wait(map,chip);
 
 	for(try=0;try<10;try++){
-		map_write32(map,CMD_BYTE_WRITE,adr);
+		sharp_send_cmd(map, CMD_BYTE_WRITE, adr);
 		/* cpu_to_le32 -> hack to fix the writel be->le conversion */
-		map_write32(map,cpu_to_le32(datum),adr);
+		data.x[0] = cpu_to_le32(datum);
+		map_write(map, data, adr);
 
 		chip->state = FL_WRITING;
 
 		timeo = jiffies + (HZ/2);
 
-		map_write32(map,CMD_READ_STATUS,adr);
+		sharp_send_cmd(map, CMD_READ_STATUS, adr);
 		for(i=0;i<100;i++){
-			status = map_read32(map,adr);
-			if((status & SR_READY)==SR_READY)
+			status = map_read(map, adr);
+			if((status.x[0] & SR_READY) == SR_READY)
 				break;
 		}
 		if(i==100){
 			printk("sharp: timed out writing\n");
 		}
 
-		if(!(status&SR_ERRORS))
+		if(!(status.x[0] & SR_ERRORS))
 			break;
 
-		printk("sharp: error writing byte at addr=%08lx status=%08x\n",adr,status);
+		printk("sharp: error writing byte at addr=%08lx status=%08lx\n", adr, status.x[0]);
 
-		map_write32(map,CMD_CLEAR_STATUS,adr);
+		sharp_send_cmd(map, CMD_CLEAR_STATUS, adr);
 	}
-	map_write32(map,CMD_RESET,adr);
+	sharp_send_cmd(map, CMD_RESET, adr);
 	chip->state = FL_READY;
 
 	wake_up(&chip->wq);
@@ -434,18 +443,18 @@
 {
 	int ret;
 	unsigned long timeo;
-	int status;
+	map_word status;
 	DECLARE_WAITQUEUE(wait, current);
 
-	map_write32(map,CMD_READ_STATUS,adr);
-	status = map_read32(map,adr);
+	sharp_send_cmd(map, CMD_READ_STATUS, adr);
+	status = map_read(map, adr);
 
 	timeo = jiffies + HZ;
 
 	while(time_before(jiffies, timeo)){
-		map_write32(map,CMD_READ_STATUS,adr);
-		status = map_read32(map,adr);
-		if((status & SR_READY)==SR_READY){
+		sharp_send_cmd(map, CMD_READ_STATUS, adr);
+		status = map_read(map, adr);
+		if((status.x[0] & SR_READY)==SR_READY){
 			ret = 0;
 			goto out;
 		}
@@ -476,7 +485,7 @@
 {
 	int ret;
 	//int timeo;
-	int status;
+	map_word status;
 	//int i;
 
 //printk("sharp_erase_oneblock()\n");
@@ -486,26 +495,26 @@
 	sharp_unlock_oneblock(map,chip,adr);
 #endif
 
-	map_write32(map,CMD_BLOCK_ERASE_1,adr);
-	map_write32(map,CMD_BLOCK_ERASE_2,adr);
+	sharp_send_cmd(map, CMD_BLOCK_ERASE_1, adr);
+	sharp_send_cmd(map, CMD_BLOCK_ERASE_2, adr);
 
 	chip->state = FL_ERASING;
 
 	ret = sharp_do_wait_for_ready(map,chip,adr);
 	if(ret<0)return ret;
 
-	map_write32(map,CMD_READ_STATUS,adr);
-	status = map_read32(map,adr);
+	sharp_send_cmd(map, CMD_READ_STATUS, adr);
+	status = map_read(map, adr);
 
-	if(!(status&SR_ERRORS)){
-		map_write32(map,CMD_RESET,adr);
+	if(!(status.x[0] & SR_ERRORS)){
+		sharp_send_cmd(map, CMD_RESET, adr);
 		chip->state = FL_READY;
 		//spin_unlock_bh(chip->mutex);
 		return 0;
 	}
 
-	printk("sharp: error erasing block at addr=%08lx status=%08x\n",adr,status);
-	map_write32(map,CMD_CLEAR_STATUS,adr);
+	printk("sharp: error erasing block at addr=%08lx status=%08lx\n", adr, status.x[0]);
+	sharp_send_cmd(map, CMD_CLEAR_STATUS, adr);
 
 	//spin_unlock_bh(chip->mutex);
 
@@ -517,20 +526,20 @@
 	unsigned long adr)
 {
 	int i;
-	int status;
+	map_word status;
 
-	map_write32(map,CMD_CLEAR_BLOCK_LOCKS_1,adr);
-	map_write32(map,CMD_CLEAR_BLOCK_LOCKS_2,adr);
+	sharp_send_cmd(map, CMD_CLEAR_BLOCK_LOCKS_1, adr);
+	sharp_send_cmd(map, CMD_CLEAR_BLOCK_LOCKS_2, adr);
 
 	udelay(100);
 
-	status = map_read32(map,adr);
-	printk("status=%08x\n",status);
+	status = map_read(map, adr);
+	printk("status=%08lx\n", status.x[0]);
 
 	for(i=0;i<1000;i++){
-		//map_write32(map,CMD_READ_STATUS,adr);
-		status = map_read32(map,adr);
-		if((status & SR_READY)==SR_READY)
+		//sharp_send_cmd(map, CMD_READ_STATUS, adr);
+		status = map_read(map, adr);
+		if((status.x[0] & SR_READY) == SR_READY)
 			break;
 		udelay(100);
 	}
@@ -538,14 +547,14 @@
 		printk("sharp: timed out unlocking block\n");
 	}
 
-	if(!(status&SR_ERRORS)){
-		map_write32(map,CMD_RESET,adr);
+	if(!(status.x[0] & SR_ERRORS)){
+		sharp_send_cmd(map, CMD_RESET, adr);
 		chip->state = FL_READY;
 		return;
 	}
 
-	printk("sharp: error unlocking block at addr=%08lx status=%08x\n",adr,status);
-	map_write32(map,CMD_CLEAR_STATUS,adr);
+	printk("sharp: error unlocking block at addr=%08lx status=%08lx\n", adr, status.x[0]);
+	sharp_send_cmd(map, CMD_CLEAR_STATUS, adr);
 }
 #endif