CM3 U-Boot patch does not apply on Hardknott branch #876
Comments
|
@Metatron2k2 I hope you are on same branch ( hardknott ) of other layers too. Secondly, I would suggest to disable all layers except core layer and meta-rpi and run |
|
@kraj Yes everything was in in hardknott branch. I removed all non-openembedded and non-poky layers. Result is still the same Bitbake log: For me it does not seem like any patch not part of open-embedded or poky being applied. Any Idea why this happens? |
|
thanks, this means this patch needs to be forward ported as it seems it was missed when oe-core u-boot got updated. |
|
HI, |
It moves the platform data translation more early in the file so it executes in an order that makes cm3 boot |
|
Hi @emilm, I‘ve seen you already created a patch on the dunfell branch. Would you be so kind to share it with me? Best, |
|
Hello @Metatron2k2 ! Does the patch break for you the same way? |
|
Hey, I just double checked. In fact it breaks in a different way. I‘m also not sure if it is really necessary here though…. |
|
So it turns out that it does not boot. It seems like the file changed quite a bit and I'm not sure where to start. Some help would be appreciated. |
|
If you are on Hardknott, my patch for Dunfell would probably not work. |
|
Hey @emilm, Looking at the files it seems like the order is correct (but I'm not 100% sure). On the CMIO board i get a few blinks on the activity LED and then nothing. Debug UART (I assume GPIO 14 and 15? ) is also not doing anythin. |
|
Looking at the git history upstream it seems like the patch should already be applied. But i still don't get any debut output or anything useful from uboot. Any idea? |
|
Seems like the right order. However u-boot has been refactored several times.
It seems outdated. No other ideas than comparing a patched u-boot from Dunfell with this one and see how the code ultimately ends up working in sequence :/ You can use devtool modify u-boot , then edit the source to log more (remember to enable more verbose logging in the config) Do you use UART overlay or anything like that? |
|
We're only using ENABLE_UART=1 in the config no other overlays. Strangly enough i do not get anything on the UART. The UART adapter itself seems fine (at least it is working on my PI4). Any Idea why I do not get anything from u-boot on uart at all? |
|
What pins is it wired up to, and what is your cmdline.txt? |
|
cmdline.txt: |
|
Did you try pins 32 and 33, the UARTs are flipped in CM3 also afaik. |
|
Yeah tried both. Also tried a pi zero W as UART adapter. I was able to get output on our "old" production image. I'd like to run a build against dunfell to see if it is working there. Could you supply me with your patch so I can get U-Boot up and running there? Once i know the old U-Boot is working well, I would try to get some more support from the U-Boot mailing list. |
|
OK, you should try without the patch first. |
|
Hey @emilm Thanks for the patch. I can now confirm that i get Debug output from U-Boot 2020.1 without the patch. With your patch it boots just fine. I assume that U-Boot in Hardknott is broken for CM3 completely. |
|
Ok, as it is not an issue with the patch I've opened a new issue #897 |
|
Closing this issue in favour of #897 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Description
U-Boot patch for CM3 does not apply on hardknott.
Steps to reproduce the issue:
Describe the results you received:
Error that hunk 2 patch does not apply.
Describe the results you expected:
Patch should apply and no error should be throwb.
Additional information you deem important (e.g. issue happens only occasionally):
The error occurs for me trying to build an swupdate-image (meta-swupdate)
Additional details (revisions used, host distro, etc.):
Host is a nspawn container based on Debian 10 (stable)
The text was updated successfully, but these errors were encountered: