wooosaiiii has quit [Remote host closed the connection]
wooosaiiii has joined #u-boot
dhruvag2000 has joined #u-boot
jmasson has joined #u-boot
Clamor has joined #u-boot
monstr has joined #u-boot
sakman has quit [Ping timeout: 252 seconds]
Clamor has quit [Ping timeout: 256 seconds]
Clamor has joined #u-boot
frieder has joined #u-boot
jclsn has quit [Ping timeout: 240 seconds]
jclsn has joined #u-boot
jmasson has quit [Remote host closed the connection]
mmu_man has joined #u-boot
ldevulder_ is now known as ldevulder
davlefou has quit [Ping timeout: 256 seconds]
sszy has joined #u-boot
ezulian has joined #u-boot
zkrx has quit []
davlefou has joined #u-boot
zkrx has joined #u-boot
mmu_man has quit [Ping timeout: 264 seconds]
slobodan has joined #u-boot
ezulian has quit [Quit: ezulian]
prabhakarlad has joined #u-boot
ezulian has joined #u-boot
prabhakarlad has quit [Quit: Client closed]
Lightsword has quit [Quit: ZNC]
Lightsword has joined #u-boot
<qschulz>
Tartarus: Kever told me you wanted the board READMEs to be in rST format now (and merged with doc/boards/rockchip?)
<qschulz>
Tartarus: the Rockchip doc doesn't actually document how to flash the eMMC/SPI over USB, only once you have a running system, which is... well a bit of a chicken and the egg problem :)
<qschulz>
and obviously the USB port to use for flashing would be different for each board
<qschulz>
so the question is basically, what is exactly the plan with this migration to docc/boards/<vendor>, what would you like to see happen there?
sszy has quit [Remote host closed the connection]
sszy has joined #u-boot
mmu_man has joined #u-boot
slobodan has quit [Read error: Connection reset by peer]
<Tartarus>
And, uh, rewrite the content as you or someone else has time?
<qschulz>
Tartarus: thx for the confirmation
prabhakarlad has joined #u-boot
prabhakar has joined #u-boot
<qschulz>
does it **have to** be in doc/board/rockchip though? or should/could it rather match what the layout in board/?
<Tartarus>
Well, that depends a little
<Tartarus>
See for example doc/board/ti and doc/board/phytec
<Tartarus>
The phytec ones reference generic TI parts, the imx8 ones don't reference back (iirc) NXP ones as the NXP ones aren't written that way
<Tartarus>
I think the TI way is nicer, but is more prep work
pgreco has quit [Ping timeout: 268 seconds]
<qschulz>
Kwiboo: you made me try to check the SD card read/write on RK3588 as well.... turns out the driver is not even reading most speeds from the device tree, so I'm stuck in SD high-speed
mripard has joined #u-boot
prabhakarlad has quit [Ping timeout: 250 seconds]
cakes has quit [Ping timeout: 256 seconds]
cakes has joined #u-boot
cakes has joined #u-boot
cakes has quit [Changing host]
pgreco has joined #u-boot
mmu_man has quit [Ping timeout: 260 seconds]
mmu_man has joined #u-boot
monstr has quit [Ping timeout: 252 seconds]
pgreco has quit [Ping timeout: 260 seconds]
Leopold has quit [Quit: No Ping reply in 180 seconds.]
Leopold has joined #u-boot
sakman has joined #u-boot
pgreco has joined #u-boot
sakman1 has joined #u-boot
sakman has quit [Ping timeout: 276 seconds]
sakman1 is now known as sakman
monstr has joined #u-boot
sakman has quit [Ping timeout: 276 seconds]
Clamor has quit [Ping timeout: 256 seconds]
Clamor has joined #u-boot
sakman has joined #u-boot
<sjg1>
tlwoerner: Just checking that you have CONFIG_BOOTSTD_FULL enabled?
<sjg1>
tlwoerner: Also see bootmeth_cmd_order() which is the test of all this behaviour
<sjg1>
tlwoerner: It looks like you do have that enabled. I am not sure what is wrong there, but it does seem to be broken
<sjg1>
tlwoerner: So 'bootmeth order' works but 'setenv bootmeths' does not?
monstr has quit [Remote host closed the connection]
frieder has quit [Remote host closed the connection]
<tlwoerner>
sjg1: i can set the boot order using "env set bootmeths ..." but it doesn't seem to be consulted when actually booting
<tlwoerner>
there isn't any difference between "env set ..." and "setenv ..." is there?
<tlwoerner>
sjg1: i'll do a deep dive into it to see, and i'll double check the CONFIG_BOOTSTD_FULL
<tlwoerner>
thanks!
<tlwoerner>
i'm probably messing something else up
<sannis>
Good afternoon. Is this the appropriate channel to ask questions about compilation errors?
<Tartarus>
Sure
<sannis>
Just didn't want to spam anyone out.
mmu_man has quit [Ping timeout: 276 seconds]
<sannis>
Background: I am attempting to resurrenct some old project work for my day job. u-boot (ARM64) with OP-TEE and HAB enabled, everything is building up until I get to the image tools, and in image-fit-sig.c I keep getting linker errors (undefined reference in function )for functions in hab.c w/ prototypes in hab.h.
<sannis>
The board in question is a custom sized NXP i.mx8mp board based on the i.mx8mp_evk.
hanetzer has quit [Quit: WeeChat 4.1.3]
mmu_man has joined #u-boot
prabhakarlad has joined #u-boot
prabhakarlad has quit [Client Quit]
<sannis>
Has anyone seen this issue in older builds? I've google-fu'd my heart out, but I haven't come across anything.
<Tartarus>
Well, pastebin a make V=1
<sannis>
Sure thing, I will do that now ..
jfsimon1981 has joined #u-boot
clarity has quit [Ping timeout: 252 seconds]
clarity has joined #u-boot
Clamor has quit [Read error: Connection reset by peer]
<sannis>
Ok that took longer than expected .. I had to tease the file off my build box ..
<cambrian_invader>
sannis: imx_hav_is_enabled isn't present in that file upstream
<cambrian_invader>
and it really shouldn't be, since a host tool has no hab to speak of
edwinistrator2 has joined #u-boot
edwinistrator2 has quit [Ping timeout: 252 seconds]
edwinistrator2 has joined #u-boot
<sannis>
@cambrian_invader: I am confused by that, I haven't added anything to the source of those files, I've only tried to compile the source as it was given to me. Would you mind clarifying what you mean by imx_hab_is_enabled not being present in the file upstream?
<sannis>
I'm not very good with C, and my normal job is IoT device enablement, so I am a bit out of my comfort zone t-shooting this build.
<sannis>
The error comes from the image-fit-sig.c file which I assume, based on my reading, is trying to confirm that signed binary will fit withing the boot rom flash area.. I don't know if that requires verifying HAB status or not.
<sannis>
or at the very least the image_fit tools are being used for that purpose.
ezulian has quit [Ping timeout: 260 seconds]
<cambrian_invader>
there are no calls to imx_hab_is_enabled in tools/boot/image-fit-sig.c
<cambrian_invader>
if there are any in your version, they have been added by someone else
<cambrian_invader>
I suggest having a look at the git history for that file to determine why they were added
qqq has quit [Quit: Lost terminal]
qqq has joined #u-boot
___nick___ has quit [Ping timeout: 264 seconds]
<sannis>
Thanks, I will take a look ..
mmu_man has quit [Ping timeout: 256 seconds]
mmu_man has joined #u-boot
redbrain has quit [Read error: Connection reset by peer]
redbrain has joined #u-boot
<marex>
sannis: mx8mp with HAB ?
<marex>
sannis: iirc there is some scripting for that in current upstream u-boot , do you do authentication or also encryption (DEK stuff) ?
<sannis>
The work previous work was done by Canonical Hardware Enablement Team on a previous prototype ..
<sannis>
So the scripting to stream in HAB and OP-TEE is part of the snapcraft.yaml file feeding the build scripts.
<sannis>
all of that is based on the Raspberry Pi device gadget and Ondra Kubik (Canonical) wrangled the imx-gadget snap design. I am starting from that point with some new dtb's ..
<sannis>
@cambrian_invader thanks.. that pointed me where I needed to go to clear up those undefined references .. Also @marex, yeah .. no idea .. I inherited the jungle, now I am just trying not to burn it down..
<sannis>
@marex Thanks for the reference docs.. much appreciated.
<marex>
which U-Boot version is this ?
jfsimon1981 has quit [Remote host closed the connection]
jfsimon1981 has joined #u-boot
<sannis>
@marex 2023.04
<sannis>
Or that is the reference from the head.. 2023.04-6.1.36-2.1.0
* sannis
shrugs
<marex>
oh, that's NXP downstream fork with some 300+ kLoC of changes compared to mainline 2023.04 and still vulnerable to CVE-2023-39902 which effectively disables security ?
<sannis>
LOL ... sounds about right.
<sannis>
NXP's source trees are .. at best confusing..
slobodan has quit [Ping timeout: 276 seconds]
<sannis>
Thanks for the insights, I appreciate it.. I will try a clean source tree from the upstream and see if I can wrangle it in place.
ldevulder_ has joined #u-boot
ldevulder has quit [Ping timeout: 255 seconds]
sannis has quit [Ping timeout: 260 seconds]
jfsimon1981 has quit [Remote host closed the connection]