ChanServ changed the topic of #linux-sunxi to: Allwinner/sunxi development - Did you try looking at our wiki? https://linux-sunxi.org - Don't ask to ask. Just ask and wait for an answer! - This channel is logged at https://oftc.irclog.whitequark.org/linux-sunxi
hentai has joined #linux-sunxi
hentai has quit [Read error: Connection reset by peer]
Esmil has quit [Remote host closed the connection]
Esmil has joined #linux-sunxi
youmukonpaku1337 has joined #linux-sunxi
Daanct12 has joined #linux-sunxi
youmukonpaku1337 has quit [Remote host closed the connection]
youmukonpaku1337 has joined #linux-sunxi
apritzel has quit [Ping timeout: 480 seconds]
Schimsalabim has joined #linux-sunxi
youmukonpaku1337 has quit [Remote host closed the connection]
ftg has quit [Read error: Connection reset by peer]
youmukonpaku1337 has joined #linux-sunxi
montjoie_ has joined #linux-sunxi
montjoie has quit [Ping timeout: 480 seconds]
youmukon1 has joined #linux-sunxi
youmukonpaku1337 has quit [Read error: Connection reset by peer]
acmeplus has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
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]
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]
<LordKalma> https://www.aliexpress.com/item/1005006495583584.html for the price sounds like an interesting toy
Daanct12 has quit [Quit: WeeChat 4.2.1]
jagan_ has joined #linux-sunxi
Daanct12 has joined #linux-sunxi
warpme has joined #linux-sunxi
apritzel has quit [Remote host closed the connection]
apritzel has joined #linux-sunxi
Daanct12 has quit [Quit: WeeChat 4.2.1]
youmukon1 has quit [Remote host closed the connection]
youmukonpaku1337 has joined #linux-sunxi
JohnDoe_71Rus has quit [Quit: KVIrc 5.0.1 Aria http://www.kvirc.net/]
warpme has quit []
<jakllsch> LordKalma: hmm, powervr
<jakllsch> i wonder how it compares to the anbernic rockchip units
youmukonpaku1337 has quit [Remote host closed the connection]
youmukonpaku1337 has joined #linux-sunxi
DarkNeutrino has quit [Ping timeout: 480 seconds]
DarkNeutrino has joined #linux-sunxi
wasutton- has quit []
youmukonpaku1337 has quit [Remote host closed the connection]
youmukonpaku1337 has joined #linux-sunxi
youmukonpaku1337 has quit [Remote host closed the connection]
youmukonpaku1337 has joined #linux-sunxi
jagan_ has quit [Remote host closed the connection]
apritzel_ has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
apritzel__ has joined #linux-sunxi
apritzel has quit [Ping timeout: 480 seconds]
apritzel__ has left #linux-sunxi [#linux-sunxi]
apritzel_ has quit [Ping timeout: 480 seconds]
apritzel has joined #linux-sunxi
youmukonpaku1337 has quit [Remote host closed the connection]
youmukonpaku1337 has joined #linux-sunxi
junari has joined #linux-sunxi
<apritzel> LordKalma: toy for what? Playing games or getting mainline Linux to run on it?
<jakllsch> why not both?
<apritzel> because getting mainline on it will be a pain!
bauen1 has quit [Ping timeout: 480 seconds]
<apritzel> given the lacklustre A100/A133 support we have
<apritzel> getting the Anbernic RG35XX units is much more promising, and they are one sale atm ...
<jakllsch> those are what, H700?
<apritzel> yes, which is basically H616 + RGB LCD
acmeplus has joined #linux-sunxi
<apritzel> and the H616 is definitely better than the A133, I'd say, not only in terms of mainline support
<acmeplus> apritzel: what would be the path to try to tinker with the LCD? would that be similar to the LCD support on the T507?
<apritzel> acmeplus: I'd say identical ;-)
<acmeplus> Also I captured the gpio map from stock with lcd and hdmi: https://gist.github.com/acmeplus/44e9f0778204d32d188c518e681cc19f
<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 = <&reg_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]
bauen1_ has joined #linux-sunxi
bauen1 has quit [Ping timeout: 480 seconds]
bauen1 has joined #linux-sunxi
bauen1_ has quit [Ping timeout: 480 seconds]
acmeplus has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
Schimsalabim has quit [Ping timeout: 480 seconds]
<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
<jernej> right, let me check bsp dt
wasutton3 has joined #linux-sunxi
<KREYREN_oftc> diego71, what sdcard are you using in teres? I am using https://www.alza.cz/sandisk-microsdxc-128gb-nintendo-switch-a1-uhs-i-v30-u3-d5575543.htm and it's still very slow with it
<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
<acmeplus> jernej: the initial partitions from stock are here: https://github.com/rg35xx-cfw/batocera.linux/tree/rg35xx-plus-wip/board/batocera/allwinner/h700/rg35xx-plus/partitions For a full update let me find what anbernic has, afaik is a full image
<apritzel> KREYREN_oftc: is the eMMC using 3.3V only as well?
<KREYREN_oftc> apritzel, seems to be
<gamiee> well, slow eMMC sounds as issue of board
<gamiee> ( apritzel : correct me if I am wrong please)
<acmeplus> jernej: this is anbernic link to their OS: https://mega.nz/folder/MmcQFJTL#pxmRBcVMt4EcGlDY6ZRe9g
<apritzel> yes, vqmmc supply is DCDC1 @ 3.3V
<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
<KREYREN_oftc> https://www.digikey.cz/en/products/detail/micron-technology-inc/MTFC32GAPALNA-AAT/7918879 though this one is the replacement for the obsolete chip that teres has now so it should work?
<KREYREN_oftc> hard to know really
<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> that's pretty slow and 8GB max only?
<KREYREN_oftc> says 64GB?
<KREYREN_oftc> seems to be the same class as the current emmc
<apritzel> looks like 64 Gbit to me?
<KREYREN_oftc> oh
<apritzel> and the datasheet only talks of 4GB and 8GB versions
<apritzel> write speed maxes out at 24 MB/s, which does not sound good
<KREYREN_oftc> https://octopart.com/datasheet/mtfc16gakaena-4m+it-micron-44694452 16,32,64GB for the TBGA-100 14x18 ?
<apritzel> a bit better, but the one you had first was even better: Micron MTFCxxGAP
acmeplus has quit [Remote host closed the connection]
acmeplus has joined #linux-sunxi
<KREYREN_oftc> can't find any suppliers for any of these atm
* KREYREN_oftc is going to sleep and will look into it later
chewitt has quit [Quit: Zzz..]
apritzel has quit [Ping timeout: 480 seconds]
flyback has quit []
flyback has joined #linux-sunxi
vagrantc has joined #linux-sunxi
<diego71> KREYREN_oftc: 13.30MB/s internal emmc, 69.60MB/s Kingstone microsd 32GB Canvas Select plus
<diego71> tested with hdparm -t /dev/mmcblk[02]
acmeplus has quit [Ping timeout: 480 seconds]
JohnDoe_71Rus has quit [Quit: KVIrc 5.2.0 Quasar http://www.kvirc.net/]
acmeplus has joined #linux-sunxi
apritzel has joined #linux-sunxi
<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
vagrantc has quit [Quit: leaving]