No mmc in /dev - Githubissues

aferre commented 11 years ago

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 commented 11 years ago

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 commented 11 years ago

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 commented 11 years ago

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 commented 11 years ago

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 commented 11 years ago

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 commented 11 years ago

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 commented 11 years ago

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 commented 11 years ago

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 commented 11 years ago

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 commented 11 years ago

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 commented 11 years ago

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 commented 11 years ago

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 commented 11 years ago

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 commented 11 years ago

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.

RobertCNelson commented 11 years ago

The patch was actually written by someone else... They have since disappeared from the community. The patch can not be enabled by default as it breaks older omap34xx based hardware (they don't boot).. My collection of xM's do not suffer from the issue.. There's a thread on linux-omap/beagleboard, but "NO ONE" with the issues followed up with Paul's questions, from Feb 24th or July 12th: https://groups.google.com/forum/#!topic/beagleboard/m7DLkYMKNkg

Regards,

aferre commented 11 years ago

Yes I saw this post. I'd love to help on this matter but my main problem is that the problem isn't reproductable. Do you have some kind of test scenario?

RobertCNelson commented 11 years ago

The usual suspect is:

[ 2233.088470] hub 1-0:1.0: port 2 disabled by hub (EMI?), re-enabling... [ 2233.098937] usb 1-2: USB disconnect, device number 2 [ 2233.098968] usb 1-2.1: USB disconnect, device number 3 [ 2233.099456] smsc95xx 1-2.1:1.0: eth0: unregister 'smsc95xx' usb-ehci-omap.0-2.1, smsc95xx USB 2.0 Ethernet [ 2233.909301] usb 1-2.3: USB disconnect, device number 4

after running fine for a few minutes/hours...

With the 4 random generations of xM boards i have, it's not reproducible by me...

aferre commented 11 years ago

I never had this error. Usually I have an error like khubd disconnects. If I encounter it again I'll paste it.

Le 05/12/2012 15:31, Robert Nelson a écrit :

The usual suspect is:

[ 2233.088470] hub 1-0:1.0: port 2 disabled by hub (EMI?), re-enabling... [ 2233.098937] usb 1-2: USB disconnect, device number 2 [ 2233.098968] usb 1-2.1: USB disconnect, device number 3 [ 2233.099456] smsc95xx 1-2.1:1.0: eth0: unregister 'smsc95xx' usb-ehci-omap.0-2.1, smsc95xx USB 2.0 Ethernet [ 2233.909301] usb 1-2.3: USB disconnect, device number 4

after running fine for a few minutes/hours...

With the 4 random generations of xM boards i have, it's not reproducible by me...

— Reply to this email directly or view it on GitHub https://github.com/RobertCNelson/stable-kernel/issues/19#issuecomment-11043213.

aferre commented 11 years ago

Do you have a special option to pass to the kernel to enable UART2 on beagle/panda boards like you do for spidev?

RobertCNelson commented 11 years ago

I've looked at enabling with buddy=spidev..

http://beagleboard.org/static/BB-xM_REV_C-2011-05-23.zip AE5 (uart2_rx) AA25 (uart2_tx)

The pinmux is setup similar to this: (but the appropriate pins) https://github.com/RobertCNelson/stable-kernel/blob/v3.7.x/patches/omap_beagle_expansion/0010-Beagle-expansion-add-LSR-COM6L-Adapter-Board.patch#L63

Do you have the tx/rx lines connected to something right now, as i could push a test patch and have you test it..

Regards,

aferre commented 11 years ago

I could wire them together to test in situ. Could your patch enable rts and cts as well?

Le 12/12/2012 16:37, Robert Nelson a écrit :

I've looked at enabling with buddy=spidev..

http://beagleboard.org/static/BB-xM_REV_C-2011-05-23.zip AE5 (uart2_rx) AA25 (uart2_tx)

The pinmux is setup similar to this: (but the appropriate pins) https://github.com/RobertCNelson/stable-kernel/blob/v3.7.x/patches/omap_beagle_expansion/0010-Beagle-expansion-add-LSR-COM6L-Adapter-Board.patch#L63

Do you have the tx/rx lines connected to something right now, as i could push a test patch and have you test it..

Regards,

— Reply to this email directly or view it on GitHub https://github.com/RobertCNelson/stable-kernel/issues/19#issuecomment-11293663.

RobertCNelson commented 11 years ago

Please test, the v3.7.x branch: and enable this patch:

https://github.com/RobertCNelson/stable-kernel/blob/v3.7.x/patch.sh#L277

Please test with an active serial connection over the expansion pins with a usb device plugged in.. ;)

aferre commented 11 years ago

The uart2 seems to be enabled by default (demo image ubuntu-12.10-r2-minimal-armhf-2012-11-29 i.e. kernel 3.6.8-x4). We will test in the afternoon if the RTS and CTS pins are also correctly set at boot, if not I'll try to use your patch. You pointed me to the patch with spidev, buyt isn't the patch supposed to be 0011-WIP-Beagle-expansion-extend-spidev-to-uart2.patch ?

From what I can tell, your patch seems to enable the uart2 if I use "spidev", but it enables spidev as well.

Would like me to try and push a patch to enable UARTx or spidev using something like "uart2", "uart1", ...?

RobertCNelson commented 11 years ago

The "uart2" that enabled by default is actually "uart3/ttyO2".. The TI pin name to Kernel uart number is one off..

