<cini>
noblock,I get uboot from github.com/apritzel/uboot sunxi64-beta but I cannt get sun50i_h5_spl32_defconfi. so ,should I get uboot from https://github.com/ehoutsma/u-boot.git?
ErwinH has joined #linux-sunxi
fkluknav has joined #linux-sunxi
cini has quit [Ping timeout: 260 seconds]
lemonzest has joined #linux-sunxi
ErwinH has quit [Ping timeout: 256 seconds]
premoboss has joined #linux-sunxi
<MoeIcenowy>
mripard: at least for V3s and R40 I found it necessary to have a parent reset line for a reset line...
<wens>
which one?
ErwinH has joined #linux-sunxi
premoboss has quit [Ping timeout: 255 seconds]
ErwinH has quit [Ping timeout: 252 seconds]
<MoeIcenowy>
for V3s RST_USB_PHY depends on RST_USB_OTG
<MoeIcenowy>
for R40's tcon, tvd, tve there's "*-top" reset lines which is depended on by seperate bus rsts
DullTube has joined #linux-sunxi
<MoeIcenowy>
or there's another solution -- pass both resets (the -top one and the seperate one) into the driver, and the driver deasserts the -top one in shared mode, and deassert the seperate one in non-shared mode
ErwinH has joined #linux-sunxi
ErwinH has quit [Ping timeout: 240 seconds]
msevwork has joined #linux-sunxi
<wens>
is *-top in a separate address space?
tkaiser has joined #linux-sunxi
techping has quit [Ping timeout: 260 seconds]
tkaiser has quit [Ping timeout: 260 seconds]
Putti has quit [Ping timeout: 240 seconds]
Putti has joined #linux-sunxi
f0xx has joined #linux-sunxi
ErwinH has joined #linux-sunxi
fl_0 has quit [Ping timeout: 260 seconds]
florianH has joined #linux-sunxi
tkaiser has joined #linux-sunxi
cini has joined #linux-sunxi
tkaiser has quit [Ping timeout: 260 seconds]
fl_0 has joined #linux-sunxi
<cini>
apritzel, noblock, my orangepi-pc2 can boot lasted linux with sdcard. cool, thanks. all works well with https://github.com/ehoutsma/u-boot-h5
reinforce has quit [Quit: Leaving.]
cini has quit [Ping timeout: 260 seconds]
reinforce has joined #linux-sunxi
tkaiser has joined #linux-sunxi
jernej has quit [Ping timeout: 260 seconds]
LargePrime has quit [Ping timeout: 260 seconds]
Mr__Anderson has joined #linux-sunxi
yann has quit [Ping timeout: 255 seconds]
<wens>
drm cleanup patches are stacking up
LargePrime has joined #linux-sunxi
<plaes>
oh sweet
<wens>
plaes: i haven't gotten to multiple pipeline support yet
<wens>
fixing a bunch of stuff along the way
<plaes>
yeah, that's always nice :)
<plaes>
I'll probably have more free time in evenings from next month...:)
<oliv3r>
tkaiser: toggeling PH3 and PH6 works fine and is somewhat exactly what i want
<oliv3r>
tkaiser: but i want to do it from user space
<oliv3r>
tkaiser: in a somewhat official/generic way
<oliv3r>
by toggeling the USB vbus pins manually, i have to thus unbind them from the driver, meaning the driver no longer has control over the vbus
<plaes>
extend rfkill to usb
<oliv3r>
plaes: yeah that's one way of doing it
<oliv3r>
plaes: but isn't rfkill only for radio devices?
<oliv3r>
if i have a camera on usb1, is it appropiate to use rfkill for that?
<oliv3r>
and how does rfkill work with usb right now? (i know it works for certain internal USB bluetooth adapters
<plaes>
haven't investigated that :(
<oliv3r>
i wonder what rfkill really does. tell the device to disable power
<oliv3r>
or actually power off a port
<oliv3r>
(if it can)
<wens>
rfkill is just the framework
<wens>
drivers might register an rfkill device with it, and the callbacks would toggle low power states
<oliv3r>
well rf stands for Radio Frequency, so is it a bad name that was left behind?
<oliv3r>
ah see, low-power state, i want to completly cut off power
<wens>
don't think that works, since if you cut off power, the device disappears, and the rfkill device along with it
<oliv3r>
i would expect a hard block to (in our case) cut off vbus entirely
<wens>
rfkill only kills the rf part, hence the name
<oliv3r>
ah see, so rfkill is not the proper solution :(
<wens>
nope
<oliv3r>
but toggeling ph3 maually via sys_gpio is very ugly too
<wens>
though vendors do abuse it
<oliv3r>
ideally, i want a user-space hook for phy_power_off
<wens>
is it usb or sdio based?
<oliv3r>
right now i'm trying to see if i can unbind ehci-platform (and ohci-platform) which does kill the power
<oliv3r>
i want to cut power of the USB ports
<wens>
that sounds like an idea
<oliv3r>
yeah but right now, when i re-enable power, the atheros driver crashes :
<wens>
:/
paulk-collins has joined #linux-sunxi
<oliv3r>
so i may have to unbind the ehci-platform driver, unload the usb drivers (ath9k/uvc) etc
BenG83_PB has quit [Ping timeout: 268 seconds]
<oliv3r>
(or unbind ath9k in more then one spot)
<oliv3r>
anyhow, rfkill is not tied into the phy_power_off in any way
<oliv3r>
it seems only the platform drivers are
yann has joined #linux-sunxi
<MoeIcenowy>
wens: no, *-top is directly after seperate gates/resets
<wens>
hmm
<wens>
on the a80 they were in different address spaces, so i just did a separate device driver for them
wzyy2 has quit [Read error: Connection reset by peer]
Andy-D has joined #linux-sunxi
camh1 is now known as camh
BenG83 has joined #linux-sunxi
matthias_bgg has quit [Quit: Leaving]
<MoeIcenowy>
wens: you mean usb clks/rsts @ 0xcc?
<wens>
MoeIcenowy: yup
<MoeIcenowy>
wens, mripard: I have a question: if a clock have two parents configurable, one is only used by this clock as parent, and the other is a common parent, can I set the clock as CLK_SET_RATE_PARENT
<MoeIcenowy>
(or specified: the sata mod clk on R40 have two parents: pll-sata and pll-periph0
<MoeIcenowy>
(and it's a mux only clock
<MoeIcenowy>
wens: I didn't record 0xcc clocks to the doc, as I directly modified the ccu-sun8i-r40.c
<wens>
the sata clock probably will never change
IgorPec has quit [Ping timeout: 252 seconds]
<MoeIcenowy>
but if there's no CLK_SET_RATE_PARENT I think it won't change pll-sata
<wens>
but to be safe you can do CLK_SET_RATE_PARENT + CLK_NO_REPARENT, and force the parent to pll-sata
<MoeIcenowy>
how to force parent?
<MoeIcenowy>
should force parent in dt?
matthias_bgg has joined #linux-sunxi
matthias_bgg has quit [Client Quit]
matthias_bgg has joined #linux-sunxi
<MoeIcenowy>
OOPS! THE BSP CLOCK CODE OF R40 SHOWS A COLLISION ON DRAM_GATE 2!
<MoeIcenowy>
both deinterlace and csi1 uses DRAM_GATE 2
fkluknav has quit [Ping timeout: 240 seconds]
leviathancn has joined #linux-sunxi
<wens>
MoeIcenowy: call clk_set_parent in the ccu probe function :)
jelle has quit [Quit: Ragequittt]
IgorPec has joined #linux-sunxi
BenG83 has quit [Ping timeout: 240 seconds]
dave0x6d has quit [Quit: Connection closed for inactivity]
fALSO has quit [Ping timeout: 276 seconds]
nikre has joined #linux-sunxi
BenG83_PB has joined #linux-sunxi
jelly12gen has joined #linux-sunxi
jelly12gen has joined #linux-sunxi
jelly12gen has quit [Changing host]
jelly12gen is now known as jelle
maz has joined #linux-sunxi
tsuggs has quit [Ping timeout: 276 seconds]
BenG83_PB has quit [Quit: Leaving]
tkaiser has quit [Ping timeout: 256 seconds]
BenG83_PB has joined #linux-sunxi
Ntemis has joined #linux-sunxi
IgorPec has quit [Ping timeout: 256 seconds]
BenG83_PB has quit [Remote host closed the connection]
BenG83 has joined #linux-sunxi
wzyy2 has joined #linux-sunxi
gzamboni has quit [Ping timeout: 258 seconds]
wzyy2 has quit [Read error: Connection reset by peer]
yann has quit [Ping timeout: 276 seconds]
yann|work has joined #linux-sunxi
wzyy2 has joined #linux-sunxi
tkaiser has joined #linux-sunxi
komunista has joined #linux-sunxi
wzyy2 has quit [Read error: Connection reset by peer]
vinimac has joined #linux-sunxi
tkaiser has quit [Ping timeout: 268 seconds]
vinimac has quit [Quit: Saindo]
maz has quit [Remote host closed the connection]
JohnDoe_71Rus has quit [Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org]
chomwitt has joined #linux-sunxi
<Wizzup>
I have an Olimex A64 board, is anyone working on any dtses/u-boot patches?
<plaes>
which board?
fkluknav has joined #linux-sunxi
<plaes>
Wizzup: if you have the board, then please start contributing to the wiki
<swabbles>
problem is, we currently lack a working u-boot/Linux kernel.
<swabbles>
sunxi-fel does work though.
<plaes>
well, Olimex also is not yet selling A64 boards
<Wizzup>
this is a sample
<Wizzup>
I can make pictures and add to the wiki
<Wizzup>
I will mail them about a repo for u-boot/kernel
<plaes>
ok, please do
<Wizzup>
in the evening I will
maz has joined #linux-sunxi
fkluknav has quit [Ping timeout: 255 seconds]
victhor has joined #linux-sunxi
mzki has quit [Ping timeout: 240 seconds]
mzki has joined #linux-sunxi
BenG83 has quit [Ping timeout: 240 seconds]
leio has quit [Ping timeout: 240 seconds]
leio has joined #linux-sunxi
DullTube has quit [Quit: Leaving]
BenG83 has joined #linux-sunxi
cnxsoft has quit [Remote host closed the connection]
fkluknav has joined #linux-sunxi
<jelle>
I think I'll wait on the orange pi pc2 merge before I start on the nanopi a64 :P
tkaiser has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
reinforce has quit [Quit: Leaving.]
igraltis1 is now known as igraltist
nove has joined #linux-sunxi
BenG83 has quit [Ping timeout: 252 seconds]
msevwork has quit [Quit: Leaving]
leviathancn has quit [Remote host closed the connection]
iamfrankenstein has quit [Ping timeout: 240 seconds]
foxx has joined #linux-sunxi
chlorine has joined #linux-sunxi
foxx has quit [Read error: No route to host]
foxx has joined #linux-sunxi
jernej has joined #linux-sunxi
lkcl has quit [Ping timeout: 240 seconds]
foxx has quit [Ping timeout: 240 seconds]
fkluknav has quit [Ping timeout: 240 seconds]
yann|work has quit [Ping timeout: 252 seconds]
chlorine has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
chlorine has joined #linux-sunxi
BenG83 has joined #linux-sunxi
BenG83 has quit [Client Quit]
fkluknav has joined #linux-sunxi
yann|work has joined #linux-sunxi
ErwinH has quit [Remote host closed the connection]
reinforce has joined #linux-sunxi
chlorine has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<jernej>
MoeIcenowy: I found issue for DE2 on A64!
ErwinH has joined #linux-sunxi
<jernej>
MoeIcenowy: 24 bit in some syscon register (0x01c00004) must be cleared
IgorPec has joined #linux-sunxi
<jernej>
MoeIcenowy: BSP explanation of register is: "set sram for vedio use, default is boot use"
<jernej>
actually, explanation of clearing that bit
<jernej>
apritzel: do you know anything of above register? Should I make a patch for mainline U-Boot? Allwinner cleared this bit in board_init() function
ErwinH has quit [Ping timeout: 240 seconds]
<CuteIcenowy>
jernej: THANKS!
<CuteIcenowy>
jernej: as it's only DE-related, clear it in sunxi_composer_init it enough
<jernej>
well, in the end, it was just one bit
<CuteIcenowy>
magic bit ;-)
<CuteIcenowy>
I discovered many magic bits since I started mainline sunxi development ;-)
<CuteIcenowy>
and maybe we can find it more easily if they didn't have the typo of vedio ;-)
<jernej>
do you know what "vedio" means?
<jernej>
ah, video :)
<CuteIcenowy>
It's the kind of allwinner typo ;-)
<CuteIcenowy>
like "eraly jump fel" ;-)
Gerwin_J has quit [Quit: Gerwin_J]
<CuteIcenowy>
(eraly jump fel is a log text in boot0
CuteIcenowy has quit [Quit: Leaving.]
<MoeIcenowy>
ok my ZNC is back ;-)
fkluknav has quit [Ping timeout: 240 seconds]
ErwinH has joined #linux-sunxi
<MoeIcenowy>
my ccu-sun8i-r40 passed compilation ;-)
<jernej>
MoeIcenowy: Now, instead of asking for DE2 issue, you could ask for full A64 syscon description :)
<MoeIcenowy>
oh it's Feb 17 now
<jernej>
still 16 for me :)
<MoeIcenowy>
I haven't closed the problems page
ErwinH has quit [Ping timeout: 256 seconds]
<MoeIcenowy>
P.S. I remembered when I made sunxi-cedrus work on A33
<MoeIcenowy>
it's also a syscon magic bit ;-)
<jernej>
so syscon description would be very useful
BenG83_PB has joined #linux-sunxi
<MoeIcenowy>
in former SoCs (A33-) there's syscon description
<beeble>
on other cpus it will be the second after spi0
<jelle>
beeble: no h3 there
nove has quit [Ping timeout: 240 seconds]
<beeble>
but there are no bootsel pins on h3 as on the a64. so it will probe all the interface in some order
f0xx has quit [Ping timeout: 260 seconds]
<beeble>
as long as there are no fuses set
nove has joined #linux-sunxi
<jelle>
hmm some order
<beeble>
take the sd card out if you want to be sure to boot from emmc :)
<jelle>
ah ok
LargePrime has quit [Ping timeout: 240 seconds]
<beeble>
same 8k offset
<beeble>
to but the spl
<beeble>
put
<jelle>
thanks
<beeble>
ah and with mainline dts the mmcblk will be reorderd depending on if there is a sd card plugged in or not
<beeble>
so keep that in mind for bootargs
premoboss has quit [Ping timeout: 260 seconds]
<jelle>
beeble: thanks, going to try bluetooth first
apritzel has joined #linux-sunxi
LargePrime has joined #linux-sunxi
Andy-D has joined #linux-sunxi
<beeble>
apritzel: do you have already a uboot/atf branch where you can send axp requests for read/write?
<beeble>
apritzel: interactive, if not no problem. i will implement it myself. just don't want to do duplicated work
nikre has quit [Quit: Leaving]
<beeble>
apritzel: nvm. was less wirk then i thougt
<apritzel>
beeble: what for, exactly?
Andy-D has quit [Ping timeout: 240 seconds]
LargePrime has quit [Ping timeout: 258 seconds]
<apritzel>
I have some SCPI framework in ATF, which can be easily connected to a SCPI regulator or power domain
<beeble>
apritzel: have to debug IPS from second stage uboot. so i have to read and write random registers. but found how to implement that with scpi and services/std_svc/std_svc_setup.c
<beeble>
that can be done easily with what you already provide
premoboss has joined #linux-sunxi
LargePrime has joined #linux-sunxi
cptG has joined #linux-sunxi
cptG_ has quit [Ping timeout: 240 seconds]
<apritzel>
beeble: well, if it's just for debugging: I used my peekpoke tool from Linux for that, using RSB is easy with just a simple sequence of MMIO commands
<beeble>
apritzel: i now have smc axp reg. since my teating results in a lot of reboots i prefer to do it in uboot to reduce turnaround times
<BenG83_PB>
I will probably do something similar...
<BenG83_PB>
Pinebook charges really slow sometimes
<apritzel>
beeble: I think there is some stub rsb command in U-Boot already
<BenG83_PB>
need to play a bit with register settings
<apritzel>
if not then I quickly hacked, can't remember anymore ;-)
<beeble>
apritzel: i'm already finished :)
<MoeIcenowy>
wens: I have already locally get R40's MMC to work ;-)
Andy-D has joined #linux-sunxi
LargePrime has quit [Ping timeout: 252 seconds]
<willmore>
BenG83_PB, is the power setup on the PineBook anything like the Pine64 with a battery attached?
<BenG83_PB>
PB has a 10Ah LiPo
<BenG83_PB>
but as always, no one changed the battery parameters in the dts
<BenG83_PB>
just trying to tweak things a bit
<BenG83_PB>
aside from the sizes, battery setup is the same
<BenG83_PB>
trying to figure out how I can dynamically adjust the charge current
<BenG83_PB>
instead of the fixed limit
<willmore>
BenG83_PB, wonderful. I hope you're documenting what you learn. :)
<BenG83_PB>
well I am mostly a hardware guy so I know what I want to do
<BenG83_PB>
just not how to integrate this with Linux
<BenG83_PB>
and the different parts like the ATF, AR100 etc
<apritzel>
the question is why Linux should be involved in it in the first place?
<willmore>
It's a pretty deep rabbit hole. ;)
<BenG83_PB>
it would be much easier if I could just talk to the AXP directly
<BenG83_PB>
I want to charge the battery with 3A if the PB is off
<BenG83_PB>
and adapt charge current to load if the PB is on
<BenG83_PB>
atm is just has a fixed limit of 1200mA
<BenG83_PB>
since that is the AXP default
<apritzel>
so why would you want to do it in Linux?
<BenG83_PB>
under load, the battery almost discharges
<willmore>
There's no way to tell the AXP that the input current has a limit and let it do the work?
<apritzel>
I consider this a firmware things
<apritzel>
in the end this is what real laptops (TM) do
<BenG83_PB>
if it can be done in ATF I am good with that
<BenG83_PB>
there are limit for BAT, DC, USB rails
<willmore>
It's generally easier to debug processes in a full OS and then later commit them to firmware.
<BenG83_PB>
and some budgeting functions
<apritzel>
whether it's ATF or the arisc is actually an implementation detail
<BenG83_PB>
the way mainline will do it is without arisc, right?
<apritzel>
I don't know how we will do this
<apritzel>
so far we don't have anything on the arisc
<apritzel>
because we don't need anything there
<apritzel>
and it's just additional churn
<apritzel>
if battery charging requires constant hand holding, that looks like a task for the arisc
<BenG83_PB>
I would start with making a model
<BenG83_PB>
how charging should work in different states
<BenG83_PB>
and then see how to implement it with what the AXP can do
<BenG83_PB>
based on a power input budget
<BenG83_PB>
and some state info from the OS
<willmore>
BenG83_PB, what's the power supply on the PB?
<BenG83_PB>
there is a hard input limit of 3A
<willmore>
Due to?
<BenG83_PB>
input regulator
<BenG83_PB>
has programmable cut off
<BenG83_PB>
according to the schematic
<BenG83_PB>
its set to 3A
<BenG83_PB>
the AXP can do 4A max iirc
<willmore>
Let me try again. What is the physical supply of power for the PB and how does it mechanically connect to the PB?
<willmore>
Some kind of power brick? With a barrel connector?
<BenG83_PB>
barrel connector
<willmore>
Okay, so there is no signaling with the power supply a la USB-PD.
<BenG83_PB>
no
<willmore>
So you're designing this assuming a power supply that can handle the full limit of your power input circuitry which is 3A?
<BenG83_PB>
yes
* willmore
is just trying not to make assumptions
<BenG83_PB>
I think they went a bit on the low side with 3A
<willmore>
Agreed. If you put a 10Ah pack in it, 3A is quite low.
LargePrime has joined #linux-sunxi
<BenG83_PB>
if I consider what I know from my Pine boards
<willmore>
Is it just a 1S lithium pack?
<BenG83_PB>
plus the LCD and backlight
<BenG83_PB>
the battery is 1S2P
<BenG83_PB>
10Ah
<willmore>
So, two 5A Li-po slabs?
<BenG83_PB>
yes
<willmore>
Yeah, 3A is tiny.
<BenG83_PB>
i was thinking about adding some custom charging circuirty ;)
<willmore>
But, if the power handler chip can only do 4A, it's not that much worse.
<BenG83_PB>
yeah
<willmore>
Are you with Olimex?
<BenG83_PB>
no just a Pine user
<willmore>
Okay.
<BenG83_PB>
i got a PB prototype during FOSDEM from Tl
<willmore>
Wonderbar.
<BenG83_PB>
currently trying to get some Linux running
<BenG83_PB>
and fixing some laptop related things
<willmore>
You're got your work cut out for you.
<BenG83_PB>
I think it would already help if one would set the full charge current in the AXP on shutdown
<BenG83_PB>
so it doesnt take like 10h to charge the battery
<willmore>
I would have hoped that you could just tell the AXP the input power limit and the battery power limit and just walk away and let it do what needs done.
<beeble>
it's not a lot more than that
<BenG83_PB>
I think it can reduce battery charge current if the PS rail needs to much power
<beeble>
just a bit to decicde the running state and deciding on the ACIN available bit
<BenG83_PB>
need to read the AXP datasheet again
<beeble>
there should pretty much everything already available in ATF and SCPI enabled mainline
<beeble>
with 3.10 bsp you would have the arisc inbetween
<BenG83_PB>
we spent a lot of time at work designing power managment around MCUs (mostly CortexM) for mobile devices, so I have some experience on the hardware side
<BenG83_PB>
we usually dont do much with Linux based embedded systems so I learn a lot atm ;)
<BenG83_PB>
yeah I am using longsleeps 3.10 BSP kernel atm
<BenG83_PB>
mostly because I need a display driver to use the PB
<apritzel>
beeble: yeah, the Allwinner design is really convoluted, and I fail to see the reason for that: Linux calls ATF via an smc call, which in turn uses the mailbox to communicate with the arisc, which then writes the value into the AXP
<apritzel>
I would understand that if there would be some kind of abstraction, but it's really AXP address and value pairs passed on
<BenG83_PB>
can the arisc access periperals?
<apritzel>
yes
<apritzel>
except the GIC (the ARM interrupt controller)
<apritzel>
which is an architectural limitation
<BenG83_PB>
so you could do all sorts of interesting things in a ultra low power state...
<apritzel>
yes
<apritzel>
that's the idea, I guess
<apritzel>
you could even snoop the Ethernet or Wifi
<beeble>
apritzel: the only thing i can think of is that you can still use the arisc stand alone without any of the arm cores running. and just using the atf because you expect them to have it on arm :)
<beeble>
*arm64
<apritzel>
beeble: yes, I am afraid so as well ;-)
<apritzel>
it would be much smarter to just call from Linux into the arisc with the mailbox, and then use some kind of abstracting, probably standardised protocol
<apritzel>
yes, SCPI is not perfect, but it's the only standardised interface for that purpose I know of
tsuggs has joined #linux-sunxi
solarnetone has quit [Ping timeout: 240 seconds]
lemonzest has quit [Quit: Leaving]
BenG83_PB has quit [Quit: Leaving]
BenG83_PB has joined #linux-sunxi
Ntemis has quit [Remote host closed the connection]
IgorPec has quit [Ping timeout: 240 seconds]
<lurchi_>
Is anyone working on audio support for the Pine64/A64?
<apritzel>
lurchi_: I think I saw some success reports already here in the last few days
<apritzel>
lurchi_: check the wiki
<lurchi_>
apritzel: According to the matrix, H3 is supported currently, A64 is not