No mmc in /dev

[aferre]

Hi,

Using your script to build a kernel for beagleboard xm, I end up with a bootable kernel but there is no mmc in /dev

in system.sh I modified those lines:

ARCH=arm
CC=arm-linux-gnueabi-
BUILD_UIMAGE=1

OPTIONAL: ZRELADDR: needed when building uImage's.

For TI: OMAP3/4/AM35xx

ZRELADDR=0x80008000

and the mmc part to point to my sd card

I tried to change the UUID to a LABEL and used rootfs as the label but it didn't help and that's when I checked the devices directory.

[RobertCNelson]

MISSING INFO: branch used of stable-kernel
MISSING INFO: kernel version built of stable-kernel

Hi Adrien,

First... Why did you modify ARCH? Is there something wrong in the logic in system.sh when running the script on a Native arm platform. As on most native platforms the "arm-linux-gnueabi*" prefix is not needed, so we just call gcc

2nd, Please expand on how your actually booting into the OS if your statement "no mmc in /dev/" is actually true. As to actually verify that there is "no mmc in /dev" you kinda have to be in the OS... So unless your OS is on an external USB or NFS mount (this info is kinda very important..) the MMC driver is kind-of actually working..

Regards,

[aferre]

Hi

I modified ARCH because I thought this script was meant to be used on a build system or for people like me who don't fully understand the build system. I am building the kernel on a ubuntu x64 virtual machine so I just put arm in there to enable cross compilation and the cc part to use the arm linux eabi cross compiler

I am not actually booting into the system as it cannot mount the rootfs partition I have on my MMC. But I just understood that from initramfs point of view I am browing through the files on the mmc and not through all devices as I could on the booted system and this is why I don't see the /dev/mmcblk... .

The kernel used is 3.2.33. Git status shows that the branch used is master

[RobertCNelson]

Hi Adrien,

Okay, I'd just never seen anyone do that, so I wondering if there was a bug or something... In that case, leaving "ARCH=$(uname -m)" would have worked fine, as your system would have been detected as "x86_64" therefor it would just use this CC variable ( https://github.com/RobertCNelson/stable-kernel/blob/master/system.sh.sample#L18 )... I'm working on a patchset that uses ARCH fully and auto detects the ubuntu cross compiler, so it's not advisable to change it down the road. ;)

Ah, the "initramfs" I so forgot about that... Yeah that would defiantly give you a busybox shell... Using "https://gist.github.com/ or pastebin.com" can you dump your full serial boot log, there's a couple places mmc can fail in dmesg.... And on your x86 pc, what does "sudo fdisk -l" show for that mmc card?

btw.. in the next few hours, i'm nuking master, so when you do a git pull, v3.2.x will be in a branch (it's already there now, but master still works as of today's git..)

Regards,

[aferre]

You say you haven't seen anyone do this, but don't you have some part of your script mntionning jenkins? Maybe you are running jenkins on arm devices but that would be weird IMHO.

What I usually do in checkout the linux-linaro-precise-3.1.14 kernel and run the following:

make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- uImage
make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- modules
cp arch/arm/boot/uImage /media/boot
sudo cp .config /media/rootfs/boot/config
sudo make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- modules_install INSTALL_MOD_PATH=/media/rootfs
sudo make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- firmware_install INSTALL_FW_PATH=/media/rootfs/lib/firmware
sudo sync

And i end up with a bootable system.

What do you think would be the difference between what you are doing and what I'm used to do?

EDIT/ I am rebuilding the whole thing and I get back to you once I can

[RobertCNelson]

Yes, i have a Jenkins system setup to make sure the scripts never break.. Since I don't have "gcc" detection in place, in "system.sh" it uses this appended to the default "system.sh.sample":

"CC=/opt/gcc/gcc-linaro-arm-linux-gnueabihf-4.7-2012.10-20121022_linux/bin/arm-linux-gnueabihf-"
"AUTO_BUILD=1"

