<[TheBug]>
jrg: though someone quoted: ‘Another person also leveraged Jared’s work to run FreeBSD to NanoPi NEO board instead of NetBSD’
<[TheBug]>
jrg: so you probably have to dig but it should be possible
Andy-D__ has joined #linux-sunxi
Andy-D_ has quit [Ping timeout: 240 seconds]
dave0x6d has quit [Quit: Connection closed for inactivity]
BenG83_ has joined #linux-sunxi
BenG83 has quit [Quit: Leaving]
chlorine has joined #linux-sunxi
chlorine has quit [Ping timeout: 240 seconds]
digitalpeer_ has quit [Quit: Leaving]
lennyraposo has quit [Quit: Leaving.]
pg12 has quit [Ping timeout: 240 seconds]
pg12 has joined #linux-sunxi
dave0x6d has joined #linux-sunxi
ninolein_ has joined #linux-sunxi
ninolein has quit [Ping timeout: 260 seconds]
ganbold has quit [Quit: Leaving]
ganbold has joined #linux-sunxi
cnxsoft has joined #linux-sunxi
nihcas_ has joined #linux-sunxi
meridion_ has joined #linux-sunxi
longsleep_ has joined #linux-sunxi
Rondom has quit [Disconnected by services]
Rondom has joined #linux-sunxi
fire219_ has joined #linux-sunxi
smaeul_ has joined #linux-sunxi
dave0x6d has quit [*.net *.split]
popolon has quit [*.net *.split]
fire219 has quit [*.net *.split]
meridion has quit [*.net *.split]
Hauke has quit [*.net *.split]
droman0 has quit [*.net *.split]
longsleep has quit [*.net *.split]
medvid has quit [*.net *.split]
a|3x has quit [*.net *.split]
smaeul has quit [*.net *.split]
nihcas has quit [*.net *.split]
a|3x has joined #linux-sunxi
nihcas_ is now known as nihcas
Hauke has joined #linux-sunxi
Gerwin_J has joined #linux-sunxi
medvid has joined #linux-sunxi
meridion_ is now known as meridion
pg12 has quit [Ping timeout: 240 seconds]
pg12 has joined #linux-sunxi
terra854 has joined #linux-sunxi
popolon has joined #linux-sunxi
duracrisis has quit [Ping timeout: 276 seconds]
duracrisis has joined #linux-sunxi
droman0 has joined #linux-sunxi
chlorine has joined #linux-sunxi
<ullbeking>
wow, this is cool
<ullbeking>
jrg: i've ordered a +2e, cannot wait for it to arrive
JohnDoe_71Rus has joined #linux-sunxi
chlorine has quit [Ping timeout: 240 seconds]
FergusL has quit [Ping timeout: 260 seconds]
lurchi_ has joined #linux-sunxi
lurchi__ has quit [Ping timeout: 255 seconds]
lkcl has joined #linux-sunxi
TheSeven has quit [Ping timeout: 246 seconds]
TheSeven has joined #linux-sunxi
Andy-D__ has quit [Ping timeout: 246 seconds]
smaeul_ is now known as smaeul
pmpp_ is now known as pmpp
reinforce has joined #linux-sunxi
rocketpenguin has joined #linux-sunxi
scream has joined #linux-sunxi
<oliv3r>
Net147: i managed to clock the i2c on the hdim to 450-ish MHz and worked great
<Net147>
oliv3r: are you using i2c-dev from userspace or did you add the i2c devices to the device tree?
jstein_ has joined #linux-sunxi
<oliv3r>
userspace
<oliv3r>
these are just early experiments
<oliv3r>
but for now, i'm thinking of changing the hdmi driver to accept an ddc = <&i2c> node
<Net147>
oliv3r: are you doing anything timing critical over the I2C?
<oliv3r>
since a designer can route any bus he wants
<oliv3r>
Net147: what do you mean? the timing on the bus should be proper; if your talking about 'pacemaker device on i2cc' then no, it'll be a touchscreen
jstein_ is now known as jstein
<Net147>
oliv3r: the driver will generally send in chunks of 16 bytes. there will very some very short delays between the chunks. but I guess you don't have any I2C read/writes that are more than 16 bytes?
<oliv3r>
ah like that
<oliv3r>
no, i doubt touch screen data will be more then that
<oliv3r>
but i'm not quite sure i follow
<oliv3r>
there is a 16 byte fifo i gathered
<oliv3r>
which is what is causing the delays
<oliv3r>
so if my i2c transmission is less then the fifo size, i'll get the data as requested right?
<oliv3r>
i'm expecting very small transmission actually
<Net147>
oliv3r: we are not using the FIFO as normal since we don't care much about precise timing
<oliv3r>
why not? easier to implement? bugs in the silicon?
<Net147>
oliv3r: should use interrupts for tighter timing
<Net147>
oliv3r: and possibly DMA
<oliv3r>
anyhow, i'm expecting transfer sizes in the 4 - 16 byte range for touchscreen I/O
<oliv3r>
Net147: ahh ok so those are software improvements we can add at a later time
<Net147>
well interrupts are easy to add. I got it working at some stage before.
<Net147>
just add an interrupt handler to signal completion and then modify the poll to wait for the completion
<oliv3r>
Net147: well it's good to have a simple basic driver working first :)
<oliv3r>
then add the fluff later
<Net147>
wens is adding A31 DDC support to the driver
<oliv3r>
nice one
<Net147>
the Allwinner BSP code doesn't use interrupts or DMA at all
<oliv3r>
well if the hardware supports it, it would be nice to add them later; but i'll be working on this the next few months
<mripard>
it won't make much sense to use DMA for such small data transfers
<oliv3r>
well the IRQ mostly
<mripard>
you're going to spend more time programming the DMA engine than getting your data out of the FIFO
<oliv3r>
anyway, we are building our first proto boards right now, which will add the touchscreen to the hdmi i2c port
<oliv3r>
yeah i don't expect to be seeing data transfers that big
<Net147>
I think the Linux I2C API is limited to 16 byte transfers anyway
<oliv3r>
and the eeprom (which in theory could be large) isn't timing critical and only queried once at boot-up
<Net147>
or maybe 32...
<oliv3r>
i'll play with the interrupt
<oliv3r>
once i have proto hardware
<mripard>
oliv3r: since you'll need more than just HDMI anyway, why not just using a real I2C bus ?
<oliv3r>
mripard: because we are not designing the a20 board, we are using lime2 boards and just connecting the HDMI connector
<oliv3r>
mripard: as we are re-using our existing 'platform', just swapping out the UI
<Net147>
oliv3r: the UEXT connector too difficult?
<oliv3r>
the alternative is running seperate cables to the front, which adds cost and complexity (i2c over long distance is hard to get right, the hdmi cable makes it so much cleaner)
<mripard>
oliv3r: yeah, but you'll need one or two additional signals on top of HDMI
<mripard>
like the interrupt from the touchscreen
<oliv3r>
Net147: but we only are using the HDMI connector, so then we'd need to add a secondary plug, combine the wires, and extract the wires again into 2 plugs
<oliv3r>
mripard: for now, we are thinking of polling it
<mripard>
good luck with that :)
<oliv3r>
mripard: share :p
<oliv3r>
according to the datasheet that should be a possibilty
<mripard>
yes, everything is a possibility according to datasheet
<oliv3r>
we where looking at that, and where thinking of abusing the CEC pin :p luckly, they agreed that was a bad idea
<oliv3r>
mripard: you expect it to be to slow?
<Net147>
oliv3r: hopefully the touchscreen will do at least some clock stretching for polling so you don't have to poll at such a high rate...?
<oliv3r>
well that's what round 1 is for, see all the problems we potentially run into
<oliv3r>
Net147: we haven't picked a touch screen controller chip yet
<mripard>
oliv3r: either you will slow the system down, or you'll have input latency and / or missed input
<oliv3r>
but that's a good point, we should start ordering a few and start connecting them to see what works
<mripard>
getting the right balance will probably be tricky
<oliv3r>
mripard: you expect such a high overhead?
<oliv3r>
cpu-load wise?
<oliv3r>
well first we gotta try it :)
<oliv3r>
if it turns out we can't do it without the interrupt, well then that plan needs to be adjusted
<wens>
polling always incurs cpu overhead
<oliv3r>
of course
<wens>
how much depends on how slow your I2C + touchscreen controller are
<wens>
given that the A20 isn't very powerful...
Gerwin_J has quit [Read error: Connection reset by peer]
<oliv3r>
absolutly valid points
<oliv3r>
so we'll just have to try and see
<oliv3r>
we are using about 75% of 1 core atm i guess
<oliv3r>
but i'll let you all know how it fares :)
Gerwin_J has joined #linux-sunxi
<oliv3r>
is usb in that regard any beter?
<oliv3r>
since usb is often also host based
<Net147>
USB you get some jitter due to 1ms polling isn't it?
<oliv3r>
i suppose that would be one alternative, touchscreen -> usb
<oliv3r>
but then we'd add a USB hub chip also as we need more then 1 port
<oliv3r>
or, run dedicated controller wires
asyring has joined #linux-sunxi
<oliv3r>
to bad we can't use the audio return wire :)
<oliv3r>
as a GPIO :p
<asyring>
hi, can I use the "old" clock and the "new" ccu on a20 at the same time for debugging?
<asyring>
or is it exclusive? one or the other?
<MoeIcenowy>
mripard: do you want a patch to sunxi-mali that adds support for mali-450 on H5?
<mripard>
MoeIcenowy: what's different about the mali-450 ?
<MoeIcenowy>
mripard: more PPs and more GPs
<MoeIcenowy>
the mali_create_450mp4_resources function should be called for Mali-450MP4 of H5
<MoeIcenowy>
(oh sorry it's also a function added by me
<MoeIcenowy>
let me paste the patch for you ;-)
nvz has quit [Ping timeout: 240 seconds]
<MoeIcenowy>
but it's still not verified by a good blob
<MoeIcenowy>
ElBarto: Is a HDMI driver possible now for H3/H5/A64 FreeBSD? ;-)
<MoeIcenowy>
such driver is now available on some of my (and jernej's) personal branches of Linux
<ElBarto>
MoeIcenowy: yeah I'm working on efifb right now
<ElBarto>
MoeIcenowy: later I'll look at doing DE2 support
<MoeIcenowy>
but unfortunately U-Boot now cannot pass the FB via EFIFB properly
<ElBarto>
but I need to move to DRM first (our DRM support is crap in FreeBSD ...)
<ElBarto>
what do you mean ?
<ElBarto>
it works in our loader (our loader can interact with efi gop)
<MoeIcenowy>
but unfortunately the EFI GOP implementation in U-Boot is now broken
<MoeIcenowy>
it doesn't support pure DM video
<ElBarto>
mhm, since when ?
<MoeIcenowy>
always
<MoeIcenowy>
The implementation is only for LCD framework
<MoeIcenowy>
then added some code of LCD-DM mixed video framework
nOOb__ has quit [Ping timeout: 248 seconds]
chrisf_ has quit [Ping timeout: 248 seconds]
nvz has quit [Ping timeout: 255 seconds]
chrisf_ has joined #linux-sunxi
<ElBarto>
so it's just incomplete, not broken
nOOb__ has joined #linux-sunxi
<agraf`>
ElBarto: yup, too many frameworks in u-boot :)
nvz has joined #linux-sunxi
<chrisf_>
I'm having trouble with PCSI calls to the ATF. Return values don't make sense (e.g. PCSI version 0x00000021). I'm using the sunxi-v2017.x branch of https://github.com/friendlyarm/u-boot.git that includes a pre-built bl31.bin on an H5. Has anyone got experience of these SMC calls?
<chrisf_>
Might I need to rebuild the ATF? I assume it's the apritzel port?
<ElBarto>
chrisf_: not an ATF expert (in fact I know nothing) but I'm using u-boot mainline + aprizel port for Pine64 and I can start core and reboot/shutdown using PCSI
<chrisf_>
ElBarto: that's encouraging. Pine64 is an A64 right? Did you build the aprizel port yourself?
<ElBarto>
yes and yes :)
<MoeIcenowy>
And I think the apritzel port now supports secondary core starting on H5
<chrisf_>
I'm using a NEO 2 so an H5.
<MoeIcenowy>
I have also NEO2
<MoeIcenowy>
and Linux can do PSCI properly on it
<chrisf_>
It may be something I'm doing wrong (obv). I've checked the assembly is setting up eg X0 with the right code for get PCSI and it comes straight back with 0x21 which should be 0xXXXXYYYY where X and Y are major and minor versions.
<chrisf_>
get PCSI version
<chrisf_>
unless that's version 0.33 ... which doesn't seem likely. I get a stubborn return of 0x01 when I try to start a CPU and no increase in current.
<chrisf_>
Thought the return values should be 0,-1,-2,-3 etc.
<ElBarto>
haven't tried H5 yet, that's on my list for this weekend
<MoeIcenowy>
what function id did you called?
<chrisf_>
84000000
<MoeIcenowy>
I think PSCI0.2 64-bit VERSION function should be 0xc4000000
<MoeIcenowy>
oh got it wrong
<MoeIcenowy>
the VERSION function doesn't have 64-bit version
<MoeIcenowy>
it should be 0x84000000
<chrisf_>
That's what I thought.
<chrisf_>
I don't know what the bl31.bin in the sunxi-v2017.x branch comes from so I'll try to build it fresh.
<MoeIcenowy>
it should be apritzel's
<chrisf_>
built for sun50iw1p1?
<chrisf_>
Mind you, I can't see that affecting version number.
<MoeIcenowy>
yes sun50iw1p1
<chrisf_>
I just built bl31.bin again from source and the binary length is suspiciously similar 20484 vs 20484.
<chrisf_>
but they are different.
<chrisf_>
Same return values from my SMC calls though :(
<chrisf_>
ElBarto: are you making SMC calls directly or using the kernel?
<ElBarto>
chrisf_: the FreeBSD kernel is doing calls, I do nothing :)
chrisf_ has quit [Ping timeout: 248 seconds]
chrisf_ has joined #linux-sunxi
afaerber has quit [Quit: Leaving]
fkluknav has joined #linux-sunxi
<asyring>
plaes: I've saw that these files (include/dt-bindings/clock/sun4i-a10-ccu.h, include/dt-bindings/clock/sun7i-a20-ccu.h, include/dt-bindings/reset/sun4i-a10-ccu.h) aren't included in the dtsi. Is that correct? Where are they used? Does this prevent me to boot up my cubietruck with the ccu-patch-set?
afaerber has joined #linux-sunxi
<wens>
asyring: they will be included after the initial patches have been merged
<wens>
right now the dtsi files would use raw numbers, instead of the macros defined in the headers, to deal with cross tree merge issues
<asyring>
ok i've thought they were lost in patch v4
<asyring>
there is no comment about it in changelog
<smaeul>
chrisf_: the build date is integrated into the ATF binary, so they'll be different. Add BUILD_MESSAGE_TIMESTAMP='"<the date printed by the old binary>"' when you compile or just do a binary diff if it matters
<smaeul>
chrisf_: also, out of curiosity, what toolchain did you use to compile ATF with?
<smaeul>
for me the Linaro gcc works fine, but a gcc I compile myself hangs at enabling the MMU
<chrisf_>
smaeul: The results of my SMC calls are the same so I'm not too fussed.
<chrisf_>
make PLAT=sun50iw1p1 CROSS_COMPILE=aarch64-linux-gnu-
<smaeul>
so your distro's packaged cross toolchain?
<chrisf_>
Linaro GCC 6.3-2017.02
<smaeul>
ok thanks
<chrisf_>
That's the right one to use is it?
<smaeul>
igraltist: make sure you have an aarch64 toolchain, not arm
<smaeul>
chrisf_: if it boots, it's the right one
<chrisf_>
Yes it boots.
<MoeIcenowy>
so I think maybe your code have some problem?
tom_nov has joined #linux-sunxi
Leepty has quit [Ping timeout: 246 seconds]
kloczek has quit [Remote host closed the connection]
<smaeul>
also, just FYI 0x01f01da0 = standby flag register, 0x01f01da4 = cpu0+ (or cpu0 hotplug) entry address register, 0x01f01da8 = standby resume entry address register, and 0x01f01dac = hotplug flag register
<smaeul>
so the documentation is correct
<MoeIcenowy>
what doc?
<smaeul>
h5 manual
<chrisf_>
MoeIcenowy: I guess so. I'm running code directly after ATF so it's SPL->ATF->Custom code. The stack is set up and I get output from the UART. It's running at EL2 so should be able to SMC to EL3. I'm not sure if it's running in secure mode or not at the moment.
<MoeIcenowy>
EL2 doesn't have secure mode
<smaeul>
there was some question in chrisf_'s stackoverflow discussion
<MoeIcenowy>
it's a common sense
<chrisf_>
Thanks. That saved me some time.
<chrisf_>
Guess I've given away my naivety now.
<igraltist>
smaeul: thx for hint
tkaiser has joined #linux-sunxi
<MoeIcenowy>
tkaiser: someone seems to be from Xunlong told me that early OPi Zero Wi-Fi issue is board problem
<chrisf_>
Strange though because the disassembly looks fine. Loads correct value into X0
<chrisf_>
and executes SMC #0
<MoeIcenowy>
and v1.4 fixed it
<tkaiser>
MoeIcenowy: I heard this too and asked in Armbian forum users who have 1.1 and 1.4 lying next together. No response :(
<MoeIcenowy>
maybe I should request a V1.4?
<MoeIcenowy>
mine is V1.1, even with no SPI NOR pre-soldered
<MoeIcenowy>
and my soldering skill is terrible
<tkaiser>
Mine is also v1.1, no SPI NOR flash, broken Wi-Fi (after I glued a heatsink). My soldering skills are even worse than yours and I can kill boards by looking at them
f0xx has joined #linux-sunxi
<tkaiser>
MoeIcenowy: With 1.4 temperature readouts are also much higher. Steven said that only 'temperature base' has changed... hmm...
Leepty has joined #linux-sunxi
<tkaiser>
MoeIcenowy: But they changed power related stuff there. Some close-ups: https://forum.armbian.com/index.php?/topic/4313-new-opi-zero-yet-another-high-temperature-issue/
<chrisf_>
Embarassing typo. PCSI version is 0.2 and CPU_ON is returning 0x0000. Sorry to have wasted your time. Hate it when that happens.
<MoeIcenowy>
chrisf_: how do you do it successfully?
<chrisf_>
Oh, it's too embarrassing to say ... I was printf'ing %lx for long hex format only it was %xl so I got a sodding "1" which wasn't a "1" on all my reports.
<chrisf_>
Not funny.
<MoeIcenowy>
interesting ;-)
lamer15003757358 has joined #linux-sunxi
<chrisf_>
yes. indeed. still not booted another cpu but at least the smc calls make sense.
tkaiser has quit [Ping timeout: 260 seconds]
lamer15003761725 has joined #linux-sunxi
lamer15003757358 has quit [Ping timeout: 248 seconds]
lamer15003761725 has quit [Client Quit]
FergusL has joined #linux-sunxi
diego_r has quit [Ping timeout: 260 seconds]
cnxsoft1 has joined #linux-sunxi
cnxsoft has quit [Ping timeout: 255 seconds]
cnxsoft1 is now known as cnxsoft
BenG83 has joined #linux-sunxi
<Net147>
beeble: wens: PA17 (ETXERR) needs to be driven low on A20-OLinuXino-A20 Rev J for ethernet to work, otherwise transmit will fail
<Net147>
beeble: wens: on A20-OLinuXino-MICRO
<ElBarto>
Net147: I've briefly tested again my A20-Olinuxino and it seems that ethernet doesn't work on u-boot, have you seens this too ?
<Net147>
we could just drive PA17 low for all board revisions if it doesn't prevent RTL8102CP from working properly. otherwise we would need a new board definition for Rev J.
chlorine has joined #linux-sunxi
lkcl has quit [Ping timeout: 260 seconds]
marble_visions has joined #linux-sunxi
marble_visions has left #linux-sunxi [#linux-sunxi]
perr has joined #linux-sunxi
fkluknav has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
perr has quit [Remote host closed the connection]
perr has joined #linux-sunxi
lemonzest has joined #linux-sunxi
shadeslayer has joined #linux-sunxi
specing has joined #linux-sunxi
matthias_bgg has quit [Ping timeout: 240 seconds]
fkluknav has quit [Ping timeout: 268 seconds]
nvz has joined #linux-sunxi
nvz has quit [Remote host closed the connection]
nvz has joined #linux-sunxi
cnxsoft has quit [Quit: cnxsoft]
fkluknav has joined #linux-sunxi
chlorine has quit [Ping timeout: 255 seconds]
f0xx has quit [Ping timeout: 276 seconds]
<chrisf_>
MoeIcenowy: :D I just started up my first ever secondary core!! Thanks for the help.
<MoeIcenowy>
oh congrats
<BenG83>
does anyone know if A64 can boot from NAND flash?
phil42 has quit [Remote host closed the connection]
perr has quit [Remote host closed the connection]
perr has joined #linux-sunxi
chlorine has joined #linux-sunxi
dave0x6d has joined #linux-sunxi
<MoeIcenowy>
BenG83: see,s
<MoeIcenowy>
seems
<MoeIcenowy>
but currently no such device available
perr has quit [Remote host closed the connection]
<BenG83>
there was someone asking over on Pine64 and I saw that the whole of PortC is routed to the header
<BenG83>
so electrically it may be even possible to connect one
perr has joined #linux-sunxi
perr has joined #linux-sunxi
<BenG83>
but as you said, I havent seen a A64 device with NAND either
<BenG83>
chrisf_, are you doing bare metal programming?
<BenG83>
I have some Xilinx dual core A9/FPGA SoC at work that runs Linux on one core and FreeRTOS on the other
Andy-D__ has joined #linux-sunxi
reinforce has quit [Quit: Leaving.]
f0xx has joined #linux-sunxi
<Pe3ucTop>
Hello to all, question about Boot-SPI-Flash and sizes for u-boot/dtb/kernel/root , in all examples I see 1M for u-boot , coult it be less ??
<Pe3ucTop>
could it be 512K (
jstein has quit [Remote host closed the connection]
f0xx has quit [Ping timeout: 248 seconds]
Gerwin_J has quit [Quit: Gerwin_J]
Gerwin_J has joined #linux-sunxi
Gerwin_J has quit [Client Quit]
BenG83 has quit [Quit: Leaving]
tkaiser has joined #linux-sunxi
fkluknav has quit [Ping timeout: 248 seconds]
yann has joined #linux-sunxi
matthias_bgg has joined #linux-sunxi
perr has quit [Quit: Leaving]
fkluknav has joined #linux-sunxi
phil42 has joined #linux-sunxi
reinforce has joined #linux-sunxi
jstein_ has joined #linux-sunxi
jstein_ is now known as jstein
<chrisf_>
q
chrisf_ has quit [Quit: Ex-Chat]
dev1990 has joined #linux-sunxi
netlynx has joined #linux-sunxi
netlynx has joined #linux-sunxi
netlynx has quit [Changing host]
msimpson has quit [Quit: Leaving]
phipli has joined #linux-sunxi
Andy-D__ has quit [Ping timeout: 255 seconds]
Ntemis has joined #linux-sunxi
matthias_bgg has quit [Quit: Leaving]
BenG83 has joined #linux-sunxi
pmpp has quit [Ping timeout: 246 seconds]
leviathan_ has joined #linux-sunxi
vagrantc has joined #linux-sunxi
phipli has quit [Ping timeout: 255 seconds]
pmpp has joined #linux-sunxi
phipli has joined #linux-sunxi
yann has quit [Ping timeout: 240 seconds]
pmpp has quit [Ping timeout: 240 seconds]
jstein has quit [Remote host closed the connection]
tkaiser has quit [Ping timeout: 240 seconds]
pmpp has joined #linux-sunxi
chlorine has joined #linux-sunxi
chlorine has quit [Ping timeout: 276 seconds]
lkcl has joined #linux-sunxi
chrisf_ has joined #linux-sunxi
<chrisf_>
Need to get some interrupt handlers working in my SPL->ATF->Custom code. Am I fiddling direct with GICD/GICC registers from EL2 or is there something in the ATF? I read that the ATF "sets up" the GICv2 in the H5 but am struggling with detail. Tips/pointers gratefully received!
BenG83_ has joined #linux-sunxi
deep-book-gk_ has joined #linux-sunxi
deep-book-gk_ has left #linux-sunxi [#linux-sunxi]
tom_nov has quit [Ping timeout: 260 seconds]
pmpp has quit [Quit: No Ping reply in 180 seconds.]
pmpp has joined #linux-sunxi
netlynx has quit [Quit: Ex-Chat]
pmpp has quit [Quit: No Ping reply in 180 seconds.]