<yann-kaelig>
I'm not an expert. I can see that some things are missing at uboot side, but I have no idea what I need and how to enable it
<yann-kaelig>
Not really sure but this "line 236: unnamed output consumer=ahci-5v" look importamt in my opinion. Missing at uboot boot could be the source of my issue
<cambrian_invader>
what is the problem you are having?
<yann-kaelig>
cambrian_invader: Hello. I use a subboard hdd-raid on my cubietruck board and I can not boot from the device connected on this subboard /dev/sda
<cambrian_invader>
why do you think this is related to the GPIOs?
ungeskriptet has quit [Ping timeout: 268 seconds]
<yann-kaelig>
Yes, because if I boot first on my sdcard then I connect the SSD device and run at uboot command prompt, scsi scan, it work
<yann-kaelig>
them I reboot and connect
<yann-kaelig>
there is something missing at uboot boot and it seems related to the gpio connection where the subboard is connected
Clamor has quit [Read error: Connection reset by peer]
Clamor has joined #u-boot
<yann-kaelig>
So how can I find the uboot config that enable this line "236: unnamed output consumer=ahci-5v" ?
<yann-kaelig>
or maybe there is one config to enable all the connector ?
<cambrian_invader>
that looks like a gpio regulator
<marex>
yann-kaelig: try 'gpio status -a' -> locate whatever looks like '1 8' there, flip it with 'gpio set ...' or 'gpio clear ...' and see if the SATA stuff magically starts working
<macromorgan>
does U-Boot support booting an android image with both a vendor_boot and init_boot ramdisk?
<macromorgan>
abootimg looks like it wants the boot.img (kernel) and vendor_boot.img only
<marex>
macromorgan: I never used it, so I dont know
<yann-kaelig>
marex: Hello What do you mean by '1 8' ? This is my gpio status -a output https://dpaste.com/DGCZNSENC
<marex>
yann-kaelig: try gpio set PA8
<marex>
EFI ... in SPL ...
* marex
faints
<yann-kaelig>
marex: I'm trying to understand something. Looking at the schematic I see two connector CN8 with 2x15 PINS and CN9 with 2x12 PINS. The subboard is connected on the CN8 connector but not all of the PINS are used. When I run gpio status -a there are BANK from PA to PI with 31 PINS but where are all of these PINS in my board ?
<yann-kaelig>
I'm unable to make a link between the connectors PINS and the gpio status output
Stat_headcrabed has joined #u-boot
<marex>
yann-kaelig: PA0..PI31 are not physical lines
<marex>
yann-kaelig: the GPIO controller in the SoC has multiple banks (PA..PI) of lines in the SoC (0..31 on each bank), those are plugged into pinmux block
<marex>
yann-kaelig: for each physical ball of the SoC , the pinmux IP has multiple inputs from different functions, one of those functions is some GPIO PxY
<marex>
yann-kaelig: another function can be for example I2Cn SDA
<marex>
yann-kaelig: so, you have to select the muxing for each pin first (I suspect 'gpio set ...' will flip the mux for you to GPIO function)
<marex>
yann-kaelig: and then the signal is routed through from the GPIO block -> pinmux -> physical SoC ball -> some signal on the PB
<marex>
you can find similar info in your SoC reference manual or datasheet
<yann-kaelig>
I have all the datasheet, schematic found on sunxi website, but this is something totally new for me and I'm for now lost :)
<marex>
yann-kaelig: it is really stupidly simple
<marex>
yann-kaelig: basically, silicon is cheap...ish
<marex>
yann-kaelig: synthesizing IPs on the silicon is also cheap, so to make the SoC flexible, the vendors synthesize multiple SPI controllers and I2C controllers and all kinds of stuff, right ?
<marex>
yann-kaelig: but ... all these IPs have way too many pins, more than the SoC has physical balls (signals going out of the chip)
<marex>
yann-kaelig: that is why the SoC vendors place a 1:n multiplexing unit between the signals from all these IPs they put in the chip , and physical balls of the chip
<marex>
yann-kaelig: it is up to the user to configure which of the IPs they want connected to which physical balls of the chip
<Sout>
want to use everything. buy the bigger and better version :D
vagrantc has quit [Ping timeout: 268 seconds]
vagrantc has joined #u-boot
zsoltiv_ has quit [Ping timeout: 256 seconds]
rvalue- has joined #u-boot
rvalue has quit [Ping timeout: 260 seconds]
Stat_headcrabed has quit [Quit: Stat_headcrabed]
slobodan_ has quit [Ping timeout: 260 seconds]
rvalue- is now known as rvalue
mmu_man has quit [Ping timeout: 268 seconds]
ikarso has quit [Quit: Connection closed for inactivity]
<yann-kaelig>
diff between reboot and working is SSD device pluged in the SATA cable
Clamor has quit [Ping timeout: 255 seconds]
warpme has quit [Ping timeout: 252 seconds]
<Jones42>
Hi, I've enabled CONFIG_IMX_HAB on my imx8mp and suddenly I get a "spl_romapi_raw_seekable_read Failure when load 0x60000, size 0xd1000 / SPL: failed to boot from all boot devices" when trying to boot. Can someone maybe give me any hint on where to look for solutions? (I'm using the 2024.01 phytec version (should be close to mainline?). The same
<Jones42>
experiment worked well when I tried it with the 2022.04 nxp version.)
mmu_man has joined #u-boot
Clamor has joined #u-boot
<yann-kaelig>
marex: scsi scan has an inpact on PH12 which is set and PI18 which is set but PI16 and PI17 are the same as the default failing case. Lets see what happen when I change the value of them
Clamor has quit [Read error: Connection reset by peer]
<yann-kaelig>
marex: how can I manually switch from PH12: input: 0 [ ]␍to PH12: output: 1 [x] ahci-5v.gpio␍I can toggle the Port but how can I enable the value ahci-5v.gpio ?
<yann-kaelig>
Right now it doesn't work if I set the PI16 and PI17 and run a scsi scan. That weird, there must be something else maybe with PH12
slobodan has joined #u-boot
warpme has joined #u-boot
warpme has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
f_ has quit [Ping timeout: 260 seconds]
<yann-kaelig>
It doesn't fix the issue. There is something else happening after a kernel reboot to u-boot command prompt, which make scsi scan working.
<yann-kaelig>
and my device connected on my subboard reachable
<marex>
Jones42: if you are looking for signed boot, this is currently work in progress
<marex>
+CONFIG_IMX_HAB=y
<marex>
+CONFIG_ARCH_MISC_INIT=y
<marex>
+CONFIG_SPL_CRYPTO=y
<marex>
+CONFIG_FSL_CAAM=y
<marex>
this ^ is what you need to enable for signed boot btw
<marex>
yann-kaelig: that [x] means the GPIO was claimed by some consumer , most likely the regulator that is itself consumed by the AHCI driver
<marex>
yann-kaelig: that looks like the right thing to do
<marex>
s@to do@to be happening@
<marex>
yann-kaelig: does fiddling with PH12 using gpio set / gpio clear have any impact on your hardware ? Like maybe it turns on some LED or something ?
enok has quit [Quit: enok]
enok has joined #u-boot
<yann-kaelig>
marex: no, the LED turn ON when I use the button to power ON the board and after 2 second turn OFF
<yann-kaelig>
gpio set/clear/toggle on PH12 doesn't turn ON the LED
<yann-kaelig>
only scsi scan
<yann-kaelig>
or scsi reset
enok has quit [Client Quit]
enok has joined #u-boot
enok has quit [Remote host closed the connection]
<marex>
yann-kaelig: you did write that if you reboot from Linux, both SATA drives work, right ?
enok has joined #u-boot
<marex>
yann-kaelig: and you tried to use gpio set / gpio clear after cold power on to configure GPIOs the same way as _after_ reboot from Linux, and that did not help ?
<yann-kaelig>
Both I don't know but at least scsi scan works and my device /dev/sda on port0 is reachable
<yann-kaelig>
no that did not help
<yann-kaelig>
it's only workign after a reboot from linux. That incredible :D
<marex>
yann-kaelig: clearly the state of the system differs and that state survives warm reset
joeskb7_ has joined #u-boot
joeskb7 has quit [Ping timeout: 255 seconds]
<yann-kaelig>
yes, the fact that state survives it's also somethign I can not understand. Is it normal ?
<marex>
yann-kaelig: normal is such an opaque word ...
<marex>
yann-kaelig: yes, you can have state which persists warm reset, for whatever reason
<yann-kaelig>
I understand. Well, now my mission is to find it ^^
<yann-kaelig>
I have no idea how to do, it's mission impossible for me
<marex>
yann-kaelig: do you know which DT does this platform use in Linux ?
<marex>
yann-kaelig: btw try this .. .before and after ...
<marex>
=> regulator status -a
<marex>
might give you another hint
<yann-kaelig>
ok
<yann-kaelig>
well I have to enable a config
<marex>
no regulator command ?
<marex>
hm
<yann-kaelig>
not by default. I will try tomorrow after a u-boot rebuild
<yann-kaelig>
Time to AFK
<yann-kaelig>
Thx a lot marex
<yann-kaelig>
CU later
<marex>
sure
<marex>
yann-kaelig: I suspect you'll have to dig into it, I can give you some generic pointers, but that's about it
<yann-kaelig>
Anything that can help the debug is welcome. Thx
<marex>
yann-kaelig: it is likely going to be something trivial in the end, but so far, we just dont know
<yann-kaelig>
I don't usually give up.
<marex>
that's a good trait
<yann-kaelig>
It depends on what you have to do the next day :)
<marex>
yann-kaelig: coffee can fix most of that :)
<marex>
yann-kaelig: so, which DT does this machine use ?
<yann-kaelig>
yes it is : PH12: output: 1 [x] ahci-5v.gpio
<yann-kaelig>
but what is 7 ?
<marex>
A B C D E F G H ... pio 0 is A , 1 is B ...
<yann-kaelig>
ok
<marex>
yann-kaelig: try one more thing ... => clk dump
<marex>
does that print a clock tree ?
<marex>
the SATA IP seems to have two clocks = <&ccu CLK_AHB_SATA>, <&ccu CLK_SATA>;
<marex>
maybe those are misconfigured
<yann-kaelig>
same no clk command by default
<yann-kaelig>
need t orebuild with this config too
<marex>
yann-kaelig: maybe not
<marex>
can you ....
<marex>
=> md 0x01c20000 0x100
<marex>
that will dump the entire register space of CCU , the clock unit
<marex>
dump it before and after, save to files, do a diff
<marex>
if you see any differing bits there, check them
<marex>
see Linux drivers/clk/sunxi-ng/ccu-sun4i-a10.c , grep for SATA , focus on those bits which are related to SATA in the CCM
<yann-kaelig>
I will try, this is a first time for me. I've never gone this far in debugging
<yann-kaelig>
ok, this time I quit. CU later and thx again
yann-kaelig has quit []
<Jones42>
marex: thanks! yes, I'm trying to get signed boot to work. I've enabled the configs you mentioned, but I still get the error in the SPL. So would you advise me to use the u-boot-imx instead for the time being? (Phytec just published BSPs that use mainline, but their secure-boot examples are only available for their old nxp-bsp if I see correctly)
<marex>
Jones42: I would never recommend anyone to use the downstream crud, no
<marex>
Jones42: that u-boot-usb repo contains patches on top of current master, i.e. 2024.07-rc1
<marex>
Jones42: I was testing that before submitting that stuff upstream on mx8mp yesterday
<marex>
Jones42: the mainline U-Boot does have signed boot support, the scripts are just awful and the binman conversion was long overdue, that's all
<marex>
Jones42: oh btw anything before 2023.07 is totally broken, no security at all, avoid
slobodan has quit [Ping timeout: 252 seconds]
<Jones42>
marex: Oh, alright... I'd rather use mainline, but there's only so much time I can spend on getting things to work, I'm just trying to figure out if I should just use what the board vendor provides instead...
<marex>
Jones42: are you using the pollux board ?
<marex>
Jones42: or the other one, whatever that was called ?
<marex>
that is probably the most fool proof quick how to get this going
<marex>
generate keys with CST scripts, sign U-Boot SPL and U-Boot using U-Boot shell scripts in doc/imx/habv4/ , fuse keys , test with hab_status that the platform reports no hab events ...
<marex>
and then eventually close it (once you are sure everything is fine !)
mmu_man has quit [Ping timeout: 264 seconds]
<marex>
with this binman branch above, all you have to do is patch imx8mp-u-boot.dtsi (see the topmost patch) , copy the CST generated key material into build dir, and run make flash.bin , the binman wrapper will sign both parts for you
<Jones42>
marex: thanks, I've read the documentation extensively. It's just that my SPL crashes as soon as i enable the HAB config. I haven't even started signing stuff
<marex>
Jones42: enable the four config options, see above
<marex>
Jones42: does that improve things ?
<marex>
Jones42: do you use downstream TFA or upstream TFA ? I only ever tested the upstream 2.10
<Jones42>
marex: I'm not sure about the TFA. I'll check.
<Jones42>
marex: all I did was enabling the four configs and all of a sudden the SPL gives me this:" spl_romapi_raw_seekable_read Failure when load 0x60000, size 0xcfa00, SPL: failed to boot from all boot devices "
<marex>
Jones42: are you starting the stuff via USB OTG upload ?
<marex>
using uuu ?
<Jones42>
marex: no, I'm flashing the wic file on a sd card
<marex>
Jones42: are you sure the card contains flash.bin written properly ?
schroes has quit [Read error: Connection reset by peer]
<marex>
Jones42: do you see anything else in the log ?
<Jones42>
I haven't checked. All I can tell is that everything works fine once I disable the IMX_HAB
<marex>
Jones42: offset 0x60000 (bytes) in the card is sector 0x300, which is where u-boot.itb (u-boot fitImage) should be located
<marex>
Jones42: but (!) that is part of an important bugfix
<marex>
Jones42: so if you enable IMX_HAB and include this fit,external-offset and it magically fixes your problem, this is a hint what the problem might be, this is NOT A FIX
<marex>
Jones42: CVE-2023-39902
<Jones42>
marex: alright, I'll give it a try, thanks!
<marex>
Jones42: btw my test machine was a disposable old DH iMX8MP DHCOM SoM on PDK3
<marex>
Jones42: I dont have any of the phytec hardware, but ... it shouldn't make much difference
<marex>
(soms are great for such testing, esp. ones that are decomissioned and catching dust because prototype etc)
<Jones42>
marex: for some reason, it was set to 0x0 by default.
<marex>
oh, yeah, that has to be in DRAM
<marex>
odd, it shouldn't be 0
<marex>
Jones42: well, good
<Jones42>
marex: but I don't know why it worked before then? If i don't enable IMX_HAB it's not problem even though it's zero
<Jones42>
marex: doesn't it use fit images for u-boot proper then?
<marex>
mx8m in general should use fitImages
<marex>
but wait ...
<marex>
git grep LOAD_FIT arch/arm/mach-imx/
<marex>
there are a few hits, in case the address is 0 the code does something slightly different
<marex>
for signed boot, the address must be in DRAM though
<marex>
i.e. non-zero
<marex>
you might want to check which of the conditionals you did hit with LOAD_FIT_ADDRESS being 0
<marex>
oh, the boards I use have this set, others default to some derivative of BOOTM load address
<marex>
but for signed configuration, whatever goes into the CST config file must match the FIT load address, because HAB checks the address of data it authenticates ... so you have to set it for HAB to work correctly
<Jones42>
marex: thanks a lot, that was very, very, helpful!