arm: how to operate leds on zaurus?

arm: how to operate leds on zaurus?

[Pavel Machek]

Hi!

2.6.12-rc5 (and newer) does not boot on sharp zaurus sl-5500. It
blinks with green led, fast; what does it mean? I'd like to verify if
it at least reaches .c code in setup.c. I inserted this code at
begining of setup.c:674...

#define locomo_writel(val,addr) ({ *(volatile u16 *)(addr) = (val); })
#define LOCOMO_LPT_TOFH         0x80
#define LOCOMO_LED              0xe8
#define LOCOMO_LPT0             0x00

      locomo_writel(LOCOMO_LPT_TOFH, LOCOMO_LPT0 + LOCOMO_LED);

...but that does not seem to do a trick -- it only breaks the boot :-(
(do I need to add some kind of IO_BASE?).
								Pavel
-- 
teflon -- maybe it is a trademark, but it should not be.

Re: arm: how to operate leds on zaurus?

[Russell King]

On Mon, Jul 11, 2005 at 09:34:54PM +0200, Pavel Machek wrote:
> Hi!
> 
> 2.6.12-rc5 (and newer) does not boot on sharp zaurus sl-5500. It
> blinks with green led, fast; what does it mean? I'd like to verify if
> it at least reaches .c code in setup.c. I inserted this code at
> begining of setup.c:674...
> 
> #define locomo_writel(val,addr) ({ *(volatile u16 *)(addr) = (val); })
> #define LOCOMO_LPT_TOFH         0x80
> #define LOCOMO_LED              0xe8
> #define LOCOMO_LPT0             0x00
> 
>       locomo_writel(LOCOMO_LPT_TOFH, LOCOMO_LPT0 + LOCOMO_LED);
> 
> ...but that does not seem to do a trick -- it only breaks the boot :-(

Basically because you do not have access to IO during the early boot.
The easiest debugging solution is to enable CONFIG_DEBUG_LL and
throw a printascii(printk_buf) into printk.c, after vscnprintf.
That might get you some boot messages through the serial port (if
it's implemented it correctly.)

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core

Re: arm: how to operate leds on zaurus?

[Pavel Machek]

Hi!

> > 2.6.12-rc5 (and newer) does not boot on sharp zaurus sl-5500. It
> > blinks with green led, fast; what does it mean? I'd like to verify if
> > it at least reaches .c code in setup.c. I inserted this code at
> > begining of setup.c:674...
> > 
> > #define locomo_writel(val,addr) ({ *(volatile u16 *)(addr) = (val); })
> > #define LOCOMO_LPT_TOFH         0x80
> > #define LOCOMO_LED              0xe8
> > #define LOCOMO_LPT0             0x00
> > 
> >       locomo_writel(LOCOMO_LPT_TOFH, LOCOMO_LPT0 + LOCOMO_LED);
> > 
> > ...but that does not seem to do a trick -- it only breaks the boot :-(
> 
> Basically because you do not have access to IO during the early boot.
> The easiest debugging solution is to enable CONFIG_DEBUG_LL and
> throw a printascii(printk_buf) into printk.c, after vscnprintf.
> That might get you some boot messages through the serial port (if
> it's implemented it correctly.)

I'm afraid I do not have serial cable :-(. I'll try to get one [erik,
do you have one you don't need?], but zaurus has "little" nonstandard
connector.

Would code above work if executed later?
								Pavel
-- 
teflon -- maybe it is a trademark, but it should not be.

Re: arm: how to operate leds on zaurus?

[John Lenz]

On Mon, July 11, 2005 2:34 pm, Pavel Machek said:
> Hi!
>
> 2.6.12-rc5 (and newer) does not boot on sharp zaurus sl-5500. It
> blinks with green led, fast; what does it mean? I'd like to verify if
> it at least reaches .c code in setup.c. I inserted this code at
> begining of setup.c:674...
>
> #define locomo_writel(val,addr) ({ *(volatile u16 *)(addr) = (val); })
> #define LOCOMO_LPT_TOFH         0x80
> #define LOCOMO_LED              0xe8
> #define LOCOMO_LPT0             0x00
>
>       locomo_writel(LOCOMO_LPT_TOFH, LOCOMO_LPT0 + LOCOMO_LED);
>
> ...but that does not seem to do a trick -- it only breaks the boot :-(
> (do I need to add some kind of IO_BASE?).
> 								Pavel

No, that won't work.

As Russell said, there are problems accessing memory before the io maps
have been set up correctly.  You can see the patch
http://www.cs.wisc.edu/~lenz/zaurus/files/2.6.12-rc5/lenz-03-leds-2.6.12-rc5.patch
need scroll near the bottom in file locomo.c to see how the led gets set. 
You won't actually be able to know where in memory that space is mapped
because we call ioremap, and won't be able to access the locomo stuff
until device_initcall.

WARNING: Horrible hack!  Ugly, ugly, ugly!  First read and understand the
warning at
http://lists.arm.linux.org.uk/pipermail/linux-arm-kernel/2002-January/006730.html

Having said that, either before the MMU has been activated or before the
ioremap() has been called, it is sometimes possible to access the LEDs at
the physical addresses they are located at.  This may or may not work,
might not always work, etc... but it can help as a last resort.  On the
SL5500, the physical address of the start of the locomo chip is
0x40000000, and the leds are at an offset of 0xe8, so something like
volatile u16 *led = (volatile u16 *)0x400000e8;
*led = 0x80;
As the above email says, this is not guarenteed to work at all, will fail
at some point in the boot process, but is something you can try.

That said, I am aware that recent kernel versions have broken the boot on
collie, but haven't looked at the problem in detail (i.e. tried doing a
binary search between known working versions and broken ones to see the
patch that introduced the problem).  I have been working on the SL5600
recently.

John

Re: arm: how to operate leds on zaurus?

[Hamera Erik]

> > > 2.6.12-rc5 (and newer) does not boot on sharp zaurus sl-5500. It
> > > blinks with green led, fast; what does it mean? I'd like to verify if
> > > it at least reaches .c code in setup.c. I inserted this code at
> > > begining of setup.c:674...
> > > 
> > > #define locomo_writel(val,addr) ({ *(volatile u16 *)(addr) = (val); })
> > > #define LOCOMO_LPT_TOFH         0x80
> > > #define LOCOMO_LED              0xe8
> > > #define LOCOMO_LPT0             0x00
> > > 
> > >       locomo_writel(LOCOMO_LPT_TOFH, LOCOMO_LPT0 + LOCOMO_LED);
> > > 
> > > ...but that does not seem to do a trick -- it only breaks the boot :-(
> > 
> > Basically because you do not have access to IO during the early boot.
> > The easiest debugging solution is to enable CONFIG_DEBUG_LL and
> > throw a printascii(printk_buf) into printk.c, after vscnprintf.
> > That might get you some boot messages through the serial port (if
> > it's implemented it correctly.)
> 
> I'm afraid I do not have serial cable :-(. I'll try to get one [erik,
> do you have one you don't need?], but zaurus has "little" nonstandard
> connector.

I am sorry, I sold my SL-5500 before a few days. For build serial 
cable you need: connector, two negator gates (CMOS 4011, 74HCT00 ...), 
MAX232 (RS232 voltage level convertor) and DB9 serial connector. Circuit 
is a bit strange, because Zaurus have inverted TxD and RxD signals.
All parts I can buy in .cz without problems, only connector I can't.

Yokotashi

> 
> Would code above work if executed later?
> 								Pavel
> -- 
> teflon -- maybe it is a trademark, but it should not be.
> 

Re: arm: how to operate leds on zaurus?

[Russell King]

On Mon, Jul 11, 2005 at 09:50:59PM +0200, Pavel Machek wrote:
> I'm afraid I do not have serial cable :-(. I'll try to get one [erik,
> do you have one you don't need?], but zaurus has "little" nonstandard
> connector.
> 
> Would code above work if executed later?

If done after the IO mappings are setup.  That will be after
paging_init() has been called.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core

Sharp Zaurus sl-5500 broken in 2.6.12

[Pavel Machek]

Hi!

...and that's well known; but now I did some back tracking, and
2.6.12-rc1 works, 2.6.12-rc2 does *not* and 2.6.12-rc2 with arm
changes reverted works. I'll play a bit more.
							Pavel
-- 
Boycott Kodak -- for their patent abuse against Java.

Re: Sharp Zaurus sl-5500 broken in 2.6.12

[Pavel Machek]

Hi!

> ...and that's well known; but now I did some back tracking, and
> 2.6.12-rc1 works, 2.6.12-rc2 does *not* and 2.6.12-rc2 with arm
> changes reverted works. I'll play a bit more.

This fixes at least one break-the-boot bug in -rc2...

							Pavel

--- linux-z11.rc2bad/arch/arm/mach-sa1100/collie.c	2005-07-19 20:49:07.000000000 +0200
+++ linux-z11/arch/arm/mach-sa1100/collie.c	2005-07-19 21:05:54.000000000 +0200
@@ -235,7 +235,7 @@
 	sa11x0_set_flash_data(&collie_flash_data, collie_flash_resources,
 			      ARRAY_SIZE(collie_flash_resources));
 
-	sharpsl_save_param();
+//	sharpsl_save_param();
 }
 
 static struct map_desc collie_io_desc[] __initdata = {


-- 
teflon -- maybe it is a trademark, but it should not be.

Re: Sharp Zaurus sl-5500 broken in 2.6.12

[Richard Purdie]

On Tue, 2005-07-19 at 21:21 +0200, Pavel Machek wrote:
> Hi!
> 
> > ...and that's well known; but now I did some back tracking, and
> > 2.6.12-rc1 works, 2.6.12-rc2 does *not* and 2.6.12-rc2 with arm
> > changes reverted works. I'll play a bit more.
> 
> This fixes at least one break-the-boot bug in -rc2...
> 
> 							Pavel
> 
> --- linux-z11.rc2bad/arch/arm/mach-sa1100/collie.c	2005-07-19 20:49:07.000000000 +0200
> +++ linux-z11/arch/arm/mach-sa1100/collie.c	2005-07-19 21:05:54.000000000 +0200
> @@ -235,7 +235,7 @@
>  	sa11x0_set_flash_data(&collie_flash_data, collie_flash_resources,
>  			      ARRAY_SIZE(collie_flash_resources));
>  
> -	sharpsl_save_param();
> +//	sharpsl_save_param();
>  }
>  
>  static struct map_desc collie_io_desc[] __initdata = {

Could you check this wasn't caused by this typo please:

http://www.rpsys.net/openzaurus/patches/collie_typofix-r0.patch

(this has been fixed in recent kernels)

Cheers,

Richard

Re: Sharp Zaurus sl-5500 broken in 2.6.12

[Pavel Machek]

Hi!

> > > ...and that's well known; but now I did some back tracking, and
> > > 2.6.12-rc1 works, 2.6.12-rc2 does *not* and 2.6.12-rc2 with arm
> > > changes reverted works. I'll play a bit more.
> > 
> > This fixes at least one break-the-boot bug in -rc2...
> > 
> > 							Pavel
> > 
> > --- linux-z11.rc2bad/arch/arm/mach-sa1100/collie.c	2005-07-19 20:49:07.000000000 +0200
> > +++ linux-z11/arch/arm/mach-sa1100/collie.c	2005-07-19 21:05:54.000000000 +0200
> > @@ -235,7 +235,7 @@
> >  	sa11x0_set_flash_data(&collie_flash_data, collie_flash_resources,
> >  			      ARRAY_SIZE(collie_flash_resources));
> >  
> > -	sharpsl_save_param();
> > +//	sharpsl_save_param();
> >  }
> >  
> >  static struct map_desc collie_io_desc[] __initdata = {
> 
> Could you check this wasn't caused by this typo please:
> 
> http://www.rpsys.net/openzaurus/patches/collie_typofix-r0.patch
> 
> (this has been fixed in recent kernels)

Oops, you are right, it is now fixed. I screwed up some config or
something... It works now.

BTW is there some place where I can find modifications Sharp did to
mainline 2.4 kernel?
								Pavel
-- 
Boycott Kodak -- for their patent abuse against Java.

Re: Sharp Zaurus sl-5500 broken in 2.6.12

[John Lenz]

On Wed, July 20, 2005 12:57 pm, Pavel Machek said:

> BTW is there some place where I can find modifications Sharp did to
> mainline 2.4 kernel?

First, sharp's modifications were not to the base 2.4 kernels, but you
first applied the rmk patch and then the pxa patch.

I have tried to split up the huge patch
http://www.cs.wisc.edu/~lenz/zaurus/files/slc860-patches.tar.bz2

But the original patch is hosted around here somewhere.  To find where,
take a look inside the .bb file inside OE... you should be able to check
out openembedded (from www.openembedded.org) and find the .bb file that
builds the kernel.

John