kaspter has quit [Remote host closed the connection]
kaspter has joined #linux-sunxi
chewitt has quit [Quit: Zzz..]
lurchi_ has joined #linux-sunxi
lurchi__ has quit [Ping timeout: 272 seconds]
selfbg has joined #linux-sunxi
t0dd1v has joined #linux-sunxi
s_frit has quit [Remote host closed the connection]
s_frit has joined #linux-sunxi
chewitt has joined #linux-sunxi
leviathan has joined #linux-sunxi
IgorPec has joined #linux-sunxi
_whitelogger has joined #linux-sunxi
diego_ has joined #linux-sunxi
IgorPec has quit [Ping timeout: 252 seconds]
yann has quit [Ping timeout: 240 seconds]
IgorPec has joined #linux-sunxi
tllim has quit [Read error: Connection reset by peer]
afaerber has quit [Quit: Leaving]
t0dd1v has quit [Quit: Connection closed for inactivity]
m4ssi has joined #linux-sunxi
<curlybracket>
What seems a bit off is that while there's no HDMI video with neither 2560x1440 nor 1440x2560 screen, it showed up with a 1080x1920 panel. Now I see that both outputs display contents of the same framebuffer
<quitte>
If at least it is somewhat there it'll be fine. the dealbreaker with the rpi3 for me is the interrupt controller.
<KotCzarny>
basically almost all boards run without secure boot enabled
<quitte>
Figured out how to get jtag working so that I could try multicore irq balancig...
<quitte>
I don't care about secure boot
<KotCzarny>
but without it trustzone isnt doing anything afaiu from those chats
<quitte>
it just looks like a quick way to seperate memory access between interrupt service routines and the normal code without mmu reconfiguration, which I assume is slower
<quitte>
no trustzone can be used from the interrupt vector tables from how I interpret the parts of the manuals I read
<quitte>
by trustzone I mean the 33rd address bit that marks memory as secure
<KotCzarny>
but trustzone isnt 64bit specific, then you can get some older board cheaply to play around?
<quitte>
I already have a solid-run i.mx6 board. the problem is the jtag connection. It must survive being carried in a backpack
smaeul has joined #linux-sunxi
<KotCzarny>
i mean allwinner one (a20/h3)
<quitte>
hmm. I have a cubietruck...
<KotCzarny>
maybe smaeul will know more
<quitte>
burnt the power management chip though. but it still runs. I guess it would do if I figured out a good waz to attach jtag. It's shared with the sdcard so essentially the same problem as with the solid-run board
<KotCzarny>
spi boot?
<KotCzarny>
or fel-boot (via microusb)
<quitte>
booting doesn't matter as long as jtag works
<quitte>
oh
<quitte>
which it doesn't
<quitte>
the problem is attaching the wires such that they will survive being thrown in a backpack
<KotCzarny>
get the tv box ?
<quitte>
repeatedlz
<quitte>
sorry about the y/z mistakes.
<quitte>
tv box?
<KotCzarny>
you will get something with quite tight box, and you can hotglue the wires/connector
<quitte>
smaeul: it's about servicing interrupts fast while seperating the interrupted processes memory from the interrupt. My assumption being that doing the MMU thing is slower than switching to secure mode
<quitte>
beeble: that looks good if shipping and tax is reasonable
<smaeul>
quitte: are you on armv7 or armv8?
<smaeul>
on armv8 all secure interrupts go through ATF if received in NS world
<quitte>
smaeul: right now rpi3 which turns out doesn't have a usable interrupt controller. So now I need to figure out what kind of hardware I hould use instead
<smaeul>
sorry, I sort of turned my computer on in the middle of this discussion... I'm not sure what your goal is
diego_ has quit [Ping timeout: 272 seconds]
<quitte>
smaeul: essentially I want to figure out interrupts in a multi core scenario. bare metal. Of course I'd rather not deal with legacy or cost saving measures because why would I.
s_frit has joined #linux-sunxi
<quitte>
smaeul: And the RPI3 I have turns out to not have a GIC, which is unacceptable
<KotCzarny>
saying the man who bought the rpi :>
<quitte>
smaeul: and it needs to be able to be thrown in my backpack ;)
<smaeul>
well A64/H5 SoCs have working GICv2, and an OpenRISC coprocessor with its own interrupt controller (including an NMI)
<quitte>
KotCzarny: it's armv8 how was I supposed to know they'd recycle even the interrupt controller for a 64bit soc?
<quitte>
openrisc? that foss architecture? Time flies.
<smaeul>
as for secure mode, you can run A64/H5 with upstream opensource ATF, and I know people have used that with a TrustZone implementation (OPTEE, I believe)
<smaeul>
though I'm not sure what the state of TrustZone ports is
<smaeul>
yes, that one
matthias_bgg has joined #linux-sunxi
scelestic has joined #linux-sunxi
<quitte>
Okay sounds like I won't hit a wall similar to the rpi with a pine 64 before it's obsolete.
<quitte>
do you happen to know what it takes to jtag attach to it?
<smaeul>
quitte: are you looking for hardware documentation? or software to use/examine?
<quitte>
neither: hardware to use/examine
<smaeul>
jtag... plug into the appropriate GPIO
<smaeul>
beyond that, I don't know for sure
<quitte>
so probably needs some pin configuration. It'll be fine
<smaeul>
I know MoeIcenowy has used JTAG before, and I'm pretty sure openocd works with the H3 (latest 32-bit SoC), but that's about it
<beeble>
iirc on a64 if there is no sd card detected it will mux the pins to jtag. otherwise you have to pinmux these or the alternative pins to jtag
<beeble>
works with openocd
<smaeul>
quitte: I know the pin configuration is setup by the boot rom if you FEL boot (the boot-over-USB protocol when you don't have a boot device plugged in
<quitte>
beeble: being able to just load code to sram via jtag without any bootloader nonsense would be a dream
<beeble>
you will start in 32bit mode on the a64 although
<beeble>
but im not 100% sure on the a64 and jtag fallback right now. that was a while back i did it the last time
<quitte>
yes I noticed that. no problem. all the peripherals are 32bit anyways so why waste all those bits in interrupt service routines
<quitte>
thumb would probably do
<beeble>
it is on rk33xx like that (the fallback)
<beeble>
just keeping card detect inactive works
<smaeul>
quitte: the openrisc coprocessor has direct access to everything (no MMU, can read/write all secure registers, can turn ARM cores on/off)
<smaeul>
so you could use it as a custom software jtag or equivalent for some purposes
<beeble>
so you might try that if it works the same
<quitte>
thanks everybody. Pretty sure I'll buy the thing and then see why I don't like it. (except for the docuentation which I' sure I'd prefer the i.MX8's)
<KotCzarny>
ah right, the docs
<KotCzarny>
;)
<smaeul>
quitte: yeah, with allwinner documentation, usually it's there somewhere, but you may have to look in an older SoC's manual, or the bsp source code, or...
<KotCzarny>
the running joke of allwinner
<beeble>
quitte: if you can you might want to use a cmsis-dap adapter instead of ftdi based bitbanger
<quitte>
beeble: I have this j-link v8 clone that so far seemed decent.
<beeble>
yes, should work similar well
<beeble>
quitte: btw, do remeber that gicv2 vs gicv3 has a major difference in interrupt distribution. gicv2 can broadcast interrupts for the sake of latency even though it decreased your performance
<beeble>
this got removed from gicv3 and you have to assign a core for an interrupt
<quitte>
beeble: 1:N vs. N:N ? and gicv3 dropped N:N?
dddddd has quit [Read error: Connection reset by peer]
<beeble>
1:N was dropped
<quitte>
I may have misunderstood which was which. It is now impossible to have an interrupt wake more than one core?
<beeble>
was N:N available? not sure right now
<KotCzarny>
is that the reason there is no automatic irq scheduling on arm?
<quitte>
as far as I understood an interrupt could either be assigned to 1 core or all cores. But not more than one core but less than all
<quitte>
A proper service routine should be done fast enough for it not to matter. the peripheral clocks are the bottleneck on cortex-a. At least I hope to find a way to not block the cores waiting for the peripherals
<beeble>
The ARM GIC architecture guarantees that a 1 of N interrupt is presented to only one PE
<beeble>
listed in the target PE set.
<beeble>
and which PE takes it is implementation specific
chewitt has quit [Ping timeout: 252 seconds]
<quitte>
PE?
<beeble>
processing element. that was a verbatim copy from the gic spec
<quitte>
I don't think that pdf will load anytime soon on this connection I'm on. But "PE set" sounds like an interrupt can be handled by more thatn one CPU, still. Except now it doesn't have to be either one or all
<quitte>
I don't understand how I didn't find out about the existence of GIC3 and 4 days ago when I searched for GIC documentation and the latest I found was V2. Oh well.
IgorPec has joined #linux-sunxi
reinforce has quit [Quit: Leaving.]
IgorPec has quit [Ping timeout: 252 seconds]
quitte has quit [Quit: leaving]
matthias_bgg has quit [Ping timeout: 272 seconds]
<anarsoul|2>
wens: are you around?
<anarsoul|2>
wens: I'm trying to clean up audiocodec patches for A64
<anarsoul|2>
and looks like sun8i-codec-analog.c is not trivial - I have to replace has_* quirks with callbacks
<anarsoul|2>
and duplicate the code since registers addresses have changed
tllim has quit [Quit: Leaving]
<anarsoul|2>
normally I would use regmap to deal with it
<anarsoul|2>
but it's not possible in this case since it uses register addresses (and values) in static routes and widgets arrays
<anarsoul|2>
wens: so does it justify to move A64 code to another driver instead of extending sun8i-codec-analog.c?
<anarsoul|2>
I *can* extend sun8i-codec-analog.c but it becomes messy and hard to read