igraltist has quit [Remote host closed the connection]
igraltist has joined #linux-sunxi
al1o has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<wens>
tkaiser: got it
<MoeIcenowy>
wens: how can I know which reset line should be in nfc dt node?
<wens>
MoeIcenowy: look up the index in the user manual, it's part of the CCU
<wens>
clock control module/unit
<MoeIcenowy>
wens: do you mean BUS_SOFT_RST_REG0
<MoeIcenowy>
its bit13 is said to be NAND_RST
<GeneralStupid>
MoeIcenowy: armbian dosnt have such file -.-
apritzel has quit [Ping timeout: 244 seconds]
<wens>
MoeIcenowy: yes
<MoeIcenowy>
GeneralStupid: build your own mainline kernel.
popolon has joined #linux-sunxi
<GeneralStupid>
MoeIcenowy: short answer: no.
<GeneralStupid>
is it possible to debug my boot.cmd? i have two gpio set commads in front of it, they work (for "debugging") but thats it...
libv_ is now known as libv
<GeneralStupid>
is it possible to start my uboot with qemu?
<TheLinuxBug>
wow what a piece of grabage the Android release for OrangePi Plus 2E is, there is no way to functionally root it because they us some special kernel security making it so you can't ever remount the /system volume and even if you do get OTG installed and used adb which you can get root, all system volumes are mounted nosuid so chmoding 4755 su does nothing at al. Then too boot they have it so broke there is no way to install GAPPS. *sigh*
<TheLinuxBug>
why do these groups release such garbage
<TheLinuxBug>
can't run any real licensed apps on it, only hacked versions from non standard app stores
<TheLinuxBug>
means every app has ads
<TheLinuxBug>
just total junk.
<TheLinuxBug>
/rant
Mr__Anderson has joined #linux-sunxi
<dearfibonacci>
hello. trying to setup sunxi-kernel / sunxi-uboot on a device (ye older versions because of graphics) here's the uart log of what can I see.the script bin is in the /boot dir with the zImage and boot.scr http://pastebin.com/raw/tzB7kbH2
<KotCzarny>
�TheLinuxBug:have you tried to build whole thing from source?
<GeneralStupid>
dearfibonacci: is boot on your ext4 partition?
<GeneralStupid>
dearfibonacci: and paste boot.cmd too, plt
<MoeIcenowy>
"sun8i-a23-r-pinctrl 1f02c00.pinctrl: Reset controller missing" and "sun6i-dma 1c02000.dma-controller: No reset controller specified"
<MoeIcenowy>
is it normal?
apritzel has quit [Ping timeout: 244 seconds]
<oliv3r>
ssvb: i hope that it's expected that sun50i u-boot does not yet compile?
<ssvb>
oliv3r: what do you mean?
<wens>
MoeIcenowy: it's probably normal, since the reset controller is probed after dma
<ssvb>
oliv3r: there is no SPL support for sun50i but it should compile (I haven't tested it lately though)
<wens>
MoeIcenowy: and the r-pinctrl block does not have reset either
<apritzel1>
oliv3r: works for me on v2016.07-rc1
<apritzel1>
oliv3r: do you have an aarch64 cross compiler setup? CROSS_COMPILE=aarch64-linux-gnu-
<ssvb>
oliv3r: just checked it, seems to build fine
<oliv3r>
ssvb: bah :p
<oliv3r>
ssvb: i'm using the pine64 defconfig and i get
<oliv3r>
ssvb: ohh wait, i probably need a different compiler :)
<MoeIcenowy>
wens: thx
<MoeIcenowy>
I'm now trying to make full otg work on 4.7...
<ssvb>
oliv3r: pine64 uses a 64-bit processor and needs a 64-bit toolchain to build U-Boot :)
<ssvb>
oliv3r: have you just received a pine64 board yourself?
<oliv3r>
ssvb: nah, doing compiletests atm only :(
<oliv3r>
to ensure i didn't break anything :)
<oliv3r>
ssvb: more importantly, i just booted a baord from eMMC and dumping memory :)
[7] has quit [Ping timeout: 258 seconds]
<oliv3r>
ssvb: and it looks like there is more data injected into the sram then just the bootmedia, or am I miss-reading something here : http://sprunge.us/MeTJ
TheSeven has joined #linux-sunxi
<oliv3r>
ssvb: or does u-boot corrupt things?
<ssvb>
oliv3r: what is in the first 0x40 bytes of your SPL file for comparison?
<oliv3r>
let me find that
<oliv3r>
hmm it actually contains the same junk; i wonder why
<oliv3r>
makes sense as the bootloader was on this board for quite some time :)
<oliv3r>
the problem is now though, the nand bootloader i have doesn't have the fix either, so i'd have to a) figure out how I built the bootloader back then, patch it to 64 bytes (easy) and then flash it again
<ssvb>
that's why you are getting the byte at 0x28 changed from 0x14 to 0x02 (overwriting the U-Boot's reset vector code)
<oliv3r>
i've read up on your patches :) just didn't correlate it this early in the morning :)
kaspter has joined #linux-sunxi
<ssvb>
you can still use your old nand bootloader, this kind of corruption is not life threatening for U-Boot (otherwise somebody would have noticed it much earlier) :)
<GeneralStupid>
whats the fallback if boot.scr isnt working?
<oliv3r>
ssvb: yeah but i want to dump offset 0x28
<ssvb>
you still can do this
<oliv3r>
with the corruption going on?
<ssvb>
yes
<oliv3r>
ah okay :)
<oliv3r>
let me first get my emmc board working with the md stuff
<oliv3r>
as it was not compiled in for some reason
<ssvb>
because you had exactly the same with your eMMC test
<jelle>
ssvb: btw, pushed a refactored u-boot to my h3-hdmi branch
<jelle>
HPD still works, EDID is still a mystery
<ssvb>
oliv3r: and your eMMC test already showed the 0x02 code at the offset 0x28 :)
<oliv3r>
ah you looked further then i did :)
<oliv3r>
ok then i'll check the nand loader in a min
<oliv3r>
ah there it is indeed
<oliv3r>
i'll double check the nand, then send you a quick patch
<ssvb>
send it to the U-Boot mailing list and add me to CC
<ssvb>
jelle: thanks!
<oliv3r>
ssvb: of course
<mripard>
jelle: you know that you can't look at the current Allwinner kernel code to implement it in U-boot, right?
<oliv3r>
mripard: the latest aw kernel is not gpl-ed?
<jelle>
mripard: uhh no?
<jelle>
mripard: if that's the case, it's impossible to create a u-boot hdmi driver
<oliv3r>
heh, so they are in gpl violation and we can't use their stuff
<oliv3r>
jelle: clean-room RE
<oliv3r>
jelle: someone writes the specs (register info etc on the wiki) you implement it based on that spec
<ssvb>
mripard: Allwinner has to eventually resolve this issue, because they have no right to use this code inside of the Allwinner kernel code themselves
<oliv3r>
jelle: since technically you have been poisoned by the current implementation, you can technically only write the docs, and someone clean can implement it
<oliv3r>
but as ssvb says, they are in violation of the gpl so in the end their code must turn into gpl or removed
<ssvb>
mripard: AFAIK this is being resolved now, with the Pine64 people doing all the pushing of Allwinner in the right direction :)
RzR has left #linux-sunxi ["Leaving"]
<jelle>
damn this is an annoying situation
<jelle>
it's also the first time I'm attempting to implement something so big
<ssvb>
jelle: yes, but after Allwinner releases the fixed kernel source code, you would be able to contribute this code to U-Boot
IgorPec has quit [Ping timeout: 240 seconds]
<wens>
legal stuff is always annoying :/
<jelle>
otherwise I'll be able to contribute some docs
caog has joined #linux-sunxi
<ssvb>
jelle: yes, you can document all your findings in the wiki
<jelle>
does anyone know if the controller is really the same as the one mentioned used in imx.6
<wens>
didn't someone figure out the controller is designware with some obscuring on the data lines?
<jelle>
AW also still has to publish the h3 u-boot right?
<jelle>
or is that only on github?
<oliv3r>
jelle: that's sorta publishing it isn't it?
<mripard>
oliv3r: the HDMI part has "All rights reserved. Allwinner"
<oliv3r>
ssvb: i missed your comment, but quite likly yes :)
<oliv3r>
i did grep for #40 though and came up empty
<oliv3r>
ssvb: ah let me read the rest of your dump :)
<oliv3r>
ssvb: i guess it won't hurt to do a new dump of the BROM and see if there are changes, and hopefully a version identifier
<oliv3r>
to bad hno doesn't idle here anymore, as he extracted the initial BROM
Worf has joined #linux-sunxi
<ssvb>
oliv3r: this stuff is also a gray area, the boot ROM code is definitely copyrighted and we need to be careful when dealing with it
<oliv3r>
ssvb: BUT the BROM is in GPL violation :)
<ssvb>
oliv3r: is it?
<oliv3r>
ssvb: they incorperated GPL code into the BROM
<oliv3r>
yeah
<oliv3r>
and hence the BROM is poisoned
afaerber_ has joined #linux-sunxi
<oliv3r>
anyway, we can't change the BROM anyway, so it's merly a documentation excersize, 'cleanrooming' it so to speak, write down what happens and leave it a tthat
<oliv3r>
but yeah, i agree, very gray it is
<ssvb>
we are not trying to reimplement the BROM, so we are reasonably safe
<oliv3r>
ssvb: i'm looking at your dump and incidentally, ffff521c is pretty much where load_from_mmc just returns to the main loop
<ssvb>
all this is done merely for interoperability, which is perfectly legal unless I'm mistaken
<oliv3r>
ssvb: so the A10 brom might not do this as you say
<oliv3r>
ssvb: ianal :p
<ssvb>
if you check the irc logs, I mentioned earlier that the BROM probably had more than one revision in A10
<ssvb>
all my A10 devices do support this boot media identifier at the 0x28 offset in the SPL header
<oliv3r>
ssvb: i wonder what A10 hno then had
<ssvb>
it would be very interesting to find somebody with an ancient A10 to do some tests on it
<oliv3r>
would be nice if we could identify some version field in the brom header of sorts
<oliv3r>
i might have an early cubieboard or olimex board
<oliv3r>
with the SID set to 000000
<oliv3r>
so it might be one of those very early boards
<MoeIcenowy>
I'm trying to get 4.7-rc3 kernel with a33 full otg
<MoeIcenowy>
I backported some patches from jwrdegoede/linux-sunxi sunxi-wip
<oliv3r>
ssvb: can we get this info from /dev/mem from linux or is it u-boot only?
<ssvb>
oliv3r: the A10 DRAM controller initialization code already has to deal with the reversed reset bit, depending on the A10 revision
<jelle>
MoeIcenowy: it worked on my a33 tablet btw
<oliv3r>
ssvb: so that bit can be used to decide wether we can rely on the bit (on old boards)
<MoeIcenowy>
but i think a33 should use vbus-power-supply rather than vbus-det-gpio
<ssvb>
oliv3r: we can also fill the data at the 0x28 offset in the SPL header with some special pattern instead of 0
<ssvb>
oliv3r: and of the BROM does not support the boot device type reporting feature, then this magic value will remain at the offset 0x28 and the SPL will know that we can't rely on it
<GeneralStupid>
actually it looks like uboot ignores my scr file
<KotCzarny>
old uboot, bad uboot
<GeneralStupid>
is there a way to write uboot debug informations to fat ?
<ssvb>
oliv3r: it still would be very interesting to find an ancient A10 and run tests on it
<GeneralStupid>
KotCzarny: its the uboot from armbian, i guess it should work for me :D
<GeneralStupid>
KotCzarny: it supports bootz, so what do i need more?
<KotCzarny>
GeneralStupid: do you use serial console as debug?
<oliv3r>
ssvb: yeah i'll check my parts drawer at home :)
<oliv3r>
btw, i'll hold the patch back for now until i can check a nand board that i can access the sram from
<KotCzarny>
GeneralStupid: compiling uboot is quick and easy, just try it?
<MoeIcenowy>
jelle: will jwrdegoede appear here?
<GeneralStupid>
KotCzarny: no ... my serial console adapter is 300 km away... i would like to fix it without if possible
<jelle>
MoeIcenowy: you mean on irc?
<oliv3r>
ssvb: btw, to answer your SPI question :p
<MoeIcenowy>
jelle: yes
<oliv3r>
i talked to olimex at the time, to see if we could get a board with easy access to the pins
<KotCzarny>
GeneralStupid: which soc it is? h3 or a20?
<GeneralStupid>
h3
<oliv3r>
ssvb: i figured we should be able to solder a SPI flash to a lime board without nand, but then time ran out
<jelle>
MoeIcenowy: nick would be hansg, but I don't seen him often on irc
<jelle>
MoeIcenowy: better to just mail him I guess
<KotCzarny>
GeneralStupid: then it should work, did you compile your boot.scr after editing?
reinforce has joined #linux-sunxi
<oliv3r>
ssvb: i started to document the BROM just to see which spi ports would be checked etc
<KotCzarny>
mkimage -C none -A arm -T script -d boot.cmd boot.scr etc
<GeneralStupid>
KotCzarny: yes -.-
<GeneralStupid>
compile my boot.scr ? Wait what :D
<oliv3r>
ssvb: but as I said, i ran out of time to explore this further. i did get really excited to hear about your progress though :)
<GeneralStupid>
i thought i have to mkimage my boot.cmd to boot.scr -.-
<GeneralStupid>
thats not everything?
<KotCzarny>
yeah
<ssvb>
oliv3r: it would be great if Olimex could make an A20-OLinuXino-LIME2-SPI variant of the board :)
<oliv3r>
well the problem with SPI flash is that it usually is very small (or expensive)
afaerber_ is now known as afaerber
<oliv3r>
ssvb: how are you conducting your SPI experiments and how far are you? full boot right?
<KotCzarny>
GeneralStupid: im using it on my oranges without the problem, what exactly is not working for you?
<GeneralStupid>
KotCzarny: he is falling back to the old "loboris" uImage
<oliv3r>
ssvb: they exposed the NAND SPI0 pins?
<KotCzarny>
GeneralStupid: paste your boot.cmd
<oliv3r>
or does it work with any spi0 bus?
enrico_ has joined #linux-sunxi
<GeneralStupid>
KotCzarny: its exactly the kernel i used with armbian without problems. modules are there too, and i guess if its a kernel problem i should get display messages
<oliv3r>
ssvb: ah the board probably doesn't have nand :)
<ssvb>
oliv3r: yes, they have no NAND and expose the PC0-PC3 pins on the expansion header
<oliv3r>
nice :)
<oliv3r>
but you can fully boot allready, right?
<KotCzarny>
GeneralStupid: quick idea, do you have more than 1 sbc?
<KotCzarny>
just connect 3 wires and you have serial console
<oliv3r>
ssvb: awesome
<MoeIcenowy>
jelle, wens: If I want to contribute a dts file, can it have some stub code for some devices without mainlined driver?
<oliv3r>
oh wow that's like 5 days ago :)
<MoeIcenowy>
for example, I enable mmc1 for a wifi card not mainlined
<GeneralStupid>
KotCzarny: impossible now. Maybe in the evening -.- Did you see something very wrong on that file?
<MoeIcenowy>
(but it have a driver that can be compiled and running on mainline
<KotCzarny>
is there such thing as mmc 0:0 ?
<oliv3r>
in the allwinner boot0 code, was there a method to interrupt booting and force the u-boot console to activate?
<oliv3r>
boot0/boot1/u-boot
apritzel has joined #linux-sunxi
<KotCzarny>
also, double check if you are putting files on /dev/mmcblk0,because you might have it as a separate partition and mounted somehwere else
<GeneralStupid>
KotCzarny: boot is on /dev/mmcblk0p1
<GeneralStupid>
root is on ...p2
<KotCzarny>
yes, and when you are copying zImage where it goes?
<GeneralStupid>
boot is mounted into /media/boot/
<KotCzarny>
and if you copy zImage there its booting old kernel anyway?
<GeneralStupid>
i have uImage and zImage in one folder. and thats (i read it yesterday) uboots standard behaviour . if nothing works he tries to boot a uImage from a fat boot device
<KotCzarny>
never observed it
<jelle>
MoeIcenowy: not sure how that works, but shouldn't there first be a driver mainlined
<GeneralStupid>
i think i would never observe it unless it works ...
<wens>
keep that in mind when porting stuff onto later SoCs
montjoie has quit [Ping timeout: 240 seconds]
<ssvb>
tkaiser: does this information look clear/reasonable to you?
<tkaiser>
ssvb: Nope, I scratched my head already this morning :) To be honest, I have to look into later in more detail
montjoie has joined #linux-sunxi
<KotCzarny>
ssvb: most people didnt have statistical math courses, so it needs explanation or being more straightforward
<GeneralStupid>
tkaiser: thanks. but thats great...
<ssvb>
tkaiser, KotCzarny: ok, I just wanted to ask for some feedback and maybe clarify some things
<KotCzarny>
ssvb: tbh gnuplot was more understandable for me (i might've misunderstood it too, though)
<KotCzarny>
simple 'probability of the board to survive' would be the best imo
<ssvb>
KotCzarny: the table already contains the same data as the old gnuplot pictures
<ssvb>
KotCzarny: but we can bring the pictures back if necessary
<tkaiser>
KotCzarny: There's a histogram on the right
<KotCzarny>
tkaiser: that histogram is something else
<KotCzarny>
its just results chart
<KotCzarny>
earlier there was a nice gnuplot of the data from the second column (or third)
<tkaiser>
ssvb: I fear the whole section is only of use for you and maybe a few others, the average user doesn't care and the testers just want to know what to adjust where afterwards
<ssvb>
KotCzarny: yes, it was based on the data from the second column
<KotCzarny>
ssvb, i think it was a third, because it was nonzero at 624 etc
<KotCzarny>
also it starts growing big, so maybe move whole thing to subpage and only include a summary paragraph via wiki paragraph include
<tkaiser>
I second that.
<KotCzarny>
that way device's page will stay readable, have important information and you can go wild on the subpage
<tkaiser>
I've sent a few people to the wiki just to get the reaction: WTF?! TL;DR
<ssvb>
tkaiser: basically, the first column is the experimental data (how many boards have in fact failed in real tests)
<KotCzarny>
first column is clock speed
<KotCzarny>
:)
<KotCzarny>
unless you count from 0
<KotCzarny>
;)
<ssvb>
tkaiser: the second is trying to do the theoretical approximation assuming that the distribution is really Gaussian (the bell shaped curve)
<ssvb>
tkaiser: and the third is the "worst case" estimate, just in case if the actual distribution is not Gaussian but something more fancy
<ssvb>
tkaiser: the real probability may be something between the numbers in the second and the third columns, just in case if we have a somewhat distorted Gaussian distribution
<KotCzarny>
ssvb: distorted by crappy PSUs
<tkaiser>
ssvb: So not even 624 MHz can be considered 'safe' :(
<ssvb>
KotCzarny: oh, I'm counting the columns with the failure percents
<KotCzarny>
maybe we need a column in results table named 'PSU used'
<ssvb>
tkaiser: well, we have a theoretical prediction for having 0.4 % failures at 624 MHz, and this was exactly the same before
IgorPec has joined #linux-sunxi
<ssvb>
tkaiser: it's up to us to decide if it is "safe" enough or not
<tkaiser>
ssvb: I'm pretty fine with 624 MHz for all H3 boards and a provided 'test image' for people who think they would benefit from higher DRAM clocks.
<ssvb>
tkaiser: and since Hans de Goede is the nominal maintainer for the Cubieboard 2 board, ensuring reliability is his responsibility after all
<KotCzarny>
pcduinos use 480 too
<KotCzarny>
olimex the same
<KotCzarny>
so its just bananas/oranges with 432 by default
<ssvb>
tkaiser: I only verified that 480 MHz DRAM clock speed was working fine on *my* Cubieboard 2 (while I still had this board), but mileage may vary
<ssvb>
again, it's the maintainer's responsibility
<ssvb>
if the maintainer wants to ship crap to the end users, nobody can can really stop him
<KotCzarny>
question is, what value should be used on devices pages
<tkaiser>
Well, the distro people could. Or could at least try to encourage some users to test so that some awareness for bad settings might increase.
<wens>
KotCzarny: probably the one from the fex file? that's likely what you get from the vendor
<ssvb>
KotCzarny: I believe that it is taken from the vendor's fex file, and then adjusted if necessary
<KotCzarny>
vendors (especially chinese) ship software by copypaste
<wens>
KotCzarny: software is probably not their expertise
<ssvb>
yes, sometimes they are just copy/pasting from the other boards, and sometimes deliberately overclocking hardware to look good in the marketing materials
<KotCzarny>
i think sunxi wiki should note what is the source of that value (vendor or user tests)
<KotCzarny>
and discourage unstable ones
<ssvb>
tkaiser: yes, driving this activity by the distro maintainers may work too
<KotCzarny>
Memory type matters. It has been found that board with DDR3 memory tend to overheat much more than boards with DDR3L memory. At the time of writing, Xunlong Orange Pi boards are all based on DDR3L memory, but Banana Pi M2+ and NanoPi M1 boards are fitted with DDR3 memory instead
<KotCzarny>
nice comment if anyone wonders why the heck some boards overheat like crazy
<KotCzarny>
tkaise, consider doing banana m2 test with heatsinks on dram?
<tkaiser>
KotCzarny: Wrong/outdated info. Where did you find it so I can correct it?
<KotCzarny>
ie. it might lower board (and cpu in the consequence too)
cnxsoft has quit [Read error: Connection reset by peer]
<KotCzarny>
tkaiser, um, what about ths?
<tkaiser>
jrg: And I won't repeat this a 3rd time.
<KotCzarny>
also, he has opi+2e
<tkaiser>
KotCzarny: Doesn't matter on OPi 2E Plus. Clockspeed in this image is 816 MHz and that fine with Oranges (but bad for Banana)
<tkaiser>
BPi M2+ is an overheating version of OPi Plus 2E (minus one USB port, minus one led)
<tkaiser>
That's not that hard to understand, isn't it?
cnxsoft has joined #linux-sunxi
<tkaiser>
Every f*cking pin mapping is identical so everything works (minus...)
<KotCzarny>
hehe
formruga has joined #linux-sunxi
<jrg>
an overheating version lol
massi has quit [Read error: Connection reset by peer]
<KotCzarny>
hot version
massi has joined #linux-sunxi
<jrg>
tkaiser: this would involve wiping whats already installed?
<KotCzarny>
jrg, you need more sd cards
<tkaiser>
jrg: Nope, just use a spare SD card (4GB)
<jrg>
when i get home ill test it out
<tkaiser>
jrg: In Armbian forum someone wanted to use his OPi as AppleTalk device. Not possible with this 3.4.x BSP kernel. Switching to mainline kernel --> everything works perfectly now (and this must've been a very early version of montjoie's driver since this has happened months ago)
<ssvb>
kas: just use the "sun7i_lima_memtester_defconfig" to build it
<tkaiser>
ssvb: Oh, nice.
<kas>
thanks
<ssvb>
tkaiser: that's a different branch (for A10/A13/A20)
<MoeIcenowy>
bbrezillon: is these patches in a git repo?
<ssvb>
kas: it has embedded initramfs, so you just can temporarily replace your current kernel and boot it
<tkaiser>
ssvb: Ah, now I see it (the missing '-h3')
<kas>
okok
<ssvb>
the test will start automatically and report the results on the UART serial console, there will be also a spinning textured cube demo running (but you will not see it without a connected hdmi monitor)
<ssvb>
tkaiser: yes, we had the FEL based DRAM test for A10/A13/A20/H3 available from the very start, it was not Orange Pi PC specific :)
<ssvb>
tkaiser: I still did not have time for debugging it on opi+2e though
<kas>
ok, i want use lima with a10 dram calibration tools
<tkaiser>
ssvb: No worries. And I knew it, just got confused since I already searched in your repo for an A20 branch (but overlooked it)
naibmra has joined #linux-sunxi
<kas>
is this possible with embedded lima-memtester
<kas>
ssvb: I fixed this, script.bin -> disp_init_enable = 1
<KotCzarny>
kes, you did say its your own board, what does it mean?
<kas>
Custom desing for building automation
<jonkerj>
Some of you are working hard on NAND-support. My board (H3 Opi+) has eMMC, but the schematic suggest there is something NAND-y going on between SOC and memory chip. Does this mean that the memory could be interfaced both NAND and eMMC?
<KotCzarny>
nice, built locally or in china?
<kas>
locally
<KotCzarny>
kas, so no plans for super cheap boards from .eu ?
kaspter has quit [Ping timeout: 276 seconds]
<kas>
we change soc, freescale or smth
<kas>
maybe in future
<wens>
jonkerj: the design is you can choose either nand or emmc, but not both
<wens>
the pins are shared
<jonkerj>
of course, but in theory, I could use low-level NAND access instead of eMMC on this board?
<wens>
and you can layout a board that can use either emmc or nand in the same area, though with different pads of course
<wens>
maybe
<MoeIcenowy>
bbrezillon: thanks
<MoeIcenowy>
but after applying the patch
<MoeIcenowy>
the nand doesn't work properly either now
<MoeIcenowy>
(but the oobsize is correctly set to 1664 rather than 224
<oliv3r>
ssvb: !!! i found a working nand based board :) it uses the old 32bytes u-boot header, but lo en behold :)
<megi>
datasheet states that "Clock output of PLL_CPUX is used only for CPUX, and the frequency factor can be dynamically modified for DVFS"
<megi>
yet the diagram looks like it is used for ATB and AXI via some divider
apritzel has quit [Ping timeout: 244 seconds]
p1u3sch1 has quit [Ping timeout: 272 seconds]
apritzel has joined #linux-sunxi
<megi>
divider values are configured in u-boot, and if I increase the values to max, I prevent lockups when PLL_CPUX is modified in kernel (i put pintks around the register change, and it locks up exactly during the change, without this patch)
<megi>
it seems that something gets overclocked, via CPUX frequency change
<megi>
in other words, will u-boot maintainer accept my patch with "hey, it prevents lockups but i don't know why" explanation? :D
<ssvb>
megi: what is the original and what is the new clock frequency when it deadlocks?
p1u3sch1 has joined #linux-sunxi
<megi>
original is what is set in u-boot
<ssvb>
either way, it's best to first figure out what is wrong
<ssvb>
if the BSP kernel is able to work correctly and do DVFS things after booting with the same bootloader, then your code is probably doing something wrong
apritzel has quit [Ping timeout: 244 seconds]
<megi>
it's probably not my code, I just set up the operating points in dts
<megi>
cpu clock is managed by sunx-clk
<ssvb>
looks like it might be fun to debug
<oliv3r>
bbrezillon: did you ever get the problem confirmed about corrupted nand, even in slc mode? i just found 1 of the 3 boards i used for NAND and it was still intakt, (i had a failure rate of 2/3 back then)
<megi>
I don't remember what the new frequency was, but it could have possibly been lower, because the original was set to 1.3GHz and the new one get's set by thermal-zone
lamer14658332975 has joined #linux-sunxi
<ssvb>
megi: is the voltage also getting changed?
<megi>
no, I tested it without voltage scaling
tkaiser has quit [Ping timeout: 240 seconds]
<megi>
I did the testing a few months ago, but I remember isolating it just to the PLL_CPUX register change, with all else equal
<wens>
AXI is probably related to the memory / bus interface of the cpu
<wens>
clocking it too high might not work
<ssvb>
megi: anyway, it's best to cross-check everything against the BSP kernel, compare the AXI divisor settings and everything else
<megi>
also it might be, that the bsp kernel touches the ATB/AXI divider setup in the kernel too so even if u-boot sets up something not stable, the kernel fixes it
<megi>
yeah, I'll try checking what exactly BSP kernel does with relevant registers during boot
<bbrezillon>
oliv3r: I don't remember seeing a corruption when operating in SLC mode, but I can't say it will never happen :-)
<ssvb>
megi: isn't the arisc core responsible for the DVFS job on H3 though?
<megi>
not necessarily
<megi>
you can successfully do dvfs without it
lamer14658332975 has quit [Ping timeout: 244 seconds]
<ssvb>
so far it looks like you can't ;)
<megi>
it works for me
<megi>
with the patch
<megi>
but it might make it harder to debug what the bsp kernel does...
<ssvb>
that's what I mean
<megi>
is there a way to access the registers from userspace? like using /dev/mem or something?
<megi>
I'm thinking of just dumping the registers while the kernel is running on various frequencies
<ssvb>
yes, try devmem2
cptG_ has joined #linux-sunxi
<megi>
ah, cool :)
<ssvb>
it might be necessary to toggle some kernel option to allow it to work though, but this is simple
<ssvb>
CONFIG_STRICT_DEVMEM
<megi>
thanks
cptG has quit [Ping timeout: 250 seconds]
<oliv3r>
bbrezillon: i'll see if ihave a corrupted board and will try to get a dump from it if that helps at all
<MoeIcenowy>
bbrezillon: ubifs now do not support 4MByte eraseblock?
<MoeIcenowy>
"mkfs.ubifs /dev/ubi0_0" gets "Error: too large LEB size 4161536, maximum is 2097152"
<bbrezillon>
MoeIcenowy: yes, we have a patch for that one as well, though if you use SLC mode you'll have 2M pages
orly_owl has quit [Ping timeout: 244 seconds]
<megi>
aha! :)
<megi>
ssvb: I got the difference
<ssvb>
megi: great! what was it?
<megi>
CPUX_AXI_CFG_REG at 0x01C20050 has value 0x00020202 on bsp kernel, which means AXI_DIV_3 and ATB_DIV_4, u-boot sets ATB_DIV_2
<megi>
so the ATB clock on mainline gets twice the frequency
<MoeIcenowy>
bbrezillon: but the SLC mode commits are difficult to cherry-pick
caog has quit [Ping timeout: 244 seconds]
orly_owl has joined #linux-sunxi
Inode has joined #linux-sunxi
apritzel has joined #linux-sunxi
<megi>
ssvb: I used my patched u-boot, with original u-boot the dividers stay the same
<ssvb>
megi: does fixing only the ATB divisor help to avoid deadlocks?
<TheLinuxBug>
anyone have a link for Lubuntu_1404_For_OrangePi_Plus2E_v0_8_0.img.xz that isn't baidu - I would love to download it but I can't get more than 5kb/sec
<KotCzarny>
you dont want it
<TheLinuxBug>
hmm
<TheLinuxBug>
it worse than armbian
<TheLinuxBug>
?
<KotCzarny>
how should i say it
<TheLinuxBug>
I am apauled by their Android release
<TheLinuxBug>
so nothing would suprise me at this point
<KotCzarny>
armbian is the best thing you can get for sunxi boards
<KotCzarny>
and manufacturer images are the worst thing you can get
<TheLinuxBug>
That Android release is the biggest pile of horse manure I think I have ever dealt with regarding Android
<KotCzarny>
their linux images are just random grabs from the internet
<KotCzarny>
just to fill their download pages
<KotCzarny>
and to claim that 'they have software'
<TheLinuxBug>
I actually was going to use this for a media center for my sister until I realized how total crap that android release is
<TheLinuxBug>
ended up giving her my Odroid C2 and ordering a new one
<KotCzarny>
you can still use armbian for that
<TheLinuxBug>
it was not worth it to have her call me all the tmie asking about apps etc
<TheLinuxBug>
Odroid C2 just works
<TheLinuxBug>
and hardkernel produces a beautiful Android image
<KotCzarny>
you know why you pay for those chinese boards so little?
<TheLinuxBug>
If I were anywhere near any of them I would offer to buy coffee, thats how much a dream it is compared ro the orang Pi
<TheLinuxBug>
Oragne Pi Plus 2E
book` has quit [Ping timeout: 240 seconds]
<TheLinuxBug>
well
<TheLinuxBug>
its depressing
<KotCzarny>
not really
<TheLinuxBug>
because it COULD be an awesome board for that
<KotCzarny>
just grab hard work armbian folks did to make things work
<TheLinuxBug>
if only someone spent a few minutes to think when they built the SDK
<TheLinuxBug>
yeah but my sister who isn't a computer nerd isn't gonna understand using Armbian, thats the point of Android
<TheLinuxBug>
if that would have suited the purpose and I thought she could handle it, then I would have taken that route
<TheLinuxBug>
unfortunately not so much
<KotCzarny>
why are you saying about 'lubuntu' then?
<TheLinuxBug>
I was just gonna look at it on the board now and see how crappy it was lol
<TheLinuxBug>
before I tossed it in the bin of 'maybe I will play with again someday' and go back to working with my RPi3
<KotCzarny>
board is nice, software is nonexistent
<TheLinuxBug>
and oder me a new odroid c2
<KotCzarny>
but armbian fills that hole
Seppoz has quit [Remote host closed the connection]
<KotCzarny>
still, you can grab any similar board, move script.bin and have a working os
<KotCzarny>
well, not move, but replace some magic things
<TheLinuxBug>
KotCzarny: don't get me wrong, sunxi does wonderful work and I am sure it makes a half decent workstation, but thats not what I wanted to use it for.. so for now it doesn't have a real use for me as I spent 36 hours messing with Android and such to find just an abysmal piece of crap that no one even spent time to care about. Kinda removed for me the attraction it once had.
<KotCzarny>
see above, beauty of soc is that differences are small enough to swap images
<TheLinuxBug>
if you can find/get me easy steps to make one of the Android images that is worth a crap to work, ill send you $20 on paypal. For me though my time is to valuable to even look at that board again for a few weeks, I honestly about through it at the wall after I realized the shit kernel they installed on that android release.
<KotCzarny>
tbh i havent bothered with android as i wanted them for linux only
<KotCzarny>
for a quickie you can just try android images for other h3 board
<TheLinuxBug>
I actually just tried one that was supposed to be for OPi PC
ganbold has quit [Remote host closed the connection]
<TheLinuxBug>
with no luck
<TheLinuxBug>
uboot seems different
<TheLinuxBug>
doesn't even try to boot the sdcard
jernej has joined #linux-sunxi
<KotCzarny>
maybe it detects wrong mmc device or something
<TheLinuxBug>
KotCzarny: My A10's and my BPi M1 are my main work horses because of SATA and I use them for several things around here, but without SATA or a usable android image at least right now that OrangPi Plus 2E board doesn't really garner much interest atm, plus im so frustrated with it att his point I could happily go a few weeks without thinking about it again :Z
<tkaiser>
TheLinuxBug: Why do you waste your time with this 'official' Android build? You find in Orange Pi forums a few Android ROMs for H3 TV boxes.
<tkaiser>
TheLinuxBug: Then grab fex file from Armbian, read through the link I posted a few days ago how to overwrite sys_config.fex stuff and you're done.
<tkaiser>
I try to keep every fex we use at Armbian compatible with the old u-boot 2011.09 all the other Linux images or Android ROMs are using (except of led definitions). So it should just work
<TheLinuxBug>
tkaiser: mostly because it already on the eMMc and my goal would be to run this from eMMc and not a SDcard.
xcasex has joined #linux-sunxi
<TheLinuxBug>
tkaiser: but obviously that is the direction I will have to go if I want anything usable. It is mostly disappointing to me they would even release those Android images as they are utter crap and the person who made them has to know that.
jstein has joined #linux-sunxi
tkaiser has joined #linux-sunxi
<tkaiser>
TheLinuxBug: I don't know Android at all so can't say that much. But by following some threads over there at the forums half a year ago I got the impression that there exist a few pretty good ROMs from TV box vendors.
<tkaiser>
TheLinuxBug: That should work on all H3 devices... but know that I thought about it again: Most probably neither Wi-Fi nor (Gbit) Ethernet will be working since the aging Android kernel neither supports the new 8189FTV chip and external GbE PHY (the latter to be confirmed)
paulk-nyan-big has joined #linux-sunxi
mossroy has quit [Quit: Quitte]
<TheLinuxBug>
yeah thats probably likely, tbh if I had more time for the project overall (which I think I have expired my current time for that) I would probably get the SDK and try to build my own kernel etc. Unfortunately I just don't have the time for it atm, so was kinda hoping for something exitent to work. Obviously the board works well with Arbian, can Igor and the people who work on that are #1 in my book ;p but unfortunately...
<TheLinuxBug>
there does not exist an equally good team of people making a decent Android dist
<TheLinuxBug>
existent*
<TheLinuxBug>
Armbian (eesh the spelling mistakes are just rolling off my fingers today)
Mr__Anderson has quit [Remote host closed the connection]
paulk-nyan-big has quit [Quit: Leaving]
Shirasaka-Hazumi has quit [Ping timeout: 258 seconds]
Shirasaka-Hazumi has joined #linux-sunxi
fredy has quit [Excess Flood]
fredy has joined #linux-sunxi
Shirasaka-Hazumi has quit [Ping timeout: 272 seconds]
jstein has quit [Remote host closed the connection]
Shirasaka-Hazumi has joined #linux-sunxi
Macer has quit [Ping timeout: 252 seconds]
lemonzest has quit [Quit: Leaving]
nove has quit [Quit: nove]
Macer has joined #linux-sunxi
piotaras has quit [Quit: Page closed]
piotaras has joined #linux-sunxi
piotaras has quit [Remote host closed the connection]
indy has quit [Ping timeout: 244 seconds]
indy has joined #linux-sunxi
<lennyraposo>
hey longsleep
<lennyraposo>
are you about mate
tlwoerner has quit [Ping timeout: 240 seconds]
<lennyraposo>
ssvb are you about?
<ssvb>
lennyraposo: yes, somehow
<lennyraposo>
ya
<lennyraposo>
allwinner is messed up
<lennyraposo>
here is amessage I just got from them through tllim
<lennyraposo>
Allwinner current working on 64 Mali driver for us and there encounter an issue as follow due to current system don't have xorg. They need to compile an xorg with backtrace open. Thanks on the assistance.