<mwalle>
mhh that random command seems to be broken in many ways, it uses an uninitialized seed (dunno if it is really not initialized, at least with ECC it will be initialized) and it uses get_timer(0) which on my board had the same value most of the time, thus i onced switched to get_ticks() in net_random_ethaddr() to make it at least a bit better
<macromorgan>
it's the Rockchip PX30... it has a hardware rng but it doesn't look like there is any code to take a hardware rng and turn it into a kaslr-seed value
<macromorgan>
rng uses the hardware rng, random does not unfortunately
<mwalle>
macromorgan: booting via efi will use the rng protocol :)
<macromorgan>
I am using random to set the kaslr-seed today, but it's for development right now (having kaslr enabled in Linux seems to shake out some memory issues in drivers that don't otherwise appear, which is nice for debugging)
<macromorgan>
I wonder if there is any value in writing a command that uses a hardware rng to set kaslr-seed?
<macromorgan>
looks like only a handful of boards would support it anyway
tnovotny has quit [Read error: Connection reset by peer]
tnovotny has joined #u-boot
tnovotny_ has joined #u-boot
<macromorgan>
now if only I could figure out how to get op-tee to work...
tnovotny has quit [Ping timeout: 248 seconds]
<mwalle>
Tartarus: that was fast :p
<Tartarus>
heh
<Tartarus>
I've raised this with the NXP folks at least once before
<Tartarus>
(And they aren't alone in being out of sync and having broken Linux)
* mwalle
will be looking at how bad it is for the ls1028a later
<Tartarus>
I hope it's only those bindings you identified
tnovotny_ has quit [Read error: Connection reset by peer]
tnovotny_ has joined #u-boot
tnovotny has joined #u-boot
tnovotny_ has quit [Ping timeout: 250 seconds]
torez has joined #u-boot
tre has joined #u-boot
fdanis has quit [Ping timeout: 240 seconds]
tnovotny has quit [Quit: Leaving]
tre has quit [Remote host closed the connection]
redbrain has joined #u-boot
<marex>
Tartarus: what kind of blasphemy are you talking about on 30th anniversary of the greatestest kernel of them all ? :)
<marex>
Tartarus: I wonder if 30 years from now, we would still have downstream vendor kernel forks ...
<LeSpocky>
o.O
<marex>
uh oh
<Tartarus>
Not if, how many levels of it
<Tartarus>
But I'm not the optimist I used to be ;)
<marex>
haaa ;-)
<milkylainen_>
more forks than you can shake a stick at.
<marex>
milkylainen_: thats assuming we'll live long enough to need a cane, no stress-induced heart attack/stroke/organ failure/... that kind of thing
<milkylainen_>
marex :)
<milkylainen_>
We'll be the generation pretending to have laser sword fights, but with our canes.. :P
<milkylainen_>
No slashdot article on the kernel birthday?
fdanis has joined #u-boot
<Sout_>
maybe in 30 year we will all be using hurd
<marex>
I did boot the debian hurd iso recently
<marex>
the microkernel approach does have its appeal
vagrantc has joined #u-boot
frieder has quit [Remote host closed the connection]
jwillikers has quit [Remote host closed the connection]
<Tartarus>
mwalle: Yeah. If I had tooling in CI to fail on that, I'd quite welcome it.
<Tartarus>
Hmmm
<Tartarus>
mwalle: Can I Reported-by you on that?
<mwalle>
Tartarus: on what?
<Tartarus>
The revert I'm gonna post as part of raising the problem here.
<Tartarus>
Or should I wait for you to investigate things a bit more?
<mwalle>
i was gonna move that into an u-boot.dtsi, which will then need to be included in every <board>-u-boot.dtsi, to not break anything (yet). well i'm certainly open to just revert it and let NXP figure out a correct way
<Tartarus>
Have you looked at the -u-boot.dtsi auto-include logic? I would hope there's a high level spot to drop that in to
<Tartarus>
Because even if that's in -u-boot.dtsi, that still doesn't resolve your issue of giving the kernel the u-boot dtb leading to failure, right?
<Tartarus>
That's just required for u-boot to boot still
<mwalle>
Tartarus: AFAIK it only includes final-dtb-name-u-boot.dtsi, at least all the board use some kind of include on common u-boot.dtsi things
<mwalle>
Tartarus: I don't think that will lead to a failure, its just some random stuff dumped into the device tree
<Tartarus>
mwalle: There's a few variables checked like $(SYS_SOC) I believe too, but it can end up being we need a per-board -u-boot.dtsi file that includes a common hunk
<Tartarus>
mwalle: I'll post my revert in a bit, incase you figure out something else shortly that would mean I should have waited. Thanks!
<mwalle>
Tartarus: moving that stuff into u-boot.dts won't really fix the problem though, it will just make it easier to copy the kernel device tree to u-boot. which is my final goal for now
<Tartarus>
mwalle: Right, I think a revert is the right approach to make sure it's clear there needs to be another fix here
<Tartarus>
Or, pushing the binding upstream
<Tartarus>
Which is supposed to be a thing that's more acceptable now than it was even a few years ago
<mwalle>
if that compatible even makes sense..
<mwalle>
*binding
<mwalle>
i don't understand the issue though.. but it seems like it just translate that to a reserved memory region. so.. i don't know what kind of driver that should be
<Tartarus>
We have places to whack reserved regions, I would swear...
<mwalle>
Tartarus: mh I was working (or well pursuing the right persons *g*) to have the device trees included for boot in debian, for example
<Tartarus>
mwalle: Yeah, and you're aarch64 too right? So it really should / could be passed along and Work
<mwalle>
if it wasn't for a mistake, the debian 11 installer would have been able to boot via EFI on any upstream supported board
<Tartarus>
If, *groan*, things were working like it's supposed to
<Tartarus>
Yes, that's part of why I'm so ...unhappy... about these breakages
<mwalle>
Tartarus: yes it should work with the bootloaders device tree, but that is then likely outdated most of the time
<mwalle>
but the actual linux device trees of the kernel are now included in the installer iso and automatically loaded if fdtfile is set correctly
<mwalle>
what is still missing is the actual device tree in the installed system itself
<Tartarus>
mwalle: Device trees aren't supposed to be changing every week
<Tartarus>
But that's another lament for another time I suppose too
<mwalle>
Tartarus: yeah but esp with a new soc/board its likely to change
<mwalle>
and stuff is added
redbrain has quit [Ping timeout: 240 seconds]
<mwalle>
Tartarus: and yes, feel free to add my reported-by
<Tartarus>
thanks
agust has quit [Quit: Leaving.]
torez has quit [Remote host closed the connection]