lucascastro has quit [Remote host closed the connection]
TheSeven has quit [Ping timeout: 240 seconds]
IgorPec has joined #linux-sunxi
TheSeven has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
TheSeven has quit [Ping timeout: 252 seconds]
iamfrankenstein has quit [Ping timeout: 240 seconds]
TheSeven has joined #linux-sunxi
TheSeven has quit [Ping timeout: 252 seconds]
[7] has joined #linux-sunxi
reinforce has joined #linux-sunxi
fkluknav has joined #linux-sunxi
<jernej>
Net147: No need for such drastic measures. U-Boot correctly displays image, so I just need to fix clocks.
leviathan has joined #linux-sunxi
f0xx has joined #linux-sunxi
leviathan has quit [Remote host closed the connection]
leviathan has joined #linux-sunxi
iamfrankenstein has joined #linux-sunxi
iamfrankenstein has quit [Client Quit]
iamfrankenstein has joined #linux-sunxi
IgorPec has quit [Ping timeout: 240 seconds]
fkluknav has quit [Ping timeout: 252 seconds]
kloczek has quit [Quit: kloczek]
kloczek has joined #linux-sunxi
Mr__Anderson has joined #linux-sunxi
merbanan has quit [Ping timeout: 252 seconds]
kloczek has quit [Quit: kloczek]
IgorPec has joined #linux-sunxi
merbanan has joined #linux-sunxi
kloczek has joined #linux-sunxi
hardfalcon1 has quit [Ping timeout: 248 seconds]
<mripard>
jernej: that's definitely true (check the clocks first)
nuuuciano__ has quit [Ping timeout: 268 seconds]
nuuuciano__ has joined #linux-sunxi
xcko has joined #linux-sunxi
chomwitt has joined #linux-sunxi
sr-digitronic has joined #linux-sunxi
tom_nov has joined #linux-sunxi
clemens3 has joined #linux-sunxi
fkluknav has joined #linux-sunxi
hardfalcon has joined #linux-sunxi
<wens>
embed-3d: you could send a ping by replying to your patches
BroderTuck has joined #linux-sunxi
xcko has quit [Ping timeout: 256 seconds]
clemens3 has quit [Ping timeout: 248 seconds]
aballier has quit [Ping timeout: 240 seconds]
clemens3_ has joined #linux-sunxi
dlan_ has joined #linux-sunxi
clemens3_ has quit [Quit: WeeChat 1.0.1]
clemens3 has joined #linux-sunxi
aballier has joined #linux-sunxi
aballier has joined #linux-sunxi
clemens3 has quit [Client Quit]
yann has joined #linux-sunxi
clemens3 has joined #linux-sunxi
tl_lim has quit [Ping timeout: 245 seconds]
tl_lim has joined #linux-sunxi
cnxsoft has quit [Read error: Connection reset by peer]
msimpson has joined #linux-sunxi
aballier has quit [Ping timeout: 240 seconds]
cnxsoft has joined #linux-sunxi
<wens>
mripard: I think Linus missed your followup fix for gpiolib-of
<wens>
mripard: the pull request he just sent out is the original version
BenG83 has quit [Ping timeout: 240 seconds]
<mripard>
yes, I've seen
aballier has joined #linux-sunxi
matthias_bgg has joined #linux-sunxi
<mripard>
maz: what happens when you try to set CNTVOFF from non-secure ?
<mripard>
is that just ignored?
pgreco has joined #linux-sunxi
BroderTuck_ has joined #linux-sunxi
<maz>
mripard: you get an UNDEF.
<maz>
mripard: assuming you mean from non-secure PL1.
<maz>
mripard: PL2 *is* non-secure.
tl_lim has quit [Read error: Connection reset by peer]
hardfalcon has quit [Ping timeout: 245 seconds]
BroderTuck has quit [Ping timeout: 268 seconds]
fkluknav has quit [Ping timeout: 256 seconds]
<mripard>
I meant either PL1 or PL2
<mripard>
but I guess that would be UNDEF in both cases
matthias_bgg has quit [Remote host closed the connection]
fkluknav has joined #linux-sunxi
victhor has joined #linux-sunxi
<maz>
mripard: no. PL2 is in control of CNTVOFF, by the very definition of what it does.
<maz>
mripard: Monitor mode can change it as well by virtue of being more privileged than PL2, but that's about it.
<mripard>
ah, right
paulk-gagarine-s has quit [Quit: Leaving]
<maz>
mripard: so if you're booted in S-PL1, to can switch to MON and whack CNTVOFF to zero.
<maz>
mripard: if you#re booted in NS-PL1, you're screwed.
matthias_bgg has joined #linux-sunxi
hardfalcon has joined #linux-sunxi
mhlavink has joined #linux-sunxi
DullTube has joined #linux-sunxi
fkluknav has quit [Ping timeout: 240 seconds]
merbanan has quit [Ping timeout: 245 seconds]
merbanan has joined #linux-sunxi
return0e has quit [Read error: No route to host]
return0e has joined #linux-sunxi
afaerber has quit [Quit: Leaving]
afaerber has joined #linux-sunxi
<embed-3d>
wens: Sorry! Looks like I missed something. I'm very busy right now with some private stuff that makes it difficult for me to keep track of everything. I plan to send out a new version of the AC100 bug today.
maz has quit [Quit: Leaving]
fkluknav has joined #linux-sunxi
ernestask has joined #linux-sunxi
fkluknav has quit [Ping timeout: 256 seconds]
hanni76 has joined #linux-sunxi
dave0x6d has joined #linux-sunxi
kaspter has quit [Remote host closed the connection]
kaspter has joined #linux-sunxi
BroderTuck_ is now known as BroderTuck
pgreco has quit [Ping timeout: 245 seconds]
<Strontium>
So i was thinking about a simple demo for the AR100 core in the H3, to generate up to 20 PWM servo pulses in realtime. But then i considered, to do that, i need to write the GPIO registers, which is fine, except its a read/modify/write cycle to set the GPIO
<Strontium>
so if the AR100 accesses the GPIO and the Arm cores also access the same registers corruption will result.
<Strontium>
so there would need to be some kind of control to prevent contention. the hardware spinlock seems like an appropriate mechanism, but can we reserve one for the AR100? How would that work?
<KotCzarny>
you will have to write it yourself, or just use common sense
<KotCzarny>
there are hw spinlocks in the socs, accessible by both arm and arisc
<Strontium>
KotCzarny: of course i need to write it myself, i was just wondering if its been considered. Yes i know and a linux driver exposes them to the kernel.
<Strontium>
But for the AR100 to use it, it would need to know which one/ones are the appropriate ones to use.
<KotCzarny>
for now arisc is uncharted are regarding mainline kernel devel
<KotCzarny>
*area
<Strontium>
I understand, i am just discussing it, not looking for answers "per se".
<KotCzarny>
which gives you the chance to design and write it
<KotCzarny>
just leave a note on status page that you are doing it
<KotCzarny>
also, i think smaeul started work on hw msg box, which is also required for arm/arisc synchro
<Strontium>
I was thinking, a very simple way is just to reserve one hardware spinlock for AR100 to core usage. Then if its useful to the AR100, just use that spinlock before accessing those registers. And we just document whats safe, whats not.
<Strontium>
The GPIO status register is one. Read obviously doesn't need protection, but write does.
<Strontium>
I think its better for AR100, to do as much setup on the Arm side, so your not wasting code space on the AR100.
<Strontium>
which limits the amount of protection one needs.
<mripard>
Strontium: and if you start using the spinlocks, you should reconsider your realtime requirement
<Strontium>
mripard: agreed, it will add jitter.
<Strontium>
i just wonder how else one can toggle the gpio successfully, without risking corruption.
<KotCzarny>
maybe you can offload all gpio toggling to arisc exclusively?
<Strontium>
for a pwm servo, the jitter would be tollerable, because you would only spinlock protect the actual register write to set the state of the GPIO. the chance of hitting it would be exceptionally low.
<Strontium>
KotCzarny: Can, but that would require a change to the linux driver to send messages to the AR100 code. i was thinking of (for now) a simple mechanism to let people put arbitrary code in the AR100, and have a few simple rules to make it kind of safe, with minimal support from arm side.
<Strontium>
obviously if your writing code for the AR100 you are not a typical wiringpi user.
hardfalcon has quit [Quit: Leaving.]
hardfalcon has joined #linux-sunxi
pgreco has joined #linux-sunxi
<willmore>
CPUS is allwinner speak for the AR100, right?
<KotCzarny>
yes
<KotCzarny>
and arm is CPUX
hardfalcon has quit [Ping timeout: 256 seconds]
megi has joined #linux-sunxi
<willmore>
Thanks. Wow, the GPIO on the Allwinner chips (H5 datasheet at the moment) is super primitive.
<willmore>
No bit set/clear registers. No separate read/write ports...
<willmore>
Only one data port address.
<BroderTuck>
I collected everything from my h3 hdmi experiment yesterday and put it at www.palvencia.se/H3 hope I managed to catch everything
maz_ has joined #linux-sunxi
hardfalcon has joined #linux-sunxi
hipboi has quit [Quit: This computer has gone to sleep]
cnxsoft has quit [Quit: cnxsoft]
<Strontium>
willmore: yup, bit set/clear/toggle registers would be nice. But alas, no such luck.
<willmore>
Strontium, this is like being back in the 90's before uC designers realized how important that kind of stuff was. Someone email an STM32 datasheet to Allwinner. :)
<KotCzarny>
so, stm32 on every allwinner board? :>
<Strontium>
KotCzarny: i think he just means that all the tiny mcu's have good GPIO registers now, its not like they haven't got plenty of stuff to copy from.
<willmore>
KotCzarny, no! If we wanted that we'd send that data sheet to the board makers.:)
<willmore>
Strontium is correct.
maz_ is now known as maz
<KotCzarny>
:)
<willmore>
KotCzarny, get a copy of en.CD00171190.pdf. Take a look at sections 9.2 and 3.3.2
<pmpp>
lol
<willmore>
You can address *one* location in memory and set a bit and access another to clear it. No locking necessary between processes touching that whole port the bits are in.
<pmpp>
"bit banding"
<willmore>
It's a funny name.
<Strontium>
atmel does a similar thing.
<Strontium>
now microchip.
<willmore>
Strontium, yes, most uC makers do these days.
<willmore>
I just had that datasheet handy.
[7] has quit [Ping timeout: 252 seconds]
<Strontium>
even just a register that write a 1 to set, and another thats write a 1 to clear. is better than Read/Modify/Write cycles. But maybe Allwinner does have this functionality, and its a secret so they can't tell anyone they have it, in case a competitor copies it.
TheSeven has joined #linux-sunxi
<willmore>
Strontium, but it's already standard in the industry. ;)
<Strontium>
willmore: since when has that stopped chinese chip makers from not wanting to document their chips?
<willmore>
Most of the obfuscation in Allwinner datasheets is there to hide where they got the IP.
<willmore>
Strontium, point.
<willmore>
And, they're not the only ones who do that. It's prevasive.
<willmore>
pervasive.
<willmore>
Any, too far OT, keep up the good work, Strontium.
<Strontium>
willmore: busy designing retaining walls now. hopefully will get back to computer stuff later.
lemonzest has joined #linux-sunxi
<willmore>
Can't program if the walls are falling down around you. :)
DullTube has quit [Quit: Leaving]
afaerber has quit [Ping timeout: 245 seconds]
BenG83 has joined #linux-sunxi
matthias_bgg has quit [Ping timeout: 240 seconds]
afaerber has joined #linux-sunxi
matthias_bgg has joined #linux-sunxi
dave0x6d has quit [Quit: Connection closed for inactivity]
dddddd has joined #linux-sunxi
BroderTuck has quit [Quit: Heading home]
sunshavi has joined #linux-sunxi
JohnDoe6 has joined #linux-sunxi
SP7RT has joined #linux-sunxi
reinforce has quit [Quit: Leaving.]
xerpi has joined #linux-sunxi
xerpi has quit [Read error: Connection reset by peer]
xerpi has joined #linux-sunxi
afaerber has quit [Ping timeout: 245 seconds]
tlwoerner has joined #linux-sunxi
tlwoerner has joined #linux-sunxi
tlwoerner has quit [Changing host]
afaerber has joined #linux-sunxi
merbanan has quit [Ping timeout: 252 seconds]
merbanan has joined #linux-sunxi
maz has quit [Quit: Leaving]
kloczek has quit [Read error: Connection reset by peer]
kloczek has joined #linux-sunxi
zzeroo has quit [Ping timeout: 256 seconds]
maz has joined #linux-sunxi
reinforce has joined #linux-sunxi
zzeroo has joined #linux-sunxi
rwmjones|AFK is now known as rwmjones
SP7RT has quit [Ping timeout: 245 seconds]
dave0x6d has joined #linux-sunxi
tllim has joined #linux-sunxi
<smaeul>
Strontium: if you can limit yourself to port L pins, you can control them exclusively from AR100
<smaeul>
everything that Linux uses port L and its connected devices for can be done on the AR100
<smaeul>
especially if your board doesn't have a PMIC, then practically none of that hardware is in use
<smaeul>
and even if it is, the GPIO pins generally aren't, so if you leave the Linux driver for R_PIO loaded, it will only touch the mode registers, not the data registers
<smaeul>
but the feasibility of that highly depends on how many pins you need
lkcl has joined #linux-sunxi
lucascastro has joined #linux-sunxi
lucascastro has quit [Remote host closed the connection]
fixmer has joined #linux-sunxi
fkluknav has joined #linux-sunxi
duracrisis has joined #linux-sunxi
msimpson has quit [Quit: Leaving]
yann has quit [Ping timeout: 245 seconds]
f0xx has quit [Ping timeout: 240 seconds]
fkluknav has quit [Ping timeout: 256 seconds]
aalm has quit [Ping timeout: 252 seconds]
lucascastro has joined #linux-sunxi
tl_lim has joined #linux-sunxi
tllim has quit [Ping timeout: 245 seconds]
kloczek has quit [Ping timeout: 240 seconds]
tom_nov has quit [Quit: Leaving]
kloczek has joined #linux-sunxi
focus has joined #linux-sunxi
aalm has joined #linux-sunxi
<BenG83>
will anyone be at embedded world during this week?
sr-digitronic has quit [Remote host closed the connection]
<ElBarto>
BenG83: can you confirm that the usb type a on the cluster board is connected to the otg port ? that's what it seems by looking at the schematics
yann has joined #linux-sunxi
<BenG83>
ElBarto, there is only a host and a OTG controller on A64
<BenG83>
the OTG is forced into host mode on regular Pine64
<ElBarto>
yes I know
<ElBarto>
but the type a plug seems to be connected on the otg lines and the micro (type C ? can't really see on the pics) to the host lines
xerpi has quit [Quit: Leaving]
<BenG83>
mmh I haven't checked that really, or used any of them so far
<ElBarto>
ok thanks
<BenG83>
USB0-Dx is connected to the regular A according to schematics
<BenG83>
USB1-Dx to the micro-USB
<ElBarto>
isn't usb0 the otg ?
<BenG83>
I mean the ID pins seems not connected so it doesn't really work like that anyways
<ElBarto>
we don't support the otg in FreeBSD for now and a another fbsd dev can't seems to have usb working
<ElBarto>
same in u-boot
<ElBarto>
so I wonder if it is the problem
<ElBarto>
so yeah usb0-DX is the otg port
<ElBarto>
by looking at the olinuxino schematics
<BenG83>
I would say so too according to the A64 UM
<BenG83>
it doesnt say it directly, but the pinout suggests it
<ElBarto>
that seems weird to connect a micro usb plug to a usb host ...
maz has quit [Ping timeout: 256 seconds]
<BenG83>
I guess it was a space issue :)
<ElBarto>
it's possible, but then it would have make more sense to exchange them
<BenG83>
I have some host wire adapters for phones that connect micr-a to A socket
<BenG83>
maybe they wanted to keep the USB A-to-A FEL cable
<ElBarto>
oh yeah I'm sure cable exists for that
<ElBarto>
A to A is not something that should exist iirc :)
<BenG83>
I only have one for my Allwinner and Rockchip devices
<BenG83>
although I had some harddisk enclosure somewhere in 2005 that had a USB A input socket for some reason
<ElBarto>
I was gonna ask which allwinner but yeah pine64* :)
<BenG83>
I'm all for making them all USB-C
<ElBarto>
isn't usb-c more than just a plug ? (in theory at least)
<ElBarto>
not that I would complain having usb-c port that aren't true usb-c host
<BenG83>
the minimal implementation is just a USB2.0 device port
<BenG83>
my phone has such a USB-C port
<BenG83>
but it's nice for the power handling capability
<BenG83>
and no more A/B sockets
<BenG83>
but it can get pretty complicated
<BenG83>
if you look at a RK3399 USB-C port with display port and power switching for OTG