<jurc192[m]>
Does anyone here use U-Boot on Raspberry Pi 4B ? I am trying to understand the difference between `fdt_addr_r` and `fdt_addr`, but can't find any documentation/explanation...
<Guest30>
marex, you was right. I've fixed issue by adding "u-boot,dm-pre-reloc" to "pinctrl_uart0: uart0grp {" section.
<Guest30>
thanks for help!
jordemort has quit [Quit: Bridge terminating on SIGTERM]
LinuxHackerman has quit [Quit: Bridge terminating on SIGTERM]
hthiery has quit [Quit: Bridge terminating on SIGTERM]
alone[m] has quit [Quit: Bridge terminating on SIGTERM]
Dhruvagole[m] has quit [Quit: Bridge terminating on SIGTERM]
MartijnBraam[m] has quit [Quit: Bridge terminating on SIGTERM]
cpackham[m] has quit [Quit: Bridge terminating on SIGTERM]
[0x4A6F] has quit [Quit: Bridge terminating on SIGTERM]
samueldr has quit [Quit: Bridge terminating on SIGTERM]
kallisti5[m] has quit [Quit: Bridge terminating on SIGTERM]
jurc192[m] has quit [Quit: Bridge terminating on SIGTERM]
mvaittin has quit [Quit: Bridge terminating on SIGTERM]
kaji has quit [Quit: Bridge terminating on SIGTERM]
ladis has quit [Ping timeout: 268 seconds]
Guest30 has quit [Quit: Client closed]
cpackham[m] has joined #u-boot
EdSwarthout has quit [Remote host closed the connection]
cpackham[m] has quit [Quit: Client limit exceeded: 20000]
mvaittin has joined #u-boot
samueldr has joined #u-boot
kallisti5[m] has joined #u-boot
kaji has joined #u-boot
Dhruvagole[m] has joined #u-boot
jurc192[m] has joined #u-boot
LinuxHackerman has joined #u-boot
hthiery has joined #u-boot
MartijnBraam[m] has joined #u-boot
LinuxHackerman has quit [Quit: Client limit exceeded: 20000]
alone[m] has joined #u-boot
[0x4A6F] has joined #u-boot
jordemort has joined #u-boot
samueldr has quit [Quit: Client limit exceeded: 20000]
ilunev has quit [Remote host closed the connection]
stefanro has quit [Quit: Leaving.]
stefanro has joined #u-boot
<rfs613>
jurc192[m]: fdt_addr is the address of the FDT in the flash memory, while fdt_addr_r is the adddress in memory where it gets loaded. Though this is just a convention. I have no idea what RPi does...
cpackham[m] has joined #u-boot
samueldr has joined #u-boot
LinuxHackerman has joined #u-boot
tnovotny has quit [Quit: Leaving]
<Tartarus>
sjg1: around?
mckoan is now known as mckoan|away
<sjg1>
Tartarus: Hi
<Tartarus>
sjg1: Hey, got scrollback to see the debug log I pasted Wednesday? I've got a platform where booti has one sequence during DM usb_stop() that results in everything being shut down, but via bootefi it does not and so the system crashes
<Tartarus>
And I'm looking for any specific advice on debugging that
<Tartarus>
I think it looked like we somehow never found the root hub, for some reason
<Tartarus>
It's an xhci platform (j721e_evm_a72 specifically)
<sjg1>
Tartarus: Yes I see it. I thought xypron said the answer was that the EFI boot inits all USB devices?
lucaceresoli has quit [Quit: Leaving]
<sjg1>
Tartarus: Oh you mean it doesn't do the usb_stop:202 when it fails?
<Tartarus>
sjg1: Right, it's not behaving correctly
<Tartarus>
Other platforms have everything shut down normally
<Tartarus>
But xypron didn't report back on another xhci rather than ehci system
<Tartarus>
and I didn't yet try seeing what happens on say amlogic since my pine-a64 system is so crazy
<Tartarus>
(and my other TI platform would almost certainly also hit this, being the same SoC family)
<sjg1>
Tartarus: OK, can you push the tree somewhere so I can check the line numbers? I have a pine 64 somewhere so could try that. What distro is it?
<Tartarus>
Note that pine should work as xypron tested a different sunxi platform with EHCI and it behaves as expected
<Tartarus>
Something else with xhci would be interesting to see
<Tartarus>
Which is why I do need to dig out and see about lab'ing for real my le potato as that's xhci too
<Tartarus>
So that'd show xhci vs platform being the problem
<sjg1>
Tartarus: Ah OK I see, so XHCI. I think coral is XHCI. I'll have a crack tonight/tomorrow
<Tartarus>
OK, thanks
ilunev has joined #u-boot
ilunev has quit [Remote host closed the connection]
ilunev has joined #u-boot
<mwalle_>
rfried: sorry for being so harsh, but I have the impression that half baked things are getting in too fast. I don't know if I should care right now, but I have a feeling this will bite me in the future
<rfried>
@mwalle_: can you give an example of such things ?
guillaume_g has quit [Quit: Konversation terminated!]
mmu_man has joined #u-boot
<mwalle_>
rfried: besides that the "net list" fix will have undesired side effects?
<mwalle_>
although it could be fixed in a better way?
<mwalle_>
well that macb compatible topic which almost introduced a new compatible just for u-boot
cambrian_invader has quit [Ping timeout: 260 seconds]
<rfried>
mwalle_: I didn't approve that compatible patch.
<mwalle_>
rfried: I didn't imply you did
mwalle_ is now known as mwalle
<mwalle>
rfried: now what should i do about that "we pass the random mac address to linux" patch?
<rfried>
mwalle: OK. for the compatible patch, people send bad patches, I didn't even review it, I don't understand why you even mentioned that patch.
<rfried>
Regarding the net list, I missed your answer, but I concur with Michal. I think that patch is in place. I do agree that this needs to be documented.
<rfried>
I will ask Michal add a documentation for that.
<mwalle>
rfried: my complain wasn't specically for networking, but for u-boot in general
<mwalle>
and that macb was just the latest one i remembered from the top of my head
<rfried>
mwalle: you pointed you complain to me, I'm answering.
<mwalle>
rfried: and regarding that net list patch, I'm still not sure it will be that good to do it that way
<marex>
oh ... is this the next episode of "friday maintainer bashing" ?
<mwalle>
no one answered why net list couldn't be fixed in a different way
<mwalle>
instead of changing behavior
<rfried>
mwalle: you have bizzare scenario where for some-reason you want u-boot and Linux not to share the same MAC-Address.
<mwalle>
rfried: so its ok to do so?
<mwalle>
lol
<rfried>
yes, the only reason it used to "work" for you, is because the environment wasn't exported internally in U-boot. that's a bug in u-boot.
<mwalle>
nobody cared, only until the net list was broken, and now its fixed in a way it will change mac handlin in lnux
<marex>
"half baked things are getting in too fast" ... ok, what else is new ?
<rfried>
where do you get the MAC address in Linux, in your setup ?
<mwalle>
rfried: OTP
<mwalle>
from SPI flash
<marex>
mwalle: cant uboot read OTP and patch the MAC address into DT as on all platforms ?
<rfried>
so, why can't you use that in U-boot. why do you use random value ?
<mwalle>
marex: sure it can, but there is no support for it
<marex>
mwalle: dang ... what should we do about that ?
<rfried>
I see 2 possibilties. either we add support.
<mwalle>
but i don't get why u-boot should generate a random mac address and pass that one to linux
<rfried>
or before you boot, you add to your scripts: env delete macaddr....
<marex>
mwalle: CONFIG_NET_RANDOM_ETHADDR=y because of this ?
<mwalle>
marex: well add support, but i dont have time
<rfried>
If I recall correctly, the fixup is per board, it's not generic to u-boot.
<marex>
mwalle: OK, I stop here ... collaborative project depends on contributor activity => no contributor activity, it is all pointless, you know the drill
<mwalle>
anyway, i said, i don't care for now. i just wondered that the patch got in without any further answer
<marex>
mwalle: which patch ?
<marex>
mwalle: got patchwork link ?
<rfried>
mwalle: ask I said, your answer slipped, and I missed it. but I stand behind that patch.
<mwalle>
ok i see myself adding yet a new kconfig option to not pass that random mac address to linux
<marex>
rfried: I feel it is part of the same problem -- maintainers are busy, the current situation doesn't help it, so people make mistakes -- it's hard to blame anyone here
<marex>
rfried: the only way out of this is to get more reviewers/contributors/etc. ...
<rfried>
mwalle: I don't think a new kconfig solves that. just delete the environement variable or add a patch specific to the board not to patch the fdt.
<mwalle>
my intention wasn't to blame anyone actually. actually i said sorry above. took a wrong turn. so sorry again. I'm just a dissatified
<marex>
mwalle: or you fix it properly and upstream the fix, because that's what all the other people "who had time" did and therefore you can now use the code you use ...
<marex>
that's really the only way
<marex>
mwalle: yes, I agree, blaming people use pointless, it gets us nowhere
<mwalle>
marex: see here, i have the feeling i'm running after all these this, and try to do it correct (at least in my opinion), but i've asked that explicitly and there was never an answer if it can be done differently
<marex>
mwalle: didn't rfried just say it was missing ?
<marex>
mwalle: can you send a subsequent patch ?
<mwalle>
marex: no it was a question for michal
<mwalle>
marex: did you find the patch? or still need a pw link
<marex>
mwalle: I also have a feeling I am fixing things all the time, and it has me concerned too
<marex>
mwalle: it shows there is a large adoption of u-boot and there is upstreaming going on, but there is too little testing
<marex>
can we do better ? yes ... but not without help from the contributors
<marex>
mwalle: I need a link still
<marex>
mwalle: it seems Michal was away this week btw, I couldn't reach him either ...
<marex>
mwalle: I agree with rfried , the fix should be on your board level, let's not add un-maintain-able hacks please
<marex>
mwalle: can't you add "env set -f ethaddr" into your bootcmd ?
<marex>
(as a stop-gap measure that is) ?
<marex>
rfried: indeed, I agree
<mwalle>
no i can't because actually i'd like to allow users to overwrite the mac address
<marex>
mwalle: but you can, can't you ?
<marex>
mwalle: env set -f ethaddr 00:aa:bb:cc:dd:ee
<marex>
that still works, doesn't it ?
<marex>
that ^ would get propagated to Linux then
<mwalle>
and then? if bootcmd has the "env set -f ethaddr" it will be cleared again
<marex>
env set -f ethaddr ${custommacaddr} then ... and either set or not set custommacaddr
<mwalle>
please note, that this isn't your typical embedded board
<mwalle>
but it should be used with EFI (or maybe plain distro boot) and there shouldn't be any magic
<marex>
mwalle: in that case, you really should fix the retrieval of correct MAC address from the SPI NOR
<marex>
else you always have this fragile crap underneath
<mwalle>
marex: what if i don't need ethernet at all
<mwalle>
in uboot
<mwalle>
anyway, i think i don't care at the moment (sorry!)
<marex>
mwalle: then you still get the correct MAC address and that gets correctly passed to Linux
<mwalle>
the mac addresses are passed in registers for this ethernet controller, and the nvmem part in linux will take precedence
<marex>
mwalle: I guess I wouldn't bother trying to find a workaround, I would just write the OTP access in u-boot too and move on
<marex>
mwalle: if I understand that patch, it basically fixes the problem where you either have no MAC address passed to Linux at all, or the same random one as U-Boot ... hum
<marex>
if you;re using random MAC anywhere, it is already iffy
<mwalle>
marex: but the patch is for fixing "net list"
<mwalle>
marex: right, and thus it should be u-boot only. linux will generate its random mac address (or use other means)
<marex>
mwalle: the commit message is iffy indeed
<mwalle>
like reading OTP or SoC otp registers
<marex>
mwalle: it seems to fix more than that
<mwalle>
but with that patch in place, linux wont do that anymore
<marex>
mwalle: well that's the thing -- MAC address is interface specific, so why should it be different between u-boot and linux ?
<marex>
I think you rather want it to be the same , otherwise you have all these ARP request for suddenly dead machines floating around
<mwalle>
marex: it shouldn't in the normal case
<marex>
mwalle: ah, so the MAC set up by U-Boot takes precedence over the NVMEM in your case in Linux ?
<mwalle>
marex: iff there is a mac-address property (or local-mac-address) property in the DT, it will be fixed up by u-boot with the random mac address
<mwalle>
and linux won't notice that it will be randomly generated, so yes
<marex>
mwalle: well ... make u-boot patch in the right thing ... then the entire stack works as it should work
<mwalle>
what is patching the right thing?
<marex>
the MAC address from the NVM, no ?
<marex>
or MAC address set in ethaddr , which should be default set from the NVM
<marex>
and if user overrides it, then the overriden mac is also passed to Linux
<rfried>
marex/mwalle: random MAC address are very bad approach that only works in labs. one time we had a problem in our office that machine couldn't get IP's through DHCP. it appears that a U-boot configured with random exhausted all IP-Addresses.
<rfried>
The router was configured to hold IP's for MAC's at least for few hours.
<mwalle>
as I said, for my board, I don't really care (I guess, so far). Its about the general case. linux might have its own way of handling missing mac addresses, but this now will never be triggered
<rfried>
now all our boards in the lab get a dedicated MAC address, we don't use random at all.
<rfried>
again, it's only for your specific board.
<mwalle>
why is that?
<mwalle>
most boards have mac-address = [ 00 00 00 00 00 00 00 ]; /* fixed up by bootloader */
<rfried>
I'm not sure it's correct. let me check.
<mwalle>
now before, this should still be the zero mac, and linux will do whatever the network driver will do if it gets the zero mac and afterwards, it will just see a "normal" looking mac address, which is in fact randomly generated by u-boot
<marex>
mwalle: mac address 0 is special
<marex>
mwalle: see is_valid_ethaddr() in u-boot
<mwalle>
marex: what do you mean?
<marex>
833 static inline int is_valid_ethaddr(const u8 *addr)
<marex>
mwalle: random mac address is also bogus, because you fill other stations' ARP tables with nonsense entries, which might even collide with other stations on the network segment
<rfried>
mwalle: I stand corrected, all the boards are fixed-up. nevertheless. how hard will it be to add OTP support for U-boot for that specific board ?
<mwalle>
rfried: there is no OTP support in u-boot at all, so I don't know (i did the support in linux but anyway). and yes, i agree it is missing, just because u-boot should use the same mac addresses. But that wasn't (or isn't) my concern here
cambrian_invader has joined #u-boot
<marex>
mwalle: what do you mean by "no OTP support in U-Boot" ?
<marex>
mwalle: there is OTP support for all of iMX, stm32, and multiple other devices
<mwalle>
marex: spi-nor has no otp support
<marex>
mwalle: oh, is that the command 0x42 or 0x44 ?
<mwalle>
ah, i'm not talking about the efuses in the SoC
<mwalle>
marex: dunno, there are at least two different mechanism between the flash vendors
<marex>
the SPI MEM subsystem in U-Boot is very much the same as in linux
<mwalle>
marex: i know, and i know pratyush very well ;)
<marex>
the code should be a matter of copy-paste
<marex>
mwalle: so ...
<marex>
mwalle: instead of discussing this here, you could've already been half-way through implementing that ;-)
<marex>
(I was looking into that SPI NOR OTP registers recently too)
<mwalle>
marex: doesn't change the fact that it just hides the problem then, where u-boot will silence the kernel workarounds for missing mac addresses
<marex>
mwalle: not really, u-boot and linux will share the MAC address and u-boot will pass the MAC to Linux as usual (via DT)
<marex>
mwalle: U-Boot will still warn the user if there is invalid MAC address in the SPI NOR OTP register(s) and/or in $ethaddr
<mwalle>
marex: well there was a valid point that you usually, don't look at u-boot console output but at dmesg
<marex>
mwalle: what ?
<mwalle>
if u-boot will generate a random mac address and pass that to linux, then there will be no warning in dmesg
<marex>
mwalle: then disable that RANDOM mac config option and u-boot will not pass in any MAC address
<marex>
mwalle: in which case, you either get no MAC at all, or valid one
<mwalle>
marex: but i really want that for u-boot network connectivity in worst case (and that was what the RANDOM_ETHERNET config option was for until recently)
ilunev has joined #u-boot
<mwalle>
to not create even more fuzz, i'm giving up now
<marex>
mwalle: what is the "worst case" ?
<marex>
mwalle: SPI NOR has no valid address in OTP ?
<mwalle>
rfried: and sorry again!
<mwalle>
marex: production environment for example
<marex>
mwalle: and that production environment cannot set u-boot env ?
<marex>
and/or you cannot do if !mac ; then setenv mac ; fi in some preboot script ?
alan_o has quit [Ping timeout: 264 seconds]
<marex>
come on
<mwalle>
marex: then why is there that RANDOM_ETHERNET thingy at all
<mwalle>
you make it sound like its nonsense
<rfried>
mwalle: np. good night
<marex>
mwalle: I might be a bit grumpy after listening to "billion reasons why things cannot be done" for a while recently ...
<marex>
not from you obviously, it just makes me unhappy
cambrian_invader has quit [Ping timeout: 268 seconds]
<marex>
mwalle: can;t you somehow expose the random ethaddr on command line and assign random ethaddr only in specific cases where it really is needed, not always ?
<mwalle>
marex: maybe for a valid reason look at board/buffalo/lsxl/lsxl.c
<marex>
mwalle: where exactly ?
<mwalle>
marex: rescue mode
<marex>
env_set("bootsource", "rescue");
<marex>
and that needs random MAC address why ?
<marex>
(can't you assign the random mac address there in code just by calling that random mac function?)
<mwalle>
marex: its explained in the header why you'd need one (or you'd need *any*), because you need netconsole
<mwalle>
marex: and yes, probably you can just assign one in the code, it was an example why you need a random one
<marex>
235 static void rescue_mode(void)
<marex>
237 printf("Entering rescue mode..\n");
<marex>
236 {
<marex>
238 env_set("bootsource", "rescue");
<marex>
239 }
<marex>
mwalle: I know there are cases where random MAC address may be useful (even though it often becomes more annoying than useful after a few reboots), I just don't think enabling it indiscriminately is a great idea
<marex>
mwalle: and in your case, it looks like the SPI NOR OTP readout in u-boot is the way to go ... or ?
<mwalle>
marex: iirc that was actually the first board which also introduced it
<marex>
mwalle: I can see how you could easily make u-boot pass in some extra DT property indicating the MAC is random to linux
<marex>
but that;s something you'd better check with robher ^
<mwalle>
marex: hahaha :p
<mwalle>
marex: first i need to get the last 1% to actually fetch linux the mac address from otp :p
<mwalle>
because, i'm unlucky and just have the base mac in OTP. and i have serveral NICs and some need an offset
alan_o has joined #u-boot
___nick___ has quit [Ping timeout: 245 seconds]
vagrantc has joined #u-boot
mmu_man has quit [Ping timeout: 265 seconds]
cambrian_invader has joined #u-boot
<Tartarus>
sjg1: New problem! test_dm.py, test_dm_compat fails on amlogic over 'meson-gx-gpio' not being in dm compat, only dm tree. And I see meson-gx-gpio has a match in drivers/pinctrl/meson/pinctrl-meson-gx-pmx.c so what's missing?
mmu_man has joined #u-boot
cambrian_invader has quit [Ping timeout: 268 seconds]
<sjg1>
Tartarus: Re meson I don't believe that can happen as no device can be created without a driver, so can you share the test output?
<sjg1>
Re the second, yes it seems like this should be in the PHY uclass
<sjg1>
Tartarus: Which actually has a sandbox driver so I don't see much concern about breaking stuff
redbrain has quit [Ping timeout: 256 seconds]
<Tartarus>
sjg1: Can you please chime in there?
<Tartarus>
and re meson, ok, I'll log the whole thing, but it's visible in dm tree and not dm compat
<Tartarus>
and reproducible
<sjg1>
Tartarus: OK, chimed
<sjg1>
Tartarus: Re meson, there is some strange goings on in meson_pinctrl_probe(). The code doesn't look completely wrong from a quick look, but it is quite odd
agust has quit [Quit: Leaving.]
<sjg1>
Tartarus: Also I reviewed it at the time...
<Tartarus>
Meson? Yes, it's working, seemingly, but I just put my libretech-cc in to the lab, since that's also arm64+xhci, so I could also poke that bug
<Tartarus>
And my initial testing also includes firing off pytest and hit that :)