<MoeIcenowy>
very very sample -- even CPUX shutdown is not properly implemented now, only system reset implemented
Putti has joined #linux-sunxi
nove has joined #linux-sunxi
The_Loko has joined #linux-sunxi
<KotCzarny>
huh, so much code for a simple function
<MoeIcenowy>
KotCzarny: yes ;-)
<MoeIcenowy>
most of the code is still derived from megous's work
perr has quit [Quit: Leaving]
JohnDoe_71Rus has joined #linux-sunxi
enrico__ has quit [Quit: Bye]
enrico__ has joined #linux-sunxi
wzyy2 has quit [Read error: Connection timed out]
wzyy2 has joined #linux-sunxi
f0xx has joined #linux-sunxi
lkcl has quit [Ping timeout: 240 seconds]
<enrico__>
diego_r: yes
<MoeIcenowy>
oh so strange... if I deassert the reset line of arisc under Linux it will soon be re-asserted automatically
<MoeIcenowy>
and the code for arisc is not really executed
<MoeIcenowy>
(My deassertion is not done by using devmem2...
<dgp>
MoeIcenowy: do you have plans to implement something that could do deep sleep?
<MoeIcenowy>
currently not so deep ;-)
reinforce has quit [Quit: Leaving.]
* dgp
thinks wake on wifi would be cool.. :)
<KotCzarny>
huh
<MoeIcenowy>
but if I do the deassertion by sunxi-fel the CPUs code can be executed successfully
<KotCzarny>
would require lots of code
<KotCzarny>
or smart idea
<dgp>
KotCzarny: for wake on wifi?
<MoeIcenowy>
for wake on anything ;-)
<KotCzarny>
unless one could load some custom payload on beacons or other unencrypted packets
jbrown has quit [Quit: Leaving]
<dgp>
KotCzarny: most wifi chips support templates that you configure so they automatically reply to stuff without the host doing anything
<KotCzarny>
dgp, also, remember that most cheap realteks load some 1-2MB blob in driver
<KotCzarny>
and for risc cpu you have.. 32kB\
<KotCzarny>
and normal ram is 50-100x slower than usual
<dgp>
KotCzarny: but you don't need that on the arisc. All the arisc needs to do is listen for the wake up interrupt when the wifi chip says there is data queued and wake the real host
<KotCzarny>
yes, but still, wifi is usb usually
<KotCzarny>
we dont have usb driver in arisc
<dgp>
KotCzarny: I'm thinking more of SDIO connected chips
<dgp>
which low power hosts are going to be using
techping has quit [Remote host closed the connection]
fkluknav has quit [Ping timeout: 268 seconds]
<MoeIcenowy>
wens: how could we update U-Boot PSCI version to 1.0?
<MoeIcenowy>
do we need to implement all functions for PSCI 1.0 to add support for it?
f0xx has quit [Ping timeout: 260 seconds]
leviathancn has joined #linux-sunxi
fkluknav has joined #linux-sunxi
<MoeIcenowy>
oh there's a default implementation (return -1)
<MoeIcenowy>
ok did a simple implementation
<diego_r>
enrico__: ciao :-) I'm the one who opened the Lime2 eMMC pull request. If you have any question I'm here
lemonzest has quit [Quit: Leaving]
reinforce has joined #linux-sunxi
lkcl has joined #linux-sunxi
leviathancn has quit [Ping timeout: 240 seconds]
<wens>
MoeIcenowy: all _required_ functions
fkluknav has quit [Ping timeout: 240 seconds]
popolon has quit [Ping timeout: 252 seconds]
popolon has joined #linux-sunxi
<KotCzarny>
wouldnt it be nice if someone implemented some arduino like os for arisc?
<KotCzarny>
that way those boards could be cheap a** alternative with high performance piggy backed
wzyy2 has quit [Ping timeout: 268 seconds]
victhor_ has joined #linux-sunxi
victhor_ is now known as victhor
fkluknav has joined #linux-sunxi
dh1tw has quit [Ping timeout: 240 seconds]
<MoeIcenowy>
wens: which are required?
dh1tw has joined #linux-sunxi
<dgp>
KotCzarny: arduino is just GCC + some libraries
<dgp>
I think getting FreeRTOS running on it would be good though. Would make adding functionality to it easier
Andy-D has joined #linux-sunxi
chlorine has quit []
<KotCzarny>
someone could measure power draw with running only arisc?
<wens>
MoeIcenowy: check the PSCI standard
<wens>
reset and power off are required though... very problematic
<KotCzarny>
i thinks thats the two things she is going to implement
<beeble>
KotCzarny: 25mW on a31 with 1gb dram in self refresh and 32khz clock
<KotCzarny>
hum, still a lot
<KotCzarny>
and with dram turned off?
<beeble>
don't know, couldn't find the number on my harddisk
<wens>
KotCzarny: power off means talking to the PMIC in most cases
<wens>
i guess it's possible to implement some bare bone RSB driver that just assumes the pmic is already initialized
<KotCzarny>
wens, we have to fake the 'power off', otherwise we cant turn board on again without power cycle?
<wens>
since the power off bit is the same across all the variants
<wens>
KotCzarny: i'm talking about the generic case, the ones with PMICs
<beeble>
i probably measured it, but the dram self refresh numbers had been more important
<wens>
KotCzarny: and you can't do PSCI with the openrisc core
<MoeIcenowy>
wens: we can only implement PSCi 1.0 for H3
dave0x6d has joined #linux-sunxi
<wens>
you mean implement it just/only for the H3
<MoeIcenowy>
yes
<wens>
yeah i suppose that works
<MoeIcenowy>
I have already done an implementation
<MoeIcenowy>
poweroff: which try to de-assert ARISC, if failed, then force shutdown core 1~3, then core 0 do a infinite WFI
<wens>
have a power off function in u-boot psci that brings up the openrisc core and then busy loops itself
<MoeIcenowy>
and reset of course uses wdt ;-)
<wens>
you don't have to check if it failed or not
<MoeIcenowy>
yes no check needed
<wens>
just load code, de-assert, then wfi loop
<BenG83>
moin moin
<MoeIcenowy>
but I think we cannot load code in PSCI zone...
<wens>
openrisc just comes in and turns everything off
<MoeIcenowy>
we need other functionality to load arisc firmware
<wens>
hehe, that's the problem :)
<wens>
you can't tell the kernel to do it either
<MoeIcenowy>
one way is SPL FIT ;-)
<wens>
for all we know, the kernel may have something else running on the openrisc core that you will disrupt
matthias_bgg has quit [Quit: Leaving]
<MoeIcenowy>
oh yes...
<MoeIcenowy>
maybe we should do this in kernel side?
<MoeIcenowy>
make an ar100-poweroff driver?
<wens>
then you can't use psci
<MoeIcenowy>
but all poweroff drivers will be overrided by psci
<MoeIcenowy>
so we should keep use psci 0.1 here and even cannot update to 0.2/1.0
<wens>
in any case, loads of possible conflicts
<MoeIcenowy>
yes
<wens>
it's been this case for a long time, since we're not doing reset/poweroff in psci
<wens>
i think a while back hansg had asked about it
<MoeIcenowy>
now I think having an ATF is pretty cleaner ;-)
<wens>
(a year or two ago)
<wens>
yeah, and then you have ATF and the kernel fighting over resources
<wens>
clocks, peripherals, you name it
BenG83 has quit [Quit: Leaving]
diego_r has quit [Ping timeout: 260 seconds]
<MoeIcenowy>
the most clean way is make the ARM core co-processors ;-)
<MoeIcenowy>
see the BroadCom VideoCore MCUs with ARM co-processors used on RPis ;-)
<wens>
ha
<MoeIcenowy>
in this situation ARM core have no resources -- except the ones that are borroweded from VC4
miasma_ is now known as miasma
lennyraposo has quit [Quit: Leaving.]
massi has quit [Remote host closed the connection]
<KotCzarny>
maybe make resources in kernel configurable?
<KotCzarny>
ie. can be marked as disable/offloaded to arisc?
<KotCzarny>
or make 'arisc' driver that will negotiate what it can grab?
enrico__ has quit [Quit: Bye]
BenG83 has joined #linux-sunxi
<MoeIcenowy>
the pin controller is a big problem
<MoeIcenowy>
maybe we can do this -- assign all needed peripherals' pinctrl nodes to the arisc device tree node
<MoeIcenowy>
P.S. I think we should create a ARISC firmware format, which has a file header at 0x4000 position (the SRAM A2 start)
<MoeIcenowy>
the SRAM A2 start seen from AR100
<MoeIcenowy>
and I now think to divide AR100 firmware to 3 classes -- shutdown firmware, suspend firmware, offload firmware
<KotCzarny>
or just make one proper?
<KotCzarny>
otherwise you could be duplicating code
<KotCzarny>
which isnt good
<MoeIcenowy>
I think many people want to make their own offload firmwares ;-)
<KotCzarny>
want - yes, have time/skills - nope ;)
<MoeIcenowy>
maybe we should first make a barebone then make some firmwares based on the barebones
jernej has joined #linux-sunxi
urpablo has joined #linux-sunxi
<urpablo>
Hola buenas tardes. Busco ayuda con una implementación en orange pi
<TheLinuxBug>
Hola urpablo, ¿hablas inglés, hablamos principalmente inglés en este canal.
<urpablo>
Hemos seguido los tutoriales para poder rotar la pantalla de una orange pi, pero no conseguimos que rote todo el contenido (una ventana que despliega un video).
<TheLinuxBug>
urpablo: Si bien es posible utilizar una herramienta de traducción, obtendrá mucho más ayuda aquí si puede comunicarse en inglés
<TheLinuxBug>
urpablo: tal vez usted puede traducir antes de preguntar y entonces podemos tratar de responder a su pregunta para usted si usted no es fluido en inglés
<urpablo>
ok. I want for help in a implementation of sunxi on orange pi. We followed the tutorials to be able to rotate the screen of an orange pi, but we did not get it to rotate all the content (a window that displays a video).
<MoeIcenowy>
is the video played via libvdpau-sunxi?
<urpablo>
Yes
<MoeIcenowy>
thus it cannot rotate.
<TheLinuxBug>
urpablo: I think MoeIcenowy is saying it is a limitation of the hardware gpu accell that it can not rotate, to get rotation you would likely need software decoding/playback.
<MoeIcenowy>
yes
<MoeIcenowy>
as the libvdpau-sunxi driver directly writes to the disp module
<KotCzarny>
what's sunxi?
<TheLinuxBug>
urpablo: Creo que MoeIcenowy está diciendo que es una limitación de la accell gpu hardware que no puede girar, para obtener la rotación es probable que necesite decodificación de software / reproducción como el driver libvdpau-sunxi escribe directamente en el módulo disp
fkluknav has quit [Ping timeout: 260 seconds]
<TheLinuxBug>
KotCzarny: lol
<urpablo>
I tried to compile the kernel as a native rotation
<urpablo>
But we did not get the compilation because it did not generate us correctly the uboot
<TheLinuxBug>
urpablo: you will need to compile u-boot seperatly from kernel, they are two different things
<TheLinuxBug>
and in most case as long as you place kernel back in same boot volume to replace existing you shouldn't need new uboot
<urpablo>
You mean a cross build?
<KotCzarny>
unless you run old smelly unconfigurable uboot
<TheLinuxBug>
Urpablo: se puede encontrar información acerca de u-boot http://linux-sunxi.org/U-Boot se compila separada del kernel, sin embargo, si está utilizando una imagen común, puede montar la primera partición en la tarjeta y Reemplazar el kernel existente sin nuevo u-boot, depende de la imagen que está utilizando.
<MoeIcenowy>
P.S. there's no native rotation
<TheLinuxBug>
MoeIcenowy: just curious, how does Android accomplish rotation then?
<MoeIcenowy>
Mali
<TheLinuxBug>
ahh I see
<MoeIcenowy>
but to use this for rotation under X we will need lima
fl__0 has joined #linux-sunxi
<KotCzarny>
or just opengl based window manager
<urpablo>
Ok, we run a smelly uboot, but it's configurable. Actually we're compiling a new image under version 4.9, according to what they indicate should not have problems given that it is a clean image.
<KotCzarny>
huh, he should check mainline_uboot page
<TheLinuxBug>
hehehe
<KotCzarny>
there should be big red redirect
<TheLinuxBug>
he will be back im sure
<KotCzarny>
;)
<nove>
is not a hardware limitation, but about software integration which can only be made adequately by having *proper* drivers
Gerwin_J has quit [Quit: Gerwin_J]
<nove>
rotation, as was said can be done by the gpu (the lazy way)
<nove>
but the correct way would be to use the display engine, G2D or the transform engine, or whatever
<nove>
or whatever that can do rotation
fkluknav has joined #linux-sunxi
f0xx has joined #linux-sunxi
xes has quit [Quit: WeeChat 1.6]
<victhor>
I'm having a problem configuring UART1 in ports PD10 and PD11 on a A33 q8 tablet board. I have configured the ports on the dts file, but UART1 doesn't work, and I can still export PD10 and PD11 as gpios, instead of getting a busy error
<victhor>
I had asked this question here before, but I have had no progress so far...
<beeble>
iirc you will only get a busy error if the pin is used as a gpio in linux (for example gpio controlled regulator)
simosx has quit [Quit: Yakkety Bye!]
\\Mr_C\\ has quit [Quit: .]
lkcl has quit [Ping timeout: 260 seconds]
JohnDoe0 has joined #linux-sunxi
JohnDoe_71Rus has quit [Ping timeout: 255 seconds]
lkcl has joined #linux-sunxi
f0xx has quit [Ping timeout: 240 seconds]
terra854 has quit [Quit: Connection closed for inactivity]