<KotCzarny>
here i need it to access either sram a1 or a2
<KotCzarny>
i wonder if there is a3/a4 on h3
<guest_2222>
I've got question about registering irq handler in kernel module. I'm registering handler with request_irq/devm_request_irq for USB OTG and I'm still get it registered in "sunxi_pio_edge" domain
<guest_2222>
but AFAIK it should be GIC-0 domain
<guest_2222>
and I have not idea what is going on...
<guest_2222>
anyone knows what should be to to get this handler connected to GIC?
<maz>
guest_2222: what is that line physically connected to?
<guest_2222>
irq no 70 as I remember
<maz>
guest_2222: that's not what I asked.
<maz>
guest_2222: which interrupt controller is this line connected to?
<guest_2222>
I hope it is GIC nut I'm not sure in 100%
<guest_2222>
s/nut/but/
<maz>
guest_2222: well, you *really* need to be know.
<oliv3r>
KotCzarny: the wiki page probably hasn't been updated in ages with regards to the sram controller. but check the datasheet at the very least :) h3 ... wasn't that a repackaged a13? or am I confused?
<maz>
to know...
* maz
cannot type these days.
<KotCzarny>
oliv3r: very confsed..
<KotCzarny>
and in h3/h5 datasheet there is only sram a1/a2/c
<maz>
guest_2222: look at the schematics/TRM for your board/SoC. that should make it unambiguous.
Ntemis has joined #linux-sunxi
<oliv3r>
we both know how good the quality of these datasheets is :)
<oliv3r>
maybe the a10 one was even wrong ..
<maz>
guest_2222: and once you find out, set the interrupt-parent to the right value in the DT node for your device.
<KotCzarny>
things were changing between socs
<guest_2222>
maz: it is R40 board, and AFAIK this OTG is built in the SoC, so there is no schematic
<guest_2222>
or mayby I missed something
BenG83 has joined #linux-sunxi
<wens>
are you requesting the right irq?
<maz>
guest_2222: then look at the TRM and identify which interrupt controller the OTG is connected to.
<mripard>
guest_2222: paste us your DT
<guest_2222>
wens: in DT I wrote: interrupts = <GIC_SPI 38 IRQ_TYPE_LEVEL_HIGH>
<maz>
guest_2222: what is the interrupt parent for that interrupt?
<wens>
guest_2222: where did you get the value you passed to request_irq?
<guest_2222>
the value 38=70-32
<wens>
no
<wens>
in your code
<wens>
not the device tree
<guest_2222>
I hardcoded it to 38
<guest_2222>
because
<guest_2222>
everytime i run platform_get_irq() I got 25
<wens>
you can't do that...
<wens>
nobody said that irq numbers are 1:1 mapping...
<guest_2222>
I'mm very beginning in DT
<guest_2222>
ok, so how to do this?
<maz>
and actually, they are dynamic.
<wens>
it seems you are also very new at kernel programming in general...
<wens>
guest_2222: use platform_get_irq() as designed...
<guest_2222>
so far I used only request_irq() and it worked somehow :)
<wens>
and now it blew up
<guest_2222>
:)
<KotCzarny>
amazing, my code works
<KotCzarny>
maybe i should implement http server on arisc
<KotCzarny>
or some proxy
BenG83 has quit [Remote host closed the connection]
kloczek has quit [Remote host closed the connection]
kloczek has joined #linux-sunxi
nuuuciano has joined #linux-sunxi
<KotCzarny>
interestingly emac byte order and arisc one are different
<guest_2222>
wens: any pointers how should I fix my DT or sources?
BenG83 has joined #linux-sunxi
kaspter has quit [Read error: Connection reset by peer]
chomwitt has joined #linux-sunxi
kaspter has joined #linux-sunxi
<smaeul>
KotCzarny: networking is big endian ("network byte order"). arisc is big endian. so actually they're the same. but allwinner's "reverse the data lines" idea makes them seem backward
tllim has joined #linux-sunxi
<KotCzarny>
seems so, still, to only check for few bytes i could cope without writing proper swapper
<KotCzarny>
sure, but cycles are slow for arisc and dram
chlorine_ has quit [Remote host closed the connection]
chlorine has joined #linux-sunxi
chlorine has quit [Remote host closed the connection]
<smaeul>
oh, definitely. I'd be impressed if the compiler wasn't smart enough to do the swapping in a cpu register, but yeah if you don't *need* it you can save a few cycles
<KotCzarny>
it's not about swapping per se, but accessing dram from arisc
<KotCzarny>
and since i run on 24mhz and also watch for ir and gpio, things might be tight when delayed too much
<KotCzarny>
especially for ir
<smaeul>
KotCzarny: I did figure out the IR interrupt number for arisc, if that helps with your IR timing
<KotCzarny>
well, i have to get data off ir fifo fast enough
<KotCzarny>
otherwise it overflows (each ir keycode spills over fifo capacity)
<smaeul>
right, and if it's a latency issue, interrupts will help, but if it's a throughput issue, they won't. and I haven't written an IR driver yet so I don't know :)
<KotCzarny>
yeah, ints would help. because it would be about getting there and servicing poor fifo
<KotCzarny>
btw. did you check if arisc has some powersaving idle instruction?
aalm has quit [Ping timeout: 255 seconds]
msimpson has quit [Quit: Leaving]
<smaeul>
no, I haven't had an opportunity to check if the optional one listed in the or1k docs is present
<KotCzarny>
also, thanks for that byteswap.h
<smaeul>
and ir rx interrupt should be 0x05 on the r_intc
Jackie_ has quit [Remote host closed the connection]
Jackie_ has joined #linux-sunxi
chlorine has joined #linux-sunxi
<willmore>
KotCzarny, did you give up on the MAC layer doing the magic packet detection on its own?
<KotCzarny>
willmore: um, give me the reg to check and i will use it
<willmore>
IIRC, some PC NICs do that detection on their own. But, at what layer they implement it, I do not know.
* willmore
shrugs....
<KotCzarny>
;)
<willmore>
Does anyone have a datasheet for *any* of these chips? ;)
<KotCzarny>
if i have seen any wol related reg in manual i would use it
<KotCzarny>
montjoie would be an expert to answer that question
guest_2222 has quit [Quit: Page closed]
chlorine_ has joined #linux-sunxi
chlorine has quit [Ping timeout: 256 seconds]
<willmore>
KotCzarny, I reviewed the H3 ethernet chapter and I don't see any sign of it. I'll check the WOL spec and see if they have any special terminology or tricks.
<KotCzarny>
willmore: i did, and i'm writing own baremetal ethernet driver and parser
<KotCzarny>
yay, just finished code part, it works, now i have to integrate wolmac param into arm binary
<tuxillo>
hi
<tuxillo>
does somebody know if I can boot the pine64 from the network with uboot?
smaeul has quit [Read error: Connection reset by peer]
chlorine has joined #linux-sunxi
smaeul has joined #linux-sunxi
IgorPec has joined #linux-sunxi
chlorine_ has quit [Ping timeout: 256 seconds]
chlorine has quit [Ping timeout: 256 seconds]
matthias_bgg has quit [Ping timeout: 240 seconds]
tl_lim has joined #linux-sunxi
<willmore>
KotCzarny, So far the only advice I can find is to make sure you switch the link speed down to 10Mb/s to save power.
tllim has quit [Ping timeout: 265 seconds]
<willmore>
KotCzarny, yeah, nothing of use in the standard MII registers, either. :(
<KotCzarny>
willmore: yeah, doing that already
<willmore>
Unless there's magic hidden somewhere in the allwinner SoC, I'm afraid your plan is all that'll work.
<willmore>
Sorry I couldn't be of more help.
<KotCzarny>
btw. if you are interested in h3fakeoff with gpio/ir/uart/wol wakeup shout
<KotCzarny>
works on h3 (and probably h5)
<KotCzarny>
runs on arisc and turns off anything it can
<willmore>
KotCzarny, what do you have the idle power/current down to?
<KotCzarny>
~40mA
<willmore>
Not bad!
<KotCzarny>
and you can still do things on arisc
<willmore>
What about without WOL? Just waiting on a GPIO?
<KotCzarny>
basically anything you would do on microcontroller
<KotCzarny>
yeah, its configurable
nuuuciano has quit [Read error: Connection timed out]
<KotCzarny>
if you dont add wol param it turns off dram and emac
<willmore>
Oww, that's got to be a large chunk
<KotCzarny>
yeah, i get +6-10C compared to without dram/emac
<KotCzarny>
but still good -8C compared to idle linux
<KotCzarny>
and without wol there is still gpio/ir/uart wakeup
<willmore>
IR can't cost more than a few mA, I'd imagine.
<willmore>
KotCzarny, you making up a wiki page for your work?
<KotCzarny>
will do github then wiki once i finish it
LargePrime has joined #linux-sunxi
<willmore>
Cool, thanks.
<tuxillo>
did all the pine64s include the power button?
<willmore>
I'm pretty sure I had to solder two buttons onto mine. I don't remember which they were. They were on the two pads over by the wireless header.
<montjoie>
KotCzarny: ephy datasheet in H6 speak that internal PHY support WoL
<montjoie>
if Ac200 support it , why realtek dont ?
<KotCzarny>
montjoie: got any pointers?
<KotCzarny>
though now i have implemented it on arisc, it would only help for dropping dram
<tuxillo>
willmore: the one in their web claims needs no soldering
<montjoie>
H6 usermanual, no more info. end of knowledge on that topic:)
<tuxillo>
at least the power button which I assume could be used as reset switch too
<tuxillo>
willmore: there are no buttons attached, the button used to come loose on the box
<tuxillo>
so you could insert it in the holes
<tuxillo>
(no need to solder it)
<tuxillo>
is apritzel still hanging around here ?
<KotCzarny>
hmm, what is alternative to setenv bootm_boot_mode sec ?
hardfalcon has joined #linux-sunxi
<KotCzarny>
norm? nor? normal? unsec?
phipli has joined #linux-sunxi
nashpa has quit [Quit: Going away]
nashpa has joined #linux-sunxi
foxx_ has quit [Ping timeout: 248 seconds]
kaspter1 has joined #linux-sunxi
kaspter has quit [Quit: kaspter]
kaspter1 is now known as kaspter
<KotCzarny>
lol @ that opi0wh comment
<KotCzarny>
erm. rpi0wh
lkcl has quit [Ping timeout: 256 seconds]
kaspter has quit [Remote host closed the connection]
kaspter has joined #linux-sunxi
pgreco has quit [Quit: Leaving.]
smaeul has quit [Quit: WeeChat 2.0]
aalm has joined #linux-sunxi
Mr__Anderson has quit [Read error: Connection reset by peer]
nuuuciano has joined #linux-sunxi
lkcl has joined #linux-sunxi
tllim has joined #linux-sunxi
kaspter has quit [Ping timeout: 268 seconds]
aalm has quit [Ping timeout: 255 seconds]
afaerber has quit [Quit: Leaving]
nothim has joined #linux-sunxi
iamfrankenstein has quit [Quit: iamfrankenstein]
reinforce has quit [Quit: Leaving.]
edfox has joined #linux-sunxi
Ntemis has quit [Remote host closed the connection]
<edfox>
Hello guys, I'm having some issues with an H2+ board. Everything I need works fine with a standard Debian install (mainline kernel)
<edfox>
However, I can't seem to make the codec work at all. I added two blocks (&codec and &analog_codec) in my dts file and it looks like the codec is loading - however i'm having the same issue as this one https://github.com/armbian/build/issues/700
dev1990 has quit [Read error: Connection reset by peer]
dev1990 has joined #linux-sunxi
edfox has quit [Remote host closed the connection]
edfox has joined #linux-sunxi
kaspter has joined #linux-sunxi
gnufan has joined #linux-sunxi
skiboy has joined #linux-sunxi
skiboy has quit [Client Quit]
IgorPec has quit [Ping timeout: 255 seconds]
tlwoerner has quit [Quit: Leaving]
<willmore>
tuxillo, Ahh, that might have been after I bought mine. I got one of the very early models. Did not come with a switch. Fortunately, I have a ton of the right switches, so I just stuffed in two.
<willmore>
KotCzarny, the guy who can't use Orange Pi boards?
<willmore>
hanetzer, I, for one, have never heard of it.
* willmore
is not a representative sample of anything.
<hanetzer>
willmore: its referenced in the wiki about external interrupt handling
<willmore>
hanetzer, okay.
<hanetzer>
mostly interested because doing bga pcbs is dicks :P
tlwoerner has joined #linux-sunxi
tlwoerner has quit [Changing host]
tlwoerner has joined #linux-sunxi
<Wizzup>
Net147: do you have the 4.3" olimex ts working on 4.14? something changed in the dts that broke it, see my msgs from last night, but I don't know what
<Net147>
Wizzup: yes, I did have it working on 4.14 but I merged the CCU sunxi-ng style clock conversion patches so the device tree is using sunxi-ng
<Net147>
Wizzup: I haven't used the old style clocks for long time
<Wizzup>
I tried to use the dts essentially unchanged from 4.11 and that doesn't work