linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
* linux-2.6.36-rc4 problems booting rootfs from SD card
@ 2010-09-28 11:00 dylan cristiani
       [not found] ` <4CA1F195.4080601@yahoo.es>
                   ` (2 more replies)
  0 siblings, 3 replies; 7+ messages in thread
From: dylan cristiani @ 2010-09-28 11:00 UTC (permalink / raw)
  To: linux-arm-kernel

Hi sirs, here is my scenario: kernel 2.6.36-rc4; cpu pxa270; platform
is an enhancement (i like to see things that way...) and customisation
of the mainstone III board; here comes the (my) problem: if i boot with
my standard kernel boot command line (to boot from system flash):
'root=/dev/mtdblock2 rootfstype=jffs2 mem=64M console=ttyS0,115200n8'

i can get the rootfs up, and the SD card is up too, and correctly
working; here's the relevant kernel log:

....
XScale iWMMXt coprocessor detected.
 rtc-ds1307 0-0068: setting system clock to 2010-09-28 03:03:08 UTC
(1285642988)
 pxa27x-udc pxa27x-udc: USB reset
 mmc0: new SD card at address aaaa
 mmcblk0: mmc0:aaaa SD02G 1.84 GiB
  mmcblk0: p1
 pxa27x-udc pxa27x-udc: USB reset
.....

then the rootfs coems up properly.

Else, if i try to boot the rootfs directly form the SD card, with
kernel boot command line:
'root=/dev/mmcblk0p1 rootfstype=ext2 mem=64M console=ttyS0,115200n8'

the rootfs doen't work, and i can see some problems around with usb
client gadget; here's the relevant kernel log:

....
XScale iWMMXt coprocessor detected.
 rtc-ds1307 0-0068: setting system clock to 2010-09-28 03:03:43 UTC
(1285643023)
 VFS: Cannot open root device "mmcblk0p1" or unknown-block(0,0)
 Please append a correct "root=" boot option; here are the available
partitions:
 1f00             256 mtdblock0 (driver?)
 1f01            2048 mtdblock1 (driver?)
 1f02           63232 mtdblock2 (driver?)
 Kernel panic - not syncing: VFS: Unable to mount root fs on
unknown-block(0,0)
 Backtrace:
 [] (dump_backtrace+0x0/0x118) from [] (dump_stack+0x18/0x1c)
r6:00008000 r5:c3813000 r4:c0417b70 r3:c03f5714
 [] (dump_stack+0x0/0x1c) from [] (panic+0x60/0x18c)
 [] (panic+0x0/0x18c) from [] (mount_block_root+0x25c/0x2ac)
 pxa27x-udc pxa27x-udc: ep0:handle_ep0: state=WAIT_FOR_SETUP,
req=(null), udccsr0=0x2c1, udcbcr=8, irq_msk=1
 pxa27x-udc pxa27x-udc: ep0:set_ep0state:
state=WAIT_FOR_SETUP->SETUP_STAGE, udccsr0=0x2c1, udcbcr=8
 pxa27x-udc pxa27x-udc: ep0:handle_ep0_ctrl_req: SETUP 80.06 v0100
i0000 l0040
 pxa27x-udc pxa27x-udc: ep0:set_ep0state:
state=SETUP_STAGE->IN_DATA_STAGE, udccsr0=0x281, udcbcr=0
 pxa27x-udc pxa27x-udc: ep0:pxa_ep_queue: queue req
c393dbc0(first=yes), len 18 buf c386d000
 pxa27x-udc pxa27x-udc: ep0:write_ep0_fifo: in 16 bytes, 2 left,
req=c393dbc0, udccsr0=0x202
 pxa27x-udc pxa27x-udc: USB reset
 pxa27x-udc pxa27x-udc: USB reset start
 pxa27x-udc pxa27x-udc: ep0:req_done: complete req c393dbc0 stat -71
len 16/18
 g_ether gadget: setup complete --> -71, 16/18
 pxa27x-udc pxa27x-udc: ep0:set_ep0state:
state=IN_DATA_STAGE->WAIT_FOR_SETUP, udccsr0=0x200, udcbcr=0
 pxa27x-udc pxa27x-udc: ep0:handle_ep0: state=WAIT_FOR_SETUP,
req=(null), udccsr0=0x200, udcbcr=0, irq_msk=1
  r3:00000001 r2:20000013 r1:c3825f60 r0:c039601b
 [] (mount_block_root+0x0/0x2ac) from [] (mount_root+0x54/0x6c)
  r8:00000000 r7:00000013 r6:c0051e48 r5:00000000 r4:c039607f
 [] (mount_root+0x0/0x6c) from [] (prepare_namespace+0x12c/0x184)
  r5:c00203c1 r4:c00203ac
 [] (prepare_namespace+0x0/0x184) from [] (kernel_init+0x114/0x154)
  r5:c00083d4 r4:c0416e60
 [] (kernel_init+0x0/0x154) from [] (do_exit+0x0/0x5dc)
  r4:00000000 r3:00000000
....

