<apritzel>
gets even weirder... apparently some parts of the SRAM are flaky, at least on my board
<apritzel>
adding debug code shifts this into a data region, so I see some wrong output strings, but it works
<apritzel>
removing this debug code make it crash, presumably because the faulty byte(s) are now in code
<apritzel>
compiling with DEBUG=0 works though
<apritzel>
like this: "arm_gic_cpuif_setup on MPIDR 0
<apritzel>
arm_gic_distif_setup on MPIgR 0"
<apritzel>
the second "MPIDR" is wrong
<apritzel>
with some debug code I get this: "arm_gic_setup, MPIDR: llu" (so the % got lost somehow, so it prints the format specifier instead of the number)
<ssvb>
apritzel: this might be also a symptom of the stack overwriting your data section
<apritzel>
you mean the FEL stack backup?
<apritzel>
I checked in fel.c that you use 0x1.8000 till 0x2.0000 only
<ssvb>
I mean the ATF stack growing down and overwriting the ATF const data section
<apritzel>
mmh, possible, though unlikely
<apritzel>
the stack is 1K per CPU
<apritzel>
and loading everything into SRAM A2 works without crashes or broken strings
<apritzel>
looks like a job for a memtester ;-)
<ssvb>
yeah, if the same test with the SRAM A2 works fine, then something is not right
<ssvb>
^ this is a comparison of two SRAM dumps from A13, the uninitialized area seems to be somewhat deterministic with some unstable bits :)
kaspter has joined #linux-sunxi
<ssvb>
it's very strange to see such single byte errors inside of string constants in your log
<willmore>
apritzel, they forgot to declare the loop variable volatile?
<willmore>
I don't know if this is relevant, but I remember a problem on an ARM system over a decade ago where early boot would turn the caches on and later we would turn them back off. The problem was that turning them off doesn't really turn them off.
<willmore>
It basically means that new data won't get written to them, but old data in them will still be read.
<willmore>
An explicit 'flush the cache' sequence needed to be done to get the cache to really be empty.
khuey is now known as khuey|away
<willmore>
That was a realy PITA to solve.
gzamboni has joined #linux-sunxi
<apritzel>
willmore: yeah, this is a common ARM problem
<apritzel>
that udelay() implementation looked really involved on the first glance, but the compiler was smarter and optimized it away
<willmore>
For the life of me I couldn't figure out why my FLASH programming routine kept failing and the error pattern was so similar every time...
<willmore>
Good compiler!
<apritzel>
interestingly they didn't even realise it, so every udelay() call in ATF is actually snake oil ;-)
<apritzel>
(in the Allwinner port of ATF, that is)
engidea-vr has quit [Quit: Konversation terminated!]
engideavr has joined #linux-sunxi
<lennyraposo>
hey longsleep are you about?
JohnDoe_71Rus has joined #linux-sunxi
IgorPec has joined #linux-sunxi
reinforce has joined #linux-sunxi
jernej_ has quit [Ping timeout: 244 seconds]
IgorPec has quit [Ping timeout: 250 seconds]
juri_ has quit [Ping timeout: 250 seconds]
fl_0 has quit [Ping timeout: 250 seconds]
fl_0 has joined #linux-sunxi
al1o has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<pitillo>
hello, is there available prebuilt kernel images and modules for the pine64b?
edolnx has quit [Ping timeout: 250 seconds]
edolnx has joined #linux-sunxi
IgorPec has joined #linux-sunxi
reev has joined #linux-sunxi
juri_ has joined #linux-sunxi
Amit_T has joined #linux-sunxi
apritzel has joined #linux-sunxi
Gerwin_J has joined #linux-sunxi
premoboss has joined #linux-sunxi
iamfrankenstein has joined #linux-sunxi
The_Loko has joined #linux-sunxi
<apritzel>
willmore: ATF = ARM Trusted Firmware, that's the part that offers PSCI services and does all the 64-bit initialization on the Pine64
<apritzel>
agraf: for the records: in contrast to the manual there does not seem to be SRAM from 0x3.3000 till 0x4.0000 on the A64 - at least on my board
<agraf>
apritzel: hooray :)
avph has quit [Ping timeout: 250 seconds]
<apritzel>
agraf: at least it's not accessible - as both FEL and ATF run in monitor/EL3 mode, I doubt that it's a secure thing
<apritzel>
agraf: but on the bright side: ATF runs in SRAM now!
<agraf>
great :)
<apritzel>
I just load it at 0x20000 and that works (plus some patches to limit the ATF sections to the 64KB is actually needs)
<agraf>
how fast is sram access compared to caches?
<apritzel>
feels really fast with U-Boot's md.l ;-)
<apritzel>
honestly: didn't check and don't care anyway at this stage
<agraf>
I'm wondering whether it'd make sense to put our EL2 KVM code there
<agraf>
not that it matters with v8.1
<apritzel>
v8.1? Pine64?
<agraf>
unrelated to pine
<apritzel>
I am not sure if SRAM is always meant to be fast on those SoC, it just doesn't need initialization and can be easily made secure only
<apritzel>
also you can give a small region easily to some firmware service or some other blob
avph has joined #linux-sunxi
IgorPec has quit [Ping timeout: 252 seconds]
<Amit_T>
apritzel: Sorry my understanding is bit low here but how did you load ATF into sram, through EFL ?
<agraf>
apritzel: well, sram is always faster than dram fwiw
<apritzel>
agraf: maybe, but that also depends on how it's connected to the bus
<apritzel>
agraf: and I am pretty sure it's slower than the caches
<agraf>
apritzel: hm, and we expect few cache misses in hot paths anyway
<agraf>
apritzel: oh well :)
<apritzel>
since the caches are connected very tight to the core, while the SRAM accesses have to go through an arbitrated bus, which is probably only 32-bits wide
<apritzel>
also clocked much slower
avph has quit [Ping timeout: 250 seconds]
<Amit_T>
I meant through FEL ?
<apritzel>
Amit_T: yes, through FEL for the time being
<apritzel>
but I will switch over to boot0 loading tonight
<apritzel>
not sure boot0 really respects the load address in that header before the ATF, but I am ready to hack some small memcpy / trampoline code
<NiteHawk>
btw, which FEL utility are you using - from ssvb's A64 branch?
<Amit_T>
ok and where boot0 is programmed, in some kind of flash ?
<apritzel>
NiteHawk: yes
<apritzel>
Amit_T: there is no flash on the Pine64. It's all from SD card or via FEL
<Amit_T>
ok, so many questions , I can access the FEL through the same OTG port(but yesterday you menation there is no boot over USB support)
avph has joined #linux-sunxi
<Amit_T>
apritzel: Oh I think you are loading FEL code into sd card and from there on ATF and u-boot?
<apritzel>
Amit_T: you was asking for U-Boot and USB
<Amit_T>
Yes
<apritzel>
there is a small boot ROM in the SoC, which can load code via USB OTG very early if there is no SD card
<apritzel>
this has nothing to do with U-Boot
<apritzel>
U-Boot still can't use USB - that was your question yesterday
<apritzel>
so FEL code works without a SD card, which is the neat part of it
<apritzel>
I will document my steps in the Wiki later (now that ATF is in an usable state for me)
<Amit_T>
Sorry I just could not ask it properly , I am looking a way to reach at u-boot prompt just like I am doing it on Orangepipc and now you answered it.
<apritzel>
Yes, I have a U-Boot prompt without any SD card by just loading stuff via sunxi-fel over USB
<apritzel>
I also booted Linux and an initrd on the same way
<Amit_T>
but I have more doubt , On pine64 I have one only one OTG port(micro USB) and that is for power supply .
kaspter has quit [Remote host closed the connection]
<apritzel>
it's the upper USB port
<apritzel>
you need an USB-A <-> USB-A cable
<apritzel>
non-standard, but all over EBay ;-)
<Amit_T>
oh no my expenses are keep getting increasing :(
<apritzel>
it's very cheap, though
ricardocrudo has joined #linux-sunxi
<apritzel>
the annoying part is just that your shop around the corner usually doesn't have it, so you have to order and wait for it
avph has quit [Ping timeout: 250 seconds]
luoyi has joined #linux-sunxi
<luoyi>
does anyone have used the mainline linux 4.5.2 kernel with Banana Pi M1+ ? looks like the wifi driver is not usable.
<zoobab>
that's the big missing part for the H3 openwrt port
<zoobab>
any intent to backport it to an LTS release like 4.4?
<zoobab>
openwrt sticks to LTS kernels, but wigyori told me there were lots of changes in the network stack, and that was a lot of work to backport that
doppo has quit [Ping timeout: 250 seconds]
doppo has joined #linux-sunxi
<oneinsect>
hmm apritzel: i cant seem to find the dts file...i generally mainline from armbian
<apritzel>
zoobab: you could give it a try: the driver is just one file, you could download it from montjoie's github and just add it to the Makefile of a 4.4 kernel and see what happens
<oneinsect>
i am trying to get that RTC clock working
<oneinsect>
but its not detecting
<oneinsect>
i will try again
<oneinsect>
with RC4
doppo has quit [Ping timeout: 250 seconds]
<oneinsect>
DS3231 PRECISION RTC
<apritzel>
oneinsect: I used something similar, using i2ctools to directly poke the RTC registers
<oneinsect>
hmm
<oneinsect>
i will
doppo has joined #linux-sunxi
<apritzel>
wiring it up as a proper RTC detected by the kernel is probably more involved
<speakman>
what apritzel said
<oneinsect>
i2ctools is there in apt?
<speakman>
DS3231 is 100% compatible with DS1307 so you can use that kernel driver to hook it up onto the i2c bus and then use "hwclock" tool on it.
* speakman
is using it as we speak on A20
<oneinsect>
indeed i had used ds1307 before on rpi
<oneinsect>
let me boot mainline
<oneinsect>
and check
<speakman>
Don't use i2ctools
<oneinsect>
then?
<oneinsect>
hwclock will directly detect it?
<speakman>
it doesn't have to
<speakman>
What are you trying to do? Just add a working RTC clock into your project?
<speakman>
What CPU exactly?
doppo has quit [Ping timeout: 268 seconds]
<oneinsect>
nanopim1 which is exactly as orange pi pc
<oneinsect>
i need to add an RTC clock for my projects
<oneinsect>
which will update itself via gps connected via serial port
<oneinsect>
i used gpsd, ntpd etc
<speakman>
ok, because some of the Allwinner CPU does already include one RTC, just wanted to check that first.
<oneinsect>
well yes
<speakman>
First of all, make sure you have REMOVED any sunxi-rtc support in the kernel.
<oneinsect>
interestingly this board has no rtc clock
<speakman>
Then make sure you have DS1307 support compiled-in to the kernel.
<oneinsect>
maxim support via kernel config right?
<speakman>
Yes
<oneinsect>
okie i will
<speakman>
I don't like separate modules on minor projects, but it's up to you how you solve it. Just make sure it's built and available during boot.
<oneinsect>
i am gonna recompile the kernel now
<oneinsect>
yes i dont like seperate modules as well
<speakman>
(hence I mark all device drivers for "built-in" rather than "module")
<mripard>
speakman: you don't have to disable it
<speakman>
great
<speakman>
mripard: just a to be sure
<speakman>
be sure it won't take up /dev/rtc0
<oneinsect>
but even if it does....i am anyway connected a maxim ic instead of the their own RTC clock
<oneinsect>
so should it just work
<oneinsect>
on the same clock lines i mean
<speakman>
oneinsect: how ever, in a boot script, but "echo ds1307 0x68 > /sys/class/i2c-adapter/i2c-2/new_device"
<speakman>
but = put
<oneinsect>
yes
<speakman>
change i2c-2 into what ever i2c bus you're using
<oneinsect>
yes
<speakman>
(the kernel will tell you if it doesn't find the rtc)
<oneinsect>
indeed
<oneinsect>
okie starting compile
<oneinsect>
waiting for menu-config
<speakman>
after that, you will have a new file in /dev called rtc0
<oneinsect>
hmmm
<speakman>
Now you can use "hwclock" for setting system and hardware clock
<speakman>
It will by default use /dev/rtc0
afaerber has quit [Quit: Ex-Chat]
<oneinsect>
are you guys here for a few? i am gonna try it and report back
<oneinsect>
?
<speakman>
And while I'm at it; the rtc will need to be re-writting continously (to keep up with the current system time, which has a way higher precision)
<speakman>
oneinsect: for a few..?
<speakman>
:D
<oneinsect>
minutes
<speakman>
I have written a background script which every 30 minutes will run hwclock -w -u
<oneinsect>
in raspberry pi...i just connect NTPD to gps on a serial port via gpsd daemon
<oneinsect>
it picks up automatically
<speakman>
I havn't found any "best practice" on this, and there are probably tools out there to fix this automatically. Maybe mripard or apritzel or someone else have some better suggestions?
<oneinsect>
the moment there is a gps signal
<oneinsect>
and autocorrects time
<oneinsect>
probably then my scripts waits for the gps to pick up signals and show correct and then starts its process of video monitoring
<oneinsect>
correct time*
<speakman>
You probably want the system time to be set up way before first contact with GPS is established.
pitelpan has quit [Ping timeout: 260 seconds]
<oneinsect>
correct ...it should be since the last clock sync will help it maintain it
<speakman>
And you will need to write new system time to hardware (rtc) on regulary basis.
<oneinsect>
aha
<oneinsect>
wont ntpd do it? does it only set system time? does it not sync it to hwclock?
avph has quit [Read error: Connection reset by peer]
<oneinsect>
becoz i know it syncs system2hwclock during shutdown
avph has joined #linux-sunxi
<oneinsect>
but what if i dont cleanly shut down
<oneinsect>
you are right speakman:
<oneinsect>
may be i need a script for syncing hwclock regularly
kaspter has quit [Ping timeout: 244 seconds]
doppo has joined #linux-sunxi
<speakman>
No idea what ntpd is capable of, sorry
<montjoie>
first you need monitoring :)
<oneinsect>
monitoring of what monty
<montjoie>
checking ntp/hwclock derive
<oneinsect>
hmmm
pitelpan has joined #linux-sunxi
bwarff has quit [Ping timeout: 252 seconds]
afaerber has joined #linux-sunxi
tomboy64 has quit [Ping timeout: 268 seconds]
afaerber has quit [Ping timeout: 250 seconds]
afaerber has joined #linux-sunxi
tomboy64 has joined #linux-sunxi
oneinsect has quit [Ping timeout: 250 seconds]
iamfrankenstein has quit [Quit: iamfrankenstein]
cnxsoft has quit [Quit: cnxsoft]
avph has quit [Ping timeout: 250 seconds]
avph has joined #linux-sunxi
apritzel has quit [Ping timeout: 244 seconds]
The_Loko has quit [Quit: Leaving]
psychedup74 has joined #linux-sunxi
luoyi has joined #linux-sunxi
nove has joined #linux-sunxi
Gerwin_J has quit [Quit: Gerwin_J]
JohnDoe_71Rus has joined #linux-sunxi
zuikis has joined #linux-sunxi
apritzel has joined #linux-sunxi
psychedup74 has quit [Quit: leaving]
deskwizard has quit [Quit: Leaving]
oneinsect has joined #linux-sunxi
akaWolf has quit [Ping timeout: 244 seconds]
dev1990 has joined #linux-sunxi
akaWolf has joined #linux-sunxi
jernej_ has joined #linux-sunxi
<oneinsect>
does orange pi pc has good usb support
<oneinsect>
[*]Enable loadable module support ---> Device Drivers --->Graphics support --->Frame buffer Devices --->[*]support for frame buffer devices --->[*]Simple framebuffer support Device Drivers --->Graphics support --->Console display driver support --->[*]Framebuffer Console support
<oneinsect>
modprobe: module fbcon not found in modules.dep failed. initramfs emergency recovery shell launched. Type 'exit' to continue boot sh: can't access tty; job control turned off / #
<oneinsect>
atleast
<KotCzarny>
anyway, it booted, which is a bit better than before ;)