We have developed our own custom carrier card for the AGXi, one deviation we have here is that we do not use the MGBE or a standard MAC/PHY configuration, we connect the RGMII to a KSZ switch, I will attach a snippet showcasing what this looks like in the dts we use.
However we run into an issue where if the ethernet node is enabled it will complain that FMON_EQOS_RX is not expected, for this I have disabled the networking stack entirely (or so I think) in the edk2 config.
but this still does not allow the module to boot, I’ve attached the logs of 2 boot attempts, one with ethernet enabled and one with ethernet disabled, the only difference between these boots is the status property being either okay or disabled for ethernet@2310000 (nveqos)
It’s all identical up to when I’d expect “Jetson UEFI firmware” to be printed, this never happens and it just gets stuck.
I really hope some light can be shed on what’s going on here as this is becoming a huge issue for us that we cannot get the ethernet functional.
I’m investigating using extlinux to try make it UEFI boot with ethernet disabled and enable it in Linux, but this is really not ideal even if it works.
Yes that is what I’m investigating now, but I’d also really like to understand what the issue here is, I also don’t know if me disabling the ethernet for the boot chain will give me any issues when then having this enabled only in Linux (e.g. does BPMP or any other boot component look at this?)
Yes I’m quite sure of this, the only difference between both logs is the ethernet@2310000 (nveqos) device tree node being either disabled or enabled.
It indeed doesn’t make much sense to me either, hence I’m coming here with the hope of getting some understanding of what is going on or what could be wrong.
Yes I did try that, and it does get past the UEFI if I do so, and from the log I think it boots the Linux, however I lose all logging at that point and I cannot get the console, I’m not sure what needs to be changed there, it’s just using the ttyTCU0 as console.
What you are doing shall not affect any log from UART side. Could you clean up your BSP to near the original one and do minimal change to make sure the behavior you saw here is reproducible?
It currently suspect an issue with the dts compilation not being consistent and the TCU not being enabled (which I didn’t spot initially, assuming ttyTCU being assigned console was enough)
As to why it would then sometimes show a console over it, and sometimes not, I’m gearing towards the dts compilation being funky, which I’ll try to verify for myself today, but I think the issue can be closed for the time being