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
rah has quit [Ping timeout: 252 seconds]
wookey has quit [Ping timeout: 276 seconds]
vpeter has quit [Ping timeout: 240 seconds]
stoned0651 has joined #linux-sunxi
vpeter has joined #linux-sunxi
wookey has joined #linux-sunxi
rah has joined #linux-sunxi
vinimac has quit [Quit: Leaving]
Andy-D has quit [Ping timeout: 258 seconds]
Andy-D has joined #linux-sunxi
lurchi_ is now known as lurchi__
muvlon has joined #linux-sunxi
wens has joined #linux-sunxi
wzyy2 has joined #linux-sunxi
cnxsoft has joined #linux-sunxi
egbert has quit [Disconnected by services]
egbert has joined #linux-sunxi
jrg has quit [Ping timeout: 256 seconds]
jrg has joined #linux-sunxi
terra854 has joined #linux-sunxi
vishnup has quit [Ping timeout: 240 seconds]
muvlon has quit [Quit: Leaving]
muvlon has joined #linux-sunxi
ninolein has quit [Ping timeout: 256 seconds]
ninolein has joined #linux-sunxi
vagrantc has quit [Quit: leaving]
reev has joined #linux-sunxi
jrg has quit [Read error: Connection reset by peer]
victhor has quit [Ping timeout: 240 seconds]
<wens> hmm, -rc8
<terra854> How close are we to 4.10 stable?
<wens> one more week probably
<wens> -rc7 or -rc8 is the last -rc, depending on Linus' mood :p
<terra854> I see
<terra854> BTW any A64 stuff ready for 4.11?
wzyy2 has quit [Read error: Connection reset by peer]
pg12 has quit [Ping timeout: 276 seconds]
pg12_ has joined #linux-sunxi
<wens> AFAIK, just USB support
<wens> and mmc
<MoeIcenowy> but usb and mmc renders the board usable as headless ;-)
<wens> yeah, normally we do uarts, pinctrl, clocks, mmc, usb, ... in that order
<wens> then whatever comes is up to personal preference or needs
IgorPec has joined #linux-sunxi
<MoeIcenowy> ether is also an important thing ;-)
<MoeIcenowy> wait for montjoie ;-)
Andy-D has quit [Ping timeout: 264 seconds]
wzyy2 has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
stoned0651 has quit [Ping timeout: 260 seconds]
<KotCzarny> anyone knows if it's fixable? or what can be the cause?
<plaes> wrong address?
lurchi__ has quit [Read error: Connection reset by peer]
lurchi__ has joined #linux-sunxi
<KotCzarny> any way to guess the right address or it's black magic without docs?
<MoeIcenowy> i2ctest
<beeble> i2c probe in uboot
cnxsoft1 has joined #linux-sunxi
<beeble> do you have a scope or are you bound to software only testing?
<KotCzarny> but it seems tp65185 detected something at 0x68 according to this log
cnxsoft has quit [Read error: Connection reset by peer]
cnxsoft1 is now known as cnxsoft
<KotCzarny> unless it's from the fex file
<beeble> for me it looks like it only fetches data from the fex
<beeble> and failes at i2c transfer
<KotCzarny> uhum
<KotCzarny> will try uboot detect, it should work regardless of wrong board defs?
<plaes> no, it doesn't actually detect it
<beeble> the probe function only checks all addresses on the bus if it gets an ACK
<plaes> it just announces the info that's read from FEX
<beeble> so you can check the different buses for i2c ids
<beeble> but tps65185 has only one fixed address
<plaes> and with epaper, it's usually the screen that burns out, not pmic ;)
<KotCzarny> plaes, so there is a chance that screen is burnt?
<KotCzarny> o.o
<plaes> no, there's a bigger chance that something is wrong with fex
<KotCzarny> phew, so there is hope
reinforce has joined #linux-sunxi
<plaes> I think the address or i2c bus is wrong
<plaes> but e-paper is hard to handle :(
<plaes> multiple different voltages
<plaes> -15, -30, 15 ... etc
<plaes> which you have to drive in correct sequences
<KotCzarny> o.O
<plaes> that's why there's second pmic
<KotCzarny> i2c bus shows twsi0, i2c probe says: valid chip addresses: 34
<KotCzarny> what now?
<plaes> looks like i2c1 is not enabled
<plaes> you could try i2c-utils in linux
<KotCzarny> first i would need booting linux, which isnt (legacy panics on papyrus and my own build doesnt even start
<plaes> vendor linux one doesn't have serial console?
[7] has quit [Ping timeout: 256 seconds]
<KotCzarny> see 'panics'
TheSeven has joined #linux-sunxi
<KotCzarny> it doesnt get to userland
<plaes> o_O
<KotCzarny> mainline uboot should detect both busses or they have to be enabled in board config?
<plaes> dunno :)
<plaes> there's CONFIG_SPL_I2C_SUPPORT=y
<plaes> I guess create a simple a13 device tree that enables all i2c buses
<KotCzarny> its already enabled
<KotCzarny> (the i2c_support option)
chomwitt has quit [Ping timeout: 252 seconds]
<KotCzarny> hmm, sub5i.dtsi defines same twi[012] as fex file
<KotCzarny> so theoretically it should be enabled
<terra854> So 4.11 can fully run a headless server (no HDMI/LCD) on A64 devices?
<KotCzarny> oh, status = "disabled"
<KotCzarny> but it's also disabled for i2c0 and somehow it comes up
<MoeIcenowy> terra854: you will need to apply sun8i-emac or sun8i-stmmac patch
<terra854> For ethernet?
<KotCzarny> hmm, sun5i-a13.dtsi defines lcd_rgb666_pins pd18/19 which in fex are used for tps65185_wakeup/vcom, could it be that fried the eink controller?
<MoeIcenowy> if it's not enabled, maybe it won't
<MoeIcenowy> terra854: yes
<KotCzarny> i think it was..
<MoeIcenowy> KotCzarny: if you do not enable LCD, the pinctrl node won't be used
<KotCzarny> i've copied jernej's h3 display enabled tree
<terra854> MoeIcenowy: So that is the ethernet driver for the A64 that goes to the mainline?
muvlon has quit [Ping timeout: 245 seconds]
reinforce has quit [Quit: Leaving.]
<MoeIcenowy> terra854: it's still pending
<MoeIcenowy> montjoie is WIP on making it better
<MoeIcenowy> but it's usable now
reinforce has joined #linux-sunxi
<terra854> MoeIcenowy: Do i need to manually run a diff between that tree and the mainline 4.10-rc2 tree?
<terra854> MoeIcenowy: Cause I don't see a patch floating around for it
<MoeIcenowy> maybe after 4.11-rc is out a merged tree will be ready ;-)
<terra854> Including the mmc and usb support wens was talking about?
muvlon has joined #linux-sunxi
IgorPec has quit [Ping timeout: 260 seconds]
<montjoie> even dwmac-sun8i is very usable now
<MoeIcenowy> terra854: mmc and usb is in mainline 4.11
<MoeIcenowy> but dwmac-sun8i is still out-of-tree
<MoeIcenowy> montjoie: can you send out dwmac-sun8i in 4.12 merging window?
<montjoie> I need to finish some todo but I will try
f0xx has joined #linux-sunxi
<KotCzarny> to enable i2c1 its enough to add &i2c1 { status = "okay"; };
<KotCzarny> right?
<beeble> if the dtsi ist written correctly, yes. a13 does not have multiple pinmux options for twi1
<KotCzarny> yes, it's including default a13 config
<KotCzarny> ssvb, nitehawk: to boot uboot via fel i have to run: sunxi-fel uboot u-boot-sunxi-with-spl.bin right?
<KotCzarny> or do i have to provide more files? (that bin file is booting fine from sdcard, and it's mainline one
<KotCzarny> (2016.11-rc2)
<KotCzarny> beeble: if i2c1 isnt showing in i2c bus, it means its fried?
<beeble> are you takling linux or uboot?
<terra854> so ethernet is not ready for 4.11?
<beeble> if uboot then enabling it in the dts is not sufficient. the i2c driver is not yet devicetree enabled. so you have to set the correct I2C config options in .config
<beeble> KotCzarny: and you should look into the ifdef jungle if the pinmus is setup correctly
<beeble> KotCzarny: http://git.denx.de/?p=u-boot.git;a=blob;f=board/sunxi/board.c;hb=HEAD#l417 looks fine as long as you have CONFIG_I2C1_ENABLE
lemonzest has joined #linux-sunxi
IgorPec has joined #linux-sunxi
cnxsoft has quit [Remote host closed the connection]
cnxsoft has joined #linux-sunxi
KotC has joined #linux-sunxi
<KotC> eh.
<KotC> monday, bloody monday
<montjoie> terra854: no ethernet for 4.11
AndroUser has joined #linux-sunxi
AndroUser has quit [Remote host closed the connection]
leviathan has joined #linux-sunxi
<terra854> Rats, thought i can finally use ssh with the mainline kernel...
<MoeIcenowy> terra854: you can use a USB to Ethernet dongle ;-)
<terra854> No thanks. Cause USB2 cuts speed by half
<terra854> I might consider if it have USB3
<MoeIcenowy> but I think after 4.10 or 4.11 is out, a branch with everything available now will be made
<MoeIcenowy> by apritzel or me
Gerwin_J has joined #linux-sunxi
<plaes> um.. what are you using this machine for?
<KotC> science, probably ;)
ErwinH has joined #linux-sunxi
<KotC> high speed hot wet science
<KotC> in HD
ErwinH has quit [Remote host closed the connection]
ErwinH has joined #linux-sunxi
cnxsoft has quit [Quit: cnxsoft]
msevwork has joined #linux-sunxi
<KotC> hmm, after enabling i2c1 i got valid chip addresses 51 and 71
cnxsoft has joined #linux-sunxi
<plaes> cool
<beeble> KotC: doesn't look like 0x68 at all :)
<plaes> now you could try sending out the version info command and see what it returns
<KotC> how do i do that?
<beeble> i2c md <address> 0x10
<beeble> after i2c dev 1
<plaes> i2c md <address>.<bus> <num_bytes]
<plaes> ah no
<plaes> yeah..i2c dev1
<beeble> should return 0x45, 0x55, 0x65 or 0x66
<beeble> but i don't think you see the tps on the bus yet
<MoeIcenowy> some i2c device needs some GPIO to be set to enable
<MoeIcenowy> otherwise you cannot even i2cdetect it
<KotC> tps65185_wakeup ?
<beeble> yes
<plaes> yeah
<beeble> WAKEUP has to be high
codekipper has quit [Quit: Page closed]
<plaes> D18 ?
<KotC> this is from fex
<plaes> yeah..confirms with the code;)
<KotC> gpio set pd18 ?
matthias_bgg has joined #linux-sunxi
<plaes> apparently address is 0x6c
<beeble> KotC: md 0x01C20874 1 change bit 8-10 to 001
<beeble> and then set bit 18 in 0x01C2087c
<plaes> o_O
<beeble> ah, he has a uboot with gpio command :)
<beeble> ok then use that
<KotC> i've set wakeup vcom and powerup to 1
<KotC> still nothing
<beeble> maybe powerup was not such a good idea yet
<beeble> since it's not yet configured
<KotC> it wasnt showing with wakeup alone anyway
<KotC> this is complete fex file
orly_owl_ has joined #linux-sunxi
orly_owl has quit [Disconnected by services]
orly_owl_ is now known as orly_owl
orly_owl has quit [Changing host]
orly_owl has joined #linux-sunxi
<KotC> could this be a reason of i2c probe not working?
<KotC> but i don't seem to do anything like that
komunista has joined #linux-sunxi
Leepty has joined #linux-sunxi
<KotCzarny> can i2c device be reset?
florianH has joined #linux-sunxi
kaspter has joined #linux-sunxi
<beeble> depends on the device
<beeble> KotCzarny: http://www.ti.com/lit/ds/symlink/tps65185.pdf see page 17
<beeble> try do duplicate that wakeup procedure
<KotCzarny> register map refers to i2c address?
<plaes> yes
<plaes> WAKEUP pin high with the PWRUP pin low
<KotCzarny> pin low means gpio clear, right?
<plaes> yeah, should be
<KotCzarny> to do anything with i2c i would need to see it on the bus
<KotCzarny> and setting wakup/pwrup pins doesnt make it available
<beeble> montjoie: tested your stmmac-sun8i-wip-next-20170210 with a micrel phy. plain iperf3 without any additional settings/tuning 936 in both directions
<KotCzarny> maybe i should cut battery connector, hum
fdcx has quit [Remote host closed the connection]
<KotCzarny> or is there a way to make axp209 cut the power to the whole board?
<beeble> pin 25 :)
<beeble> reset will do a power cycle on axps
<KotCzarny> so, simply shorting it to the ground cuts WHOLE power? gotta try it
<montjoie> thanks beeble
<KotCzarny> is it a trigger or i can held it in hopes of draining all voltages?
<beeble> it's triggered on a falling edge and will do a shutdown followed with a power up. and keep doing it if you keep it low. so no benefit in keeping it low as it will cycle through the power up
fdcx has joined #linux-sunxi
<beeble> montjoie: is this roughly the same as with the realtek on your pine/h3?
<montjoie> on my pine64 I got less Tx 500 RX 700 at max
<montjoie> my h3 board (bpim2+) is worst 100/150
<beeble> ah forgot to mentions. a64 here
<beeble> *mention
<wens> KotCzarny: iirc it doesn't cut RTC power
<KotCzarny> wens, i want to try resetting i2c device in hopes its not fried just stuck
leon-anavi has joined #linux-sunxi
<leon-anavi> hi
IgorPec has quit [Quit: Nettalk6 - www.ntalk.de]
<leon-anavi> I need help with A20 OLinuXino MICRO :)
<leon-anavi> What should I do to enable the 7" Olimex touch screen on mainline kernel for A20-OLinuXino-MICRO?
IgorPec has joined #linux-sunxi
<leon-anavi> Following the instructions from linux-sunxi wiki I have already modified the mainline u-boot and I am able to see the video output on the 7" screen but the touch screen does not work out of the box. I guess I should change something in the kernel defconfig, shouldn't I?
popolon has joined #linux-sunxi
dave0x6d has quit [Quit: Connection closed for inactivity]
IgorPec5 has joined #linux-sunxi
fkluknav has joined #linux-sunxi
Laibsch has joined #linux-sunxi
<Laibsch> Hi guys, one of the questions I have is how you would rate GPL-compliance of Rockchip vs Allwinner vs Amlogic? Or are they all equally bad?
vicenteH has joined #linux-sunxi
DullTube has joined #linux-sunxi
flygoat has joined #linux-sunxi
<Net147> leon-anavi: you need to modify the DTS like this - http://pastebin.com/ACn02sQC
leviathan has quit [Remote host closed the connection]
IgorPec5 has quit [Ping timeout: 256 seconds]
<NiteHawk> KotCzarny, KotC: that command is correct. were you able to boot U-Boot that way? see also http://linux-sunxi.org/FEL/USBBoot
<KotCzarny> nitehawk: nope, it ended in usual -7
<NiteHawk> try it with the "-v" (--verbose) option to get a list of steps that sunxi-fel performs. it may fail again at the SPL stage
muvlon has quit [Ping timeout: 245 seconds]
<NiteHawk> but it's remarkable the same .bin boots from sdcard, so you know that it is mostly fine for your SoC
<KotCzarny> but i think device is still available, 1f3a:efe8
<NiteHawk> hmm... you get the L2 cache and stack output, but it seems that the next step aw_backup_and_disable_mmu() might cause trouble
<KotCzarny> if you want me to test anything just shout
fkluknav has quit [Ping timeout: 255 seconds]
muvlon has joined #linux-sunxi
<NiteHawk> I have currently no good idea of what is going on there :/
<KotCzarny> plainly something hangs
<KotCzarny> either fel stack or soc
<KotCzarny> does sunxi-fel do some checksumming if data transferred was ok?
<KotCzarny> or its not possible?
<NiteHawk> not at that particular stage
<NiteHawk> the thing is that you get stack even before it tries to load/execute the SPL, which is rather unusual
<NiteHawk> s/stack/stuck/
Laibsch has quit [Read error: Connection reset by peer]
wzyy2 has quit [Read error: Connection reset by peer]
<BenG83> morning
Mr__Anderson has joined #linux-sunxi
<BenG83> does anyone know if using the SDIO3.0 bus on SDC1 for the A64 allows for 433Mbit wifi modules? Theoretical bandwith should be around 600Mbit if I read the datasheet correctly...
huawei has joined #linux-sunxi
vinimac has joined #linux-sunxi
<ssvb> KotCzarny: just add debug prints everywhere and identify where it gets stuck
<KotCzarny> which file too look in?
<KotCzarny> fel.c or fel_lib.c ?
<ssvb> this was one of the last messages in your console output
<KotCzarny> oh good, at least its a single function
<ssvb> just add a lot more debugging prints around in order to identify the exact place where it fails
<ssvb> you can also try to duplicate the aw_get_stackinfo(dev, soc_info, &sp_irq, &sp) calls
<ssvb> just to check if you can repeatedly get this information and the device does not die
<KotCzarny> yup, it dies in that disable mmu line
<KotCzarny> ie. i've added a debug after it and it didnt get printed
<ssvb> usually if some operation fails with USB timeout, then there was likely something wrong done on the previous step
<ssvb> you can go into the aw_backup_and_disable_mmu function and add lots of debugging prints there too
<KotCzarny> cool, now it didnt even reach the stack pointers
<ssvb> be sure to reset the device between attempts
<KotCzarny> i did
<KotCzarny> always checking with 'ver' if it's ready
<KotCzarny> could it be that sunxi-fel is sending too quick and something gets confused on the soc side?
<ssvb> you can try a different USB port on your PC too
<ssvb> not sure if it will help, but might be worth a try
<KotCzarny> i dont have usb3, its thinkpad t500
<KotCzarny> (and running linux inside virtualbox)
<ssvb> USB3?
<ssvb> FEL is working in the 12 Mbit mode :-)
<leon-anavi> Net147, thanks!
<KotCzarny> when i changed bulk send size to 1k it didnt even get to enabling cache
<KotCzarny> when i changed it to 1M it got to aw_get_ttbcr in disable_mmu
<ssvb> KotCzarny: do you have any other Allwinner devices to test?
<NiteHawk> KotCzarny: you're doing FEL from inside VBox, with the SoC (USB) "passed through" into the emulation?
<KotCzarny> yup
<NiteHawk> X)
<KotCzarny> ;)
<KotCzarny> anyway, see my comment about bulk size
<NiteHawk> what's you main OS, Windows? maybe try http://linux-sunxi.org/FEL/USBBoot#Using_sunxi-fel_on_Windows for a change
<KotCzarny> win7_64
<KotCzarny> i might try using opipc instead to run uboot on that ereader
<ssvb> yes, please try that
foxx has joined #linux-sunxi
<ssvb> if opipc also fails to FEL boot, then it would indicate that there might be something wrong with your virtualbox USB thingie
<NiteHawk> i don't think the USB emulation helps - the FEL protocol may be sensitive to timing issues, and your bulk size experiments to me point a bit in that same direction. better verify it on "real" hardware first
<KotCzarny> i should get bigger desk, getting crowded here
KotC has quit [Quit: brb]
foxx has quit [Ping timeout: 240 seconds]
<BenG83> I had all sorts of problems running FEL or u-boot ums through Virtualbox
<BenG83> didn't work at all with USB3.0 emulation
<BenG83> and USB2.0 was unstable
<KotCzarny> apparently running from opipc worked
<NiteHawk> \o/
<ssvb> do you mean that you successfully FEL booted your bookreader by running sunxi-fel on opipc?
<plaes> yay!
<plaes> yes
enrico__ has joined #linux-sunxi
<ssvb> congrats!
<KotCzarny> thx!
<KotCzarny> but now i have to confirm it actually ran
<KotCzarny> oh, it did
<ssvb> BenG83: is it only FEL having problems or is USB unstable in general in Virtualbox?
<KotCzarny> usb usually works
<BenG83> USB usually is not problem
<NiteHawk> USB emultion is okay for the more common devices (e.g. mass storage) and reasonably robust protocols - which FEL is NOT :D
* ssvb just wonders if something can be improved in sunxi-fel to make it more reliable even in adverse conditions
<BenG83> but I had problems with custom firmware updates for measurement equipment before
<BenG83> I think stuff the uses interrupt transfers with low time slices might be tricky
<NiteHawk> KotCzarny: if you feel like it, have a go with the windows version of sunxi-fel - i've been testing it successfully with Win10 x64
<BenG83> especially if the protocol doesnt do error correction or retransmits
<ssvb> can this virtualbox setup be detected somehow, so that we at least print a warning?
<KotCzarny> yeah, virtualbox adds some dmi data
<KotCzarny> or you can probe for some pci devices
<NiteHawk> i think vbox has a dedicated USB/PIC id for the usb "controller" (root hub)
<ssvb> KotCzarny: was this also happening in virtualbox - https://irclog.whitequark.org/linux-sunxi/2017-02-10#18822076; ?
<KotCzarny> most likely
<ssvb> okay, case closed :-)
<KotCzarny> nah, not closed, just solved a bit
<KotCzarny> ;)
<KotCzarny> does fel protocol allow to create some stability test?
<KotCzarny> ie. for sunxi-fel to test if connection is reliable
<ssvb> fel protocol had been reverse engineered
<plaes> KotCzarny: btw, you can use wireshark to dump usb packets
<ssvb> maybe we don't have a complete understanding of it yet, at least in the parts related to possible errors correction
<KotCzarny> ssvb: i meant, to transfer some bigger block of data and check if it still works (but without storing that data on the other end)
<KotCzarny> though as seen in my case even 500kB is sufficient to trigger the instability
<MoeIcenowy> to be honest, sometimes I think "have a real machine with GNU/Linux" as a prequisite to do any development ;-)
<ssvb> you can try to read 32K of SRAM instead of the "sunxi-fel ver" test
kaspter has quit [Ping timeout: 260 seconds]
<BenG83> I run Fedora natively, but I have a lot of Ubuntu build VMs for images
<BenG83> could probably use something better than Virtualbox
<plaes> systemd-nspawn ;)
<plaes> though, not sure how it handles hw stuff
<BenG83> I read about it after I finally managed to get some time in to learn systemd
<BenG83> not tried it yet
<BenG83> but it looks quite lightweight
<plaes> yeah
<plaes> I have multiple containers in my VM with 512MB ;)
<KotCzarny> hrm, windoze version doesnt seem to find fel device
<KotCzarny> even if device 1f3a:efe8 is installed
IgorPec has quit [Read error: Connection reset by peer]
kaspter has joined #linux-sunxi
IgorPec has joined #linux-sunxi
<KotCzarny> umkay, seems to be some cruft from dragonflasher
<KotCzarny> and it seems to be working (ie. uboot booted from win7_64's version of sunxi-fel)
<KotCzarny> [admin@t500 13:15:51 /cygdrive/g/f/sunxi-tools-win32]$ ./sunxi-fel.exe --help
<KotCzarny> Invalid option --help
<KotCzarny> please fix that :P
<plaes> heh
<plaes> maybe you want /? too ;)
<KotCzarny> nah, -h/--help should be enough ;)
<KotCzarny> cmdline people get used to use it
<KotCzarny> otoh i got -7 on fel write of 32MB file
<KotCzarny> and even on 1M file now
<KotCzarny> what should be the address format? 0x44000000 is fine?
<ssvb> 0x40000000 is the start of physical RAM
<KotCzarny> its not 40 its 44
<KotCzarny> hmm
<KotCzarny> sunxi-fel write doesnt work for me
<KotCzarny> hmm
<KotCzarny> it fails when done from opipc too
<ssvb> "sunxi-fel write" should work, because it transferred the main u-boot part somehow
<KotCzarny> could be related that boot0 wasn't initialized
<ssvb> boot0 part?
<KotCzarny> ssvb, can you check: ./sunxi-fel write 0x44000000 u-boot-sunxi-with-spl.bin
<ssvb> basically, if you have already started the main u-boot part, then it does not talk FEL protocol anymore
<ssvb> that's why you need to run "sunxi-fel spl u-boot-sunxi-with-spl.bin" (the "spl" command instead of "uboot") in order to be able to read/write DRAM
Keziolio has joined #linux-sunxi
Keziolio has joined #linux-sunxi
Keziolio has quit [Changing host]
<KotCzarny> yup, that's it, thx again
<KotCzarny> 570kB/s
<KotCzarny> and 944kB/s when ran from opipc
<KotCzarny> target was the same a13 ereader
flygoat has quit [Quit: Connection closed for inactivity]
<ssvb> hmm, that's very interesting
<ssvb> is the 944kB/s speed reproducible when transferring large data blocks?
<KotCzarny> yes, it was 8MB block
<KotCzarny> want me to try something bigger?
<ssvb> well, as you can see in the speed results table, we got a lot of various numbers there
<KotCzarny> yup, just added a note about that
<ssvb> it is not quite clear what causes this particular difference (between ~500KB/s and ~900KB/s)
<KotCzarny> i bet it's the os adding some overhead
<KotCzarny> and i bet those 900+ results were all ran from linux
<KotCzarny> and those ~500-600 from windoze
<ssvb> just try to check if the high transfer speed is really reproducible for you after a few reboots
<KotCzarny> reboots of a13 or hosts?
<KotCzarny> all i did was reconnecting cable between opipc and laptop
<KotCzarny> when reconnected to laptop it was 570 again
<KotCzarny> so it's reproducible
<ssvb> preferably reboot both
<ssvb> the host system in your case is the opipc, right?
<KotCzarny> yes, i'm using a13 as a target in both cases
<ssvb> BTW, most of the speed test results are from my Intel Core i7 computer running Linux
<NiteHawk> i've noticed a distinct difference in FEL write speeds on my a20 (bpi-m1) depending on whether uart is connected, or not
<KotCzarny> maybe you should redo them and mark system/os used?
<ssvb> I doubt that anyone used Windows for these benchmarks before :-)
<KotCzarny> nitehawk: uart was connected in both cases
<ssvb> NiteHawk: yes, it would be great to identify what exactly affects the transfer speed
<KotCzarny> latency? overhead? noise?
<NiteHawk> KotCzarny: did you build the cygwin sunxi-fel yourself, or is that the precompiled binary from appveyor?
<KotCzarny> though noise shouldnt, as you dont do retransmits
<KotCzarny> used the binary
<NiteHawk> ok, fine
<KotCzarny> hmm
<KotCzarny> i'll try disconnecting uart from laptop
<KotCzarny> still 570
<KotCzarny> [admin@t500 13:49:58 /cygdrive/g/f/sunxi-tools-win32]$ ./sunxi-fel write
<KotCzarny> Invalid command write
<KotCzarny> you could add some better error messages (ie. printing usage on commands)
<ssvb> you could fix this yourself and submit a pull request :-)
<KotCzarny> :)
<KotCzarny> maybe, if i ever learn how to make pr
victhor has joined #linux-sunxi
<NiteHawk> KotCzarny: ./sunxi-fel with no arguments at all gives some (terse) usage info. admittedly we should probably handle -h/--help
<KotCzarny> wth, after a reboot i'm getting -7 from win7
<NiteHawk> (and print "It's no time for Beatles' hits.")
<KotCzarny> (and ver worked before that -7)
<KotCzarny> ahm, nvm. forgot the spl
cobra_koral has joined #linux-sunxi
<KotCzarny> still 570kB after a reboot
cazzacarna has left #linux-sunxi [#linux-sunxi]
paulk-collins has joined #linux-sunxi
IgorPec has quit [Ping timeout: 255 seconds]
cajg_ has joined #linux-sunxi
JohnDoe_71Rus has quit [Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org]
cajg has quit [Ping timeout: 240 seconds]
cajg_ is now known as cajg
ericxdu_ has joined #linux-sunxi
Harrier has joined #linux-sunxi
ruben-ikmaak has joined #linux-sunxi
Nacho__ has joined #linux-sunxi
mnemoc has joined #linux-sunxi
IgorPec has joined #linux-sunxi
jkarlson has joined #linux-sunxi
jkarlson has joined #linux-sunxi
jkarlson has quit [Changing host]
kelvan_ has joined #linux-sunxi
zoobab_ has joined #linux-sunxi
andromed1-galaxy has joined #linux-sunxi
mfa298_ has joined #linux-sunxi
jski_ has joined #linux-sunxi
buZz_ has joined #linux-sunxi
Nemo_bis_ has joined #linux-sunxi
lynxis_ has joined #linux-sunxi
jski has quit [Write error: Broken pipe]
ericxdu has quit [Write error: Broken pipe]
zoobab has quit [Write error: Broken pipe]
buZz has quit [Write error: Broken pipe]
Nacho has quit [Quit: No Ping reply in 180 seconds.]
GrimKriegor has quit [Excess Flood]
Harrier_ has quit [Quit: No Ping reply in 180 seconds.]
lynxis has quit [Quit: No Ping reply in 180 seconds.]
ikmaak has quit [Quit: No Ping reply in 180 seconds.]
kelvan has quit [Quit: No Ping reply in 180 seconds.]
menomc has quit [Remote host closed the connection]
Ke has quit [Remote host closed the connection]
mfa298 has quit [Remote host closed the connection]
andromeda-galaxy has quit [Remote host closed the connection]
Nemo_bis has quit [Remote host closed the connection]
xdanger_ has joined #linux-sunxi
jkarlson is now known as Ke
GrimKriegor has joined #linux-sunxi
buZz_ is now known as buZz
IgorPec has quit [Ping timeout: 240 seconds]
IgorPec has joined #linux-sunxi
xdanger has quit [Ping timeout: 258 seconds]
mhlavink_afk has joined #linux-sunxi
mhlavink has quit [Ping timeout: 260 seconds]
cnxsoft has quit [Quit: cnxsoft]
IgorPec2 has joined #linux-sunxi
IgorPec has quit [Read error: Connection reset by peer]
vinimac has quit [Quit: Leaving]
<KotCzarny> hmm, U-Boot 2016.11-rc2-00096-g4b0dcc5-dirty (Feb 13 2017 - 08:44:01 +0100) Allwinner Technology
<KotCzarny> why is there 'allwinner technology' mark?
<NiteHawk> because that's U-Boot compiled for *sunxi* SoCs. No other manufacturer produces those
<KotCzarny> still, looks like they copyright the code or something
<KotCzarny> 'compiled for sunxi' would be more informative ;)
<NiteHawk> ssvb: https://paste.fedoraproject.org/556854/48699373/ - think that would a reasonable warning message?
<KotCzarny> add some info about error -7
<KotCzarny> that it's usually usual result
<NiteHawk> error -7 might even be misleading in this particular (VM) case. the usual cause is that the FEL handler crashed, often due to attempts to access ununitialized memory (DRAM)
<KotCzarny> add '*might*' then
<NiteHawk> but agreed, we could be a bit more verbose on that -7
<NiteHawk> you too didn't tell us you're using a VM right away - and thus sent us chasing phantoms ;)
DullTube has quit [Quit: Leaving]
<KotCzarny> too many variables affecting same error code
lemonzest has quit [Ping timeout: 240 seconds]
<KotCzarny> fun, mkimage doesnt work on network drive
Nemo_bis_ is now known as Nemo_bis
Nemo_bis has quit [Changing host]
Nemo_bis has joined #linux-sunxi
lemonzest has joined #linux-sunxi
fkluknav has joined #linux-sunxi
chomwitt has joined #linux-sunxi
<KotCzarny> is there some 'wait for device' switch in sunxi-fel ?
<NiteHawk> currently not. iirc, ssvb was working on some sort of "fel deamon" for a while
<NiteHawk> "./sunxi-fel --list" sets its exit code depending on whether devices were found or not. you could use that (with "sleep") in a while loop from a shell script
<KotCzarny> will do that probably
<KotCzarny> though such switch should be simple, or maybe it might even be a command looping over ver till it gets something
<NiteHawk> how about this additional info?
<NiteHawk> usb_bulk_send() ERROR -7: Operation timed out
<NiteHawk> that wasn't properly initialized (by running boot0/SPL).
<NiteHawk> SoC has crashed. One possible cause could be a attempt to access DRAM memory
<NiteHawk> The FEL handler seems no longer responsive. This error might indicate that the
<NiteHawk> You probably need to reset / power-cycle the device now.
<KotCzarny> 'has crashed or booted.'
Laibsch has joined #linux-sunxi
<KotCzarny> running uboot or linux or anything exits fel mode too
<NiteHawk> right, good point. "has crashed or exited FEL mode"
<KotCzarny> can i combine u-boot-spl.bin from mainline with u-boot.bin from legacy and have a working u-boot-with-spl.bin ?
<ssvb> KotCzarny: why would you want this?
<NiteHawk> could be, though I'm not sure. try it with running the SPL alone (sunxi-fel spl spl/sunxi-spl.bin), and the "write" and "exec" the legacy U-Boot manually. but that might fails as you seemed to have a very old legacy version
<KotCzarny> ssvb, to boot legacy uboot.bin?
<NiteHawk> yes, but what's the point when you have mainline working?
<ssvb> KotCzarny: again, why would you want this? are you missing some features?
<KotCzarny> (via fel, for testing and not swapping card, rewriting it etc)
<KotCzarny> ssvb, right now i'm trying to unbrick my device
<NiteHawk> NAND support?
<KotCzarny> that too
<ssvb> KotCzarny: which device? the bookreader?
<ssvb> BTW, one of the reasons why I bought https://linux-sunxi.org/MSI_Primo81 was that the vendor provided a flashable image of the OS among other things
<KotCzarny> yup
<KotCzarny> ssvb, my dream is to have eink based linux device
<ssvb> does the vendor provide any images for this bookreader?
<KotCzarny> hackable linux device
mfa298_ is now known as mfa298
<KotCzarny> ssvb, nope, just 'updates', kernel and uboot trees
<ssvb> this sucks, it's a good reason to avoid this hardware
<KotCzarny> of course no documentation how to build
<MoeIcenowy> NiteHawk: for -7 I think you should do so:
<MoeIcenowy> first verify whether the address is in DRAM
<MoeIcenowy> if in, show an notice "If you're trying to access DRAM, please first execute a SPL to initialize DRAM"
<KotCzarny> ssvb, know any other cheap/eink based/hackable linux device?
<MoeIcenowy> next try sunxi-fel ver
<MoeIcenowy> if failed also, show "The FEL stack cannot respond -- maybe it died. Please try to reset the board"
<ssvb> KotCzarny: no idea, and I have no time to invest into investigating this
<NiteHawk> MoeIcenowy: the problem is that this is a 'generic' error handler that might actually get called from a lot of ("low-level") places - https://github.com/linux-sunxi/sunxi-tools/blob/master/fel_lib.c#L45-L60
<ssvb> NiteHawk: we have high level read/write functions, which are also having a safety check to prevent overwriting u-boot
<KotCzarny> nitehawk: then it should describe all those possible situations
<ssvb> NiteHawk: in principle, we can have a basic check to see if the DRAM clock is on
<NiteHawk> ssvb: fair enough. still requires a rewrite to the lower-level function return a result code then
<NiteHawk> that's an idea. without DRAM clock any access attempt is doomed to fail anyway
JohnDoe_71Rus has joined #linux-sunxi
<ssvb> of course, with just a single HW register read, we can't be sure that the DRAM is initialized correctly
<ssvb> but at least we can see that such attempt had been done :-)
<NiteHawk> exactly - and without it, FEL is doomed to fail anyway
reinforce has quit [Quit: Leaving.]
<KotCzarny> is there a way to detect kernel format? bootz is detected by 'file' but others?
<ssvb> we just need to add a property to the soc_info struct with the location of the relevant bit in memory
<ssvb> then show an error message and refuse reads/writes to the DRAM area if it is not set
<ssvb> KotCzarny: regarding you 900 KB/s FEL transfer speed on A13, can you maybe investigate it a bit more?
kelvan_ is now known as kelvan
kelvan has quit [Quit: http://quassel-irc.org - Chat comfortably. Anywhere.]
<KotCzarny> ssvb: tell me what you need
kelvan has joined #linux-sunxi
<ssvb> KotCzarny: please provide detailed instructions about how you got it working (the opipc board, the linux kernel version and the type of linux distro running on it, etc.) and maybe submit an issue at github
<ssvb> basically, we know that there is some final bottleneck which is not allowing to get 900 KB/s transfer speeds on some boards, but nobody was able to debug this yet
<ssvb> we have already eliminated a number of other performance bottlenecks and this seems to be the last one
<KotCzarny> ssvb: armbian, kernel, hum, gotta boot it
<ssvb> just post this information as a github issue filed against sunxi-tools, providing as much details as possible
<ssvb> you can label it as "900 KB/s FEL transfer speed on A13"
<ssvb> and we want to know if it is possible to ensure that we can reach it in a reliable way
<KotCzarny> kernel 3.4.112+ (from armbian, but compiled my own config)
<KotCzarny> issue posted, let me know if you need any other data
<NiteHawk> ssvb: i notice that code uses PLL5_CFG_REG (aka PLL_DDR_CFG_REG) instead of DRAM_CLK_REG / DRAM_CLK_GATING_REG (0x100) - is there a particular reason for that? can we be sure that it's always the same PLL for each SoC, or it that possibly up to the board (hw) designer?
<NiteHawk> ah, after some more reading DRAM_CLK (related to CSI?) is misleading - it needs to be some dedicated "DDR" clock
<ssvb> NiteHawk: the DRAM PLL HW register (and the "enabled" bit) is SoC specific, that's why we need to add a new field to soc_info
<ssvb> KotCzarny: thanks, maybe I'll try to reproduce it if I manage to find a spare SD card for armbian
<KotCzarny> you can just compile kernel and dualboot
<KotCzarny> should i attach my .config ?
<ssvb> nah, that's too much hassle, also I want to have the step by step reproduction instructions as simple as possible
<KotCzarny> then it's required as i believe it's up to kernel, not the os
<ssvb> your config will be needed if the stock armbian image does not exhibit this behavior
<KotCzarny> and i'm not using default armbian kernel, but compiled my own from their sources
<KotCzarny> k
<ssvb> well, that's why I wanted the *exact* step by step instructions
<ssvb> if we can reproduce this with the default armbian config, then it would be the best
<KotCzarny> maybe i'll reboot this thinkpad to linux later and check there too
<ssvb> thanks, it would be nice
<NiteHawk> ssvb: that's okay - but a board designed cannot deliberately decide to use a different PLL, it's bound to the specific SOC. right?
<NiteHawk> ..designer
<ssvb> yes
<rellla> how can display output support be implemented in the status matrix in a good way? different drm-hdmi, drm-lvds ... rows?
msevwork has quit [Quit: Leaving]
IgorPec2 has quit [Ping timeout: 255 seconds]
<KotCzarny> ssvb: 570kB/s from linux
vishnup has joined #linux-sunxi
<MoeIcenowy> rellla: sub matrix?
<KotCzarny> ssvb: when adding some very cheap usb1 hub between it jumped to 574kB/s
IgorPec has joined #linux-sunxi
<KotCzarny> linux kernel 4.5.2 on this linux
vinimac has joined #linux-sunxi
<KotCzarny> i suspect it's specific to usb host chipset
<ssvb> we just need to verify if anything can be done via the available libusb configuration knobs to improve the situation
<KotCzarny> similarly to some ethernet hubs acting weird with specific ethernet cards
<ssvb> as I mentioned in the github issue, it's good that you confirmed that there does not seem to be a FEL transfer bottleneck on the A13 device side (it can go up to 900kB/s depending on the host system)
<ssvb> either way, the USB stack implemented by the BROM on the device side is completely out of our control
<ssvb> but if we can nudge something on the host side, then it would be great
<KotCzarny> would be nice to test it with usb host that has chipset other than intel
<ssvb> yeah, mine is obviously Intel too
<KotCzarny> and maybe good usb hub, who knows
reinforce has joined #linux-sunxi
<rellla> MoeIcenowy: to be filled ...
IgorPec has quit [Ping timeout: 255 seconds]
kaspter has quit [Ping timeout: 256 seconds]
leon-anavi has quit [Quit: Leaving]
<KotCzarny> funny that compiled binaries show ver 1.4.2 and git compiled one 1.4.1
<NiteHawk> huh? you mean "git describe --tags --always" doesn't produce something based on 1.4.2 for you?
fkluknav has quit [Ping timeout: 258 seconds]
<KotCzarny> nope, i mean running sunxi-fel
<KotCzarny> it's in the first line
<KotCzarny> this is for the binary compiled just now: sunxi-fel v1.4.1-25-g93a26d5
<KotCzarny> and this is in windows binary: sunxi-fel v1.4.2 632925d
<KotCzarny> maybe i've git cloned weirdly
<KotCzarny> though it includes your -h change at least, so should be latest
<NiteHawk> 93a26d5 dates back to November 2016
<NiteHawk> did you limit the clone depth?
<KotCzarny> maybe, i have this directory laying around and just git pull'ing sometimes
wzyy2 has joined #linux-sunxi
<vinimac> mripard: The Mark Brown's recommendation seems very much complex than a simple dts property, am I right?
<KotCzarny> nitehawk: cloned it again, sunxi-fel v1.4.2-45-g7128c73
fkluknav has joined #linux-sunxi
<KotCzarny> sources compile same sizes in both cases, only version differs, funky
<NiteHawk> i just recalled that an existing version.h might now get overwritten on every compile - might explain it. the auto-versioning is mainly thought for automated builds, e.g. the CI ones
<NiteHawk> s/might now/might not/
<NiteHawk> (it will work correctly if you force a full rebuild with "make -B")
vinimac has quit [Quit: Saindo]
vinimac has joined #linux-sunxi
IgorPec has joined #linux-sunxi
Gerwin_J has quit [Quit: Gerwin_J]
<KotCzarny> oh wow, someone transposed status matrix
jernej has joined #linux-sunxi
<KotCzarny> on the plus side now it fits horizontally ;)
terra854 has quit [Quit: Connection closed for inactivity]
Mr__Anderson has quit [Remote host closed the connection]
victhor has quit [Ping timeout: 260 seconds]
vagrantc has joined #linux-sunxi
huawei has quit [Ping timeout: 240 seconds]
LargePrime has joined #linux-sunxi
netlynx has joined #linux-sunxi
IgorPec has quit [Quit: Nettalk6 - www.ntalk.de]
IgorPec5 has joined #linux-sunxi
<plaes> KotCzarny: on the minus side, we'll probably have new SoC's soon :(
IgorPec has joined #linux-sunxi
<KotCzarny> he he ;)
chomwitt has quit [Ping timeout: 258 seconds]
IgorPec5 has quit [Ping timeout: 240 seconds]
fkluknav has quit [Ping timeout: 256 seconds]
|Jeroen| has joined #linux-sunxi
Ixnus has joined #linux-sunxi
<Ixnus> rellla: well done! KotCzarny: nice progress.
<KotCzarny> ixnus: progress being apparently killing eink controller? eh
<Ixnus> btw - now the status matrix has space to fit 2-3 more SoCs;
<jelle> oh woah
<jelle> whoever did that nice :)
<Ixnus> is it that easy to kill one?
<Ixnus> rellla - did it.
<Ixnus> KotCzarny: check this might be helpful: http://blog.soutade.fr/post/2015/03/game_over.html
<KotCzarny> ixnus: i dont know what killed it, but it failed to update, most likely it was it
<KotCzarny> yup, update was from that site
<KotCzarny> maybe if i get original kernel for nolimbook, but chances are slim
<Ixnus> isn't it software issue then ?
Andy-D has joined #linux-sunxi
<KotCzarny> dont know, but eink controller no longer responds on i2c bus
<KotCzarny> i'm trying to make the mainline kernel boot on it
Pepe has quit [Ping timeout: 240 seconds]
<KotCzarny> weridly enough default a13 dts uses in lcd_rgb666_pins section pins connected to eink controller
enrico__ has quit [Quit: Bye]
<KotCzarny> (couldn't they have just connect them to some generic gpio pins, eh?)
<Ixnus> u got the mainline u-boot running now ?
<KotCzarny> yes, its not a problem since a13 is supported
<Ixnus> half-way there
<KotCzarny> but generic a13 kernel i've compiled doesnt even start, board just resets
<KotCzarny> not even earlyprintks
<ElBarto> KotCzarny: which board is it ?
<KotCzarny> bookeen muse clone (nolimbook)
<Ixnus> 4.X kernel ? Which DTS u use ?
<KotCzarny> copied one from q8-a13 and removed display section
mossroy has joined #linux-sunxi
<KotCzarny> mainline is mainline, 4.10-rcsomething
Pepe has joined #linux-sunxi
<Ixnus> hm, excluding the e-ink this _is_ plain a13 board - the best supported sunxi SoC
<KotCzarny> grab the second one and join the hacking party?
<MoeIcenowy> KotCzarny: You killed the eink controller?!
<MoeIcenowy> R.I.P.
<KotCzarny> MoeIcenowy: it doesnt respond on i2c, what can i do about it?
<MoeIcenowy> can stock ROM still be used?
<KotCzarny> nope, it's the reason im trying to hack mainline into it
<KotCzarny> eink driver panics when it cant enable hw
<MoeIcenowy> you broke the stock ROM?
<KotCzarny> such grace, much juy
<KotCzarny> *joy
* jelle once blew up a touchscreen i2c controller
<KotCzarny> jelle: how?
<jelle> KotCzarny: trying to get firmware support working
<KotCzarny> then you were writing something to it, i didnt even get there
<jelle> KotCzarny: yup
<KotCzarny> now i'm taking quick course on DT
<jelle> KotCzarny: :)
<KotCzarny> i wonder why they haven't just put dts parser into the kernel
scream has joined #linux-sunxi
<MoeIcenowy> Updates to http://linux-sunxi.org/User:Icenowy/Problems_to_Allwinner is now still welcomed
<Ixnus> for sure I'll get one - just don't know when - I already have bough one with the wrong SoC :)
<MoeIcenowy> I will translate the problems to zh_CN
<jelle> MoeIcenowy: you are meeting with allwinner?
<MoeIcenowy> jelle: not sure whether I will meet with AW
<MoeIcenowy> but TL Lim says that he will pass these problems to AW BU2 (A-series and H8VR)
* jelle thinks
<jelle> MoeIcenowy: documentation about the openrisc core?
<beeble> KotCzarny: did you enable LDO4?
netlynx has quit [Quit: Ex-Chat]
<MoeIcenowy> jelle: I don't think they will give any documentation about it...
<jelle> MoeIcenowy: :(
<KotCzarny> beeble: don't know, will check
<MoeIcenowy> but the parameters of AR100 is not a difficult thing
<MoeIcenowy> the peripherals used in ARISC firmware is indeed the real important thing ;-)
<KotCzarny> MoeIcenowy: but maybe they have some info that isnt obvious, who knows
<jelle> MoeIcenowy: isn't the openrisc core required for suspend?
<beeble> KotCzarny: maybe the tps has its own powerrail. would make sense to be able to turn it off completely in a ereader
<KotCzarny> beeble, umkay, to make it quicker, where should i look? in uboot dts?
<MoeIcenowy> jelle: maybe you should say "they used it for suspend"
<jelle> MoeIcenowy: ah well, I'm interesting in getting suspend working =)
<KotCzarny> jelle: +1
<jelle> I know it requires more work
<beeble> KotCzarny: CONFIG_AXP_ALDO4_VOLT
<jelle> iirc you also program the dram controller etc.
<MoeIcenowy> but I think current documents that we have got can already make suspend work
<MoeIcenowy> except the lack of some PRCM documents
<jelle> MoeIcenowy: ok (btw I'm a noob++) :P
<MoeIcenowy> and I asked for PRCM documents
<KotCzarny> =3300
<jelle> MoeIcenowy: cool
<MoeIcenowy> in A83T there's doc for PRCM in user manual
<KotCzarny> same for aldo3
<MoeIcenowy> we only cannot ensure whether it's usable on other SoCs
<jelle> MoeIcenowy: suspend would be nice for the a64 laptop :)
<BenG83> what is PRCM?
<jelle> (obviously)
<MoeIcenowy> jelle: maybe you need "S0ix" ;-)
<BenG83> suspend doesn't even really work with the BPS kernel, at least not 100%
<jelle> MoeIcenowy: looks like an intel thing :P
Ntemis has joined #linux-sunxi
<jelle> BenG83: well I bet they aren't interested in it (in the BSP)
<beeble> KotCzarny: could you pastebin your .config?
<MoeIcenowy> BenG83: Power, Reset and Clock Management
<ssvb> BenG83: suspend should work on tablets, otherwise they can't have any reasonable battery life
<BenG83> it works most of the time with the stock image that came with the Pinebook
<BenG83> sometimes it doesnt wake up
<MoeIcenowy> ssvb: usually for tablets it's not really suspended
<BenG83> and the BSP source drop that came with it
<MoeIcenowy> they only enters a mode that many peripherals is temporarily disabled
<ssvb> MoeIcenowy: are you sure about this?
<MoeIcenowy> ssvb: at least when it's connected to PC, it's true
<jernej> does anybody know what SDM bit in PLL registers do?
<MoeIcenowy> jernej: which PLL?
<ssvb> MoeIcenowy: A20 implements suspend without OpenRISC, but the whole SoC gets powered down and the wake up is handled as a new boot
<jelle> ohh interesting
<jernej> I think every H3 PLL register has this bit
<jernej> MoeIcenowy: PLL_DE, for example
<ssvb> MoeIcenowy: only a few HW registers are battery backed and retain state, they are used to store the "super-suspend flag" which tells the bootloader to bring DRAM back from self-refresh rather than doing full init
<MoeIcenowy> jernej: oh I found it, but I really do not know it...
<ssvb> MoeIcenowy: after my A20 tablet suspends in Android, I can insert an SD card with the mainline U-Boot, and when Android is supposed to "wake up" the mainline U-Boot gets booted instead :-)
<rellla> Ixnus: thanks. N/A for H3 display is really right? wasn't aware of that...
<MoeIcenowy> ssvb: oh...
<jernej> MoeIcenowy: BTW, I didn't have any troubles with enabling DE2 on A83T
<ssvb> MoeIcenowy: that's how the stuff works without a dedicated OpenRISC core
<KotCzarny> ssvb: that's becauyse its implemented in uboot
<KotCzarny> (resume)
<jernej> rellla: H3 has only cvbs and hdmi
<rellla> oh :)
<jernej> rellla: as H5, because they are set top box series
<jelle> ssvb: so then you only have to fiddle in u-boot to get a h3 to suspend
<jernej> rellla: A series doesn't have CVBS for example
<MoeIcenowy> for H3 one can never re-power up the SoC if it's halted withoue AR100 enabled
<ssvb> jelle: H3 has an OpenRISC core, and this core is supposed to be awake during suspend
<KotCzarny> also, h3 doesnt have battery backup ;)
<jelle> oh yeah lol ;-)
<MoeIcenowy> I think first we should implement ARISC to listen to IR & some r_gpio_keys ;-)
<ssvb> jelle: when the wake up button is pressed (that's just an ordinary GPIO button on the port L), the OpenRISC core is supposed to start the ARM cores again
<MoeIcenowy> ssvb: y
<jelle> MoeIcenowy: that would be neat. I want to have that for when I poweroff
<rellla> plaes: for the alignment i thought we have at least more features than socs :)
<MoeIcenowy> but I cannot do OpenRISC assembly...
<jelle> MoeIcenowy: I looked into making the h3 poweroff completely too since now it still draws power
<jelle> MoeIcenowy: your smart enough though :)
<beeble> MoeIcenowy: there is a compiler :)
<MoeIcenowy> beeble: it's difficult to port a or1k-gcc to a specified machine
<beeble> MoeIcenowy: on a31 we had or1k stuff running. with a shell and all the fancy stuff
<beeble> compiled with or1k-gcc
<ssvb> MoeIcenowy: you can doenload a binary toolchain, and I have toolchain build instructions for Gentoo - https://linux-sunxi.org/Toolchain#OpenRISC_crosscompiler
<ssvb> there is nothing really difficult about it
<MoeIcenowy> as a distro maintainer I of course have the ability to build a cross toolchain ;-)
<jelle> :p
<ssvb> so what's the problem then?
<MoeIcenowy> we will lose newlib with such a unported toolchain ;-)
<MoeIcenowy> although we can fully prevent to use libc ;-)
<ssvb> how would you lose it?
<ssvb> OpenRISC is supported in upstream newlib and binutils
<ssvb> the only problem is GCC - https://linux-sunxi.org/AR100#Toolchain
<beeble> KotCzarny: checked you .config against your fex file. don't see anything wrong.
<KotCzarny> beeble: keep in mind i have edited few things by hand before running make
<ssvb> it does not make any sense to use glibc for OpenRISC without MMU
<KotCzarny> beeble: legacy kernel panics on papyrus powerup, it's all about missing device on i2c
<MoeIcenowy> P.S. for A64 apritzel choose to let ATF occupy the space of ARISC firmware in mainline solution
florianH has quit [Quit: Connection closed for inactivity]
<KotCzarny> MoeIcenowy: that's not nice
<KotCzarny> ;)
<ssvb> MoeIcenowy: this is not set in stone
<ssvb> also there might be enough space for both ATF and ARISC firmware in SRAM A2
<ssvb> apritzel also considered an option of loading the ATF into SRAM A1 some time ago
<MoeIcenowy> A2 is the best choice when there's no arisc
<ssvb> or the ATF can be moved back to the DRAM, just like it is done by Allwinner
<MoeIcenowy> and for A64 arisc is not so critical
<ssvb> yeah, assuming that you can implement a decent suspend support without it
<KotCzarny> ssvb, powering down whole soc is a nice feature
<KotCzarny> well, almost whole soc
<MoeIcenowy> jernej: so A64 is the only SoC that mysteriously cannot have DE2 to work?
<jernej> MoeIcenowy: yes, from what I can tell
<beeble> KotCzarny: so from the software point of view i can't think of anythign anymore. i would use a scope for more :)
<MoeIcenowy> P.S. I also easily got V3s DE2 to work
Mr__Anderson has joined #linux-sunxi
<ssvb> jernej: but you can get DE2 to work on A64 if you boot with boot0, or I misunderstood something?
<MoeIcenowy> so we got A83T, V3s, H3, H5 to work, only not working SoC is A64
<KotCzarny> beeble: thanks for the help though, i still havent tried cutting battery wires
<KotCzarny> pin25 trick didnt help
<jernej> MoeIcenowy: DE2 works with BSP U-Boot, I have to try uboot0 + mainline combination
<MoeIcenowy> or maybe there's some hidden code in arisc?
<ssvb> jernej: well, this means that it *can* work in principle, there are just some missing configuration knobs
<jernej> MoeIcenowy: I considered that too, but it is tedious to go through assembly
<jernej> ssvb: I know, but I tried almost everything I can think of
<KotCzarny> jernej: have you tried asking aw?
<beeble> KotCzarny: maybe you connected not correctly. qfn packages can be hard to connect due the only very small exposed pin. and if you didn't get through the oxidlayer of the solder joint nothing would happen
<jernej> KotCzarny: I just put that question on MoeIcenowy list of questions for Allwinner
<KotCzarny> beeble: device was working initially, update failed, then it wasnt booting anymore (due to papyrus panic)
jstein_ has joined #linux-sunxi
jstein_ has quit [Remote host closed the connection]
<beeble> KotCzarny: i was talking about pin 25
<MoeIcenowy> jernej: you clocked up DE2 with PLL_DE on A83T, right?
<jernej> MoeIcenowy: yes
<MoeIcenowy> maybe I should have a deadline for the wiki page, then pack the problems up and send them...
<KotCzarny> beeble: not that hard because its one of the side pins
<jernej> MoeIcenowy: there is no CCU DE register (0x104)
<MoeIcenowy> ah-oh
<jernej> it is not needed aparently
<jernej> it is funny how much variations could be there for basically same functionality
<MoeIcenowy> oh there's really CCU DE register...
<MoeIcenowy> but in CCU_SCLK chapter
<MoeIcenowy> oh... I opened the file of A80
* MoeIcenowy get too silly
<MoeIcenowy> yes there's really no CCU_DE register
<KotCzarny> could you guys sniff what bsp is doing?
<KotCzarny> (and girls)
<jernej> we're trying but the secret is heavily protected :)
<MoeIcenowy> I didn't find any code with suspicion in lowlevel_sun50iw1/ of DE2 code
<KotCzarny> i mean, is it possible to see what clocks are used and where?
<KotCzarny> on a running system
<jernej> KotCzarny: I copied clock values from working image, but it didn't work
<MoeIcenowy> so did I
gk-1wm-su has joined #linux-sunxi
f0xx has quit [Ping timeout: 240 seconds]
<KotCzarny> magic initializations ahoy!
komunista has quit [Quit: Leaving.]
gk-1wm-su has quit [Client Quit]
IgorPec5 has joined #linux-sunxi
quinward has joined #linux-sunxi
IgorPec5 has quit [Ping timeout: 245 seconds]
cobra_koral has quit [Ping timeout: 255 seconds]
cobra_koral has joined #linux-sunxi
cobra_koral has quit [Ping timeout: 255 seconds]
wzyy2 has quit [Remote host closed the connection]
Ixnus has quit [Quit: Page closed]
quinward has quit [Quit: WeeChat 1.5]
chomwitt has joined #linux-sunxi
Ntemis has quit [Remote host closed the connection]
<plaes> KotCzarny: got it working?
<KotCzarny> nah, just commenting on moeicenowy and jernej's adventures
apritzel has joined #linux-sunxi
<apritzel> re A64 ATF load address> SRAM A2 seems like an easy choice, because it's secure(*) by default and not used atm
mossroy has quit [Quit: Leaving]
utente has joined #linux-sunxi
<apritzel> but as ssvb said: nothing is set in stone, it's just load addresses in some config file
<apritzel> and I indeed I was playing with the idea of moving it into SRAM A1
lemonzest has quit [Quit: Leaving]
<apritzel> MoeIcenowy: and having a bare metal tool chain to compile some low level code for OR1K is easy, I think I had a hello world running already some months ago
|Jeroen| has quit [Quit: dada]
<beeble> apritzel: we also did some clocking and power stuff already. just to see how low we can get in terms of consumption
<apritzel> beeble: running the arisc from LOSC (32KHz)?
<beeble> yes
<KotCzarny> isnt kilo shorthand lowercase k ?
<beeble> but since all the wakeup code was not done (yet) it wasn't that useful
<beeble> KotCzarny: yes
<beeble> running at 32khz is pretty painful btw :)
<beeble> keystroke to echo takes seconds
<KotCzarny> o.O
<beeble> funny sidesnote btw. rockchip has two cortex m0 instead of a arisc. even naming one dedicated pmumcu but the only code running on it is about 3 lines of c code as a workaround for a siliconbug at warm reset
<apritzel> lol
<apritzel> beeble: in the 3399?
<beeble> apritzel: should tell that you bosses as a way to sell more core licenses :)
<apritzel> beeble: do you think that's an accident? ;-)
<beeble> apritzel: yes. can look the source up if you are interested when i'm off mobile again
<apritzel> the M class outsells A class by a large margin anyway ...
<beeble> understandable
<beeble> dirt cheap nowdays, great toolchains and versatilebas hell
<apritzel> beeble: do you use GCC or the ARM compiler?
<beeble> did a lot of m3 projects in the past and even nowdays we just put one ore more m0/3 as compananions next to a cortex-a
<beeble> gcc
<beeble> we only use keil if we have legacy code that we can't touch (or are not paid) to make it compile with gcc
<apritzel> thought so ...
<BenG83> most new projects I do use gcc now
<BenG83> but we used Keil4/5 for almost 10 years
<beeble> and we only see it from the big companies and source drops fron the cpu vendors
<beeble> bcm seems still like to stick with keil for whatever reason
<BenG83> just started a new project using Freescale/NXP Kinetis K81
vinimac has quit [Quit: Leaving]
<beeble> BenG83: any special reason for chosing kinetis?
<BenG83> and probabl i.MX6
<BenG83> yes security features
<BenG83> it's for an applications involving smartcards
<BenG83> tamper pins
<BenG83> and other things
<beeble> hmm doing that with st
<BenG83> i.MX6UL has also DryICE
<BenG83> we are doing one low end design with K81 and one with the i.MX6
<BenG83> running Linux
<beeble> does kinetis has finaly usarts?
<BenG83> no
<KotCzarny> maybe those running pure asm are those ran by old timers?
<BenG83> at least not the K81
<beeble> thats ine if the reasons we always stick to stm32
<BenG83> I personally prefer LPCxxx
<BenG83> I worked for Atmel a couple years then went back to research
<BenG83> now working on industrial projects
<beeble> there you get up to 3 usarts and we build smartcard readers for three cards with it
<BenG83> we heavily used LPC2148/2368 with ARM7
<BenG83> then the compatible CortexM when they came out
<BenG83> now we use whatever the customer wants :)
<apritzel> usart as in one peripheral can do I2C, SPI and UART?
<beeble> apritzel: no, uart with clock
<beeble> needed if you want to talk iso7816 directly
vinimac has joined #linux-sunxi
<BenG83> the K81 has dedicated smartcard interfaces
<beeble> "needed" you could always bitbang :)
<beeble> ah, ic. should lookup the datasheet how flexible that block is
<BenG83> we bitbang smartcard sometimes
<BenG83> but mostly for applications that have soldered internal ones
<BenG83> where you can tune stuff for the certification
reinforce has quit [Quit: Leaving.]
<beeble> our allwinner modules do have jcop cards solderd on
<BenG83> I have one prototyping project where we maybe use SOPine :)
cptG_ has joined #linux-sunxi
<beeble> makes me sad :)
<beeble> no, whatever fits your application
<BenG83> we do mostly automotive or medical applications
<beeble> we do have automotive components options if you can overlook the allwinner issue :)
<beeble> but yeah. for that kindnof stuff i use imx6 as well
<beeble> mostly
* apritzel shivers when thinking off an A64 in a medical application ;-)
<BenG83> so far we used mostl i.MX6
<BenG83> medical applications is mostly Cortex-M stuff
<BenG83> :)
* apritzel decides to not get sick
<BenG83> one project uses Xilinx Zynq
<BenG83> for a tracking system
cptG has quit [Ping timeout: 255 seconds]
<beeble> apritzel: the only difference is that you get the errata sheet from freescale/nxp the content doesn't look better :)
<BenG83> ^
victhor has joined #linux-sunxi
<beeble> i will always remember the ine where freescale mixed up the endiness in ther emac block
<beeble> therefore you had to reverse every received byte in the alu
<apritzel> beeble: that's why it's called network byte order ;-)
<beeble> another funny thing was the imx6 manual that told you to change a setting you should change a variable in the source
<beeble> abd below was vhdl printed
<beeble> of the soc
freemangordon has quit [Read error: No route to host]
IgorPec has quit [Ping timeout: 276 seconds]
Mr__Anderson has quit [Remote host closed the connection]
<beeble> apritzel: but they added stuff now. so the m0 does pmu and ddr stuff now. so it's not that ridiculous anymore
paulk-collins has quit [Remote host closed the connection]
scream has quit [Remote host closed the connection]
utente has quit [Ping timeout: 255 seconds]
utente has joined #linux-sunxi
Laibsch has quit [Read error: Connection reset by peer]
JohnDoe_71Rus has quit [Quit: KVIrc 4.9.2 Aria http://www.kvirc.net/]
<Macer> hm
<Macer> what is the best image to use for an opi+2e nowadays?
<Macer> is there an official armbian distro around that i can use on it?
<Macer> ah never mind. i see it
<Macer> debian jessie is on armbian.org
<Macer> no mainline tho :/
<vinimac> for server there are mainline versions
<Macer> hm. don't see any on armbian.com
<Macer> Mainline
<Macer> No stable releases yet. Check nightly releases tab to see if experimental images are available.
Laibsch has joined #linux-sunxi
gk--1wm- has joined #linux-sunxi
gk--1wm- has left #linux-sunxi [#linux-sunxi]
Laibsch has quit [Read error: Connection reset by peer]
utente has quit [Ping timeout: 255 seconds]
lurchi__ is now known as lurchi_
Laibsch has joined #linux-sunxi
<willmore> KotCzarny, technically, yes, kilo is lower case, but there is not other 'k', so there's no ambiguity like 'm' and 'M'. Or 'p' and 'P'.
<willmore> And, since it's not kilo, it's really kibi Hz, both are technically wrong. :)
<willmore> 32KHz clocks are really 32768 Hz clocks. 2^15 of course.
vinimac has quit [Quit: Leaving]
vagrantc has quit [Quit: leaving]