The system stops booting when it reaches the kernel

[Zyx498495679]

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]

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:

• MPU : 1000 MHz
• AXI : 266.500 MHz
• PER : 24 MHz
• DDR : 533 MHz Core: 252 devices, 32 uclasses, devicetree: board WDT: Started watchdog with servicing (32s timeout) NAND: 0 MiB MMC: STM32 SD/MMC: 0, STM32 SD/MMC: 1 Loading Environment from MMC... *** Warning - bad CRC, using default environment

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]

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]

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]

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

[xogium]

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]

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]

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!

[xogium]

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]

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]

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]

Hi @Zyx498495679, is there any news on this?

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

[Zyx498495679]

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.

[danny-source]

i have same problem. do we have any news, guys ?

[Zyx498495679]

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

[xogium]

Hiya @danny-source, I'm not sure about this myself. But since you appear to have the issue, both of you, I will investigate deeper. I will do a fully clean build again and try to boot it up. I'm very sorry you have problems. Let's try to fix them. I assume you also use a micro sd card?

Thanks!

[xogium]

After building a system image and using dd to write it onto a micro sd, I confirm this is booting up, for me. I am on the latest commit, added on september 29th. The system fully boots up and gets a dhcp lease from my router, as well as a slaac ipv6 address.

I took out all the jumpers == micro sd boot, wrote the image on the micro sd using dd if=sdcard.img of=/dev/sdb conv=fsync bs=2M and booted it up. Is there anything you perhaps both do differently? This is a puzzling mystery.

[xogium]

Alternatively, can you send me the generated sdcard.img file so that I can test it on my side as well? This would point towards either a problem during build if it fails to boot, or a problem with your hardware itself.

[danny-source]

Alternatively, can you send me the generated sdcard.img file so that I can test it on my side as well? This would point towards either a problem during build if it fails to boot, or a problem with your hardware itself. pls: https://mega.nz/file/dRsmyJJa#Rr4DtHFxEkvNylWnfJpMfliGYiKTEPx2FC47_o9Xz7I

[xogium]

Thank you! I will try it immediately and report back.

Do you burn it the same way as me on the micro sd?

[danny-source]

Thank you! I will try it immediately and report back.

Do you burn it the same way as me on the micro sd?

i use your parameter "dd if=sdcard.img of=/dev/sdb conv=fsync bs=2M"

[xogium]

How interesting! The good news is, I reproduce your issue with this image. Which would probably indicate it's a problem that happens on your system when building. Hmm. I wonder what is so different. What OS do you build on?

[xogium]

Could you try this image when you have a moment? Just to confirm this one boots without a problem on the board, like it does for me. https://paste.xogium.me/cp.tgz

[xogium]

One thing I notice right away is that your image is 310 MB when uncompressed, where as mine is only 110. Did you add softwares?

[danny-source]

One thing I notice right away is that your image is 310 MB when uncompressed, where as mine is only 110. Did you add softwares? no, i don't have add software, just try build image. i want to make sure problem, i use "Debian 5.10.226-1"

[xogium]

I'll try to investigate this deeper with a tool called diffoscope. Feel free to try too, if you have some time. It's basically checking for differences in large files and displaying what has changed on the hexadecimal level and where.

[danny-source]

I'll try to investigate this deeper with a tool called diffoscope. Feel free to try too, if you have some time. It's basically checking for differences in large files and displaying what has changed on the hexadecimal level and where.

i change the BR2_TARGET_ROOTFS_EXT2_SIZE="300M"

[xogium]

Right, I figured that was a change you might have done. But you did nothing else besides that? I'm trying to reproduce this in a debian 12 container at the moment. I'm not sure what else to try.

[danny-source]

Right, I figured that was a change you might have done. But you did nothing else besides that? I'm trying to reproduce this in a debian 12 container at the moment. I'm not sure what else to try.

can you provide yours enviorment? i will try , too. In addition, you can also provide the simplest sdcard.img for me to try

[xogium]

Hi, I'm absolutely sorry for the false alarm. I will freely admit that I messed up here and forgot to check the jumpers configuration of the board I was testing this on. All this time the eMMC was empty, leading to me thinking it was hanging. I apologize for my mistake. I could not ultimately reproduce your problem, and I actually got your image to boot up just fine on the board once I fixed the jumpers.

Could you try out one or two more micro sd card to rule out that it really is the card at fault? Micro sd cards are always the first point of failure in embedded systems, and it's even more the case during development.

As for the image, I've sent a link to mine already, see here: https://paste.xogium.me/cp.tgz

Once again, I'm sorry for the confusion.

If you really have the problem with multiple sd cards I'll do my best to come up with a way to figure it out. If it turns out to be the case, I would dump the entire micro sd via dd and analyze it with tools. I'd be glad to help with this task if it proves to be necessary.

[danny-source]

Hi, I'm absolutely sorry for the false alarm. I will freely admit that I messed up here and forgot to check the jumpers configuration of the board I was testing this on. All this time the eMMC was empty, leading to me thinking it was hanging. I apologize for my mistake. I could not ultimately reproduce your problem, and I actually got your image to boot up just fine on the board once I fixed the jumpers.

Could you try out one or two more micro sd card to rule out that it really is the card at fault? Micro sd cards are always the first point of failure in embedded systems, and it's even more the case during development.

