youmukon1 has quit [Read error: Connection reset by peer]
youmukon1 has joined #linux-sunxi
youmukonpaku1337 has quit [Read error: Connection reset by peer]
f_ has quit [Read error: Connection reset by peer]
f_ has joined #linux-sunxi
hexdump0815 has joined #linux-sunxi
hexdump01 has quit [Ping timeout: 480 seconds]
vvpnet has joined #linux-sunxi
youmukonpaku1337 has joined #linux-sunxi
youmukon1 has quit [Read error: Connection reset by peer]
vvpnet has quit []
JohnDoe_71Rus has joined #linux-sunxi
youmukon1 has joined #linux-sunxi
youmukonpaku1337 has quit [Read error: Connection reset by peer]
Schimsalabim has quit [Read error: Connection reset by peer]
Schimsalabim has joined #linux-sunxi
youmukonpaku1337 has joined #linux-sunxi
youmukon1 has quit [Ping timeout: 480 seconds]
Schimsalabim has quit [Ping timeout: 480 seconds]
Schimsalabim has joined #linux-sunxi
<Jookia>
how does that work? don't you probe stick values over i2c?
apritzel has joined #linux-sunxi
warpme has joined #linux-sunxi
apritzel has quit [Ping timeout: 480 seconds]
Schimsalabim has quit [Read error: Connection reset by peer]
Schimsalabim has joined #linux-sunxi
warpme has quit []
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
warpme has joined #linux-sunxi
Schimsalabim has quit [Ping timeout: 480 seconds]
DarkNeutrino has quit [Ping timeout: 480 seconds]
Schimsalabim has joined #linux-sunxi
DarkNeutrino has joined #linux-sunxi
youmukon1 has joined #linux-sunxi
DarkNeutrino has quit [Ping timeout: 480 seconds]
DarkNeutrino has joined #linux-sunxi
youmukonpaku1337 has quit [Read error: Connection reset by peer]
Schimsalabim has quit [Read error: Connection reset by peer]
Schimsalabim has joined #linux-sunxi
youmukonpaku1337 has joined #linux-sunxi
youmukon1 has quit [Read error: Connection reset by peer]
youmukon1 has joined #linux-sunxi
youmukonpaku1337 has quit [Read error: Connection reset by peer]
youmukonpaku1337 has joined #linux-sunxi
youmukon1 has quit [Remote host closed the connection]
chewitt has joined #linux-sunxi
DarkNeutrino has quit [Ping timeout: 480 seconds]
DarkNeutrino has joined #linux-sunxi
apritzel has joined #linux-sunxi
<apritzel>
Jookia: are you thinking about SPD EEPROMs, as on DIMM modules?
youmukon1 has joined #linux-sunxi
youmukonpaku1337 has quit [Read error: Connection reset by peer]
bauen1 has quit [Ping timeout: 480 seconds]
youmukonpaku1337 has joined #linux-sunxi
youmukon1 has quit [Read error: Connection reset by peer]
warpme has quit []
youmukon1 has joined #linux-sunxi
youmukonpaku1337 has quit [Read error: Connection reset by peer]
<Jookia>
yeah
<apritzel>
Jookia: I am sorry to disappoint you ;-), but it's much more primitive than you think: there are just the raw DRAM chips connected to the DRAM controller inside the SoC
<Jookia>
oh no. so how does it know the size? does it ... guess?
<apritzel>
it's an educated guess, I'd say ;-)
<Jookia>
it gueses right 100% of the time 80% of the time :D
<libv>
Jookia: write to addresses, and see if the same value repeats somewhere
<apritzel>
we set up different configurations, then look for aliases somewhere else
<Jookia>
oh, it wraps around?
<Jookia>
interesting
<libv>
Jookia: at least it does on retro computers and such
<libv>
it makes sense that it still is like that
<libv>
bigger ram means more address lines
<libv>
smaller ram has less of the high address lines connected
<Jookia>
interesting
<libv>
so the pattern will repeat
<apritzel>
Jookia: look at mctl_auto_detect_dram_size() in arch/arm/mach-sunxi/dram_sun50i_h616.c
<Jookia>
oh right, it's open source
<Jookia>
interesting!
<libv>
i remember seeing something like it 11 or so years ago in uboot code for a10/a20
<Jookia>
thanks for explaining. i have to sleep now though :)
<libv>
but i was not going to put my hand in the fire for it
<libv>
could be that some ram controllers nowadays are "special"
<apritzel>
the function above that probes for the number of ranks and the bus width (16 or 32 bits)
<apritzel>
libv: the DRAM controller details changed quite a bit since then, but the basic principles are still the same
<apritzel>
Jookia: to be clear: the guessing algorithm itself is correct, it's the DRAM controller setup and the timing of doing so that we are not sure about
youmukon1 has quit [Ping timeout: 480 seconds]
bauen1 has joined #linux-sunxi
youmukonpaku1337 has joined #linux-sunxi
dsimic is now known as Guest3158
dsimic has joined #linux-sunxi
youmukon1 has joined #linux-sunxi
Guest3158 has quit [Ping timeout: 480 seconds]
youmukonpaku1337 has quit [Read error: Connection reset by peer]
youmukonpaku1337 has joined #linux-sunxi
youmukon1 has quit [Read error: Connection reset by peer]
youmukon1 has joined #linux-sunxi
youmukonpaku1337 has quit [Read error: Connection reset by peer]
<acmeplus>
ok, the reason I ask is because I tried yesterday and of course failed :)
<apritzel>
jakllsch: and since there are three people actively working on mainlining the RG35XX, this is much more promising
<acmeplus>
Also the RG35XX Plus and H are well built devices, and the screen is very good
<apritzel>
acmeplus: yeah I saw your dump yesterday, thanks for that. I don't know if jernej has something for RGB LCDs on top of DE33 and the existing HDMI TCON
<apritzel>
and also macromorgan did upstreaming of the similar (or same?) LCD panels for the RK units, IIUC
<acmeplus>
If those are for the other RG353 or similar I believe they are basically the same or compatible
youmukonpaku1337 has quit [Remote host closed the connection]
<macromorgan>
the pin count on the panel ribbon cable makes me think this is a DPI display not a DSI like all those rockchip panels
<macromorgan>
so it should be easier since no init sequence is needed, just proper timings
<apritzel>
but LCD is certainly out of my comfort area, so I am not of much help here, I am afraid :-(
youmukonpaku1337 has joined #linux-sunxi
<apritzel>
macromorgan: it must be DPI, since the H700 does not support DSI, as far as we know
<macromorgan>
then that almost certainly seals the deal... too many pins for DSI + not supported by the SoC anyway
<macromorgan>
sorry I haven't gotten that far yet, I'm just now getting it to bring-up Debian from the SDMMC
<apritzel>
I think jernej hinted the other day that DPI support should not be too hard?
bauen1 has joined #linux-sunxi
<macromorgan>
I don't know that yet, in my experience "this should be easy" are famous last words...
<macromorgan>
I know I know nothing about how the regulators are defined, so the ranges and stuff from the factory devicetree might be wrong
junari has quit [Ping timeout: 480 seconds]
<apritzel>
macromorgan: for the generic AXP regulator nodes? I think we have this covered, courtesy of a dump of the regulator values from the BSP kernel
<apritzel>
we just need to figure out which regulator rail drives what
<acmeplus>
looking at the T507 it uses vcc-pd-supply = <®_sw>; for the display, but looking at the stock dts for the plus I couldn't find an equivalent.
<apritzel>
acmeplus: this would be a board detail, that has nothing to do with the SoC or the display
<acmeplus>
ok
<apritzel>
a simple way of getting the regulator rail assignment is to turn on everything, then switching rails off one by one and observing what dies
<apritzel>
some can be guessed by the vendor DT, but this is unreliable in my experience
bauen1_ has joined #linux-sunxi
<apritzel>
another hint is the voltage: certain devices require certain voltages, so this limits the choice
<apritzel>
for instance the SoC HDMI supply is 1.8V according to the H616 datasheet, so it could only be those LDOs that are programmed to 1.8V, like BLDO2
bauen1 has quit [Ping timeout: 480 seconds]
<apritzel>
maybe measuring some voltages on the LCD or cable might help to identify some more?
thecheofusi has joined #linux-sunxi
youmukonpaku1337 has quit [Remote host closed the connection]
youmukonpaku1337 has joined #linux-sunxi
<acmeplus>
Thanks for the hints. I did some testing turning display on/off and switching to hdmi with stock yesterday but couldn't observe any clear pattern. But will keep trying
bauen1 has joined #linux-sunxi
bauen1_ has quit [Ping timeout: 480 seconds]
youmukon1 has joined #linux-sunxi
youmukonpaku1337 has quit [Ping timeout: 480 seconds]
ungeskriptet is now known as Guest3170
ungeskriptet has joined #linux-sunxi
thecheofusi_ has joined #linux-sunxi
Guest3170 has quit [Ping timeout: 480 seconds]
thecheofusi has quit [Ping timeout: 480 seconds]
thecheofusi_ has quit [Remote host closed the connection]
<jernej>
acmeplus: macromorgan: RGB and LVDS LCDs are really easy, also on H616 & co., as far as drivers are concers. However, if you don't have schematic, proper settings might be a bit tricky.
Schimsalabim has joined #linux-sunxi
<jernej>
dc1sw is usually used for power
<jernej>
but you also need to figure backlight
<jernej>
and for some reason, there was extra 1.8 V rail that I have to enable in order to make it work
<jernej>
(I had incomplete schematic)
<apritzel>
I don't think there is a "switch" rail on the AXP717, that's what triggered me above to say it's board dependent
<KREYREN_oftc>
and it doesn't seem able to utilize the full speed of it iirc ~40MB/s ?
<jernej>
oh, yes, this one will be a bit tricky. 5 gpios with unknown functionality
<KREYREN_oftc>
might be bcs the sdcard's overheating though
<apritzel>
KREYREN_oftc: the SD card interface on the A64 is single voltage from the SoC side, so you are limited to speed modes that work with 3.3V only
<KREYREN_oftc>
apritzel, i know just exploring in case there is some magic card that works better in teres
acmeplus has joined #linux-sunxi
<acmeplus>
jernej: yeah, looking at the gpio comparison I can see gpios 264, 265, 266, 270, and 271 are exported when the internal display is switched on
<apritzel>
KREYREN_oftc: which is "High Speed": 50 MHz SDR at 4 bits => 25 MB/s
<apritzel>
KREYREN_oftc: are you hoping for magic here?
<KREYREN_oftc>
apritzel, the issue on those seems to be overheating so i was thinking that maybe using XC would manage that better for more constant speeds
<jernej>
acmeplus: do you know where I can download update file? I'll try to extract lcd driver. It should make clear what is proper order to turn on LCD
<KREYREN_oftc>
bcs the storage speed is a major bottleneck on teres
<gamiee>
eMMC exists for that reason KREYREN
<apritzel>
KREYREN_oftc: one *could* put all SD card pins through a level shifter and add an extra regulator to switch that, but no one seemed to care enough to do that
<KREYREN_oftc>
gamiee, ye but the eMMC on the teres is slower than the sdcard and i am struggling finding a compatible alternative to replace that without having to fabricate a new mainboard https://git.dotya.ml/KREYLIMEX/TERES/issues/3
<apritzel>
or you take one of the new SoCs (H616 or later), that support that more natively
<KREYREN_oftc>
gamiee, ye projected to be fixed in new design just exploring options for data tm
<KREYREN_oftc>
*atm
<apritzel>
KREYREN_oftc: just choose a design that uses 1.8V for the I/O voltage, many other boards do, including the Pine64-LTS for instance
<KREYREN_oftc>
apritzel, why?
<apritzel>
I think the best I have seen is 120 MB/s, with HS-200, probably limited by the actual flash chip
<apritzel>
because 3.3V I/O voltage limits you speed options
<macromorgan>
not only do I not have schematics, I'm pretty sure the devicetree is all wrong (not a single regulator definition except the CPU reg)
<KREYREN_oftc>
apritzel, hmm i guess the thing is that there are lot of pin-compatible options that would be great for current teres usesrs to just reflow the chip that i would like to make easier https://imgur.com/cagBR69
<KREYREN_oftc>
but they have some weird shit in th A and B rows that are NC on the current design
<jernej>
macromorgan: regulators could be pre-set and just left on
<apritzel>
there is both the interface limit and the chip's transfer limit to consider
<apritzel>
as it stands at the moment, the kernel would limit the interface to eMMC High Speed, which is 50 MB/s
<apritzel>
among an eMMC chip series, smaller chips (8GB, 16GB) tend to be much slower
<KREYREN_oftc>
apritzel, ye it has a 16GB eMMC atm
<apritzel>
also write performance on those small chips is typically abysmal, like a few MB/s only
<KREYREN_oftc>
yea
<KREYREN_oftc>
tsvetan allegedly designed it bcs the eMMC chips were too expensive and for them to be easily replacible by the user for a better once so trying to explore that route prior to releasing new designs tbh
<KREYREN_oftc>
if the 1.8V are better then i wonder if i can add a resistor there
<KREYREN_oftc>
probably really bad idea as it's probably using that voltage to do high and lows
<apritzel>
that's not that easy, because it needs to be bidirectional
<apritzel>
the datasheet of that Micron chip above says it's 60MB/s write and 180MB/s read performance for the 16GB version, but in HS-200 mode, so with 1.8V only
<KREYREN_oftc>
ye like ideally i would like to add a link to e.g. octoparts to the wiki that will print out a list of compatible chips for replacement
<KREYREN_oftc>
but it's a loot of reading
<apritzel>
most AW MMC controllers are limited to 150 MHz, though, so you can't expect more than 150MB/s
<KREYREN_oftc>
and that 60MB/s is probably too slow as based on gnome benchmark it peaks at 48MB/s
<apritzel>
50MB/s would be the interface limit in your case
<KREYREN_oftc>
So basically getting the peak performance with that sdcard?
<apritzel>
you can try to enable HS DDR mode, though this rarely works on AW boards: add "mmc-ddr-3_3v;" to the mmc2 DT node
<apritzel>
that should use 52 MHz @ DDR @ 8bits -> 100 MB/s
<apritzel>
104 MB/s, but who counts
<KREYREN_oftc>
100MB/s would be optimal why it rarely works on AW?
<apritzel>
that is unclear, to be honest, I think it's often a trace issue
<apritzel>
we have seen boards that run fine at 150 MHz SDR, but fail with 50 MHz DDR
<KREYREN_oftc>
with that change if it works it should be noticable on the used sdcard right?
<apritzel>
if you mean eMMC, then I guess yes, you should see faster read speeds
<apritzel>
not sure about the writes, though
ftg has joined #linux-sunxi
<KREYREN_oftc>
i meant the sdcard used for eMMC i first need to find a suitable replacement as the MTFC16GAKAENA-4M is too small for painless testing
<KREYREN_oftc>
* used, for ..
<apritzel>
for the real SD cards you are locked to the 25MB/s, and there is nothing you can do about that, without redesigning the circuit and adding this level shifter
<KREYREN_oftc>
i see
youmukonpaku1337 has joined #linux-sunxi
bauen1 has quit [Ping timeout: 480 seconds]
<apritzel>
jernej: by the way: I put a UHS-1 card in my H618 TV box, and it read at 50 MB/s with the BSP kernel, so that voltage switching is working there
youmukon1 has quit [Read error: Connection reset by peer]
<KREYREN_oftc>
apritzel, do you know if there is a capacity limit on the eMMC for A64? I can't find anything about it in datasheet
<apritzel>
I don't think there is such a limit, really
<apritzel>
because the storage size is a MMC protocol property, not a controller one
<macromorgan>
what's the max block address?
<apritzel>
I think you hit a limit in your wallet first ;-)
<apritzel>
diego71: that sounds ... weird, are you sure it's not the other way around? but even then it sounds like something is off
<apritzel>
what kernel and DT is this with? AW BSP based kernel or mainline?
apritzel has quit [Ping timeout: 480 seconds]
<diego71>
kernel 6.7.6 with patches for display clock and gpu trip point
Schimsalabim has quit [Read error: Connection reset by peer]
<diego71>
i'll double check
Schimsalabim has joined #linux-sunxi
<diego71>
apritzel you are right: 67.83 internal emmc, 22.25 microsd
<diego71>
retested with 6.7.6+ kernel
<diego71>
debian kernel 6.1 have similar number
DarkNeutrino has quit [Read error: Connection reset by peer]
DarkNeutrino has joined #linux-sunxi
acmeplus has quit [Ping timeout: 480 seconds]
acmeplus has joined #linux-sunxi
youmukon1 has joined #linux-sunxi
acmeplus has quit []
youmukonpaku1337 has quit [Read error: Connection reset by peer]
apritzel has joined #linux-sunxi
youmukonpaku1337 has joined #linux-sunxi
<apritzel>
diego71: ah, that makes more sense, thanks for checking! 67 MB/s is not too bad for a 3.3V eMMC
youmukon1 has quit [Ping timeout: 480 seconds]
electricworry has joined #linux-sunxi
youmukonpaku1337 has quit [Read error: Connection reset by peer]
bauen1 has joined #linux-sunxi
Schimsalabim has quit [Read error: Connection reset by peer]
DarkNeutrino has quit [Ping timeout: 480 seconds]
Schimsalabim has joined #linux-sunxi
<apritzel>
acmeplus, macromorgan, tokyovigilante: I had reports that the 32K clock fanout is not very accurate on the H616, when not having an external crystal oscillator: someone measured 29 KHz.
<apritzel>
This is most likely because we miss calibration in the RTC driver. I have no clue if this actually affects the WiFi or BT in actual operation, but maybe something to investigate