I've walked through building with LTIB using L3.0.35_4.1.0_130816 source and images.
I installed everything to SD card as per instructions in SABRE-SD users' guide.
At powerup uboot runs as expected, it pulls the kernel of the SD card and then the
kernel attempts to access the file system and things fail...
....
EXT3-fs: barriers not enabled
kjournald starting. Commit interval 5 seconds
EXT3-fs (mmcblk1p1): using internal journal
EXT3-fs (mmcblk1p1): recovery complete
EXT3-fs (mmcblk1p1): mounted filesystem with writeback data mode
VFS: Mounted root (ext3 filesystem) on device 179:25.
Freeing init memory: 200K
modprobe: FATAL: Could not load /lib/modules/3.0.35-2027-g0596856/modules.dep: No such file or directory
mount: mount point /lib/init/rw is not a directory
mountall: mount /lib/init/rw [3937] terminated with status 32
mountall: Filesystem could not be mounted: /lib/init/rw
I remove the sd card and look at the contents on a real linux box and the /lib/modules/3.0.35-2027-g0596856 does not exist. The dir on my sd card (as created from oneiric.tgz) is 3.0.35-2666-gbdde708. Any idea what I'm doing wrong?
Well, I'm back to square one apparently...
As a self-check, I decided to take a step back to make sure what I thought I knew was correct...
Starting with a raw SD card, I *thought* I should be able to simply install the uboot image at block #2 and the board would boot uboot.
I can't even get that to work now (using multiple SD-cards). Using:
sudo dd if=u-boot-mx6q-sabresd.bin of=/dev/sdb bs=512 seek=2 conv=fsync
(tried with and without 'skip=2') does not give me a bootable SD card.
What's even more interesting is that when I read the SD card that does boot, the data doesn't resemble uboot at all.
That makes no sense to me so obviously I'm either thinking wrong or just doing something stupid and haven't realized
it yet (probably the latter).
Anyway, I guess my question is:
should the above 'dd' command create a valid/bootable SD card (assuming of course that the .bin file is valid)?
If I read back the raw data on the sd card using
sudo dd if=/dev/sdb of=/tmp/image bs=512 count=1024 conv=fsync
shouldn't I see stuff that looks like the binary equivalent of u-boot's flash_header.S file?
Ed
Are you building a u-boot suitable for your board? Just make sure you are selecting the correct board on the u-boot option on the main LTIB menu. Also, AFAIK the 'skip=2' is necessary.
I can use imx_usb tool to boot the image through the serial downloader, so I assume that means its good-to-go.
Bottom line... shouldn't I be able to use the 'dd' command on linux to copy the first 1024 blocks from a bootable SD card onto a second SD card and at least see u-boot start up? I don't even see that.
Ed, here is how I compile mainline u-boot and boot it off of SD :
make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- distclean
make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- mx6qsabresd_config
make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- all
sudo dd if=u-boot.imx of=/dev/sdb seek=1 bs=1k
Note the seek or the skip as Leonardo also pointed out.
Hope this helps
Sinan Akman
That's almost exactly what I'm doing, but I don't have a u-boot.imx file, I've been loading the
u-boot.bin. What is the .imx file?
The only other difference is that I use a blocksize of 512, so I use "seek=2"...
sudo dd if=u-boot.bin of=/dev/sdd1 seek=2 bs=512 conv=fsync
I assume the "seek=2" is so that the write doesn't clobber the partition table on the SD card. Not quite sure about the "skip=2". The docs talk about a "non-padded" boot image; I assume they are referring to the 0x400 byte offset of the ivt_header (in flash_header.S). My u-boot.bin file includes those initial 0x400 bytes, so does that mean its padded?? I haven't read anything in any of the docs that states where the internal bootloader starts reading from on the SD card, so I just tried it with and without the "skip=2". Unfortunately neither works.
The strange thing is this:
I have one SD card that does boot u-boot. When I read that card's image into a file using my Linux host and an SD-card reader, I DON'T see what I think I should see. Shouldn't I see the u-boot.bin image near the base of that file?
I'm starting to think I have a few bad SD cards, but then they work just fine on my Linux host.
AHHH!!! Just realized what I have been doing wrong...
I was using /dev/sdd1 instead of /dev/sdd, so I wasn't reading/writing relative to the base of the device.
MORON!!!
I had changed from a single-card reader to a multi-card reader midstream the other day (minor detail I didn't mention) and the device name changed. Things are immediately back to sanity again...
Thanks for the suggestions.
Hi Ed, I am glad you were able to solve the problem. Don't feel too bad for the oversight, we all have been there this way or another :smileywink:
Thanks
Sinan Akman
Hi Ed,
As Sinan has mentioned, the kernel's release string must match
$ ls /lib/modules/
3.0.35-2666-gbdde708
root@freescale ~$ uname -r
3.0.35-2666-gbdde708
root@freescale ~$
As a workaround, try renaming your module folder matching the kernel release string. 'root' is the login, no password for any LTIB demo image.
Leo
Hi Ed, did you generate the rootfs and the kernel using LTIB. It is possible that you compiled a kernel with modules but used an older rootfs that didn't have modules installed.
Sinan, thanks for the quick reply...
I built following the instructions in the user's guide: "i.MX 6Dual/6Quad SABRE-SD Linux User's Guide", and I am suspicious of having a mismatch between kernel and fs. I built rootfs on the SD card using the downloaded oneiric.tgz; so maybe that was the wrong step?
Thanks in advance...
Hmmm... maybe I was supposed to use rootfs.ext2.gz... I'll give that a try.
Ed, can you loop mount that rootfs.ext2.gz and see if it has modules in it.
better yet, I just installed it onto my SD card and tried it... It now boots (I get a login prompt); however that leaves me with two questions:
1. what is the login/password (linaro/linaro doesn't work)?
2. what is the point of step #2 of section 3.8 of the user's guide which appears to give instructions to overwrite the rootfs.ext2 (that was just installed by step #1) with oneiric.tgz?
Hi Ed, I would think the login would be root or admin and no password but I never used TLIB so I am sorry I don't really know what it generates. Likewise, I think the UG you are referring is about using LTIB. I usually compile the mainline kernel and build a small rootfs manually.
That did it! Duh, didn't even think to try "root". I tried admin/admin, etc...
Anyway for anyone trying to build a rootfs for installation onto an SD card for the SABRE
board for smart devices, don't use oneiric.tgz (as outlined in section 3.8) just go directly to
chapter 8 of the users guide. The steps in section 3.8 "How To Set Up Ubuntu Rootfs" are
just confusing (and apparently wrong).
The file that is used to create the rootfs is rootfs.ext2.gz.
I am glad that worked. I have a sabresd board where I can compile mainline kernel with own rootfs. If you like to have a non-LTIB way to build mainline kernel and a min rootfs, let me know.
Sinan,
Yea, I would be interested. I know there are plenty of different paths to take here. LTIB appears to be the path most supported by Freescale; however it does appear to be a bit bulky.
Ed
Hi Ed, let me know what would you need in particular. I have an sabresd board here that I am running a kernel and rootfs not generated with LTIB. If you like I could send you the rootfs or better yet I can document the simple steps to produce mainline kernel and a minimum rootfs but it may take some days. Until then let me know if you need anything specific.
Thanks
Sinan Akman
Sinan,
Thanks much for the offer; I still need to figure out what route to take here. Seems like a lot of options (LTIB, Yocto, Linaro, Buildroot, custom, ...). The LTIB stuff basically came right up; however, based on what I read Yocto is the way to go. Any thoughts on that?
Ed