last months i ported my system form ancient 2.6.18 kernel to my current
kernel (2.6.36-rc4), but i remember that with 2.6.18 the rootfs's
booting from SD did work; so i re-loaded 2.6.18 zImage, and in fact the
SD roots booting worked properly; then i investigated a bit and i have
found that also with 2.6.19 it worked, while with 2.6.20 it stopped
working (i didn't try between 2.6.20 and 2.6.36-rc4 but if it's helpful
i can do it).
The only way to solve my problem was to 'patch' the file
drivers/Makefile, moving the mmc.o object file upward; here is a sort of
'patch', but i regret in advance for some 'possible' (i had to write
'sure', but i like to be modest person....) syntax mistake, but i'm not
in habbit with patches...:

 --- a/drivers/Makefile
 +++ b/drivers/Makefile
 @@ -44,7 +44,8 @@
  obj-y                += macintosh/
  obj-$(CONFIG_IDE)        += ide/
  obj-$(CONFIG_SCSI)        += scsi/
  obj-$(CONFIG_ATA)        += ata/
  obj-$(CONFIG_MTD)        += mtd/
  obj-$(CONFIG_SPI)        += spi/
 +obj-$(CONFIG_MMC)        += mmc/
  obj-y                += net/
 @@ -92,9 +93,8 @@
  obj-y                += lguest/
  obj-$(CONFIG_CPU_FREQ)        += cpufreq/
  obj-$(CONFIG_CPU_IDLE)        += cpuidle/
 -obj-$(CONFIG_MMC)        += mmc/
  obj-$(CONFIG_MEMSTICK)        += memstick/
  obj-$(CONFIG_NEW_LEDS)        += leds/
  obj-$(CONFIG_INFINIBAND)    += infiniband/
  obj-$(CONFIG_SGI_SN)        += sn/
  obj-y                += firmware/

stated that it's not clear to me why when i don't try to boot the
rootfs directly from the SD, its driver comes up in the right way, and
the SD works, while when i try to boot the rootfs from the SD i cannot
get things to work (maybe the device is not up yet when the VFS
tryies to come up in fact in such a situation i cannot read any log
about mmc0 device!), i was wondering if this patch could be fair or
maybe (probably) i'm missing some potential side effects???
any hint will be appreciated!!!
thanks and bye

-

dylan cristiani

--
Fortunately I?ve been adhering to a pretty strict, uh, drug regimen to
keep my mind, you know, uh, limber...
---

^ permalink raw reply	[flat|nested] 7+ messages in thread

* linux-2.6.36-rc4 problems booting rootfs from SD card
       [not found] ` <4CA1F195.4080601@yahoo.es>
@ 2010-09-28 14:04   ` dylan cristiani
  0 siblings, 0 replies; 7+ messages in thread
From: dylan cristiani @ 2010-09-28 14:04 UTC (permalink / raw)
  To: linux-arm-kernel

On Tue, 28 Sep 2010 21:45:57 +0800
Hein_Tibosch <hein_tibosch@yahoo.es> wrote:

>  On 28-9-2010 19:00, dylan cristiani wrote:
> > Hi sirs, here is my scenario: kernel 2.6.36-rc4; cpu pxa270;
> > platform is an enhancement (i like to see things that way...) and
> > customisation of the mainstone III board; here comes the (my)
> > problem: if i boot with my standard kernel boot command line (to
> > boot from system flash): 'root=/dev/mtdblock2 rootfstype=jffs2
> > mem=64M console=ttyS0,115200n8'
> >
> > i can get the rootfs up, and the SD card is up too, and correctly
> > working; here's the relevant kernel log:
> >
> > ....
> > XScale iWMMXt coprocessor detected.
> >  rtc-ds1307 0-0068: setting system clock to 2010-09-28 03:03:08 UTC
> > (1285642988)
> >  pxa27x-udc pxa27x-udc: USB reset
> >  mmc0: new SD card at address aaaa
> >  mmcblk0: mmc0:aaaa SD02G 1.84 GiB
> >   mmcblk0: p1
> >  pxa27x-udc pxa27x-udc: USB reset
> > .....
> >
> > then the rootfs coems up properly.
> >
> > Else, if i try to boot the rootfs directly form the SD card, with
> > kernel boot command line:
> > 'root=/dev/mmcblk0p1 rootfstype=ext2 mem=64M console=ttyS0,115200n8'
> >
> > the rootfs doen't work, and i can see some problems around with usb
> > client gadget; here's the relevant kernel log:
> >
> Hi Dylan
> 
> A reason could be that you linked the ext2 driver as a module,
> which is normally loaded after your jffs2 fs has booted?
> The solution would be to link it into the kernel, thus using
> "CONFIG_EXT2_FS=y" in stead of "=m"
Hi Hein, foa thanks for your answer, but the ext2 driver in compiled
into kernel not as a module but buil-into the kernel so i've already:
"CONFIG_EXT2_FS=y"
setted in my .config file
as i told you the booting form SD worked till 2.6.19 kernel and first
trouble i've seen is into 2.6.20

> 
> Note that ext3 is again more stable than ext2 and also supported by
> u-boot.
> 
> I hacked init/do_mounts.c
> 
> -        printk("VFS: Cannot open root device \"%s\" or %s\n",
> -                root_device_name, b);
> +        printk("VFS: Cannot open root device \"%s\" or %s (fstype %s
> err %d)\n",
> +                root_device_name, b, fs_names, err);
> 
> so at least I get some more error information.
i'll try this and if i'll get more info i'll post them

