-
Notifications
You must be signed in to change notification settings - Fork 22
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
CM3 does not boot #10
Comments
I haven't tested using the Raspberry Pi's CM4 IO board, however, you could try this ... For UBoot ... For Linux ...
|
Same result, the board hangs after checking optee. By the way, when booting the standard debian image the bootloader checks a few more partitions:
Are they important for the boot process? |
Not sure - just double checking that for a sanity check you removed
linux and uboot and rebuilt ? Possibly a complete sanity check would be
a distclean ?
…On 16/9/22 01:20, Bernhard Petschina wrote:
Same result, the board hangs after checking optee.
I also changed the root device in boot.cmd and updated the fdtfile in
vars.txt, but the result is the same.
By the way, when booting the standard debian image the bootloader
checks a few more partitions:
|[SNIP] U-Boot SPL board init U-Boot SPL 2017.09-ga65d0aec67 #stephen
(Aug 25 2022 - 00:10:5unknown raw ID phN unrecognized JEDEC id bytes:
00, 00, 00 Try boot from MMC2 MMC error: The cmd index is 1, ret is
-110 Card did not respond to voltage select! mmc_init: -95, time 10
spl: mmc init faileror: -95 Trying to boot from MMC1 ## Verified-boot:
0 ## Checking atf-1 0x00040000 ... sha256(fe4f274c06...) + OK ##
Checking uboot 0x00a00000 ... sha256(37d023461e...) + OK ## Checking
fdt 0x00b2f8c8 ... sha256(2154df9e4a...) + OK ## Checking atf-2
0x00068000 ... sha256(8d44036095...) + OK ## Checking atf-3 0xfdcd0000
... sha256(e410275b51...) + OK ## Checking atf-4 0xfdcc9000 ...
sha256(990c53fc01...) + OK ## Checking atf-5 0x00066000 ...
sha256(315a4195a9...) + OK Jumping to U-Boot(0x00a00000) via ATotal:
213.498 ms INFO: Preloader serial: 2 [SNIP] |
Are they important for the boot process?
—
Reply to this email directly, view it on GitHub
<#10 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAFLUB52HG32Z4PCQ5EOLLDV6M5C5ANCNFSM6AAAAAAQMTHQYQ>.
You are receiving this because you commented.Message ID:
***@***.***>
|
Yes, I deleted the output and buildroot.dl folders and cleaned both repos to make sure everything is rebuilt. As another test I built everything on a Raspberry Pi 4 (that took a few hours...) from clean repos and now the CM3 hangs even earlier:
Now it doesn't even get to the optee check. When I have time I'll build a debian image from the debos-radxa repo and compare the outputs. Maybe I can spot some important differences. |
ok - do you have a CM3 IO board to do a sanity check on with the original repo ? |
Unfortunately no. But I don't really think that the board makes such a huge difference. Could you build the image and provide the sdcard.img so I can test that one? |
I could get my hands on a Rock 3A board, and that one doesn't boot either (with the respective rock3a configuration):
I'm currently settung up a fresh VM to make sure I don't have any bugs in my buildsystem, but I don't think that's the issue because I already built the image on my Raspberry 4 with the same result. By the way, my build system looks like this:
That should be the correct way to build the image, right? |
That looks correct. |
I'm using Ubuntu 22.04 with latest updates. I also found another buildroot repo for the cm3 (the firefly repo, if you know about it), but I don't really want to use that one because it uses it's own forks of u-boot and linux, and it comes with a huge amount of user apps for video and audio. |
IT should be building properly. Now how about your SDCard, have you only been using the one card ? Are you sure that card is writing as expected ? |
I've tried running the image on 3 different SDCards on the Rock3, and the eMMC on the CM3. I've also tried building the image with this Dockerfile: Could you try building the system yourself using this Dockerfile? I also built the official debian image with the debos-radxa repo, and that one works without problems. Could you also make sure you have no local changes you haven't checked in? |
I just did a complete rebuild for the cm3 module on the cm3 io board. I started with I would recommend getting a cm3 io board and testing with that first. This initial io board test will confirm that there is nothing strange going on in your system build nor writing to sdcard. After that you can build and run on other boards. I took this approach before manufacturing and running on my own cm3 carrier board.
|
I found the problem: You are using an old version of the rkbin repo, which NEEDS PYTHON2! I think you should either specify that python2 needs to be installed, or update the rkbin (and u-boot) repos to a later version. Here are the relevant lines of the build log without python2 installed:
And here's the log with python2 installed:
As you can see, without python2 the bootloader image is invalid because the atf sections are missing. That's why my cm3 would always hang when trying to validate the atf sections. |
@Tidone It looks like you may have gotten this to work. Could you provide more details? I am also working on batting the CM3 on a CM4 IO board but am stuck. I have a CM3 with eMMC so I am writing the output image to the eMMC with Here is a Gist showing what setup I am doing before running make. Everything seems to compile correctly -- no noticeable errors in the compile output -- but then when running I get the following:
I am building on a parallels VM running Ubuntu 22.04 on a Mac M1. I have also installed python2 based on your comment above. Is that all you did?
I don't have a CM3 IO board and have tried to order one but can't get it for more then a month... I have been at this for a couple of days now on and off with no success. Thank you in advance for any help. |
Yes, I got it to work on the CM4 IO board. You don't really need a CM3 IO board because your CM3 gets stuck before it uses any hardware specific parts. According to your uboot log you definitely still have compile errors. I checked your environment and have a few comments:
I could create a working image with your setup and these changes. (Check this Gist for my relevant logs.) You can check the
|
@Tidone Thank your for your quick reply and detailed info. Unfortunately I am still stuck but have had some findings. I have updated my gist with my patches, setup script and br.log output I am hopeful since you can make a build but seems we need to find the difference in our two setups. I am still only getting to
I have noticed two differences. Your output has a line I believe this may be due to the error I found in the br.log output
This is right after the It looks like this should read
I did try to change my build and before doing Any ideas are greatly appreciated! PS. I don't think this matters yet but I am pushing the the eMMC by doing the following
|
I have been digging some more and also found
I checked out https://github.com/rockchip-linux/rkbin at that commit and the path does appear to be correct... maybe the defconfig or something else... still digging Not sure exactly where in the dir structure the
|
The main problem is that we are relying on binary blobs in rkbin, which are compiled for x86-64. All your build errors can be traced back to the build system trying to execute rkbin/tools/boot_merger, which fails because you are compiling on a Mac M1 (ARM64) system. Unfortunately you also can't use the boot_merger in u-boot because the rkbin one has some device specific patches (and we don't have the sources for that). You could try to use qemu to execute the offending scripts (maybe build inside docker and use multiarch/qemu-user-static?). I also have a heavily modified version of this repo which uses newer versions of u-boot and Linux. EDIT: I just published my heavily modified fork of this repo (https://github.com/Tidone/buildroot.cm3). My fork will build an image for the CM3-CM4IO with the latest mainline Linux Kernel 6.1 and U-Boot v2022.04. |
Thank you so much for your reply and fork. I will give it a go later today. I am actually working on bringing the CM3 up as a Nerves supported board. So all of your help is greatly appreciated and hopefully will be realized by many |
@CaptChrisD Seriously? I actually already created a Nerves System (https://github.com/sportalliance/nerves_system_radxa_cm3). It uses a really minimal set of hardware features because we use it for some of our companie's products, but one can fork it and adapt the dtb to enable additional features. |
Wow... that would have saved a lot of time. So cool. I have brought up the board with your buildroot.cm3 repo as well as the nerves system. As well as with the nerves system. I am just going to start working through getting the device tree switched out to support the cm4-io board. If I bump into troubles I will ping you over in that repo. |
I'm using a Radxa CM3 module on a Raspberry Pi CM4 IO Board.
I built the image as described, and flashed it onto the internal eMMC.
The board starts U-Boot SPL, but then hangs after verifying the checksums:
I also tried to write the image onto an sdcard, but that didn't work as well (maybe a different dtbo is needed). Even if it worked on an external sdcard, I would like it to boot from the internal eMMC.
The text was updated successfully, but these errors were encountered: