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
Syter has joined #linux-sunxi
vagrantc has quit [Quit: leaving]
ftg has quit [Read error: Connection reset by peer]
montjoie_ has quit [Ping timeout: 480 seconds]
apritzel has quit [Ping timeout: 480 seconds]
flyback has quit []
<ity> OH
<ity> Which drivers is it handled by? Which devices does devfreq scale
flyback has joined #linux-sunxi
evgeny_boger has joined #linux-sunxi
evgeny_boger has quit [Ping timeout: 480 seconds]
evgeny_boger has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
hexdump0815 has joined #linux-sunxi
hexdump01 has quit [Ping timeout: 480 seconds]
KREYREN_oftc has quit [Remote host closed the connection]
evgeny_boger has quit [Quit: evgeny_boger]
ungeskriptet has joined #linux-sunxi
junari has joined #linux-sunxi
ungeskriptet has quit [Quit: Ping timeout (120 seconds)]
ungeskriptet has joined #linux-sunxi
ungeskriptet is now known as Guest621
ungeskriptet has joined #linux-sunxi
Guest621 has quit [Ping timeout: 480 seconds]
ungeskriptet is now known as Guest623
ungeskriptet has joined #linux-sunxi
Guest623 has quit [Ping timeout: 480 seconds]
ungeskriptet has quit [Quit: Ping timeout (120 seconds)]
ungeskriptet has joined #linux-sunxi
montjoie has joined #linux-sunxi
ungeskriptet is now known as Guest626
ungeskriptet has joined #linux-sunxi
Guest626 has quit [Ping timeout: 480 seconds]
ungeskriptet is now known as Guest628
ungeskriptet has joined #linux-sunxi
Guest628 has quit [Ping timeout: 480 seconds]
ungeskriptet is now known as Guest629
ungeskriptet has joined #linux-sunxi
Guest629 has quit [Ping timeout: 480 seconds]
apritzel has joined #linux-sunxi
ungeskriptet is now known as Guest631
ungeskriptet has joined #linux-sunxi
Guest631 has quit [Ping timeout: 480 seconds]
apritzel has quit [Ping timeout: 480 seconds]
ungeskriptet is now known as Guest633
ungeskriptet has joined #linux-sunxi
Guest633 has quit [Ping timeout: 480 seconds]
ungeskriptet is now known as Guest635
ungeskriptet has joined #linux-sunxi
ungeskriptet has quit []
Guest635 has quit [Ping timeout: 480 seconds]
warpme has joined #linux-sunxi
junari_ has quit [Remote host closed the connection]
bauen1 has quit [Ping timeout: 480 seconds]
junari has quit [Ping timeout: 480 seconds]
warpme has quit []
apritzel has joined #linux-sunxi
<apritzel> ity: CPUFREQ_DT and the generic cpufreq governors
warpme has joined #linux-sunxi
dsimic is now known as Guest656
dsimic has joined #linux-sunxi
Guest656 has quit [Ping timeout: 480 seconds]
warpme has quit []
bauen1 has joined #linux-sunxi
warpme has joined #linux-sunxi
colinsane has quit []
colinsane has joined #linux-sunxi
<jernej> apritzel: regarding your wiki edit, H616 video engine is simple to support, but it needs new SRAM handling, otherwise it will break thermal driver
<apritzel> jernej: ah, thanks, funny enough I was just looking at this SRAM part in your github ;-)
<apritzel> jernej: so this SRAM C1 is for VE or DE?
<jernej> I didn't bother to properly implement it yet
<apritzel> and are you sure it's really all those bits in register 0? because in my experiments reg 0 didn't do anything, but bit 24 in reg 0x4 changed access
<apritzel> so like sun50i_a64_sram_c
<jernej> as I said, my code is not correct
<jernej> because I assumed it's same as on H6
<jernej> let me check
<apritzel> OK, but those patches were successfully used by people already, weren't they?
<jernej> yeah, Cedrus works with them
<apritzel> I think I saw somewhere else that just bit 0 in reg 0x0 was used
<apritzel> which would solve the clash with the thermal driver, I guess?
<apritzel> jernej: btw: I wrote some GPU PPU driver: 125 lines of mostly boilerplate to flip a single bit ;-)
<jernej> oh, great
<jernej> please send it
<apritzel> but then realised that we already somewhat claim that PRCM region via the CCU-R driver
<apritzel> atm we limit its size to 0x210, which is just the last register used there
<apritzel> so I was wondering if the PPU driver should be put into ccu-sun50i-h6-r.c
<jernej> BSP code has two bits for Cedrus - bit 0 in reg 0 and bit 24 in reg 4
<apritzel> does anyone have any pointer to some H616 PRCM documentation? I mean we know about the clock bits there, where did this info come from? smaeul, any hints?
<apritzel> jernej: so both for VE?
<jernej> I guess. There are following comments: "remapping SRAM to MACC for codec test" and "clear bootmode bit for give sram to ve" for bit 0 and bit 24, respectively
<jernej> although I switched only first and it worked as far as I tested
<jernej> definitvely some testing is needed
<apritzel> so is it two independent bits? One to connect the VE to the SRAM, and the other to connect the CPU to the SRAM?
<apritzel> so if you leave bit 24 on, you *could* disturb the VE memory from the CPU? But it doesn't hurt if you leave the access on, but just don't touch it?
<jernej> I'm confused by the comments,
<jernej> I've seen glitches when using AFBC compression, so maybe that's a reason?
<jernej> *the reason
<apritzel> so anyway we could just have two allwinner,sram elements in the VE DT node, and let them point to reg0x0/bit0 and reg0x4/bit24 in the SRAM (driver)?
<apritzel> that should not disturb the thermal driver usage, I made sure they share the same lock, and thermal just asks for exactly only bit reg0x0/bit16
colinsane has quit []
<jernej> ok, so bit 24 in reg 4 is usually associated with display engine
<jernej> that's an easy test
<jernej> and my confusion with clearing proper bits is understandable
<jernej> there is different code between 4.9 and 5.4 based BSP
colinsane has joined #linux-sunxi
<jernej> 5.4 clears only bit 0, while 4.9 clears much more
<apritzel> IIRC, clearing reg0x4/bit24 made all of SRAM C read-as-zero/write-ignore from the CPU. When setting the bit back, all the old content reappeared
<apritzel> (that was in U-Boot)
<jernej> btw, are thermal patches applied?
<apritzel> jernej: do you want any last minute change in there?
<apritzel> but I guess we can fix any potential conflicts when the VE/DE patches appear?
<jernej> no, it wasn't clear to me if I should also apply DT patch
<jernej> I will, before I send PRs later today
<apritzel> IIUC, that was Daniel's idea: he takes the code & bindings, you take the .dts patch
<jernej> sure, but I can't see patches in linux-next
<apritzel> I can poke him ...
macromorgan_ has joined #linux-sunxi
macromorgan_ has quit [Remote host closed the connection]
<apritzel> done
macromorgan has quit [Ping timeout: 480 seconds]
macromorgan has joined #linux-sunxi
hitechshell has joined #linux-sunxi
hitechshell has quit []
nitechshell has joined #linux-sunxi
colinsane has quit []
nitechshell has quit []
bauen1 has quit [Ping timeout: 480 seconds]
colinsane has joined #linux-sunxi
hitechshell has joined #linux-sunxi
wingrime has joined #linux-sunxi
wingrime has quit []
wingrime-ww has joined #linux-sunxi
<wingrime-ww> hi! anyone got Teclast P85T in fel mode?
<wingrime-ww> dd
<wingrime-ww> dd'ing toc0 to sdcard does not works, wonder why
hitechshell has quit []
hitechshell has joined #linux-sunxi
hitechshell has quit []
hitechshell has joined #linux-sunxi
hitechshell has quit [Quit: Page closed]
hitechshell has joined #linux-sunxi
<apritzel> wingrime-ww: which toc0, exactly? fel-sdboot? or something nicked from some vendor image?
<hitechshell> Hello. I successfully launched uboot, but usb does not work. After some searching I managed to find out that if I manually set the value 1 for the usb_det_vbus_gpio pin, then the usb starts working. device: pocketbook 614 plus
<hitechshell> Can anyone tell me what I'm doing wrong?
hitechshell has quit []
hitechshell has joined #linux-sunxi
<apritzel> wingrime-ww: I had it going into FEL mode with some fel-sdboot version a few weeks ago, but couldn't reproduce it last week. Will debug it this weekend.
<apritzel> wingrime-ww: but I got my own code running from a TOC0 on SD card, and I managed to boot a boot0.toc0 isolated from a vendor image
<wingrime-ww> apeitzel: I tried converted image from
<apritzel> that's is using 0x10060 as the load address, right? Try 0x20060
<wingrime-ww> I also have seen fel usb in dmesg for short period of time...
<apritzel> wingrime-ww: also you can use U-Boot's mkimage now, that natively supports TOC0: mkimage -t sunxi_toc0 ...
<apritzel> hitechshell: what is the SoC on this device? And what U-Boot version are you running? mainline?
<wingrime-ww> apritzel: mainline uboot?
<apritzel> wingrime-ww: yes, tools/mkimage in any halfway recent U-Boot tree. Some distros ship mkimage also via the u-boot-tools package
<apritzel> mksunxiboot or the conversion from egon -> toc0 are now obsolete
<wingrime-ww> apritzel: thanks
hitechshell has quit [Quit: Page closed]
<apritzel> jernej: check you email, Daniel replied. I guess this means you can merge the .dts patch ...
hitechshell has joined #linux-sunxi
<jernej> yeah, I saw. I will.
<hitechshell> apritzel: soc is https://linux-sunxi.org/A13
<hitechshell> (sorry for delay. It turns out my messages were not sent)
<hitechshell> i use mainline uboot
<hitechshell> devicetree: https://bpa.st/KWL56 config: https://bpa.st/PKQ5G
<apritzel> hitechshell: and there is only one (external) USB port, which is USB0, I guess?
f_ has quit [Ping timeout: 480 seconds]
<hitechshell> yes
f_ has joined #linux-sunxi
<hitechshell> i really dont know what is usb1 (but in script.fex it exist)
<hitechshell> script.fex https://bpa.st/GZ4ZY
<apritzel> something internally connected, maybe? Like Wifi? We have seen this on some devices before
<hitechshell> maybe. there is space on the board for a wifi module
<wingrime-ww> apritzel: sd-card boot ignored, tablet goes to android boot, mkimage -A arm -T sunxi_toc0 -a 0x20060 -d sunxi-tools/bin/fel-sdboot.sunxi output.toc0
<wingrime-ww> maybe I need fel-sdboot from vendor image&
<hitechshell> apritzel: As far as I understand, the board understands that the wire is connected according to the state of the pin specified in CONFIG_USB0_VBUS_DET
<hitechshell> but according to "gpio state -a" in uboot nothing changes when connecting/unplugging the cable
junari has joined #linux-sunxi
junari has quit [Remote host closed the connection]
warpme has quit []
<apritzel> hitechshell: please note that this pin is not the ID det pin, but the VBUS detect pin. That's something internal that senses whether VBUS is supplied via the cable
<apritzel> hitechshell: but the U-Boot code around this is particularly confusing, if not buggy. I need to have a closer look ...
<apritzel> wingrime-ww: you need to write fel-sdboot.bin, otherwise it's double wrapped
<hitechshell> apritzel: I looked at the code. checking the presence of a cable is to check the status of this pin
ity has quit [Remote host closed the connection]
ity has joined #linux-sunxi
<apritzel> hitechshell: actually, do you want to use it in gadget mode, or in host mode?
<hitechshell> at least in gadget mode (if I understand correctly, this is when the wire is connected from the computer to the device)
<hitechshell> I managed to achieve this, but only by manually setting the state of this pin
<apritzel> this pin is optional, I think, have you tried without it?
<hitechshell> optional? no, I haven't tried it
bauen1 has joined #linux-sunxi
<hitechshell> apritzel: Do you mean remove it from the config or even from devicetree? ​
<apritzel> yeah, you can try both. You said "nothing changes when connecting/unplugging a cable": is there some host connected on the other end, supplying a VBUS voltage that the board could detect?
<hitechshell> the other end of the wire is connected to the laptop
<apritzel> and that GPIO is used as VBUS detect in the FEX file?
<hitechshell> [usbc0]usb_used = 1 usb_port_type = 2 usb_detect_type = 1 usb_id_gpio = port:PG02<0><1><default><default> usb_det_vbus_gpio = port:PG01<0><0><default><default> usb_drv_vbus_gpio = port:PG12<1><0><default><0> usb_host_init_state = 0
wingrime-ww has quit [Quit: Lost terminal]
ity has quit [Ping timeout: 480 seconds]
ity has joined #linux-sunxi
wingrime-ww has joined #linux-sunxi
vagrantc has joined #linux-sunxi
wingrime-ww has quit [Quit: leaving]
wingrime-ww has joined #linux-sunxi
ity has quit [Ping timeout: 480 seconds]
colinsane has quit []
<wingrime-ww> success AWUSBFEX ID=0x00189000(A523/A527/MR527/T527) dflag=0x44 dlength=0x08 scratchpad=0x00061500
apritzel has quit [Ping timeout: 480 seconds]
ity has joined #linux-sunxi
colinsane has joined #linux-sunxi
ity has quit [Remote host closed the connection]
ity has joined #linux-sunxi
<wingrime-ww> I added instructions about xfel https://linux-sunxi.org/Teclast_P85T
KREYREN_oftc has joined #linux-sunxi
JohnDoe_71Rus has quit [Quit: KVIrc 5.2.0 Quasar http://www.kvirc.net/]
vagrantc has quit [Ping timeout: 480 seconds]
vagrantc has joined #linux-sunxi
apritzel has joined #linux-sunxi
ungeskriptet has joined #linux-sunxi
<apritzel> wingrime-ww: ah, great, curious why this didn't work for me last week ...
<apritzel> wingrime-ww: do you have any ambitions, plans or even patches for upstreaming?
<apritzel> I am at offset 0xa74 for the clock driver
ungeskriptet is now known as Guest688
ungeskriptet has joined #linux-sunxi
Guest688 has quit [Ping timeout: 480 seconds]
vagrantc has quit [Ping timeout: 480 seconds]
ungeskriptet is now known as Guest689
ungeskriptet has joined #linux-sunxi
ungeskriptet has quit []
ungeskriptet has joined #linux-sunxi
Guest689 has quit [Ping timeout: 480 seconds]
vagrantc has joined #linux-sunxi
ungeskriptet has quit [Quit: Ping timeout (120 seconds)]
ungeskriptet has joined #linux-sunxi
ungeskriptet has quit [Quit: Ping timeout (120 seconds)]
ungeskriptet has joined #linux-sunxi
ungeskriptet has quit [Quit: Ping timeout (120 seconds)]
ungeskriptet has joined #linux-sunxi
ungeskriptet has quit []
ungeskriptet has joined #linux-sunxi
hitechshell has quit [Remote host closed the connection]
ungeskriptet has quit [Quit: Ping timeout (120 seconds)]
ungeskriptet has joined #linux-sunxi
ungeskriptet has quit [Quit: Ping timeout (120 seconds)]
ungeskriptet has joined #linux-sunxi
ungeskriptet is now known as Guest696
ungeskriptet has joined #linux-sunxi
ungeskriptet has quit []
ungeskriptet has joined #linux-sunxi
Guest696 has quit [Ping timeout: 480 seconds]
ungeskriptet has quit []
ungeskriptet has joined #linux-sunxi
<apritzel> wingrime-ww: are you sure the SID dump is correct? I think at least lcjs should have the secure boot bit set ...
ungeskriptet has quit [Quit: Ping timeout (120 seconds)]
ungeskriptet has joined #linux-sunxi
<apritzel> in previous experiments the FEL mode (entered this way) was non-secure, so the SID reads might be heavily filtered: all the later fuses read as zero
ungeskriptet has quit []
ungeskriptet has joined #linux-sunxi
ungeskriptet is now known as Guest699
ungeskriptet has joined #linux-sunxi
Guest699 has quit [Ping timeout: 480 seconds]
ungeskriptet is now known as Guest701
ungeskriptet has joined #linux-sunxi
ungeskriptet has joined #linux-sunxi
Guest701 has quit [Ping timeout: 480 seconds]
ungeskriptet is now known as Guest703
ungeskriptet has joined #linux-sunxi