<robogoat>
Anybody have hints about how to switch usb power on a pcduino3 nano?
gianMOD has quit [Ping timeout: 240 seconds]
<robogoat>
Yay, pin 98!
<robogoat>
With the schematic and the gpio computation on the wiki, amazingly easy to identify.
bisla has joined #linux-sunxi
_stephan has joined #linux-sunxi
gianMOD has joined #linux-sunxi
domidumont has joined #linux-sunxi
premoboss has quit [Remote host closed the connection]
gianMOD has quit [Ping timeout: 255 seconds]
domidumont has quit [Remote host closed the connection]
domidumont has joined #linux-sunxi
IgorPec has joined #linux-sunxi
bisla has quit [Quit: Page closed]
robogoat has quit [Ping timeout: 245 seconds]
HeHoPMaJIeH has joined #linux-sunxi
HeHoPMaJIeH has quit [Changing host]
HeHoPMaJIeH has joined #linux-sunxi
gianMOD has joined #linux-sunxi
robogoat has joined #linux-sunxi
naobsd has quit [Remote host closed the connection]
FlorianH has joined #linux-sunxi
gianMOD has quit [Ping timeout: 264 seconds]
FlorianH has quit [Ping timeout: 256 seconds]
FlorianH has joined #linux-sunxi
premoboss has joined #linux-sunxi
mmwolbrink has joined #linux-sunxi
gianMOD has joined #linux-sunxi
bfree has quit [Remote host closed the connection]
premoboss has quit [Ping timeout: 255 seconds]
premoboss has joined #linux-sunxi
<MoeIcenowy>
what' R_UART in A23/33 mainline kernel?
<MoeIcenowy>
what's
<plaes>
pl2, pl3
<MoeIcenowy>
pl2, pl3?
<plaes>
pins
<MoeIcenowy>
[s_uart0] section in script.fex?
<MoeIcenowy>
(so uart0 is not the main uart in a23/33?
<MoeIcenowy>
In addition, how to configure simplefb on a33 mainline kernel?
<plaes>
it depends on the device
<MoeIcenowy>
(LCD is working during uboot
<plaes>
ah.. r_uart is the uart used by RISC core in those SoC
<MoeIcenowy>
ah oh
<plaes>
but dunno how it really works, I don't have any A23/A33 machines
premoboss has quit [Ping timeout: 245 seconds]
premoboss has joined #linux-sunxi
gianMOD has quit [Remote host closed the connection]
Andy-D has quit [Remote host closed the connection]
reinforce has joined #linux-sunxi
Andy-D has joined #linux-sunxi
gianMOD has joined #linux-sunxi
<wens>
plaes: its just a standard uart, allocated to be used by the RISC core, as all other R_* peripherals
<wens>
but since the address space is shared, the main cpu can also use it
Ueno_Otoko has quit [Ping timeout: 255 seconds]
tomboy65 has quit [Read error: Connection reset by peer]
tomboy64 has joined #linux-sunxi
gianMOD has quit [Remote host closed the connection]
viccuad has joined #linux-sunxi
caog has joined #linux-sunxi
gianMOD has joined #linux-sunxi
gianMOD has quit [Remote host closed the connection]
gianMOD has joined #linux-sunxi
gianMOD has quit [Ping timeout: 264 seconds]
premoboss has quit [Ping timeout: 260 seconds]
premoboss has joined #linux-sunxi
enrico_ has joined #linux-sunxi
<KotCzarny>
hmm, funny, banana pi doesnt have li-ion connector
kz1 has joined #linux-sunxi
enrico_ has quit [Quit: Bye]
FlorianH has quit [Ping timeout: 250 seconds]
<KotCzarny>
unless it has, but it's unpopulated apparently
gianMOD has joined #linux-sunxi
<yann|work>
what is it, that could cause a 2016.01-rc4 u-boot and a lichee 3.4 kernel to fail booting with "unrecognized/unsupported machine ID (r1 = 0x00000000)" ? I thought it could be the lack of CONFIG_OLD_SUNXI_KERNEL_COMPAT=y in u-boot, but apparently adding it isn't enough
<mripard>
yann|work: do you have bootm_boot_mode set to "sec" ?
<mripard>
(in the uboot environment)
<NiteHawk>
yann|work: it's unusual that your r1 has all the lower bits cleared (0x0000) - the CONFIG_OLD_SUNXI_KERNEL_COMPAT=y is only about passing the high word (msb) flag (0x1000)
<vinifr>
Anyway, I found out that problem is due to conflicting FLAGS(IRQF_ONESHOT and IRQF_SHARED). However, even using the same FLAG(IRQF_SHARED), i'm not able to request IRQ 28.
<mripard>
yes
<mripard>
because your assumption about the fact that the linux irq number and the hardware irq line are the same is wrong
ricardocrudo has joined #linux-sunxi
<mripard>
mostly due to the fact that you can have several hw irq 28 in your system
<mripard>
depending on the interrupt controller we're talking about
<mripard>
the linux irq number is a virtual number
<mripard>
and the first thing you have to do is create a mapping with your hardware irq line
<mripard>
fortunately, it's done automatically by the i2c framework
<mripard>
so you can just use client->irq and it works
<mripard>
but in order to do that, you have to provide the right interrupt description in the DT
<vinifr>
ok, is it enough to use? client->irq = irq_of_parse_and_map(client->dev.of_node, 0);
<mripard>
and it's where your patch doesn't work, because you simply don't respect what the driver expects
<mripard>
you don't even need that
<mripard>
client->irq is already set when you probe
<vinifr>
ok, thanks very much to your help and time
JohnDoe_71Rus has quit [Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org]
iamfrankenstein1 has joined #linux-sunxi
iamfrankenstein has quit [Read error: Connection reset by peer]
iamfrankenstein1 is now known as iamfrankenstein
catphish has joined #linux-sunxi
<catphish>
i'm trying to write a simple driver for the A20 GMAC, is there some documentation that might be able to get me started with how to use this device? i've been looking at the stmmac linux driver, but was hoping there might be some more readable documentation somewhere?
<apritzel>
catphish: some other Allwinner SoC with the same MAC has actually some register documentation, just a sec ...
<apritzel>
catphish: it's the A83T
<apritzel>
it says EMAC in the documentation, but it's actually the GMAC as we know it
sunxi_fan has quit [Remote host closed the connection]
<catphish>
apritzel: thank you very much, i'll have a look at that
sunxi_fan has joined #linux-sunxi
cnxsoft has quit [Quit: cnxsoft]
<catphish>
apritzel: i believe that has exactly what i need, thank you, i imagine this will still be fairly complicated, but that documentation has far more information than anything i've found before
bmeneg has quit [Quit: WeeChat 1.3]
<apritzel>
catphish: out of interest: what do you need a new driver for? A different OS? Hypervisor?
bmeneg has joined #linux-sunxi
<apritzel>
since this GMAC is based on one which is widely supported, this Ethernet chip is actually our least concern ...
<catphish>
apritzel: i'm trying to use an A20 to run some realtime code without an operating system, i basically needed a very fast microcontroller with ethernet, and i had a banana pro lying around, so thought i'd give it a try
<apritzel>
catphish: maybe worth to look at u-boot code, too
<apritzel>
their drivers tend to be easier to understand and more straight-forward
<catphish>
apritzel: that makes sense, i'm not very good at reading C code from large projects, but i'll look again with reference to that manual you linked
<catphish>
thanks
<catphish>
i did consider looking at the u-boot code, i'll see if i can find the gmac driver in there
Ueno_Otoko has joined #linux-sunxi
<apritzel>
I guess it's drivers/net/designware.c
<apritzel>
at least the register layout in the header file looks familiar
<catphish>
just has a look, i think that's correct
<catphish>
i searched for some constants, they pointed to that file too
<apritzel>
I looked for the MAC address registers being at 0x40 and 0x44 ;-)
<yann|work>
ssvb: that does the job, thanks much!
<yann|work>
mripard: I had checked that u-boot was built without the nonsec support (but was still issuing the setenv just in case ;)
naobsd has joined #linux-sunxi
<catphish>
i was confused when i started playing because i booted via u-boot TFTP, then dumped 0x00, the MAC configuration register, and it didn't seem to contain a sensible configuration, in particular tx and rx were disabled, but i guess it's possible u-boot disables these when it's finished with the NIC
<catphish>
that documentation seems to explain it very well anyway
<catphish>
i'll come back when i get stuck, thanks again
<apritzel>
catphish: I guess it's safer to disable RX/TX before booting Linux, as it avoids spurious DMA or interrupts
leio has quit [Remote host closed the connection]
<apritzel>
remember: there could be a network packet coming in at any time
<catphish>
apritzel: come to think of it, yes, i imagine those could be quite harmful to the early boot
<apritzel>
we actually had this here once ...
<apritzel>
random kernel crashes with strange memory corruption
<apritzel>
took ages to debug until one found that this memory content looks a lot like an Ethernet header ;-)
<apritzel>
(imagine getting your SMB discovery packet directly delivered into a page table ...)
afaerber has joined #linux-sunxi
afaerber has quit [Client Quit]
afaerber has joined #linux-sunxi
<catphish>
indeed
<catphish>
am i right in thinking that the OS gives the NIC a memory location to use? i've never worked with DMA before
leio has joined #linux-sunxi
<apritzel>
yes, and that's physical memory as seen by the bus
<apritzel>
which does not necessarily need to be identical with physical addresses as seen by the CPU
<apritzel>
(that's the difference between dma_addr_t and phys_addr_t in Linux)
<catphish>
that makes sense, thanks
<yann|work>
ssvb: oh, took me a bit of time to identify MACHINE_START(SUNXI, "sun8i") behind this :)
<apritzel>
but for your case they are ;-)
<catphish>
apritzel: they'll be the same? that's handy
<apritzel>
yes, unless you use a SMMU
<apritzel>
or any other fancy system design
<apritzel>
SMMU = IOMMU
<catphish>
ok
_stephan has quit [Quit: Ex-Chat]
<catphish>
anyway, i've got a lot to get started on now
<apritzel>
btw.: have you looked at Jailhouse? That lets you pair a custom (realtime) OS running on one core with a fully featured Linux running on the other
<apritzel>
but I don't want to spoil your I-write-my-own-OS-and-drivers experience ;-)
<apritzel>
mripard: wens: ssvb: is there any space where I could put images to?
<apritzel>
I am thinking about sparing people the Windows VM experience I had yesterday to create the Pine64 SD card image
<apritzel>
with that dodgy Allwinner PhoenixCard.exe
gianMOD has quit [Remote host closed the connection]
<mripard>
apritzel: you could probably ask for an account on dl.linux-sunxi.org
<ssvb>
apritzel: maybe talk to pine64 people?
<mripard>
I'm not quite sure who's responsible for that these days
<ssvb>
apritzel: what kind of SD card image is that?
<apritzel>
shitty Android, but at least it has the firmware bits in place
<apritzel>
I actually plan to remove Android from there and provide an easy template for people to put their own kernels in
<apritzel>
ssvb: it's the one provided by Pine64
<catphish>
apritzel: that sounds pretty cool, i did always wonder if linux would let me have one core for realtime and use the other for interrupts etc
<catphish>
apritzel: but i'm gonna press ahead with the DIY option for now, because i like that kinda thing
<apritzel>
catphish: I guessed so ;-)
<catphish>
thanks for the idea though, i'll look at that if / when i give up
<ssvb>
catphish: depending on what you need, the openrisc core might be suitable for realtime tasks
<catphish>
what i actually want to do is use GPIO to simultaneously bitbang several strings of RGB LEDs, and receive the data from ethernet
<catphish>
everyone says "you can't do this with linux because interrupts / multitasking will break the timing"
<apritzel>
and use some kind of shared buffer to communicate
<catphish>
basically it needs to wait for a frame, buffer the frame in memory, then switch to realtime and bitbang the GPIO with timings based on the data that was received in the frame
<apritzel>
or you could run a high priority realtime task doing that
<ssvb>
catphish: oh, wait, are you using A20?
<apritzel>
preferably that runs on core1, while core0 takes all IRQs anyway (unless you change the affinity)
<catphish>
ssvb: i am
<catphish>
ssvb: i don't have to, its just what i had handy
<ssvb>
catphish: there is no OpenRISC core in it then
<catphish>
ssvb: oh ok
<catphish>
apritzel: yeah, would need to pin a realtime task to core1, that might work
<apritzel>
so you basically need a periodic task to multiplex the LEDs?
<catphish>
i don't know how "realtime" linux's realtime is, nor do i know how fast the GPIO access would be via the linux kernel
<apritzel>
what's fast for you?
<apritzel>
I guess you get pretty far with standard Linux and realtime priorities already
<apritzel>
or you look at that RT branch Thomas Gleixner maintains
<catphish>
so a resolution of roughly 50ns
<catphish>
which is trivial for a 1GHz CPU, but problematic if interrupted
<apritzel>
I guess it's worth giving it a try
Ueno_Otoko has quit [Ping timeout: 256 seconds]
<apritzel>
you may use CPU groups & co to keep core1 as empty as possible
<catphish>
i agree in principle, but i'm gonna play around with doing it barebones for a while first
lemonzest has joined #linux-sunxi
<catphish>
failing that, i'll certainly see if i can have linux pin everything to cpu0 and my app to cpu1, with realtime priority
<catphish>
aren't there specific patches / kernel options for more true realtime
<apritzel>
sure, but don't forget to add SSL and a firewall ;-)
<apritzel>
there are, the RT branch, but haven't used it before
gianMOD has joined #linux-sunxi
<catphish>
well /obviously/ i'll want to make my own TLS implementation for it ;)
<catphish>
and perhaps a javascript interpreter, because everyone loves javascript right
<apritzel>
let's talk about that once you finished the TCP/IP stack ;-)
<apritzel>
(or UDP/IP, for a start)
domidumont has quit [Remote host closed the connection]
domidumont has joined #linux-sunxi
leio has quit [Remote host closed the connection]
vinifr has quit []
JohnDoe_71Rus has joined #linux-sunxi
lemonzest has quit [Ping timeout: 260 seconds]
apritzel has quit [Ping timeout: 246 seconds]
mmwolbrink has quit [Ping timeout: 265 seconds]
<yann|work>
ssvb: did you experience any GMAC "Initialize hardware error" on the OPi-PC ? I have them with your branch, but not with the loboris one - and I noticed some driver diffs between the two, will apply them onto your branch to check
<ssvb>
yann|work: the ethernet works fine for me
<ssvb>
what kind of fex file are you using?
<ssvb>
if the loboris kernel has some useful fixes, then we can surely make use of them
<yann|work>
good point, I went back to the script.bin.OPI-PLUS_1080p60 from loboris after not noticing any boot improvements, let's try that first
<ssvb>
the sunxi-boards repository still does not have a fex file for opi-plus
<ssvb>
so the hardware is somewhat different and this probably explain the problems
<ssvb>
tkaiser: that's a good point, thanks
<tkaiser>
It's in build/sunxi_geth.c.piplus vs. build/sunxi_geth.c
<tkaiser>
And Kconfig.piplus of course
<tkaiser>
And if I remember correctly applying your fex fixes for the 2 onboard LEDs led to disabled Ethernet on the Orange Pi PC using loboris kernel. I wanted to verify this but forgot in the meantime and am now running out of time.
<tkaiser>
Without 1-wire doesn't work on H3 based Orange Pis
<tkaiser>
And in his fex files he also defined a pin to be used with 1-wire
<tkaiser>
That's all the necessary stuff I recall. But crawling through his commit logs might be interesting too. There were a few fixes he made that were really necessary.
akaizen has quit [Remote host closed the connection]
<catphish>
apritzel: i'm actually hoping implementing a basic IP/UDP stack will be reasonably easy, i have a "pretty good" knowledge of network protocols, TCP is a different story, but not one i need to worry about
<catphish>
the drivers are the scary part for me
ninolein has quit [Ping timeout: 250 seconds]
ninolein has joined #linux-sunxi
Wizzup_ has quit [Quit: Reconnecting]
Wizzup has joined #linux-sunxi
jinzo has joined #linux-sunxi
<yann|work>
will need to check this HDMI/DVI stuff, which might explain the magenta tint I get when using DVI...
tkaiser has joined #linux-sunxi
Netlynx has joined #linux-sunxi
Netlynx has quit [Changing host]
Netlynx has joined #linux-sunxi
<JohnDoe_71Rus>
yann|work: i get this my cb2 android
<tkaiser>
yann|work: Yes, both settings necessary when you use kernel 3.4 and a HDMI-DVI converter.
<tkaiser>
Does also apply to A83T/H8/R58 when using sunxi 3.4 kernel
<yann|work>
expectedly, there are 3 processes in "D" state: [vsync proc 0] [vsync proc 1] [usb-hardware-sc]
mmwolbrink has quit [Remote host closed the connection]
<yann|work>
tkaiser: do you have something similar ?
<tkaiser>
Pardon?
<yann|work>
does "ps aux |grep D" gives you any process in "D" state (as opposed to usually S or R ?
<yann|work>
(consistently in D state, that is)
<yann|work>
that's processes blocked in uninterruptible sleep, and they do add to the system load value (without impacting the CPU load)
<tkaiser>
Can't test. And am not running 3.4 any longer on H3. The one Orange Pi PC runs with 4.4 and is serving music. If I reboot I will get killed immediately ;)
<yann|work>
ok :)
<yann|work>
the sinovoip guys should have asked you for more details, but apparently they're not the talkative type :)
<tkaiser>
No comment. They made me crazy but this time's over. :)
ricardocrudo has quit [Remote host closed the connection]
<jelle>
oh my, who will be the winner
afaerber has quit [Quit: Ex-Chat]
<ssvb>
the benchmark numbers make no sense
<jelle>
sounds like your normal phoronix
<ssvb>
for example, the orange pi pc should have roughly the same performance as orange pi plus
<ssvb>
Banana Pi M2 and Raspberry Pi 2 (Cortex-A7 with slower clock speed) are sometimes winning against Orange Pi PC
<jelle>
ssvb: but what image did he use?
<jelle>
I tried to get started with the PMIC controller of the orange pi pc in u-boot but can't get a i2c connection yet :(
<yann|work>
ssvb: I did not look too much at the code, and I don't have that board, sorry
<ssvb>
yann|work: ok
<GeneralStupid>
ssvb: please mention that the 1.6 Ghz are not really usable
<maz_>
mripard: just so you know, mainline explodes on a CT if the BRCM driver is compiled in.
<maz_>
mripard: I'll try to bisect the sucker tomorrow if I get the time.
<ssvb>
GeneralStupid: very nice, apparently I can't comment in the phoronix forums :-) it just does not get through (maybe awaiting moderation)
TheSeven has quit [Remote host closed the connection]
Netlynx has quit [Quit: Leaving]
<GeneralStupid>
ssvb: unless you dont install your device at the outside in a cold region it wont run on 1.6 in the original configuration
<ssvb>
GeneralStupid: are you telling this to me?
<GeneralStupid>
ssvb: iam telling it to you, with the knowledge that you already know it and in hope that anyone who is interrested in an orangepi will read this
<vagrantc>
i've got one orangepi plus2 that seems to work fine, and another that's giving me all sorts of headaches.
<vagrantc>
finally had it booting several times from a cold boot, and now it's giving me this
gianMOD has quit [Remote host closed the connection]
nashpa has joined #linux-sunxi
gianMOD has joined #linux-sunxi
Andy-D has quit [Remote host closed the connection]
gianMOD has quit [Remote host closed the connection]
pmattern has quit [Quit: Genug für heute.]
afaerber has joined #linux-sunxi
Andy-D has joined #linux-sunxi
gianMOD has joined #linux-sunxi
naobsd has quit [Quit: naobsd]
<yann|work>
ssvb: the vonfritz fex is 720p - OTOH loboris provides several choices for different resolutions. That system is a PITA, how do we handle that in a sane world ? :}
<ssvb>
yann|work: wait for the mainline kernel with a KMS display driver for H3
<ssvb>
the sunxi-3.4 kernel for A10/A13/A20 got EDID support and can automatically identify the monitor resolution
<yann|work>
fair enough
<ssvb>
in principle somebody can hack the Allwinner's 3.4 kernel for H3 and add EDID support there too, but it's hard to find a motivated individual to do this work
<yann|work>
there is so much to do in much saner places :)
<yann|work>
hm, m4 gets sigkilled when run as user, with no clue from strace
<yann|work>
are there that many security features of the CONFIG_ANDROID_PARANOID_NETWORK kind ?
gianMOD has quit [Remote host closed the connection]
paulk-collins has quit [Quit: Quitte]
gianMOD has joined #linux-sunxi
gianMOD_ has joined #linux-sunxi
gianMOD has quit [Ping timeout: 240 seconds]
Nyuutwo has quit [Read error: Connection reset by peer]
Nyuutwo has joined #linux-sunxi
jinzo has quit [Quit: Leaving]
tkaiser has joined #linux-sunxi
<tkaiser>
yann|work: m4 gets sigkilled when running on your Orange Pi? If yes what's the output of 'cat /proc/sys/vm/mmap_min_addr'?
<yann|work>
65536
<yann|work>
setxkbmap too
<tkaiser>
Does 'echo 4096 >/proc/sys/vm/mmap_min_addr' fix it?
<yann|work>
ah ok, that's just not in ssvb/linux-sunxi yet :)
<yann|work>
did you push those fixes somewhere already ?
<tkaiser>
BTW: Regarding different display resolutions. AFAIK fbset works. When I need 'exotic' resolutions like 1024x600 I define them in /etc/fb.modes and call fbset at boot.
<tkaiser>
Nope, I pushed nothing since I can not test. Just wanted to save someone else some time.
<tkaiser>
Since I went through similar fixes necessary for Banana Pi M3 (the BSP they use is almost identical to the one for H3)
<yann|work>
it would save some time if you pushed what you've already done, or I'll have to reconstruct them to test (but then, I had planned to do pick them myself anyway ;)
<yann|work>
or just git format-patch them and put them to some pastebin, that should do equally well
<tkaiser>
Nope, I just collected what I recalled from memory since I stumbles across when using H3 and A83T. That's all. Good night.
<danboid>
I've just installed 4.4.0 under Arch and it looks like BPi ALSA support didn't make it into the latest mainline kernel
gianMOD_ has quit [Remote host closed the connection]
gianMOD has joined #linux-sunxi
<yann|work>
ssvb: is there any particular reason to have DRM not set ? loboris has it activated, and I recall seeing a mali_drm.ko with his kernel, that could be useful