Turl changed the topic of #linux-sunxi to: Allwinner/sunxi /development discussion - did you try looking at our wiki? https://linux-sunxi.org - Don't ask to ask. Just ask and wait! - https://github.com/linux-sunxi/ - Logs at http://irclog.whitequark.org/linux-sunxi
chomwitt has quit [Ping timeout: 265 seconds]
clemens3 has quit [Ping timeout: 260 seconds]
liushuyu has quit [Quit: liushuyu]
anarsoul has quit [Ping timeout: 240 seconds]
pgreco has joined #linux-sunxi
<pgreco> Hello, I'm having problems booting my bananapi-m3 (a83t) after upgrading from 4.14 to 4.15rc
<pgreco> it doesn't recognize the mmc anymore, so it can't find the root filesystem
dave0x6d has quit [Quit: Connection closed for inactivity]
<pgreco> the strange thing is that if I replace the dtb with the old one (4.14) boots ok
<pgreco> wens, the only changes to the dtb what I found are wens' new regulators and wifi
voxadam has quit [Quit: WeeChat 1.9.1]
liushuyu has joined #linux-sunxi
anarsoul has joined #linux-sunxi
argulp has quit [Ping timeout: 240 seconds]
chlorine has joined #linux-sunxi
tl_lim has quit [Ping timeout: 265 seconds]
chlorine has quit [Ping timeout: 272 seconds]
tl_lim has joined #linux-sunxi
liushuyu has quit [Quit: liushuyu]
liushuyu has joined #linux-sunxi
tl_lim has quit [Ping timeout: 265 seconds]
tl_lim has joined #linux-sunxi
tl_lim has quit [Ping timeout: 265 seconds]
tl_lim has joined #linux-sunxi
muvlon has quit [Quit: Leaving]
tgaz has joined #linux-sunxi
junnie has joined #linux-sunxi
liushuyu has quit [Quit: liushuyu]
ninolein has quit [Ping timeout: 240 seconds]
ninolein has joined #linux-sunxi
popolon has quit [Quit: WeeChat 2.0]
cnxsoft has joined #linux-sunxi
junnie has quit [Ping timeout: 272 seconds]
LargePrime has quit [Ping timeout: 256 seconds]
Ntemis has quit [Remote host closed the connection]
junnie has joined #linux-sunxi
tlwoerner has joined #linux-sunxi
tlwoerner has joined #linux-sunxi
tlwoerner has quit [Changing host]
<wens> do you have all the axp-related drivers enabled and builtin?
tl_lim has quit [Ping timeout: 265 seconds]
tl_lim has joined #linux-sunxi
junnie has quit [Ping timeout: 265 seconds]
tl_lim has quit [Ping timeout: 265 seconds]
tl_lim has joined #linux-sunxi
junnie__ has joined #linux-sunxi
vagrantc has quit [Ping timeout: 255 seconds]
Hao has joined #linux-sunxi
voxadam has joined #linux-sunxi
vagrantc has joined #linux-sunxi
argulp has joined #linux-sunxi
argulp has quit [Ping timeout: 256 seconds]
liushuyu has joined #linux-sunxi
lurchi__ is now known as lurchi_
matthias_bgg has joined #linux-sunxi
cnxsoft has quit [Read error: Connection reset by peer]
cnxsoft has joined #linux-sunxi
liushuyu has quit [Quit: liushuyu]
vagrantc has quit [Quit: leaving]
tl_lim has quit [Read error: Connection reset by peer]
chlorine has joined #linux-sunxi
kaspter has joined #linux-sunxi
chlorine has quit [Ping timeout: 265 seconds]
kaspter1 has joined #linux-sunxi
<icenowy[m]> wens: I got a H5 ver of ALL-H3-CC Tritium board
<icenowy[m]> (along with a H3 ver now
Gerwin_J has joined #linux-sunxi
kaspter has quit [Ping timeout: 248 seconds]
kaspter1 is now known as kaspter
nuuuciano has quit [Ping timeout: 240 seconds]
<wens> hmm
lurchi_ is now known as lurchi__
TheSeven has quit [Ping timeout: 240 seconds]
nuuuciano has joined #linux-sunxi
freemangordon has quit [Read error: Connection reset by peer]
TheSeven has joined #linux-sunxi
IgorPec has joined #linux-sunxi
TheSeven has quit [Ping timeout: 265 seconds]
liushuyu has joined #linux-sunxi
hardfalcon1 has joined #linux-sunxi
hardfalcon has quit [Ping timeout: 256 seconds]
junnie__ has quit [Ping timeout: 256 seconds]
lurchi_ has joined #linux-sunxi
lurchi__ has quit [Ping timeout: 240 seconds]
junnie__ has joined #linux-sunxi
liushuyu has quit [Quit: liushuyu]
nuuuciano has quit [Ping timeout: 265 seconds]
reinforce has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
foxx_ has joined #linux-sunxi
aalm has joined #linux-sunxi
freemangordon has joined #linux-sunxi
DullTube has joined #linux-sunxi
aalm has quit [Ping timeout: 272 seconds]
argulp has joined #linux-sunxi
TheSeven has joined #linux-sunxi
xes_ has joined #linux-sunxi
yann has quit [Ping timeout: 260 seconds]
xes has quit [Ping timeout: 255 seconds]
ernestask has joined #linux-sunxi
cnxsoft has quit [Quit: cnxsoft]
cnxsoft has joined #linux-sunxi
rasp has joined #linux-sunxi
chomwitt has joined #linux-sunxi
<wens> my opi-p2e seems to crash/hang easily
<KotCzarny> power? undervoltage in dvf?
<KotCzarny> dvfs*
<wens> no idea atm
<wens> not really willing to spend time on it
<KotCzarny> try armbian to confirm it's not a bad board/setup
<KotCzarny> will take 10-20 minutes to install and run stress command
<wens> the h3 doesn't even have dvfs on mainline :/
<icenowy[m]> wens: maybe I should take over the device tree mainlineing effort of ALL-H3-CC?
junnie__ has quit [Ping timeout: 265 seconds]
<KotCzarny> armbian has it patched in
<KotCzarny> that's why i'm suggesting it
<icenowy[m]> As I have H5 ver
sr-digitronic has joined #linux-sunxi
<icenowy[m]> ohhhhhhhh
<icenowy[m]> the H3 ver dt is applied
<icenowy[m]> oops
<wens> icenowy[m]: :)
<icenowy[m]> in fact I have some WIP branch for BPi M2+ H5
<icenowy[m]> but I won't push them until Banana Pi make pots a accessory for BPi M2+ ;-)
<wens> icenowy[m]: my original idea was to have the h5 version #include both the h3 version dts and h5.dtsi, in that order
<wens> don't know if that would work.
<icenowy[m]> I think it may not
<wens> if it doesn't, will need to pull out everything into a common dtsi file
<icenowy[m]> DTSI's do not have include guard
<icenowy[m]> I agree the common DTSI way
<wens> anyway, I won't get my board until next year maybe lol
<wens> pots? accessory?
<icenowy[m]> H5?
<wens> yeah, H5 ver.
hardfalcon1 has quit [Quit: Leaving.]
<mripard_> KotCzarny: armbian has patched everythintg
junnie has joined #linux-sunxi
<mripard_> the issue is that armbian doesn't upstream most of their patches
<mripard_> so it really doesn't help.
<KotCzarny> well, it would help to confirm if it's a problem with wens' setup (hw/sw) or not
chlorine has joined #linux-sunxi
chlorine has quit [Remote host closed the connection]
<ElBarto> does new operating point table needs to be in v2 format ?
<ElBarto> or does v1 is still accepted ?
<mripard_> ElBarto: if possible, go for v2
<ElBarto> mripard_: ok, I'll need to code a v2 driver for FreeBSD first then :)
<ElBarto> I've never upstreamed the dvfs patches that we had for h3 because it was v1
<ElBarto> I've removed them and now only uses mainline dts, don't want to deal with local patches
<wens> a80 mmc seems broken :(
<mripard_> ElBarto: good :)
hardfalcon has joined #linux-sunxi
Pe3ucTop has joined #linux-sunxi
junnie has quit [Ping timeout: 256 seconds]
<smaeul> I'm writing a Linux msgbox driver for use with SCPI. ATF is responsible for turning on the msgbox when loading ARISC firmware, so the hardware is already enabled when Linux boots. What do I do about clock/reset in the Linux driver? Ignore them? Try to enable anyway?
<smaeul> and failing to probe the driver shouldn't turn off the hardware (or else ATF couldn't use it)... but leaving the hardware half-configured seems ugly
<mripard_> well, you don't really have much choice
Pe3ucTop has quit [Ping timeout: 264 seconds]
matthias_bgg has quit [Ping timeout: 256 seconds]
<mripard_> you can't get your mailbox clocks from the linux driver, this is a chicken and egg issue
<mripard_> and I'd expect that SCPI somewhat expects that the channel would always be open
<smaeul> I don't expect (for now, at least) to use SCPI for any clocks other than PLL-CPUX, but that's something to keep in mind
junnie has joined #linux-sunxi
<wens> you can't really use it _just_ for a few clocks, can you?
<wens> the kernel's clock driver would be out of sync, or worse, try to disable clocks it thinks aren't in use
benettig has quit [Read error: Connection reset by peer]
<mripard_> yeah, the caching in the clock framework is going to get completely mad
<mripard_> so it really is an all or nothing
<smaeul> there are two SCPI clock drivers, scpi-dvfs-clocks and scpi-variable-clocks
<smaeul> so you can use DVFS for the CPU without using the clock framework drivers
<anarsoul> mripard_: hey, have you seen my message about broken vblank on 4.15?
<mripard_> anarsoul: hey, have you seen my message about a patch that could fix the broken vblank on 4.15? ;)
<anarsoul> nope :(
cosm has quit [Ping timeout: 250 seconds]
<plaes> mripard_: I can test this tonight...
cosm has joined #linux-sunxi
<mripard_> smaeul: the CPU clock is still defined in the clock framework
<mripard_> and there's still caching involved
<anarsoul> mripard_: how does it fix the race with interrupt handler?
<mripard_> hmmm
<mripard_> I might not have seen a message about a race :)
<mripard_> which race are you talking about ?
<anarsoul> mripard_: vblank irq handler calls drm_crtc_handle_vblank() that re-enables vblank
<wens> iirc irq handler blocks the same interrupt from happening
<mripard_> drm_crtc_handle_vblank might disable it yes
<mripard_> but I don't see how it can enable it
<smaeul> mripard_: in dts there is e.g. `&cpu0 { clocks = <&ccu CLK_CPUX>; };`, which would be replaced with e.g. `&cpu0 { clocks = <&scpi_dvfs 0>; };`. If nothing else uses `<&ccu CLK_CPUX>`, why would the cached value matter
<smaeul> ?
<mripard_> because the clock driver is still registered
<mripard_> you just removed the consumer
<mripard_> but the driver is still there
<anarsoul> let me double check
msimpson has joined #linux-sunxi
<anarsoul> mripard_: it throws another warning with your patch, see https://gist.github.com/anonymous/4866cebce79bba5473c7176c47fb7106#file-dmesg-txt-L7374 and L7446
JohnDoe_71Rus has quit [Read error: Connection reset by peer]
JohnDoe_71Rus has joined #linux-sunxi
aalm has joined #linux-sunxi
<ElBarto> someone gave me a link to a more recent ATF than apritzel's one but I can't remember who ...
<ElBarto> ah https://github.com/smaeul/arm-trusted-firmware, that seems to be the one
apritzel has joined #linux-sunxi
<wens> ElBarto: smaeul ?
<smaeul> ?
<ElBarto> wens: yeah
<ElBarto> smaeul: was looking for the latest atf
<smaeul> that's the one
<smaeul> still a bit wip though
<ElBarto> I'm still using the one from apritzel
<ElBarto> from july or something like that
yann has joined #linux-sunxi
<apritzel> ElBarto: please update to have my fixes from October, at least
matthias_bgg has joined #linux-sunxi
<apritzel> ElBarto: or wait until next week when I start upstreaming something based on smaeul's work
<apritzel> it's working already, but needs some more cleanup in the PMIC driver
netlynx has joined #linux-sunxi
qwdqw has joined #linux-sunxi
<apritzel> ElBarto: or you could even use the SCPI branch, which gives you DVFS via SCPI
qwdqw has quit [Client Quit]
RawWalk13 has joined #linux-sunxi
<RawWalk13> hi all
RawWalk13 has quit [Client Quit]
<pgreco> wens, sorry for the delay, I was sleeping (GMT-3)
<apritzel> smaeul: ah, great! thanks
<pgreco> I am using Fedora rawhide
<pgreco> these are axp reated settings in config https://paste.fedoraproject.org/paste/OssoORefpEVqFns6MhEeSw
<wens> yeah, known issue with RSB client modules not auto-loading
popolon has joined #linux-sunxi
<wens> try having axp20x-rsb load automatically by the initrd
<ElBarto> apritzel: oh cool, I'll do some test and update the freebsd packages soon then
Pe3ucTop has joined #linux-sunxi
<apritzel> ElBarto: cpu hotplug was completely broken in the older version, but works now (survived a test with multiple 1000s onlines/offlines)
<apritzel> ElBarto: does FreeBSD support CPU hotplug?
<ElBarto> nope :)
<apritzel> so you never call PSCI's CPU_OFF?
<ElBarto> maybe at shutdown ? I don't know
<ElBarto> not really familiar with our PSCI code
kleinjl has joined #linux-sunxi
kleinjl has quit [Remote host closed the connection]
<apritzel> smaeul: I needed to add RESET_TO_BL31 (and fill the gaps) to get a working bl31.bin, did you load ATF somehow differently?
<smaeul> no, just like always
<smaeul> the only changes I have that aren't pushed are moving the load address to 0x46000 from 0x44000 (to make space for ARISC fw) and the orangepi-pc2-specific poweroff sequence
hardfalcon has quit [Ping timeout: 265 seconds]
<smaeul> apritzel: what happened without RESET_TO_BL31?
<apritzel> I got an data abort
<apritzel> because the whole handover from BL2 was not working
<smaeul> ohhhh
hardfalcon has joined #linux-sunxi
<smaeul> I use u-boot SPL's ATF support
<smaeul> so I don't have to hardcode those values
chlorine has joined #linux-sunxi
<apritzel> I see
<apritzel> haven't looked in detail into this, so to ATF the SPL then looks like a BL2?
<smaeul> maybe? it just fills in the structs, before jumping to the address (hardcoded) in the u-boot .config: https://github.com/u-boot/u-boot/blob/master/common/spl/spl_atf.c
kleinjl has joined #linux-sunxi
<smaeul> oh, heh, it just got updated, maybe it does more now
chlorine has quit [Ping timeout: 255 seconds]
<apritzel> smaeul: but you still rely on a certain fixed load address in ATF, right?
<smaeul> apritzel: now it looks like it automatically finds ATF in the FIT image, and passes it the device tree
junnie has quit [Ping timeout: 264 seconds]
<smaeul> apritzel: yes, the address hardcoded as BL31_BASE had to be hardcoded in u-boot .config
<smaeul> but hopefully not anymore with these new changes (https://github.com/u-boot/u-boot/commit/1d3790905d9c089b434c376f2dcc585b6a92bc99)
<smaeul> I haven't tried them yet
kleinjl has quit [Ping timeout: 260 seconds]
kleinjl has joined #linux-sunxi
lurchi_ has quit [Ping timeout: 272 seconds]
fkluknav has joined #linux-sunxi
hardfalcon has quit [Ping timeout: 272 seconds]
<kleinjl> hi, is the csi camera driver open source?
<kleinjl> or have blobs
hardfalcon has joined #linux-sunxi
fkluknav has quit [Ping timeout: 264 seconds]
<mripard_> kleinjl: it depends
<mripard_> kleinjl: do you refer to csi as MIPI CSI, or Allwinner's CSI
<mripard_> Allwinner's CSI being the camera capture controller, that might or might not support MIPI CSI, depending on the SoC
kleinjl has quit [Ping timeout: 260 seconds]
<mripard_> (yeah, I know, it's confusing)
<mripard_> too confusing apparently
<apritzel> icenowy[m]: thanks for the AXP805 manual!
<KotCzarny> quick question, does DT support decimal args in <> ?
<KotCzarny> ie <1200000000> instead of <0x47868c00>
<apritzel> icenowy[m]: do you know to which rail the CPU is connected?
<apritzel> KotCzarny: sure it does
<KotCzarny> thanks
<apritzel> KotCzarny: it's just that if you convert back from .dtb to .dts, you end up with hex everywhere
<apritzel> KotCzarny: clock frequencies are usually expressed in decimal in the mainline DTs
<fossxplorer> icenowy[m], how is your H6 board coming along?
netlynx has quit [Ping timeout: 263 seconds]
<KotCzarny> hmm, when boot0 starts it detects soc/board params or has them embedded?
<KotCzarny> got some funny output on my opipc:
<KotCzarny> [648]DRAM CLK = 744 MHz---DRAM zq value: 003b3bfb
<KotCzarny> [643]DRAM Type = 3 (2:DDR2,3:DDR3,6:LPDDR2,7:LPDDR3)
<apritzel> KotCzarny: the code is more or less generic, but there is a hardcoded data structure with those values
<apritzel> KotCzarny: so you can change them without touching the actual code
<KotCzarny> still, that 744 doesnt match any known board
<apritzel> KotCzarny: why are you using boot0 in the first place?
<apritzel> and where did you get the boot0 from?
<KotCzarny> playing with some image before i rape it with mainline uboot
<KotCzarny> and that 744mhz for dram caught my eye
<apritzel> my understanding is that the board vendor is meant to customize the boot0 they ship
<apritzel> by adjusting those values to match the DRAM chips used on their board
<apritzel> KotCzarny: if you look at the beginning of a boot0 hexdump you should be able to spot the ZQ value, also the frequency (IIRC it's in MHz)
<KotCzarny> still, it managed to get as far as detecting mmc
Hao has quit [Ping timeout: 264 seconds]
<apritzel> KotCzarny: please don't start that old DRAM frequency discussion again ;-)
<KotCzarny> :)
<KotCzarny> 0x eb 02 00 00, yeah, it's hardcoded there
Ntemis has joined #linux-sunxi
tom_nov has joined #linux-sunxi
anarsoul has quit [Ping timeout: 248 seconds]
hor has joined #linux-sunxi
anarsoul has joined #linux-sunxi
nuuuciano has joined #linux-sunxi
mzki has quit [Ping timeout: 260 seconds]
lkcl has joined #linux-sunxi
mzki has joined #linux-sunxi
banshi has joined #linux-sunxi
rwmjones is now known as rwmjones|holiday
voxadam has quit [Quit: WeeChat 1.9.1]
libv_ has joined #linux-sunxi
<apritzel> ElBarto: sys/dev/psci/psci.c: TODO:- Add support for remaining PSCI calls [this implementation only supports get_version, system_reset and cpu_on].
libv has quit [Ping timeout: 260 seconds]
DullTube has quit [Quit: Leaving]
JohnDoe_71Rus has quit [Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org]
netlynx has joined #linux-sunxi
netlynx has quit [Changing host]
netlynx has joined #linux-sunxi
voxadam has joined #linux-sunxi
<ElBarto> apritzel: right, I knew it wasn't finished, maybe I'll take some time to finish it one day
nuuuciano has quit [Ping timeout: 248 seconds]
<apritzel> ElBarto: btw, do you booting FreeBSD using EFI?
<ElBarto> it's required for arm64
<ElBarto> I'm trying to push it for arm32
<ElBarto> with latest u-boot + 2 patches queue it work out of the box now
<ElBarto> queued*
<apritzel> ah, nice!
<ElBarto> and with edk2 based implementation it also works
yann has quit [Ping timeout: 272 seconds]
<apritzel> you would hope so ;-)
<ElBarto> no
<ElBarto> on my overdrive 1000
<ElBarto> we haven't found the bugs at least :P
<apritzel> or do you mean some EDK2 for sunxi?
<ElBarto> or on thunderx
<ElBarto> did someone made a EDK2 based bootloader for sunxi ?
afaerber has quit [Quit: Leaving]
nuuuciano has joined #linux-sunxi
<apritzel> I dimly remember there was some work for some dodgy Windows support, but am not sure if it actually was EDK2 based
<ElBarto> ah right, the windows IoT on pine64 or something like that ?
<apritzel> yes
<apritzel> I briefly looked at it and decided to quickly forget about it ;-)
<ElBarto> eheh
<apritzel> ElBarto: something like this: https://github.com/Leeway213/WinIoTBoot
fkluknav has joined #linux-sunxi
junnie has joined #linux-sunxi
yann has joined #linux-sunxi
<apritzel> ElBarto: where can I find the two EFI U-Boot patches you mentioned before?
<ElBarto> apritzel: is there anything worth being stealed from that ?
afaerber has joined #linux-sunxi
<ElBarto> the second one should have a patchwork entry now I guess
<apritzel> ElBarto: no idea, having an EDK2 port sounds like a good thing, but I don't want to open up another building site
<ElBarto> was thinking of the atf part
<apritzel> ElBarto: is there any difference to that other AW port? It seems to be based on v1.0 as well...
* apritzel is getting sick from all those "initial commit" plus a handful of huge patches crap
<ElBarto> apritzel: no idea, haven't looked at the code
<apritzel> it would only be interesting if they would have an MMC driver (easy) and DRAM init in ATF
<apritzel> but it doesn't look like it, I guess they use boot0
my123_ has quit [Ping timeout: 260 seconds]
my123 has joined #linux-sunxi
my123 has quit [Changing host]
my123 has joined #linux-sunxi
fdcx has quit [Remote host closed the connection]
fdcx has joined #linux-sunxi
cnxsoft has quit [Quit: cnxsoft]
xes__ has joined #linux-sunxi
xes_ has quit [Ping timeout: 240 seconds]
hor has quit [Ping timeout: 260 seconds]
banshi has quit [Quit: Leaving]
reinforce has quit [Quit: Leaving.]
chomwitt has quit [Ping timeout: 240 seconds]
<icenowy[m]> I have checked this EDK2
<icenowy[m]> meaningless
<icenowy[m]> blobful
<icenowy[m]> 32-bit only
<icenowy[m]> and they used boot0
<apritzel> icenowy[m]: ah, right, that was the main issue: it was 32-bit only!
<icenowy[m]> it's a boot0 and it loads atf, scp and uefi
<icenowy[m]> yes it's still the similar taste ;-)
<icenowy[m]> apritzel: have you received the axp805 datasheet?
<apritzel> icenowy[m]: yeah, I saw your Wiki entry, many thanks for that!
<icenowy[m]> in fact it's made several days ago
<icenowy[m]> but I forgot it, and TL seems to also forgot
<apritzel> icenowy[m]: do you know to which rail the CPU is connected to?
<icenowy[m]> dcdca+dcdcb
<icenowy[m]> seems to be polyphase like AXP803
Andy-D_ has joined #linux-sunxi
<apritzel> thanks, but only two phases, right?
<apritzel> since the AXP805 also support triphase (A+B+C)
<icenowy[m]> 2
<icenowy[m]> c's gpu
<icenowy[m]> d's sys
<icenowy[m]> e's ddr
<apritzel> icenowy[m]: cool, thanks, DDR was my next question ;-)
Gerwin_J has quit [Quit: Gerwin_J]
Putti has joined #linux-sunxi
junnie has quit [Ping timeout: 260 seconds]
SP7RT has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
sr-digitronic has quit [Remote host closed the connection]
Putti has quit [Ping timeout: 265 seconds]
reinforce has joined #linux-sunxi
LargePrime has joined #linux-sunxi
msimpson has quit [Read error: Connection reset by peer]
yann has quit [Ping timeout: 264 seconds]
Putti has joined #linux-sunxi
dave0x6d has joined #linux-sunxi
foxx_ has quit [Ping timeout: 264 seconds]
yann has joined #linux-sunxi
victhor has quit [Remote host closed the connection]
ernestask has quit [Quit: ernestask]
matthias_bgg has quit [Ping timeout: 248 seconds]
Andy-D__ has joined #linux-sunxi
Andy-D_ has quit [Ping timeout: 256 seconds]
clemens3 has joined #linux-sunxi
apritzel has quit [Read error: Connection reset by peer]
apritzel has joined #linux-sunxi
tllim has joined #linux-sunxi
netlynx has quit [Quit: Ex-Chat]
apritzel has quit [Read error: Connection reset by peer]
jstein_ has joined #linux-sunxi
jstein_ is now known as jstein
<icenowy[m]> IgorPec: how is xr819 performing on nanopi duo?
<IgorPec> little over 10Mbit on close proximity, but haven't tested recent changes if anyathing better
<icenowy[m]> is it stable?
<IgorPec> well, hard to tell. haven't done hardcore tests but sometimes it doesn' see all stations
<IgorPec> and it refuse to reconnect for this reason
<icenowy[m]> oh I saw it on opi0
<IgorPec> this problem is here since i remember
<icenowy[m]> P.S. is there the situation that the station used cannot be seen?
foxx_ has joined #linux-sunxi
<icenowy[m]> all other stations are still there
<IgorPec> mmm, i am affraid yes
<icenowy[m]> so it's still bad driver quality
<IgorPec> sometimes it can't see my primary AP 50cm away
chrisf_ has joined #linux-sunxi
<IgorPec> yes. its bordeline usable
chrisf_ has quit [Read error: Connection reset by peer]
<IgorPec> i am still not sure shell we keep it in the kernel or not
<icenowy[m]> xr819 is the worst wifi chip I have ever seen
<icenowy[m]> why don't they use esp8089
<IgorPec> heh, don't tell me this :) i have more gray hair because of it
<IgorPec> well at least Friendlyarm ditched it on other boards
<IgorPec> i have Neo2+ with it
<icenowy[m]> ?!
<icenowy[m]> ohhhhhhhh my gooooooooood
<IgorPec> yes, it's some preproducion sample
<icenowy[m]> but this kind of COB chip is usuallly decided when doing initial design
apritzel has joined #linux-sunxi
<IgorPec> well, i guess they realized it was mistake and redesign a board. dunno. will ask them once
yann has quit [Ping timeout: 248 seconds]
<icenowy[m]> P.S. how to add a board to armbian?
<icenowy[m]> libre computer sent me their ALL-H3-CC Tritium board, one H3 ver and one H5 ver
<IgorPec> legacy or mainline kernel or both?
<IgorPec> in any case, first config, than FEX, DTS are added with a patch
vagrantc has joined #linux-sunxi
<icenowy[m]> legacy
<icenowy[m]> mainline is not yet ready now
<IgorPec> and fex with the same name here https://github.com/armbian/build/tree/master/config/fex
<IgorPec> that's all
<icenowy[m]> ok
<icenowy[m]> oh a bit offtopic
<KotCzarny> hmm, i wonder if that xr819 is fixable with proper driver/fw
<jernej> icenowy[m]: any word on DRAM code for H6?
<icenowy[m]> still no
<icenowy[m]> KotCzarny: I think it should be, as it should be design from ST-E
<jernej> I received explanation how to use PLL pattern registers
<jernej> which allows to set any clock rate imaginable
<KotCzarny> jernej: 800mhz?
<KotCzarny> :)
<jernej> well, maybe I use wrong word
<jernej> It allows to set fraction part to N multiplication factor
<jernej> that mode is used for audio PLL
<jernej> for example
<jernej> to reach exact clock rates, otherwise audio is too quick or slow
<jernej> it may be useful for video clocks too, for some exotic resolution
<jernej> I'm not sure how to properly describe register
<KotCzarny> so it's (0..maxclk] ?
<jernej> maybe just copy/paste e-mail and form it later
<jernej> it still has to be within PLL range described in datasheet, yes
<icenowy[m]> exotic ;-)
afaerber has quit [Quit: Leaving]
<icenowy[m]> I think usual display hardware can all bear a frequency range
Keziolio has quit [Ping timeout: 248 seconds]
<jernej> that's true
<icenowy[m]> so rounding is not so critical
<jernej> I saw that this register is used for DRAM initialization too in some cases
<jernej> I guess it's nice to have explanation
<KotCzarny> but since it can already be set in 24mhz steps
<jernej> and anyone can implement it later if needed
<KotCzarny> is there any use?
<icenowy[m]> wink says that it can also be used to prevent EMI
<jernej> as I said, audio PLL needs it
<jernej> others, not so much, or at least rarely
<icenowy[m]> so maybe it can prevent some DDR signal glitches?
<icenowy[m]> (just my guess
<icenowy[m]> (I said this to wink but he says &quot;the EMI prevention is usually used for testing&quot;
<jernej> I don't know much about DDR, so, maybe
<jernej> I hate magic numbers, so I had to ask
apritzel has quit [Ping timeout: 256 seconds]
Andy-D__ has quit [Quit: Alive/Dead]
tom_nov has quit [Quit: Leaving]
Putti has quit [Ping timeout: 260 seconds]
hardfalcon has quit [Quit: Leaving.]
Keziolio has joined #linux-sunxi
Keziolio has quit [Changing host]
Keziolio has joined #linux-sunxi
kaspter has quit [Read error: Connection reset by peer]
kaspter has joined #linux-sunxi
afaerber has joined #linux-sunxi
yann has joined #linux-sunxi
<jernej> If anyone wants to play with PLL pattern register, here is quick description with two examples: https://linux-sunxi.org/User:Jernej/PLL_Pattern_Control_Register
<jernej> I hope it is good enough
<icenowy[m]> P.S. just now I have a thought at #h3droid
<icenowy[m]> mesa-lima-memtester
hardfalcon has joined #linux-sunxi
hardfalcon has quit [Client Quit]
vagrantc has quit [Quit: leaving]
xes has joined #linux-sunxi
xes__ has quit [Ping timeout: 272 seconds]
<jernej> and it would work even for mali450 (H5)
IgorPec has quit [Ping timeout: 272 seconds]
vagrantc has joined #linux-sunxi
<icenowy[m]> yes it's my point.
xes has quit [Ping timeout: 248 seconds]
<anarsoul> hm, something's wrong with sun4i_dclk_round_rate()
<anarsoul> it gets parent rate wrong on 2nd time
<anarsoul> so pinebook LCD doesn't work after 2nd modetest (i.e. after exit from kmscube)
<anarsoul> if I hardcode parent_rate to 650666666 it works fine
* vagrantc hasn't been able to get LCD or USB working on pinebook
<anarsoul> and /sys/kernel/debug/clk/tcon0/clk_rate differs from /sys/kernel/debug/clk/pll-video0-2x
<anarsoul> vagrantc: works for me, both LCD and USB
<anarsoul> (right one)
aalm has quit [Ping timeout: 240 seconds]
<anarsoul> icenowy[m]: any idea what could be wrong? IIRC you added A64 DE2 CCU support
<vagrantc> anarsoul: with a 4.x kernel?
<anarsoul> vagrantc: yes, 4.15-rc2
<anarsoul> and sound :P
<vagrantc> modular or as built-ins?
<icenowy[m]> jernej: but we still won't have tamil-memtester ;-)
<icenowy[m]> I think finally another way to stress DRAM should be found
<vagrantc> anarsoul: just with arm64 defconfig?
<anarsoul> vagrantc: well, I'm using archlinux config with several modifications
<jernej> icenowy[m]: I hope something useful will show up here: https://notabug.org/cafe/chai
<vagrantc> anarsoul: hmmm... i should try this.
Pe3ucTop has quit [Ping timeout: 255 seconds]
gnufan has joined #linux-sunxi
Mr__Anderson has joined #linux-sunxi
matthias_bgg has joined #linux-sunxi
xes has joined #linux-sunxi
fossxplorer has left #linux-sunxi ["Leaving"]
kaspter has quit [Read error: Connection reset by peer]
kaspter has joined #linux-sunxi
Ntemis has quit [Remote host closed the connection]
<anarsoul> icenowy[m]: how does driver selects parent for a64 tcon0 clock?
JohnDoe_71Rus has quit [Quit: KVIrc 4.9.2 Aria http://www.kvirc.net/]
<anarsoul> icenowy[m]: looks like it doesn't work for me if tcon0 parent is pll-video-2x, but it works fine if it's pll-mipi
<anarsoul> wens: ^^
<mripard_> it picks the parent that can give the closest rate
Putti has joined #linux-sunxi
<anarsoul> yeah, but how does it select which clock is parent? I.e. sets some bit in some register, etc?
<mripard_> yes
<mripard_> in the clock control unit most of the time
<anarsoul> mripard_: is it documented?
* anarsoul is checking a64 user manual...
<anarsoul> hm, I don't see pll-video0-2x in clock tree for A64
chlorine has joined #linux-sunxi
foxx_ has quit [Ping timeout: 248 seconds]
chlorine has quit [Ping timeout: 264 seconds]
chlorine has joined #linux-sunxi
<mripard_> it is
<mripard_> register 0x10
reinforce has quit [Quit: Leaving.]
chlorine has quit [Ping timeout: 265 seconds]
Ntemis has joined #linux-sunxi
aalm has joined #linux-sunxi
<anarsoul> mripard_: any idea how to debug why pll-video-2x doesn't work as a parent on a64?
<anarsoul> I checked driver code, and all definitions seem to be correct
voxadam has quit [Ping timeout: 272 seconds]
<mripard_> I usually try to figure out the rates generated both in the working case and non working case
<mripard_> by hand
voxadam has joined #linux-sunxi
<anarsoul> mripard_: well, it attempts to set correct rate according to my traces
<anarsoul> anarsoul: but it doesn't work, panel can't sync
hardfalcon has joined #linux-sunxi
victhor has joined #linux-sunxi
tl_lim has joined #linux-sunxi
Ntemis has quit [Remote host closed the connection]
dev1990 has joined #linux-sunxi
tllim has quit [Ping timeout: 265 seconds]
gnufan has quit [Quit: Leaving.]
Pe3ucTop has joined #linux-sunxi
Putti has quit [Ping timeout: 240 seconds]
igraltist has quit [Remote host closed the connection]
igraltist has joined #linux-sunxi
matthias_bgg has quit [Ping timeout: 265 seconds]
hardfalcon has quit [Ping timeout: 240 seconds]
Pe3ucTop has quit [Ping timeout: 272 seconds]
<Net147> anarsoul: I use the following to check requested rates - https://patchwork.kernel.org/patch/9638785/
hardfalcon has joined #linux-sunxi
<anarsoul> Net147: thanks
Putti has joined #linux-sunxi
chlorine has joined #linux-sunxi
Putti has quit [Client Quit]
chlorine has quit [Ping timeout: 248 seconds]
argulp has quit [Ping timeout: 272 seconds]
fkluknav has quit [Ping timeout: 256 seconds]
kilobyte has quit [Ping timeout: 246 seconds]
kilobyte has joined #linux-sunxi
GrimKriegor has quit [Quit: oh bai bai bai]