Kernel 3.4.79 with initramfs (initrd) doesn't recognize/boot SD card

[dudo]

Hi there.

After compiling latest version of 3.4.79 linux-sunxi kernel, branch sunxi-3.4, and using it with initramfs (initrd) image, my A13-OLinuXino board can't boot SD card any more. As if kernel doesn't "recognise" MMC/SD card device. If I remove loading of initrd from boot.scr and tell u-boot to load and boot kernel without initramfs, kernel recognizes MMC/SD card device and continues booting normally. The same procedure was ok with kernel 3.4.67 which booted rootfs normally. Here are some details of my configuration:

• A13-OLinuXino
• kernel 3.4.67 + initramfs boots rootfs ok
• kernel 3.4.79 + initramfs doesn't "recognize" MMC/SD card device, so it doesn't boot rootfs from SD card; when initrd removed from boot.scr, kernel boots rootfs ok
• kernel branch sunxi-3.4
• custom kernel configuration or configuration taken from a13_defconfig, neither boots rootfs; support for MMC and initramfs is included
• u-boot version 2013.10-rc2
• boot.scr built from boot.cmd:
• setenv bootargs console=ttyS0,115200 loglevel=8 root=/dev/mmcblk0p2 rootwait panic=10 ${extra}

  fatload mmc 0 0x46000000 initrd.img

  fatload mmc 0 0x43000000 script.bin

  fatload mmc 0 0x48000000 uImage

  bootm 0x48000000 0x46000000
• kernel messages regarding MMC:
• [    1.359357] [mmc-msg] sw_mci_init

  [    1.362752] [mmc-msg] MMC host used card: 0x1, boot card: 0x0, io_card 0

  [    1.369554] [mmc-err] alloc dma des failed

  [    1.373667] [mmc-err] sunxi-mmc.0: Failed to get resouce.

  [    1.379098] [mmc_pm]: no sdio card used in configuration

I also started sh inside initrd and interactively tried to list /dev/mmcblk0 device with sfdisk -l, but as if there wasn't device at all (but device file was present):

ls /dev/mmcblk0

brw-rw---T 1 0 25 179,0 /dev/mmcblk0

sfdisk -l /dev/mmcblk0

/dev/mmcblk0: No such device or address

sfdisk: cannot open /dev/mmcblk0 for reading

After starting udev, also no MMC device or partitions detected.

All this worked fine with kernel 3.4.67.

Thanks.

[Siarhei Siamashka]

On Fri, 14 Feb 2014 01:54:25 -0800 (PST)
dudo <dgor...@gmail.com> wrote:

> Hi there.
> After compiling latest version of 3.4.79 linux-sunxi kernel, branch
> sunxi-3.4, and using it with initramfs (initrd) image, my A13-OLinuXino
> board can't boot SD card any more. As if kernel doesn't "recognise" MMC/SD
> card device. If I remove loading of initrd from boot.scr and tell u-boot to
> load and boot kernel without initramfs, kernel recognizes MMC/SD card
> device and continues booting normally. The same procedure was ok with
> kernel 3.4.67 which booted rootfs normally. Here are some details of my
> configuration:
>

> - A13-OLinuXino
> -
> - kernel 3.4.67 + initramfs boots rootfs ok
> - kernel 3.4.79 + initramfs doesn't "recognize" MMC/SD card device, so

> it doesn't boot rootfs from SD card; when initrd removed from boot.scr,
> kernel boots rootfs ok

> - kernel branch sunxi-3.4
> - custom kernel configuration or configuration taken from a13_defconfig,

> neither boots rootfs; support for MMC and initramfs is included

> - u-boot version 2013.10-rc2
> - boot.scr built from boot.cmd:
> - setenv bootargs console=ttyS0,115200 loglevel=8 root=/dev/mmcblk0p2

> rootwait panic=10 ${extra}
> fatload mmc 0 0x46000000 initrd.img
> fatload mmc 0 0x43000000 script.bin
> fatload mmc 0 0x48000000 uImage
> bootm 0x48000000 0x46000000

> - kernel messages regarding MMC:
> - [ 1.359357] [mmc-msg] sw_mci_init

