<atsampson>
apritzel: if you're not allowed to distribute the modified boot0, you could write a "boot-1" that sat in front of it, patched it and copied it into the right place ;-)
mozzwald has quit [Ping timeout: 276 seconds]
mozzwald has joined #linux-sunxi
libv_ has joined #linux-sunxi
mosterta has quit [Ping timeout: 260 seconds]
libv has quit [Ping timeout: 246 seconds]
<jrg>
let me see where my orange pi is heh
<jrg>
oh neat
<jrg>
there is an opi plus 2e wiki page now
mpmc has quit [Quit: ZNC 1.6.1+deb1+jessie0 - http://znc.in]
mpmc has joined #linux-sunxi
libv has joined #linux-sunxi
libv_ has quit [Ping timeout: 260 seconds]
<apritzel>
atsampson: eventually we will replace boot0 anyway, so it's not worth the hassle, I guess
kaspter has joined #linux-sunxi
ganbold has joined #linux-sunxi
apritzel has quit [Ping timeout: 244 seconds]
Nacho has quit [Ping timeout: 244 seconds]
Nacho has joined #linux-sunxi
libv_ has joined #linux-sunxi
libv has quit [Ping timeout: 264 seconds]
libv has joined #linux-sunxi
libv_ has quit [Ping timeout: 250 seconds]
Akagi201 has joined #linux-sunxi
libv_ has joined #linux-sunxi
libv has quit [Ping timeout: 264 seconds]
libv_ has quit [Ping timeout: 260 seconds]
ninolein has quit [Ping timeout: 272 seconds]
ninolein has joined #linux-sunxi
egbert has quit [Disconnected by services]
egbert has joined #linux-sunxi
<willmore>
atsampson, wouldn't that be boot-1/
cnxsoft has joined #linux-sunxi
libv has joined #linux-sunxi
doppo has quit [Ping timeout: 272 seconds]
doppo has joined #linux-sunxi
libv has quit [Ping timeout: 240 seconds]
libv has joined #linux-sunxi
libv has quit [Ping timeout: 244 seconds]
libv has joined #linux-sunxi
<wens>
right, it's computex
<wens>
oh, the video shows Nora from Foxconn, the banana pi PM
libv_ has joined #linux-sunxi
libv has quit [Ping timeout: 244 seconds]
Gerwin_J has joined #linux-sunxi
<luoyi>
mripard: what's your mean of 'You can use reg_vcc3v3 from sunxi-common-regulators.dtsi' ? I've looked at the bpi's dts file, and it also have it's own reg_gmac_3v3 section.
reev has joined #linux-sunxi
<wens>
maz: any further comments on the PSCI series? otherwise I'll send v3 tonight
IgorPec has joined #linux-sunxi
cnxsoft has quit [Read error: Connection reset by peer]
cnxsoft1 has joined #linux-sunxi
kaspter has quit [Ping timeout: 272 seconds]
cnxsoft1 is now known as cnxsoft
libv has joined #linux-sunxi
libv_ has quit [Ping timeout: 260 seconds]
<wens>
just realized that sinovoip/bpi do have their fex files on github
<wens>
you just have to know where to look in the BSP
luoyi has quit [Ping timeout: 250 seconds]
<wens>
same can't be said for orangepi
<KotCzarny>
wens, xunlong's one man army is probably busy designing X64 board ;)
<wens>
well, the way the whole *pi stuff worked was (not sure about now) Foxconn's bananapi team comes up with the specs, has steven layout the PCB
<wens>
then gives the design to Sinovoip to manufacture and distribute
<wens>
haven't heard plans about bpi doing A/H64 stuff though
<wens>
so he's probably on his own on this
<KotCzarny>
they will most likely jump on X64 wagon too
<wens>
they just put out the bpi-m2+
<wens>
it will probably take a while :/
<KotCzarny>
three weeks? ;)
vagrantc has quit [Quit: leaving]
<MoeIcenowy>
what's the different of {A,H}64?
<KotCzarny>
moe: nobody knows for sure
<MoeIcenowy>
ah-oh
<KotCzarny>
the only known info is a64 being for the tablets and h64 for ott boxes
<KotCzarny>
from cnxsoft page: Allwinner has two 64-bit ARM processors in the works: Allwinner H64 and Allwinner A64. Both are quad core Cortex A53 processors with a Mali-400MP2 GPU, H.265 4K video playback with basically the same interfaces and peripherals, but H64 also supports H.264 at 4K resolutions, while A64 is limited to H.264 @ 1080p, and H64 adds a TS interface
<KotCzarny>
and probably some config regarding security
<MoeIcenowy>
wens: I don't think "platform" means settop box
<MoeIcenowy>
no settop boxes needs LCD interface
<MoeIcenowy>
but they come with A10/20
<MoeIcenowy>
:-)
tomboy64 has quit [Ping timeout: 244 seconds]
<tkaiser>
wens: Regarding BPi fex files you should be aware that at least for M2+ they used loboris kernel tree (instead of the one ssvb used for H3 for example or the newer BSP variant FriendlyARM provided a few weeks ago) and that fex settings are a nice mixture of Allwinner BSP stuff, loboris stuff and their own development efforts
tomboy64 has joined #linux-sunxi
<MoeIcenowy>
and R series is considered as "IoT" processors
<wens>
MoeIcenowy: hence i have no idea what that means :p
<tkaiser>
To me it seems Allwinner has internally at least 3 different business units and R, A and H belong to them. They then decide about differentiation (market segmentation) and then some stuff that works on A SoC won't work on H or R SoC since managers decided against)
<MoeIcenowy>
wens: see the video
<MoeIcenowy>
just in the scene of 4 processors
<MoeIcenowy>
the left part is "R series IoT processor"
<wens>
MoeIcenowy: i meant the "platform" thing
<wens>
tkaiser: should bpi be commended or criticized for this?
<MoeIcenowy>
wens: I think platform means development boards or NAS...
<tkaiser>
wens: Neither/nor. But based on experiences from the past I can't trust in fex/.dts contents any more. When they released BPi M2 the fex file contained zero pin mappings for GPIO pins. With Lamobo R1 they forgot to add SATA power. And now it seems they use internally an already advanced fex for M2+ and did not update on Github.
Andy-D has joined #linux-sunxi
<MoeIcenowy>
OK I now get all the Chinese translated in the PPT in the video
<tkaiser>
wens: Or ask Hans for example regarding device tree stuff for BPi M2
<wens>
tkaiser: i just use the schematics for doing dts
<tkaiser>
wens: Fortunately now they release them in time (took over a year for Lamobo R1)
<wens>
i've done the dts, now i need to do u-boot
<wens>
after $work that is
paulk-aldrin has joined #linux-sunxi
matthias_bgg has joined #linux-sunxi
<maz>
wens: I will try and go back to it today - got 5 kernel series to review, plus your PSCI stuff, bit of a long queue.
<wens>
maz: ok
<wens>
tkaiser: schematics mention (but don't have the actual resistor net values) that the CPU voltage is 1.2V
<wens>
for the bpi-m2+
paulk-collins_ has joined #linux-sunxi
<tkaiser>
wens: Interesting. Thermal readouts seem to indicate 1.3V. Are you able to measure on test points?
ganbold has quit [Quit: This computer has gone to sleep]
ganbold has joined #linux-sunxi
ganbold has quit [Remote host closed the connection]
<wens>
i don't have a multimeter
<tkaiser>
wens: I have a broken one.
<wens>
tkaiser: could also be that since its a dumb regulator, there's no interface for the kernel to check the voltage, so it's ignored byt dvfs
<KotCzarny>
tkaiser, what is pmu_level1 ?
<tkaiser>
wens: Alsmost the same with Orange Pi One/Lite that use the primitive GPIO driven regulator (no way to read out the voltage only able to set it). Maybe I find the time later to buy a multimeter and check the voltage.
<KotCzarny>
opi+2e fex has it as 1100, but on opipc i had 576
<KotCzarny>
uhum, just trying to compare fexes and see why it fails
<tkaiser>
KotCzarny: And the 576 were the results of a mistake I made since I wrote 01100 in the fex file which is interpreted as octal and results in 576 decimal. The correct value is 1100 and not 01100 (fixed with Armbian 5.11)
<KotCzarny>
noted.
<wens>
tkaiser: ugh, i meant there would be no regulator tied to the cpufreq driver, so it might just ignore any voltage settings/requirements
<wens>
and go all the way up to 1200 MHz
<KotCzarny>
tkaiser, did anyone wrote automatic cpu freq/voltage tester that would generate board specific table?
<KotCzarny>
or is it at all possible to change dvfs from linux?
Mr__Anderson has joined #linux-sunxi
<wens>
it's unlikely you can change it from userspace
<KotCzarny>
wens, but it's just some byte in memory or it programs something on boot?
<wens>
the table is in memory
<wens>
the cpufreq driver picks a value from the table, and configures the clocks and regulators
<KotCzarny>
so theoretically it can be exposed in /sys ? (as it was in the intelcore/amd case)
Akagi201 has quit [Remote host closed the connection]
<tkaiser>
KotCzarny: On boards with SY8106A (yours) you might read out values through I2C. But for what? Since the voltage regulator behaves as you define (through dvfs table). So instead of querying sysfs you can also query dvfs table directly.
Akagi201 has joined #linux-sunxi
<KotCzarny>
tkaiser, i wanted to write a tool that would test the box with minimal number of reboots and preferable without the need for user interactions
<tkaiser>
KotCzarny: I know but you still ignore two facts: You need a good PSU and to test reliability you would need to improve heat dissipation *A LOT* since otherwise you don't know whether H3 works reliably at higher clockspeeds. And since most if not all people will ignore this it's just useless to provide a script
<KotCzarny>
tkaiser, right now i know it hangs on the first ths point
<KotCzarny>
didnt have time to test yesterday
<tkaiser>
KotCzarny: On boards with SY8106A you could disable dvfs code in kernel and talk directly to the voltage regulator through I2C.
<KotCzarny>
i will try setting it to 65C and see what happens
<KotCzarny>
hmm, i2c solution might be it
<tkaiser>
KotCzarny: Do as you like but I would rule out possible hardware failures before (your PSU, remember). And please keep in mind that there are hundreds of users (maybe thousands) that use the settings you blame for your freezes ;)
<KotCzarny>
sure, and you run limamemster and in opipc there are boards that fail with 672, remember?
<tkaiser>
Sure, but that's different stuff :)
<KotCzarny>
nope, it isnt
<KotCzarny>
i mean, its about 'hundreds of users using default value'
<tkaiser>
Or in other words: Thinking about writing a script, modifying kernel code and trying to talk to a voltage regulator through I2C is a huge waste of time when you didn't replace your PSU before
<KotCzarny>
not a waste of time because even with good psu i still would like to know stable voltages at diff. freqs
<tkaiser>
KotCzarny: And you are willing to attach a heatsink and use temporarely a fan?
<KotCzarny>
btw. 1296 is not a problem, because i see it was compiling just fine
<KotCzarny>
and temp. was below 70C (though rising)
<KotCzarny>
i might set it to 1008mhz and just bump voltage to make it heat up
<tkaiser>
KotCzarny: Running make is a joke as you already noticed. You need real workloads to verify reliability.
<KotCzarny>
yeah, still, all of that in the evening
ganbold has joined #linux-sunxi
apritzel has joined #linux-sunxi
IgorPec has quit [Ping timeout: 240 seconds]
enrico_ has joined #linux-sunxi
<enrico_>
bbrezillon: what's the status of nand support in 4.6? can i test it on olinuxino micro/lime2? rootfs will be readonly so even if randomizer support is still not perfect it is not a problem
iamfrankenstein has quit [Quit: iamfrankenstein]
<bbrezillon>
enrico_: it's way better than it used to be, and it should work
<bbrezillon>
actually the randomizer is supported in 4.6 ;)
<bbrezillon>
you just need to define a full-id entry in nand_ids for your NAND
<bbrezillon>
enrico_; and for your second patch (http://pastebin.com/bSitkWRg), drop it and add a full-id entry in nand_ids.c
<KotCzarny>
btw. partition table of the emmc on opi+2e is b0rken, /dev/mmcblk1p1 end 30601215 while max is: 30535680 sectors
<enrico_>
bbrezillon: ok thanks
<KotCzarny>
i wonder what would happen when user fills it to the max
jbrown has quit [Quit: Leaving]
<KotCzarny>
and its not the only discrepacy, he he
tomboy64 has quit [Ping timeout: 252 seconds]
jbrown has joined #linux-sunxi
akaizen has quit [Ping timeout: 260 seconds]
ssvb has joined #linux-sunxi
<apritzel>
KotCzarny: do we really need a Wiki page _speculating_ about the H64 based on shady marketing slides?
<apritzel>
for instance the A64 manual describe a TS interface as well, also the datasheet shows the pins
<KotCzarny>
apritzel, but they are connected to anything on pine64?
<KotCzarny>
or any other a64 board?
<wens>
KotCzarny: emmc partition table is broken on all vendor images
<apritzel>
KotCzarny: don't think so, but it's on the SoC, and this is what the H64/A64 are
akaizen has joined #linux-sunxi
<KotCzarny>
apritzel, so it wont work without dremelling? feel free to do whatever you desire, but it might be of use to know even about those marketing tricks
<enrico_>
bbrezillon: i don't get how to set some of the params after NEED_SCRAMBLING: 6, 640, NAND_ECC_INFO(40, SZ_1K), 4 }
<enrico_>
640 should be the redundant area size, the others...i don't know :D
<tkaiser>
KotCzarny: This is Linpack on OPi Plus 2E at 1296 MHz without throttling since I already undervolted to 1280mV and increased trip points to start throttling at 95*C
<tkaiser>
KotCzarny: So you might be able to test without a fan and only a heatsink since PCB heat dissipation is that good on this board
<tkaiser>
I use 180 seconds cpuburn-a7 to heat up the SoC and let then Linpack start.
<bbrezillon>
enrico_: look at nand_flash_dev definition
<KotCzarny>
uhum
<mripard>
apritzel: there's a difference between what's on the die and what's available on the pins
<apritzel>
sure, but according to the A64 manual it has both the circuitry and the pins for TS
<apritzel>
I was just thinking that putting speculative information to the Wiki might not be the best idea
<KotCzarny>
tkaiser, yeah, 1200 is quite a lot lower than recommended 1340 ;)
<KotCzarny>
also, i wonder how accurate that regulator is, ie. if power source quality affects voltage supplied
<KotCzarny>
or system power (devices) load
<tkaiser>
KotCzarny: That would make the whole approach pretty useless. BTW: We have also information in our wiki and not just speculations. Eg link to SY8106A datasheet ;)
<KotCzarny>
borrow good multimeter from the work for a day? ;)
<tkaiser>
KotCzarny: And on OPi PC I made tests with 4.5V, 5V and 5.5V DC-IN and let the usual tests run. Same thermal readouts so most likely same voltages
<KotCzarny>
mhm
<BroderTuck>
wens: bummer, then that needs to be patched in then along with all the other items
<KotCzarny>
tkaiser, regarding psu from xunlong, i've read a lot about crappy psus, especially noname from china (but also 'good' brands like belkin etc)
luoyi has quit [Ping timeout: 250 seconds]
<BroderTuck>
anyway, the item I'm most curious about is the nand item
<tkaiser>
KotCzarny: Based on my experiences so far hardware from Xunlong I consider 'quality stuff'. No real experiences with the PSUs though. But since I prepare a test with 3 host powered 2.5" disks connected to OPi Plus 2E...
<KotCzarny>
:)
<KotCzarny>
got any oscilloscope handy?
hansg has joined #linux-sunxi
iamfrankenstein has joined #linux-sunxi
f15h has joined #linux-sunxi
<f15h>
is there any info available about the allwinner R40 ?
<f15h>
I am curious about the Camera Interfaces in particular
IgorPec2 has joined #linux-sunxi
<wens>
it was just mentioned at computex
<wens>
i doubt there's any more information
IgorPec has quit [Ping timeout: 264 seconds]
hansg has quit [Quit: Leaving]
<f15h>
the charbax videos there is a slide where the mention a10/a20 compability - so I am curious about the 24Bit-parallel-CSI interface and if it has SATA onboard
<montjoie>
mripard: wens for NET_VENDOR_ALLWINNER, I want to permit COMPILE_TEST, do you think the best is just replace ARCH_SUNXI (since other driver already have depend on ARCH_SUNXI) or to put ARCH_SUNXI || COMPILE_TEST
<bbrezillon>
boot your new kernel, launch flash_erase /dev/mtd[0-X]
<bbrezillon>
re-introduce the bad block check, re-enable on-flash-bbt and boot the new kernel
<bbrezillon>
all the bad blocks should be gone after that
<KotCzarny>
seems like a lot of fun with the nand
<plaes>
o_O
<enrico_>
lol yes
<enrico_>
thanks boris, i'll try that now
<KotCzarny>
almost as much as asm vs c ;)
<bbrezillon>
yes, mainly because Allwinner decided to ignore bad block markes
<bbrezillon>
markers
<KotCzarny>
so it is one time fix?
<bbrezillon>
but with proper support in u-boot and the nand scrub command, it should be way easier
<plaes>
bbrezillon: can't you add module option for that?
<bbrezillon>
plaes: it's been rejected several times
<plaes>
ok :)
<bbrezillon>
I mean, the possibility to force bad block erasure
<bbrezillon>
but thankfully, uboot people decided to provide this command ;)
<plaes>
ah.. cool
ganbold has joined #linux-sunxi
<bbrezillon>
(because you have to remember that it's risky, you might erase real bad blocks by doing that, and start re-using those bad blocks to store data)
<bbrezillon>
s/because/but
<bbrezillon>
KotCzarny: yep, it's a one time fix, unless you keep switching from Allwinner to mainline kernels ;)
<enrico_>
ops, noticed now the -N option, shame on me :D
<wens>
montjoie: ARCH_SUNXI || COMPILE_TEST
Worf has joined #linux-sunxi
<BroderTuck_>
bbrezillon: you seem to be the one who knows nand best. MLC nand seems to be nearing mainline usability, but what's your take on the problems mentioned in getting this chip working: https://groups.google.com/forum/#!topic/linux-sunxi/9AjJNbwC-jM ?
<enrico_>
bbrezillon: many thanks, it's working now
<BroderTuck_>
I'm specifically interested in being able to somehow read the fex currently stored on the nand.
BroderTuck_ is now known as BroderTuck
<bbrezillon>
BroderTuck_: this NAND should work with 4.7-rc1
<bbrezillon>
I've reworked the nand OOB layout description so that we won't have to change the macro defining the maximum OOB size
<bbrezillon>
BroderTuck: now, regarding the fex partition dump, I don't know if it's doable
<bbrezillon>
first I don't know where it's stored in the NAND, and I don't know the format they used
tomboy64 has quit [Quit: Uhh ... gotta go.]
gianMOD has quit [Remote host closed the connection]
reev has quit [Ping timeout: 260 seconds]
tomboy64 has joined #linux-sunxi
gianMOD has joined #linux-sunxi
<wens>
huh, my bpi m2+ has empty emmc...
Nacho has quit [Ping timeout: 276 seconds]
BroderTuck has quit [Quit: -]
Nacho has joined #linux-sunxi
<tkaiser>
wens: Was it different with M3? AFAIK Sinovoip doesn't populate the eMMC (at least on my M3 and M2+ it was like this)
<ssvb>
wens: this probably makes manufacturing them a bit cheaper
<wens>
tkaiser: i don't remember using the emmc on the m3
JohnDoe_71Rus has quit [Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org]
<ssvb>
apritzel: regarding the SRAM C corruption on A64, have you also observed it with boot0 when you tried placing the ATF into SRAM C?
<apritzel>
ssvb: mmh, good question, not so sure about it, but I can surely test this evening
<apritzel>
the corruption was evident quickly for me
gianMOD has quit [Remote host closed the connection]
Amit_t_ has joined #linux-sunxi
<ssvb>
basically I wonder if the SRAM C reliability is caused by improper voltages when running on PMIC defaults, or maybe the 200MHz AHB1 clock speed is unreliable in general
<wens>
200 mhz should be within reasonable limits
<wens>
ugh, reasonably within limits
<ssvb>
and if it is only SRAM C being unreliable at higher AHB1 clock speeds, then maybe Allwinner developers could have decided to give up on SRAM C in favor of having faster AHB1? :-)
<apritzel>
also it's the Allwinner default, isn't it?
alain_ has joined #linux-sunxi
<alain_>
montjoie: did you ever get reports of the sun8i-emac driver working on the OPI Plus?
<ssvb>
it is not the reset default setup for the SoC, but that's what the BSP software stack is using
<montjoie>
alain_: could you retry my new branch ?
<alain_>
any changes since yesterday evening? (don't see anything new on github)
<montjoie>
yes some report from wens
<montjoie>
on regulator
<alain_>
hmmm this may indeed be it
<alain_>
let me rebuild and test, will get back to you in a couple of hours
<montjoie>
for fatest build you could just get sun8i-emac.c file
gianMOD has joined #linux-sunxi
gianMOD_ has joined #linux-sunxi
gianMOD has quit [Read error: Connection reset by peer]
Nacho has quit [Quit: No Ping reply in 180 seconds.]
Nacho has joined #linux-sunxi
Net147 has quit [Ping timeout: 244 seconds]
cnxsoft has quit [Quit: cnxsoft]
Net147 has joined #linux-sunxi
f15h has quit [Remote host closed the connection]
Worf has quit [Quit: Konversation terminated!]
<alain_>
[ 93.065557] sun8i-emac 1c30000.ethernet eth0: Could not attach to PHY
<alain_>
montjoie: same error as yesterday
<alain_>
the interface appears, I can see it's MAC address but phy error
<montjoie>
could you add #DEBUG on top of sun8i-emac.c and recompile
<alain_>
yep
<alain_>
just #DEBUG on a line of its own or some #define DEBUG ?
<montjoie>
#define DEBUG:)
<alain_>
newbie onboard
<wens>
montjoie: might have found the bug, let me dig through some code
<alain_>
cp: '/mnt2/uImage' and '/boot/uImage' are the same file
<alain_>
montjoie: looks like adding the debug statement didn't change anything
<wens>
montjoie: right, so the bug is that for external phys, it was only resetting the syscon to the default value
<wens>
montjoie: but the default value selects internal phy......
<apritzel>
wens: montjoie: the error message looks very similar to the one I got
<apritzel>
but the external PHY worked on the A83T, right?
<montjoie>
apritzel: yes
<wens>
apritzel: the bug is only on the h3
<wens>
i did not have a board with external phy to test then
<apritzel>
alright, I thing I found strange things in the sun50i BSP driver the other day, where it cleared a bit in SYSCON which the manual said should be set
<montjoie>
alain_: could you replace dev_dbg by dev_info on regulator mesages ?
<wens>
montjoie: let me do a fix for you, but i won't be able to test until tomorrow
<montjoie>
wens: ok
<wens>
no way to load image onto the board
nove has joined #linux-sunxi
<alain_>
wens: are we talking about the same issue? If so I have a board available to test (Opi Plus)
<tkaiser>
alain_: _Now_ wens has two to test with ;)
<montjoie>
alain_: probably
<montjoie>
apritzel: a64-wip is still the good branch to use ?
<KotCzarny>
hmm
<apritzel>
montjoie: until I get your driver working: yes ;-)
<KotCzarny>
tkaiser, is limamemtester enabling hdmi?
<KotCzarny>
(on opi+2e)
<apritzel>
my plan is to push -v5 based on 4.7-rc1 as soon as Ethernet works
<KotCzarny>
because i see led blinking, but no display
reinforce has quit [Quit: Leaving.]
<montjoie>
apritzel: but you have done also something in uboot right ?
<montjoie>
just for knowing if I can test it also
<tkaiser>
KotCzarny: Hmm... the fex used should try to negotiate 720p60. Didn't had a look myself when testing whether I got a display or not since boards are lying around next to a DVI connected display only
<apritzel>
well, I program the PMIC in ATF now, which enables the power to the PHY
<alain_>
montjoie: here we go, rebooting with dev_info
<KotCzarny>
then it failed apparently
<apritzel>
but I haven't pushed this code, since it was broken till about yesterday nonn
<apritzel>
*noon
<KotCzarny>
(hdmi wise, test is going on)
<tkaiser>
KotCzarny: If green led is still blinking then everything is ok. Touch the SoC with your finger. If it hurts it's all right.
<apritzel>
montjoie: and now I have to clean up all the debug mess from the last two weeks ... ;-)
<KotCzarny>
i know, just wanted to see "the cube"
<KotCzarny>
;)
<alain_>
montjoie: same error messages, nothing new
<KotCzarny>
also, is there a way to reset box now in any other way than just removing power?
<tkaiser>
KotCzarny: No idea, maybe reset button works
<KotCzarny>
there is reset button?
<tkaiser>
Maybe SW2?
<KotCzarny>
will check at the end of the current test
<tkaiser>
KotCzarny: Be creative and try everything out. No schematic released yet ;)
<KotCzarny>
also, maybe i should try to start with high dram, will be faster than going 30 minutes at each step
<tkaiser>
KotCzarny: Of course, that saves much time
<ssvb>
KotCzarny: unless you get the red LED in addition to the blinking GREEN, the test has not passed
<KotCzarny>
yes, i'm waiting still
<ssvb>
KotCzarny, tkaiser: there was a report about the test actually dying, while the LED blinking code in the kernel was still somehow alive
<KotCzarny>
and yes, i remember
<KotCzarny>
that's also why i wanted to see the cube
<ssvb>
do you have UART serial console?
<tkaiser>
ssvb: And this time I double checked the fex files for all boards contained in the new archive (since we might ask Lite and Plus 2 -- also Hynix DRAM on the latter -- users too)
<KotCzarny>
not connected, but test is going (finger hurty)
<ssvb>
KotCzarny: if it is stuck in this state for too long (more than a few hours, then it will probably not succeed)
<KotCzarny>
one idea: make red light turn on in fex, then start of the test turns it off, then test OK turns it on again
<ssvb>
having no cube animation is a very bad symptom too
<KotCzarny>
that way you will detect test failing
<KotCzarny>
ssvb: i assume its just broken fex/driver (opi+2e)
<ssvb>
well, basically you are suggesting to invert the meaning of the red LED, which may cause some confusion for the people who are already familiar with the old interpretation
<ssvb>
did you have the monitor plugged from the very start of the test?
<KotCzarny>
ssvb, nope, i just suggest to turn it on in fex, then turn off when test started
<KotCzarny>
yes
<KotCzarny>
ssvb, another idea could be audio cue
Mr__Anderson has quit [Remote host closed the connection]
<ssvb>
hmm, then you can probably stop the test and try it again at some very conservative settings, like 600MHz
<KotCzarny>
because basically all h3 drivers are the same and playing some trash to /dev/dsp is easy
<ssvb>
if you see the cube, then that's how it should work
<ssvb>
not seeing the cube -> test failed
<KotCzarny>
ssvb, display is not inited at all, but ok, ill start from 624
<KotCzarny>
tkaiser, next time just login to the board via serial and confirm anything is running ;)
<KotCzarny>
though on the other hand, you've seen red light ?
<KotCzarny>
# uname -a
<KotCzarny>
Linux lima-memtester 3.4.39+ #1 SMP PREEMPT Wed Dec 9 07:24:09 EET 2015 armv7l GNU/Linux
<KotCzarny>
that confirms im not in android ;)
alain_ has quit [Ping timeout: 250 seconds]
<tkaiser>
ssvb: This is serial console output from the board when I start memtester: http://pastebin.com/dK5RWXgz
<KotCzarny>
i've ran 'reboot' but it just prints 'gp job/pp job' repeatedly (and brave green light is still blinking)
<KotCzarny>
yup, says the same on boot here, but no display
<ssvb>
tkaiser: oops, this is bad, looks like mali is not happy
<tkaiser>
Tried it with OPi PC and the appropriate script and get the spinning cube. So there's definitely something wrong and the results collected so far are wortless
<ssvb>
tkaiser: maybe that's something related to 2GB of RAM
<KotCzarny>
or tkaiser's fex files
<KotCzarny>
because he uses modified ones
<KotCzarny>
lets see how opipc's fex work
<tkaiser>
KotCzarny: Doesn't work either
<KotCzarny>
yup
<ssvb>
tkaiser: it might help to recompile U-Boot and restrict the RAM size to 1GB
<KotCzarny>
ssvb, wouldnt that make the test incomplete?
<KotCzarny>
unless its only controller test, and not checking all memory banks
<ssvb>
tkaiser: the framebuffer is located at higher addresses, and this might cause some problems
<KotCzarny>
ssvb: i think memory is autodetected, i remember when i ran opipc sd card in opi+2e it detected 2gb even with opipc's fex
<ssvb>
however, the test used to work on the Cubietruck with 2GB of RAM, and there were some 2GB related fixes already in the mali code
<ssvb>
KotCzarny: you can artificially limit the RAM size by patching the U-boot code
<KotCzarny>
uhum
<tkaiser>
ssvb: Patching u-boot as a measure to get the idea whether it's related to 2GB or not?
<ssvb>
tkaiser: yes
<ssvb>
tkaiser: still it is a bit more complicated, but I will not go into details yet
<KotCzarny>
hmm, booting opipc xorg seems to work, but no image
<KotCzarny>
so it might be easier solved by just trying to get x to work
<tkaiser>
ssvb: Ok, and I won't test yet due to lack of time and knowledge where to adjust what :)
reinforce has joined #linux-sunxi
<ssvb>
tkaiser: you can get the latest U-Boot from git, then patch the return value of sunxi_dram_init here - http://git.denx.de/?p=u-boot.git;a=blob;f=arch/arm/mach-sunxi/dram_sun8i_h3.c;h=2020d75fd14529e861ef03144c918120153e93a0;hb=HEAD#l431
<ssvb>
tkaiser: also don't forget to add "setenv bootm_boot_mode sec" to boot.cmd
<ssvb>
tkaiser: if all of this helps, then we will know that this was the problem :)
<tkaiser>
ssvb: Sure, but not today and tomorrow :\
<ssvb>
tkaiser: if it does not help, then 2GB still could be a problem, but in a more tricky way
<KotCzarny>
ssvb, would limiting mem by kernel param work too?
<KotCzarny>
or its prekernel
<ssvb>
KotCzarny: you could try
<KotCzarny>
though hdmi is initialized by fex in uboot and linux kernel just uses simplefb
vagrantc has joined #linux-sunxi
<KotCzarny>
[ 0.129981] WARNING: at drivers/base/dma-contiguous.c:153 cma_init_reserved_areas+0xa0/0x1ec()
<KotCzarny>
[ 0.130012] Modules linked in:
<KotCzarny>
[lol
<KotCzarny>
what a beautifool oops
<KotCzarny>
[ 0.220113] Unable to handle kernel NULL pointer dereference at virtual address 00000108
<KotCzarny>
passing mem=1G is a bad idea ;)
<ssvb>
KotCzarny, tkaiser: does the normal x11 linux desktop work on 2E with the armbian kernel?
<ssvb>
KotCzarny: also have you figured out what was wrong with your 70C deadlocks?
<KotCzarny>
ssvb: nope
<KotCzarny>
i mean x starts, but no display
<ssvb>
I see, are there any other H3 boards with 2GB?
<tkaiser>
ssvb: Only Plus 2
jernej_ has joined #linux-sunxi
<ssvb>
tkaiser: is the plus 2 board problem free?
<ssvb>
KotCzarny: you could try to recompile U-Boot with the trick to restrict the RAM size just like I have described above
<tkaiser>
ssvb: We have not a single feedback regarding this. Users take Armbian image for 'Plus' (1Gb Samsung) and we never got complaints. So I would assume X is working there
<ssvb>
heh, maybe I should somehow get the opi+2e board myself, I completely forgot about a chance of having the 2GB related entertainment with it
<tkaiser>
ssvb: hehe, I drop Igor a note since he's in touch with Steven
<jrg>
so with the microusb power the bpi is only stable at 1.2GHz.. 1.6 was too much for it
<jrg>
might as well have just kept the heatsink off of it and let it thermal throttle heh
<jrg>
ill see about going to radio shack later to grab a barrel connector i can put on it
<jrg>
wonder how long before a pkg leaves Shenzhen and arrives in the US
tsuggs has quit [Ping timeout: 252 seconds]
<KotCzarny>
jrg: 2-3 days to leave china
<KotCzarny>
then another 2-3 to fly, then it depends on customs in us
<KotCzarny>
ssvb, sure, i have to fix the bootparams first thpo
<jrg>
KotCzarny: ah ok. awesome.
lamer14647101305 has joined #linux-sunxi
<jrg>
it departed shenzhen a couple days ago. hopefully it is in the air.
<jrg>
no official armbian for it yet right?
<KotCzarny>
jrg: you have tracking on the ali site
Shirasaka-Hazumi has quit [Ping timeout: 272 seconds]
<jrg>
yeah. tracking just says it left shenzhen
<jrg>
well it says "processed through facility"
<jrg>
not sure if that is the same.
tkaiser has quit [Ping timeout: 260 seconds]
<jrg>
probably not because the airplane liftoff icon isnt highlighted.
<KotCzarny>
for me the last china based comment was 'Package sent.SHENZHEN'
<KotCzarny>
so its between warehous and china mail now
<ssvb>
KotCzarny: did U-Boot print anything about the RAM size?
<KotCzarny>
let me connect serial then
<KotCzarny>
my poor banana has only 2 usb ports
<KotCzarny>
DRAM: 2 GiB
<ssvb>
KotCzarny: also there might be other places checking for the DRAM size in U-Boot, via something like "get_ram_size((long *)PHYS_SDRAM_0, PHYS_SDRAM_0_SIZE)"
<ssvb>
KotCzarny: are you sure that you have booted the recompiled U-Boot?
<KotCzarny>
so either i did something wrong or it didnt work
<apritzel>
Amit_t: works for me, did you do "make distclean" before?
<KotCzarny>
ssvb: how can i make uboot print something to console?
<KotCzarny>
puts()
<ssvb>
KotCzarny: ok, let me try to do some experiments on opi-pc
<KotCzarny>
DRAM:
<KotCzarny>
*DING*
<KotCzarny>
then some messages then DRAM: 2 GiB
<KotCzarny>
so it detects mem in some other place too
<ssvb>
KotCzarny: and then check if you get the same mali gp and pp error messages in the log
<ssvb>
KotCzarny: on older A10/A20 kernels from Allwinner, we had to fix the conversion between bus and physical addresses to make 2GB boards working properly
<KotCzarny>
ahm, my 70C limit
<KotCzarny>
apparently my box hung
<KotCzarny>
;)
<ssvb>
KotCzarny: maybe the same shit needs to be fixed for H3 kernels too
<KotCzarny>
i will try limiting to lowest cpu speed before running it
<ssvb>
you can try to set the performance governor and limit the CPU clock speed to make sure that the transitions between operating points are not happening
<ssvb>
still, having this issue is definitely not great
<KotCzarny>
e2fsck running
<ssvb>
sigh, the first opi+2e users might have not a very great experience
<KotCzarny>
im still happy
<ssvb>
are you a masochist? ;-) how can you be happy with a deadlocking board?
<KotCzarny>
:)
<lamer14647101305>
ssvb: KotCzarny: While cooking I let an Armbian desktop image compile. Works flawlessly.
<tkaiser>
KotCzarny: And do you remember? config for size (or something like that) --> no HDMI output
<KotCzarny>
hmm
<KotCzarny>
let me check
<KotCzarny>
[*] Optimize for size
<KotCzarny>
then it should work
Phipli has joined #linux-sunxi
bonbons has joined #linux-sunxi
<KotCzarny>
oh, wow, temp stayed ~60C and box rebooted itself
<KotCzarny>
o.O
<tkaiser>
KotCzarny: Replaced PSU already?
<KotCzarny>
not yet
<KotCzarny>
but good catch
<tkaiser>
Then why are you looking at temperatures?
<KotCzarny>
how can i lower power usage at the moment?
<tkaiser>
Disable SMP? Run with 480 MHz maximum? Depends on what are you trying to do...
<tkaiser>
OPi Plus 2E runs perfectly stable at +90*C, no problem with the 2GB and X windows at least with the newer kernel and WiFi stuff has been fixed by jernej and Igor also yesterday and today.
<tkaiser>
ssvb: BTW: You got mail and we're waiting urgently for an answer
<tkaiser>
KotCzarny: Do you want a download address for a fresh Armbian 5.12 image for Plus 2E?
<tkaiser>
With desktop and WiFi?
<KotCzarny>
tkaiser, kernel+modules will be enough
<KotCzarny>
unless you folks patches x and friends too
<KotCzarny>
*patched
<tkaiser>
KotCzarny: Damn, Igor again commited fixes in the meantime. For desktop useage it's better to use a whole image (and move your homedir afterwards) since we still didn't manage to move all the necessary stuff to clean packages (as far as I understood -- looking at X windows every few months)
maz has joined #linux-sunxi
<tkaiser>
I'll rebuild the image. Should take 6 minutes since most of the stuff should already be cached. Drop you a note after uploading it somewhere
<KotCzarny>
kernel+modules for starters
<KotCzarny>
i didnt clean my rootfs yet so i dont want a reflash yet
Mr__Anderson has quit [Remote host closed the connection]
<tkaiser>
ssvb: KotCzarny: I haven't touched the whole stuff after we exchanged BSP kernel sources. But now the only patch that does not apply cleanly is the one to increase GPU clockspeed from 252 MHz to 600 MHz (since sources are different): http://pastebin.com/mk4Gm2QN
dlan has joined #linux-sunxi
VargaD_ has joined #linux-sunxi
VargaD has quit [Ping timeout: 276 seconds]
<KotCzarny>
tkaiser: and im using that new tree and patches
<tkaiser>
KotCzarny: Nope, you would've to adjust fex contents instead I would believe.
VargaD_ is now known as VargaD
<tkaiser>
This patch does not work any more
<KotCzarny>
mhm
<ssvb>
I just hope that somebody has tested these patches
<KotCzarny>
anyway, ssvb: shall i try 252?
<ssvb>
KotCzarny: I don't know, I still suspect 2GB of RAM being the root cause, but other things have apparently changed too
<KotCzarny>
ssvb, but as i said, your binary works on 2gb
<KotCzarny>
ssvb, you might grab the kernel tkaiser posted and check
Nacho has joined #linux-sunxi
<ssvb>
depends on your definition of "works", it definitely has problems, based on the log messages that you have posted
<KotCzarny>
k, lets see 252 then
<tkaiser>
KotCzarny: ssvb is using Gentoo IIRC. Unfortunately jernej isn't online since he looked into the new BSP kernel and which Mali driver is used there (I forgot it since me and GUI stuff --> noob)
<KotCzarny>
i meant for limatester
<KotCzarny>
oh, wow
<KotCzarny>
i see the cube
<jernej>
tkaiser: I'm online :)
<KotCzarny>
[ 126.017740] mali clk: 600 MHz
<KotCzarny>
but its still the 600
<KotCzarny>
(changed it in fex)
<ssvb>
KotCzarny: what have you changed to make it work?
<jernej>
tkaiser: default mali driver is DX910-SW-99002-r4p0-00rel0
<KotCzarny>
ssvb: its not in fel boot, but in normal linux
<ssvb>
KotCzarny: with 1GB or 2GB of RAM configured by U-Boot?
<KotCzarny>
2gb
<ssvb>
why didn't it work before?
* ssvb
is getting really confused
<KotCzarny>
can i boot my kernel with limatester?
<ssvb>
yes, kind of
<KotCzarny>
or it had something specific compiled in?
<ssvb>
you can try to apply this patch to your current kernel and just build the test kernel using the sun8i_h3_lima_memtester_defconfig
vagrantc has quit [Ping timeout: 264 seconds]
Nacho has quit [Ping timeout: 252 seconds]
<ssvb>
KotCzarny, tkaiser: do I understand it correctly that the updated Allwinner's BSP with some extra armbian patches resolves the problem and you get a spinning cube?
<KotCzarny>
ssvb, running in linux, havent tried glueing it and fel booting
<ssvb>
KotCzarny: it should also work with fel booting if it works in linux
Amit_t_ has quit [Quit: Page closed]
<ssvb>
somebody may try to provide an updated fel based lima-memtester package for opi-2e with the new kernel
Mr__Anderson has joined #linux-sunxi
gianMOD has joined #linux-sunxi
tlwoerner has joined #linux-sunxi
paulk-collins_ has quit [Ping timeout: 250 seconds]
<ssvb>
jernej: what is the r4p0 mali driver story?
<jernej>
ssvb: nothing really, it seems to be default BSP driver
<jernej>
BSP kernel has also a newer revision DX910-SW-99002-r4p0-00rel1, but for some reason is not default
<jernej>
it seems that both drivers works good
<ssvb>
are there non-android r4p0 userland blobs available?
<KotCzarny>
argh, ssvb, your uboot seems to be size limited, why the heck 8MB is the default
<tkaiser>
ssvb: I know, and this forum sorts post somewhat weird. At least there Steven sent the binaries to someone and 'whitewind' posted them back to the forum.
klarrt has quit [Ping timeout: 250 seconds]
<jernej>
ssvb: try asking in pull request
<ssvb>
KotCzarny: is it really built in?
Netlynx has quit [Quit: Leaving]
<KotCzarny>
hmm
<KotCzarny>
can i check it somehow?
<ssvb>
KotCzarny: check the .config file for anything MALI related