> 
> Good luck!
tks
dylan

^ permalink raw reply	[flat|nested] 7+ messages in thread

* linux-2.6.36-rc4 problems booting rootfs from SD card
  2010-09-28 11:00 linux-2.6.36-rc4 problems booting rootfs from SD card dylan cristiani
       [not found] ` <4CA1F195.4080601@yahoo.es>
@ 2010-09-28 14:16 ` Vasily Khoruzhick
  2010-09-28 14:51   ` dylan cristiani
  2010-09-28 14:58   ` Hein_Tibosch
  2010-09-28 19:08 ` Russell King - ARM Linux
  2 siblings, 2 replies; 7+ messages in thread
From: Vasily Khoruzhick @ 2010-09-28 14:16 UTC (permalink / raw)
  To: linux-arm-kernel

On 28 of September 2010 14:00:43 dylan cristiani wrote:
> Hi sirs, here is my scenario: kernel 2.6.36-rc4; cpu pxa270; platform
> is an enhancement (i like to see things that way...) and customisation
> of the mainstone III board; here comes the (my) problem: if i boot with
> my standard kernel boot command line (to boot from system flash):
> 'root=/dev/mtdblock2 rootfstype=jffs2 mem=64M console=ttyS0,115200n8'
> 
> i can get the rootfs up, and the SD card is up too, and correctly
> working; here's the relevant kernel log:
> 
> ....
> XScale iWMMXt coprocessor detected.
>  rtc-ds1307 0-0068: setting system clock to 2010-09-28 03:03:08 UTC
> (1285642988)
>  pxa27x-udc pxa27x-udc: USB reset
>  mmc0: new SD card at address aaaa
>  mmcblk0: mmc0:aaaa SD02G 1.84 GiB
>   mmcblk0: p1
>  pxa27x-udc pxa27x-udc: USB reset
> .....
> 
> then the rootfs coems up properly.
> 
> Else, if i try to boot the rootfs directly form the SD card, with
> kernel boot command line:
> 'root=/dev/mmcblk0p1 rootfstype=ext2 mem=64M console=ttyS0,115200n8'
> 
> the rootfs doen't work, and i can see some problems around with usb
> client gadget; here's the relevant kernel log:
> 
> ....
> XScale iWMMXt coprocessor detected.
>  rtc-ds1307 0-0068: setting system clock to 2010-09-28 03:03:43 UTC
> (1285643023)
>  VFS: Cannot open root device "mmcblk0p1" or unknown-block(0,0)
>  Please append a correct "root=" boot option; here are the available
> partitions:
>  1f00             256 mtdblock0 (driver?)
>  1f01            2048 mtdblock1 (driver?)
>  1f02           63232 mtdblock2 (driver?)
>  Kernel panic - not syncing: VFS: Unable to mount root fs on
> unknown-block(0,0)
>  Backtrace:
>  [] (dump_backtrace+0x0/0x118) from [] (dump_stack+0x18/0x1c)
> r6:00008000 r5:c3813000 r4:c0417b70 r3:c03f5714
>  [] (dump_stack+0x0/0x1c) from [] (panic+0x60/0x18c)
>  [] (panic+0x0/0x18c) from [] (mount_block_root+0x25c/0x2ac)
>  pxa27x-udc pxa27x-udc: ep0:handle_ep0: state=WAIT_FOR_SETUP,
> req=(null), udccsr0=0x2c1, udcbcr=8, irq_msk=1
>  pxa27x-udc pxa27x-udc: ep0:set_ep0state:
> state=WAIT_FOR_SETUP->SETUP_STAGE, udccsr0=0x2c1, udcbcr=8
>  pxa27x-udc pxa27x-udc: ep0:handle_ep0_ctrl_req: SETUP 80.06 v0100
> i0000 l0040
>  pxa27x-udc pxa27x-udc: ep0:set_ep0state:
> state=SETUP_STAGE->IN_DATA_STAGE, udccsr0=0x281, udcbcr=0
>  pxa27x-udc pxa27x-udc: ep0:pxa_ep_queue: queue req
> c393dbc0(first=yes), len 18 buf c386d000
>  pxa27x-udc pxa27x-udc: ep0:write_ep0_fifo: in 16 bytes, 2 left,
> req=c393dbc0, udccsr0=0x202
>  pxa27x-udc pxa27x-udc: USB reset
>  pxa27x-udc pxa27x-udc: USB reset start
>  pxa27x-udc pxa27x-udc: ep0:req_done: complete req c393dbc0 stat -71
> len 16/18
>  g_ether gadget: setup complete --> -71, 16/18
>  pxa27x-udc pxa27x-udc: ep0:set_ep0state:
> state=IN_DATA_STAGE->WAIT_FOR_SETUP, udccsr0=0x200, udcbcr=0
>  pxa27x-udc pxa27x-udc: ep0:handle_ep0: state=WAIT_FOR_SETUP,
> req=(null), udccsr0=0x200, udcbcr=0, irq_msk=1
>   r3:00000001 r2:20000013 r1:c3825f60 r0:c039601b
>  [] (mount_block_root+0x0/0x2ac) from [] (mount_root+0x54/0x6c)
>   r8:00000000 r7:00000013 r6:c0051e48 r5:00000000 r4:c039607f
>  [] (mount_root+0x0/0x6c) from [] (prepare_namespace+0x12c/0x184)
>   r5:c00203c1 r4:c00203ac
>  [] (prepare_namespace+0x0/0x184) from [] (kernel_init+0x114/0x154)
>   r5:c00083d4 r4:c0416e60
>  [] (kernel_init+0x0/0x154) from [] (do_exit+0x0/0x5dc)
>   r4:00000000 r3:00000000
> ....
> 
> last months i ported my system form ancient 2.6.18 kernel to my current
> kernel (2.6.36-rc4), but i remember that with 2.6.18 the rootfs's
> booting from SD did work; so i re-loaded 2.6.18 zImage, and in fact the
> SD roots booting worked properly; then i investigated a bit and i have
> found that also with 2.6.19 it worked, while with 2.6.20 it stopped
> working (i didn't try between 2.6.20 and 2.6.36-rc4 but if it's helpful
> i can do it).
> The only way to solve my problem was to 'patch' the file
> drivers/Makefile, moving the mmc.o object file upward; here is a sort of
> 'patch', but i regret in advance for some 'possible' (i had to write
> 'sure', but i like to be modest person....) syntax mistake, but i'm not
> in habbit with patches...:
> 
>  --- a/drivers/Makefile
>  +++ b/drivers/Makefile
>  @@ -44,7 +44,8 @@
>   obj-y                += macintosh/
>   obj-$(CONFIG_IDE)        += ide/
>   obj-$(CONFIG_SCSI)        += scsi/
>   obj-$(CONFIG_ATA)        += ata/
>   obj-$(CONFIG_MTD)        += mtd/
>   obj-$(CONFIG_SPI)        += spi/
>  +obj-$(CONFIG_MMC)        += mmc/
>   obj-y                += net/
>  @@ -92,9 +93,8 @@
>   obj-y                += lguest/
>   obj-$(CONFIG_CPU_FREQ)        += cpufreq/
>   obj-$(CONFIG_CPU_IDLE)        += cpuidle/
>  -obj-$(CONFIG_MMC)        += mmc/
>   obj-$(CONFIG_MEMSTICK)        += memstick/
>   obj-$(CONFIG_NEW_LEDS)        += leds/
>   obj-$(CONFIG_INFINIBAND)    += infiniband/
>   obj-$(CONFIG_SGI_SN)        += sn/
>   obj-y                += firmware/
> 
> stated that it's not clear to me why when i don't try to boot the
> rootfs directly from the SD, its driver comes up in the right way, and
> the SD works, while when i try to boot the rootfs from the SD i cannot
> get things to work (maybe the device is not up yet when the VFS
> tryies to come up in fact in such a situation i cannot read any log
> about mmc0 device!), i was wondering if this patch could be fair or
> maybe (probably) i'm missing some potential side effects???
> any hint will be appreciated!!!
> thanks and bye
> 
> -
> 
> dylan cristiani
> 
> --
> Fortunately I?ve been adhering to a pretty strict, uh, drug regimen to
> keep my mind, you know, uh, limber...
> ---

It seems you're missing rootdelay=[0-9]+ argument to kernel

^ permalink raw reply	[flat|nested] 7+ messages in thread

* linux-2.6.36-rc4 problems booting rootfs from SD card
  2010-09-28 14:16 ` Vasily Khoruzhick
