Ntemis has quit [Read error: Connection reset by peer]
lurchi_ is now known as lurchi__
<wens>
MoeIcenowy: you should probably have different compatibles for the different ccus, matching the soc name at least? (if they are known to be different)
\\Mr_C\\ has joined #linux-sunxi
cnxsoft has quit [Remote host closed the connection]
cnxsoft has joined #linux-sunxi
ErwinH has joined #linux-sunxi
ErwinH has quit [Ping timeout: 260 seconds]
ErwinH has joined #linux-sunxi
ErwinH has quit [Ping timeout: 260 seconds]
chlorine has joined #linux-sunxi
pg12 has quit [Ping timeout: 268 seconds]
pg12 has joined #linux-sunxi
chlorine has quit [Ping timeout: 260 seconds]
ErwinH has joined #linux-sunxi
ErwinH has quit [Ping timeout: 260 seconds]
leviathan has joined #linux-sunxi
Gerwin_J has quit [Quit: Gerwin_J]
<plaes>
wens: while you're at it...
<plaes>
in drivers/gpu/drm/sun4i/sun4i_backend.c sunxi_rgb2yuv_coef can be marked const
ErwinH has joined #linux-sunxi
ErwinH has quit [Ping timeout: 260 seconds]
TheSeven has quit [Ping timeout: 259 seconds]
TheSeven has joined #linux-sunxi
lurchi__ has quit [Read error: Connection reset by peer]
<MoeIcenowy>
montjoie: nope... BU2 seems to not care EMAC
<walkiry>
montjoie: line 371
<walkiry>
montjoie: i commented some stuffs i understood from their maze code
<oliv3r>
wens: ok turns out, its the PMIC that stops working after enabling ldo3 in u-boot
<jelle>
MoeIcenowy: BU2 is?
gumblex has quit [Quit: ZNC 1.6.4+deb1 - http://znc.in]
<montjoie>
MoeIcenowy: thanks for the try, I will try ask them direclty just in case of...
<MoeIcenowy>
A series and VR
gumblex has joined #linux-sunxi
cnxsoft has quit [Quit: cnxsoft]
fkluknav has joined #linux-sunxi
<willmore>
MoeIcenowy, welcome back! Are you going to put your notes online somewhere? :)
<MoeIcenowy>
an email will be sent to me
<MoeIcenowy>
and I will translate it to English
<willmore>
Wonderful. Thank you for all the work you've done!
<BenG83>
yeah thanks I hope you had a good trip
<oliv3r>
wens: i have not figured out as to why enabling LDO3 75% of the time causes failure. I have seen an old thread where people talk about ldo3 and its unknown secret properties
<wens>
MoeIcenowy: sounds like it was a long meeting
<MoeIcenowy>
not too long ;-)
my123 has quit [Ping timeout: 260 seconds]
Worf has quit [Quit: Konversation terminated!]
<oliv3r>
i'm now going over the datasheet, but I wonder if there is an errata for the AXP209 user manual?
<oliv3r>
i'm guessing we may need to stagger power up of the PMIC
victhor has joined #linux-sunxi
<oliv3r>
MoeIcenowy: did you get anything usefull from it? :)
fkluknav has quit [Ping timeout: 240 seconds]
jemk has quit [Remote host closed the connection]
jemk has joined #linux-sunxi
techping has quit [Remote host closed the connection]
msevwork has quit [Quit: Leaving]
willmore has quit [Ping timeout: 260 seconds]
Andy-D has joined #linux-sunxi
fkluknav has joined #linux-sunxi
ErwinH has joined #linux-sunxi
willmore has joined #linux-sunxi
ErwinH has quit [Read error: No route to host]
ErwinH has joined #linux-sunxi
chlorine has joined #linux-sunxi
ErwinH has quit [Ping timeout: 260 seconds]
The_Loko has joined #linux-sunxi
chlorine has quit [Ping timeout: 260 seconds]
ErwinH has joined #linux-sunxi
my123 has joined #linux-sunxi
my123 has joined #linux-sunxi
my123 has quit [Changing host]
ErwinH has quit [Ping timeout: 268 seconds]
IgorPec has quit [Ping timeout: 260 seconds]
pietrushnic has quit [Ping timeout: 240 seconds]
ErwinH has joined #linux-sunxi
ErwinH has quit [Ping timeout: 240 seconds]
LargePrime has quit [Ping timeout: 260 seconds]
ErwinH has joined #linux-sunxi
ErwinH has quit [Ping timeout: 240 seconds]
fkluknav has quit [Ping timeout: 260 seconds]
LargePrime has joined #linux-sunxi
nove has joined #linux-sunxi
fkluknav has joined #linux-sunxi
r1mikey has quit [Remote host closed the connection]
<apritzel>
MoeIcenowy: thanks for trying to talk some sense into AW ;-)
<MoeIcenowy>
jernej: thx
ErwinH has quit [Ping timeout: 260 seconds]
<apritzel>
MoeIcenowy: I started with LPDDR3 support yesterday, identifying differences in boot0 between LPDDR3 and DDR3 and adding this to the U-Boot driver
<MoeIcenowy>
thx ;-)
<apritzel>
MoeIcenowy: I need now to add the different timings, probably taking some of your V3s patches as a base
<apritzel>
MoeIcenowy: and then probably compare register dumps as a final step to identify leftovers
ErwinH has joined #linux-sunxi
<jernej>
MoeIcenowy: I also found out that MIPI DSI on A64 is same as described in R16/A33 manual (unfortunatelly, without PHY part)
ErwinH has quit [Ping timeout: 240 seconds]
<jernej>
MoeIcenowy: and that GPL licensed DSI code is in tinalinux repo
<jernej>
at least we can support A64 lcds...
<jernej>
I mean pine64
<MoeIcenowy>
yes I think so ;-)
* apritzel
is slightly concerned that a 4.4 BSP will not be helpful
<apritzel>
instead might steer people away from mainline
ErwinH has joined #linux-sunxi
<apritzel>
I wonder if they just forward port their drivers, mostly ignoring the mainline drivers
phipli has joined #linux-sunxi
<Ke>
btw. are people also pushing supported configurations to distro stock kernels as far as they are possible?
<jelle>
well that's up to the distros I assume
<apritzel>
Ke: you mean asking for backports?
sgteem has quit [Ping timeout: 240 seconds]
<Ke>
definitely, but distros often might not move unless prompted to do so
<Ke>
apritzel: I mean enabling proper config options in the existing kernels
<jelle>
o?
<apritzel>
Ke: oh, I see
<Ke>
not everything can be supported in whatever distros provide, but to the extent that is possible
<apritzel>
Ke: for arm64 parts (the one and only) defconfig should cover most of it
<MoeIcenowy>
apritzel: I think they reused some mainline drivers when porting to 3.10
<apritzel>
Ke: that's what we push for
<Ke>
I remember c201 support bug on debian bugzilla unattended for a very long time even though linux-4.9 has extremely good support for it
ErwinH has quit [Ping timeout: 260 seconds]
<apritzel>
MoeIcenowy: did they? I thought that they are still using their UART drivers, for instance
<jelle>
Ke: well that's up to debian then I'd say
<Ke>
apritzel: do distros mainly follow defconfigs?
<MoeIcenowy>
at least for MMC driver they applied their changes on top of mainlined driver
<MoeIcenowy>
so does sun4i-emac driver (used in R40)
<Ke>
jelle: obviously, but distros can be lobbied
<apritzel>
Ke: so you are volunteering? Nice!
<Ke>
I don't even own the hw, just asking
* jelle
doesn't see the point
afaerber has quit [Quit: Leaving]
<apritzel>
Ubuntu has CONFIG_ARCH_SUNXI off in their arm64 v4.10 .config
<apritzel>
(though 4.10 is not really useful, I've to admit)
<apritzel>
but it's enabled in mainline defconfig
ErwinH has joined #linux-sunxi
sgteem has joined #linux-sunxi
<MoeIcenowy>
oh the bridge get mysterious -- when it's probed it's normal, but when it boots into U-Boot cmdline it disappeared on I2C bus
<jernej>
which bridge?
<MoeIcenowy>
ANX6345, used in Pinebook as RGB to eDP
ErwinH has quit [Ping timeout: 260 seconds]
chomwitt has joined #linux-sunxi
ErwinH has joined #linux-sunxi
ErwinH has quit [Ping timeout: 260 seconds]
BenG83_PB has joined #linux-sunxi
LargePrime has quit [Ping timeout: 260 seconds]
ErwinH has joined #linux-sunxi
vishnup has quit [Ping timeout: 268 seconds]
alt01d has joined #linux-sunxi
ErwinH has quit [Ping timeout: 255 seconds]
r1mikey has joined #linux-sunxi
r1mikey has quit [Remote host closed the connection]
r1mikey has joined #linux-sunxi
IgorPec has quit [Ping timeout: 255 seconds]
ErwinH has joined #linux-sunxi
<alt01d>
Hi, I want to change the APB1 clock from 24MHz to 30MHz on CHIP (R8, GR8) on Linux 4.4. Can I do that in the device tree? or do I need to change drivers/clk/sunxi/clk/sunxi.c?
<MoeIcenowy>
apritzel: have you asked any Pinebook sample to TL?
<apritzel>
MoeIcenowy: no, though he once mentioned earlier he wanted to send some to me
<apritzel>
MoeIcenowy: but I'd wait till get the display to work :-D
<apritzel>
*till you get*
<apritzel>
MoeIcenowy: is it easy to connect serial?
<MoeIcenowy>
this early version is a disaster for developing...
<MoeIcenowy>
very uneasy
<MoeIcenowy>
except use MicroSD breakout
<apritzel>
opening the case?
<MoeIcenowy>
soldering needed
ErwinH has quit [Ping timeout: 240 seconds]
<jernej>
apritzel: simplefb works with my u-boot patches
<jernej>
I guess it is enough for dev purposes
<apritzel>
jernej: so you have a "magic bit 24" patch in your repo?
<jernej>
yep
<apritzel>
jernej: but only via HDMI, right?
<jernej>
yes
<apritzel>
jernej: I might give it a try on my Remix Mini PC, then
<jernej>
de2_wip branch
<MoeIcenowy>
I'm now trying hard to get eDP to work on PB...
<MoeIcenowy>
I hate the Analogix bridge
<apritzel>
MoeIcenowy: do you have *any* kind of documentation?
<jernej>
it has also H5 hdmi and tv out support
<MoeIcenowy>
no except some code by AW/RK
* apritzel
feels pity for MoeIcenowy
ErwinH has joined #linux-sunxi
<MoeIcenowy>
or should I just give up U-Boot and go to kernel side for graphics support? ;-)
<apritzel>
I will trade LPDDR3 support for a working display ;-)
<BenG83_PB>
:)
<MoeIcenowy>
As the kernel TCON code is more robust ;-)
<apritzel>
MoeIcenowy: makes some sense, but for the Pinebook U-Boot graphics support would be actually useful
<BenG83_PB>
whatever AW hacked in the driver for the ANX, it was enough to get it working on their BSP kernel
<jernej>
apritzel: actually, that 24th bit is not magic anymore. It has comment that it means switching SRAM from cpu to video control
<MoeIcenowy>
s/enough/only &/g
<BenG83_PB>
;P
<jernej>
apritzel: but I don't know which section.
<apritzel>
jernej: right, I saw that the other day
<apritzel>
jernej: do we know which (part of the) SRAM this affects
ErwinH has quit [Ping timeout: 260 seconds]
<jernej>
apritzel: as I said, no
<MoeIcenowy>
I think currently these "SRAM"s do not have any mapping in CPU address space
<MoeIcenowy>
so we can just consider them as generic syscon magic bits ;-)
<apritzel>
MoeIcenowy: but we don't have access to the last part of SRAM C, for instance
<apritzel>
MoeIcenowy: and also see issues with higher bus frequencies for the first part
<BenG83_PB>
I hoped Tl had a new PCB revision for MoeIcenowy, that's why I started the wiki page for PB
<MoeIcenowy>
BenG83: Nope
<MoeIcenowy>
some small hardware bugs occured on the new revision
<MoeIcenowy>
so it's delayed
<BenG83_PB>
ok
<apritzel>
also IIRC on older AW SoCs you also switch SRAM ownership
<BenG83_PB>
should I start adding pictures for UART, FEL testpoints for the prototype revision?
<BenG83_PB>
or do we wait a bit until the next PCBs come out
<apritzel>
BenG83_PB: yes, please
<apritzel>
give as most information as possible
<apritzel>
chances are most of it does not change much
<apritzel>
even if, it's a Wiki ...
<jernej>
uh, BSP u-boot mentions that VE is enabled by BROM (reset, gates) and it is explicitly cleared by U-Boot
leviathan has quit [Ping timeout: 255 seconds]
<jernej>
should we do something similar?
<jernej>
as I don't see any value having VE enabled
<apritzel>
jernej: VE?
<apritzel>
what for?
<apritzel>
fancy boot animation? ;-)
<BenG83_PB>
^
<jernej>
no, it is not used at all
<jemk>
for sram c, at least the secure brom uses it for large toc0
<jernej>
but for some strange reason, BROM enables it
<jernej>
and leaves it enabled
<jernej>
at least partially
phipli has quit [Ping timeout: 255 seconds]
<apritzel>
jemk: I saw the secure brom enables crypto engine
<apritzel>
which makes some sense
<jernej>
if you dump CCU regs, check bus gating and reset regs
<jernej>
you will see that VE is enabled
<jernej>
on mainline U-Boot
<apritzel>
jernej: I think I did it lately and didn't spot anything weird, but can re-check
<jernej>
apritzel: but I'm not sure where would be the best place
ErwinH has joined #linux-sunxi
<apritzel>
ssvb: yeah, I dimly remembered you mentioning this some months ago
IgorPec4 has joined #linux-sunxi
<apritzel>
so this is actually this "magic" bit which makes DE work on the A64, right?
<jernej>
if you mean 24 bit in sram control register, then yes
ErwinH has quit [Ping timeout: 240 seconds]
<MoeIcenowy>
Is DE2 just occpying SRAM C?
<MoeIcenowy>
Or what it occpies is only some unmapped SRAM?
<ssvb>
both DE2 and VE might possibly use it for storing its own data
<apritzel>
MoeIcenowy: and I think it's the same SRAM C that *is* mapped to the CPU as well
<apritzel>
so this bit just transfers ownership
<ssvb>
during early boot SRAM C provides some extra storage space in SRAM for the bootloader
<ssvb>
if we don't need this storage space, then we can disable it from the SPL
<montjoie>
MoeIcenowy: PHY problem confirmed on my opipc without emac in uboot
<apritzel>
ssvb: yeah, makes sense, when you need graphics or video, you probably have DRAM up already
<MoeIcenowy>
montjoie: thx l-)
<MoeIcenowy>
;-)
ErwinH has joined #linux-sunxi
<montjoie>
MoeIcenowy: I will work on it tomorow, but fix is nearly easy
<montjoie>
funny that I hit it certainly, but forget it after updated uboot
<montjoie>
and so moved init_phy too late in the process
<jernej>
apritzel: ssvb: Should be also VE gate and reset disabled in SPL? I just confirmed that they are enabled through fel
<ssvb>
jernej: maybe yes, if allwinner is handling these configuration bits together
<MoeIcenowy>
Now I really hope there can be someone to give me tips for the ANX bridge support ;-)
<jemk>
ssvb: followup on bootimes, i've now measured them and my feeling was correct: 1.13s secure vs 0.51s normal, from cpu reset to first char of spl banner, on h3
ErwinH has quit [Ping timeout: 240 seconds]
<ssvb>
apritzel: if we disable SRAM C, then we need to find 8K of space in SRAM A2 for FEL boot
<ssvb>
apritzel: so that we fit the SPL stack, FEL backup storage area and ATF there
* apritzel
generously hands over the last 8K of it
<apritzel>
ssvb: ATF is only about 32KB atm
<apritzel>
and I started using parts of it for the SPL stack already
r1mikey_ has joined #linux-sunxi
<apritzel>
ssvb: what about 0x50000 - 0x51fff?
<apritzel>
so 5,2000 till 5,3fff can be used for the SPL stack
r1mikey has quit [Ping timeout: 240 seconds]
<apritzel>
that would still leave 48K for ATF
r1mikey_ has quit [Ping timeout: 240 seconds]
<apritzel>
(which is the total amount of RAM my first computer had)
afaerber has joined #linux-sunxi
phipli has joined #linux-sunxi
alexxy has quit [Ping timeout: 245 seconds]
ErwinH has joined #linux-sunxi
ErwinH has quit [Ping timeout: 260 seconds]
ErwinH has joined #linux-sunxi
apritzel has quit [Ping timeout: 240 seconds]
<jernej>
apritzel: ssvb: Should I prepare the patch for A64 SPL to transfer SRAM control and disable VE bits?
ErwinH has quit [Ping timeout: 260 seconds]
IgorPec has joined #linux-sunxi
yann has joined #linux-sunxi
ErwinH has joined #linux-sunxi
IgorPec4 has quit [Ping timeout: 260 seconds]
terra854 has quit [Quit: Connection closed for inactivity]
r1mikey has quit [Remote host closed the connection]
ErwinH has quit [Ping timeout: 260 seconds]
alt01d has quit [Ping timeout: 260 seconds]
mossroy has joined #linux-sunxi
f0xx has quit [Ping timeout: 240 seconds]
_whitelogger_ has joined #linux-sunxi
lemonzest has quit [Quit: Leaving]
ErwinH has quit [Ping timeout: 260 seconds]
_whitelogger has quit [Remote host closed the connection]
iamfrankenstein has quit [Quit: iamfrankenstein]
phipli has joined #linux-sunxi
apritzel has joined #linux-sunxi
<apritzel>
jernej: transfer SRAM control to whom? The DE? Wouldn't this be part of the DE2.0 U-Boot series?
r1mikey has joined #linux-sunxi
ErwinH has joined #linux-sunxi
<jernej>
yes, but it would also be needed if there is a possibility to run BSP kernel. Is such thing possible?
<apritzel>
jernej: do you mean BSP kernel with upstream U-Boot?
<jernej>
apritzel: yes, that works nicely with H3
<apritzel>
jernej: but doesn't work at all with the A64
<apritzel>
and this bit is A64 only, right?
<ssvb>
apritzel, jernej: personally I would prefer to see SRAM C disabling and AHB1 reclocking done somewhere after the SPL, maybe in the ATF
<ssvb>
but this just breaks a nice abstraction where we have basic clocks setup done by the SPL
ErwinH has quit [Ping timeout: 240 seconds]
<ssvb>
still having SRAM C available to the SPL potentially allows us to load huge SPL binaries (via runtime code decompression or a simple trampoline stub)
<jernej>
apritzel: yes, it is A64 only. Out of curiosity, what is the issue with loading BSP kernel on upstream U-Boot? ATF?
komunista has quit [Quit: Leaving.]
<jernej>
ssvb: I'm ok either way, but that bit must be cleared any way (I guess DRM driver won't bother with that)
<jernej>
so maybe in board init code?
<ssvb>
as a start, can your video driver just do this?
<jernej>
of course, that was initial plan
<ssvb>
:)
ErwinH has joined #linux-sunxi
<jernej>
but as I said, should be Linux DRM driver aware of this? I think not...
<ssvb>
you can always check the bit and do something if it is not right (fixup and/or maybe print some warning)
<apritzel>
setting both to #if 1 generates no valid signal (monitor complaining)
<apritzel>
before that the signal seemed valid, though the screened remained black
<apritzel>
checking now only one of them
<jernej>
well, you could still try to set that clrbits to setbits
<jernej>
if signal seems to be ok, then the issue has to be connected to DE2
<apritzel>
setbits didn't help either
<apritzel>
setting mux := 1; now: still no signal
<apritzel>
(in line 1009 I mean)
lurchi_ is now known as lurchi__
ErwinH has joined #linux-sunxi
<jernej>
I'm out of the ideas. It might be something with the clocks. For example, A83T doesn't even have DE2 clock register. Why? I don't know, but it seems that Allwinner likes doing small changes
lurchi__ is now known as lurchi_
<apritzel>
jernej: no worries, thanks anyway for your help
ErwinH has quit [Ping timeout: 260 seconds]
<jernej>
no problem, but you will still test it with A64?
<apritzel>
so changing either or both line 988 and 1009 to the H3/H5 behaviour never generated a signal
phipli has quit [Ping timeout: 240 seconds]
<apritzel>
keeping them both to the non-H3/H5 makes the screen black, actually to the point where the monitor doesn't really react anymore (on-screen menu doesn't appear)
<apritzel>
clrbits or setbits in line 442 doesn't make a difference
<apritzel>
let me compare the clock registers
<apritzel>
the usual ones in the CCU? Or in the DE2 block?
<apritzel>
and sure: I will stay on the A64
<jernej>
uh, there is also the possibility that H64 is using different HDMI PHY, just like A83T
<apritzel>
sounds like AW
<apritzel>
mix and match
<jernej>
actually, I would prefer A83T approach, because it uses standard Synopsys IP block
<jernej>
other SoCs are using something proprietary with no documentation
<jernej>
I mean HDMI PHY
ErwinH has joined #linux-sunxi
<apritzel>
Ah, I see
<apritzel>
do we have A83T HDMI PHY support in U-Boot already?
<jernej>
no, I plan to add it
<jernej>
I first have to extract platform independant code from rockchip hdmi driver
<jernej>
to share as much as possible
<jernej>
this will work very well with A83T
<apritzel>
sounds nice indeed
ErwinH has quit [Ping timeout: 255 seconds]
<apritzel>
and no hurry here, H64 is not that widespread
<apritzel>
lets focus on A64/H3/H5 first
<apritzel>
jernej: I was wondering if we could name the #defines after their effect and not after the SoCs showing this behaviour