00:15 <alyssa> HdkR: :D

14:44 <urjaman> i was reading the RK3288 TRM (as you do when bored, it seems?... actually i was just browsing it for the funny english), and found some registers (DRAM stride) where the table went to 8GB Total and I was like wait what isnt the max 4GB

14:45 <urjaman> then i happened upon an older version of a part of the TRM that read 8GB on the intro/summary page, so i guess they down-specced the RK3288 max RAM at some point... i guess errata? but still funny.

16:32 <mmind00> urjaman: https://patchwork.kernel.org/patch/9874029/

16:32 <mmind00> lpae seems possible and even in use

17:03 <alyssa> mmind00: what about rk3399?

17:03 <alyssa> mmind00: re that patch - Midgard uses a 64-bit address space even if the CPU is 32-bit

17:04 <alyssa> it's still 4GB physically, but sparse

17:05 <mmind00> alyssa: really no clue :-( ... when urjaman mentioned that 8gb thingy I just remembered that lpae patch flying by some years ago

17:12 <alyssa> fair enough

17:42 <urjaman> yeah i know it has LPAE, my "isnt the max 4GB" is from the TRM saying max 4GB address space for memory controller

17:45 <urjaman> i mean in theory it could also be that they just didnt want to support someone doing the 8GB... if i had the skills and money it might be a fun experiment to swap the memory chips on a C201 :P (i did check the boardview and googled that some 4GB/32Gb physically compatible chips exist, and they didnt seem to need any extra pins to be routed either)

17:55 <urjaman> (also in the list of things one could do to a C201 if swapping BGA's is easy for you: bigger eMMC, maybe different wifi chip... this one is a bit harder, difficult to find same form factor non-evil one... tho if anything is better than broadcom i did find one with a marvell chip that seemed compatible-ish)

17:56 <HdkR> I've only ever had problems with Marvell chips under Linux :/

17:58 <urjaman> yeah that's kinda what i've heard too...

18:10 <alyssa> urjaman: IIRC the issue is that there aren't any sdio wifi chips that don't need proprietary fw (but I'd love to be proven wrong here)

19:37 <Cruft> panfrost compatible chromebook device prices skyrocketing

19:40 <HdkR> Seems like we need more Panfrost compatible chromebooks on the market :P

19:42 <Cruft> I've been trying to shorten the length of directions for installation but arch users are anti efficiency

19:42 <Cruft> and debian users don't like alt arch rootfs

19:44 <Cruft> Right now i'm trying to use busybox static and allarch debootstrap to build rootfs from device to microsd but its hard on 16GB devices with 1.8GB free max in /usr/local but i can split to /tmp maybe for building panfrost.

21:47 <Dil3mm4> Hello.

21:49 <Dil3mm4> Currently running armbian on a s912 equipped box with an image from balbes150, got panfrost driver logline at boot 'error powering up gpu'

21:50 <Dil3mm4> As I can understand, to debug, isn't really enough. So I'm here wondering how can I help/understand what's wrong

21:50 <Dil3mm4> Till now I've mostly messed around with dtb files, which give me all the same result about panfrost.

22:03 <Dil3mm4> Lurking in the logs I've found some infos, but I can't really understand what's the current status... alyssaa mind giving me a few bits? :)

22:07 <Dil3mm4> phh umpf.

22:09 <HdkR> 1Weekend so a lot of people won't be paying attention to IRC

22:49 <kaichi> What kernel version is the image using

22:49 <Dil3mm4> kaichi 5.5.0-rc6-aml-s9xxx