rellla changed the topic of #linux-sunxi to: Allwinner/sunxi /development discussion - did you try looking at our wiki? - Don't ask to ask. Just ask and wait! - - Logs at - *only registered users can talk*
<apritzel> I mean the PMICs of choice (AXP806,805,305) don't even have battery support
<apritzel> I mean AW seems to become more consequent in their peripheral choice: no more Ethernet & HDMI in Axx SoCs (A63), no panel and camera support in H class (H616)
<smaeul> apritzel: the purpose of two DRAM PLLs is so you only modify the factors of the inactive PLL, then swap once it locks
<smaeul> which is explicitly supported now for CPUX as well, with a PLL_PERIPH0 bypass of PLL_CPUX
<apritzel> smaeul: but isn't PLL_CPUX supposed to be able to switch frequency without glitches, and without switching?
<apritzel> or does that not really work reliably?
<smaeul> apritzel: it doesn't work reliably, which is why we have a rate notifier that reparents to OSC24M
<apritzel> right, I was scratching my head about that I found that somewhere in the code
<smaeul> and in the newest (H616 I believe) manual, PLL_CPUX is actually described as DVFS = NO in the PLL table
<apritzel> but AW seemed to go to great lengths in the manual to claim that the PLL_CPUX (and only that one) could do "live" changes?
<smaeul> they used to, yes
<apritzel> so they messed up, have some glitches now and then, and gave up?
<smaeul> sure, something like that
<smaeul> not that bypassing the PLL during rate changes really breaks anything
<apritzel> smaeul: so PERIPH0(1x) can now drive the cores?
<apritzel> which is typically at 600 MHz?
<smaeul> apritzel: yes, read Frequency Adjustment of PLL_CPUX in H616 manual
<smaeul> (1) Before you configure PLL_CPU, switch the clock source of CPU to PLL_PERI0(1X)
popolon has quit [Quit: WeeChat 3.0]
<apritzel> smaeul: ah, thanks for the pointer, I was already rummaging around in that area
<apritzel> and that explicitly mentions the DRAM switch there, thanks
<apritzel> smaeul: do you use frequency scaling for DRAM in crust yet, or do you have any plans for that?
<smaeul> apritzel: not currently, I only touch the DRAM PLL when I turn it off during suspend
<smaeul> but that is something that I want to do eventually
<smaeul> doing it in crust has the nice property that I can temporarily stop the world to reprogram the DRAM controller
<smaeul> and if we ever want to turn off VDD_SYS, either ATF or crust needs to be able to program the DRAM controller from scratch anyway
<apritzel> ah, so you turn the PLL off, but need to keep it powered up, to not lose the DRAM controller setup?
<smaeul> I can reset the AHB/AXI/MBUS domain, but I can't reset the APB domain. all of those are powered by VDD_SYS, which can't be turned off in suspend for a multitude of reasons
<smaeul> (APB domain == MCTL registers)
<apritzel> with "suspend" you mean suspend-to-RAM or suspend-to-disk?
<smaeul> suspend to ram
<smaeul> for suspend to disk (== poweroff), I can kill DRAM entirely, since that is followed by normal boot
<apritzel> but then you need to DRAM controller to stay alive to perform the refresh? Or do the chips do that autonomously in some self-refresh state?
<smaeul> correct, the chips are in self-refresh, and the DRAM pads are all tristated
<apritzel> ah, I see
<apritzel> was confused how you could tinker with the DRAM controller when you care about the content ...
<smaeul> very carefully
<apritzel> can imagine ...
<apritzel> sounds like open heart surgery
apritzel has quit [Ping timeout: 246 seconds]
ChriChri_ has joined #linux-sunxi
ChriChri has quit [Ping timeout: 260 seconds]
ChriChri_ is now known as ChriChri
Net147 has joined #linux-sunxi
Net147 has quit [Read error: Connection reset by peer]
Net147 has joined #linux-sunxi
Net147 has quit [Read error: Connection reset by peer]
Net147 has joined #linux-sunxi
netlynx has quit [Quit: Ex-Chat]
victhor has quit [Ping timeout: 265 seconds]
vagrantc has quit [Ping timeout: 272 seconds]
night199uk has quit [Quit: ZNC 1.6.6+deb1ubuntu0.2 -]
sunshavi has quit [Read error: Connection reset by peer]
night199uk has joined #linux-sunxi
gaston1980 has quit [Quit: Konversation terminated!]
night199uk has quit [Quit: ZNC 1.6.6+deb1ubuntu0.2 -]
lurchi_ has joined #linux-sunxi
sunshavi has joined #linux-sunxi
lurchi__ has quit [Ping timeout: 272 seconds]
JohnDoe_71Rus has joined #linux-sunxi
lurchi_ is now known as lurchi__
JohnDoe_71Rus has quit [Quit: KVIrc 5.0.1 Aria]
night199uk has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
vagrantc has joined #linux-sunxi
hlauer has joined #linux-sunxi
apritzel has joined #linux-sunxi
apritzel has quit [Ping timeout: 256 seconds]
asdf28 has joined #linux-sunxi
chewitt has quit [Read error: Connection reset by peer]
chewitt_ has joined #linux-sunxi
chewitt_ is now known as chewitt
cmeerw has joined #linux-sunxi
AneoX has joined #linux-sunxi
<jernej> apritzel: there is no harm in making H6 SPL 48 KiB in size too, right?
<jernej> eh, scratch that, I'll leave it as it is
vagrantc has quit [Quit: leaving]
lurchi__ is now known as lurchi_
freemangordon has quit [Remote host closed the connection]
freemangordon has joined #linux-sunxi
<clementp[m]> apritzel: h616 doesn't enable / disable the clock but enable / disable the output. The video0 clk is different also
<clementp[m]> But I agree it's 90% similar
<clementp[m]> Did you compare the AW implementation between 50iw6 and 50iw9 ? Or did you read the datasheet ?
apritzel has joined #linux-sunxi
netlynx has joined #linux-sunxi
victhor has joined #linux-sunxi
fl__0 has joined #linux-sunxi
<apritzel> clementp[m]: many thanks for your input
fl_0 has quit [Ping timeout: 260 seconds]
random_yanek has quit [Ping timeout: 260 seconds]
<apritzel> jernej: yes, just not heavily tested
<jernej> ok, if you don't mind I'll pick it and add your SoB
random_yanek has joined #linux-sunxi
<apritzel> jernej: yes, thanks!
<apritzel> clementp[m]: so I compared the PLLs in the datasheet under the aspect of: can the H6 code drive them
<apritzel> clementp[m]: so do you think we need to make use of the output enable bit [27]?
<apritzel> clementp[m]: and thanks for the heads up with PLL_VIDEO0, so we need to tweak hdmi_parents and friends then as well, I guess
<jernej> apritzel: for sure - just check pll1 and pll5 changes in u-boot
<jernej> that was one of the initial issues I had
<apritzel> jernej: are they turned off? the manual says default is 1 (enabled)
<jernej> idk, SPL does normal write, not rmw, so I had to add it
<apritzel> ah, I see
freemangordon has quit [Ping timeout: 260 seconds]
jstein has joined #linux-sunxi
fl__0 is now known as fl_0
freemangordon has joined #linux-sunxi
<jernej> apritzel: Initial H616 U-Boot clean up:
<jernej> apritzel: but it doesn't boot from SD card for some reason
<jernej> apritzel: it would be appreciated if you can take a look, I have to go away from computer for some time
<jernej> oh, boot over FEL works fine
<apritzel> jernej: many many thanks for that!
<jernej> booting from SD stops after TF-A returns
<apritzel> I will have a look and try to fix the SD card boot
<jernej> or so it seems
<apritzel> jernej: did you change CONFIG_SPL_PAD_TO?
<jernej> apritzel: it would be nice to start reviewing Linux patches soon in order to have proper DT for U-Boot
<apritzel> jernej: yes, I will try to fix the video clocks and send something early next week
<jernej> ok, great
<jernej> afk
kaspter has joined #linux-sunxi
chewitt has quit [Read error: Connection reset by peer]
chewitt_ has joined #linux-sunxi
chewitt_ is now known as chewitt
asdf28 has quit [Ping timeout: 256 seconds]
jstein has quit [Ping timeout: 256 seconds]
lurchi_ is now known as lurchi__
cnxsoft1 has quit [Quit: cnxsoft1]
gaston1980 has joined #linux-sunxi
asdf28 has joined #linux-sunxi
kaspter has quit [Remote host closed the connection]
kaspter has joined #linux-sunxi
parabyte has joined #linux-sunxi
<parabyte> i have a horrible mxq pro 4k tv box. its motherboard has h3q44 v.20 printed on it
<parabyte> i cant get it to boot uboot via sdcard no matter how i try, it locks up just after initialising but i can get uboot to run via fel
<parabyte> what i was wondering is, does anyone know of any methods that i can use to extract its firmware?
<parabyte> i have access to toybox shell via uart
<parabyte> the uboot builds i been playing with are for another board and do not support the boards mmc
<DonkeyHotei> [TheBug]: ^
<parabyte> oh also toybox does not have root, i cant seem to figure out how to get root. i am logged in as shell user
<parabyte> my plan is to extract the firmware from the box somehow and reuse its kernel and uboot so i got a functional armbian based system or debian
jbrown has quit [Ping timeout: 272 seconds]
jbrown has joined #linux-sunxi
<buZz> wasnt there someone in here that worked on libreelec and said there was a version for Allwinner H3 ?
<buZz> i'm not seeing it on their website
<buZz> ah > Only nightly releases are available right now. Use at your own risks!
<buZz> bit hard to find , lol
<asdf28> :->
<jernej> buZz: it was me
<buZz> jernej: the 'test.libreelec' could be linked from the webpage ;)
<buZz> instead of scrolldownonthewikisomewhere :D
<jernej> and yes, first stable (as much as they can be) images will be released with LibreELEC 10
<buZz> :)
<buZz> i'll go try the 'nanopi m1' version in a bit, anyway
<jernej> on forum it's very clearly marked :)
<jernej> nightly images will never be promoted on first page...
<buZz> oh reddit?
<buZz> i was talking about the webpage anyway
<jernej> what reddit?
<buZz> thats a forum
<buZz> oh, there's 'forum' before wiki in the topbar
<buZz> i dont see test.libreelec linked from that
<buZz> ah you ment in the allwinner subpages of it?
<buZz> still, i consider that hidden
<buZz> i dont want to wade through piles of 'opinion threads' just to find where to download a image :P
<jernej> first of all, it's not burried, but it's in OP of pinned thread in proper subforum
<jernej> and idea is that people read text to know what to expect, because they are not stable
<jernej> yet
<jernej> once they will be stable, they will be, of course, referenced in download section
jstein has joined #linux-sunxi
asdf28 has quit [Ping timeout: 260 seconds]
<jernej> apritzel: I found the bug and updated my branch
iyzsong has quit [Quit: ZNC 1.7.5 -]
iyzsong has joined #linux-sunxi
Mangy_Dog has joined #linux-sunxi
<apritzel> jernej: nice, what was it?
<jernej> apritzel: I only partially ifdef'ed scp out, so U-Boot stopped when it was not found
AneoX has quit [Quit: Textual IRC Client:]
lurchi__ is now known as lurchi_
lurchi_ is now known as lurchi__
dev1990 has joined #linux-sunxi
lurchi__ is now known as lurchi_
asdf28 has joined #linux-sunxi
DrFrankensteinUK has quit [Read error: Connection reset by peer]
DrFrankensteinUK has joined #linux-sunxi
kaspter has quit [Quit: kaspter]
lurchi_ is now known as lurchi__
apritzel has quit [Ping timeout: 240 seconds]
_whitelogger has joined #linux-sunxi
lurchi__ is now known as lurchi_
JohnDoe_71Rus has quit [Quit: KVIrc 5.0.1 Aria]
shailangsa has quit [Ping timeout: 240 seconds]
gaston1980 has quit [Quit: Konversation terminated!]
apritzel has joined #linux-sunxi
pion3k has joined #linux-sunxi
pion3k has quit [Remote host closed the connection]
pion3k has joined #linux-sunxi
pion3k has quit [Remote host closed the connection]
<apritzel> jernej: did you try Ethernet on your TV box? Does this one use the internal PHY?
shailangsa has joined #linux-sunxi
<jernej> not yet, probably in following days, enough H616 for a day or two :)
<jernej> but yes, it uses internal phy
<jernej> interestingly, BSP DT references register 0x34 in syscon
pion3k has joined #linux-sunxi
<jernej> so I guess driver will need separate compatible string
<apritzel> jernej: I saw that as well and tried to ignore it ;-)
<jernej> well, if you think about it, syscon register can't be the same
<apritzel> the manual suggests that the internal PHY is hardwired on EMAC1, for EMAC0 you have to use an external PHY (RMII or RGMII)
<apritzel> so there is no switch anymore
<jernej> true, but you have to set LED polarity somehow
<apritzel> so we might need a new compatible string, but maybe only use the A64 as the fallback?
<apritzel> for EMAC0, that is
pion333 has joined #linux-sunxi
<jernej> and there are also delay settings, although I'm not sure how critical they are for fast ethernet
lurchi_ is now known as lurchi__
<jernej> yeah, for emac0, a64 fallback is good imo
<apritzel> so at 0x300b000 (GPIO PortA) I see 13 pins in the register (77777777 00077777)
<apritzel> that's more than the 9 for RMII, but less than the 18 in MII
<apritzel> jernej: you mentioned port A the other day, do you have any source for that? BSP?
<jernej> BSP, yes
<apritzel> ah, got it
<jernej> there is also another I2C3 there and last pin is PWM5
<jernej> that reminds me on H6 and co-packaged AC200
<jernej> however, I don't think H616 has it
pion3k has left #linux-sunxi [#linux-sunxi]
<apritzel> ... which was my next question ;-)
<jernej> although it would be interesting to enable that I2C and scan addresses
dev1990 has quit [Quit: Konversation terminated!]
luke-jr has quit [Quit: ZNC -]
<apritzel> there are also audio pins in PortA
luke-jr has joined #linux-sunxi
dev1990 has joined #linux-sunxi
<jernej> yeah, port A is a bit weird
<apritzel> jernej: how hard was it to get a UART on your TV box?
<jernej> simple, it is nicely marked
<apritzel> no pins to bridge or transistors to solder?
<jernej> I just soldered 3 pins on it
<jernej> I mean on header
<jernej> nope
<jernej> first box was also easy, header was already properly marked and worked first time already
pion333 has quit [Remote host closed the connection]
<apritzel> jernej: do you also have one of those T95 boxes? Or know if they are similar?
<jernej> yes, second one is T95 and it's pretty decent build quality
<jernej> easy to open - screws
<jernej> FEL button is behind analog audio port, but at this stage you won't need it
<jernej> one of the reasons for TV box was 4 GiB RAM
<apritzel> did you boot mainline on it? Does eMMC work without the shift-by-2 fix?
<apritzel> the manual suggests that this is only for MMC0 and MMC1
<jernej> not yet
<apritzel> which would make MMC2 compatible to the a64_emmc_cfg
pion3k has joined #linux-sunxi
<pion3k> Hi guys, I have a question concerning setting internal pull-up/down for PA10 gpio in BananaPi M2+ v1.2 (allwinner H3), kernel 5.4.69. I added new node to sun8i-h3-bananapi-m2-plus.dts, in the pinctrl@1c20800 node, with the following properties: pins = "PA10"; function = "gpio_in"; drive-strength = <0x1e>; bias-pull-down; I believe that there is something fundamental missing here since I observer floating values on the PA10 by usin
<pion3k> g libgpiod. How can I configure this internal pull-up/down prop?
<apritzel> pion3k: that's not how you typically configure GPIOs
ChanServ has quit [shutting down]
<apritzel> I think on 5.4 you can use the new ioctl based GPIO interface, which allow to configure pull-ups, IIRC
ChanServ has joined #linux-sunxi
lynxis has quit [Ping timeout: 260 seconds]
lynxis has joined #linux-sunxi
<apritzel> pion3k: dammit, pull up/down control seems to be a 5.5 feature ...
<pion3k> Hmm, what should be the proper way for 5.4 then? Is it possible to configure this through dts? I just want to achieve not-floating gpio input pin to test its value in the userspace
<apritzel> pion3k: yeah, looks like you need to configure the pull down this way in the DT in this case
<apritzel> but I am not sure if the pinctrl entry is used this way for GPIOs, because typically those pinctrl child nodes need to be referenced by some other DT node to be active
<jernej> apritzel: any luck with USB?
<apritzel> not yet
<jernej> in worst case, you can boot BSP image and dump register values
<pion3k> apritzel: This is what I concluded as well, but unfortunately I could not find any working example for that. For example for a similar description of pinctrl for mmc0-pins I can see that it has a property phandle=<0x08>, which in turn is referenced in the mmc@1c0f000 node by: pinctrl-0=<0x08>. Does it mean that I should add new node with some specific GPIO driver selected (through the compatible string)?
dddddd has quit [Quit: dddddd]
<apritzel> pion3k: that sounds like not the right way. So far personally I got away without pull-up/downs for my GPIOs, and just saw that it's now possible to configure from userland
<apritzel> pion3k: for MMC for instance, the MMC driver uses the in-kernel GPIO interface to configure the pin, which takes care of the pull-up/down settings
<apritzel> maybe some other people more familiar with GPIOs know the proper way?
dddddd has joined #linux-sunxi
<pion3k> If only I had known them :) Anyway, thanks for helping. I will ask more general question tomorrow, maybe there will be more people here.
merbanan has quit [Ping timeout: 256 seconds]
merbanan has joined #linux-sunxi
<apritzel> clementp[m]: you were right: on closer inspection there are many more subtle differences between H6 and H616, especially in the whole video area (which I only skimmed over before)
<apritzel> I still think it warrants a joint driver
<clementp[m]> Yes if it was only some slightly clock différences but the fact that H6 PLL enable / disable whereas H616 toggle the PLL output means that all PLLs will have different structures
pion3k has quit [Quit: Leaving.]
<clementp[m]> And H6 is sun50iw6, h616 sun50iw9, a100 sun50iw10. Maybe h616 and a100 are close than h6 and h616
<apritzel> ah, good point, the A100 clocks are in there already
<apritzel> clementp[m]: well, the enable it only additional, and default on, so for now it shouldn't hurt
<clementp[m]> Haha I think they are no logic to choose one or the other
<apritzel> clementp[m]: well, if the A100 is closer, I might need less additional clocks
<apritzel> and A100 is probably more again more a true tablet-only chip (like the A63), so it removes everything non-tablet-y, like Ethernet and HDMI
<apritzel> let met check that ccu file ...
<clementp[m]> Yes I agree I think h616 clocks are close to h6
<clementp[m]> Than a100
<apritzel> yeah, indeed no sign of GMACs or HDMI or TVout
<clementp[m]> Except for this output switch Vs enable disable.
<apritzel> indeed
<apritzel> I am not sure this the right way of modelling it
<clementp[m]> What do you mean ?
<apritzel> I mean we now just gate the PLL output if we turn it off, but it keeps running
<apritzel> wasting power
<apritzel> I think the reason we turn PLLs off is to save power, maybe even reduce electrical noise
<apritzel> AFAIK PLLs are nasty analogue circuitry
<clementp[m]> Ok
<apritzel> and also that means that we rely on all PLLs already being enabled, since we lose the possibility to turn them on?
<clementp[m]> It's done at CCU probe
<apritzel> ah, I see
<apritzel> I wonder if "Due to the current design..." means "has always caused trouble, we just decided to work around it with an extra gate"
<apritzel> clementp[m]: do you know of any available A100 documentation?
<clementp[m]> No never see one, Just code source and Yang Tao upstream
<clementp[m]> But I think you're right this a bit a hack we use the .enable to gate the output
<clementp[m]> I think we should add a .gate with this bit and add a flag to say USE_GATE_NOT_ENABLE
<apritzel> yeah, I was thinking about this as well
<clementp[m]> And i also agree is this due to new design or we just recently observed some trouble... so we fix it for new SoC
<apritzel> .gate and a flag sounds like a good idea!
<clementp[m]> I have some instability with GPU PLL when I enable GPU devfreq
<apritzel> not sure what causes trouble, exactly, maybe it's just switching off? So we could leave them off in probe, and turn them on *once* we need them (but never turn them off again)
<smaeul> the manual mentions that switching on/off one PLL could affect other PLLs
<apritzel> and only use the .gate from that point on
<smaeul> speaking of PLL bugs... the newest A64 ARISC blob has code to repeatedly power cycle the entire VCC-PLL power domain if it can't lock PLL_DDR1 during resume :/
<apritzel> smaeul: oh dear, some code should never be looked at ...
<apritzel> smaeul: do those reverse engineer tools support OpenRISC? Or do you work on pure objdumps?
<jernej> apritzel: megi wrote openrisc plugin for ghidra
<apritzel> solely for the ARISC, I guess? Because that horse is dead for quite a while, isn't it?
netlynx has quit [Quit: Ex-Chat]
<jernej> I'm not sure, there is official gcc port for it now
<smaeul> apritzel: it's the only use I have for it, but the spec and toolchain are still getting updates
<jernej> I worked with zigbee modules with openrisc core few years ago
<jernej> iirc
<apritzel> I guess the remaining OpenRISC usage is probably swept up by RiscV these days
<smaeul> using ghidra is several orders of magnitude faster than staring at objdumps
<smaeul> especially when dealing with large switch statements on a processor architecture that has delay slots :)
<apritzel> delay slot (noun): deceiving optimization opportunity, perfectly suited for introducing subtle bugs
<clementp[m]> smaeul: Hooo didn't know a bout this ghidra plugin. Maybe adding this to the wiki could be nice no ?
<apritzel> I spent two weeks of debugging back in uni because I didn't want to hear to my prof saying: "just put a NOP in there"
<smaeul> :)
<smaeul> clementp[m]: yes, I need to update that page some. though ideally I could get the processor plugin merged upstream as well
<bauen1> apritzel: because some instructions won't work properly unless the next instruction is a "nop" or how should that be understood ?
<smaeul> bauen1: the CPU executes the instruction after a branch before branching. you can pretend that doesn't happen by putting a nop after every branch
<apritzel> bauen1: because as a young lad you try to put some *previous* instruction in there, to not waste that slot
<bauen1> aren't the side effects of that _supposed_ to be invisible
<apritzel> bauen1: yeah, *theoretically* that should work, it's just mind-boggling and error prone
<bauen1> apritzel: so you were trying to "optimise" by putting the first instruction of a loop after the branch that goes back up to save a word of code ?
<apritzel> bauen1: something like that, yeah
<apritzel> for unconditional branches that works quite well, but for conditional ones you quickly get into trouble
<bauen1> tbh that sounds like a nice idea to fuck with the one correcting your homework
<smaeul> the reason why switch statements are fun is they usually get compiled to a binary search => chained conditional branches
<smaeul> on or1k a conditional branch takes 2 instructions: 1) set-flag-if-cond 2) branch-if-flag
<smaeul> so gcc puts the second set-flag-if-cond inside the first branch-if-flag's delay slot, and when you disassemble it, you just see branch-if-flag -> branch-if-flag -> branch-if-flag and you have to figure out where the instruction actually setting the flag is
<clementp[m]> apritzel: found some A100 docs
<clementp[m]> maybe gediz0x539 could you download them ?
<clementp[m]> Allwinner A100 B3 with AXP707
<apritzel> smaeul: lol, but indeed a compiler is the only sane "person" to be able to pull those things off
<apritzel> I wonder if this is a side effect of generic peephole delay-slot optimisation, or something put deliberately into the code generator for switch/case constructs
<smaeul> I don't believe it's switch/case-specific
<smaeul> one downside of ghidra is that sharing the databases is nontrivial - collaboration requires an application-specific server
<smaeul> though if anyone is interested, I'm happy to share what I have
<jernej> apritzel: I just checked PortA oddities
<jernej> this particular die is used in several packages
<jernej> and on some, port A seems to be connected to pins
<jernej> this can be deduced from comment in sun50iw9p1-pinctrl.dtsi
lynxis has quit [Read error: Connection reset by peer]
<apritzel> jernej: you mean that affects the functions *other* than gmac1? And gmac1 is there in every case, and we also need to switch to that function for the internal PHY to work?
lynxis has joined #linux-sunxi
kilobyte_ch has quit [Ping timeout: 260 seconds]
hlauer has quit [Ping timeout: 240 seconds]
jstein has quit [Quit: quit]
cmeerw has quit [Ping timeout: 244 seconds]