linuxsh-dev

Re: hp6xx-setup.c.patch

[Paul M. <le...@li...>]

On Thu, Apr 05, 2007 at 02:58:45PM -0700, Kristoffer Ericson wrote:
> Greetings,
> 
> Here's the adjusted patch (used vim to remove all whitetrails I could
> see). Im using gmail now instead and hoping it will work better. Im
> including same patch as an attachment mostly so I can check wether or
> not it has changed when I receive it.
> 
> HP6xx works fine now, I finally found my error.

Applied, with space -> tab fixes.

Re: HZ macro

[Paul M. <le...@li...>]

On Mon, Apr 09, 2007 at 11:02:17AM +0900, Hideo Saito wrote:
> HZ macro used by tmu_timer_init() in arch/sh/kernel/timers/timer-tmu.c is defined by include/asm-sh/param.h as follows.
> 
> # ifdef CONFIG_SH_WDT
> #  define HZ            1000            /* Needed for high-res WOVF */
> # else
> #  define HZ            100
> 
> However, I think HZ should be defined by CONFIG_HZ that is defined by Kconfig.hz.
> 
Yes, that looks reasonable. I suppose we'll have to forcibly select HZ at
1000 in the shwdt case in order to keep things functional. I'll check in
a fix for this, thanks.

Re: Linker (?) problems

[Mike F. <va...@ge...>]

On Monday 09 April 2007, Stuart MENEFY wrote:
> The problem is that you're not getting shell arithmetic expansion. I'm
> guessing that the shell invoked by your make (usually /bin/sh) is not
> bash, or is one of the versions which doesn't support $[ ... ] for
> arithmetic expansion (version 2.0 ?).

$[...] is a bashism ... that should be converted to POSIX $((...))
-mike

Re: Linker (?) problems

[Adrian M. <ad...@ne...>]

On Mon, 2007-04-09 at 22:13 +0100, Stuart MENEFY wrote:
> Adrian
> 
> Adrian McMenamin wrote:
> > This is what I am getting with 2.6.20
> > 
> >   MODPOST vmlinux
> > printf: 1: $[0x80000000: expected numeric value
> > printf: 1: +: expected numeric value
> > printf: 1: +: expected numeric value
> > printf: 1: 0x00001000+0x1000]: not completely converted
> > printf: 1: $[0x80000000: expected numeric value
> > printf: 1: +: expected numeric value
> > printf: 1: +: expected numeric value
> > printf: 1: 0x00800000]: not completely converted
> >   AS      arch/sh/boot/compressed/head.o
> >   CC      arch/sh/boot/compressed/misc.o
> >   OBJCOPY arch/sh/boot/compressed/vmlinux.bin
> >   GZIP    arch/sh/boot/compressed/vmlinux.bin.gz
> >   LD      arch/sh/boot/compressed/piggy.o
> >   LD      arch/sh/boot/compressed/vmlinux
> > /home/adrian/buildroot/build_sh4/staging_dir/bin/sh4-linux-ld: invalid
> > hex number `0x000000000x000000000x0c0000000x000000000x00800000'
> > make[2]: *** [arch/sh/boot/compressed/vmlinux] Error 1
> > make[1]: *** [arch/sh/boot/compressed/vmlinux] Error 2
> > make: *** [zImage] Error 2
> > 
> > I got similar stuff yesterday with 2.6.17 but I assumed this was bit rot
> > in the tools, so I rebuild them.
> > 
> > This is over my head - anyone able to tell me where to start fixing
> > this?
> 
> The problem is that you're not getting shell arithmetic expansion. I'm
> guessing that the shell invoked by your make (usually /bin/sh) is not
> bash, or is one of the versions which doesn't support $[ ... ] for
> arithmetic expansion (version 2.0 ?).


Ubuntu 6.10 has /bin/sh -> dash which causes all sorts of problems, I
have just discovered. So sudo rm /bin/sh; ln -s /bin/sh /bin/bash  and
all is right with the world.

Re: Linker (?) problems

[Stuart M. <stu...@st...>]

Adrian

Adrian McMenamin wrote:
> This is what I am getting with 2.6.20
> 
>   MODPOST vmlinux
> printf: 1: $[0x80000000: expected numeric value
> printf: 1: +: expected numeric value
> printf: 1: +: expected numeric value
> printf: 1: 0x00001000+0x1000]: not completely converted
> printf: 1: $[0x80000000: expected numeric value
> printf: 1: +: expected numeric value
> printf: 1: +: expected numeric value
> printf: 1: 0x00800000]: not completely converted
>   AS      arch/sh/boot/compressed/head.o
>   CC      arch/sh/boot/compressed/misc.o
>   OBJCOPY arch/sh/boot/compressed/vmlinux.bin
>   GZIP    arch/sh/boot/compressed/vmlinux.bin.gz
>   LD      arch/sh/boot/compressed/piggy.o
>   LD      arch/sh/boot/compressed/vmlinux
> /home/adrian/buildroot/build_sh4/staging_dir/bin/sh4-linux-ld: invalid
> hex number `0x000000000x000000000x0c0000000x000000000x00800000'
> make[2]: *** [arch/sh/boot/compressed/vmlinux] Error 1
> make[1]: *** [arch/sh/boot/compressed/vmlinux] Error 2
> make: *** [zImage] Error 2
> 
> I got similar stuff yesterday with 2.6.17 but I assumed this was bit rot
> in the tools, so I rebuild them.
> 
> This is over my head - anyone able to tell me where to start fixing
> this?

The problem is that you're not getting shell arithmetic expansion. I'm
guessing that the shell invoked by your make (usually /bin/sh) is not
bash, or is one of the versions which doesn't support $[ ... ] for
arithmetic expansion (version 2.0 ?).

