ftg has quit [Read error: Connection reset by peer]
smaeul has joined #linux-sunxi
apritzel has quit [Ping timeout: 480 seconds]
colinsane has quit []
<MasterR3C0RD>
Narrowed down some of the boot issues in my code to the code setting up the address map for the DDR controller. Controller's the same as the H616, but wanted to get something that was more accurate in terms of bank and bank group handling in case it pops up. https://gist.github.com/BrokenR3C0RD/c4fa7897c2582ac3f1d25ecb97c3f3f6
hipboi has joined #linux-sunxi
colinsane has joined #linux-sunxi
<MasterR3C0RD>
Well, more specifically it turns out my device has a single rank with banks/bank groups, thus implementing support for that was necessary. No clue whether or not the rank support works, as there's no way for me to test; however, the address mapping code works as expected
iscle has quit [Remote host closed the connection]
<nolash>
I am trying to build mainline kernel as per tutorial but getting uboot complaints about bad magic number. Any insights would be welcome https://forum.pine64.org/showthread.php?tid=1946
hipboi has quit [Quit: hipboi]
<apritzel>
nolash: what tutorial? and this thread doesn't seem to exist? can you share some more details?
<apritzel>
I guess it's an arm64 kernel? And what board are you running that on? Which U-Boot? Also mainline? And what is the command line that fails in U-Boot?
<apritzel>
"bad magic number" typically means your kernel is somehow mangled (unsupported format or compression?), or has been misloaded
hazardchem has quit [Read error: Connection reset by peer]
hazardchem has joined #linux-sunxi
<apritzel>
nolash: in short: make -jxxx Image; cp arch/arm64/boot/Image /mnt/sd/Image, then in U-Boot: fatload mmc 0:1 $kernel_addr_r Image; booti $kernel_addr_r - $fdtcontroladdr
<apritzel>
... that's of course a very rough summary, please fill the gaps ;-)
<apritzel>
you mean the version in the "Timer" support row? That doesn't mean much ...
<nolash>
yes, well that's the information I had found to possibly narrow the "problem.
<nolash>
anyway this whole thing is a narrowing of a problem with alpine linux, that blanks the display after kernel loaded
<nolash>
display as in hdmi
<apritzel>
also: earlyprintk doesn't exist on arm64, you would want "earlycon". And specifying a console typically helps as well: console=ttyS0,115200n8
<nolash>
apritzel: nice thanks
<apritzel>
nolash: is Alpine loading via EFI (either bootefi or grub), or booti from U-Boot directly?
<apritzel>
I guess losing display means you are missing the display drivers, and eventually the kernel will disable the (seemingly) unused display clocks?
<nolash>
it was grub, but I believe extlinux was tried and failed first. I will make another pass at this now that I know more about the details on how it all works
<nolash>
let me first verify i can boot a custom kernel and get mounted on a rootfs, then i will pivot back to the alpine case.
<apritzel>
or a regulator issue? Pine64 requires DLDO1 to be enabled for HDMI. Same issue here, the kernel might turn that rail off if it sees it unused
<apritzel>
do you see some kernel images, and then the screen goes blank?
<nolash>
apritzel: it seemed to try to load the kernel, but i cannot say if it succeeded, this is why i wanted to try with a custom kernel maybe and see if that can make it work. I'll give it all a shot now.
dsimic is now known as Guest6347
dsimic has joined #linux-sunxi
Guest6347 has quit [Ping timeout: 480 seconds]
JohnDoe_71Rus has joined #linux-sunxi
<nolash>
apritzel so what am Iexpecting to see when kernel starts? it successfully loading now (without initrd) and all i get is "starting kernel...." no debug output or anything else.
<nolash>
(i've never tried to start a kernel in this way before)
MasterR3C0RD has quit [Remote host closed the connection]
<nolash>
apritzel: never mind got panic for rootfs now enabling debug. all good, thanks for the help.
warpme has quit []
<macromorgan>
apritzel: My device (Anbernic 35XXH) works just fine with 1100 for the RAM, but also 1160. I can send a patch upstream to fix that. Should I also update the RAM in the mainline device trees to that value?
<apritzel>
macromorgan: well, only if that fixes something. I was under the impression someone was using that value to improve stability, but I might be confusing it with some other board
<macromorgan>
it's possible... honestly I still have very little idea what I'm doing on this device :-(
<apritzel>
tokyovigilante: did you ever need to increase the DRAM voltage on your devices?
<macromorgan>
the efuse value for my board is 1100
<apritzel>
macromorgan: which efuse value? for cpufreq?
<macromorgan>
for dcdc3
<macromorgan>
the efuse on the PMIC
<loki666>
for me it greatly impres u-boot dram detection
<loki666>
so far 100%
<loki666>
macromorgan: I also have a 35XXH
<macromorgan>
okay, we can set it to 1160 as for me either value doesn't appear to be an issue
<macromorgan>
wonder if it's just a RAM binning issue
<macromorgan>
I also note that we need to enable cpusldo or else the device is unpredictable at reboot. No idea what that regulator is used for though.
<macromorgan>
so thinking for mainline we push an update raising the voltage of the dcdc3, re-enable the cpusldo (for Linux), and then update the defconfig for U-Boot setting the dcdc3 value to 1160? I'm going to test that out for a while.
hentai has joined #linux-sunxi
ftg has joined #linux-sunxi
wingrime-ww has joined #linux-sunxi
wingrime1 has quit [Ping timeout: 480 seconds]
ats has quit [Quit: new GPU]
ats has joined #linux-sunxi
<apritzel>
loki666: I guess you did just U-Boot boot tests? I wonder what happens when Linux brings back DCDC3 to 1.1V (with the current DT)? It sounds fishy, but I guess happens to work?
<apritzel>
macromorgan: please send the DT patches to Linux, as fixes
<apritzel>
(increasing max to 1.16V, keep min at 1.1V)
<apritzel>
the U-Boot patch is less critical, timing-wise
<apritzel>
(I mean for upstreaming)
smaeul has quit [Remote host closed the connection]
apritzel has quit [Remote host closed the connection]
apritzel has joined #linux-sunxi
<macromorgan>
I'm regressioning it a bit as loki666 also mentioned some crashes when running stress-ng. I'm *thinking* maybe cpusldo may play into this, so I'm going to add that in my upstream fixes.
<macromorgan>
I just completed an hour run and no crashes to speak of (stress-ng -c 4)
hexdump0815 has quit [Quit: WeeChat 3.8]
hexdump0815 has joined #linux-sunxi
smaeul has joined #linux-sunxi
apritzel has quit [Ping timeout: 480 seconds]
megi has quit [Ping timeout: 480 seconds]
smaeul_ has joined #linux-sunxi
smaeul has quit [Read error: Connection reset by peer]
smaeul_ has quit [Remote host closed the connection]
smaeul has joined #linux-sunxi
<loki666>
apritzel I have a full blown retro emulation distro running behind u-boot
<loki666>
I do have some crash/hang not sure if it's CPU or GPU
smaeul has quit [Remote host closed the connection]
smaeul has joined #linux-sunxi
smaeul has quit [Read error: No route to host]
smaeul_ has joined #linux-sunxi
megi has joined #linux-sunxi
smaeul_ has quit [Remote host closed the connection]
smaeul has joined #linux-sunxi
smaeul_ has joined #linux-sunxi
smaeul has quit [Remote host closed the connection]