<Peng_Fan>
marex, oh. that is weird. If compiler matters, there might be some gcc optimization or SM code not strong
frytaped has joined #u-boot
<rfs613>
Forty-Bot: I don't see UCLASS_PCS, however, the zynq one uses UCLASS_PHY (as opposed to UCLASS_ETH_PHY), which has both set_mod() and set_speed() which might work for what I need.
hanetzer has quit [Ping timeout: 248 seconds]
<rfs613>
so thanks for the tip, I'll start there.
hanetzer has joined #u-boot
Daanct12 has joined #u-boot
<Forty-Bot>
rfs613: that's for serdes iirc
<rfs613>
Forty-Bot: yep, it wasn't the one I was expecting, but it might work. Will try tomorrow.
<rfs613>
(I mean the API might work, not the actual code in that driver)
<Forty-Bot>
tbh I would just grab the PCS API from Linux
<Forty-Bot>
but either way I think you're going to have to do some plumbing
joeskb7 has quit [Ping timeout: 260 seconds]
Daanct12 has quit [Ping timeout: 244 seconds]
qqe has joined #u-boot
joeskb7 has joined #u-boot
mmu_man has quit [Ping timeout: 252 seconds]
Daanct12 has joined #u-boot
goliath has joined #u-boot
sakman has quit [Remote host closed the connection]
sakman has joined #u-boot
monstr has joined #u-boot
sakman has quit [Quit: Leaving]
sakman has joined #u-boot
mckoan|away is now known as mckoan
naoki has quit [Quit: naoki]
naoki has joined #u-boot
ikarso has joined #u-boot
ldevulder has joined #u-boot
<marex>
Peng_Fan: using -O3 in SM Makefile is weird
<marex>
Peng_Fan: I switched it to -Os but that made no difference
<Peng_Fan>
marex: what is your build command?
<marex>
make SM_CROSS_COMPILE=arm-none-eabi- V=y M=2 config=mx95evk -j65 all
<Peng_Fan>
marex, ok, which version toolchain are u using?
<Peng_Fan>
marex, I am using gcc version 12.3.1 20230626 (Arm GNU Toolchain 12.3.Rel1 (Build arm-12.35))
<marex>
the non-working one matches what is suggested in doc/board/nxp/imx95_evk.rst in the MX95 patchset
dsimic has joined #u-boot
<marex>
and the arm-none-eabi-gcc 13.3 in debian/testing and newer is also non-working
<marex>
(the same toolchain source, packaged by debian)
<marex>
so that hints at something odd going on with the 13.3.y version
<Peng_Fan>
marex, ok. we internal use 12.3.Rel1. I will check with Alice on the toolchain she use.
<Peng_Fan>
For 13.2, or 13.3, I will give a try at my side.
<marex>
Peng_Fan: thank you
<Peng_Fan>
marex, no problem
<Peng_Fan>
marex, I just give a try with 14.2, the latest one. Only compiled imx-sm, no issue.
sszy has joined #u-boot
<marex>
Peng_Fan: maybe it is broken with 13.3.y specifically ?
<Peng_Fan>
marex, Alice told me, she tested the toolchain used in imx95_evk.rst
<marex>
Peng_Fan: can you give the 13.3.y a try too ?
<Peng_Fan>
marex, sure
<marex>
Peng_Fan: thank you
<marex>
Peng_Fan: dont forget to run some 'git clean -fqdx' in the SM source to clear out any stale stuff
<marex>
Peng_Fan: and make sure it picks up the right compiler version
<marex>
I'll be back in a bit
<Peng_Fan>
marex, I use "rm -rf build" to clean the out.
<Peng_Fan>
ok
<marex>
Peng_Fan: I use 'git reset --hard ; git clean -fqdx' , that scrubs everything
sszy has quit [Ping timeout: 246 seconds]
<Peng_Fan>
marex, with 'git clean -fqdx' and arm-gnu-toolchain-13.3.rel1-x86_64-arm-none-eabi/bin/arm-none-eabi-gcc, it still work on my board.
sszy has joined #u-boot
naoki has quit [Quit: naoki]
naoki has joined #u-boot
qqe has quit [Quit: Lost terminal]
<marex>
Peng_Fan: hum, odd, I guess I'll have to take a look at the difference between the generated binaries
<marex>
Peng_Fan: thanks for checking
xroumegue has quit [Ping timeout: 252 seconds]
prabhakalad has quit [Quit: Konversation terminated!]
prabhakalad has joined #u-boot
xroumegue has joined #u-boot
m5zs7k has quit [Ping timeout: 252 seconds]
m5zs7k has joined #u-boot
mmu_man has joined #u-boot
goliath has quit [Quit: SIGSEGV]
goliath has joined #u-boot
naoki has quit [Quit: naoki]
rvalue has quit [Read error: Connection reset by peer]
monstr_ has joined #u-boot
monstr has quit [Read error: Connection reset by peer]
rvalue has joined #u-boot
<calebccff>
sjg1: do you have any issues with dropping UCLASS_SMEM as per lore.kernel.org/u-boot/20241124-b4-modernise-smem-v1-0-b7852c11b67c@linaro.org ?
<calebccff>
it's implemented as some generic interface despite really being a qualcomm specific feature, and we need it to be available early since we can retrieve the memory map from there
<sjg1>
calebccff: Not really. I like the shared code with Linux. But we do need to find a way to move this out of fdtdec_setup()
frytaped has quit [Ping timeout: 248 seconds]
Daanct12 has quit [Quit: WeeChat 4.4.4]
<calebccff>
sjg1: for sure, something for a different series though heh
<calebccff>
any chance i could get some acked-by's? and would it make sense to take that series through the qcom tree?
<sjg1>
calebccff: Yes to both, from my POV. I'll take a look a bit later
<calebccff>
ok, thanks
joeskb7 has quit [Quit: leaving]
joeskb7 has joined #u-boot
zsoltiv_ has quit [Ping timeout: 244 seconds]
<sjg1>
calebccff: One question from looking through it: I am unsure why you cannot parse the memory map / read serial number with SMEM as a driver?
yann-kaelig has joined #u-boot
<RoganDawes>
Marex: thanks for the response, I have looked at https://github.com/u-boot/u-boot/blob/master/doc/imx/habv4/guides/mx6_mx7_secure_boot.txt, but it makes no mention of mfgtool, uuu, or Serial Download Protocol (SDP). Section F.1 of AN4581 is specifically talking about preparing an image for use when downloading via UART or USB. And hence my question
<RoganDawes>
about whether the removal of the DCD data is strictly required, or merely advised in this specific case.
<calebccff>
sjg1: in theory we could, but since we'd have to manually probe the driver from mach-specific code anyway and we have no use for a udevice object (there is only ever one SMEM, it's global and accessed from devices which have no way to get an OF handle) it's just overhead
<calebccff>
the kernel doesn't handle this super well either, things that need smem just have to -EDEFER until it's available and wait for the kernel to probe it
goliath has quit [Quit: SIGSEGV]
yann-kaelig has quit []
<sjg1>
calebccff: Well it seems that there is no particular need to drop the driver, other than to follow Linux. That seems reasonable to me
<sjg1>
calebccff: But I don't like the huge changes for U-Boot and I think you should expand the linux/compat.h etc. to reduce the number of changes. Otherwise, what's the point?
<sjg1>
calebccff: Just as an example on the first point, video drivers are bound before relocation so we can find out how much memory they want
<sjg1>
calebccff: I suppose you know this, but U-Boot binds devices in a separate step and nothing is allowed to probe devices until everything is bound (although some drivers are bound when their parents are probed)
<sjg1>
calebccff: Anyway, I'll send my review tags and you can take a look in a follow-up if you like
<calebccff>
sjg1: yeah, i don't think either solution is really perfect but im hoping my proposal here is at least a big step in the right direction
<calebccff>
regarding compat.h that's a fair point, i would for sure like to see that be improved on
<calebccff>
might take another look at barebox for inspiration there
alpernebbi has quit [Ping timeout: 276 seconds]
<sjg1>
calebccff: OK ta. If I were doing it, I would probably leave it as a driver and try to encourage others to use it, but I'm not sure if others would...also I'm not doing it
<sjg1>
calebccff: Re the OF stuff, I wonder if we should start allowing 'livetree-only' code?
<Slimey>
everybody gansta until the magic smoke escapes
swiftgeek has quit [Ping timeout: 260 seconds]
mmu_man has quit [Ping timeout: 252 seconds]
<marex>
RoganDawes: iMX HAB signing and encryption is done using CST (code signing tool)
<marex>
uuu or mfgtool implement SDP/SDPS , the USB upload protocol, different thing
manawyrm has quit [Quit: Read error: 2.99792458 x 10^8 meters/second (Excessive speed of light)]
mmu_man has joined #u-boot
<sjg1>
xypron: Just wanting to discuss the test failure: