Hi there,
In the past couple of days, I have been trying to make Fedora 21 boot in a BeagleBoard-xM Rev C. Unfortunately, this doesn't work out of the box as I expected, and I had to do many tweaks to the documented procedure:
https://fedoraproject.org/wiki/Architectures/ARM/F21/Installation
FWIW, I am using the Minimal Fedora image for this.
Well, the first thing I tried was following the exact instructions for a BeagleBone:
But, as I said, this did not work. I found that BeagleBoard-xM expects the first partition to be a FAT one, and the image provided by Fedora has an ext* partition. OK, so I manually created an SDCard with a FAT partition as the first one (where the u-boot files + the Linux kernel stay), and then the rest of the partitions are the ones that you find in the original image. It worked, in the sense that I could turn on the board and see something in the serial. However, more problems ahead...
The second problem was about "catX" not being defined. It is actually defined in boot.cmd, but due to some bugs in the u-boot version that is being used, it is not recongnized. I found this message about the subject:
https://lists.gnu.org/archive/html/qemu-devel/2014-10/msg03127.html
[It feels strange that nobody noticed/experienced this problem before; I hope I'm not doing anything wrong...]
Anyway, after struggling a lot with this, I decided to give up the original boot.cmd and write very simple boot.cmd + uEnv.txt files, just for the board that I have. The contents are:
boot.cmd: http://paste.fedoraproject.org/191836/16762614/
uEnv.txt: http://paste.fedoraproject.org/191837/14251676/
Those were obviously made using the definitions found in the original boot.cmd file. With them, the board can finally (and apparently) load the Linux kernel + the initrd + the dtb files from the SDCard, but I still can't make it to boot; it freezes after the "Starting kernel ..." message, all the lights turn on, and nothing else happens.. Here is what I see now:
http://fpaste.org/191831/25164279/
It seems to me that I have made some mistake somewhere (offsets? files to load? u-boot commands?), but I can't find it. I was at least expecting to see the "decompressing kernel" message, but nothing... And adding earlyprintk in the bootargs doesn't tell anything either.
So, I'm kind of running out of ideas on how to solve this, and I want to get everything working until Monday. Does anyone know what can be wrong, or point me to some documentation that I can use to boot Fedora 21 on this BeagleBoard-xM?
Thanks a lot,
I'm booting F21 LXDE successfully on Beagleboard xM rev B. Different DTB but the rest should be the same. Comparing mine to yours you may be loading the kernel at the wrong address. I'm not really using the boot.scr.
More info here including my uEnv.txt: https://lists.fedoraproject.org/pipermail/arm/2015-January/008901.html
On 2/28/15 10:22 PM, Sergio Durigan Junior wrote:
Hi there,
In the past couple of days, I have been trying to make Fedora 21 boot in a BeagleBoard-xM Rev C. Unfortunately, this doesn't work out of the box as I expected, and I had to do many tweaks to the documented procedure:
https://fedoraproject.org/wiki/Architectures/ARM/F21/Installation
FWIW, I am using the Minimal Fedora image for this.
Well, the first thing I tried was following the exact instructions for a BeagleBone:
But, as I said, this did not work. I found that BeagleBoard-xM expects the first partition to be a FAT one, and the image provided by Fedora has an ext* partition. OK, so I manually created an SDCard with a FAT partition as the first one (where the u-boot files + the Linux kernel stay), and then the rest of the partitions are the ones that you find in the original image. It worked, in the sense that I could turn on the board and see something in the serial. However, more problems ahead...
The second problem was about "catX" not being defined. It is actually defined in boot.cmd, but due to some bugs in the u-boot version that is being used, it is not recongnized. I found this message about the subject:
https://lists.gnu.org/archive/html/qemu-devel/2014-10/msg03127.html
[It feels strange that nobody noticed/experienced this problem before; I hope I'm not doing anything wrong...]
Anyway, after struggling a lot with this, I decided to give up the original boot.cmd and write very simple boot.cmd + uEnv.txt files, just for the board that I have. The contents are:
boot.cmd: http://paste.fedoraproject.org/191836/16762614/
uEnv.txt: http://paste.fedoraproject.org/191837/14251676/
Those were obviously made using the definitions found in the original boot.cmd file. With them, the board can finally (and apparently) load the Linux kernel + the initrd + the dtb files from the SDCard, but I still can't make it to boot; it freezes after the "Starting kernel ..." message, all the lights turn on, and nothing else happens.. Here is what I see now:
http://fpaste.org/191831/25164279/
It seems to me that I have made some mistake somewhere (offsets? files to load? u-boot commands?), but I can't find it. I was at least expecting to see the "decompressing kernel" message, but nothing... And adding earlyprintk in the bootargs doesn't tell anything either.
So, I'm kind of running out of ideas on how to solve this, and I want to get everything working until Monday. Does anyone know what can be wrong, or point me to some documentation that I can use to boot Fedora 21 on this BeagleBoard-xM?
Thanks a lot,
On Saturday, February 28 2015, Scott M. Jones wrote:
I'm booting F21 LXDE successfully on Beagleboard xM rev B. Different DTB but the rest should be the same. Comparing mine to yours you may be loading the kernel at the wrong address. I'm not really using the boot.scr.
More info here including my uEnv.txt: https://lists.fedoraproject.org/pipermail/arm/2015-January/008901.html
Thanks for the reply, Scott. Actually, your post was one of the first ones I saw, and apparently I should have paid more attention to it :-).
Well, I don't think the problem is loading the Linux kernel at the wrong address, but rather using the wrong dtb file. I was using omap3-beagle-xm.dtb, but when I replaced that by omap3-beagle-xm-ab.dtb, at least I got the kernel to boot. I am not really sure the -ab version fully works with rev C, but that's the best I've gotten now, apparently.
*However*, that did not really solve everything for me, because now I am seeing errors during the boot, and I can't get the boot to complete. Here's the full log:
http://fpaste.org/191874/51860941/
The real problem is getting the root right here, I think (although I also don't think the error messages are good too). I check the UUID of the partition and it's all good; I also tried using the LABEL=_/ value in the root= parameter, but it didn't work also.
Ideas here? Thanks,
I would have thought the first .dtb you were using was the correct one for you. I'm surprised the LABEL=_/ option doesn't work. Maybe run blkid and double check the UUID? Can you post the partition table? I only see p1 - p3.
On Mar 1, 2015, at 12:12 AM, Sergio Durigan Junior sergiodj@sergiodj.net wrote:
On Saturday, February 28 2015, Scott M. Jones wrote:
I'm booting F21 LXDE successfully on Beagleboard xM rev B. Different DTB but the rest should be the same. Comparing mine to yours you may be loading the kernel at the wrong address. I'm not really using the boot.scr.
More info here including my uEnv.txt: https://lists.fedoraproject.org/pipermail/arm/2015-January/008901.html
Thanks for the reply, Scott. Actually, your post was one of the first ones I saw, and apparently I should have paid more attention to it :-).
Well, I don't think the problem is loading the Linux kernel at the wrong address, but rather using the wrong dtb file. I was using omap3-beagle-xm.dtb, but when I replaced that by omap3-beagle-xm-ab.dtb, at least I got the kernel to boot. I am not really sure the -ab version fully works with rev C, but that's the best I've gotten now, apparently.
*However*, that did not really solve everything for me, because now I am seeing errors during the boot, and I can't get the boot to complete. Here's the full log:
http://fpaste.org/191874/51860941/
The real problem is getting the root right here, I think (although I also don't think the error messages are good too). I check the UUID of the partition and it's all good; I also tried using the LABEL=_/ value in the root= parameter, but it didn't work also.
Ideas here? Thanks,
-- Sergio GPG key ID: 0x65FC5E36 Please send encrypted e-mail if possible http://sergiodj.net/
On Sunday, March 01 2015, Scott M. Jones wrote:
I would have thought the first .dtb you were using was the correct one for you.
Yeah, me too. That's why I wasn't even bothering trying the -ab one.
I'm surprised the LABEL=_/ option doesn't work. Maybe run blkid and double check the UUID? Can you post the partition table? I only see p1 - p3.
I already double-checked (or triple-checked now :-) the UUID; everything's fine.
The partition table is:
Disk /dev/mmcblk0: 14.9 GiB, 16021192704 bytes, 31291392 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: dos Disk identifier: 0x00000000
Device Boot Start End Sectors Size Id Type /dev/mmcblk0p1 * 2048 1001471 999424 488M 6 FAT16 /dev/mmcblk0p2 1001472 1251327 249856 122M 83 Linux /dev/mmcblk0p3 1251328 3985407 2734080 1.3G 83 Linux
Nothing really fancy. The first partition contains the u-boot + MLO + the Linux kernel files. The other ones are exactly the last two partitions in the original image.
I ran into a problem where the kernel needs to load a vfat module in order to read /boot but the module is on /boot, so it goes to emergency mode. So you need to create a separate vfat partition for MLO and u-boot.img and leave /boot as ext. Make the vfat partition p1 and turn on the bootable flag. (Or else recompile the kernel with vfat built in, not a module.)
On Mar 1, 2015, at 2:30 AM, Sergio Durigan Junior sergiodj@sergiodj.net wrote:
On Sunday, March 01 2015, Scott M. Jones wrote:
I would have thought the first .dtb you were using was the correct one for you.
Yeah, me too. That's why I wasn't even bothering trying the -ab one.
I'm surprised the LABEL=_/ option doesn't work. Maybe run blkid and double check the UUID? Can you post the partition table? I only see p1 - p3.
I already double-checked (or triple-checked now :-) the UUID; everything's fine.
The partition table is:
Disk /dev/mmcblk0: 14.9 GiB, 16021192704 bytes, 31291392 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: dos Disk identifier: 0x00000000
Device Boot Start End Sectors Size Id Type /dev/mmcblk0p1 * 2048 1001471 999424 488M 6 FAT16 /dev/mmcblk0p2 1001472 1251327 249856 122M 83 Linux /dev/mmcblk0p3 1251328 3985407 2734080 1.3G 83 Linux
Nothing really fancy. The first partition contains the u-boot + MLO + the Linux kernel files. The other ones are exactly the last two partitions in the original image.
-- Sergio GPG key ID: 0x65FC5E36 Please send encrypted e-mail if possible http://sergiodj.net/
On Sat, Feb 28, 2015 at 11:12 PM, Sergio Durigan Junior sergiodj@sergiodj.net wrote:
On Saturday, February 28 2015, Scott M. Jones wrote:
I'm booting F21 LXDE successfully on Beagleboard xM rev B. Different DTB but the rest should be the same. Comparing mine to yours you may be loading the kernel at the wrong address. I'm not really using the boot.scr.
More info here including my uEnv.txt: https://lists.fedoraproject.org/pipermail/arm/2015-January/008901.html
Thanks for the reply, Scott. Actually, your post was one of the first ones I saw, and apparently I should have paid more attention to it :-).
Well, I don't think the problem is loading the Linux kernel at the wrong address, but rather using the wrong dtb file. I was using omap3-beagle-xm.dtb, but when I replaced that by omap3-beagle-xm-ab.dtb, at least I got the kernel to boot. I am not really sure the -ab version fully works with rev C, but that's the best I've gotten now, apparently.
the "-ab" just inverts the signal enabling the usb hub.
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/ar...
So running the "-ab" on the "c" just disables the usb hub..
Regards,
On Sunday, March 01 2015, Scott M. Jones wrote:
I ran into a problem where the kernel needs to load a vfat module in order to read /boot but the module is on /boot, so it goes to emergency mode. So you need to create a separate vfat partition for MLO and u-boot.img and leave /boot as ext. Make the vfat partition p1 and turn on the bootable flag. (Or else recompile the kernel with vfat built in, not a module.)
Thanks, I tried that but I couldn't even boot my system anymore (i.e., the board wouldn't find the u-boot image). Now, I am trying to get back to the state I was before.
Indeed you are right, Linux is compiled with FAT support as a module. I will keep trying to generate a SDCard with a /boot partition that is not FAT.
Any ideas? BTW, I'm not doing any dd command to store the u-boot/MLO files at certain positions in the partition; instead, I'm just copying the files into the FAT partition.
On Sunday, March 01 2015, Scott M. Jones wrote:
I ran into a problem where the kernel needs to load a vfat module in order to read /boot but the module is on /boot, so it goes to emergency mode. So you need to create a separate vfat partition for MLO and u-boot.img and leave /boot as ext. Make the vfat partition p1 and turn on the bootable flag. (Or else recompile the kernel with vfat built in, not a module.)
So, after spending a lot of time struggling with this, I finally managed to go back to where I was before: i.e., booting, but not able to mount the rootfs.
Here's how my SDCard looks now:
Disk /dev/mmcblk0: 14.9 GiB, 16021192704 bytes, 31291392 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: dos Disk identifier: 0x00000000
Device Boot Start End Sectors Size Id Type /dev/mmcblk0p1 * 63 144584 144522 70.6M c W95 FAT32 (LBA) /dev/mmcblk0p2 145408 1144831 999424 488M 83 Linux /dev/mmcblk0p3 1144832 1394687 249856 122M 82 Linux swap / Solaris /dev/mmcblk0p4 1394688 4128767 2734080 1.3G 83 Linux
In order to finally get a "working" system, I used Arch[GNU/]Linux's scripts/u-boot/MLO found at http://archlinuxarm.org/platforms/armv7/ti/beagleboard-xm. I don't know why, but I couldn't make the Fedora ones work with this setup...
Anyway, as I said, I'm back to a non-functional system (that, at least, shows me errors when booting Linux). It is still unable to find my root file system by LABEL or UUID, and it still shows me *lots* of errors/warnings when booting Linux.
My question now is: does Fedora 21 really work on a BeagleBoard-xM rev C? I'm starting to believe it doesn't (or that my board is somehow problematic/broken).
Any more ideas? BTW, the uEnv.txt file that I am using is:
mmcargs=setenv bootargs console=ttyO2,115200n8 root=LABEL=_/ ro rootwait cgroup_disable=memory fixrtc earlyprintk
mmcload=ext2load mmc 0:2 0x80000000 uInitrd-3.17.4-301.fc21.armv7hl; ext2load mmc 0:2 0x88000000 dtb-3.17.4-301.fc21.armv7hl/omap3-beagle-xm-ab.dtb; ext2load mmc 0:2 0x88080000 vmlinuz-3.17.4-301.fc21.armv7hl
uenvcmd=run mmcload; run mmcargs; bootz 0x88080000 0x80000000 0x88000000
And I am not using boot.cmd/boot.scr anymore.
Thanks,
Can you try root=/dev/mmcblk0p4 in the boot args?
On Mar 2, 2015, at 2:18 AM, Sergio Durigan Junior sergiodj@sergiodj.net wrote:
On Sunday, March 01 2015, Scott M. Jones wrote:
I ran into a problem where the kernel needs to load a vfat module in order to read /boot but the module is on /boot, so it goes to emergency mode. So you need to create a separate vfat partition for MLO and u-boot.img and leave /boot as ext. Make the vfat partition p1 and turn on the bootable flag. (Or else recompile the kernel with vfat built in, not a module.)
So, after spending a lot of time struggling with this, I finally managed to go back to where I was before: i.e., booting, but not able to mount the rootfs.
Here's how my SDCard looks now:
Disk /dev/mmcblk0: 14.9 GiB, 16021192704 bytes, 31291392 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: dos Disk identifier: 0x00000000
Device Boot Start End Sectors Size Id Type /dev/mmcblk0p1 * 63 144584 144522 70.6M c W95 FAT32 (LBA) /dev/mmcblk0p2 145408 1144831 999424 488M 83 Linux /dev/mmcblk0p3 1144832 1394687 249856 122M 82 Linux swap / Solaris /dev/mmcblk0p4 1394688 4128767 2734080 1.3G 83 Linux
In order to finally get a "working" system, I used Arch[GNU/]Linux's scripts/u-boot/MLO found at http://archlinuxarm.org/platforms/armv7/ti/beagleboard-xm. I don't know why, but I couldn't make the Fedora ones work with this setup...
Anyway, as I said, I'm back to a non-functional system (that, at least, shows me errors when booting Linux). It is still unable to find my root file system by LABEL or UUID, and it still shows me *lots* of errors/warnings when booting Linux.
My question now is: does Fedora 21 really work on a BeagleBoard-xM rev C? I'm starting to believe it doesn't (or that my board is somehow problematic/broken).
Any more ideas? BTW, the uEnv.txt file that I am using is:
mmcargs=setenv bootargs console=ttyO2,115200n8 root=LABEL=_/ ro rootwait cgroup_disable=memory fixrtc earlyprintk
mmcload=ext2load mmc 0:2 0x80000000 uInitrd-3.17.4-301.fc21.armv7hl; ext2load mmc 0:2 0x88000000 dtb-3.17.4-301.fc21.armv7hl/omap3-beagle-xm-ab.dtb; ext2load mmc 0:2 0x88080000 vmlinuz-3.17.4-301.fc21.armv7hl
uenvcmd=run mmcload; run mmcargs; bootz 0x88080000 0x80000000 0x88000000
And I am not using boot.cmd/boot.scr anymore.
On Monday, March 02 2015, Scott M. Jones wrote:
Can you try root=/dev/mmcblk0p4 in the boot args?
Sorry for the delay. I tried that, and apparently Linux found the rootfs. However, the only thing that changes is that now I don't see the message saying that no partition was found; other than that, I still see lots and lots of warnings/errors during the boot, and Linux still enters in emergency mode after boot.
FWIW, here's the full log, updated:
http://fpaste.org/193052/14254276/
As I said in another message, I am suspecting that Linux is lacking some support for the board. I'm totally out of ideas now; will see if I can recompile Linux later, maybe.
On Tue, Mar 3, 2015 at 6:07 PM, Sergio Durigan Junior sergiodj@sergiodj.net wrote:
On Monday, March 02 2015, Scott M. Jones wrote:
Can you try root=/dev/mmcblk0p4 in the boot args?
Sorry for the delay. I tried that, and apparently Linux found the rootfs. However, the only thing that changes is that now I don't see the message saying that no partition was found; other than that, I still see lots and lots of warnings/errors during the boot, and Linux still enters in emergency mode after boot.
FWIW, here's the full log, updated:
http://fpaste.org/193052/14254276/
As I said in another message, I am suspecting that Linux is lacking some support for the board. I'm totally out of ideas now; will see if I can recompile Linux later, maybe.
CONFIG_CRYPTO_MANAGER_DISABLE_TESTS=y ?
Regards,
I had a similar problem when I was first setting mine up, but I kept rebooting over and over and eventually got to a root shell. Once there I did a yum update and it has been stable ever since.
So... Try booting over and over and if you get to a root shell, connect to a network and update immediately.
-Scott
On 3/3/15 7:07 PM, Sergio Durigan Junior wrote:
On Monday, March 02 2015, Scott M. Jones wrote:
Can you try root=/dev/mmcblk0p4 in the boot args?
Sorry for the delay. I tried that, and apparently Linux found the rootfs. However, the only thing that changes is that now I don't see the message saying that no partition was found; other than that, I still see lots and lots of warnings/errors during the boot, and Linux still enters in emergency mode after boot.
FWIW, here's the full log, updated:
http://fpaste.org/193052/14254276/
As I said in another message, I am suspecting that Linux is lacking some support for the board. I'm totally out of ideas now; will see if I can recompile Linux later, maybe.
On Tuesday, March 03 2015, Scott M. Jones wrote:
I had a similar problem when I was first setting mine up, but I kept rebooting over and over and eventually got to a root shell. Once there I did a yum update and it has been stable ever since.
So... Try booting over and over and if you get to a root shell, connect to a network and update immediately.
Sorry for taking so long to reply. I managed to solve the problem a while ago, but forgot to post what I did here.
I am not really sure what was wrong. But here is roughly what I did:
- Updated u-boot using F22's version, instead of the (provided) F21
- Used Arch[GNU/]Linux's scripts to regenerate my sdcard and initial boot partitions. You can see the instructions here:
http://archlinuxarm.org/platforms/armv7/ti/beagleboard
The script to create the sdcard can be found here:
http://archlinuxarm.org/os/omap/BeagleBoard-bootloader.tar.gz
- Adapted the sdcard created by the script mentioned above in order to accomodate the necessary Fedora partitions.
After all of that, the system finally booted. I am still seeing many warnings from Linux during the boot, and I spent a lot of time doing the steps above and figuring out what worked and what didn't, so I can't really say now if everything is indeed needed, or if only a subset of the steps above would fix the problem.
Anyway, I hope this helps anyone who is also trying to install Fedora on a BeagleBoard-xM Rev C.
Cheers,
-
Robert Nelson -
Scott M. Jones -
Sergio Durigan Junior