lvrp16 has quit [Read error: Connection reset by peer]
lvrp16 has joined #linux-sunxi
Benjojo has quit [Read error: Connection reset by peer]
Benjojo has joined #linux-sunxi
indy has quit [Remote host closed the connection]
indy has joined #linux-sunxi
apritzel has joined #linux-sunxi
Mangy_Dog has joined #linux-sunxi
Mangy_Dog has quit [Ping timeout: 480 seconds]
tnovotny has joined #linux-sunxi
mps_ has left #linux-sunxi [#linux-sunxi]
<macromorgan>
anyone have issues with the display-engine on a 5.14 or 5.15 kernel? I have an A13 (an R8 actually) that won't load the display-backend because it says the dram-controller isn't ready yet.
<macromorgan>
the problem is there is no driver in Linux (past, present, or near as I can tell future) for the dram-controller
tnovotny has quit [Remote host closed the connection]
tnovotny has joined #linux-sunxi
cnxsoft has quit []
JohnDoe_71Rus has joined #linux-sunxi
cmeerw has joined #linux-sunxi
<jernej>
macromorgan: I discussed similar bug a few weeks back on linux-sunxi ML (not googlegroups) with fw_devlink dev, which enabled it by default on 5.14
<jernej>
but we didn't reached a conclusion yet (I have to respond)
<jernej>
anyway, set mbus driver to disabled and it should work
<jernej>
sorry, mark mbus node in DT as disabled
<macromorgan>
okay cool, thank you
<macromorgan>
that did it, thank you
Mangy_Dog has joined #linux-sunxi
tnovotny has quit [Quit: Leaving]
<jernej>
macromorgan: ok, good to know
<jernej>
apritzel: I see that U-Boot supports now powering on status LED already in SPL
<jernej>
I would argue that this is useful on most, if not all boards
<jernej>
few years back, users complained to me enough that I implemented a quick hack
<jernej>
would you accept patches for each board?
<apritzel>
jernej: sure, but that requires specifying the LED GPIO in defconfig, so requires patches for each board
<apritzel>
lol
<apritzel>
yeah, patches welcome
<apritzel>
but please only if someone/you can test it
<jernej>
well, at the time, I only supported OrangePi H3 based boards, so GPIO was same in all cases
<apritzel>
is there some "power" LED wired to the same GPIO there?
<jernej>
I believe so, let me check
<jernej>
apritzel: sorry, at the time, implementation relied on DT
<apritzel>
I was faster, it seems indeed to be PL10
<apritzel>
(grepping some .dts)
<jernej>
yeah, it seems so
<jernej>
but that's not a rule
<apritzel>
in any case, if you can test boards, I am happy to take patches. Maybe you can work out how to compress all those symbols into fewer ones?
<jernej>
shouldn't be that possible with new Kconfig symbol, which would set right values?
<apritzel>
yeah, something like that
macromorgan has quit [Read error: Connection reset by peer]
macromorgan has joined #linux-sunxi
apritzel has quit [Ping timeout: 480 seconds]
pnill has quit [Ping timeout: 480 seconds]
<ad__>
h2+ / h3: satasheet shows 2 SRAM area A1 and A2. Is it static ram or secure ram ?
<jernej>
apritzel: btw, updating H6 DTs would be nice - Tanix TX6 would gain support for booting from eMMC. Is there any compatibility concern or should I just send patch?
<jernej>
speaking about U-Boot, of course
apritzel has joined #linux-sunxi
warpme_ has quit [Quit: Connection closed for inactivity]
<apritzel>
jernej: fdt_fixup_ethernet(), looks dodgy, but is probably fine
<jernej>
as I explained, we can't really avoid this case, if overlays are used
<jernej>
I concur that this is not fine for ordinary ethernet support, which should be just properly implemented
<jernej>
but I have no better idea for DT overlay case
<jernej>
if you have, I'm willing to look into it
<apritzel>
well, as I said it's probably fine, I plan on sending a second PR next week anyway
<apritzel>
and I think we should not get hold up with those nits, especially if they fix real problems
<apritzel>
jernej: H6 update: last time I checked the RTC clock binding update broke booting older kernels
<apritzel>
and with older kernels I mean everything < 5.13, which is not cool
<jernej>
can you pinpoint commit? I don't see any recent RTC change...
<apritzel>
Linux 73088dfee635
<apritzel>
(I think)
<jernej>
ah, R_INTC
<apritzel>
seems innocent, but has quite some ripple effects
<jernej>
what if I just send board DT update? it should still work with old DTSI, since there is no relevant change
<jernej>
yeah, this is a tough one, if you want to preserve backward compatibility
<apritzel>
it'
<apritzel>
it's also a general problem
<apritzel>
for once I keep telling people to only send verbatim Linux copies
<apritzel>
and on the other hand Linux maintainers explicitly don't care about backwards compatibility
<jernej>
I guess this is one of the reasons why some (most?) distros prefer to ship and load matching kernel dtb file instead of re-using one from U-Boot
<apritzel>
if you ask me this is embedded nonsense
<apritzel>
I guess I need to break my own rule and let the U-Boot DTs deviate from the kernel :-(
<apritzel>
another hack I thought about is "compat overlays" (or have old DTs and use "new kernel overlays")
<jernej>
you don't want to know how many images were built for LibreELEC 10 release, just to accomodate U-Boot settings and other tweaks for each board :)
<jernej>
but we also have generic SoC updates, which skips bootloader update
<jernej>
anyway, it's easier for me that way. If I need to add any new functionality which include U-Boot/Crust/DT change, it can be updated much easier
<jernej>
especially DT
<apritzel>
jernej: you can (probably with some hacks) compile one U-Boot proper image that supports multiple boards, and just select the right DT from the FIT image
<apritzel>
but doing that for the SPL as well gets a bit more tricky, of course
<jernej>
ah, building separate images is not really a problem and infrastructure handles it well
<jernej>
it's easier for end user too, they don't have to select or change anything
<jernej>
how do you image selecting right DT would work?
<jernej>
automatic selection is not something that can work well, except for limited number of boards, which were made with this in mind
<apritzel>
limited selection of boards and auto-detect is one approach, yes. I had one for some Pine64 boards
<apritzel>
the other solution would be just look at the SPL header, where someone has put the right DT name
<apritzel>
but yeah, of course there is no silver bullet to cover everything
<jernej>
yeah, pine64 images could be consolidated, there is a lot of confusion between original board and plus
<jernej>
and of course almost everything works, except ethernet
<apritzel>
but conceptually modern U-Boot could come as one "proper" image per SoC, or even for multiple SoCs (A64+H5, for instance)
<apritzel>
for the 512MB DRAM Fast Ethernet and 1GByte GBit Ethernet we do that already
<apritzel>
to include the Pine64-LTS/SoPine requires both LPDDR and DDR3 DRAM types supported
<apritzel>
I had this running, but only with a 32-bit SPL, because of size constraints
<jernej>
I guess I should at least switch from hardcoding dtb file name in extlinux.conf to asking U-Boot what is dtb filename reported by SPL
<jernej>
that would solve pine64 fast/gigabit ethernet case
<apritzel>
isn't that already implemented in PXE boot?
<jernej>
depends how you use it :)
<apritzel>
it uses $fdtfile if you did not specify something in your PXE config
<jernej>
now that there is 1:1 match between U-Boot and Linux DT file names, that would work, yes
<apritzel>
if (label->fdt) {fdtfile = label->fdt;} else if (label->fdtdir) { char *f1 = env_get("fdtfile"); ... }
<jernej>
before I had ugly hacks with dtb file names mismatched, because I reused some of them for other boards (for those boards which were not yet supported in U-Boot)
<apritzel>
jernej: btw: do you know of some automatic DT overlay application outside of PXE?
<jernej>
it's possible to apply overlays via command
<jernej>
and Armbian has a script for that
<apritzel>
yeah, I was thinking about something like for the RPi, where it applies every file in a magic directory
<jernej>
AFAIK, you have to list overlays for both variants, PXE and Armbian script