> [ 1.362752] [mmc-msg] MMC host used card: 0x1, boot card: 0x0,
> io_card 0
> [ 1.369554] [mmc-err] alloc dma des failed
> [ 1.373667] [mmc-err] sunxi-mmc.0: Failed to get resouce.
> [ 1.379098] [mmc_pm]: no sdio card used in configuration
>
>
> I also started sh inside initrd and interactively tried to list
> /dev/mmcblk0 device with sfdisk -l, but as if there wasn't device at all
> (but device file was present):
> ls /dev/mmcblk0
> brw-rw---T 1 0 25 179,0 /dev/mmcblk0
> sfdisk -l /dev/mmcblk0
> /dev/mmcblk0: No such device or address
> sfdisk: cannot open /dev/mmcblk0 for reading
> After starting udev, also no MMC device or partitions detected.
> All this worked fine with kernel 3.4.67.

There is a universal recipe for this kind of problems - git bisect.

If something used to work before, but does not work any longer, then
it is likely that some commit has caused this. Either by introducing
a bug or by exposing some other latent bug. Identifying this particular
problematic commit can provide a lot of valuable information.

Bisecting is a mechanical work which takes a bit of time, but does not
require any special skills other than being able to compile the kernel
from sources. One can find many guides on the Internet or just read
about it in "man git-bisect".

--
Best regards,
Siarhei Siamashka

[Siarhei Siamashka]

Not sure if dudo has had any progress with bisecting yet. But another
person has reported a somewhat similar problem with 3.4.79 (also
using it with initrd) just a few hours ago:
http://irclog.whitequark.org/linux-sunxi/2014-02-15#6501909;

A quick summary of this investigation. The new kernel now
has CMA enabled by default. CMA is trying to reserve 192MB
of physically contiguous memory between physical addresses
0x43000000 and 0x50000000. Using specifically this address
range is important because CedarX hardware can work only with
the first 256MB of physical DRAM (the base physical address
of DRAM is 0x40000000). Now if initrd is placed by u-boot
somewhere in the middle of this memory area (cutting it into
two halves), then CMA can't reserve physically contiguous
192MB memory block there anymore. So the reservation of
the CMA memory area fails at boot time:
[ 0.000000] cma: CMA: failed to reserve 192 MiB
And then loading of the CedarX kernel module fails later at
runtime too:
[ 7.894415] cedar: failed to allocate memory buffer

Now looking at dodo's logs again, we see that initrd gets
loaded at a problematic address too:

> > fatload mmc 0 0x46000000 initrd.img

And then something related to dma (memory?) allocation fails:

> > [ 1.369554] [mmc-err] alloc dma des failed

The solution for this problem is not to place initrd anywhere
between 0x43000000 and 0x50000000. It might be even a good
idea to introduce a special check in the kernel code for this
problem to log a comprehensive error message and warn the users.

Even with the older kernels, placing initrd into this particular
memory addresses range was not completely safe either. Just the
overlapping with other memory reservations was not checked
strictly enough.

It's good to see that people are taking sunxi 3.4.79 kernel into
use so soon after it got tagged and are now providing feedback.

Thanks!

[dudo]

Unfortunately, currently I don't have time for bisecting.

One thing that I forgot to mention is that I made initrd image with 'mkimage' option '-a 0x45000000', if it means anything to you.

Another thing which I would mention is example from sunxi initial ramdisk wiki:

fatload mmc 0 0x43000000 script.

bin
fatload mmc 0 0x41000000 uImage
fatload mmc 0 0x45000000 uInitrd
bootm 0x41000000 0x45000000

I also tried this example of boot.scr, but with same results as from topic post.

I'm thankful for your bisect advice. On monday I'll try another load address (outside the range you mentioned) for initrd and report result.

Thanks once more for your replies.

[dudo]

I've changed load address of initrd from 0x46000000 to 0x41000000 in boot.scr and now SD cards seems to work ok, it's recognized by kernel as was with older kernel.

I have one (or two) more question regarding those addresses. Which address ranges are legal anyway for u-boot (placed in boot.scr)? As I can see, when uImage and initrd are loaded by u-boot, those are placed at another address location displayed by "Load address:" line of u-boot dump. In my example, boot.scr has addr. for uImage 0x45000000, initrd 0x41000000, but after u-boot loads then, "Load address:" fields are 0x40008000 and 0x45000000 respectively. What are meanings of all those addresses?

Thanks.

[Luc Verhaegen]

> --
> You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.

Please adapt http://linux-sunxi.org/Initial_Ramdisk

Luc Verhaegen.