rellla 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 - *only registered users can talk*
elros1 has joined #linux-sunxi
Mangy_Dog has quit [Ping timeout: 264 seconds]
popolon has quit [Quit: WeeChat 3.0]
elros1 has quit [Remote host closed the connection]
Ntemis has quit [Read error: Connection reset by peer]
elros1 has joined #linux-sunxi
ChriChri_ has joined #linux-sunxi
ChriChri has quit [Ping timeout: 256 seconds]
ChriChri_ is now known as ChriChri
kaspter has joined #linux-sunxi
cnxsoft has joined #linux-sunxi
apritzel has quit [Ping timeout: 260 seconds]
lkcl has quit [Ping timeout: 240 seconds]
victhor has quit [Ping timeout: 240 seconds]
lkcl has joined #linux-sunxi
camus has joined #linux-sunxi
elros1 has quit [Quit: http://quassel-irc.org - Chat comfortably. Anywhere.]
kaspter has quit [Ping timeout: 240 seconds]
camus is now known as kaspter
<smaeul> my preferred solution is to not put BL31 in DRAM
luke-jr has quit [Quit: ZNC - http://znc.sourceforge.net]
luke-jr has joined #linux-sunxi
gaston1980 has quit [Quit: Konversation terminated!]
<smaeul> SRAM A2 is at the same location as H6, but back down to the size of A64/H5: reg = <0x0 0x00100000 0x0 0x14000>;
<wens> anyone verified address of SRAM C/C1 on H3 and later? the address currently used in mainline dts seems bogus
camus has joined #linux-sunxi
kaspter has quit [Read error: Connection reset by peer]
camus is now known as kaspter
tlwoerner has quit [Quit: Leaving]
<gediz539> some bot spammed wiki with gambling ads by creating Talk pages lol
JohnDoe_71Rus has joined #linux-sunxi
lurchi_ has joined #linux-sunxi
lurchi__ has quit [Ping timeout: 256 seconds]
<megi> smaeul: nice find
<megi> it's probably just a minor update
<megi> that looks like something very new :)
<megi> v5.2.1.7 -> v5.2.1.9 vs v5.2.1.7 -> v5.12.2-7
<megi> hopefully they cleaned up the power management :)
luke-jr has quit [Quit: ZNC - http://znc.sourceforge.net]
luke-jr has joined #linux-sunxi
kaspter has quit [Ping timeout: 240 seconds]
kaspter has joined #linux-sunxi
camus has joined #linux-sunxi
camus1 has joined #linux-sunxi
camus has quit [Client Quit]
kaspter has quit [Ping timeout: 240 seconds]
camus1 is now known as kaspter
lkcl has quit [Ping timeout: 240 seconds]
linkmauve has quit [Ping timeout: 260 seconds]
<jernej> smaeul: I just tested 0x00100000 and 0x00100100 via FEL and writel/readl operations and it always return 0
<jernej> so I would say there is no SRAM A2
lkcl has joined #linux-sunxi
camus has joined #linux-sunxi
kaspter has quit [Ping timeout: 256 seconds]
camus is now known as kaspter
apritzel has joined #linux-sunxi
hlauer has joined #linux-sunxi
apritzel has quit [Ping timeout: 265 seconds]
kaspter has quit [Ping timeout: 240 seconds]
tlwoerner has joined #linux-sunxi
kaspter 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]
asdf28 has joined #linux-sunxi
Net147 has joined #linux-sunxi
<bauen1> yog: not really, but if the 1 year lifetime figure is somewhat accurate that would probably be enough for my usecase
<asdf28> :->
<bauen1> jernej: if FEL is not in secure mode read / write to SRAM A2 will result in 0
AneoX has joined #linux-sunxi
cmeerw has joined #linux-sunxi
lurchi_ is now known as lurchi__
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
lurchi__ is now known as lurchi_
AneoX has quit [Ping timeout: 272 seconds]
AneoX has joined #linux-sunxi
ldevulder_ is now known as ldevulder
reinforce has joined #linux-sunxi
tnovotny has joined #linux-sunxi
yoq has joined #linux-sunxi
<yoq> jernej: also the first 0x4000 of SRAM A2 used to be sparse SRAM for a interrupt vector table. that layout may have changed if they use a different core for CPUS, better check past the first 16kiB
<yoq> the H616 datasheet has a single reference to SRAM A2 on page 46 in the system bus tree, fwiw
yoq has quit [Remote host closed the connection]
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
apritzel has joined #linux-sunxi
lurchi_ is now known as lurchi__
forkbomb has quit [Quit: In the beginning the Universe was created. This has made a lot of people very angry and been widely regarded as a bad move.]
forkbomb has joined #linux-sunxi
matthias_bgg has joined #linux-sunxi
cnxsoft has quit [Read error: Connection reset by peer]
MoeIcenowy has quit [Quit: ZNC 1.7.2+deb3 - https://znc.in]
MoeIcenowy has joined #linux-sunxi
cnxsoft has joined #linux-sunxi
matthias_bgg has quit [Quit: Leaving]
nashpa has quit [Ping timeout: 240 seconds]
victhor has joined #linux-sunxi
<apritzel> so this SRAM "A2" (or whatever) on the H616 is very weird: First I get nothing from U-Boot (non-secure EL2), which is somewhat good news (is it really secure this time?)
<apritzel> when I write something from TF-A (in EL3), I see some *patches* of SRAM functionality around that area
<bauen1> apritzel: iirc the SRAM "A2" is the (almost) the only thing correctly marked as secure
<bauen1> usually the SPC, SMC and some cpu configuration registers are marked as secure and the DMA is setup correctly
<bauen1> but the RTC (and possibly other) peripherals aren't necessarily set to secure even though they should be
<apritzel> bauen1: disregard your understanding of the term "usually" when it comes to Allwinner SoCs
<apritzel> bauen1: first: SRAM A2 is definitely *not* secure on the A64, H5, unless you burn the secure fuse
<apritzel> the same applies to all peripherals handled by the SPC, regardless of whether you switch them or they are fixed to secure
<apritzel> IIRC the H6 is the same in this regard
<apritzel> the SMC worked in my experiments a while back, though
<bauen1> apritzel: did you burn the secure fuse on your H616 ?
<apritzel> surely not!
<apritzel> it just complicates things, and is not what other people do
<apritzel> I tend to keep my boards in sync with the vast majority of users out there, so I can do actual testing
<bauen1> apritzel: yeah, that's what i was thinking, which is also why i'm a bit confused that "A2" wouldn't work from non-secure but (somewhat) work from secure
<apritzel> bauen1: again: this is AW, abandon all hope. There is little rhythm or rhyme to their designs
<apritzel> a lot of things tend to be similar to previous SoC, but then they change random things here and there
<bauen1> well, they do like to copy + paste for their technical manuals lo
<bauen1> *lol
<apritzel> the quality of the manuals is not good enough to rely on them
<apritzel> whenever I read something in there, I always try to verify it on the SoC
<apritzel> so the pattern I see on the H616 is: writes stick between 0xb0000-0xb1100, and 0xc0000-0xc1100, 0xd0000-0xd1100 and so on, and they are distinct (so not aliased)
<apritzel> later on it might get patchy, with bursts of 64 bytes RAZ/WI in the middle
<apritzel> which makes me think this might be some clock issue or general instability under certain conditions
<apritzel> we have seen that in the past, when the AHB1 clock for SRAM C was too fast, SRAM C couldn't be accessed reliably from the CPU
<apritzel> need to investigate further after nightfall, the clock setup by boot0 seems also dodgy (AHB1 at 4MHz?)
Mangy_Dog has joined #linux-sunxi
<hlauer> pgreco: sun7i-dwmac 1c50000.ethernet eth0: configuring for phy/rgmii link mode - seems to work with 100M too. No clue at the moment...
lucascastro has quit [Ping timeout: 256 seconds]
yann has quit [Read error: Connection reset by peer]
<pgreco> hlauer: is that with 5.10-rcX?
yann has joined #linux-sunxi
<hlauer> yes - wondering even why it's not phy/rgmii-id, as that should be in the dtb...
<hlauer> 5.10-rc5
<pgreco> maybe it works in 100 but fails at 1G, seems strange
<pgreco> do you remember what you had booted when it failed?
<apritzel> so on RGMII when the PHY negotiated 100Mbit/s, we use a 25MHz clock, not the 125 MHz one for 1GBit/s, right?
<apritzel> which means timing is much more relaxed on a 100Mbit/s link, so those delay might not matter?
<pgreco> no idea about the clocks, but something like that is what crossed my mind
<apritzel> can we force the link down to 100Mbit/s easily in Linux?
<pgreco> with ethtool
lucascastro has joined #linux-sunxi
<apritzel> right, that was it: ethtool speed 100
<pgreco> ethtool –s eth0 speed 100 duplex full autoneg off
<apritzel> might be interesting to see if that at least establishes network connectivity with a mismatching DTB, so people can upgrade their way out
matthias_bgg has joined #linux-sunxi
<pgreco> trying that here
<pgreco> apritzel: didn't work :(
<apritzel> bummer!
<apritzel> pgreco: thanks for trying
<pgreco> I tested using bananapi-m2b 5.9.2 , rgmii, setting ethtool -s eth0 speed 100 duplex full autoneg off
lucascastro has quit [Ping timeout: 265 seconds]
lucascastro has joined #linux-sunxi
<pgreco> apritzel: for a "way out" this might help fdtput -t s /boot/dtb-5.9.2-301.el7.armv7hl/sun8i-r40-bananapi-m2-ultra.dtb /soc/ethernet@1c50000 "phy-mode" "rgmii-id"
gaston1980 has joined #linux-sunxi
<apritzel> pgreco: yeah, if you find that ;-)
camus has joined #linux-sunxi
<pgreco> yeah, ethtool is easier
<pgreco> but this is easier than rebuilding a kernel :)
kaspter has quit [Ping timeout: 240 seconds]
camus is now known as kaspter
hramrach has joined #linux-sunxi
lucascastro has quit [Ping timeout: 260 seconds]
linkmauve has joined #linux-sunxi
<apritzel> pgreco: if a *user* needs to *rebuild* a kernel, something is wrong. I was thinking about "apt-get upgrade".
<pgreco> yeah, unfortunately, I think we're already there the latest 5.8.x was broken for a lot of devices, and 5.9.x is broken for less, but still broken
anarsoul has quit [Remote host closed the connection]
<JohnDoe_71Rus> do you hear about Allwinner R18 ?
<apritzel> JohnDoe_71Rus: from all we know it's just a relabelled A64, otherwise identical
nashpa has joined #linux-sunxi
<JohnDoe_71Rus> just read, it is used in yandex.station
<apritzel> it's used on the Pine64-LTS as well
JohnDoe_71Rus has quit [Quit: KVIrc 5.0.1 Aria http://www.kvirc.net/]
nashpa has quit [Ping timeout: 246 seconds]
anarsoul has joined #linux-sunxi
lucascastro has joined #linux-sunxi
nashpa has joined #linux-sunxi
matthias_bgg has quit [Ping timeout: 272 seconds]
sunshavi has quit [Read error: Connection reset by peer]
matthias_bgg has joined #linux-sunxi
victhor has quit [Quit: Leaving]
lurchi__ is now known as lurchi_
JohnDoe_71Rus has joined #linux-sunxi
netlynx has joined #linux-sunxi
netlynx has joined #linux-sunxi
lkcl has quit [Ping timeout: 256 seconds]
lurchi_ is now known as lurchi__
lkcl has joined #linux-sunxi
victhor has joined #linux-sunxi
lurchi__ is now known as lurchi_
lurchi_ is now known as lurchi__
hlauer has quit [Ping timeout: 256 seconds]
hlauer has joined #linux-sunxi
fl_0 has quit [Quit: STRG + Q]
fl_0 has joined #linux-sunxi
<hlauer> pgreco,apritzel: gbit has 60% packet loss with phy/rgmii link mode, so rgmii-id is needed on newer kernels.
<hlauer> Thought I messed up my ethernet cables when I noticed that in 5.8/5.9 series
<hlauer> and ssh stopped working...
<pgreco> so it seems that there are different levels of broken with rgmii, mine doesn't even get an ip from dhcp
<hlauer> so banana pro and m2u both need rgmii-id. my banana pi is waiting for it's 3V chip on the way from china, so can't test at the moment
<jernej> 5.9.11 kernel should have all those fixes included
<jernej> for phy timing
<pgreco> jernej: bananapro was in the list?
<jernej> not sure but m2u for sure
<pgreco> yeap, m2u is there, the ones I did are still missing (m2b and m1)
<jernej> if no one posted a fix then it's not fixed, yeah
<jernej> I went through my collection but I don't have m2b nor m1
<pgreco> yeah, that's what I was trying to confirm with hlauer, so we could confirm
<pgreco> yeap, I have both of those, m2b is not a big deal because you can always use m2u
<ats_> 5.9.11 doesn't have all the fixes - there are still a few that have been sent to linux-sunxi but haven't made it into stable yet
lurchi__ is now known as lurchi_
<ats_> (My kernel build has a patch file which has been steadily getting smaller :-) )
sunshavi has joined #linux-sunxi
<apritzel> I have an M2 Berry, if that is what you refer to with "m2b". I will test tonight and send a fix if needed
luke-jr has quit [Quit: ZNC - http://znc.sourceforge.net]
luke-jr has joined #linux-sunxi
<jernej> apritzel: I received OPi 02, I'm already investigating DRAM init
<apritzel> jernej: great!
<jernej> found one difference, but it must be something more
<[TheBug]> jernej: does that board have wifi and if so what chipset could you tell me (thanks.)
<jernej> well, it's complicated :)
<apritzel> [TheBug]: looks at the pictures in the Wiki, it's apparently a new Allwinner Wifi chip
<[TheBug]> wondering if its another xradio or not
<jernej> that's just a rebrand
<jernej> no, it's not, but it's still obscure
<jernej> let me dig real company/chip name
<[TheBug]> k
<[TheBug]> cool, thanks
anarsoul|2 has joined #linux-sunxi
<apritzel> jernej: be careful with your Opi Lite placeholder DT for the Opi02, the power rails are quite different, with TF-A working it was programming them wrongly
victhor has quit [Quit: Leaving]
anarsoul has quit [Ping timeout: 260 seconds]
<jernej> uh, I should remove that part then
<apritzel> jernej: I have made a proper DT with the correct regulator settings
<jernej> great, then I'll use your
<apritzel> papering over the h616.dtsi part for now (that's work in progress here)
lurchi_ is now known as lurchi__
<apritzel> jernej: it seems like the AXP305 is fully register compatible with the 805?
<apritzel> including the chip ID (of course!)
<jernej> apritzel: I didn't investigate, but it seems so, given that U-Boot report it as 805
<jernej> I mean boot0
<apritzel> so I went through all the register bits and compared them
<jernej> I guess only initial settings are different
<apritzel> I think not even them ...
<apritzel> jernej: so your TV box was also using the 305, and had DRAM at DCDCD?
anarsoul|2 has quit [Ping timeout: 264 seconds]
<jernej> yes
<pgreco> apritzel: I've already submitted the m2berry, and was merged for next
<pgreco> just not picked up for stable yet
<apritzel> pgreco: ah great, thanks!
<jernej> [TheBug]: wifi is from Spreadtrum WCN, platform is called marlin3 and it's not supported by mainline
<apritzel> jernej: there is a pin where you can select the initial voltage for DCDCB, to be 1.2, 1.5 or 1.1V, which smells like LPDDR3/DDR4, DDR3, LPDDR4, respectively
<apritzel> jernej: but it's not used, and apparently the defaults are not specified for the 305, and are of course wrong in case of the DRAM
<JuniorJPDJ> I've a10 tablet and enabled simplefb
<JuniorJPDJ> someone told me I need to use other shit to enable hw acceleration
<JuniorJPDJ> what should I look for?
luke-jr has quit [Quit: ZNC - http://znc.sourceforge.net]
<JuniorJPDJ> a10, a13 and a64 tablets actually
luke-jr has joined #linux-sunxi
anarsoul has joined #linux-sunxi
anarsoul has quit [Excess Flood]
anarsoul has joined #linux-sunxi
anarsoul has quit [Ping timeout: 272 seconds]
anarsoul has joined #linux-sunxi
jbrown has quit [Quit: Leaving]
<jernej> apritzel: I found another change, if I comment out all error checking for training and calibration, size is correctly detected
<apritzel> jernej: so does it also work? I mean can you write values and read them back? ;-)
<jernej> I didn't try - if SPL crashes, reading and writing definitively don't work
anarsoul has quit [Ping timeout: 260 seconds]
<apritzel> ah, OK, I see
<apritzel> actually we now have enough SRAM to move BSS and heap(?) into there, and wouldn't need DRAM for the SPL already
jbrown has joined #linux-sunxi
<jernej> apritzel: imo it's good indicator what to expect :)
<apritzel> yeah, exactly
iamfrankenstein has joined #linux-sunxi
gaston1980 has quit [Ping timeout: 260 seconds]
gaston1980 has joined #linux-sunxi
apritzel has quit [Ping timeout: 260 seconds]
luke-jr has quit [Quit: ZNC - http://znc.sourceforge.net]
luke-jr has joined #linux-sunxi
anarsoul has joined #linux-sunxi
yann has quit [Ping timeout: 240 seconds]
tnovotny has quit [Quit: Leaving]
kaspter has quit [Ping timeout: 260 seconds]
kaspter has joined #linux-sunxi
lucascastro has quit [Ping timeout: 240 seconds]
yann has joined #linux-sunxi
gaston1980 has quit [Ping timeout: 260 seconds]
apritzel has joined #linux-sunxi
apritzel has quit [Ping timeout: 260 seconds]
<jernej> apritzel: Success! Correct mode register values are those which I put in for TV box
<jernej> so MR values from dram config are wrong and most likely get overwritten during auto probing something...
<jernej> let me clean changes a bit
DrFrankensteinUK has quit [Ping timeout: 260 seconds]
DrFrankensteinUK has joined #linux-sunxi
<jernej> apritzel: this is on top of my current git branch: http://ix.io/2FsL
jstein has joined #linux-sunxi
JohnDoe_71Rus has quit [Quit: KVIrc 5.0.1 Aria http://www.kvirc.net/]
bauen1 has quit [Remote host closed the connection]
<jernej> JuniorJPDJ: what kind of HW acceleration are you talking about? GPU or video decoding or something else?
ldevulder_ has joined #linux-sunxi
ldevulder has quit [Ping timeout: 246 seconds]
<JuniorJPDJ> gpu, not cedarx
<JuniorJPDJ> 3d/2d hw rendering
<JuniorJPDJ> best, both, good enough 3d
tglx has joined #linux-sunxi
<tglx> evening
<jernej> for that, simplefb won't work
<jernej> you have to enable proper DRM driver - sun4i-drm (for display) and mali (for GPU)
<tglx> trying to figure out why this driver does not load: libGL error: failed to load driver: sun4i-drm
<jernej> but both of these drivers depends on correct settings in DT
apritzel has joined #linux-sunxi
lkcl has quit [Ping timeout: 264 seconds]
apritzel has quit [Ping timeout: 265 seconds]
lkcl has joined #linux-sunxi
popolon has joined #linux-sunxi
iamfrankenstein has quit [Quit: iamfrankenstein]
gaston1980 has joined #linux-sunxi
<jernej> apritzel: ... and it's gone! Second H616 board which I destroyed in mere hours
<karlp> how'd you kill it? blew the ram apart with power supply fail?
<jernej> this time I mixed up regulators - DRAM doesn't like 3.3 V
<karlp> clever.
<karlp> all that control, all those ways to connect things :)
<jernej> copy & paste issue
<jernej> back to TV box I guess...
netlynx has quit [Quit: Ex-Chat]
<jernej> at least I fixed DRAM so apritzel could continue with his board...
victhor has joined #linux-sunxi
giomba has joined #linux-sunxi
sunshavi has quit [Ping timeout: 256 seconds]
<jernej> ah, maybe it's not destroyed after all
<jernej> hm... I wonder why at one point it behaved as it doesn't work
<[TheBug]> jernej: Thanks
hlauer has quit [Ping timeout: 264 seconds]
yann has quit [Read error: No route to host]
camus has joined #linux-sunxi
kaspter has quit [Ping timeout: 240 seconds]
camus is now known as kaspter
yann has joined #linux-sunxi
ldevulder_ has quit [Quit: Leaving]
ldevulder has joined #linux-sunxi
eduardas has joined #linux-sunxi
apritzel has joined #linux-sunxi
indy has quit [Ping timeout: 272 seconds]
<apritzel> jernej: wohoo! awesome! Now I have to move all my debug code away first ...
DonkeyHotei has joined #linux-sunxi
camus has joined #linux-sunxi
kaspter has quit [Ping timeout: 256 seconds]
camus is now known as kaspter
<jernej> apritzel: let me know if it works for you
indy has joined #linux-sunxi
giomba has quit [Remote host closed the connection]
<apritzel> jernej: \O/ works!
<jernej> great
<apritzel> so it's just the old MR values, plus this one clrbit line moved?
sunshavi has joined #linux-sunxi
<jernej> there is one feature (I don't know which) which is not used by OPi 02 - at PHY offset 0x780
<jernej> I commented it out
<jernej> that is all the difference to your previous attempts
<apritzel> I found those values to be different in my dump compared to yours, so I adjusted them to match
asdf28 has quit [Ping timeout: 240 seconds]
<apritzel> I disabled that change before applying your patch, let me check if that would work
bauen1 has joined #linux-sunxi
<apritzel> jernej: mmmh, works both ways: if I write all 0x07 in there instead, or your existing "write mostly 0x16" (or disable completely)
<jernej> apritzel: note that 0x07 is reset value, so you can just skip it in such case
popolon has quit [Quit: WeeChat 3.0]
<apritzel> jernej: right, I was just thinking about that
<jernej> I really don't know if we can leave this enabled or not
<apritzel> jernej: does it work for your OPi with the 0x16 variant as well?
<jernej> apritzel: yes, seems to work
<jernej> well, it boots
<apritzel> and on your TV box you need to disable write leveling, read training and write training?
hramrach has quit [Ping timeout: 246 seconds]
<jernej> yes
<jernej> and enable bit delay compensation
DonkeyHotei has quit [Ping timeout: 264 seconds]
<jernej> write leveling caused that only half memory was detected
<jernej> same issue was caused with one training (not sure which)
cmeerw has quit [Ping timeout: 268 seconds]
<jernej> apritzel: emac driver already kinda works, it has some communication issues - packet loss
hramrach has joined #linux-sunxi
<jernej> apritzel: ok, with tweaking delay a bit (using default one from BSP) it works now
<jernej> so, this should be good base for kernel developing
<apritzel> so did anyone look at the clocks yet?
<apritzel> I got through the PLLs yesterday
<apritzel> they look the same as the H6, only one less (I think)
<apritzel> right, the H616 has no PLL_HSIC
<jernej> apritzel: I pushed my changes for emac, if you're interested
<jernej> apritzel: any luck with TF-A and SRAM A2?
<apritzel> I was about to look at that now. I think boot0 didn't set up AHB1 properly, at least I got a weird reading (OSC as the source, /2 /3)
<apritzel> jernej: so I have a TF-A build running in DRAM
<apritzel> but the interesting part (SMP) is untested yet
<apritzel> jernej: I marked DCDCE as regulator-boot-on; in the DT, so TF-A brings that up
<jernej> I know, but there is no TF-A for now
<apritzel> yeah, just a heads up
<jernej> although I'm not 100% sure that's correct - if someone don't need ethernet because uses wifi - regulator is powered on without need
<apritzel> this is also driving the SD card
<apritzel> plus I think regulator-boot-on means you can disable it at runtime
<jernej> ok, anyway, enough tinkering for today...
<apritzel> jernej: well done, thanks a lot!
<jernej> apritzel: quick question, shouldn't be dcdce enabled by default, otherwise SD card can't be read?
<apritzel> ha, indeed
<jernej> I mean, brom couldn't boot from it
<apritzel> I will try to dump all AXP registers as early as possible
<apritzel> in the 805 datasheet the default is "enabled" at 3.3V