<marex>
Peng_Fan: bootstd is deprecated I think, use bootmethod
mmu_man has quit [Ping timeout: 244 seconds]
<marex>
Peng_Fan: also, the mx95 stuff from Alice, is that supposed to boot on the toradex evk ?
<Peng_Fan>
marex, thanks for reminding. I have not looked into details of bootstd (: But with bootmeth, seems needs extlinux or boot.scr which not used on i.MX
<Peng_Fan>
we not try the i.MX95 patchset on toradex board, I think it should work
<marex>
Peng_Fan: there is another board ?
<marex>
Peng_Fan: I was under the impression the 19x19 is the ... toradex board ?
<Peng_Fan>
marex: nope, the current i.mx95 patchset is for i.MX95 19x19 EVK board. Not i.MX95 toradex board
<marex>
Peng_Fan: re bootmethod ... I think you should be able to define a flow to boot without extlinux, ask sjg1
<Peng_Fan>
toradex board reuses most of the code from i.MX95 19x19 EVK, I think the current patchset should be able to boot toradex board, but we have not tried that.
<Peng_Fan>
marex, thanks, I will reply sjg1 in mail.
<marex>
Peng_Fan: is there some picture of the 19x19 board somewhere ?
<marex>
Peng_Fan: yes, that is what confuses me ... 19x19 verdin :()
<marex>
:)
<Peng_Fan>
the toradex board reuses most code from 19x19 evk, so technically the current under reviewing patchset should be able to boot on toradex board
<marex>
Peng_Fan: wait ... 19x19 is the SoC package size ?
<Peng_Fan>
marex, right!
<marex>
ah, I see
<marex>
lemme check if I need to build different OEI or something for this
mmu_man has joined #u-boot
<marex>
thing is, I get messages from DDR OEI and TCM OEI that init was done, err = 0x0, but nothing more (no RTOS and no U-Boot)
<Peng_Fan>
marex, ah. oei are same for evk and verdin, sm is same, ele is same
<Peng_Fan>
After OEI, there will be SM log output. If no SM log output, there must be something wrong.
<Peng_Fan>
marex, did you give a try using imx-mkimage to pack the images?
<marex>
I followed doc/board/nxp/imx95_evk.rst
<marex>
I applied the patchset from Alice and just went by the README for now
<Peng_Fan>
marex, not sure there is bug in imx8image to support imx95 or not. To use imx-mkimage, just put all the stuff under imx-mkimage/iMX95, and make SOC=iMX95 clean; make SOC=iMX95 flash_lpboot_sm_a55 LPDDR_TYPE=lpddr5 OEI=YES
<Peng_Fan>
I could give a look later today, but not have much time.
<marex>
Peng_Fan: where do I get the imx-mkimage from ?
<rfs613>
Looking for some guidance on which UCLASS_xyz to use for a ethernet media converter. It's not an ethernet (UCLASS_ETH) and its not a PHY (UCLASS_ETH_PHY), but it sits between them and converts the MII/GMII/RGMII signals. Whenever the PHY detects link, this device needs a few registers programmed (speed, duplex, etc).
<rfs613>
On the linux side, it is handled using PCS (Physical Coding Sublayer) and the driver makes use of device_link feature, but that doesn't exist in u-boot AFAIK
<SlimeyX>
dujem right on the money looks like "powerpc-fsl-linux-gcc (GCC) 4.9.2"
<SlimeyX>
GNU ld (GNU Binutils) 2.25
<SlimeyX>
marex yup i think i found them
mmu_man has quit [Ping timeout: 248 seconds]
mmu_man has joined #u-boot
mmu_man has quit [Ping timeout: 265 seconds]
mmu_man has joined #u-boot
_whitelogger has joined #u-boot
<marex>
rfs613: I think xilinx zynq has something like that for GMII
<marex>
rfs613: I also think it is supported, it might be some uclass misc
<rfs613>
marex: thanks, I did see UCLASS_MISC but figured I'd ask if there was something better
<rfs613>
i'll poke around the zynq to see if I can find their media converter (think I worked with that a while back even!)
<marex>
rfs613: their MAC IP is from cadence I think
<rfs613>
also sounds familar... i workd on the first-gen zynq maybe a decade or so ago...
rvalue has quit [Read error: Connection reset by peer]
rvalue has joined #u-boot
RoganDawes has joined #u-boot
<RoganDawes>
Does anyone have experience with HAB on imx6? I'm trying to understand Section F.1 of AN4581, describing how the image needs to be signed to use with mfgtool. In particular, how the DCD needs to be cleared first before being signed, but then the DCD value needs to be reinstated before being downloaded. This section in particular has me wondering,
<RoganDawes>
whether is is absolutely required, or just recommended, to avoid trying to reinitialise the DDR?
<RoganDawes>
> The pointer to the DCD table is cleared in the IVT in order to prevent the HAB library from processing the DCD table again during the authentication process. There is no need to reinitialize some memory, such as DDR3, when it already contains valid data.
<RoganDawes>
For reference, I am trying to access a HABv4-protected device, which has been locked down to prevent access to u-boot or a linux shell. I have a copy of the flash chip, as well as console and USB/SDP access to the device.
<sjg1>
rfs613: You are permitted to add a new uclass :-) Perhaps UCLASS_ETH_CONV ?
<sjg1>
rfs613: The important thing is to define the API carefully, although typically people can update it later if needed for particular chips / features
<marex>
Peng_Fan: FYI it is something with the SM that is not right, if I pull SM binary from OE build, I can reach U-Boot
<marex>
Peng_Fan: I am investigating
<Forty-Bot>
rfs613: UCLASS_PCS if we have it
<Forty-Bot>
the zynq thing is a phy but really should be a PCS
<marex>
RoganDawes: HAB on MX6, read U-Boot doc/imx/habv4/guides/mx6_mx7_spl_secure_boot.txt
<marex>
doc/imx/habv4/guides/mx6_mx7_secure_boot.txt for non-SPL case
naoki has joined #u-boot
umbramalison_alt has joined #u-boot
umbramalison has quit [Ping timeout: 276 seconds]
ldevulder has quit [Quit: Leaving]
goliath has quit [Quit: SIGSEGV]
<marex>
Peng_Fan: so ugh, it seems that if I compile SM with arm-none-eabi-gcc 13.2.y then it works, if I use 13.3.y it does NOT work