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
Nacho has quit [Ping timeout: 248 seconds]
vagrantc has quit [Quit: leaving]
mosterta has quit [Ping timeout: 240 seconds]
mpmctoo has quit [Ping timeout: 250 seconds]
premoboss has quit [Ping timeout: 260 seconds]
premoboss has joined #linux-sunxi
naobsd has quit [Quit: naobsd]
mpmctoo has joined #linux-sunxi
nemunaire_ is now known as nemunaire
<apritzel> ssvb: longsleep: I managed to load upstream U-Boot with boot0
<apritzel> plus: booti works! I can load an AArch64 kernel
fl_0 has quit [Ping timeout: 260 seconds]
<apritzel> the culprit was setting CNTFRQ in sunxi/board.c
<apritzel> which only works in secure state
<apritzel> commenting this for the time being fixed it
orly_owl has quit [Ping timeout: 272 seconds]
<apritzel> also the same fix allows U-Boot to run on the Remix Mini!
<apritzel> enough for today ....
apritzel has quit [Ping timeout: 248 seconds]
fl_0 has joined #linux-sunxi
Nacho has joined #linux-sunxi
mzki has quit [Quit: leaving]
Andy-D__ has quit [Remote host closed the connection]
khuey is now known as khuey|away
jstein_ has quit [Remote host closed the connection]
Andy-D has joined #linux-sunxi
cnxsoft has joined #linux-sunxi
Andy-D has quit [Ping timeout: 256 seconds]
Andy-D has joined #linux-sunxi
mark5 has quit [Ping timeout: 252 seconds]
vickycq has quit [Ping timeout: 240 seconds]
vickycq has joined #linux-sunxi
egbert has quit [Disconnected by services]
egbert has joined #linux-sunxi
sid14726 has joined #linux-sunxi
ninolein has quit [Ping timeout: 252 seconds]
ninolein has joined #linux-sunxi
Andy-D has quit [Remote host closed the connection]
Andy-D has joined #linux-sunxi
Andy-D has quit [Remote host closed the connection]
Andy-D has joined #linux-sunxi
lerc has quit [Remote host closed the connection]
lerc has joined #linux-sunxi
orly_owl has joined #linux-sunxi
cnxsoft1 has joined #linux-sunxi
cnxsoft has quit [Ping timeout: 248 seconds]
cnxsoft1 is now known as cnxsoft
Andy-D has quit [Ping timeout: 240 seconds]
lerc has quit [Ping timeout: 260 seconds]
lerc has joined #linux-sunxi
Andy-D has joined #linux-sunxi
ganbold has quit [Quit: Leaving]
montjoie has quit [Ping timeout: 252 seconds]
ganbold has joined #linux-sunxi
montjoie has joined #linux-sunxi
ganbold has quit [Quit: Leaving]
ganbold has joined #linux-sunxi
gzamboni has quit [Read error: Connection reset by peer]
p1u3sch1 has quit [Ping timeout: 264 seconds]
p1u3sch1_ has joined #linux-sunxi
TheSeven has quit [Ping timeout: 260 seconds]
TheSeven has joined #linux-sunxi
NiteHawk has quit [Ping timeout: 240 seconds]
IgorPec has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
JohnDoe_71Rus has quit [Read error: Connection reset by peer]
JohnDoe_71Rus has joined #linux-sunxi
montjoie has quit [Quit: Lost terminal]
reinforce has joined #linux-sunxi
montjoie has joined #linux-sunxi
gzamboni has joined #linux-sunxi
IgorPec has quit [Quit: Nettalk6 - www.ntalk.de]
naobsd has joined #linux-sunxi
mosterta has joined #linux-sunxi
NiteHawk has joined #linux-sunxi
domidumont has joined #linux-sunxi
domidumont has quit [Remote host closed the connection]
domidumont has joined #linux-sunxi
flok420 has joined #linux-sunxi
mosterta has quit [Ping timeout: 260 seconds]
_massi has joined #linux-sunxi
premoboss has quit [Ping timeout: 264 seconds]
naobsd has quit [Quit: naobsd]
IgorPec has joined #linux-sunxi
premoboss has joined #linux-sunxi
tchiwam has joined #linux-sunxi
tchiwam_ has quit [Ping timeout: 250 seconds]
mark5 has joined #linux-sunxi
ricardocrudo has quit [Ping timeout: 240 seconds]
<mark5> Hi. I compiled http://linux-sunxi.org/Mainline_U-Boot#Compile_U-Boot for an A10 board which hangs on "DRAM:" according to uart. Anybody who happens to recognize this? (I'm going to try the fail-safe DRAM settings in a bit)
<plaes> mark5: what board?
<mark5> plaes: A10-OLinuXino-LIME
cosm has quit [Quit: Leaving]
<plaes> I assume you used the A10-OLinuXino-Lime_defconfig ?
<mark5> make CROSS_COMPILE=arm-linux-gnueabihf- A10-OLinuXino-Lime_config
<plaes> should be 'defconfig'
<plaes> anyway, read this: http://linux-sunxi.org/Mainline_U-Boot#U-Boot_2015.07.2B_won.27t_start
<mark5> ugh, looks like you're right
<mark5> I'll try with defconfig
<plaes> if the defconfig doesn't help ;)
<wens> might also be the dram detection bug hans posted about on the u-boot mailing list?
<plaes> what bugs me is why the 'make ... A10-OLinuXino-Lime_config' worked..
clonak has quit [Ping timeout: 272 seconds]
<plaes> mark5: do you use git checkout?
clonak has joined #linux-sunxi
cptG_ has joined #linux-sunxi
cptG has quit [Ping timeout: 245 seconds]
apritzel has joined #linux-sunxi
ricardocrudo has joined #linux-sunxi
<rellla> have i missed sth or is the H3 display driver not cc'ed for linux-sunxi ml?
<mark5> plaes: Yes I did. I'm now gonna try with the v2016.01 tag as well as with 'defconfig'
<plaes> rellla: it wasn't
ricardocrudo has quit [Ping timeout: 240 seconds]
<mark5> plaes: I'm wondering, the U-boot guide only mentions that you should copy u-boot-sunxi-with-spl.bin onto the SD, but then http://linux-sunxi.org/Mainline_U-Boot#U-Boot_2015.07.2B_won.27t_start mentions using u-boot-dtb.bin and u-boot-dtb.img.. do I need those?
<plaes> no, things changed after 2015.07
<mark5> I see
<plaes> mark5: please recheck the Mainline U-boot page
<plaes> I edited it a bit..
<plaes> starting from "Determine build target"
<mark5> alright :)
<plaes> moved it around a bit
<plaes> ok, that should be enough
<mark5> Booting from the v2016.01 now with defconfig
<mark5> passed DRAM now :) currently Starting kernel
<plaes> anything else?
<plaes> or it hangs there? :)
<mark5> seems to hang
<plaes> yeah.. this is most common issue :S
<plaes> now please go through this section: http://linux-sunxi.org/Mainline_Kernel_Howto#Kernel_Configuration
<plaes> mark5: can I assume you're building kernel yourself?
<mark5> that is correct
<mark5> I'll enable debugging
<plaes> hrm.. we had a "Hangs with Starting kernel" section somewhere in the wiki, but I cannot find it anymore
mzki has joined #linux-sunxi
<mark5> plaes: menuconfig throws out CONFIG_DEBUG_SUNXI=y when I set it, any alternatives or should the Kconfig options be enough?
<plaes> mm.. I don't know
<mark5> Think I just need DEBUG_SUNXI_UART0
<plaes> btw, you're using monitor or uart?
<mark5> uart
<plaes> (I'm a bit lost here..)
cosm has joined #linux-sunxi
<plaes> mark5: any luck?
iamfrankenstein has joined #linux-sunxi
ricardocrudo has joined #linux-sunxi
HeHoPMaJIeH has joined #linux-sunxi
<mark5> plaes: was away during the compile, going to deploy the image and modules
<mark5> plaes: I dont get any more output now it seems, I'll export it in a moment
<plaes> ugh :(
<plaes> contents of your boot script?
<plaes> have you set bootargs?
<mark5> plaes: i switched from building uImage to zImage but the old uimage was still on the SD.. apparently it booted that even though the boot.scr does not contain instructions to load that
<mark5> removed the uImage and now it does something more \o/
<mark5> Unless.. you do not update the boot.scr to point to zImage
<mark5> This is not one of my brightest days
<plaes> well, it happens ;)
<apritzel> Oh dear, from Allwinner's ATF port for the Pine64: counter_base_frequency = 24<<20;
<plaes> o_O
<apritzel> I take it the arch timer is clocked from that 24MHz clock?
<apritzel> so we are 4.8% off ;-)
<NiteHawk> oh, that's noteworthy - u-boot hangs with a non-helpful "starting kernel" if you accidentally provide a uImage instead of zImage for bootz?
<apritzel> NiteHawk: no, it should detect this and barf
<plaes> what was the command to print out env in u-boot?
<apritzel> NiteHawk: something like "Bad Linux ARM zImage magic!"
<NiteHawk> apritzel: thx. then i misunderstood mark5's problem - i guess that uImage (setup in boot.scr) might still have been a legacy (3.4) kernel then
<wens> apritzel: what do you mean 4.8% off?
<apritzel> 24 shift left 20 is not 24 MHz
<wens> hehe
<plaes> it's 25165824 Hz
<wens> ok that was stupid
paulk-collins has joined #linux-sunxi
<apritzel> Linux is diligently reporting 25.1 MHz, so any timing in the kernel would be ~5% off
<apritzel> plaes: have you found "printenv" already?
<ssvb> apritzel: regarding "I managed to load upstream U-Boot with boot0" - great news, thanks!
<apritzel> ssvb: well, pat yourself on the shoulder, it's your U-Boot port that runs ...
<apritzel> I just adjusted the TEXT_BASE to make room for the header and commented the CNTFRQ write which does not work in non-secure
<apritzel> ssvb: btw: you can find the booti patch in my u-boot github repo, but that one relies on ARM trusted firmware
<apritzel> so it does not work when loaded via FEL
<apritzel> if there a nice way to load additional blobs into RAM from U-Boot's SPL code?
<apritzel> So apart from the actual U-Boot image?
<apritzel> Or would we somehow append ATF to that image?
<mark5> plaes: So now it reads the proper zImage and then attempts to start the kernel and.. hangs :( https://bpaste.net/show/a01e1cfdb43e
<ssvb> well, we will need to move this discussion to the U-Boot mailing list
<ssvb> but I'm sure that all of this is solvable
<ssvb> reading a piece of data from the SD card into RAM is definitely possible
<ssvb> btw, maybe it would be a good idea to bring back the CROSS_COMPILE_SPL topic again - http://lists.denx.de/pipermail/u-boot/2012-April/122236.html
<ssvb> too bad that the aarch64 toolchain does not support the -m32 option or everything would have been so much easier
<apritzel> ssvb: indeed ;-)
<apritzel> but then you know that the ISA and the encoding is quite different
<apritzel> so yes, I was thinking about that too: for the SPL we probably need Thumb2, which is only there for AArch32
<ssvb> in principle, we could probably also build the SPL in 64-bit mode and have some sort of a small trampoline hardcoded in mksunxiboot
<ssvb> it might be interesting to estimate the code density sacrifice
<apritzel> ssvb: but aren't we already pretty stuffed with the 32KB, even with Thumb?
<ssvb> apritzel: I have made some tests and presented them in a table here - http://linux-sunxi.org/BROM#U-Boot_SPL_limitations
<ssvb> on older SoCs the limit is 24KiB, and that's why we care so much about the SPL size
<ssvb> A64 raises this limit to 32KiB, which provides us with a bit more space
Nyuutwo has joined #linux-sunxi
<ssvb> we can also use a runtime decompression stub to gain even more space
<apritzel> Oh, it was 24 KB only before, I missed that
<apritzel> I just remember that building for SPL for my BananaPi was pretty tight
<apritzel> from the backer mail from pine64.com: "Your PINE64 will arrive in a protective cardboard box...."
<ssvb> they have learned their lesson :-)
<apritzel> indeed
<ssvb> too bad that the 64-bit SPL would make FEL boot problematic
<mark5> So how do I go about debugging a mainline kernel/uboot hanging at 'Starting kernel...' ? earlyprintk does not give me any extra info
<ssvb> mark5: maybe start with something that is known to work?
<mark5> ssvb: Such as?
<ssvb> and then figure out which of your changes break everything?
<ssvb> mark5: A10-OLinuXino-Lime is supported by the mainline U-Boot and the mainline kernel, just follow the instructions carefully without ad-hoc improvisations and everything should be fine
<mark5> ssvb: I'll go through everything again. I think the issue might be with the boot.cmd file, the instructions on what it should look like are a bit contradictory: http://linux-sunxi.org/Mainline_Kernel_Howto#boot.cmd http://linux-sunxi.org/Mainline_U-Boot#Boot
<ssvb> indeed, Mainline_Kernel_Howto needs more love
<ssvb> apart from recommending uImage instead of zImage, the Mainline_U-Boot instructions are more up to date
<ssvb> what does your boot.cmd look like?
<ssvb> also do you use the dtb file from your kernel build?
<mark5> Tried 2 variants of boot.cmd with same result https://bpaste.net/show/20a3824fefc6
<mark5> the dtb file is from ~/linux-4.4/arch/arm/boot/dts/sun4i-a10-olinuxino-lime.dtb
<ssvb> did you build this sun4i-a10-olinuxino-lime.dtb file yourself?
<mark5> Yes, with `make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- -j4 zImage dtbs`
<mark5> (or is that a no? :) )
<plaes> looks ok
<mark5> So if you're asking if I used a custom DTC then no
<ssvb> it's just that dtb files are not very compatible between different kernel versions, so you could run into troubles by picking some existing blob from your sd card image built for some other kernel
<ssvb> but apparently this is not the case, which is good
bmeneg_ is now known as bmeneg
<ssvb> everything looks ok to me, don't know what could be the problem
<ssvb> unless your toolchain happens to be buggy
viccuad has joined #linux-sunxi
<ssvb> apritzel: regarding the latest discoveries, is the description at http://linux-sunxi.org/Pine64#Sunxi.2FLegacy_U-Boot up to date?
<apritzel> ssvb: no, probably not
<apritzel> well, the rant part still holds ;-)
<ssvb> it would be nice to have a description of the boot0, ATF and U-Boot roles in the boot process
yann|work has quit [Ping timeout: 245 seconds]
<mripard> mark5: what's your configuration file ?
<apritzel> ssvb: Yes, I was planning on this, but spend the whole night yesterday inserting debug("I was here\n") lines into board_f.c and board_r.c ;-)
<plaes> mark5: did you use sunxi_defconfig?
<plaes> for kernel
<mark5> ssvb: you might be onto something there.. The toolchain for debian described here http://linux-sunxi.org/Toolchain#Debian scared me a bit because of the words 'unstable' and 'testing', so I used this recommended by someone else; 'apt-get install gcc-4.7-arm-linux-gnueabihf'
<mark5> And symlinks which remove the -4.7
<mark5> plaes: as the basis yes, but with plenty of changes. I will try to recompile the kernel with pure sunxi_defconfig to rule that out
Gerwin_J has joined #linux-sunxi
<mark5> mripard: which configuration file do you mean?
<apritzel> mark5: he talks about your .config
<plaes> kernel
<mark5> Ah ok
<apritzel> if you for instance miss the CONFIG_SERIAL_8250_DW option, there will be no output
sid14726 has quit [Ping timeout: 252 seconds]
<apritzel> which sunix_defconfig would take care of
<mark5> apritzel: CONFIG_SERIAL_8250_DW=y
<mark5> check
<mark5> Brb, grabbing lunch
Nacho has quit [Ping timeout: 245 seconds]
Nacho has joined #linux-sunxi
fl_0 has quit [Ping timeout: 252 seconds]
<apritzel> ssvb: I fixed the Wiki in respect to the Pine64 boot sequence
BarthezZ has joined #linux-sunxi
fl_0 has joined #linux-sunxi
paulk-collins has quit [Remote host closed the connection]
premoboss has quit [Quit: Sto andando via]
<mark5> ssvb: plaes: still hangs at Starting Kernel when using the exact sunxi_defconfig (though with the debugging options specified in http://linux-sunxi.org/Mainline_Kernel_Howto#Early_printk enabled)
<plaes> do you happen to have any other devices?
domidumont has quit [Read error: Connection reset by peer]
<ssvb> apritzel: thanks! that's much appreciated
clonak has quit [Ping timeout: 272 seconds]
tkaiser has joined #linux-sunxi
<tkaiser> Today my Orange Pi One arrived and I simply gave it a try based on Armbian's Orange Pi H3 image (based on ssvb
<tkaiser> 's kernel and mainline u-boot): I only changed pmuic_type = 1 in the fex file but to no avail. "ARISC ERROR" flooding the log: http://pastebin.com/Q3taqHbL
<ssvb> tkaiser: my guess is that arisc is trying to use the sy8106a pmic and fails
<ssvb> the arisc (openrisc) core is responsible for dvfs on h3
<tkaiser> Yes, I just had a look at the orangepi.org site to look for new OS images. Seems there's nothing.
<tkaiser> But the funny thing is: By changing "pmuic_type = 1" I was able to further increase the SoC's internal temperature.
clonak has joined #linux-sunxi
<ssvb> tkaiser: but the mainline kernel is going to be probably working fine on it :-)
sid14726 has joined #linux-sunxi
<tkaiser> Sure, but I want to play with the camera module I ordered again so no easy way to escape from 3.4 ;)
<mark5> plaes: No, just this one. But I'll try to use the g++-arm-linux-gnueabihf compiler
<plaes> g++ is C++ compiler
<mark5> Yeah.. Just following http://linux-sunxi.org/Toolchain#Debian to the letter
<tkaiser> ssvb: I've been wrong: changed back to pmuic_type = 2 and rebooted: Higher temperature again. Then I did a shutdown, disconnected PSU and after the next boot the temperature was as low as in the beginning. So this is a reboot issue and my assumption regarding pmuic_type was wrong
FDCX has joined #linux-sunxi
Worf has quit [Quit: Konversation terminated!]
yann|work has joined #linux-sunxi
viccuad has quit [Ping timeout: 276 seconds]
JohnDoe_71Rus has quit [Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org]
viccuad has joined #linux-sunxi
naobsd has joined #linux-sunxi
cnxsoft has quit [Remote host closed the connection]
engideavr has quit [Quit: Konversation terminated!]
cosm has quit [Ping timeout: 272 seconds]
<tkaiser> ssvb: LOL, I had to start lima-memtester on the Orange Pi One to realise that the two LEDs are also present there
<jelle> it's still only 5 euro's cheaper then the pc hrrm
<tkaiser> jelle: Yes, it's pretty limited but if you don't need all the missing stuff you save the $5
sid14726 has quit [Max SendQ exceeded]
cosm has joined #linux-sunxi
<ssvb> jelle: only 5 euro? it's 1.5x cheaper :-)
<ssvb> and it has a smaller size, which is also nice
<tkaiser> ssvb: Not really, since you don't get shipping discounts on volume orders ;-)
<jelle> ugh I might order one, since my chip is only arriving at June 2016
<ssvb> tkaiser: a good point :-)
<jelle> then I can finally build my weather station hehe
<tkaiser> IIRC they charge 3.5$ dollars each and if you order 2 pieces then you get a discount of ~2$, but no more if you order eg. 10 pieces
<ssvb> tkaiser: but when ordering two pieces, it is no longer VAT exempt in EU?
<jelle> hmm orange pi one even has csi
<tkaiser> Sorry, misunderstanding. I ordered the One and the camera module this time and shipping was 'just' $5 instead of $7
<tkaiser> The one also needs the expander board for the camera and they included it without additional costs
<tkaiser> $10 for the board, $6 for the camera, $5 shipping
<ssvb> nice
<jelle> 3 euro shipping here, 9 euro for the board
<jelle> not sure if it includes a cable hmmm
reinforce has quit [Quit: Leaving.]
<ssvb> it does not, but there should be also bundles with the cable included
<tkaiser> jelle: $9 or $9.99? And no, the only included cable is the ribbon thing when you order the camera module
mark5 has quit [K-Lined]
<jelle> tkaiser: 8,89 euro ;-)
raknaz has joined #linux-sunxi
<tkaiser> Xunlong used the same DRAM type as on the PC just with half the capacity
<ssvb> and unlike Olimex, and they use two x16 dram chips, which means full 32-bit bus width
alexvf has joined #linux-sunxi
<ssvb> no performance sacrifice and still amazingly cheap price
ganbold has quit [Ping timeout: 256 seconds]
mark5 has joined #linux-sunxi
paulk-collins has joined #linux-sunxi
<ssvb> btw, has anyone seen Allwinner A64 based tablets anywhere?
<mripard> ssvb: the nexus 9?
<mripard> ah, damn
<mripard> Allwinner
<mripard> sorry
* ssvb just wonders if A64 is a marketing failure
<libv> ssvb: so you are suggesting that this only a chip that is popular in the development board market?
<libv> a chip that is only even
<libv> if that is true, then that makes it very good for linux-sunxi and the mainlining effort
<libv> then allwinner has to really sit up and listen
JohnDoe_71Rus has joined #linux-sunxi
<libv> there does seem to be somethings on aliexpress
<libv> s/does\ /do/
<libv> iRULU eXpro X1s
<libv> but little else
<ssvb> hmm, you are right
<ssvb> still I'm pretty sure that I could not find anything A64 based on ebay and aliexpress just a few days ago
<libv> that could've changed just recently :)
huawei is now known as Jujoji-Orihime
<tkaiser> Maybe Android wasn't ready before?
<ssvb> yep, one of the aliexpress iRULU pages says "4 orders" and another says "2 orders" :-)
<tkaiser> ssvb: There's also the Sosoon X89: http://www.dealsmachine.com/best_293731.html
<libv> it still shows a pretty fundamental shift
<libv> the pine a64 was the first
<libv> the "launch partner"
<libv> development board first
<libv> that's a significant change for us
<libv> allwinner has to sit up and listen, despite what they seemed to have unlearned again this last year
<apritzel> libv: but the Remix Mini PC was already out before, I think they shipped August last year
<libv> first reviews seem to be from november
<libv> so yeah, it was first
<libv> but not august
domidumont has joined #linux-sunxi
<libv> october 30th is when they claim that minis were ready for shipment
Gerwin_J has quit [Quit: Gerwin_J]
<apritzel> August was the end of the Kickstarter campaign, (mass) shipping was indeed later
raknaz has quit [Quit: raknaz]
<apritzel> but applying this to the Pine64: End of January end of Kickstarter, mass shipping March till May
<tkaiser> At the end of this clip an Allwinner guy shows a H64 development board from 20150116 where A64 is written on the PCB: https://www.youtube.com/watch?v=mtTOK-tc0M8
<libv> apritzel: right
<tkaiser> ssvb: Orange Pi One survived 672MHz lima-memtester
<ssvb> tkaiser: what kind of fex file did you use in this test?
<tkaiser> Yours
<tkaiser> For the Orange Pi PC
<ssvb> hmm, and what about the voltage regulator arisc issues?
<tkaiser> Occured permanently
<ssvb> heh
domidumont has quit [Read error: Connection reset by peer]
raknaz has joined #linux-sunxi
<mark5> does anyone know if linux 4.4 still supports ext3?
<libv> mark5: is the ext4 driver not supposed to be able to talk to ext3 fses?
<maz> mark5: ext3 is still supported, just taken care of by the ext4 code.
Jujoji-Orihime is now known as Jujochi-Orihime
<wens> huh, a related video shows allwinner's "nobel 64" H64 dev board
<mark5> libv: yeah.. the question doesn't make much sense. I'm just trying to think of what obscure problem could cause my kernel start to hang
Jujochi-Orihime is now known as Shirasaka-Hazumi
raknaz has quit [Quit: raknaz]
ganbold has joined #linux-sunxi
<tkaiser> And I'm still wondering what the differences between A64, H64 and R18 are ;)
<mripard> tkaiser: if we take the R8 / A13 as an example
<mripard> none
<mripard> there was initially a different package
<ssvb> R8M?
<mripard> but then, they shipped R8s with the exact same package than the A13
<mripard> ssvb: R8M was a complete module, with a R8, NAND and RAM
<wens> feels more like marketing
<mripard> my guess is that they initially created it with a different package for the R8M
<mripard> and then re-purposed old A13
<apritzel> tkaiser: The H64 seems to be just a special bin of the A64: Too much heat dissipation for being used in a fanless tablet
<apritzel> but good enough for some passively cooled set-top box, for instance
domidumont has joined #linux-sunxi
<tkaiser> I still believe it's more about marketing. A --> mobile, H --> OTT box, R --> IoT but basically everything the same and just artificial differentiation
<tkaiser> I tried to boot a H8 OS image for pcDuino on Banana Pi and Allwinner's boot0/SPL complained about wrong chip ID.
<tkaiser> I used the stuff for the Banana Pi M3 (A83T): sudo dd if=boot0_sdcard.fex of=${card} bs=1k seek=8
<tkaiser> And then everything was ok except DRAM voltage
afaerber has quit [Quit: Ex-Chat]
<ssvb> how did it complain?
<tkaiser> "ic check fail,IC must=H8,but id=0x00000001": http://forum.linksprite.com/index.php?/topic/4516-lm-sensors-no-worky/?p=12084
<ssvb> can you add A83T and H8 chip ID information to http://linux-sunxi.org/SRAM_Controller_Register_Guide#SRAM_VER_REG ?
<libv> tkaiser: that cnx-soft link i remember: it looks very much like a cubieboard and then some photoshop
<tkaiser> I have no H8 device and the Banana Pi M3 is borrowed to a friend at the moment.
<libv> err, cubietruck
<tkaiser> libv: Nope, cubietruck is pretty different. You must be made to try this in Photoshop (I earned my money doing Photoshop a decade ago ;)
<tkaiser> s/made/mad
jelly is now known as INVISIBLKLINGON
INVISIBLKLINGON is now known as jelly
afaerber has joined #linux-sunxi
apritzel1 has joined #linux-sunxi
arete74 has quit [Quit: leaving]
arete74 has joined #linux-sunxi
arete74 has quit [Client Quit]
sid14726 has joined #linux-sunxi
arete74 has joined #linux-sunxi
arete74 has quit [Client Quit]
domidumont has quit [Quit: Leaving.]
domidumont has joined #linux-sunxi
arete74 has joined #linux-sunxi
reinforce has joined #linux-sunxi
cosm has quit [Ping timeout: 272 seconds]
Nyuutwo has quit [Ping timeout: 276 seconds]
diego_r has joined #linux-sunxi
caog has joined #linux-sunxi
caog has quit [Changing host]
caog has joined #linux-sunxi
Shirasaka-Hazumi has quit [Ping timeout: 245 seconds]
Nyuutwo has joined #linux-sunxi
huawei has joined #linux-sunxi
apritzel1 has quit [Ping timeout: 248 seconds]
Netlynx has joined #linux-sunxi
Netlynx has joined #linux-sunxi
huawei is now known as Shirasaka-Hazumi
<apritzel> ssvb: do you have any plans on pushing your A64 U-Boot patches upstream?
domidumont has quit [Read error: Connection reset by peer]
sid14726 has quit [Max SendQ exceeded]
yann|work has quit [Ping timeout: 250 seconds]
IgorPec has quit [Ping timeout: 250 seconds]
diego_r has quit [Ping timeout: 245 seconds]
dev1990 has joined #linux-sunxi
IgorPec has joined #linux-sunxi
dev1990 has quit [Quit: Konversation terminated!]
caog has quit [Quit: Ex-Chat]
<ssvb> apritzel: yes, I'll send RFC patches to the U-Boot mailing list later today or tomorrow
sid14726 has joined #linux-sunxi
dev1990 has joined #linux-sunxi
<apritzel> great! I have a patch for the CNTFRQ issue
apritzel has quit [Ping timeout: 248 seconds]
khuey|away is now known as khuey
premoboss has joined #linux-sunxi
vagrantc has joined #linux-sunxi
tkaiser has quit [Quit: jIRCii - http://www.oldschoolirc.com]
premoboss has quit [Ping timeout: 240 seconds]
premoboss has joined #linux-sunxi
_massi has quit [Remote host closed the connection]
cptG_ has quit [Remote host closed the connection]
reinforce has quit [Quit: Leaving.]
mzki has quit [Quit: leaving]
sid14726 has quit [Max SendQ exceeded]
afaerber has quit [Quit: Ex-Chat]
viccuad has quit [Ping timeout: 248 seconds]
tkaiser has joined #linux-sunxi
<tkaiser> ssvb: The Orange Pi One even survives 744MHz lima-memtester. Should I trust in this result given that voltage regulation doesn't work (es intended)?
<ssvb> tkaiser: if you can see the animated spinning cube on a monitor, then probably yes
<ssvb> in any case, successfully passing the lima-memtester test does not guarantee perfect reliability
domidumont has joined #linux-sunxi
<ssvb> only failing it means that the hardware is unreliable with the selected dram setup
<tkaiser> ssvb: Yes, I would consider passing 744MHz some safety headroom for using 672MHz. Will connect the display later. Until now I just tested headless.
<tkaiser> Is the memtester comparable with memtest for x86?
<tkaiser> Same patterns/strategies?
<ssvb> yes, to some extent
<ssvb> it just writes the same patterns to two buffers in memory and then compares these buffers
<ssvb> surprisingly, the selected patterns are quite good at detecting problems
tomboy64 has joined #linux-sunxi
<tkaiser> Ok, we made the experience with x86 servers that they pass 72 hours 'burn in' memtest without issues just to throw single bit ECC errors when in productive use later every few weeks/months
pmattern has joined #linux-sunxi
<ssvb> do you mean memtest86?
<tkaiser> I think we used this. I gave up on the hardware side of server business in the meantime
tomboy65 has quit [Ping timeout: 276 seconds]
<ssvb> yes, memtest86 failed me at least twice
<tkaiser> A device passed the RAM test but failed in normal use?
<ssvb> first I had an amd64 desktop computer at my workplace many years ago (one of the first x86-64 boxes) which was successfully passing the memtest86 test, but consistently segfaulting when GCC was rebuilding itself
tomboy65 has joined #linux-sunxi
<ssvb> resolved this by adjusting voltages in BIOS setup
interrobangd has joined #linux-sunxi
tomboy64 has quit [Ping timeout: 256 seconds]
afaerber has joined #linux-sunxi
<ssvb> actually this was a major PITA, because it was difficult to say whether it was an immature amd64 port of GCC causing troubles or the hardware
<tkaiser> Understandable. And that's what a tool like memtest86 is made for -- nailing the problem down
<ssvb> and another case was my current Intel Core i7 860 computer at home - https://bugs.freedesktop.org/show_bug.cgi?id=32911 :-)
<ssvb> and again, memtest86 proved to be useless
<ssvb> resolved this problem by just buying different DIMM modules
<tkaiser> Good to know. Unreliable DRAM is always PITA. And a tool not able to detect that sucks
bmeneg has quit [Quit: \o]
<montjoie> hello anyone got i2c working on A83T ? I have enabled it but got "i2c-0: mv64xxx: I2C bus locked, block: 1, time_left: 0"
<ssvb> tkaiser: ironically, the recipe for easily reproducing the problem was exactly the same as on sunxi hardware: 3D graphics workload + userspace memtester program to the rescue :-)
<tkaiser> ssvb: Yes, seems you've to push the hardware to the limits to find weaknesses
tomboy64 has joined #linux-sunxi
tomboy65 has quit [Ping timeout: 240 seconds]
<tkaiser> And this userspace memtester used different patterns than memtest86?
sid14726 has joined #linux-sunxi
<mripard> montjoie: have you checked your muxing ?
<montjoie> mripard: I have just found a thread where you say to use PULL_UP instead of NO_PULL
<montjoie> but i2cdetect still detect nothing
<montjoie> and I still have the bus locked
<montjoie> this is my DT patch for i2c https://bpaste.net/show/0ce616b1e0e1
interrobangd has quit [Quit: Leaving]
<mripard> yeah, you need pull ups if you don't have any external one
<mripard> you're sure you're using the PH2 and PH3 pins ?
<mripard> it looks odd that you're using the A10 compatible
<mripard> but that should give you an interrupt flood, not a bus locked
<mripard> is the AC200 powered ? with its regulators enabled (if it has any) ?
<mripard> I've seen some devices pull down the lines when they were not enabled
JohnDoe_71Rus has quit [Quit: KVIrc 4.2.0 Equilibrium http://www.kvirc.net/]
interrobangd has joined #linux-sunxi
apritzel has joined #linux-sunxi
<montjoie> mripard: I have enabled ac200 power in uboot
<montjoie> and PH2/3 are enabled "sun8i-a83t-pinctrl 1c20800.pinctrl: request pin 226 (PH2) for 1c2b000.i2c"
<montjoie> same log for PH0/1/2/3
<montjoie> exactly ac200 DLDO4 set to 3.3
pmattern has quit [Quit: Genug für heute.]
<mripard> hmm, then I don't know
<mripard> I guess you don't have a logical analyzer ?
tkaiser has quit [Read error: Connection reset by peer]
ninolein has quit [Remote host closed the connection]
tkaiser has joined #linux-sunxi
sid14726 has quit [Max SendQ exceeded]
ninolein has joined #linux-sunxi
domidumont has quit [Ping timeout: 246 seconds]
clonak has quit [Ping timeout: 272 seconds]
clonak has joined #linux-sunxi
cosm has joined #linux-sunxi
<tkaiser> ssvb: The Orange Pi One showed the spinning cube while DRAM was clocked with 744 MHz and lima-memtester still running.
<KotCzarny> push it further?
<tkaiser> Nope, then it fails after 30 sec.
<KotCzarny> hum, add heatsinks?
<tkaiser> If it's running stable at 744 MHz then I would use 672 for productive use instead.
<tkaiser> On the Orange Pi One I can't use the usual heatsinks I have for A20 (20x20mm).
<tkaiser> So I'll have to wait until smaller ones arrive and I don't intend to use them for productive use.
<KotCzarny> sure, its only curiosity
<tkaiser> Now I exchanged 'pmuic_type = 2' (I2C) with 'pmuic_type = 0' in script.bin and the ARISC error messages are gone and SoC temperature is lower
simosx has joined #linux-sunxi
<tkaiser> Merde, I have to wait for the heatsink to continue testing. When starting cpuburn-a7 SoC temperature exceeds 90¡C way too fast
<KotCzarny> :>
<KotCzarny> 1.2ghz ?
interrobangd has quit [Read error: Connection reset by peer]
<cosm> tkaiser: a 20x20mm heatsink should fit on the board
<tkaiser> 1008 MHz I would suspect since I use mainline u-boot.
<tkaiser> cosm: I don't think so. The SoC is 14x14mm and there is stuff on the PCB that exceeds the SoC's height nearby: http://linux-sunxi.org/File:Orange_Pi_One_1.jpg
Netlynx has quit [Quit: Leaving]
<tkaiser> On the Orange Pi PC it's no problem to use larger heatsinks (few people chose 35x35mm to also cover the DRAM chips) but not on the 'One'
<KotCzarny> add metal 'riser' ?
<ssvb> tkaiser: most likely it just defaults to the maximum voltage
<ssvb> was it 1.3V?
<ssvb> still 90C is a bit too much
ricardocrudo has quit [Remote host closed the connection]
<tkaiser> ssvb: I managed to get the CPU cores shut down also: http://kaiser-edv.de/tmp/cR5oMo/Bildschirmfoto%202016-02-10%20um%2022.29.14.png
<tkaiser> On 22:21 I switched back to Orange Pi PC FEX (pmuic_type = 2) and rebooted.
interrobangd has joined #linux-sunxi
<cosm> tkaiser: sorry, my fault, I didn't notice you were talking about opi one
<tkaiser> Based on the thermal values it seems that with pmuic_type = 0 (none) the core voltage is lower
<tkaiser> The voltage regulator on the 'One' can switch between 1.1V and 1.3V
<tkaiser> According to Orange Pi forums
tyler-baker has quit [Read error: Connection reset by peer]
hp197 has joined #linux-sunxi
egbert has quit [Disconnected by services]
egbert has joined #linux-sunxi
leio_ has joined #linux-sunxi
kelvan_ has joined #linux-sunxi
<tkaiser> LOL, I did it again and fooled myself :) Changing pmuic_type might stop ARISC error messages but does not change anything regarding SoC temperatures.
<KotCzarny> you need to fully power off between tests then
<tkaiser> The decrease in temperature before was due to the kernel shutting down 3 CPU cores.
avph has quit [*.net *.split]
leio has quit [*.net *.split]
kelvan has quit [*.net *.split]
vpeter has quit [*.net *.split]
_hp197 has quit [*.net *.split]
mcan has quit [*.net *.split]
<tkaiser> KotCzarny: I did that too to be sure.
avph has joined #linux-sunxi
<KotCzarny> uhum
mcan has joined #linux-sunxi
tyler-baker has joined #linux-sunxi
valkyr1e has quit [Ping timeout: 240 seconds]
ssvb has joined #linux-sunxi
viccuad has joined #linux-sunxi
valkyr1e has joined #linux-sunxi
paulk-collins has quit [Quit: Quitte]
<tkaiser> Ok, last conclusion for today: When using kernel 3.4.x with H3 on the Orange Pi One then the difference between pmuic_type = 0 and 1/2 is that in the former case cpufreq scaling works while it fails with 1/2: http://kaiser-edv.de/tmp/c2krvL/Bildschirmfoto%202016-02-10%20um%2023.02.30.png
<tkaiser> 1st sysbench run with type 0 and when exceeding 85¡C SoC temperature cpufreq scaling jumped in and decreased clockspeed from 1008 to 480 MHz (sysbench time: 185,5 sec)
IgorPec2 has joined #linux-sunxi
<tkaiser> Second run cpufreq scaling failed and clockspeed remained at 1008 MHz (sysbench time 2 seconds better). SoC temperature close to 89¡C -- in case the benchmark would've run longer and 90¡C would've been reached Allwinner's kernel would've started to shut CPU cores down
ricardocrudo has joined #linux-sunxi
<tkaiser> dvfs isn't working at all but setting pmuic_type = 0 seems to be smart to get cpufreq scaling back
IgorPec has quit [Ping timeout: 250 seconds]
<tkaiser> Therefore setting pmuic_type = 0 seems to be a workaround unless the problem with the different voltage regulator has been resolved by software
IgorPec2 has quit [Ping timeout: 260 seconds]
yann|work has joined #linux-sunxi
interrobangd_ has joined #linux-sunxi
rubensm_ has joined #linux-sunxi
vagrantc_ has joined #linux-sunxi
avph has quit [Ping timeout: 240 seconds]
ricardocrudo has quit [Ping timeout: 240 seconds]
jero has quit [Ping timeout: 240 seconds]
rubensm has quit [Ping timeout: 240 seconds]
interrobangd has quit [Ping timeout: 240 seconds]
vagrantc has quit [Ping timeout: 240 seconds]
avph has joined #linux-sunxi
Guest92736 has joined #linux-sunxi
vagrantc_ is now known as vagrantc
viccuad has quit [Quit: WeeChat 1.4]
cosm has quit [Quit: Leaving]
kelvan_ is now known as kelvan
kelvan has quit [Quit: http://quassel-irc.org - Chat comfortably. Anywhere.]
kelvan has joined #linux-sunxi
tkaiser has quit [Quit: jIRCii - http://www.oldschoolirc.com]
sid14726 has joined #linux-sunxi
simosx has quit [Quit: Leaving]
leio_ has quit [Ping timeout: 240 seconds]
dev1990 has quit [Quit: Konversation terminated!]