Yes, after sending you that message, i ended adding another patch, which make the link invalid.. just enable "0011-WIP-Beagle-expansion-extend-spidev-to-uart2.patch"

Yes, that's the whole point.. use "buddy=spidev" you will have two spi ports and usart..

No..

aferre commented 11 years ago

Hmm then I meant UART2 from the beagle's (spec) point of view. I end up using the /dev/ttyO1 device so from the system point of view it's omap_uart.1 or OMAP UART1. AFAIK the uart ttyO2 is the console! Your patch targets omap_uart.2 so it will enable the console which should already be enabled.

Le 13/12/2012 14:55, Robert Nelson a écrit :

The "uart2" that enabled by default is actually "uart3/ttyO2".. The TI pin name to Kernel uart number is one off..

Yes, after sending you that message, i ended adding another patch, which make the link invalid.. just enable "0011-WIP-Beagle-expansion-extend-spidev-to-uart2.patch"

Yes, that's the whole point.. use "buddy=spidev" you will have two spi ports and usart..

No..

— Reply to this email directly or view it on GitHub https://github.com/RobertCNelson/stable-kernel/issues/19#issuecomment-11335062.

RobertCNelson commented 11 years ago

Nope, look again... uart3 is wired to the serial port which is the console /dev/ttyO2...

uart2 -> /dev/ttyO1...

aferre commented 11 years ago

This is the ouput of dmesg:

[ 0.802124] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled [ 0.803833] omap_uart.0: ttyO0 at MMIO 0x4806a000 (irq = 72) is a OMAP UART0 [ 0.804351] omap_uart.1: ttyO1 at MMIO 0x4806c000 (irq = 73) is a OMAP UART1 [ 0.804840] omap_uart.2: ttyO2 at MMIO 0x49020000 (irq = 74) is a OMAP UART2 [ 1.652465] console [ttyO2] enabled [ 1.656768] omap_uart.3: ttyO3 at MMIO 0x49042000 (irq = 80) is a OMAP UART3

UART3 is indeed wired to the console but we are talking about the UART3 mentionned in the beagle specs which is the UART2 is in the above logs right? Like you said, the UARTy on the system are named like UART(y-1) on beagle specs i.e

UART2 on beagle specs = UART(2-1) on system

Le 13/12/2012 15:06, Robert Nelson a écrit :

Nope, look again... uart3 is wired to the serial port which is the console /dev/ttyO2...

uart2 -> /dev/ttyO1...

— Reply to this email directly or view it on GitHub https://github.com/RobertCNelson/stable-kernel/issues/19#issuecomment-11335399.

RobertCNelson commented 11 years ago

So, back to the original question:

Using "/dev/ttyO1" can you successfully connect to a device connected on the expansion bus?

The kernel on the omap3630 always sets up all 4 uarts, but it doesn't setup the pinmux on the other 3.. This patch enables the pin mux for uart2/dev/ttyO1

Regards,

aferre commented 11 years ago

Using /dev/ttyO1, without rebuilding the kernel for the demo image i mentionned, I end up with a working serial port (which was not the case in previous linaro demo images, typically the 11.11 or 12.11 releases). We are currently soldering a breadboard so that we can use the RTS/CTS pins.

First test was to wire pin 6 & pin 8 together on the expansion port, second test was to use a xbee module whitout RST CTS, and we will use RTS CTS pins afterwards.

Le 13/12/2012 16:56, Robert Nelson a écrit :

So, back to the original question:

Using "/dev/ttyO1" can you successfully connect to a device connected on the expansion bus?

The kernel on the omap3630 always sets up all 4 uarts, but it doesn't setup the pinmux on the other 3.. This patch enables the pin mux for uart2/dev/ttyO1

Regards,

— Reply to this email directly or view it on GitHub https://github.com/RobertCNelson/stable-kernel/issues/19#issuecomment-11339547.

RobertCNelson commented 11 years ago

I'm not involved with Linaro. ;) So who knows that they did in those images. ;)

aferre commented 11 years ago

We were finally able to test ith the patch you provided but it doesn't seeme to enable the RTS/CTS pins.

From what I can see/understand on eLinux.og (http://elinux.org/BeagleBoardPinMux#UART2) it seems that the modes set on the pins are wrong when the system is booted.

So I started searching through the 4000 pages of the TI TRM and I didn't find anything new (I don't even know if I am looking at the good tables in the document).

Next I went back to BB xm documentation, and it states that UART2_RTS mode 0 UART2_CTS mode 0 UART2_RX mode 1 UART2_TX mode 0

so the mode don't seem to match for the working rx pin (i guess this what everyone is talking about when they say that the bbxm documentation is out of date) but the other modes/pin states seem ok.

I then removed the buddy=spidev argument for the kernel and I end up with the same exact configuration for those pins (exept for uart2_cts which is in INPUT_PULLUP mode):

Last time I did this was by modifying u boot instead of muxing with the kernel so I have to say I am a little lost with the new way of setting those pins.

Do the modes seem right to you?

YaderForero commented 11 years ago

I would like to know how to enable UART2 for an application and I see that talk about applying the patch but do not know how I'm no expert

RobertCNelson / stable-kernel

No mmc in /dev #19

OPTIONAL: ZRELADDR: needed when building uImage's.

For TI: OMAP3/4/AM35xx

Flattened Device Tree blob at 815f0000