@ 2010-09-28 14:51   ` dylan cristiani
  2010-09-28 14:55     ` Ghorai, Sukumar
  2010-09-28 14:58   ` Hein_Tibosch
  1 sibling, 1 reply; 7+ messages in thread
From: dylan cristiani @ 2010-09-28 14:51 UTC (permalink / raw)
  To: linux-arm-kernel

On Tue, 28 Sep 2010 17:16:41 +0300
Vasily Khoruzhick <anarsoul@gmail.com> wrote:

> On 28 of September 2010 14:00:43 dylan cristiani wrote:
> > Hi sirs, here is my scenario: kernel 2.6.36-rc4; cpu pxa270;
> > platform is an enhancement (i like to see things that way...) and
> > customisation of the mainstone III board; here comes the (my)
> > problem: if i boot with my standard kernel boot command line (to
> > boot from system flash): 'root=/dev/mtdblock2 rootfstype=jffs2
> > mem=64M console=ttyS0,115200n8'
> > 
> > i can get the rootfs up, and the SD card is up too, and correctly
> > working; here's the relevant kernel log:
> > 
> > ....
> > XScale iWMMXt coprocessor detected.
> >  rtc-ds1307 0-0068: setting system clock to 2010-09-28 03:03:08 UTC
> > (1285642988)
> >  pxa27x-udc pxa27x-udc: USB reset
> >  mmc0: new SD card at address aaaa
> >  mmcblk0: mmc0:aaaa SD02G 1.84 GiB
> >   mmcblk0: p1
> >  pxa27x-udc pxa27x-udc: USB reset
> > .....
> > 
> > then the rootfs coems up properly.
> > 
> > Else, if i try to boot the rootfs directly form the SD card, with
> > kernel boot command line:
> > 'root=/dev/mmcblk0p1 rootfstype=ext2 mem=64M console=ttyS0,115200n8'
> > 
> > the rootfs doen't work, and i can see some problems around with usb
> > client gadget; here's the relevant kernel log:
> > 
> > ....
> > XScale iWMMXt coprocessor detected.
> >  rtc-ds1307 0-0068: setting system clock to 2010-09-28 03:03:43 UTC
> > (1285643023)
> >  VFS: Cannot open root device "mmcblk0p1" or unknown-block(0,0)
> >  Please append a correct "root=" boot option; here are the available
> > partitions:
> >  1f00             256 mtdblock0 (driver?)
> >  1f01            2048 mtdblock1 (driver?)
> >  1f02           63232 mtdblock2 (driver?)
> >  Kernel panic - not syncing: VFS: Unable to mount root fs on
> > unknown-block(0,0)
> >  Backtrace:
> >  [] (dump_backtrace+0x0/0x118) from [] (dump_stack+0x18/0x1c)
> > r6:00008000 r5:c3813000 r4:c0417b70 r3:c03f5714
> >  [] (dump_stack+0x0/0x1c) from [] (panic+0x60/0x18c)
> >  [] (panic+0x0/0x18c) from [] (mount_block_root+0x25c/0x2ac)
> >  pxa27x-udc pxa27x-udc: ep0:handle_ep0: state=WAIT_FOR_SETUP,
> > req=(null), udccsr0=0x2c1, udcbcr=8, irq_msk=1
> >  pxa27x-udc pxa27x-udc: ep0:set_ep0state:
> > state=WAIT_FOR_SETUP->SETUP_STAGE, udccsr0=0x2c1, udcbcr=8
> >  pxa27x-udc pxa27x-udc: ep0:handle_ep0_ctrl_req: SETUP 80.06 v0100
> > i0000 l0040
> >  pxa27x-udc pxa27x-udc: ep0:set_ep0state:
> > state=SETUP_STAGE->IN_DATA_STAGE, udccsr0=0x281, udcbcr=0
> >  pxa27x-udc pxa27x-udc: ep0:pxa_ep_queue: queue req
> > c393dbc0(first=yes), len 18 buf c386d000
> >  pxa27x-udc pxa27x-udc: ep0:write_ep0_fifo: in 16 bytes, 2 left,
> > req=c393dbc0, udccsr0=0x202
> >  pxa27x-udc pxa27x-udc: USB reset
> >  pxa27x-udc pxa27x-udc: USB reset start
> >  pxa27x-udc pxa27x-udc: ep0:req_done: complete req c393dbc0 stat -71
> > len 16/18
> >  g_ether gadget: setup complete --> -71, 16/18
> >  pxa27x-udc pxa27x-udc: ep0:set_ep0state:
> > state=IN_DATA_STAGE->WAIT_FOR_SETUP, udccsr0=0x200, udcbcr=0
> >  pxa27x-udc pxa27x-udc: ep0:handle_ep0: state=WAIT_FOR_SETUP,
> > req=(null), udccsr0=0x200, udcbcr=0, irq_msk=1
> >   r3:00000001 r2:20000013 r1:c3825f60 r0:c039601b
> >  [] (mount_block_root+0x0/0x2ac) from [] (mount_root+0x54/0x6c)
> >   r8:00000000 r7:00000013 r6:c0051e48 r5:00000000 r4:c039607f
> >  [] (mount_root+0x0/0x6c) from [] (prepare_namespace+0x12c/0x184)
> >   r5:c00203c1 r4:c00203ac
> >  [] (prepare_namespace+0x0/0x184) from [] (kernel_init+0x114/0x154)
> >   r5:c00083d4 r4:c0416e60
> >  [] (kernel_init+0x0/0x154) from [] (do_exit+0x0/0x5dc)
> >   r4:00000000 r3:00000000
> > ....
> > 
> > last months i ported my system form ancient 2.6.18 kernel to my
> > current kernel (2.6.36-rc4), but i remember that with 2.6.18 the
> > rootfs's booting from SD did work; so i re-loaded 2.6.18 zImage,
> > and in fact the SD roots booting worked properly; then i
> > investigated a bit and i have found that also with 2.6.19 it
> > worked, while with 2.6.20 it stopped working (i didn't try between
> > 2.6.20 and 2.6.36-rc4 but if it's helpful i can do it).
> > The only way to solve my problem was to 'patch' the file
> > drivers/Makefile, moving the mmc.o object file upward; here is a
> > sort of 'patch', but i regret in advance for some 'possible' (i had
> > to write 'sure', but i like to be modest person....) syntax
> > mistake, but i'm not in habbit with patches...:
> > 
> >  --- a/drivers/Makefile
> >  +++ b/drivers/Makefile
> >  @@ -44,7 +44,8 @@
> >   obj-y                += macintosh/
> >   obj-$(CONFIG_IDE)        += ide/
> >   obj-$(CONFIG_SCSI)        += scsi/
> >   obj-$(CONFIG_ATA)        += ata/
> >   obj-$(CONFIG_MTD)        += mtd/
> >   obj-$(CONFIG_SPI)        += spi/
> >  +obj-$(CONFIG_MMC)        += mmc/
> >   obj-y                += net/
> >  @@ -92,9 +93,8 @@
> >   obj-y                += lguest/
> >   obj-$(CONFIG_CPU_FREQ)        += cpufreq/
> >   obj-$(CONFIG_CPU_IDLE)        += cpuidle/
> >  -obj-$(CONFIG_MMC)        += mmc/
> >   obj-$(CONFIG_MEMSTICK)        += memstick/
> >   obj-$(CONFIG_NEW_LEDS)        += leds/
> >   obj-$(CONFIG_INFINIBAND)    += infiniband/
> >   obj-$(CONFIG_SGI_SN)        += sn/
> >   obj-y                += firmware/
> > 
> > stated that it's not clear to me why when i don't try to boot the
> > rootfs directly from the SD, its driver comes up in the right way,
> > and the SD works, while when i try to boot the rootfs from the SD i
> > cannot get things to work (maybe the device is not up yet when the
> > VFS tryies to come up in fact in such a situation i cannot read any
> > log about mmc0 device!), i was wondering if this patch could be
> > fair or maybe (probably) i'm missing some potential side effects???
> > any hint will be appreciated!!!
> > thanks and bye
> > 
> > -
> > 
> > dylan cristiani
> > 
> > --
> > Fortunately I?ve been adhering to a pretty strict, uh, drug regimen
> > to keep my mind, you know, uh, limber...
> > ---
> 
> It seems you're missing rootdelay=[0-9]+ argument to kernel
you scored a great gol Vasily, simply adding
rootdealy=1
to my boot command line solved the issue!!!

thanks a million and uhm....i wasn't missing it, it was just a question
of infinite ignorance of mine....sorry for noise!!!

dylan

^ permalink raw reply	[flat|nested] 7+ messages in thread

* linux-2.6.36-rc4 problems booting rootfs from SD card
  2010-09-28 14:51   ` dylan cristiani
