<loki666>
but usually it hangs at "Trying to boot from MMC1"
<apritzel>
the BROM tries MMC0 first, then MMC2. And the MMC2 *DT node* should have no influence on DRAM detection whatsoever, since the DT is only loaded after DRAM init
LordKalma has quit [Quit: Server has probably crashed]
LordKalma has joined #linux-sunxi
LordKalma has quit []
LordKalma has joined #linux-sunxi
<apritzel>
(MMC0 on the hardware side, shown as MMC1 in U-Boot)
aggi_ has quit []
bauen1 has joined #linux-sunxi
ftg has joined #linux-sunxi
Schimsalabim has quit [Ping timeout: 480 seconds]
Schimsalabim has joined #linux-sunxi
buZz has quit [Remote host closed the connection]
pvl1 has quit []
freemangordon has quit []
apritzel has quit [Ping timeout: 480 seconds]
freemangordon has joined #linux-sunxi
<loki666>
Could it be the missing CPU regulator that cause these issues?
Schimsalabim has quit [Read error: Connection reset by peer]
Schimsalabim has joined #linux-sunxi
Schimsalabim has quit [Ping timeout: 480 seconds]
Schimsalabim has joined #linux-sunxi
Schimsalabim has quit [Read error: Connection reset by peer]
Schimsalabim has joined #linux-sunxi
loki6660 has joined #linux-sunxi
loki666 has quit [Ping timeout: 480 seconds]
apritzel has joined #linux-sunxi
<apritzel>
loki6660: no, that's irrelevant: the regulator must be on, otherwise you couldn't execute code. U-Boot doesn't care about a CPU regulator at all, and Linux can happily live without one
<apritzel>
for DVFS you would at least need a dummy regulator, but without one you just couldn't change the CPU frequency, but it would still work
loki6660 has quit []
loki666 has joined #linux-sunxi
<loki666>
ok, so any idea, why booting proper is so random? dram issues ?
hexdump0815 has quit [Quit: WeeChat 3.8]
hexdump0815 has joined #linux-sunxi
<apritzel>
that's one explanation: DRAM init was good enough to pass the test, but it fails when it's used for real. The MMC code is the first DRAM user, for instance.