Try this to see if your shell does support $(( ... )) style expansion:

--- linux.orig/arch/sh/boot/Makefile
+++ linux/arch/sh/boot/Makefile
@@ -23,8 +23,8 @@ CONFIG_MEMORY_START     ?= 0
 CONFIG_ZERO_PAGE_OFFSET ?= 0

 MKIMAGE := $(srctree)/scripts/mkuboot.sh
-ULOADADDR := $(shell printf "0x%8x" $$[0x80000000 + $(CONFIG_MEMORY_START) + $(CONFIG_ZERO_PAGE_OFFSET)])
-UENTRYADDR := $(shell printf "0x%8x" $$[$(ULOADADDR) + 0x1000])
+ULOADADDR := $(shell printf "0x%8x" $$((0x80000000 + $(CONFIG_MEMORY_START) + $(CONFIG_ZERO_PAGE_OFFSET))))
+UENTRYADDR := $(shell printf "0x%8x" $$(($(ULOADADDR) + 0x1000)))

 quiet_cmd_uimage = UIMAGE  $@
       cmd_uimage = $(CONFIG_SHELL) $(MKIMAGE) -A sh -O linux -T kernel \

Linker (?) problems

[Adrian M. <ad...@ne...>]

This is what I am getting with 2.6.20

  MODPOST vmlinux
printf: 1: $[0x80000000: expected numeric value
printf: 1: +: expected numeric value
printf: 1: +: expected numeric value
printf: 1: 0x00001000+0x1000]: not completely converted
printf: 1: $[0x80000000: expected numeric value
printf: 1: +: expected numeric value
printf: 1: +: expected numeric value
printf: 1: 0x00800000]: not completely converted
  AS      arch/sh/boot/compressed/head.o
  CC      arch/sh/boot/compressed/misc.o
  OBJCOPY arch/sh/boot/compressed/vmlinux.bin
  GZIP    arch/sh/boot/compressed/vmlinux.bin.gz
  LD      arch/sh/boot/compressed/piggy.o
  LD      arch/sh/boot/compressed/vmlinux