@ 2010-09-28 14:55     ` Ghorai, Sukumar
  0 siblings, 0 replies; 7+ messages in thread
From: Ghorai, Sukumar @ 2010-09-28 14:55 UTC (permalink / raw)
  To: linux-arm-kernel



> -----Original Message-----
> From: linux-mmc-owner at vger.kernel.org [mailto:linux-mmc-
> owner at vger.kernel.org] On Behalf Of dylan cristiani
> Sent: Tuesday, September 28, 2010 8:21 PM
> To: Vasily Khoruzhick
> Cc: linux-arm-kernel at lists.infradead.org; linux-mmc at vger.kernel.org
> Subject: Re: linux-2.6.36-rc4 problems booting rootfs from SD card
> 
> On Tue, 28 Sep 2010 17:16:41 +0300
> Vasily Khoruzhick <anarsoul@gmail.com> wrote:
> 
> > On 28 of September 2010 14:00:43 dylan cristiani wrote:
> > > Hi sirs, here is my scenario: kernel 2.6.36-rc4; cpu pxa270;
> > > platform is an enhancement (i like to see things that way...) and
> > > customisation of the mainstone III board; here comes the (my)
> > > problem: if i boot with my standard kernel boot command line (to
> > > boot from system flash): 'root=/dev/mtdblock2 rootfstype=jffs2
> > > mem=64M console=ttyS0,115200n8'
> > >
> > > i can get the rootfs up, and the SD card is up too, and correctly
> > > working; here's the relevant kernel log:
> > >
> > > ....
> > > XScale iWMMXt coprocessor detected.
> > >  rtc-ds1307 0-0068: setting system clock to 2010-09-28 03:03:08 UTC
> > > (1285642988)
> > >  pxa27x-udc pxa27x-udc: USB reset
> > >  mmc0: new SD card at address aaaa
> > >  mmcblk0: mmc0:aaaa SD02G 1.84 GiB
> > >   mmcblk0: p1
> > >  pxa27x-udc pxa27x-udc: USB reset
> > > .....
> > >
> > > then the rootfs coems up properly.
> > >
> > > Else, if i try to boot the rootfs directly form the SD card, with
> > > kernel boot command line:
> > > 'root=/dev/mmcblk0p1 rootfstype=ext2 mem=64M console=ttyS0,115200n8'
> > >
> > > the rootfs doen't work, and i can see some problems around with usb
> > > client gadget; here's the relevant kernel log:
> > >
> > > ....
> > > XScale iWMMXt coprocessor detected.
> > >  rtc-ds1307 0-0068: setting system clock to 2010-09-28 03:03:43 UTC
> > > (1285643023)
> > >  VFS: Cannot open root device "mmcblk0p1" or unknown-block(0,0)
> > >  Please append a correct "root=" boot option; here are the available
> > > partitions:
> > >  1f00             256 mtdblock0 (driver?)
> > >  1f01            2048 mtdblock1 (driver?)
> > >  1f02           63232 mtdblock2 (driver?)
> > >  Kernel panic - not syncing: VFS: Unable to mount root fs on
> > > unknown-block(0,0)
> > >  Backtrace:
> > >  [] (dump_backtrace+0x0/0x118) from [] (dump_stack+0x18/0x1c)
> > > r6:00008000 r5:c3813000 r4:c0417b70 r3:c03f5714
> > >  [] (dump_stack+0x0/0x1c) from [] (panic+0x60/0x18c)
> > >  [] (panic+0x0/0x18c) from [] (mount_block_root+0x25c/0x2ac)
> > >  pxa27x-udc pxa27x-udc: ep0:handle_ep0: state=WAIT_FOR_SETUP,
> > > req=(null), udccsr0=0x2c1, udcbcr=8, irq_msk=1
> > >  pxa27x-udc pxa27x-udc: ep0:set_ep0state:
> > > state=WAIT_FOR_SETUP->SETUP_STAGE, udccsr0=0x2c1, udcbcr=8
> > >  pxa27x-udc pxa27x-udc: ep0:handle_ep0_ctrl_req: SETUP 80.06 v0100
> > > i0000 l0040
> > >  pxa27x-udc pxa27x-udc: ep0:set_ep0state:
> > > state=SETUP_STAGE->IN_DATA_STAGE, udccsr0=0x281, udcbcr=0
> > >  pxa27x-udc pxa27x-udc: ep0:pxa_ep_queue: queue req
> > > c393dbc0(first=yes), len 18 buf c386d000
> > >  pxa27x-udc pxa27x-udc: ep0:write_ep0_fifo: in 16 bytes, 2 left,
> > > req=c393dbc0, udccsr0=0x202
> > >  pxa27x-udc pxa27x-udc: USB reset
> > >  pxa27x-udc pxa27x-udc: USB reset start
> > >  pxa27x-udc pxa27x-udc: ep0:req_done: complete req c393dbc0 stat -71
> > > len 16/18
> > >  g_ether gadget: setup complete --> -71, 16/18
> > >  pxa27x-udc pxa27x-udc: ep0:set_ep0state:
> > > state=IN_DATA_STAGE->WAIT_FOR_SETUP, udccsr0=0x200, udcbcr=0
> > >  pxa27x-udc pxa27x-udc: ep0:handle_ep0: state=WAIT_FOR_SETUP,
> > > req=(null), udccsr0=0x200, udcbcr=0, irq_msk=1
> > >   r3:00000001 r2:20000013 r1:c3825f60 r0:c039601b
> > >  [] (mount_block_root+0x0/0x2ac) from [] (mount_root+0x54/0x6c)
> > >   r8:00000000 r7:00000013 r6:c0051e48 r5:00000000 r4:c039607f
> > >  [] (mount_root+0x0/0x6c) from [] (prepare_namespace+0x12c/0x184)
> > >   r5:c00203c1 r4:c00203ac
> > >  [] (prepare_namespace+0x0/0x184) from [] (kernel_init+0x114/0x154)
> > >   r5:c00083d4 r4:c0416e60
> > >  [] (kernel_init+0x0/0x154) from [] (do_exit+0x0/0x5dc)
> > >   r4:00000000 r3:00000000
> > > ....
> > >
> > > last months i ported my system form ancient 2.6.18 kernel to my
> > > current kernel (2.6.36-rc4), but i remember that with 2.6.18 the
> > > rootfs's booting from SD did work; so i re-loaded 2.6.18 zImage,
> > > and in fact the SD roots booting worked properly; then i
> > > investigated a bit and i have found that also with 2.6.19 it
> > > worked, while with 2.6.20 it stopped working (i didn't try between
> > > 2.6.20 and 2.6.36-rc4 but if it's helpful i can do it).
> > > The only way to solve my problem was to 'patch' the file
> > > drivers/Makefile, moving the mmc.o object file upward; here is a
> > > sort of 'patch', but i regret in advance for some 'possible' (i had
> > > to write 'sure', but i like to be modest person....) syntax
> > > mistake, but i'm not in habbit with patches...:
> > >
> > >  --- a/drivers/Makefile
> > >  +++ b/drivers/Makefile
> > >  @@ -44,7 +44,8 @@
> > >   obj-y                += macintosh/
> > >   obj-$(CONFIG_IDE)        += ide/
> > >   obj-$(CONFIG_SCSI)        += scsi/
> > >   obj-$(CONFIG_ATA)        += ata/
> > >   obj-$(CONFIG_MTD)        += mtd/
> > >   obj-$(CONFIG_SPI)        += spi/
> > >  +obj-$(CONFIG_MMC)        += mmc/
> > >   obj-y                += net/
> > >  @@ -92,9 +93,8 @@
> > >   obj-y                += lguest/
> > >   obj-$(CONFIG_CPU_FREQ)        += cpufreq/
> > >   obj-$(CONFIG_CPU_IDLE)        += cpuidle/
> > >  -obj-$(CONFIG_MMC)        += mmc/
> > >   obj-$(CONFIG_MEMSTICK)        += memstick/
> > >   obj-$(CONFIG_NEW_LEDS)        += leds/
> > >   obj-$(CONFIG_INFINIBAND)    += infiniband/
> > >   obj-$(CONFIG_SGI_SN)        += sn/
> > >   obj-y                += firmware/
> > >
> > > stated that it's not clear to me why when i don't try to boot the
> > > rootfs directly from the SD, its driver comes up in the right way,
> > > and the SD works, while when i try to boot the rootfs from the SD i
> > > cannot get things to work (maybe the device is not up yet when the
> > > VFS tryies to come up in fact in such a situation i cannot read any
> > > log about mmc0 device!), i was wondering if this patch could be
> > > fair or maybe (probably) i'm missing some potential side effects???
> > > any hint will be appreciated!!!
> > > thanks and bye
> > >
> > > -
> > >
> > > dylan cristiani
> > >
> > > --
> > > Fortunately I've been adhering to a pretty strict, uh, drug regimen
> > > to keep my mind, you know, uh, limber...
> > > ---
> >
> > It seems you're missing rootdelay=[0-9]+ argument to kernel
> you scored a great gol Vasily, simply adding
> rootdealy=1
> to my boot command line solved the issue!!!
> 
[Ghorai] better option would be use "rootwait" 

> thanks a million and uhm....i wasn't missing it, it was just a question
> of infinite ignorance of mine....sorry for noise!!!
> 
> dylan
> --
> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 7+ messages in thread

* linux-2.6.36-rc4 problems booting rootfs from SD card
  2010-09-28 14:16 ` Vasily Khoruzhick
  2010-09-28 14:51   ` dylan cristiani
@ 2010-09-28 14:58   ` Hein_Tibosch
  1 sibling, 0 replies; 7+ messages in thread