(AUTO_BUILD bypass's menuconfig, to make it fully automatic..)

Kernel-
Yeah Really no difference ( https://github.com/RobertCNelson/stable-kernel/blob/master/build_kernel.sh )

Please provide your boot log and any changes you made to the defconfig, as even thou i no longer support v3.2.x on the xM, it's been working fine on my Beagle C4/Beagle xM for atleast a half year..

Regards,

[aferre]

Here are the steps I use:

I use the pre built image for beagle xm availble from linaro (12.02 release)

Then I use the linux-linaro-precise kernel and build it using the config availbale on the pre built image et dump the new kernel using the steps I described above.

I now have a working beagle with the 3.1.5 kernel.

I use your script with the following configuration

CC=arm-linux-gnueabi-c
BUILD_UIMAGE=1
ZRELADDR=0x80008000
MMC=/dev/sdb

after this kernel upgrade I end up with the following boot message:

not recongized flattened tree or something and I have to make the omap3-beagle.dtb file

When pushing this new file I get some boot info:

https://gist.github.com/4087973

But as you can see I never have the mmc drivers being loaded

Note: I didn't change anything on the config file provided on the repo.

EDIT: for the jenkins part: ok I get it. Is it on a x86 x64 or arm device?

[RobertCNelson]

Ah, Device tree's...

Flattened Device Tree blob at 815f0000

Booting using the fdt blob at 0x815f0000
Loading Kernel Image ... OK
OK

Yeah, your on your own too make that work with v3.2.x... Just because Linaro has it in v3.1.x does not mean we have it in mainline.. Based on patches for the v3.8 merge, we "MAY" enable it by default for Panda in v3.8.x... AKA no chance in my v3.2.x branch...

I'd suggest you try my demo image on a spare sd card, just to verify the MMC interface works:

http://elinux.org/BeagleBoardUbuntu#Demo_Image

Jenkins -
It's setup to test i don't break anything and test kernel/u-boot
http://rcn-ee.homeip.net:8080/

Regards,

[aferre]

Ok thanks I'll try.

BTW what do you use in mainline (and what does mainline mean? is it the main repository for the kernel sources because all other repos are derived from it?) instead of the device tree?

EDIT: I see that you have a patch for the PLL that I saw when browsing through google groups when searching for usb/eth crashs. Does that really help? We currently have a dozen of bbxm boards running the environment I described above and we have several crashes each week!

[RobertCNelson]

Mainline is http://kernel.org/ ;)

So, Linus Torvalds repo: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=summary
and Greg's Stable repo: http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary

As long it's not actually the "kevent" error, the PLL fix should fix those xM boards.. I don't have one that needs it..

[aferre]

Ok so the 12.10 armhf pre built image boots fine! BTW what is this minimal system? Does it mean it only has a console as would a server distribution or has it some kind of user interface?

I'll try to go from there and dump the kernel.

WTH! I may not have to recompile after all. I see that you ship your image with ftdi support, ttyACM support, ppp support...
You are making my work much simplier.

Ah but I don't see any spi device.

[RobertCNelson]

Hi Adrien,

The "minimal" name has kind of lost it's meaning over the few years I've been doing it.. At first it was very minimal and i did have an xfce4 image to go along with it.. Now it's just a console image with almost everything essential to just connect to the internet. So beyond that is pretty easy to install almost anything..

For spi, open up the uEnv.txt file in the boot partition and change the buddy=${buddy} to buddy=spidev and it'll enable almost every spi interface. ;)

Regards,

[aferre]

Thanks for you input and your help. I love that you made my work much more efficient.

Are you the maintainer of the elinux website?

[RobertCNelson]

I maintain a few pages on elinux related to Debian/Ubuntu on the Beagle's.. Although at times, the github stuff is a little ahead of the elinux pages.. ;)

[aferre]

Ok. Well thanks for everything.

I noticed on a fewe forums that you are very active regarding the USB issues the beagleboards xm have. You even seem to provide a fix and it seems to me that your pre built image has the fix for the PLL but I still encounter the problem on a dozen boards.