ikarso has quit [Quit: Connection closed for inactivity]
naoki has quit [Quit: naoki]
naoki has joined #u-boot
naoki has quit [Quit: naoki]
naoki has joined #u-boot
zibolo_ has quit [Ping timeout: 252 seconds]
zibolo has joined #u-boot
naoki has quit [Quit: naoki]
naoki has joined #u-boot
naoki has quit [Client Quit]
naoki has joined #u-boot
samueldr has quit [Quit: (be back later, shuffling things from server to server)]
naoki has quit [Quit: naoki]
naoki has joined #u-boot
samueldr has joined #u-boot
naoki has quit [Quit: naoki]
naoki has joined #u-boot
joeskb7 has quit [Ping timeout: 252 seconds]
goliath has joined #u-boot
joeskb7 has joined #u-boot
monstr has joined #u-boot
monstr has quit [Read error: Connection reset by peer]
monstr has joined #u-boot
pericycle has quit [Ping timeout: 246 seconds]
pericycle has joined #u-boot
gsz has quit [Ping timeout: 252 seconds]
ldevulder has joined #u-boot
mckoan|away is now known as mckoan
gsz has joined #u-boot
gsz has quit [Ping timeout: 252 seconds]
warpme has joined #u-boot
<mkorpershoek>
pivi: did you solve your eMMC read failures on AM62 you reported on Monday 9 December? We might have the same problem, so asking before I spend time looking into it
frieder has joined #u-boot
Peng_Fan has joined #u-boot
frieder has quit [Ping timeout: 248 seconds]
frieder has joined #u-boot
rockosov has quit [Ping timeout: 265 seconds]
rockosov has joined #u-boot
pericycle has quit [Ping timeout: 260 seconds]
pericycle has joined #u-boot
joeskb7 has quit [Ping timeout: 244 seconds]
<pivi>
mkorpershoek: latest master seems to work fine, we did not investigate the reasons. maybe you can confirm
<pivi>
marex: your guess was correct. we do have failures only with module with >= 4GB memory.
<pivi>
apalos: shadow: ^^^
sszy has joined #u-boot
<mkorpershoek>
pivi: ok, thank you, we will try
rvalue has quit [Read error: Connection reset by peer]
rvalue has joined #u-boot
<marex>
pivi: it is always that 32bit boundary ;-)
warpme has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<apalos>
pivi: yes we hard reports of the issue being fixed, hence my question
<apalos>
Thanks fote testing!
warpme has joined #u-boot
frieder has quit [Ping timeout: 246 seconds]
frieder has joined #u-boot
slobodan__ has joined #u-boot
ikarso has joined #u-boot
<pivi>
apalos: wait, mixing up to things here. mkorpershoek was asking about am62, the issue I was writing about yesterday it's still there.
<pivi>
apalos: nothing was solved on this regard, even with latest master from last night
warpme has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<apalos>
ah ok, please send me an email with that failure then
warpme has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
warpme has joined #u-boot
gsz has quit [Ping timeout: 252 seconds]
warpme has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<apalos>
pivi: this seems like a regression indeed, otoh this seems to violate what u-boot considers are ram_top
<apalos>
since I dont have any boards around, can you send bdinfo etc that Sughosh asked,
<apalos>
We can make this work, but we'd have to ignore ram_top and i dont know if that's a good idea
<apalos>
I'd prefer fixing any board specific bugs
rber|res has quit [Read error: Connection reset by peer]
ukky has quit [Ping timeout: 272 seconds]
ukky has joined #u-boot
MyNetAz has quit [Remote host closed the connection]
MyNetAz has joined #u-boot
<pivi>
apalos: I am ok changing the board file. But let's see where the fix is going to be, this does not seem a change for an rc4. I would bet more boards are affected
<pivi>
(with "this" I mean that commit that introduced such a regression)
eballetbo has joined #u-boot
___nick___ has joined #u-boot
___nick___ has quit [Client Quit]
<apalos>
pivi: that cpmmit is just marking everything above ram_top as unsable (reserved)
___nick___ has joined #u-boot
<apalos>
which should already be the case, because ram_top is supposed to be all memory we can use
<apalos>
So that commit might have unearther hidden bugs
<apalos>
Doesnt mean we dont need to fix them, I am just saying what I think is happening
<pivi>
yeah, likely we use the heap at the end of the memory, but we limit ram top on the 32-bit boundary. why, I have no idea at the moment
<apalos>
But this will make memory above ram_top usable,
<apalos>
Which is not what ram_top is supposed to be
<pivi>
I would say either we use the heap from below ram top or we move ram top in the 64-bit address space. I agree that would be a more reasonable fix
<apalos>
you can do 21 things, eother the above
<apalos>
Or fix ram_top to be the correct address,
<apalos>
2 things*
<apalos>
the latter is better imho, but let's see what that board says first
naoki has quit [Quit: naoki]
ldevulder has quit [Quit: Leaving]
goliath has quit [Quit: SIGSEGV]
jfsimon1981 has joined #u-boot
frieder has quit [Remote host closed the connection]
___nick___ has quit [Ping timeout: 272 seconds]
___nick___ has joined #u-boot
mckoan is now known as mckoan|away
goliath has joined #u-boot
gsz has joined #u-boot
monstr has quit [Remote host closed the connection]
Daanct12 is now known as Danct12
___nick___ has quit [Ping timeout: 252 seconds]
vardhan has quit [Ping timeout: 272 seconds]
___nick___ has joined #u-boot
sally has joined #u-boot
slobodan_ has joined #u-boot
slobodan__ has quit [Ping timeout: 252 seconds]
lvrp16_ has joined #u-boot
GNUtoo_ has joined #u-boot
fsinger has joined #u-boot
veremitz- has joined #u-boot
mmu_man has joined #u-boot
flx has quit [*.net *.split]
GNUtoo has quit [*.net *.split]
lvrp16 has quit [*.net *.split]
veremitz has quit [*.net *.split]
lvrp16_ is now known as lvrp16
veremitz- is now known as veremitz
joeskb7 has joined #u-boot
fsinger is now known as flx
MyNetAz has quit [Read error: Connection reset by peer]