From: Hein_Tibosch @ 2010-09-28 14:58 UTC (permalink / raw)
  To: linux-arm-kernel

 On 28-9-2010 22:16, Vasily Khoruzhick wrote:
> On 28 of September 2010 14:00:43 dylan cristiani wrote:
>> Hi sirs, here is my scenario: kernel 2.6.36-rc4; cpu pxa270; platform
>> is an enhancement (i like to see things that way...) and customisation
>> of the mainstone III board; here comes the (my) problem: if i boot with
>> my standard kernel boot command line (to boot from system flash):
>> 'root=/dev/mtdblock2 rootfstype=jffs2 mem=64M console=ttyS0,115200n8'
>>
>> i can get the rootfs up, and the SD card is up too, and correctly
>> working; here's the relevant kernel log:
>>
>> ....
>> XScale iWMMXt coprocessor detected.
>>  rtc-ds1307 0-0068: setting system clock to 2010-09-28 03:03:08 UTC
>> (1285642988)
>>  pxa27x-udc pxa27x-udc: USB reset
>>  mmc0: new SD card at address aaaa
>>  mmcblk0: mmc0:aaaa SD02G 1.84 GiB
>>   mmcblk0: p1
>>  pxa27x-udc pxa27x-udc: USB reset
>> .....
>>
>> then the rootfs coems up properly.
>>
>> Else, if i try to boot the rootfs directly form the SD card, with
>> kernel boot command line:
>> 'root=/dev/mmcblk0p1 rootfstype=ext2 mem=64M console=ttyS0,115200n8'
>>
>> <cut>
>>  Kernel panic - not syncing: VFS: Unable to mount root fs on
>> unknown-block(0,0)
> It seems you're missing rootdelay=[0-9]+ argument to kernel
I guess the default of rootdelay=1 (sec) should do, no?

