domidumont has quit [Remote host closed the connection]
domidumont has joined #linux-sunxi
flok420 has joined #linux-sunxi
mosterta has quit [Ping timeout: 260 seconds]
_massi has joined #linux-sunxi
premoboss has quit [Ping timeout: 264 seconds]
naobsd has quit [Quit: naobsd]
IgorPec has joined #linux-sunxi
premoboss has joined #linux-sunxi
tchiwam has joined #linux-sunxi
tchiwam_ has quit [Ping timeout: 250 seconds]
mark5 has joined #linux-sunxi
ricardocrudo has quit [Ping timeout: 240 seconds]
<mark5>
Hi. I compiled http://linux-sunxi.org/Mainline_U-Boot#Compile_U-Boot for an A10 board which hangs on "DRAM:" according to uart. Anybody who happens to recognize this? (I'm going to try the fail-safe DRAM settings in a bit)
<plaes>
mark5: what board?
<mark5>
plaes: A10-OLinuXino-LIME
cosm has quit [Quit: Leaving]
<plaes>
I assume you used the A10-OLinuXino-Lime_defconfig ?
<mark5>
make CROSS_COMPILE=arm-linux-gnueabihf- A10-OLinuXino-Lime_config
<rellla>
have i missed sth or is the H3 display driver not cc'ed for linux-sunxi ml?
<mark5>
plaes: Yes I did. I'm now gonna try with the v2016.01 tag as well as with 'defconfig'
<plaes>
rellla: it wasn't
ricardocrudo has quit [Ping timeout: 240 seconds]
<mark5>
plaes: I'm wondering, the U-boot guide only mentions that you should copy u-boot-sunxi-with-spl.bin onto the SD, but then http://linux-sunxi.org/Mainline_U-Boot#U-Boot_2015.07.2B_won.27t_start mentions using u-boot-dtb.bin and u-boot-dtb.img.. do I need those?
<plaes>
no, things changed after 2015.07
<mark5>
I see
<plaes>
mark5: please recheck the Mainline U-boot page
<plaes>
I edited it a bit..
<plaes>
starting from "Determine build target"
<mark5>
alright :)
<plaes>
moved it around a bit
<plaes>
ok, that should be enough
<mark5>
Booting from the v2016.01 now with defconfig
<mark5>
passed DRAM now :) currently Starting kernel
<mark5>
plaes: i switched from building uImage to zImage but the old uimage was still on the SD.. apparently it booted that even though the boot.scr does not contain instructions to load that
<mark5>
removed the uImage and now it does something more \o/
<mark5>
Unless.. you do not update the boot.scr to point to zImage
<mark5>
This is not one of my brightest days
<plaes>
well, it happens ;)
<apritzel>
Oh dear, from Allwinner's ATF port for the Pine64: counter_base_frequency = 24<<20;
<plaes>
o_O
<apritzel>
I take it the arch timer is clocked from that 24MHz clock?
<apritzel>
so we are 4.8% off ;-)
<NiteHawk>
oh, that's noteworthy - u-boot hangs with a non-helpful "starting kernel" if you accidentally provide a uImage instead of zImage for bootz?
<apritzel>
NiteHawk: no, it should detect this and barf
<plaes>
what was the command to print out env in u-boot?
<apritzel>
NiteHawk: something like "Bad Linux ARM zImage magic!"
<NiteHawk>
apritzel: thx. then i misunderstood mark5's problem - i guess that uImage (setup in boot.scr) might still have been a legacy (3.4) kernel then
<wens>
apritzel: what do you mean 4.8% off?
<apritzel>
24 shift left 20 is not 24 MHz
<wens>
hehe
<plaes>
it's 25165824 Hz
<wens>
ok that was stupid
paulk-collins has joined #linux-sunxi
<apritzel>
Linux is diligently reporting 25.1 MHz, so any timing in the kernel would be ~5% off
<apritzel>
plaes: have you found "printenv" already?
<ssvb>
apritzel: regarding "I managed to load upstream U-Boot with boot0" - great news, thanks!
<apritzel>
ssvb: well, pat yourself on the shoulder, it's your U-Boot port that runs ...
<apritzel>
I just adjusted the TEXT_BASE to make room for the header and commented the CNTFRQ write which does not work in non-secure
<apritzel>
ssvb: btw: you can find the booti patch in my u-boot github repo, but that one relies on ARM trusted firmware
<apritzel>
so it does not work when loaded via FEL
<apritzel>
if there a nice way to load additional blobs into RAM from U-Boot's SPL code?
<apritzel>
So apart from the actual U-Boot image?
<apritzel>
Or would we somehow append ATF to that image?
<ssvb>
on older SoCs the limit is 24KiB, and that's why we care so much about the SPL size
<ssvb>
A64 raises this limit to 32KiB, which provides us with a bit more space
Nyuutwo has joined #linux-sunxi
<ssvb>
we can also use a runtime decompression stub to gain even more space
<apritzel>
Oh, it was 24 KB only before, I missed that
<apritzel>
I just remember that building for SPL for my BananaPi was pretty tight
<apritzel>
from the backer mail from pine64.com: "Your PINE64 will arrive in a protective cardboard box...."
<ssvb>
they have learned their lesson :-)
<apritzel>
indeed
<ssvb>
too bad that the 64-bit SPL would make FEL boot problematic
<mark5>
So how do I go about debugging a mainline kernel/uboot hanging at 'Starting kernel...' ? earlyprintk does not give me any extra info
<ssvb>
mark5: maybe start with something that is known to work?
<mark5>
ssvb: Such as?
<ssvb>
and then figure out which of your changes break everything?
<ssvb>
mark5: A10-OLinuXino-Lime is supported by the mainline U-Boot and the mainline kernel, just follow the instructions carefully without ad-hoc improvisations and everything should be fine
<mark5>
the dtb file is from ~/linux-4.4/arch/arm/boot/dts/sun4i-a10-olinuxino-lime.dtb
<ssvb>
did you build this sun4i-a10-olinuxino-lime.dtb file yourself?
<mark5>
Yes, with `make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- -j4 zImage dtbs`
<mark5>
(or is that a no? :) )
<plaes>
looks ok
<mark5>
So if you're asking if I used a custom DTC then no
<ssvb>
it's just that dtb files are not very compatible between different kernel versions, so you could run into troubles by picking some existing blob from your sd card image built for some other kernel
<ssvb>
but apparently this is not the case, which is good
bmeneg_ is now known as bmeneg
<ssvb>
everything looks ok to me, don't know what could be the problem
<ssvb>
it would be nice to have a description of the boot0, ATF and U-Boot roles in the boot process
yann|work has quit [Ping timeout: 245 seconds]
<mripard>
mark5: what's your configuration file ?
<apritzel>
ssvb: Yes, I was planning on this, but spend the whole night yesterday inserting debug("I was here\n") lines into board_f.c and board_r.c ;-)
<plaes>
mark5: did you use sunxi_defconfig?
<plaes>
for kernel
<mark5>
ssvb: you might be onto something there.. The toolchain for debian described here http://linux-sunxi.org/Toolchain#Debian scared me a bit because of the words 'unstable' and 'testing', so I used this recommended by someone else; 'apt-get install gcc-4.7-arm-linux-gnueabihf'
<mark5>
And symlinks which remove the -4.7
<mark5>
plaes: as the basis yes, but with plenty of changes. I will try to recompile the kernel with pure sunxi_defconfig to rule that out
Gerwin_J has joined #linux-sunxi
<mark5>
mripard: which configuration file do you mean?
<apritzel>
mark5: he talks about your .config
<plaes>
kernel
<mark5>
Ah ok
<apritzel>
if you for instance miss the CONFIG_SERIAL_8250_DW option, there will be no output
sid14726 has quit [Ping timeout: 252 seconds]
<apritzel>
which sunix_defconfig would take care of
<mark5>
apritzel: CONFIG_SERIAL_8250_DW=y
<mark5>
check
<mark5>
Brb, grabbing lunch
Nacho has quit [Ping timeout: 245 seconds]
Nacho has joined #linux-sunxi
fl_0 has quit [Ping timeout: 252 seconds]
<apritzel>
ssvb: I fixed the Wiki in respect to the Pine64 boot sequence
BarthezZ has joined #linux-sunxi
fl_0 has joined #linux-sunxi
paulk-collins has quit [Remote host closed the connection]
domidumont has quit [Read error: Connection reset by peer]
<ssvb>
apritzel: thanks! that's much appreciated
clonak has quit [Ping timeout: 272 seconds]
tkaiser has joined #linux-sunxi
<tkaiser>
Today my Orange Pi One arrived and I simply gave it a try based on Armbian's Orange Pi H3 image (based on ssvb
<tkaiser>
's kernel and mainline u-boot): I only changed pmuic_type = 1 in the fex file but to no avail. "ARISC ERROR" flooding the log: http://pastebin.com/Q3taqHbL
<ssvb>
tkaiser: my guess is that arisc is trying to use the sy8106a pmic and fails
<ssvb>
the arisc (openrisc) core is responsible for dvfs on h3
<tkaiser>
Yes, I just had a look at the orangepi.org site to look for new OS images. Seems there's nothing.
<tkaiser>
But the funny thing is: By changing "pmuic_type = 1" I was able to further increase the SoC's internal temperature.
clonak has joined #linux-sunxi
<ssvb>
tkaiser: but the mainline kernel is going to be probably working fine on it :-)
sid14726 has joined #linux-sunxi
<tkaiser>
Sure, but I want to play with the camera module I ordered again so no easy way to escape from 3.4 ;)
<mark5>
plaes: No, just this one. But I'll try to use the g++-arm-linux-gnueabihf compiler
<tkaiser>
ssvb: I've been wrong: changed back to pmuic_type = 2 and rebooted: Higher temperature again. Then I did a shutdown, disconnected PSU and after the next boot the temperature was as low as in the beginning. So this is a reboot issue and my assumption regarding pmuic_type was wrong
FDCX has joined #linux-sunxi
Worf has quit [Quit: Konversation terminated!]
yann|work has joined #linux-sunxi
viccuad has quit [Ping timeout: 276 seconds]
JohnDoe_71Rus has quit [Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org]
viccuad has joined #linux-sunxi
naobsd has joined #linux-sunxi
cnxsoft has quit [Remote host closed the connection]
engideavr has quit [Quit: Konversation terminated!]
cosm has quit [Ping timeout: 272 seconds]
<tkaiser>
ssvb: LOL, I had to start lima-memtester on the Orange Pi One to realise that the two LEDs are also present there
<jelle>
it's still only 5 euro's cheaper then the pc hrrm
<tkaiser>
jelle: Yes, it's pretty limited but if you don't need all the missing stuff you save the $5
<tkaiser>
And I'm still wondering what the differences between A64, H64 and R18 are ;)
<mripard>
tkaiser: if we take the R8 / A13 as an example
<mripard>
none
<mripard>
there was initially a different package
<ssvb>
R8M?
<mripard>
but then, they shipped R8s with the exact same package than the A13
<mripard>
ssvb: R8M was a complete module, with a R8, NAND and RAM
<wens>
feels more like marketing
<mripard>
my guess is that they initially created it with a different package for the R8M
<mripard>
and then re-purposed old A13
<apritzel>
tkaiser: The H64 seems to be just a special bin of the A64: Too much heat dissipation for being used in a fanless tablet
<apritzel>
but good enough for some passively cooled set-top box, for instance
domidumont has joined #linux-sunxi
<tkaiser>
I still believe it's more about marketing. A --> mobile, H --> OTT box, R --> IoT but basically everything the same and just artificial differentiation
<tkaiser>
I tried to boot a H8 OS image for pcDuino on Banana Pi and Allwinner's boot0/SPL complained about wrong chip ID.
<tkaiser>
I used the stuff for the Banana Pi M3 (A83T): sudo dd if=boot0_sdcard.fex of=${card} bs=1k seek=8
<tkaiser>
And then everything was ok except DRAM voltage
_massi has quit [Remote host closed the connection]
cptG_ has quit [Remote host closed the connection]
reinforce has quit [Quit: Leaving.]
mzki has quit [Quit: leaving]
sid14726 has quit [Max SendQ exceeded]
afaerber has quit [Quit: Ex-Chat]
viccuad has quit [Ping timeout: 248 seconds]
tkaiser has joined #linux-sunxi
<tkaiser>
ssvb: The Orange Pi One even survives 744MHz lima-memtester. Should I trust in this result given that voltage regulation doesn't work (es intended)?
<ssvb>
tkaiser: if you can see the animated spinning cube on a monitor, then probably yes
<ssvb>
in any case, successfully passing the lima-memtester test does not guarantee perfect reliability
domidumont has joined #linux-sunxi
<ssvb>
only failing it means that the hardware is unreliable with the selected dram setup
<tkaiser>
ssvb: Yes, I would consider passing 744MHz some safety headroom for using 672MHz. Will connect the display later. Until now I just tested headless.
<tkaiser>
Is the memtester comparable with memtest for x86?
<tkaiser>
Same patterns/strategies?
<ssvb>
yes, to some extent
<ssvb>
it just writes the same patterns to two buffers in memory and then compares these buffers
<ssvb>
surprisingly, the selected patterns are quite good at detecting problems
tomboy64 has joined #linux-sunxi
<tkaiser>
Ok, we made the experience with x86 servers that they pass 72 hours 'burn in' memtest without issues just to throw single bit ECC errors when in productive use later every few weeks/months
pmattern has joined #linux-sunxi
<ssvb>
do you mean memtest86?
<tkaiser>
I think we used this. I gave up on the hardware side of server business in the meantime
tomboy65 has quit [Ping timeout: 276 seconds]
<ssvb>
yes, memtest86 failed me at least twice
<tkaiser>
A device passed the RAM test but failed in normal use?
<ssvb>
first I had an amd64 desktop computer at my workplace many years ago (one of the first x86-64 boxes) which was successfully passing the memtest86 test, but consistently segfaulting when GCC was rebuilding itself
tomboy65 has joined #linux-sunxi
<ssvb>
resolved this by adjusting voltages in BIOS setup
interrobangd has joined #linux-sunxi
tomboy64 has quit [Ping timeout: 256 seconds]
afaerber has joined #linux-sunxi
<ssvb>
actually this was a major PITA, because it was difficult to say whether it was an immature amd64 port of GCC causing troubles or the hardware
<tkaiser>
Understandable. And that's what a tool like memtest86 is made for -- nailing the problem down
<ssvb>
resolved this problem by just buying different DIMM modules
<tkaiser>
Good to know. Unreliable DRAM is always PITA. And a tool not able to detect that sucks
bmeneg has quit [Quit: \o]
<montjoie>
hello anyone got i2c working on A83T ? I have enabled it but got "i2c-0: mv64xxx: I2C bus locked, block: 1, time_left: 0"
<ssvb>
tkaiser: ironically, the recipe for easily reproducing the problem was exactly the same as on sunxi hardware: 3D graphics workload + userspace memtester program to the rescue :-)
<tkaiser>
ssvb: Yes, seems you've to push the hardware to the limits to find weaknesses
tomboy64 has joined #linux-sunxi
tomboy65 has quit [Ping timeout: 240 seconds]
<tkaiser>
And this userspace memtester used different patterns than memtest86?
sid14726 has joined #linux-sunxi
<mripard>
montjoie: have you checked your muxing ?
<montjoie>
mripard: I have just found a thread where you say to use PULL_UP instead of NO_PULL
<montjoie>
mripard: I have enabled ac200 power in uboot
<montjoie>
and PH2/3 are enabled "sun8i-a83t-pinctrl 1c20800.pinctrl: request pin 226 (PH2) for 1c2b000.i2c"
<montjoie>
same log for PH0/1/2/3
<montjoie>
exactly ac200 DLDO4 set to 3.3
pmattern has quit [Quit: Genug für heute.]
<mripard>
hmm, then I don't know
<mripard>
I guess you don't have a logical analyzer ?
tkaiser has quit [Read error: Connection reset by peer]
ninolein has quit [Remote host closed the connection]
tkaiser has joined #linux-sunxi
sid14726 has quit [Max SendQ exceeded]
ninolein has joined #linux-sunxi
domidumont has quit [Ping timeout: 246 seconds]
clonak has quit [Ping timeout: 272 seconds]
clonak has joined #linux-sunxi
cosm has joined #linux-sunxi
<tkaiser>
ssvb: The Orange Pi One showed the spinning cube while DRAM was clocked with 744 MHz and lima-memtester still running.
<KotCzarny>
push it further?
<tkaiser>
Nope, then it fails after 30 sec.
<KotCzarny>
hum, add heatsinks?
<tkaiser>
If it's running stable at 744 MHz then I would use 672 for productive use instead.
<tkaiser>
On the Orange Pi One I can't use the usual heatsinks I have for A20 (20x20mm).
<tkaiser>
So I'll have to wait until smaller ones arrive and I don't intend to use them for productive use.
<KotCzarny>
sure, its only curiosity
<tkaiser>
Now I exchanged 'pmuic_type = 2' (I2C) with 'pmuic_type = 0' in script.bin and the ARISC error messages are gone and SoC temperature is lower
simosx has joined #linux-sunxi
<tkaiser>
Merde, I have to wait for the heatsink to continue testing. When starting cpuburn-a7 SoC temperature exceeds 90¡C way too fast
<KotCzarny>
:>
<KotCzarny>
1.2ghz ?
interrobangd has quit [Read error: Connection reset by peer]
<cosm>
tkaiser: a 20x20mm heatsink should fit on the board
<tkaiser>
1008 MHz I would suspect since I use mainline u-boot.
<tkaiser>
On 22:21 I switched back to Orange Pi PC FEX (pmuic_type = 2) and rebooted.
interrobangd has joined #linux-sunxi
<cosm>
tkaiser: sorry, my fault, I didn't notice you were talking about opi one
<tkaiser>
Based on the thermal values it seems that with pmuic_type = 0 (none) the core voltage is lower
<tkaiser>
The voltage regulator on the 'One' can switch between 1.1V and 1.3V
<tkaiser>
According to Orange Pi forums
tyler-baker has quit [Read error: Connection reset by peer]
hp197 has joined #linux-sunxi
egbert has quit [Disconnected by services]
egbert has joined #linux-sunxi
leio_ has joined #linux-sunxi
kelvan_ has joined #linux-sunxi
<tkaiser>
LOL, I did it again and fooled myself :) Changing pmuic_type might stop ARISC error messages but does not change anything regarding SoC temperatures.
<KotCzarny>
you need to fully power off between tests then
<tkaiser>
The decrease in temperature before was due to the kernel shutting down 3 CPU cores.
<tkaiser>
1st sysbench run with type 0 and when exceeding 85¡C SoC temperature cpufreq scaling jumped in and decreased clockspeed from 1008 to 480 MHz (sysbench time: 185,5 sec)
IgorPec2 has joined #linux-sunxi
<tkaiser>
Second run cpufreq scaling failed and clockspeed remained at 1008 MHz (sysbench time 2 seconds better). SoC temperature close to 89¡C -- in case the benchmark would've run longer and 90¡C would've been reached Allwinner's kernel would've started to shut CPU cores down
ricardocrudo has joined #linux-sunxi
<tkaiser>
dvfs isn't working at all but setting pmuic_type = 0 seems to be smart to get cpufreq scaling back
IgorPec has quit [Ping timeout: 250 seconds]
<tkaiser>
Therefore setting pmuic_type = 0 seems to be a workaround unless the problem with the different voltage regulator has been resolved by software