<camh>
plaes: thanks. is u-boot FEL mode supported with the allwinner uboot? I'm trying to bring up an orange pi plus / H3 / sun8iw7p1
<camh>
it does not appear to have the _FEL config targets
<plaes>
oh.. H3
<plaes>
no idea about that
_massi has joined #linux-sunxi
simosx has joined #linux-sunxi
domidumont has joined #linux-sunxi
philectro has joined #linux-sunxi
<wens>
a) H3 support is WIP b) IIRC there are no more _FEL config targets
domidumont has quit [Remote host closed the connection]
domidumont has joined #linux-sunxi
ricardocrudo has joined #linux-sunxi
domidumont has quit [Read error: Connection reset by peer]
domidumont has joined #linux-sunxi
<camh>
wens: jemk pointed me at his H3 tree recently and I'm doing what I can to progress the mainlining. Is there another WIP tree?
<camh>
but first I'm just trying to get the allwinner sources building and running so I have a known baseline
<wens>
camh: i think only jemk's
<camh>
but failing at that. lots of card swapping, hence the earlier question
<camh>
ok. jemk's tree will be my starting point after I have the allwinner uboot working.
viccuad has joined #linux-sunxi
nahom has joined #linux-sunxi
<nahom>
NiteHawk: Are you there?
<NiteHawk>
nahom: o/
<nahom>
:(
<nahom>
No luck...
<NiteHawk>
with?
<nahom>
The mainline kernel won't compile
<NiteHawk>
well, it's okay if you stay with 3.4 - however as ssvb indicated it's strongly recommended you don't use the outdated "sunxi-3.4" branch, but switch to "sunxi-next" instead. we have a strong suspicion that it's related to your kernel hang
<nahom>
It's telling me "You rcompiler is too buggy; it is known to miscompile kernels..."
<nahom>
Same error with sunxi-next version
<nahom>
Here's the error:
<nahom>
pastebin.com/e4GQgPeR
<NiteHawk>
that's a known problem with gcc 4.8.0 to 4.8.2, i think
<NiteHawk>
huh? are you cross-compiling, if so, check "armv7a-hardfloat-linux-gnueabi-gcc --version" or whatever relates to your specific toolchain
<nahom>
Yes I'm cross compiling. I'm on Ubuntu 14.04.
<nahom>
And can't find this on my system
<nahom>
armv7a-hardfloat-linux-gnueabi-gcc
<NiteHawk>
arm-linux-gnueabihf-gcc --version
<nahom>
4.8.2
<NiteHawk>
see?
<NiteHawk>
you need a newer toolchain
<nahom>
How do I get one?
<RzR>
hi
reinforce has joined #linux-sunxi
<NiteHawk>
nahom: you have three options: 1. upgrade to a newer ubuntu, 2. tweak your apt config/sources to get a newer package, and 3. use a separate 'standalone' toolchain - see e.g. http://www.lemaker.org/thread-15424-1-1.html
<nahom>
Option 2 sounds easier... let me try
<RzR>
Is there an apt repo all sunxi kernels ?
<wens>
nope
enrico_ has joined #linux-sunxi
ricardocrudo has quit [Remote host closed the connection]
ricardocrudo has joined #linux-sunxi
<ssvb>
camh: about FEL mode support on H3, can you try to load boot0 using the "fel -v spl <name_of_the_sd_or_nand_variant_of_the_boot0_blob>" command?
<ssvb>
camh: I'm assuming that you have serial console, is this right?
<camh>
ssvb: I'll see if I can experiment tonight. I'm shaving toolchain yaks at the moment
<camh>
yes I have a serial console.
<camh>
my two previous attempts to enter FEL mode failed. But I did learn it falls back to eMMC which has android pre-loaded :)
<ssvb>
oh, you surely need to enter FEL mode first before trying to boot it over FEL
<wens>
ssvb: i tried the shell script, results were posted in a comment to your gist
vishnup has joined #linux-sunxi
Net147 has quit [Ping timeout: 256 seconds]
Renard has joined #linux-sunxi
<camh>
ssvb: Warning: no 'soc_sram_info' data for your SoC (id=1680)
<camh>
ssvb: MMU is not enabled by BROM
<camh>
^^ output from fel -v spl boot0_sdcard.fex
<NiteHawk>
nahom: that sounds rather weird. can you pastebin the output of "xzcat gcc-linaro-4.9-2014.07*.tar.xz | tar tv" ?
<NiteHawk>
(should give a listing of the archive content)
<nahom>
sorry... I think I download the source and need to compile and build
<nahom>
I'm now downloading the compiled version
Net147 has joined #linux-sunxi
<nahom>
There is one more issue though... in the sunxi-next version of the kernel, there is no sun7i_defconfig file
<nahom>
NiteHawk: There is one more issue though... in the sunxi-next version of the kernel, there is no sun7i_defconfig file
<nahom>
it should have been in the /arch/arm/configs directory
vishnup has quit [Quit: Page closed]
<NiteHawk>
it think it's "sunxi_defconfig" for that one...
<NiteHawk>
but with a suitable toolchain you might also give mainline kernel another try
<ssvb>
wens: thanks a lot, I also added a comment there
<ssvb>
wens: but it looks like FEL stacks layout on A80 is similar to other SoCs, except that the base address is different
<plaes>
nahom: mainline isn't supposed to have it
<nahom>
plaes: not mainline, I'm using sunxi-next
<ssvb>
camh: thanks
<ssvb>
camh: the MMU problem on H3 is likely the same as on A33 and should be fixable in the same way
viccuad has joined #linux-sunxi
<plaes>
nahom: head -n 4 Makefile
<ssvb>
camh: the "Warning: no 'soc_sram_info' data for your SoC (id=1680)" is not dangerous and just limiting the usable SPL size to something like ~22K (instead of full 32K)
<nahom>
NiteHawk: I did this -> export PATH="$PATH":/home/user/folder/gcc-linaro-arm-linux-gnueabihf-*_linux/bin/
<nahom>
and then tried again to compile the kernel... same error as before!!!
<nahom>
This is how I tried to compile -> make -j$(nproc) ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- uImage modules
<wens>
nahom: you should put the custom binaries _before_ $PATH
<wens>
otherwise you still get the old stuff
<wens>
nahom: and sunxi-next _is_ mainline
<nahom>
wens: like this -> export PATH=/home/user/folder/gcc-linaro-arm-linux-gnueabihf-*_linux/bin/:"$PATH"?
<wens>
nahom: yes
<nahom>
wens: Yes!!! that did it, it's now compiling. Thanks!!
<ssvb>
wens: I can try to add support for the base address other than 0 to the fel utility in sunxi-tools, it would be great if we could test this on A80
<ssvb>
wens: basically, the idea is that we want to use full 32K of SRAM starting at 0x10000 in FEL mode too instead of something around 15K starting at 0x12000
viccuad has quit [Quit: WeeChat 1.1.1]
<ssvb>
camh: vishnup was going to fix the MMU issue, I don't know if he had time to do this
<ssvb>
camh: but this is not expected to be difficult problem
<camh>
ok. i'm in no hurry anyway - I'm not sure I can use it yet since I don't have a uboot with spl for the h3
<camh>
I cna't even get my build of the allwinner uboot working yet
<ssvb>
camh: what kind of u-boot are you building, was it something provided by jemk?
<camh>
not yet. just the one from the lichee sdk
<camh>
I can boot the images provided by orangepi. next I want to build them myself as a baseline
<camh>
then see if I can port the H3 stuff to mainline
<ssvb>
ok, I see
<ssvb>
I can only help with the FEL boot part, and u-boot would still need to have a proper SPL (bootable from SD card) which would be bootable via FEL too
<wigyori>
morning
<NiteHawk>
nahom: recheck "arm-linux-gnueabihf-gcc --version". "which arm-linux-gnueabihf-gcc" might help you to figure out what binary it's actually using, as others pointed out it's probably a question of $PATH / precedence
<NiteHawk>
oh, nevermind - just saw you got it working.
<nahom>
NiteHawk: yeah, I'm now copying the zImage and dtb to the card... we'll know in a minute if it works
philectro has quit [Quit: Konversation terminated!]
<nahom>
NiteHawk: :D
<NiteHawk>
\o/
<nahom>
I'm now looking at a GUI of the distro
<nahom>
Can't believe this!
<NiteHawk>
which kernel did you use now? mainline?
<nahom>
Took forever, and I wouldn't have done it without you guys!
<nahom>
No, I used the sunxi-next
<NiteHawk>
ok, that's fine - just checking that the "bootm_boot_mode" of your u-boot is suitable - which it is in this case
<nahom>
NiteHawk: My ultimate goal is to get linux on the NAND, can you just point me in the right and easiest direction ? :)
<NiteHawk>
sorry - i have no experience with that as my device comes without internal NAND, i'm just using sdcard
<nahom>
:(
paulk-cccamp has joined #linux-sunxi
<nahom>
NiteHawk: I also have another problem, both the keyboad and mouse aren't working!
pietrushnic`away has joined #linux-sunxi
<NiteHawk>
you did replace the script.bin of that distro with one for your Mele M3 (compiled from .fex), or?
pietrushnic`away is now known as pietrushnic
pietrushnic is now known as pietrushnic`away
<ssvb>
NiteHawk: btw, what do you think about deleting usb-boot script from sunxi-tools?
pietrushnic`away has quit [Client Quit]
pietrushnic`away has joined #linux-sunxi
pietrushnic`away is now known as pietrushnic
<NiteHawk>
ssvb: you said (in your mail reply) that it might still be useful / should be kept for FEL support of legacy sunxi-u-boot?
<NiteHawk>
for mainline, "fel uboot" has pretty much made it obsolete - yeah :D
<nahom>
NiteHawk: yes, I deleted scripts.bin
<ssvb>
NiteHawk: this script is still available in the sunxi-tools repository (in old tags)
<NiteHawk>
nahom: i hope you mean "replaced" it?
<nahom>
Now the files on the first partition of the SD are zImage, boot.scr and the sun7i-a20-m3.dtb
<NiteHawk>
ssvb: i think it's a question of consistency - if the wiki still had instructions (even if somewhat outdated) referring it, i'd vote for keeping it around. if that's no longer the case (i haven't checked your edit in great depth), i'm all for removing the script
<NiteHawk>
nahom: i'm not sure about that - does sunxi-next use device tree (.dtb config) now? i'm pretty sure the older 3.4.x kernels didn't
<nahom>
well, that's how it booted
<NiteHawk>
admittedly i'm a bit out of touch with linux-sunxi kernel
<ssvb>
NiteHawk: yeah, I have edited the fel boot wiki page quite a lot and even made the legacy stuff collapsed by default (so that the users have less chance to accidentally reading it when they don't intend to)
vishnup has joined #linux-sunxi
<ssvb>
NiteHawk: I can update the u-boot-sunxi part of the wiki to mention the usage of an old tag for the usb-boot script, then we can remove this script from the master branch
<ssvb>
hi vishnup
paulk-cccamp has quit [Ping timeout: 264 seconds]
<NiteHawk>
ssvb: remove the script, and have the wiki link to an appropriate branch or tagged revision?
<ssvb>
NiteHawk: yes
<vishnup>
ssvb: hi
<nahom>
NiteHawk: Any suggestions on how to the kb and mouse working?
<ssvb>
vishnup: it looks like the sunxi-tools fel MMU fix is also needed for Allwinner H3 :)
<ssvb>
vishnup: at least camh has reported this problem today
<NiteHawk>
nahom: i'd start investigating the kernel messages at boot for anything suspicious about USB initialization/detection. though that means you're probably back in the "serial console" boat... maybe you have more luck there with the kernel console than with your (unsuccessful) attempt with u-boot?
<vishnup>
ssvb: I'll try tonight,
<camh>
vishnup: I'll be around for another hour or so (9:15pm here), otherwise I can test tomorrow
<nahom>
NiteHawk: If this has anything to do with scripts.bin, I can try to find it in the sunxi-next folder and put it on the card. Could that be it?
<NiteHawk>
can you show your u-boot script (boot.cmd) again?
<NiteHawk>
nahom: well... your devices are obviously detected ("USB HID v1.11 Mouse [ USB OPTICAL MOUSE]" and "USB HID v1.10 Keyboard [CHICONY HP Basic USB Keyboard]")
<vishnup>
also at line 528, 533,
<NiteHawk>
i'm a bit puzzled why they wouldn't work - looks like there's nothing unusual related to USB
ssvb has quit [Ping timeout: 252 seconds]
<nahom>
NiteHawk: so, what do I do then?
<camh>
vishnup: Unexpected TTBR0 (88680F1B)
<NiteHawk>
nahom: i'm lacking a good idea to be honest - maybe try to plug the keyboard in _after_ the boot / startup has completed. if i got you right, you're stuck at the distro installation menu?
<vishnup>
camh: comment out the line 528, 533. I don't have board right now.
<camh>
vishnup: Reading the MMU translation table from 0x88680F1B
<camh>
and it seems to hang there
<camh>
just timed out with : libusb usb_bulk_send error -7
<nahom>
I'm looking at the desktop with three icons "Firefox browser, Media Player and X11VNC Server"
<nahom>
Damn, I was so close!
<NiteHawk>
ah - so that might be an X configuration issue (not being set up for the 'correct' input devices)?
<nahom>
What can I do?
<vishnup>
camh: so it did not hang there
<camh>
in the end, no.
<camh>
it looks like trying to read any number of bytes from that address times out
<vishnup>
I think, SPL size limit causing this problem
<camh>
$ fel read 0x88680F1B 4 /tmp/foo
<camh>
libusb usb_bulk_send error -7
<nahom>
I'm using the linaro rootfs, should I just try another distro?
<nahom>
What are you using?
<NiteHawk>
nahom: find a way to start that X11VNC and use it to connect over network? :D but this is probably something that's related more closely to that specific distro than to linux-sunxi in general...
<NiteHawk>
nahom: so you might have more luck taking it to their respective support channels? (if something like that exists)
<nahom>
Ok, I'll try that
<nahom>
NiteHawk: What do you use on your board?
<vishnup>
camh: what command are you trying ?
<camh>
originally "fel -v spl boot0_sdcard.fex"
<camh>
then I tried to just read 4 bytes from the ttbr0 address
<camh>
verified that fel read works with "fel read 0x12000 4 /tmp/foo" which works
<vishnup>
:)
<NiteHawk>
nahom: i'm running gentoo on my Banana Pi. but it's a rather minimalistic installation in "headless" mode (no GUI), mainly for testing and some development work
<nahom>
NiteHawk: Ok, thanks a lot!
FR^2 has joined #linux-sunxi
<vishnup>
what is size of boot0 binary?
<camh>
32768
<vishnup>
camh: that's the problem I' also facing anything >15KB I'm getting error -7
<camh>
i suspect that i'm not even getting that far. it does not appear to complete aw_backup_and_disable_mmu()
<camh>
it looks like this is timing out: aw_fel_read(usb, ttbr0, tt, 16 * 1024);
<camh>
(line 537)
domidumont has quit [Quit: Leaving.]
<vishnup>
I'll check with my tablet tonight
domidumont has joined #linux-sunxi
<vishnup>
camh: BTW, I've A33 not H3
<camh>
i'm running an orange pi plus
<camh>
happy to test anything you want. sydney timezone.
domidumont has quit [Quit: Leaving.]
domidumont has joined #linux-sunxi
avph has quit [Ping timeout: 246 seconds]
avph has joined #linux-sunxi
orbifx has joined #linux-sunxi
<orbifx>
Hello
<orbifx>
Is anyone here involved with booting from NAND and the ongoing development?
philectro has joined #linux-sunxi
avph has quit [Ping timeout: 260 seconds]
avph has joined #linux-sunxi
avph has quit [Ping timeout: 255 seconds]
avph has joined #linux-sunxi
kaspter has quit [Ping timeout: 265 seconds]
mmarker has quit [Quit: ZNC - 1.6.0 - http://znc.in]
mmarker has joined #linux-sunxi
mmarker has joined #linux-sunxi
nahom has quit [Ping timeout: 246 seconds]
sehraf has joined #linux-sunxi
ssvb has joined #linux-sunxi
avph has quit [Ping timeout: 272 seconds]
<ssvb>
wens: did you get a Primo81 tablet?
<ssvb>
wens: was its LCD faulty from the very beginning, or an accident happened when trying to take it apart?
Renard has quit [Ping timeout: 256 seconds]
avph has joined #linux-sunxi
<wens>
ssvb: yes, i got one very cheap, about 1/5 the sticker price iirc
<wens>
the seller mentioned the lcd was faulty, hence the low price
<wens>
and the casing looks like someone dropped it on the ground, or might have tried to take it apart
<wens>
it was already loose in one corner
<wens>
ssvb: fyi, there are 5 notches equally spaced along the long sides, that's all that's holding the back on
Renard has joined #linux-sunxi
<ssvb>
wens: apparently the previous owner mistreated this poor thing, but at least now we can get pictures and additional information
kz1 has quit [Read error: Connection reset by peer]
<wens>
uploaded a picture of the board
kz1 has joined #linux-sunxi
<wens>
there's nothing on the back but a large copper sticker
<ssvb>
thanks
<ssvb>
it's a very nice tablet and I like it quite a lot, too bad that many people missed an opportunity when these tablets could be bought at a rather cheap price
<wens>
ssvb: are you going to do another version of the dts file? otherwise i can pick it up
<wens>
yeah, if it works out i'm going to get a new one :)
<ssvb>
I was waiting for the otg support to fully land in the mainline kernel
<wens>
power-supply is still missing, so you still can't detect vbus
<wens>
and i wonder how we could get it working with a powered/charging hub
<ssvb>
yes, I know, have been successfully using usb otg with it for a few months already
<wens>
anyway, my main interest was the 4:3 ips lcd, and hdmi
<wens>
that and a working ctp driver
<ssvb>
the charging hub works fine if usb otg is configured as unpowered host
<ssvb>
don't know what's going on with the battery charging in this case, but the tablet is powered by the hub and can work for days
<ssvb>
wens: I think the biggest problem with the dts file was that mripard started picking on the serial console support and ignored the question (twice!) whether we can omit it altogether in the dts
<wens>
ssvb: there's no reason we can't
<wens>
i think the reason we had one is that the kernel complains when you don't have a proper console
<wens>
(or at least i think so)
<wens>
but now we have simplefb!
<ssvb>
well, we have sd breakout board and simplefb, so a lot could have been tested since a log time ago
<ssvb>
but this tablet is not really ready for the inexperienced end users without usb otg support
reinforce has quit [Quit: Leaving.]
<ssvb>
wens: it's interesting that primo81 has ssd2825 (probably as scaled down variant of ssd2828) and low power ddr3
<ssvb>
have we ever seen LPDDR3 in any other sunxi hardware?
<wens>
ssvb: ssd2825 has less bandwidth compared to ssd2828, but i guess it's enough
<wens>
ssvb: not that i know of, but i don't own that much hardware
ricardocrudo has quit [Quit: Leaving]
ricardocrudo has joined #linux-sunxi
<ssvb>
wens: either way, I don't mind if you take care of mainlining the dts file for primo81 :)