Also try the rootwait argument, which goes without parameters:

root=/dev/mmcblk0p1 rootwait rootfstype=ext2 mem=64M console=ttyS0,115200n8

Hein

^ permalink raw reply	[flat|nested] 7+ messages in thread

* linux-2.6.36-rc4 problems booting rootfs from SD card
  2010-09-28 11:00 linux-2.6.36-rc4 problems booting rootfs from SD card dylan cristiani
       [not found] ` <4CA1F195.4080601@yahoo.es>
  2010-09-28 14:16 ` Vasily Khoruzhick
@ 2010-09-28 19:08 ` Russell King - ARM Linux
  2 siblings, 0 replies; 7+ messages in thread
From: Russell King - ARM Linux @ 2010-09-28 19:08 UTC (permalink / raw)
  To: linux-arm-kernel

On Tue, Sep 28, 2010 at 01:00:43PM +0200, dylan cristiani wrote:
> Hi sirs, here is my scenario: kernel 2.6.36-rc4; cpu pxa270; platform
> is an enhancement (i like to see things that way...) and customisation
> of the mainstone III board; here comes the (my) problem: if i boot with
> my standard kernel boot command line (to boot from system flash):
> 'root=/dev/mtdblock2 rootfstype=jffs2 mem=64M console=ttyS0,115200n8'
> 
> i can get the rootfs up, and the SD card is up too, and correctly
> working; here's the relevant kernel log:

Use 'rootdelay=1' to give time for the SD card to be detected.

^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2010-09-28 19:08 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-09-28 11:00 linux-2.6.36-rc4 problems booting rootfs from SD card dylan cristiani
     [not found] ` <4CA1F195.4080601@yahoo.es>
2010-09-28 14:04   ` dylan cristiani
2010-09-28 14:16 ` Vasily Khoruzhick
2010-09-28 14:51   ` dylan cristiani
2010-09-28 14:55     ` Ghorai, Sukumar
2010-09-28 14:58   ` Hein_Tibosch
2010-09-28 19:08 ` Russell King - ARM Linux

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).