2.6.22 - Unable to mount root fs.

Go To Last Post
17 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

So, I had 2.6.18 and just now upgraded to 2.6.22 and applied atmel.3 patches.
Now I can't mount the rootfs, it says it doesn't know the block device

Quote:

VFS: Cannot open root device "mmcblk0p1" or unknown-block(0,0)
Please append a correct "root=" boot option; here are the available partitions:
1f00 128 mtdblock0 (driver?)
1f01 8000 mtdblock1 (driver?)
1f02 64 mtdblock2 (driver?)
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)

I tried all of those options above without any success. Did something relevant changed between those two kernel versions?

Cheers

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Have a look at this post, I believe this is your problem:
https://www.avrfreaks.net/index.p...

Follow the instructions to delete and then make new /dev/mmcblk0* files using mknod.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Vulcan, thanks for the hint.
I have changed my devices to the proposed 179 but I still have the exact same problem. It also happens with the default config, so, I suppose it's not something that I am missing here (btw, this is STK1000)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Seems like there is more to it than just the device files' major numbers.

Try adding "rootwait=1" to the bootargs variable in U-boot.

I'm attaching my .config file as well (STK1000).

Attachment(s): 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi, Slips

I tested and verified my config file with yours. But no difference, but I found one of reasons which SD is not mounted.

That is the difference of speed of SD cards.

Try with SandDisk 128MB, it works.

But, try with SandDisk's UltraII, it does not work.

So, I think the current MMC driver should be modified.

Thanks,

James

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I found two things about current MMC driver.

1) It needs

#ifndef MODULE

static int __init mmc_finish_detect(void)
{
        mmc_flush_scheduled_work();
        return 0;
}
late_initcall(mmc_finish_detect);
#endif

Apply this in sysfs.c @ drivers/mmc/core

Then, slower SD card like SanDisk 128MB is working, but
not always.
But, Faster SD card like SanDisk Ultra II 1GB is not working.

2) If you activate debugger option,

CONFIG_MMC_DEBUG=y

then, both cards are working very well, but slow.

So, I think the current MMC driver has a problem in DMA control, or other race condition.

Please let me know your idea, then I'll try some more.

James

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The rootwait got me a bit further, thanks for the hint, but I still can't boot of the sdcard, now I get stuck at

Quote:

at32ap700x_rtc at32ap700x_rtc.0: rtc core: registered at32ap700x_rtc as rtc0
at32ap700x_rtc at32ap700x_rtc.0: Atmel RTC for AT32AP700x at fff00080 irq 21
mmc0: Atmel MCI controller at 0xfff02400 irq 28
TCP cubic registered
NET: Registered protocol family 1
NET: Registered protocol family 17
at32ap700x_rtc at32ap700x_rtc.0: setting the system clock to 1970-01-01 00:00:00
(0)
Waiting for root device /dev/mmcblk0p1...
mmc0: card claims to support voltages below the defined range. These will be ign
ored.
mmc0: SD card claims to support the incompletely defined 'low voltage range'. Th
is will be ignored.

It is worth mentioning that the exact same sdcard works perfectly with 2.6.18. This is really frustrating. The newer kernel were supposed to be better *smile*

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi, I found the problem. I hope the problem will be fixed by Atmel soon. Meantime you can use the MMC driver with a line insertion

Please add printk statement, which make a little time delay, then
the driver will be working well.

FILE: drivers/mmc/host/atmel-mci.c

static void atmci_request_end(struct mmc_host *mmc, struct mmc_request *mrq)
{
        struct atmel_mci *host = mmc_priv(mmc);

        WARN_ON(host->cmd || host->data);
        host->mrq = NULL;

        mmc_request_done(mmc, mrq);

        printk("AA"); // It makes a little time delay
}

Try it, let me know your results. My board is working very well.

James

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have had exactly the same problem with 2.6.22.3 !

(see my post "YANKP" in this forum!)

Unfortunately I am not expert enough to have identified the problem as did Jungjy

THANK YOU Jungjy !

I am somewhat disappointed that Atmel folks do not appear to have addressed this issue. I may be wrong in which case I will apologise in advance, but I have the feeling that often, problems are being resolved by the users and not by Atmel support.

Perhaps we are not using the Atmel support process correctly?

@atmel

Please could you address this issue. There are numbers of users struggling with 2.6.22.3 ( and some who are not) The fact that the speed of the sd card appears to be critical would explain this difference.

Please could you summarise the problem and make it a "sticky" post in this forum. It would save a lot of heart ache.

thank you

regards

Patrick

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I don't think its necessarily an atmel support issue. I think it may rather be a general kernel issue, but I could be wrong.

Either way, I'm not so sure that we should be so hard on Atmel support, the Linux kernel is a community effort after all. :)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

superpat999 wrote:
I am somewhat disappointed that Atmel folks do not appear to have addressed this issue.
I think they're addressing the issue, it isn't an instant process ;).
superpat999 wrote:
I may be wrong in which case I will apologise in advance, but I have the feeling that often, problems are being resolved by the users and not by Atmel support.
Linux is a very community-oriented kinda thing! If the users get there before the Atmel boys do, more power to em!

A lot of companies which supply Linux for their processors both charge for it and rarely offer recent kernels. Atmel have made the decision to get their arch in to the mainline, keep it bang up-to-date and never charge for it. So you can't get 2.6.22 to work completely, that sucks indeed. But most manufacturers wouldn't give you the option, you'd still be on something years old. Hells, 2.6.10 was released on boxing day 2004 and it's still the defacto standard for embedded Linux systems (especially microkernel systems).

-S.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

superpat999 wrote:
Please could you summarise the problem and make it a "sticky" post in this forum. It would save a lot of heart ache.
Probably better to have a avr32linux.org 'Known Issues and Limitations with Kernel foo' kinda page. Though I agree it should be more placed more conspicuously.

-S.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Also would be a good idea to make a post to the avr32 kernel maillist. As far as I can see from the archives, this issue is unknown to them.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

There's a note about the rootwait parameter at http://avr32linux.org/twiki/bin/... now.

The other issue (i.e. card isn't recognized even when rootwait=1 is specified) is being discussed in this thread:

http://www.avr32linux.org/archiv...

What makes this issue so difficult to resolve is that it only happens with some cards and the problem goes away when a printk is added pretty much anywhere in the mmc code.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

A possible fix was just posted:

http://www.avr32linux.org/archiv...

Could you give it a try?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi, how

I applied the patch to my boards and stk1000.
But, it helps to improve the quality, but does not solve
the problem.

Test Results:

With SanDisk 128M it works.
Actually SanDisk 128M sometimes works on stk1000
without this patch, but with this patch looks working well.
But, I tried only 10 times.

With SanDisk Ultra II 1G does not work.

Even if I increase the mmc_delay time to 20ms, but no difference.

Thanks,

James

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi,

any news on this topic?

I have to use a 512MB SDCard with extended temperature range (-40deg .. +70deg).

I have tried all presented solutions, but unfortunatelly this card is not working at all.

Another Sandisk 512MB SDCard is working with MMC debugging enabled.

To make everything a bit slower, I have tried to reduce the CPU MCLK to 100MHz.
Curiously not even the Sandisk card is working then ...

Has somebody found a solution that works for all cards?

Gerhard