As for the image, I've sent a link to mine already, see here: https://paste.xogium.me/cp.tgz

Once again, I'm sorry for the confusion.

If you really have the problem with multiple sd cards I'll do my best to come up with a way to figure it out. If it turns out to > be the case, I would dump the entire micro sd via dd and analyze it with tools. I'd be glad to help with this task if it proves > to be necessary.

i was found out problem. when i don't plug network ,booting was spent out time. can you help me this problem?

[xogium]

Hi, investigating this, it appears I might need to give up on the capability of this project to boot over nfs. I used the kernel-level ip configuration so that one could boot over nfs, but also micro sd and eMMC. The only solution I was given when I mentioned this long timeout you are experiencing was to not use ip=dhcp on the command line when booting the kernel. In other words, to configure networking once userspace has booted up.

It looks like I may need to give up on allowing nfs boot, unless I could find a solution to allow for ip=dhcp to be added only when the boot script detects one is doing nfs. But even if I could do this, that implies that userspace will be a problem since the networking is already set up by the kernel.

I'm also very sorry I didn't notice this way earlier. I never go without plugging ethernet in any board I own that have ethernet, it's a reflexe here. If I had, I'd have noticed there was a problem sooner.

[danny-source]

Hi, investigating this, it appears I might need to give up on the capability of this project to boot over nfs. I used the kernel-level ip configuration so that one could boot over nfs, but also micro sd and eMMC. The only solution I was given when I mentioned this long timeout you are experiencing was to not use ip=dhcp on the command line when booting the kernel. In other words, to configure networking once userspace has booted up.

It looks like I may need to give up on allowing nfs boot, unless I could find a solution to allow for ip=dhcp to be added only when the boot script detects one is doing nfs. But even if I could do this, that implies that userspace will be a problem since the networking is already set up by the kernel.

I'm also very sorry I didn't notice this way earlier. I never go without plugging ethernet in any board I own that have ethernet, it's a reflexe here. If I had, I'd have noticed there was a problem sooner.

i am junior. i don't use nfs to boot it, i will remove ip=dhcp from boot.cmd and try it. Thank you for your help, YA!YA!YA!

[xogium]

No problem! I will also remove it in the repository, for what it's worth and replace with networking from userspace. Bye bye nfs. I'll also need to update the wiki page on the seeed studio wiki to mention that nfs is no longer possible, at least out of the box.

[danny-source]

No problem! I will also remove it in the repository, for what it's worth and replace with networking from userspace. Bye bye nfs. I'll also need to update the wiki page on the seeed studio wiki to mention that nfs is no longer possible, at least out of the box.

do you matianter on seeed studio wiki?

[xogium]

Yes. I am the author of the wiki article on how to get going with this specific board. I don't maintain directly however I can open a pull request and get it merged, so I can update the wiki article.

[danny-source]

Yes. I am the author of the wiki article on how to get going with this specific board. I don't maintain directly however I can open a pull request and get it merged, so I can update the wiki article.

thank you for open the project, i want to this to finish my project. you so powerful !!!!. Do you want to continue this project?

[xogium]

Absolutely! I haven't been able to do as much as I wanted due to my health unfortunately, but I'm definitely not giving up on it, don't worry! Do you have any things you would like to see added or modified? I'm never against suggestions.

[danny-source]

Absolutely! I haven't been able to do as much as I wanted due to my health unfortunately, but I'm definitely not giving up on it, don't worry! Do you have any things you would like to see added or modified? I'm never against suggestions.

i used PI to do projects, but I wanted to learn more about using STM32MP1 and buildroot to get more advanced. Unfortunately, I am just a beginner and am learning. Do you have any suggestions that may help you in the future? And i don't know this board how to use uart 2

[xogium]

Hi, the device tree provided by my project is already enabling usart2.

As for suggestions, I'm not sure. What would you like to learn? I've actually been thinking of offering a way for people to contact me directly over telegram so they can ask their questions. What do you think? Would you be interested in this? So we don't clutter issues in github.

I'm still trying to figure out the best way to allow for userspace networking on both interfaces, since we can never know in which port someone will plug a cable in. It appears that busybox's ifupdown thing is a mess all round though as it waits before the interface that has no cable plugged in to timeout before ever trying the other interface. I hate old tools. It doesn't freeze the boot from what I can tell, but due to this it takes an eternity to give you network access, which is not acceptable either in my opinion.

[danny-source]

maybe it need a forum, it's not telegram . because if this discussion is worth collecting, then ordinary communication software cannot organize the articles. i will try to develop a project from serial port to receive data and process data.

[danny-source]

I have successfully built and executed it, thank you for your help. Did you also create this circuit diagram?

[xogium]

I took the circuit diagram that shows how to connect uart via the seeed studio website, if I recall correctly.

I'm very glad you got it to build in the end, also! I'm still trying to come up with the best way to have networking handled by userspace, that's why I left this issue open. I've been feeling a bit sick the past few days, sorry this was slow.

I'm trying to come up with the best compromise between speed and complexity here, which many of the older pre-systemd network managers seem to lack. But, I didn't throw this away, no worries!

[danny-source]

Take care of yourself. This is a long-term plan. I will continue to use this version for development. I successfully made it run nodejs for my project. My work is also using this version for future product development. Thank you very much, keep in touch