On Sat, Jul 26, 2008 at 03:18:08PM +0100, Russell King - ARM Linux wrote:
> On Fri, Jul 25, 2008 at 01:48:18AM -0700, [email protected] wrote:
> > From: Akinobu Mita <[email protected]>
> >
> > Signed-off-by: Akinobu Mita <[email protected]>
> > Cc: Russell King <[email protected]>
> > Cc: Tim Schmielau <[email protected]>
> > Signed-off-by: Andrew Morton <[email protected]>
>
> Argh... Are people now submitting untested patches as a rule?
>
> drivers/char/nwflash.c: In function 'flash_read':
> drivers/char/nwflash.c:129: error: 'p' undeclared (first use in this function)
> drivers/char/nwflash.c:129: error: (Each undeclared identifier is reported only once
> drivers/char/nwflash.c:129: error: for each function it appears in.)
> drivers/char/nwflash.c:129: error: 'count' undeclared (first use in this function)
> drivers/char/nwflash.c:136: warning: passing argument 4 of 'simple_read_from_buffer' discards qualifiers from pointer target type
> make[2]: *** [drivers/char/nwflash.o] Error 1
> make[1]: *** [drivers/char] Error 2
> make: *** [drivers] Error 2
Sorry. I'm preparing cross compiler. But this patch should fix this
problem.
From: Akinobu Mita <[email protected]>
Subject: nwflash: fix build errors and warning
The commit 6ee8928d94841aa764aeaf645ad16daff811dc26
(nwflash: use simple_read_from_buffer()) broke nwflash.
drivers/char/nwflash.c: In function 'flash_read':
drivers/char/nwflash.c:129: error: 'p' undeclared (first use in this function)
drivers/char/nwflash.c:129: error: (Each undeclared identifier is reported only once
drivers/char/nwflash.c:129: error: for each function it appears in.)
drivers/char/nwflash.c:129: error: 'count' undeclared (first use in this function)
drivers/char/nwflash.c:136: warning: passing argument 4 of 'simple_read_from_buffer' discards qualifiers from pointer target type
make[2]: *** [drivers/char/nwflash.o] Error 1
make[1]: *** [drivers/char] Error 2
make: *** [drivers] Error 2
Signed-off-by: Akinobu Mita <[email protected]>
---
drivers/char/nwflash.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
Index: 2.6-mm/drivers/char/nwflash.c
===================================================================
--- 2.6-mm.orig/drivers/char/nwflash.c
+++ 2.6-mm/drivers/char/nwflash.c
@@ -126,14 +126,15 @@ static ssize_t flash_read(struct file *f
if (flashdebug)
printk(KERN_DEBUG "flash_read: flash_read: offset=0x%lX, "
- "buffer=%p, count=0x%X.\n", p, buf, count);
+ "buffer=%p, count=0x%zX.\n", *ppos, buf, size);
/*
* We now lock against reads and writes. --rmk
*/
if (mutex_lock_interruptible(&nwflash_mutex))
return -ERESTARTSYS;
- ret = simple_read_from_buffer(buf, size, ppos, FLASH_BASE, gbFlashSize);
+ ret = simple_read_from_buffer(buf, size, ppos, (void *)FLASH_BASE,
+ gbFlashSize);
mutex_unlock(&nwflash_mutex);
return ret;
On Sun, Jul 27, 2008 at 12:02:20AM +0900, Akinobu Mita wrote:
> On Sat, Jul 26, 2008 at 03:18:08PM +0100, Russell King - ARM Linux wrote:
> > On Fri, Jul 25, 2008 at 01:48:18AM -0700, [email protected] wrote:
> > > From: Akinobu Mita <[email protected]>
> > >
> > > Signed-off-by: Akinobu Mita <[email protected]>
> > > Cc: Russell King <[email protected]>
> > > Cc: Tim Schmielau <[email protected]>
> > > Signed-off-by: Andrew Morton <[email protected]>
> >
> > Argh... Are people now submitting untested patches as a rule?
> >
> > drivers/char/nwflash.c: In function 'flash_read':
> > drivers/char/nwflash.c:129: error: 'p' undeclared (first use in this function)
> > drivers/char/nwflash.c:129: error: (Each undeclared identifier is reported only once
> > drivers/char/nwflash.c:129: error: for each function it appears in.)
> > drivers/char/nwflash.c:129: error: 'count' undeclared (first use in this function)
> > drivers/char/nwflash.c:136: warning: passing argument 4 of 'simple_read_from_buffer' discards qualifiers from pointer target type
> > make[2]: *** [drivers/char/nwflash.o] Error 1
> > make[1]: *** [drivers/char] Error 2
> > make: *** [drivers] Error 2
>
> Sorry. I'm preparing cross compiler. But this patch should fix this
> problem.
I sort of did the same - but merely changing the names of the variables
generates other warnings. More complete (and build-tested) commit
queued up:
http://ftp.arm.linux.org.uk/git/gitweb.cgi?p=linux-2.6-arm.git;a=commitdiff;h=4ef584ba84125b67c17b5aded38e7783cd8cdef0
>> Sorry. I'm preparing cross compiler. But this patch should fix this
>> problem.
>
> I sort of did the same - but merely changing the names of the variables
> generates other warnings. More complete (and build-tested) commit
> queued up:
>
> http://ftp.arm.linux.org.uk/git/gitweb.cgi?p=linux-2.6-arm.git;a=commitdiff;h=4ef584ba84125b67c17b5aded38e7783cd8cdef0
>
Ah, thanks for fixing that.
> Sorry. I'm preparing cross compiler. But this patch should fix this
> problem.
nwflash is a flash programming driver. Any changes to it should be
rigorously tested or obviously correct because you can brick a netwindup
if you get it wrong.
Alan
On Sat, Jul 26, 2008 at 04:52:58PM +0100, Alan Cox wrote:
>
> > Sorry. I'm preparing cross compiler. But this patch should fix this
> > problem.
>
> nwflash is a flash programming driver. Any changes to it should be
> rigorously tested or obviously correct because you can brick a netwindup
> if you get it wrong.
Indeed.
As I understand the situation, there's only one person (in Canada) who
has the technology to unbrick them... which is a rather expensive
solution for folk this side of the pond.
On Sat, Jul 26, 2008 at 04:52:58PM +0100, Alan Cox wrote:
>
> > Sorry. I'm preparing cross compiler. But this patch should fix this
> > problem.
>
> nwflash is a flash programming driver. Any changes to it should be
> rigorously tested or obviously correct because you can brick a netwindup
> if you get it wrong.
Well, Ralph volunteered to test the changes to nwflash.c, but it seems
something is buggered with the kernel at the moment - it doesn't seem
to want to mount a rootfs, or even enter prepare_namespace().
[NeTTrom] Second level jump mode
[FB B0=0x00000045][FB B1=0x01000045][FB B2=0x00000000][FB B3=0x00000000]
[Kern loc=0x01C00000]
[VGA_30=0x02][VGA_71=0x50][VGA_72=0x06]
[VGA_B2=0xDB][VGA_B3=0x54]
[CMD=ide0=autotune console=ttyS0,115200 noinitrd keepinitrd root=/dev/sda1 rootwait rootdelay=5 netconfig_eth0=disk netconfig_eth1=disk ]
Assuming A.OUT kernel
Copying 0x0027EA00 bytes from 0x01C00200 to 0x0000C000
Initrd: scan 0x0027E7FC bytes @ 0x01C00204.
Found CRAMdisk at 0x01C03454.
CRAMdisk image @0xC0400000, size 0x0027B7B0.
Kernel entry point 0x0000C000
Press '*' TWICE to enter debug......Booting kernel...
Uncompressing Linux............................................................................................................................................. done, booting the kernel.
...
Kernel command line: ide0=autotune console=ttyS0,115200 noinitrd keepinitrd root=/dev/sda1 rootwait rootdelay=5 netconfig_eth0=disk netconfig_eth1=disk
...
NET: Registered protocol family 1
checking if image is initramfs...it isn't (bad gzip magic numbers); looks like an initrd
NetWinder Floating Point Emulator V0.97 (double precision)
...
pata_sl82c105 0000:00:0c.1: pata_sl82c105: Early bridge revision, no DMA available.
scsi0 : pata_sl82c105
scsi1 : pata_sl82c105
ata1: PATA max PIO4 cmd 0x10c0 ctl 0x10d0 bmdma 0x10a0 irq 14
ata2: PATA max PIO4 cmd 0x10c8 ctl 0x10d1 bmdma 0x10a8 irq 14
ata1.00: ATA-4: TOSHIBA MK4006MAV, F2.03 A, max UDMA/33
ata1.00: 8007552 sectors, multi 16: LBA
ata1.00: configured for PIO4
scsi 0:0:0:0: Direct-Access ATA TOSHIBA MK4006MA F2.0 PQ: 0 ANSI: 5
...
sda: sda1 sda2
sd 0:0:0:0: [sda] Attached SCSI disk
serio: i8042 KBD port at 0x60,0x64 irq 1
serio: i8042 AUX port at 0x60,0x64 irq 5
mice: PS/2 mouse device common for all mice
usbcore: registered new interface driver hiddev
usbcore: registered new interface driver usbhid
usbhid: v2.6:USB HID core driver
TCP cubic registered
Initializing XFRM netlink socket
NET: Registered protocol family 17
registered taskstats version 1
Freeing init memory: 940K
Failed to execute /init
Kernel panic - not syncing: No init found. Try passing init= option to kernel.
Note that we've passed rootdelay, which should print
"Waiting 5sec before mounting root device..." on entry to
prepare_namespace(). This implies that in init/main.c:
if (!ramdisk_execute_command)
ramdisk_execute_command = "/init";
if (sys_access((const char __user *) ramdisk_execute_command, 0) != 0) { ramdisk_execute_command = NULL;
prepare_namespace();
}
is somehow finding a /init.
I wonder if (because of the Nettrom deciding the kernel image is a CRAMfs
image) whether the kernel is somehow decoding itself and finding a /init
inside somehow...
In any case, the kernel seems rather broken on Netwinders at present, so
changes to nwflash.c won't corrupt anyones flash until whatever's causing
this no-rootfs problem is fixed.