search

xogium / buildroot-stm32mp135d-odyssey

External tree for buildroot on STM32MP135D ODYSSEY
GNU General Public License v3.0
2 stars 1 forks source link

The system stops booting when it reaches the kernel #4

Open Zyx498495679 opened 6 months ago

Zyx498495679 commented 6 months ago

Hi, I used this procedure and after compiling, burned the sdcard.img to the SD card, but the stm32mp135d didn't boot up properly!Here is the exception log：

Zyx498495679 commented 6 months ago

NOTICE: CPU: STM32MP135D Rev.Y NOTICE: Model: Seeed STM32MP135D Odyssey Board NOTICE: BL2: v2.8-stm32mp1-r1.0(release):() NOTICE: BL2: Built : 22:02:48, Jan 15 2024 NOTICE: BL2: Booting BL32 I/TC: Early console on UART#4 I/TC: I/TC: Embedded DTB found I/TC: OP-TEE version: Unknown_3.19 (gcc version 11.4.0 (Buildroot 2023.02.5)) #1 Mon Jan 15 14:00:40 UTC 2024 arm I/TC: WARNING: This OP-TEE configuration might be insecure! I/TC: WARNING: Please check https://optee.readthedocs.io/en/latest/architecture/porting_guidelines.html I/TC: Primary CPU initializing I/TC: WARNING: All debug access are allowed I/TC: No RNG configuration specified, defaulting to NIST B I/TC: Platform stm32mp1: flavor 135D_ODYSSEY - DT stm32mp135d-odyssey.dts I/TC: DTB enables console (non-secure) I/TC: Primary CPU switching to normal world boot optee optee: OP-TEE: revision 3.19

U-Boot 2022.10-stm32mp-r1 (Jan 15 2024 - 22:02:26 +0800)

CPU: STM32MP135D Rev.Y Model: Seeed STM32MP135D Odyssey Board Board: stm32mp1 in trusted mode (st,stm32mp135d-odyssey) DRAM: 512 MiB optee optee: OP-TEE: revision 3.19 Clocks:

In: serial Out: serial Err: serial invalid MAC address 0 in OTP 00:00:00:00:00:00 Net: Error: eth2@5800e000 address not set.

Error: eth1@5800a000 address not set.

Error: eth2@5800e000 address not set. No ethernet found.

Hit any key to stop autoboot: 0 Boot over mmc0! Saving Environment to MMC... Writing to redundant MMC(0)... OK switch to partitions #0, OK mmc0 is current device Scanning mmc 0:5... Found U-Boot script /boot/boot.scr 742 bytes read in 8 ms (89.8 KiB/s)

Executing script at c4100000

Micro sd card boot 44541 bytes read in 9 ms (4.7 MiB/s) 10760704 bytes read in 455 ms (22.6 MiB/s) Kernel image @ 0xc2000000 [ 0x000000 - 0xa43200 ]

Flattened Device Tree blob at c4000000

Booting using the fdt blob at 0xc4000000 Loading Device Tree to cfff2000, end cffffdfc ... OK

Starting kernel ...

[ 0.007669] /cpus/cpu@0 missing clock-frequency property [ 1.167091] Driver 'scmi-optee' was unable to register with bus_type 'tee' because the bus was not initialized. [ 1.459325] stm32-cpufreq stm32-cpufreq: OPP-v2 not supported

Zyx498495679 commented 6 months ago

My environment is: Linux 6.2.0-39-generic #40~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC Thu Nov 16 10:53:04 UTC 2 x86_64 x86_64 x86_64 GNU/Linux

xogium commented 6 months ago

Hi @Zyx498495679, this is very strange. The kernel logs are set in quiet mode so that is why you don't get a lot of messages during boot, however after a few moments, busybox should be running and you should get a login console on ttySTM0.

Just making sure here, but I assume you use the very latest commit of this repository? I will attempt to reproduce it here, but in the meantime, did you alter in any way the configuration or not at all (added / removed packages, modified the boot script), anything? Just so we both try to reproduce things on the same page, so to speak.

Zyx498495679 commented 6 months ago

您的邮件我已收到，谢谢配合。

xogium commented 6 months ago

One thing to try maybe is to edit the boot.cmd file located in board/stm32mp135d-odyssey/utilities folder, and to remove quiet from the bootargs. It might give you some more insights as to what is going on.

If that still doesn't provide you with enough information, try replacing the quiet argument with debug. When trying these, make sure to rebuild the entire system just to be sure everything gets properly compiled and rebuilt as it should (make clean && make).

I'd also try another micro sd card, just in case. Sometimes, micro sd cards can begin to fail in unpredictable ways, and if this is a card that is getting well worn out, it could be a possibility.

Zyx498495679 commented 6 months ago

One thing to try maybe is to edit the boot.cmd file located in board/stm32mp135d-odyssey/utilities folder, and to remove quiet from the bootargs. It might give you some more insights as to what is going on.

If that still doesn't provide you with enough information, try replacing the quiet argument with debug. When trying these, make sure to rebuild the entire system just to be sure everything gets properly compiled and rebuilt as it should (make clean && make).

I'd also try another micro sd card, just in case. Sometimes, micro sd cards can begin to fail in unpredictable ways, and if this is a card that is getting well worn out, it could be a possibility.

Thanks for your reply I'll try removing quiet and recompiling and try it again.

Zyx498495679 commented 5 months ago

test The resource v6.1-stm32mp-odyssey-r4 that I used inside my config file I couldn't find, so I replaced it with v6.1-stm32mp-odyssey and it works fine now! image

xogium commented 5 months ago

Hum, this should definitely not happen. The release was definitely pushed to the correct git repository, see here: https://github.com/xogium/st-linux/releases/tag/v6.1-stm32mp-odyssey-r4

I'd think something got messed up on your side for this to fail... Though I've not a clue what.

Using the branch itself might work short term but on long term it would mean that every time you build, you might end up with a different release, as buildroot would then get the latest commit. This is definitely not ideal. Would you be open to investigating this more?

Zyx498495679 commented 5 months ago

Hum, this should definitely not happen. The release was definitely pushed to the correct git repository, see here: https://github.com/xogium/st-linux/releases/tag/v6.1-stm32mp-odyssey-r4

I'd think something got messed up on your side for this to fail... Though I've not a clue what.

Using the branch itself might work short term but on long term it would mean that every time you build, you might end up with a different release, as buildroot would then get the latest commit. This is definitely not ideal. Would you be open to investigating this more?

Of course, I also want to know the reason why it didn't start normally in the first place. Now I will change the tag back to r4 and recompile to see if it can be reproduced.

xogium commented 5 months ago

Yeah, I mean, there is something going on for sure. Thing is to figure out what this might be, because the latest commit in the kernel repository is actually that r4 release, at least for now. So, it should make no difference as of today, if you picked the branch or the r4 release... And yet it did.

I notice also that the init script for beeping on boot seems to work, but yet it says that mraa, which is required for this isn't found. That does seem to point to severe breakage in the image itself, as in, the image that was written on the micro sd.

Did you try with a new card just to make sure it wouldn't be this one failing? It's a random guess like I said, but cards can start to fail in ways that are so unpredictable sometimes that you get confusing results, even contradicting ones between each burning.

xogium commented 5 months ago

Hi @Zyx498495679, is there any news on this?

Did you get the time to try building again, and did the issue persist?

Zyx498495679 commented 4 months ago

Hi @Zyx498495679, is there any news on this?

Did you get the time to try building again, and did the issue persist?

Hello, I'm so sorry, I've had to finish something else for a while now. I will continue to work on the MP135 after I finish what I'm working on.