Turl changed the topic of #linux-sunxi to: Allwinner/sunxi /development discussion - did you try looking at our wiki? https://linux-sunxi.org - Don't ask to ask. Just ask and wait! - https://github.com/linux-sunxi/ - Logs at http://irclog.whitequark.org/linux-sunxi
Akagi201 has quit [Ping timeout: 260 seconds]
[7] has quit [Ping timeout: 258 seconds]
TheSeven has joined #linux-sunxi
<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
jernej_ has quit [Ping timeout: 252 seconds]
jernej has joined #linux-sunxi
tkaiser has joined #linux-sunxi
<tkaiser> wens: MoeIcenowy: Regarding this new R40 chip. Can you translate what's written here: https://www.youtube.com/watch?v=h7KD-6HblAU&t=43s
jernej_ has joined #linux-sunxi
jernej has quit [Ping timeout: 240 seconds]
jernej_ has quit [Ping timeout: 244 seconds]
montjoie has quit [Ping timeout: 272 seconds]
montjoie has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
massi has joined #linux-sunxi
reinforce has joined #linux-sunxi
<MoeIcenowy> tkaiser: for the Chinese in the PPT?
<MoeIcenowy> to be honest, it's very difficult to recognize... (Or I should bump to the highest resolution on YouTube?)
<MoeIcenowy> and you care of R40?
<MoeIcenowy> it's said to be "延续 A10/A20 经典设计" (Continues the classical design of A10/20)
<MoeIcenowy> "接口丰富" (Rich of peripheral)
<MoeIcenowy> "性能增强" (Enhanced performance)
<MoeIcenowy> and it's a Quad A7
<MoeIcenowy> R18W is also interesting...
<MoeIcenowy> It have Wi-Fi integrated
<MoeIcenowy> (Why am I expecting another blob in lichee...
<MoeIcenowy> :-( :-P
<tkaiser> MoeIcenomy: Thanks. R40 is interesting to me if it's the announced pin compatible A20 successor (containing true SATA)
<MoeIcenowy> tkaiser: seems that
<tkaiser> Then 'Rich peripheral' might translate to 'has SATA' (and CAN for example) and performance is 'quad core vs. dual core'
<MoeIcenowy> tkaiser: I also think so
<tkaiser> And you were talking about R16W? Since R18 should be the IoT brother of A64/H64 ;)
<wens> - platform (i'm guessing settop box?) grade hardware, very expandable
<wens> - 4x cortex-a7, @ 1GHz
<wens> - continuation of A10/A20 design, plentiful peripherals
<wens> tkaiser: i've no idea what the chinese buzzwords should mean
<tkaiser> wens: LOL, great, thank you.
<tkaiser> MoeIcenowy: nove spotted yesterday this regarding R16W: http://irclog.whitequark.org/linux-sunxi/2016-05-30#16609807;
<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
<tkaiser> KotCzarny: search for pmu_level1 here http://forum.armbian.com/index.php/topic/724-quick-review-of-orange-pi-one/ (only relevant on One/Lite where a GPIO driven voltage regulator is used, does not apply to SY8106A equipped boards)
<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?
ricardocrudo has joined #linux-sunxi
<KotCzarny> first i would have to find them
<tkaiser> KotCzarny anyway otherwise you won't be able to test above ~1200 MHz. And when you're using Linpack (compare with https://github.com/deater/performance_results/tree/master/build_instructions please) then you need an additional fan too to verify settings
<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
<enrico_> like the one with NEED_RANDOMIZER?
<enrico_> (going by memory)
<bbrezillon> NAND_NEED_SCRAMBLING, yes
<enrico_> mtd: nand: add NAND_NEED_SCRAMBLING flag to the H27UCG8T2ATR-BC definition
<enrico_> (but for my nand of course)
<bbrezillon> yep
<enrico_> ok thanks, for nfc dts i applied some "old" patches, has the syntax changed? it compiles and doesn't complain on boot
IgorPec has joined #linux-sunxi
<bbrezillon> yep
<bbrezillon> it's way simpler now
<bbrezillon> can you share your dts?
<enrico_> sure, can i send it to your free electrons email?
<bbrezillon> yep, or you can use pastebin ;)
<enrico_> i'll make a mix :D
luoyi has joined #linux-sunxi
<bbrezillon> enrico_: here is the new def => http://pastebin.com/J1mQLsjj
<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: WR02R2L2 6000 256 1 1 69.02 2.087e+00
<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
<tkaiser> KotCzarny: 1296 MHZ @ 1240 mV == PASSED
<bbrezillon> enrico_: you should get all those information in your NAND datasheet
BroderTuck has joined #linux-sunxi
<bbrezillon> the only tricky part is the default ONFI timing mode, but you can leave it to 0
<mripard> apritzel: yeah, totally
<BroderTuck> Would it be possible to get someone to take a look at this wishlist? http://paste.debian.net/712934/
<KotCzarny> apritzel, is there anything known for sure regarding a64 vs h64 ?
<wens> BroderTuck: USB doesn't work on 4.7-rc1 yet
<wens> patches for shared reset controls for EHCI/OHCI haven't landed yet
<apritzel> KotCzarny: not really
<enrico_> bbrezillon: yes i was missing just the timing, i'm trying with 0, thanks
<apritzel> KotCzarny: I have some speculative ideas based on experimentation
<tkaiser> KotCzarny: 1296 MHz @ 1200mV --> kernel oops ;)
<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
Net147 has quit [Quit: Quit]
Net147 has joined #linux-sunxi
ganbold has quit [Ping timeout: 276 seconds]
gianMOD has joined #linux-sunxi
<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
keh has joined #linux-sunxi
Net147 has quit [Ping timeout: 244 seconds]
f15h has quit [Ping timeout: 240 seconds]
Net147 has joined #linux-sunxi
ganbold has joined #linux-sunxi
BroderTuck_ has joined #linux-sunxi
BroderTuck has quit [Ping timeout: 276 seconds]
tomboy64 has joined #linux-sunxi
<MoeIcenowy> tkaiser: see the bottom of this page
<MoeIcenowy> Thomas asked "Tsvetan: Is it the R40 that has been announced yesterday at Computex by Allwinner? https://www.youtube.com/watch?v=h7KD-6HblAU&t=43s"
<MoeIcenowy> OLIMEX Ltd replied No
<enrico_> bbrezillon: it works, but at first i set the size to 512MB (in nand ids) and i got this (working): http://pastebin.com/9eQGwU2c
<enrico_> bbrezillon: then i relized it should be 4 GB (not Gb) so i changed the size but i get this: http://pastebin.com/VRENZ1Dw
<enrico_> bbrezillon: unless i'm misreading the datasheets, isn't it a 4 GB (not Gb) device?
ganbold has quit [Ping timeout: 276 seconds]
<tkaiser> MoeIcenowy: The 't' in tkaiser is for 'Thomas' ;)
<tkaiser> MoeIcenomy: I have to learn to ask smarter questions :)
<bbrezillon> enrico_: yes, it's a 4GB (not Gb) device
<bbrezillon> and what you're seeing here is just the result of the BBM corruption introduced by the Allwinner flasher
<bbrezillon> enrico_: you'll have to scrub your NAND
<enrico_> bbrezillon: how can i do that? because of the errors i get no mtd device to work on
<bbrezillon> this can either be done from u-boot (but this means using these sources https://github.com/NextThingCo/CHIP-u-boot/tree/nextthing/2016.01/next, because the sunxi NAND driver is not mainlined yet )
<bbrezillon> or you disable on-flash-bbt in your DT
<enrico_> so i disable it, flash_erase all the nand, then re-enable it?
f15h has joined #linux-sunxi
<bbrezillon> then patch your kernel to remove this test => http://lxr.free-electrons.com/source/drivers/mtd/nand/nand_base.c#L2933
<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_> bbrezillon: it's not working, i see that flash_erase skips bad blocks: http://pastebin.com/BSdK1fQz
<enrico_> (patched kernel and dt of course)
<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
<wens> untested :p
luoyi has joined #linux-sunxi
Mr__Anderson has joined #linux-sunxi
<KotCzarny> test started at 624, no cube, led started blinking
<KotCzarny> i guess tkaiser broke the fex
<KotCzarny> also, no reset button, but removing dc was enough
<luoyi> connect uda1380 to my bpi m1+, and i2cdump -y 2 0x18 give me 'Device Busy' error.
MoeIcenowy is now known as duangduang
<luoyi> what''s the possible problem with this ?
duangduang is now known as MoeIcenowy
<KotCzarny> ssvb, an idea, start telnetd on serial line?
<KotCzarny> that way one could login to the board and reset/check it
<mripard> luoyi: the kernel already bound a driver to it
<tkaiser> KotCzarny: Use serial console, it works already
<KotCzarny> oh?
<KotCzarny> k
<ssvb> tkaiser: if the mali driver does not work, then the test is not doing what it is supposed to do
<ssvb> tkaiser: you just get a regular memtester, which is much less sensitive to dram misconfiguration
JohnDoe_71Rus has joined #linux-sunxi
luoyi has quit [Ping timeout: 250 seconds]
<KotCzarny> that might explain those high dram results
<ssvb> tkaiser: so it would be nice to confirm that at least somebody gets a spinning cube animated properly on 2E
<tkaiser> ssvb: I don't get one either. Just changed screen0_output_mode to 4 (was 5 before): http://sprunge.us/fJXF
<KotCzarny> i can confirm
<KotCzarny> x is not started
<KotCzarny> even more, i see no test binary running
<tkaiser> KotCzarny: You booted Android, right? ;)
<KotCzarny> nope
<KotCzarny> ran fel mode on sd
<KotCzarny> then ran limamemtester
<KotCzarny> and i know what processes run on android :P
<KotCzarny> this is ps list
<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
<KotCzarny> probably still in the mainland :P
Shirasaka-Hazumi has joined #linux-sunxi
<jrg> damn
<KotCzarny> be patient
<KotCzarny> prepare for 2 weeks of waiting
<jrg> yeah
<Amit_t_> apritzel:ssvb: I am seeing these compilation issues while compiling ATF for pine64, http://paste.ubuntu.com/16867376/
enrico_ has quit [Quit: Bye]
<KotCzarny> ssvb, what shall i set in that sunxi_dram_init ?
gianMOD_ has quit [Remote host closed the connection]
<ssvb> KotCzarny: just try to return 1GB (1024 * 1024 * 1024)
<KotCzarny> Mem: 2072072 69288 2002784 588 8256 22276
<KotCzarny> hrm, didnt work?
<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
<KotCzarny> i mean, it sets some structs, and uboot uses those structs, not function return
zuikis has joined #linux-sunxi
<ssvb> KotCzarny: you can also patch the 'get_ram_size' function, which probes for the RAM size
<KotCzarny> DRAM: 1 GiB
<KotCzarny> k, we will see
<KotCzarny> no oops yet
<KotCzarny> but also no x
<KotCzarny> Mem: 1031196 68576 962620 588 8256 22368
<KotCzarny> so its not that
<KotCzarny> ssvb, other ideas?
<ssvb> KotCzarny: do you get no framebuffer at all?
<KotCzarny> dont know, hdmi is not showing anything
<ssvb> what do you see in the dmesg log?
<Amit_t_> apritzel: Yes, I did make ARCH=arm CROSS_COMPILE=aarch64-linux-gnu- distclean
<Amit_t_> but ARCH=arm is right ?
<maz> Amit_T: ARCH=arm64 if you want to compile for aarch64.
<apritzel> ATF doesn't seem to care ;-)
<KotCzarny> seems that fb is inited, but hdmi not powered
<apritzel> ARCH=Amit works as well :-D
<Amit_t_> Yes, it is the case, nothing changes after changing it to ARCH=arm64
<maz> ah, ATF... Another Terrifying Feature...
<apritzel> Amit_t: which compiler do you have? And which branch are you building?
<Amit_t_> apritzel: Head is at fc1e255c846bc0a0c72c8e6f822e64e24704e136
<Amit_t_> toolchain I got it from linaro site.
<apritzel> aarch64-linux-gnu-gcc --version says what?
<Amit_t_> gcc-linaro-aarch64-linux-gnu-4.7+bzr115029-20121015+bzr2506_linux.tar.bz2
<KotCzarny> hdmi_power = "vcc-hdmi-18"
<KotCzarny> maybe i should boot android to see if hdmi works at all
<apritzel> Amit_t: 4.7 is a good kernel, but not a good compiler version, I am afraid ;-)
<apritzel> dude, this compiler is even older than the Allwinner BSP kernel!
<ssvb> KotCzarny: do you have /dev/fb0 ? you can also try to run the lima-memtester userland application as an experiment
<KotCzarny> crw-rw---- 1 root video 29, 0 Jan 1 1970 /dev/fb0
<KotCzarny> but as i said, it looks like fb is there, just no hdmi output
<Amit_t_> apritzel: How you come to know ?
<ssvb> KotCzarny: mali does not directly depend on the hdmi output working, it is a memory to memory accelerator
<KotCzarny> umkay, what and how shall i run?
<ssvb> KotCzarny: try to download the static binary from https://github.com/ssvb/lima-memtester/releases/tag/static-binary-20150126 or compile it from sources and run
<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.
<KotCzarny> because i know it will be fixed
<lamer14647101305> X with 1080p
lamer14647101305 has quit [Quit: jIRCii - http://www.oldschoolirc.com]
tkaiser has joined #linux-sunxi
<tkaiser> ssvb: But this is a different kernel based on a more recent BSP version
<KotCzarny> tkaiser, im using same source as you
<KotCzarny> (the new opipc kernel, right?)
<tkaiser> KotCzarny: But memtester does not. I'm talking about https://github.com/igorpecovnik/linux/tree/sun8i (made available by FriendlyARM folks). And then there are a 'few' patches applied also: https://github.com/igorpecovnik/lib/tree/master/patch/kernel/sun8i-default
<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.
<ssvb> tkaiser: can you run the lima-memtester application on your system with the newer kernel?
Netlynx has joined #linux-sunxi
maz has quit [Ping timeout: 246 seconds]
<ssvb> KotCzarny: as tkaiser says that X11 desktop works fine on his 2E board, probably your board or your PSU indeed has problems
<KotCzarny> or my kernel
<ssvb> yes, just try whatever is used by tkaiser
Gerwin_J has quit [Quit: Gerwin_J]
<tkaiser> ssvb: Usage: /tmp/lima-memtester [-p physaddrbase [-d device]] <mem>[B|K|M|G] [loops]
<ssvb> tkaiser: run it as "lima-memtester 100M"
<tkaiser> ssvb: Doesn't work. Same error messsages as before
<ssvb> tkaiser: too bad
<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]
<KotCzarny> thx
<tkaiser> KotCzarny: For WiFi you'll need another fix to get a static MAC address: https://github.com/igorpecovnik/lib/commit/1958e7329e27b673d4552820b339b32e6a1cc3f0
<KotCzarny> yes, i already have that in modprobe.d
alain has joined #linux-sunxi
xcasex has quit [Ping timeout: 246 seconds]
apritzel has quit [Ping timeout: 244 seconds]
<ssvb> tkaiser: replied
<alain> montjoie: now getting [ 93.269689] sun8i-emac 1c30000.ethernet: EMAC reset timeout
xcasex has joined #linux-sunxi
<alain> (using wen's patch referenced above(
<KotCzarny> um
<KotCzarny> i feel stupid
<KotCzarny> hdmi cable wasnt pushed all the way in
* NiteHawk hands KotCzarny a red herring
* KotCzarny bows
* KotCzarny slaps himself with the red herring
<KotCzarny> now lets see the 2gb uboot and lima too
<KotCzarny> but seriously, it had to be pushed really hard
<KotCzarny> like, REALLY hard
<KotCzarny> but no box on limatester
<KotCzarny> though at least tv doesnt display 'no signal' anymore
jernej_ is now known as jernej
<KotCzarny> so in a way i've found some bug
<KotCzarny> btw. for all your viewing pleasure:
<KotCzarny> # cat /usr/local/bin/xaosgo
<KotCzarny> xaos -fullscreen -threads 4 -maxframerate 30 -autopilot -randompalette -cycling -inhibittextoutput $*
<tkaiser> OPi Plus 2E Armbian image (based on Debian Jessie) with latest BSP kernel and jernej's fixes for WiFi and all the accelerated stuff: http://kaiser-edv.de/tmp/4U4tkD/Armbian_5.13_Orangepiplus_2E_Debian_jessie_3.4.112_desktop.7z
<ssvb> KotCzarny: limiting RAM to 1GB still does not help to make lima-memtester work with a properly inserted HDMI cable?
<KotCzarny> ssvb, will test, just a moment
<tkaiser> Same stuff for NanoPi M1 (FriendlyARM -- trying very hard to be a 99 percent clone of Orange Pi PC): http://kaiser-edv.de/tmp/4U4tkD/Armbian_5.13_Nanopim1_Debian_jessie_3.4.112_desktop.7z
<KotCzarny> ssvb: that userland binary works with 2gb (and my kernel/uboot)
<KotCzarny> i see red/green/blue/yellow stripe
<KotCzarny> but i see errors in log
iamfrankenstein has quit [Quit: iamfrankenstein]
Nacho has quit [Ping timeout: 264 seconds]
ricardocrudo has quit [Remote host closed the connection]
<ssvb> KotCzarny: hmm, you have "mali clk: 600 MHz" in your previously posted dmesg log
<KotCzarny> thats probably because i used armbian's fex
<ssvb> there are so many unpredictable things, what kind of kernel mali driver is used by armbian?
<KotCzarny> those are the patches
<KotCzarny> i think you think about 0003
<KotCzarny> and probably few next
tlwoerner has quit [Quit: Leaving]
dlan has quit [Ping timeout: 264 seconds]
<KotCzarny> shall i retry wth 252?
<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?
<KotCzarny> ahm, you have ramdisk glued in
<ssvb> yes, the test kernel has embedded initrd, you can get it here - https://github.com/ssvb/linux-sunxi/commit/24e3f78f3b7392df9671c22ae2de3e5e2bee4208
<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
<jernej> ssvb: he also made a PR https://github.com/linux-sunxi/sunxi-mali/pull/13
Nacho has joined #linux-sunxi
<ssvb> jernej: what is the origin of these binaries?
<ssvb> but thank for pointing to the pull request
<jernej> ssvb: not sure, but it may be that steven provided them on orangepi forum
<ssvb> *thanks
<ssvb> oh, this is nice, we need to find this forum thread
<jernej> ssvb: however, this is only my suspicion
<ssvb> tkaiser: too long to read
<KotCzarny> Failed to 'modprobe mali'.
<KotCzarny> huh
<KotCzarny> (its built in)
<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
mosterta has joined #linux-sunxi
<KotCzarny> you are right.
alain has quit [Quit: Page closed]
Nacho has quit [Ping timeout: 260 seconds]
paulk-collins_ has joined #linux-sunxi
IgorPec2 has quit [Ping timeout: 272 seconds]
<KotCzarny> ssvb, woo hoo, got usb
<KotCzarny> but no cube
<KotCzarny> 4 color bars only
<KotCzarny> might be overclock related
Nacho has joined #linux-sunxi
<KotCzarny> s/got usb/got hdmi/
TheLinuxBug has quit [Ping timeout: 264 seconds]
xenoxaos has joined #linux-sunxi
<KotCzarny> lots of:
<KotCzarny> pp job 0xC0009BDA returned 0x00800000
<KotCzarny> gp job returned 0x00800000
<ssvb> KotCzarny: at what DRAM clock speed?
<KotCzarny> 672
<KotCzarny> but mali is probably 600 if its using kernel values
TheLinuxBug has joined #linux-sunxi
<ssvb> anyway, it looks like mali is somewhat flakey, but you got it working at least once
<KotCzarny> let me change the fex
<ssvb> so it should be possible to identify what makes the difference
<KotCzarny> would be nice if pp job/gp job didnt overflow the screen
<ssvb> libv ^
<ssvb> :-)
paulk-collins_ has quit [Quit: Leaving]
<KotCzarny> gotta play with freq/voltages tomorrow, cya!
tkaiser has quit [Quit: jIRCii - http://www.oldschoolirc.com]
JohnDoe4 has joined #linux-sunxi
JohnDoe_71Rus has quit [Ping timeout: 252 seconds]
mosterta has quit [Read error: No route to host]
mosterta has joined #linux-sunxi
matthias_bgg has quit [Ping timeout: 252 seconds]
JohnDoe4 has quit [Quit: KVIrc 4.9.2 Aria http://www.kvirc.net/]
massi has quit [Remote host closed the connection]
TheSeven has quit [Disconnected by services]
[7] has joined #linux-sunxi
bonbons has quit [Quit: Leaving]
apritzel has joined #linux-sunxi
adj__ has left #linux-sunxi ["Leaving"]
zuikis has left #linux-sunxi [#linux-sunxi]
al1o has joined #linux-sunxi
paulk-aldrin has quit [Quit: Leaving]
reinforce has quit [Quit: Leaving.]
pekka10 has joined #linux-sunxi
mpmc has quit [Ping timeout: 240 seconds]
nove has quit [Quit: nove]
fdcx has quit [Remote host closed the connection]
fdcx has joined #linux-sunxi
akaizen has quit [Remote host closed the connection]
mosterta has quit [Ping timeout: 276 seconds]
iamfrankenstein has joined #linux-sunxi
mosterta has joined #linux-sunxi
Phipli has quit [Ping timeout: 240 seconds]
Mr__Anderson has quit [Quit: Leaving.]
apritzel1 has joined #linux-sunxi
mosterta has quit [Ping timeout: 240 seconds]
mosterta has joined #linux-sunxi
gianMOD has quit [Remote host closed the connection]
al1o has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
valkyr1e has quit [Ping timeout: 260 seconds]
<apritzel> YES! Now we are talking!
<apritzel> $ ssh ubuntu@pine64
<apritzel> Welcome to Ubuntu 16.04 LTS (GNU/Linux 4.7.0-rc1 aarch64)
<ssvb> apritzel: wow, excellent news!
valkyr1e has joined #linux-sunxi
<apritzel> ssvb: but I can't really tell who the culprit was, I just rebased on top of 4.7-rc1 and redid the DT part
gianMOD has joined #linux-sunxi
<ssvb> apritzel: is the PMIC init code usable already?
valkyr1e has quit [Ping timeout: 260 seconds]
<apritzel> yes
<ssvb> available in some repository?
<apritzel> that works now, I did a lot of experimentation with the order of things, but in the end it was really the RSB hardware device address
<apritzel> will push it
<ssvb> thanks
valkyr1e has joined #linux-sunxi
valkyr1e has quit [Ping timeout: 264 seconds]
valkyr1e has joined #linux-sunxi