/home/adrian/buildroot/build_sh4/staging_dir/bin/sh4-linux-ld: invalid
hex number `0x000000000x000000000x0c0000000x000000000x00800000'
make[2]: *** [arch/sh/boot/compressed/vmlinux] Error 1
make[1]: *** [arch/sh/boot/compressed/vmlinux] Error 2
make: *** [zImage] Error 2

I got similar stuff yesterday with 2.6.17 but I assumed this was bit rot
in the tools, so I rebuild them.

This is over my head - anyone able to tell me where to start fixing
this?

Thanks

Adrian

Re: Toolchain

[Adrian M. <ad...@ne...>]

On Mon, 2007-04-09 at 12:28 -0400, Mike Frysinger wrote:
> On Monday 09 April 2007, Adrian McMenamin wrote:
> > Sorry, for the basic question, but I am returning to my attempts to
> > finish my audio driver and all my tools have suffered bit rot. Could
> > someone recommend a gcc/binutils etc combination that will work with
> > build root?
> 
> gcc-3.4.6 / binutils-2.17 should be just peachy ...
> -mike


I can't get the cross gcc to compile on my box :( Not sure why - using
-j3 is great until you have figure out this sort of thing. Could
actually be the linker...

Re: Toolchain

[Mike F. <va...@ge...>]

On Monday 09 April 2007, Adrian McMenamin wrote:
> Sorry, for the basic question, but I am returning to my attempts to
> finish my audio driver and all my tools have suffered bit rot. Could
> someone recommend a gcc/binutils etc combination that will work with
> build root?

gcc-3.4.6 / binutils-2.17 should be just peachy ...
-mike

Toolchain

[Adrian M. <ad...@ne...>]

Sorry, for the basic question, but I am returning to my attempts to
finish my audio driver and all my tools have suffered bit rot. Could
someone recommend a gcc/binutils etc combination that will work with
build root?

Cheers

Adrian

[Task #118443] Big-endian fixes.

[SourceForge.net <no...@so...>]

Task #118443 has been updated. 

Project: LinuxSH
Subproject: 2.6.x TODO
Summary: Big-endian fixes.
Complete: 100%
Status: Closed
Authority  : aothieno
Assigned to: nobody

Description: Big-endian fixes:
- Currently the optimized memcpy() is broken on big-endian for SH-4, not an issue for anyone else.

Follow-Ups:

-------------------------------------------------------
Date: 2007-04-09 14:35
By: iwamatsu

Comment:
This problem has already been solved. 
http://git.kernel.org/?p=linux/kernel/git/lethal/sh-2.6.git;a=commit;h=c7afb7e5cbc4baa781ec82731fc9fe9039efee22

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/pm/task.php?func=detailtask&project_task_id=118443&group_id=2682&group_project_id=44197

HZ macro

[Hideo S. <sa...@de...>]

Hi Paul,

HZ macro used by tmu_timer_init() in arch/sh/kernel/timers/timer-tmu.c is defined by include/asm-sh/param.h as follows.

# ifdef CONFIG_SH_WDT
#  define HZ            1000            /* Needed for high-res WOVF */
# else
#  define HZ            100

However, I think HZ should be defined by CONFIG_HZ that is defined by Kconfig.hz.

--- include/asm-sh/param.h.org	Mon Feb  5 03:44:54 2007
+++ include/asm-sh/param.h	Mon Apr  9 10:45:52 2007
@@ -1,17 +1,13 @@
 #ifndef __ASM_SH_PARAM_H
 #define __ASM_SH_PARAM_H
 
 #ifdef __KERNEL__
-# ifdef CONFIG_SH_WDT
-#  define HZ		1000		/* Needed for high-res WOVF */
-# else
-#  define HZ		100
-# endif
+# define HZ		CONFIG_HZ	/* Internal kernel timer frequency */
 # define USER_HZ	100		/* User interfaces are in "ticks" */
 # define CLOCKS_PER_SEC	(USER_HZ)	/* frequency at which times() counts */
 #endif
 
 #ifndef HZ
 #define HZ 100
 #endif
 

Re: delayed_work issues

[Kristoffer E. <kri...@ho...>]

You are quite correct, got abit lost there. Big thanks for help.


>From: David Howells <dho...@re...>
>CC: "Kristoffer Ericson" <kri...@ho...>,        
>lin...@li...
>Subject: Re: delayed_work issues Date: Wed, 04 Apr 2007 20:42:34 +0100
>
>David Howells <dho...@re...> wrote:
>
> > > This is due to the changes in the workque.h layout.
> > > I've tried to declare a struct delayed_work *ts_delay and used
> > > &ts_delay->work instead of &work. But getting same error.
> >
> > Looking at the vanilla code:
> >
> > 	static DECLARE_WORK(work, do_softint, 0);
> >
> > should be:
> >
> > 	static DECLARE_DELAYED_WORK(work, do_softint, 0);
>
>Actually, no it shouldn't.  It should be:
>
>	static DECLARE_DELAYED_WORK(work, do_softint);
>
>And the do_softint function should be:
>
>	static void do_softint(struct work_struct *work)
>
>David

_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today it's FREE! 
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

Re: delayed_work issues

[David H. <dho...@re...>]

David Howells <dho...@re...> wrote:

> > This is due to the changes in the workque.h layout.
> > I've tried to declare a struct delayed_work *ts_delay and used 
> > &ts_delay->work instead of &work. But getting same error.
> 
> Looking at the vanilla code:
> 
> 	static DECLARE_WORK(work, do_softint, 0);
> 
> should be:
> 
> 	static DECLARE_DELAYED_WORK(work, do_softint, 0);

Actually, no it shouldn't.  It should be:

	static DECLARE_DELAYED_WORK(work, do_softint);

And the do_softint function should be:

	static void do_softint(struct work_struct *work)

David

Re: delayed_work issues

[David H. <dho...@re...>]

Kristoffer Ericson <kri...@ho...> wrote:

> This is due to the changes in the workque.h layout.
> I've tried to declare a struct delayed_work *ts_delay and used 
> &ts_delay->work instead of &work. But getting same error.

Looking at the vanilla code:

	static DECLARE_WORK(work, do_softint, 0);

should be:

	static DECLARE_DELAYED_WORK(work, do_softint, 0);

David

delayed_work issues

[Kristoffer E. <kri...@ho...>]

This is due to the changes in the workque.h layout.
I've tried to declare a struct delayed_work *ts_delay and used 
&ts_delay->work instead of &work. But getting same error.


Bootlog:
------------
Linux version 2.6.21-rc5-g57fff9e7-dirty (root@Wolverine) (gcc version 
3.4.5) #1
2 Wed Apr 4 15:50:55 PDT 2007
Built 1 zonelists.  Total pages: 8128
Kernel command line: mem=32M root=/dev/hda2 console=ttySC1,115200 
init=/bin/sh
PID hash table entries: 128 (order: 7, 512 bytes)
Interval = 55275
Using tmu for system timer
Console: colour dummy device 80x25
Dentry cache hash table entries: 4096 (order: 2, 16384 bytes)
Inode-cache hash table entries: 2048 (order: 1, 8192 bytes)
Memory: 29968k/32768k available (2256k kernel code, 2800k reserved, 94k 
data, 60
k init)
Mount-cache hash table entries: 512
CPU: SH7729
NET: Registered protocol family 16
SCSI subsystem initialized
DMA: Registering DMA API.
DMA: Registering sh_dmac handler (4 channels).
NET: Registered protocol family 2
IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
TCP established hash table entries: 1024 (order: 1, 8192 bytes)
TCP bind hash table entries: 1024 (order: 0, 4096 bytes)
TCP: Hash tables configured (established 1024 bind 1024)
TCP reno registered
HD64461 configured at 0xb0000000 on irq 36(mapped into 80 to 95)
io scheduler noop registered
io scheduler deadline registered
io scheduler cfq registered (default)
Console: switching to colour frame buffer device 80x30
fb0: Hitachi HD64461 frame buffer device
SuperH SCI(F) driver initialized
sh-sci: ttySC0 at MMIO 0xfffffe80 (irq = 25) is a sci
sh-sci: ttySC1 at MMIO 0xa4000150 (irq = 59) is a scif
loop: loaded (max 8 devices)
SCSI Media Changer driver v0.25
ata1: PATA max PIO0 cmd 0xb50001f0 ctl 0xb50001fe bmdma 0x00000000 irq 93
scsi0 : pata_platform
mice: PS/2 mouse device common for all mice
Kernel BUG: 003e [#1]
Modules linked in:

Pid : 1, Comm:              swapper
PC is at queue_delayed_work+0xe0/0x120
PC  : 8d0210c0 SP  : 8d2d5e38 SR  : 400001f0 TEA : 0001194c    Not tainted
R0  : 00000001 R1  : 00000001 R2  : 000000f0 R3  : ffffffff
R4  : 8d2459b8 R5  : 8d2459a8 R6  : 00000005 R7  : 8d2be760
R8  : 00000000 R9  : 00000000 R10
R12 : 00000000 R13 : 00000000 R14 : 00000000
MACH: 00000000 MACL: 00000000 GBR : 00000000 PR  : 8d144680

Call trace:
[<8d144680>] hp680_ts_interrupt+0x10/0x30
[<8d0314a0>] handle_IRQ_event+0x40/0x90
[<8d03278a>] handle_level_irq+0x5a/0x100
[<8d005358>] do_IRQ+0x38/0x90
[<8d007118>] ret_from_exception+0x0/0x14
[<8d005320>] do_IRQ+0x0/0x90
[<8d0319b6>] setup_irq+0xb6/0x210
[<8d031a90>] setup_irq+0x190/0x210
[<8d031cc4>] request_irq+0x74/0xb0
[<8d21e924>] __func__.0+0x4d008/0x51fd1
[<8d144670>] hp680_ts_interrupt+0x
[<8d144670>] hp680_ts_interrupt+0x
[<8d250a04>] init+0x64/0x1e0
[<8d003004>] kernel_thread_helper+0x4/0x10
[<8d2509a0>] init+0x0/0x1e0
[<8d003000>] kernel_thread_helper+0x0/0x10

Process: swapper (pid: 1, stack limit = 8d2d4001)
Stack: (0x8d2d5e38 to 0x8d2d6000)
5e20:                                                       8d144680 
8d3b0700
5e40: 8d0314a0 8d03278a 00000023 00000000 00000023 8d24b8f0 8d005358 
8d26942c
5e60: 00000033 8d007118 00000000 8d005320 ffffffff 00000000 00000000 
40000100
5e80: 00000000 000008c0 8d3b0700 00000020 a4000016 8d24b8f0 8d3b0700 
00000000
5ea0: 00000023 00000000 00000000 00000000 8d2d5ed8 8d0319b6 8d031a90 
40000100
5ec0: 00000000 00000000 00000000 ffffffff ffffffff 00000000 8d031cc4 
8d21e924
5ee0: 8d144670 00000020 00000023 8d3b0700 8d25a3fa 8d25e534 00000000 
8d25c904
5f00: 00000000 8d26e84c 00000310 00000000 8d250a04 00000000 8d25e4e4 
8d2d4000
5f20: b72d94e9 96c0cddb 95bbd2d9 b8a1b7c2 aa549930 4ef3051e eff57903 
1962fe08
5f40: 2b65127e 6044b9f3 00000001 8d003004 00000000 00000000 00000000 
00000000
5f60: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 
8d2509a0
5f80: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 
00000000
5fa0: 00000000 8d2d5f68 8d003000 00000000 40000000 00000000 00000000 
00000000
5fc0: 00000000 6033a383 3eacbffc 2be627df 98ed1a61 9f5e226d 24d82176 
67aa977c
5fe0: 348e7859 997f1c93 7acaef95 d3d52f3c 6b60fe91 48bd67f7 939dbca6 
dc27e45e
Kernel panic - not syncing: Aiee, killing interrupt handler!

_________________________________________________________________
FREE pop-up blocking with the new MSN Toolbar - get it now! 
http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/

Pata / hd64461.h adresses /mmio generic

[Kristoffer E. <kri...@ho...>]

Im still unable to get Pata support going. From what I can tell the ipr_map 
seems fine and so does all the setup code for hp6xx and h64461.

The generic MMIO needs to be changed in order for it to work for hp6xx, I 
received a patch from andriy before when we had issues with pcmcia wifi.

The adresses inside h64461.h though must be wrong atleast partly.
Examples:
+/* PC Card Controller Registers */
+#define HD64461_PCC0ISR         0x12000 /* socket 0 interface status */
+#define HD64461_PCC0GCR         0x12002 /* socket 0 general control */
+#define HD64461_PCC0CSCR        0x12004 /* socket 0 card status change */
+#define HD64461_PCC0CSCIER      0x12006 /* socket 0 card status change 
interrupt enable */
+#define HD64461_PCC0SCR         0x12008 /* socket 0 software control */

Needs to be changed to CONFIG_HD64461_IOBASE + port - 0x10000 to work. 
Otherwise no output is given on screen.

#define HD64461_STBCR   0x10000

Would result in STBCR = CONFIG_HD64461_IOBASE if port2addr were resolving 
that adress. It works if I change that value, but not otherwise.

So I know paul stated before that hd64461.h should be left untouched, but Im 
unable to get it working if I don't change some values. And the hard part is 
knowing what was touched by port2addr and what wasn't.

Im considering going back to using the hd64461_mv specific and only using 
mmio for pata, as Im making no progress.

Best wishes
Kristoffer

_________________________________________________________________
FREE pop-up blocking with the new MSN Toolbar - get it now! 
http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/

Re: Setup-sh7709.c

[Kristoffer E. <kri...@ho...>]

Greetings,

Its hard to tell wether the patch is working or not, since Pata doesnt work 
for hp6xx yet. But if it works for you then it should be fine.

Best wishes
Kristoffer Ericson

>From: tak...@op...
>To: "Kristoffer Ericson" <kri...@ho...>
>CC: lin...@li...
>Subject: Re: Setup-sh7709.c
>Date: Wed, 28 Mar 2007 02:46:25 +0900
>
>Hi, Kristoffer, and lists,
># This is not a patch commit.
>
>There is a issue whether external interrupts should be initialized in CPU 
>setup code, or not.
>I initialize them in board setup code (boards/shmin/setup.c) now.
>I don't know the answer, perhaps CPU do definition, and board should do all 
>of initialization, or
>ipr initialization and priority setting should be separated, or this is pin 
>mux issue, or ... I don't know.
>So, forget it now, please :) Here is another topic.
>
> > +	[33]            = { IPRC(1),     1 }, /* IRQ 1 */
> > ...
>Perhaps, what you want is like a patch at the end.
>Argument of IPR* macro is like "11-8".
>It's not a number, nor a mathematical notation(like 15-8=7), because of 
>"0*N*-1" in IPRx macro
>definition. I'm  sorry to have commited such a dain bramaged macros.
>
>I explain on this occasion.
>This was a kind of objection against the comment in asm-sh/irq.h. It says
>| * The shift value is now the number of bits to shift, not the number of
>| * bits/4. This is to make it easier to read the value directly from the
>| * datasheets. <snip>
>I don't think (12,8,4,0) is easier than (3,2,1,0). And what you read direct 
>from the
>datasheet is (15-12,11-8,7-4,3-0). Hence the weired math.
>But, this is ugry, sorry. I will fix the macro to (12,8,4,0) style. It 
>seems this is the majority.
>
>More important is later part.
>| <snip> The IPR address, addr, will be set from ipr_idx via the
>| * map_ipridx_to_addr function.
>I don't agree this method. Symbol reference back from core part is not 
>good.
>I don't understand what this is intended to.  If it is to abstract 
>hardware, it's not enough.
>
>IRQx macro provids the way to setup IPRs without map_ipridx_to_addr().
>I think .address  and .shift is a set, and is the hardware description.
>The macro packs them, at least for the eyes. The real one should come 
>later, perhaps when
>we introduce IRQ number abstraction.
>That's why I end whth this implementation.
>
>So, could you please test this patch on your target ? > Kristoffer.
>Here on my board(shmin/7706), it seems no problem, so far.
>
>Best regards,
>/yoshii
>
>diff --git a/arch/sh/kernel/cpu/sh3/setup-sh7709.c 
>b/arch/sh/kernel/cpu/sh3/setup-sh7709.c
>index dc9b211..47c7cf6 100644
>--- a/arch/sh/kernel/cpu/sh3/setup-sh7709.c
>+++ b/arch/sh/kernel/cpu/sh3/setup-sh7709.c
>@@ -52,20 +52,30 @@ static int __init sh7709_devices_setup(v
>  }
>  __initcall(sh7709_devices_setup);
>
>-#define IPRx(A,N) .addr=A, .shift=0*N*-1
>+#define IPRx(A,N)	.addr=A, .shift=N
>  #define IPRA(N)	IPRx(0xfffffee2UL,N)
>  #define IPRB(N)	IPRx(0xfffffee4UL,N)
>+#define IPRC(N)	IPRx(0xa4000016UL,N)
>+#define IPRD(N)	IPRx(0xa4000018UL,N)
>  #define IPRE(N)	IPRx(0xa400001aUL,N)
>
>  static struct ipr_data sh7709_ipr_map[] = {
>-	[16]		= { IPRA(15-12), 2 }, /* TMU TUNI0 */
>-	[17]		= { IPRA(11-8),  4 }, /* TMU TUNI1 */
>-	[22]		= { IPRA(3-0),   2 }, /* RTC CUI */
>-	[23 ... 26]	= { IPRB(7-4),   3 }, /* SCI */
>-	[27]		= { IPRB(15-12), 2 }, /* WDT ITI */
>-	[48 ... 51]	= { IPRE(15-12), 7 }, /* DMA */
>-	[52 ... 55]	= { IPRE(11-8),  3 }, /* IRDA */
>-	[56 ... 59]	= { IPRE(7-4),   3 }, /* SCIF */
>+	[16]		= { IPRA(12), 2 }, /* TMU TUNI0 */
>+	[17]		= { IPRA( 8), 4 }, /* TMU TUNI1 */
>+	[18 ... 19]	= { IPRA( 4), 1 }, /* TMU2 */
>+	[20 ... 22]	= { IPRA( 0), 2 }, /* RTC */
>+	[23 ... 26]	= { IPRB( 4), 3 }, /* SCI */
>+	[27]		= { IPRB(12), 2 }, /* WDT ITI */
>+	[28 ... 29]	= { IPRB( 8), 1 }, /* REF */
>+	[32]		= { IPRC( 0), 1 }, /* IRQ0 */
>+	[33]		= { IPRC( 4), 1 }, /* IRQ1 */
>+	[34]		= { IPRC( 8), 1 }, /* IRQ2 */
>+	[35]		= { IPRC(12), 1 }, /* IRQ3 */
>+	[36]		= { IPRD( 0), 1 }, /* IRQ4 */
>+	[37]		= { IPRD( 4), 1 }, /* IRQ5 */
>+	[48 ... 51]	= { IPRE(12), 7 }, /* DMA */
>+	[52 ... 55]	= { IPRE( 8), 3 }, /* IRDA */
>+	[56 ... 59]	= { IPRE( 4), 3 }, /* SCIF */
>  };
>
>  void __init init_IRQ_ipr()

_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today it's FREE! 
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

Re: [PATCH] fix fstatat64

[Paul M. <le...@li...>]

On Thu, Mar 29, 2007 at 10:54:07AM +0900, SUGIOKA Toshinobu wrote:
> fstatat64 system call does not work now.
> Following patch fixes this problem.
> (This patch makes include/asm-sh/stat.h almost identical to
>  include/asm-i386/stat.h)
> 
> Signed-off-by: SUGIOKA Toshinobu <su...@it...>
> 
Applied, thanks.

[PATCH] fix fstatat64

[SUGIOKA T. <su...@it...>]

Hi.

fstatat64 system call does not work now.
Following patch fixes this problem.
(This patch makes include/asm-sh/stat.h almost identical to
 include/asm-i386/stat.h)

Signed-off-by: SUGIOKA Toshinobu <su...@it...>

diff --git a/include/asm-sh/stat.h b/include/asm-sh/stat.h
index 6c41a60..6d6ad26 100644
--- a/include/asm-sh/stat.h
+++ b/include/asm-sh/stat.h
@@ -16,15 +16,13 @@ struct __old_kernel_stat {
 };
 
 struct stat {
-	unsigned short st_dev;
-	unsigned short __pad1;
-	unsigned long st_ino;
+	unsigned long  st_dev;
+	unsigned long  st_ino;
 	unsigned short st_mode;
 	unsigned short st_nlink;
 	unsigned short st_uid;
 	unsigned short st_gid;
-	unsigned short st_rdev;
-	unsigned short __pad2;
+	unsigned long  st_rdev;
 	unsigned long  st_size;
 	unsigned long  st_blksize;
 	unsigned long  st_blocks;
@@ -38,8 +36,6 @@ struct stat {
 	unsigned long  __unused5;
 };
 
-#define STAT_HAVE_NSEC 1
-
 /* This matches struct stat64 in glibc2.1, hence the absolutely
  * insane amounts of padding around dev_t's.
  */
@@ -47,7 +43,9 @@ struct stat64 {
 	unsigned long long	st_dev;
 	unsigned char	__pad0[4];
 
-	unsigned long	st_ino;
+#define STAT64_HAS_BROKEN_ST_INO	1
+	unsigned long	__st_ino;
+
 	unsigned int	st_mode;
 	unsigned int	st_nlink;
 
@@ -71,8 +69,9 @@ struct stat64 {
 	unsigned long	st_ctime;
 	unsigned long	st_ctime_nsec; 
 
-	unsigned long	__unused1;
-	unsigned long	__unused2;
+	unsigned long long	st_ino;
 };
 
+#define STAT_HAVE_NSEC 1
+
 #endif /* __ASM_SH_STAT_H */

SUGIOKA Toshinobu

Re: Setup-sh7709.c

[Kristoffer E. <kri...@ho...>]

I'll be glad to try it out once I get back to uni on monday. Big thanks at 
cleaning up it abit, had a few braincell losses figuring it out. :)

Best wishes
Kristoffer


>From: tak...@op...
>To: "Kristoffer Ericson" <kri...@ho...>
>CC: lin...@li...
>Subject: Re: Setup-sh7709.c
>Date: Wed, 28 Mar 2007 02:46:25 +0900
>
>Hi, Kristoffer, and lists,
># This is not a patch commit.
>
>There is a issue whether external interrupts should be initialized in CPU 
>setup code, or not.
>I initialize them in board setup code (boards/shmin/setup.c) now.
>I don't know the answer, perhaps CPU do definition, and board should do all 
>of initialization, or
>ipr initialization and priority setting should be separated, or this is pin 
>mux issue, or ... I don't know.
>So, forget it now, please :) Here is another topic.
>
> > +	[33]            = { IPRC(1),     1 }, /* IRQ 1 */
> > ...
>Perhaps, what you want is like a patch at the end.
>Argument of IPR* macro is like "11-8".
>It's not a number, nor a mathematical notation(like 15-8=7), because of 
>"0*N*-1" in IPRx macro
>definition. I'm  sorry to have commited such a dain bramaged macros.
>
>I explain on this occasion.
>This was a kind of objection against the comment in asm-sh/irq.h. It says
>| * The shift value is now the number of bits to shift, not the number of
>| * bits/4. This is to make it easier to read the value directly from the
>| * datasheets. <snip>
>I don't think (12,8,4,0) is easier than (3,2,1,0). And what you read direct 
>from the
>datasheet is (15-12,11-8,7-4,3-0). Hence the weired math.
>But, this is ugry, sorry. I will fix the macro to (12,8,4,0) style. It 
>seems this is the majority.
>
>More important is later part.
>| <snip> The IPR address, addr, will be set from ipr_idx via the
>| * map_ipridx_to_addr function.
>I don't agree this method. Symbol reference back from core part is not 
>good.
>I don't understand what this is intended to.  If it is to abstract 
>hardware, it's not enough.
>
>IRQx macro provids the way to setup IPRs without map_ipridx_to_addr().
>I think .address  and .shift is a set, and is the hardware description.
>The macro packs them, at least for the eyes. The real one should come 
>later, perhaps when
>we introduce IRQ number abstraction.
>That's why I end whth this implementation.
>
>So, could you please test this patch on your target ? > Kristoffer.
>Here on my board(shmin/7706), it seems no problem, so far.
>
>Best regards,
>/yoshii
>
>diff --git a/arch/sh/kernel/cpu/sh3/setup-sh7709.c 
>b/arch/sh/kernel/cpu/sh3/setup-sh7709.c
>index dc9b211..47c7cf6 100644
>--- a/arch/sh/kernel/cpu/sh3/setup-sh7709.c
>+++ b/arch/sh/kernel/cpu/sh3/setup-sh7709.c
>@@ -52,20 +52,30 @@ static int __init sh7709_devices_setup(v
>  }
>  __initcall(sh7709_devices_setup);
>
>-#define IPRx(A,N) .addr=A, .shift=0*N*-1
>+#define IPRx(A,N)	.addr=A, .shift=N
>  #define IPRA(N)	IPRx(0xfffffee2UL,N)
>  #define IPRB(N)	IPRx(0xfffffee4UL,N)
>+#define IPRC(N)	IPRx(0xa4000016UL,N)
>+#define IPRD(N)	IPRx(0xa4000018UL,N)
>  #define IPRE(N)	IPRx(0xa400001aUL,N)
>
>  static struct ipr_data sh7709_ipr_map[] = {
>-	[16]		= { IPRA(15-12), 2 }, /* TMU TUNI0 */
>-	[17]		= { IPRA(11-8),  4 }, /* TMU TUNI1 */
>-	[22]		= { IPRA(3-0),   2 }, /* RTC CUI */
>-	[23 ... 26]	= { IPRB(7-4),   3 }, /* SCI */
>-	[27]		= { IPRB(15-12), 2 }, /* WDT ITI */
>-	[48 ... 51]	= { IPRE(15-12), 7 }, /* DMA */
>-	[52 ... 55]	= { IPRE(11-8),  3 }, /* IRDA */
>-	[56 ... 59]	= { IPRE(7-4),   3 }, /* SCIF */
>+	[16]		= { IPRA(12), 2 }, /* TMU TUNI0 */
>+	[17]		= { IPRA( 8), 4 }, /* TMU TUNI1 */
>+	[18 ... 19]	= { IPRA( 4), 1 }, /* TMU2 */
>+	[20 ... 22]	= { IPRA( 0), 2 }, /* RTC */
>+	[23 ... 26]	= { IPRB( 4), 3 }, /* SCI */
>+	[27]		= { IPRB(12), 2 }, /* WDT ITI */
>+	[28 ... 29]	= { IPRB( 8), 1 }, /* REF */
>+	[32]		= { IPRC( 0), 1 }, /* IRQ0 */
>+	[33]		= { IPRC( 4), 1 }, /* IRQ1 */
>+	[34]		= { IPRC( 8), 1 }, /* IRQ2 */
>+	[35]		= { IPRC(12), 1 }, /* IRQ3 */
>+	[36]		= { IPRD( 0), 1 }, /* IRQ4 */
>+	[37]		= { IPRD( 4), 1 }, /* IRQ5 */
>+	[48 ... 51]	= { IPRE(12), 7 }, /* DMA */
>+	[52 ... 55]	= { IPRE( 8), 3 }, /* IRDA */
>+	[56 ... 59]	= { IPRE( 4), 3 }, /* SCIF */
>  };
>
>  void __init init_IRQ_ipr()

_________________________________________________________________
FREE pop-up blocking with the new MSN Toolbar - get it now! 
http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/

Re: GCC-4 problems

[Paul M. <le...@li...>]

On Wed, Mar 28, 2007 at 09:28:17AM +0200, Manuel Lauss wrote:
> On Wed, Mar 28, 2007 at 03:45:07PM +0900, Paul Mundt wrote:
> > diff --git a/include/asm-sh/system.h b/include/asm-sh/system.h
> > index b1e42e7..4a6a19f 100644
> > --- a/include/asm-sh/system.h
> > +++ b/include/asm-sh/system.h
> > @@ -7,6 +7,7 @@
> >   */
> >  
> >  #include <linux/irqflags.h>
> > +#include <linux/compiler.h>
> >  #include <asm/types.h>
> >  
> >  /*
> 
> 
> Yes it is fixed, thank you!
> 
GCC4 inlining strikes again.. :-)

Re: GCC-4 problems

[Manuel L. <ma...@ro...>]

On Wed, Mar 28, 2007 at 03:45:07PM +0900, Paul Mundt wrote:
> On Mon, Mar 19, 2007 at 09:27:57AM +0100, Manuel Lauss wrote:
> > Hello,
> > 
> > When I build linux with GCC-4.x and enable CONFIG_CC_OPTIMIZE_FOR_SIZE
> > linking fails with this error:
> > 
> >   LD      .tmp_vmlinux1
> > kernel/built-in.o: In function '__cmpxchg_called_with_bad_pointer'
> > make[1]: *** [.tmp_vmlinux1] Error 1
> > make: *** [_all] Error 2
> > 
> This fixed it for me, can you verify?
> 
> diff --git a/include/asm-sh/system.h b/include/asm-sh/system.h
> index b1e42e7..4a6a19f 100644
> --- a/include/asm-sh/system.h
> +++ b/include/asm-sh/system.h
> @@ -7,6 +7,7 @@
>   */
>  
>  #include <linux/irqflags.h>
> +#include <linux/compiler.h>
>  #include <asm/types.h>
>  
>  /*


Yes it is fixed, thank you!

-- 
 ml.

Re: GCC-4 problems

[Paul M. <le...@li...>]

On Mon, Mar 19, 2007 at 09:27:57AM +0100, Manuel Lauss wrote:
> Hello,
> 
> When I build linux with GCC-4.x and enable CONFIG_CC_OPTIMIZE_FOR_SIZE
> linking fails with this error:
> 
>   LD      .tmp_vmlinux1
> kernel/built-in.o: In function '__cmpxchg_called_with_bad_pointer'
> make[1]: *** [.tmp_vmlinux1] Error 1
> make: *** [_all] Error 2
> 
This fixed it for me, can you verify?

diff --git a/include/asm-sh/system.h b/include/asm-sh/system.h
index b1e42e7..4a6a19f 100644
--- a/include/asm-sh/system.h
+++ b/include/asm-sh/system.h
@@ -7,6 +7,7 @@
  */
 
 #include <linux/irqflags.h>
+#include <linux/compiler.h>
 #include <asm/types.h>
 
 /*

Re: Setup-sh7709.c

[Paul M. <le...@li...>]

On Wed, Mar 28, 2007 at 02:46:25AM +0900, tak...@op... wrote:
> There is a issue whether external interrupts should be initialized in CPU setup code, or not.
> I initialize them in board setup code (boards/shmin/setup.c) now.
> I don't know the answer, perhaps CPU do definition, and board should do all of initialization, or 
> ipr initialization and priority setting should be separated, or this is pin mux issue, or ... I don't know.
> So, forget it now, please :) Here is another topic.
> 
Agreed, this does need to be overhauled. For the IPR scheme, perhaps your
macro solution is really the most sensible way to go. There's not much in
the way of meaningful mapping we can accomplish with the
map_ipridx_to_addr() approach, so there's not a lot of point in keeping
it around.

INTC2 is going to need something similar as well, since the new-style
INTC2s place their mask/clear registers at completely different locations
depending on the IRQ offset. Irritating, but not a lot we can do about
it, it's just going to have to be something that's swalled up by the
mapping code. SH7785 INTC2 has this problem, for example.

I would rather not have this stuff visible in the board-level
configuration, at least. Boards should only care about their special IRQ
controllers, and whether they need to kick a parent IRQ in to a certain
mode for cascade or not.

Re: Setup-sh7709.c

[<tak...@op...>]

Hi, Kristoffer, and lists,
# This is not a patch commit.

There is a issue whether external interrupts should be initialized in CPU setup code, or not.
I initialize them in board setup code (boards/shmin/setup.c) now.
I don't know the answer, perhaps CPU do definition, and board should do all of initialization, or 
ipr initialization and priority setting should be separated, or this is pin mux issue, or ... I don't know.
So, forget it now, please :) Here is another topic.

> +	[33]            = { IPRC(1),     1 }, /* IRQ 1 */
> ...
Perhaps, what you want is like a patch at the end.
Argument of IPR* macro is like "11-8".
It's not a number, nor a mathematical notation(like 15-8=7), because of "0*N*-1" in IPRx macro
definition. I'm  sorry to have commited such a dain bramaged macros.

I explain on this occasion.
This was a kind of objection against the comment in asm-sh/irq.h. It says
| * The shift value is now the number of bits to shift, not the number of
| * bits/4. This is to make it easier to read the value directly from the
| * datasheets. <snip>
I don't think (12,8,4,0) is easier than (3,2,1,0). And what you read direct from the
datasheet is (15-12,11-8,7-4,3-0). Hence the weired math.
But, this is ugry, sorry. I will fix the macro to (12,8,4,0) style. It seems this is the majority.

More important is later part.
| <snip> The IPR address, addr, will be set from ipr_idx via the
| * map_ipridx_to_addr function.
I don't agree this method. Symbol reference back from core part is not good.
I don't understand what this is intended to.  If it is to abstract hardware, it's not enough.

IRQx macro provids the way to setup IPRs without map_ipridx_to_addr().
I think .address  and .shift is a set, and is the hardware description.
The macro packs them, at least for the eyes. The real one should come later, perhaps when
we introduce IRQ number abstraction.
That's why I end whth this implementation.

So, could you please test this patch on your target ? > Kristoffer.
Here on my board(shmin/7706), it seems no problem, so far.

Best regards,
/yoshii

diff --git a/arch/sh/kernel/cpu/sh3/setup-sh7709.c b/arch/sh/kernel/cpu/sh3/setup-sh7709.c
index dc9b211..47c7cf6 100644
--- a/arch/sh/kernel/cpu/sh3/setup-sh7709.c
+++ b/arch/sh/kernel/cpu/sh3/setup-sh7709.c
@@ -52,20 +52,30 @@ static int __init sh7709_devices_setup(v
 }
 __initcall(sh7709_devices_setup);
 
-#define IPRx(A,N) .addr=A, .shift=0*N*-1
+#define IPRx(A,N)	.addr=A, .shift=N
 #define IPRA(N)	IPRx(0xfffffee2UL,N)
 #define IPRB(N)	IPRx(0xfffffee4UL,N)
+#define IPRC(N)	IPRx(0xa4000016UL,N)
+#define IPRD(N)	IPRx(0xa4000018UL,N)
 #define IPRE(N)	IPRx(0xa400001aUL,N)
 
 static struct ipr_data sh7709_ipr_map[] = {
-	[16]		= { IPRA(15-12), 2 }, /* TMU TUNI0 */
-	[17]		= { IPRA(11-8),  4 }, /* TMU TUNI1 */
-	[22]		= { IPRA(3-0),   2 }, /* RTC CUI */
-	[23 ... 26]	= { IPRB(7-4),   3 }, /* SCI */
-	[27]		= { IPRB(15-12), 2 }, /* WDT ITI */
-	[48 ... 51]	= { IPRE(15-12), 7 }, /* DMA */
-	[52 ... 55]	= { IPRE(11-8),  3 }, /* IRDA */
-	[56 ... 59]	= { IPRE(7-4),   3 }, /* SCIF */
+	[16]		= { IPRA(12), 2 }, /* TMU TUNI0 */
+	[17]		= { IPRA( 8), 4 }, /* TMU TUNI1 */
+	[18 ... 19]	= { IPRA( 4), 1 }, /* TMU2 */
+	[20 ... 22]	= { IPRA( 0), 2 }, /* RTC */
+	[23 ... 26]	= { IPRB( 4), 3 }, /* SCI */
+	[27]		= { IPRB(12), 2 }, /* WDT ITI */
+	[28 ... 29]	= { IPRB( 8), 1 }, /* REF */
+	[32]		= { IPRC( 0), 1 }, /* IRQ0 */
+	[33]		= { IPRC( 4), 1 }, /* IRQ1 */
+	[34]		= { IPRC( 8), 1 }, /* IRQ2 */
+	[35]		= { IPRC(12), 1 }, /* IRQ3 */
+	[36]		= { IPRD( 0), 1 }, /* IRQ4 */
+	[37]		= { IPRD( 4), 1 }, /* IRQ5 */
+	[48 ... 51]	= { IPRE(12), 7 }, /* DMA */
+	[52 ... 55]	= { IPRE( 8), 3 }, /* IRDA */
+	[56 ... 59]	= { IPRE( 4), 3 }, /* SCIF */
 };
 
 void __init init_IRQ_ipr()