jwillikers has quit [Remote host closed the connection]
birkoff has joined #u-boot
birkoff is now known as Guest2026
sakman has quit [Remote host closed the connection]
sakman has joined #u-boot
mranostaj has quit [Remote host closed the connection]
mranostaj has joined #u-boot
fdanis_away is now known as fdanis
guillaume_g has joined #u-boot
agust has joined #u-boot
frieder has joined #u-boot
eduardas has joined #u-boot
mckoan|away is now known as mckoan
sszy has joined #u-boot
matthias_bgg has joined #u-boot
mmu_man has joined #u-boot
monstr has joined #u-boot
mckoan is now known as mckoan|away
tre has joined #u-boot
alpernebbi has quit [Ping timeout: 268 seconds]
alpernebbi has joined #u-boot
___nick___ has joined #u-boot
tre has quit [Ping timeout: 240 seconds]
___nick___ has quit [Quit: No Ping reply in 180 seconds.]
___nick___ has joined #u-boot
tre has joined #u-boot
indy has quit [Ping timeout: 245 seconds]
indy has joined #u-boot
jwillikers has joined #u-boot
___nick___ has quit [Quit: No Ping reply in 180 seconds.]
zibolo has joined #u-boot
___nick___ has joined #u-boot
monstr has quit [Ping timeout: 240 seconds]
<zibolo>
Hi everyone! I'm trying to boot a Xilinix UltraZed+ cortex A53 with u-boot from eMMC. Such device needs the so called u-boot-spl (equivalent to xilinx's FSBL) which also loads the "PMU firmware" on a separate microcontroller. Now, when I run u-boot-spl it fails with "PMU Firmware device not found - Enable it" which is kinda confusing. Is it the PMU device which is not found? Or the firmware?
matthias_bgg has quit [Read error: Connection reset by peer]
sicelo has quit [Ping timeout: 245 seconds]
pgreco has quit [Ping timeout: 265 seconds]
pgreco has joined #u-boot
matthias_bgg has joined #u-boot
tre has quit [Remote host closed the connection]
sicelo has joined #u-boot
sicelo has joined #u-boot
<LeSpocky>
when I put the environment in a UBI volume, should that be static or dynamic?
frieder has quit [Remote host closed the connection]
monstr has quit [Remote host closed the connection]
<mrnuke>
Tartarus: yes
<Forty-Bot>
zibolo: yes, you should have a node in your device tree
<Forty-Bot>
there could also be a problem probing the device
<Forty-Bot>
try adding `#define DEBUG` at the top of drivers/firmware/firmware-zynqmp.c
* mrnuke
sometimes wishes he could just #undef BUG
eduardas has quit [Quit: Konversation terminated!]
<zibolo>
Forty-Bot: Thanks! In my dts I have a zynqmp_power and pmu nodes, so I'll try to recompile with #define DEBUG and hope to see something
<zibolo>
Forty-Bot: should it print more info in the serial console?
akaWolf has quit [Ping timeout: 268 seconds]
<zibolo>
Forty-Bot: Even with `#define DEBUG` I do not have any further debug info in the serial console :'( I'll try something else tomorrow. Thanks for the help!
guillaume_g has quit [Quit: Konversation terminated!]
<marex>
Tartarus: we should change CONFIG_SF_DEFAULT_MODE to 0x0, this has been popping up on board updates left and right for me, the 0x3 default is bogus
<Tartarus>
marex: OK. Are platforms that do 0x3 today going to break when they're switched to 0x0 instead?
<Tartarus>
Er, to be clearer
<Tartarus>
Are platforms that do 0x3 today and that actually is correct and functional ...
<marex>
Tartarus: er ... I can tell you that NXP iMX, SoCFPGA, Xilinx, Renesas and STM32MP1 fail with 0x3 and should be 0x0
<marex>
so ... which are 0x3 and are correct ?
<marex>
oh and those rockchips are also broken with 0x3 and should be 0x0
<Tartarus>
So nothing was ever doing that right before, OK
<Tartarus>
Please put all that in a commit message and post :)
<marex>
Tartarus: I think the Kconfig conversion really screwed this one up, yes
<marex>
it picked one, should have picked the other, than then nobody noticed for a while because ... errr ...
<marex>
...
<Tartarus>
I'm pretty sure it picked what everyone was setting before
<marex>
it was half and half , no ?
<marex>
except 0x3 is real odd
<marex>
it is CPOL and CPHA, for boot flash that is rare, because even bootroms arent that screwed up to demand this
<marex>
oh, heh ... the conversion was done by ST and it breaks STM32MP1 ... hmmmmmmmmmmmmmmmmmmmmmmmm
<Tartarus>
Yeah, so this is why I say it never worked right
<Tartarus>
Your e2e95e5e25421fbef499e21bf94a5339701f9a99 exposes the problem
<marex>
I might have excepted that ST might have tested booting from SPI NOR before sending out that patch at least on their own platform
<Tartarus>
But the conversion in 14453fbfadc2f98ca35d6033140466c7a4b4947a shows:
<marex>
Bad hash value for 'hash-1' hash node in 'kernel-1' image node
<marex>
ERROR: can't get kernel image!
<marex>
Bad Data Hash
<marex>
mrnuke: ^
<marex>
mrnuke: seems like ST couldn;t watch my ranting about ST any longer
matthias_bgg has quit [Ping timeout: 268 seconds]
<mrnuke>
Tartarus, marex: What the frog? Byte order issue. I specifically remember testing for that on my stm32mp1
<Tartarus>
marex: I honestly wonder if a handful of platforms just didn't test SPI flash much and just accepted the default and/or forum users/etc documented using 0 while probing
<Tartarus>
xilinx does have "sf probe 0 0 0 0" in scripts, but almost nothing else does
<marex>
I was also looking for another quote about needing a revert or a solution soon or something along those lines, I knew someone used it recently and it was rather nasty entitled spit, but I can't find it
<marex>
oh well
<Tartarus>
For example, but maybe because it doesn't do crc32 on that image
<marex>
Tartarus: image is fitImage or image is entry in the image section of fitImage ?
<Tartarus>
marex: OK, I'm being a bit multi-threaded here, sorry.
<Tartarus>
On an old random fitImage I have, with that patch applied:
<Tartarus>
## Checking hash(es) for FIT Image at 82000000 ...
<Tartarus>
Hash(es) for Image 1 (fdt@1): crc32+
<Tartarus>
Hash(es) for Image 0 (kernel@1): md5+ sha1+
<Tartarus>
At the end of iminfo $loadaddr
<Tartarus>
And without that patch, hashes fail.
<Tartarus>
What I pastebin'd above is from the EFI FIT test we already have.
<mrnuke>
Tartarus: "Hash(es) for Image 1 (fdt@1): crc32+" before or after my centos.paste fix?
<Tartarus>
mrnuke: After
<Tartarus>
Before the hashes were invalid
<mrnuke>
Tartarus: okay. Thank you
redbrain has quit [Ping timeout: 252 seconds]
<Tartarus>
Now, on the host, so sandbox, we don't fail.
<Tartarus>
We didn't have checksums, but that was an easy fix, but now I see the checksums are seemingly fine, on host.
<Tartarus>
Lets fire off EFI FIT tests, which are not sandbox-only
<Tartarus>
and qemu, where the file will be remade
sbach has quit [Read error: Connection reset by peer]
<Tartarus>
OK, lets see if i can make CI fail now, like it should
sbach has joined #u-boot
<mrnuke>
Tartarus: Does testing show CRC problem happening on big endian hosts too? I'm writing the commit message BTW. Should have patch up on ML soon
<marex>
hm ... dang ... seems like ever since we grew spi-nor-core, MTDIDS for all SPI NORs are completely broken
<Tartarus>
mrnuke: I lack one to easily test on
qastokes has joined #u-boot
<mrnuke>
Tartarus: the hardest part in making a patch is writing a convincing and explanatory commit message. Up on ML
<Tartarus>
(32bit arm is where I can test pass/fail)
<Tartarus>
mrnuke: That code is shared between host/target, yes? So bad crc32 calc on host tools means bad crc32 calc also on target, so both would still match, yes?
<Tartarus>
So we would need an exiting FIT image to catch this, which is how I can make it fail on my HW, that fitImage I have is random old garbage