ikarso has quit [Quit: Connection closed for inactivity]
alpernebbi has quit [Ping timeout: 248 seconds]
zibolo has quit [Ping timeout: 260 seconds]
zibolo has joined #u-boot
alpernebbi has joined #u-boot
rvalue- has joined #u-boot
rvalue has quit [Ping timeout: 276 seconds]
rvalue- is now known as rvalue
xroumegue has quit [Ping timeout: 248 seconds]
xroumegue has joined #u-boot
Daanct12 has joined #u-boot
mmu_man has quit [Ping timeout: 260 seconds]
prabhakalad has quit [Ping timeout: 244 seconds]
prabhakalad has joined #u-boot
vardhan has joined #u-boot
haritz has quit [Ping timeout: 248 seconds]
gsz has joined #u-boot
goliath has joined #u-boot
frieder has joined #u-boot
monstr has joined #u-boot
gsz has quit [Ping timeout: 244 seconds]
ikarso has joined #u-boot
monstr has quit [Ping timeout: 252 seconds]
vardhan_ has joined #u-boot
vardhan has quit [Ping timeout: 244 seconds]
vardhan__ has joined #u-boot
vardhan_ has quit [Ping timeout: 272 seconds]
warpme has joined #u-boot
wooosaiiii has joined #u-boot
ldevulder has joined #u-boot
rockosov has joined #u-boot
monstr has joined #u-boot
mckoan|away is now known as mckoan
gsz has joined #u-boot
sszy has joined #u-boot
Guest2959 has joined #u-boot
Guest2959 has left #u-boot [Leaving]
gsz has quit [Ping timeout: 265 seconds]
vardhan__ has quit [Remote host closed the connection]
vardhan__ has joined #u-boot
macromorgan has quit [Ping timeout: 248 seconds]
macromorgan has joined #u-boot
vardhan__ has quit [Remote host closed the connection]
warpme has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
warpme has joined #u-boot
gsz has joined #u-boot
Jones42 has joined #u-boot
slobodan_ has joined #u-boot
slobodan__ has joined #u-boot
slobodan_ has quit [Ping timeout: 244 seconds]
<pivi>
uff, from what I can see all the imx8m with >=4GB RAM are currently broken in U-Boot master, not just verdin.
<apalos>
pivi: any of the changes that were proposed solves it ?
<pivi>
if we do not get to a solution we agree with in short term, probably is better to just revert that commit and have a proper solution for upcoming merge window
<pivi>
apalos: please see my last email
<pivi>
apalos: the trivial fix, will introduce regression somewhere else
<pivi>
apalos: yes, if you need more test just reply to the email thread, joao is going to be able to test easier than myself
dsimic has quit [Ping timeout: 245 seconds]
dsimic has joined #u-boot
warpme has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<frieder>
pivi: e27bddff4b97 ("imx8m: Restrict usable memory to space below 4G boundary") is a workaround for some IP cores (FEC, USDHC, etc.) which don't support direct access to the space above 0xffffffff.
<apalos>
frieder: yes I was about to say the same thing,
<apalos>
So looking at it, this is a platform definition bug
<apalos>
We'll send a reply explaining what's going on, but that ram_top @ 0xffffffff is what triggers it,
<apalos>
because we are trying to protect the relocated u-boot which ends at @ 0x100000000
<apalos>
and since ram_top is defined lower, the rextra byte has already been reserved as 'dont overwrite'
<apalos>
We should have some code printing it's a platform bug, but since we are close to the release, let's fix this and send an update post 2025.01
<apalos>
the whole lmb code assumes the last usable address is included, so this needs to be 0x100000000
<apalos>
frieder: sorry I thought you pasted the older commit from that mail, limiting it to 0x80000000
<apalos>
so yea, you are right that needs a fixes thag
<apalos>
tag*
<pivi>
apalos: Tartarus: I do not see us being able to help mure more in the next weeks, everybody in my team is going to be off or super busy as the last standing man
<pivi>
but the issue should be super clear now
<pivi>
and it's generic on imx8m, nothing specific to our board
<pivi>
s/mure/much/
<apalos>
pivi: the fix should be an oneliner + the explanation in mail
<apalos>
If noone from your team can do that, I can probably send it
Daanct12 has quit [Ping timeout: 265 seconds]
steffen[m] has joined #u-boot
mripard has joined #u-boot
mmu_man has quit [Ping timeout: 265 seconds]
<steffen[m]>
Hi, we've been looking at improving boot time on a xilinx zynqmp device with upstream u-boot (~8 seconds for u-boot). Much of the time is spent searching for things in device tree before caches are enabled. Right now we're looking at reordering the dts so we find things quicker, or moving things behind the cache setup. (serial port init without caches takes ~1.3 seconds, spl takes less than that for everything). Is...
<steffen[m]>
... anyone having similar issues? Maybe we cold move dram/cache init to be earlier in general?