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
jernej has quit [Ping timeout: 244 seconds]
OverCR has quit [Quit: Leaving.]
malfunction_ek has quit [Quit: Page closed]
Guest15887 has joined #linux-sunxi
corvusmalus has quit [Ping timeout: 260 seconds]
perr has joined #linux-sunxi
kaspter has joined #linux-sunxi
jernej has joined #linux-sunxi
kaspter has quit [Read error: Connection reset by peer]
kaspter has joined #linux-sunxi
jernej has quit [Quit: Konversation terminated!]
jernej has joined #linux-sunxi
codekipper has quit [Ping timeout: 250 seconds]
ninolein has quit [Ping timeout: 258 seconds]
ninolein has joined #linux-sunxi
jernej has quit [Ping timeout: 252 seconds]
jernej has joined #linux-sunxi
egbert has quit [Disconnected by services]
egbert has joined #linux-sunxi
jernej has quit [Ping timeout: 240 seconds]
perr has quit [Quit: Leaving]
popolon has quit [Quit: WeeChat 1.4]
cnxsoft has joined #linux-sunxi
foudubassan has joined #linux-sunxi
mosterta has joined #linux-sunxi
mosterta has quit [Ping timeout: 250 seconds]
p1u3sch1_ has quit [Ping timeout: 260 seconds]
p1u3sch1 has joined #linux-sunxi
kaspter has quit [Ping timeout: 244 seconds]
fire219 has quit [Read error: Connection reset by peer]
kaspter has joined #linux-sunxi
IgorPec has joined #linux-sunxi
scream has quit [Remote host closed the connection]
jernej has joined #linux-sunxi
kaspter has quit [Read error: Connection reset by peer]
kaspter1 has joined #linux-sunxi
mosterta has joined #linux-sunxi
mosterta has quit [Ping timeout: 258 seconds]
reinforce has joined #linux-sunxi
foxx_ has joined #linux-sunxi
massi has joined #linux-sunxi
dearfibonacci has joined #linux-sunxi
|Jeroen| has joined #linux-sunxi
dearfibonacci has quit [Ping timeout: 265 seconds]
dearfibonacci has joined #linux-sunxi
mosajjal has joined #linux-sunxi
<mosajjal> Hi everyone
<mosajjal> I have a couple questions regarding opengl on Mali400
<mosajjal> I wanted to know which drivers and tools are needed to achieve opengl HW/accel on Allwinner H3
<mosajjal> right now Xorg falls back to software rendering
<mosajjal> and glxgears takes up so much CPU so I'm guessing it's not GPU accelerated
jernej has quit [Ping timeout: 260 seconds]
<MoeIcenowy> mosajjal: glxgears won't use Mali
<MoeIcenowy> Mali do not support OpenGL, only OpenGL ES
<foxx_> KotCzarny: what about http://www.unwireddevices.com/ ?
<KotCzarny> hard to say, price?
<KotCzarny> 18650 Li battery will be enough for up to 24 hrs on a single charge with Wi-Fi enabled.
<KotCzarny> ~100mA seems like
<mosajjal> MoeIcenowy: what about Chromium ? not possible to use OpenGL ES with chromium ?
<KotCzarny> 300mA max
<foxx_> KotCzarny: 25-35$ afaik
imcsk8 has quit [Read error: Connection reset by peer]
<MoeIcenowy> mosajjal: I do not know about it...
florianH has joined #linux-sunxi
imcsk8 has joined #linux-sunxi
<KotCzarny> foxx, its up to your requirements then, you have to know target role to fit the ram/power/size/software
imcsk8 has quit [Read error: Connection reset by peer]
imcsk8 has joined #linux-sunxi
IgorPec2 has joined #linux-sunxi
IgorPec has quit [Ping timeout: 240 seconds]
Dodger78 has quit [Ping timeout: 244 seconds]
paulk-collins has joined #linux-sunxi
matthias_bgg has joined #linux-sunxi
iamfrankenstein has quit [Ping timeout: 244 seconds]
TheSeven has quit [Disconnected by services]
[7] has joined #linux-sunxi
rakeshk has joined #linux-sunxi
OverCR has joined #linux-sunxi
ricardocrudo has joined #linux-sunxi
Mr__Anderson has joined #linux-sunxi
mosterta has joined #linux-sunxi
IgorPec2 has quit [Ping timeout: 250 seconds]
mosterta has quit [Ping timeout: 252 seconds]
popolon has joined #linux-sunxi
mosajjal has quit [Ping timeout: 250 seconds]
jstein_ has joined #linux-sunxi
jstein is now known as Guest81645
jstein_ is now known as jstein
Guest81645 has quit [Ping timeout: 265 seconds]
IgorPec has joined #linux-sunxi
enrico_ has joined #linux-sunxi
apritzel has joined #linux-sunxi
derRichard has joined #linux-sunxi
<derRichard> can i read something like a cpu serial via fel? i'd like to distinguish allwinner multiple socs which are connrect via usb
<derRichard> fel sid
<derRichard> maybe...
<montjoie> derRichard: http://linux-sunxi.org/SID_Register_Guide but didnt know if there are enought random for using as serial
<apritzel> derRichard: have you tried the "sid" command with sunxi-fel?
<derRichard> apritzel: yeah, just found that command
<jonkerj> apritzel: tnx for the u-boot fdt hint, seems to do what I want
<apritzel> jonkerj: I just love that command, it allows one to quickly hack the DT and do experiments
<jonkerj> are you able to add complete new nodes using that command?
<jonkerj> like i2c clients
<apritzel> yes
<apritzel> jonkerj: in the beginning I used to delete the whole DT and rebuild it
<apritzel> because the original U-Boot didn't allow to load a DT
<jonkerj> are you using some trick to make that less masochistic?
<apritzel> (I had some script which I piped to the serial console to do this)
<jonkerj> it is a LOT of typing
<jonkerj> ah
<jonkerj> cat dts-patch > /dev/ttyOPIplus
<apritzel> I think I had something close to translating a DT into a series of fdt commands
* jonkerj started to daydream about pyparsing DT's and flattening the AST to fdt commands indeed
<apritzel> jonkerj: I think you have to wait for the prompt, so I used "expect", IIRC
<apritzel> derRichard: can you confirm that the SIDs are all different for the boards you have?
<jonkerj> well I was thinking about piping my script to 'xsel' en pasting that in the interactive console
keh has quit [Ping timeout: 265 seconds]
<derRichard> apritzel: tested with 10 socs, all different
<apritzel> jonkerj: this was an early version of what I used: https://gist.github.com/apritzel/c3f811b5493805a616698b8e06b2655a
<jonkerj> funky
<apritzel> I think this was generated by another script
<apritzel> and then fixed up
<apritzel> you have to call it with: $ ./inject_dt.sh < /dev/ttyUSBx > /dev/ttyUSBx
iamfrankenstein has joined #linux-sunxi
iamfrankenstein has quit [Client Quit]
<apritzel> derRichard: can you confirm that the assumptions in http://linux-sunxi.org/SID_Register_Guide#Currently_known_SID.27s are correct?
<apritzel> regarding either the ChipID being the first four nibbles of the SID or at least the first eight nibbles being unique for a certain SoC type?
<wens> maybe people with A64s could add their SID values to the list?
<wens> windows 10 iot core support for pine64 / bpi-m64 ...
kaspter1 has quit [Ping timeout: 276 seconds]
<derRichard> apritzel: only SID_KEY3 is different for each device
<apritzel> derRichard: so all your boards are the same model?
<derRichard> yes. 10 times the same board
<apritzel> derRichard: can you either post here or edit the Wiki to reveal the constant parts of the SID?
<apritzel> I was always curious whether one can identify a board by the SoC's SID
<apritzel> I guess board vendors get certain batches of SoCs from Allwinner and chances are the SIDs are somewhat related to each other within one batch
iamfrankenstein has joined #linux-sunxi
<jonkerj> using mainline sun8i-emac, I get a random mac address every boot, while using sunxi's 3.4 I have a consistent mac address
<jonkerj> how is that possible?
<derRichard> apritzel: fist i have to double check whether i'm allowed to share the sid's
<derRichard> the devices are not owned by me
<apritzel> jonkerj: because you don't set a MAC address using the SID
<apritzel> apritzel: I think U-Boot does that calculation
* apritzel is getting old and talking to himself
<KotCzarny> could be worse
<apritzel> jonkerj: ideally U-Boot would generate a MAC based on the SID, which should be somewhat unique
<KotCzarny> you could've been talking to youself without the pants
<apritzel> KotCzarny: how do you know ;-)
<KotCzarny> ;)
<KotCzarny> because you are at work now?
<apritzel> KotCzarny: this is England, so everything's possible clothing-wise ;-)
<apritzel> jonkerj: and either put that address into the MAC registers or into the DT
<apritzel> I think the BSP kernel does the latter
<jonkerj> I would guess the former, as BSP was DT-less, right?
<wens> u-boot mainline puts an SID-based MAC in the DT, and the mainline kernel picks it up
<wens> with the BSP, it probably just generates the MAC consistently, probably using the SID
<jonkerj> using 2016.05 and 4.7 with montjoie's patches that was not the case on my board, wens
<jonkerj> every boot new mac
<apritzel> jonkerj: do you have U-Boot with sun8i-emac Ethernet support?
<jonkerj> I have the vanilla 2016.0{5,7}
<jonkerj> they seem without sun8i-emac
<apritzel> so they don't do the SID into MAC conversion
<jonkerj> so there is a patch to enable sun8i-emac in u-boot?
<apritzel> I think it was even in 2016.09-rc1, but got disabled?
<apritzel> jonkerj: IIRC I told Amit how to trigger the MAC conversion and storage
<jonkerj> it's not a big deal for me, I was just wondering
<jonkerj> I'
<jonkerj> I'll store this in my mental note cabinet as "will probably be better in a near future"
<jonkerj> in the meanwhile, I'll keep the hwaddr xxyyzz in interfaces.d/eth0
<apritzel> derRichard: sure, no need to reveal anything here
<apritzel> derRichard: I was wondering if one can do this process somehow anonymously
<apritzel> derRichard: possibly you could confirm the assumption against a list of published SIDs, without revealing your SIDs at all
<wens> jonkerj: SID to MAC was only recently introduced for non-designware
<wens> well, for all DTs with ethernet* aliases
<wens> so you need to get the latest u-boot
IgorPec2 has joined #linux-sunxi
IgorPec has quit [Ping timeout: 258 seconds]
<montjoie> HdeGoede sent me a patch for adding ethernet*, so my v3 have it
IgorPec2 has quit [Ping timeout: 244 seconds]
<jonkerj> I'm going to try that later on, but not now
rakeshk has quit [Remote host closed the connection]
cptG_ has joined #linux-sunxi
cptG has quit [Ping timeout: 276 seconds]
mosterta has joined #linux-sunxi
mosajjal has joined #linux-sunxi
mosterta has quit [Ping timeout: 240 seconds]
perr has joined #linux-sunxi
<MoeIcenowy> I successfully made a GRUB-based boot menu on my Cubieboard1
<MoeIcenowy> with GRUB on UEFI on U-Boot
<jonkerj> apritzel: do you happen to know how to convince u-boot in doing something like pinctrl-0 = <&adxl_int_pin> ?
<jonkerj> => fdt set /soc/i2c@01c2ac00/adxl345@0 pinctrl-0 <&adxl_int_pin>
<jonkerj> syntax error
<jonkerj> probably means I should have read more about phandles
<apritzel> jonkerj: yeah, that's the nasty part of this approach ;-)
<apritzel> the phandles are unique values assigned at .dts -> .dtb compilation time by dtc
Mr__Anderson has quit [Remote host closed the connection]
<apritzel> so hacking a DT clearly becomes annoying at this point
<jonkerj> they probably need to be unique throughout the fdt
<apritzel> you can assign your own, as long as you don't mess it up
<jonkerj> do they need to be contigous?
<apritzel> no
<jonkerj> cool
<apritzel> if you have just a few, then it's probably fine
<apritzel> I think those phandles are the reason I didn't fully automate this U-Boot hacking scheme
<jonkerj> I discovered that in order to connect an adxl345 to the i2c bus, the linux driver requires an interrupt line, thus phandle for interrupt-parent, thus phandle for pinctrl
<jonkerj> should have picked a different part to test this :-)
<apritzel> jonkerj: wait till you get to clocks ;-)
<jonkerj> yeah, I'd like to avoid that
<jonkerj> print struct.unpack('>I', open(sys.argv[1], 'rb').read())[0]
<jonkerj> find /sys/ -name 'linux,phandle' -exec ./phandle.py {} \; | sort -n
<jonkerj> it goes up to 58, apparantly
fire219 has joined #linux-sunxi
<apritzel> jonkerj: yeah, as I said the clocks are crazy in this respect, as they all depend on each other, many from more than one source clock actually
cosm_ has quit [Ping timeout: 244 seconds]
montjoie has quit [Ping timeout: 250 seconds]
<jonkerj> ok, this is OK for patching disabled into okay
<jonkerj> but for subnodes needing phandles, I am going to stick to dts/dtb
<apritzel> jonkerj: sure, makes sense
<apritzel> as I said I only used it for hacking, so was OK with fixing up this one or two phandles
<jonkerj> would be great if someone patched my brain so I'd be able to do phandle resolving by heart
<jonkerj> yeah
dearfibonacci has quit [Quit: Leaving]
dearfibonacci has joined #linux-sunxi
<apritzel> can someone with a Windows box create a Windows IOT SDcard (following those instructions here: http://www.cnx-software.com/2016/08/04/allwinner-a64-based-pine-a64-and-banana-pi-m64-boards-can-now-run-windows-10-iot-core/) and dump the firmware part somewhere?
<apritzel> I am curious about the first few MB of such an image
<apritzel> reportedly it has some UEFI implementation
OverCR has quit [Quit: Leaving.]
<MoeIcenowy> apritzel: My PC have windows
<MoeIcenowy> (which I used to install win10iot on rpi2
<apritzel> MoeIcenowy: so you are volunteering? ;-)
<MoeIcenowy> maybe
havoc_ has joined #linux-sunxi
<MoeIcenowy> I may also update my Windows to RS1
<MoeIcenowy> but my network access is poor...
<apritzel> I did this PhoenixCard exercise once in a VM and can't be bothered anymore ;-)
<MoeIcenowy> my Windows is on real machine
<MoeIcenowy> my PC come with preloaded Windows 8
<apritzel> it did work with WindowsXP as a KVM guest and QEMU's USB device emulation, which is not bad
<MoeIcenowy> my PhoenixCard VM is also a XP.
<MoeIcenowy> but I used to experience the UEFI on RPI2
<apritzel> I was always wondering if ReactOS would work as a guest running PhoenixCard ...
<MoeIcenowy> it's a useless thing
<MoeIcenowy> except loading Win10IOT
<MoeIcenowy> It even have no Interface!!!
<apritzel> I was afraid of that, yes
<apritzel> well, if it picks up and loads an EFI image from the SD card
<apritzel> this could be a grub then as well
<MoeIcenowy> The RPI2 version of UEFI is not more useful than U-Boot UEFI
<MoeIcenowy> (I'm playing with U-Boot UEFI these days
<apritzel> didn't someone report a grub boot menu today ;-)
<MoeIcenowy> Maybe we should place a UEFI Shell there?
<MoeIcenowy> But the first thing for my is to download the ffu
<MoeIcenowy> 42.4 KB/s - 19.1 MB，共 1.0 GB，还剩 7 小时
<MoeIcenowy> 7 Hours left
<apritzel> remembers me of the times when I downloaded Quake from some dodgy FTP server over Christmas ;-)
<apritzel> but that was almost twenty years ago ...
<MoeIcenowy> I'm only using an ISP which have poor speed when accessing things out of China.
<MoeIcenowy> and I checked the MS Win IoT page
<MoeIcenowy> there's no page for A64
<MoeIcenowy> it's maybe the work by AW
<MoeIcenowy> apritzel: maybe we can implement some ACPI things in U-Boot?
<MoeIcenowy> (I'm thinking that you may want this kind of firmware interface
<apritzel> no, please don't use my name and "ACPI" on the same line!
<MoeIcenowy> ah-oh?!
<MoeIcenowy> what the hell
<MoeIcenowy> but as I know all the UEFIs running Windows NT kernel is with ACPI...
<apritzel> reportedly this was somehow faked for the ARM boards ;-)
<MoeIcenowy> apritzel: ?
<apritzel> but yes, WinNT seems to be married with ACPI since Win2K or so
<apritzel> ACPI is somewhat broken in general IMHO, and using it on ARM didn't improve this situation (more to the contrary, if you ask me)
<MoeIcenowy> as I know, Windows NT on ARM is highly using ACPI
<apritzel> is there actually Windows _NT_ on ARM?
<MoeIcenowy> RT 8.1。
<apritzel> aren't those Windows installations using a different kernel?
<MoeIcenowy> This person patched qemu and ovmf, and then run a Windows RT 8.1 on qemu
<apritzel> and /me was just wondering which board out there had useful ACPI tables ...
<apritzel> AFAIK there are some ARM64 server systems coming close to this
<MoeIcenowy> yes
<apritzel> but nothing for any kind of SBC - and especially ARM32
<apritzel> you would need some firmware clock implementation for that ;-)
<apritzel> nice link, btw
Mr__Anderson has joined #linux-sunxi
perr has quit [Remote host closed the connection]
cnxsoft has quit [Quit: cnxsoft]
dearfibonacci has quit [Quit: Leaving]
arossdotme has quit [Quit: Ex-Chat]
IgorPec has joined #linux-sunxi
afaerber has joined #linux-sunxi
reinforce has quit [Quit: Leaving.]
<MoeIcenowy> oh my download timed out
IgorPec has quit [Ping timeout: 260 seconds]
afaerber has quit [Ping timeout: 250 seconds]
afaerber has joined #linux-sunxi
premoboss has joined #linux-sunxi
mosterta has joined #linux-sunxi
mosterta has quit [Ping timeout: 265 seconds]
|Jeroen| has quit [Quit: dada]
<apritzel> MoeIcenowy: I downloaded it - can I put it somewhere where it's convenient for you to download?
<wens> afaik any connections across gfw are subject to artificially induced limits and delays
<apritzel> I was afraid so ...
JohnDoe_71Rus has joined #linux-sunxi
<wens> i can probably do it next week if i remember
OverCR has joined #linux-sunxi
<apritzel> wens: Allwinner should be able to put it somewhere inside, no?
<apritzel> (in the Chinternet, I mean)
<apritzel> (of course in addition to, not instead of the outside location)
Mr__Anderson has quit [Remote host closed the connection]
<sW`> apritzel: i was able to convert the .ffu with this https://github.com/t0x0/random/wiki/ffu2img
<sW`> however there is no MBR, so it can't be mounted
<apritzel> sW`: nice anyway
OverCR has quit [Client Quit]
foudubassan has quit [Remote host closed the connection]
<apritzel> though it just extracted 256KB :-(
<apritzel> which I don't debug now ...
Gerwin_J has joined #linux-sunxi
<KotCzarny> you can mount with -o offset=
montjoie has joined #linux-sunxi
Guest15887 is now known as corvusmalus
jernej has joined #linux-sunxi
TheLinuxBug has quit [Ping timeout: 258 seconds]
TheLinuxBug has joined #linux-sunxi
IgorPec has joined #linux-sunxi
BenG83 has joined #linux-sunxi
mosajjal has quit [Ping timeout: 250 seconds]
Nacho has quit [Ping timeout: 264 seconds]
Nacho has joined #linux-sunxi
IgorPec has quit [Ping timeout: 276 seconds]
premoboss has quit [Quit: Sto andando via]
Mr__Anderson has joined #linux-sunxi
Netlynx has joined #linux-sunxi
Netlynx has quit [Changing host]
Netlynx has joined #linux-sunxi
enrico_ has quit [Quit: Bye]
massi has quit [Remote host closed the connection]
iamfrankenstein has quit [Ping timeout: 244 seconds]
iamfrankenstein has joined #linux-sunxi
cosm has joined #linux-sunxi
apritzel has quit [Ping timeout: 244 seconds]
OverCR has joined #linux-sunxi
imcsk8 has quit [Read error: Connection reset by peer]
imcsk8 has joined #linux-sunxi
mosterta has joined #linux-sunxi
mosterta has quit [Ping timeout: 240 seconds]
Mr__Anderson has quit [Remote host closed the connection]
IgorPec has joined #linux-sunxi
ikmaak has quit [Ping timeout: 265 seconds]
ricardocrudo has quit [Remote host closed the connection]
lemonzest has quit [Quit: Leaving]
scream has joined #linux-sunxi
reinforce has joined #linux-sunxi
paulk-collins has quit [Quit: Leaving]
mosterta has joined #linux-sunxi
vagrantc has joined #linux-sunxi
matthias_bgg has quit [Quit: Leaving]
keh has joined #linux-sunxi
Warden has joined #linux-sunxi
Warden has quit [Client Quit]
foxx_ has quit [Ping timeout: 258 seconds]
IgorPec has quit [Ping timeout: 276 seconds]
scream has quit [Remote host closed the connection]
Netlynx has quit [Quit: Leaving]
Gerwin_J has quit [Quit: Gerwin_J]
<topi`> anybody with Orange PI hardware and the Xunlong camera module (gc2035 based)?
<topi`> I've been using an old 3.4 kernel on my OPi PC for the sole reason that it supports that $6 camera module and I can run motion there
<topi`> are there any efforts to get that camera module working on recent 4.x kernels?
<topi`> afaik there already is pretty decent H3 support in the just announced 4.7 kernel
vagrantc has quit [Quit: leaving]
Wizzup has quit [Read error: Connection reset by peer]
Wizzup has joined #linux-sunxi
reinforce has quit [Quit: Leaving.]
afaerber has quit [Quit: Ex-Chat]
apritzel has joined #linux-sunxi
Da_Coynul has joined #linux-sunxi
alexmarkley has joined #linux-sunxi
<jemk> apritzel: i haven't stress-tested it yet, but the register dump matches libdram in the relevant parts
<alexmarkley> hey all; i am following this guide http://linux-sunxi.org/Mainline_Kernel_Howto (and others on the wiki) to try and produce a bootable SD card for this device: https://www.olimex.com/Products/SOM/A13/A13-SOM-256/
<alexmarkley> i've gotten u-boot compiling/starting, and i have the kernel starting to boot okay
<alexmarkley> but it stops showing me anything on the serial port after "bootconsole [earlycon0] disabled"
JohnDoe_71Rus has quit [Quit: KVIrc 4.9.2 Aria http://www.kvirc.net/]
<alexmarkley> makes me think i am doing something wrong for my console= parameter
<jemk> alexmarkley: what devicetree do you use?
<alexmarkley> jemk: sun5i-a13-olinuxino-micro.dts
<alexmarkley> even the manufacturer (olimex) recommends using that in their walkthrough
<alexmarkley> even though it's not the same device, it's very similar
<jemk> should be ok then, some dts don't enable the uart, but this one does
<jemk> so with something like console=ttyS0,115200 it should work
<alexmarkley> jemk: it's so weird
<alexmarkley> i've definitely been trying that
<alexmarkley> i'm trying to build the ubuntu kernel 4.2.0
<alexmarkley> so i can track with ubuntu-trusty/lts-backport-wily
<alexmarkley> i'm not super-experienced with embedded linux development, but i haven't seen anything quite like this before
<alexmarkley> my kernel command line is: console=ttyS0,115200 earlyprintk root=/dev/mmcblk0p2 rootwait panic=10
<jemk> i don't know what else could be wrong, maybe you can paste the output somewhere
<alexmarkley> jemk: is it possible that i haven't properly enabled the correct uart driver in this kernel build?
<alexmarkley> i'm happy to paste it
<alexmarkley> like, "Serial: AMBA PL011 UART driver" ?
<alexmarkley> is that accurate?
<alexmarkley> this ubuntu kernel for armhf comes with a tubload of crap enabled that i don't want, and i had to enable support for allwinner SoCs
<alexmarkley> so not sure what other little gotchas may be hiding in make menuconfig
<jemk> CONFIG_SERIAL_8250_DW has to be enabled, i don't see any signs of that in your output
<alexmarkley> ok i will check for that
<alexmarkley> there's a good chance it's not
<alexmarkley> aha! jemk: it's set to M by default in the ubuntu kernel
<jemk> ouch
<alexmarkley> so that's not gonna work
<alexmarkley> thanks for the tip
<alexmarkley> i never would have guessed this
<jemk> i'd recommend to start with the sunxi_defconfig, otherwise you might miss other important things too
<alexmarkley> is there a sunxi-linux branch of 4.2?
<alexmarkley> or even 4.x ?
<alexmarkley> i guess i can look myself :-P
<jemk> no, only mainline
<alexmarkley> oh! there's a sunxi_defconfig in mainline
<alexmarkley> i see it now
<alexmarkley> nice
<alexmarkley> well thanks a ton, you saved me a lot of frustration there
<alexmarkley> i gotta run, but i will probably lurk in here some more tomorrow
<alexmarkley> cheers!
alexmarkley has quit []
tkaiser has joined #linux-sunxi
<tkaiser> ssvb: In case you've 10 minutes can you please look through the tinymembench numbers collected here: http://forum.armbian.com/index.php/topic/1748-sbc-consumptionperformance-comparisons/
<tkaiser> And tell me whether I've done something wrong?
tkaiser has quit [Client Quit]
Da_Coynul has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
<apritzel> jemk: Wow! seriously?
Da_Coynul has joined #linux-sunxi
<apritzel> how did you came up with this?
<apritzel> jemk: just tried H3 by chance and fixed stuff up?
<jemk> yes, dumped the registers and they looked very familiar
<apritzel> jemk: Thanks a ton anyway!
<apritzel> I am quite busy atm, but will give it a try ASAP
<apritzel> looks like time to push my other 64-bit and SPL fixes
<apritzel> which allow loading FIT images by the SPL
<apritzel> so U-Boot + ATF, for instance
<jemk> they should probably be squashed, but i didn't want to change your history in case you did new patches too
<apritzel> indeed, no worries, we can clean this up any time
<apritzel> you saved me quite some hours on my disassembly quest ...
<jemk> i'm in the progress of cleaning up the dram stuff anyways, there is more to come in the future
<apritzel> jemk: nice
<apritzel> jemk: if you are wondering about something, I can look things up in my de-compiled libdram
<jemk> a lot of the registers are documented in the xilinx zynq manuals, showing that aw took a lot of shortcuts here and there
<apritzel> why am I not surprised?
<apritzel> shortcuts that potentially hurt stability?
<apritzel> as I am pretty clueless in those things: can you tell apart LPDDR3 from 1.5V DDR3?
<apritzel> by probing?
<apritzel> or do you have to know beforehand?
<jemk> some might do, but most of the time they chose the safe (slow) side
Da_Coynul has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
cosm has quit [Ping timeout: 264 seconds]
<apritzel> safe & slow in terms of setup time only?
<jemk> don't know, normally you should know beforehand and set it in the config
mosterta has quit [Ping timeout: 244 seconds]
<jemk> dram timings are calculated inaccurate, often to high, but some also slightly too low
<apritzel> jemk: do you plan to fix this in your rework?
<jemk> i'll try, but that need real memtests, otherwise i might make it worse, maybe they had a reason
BenG83 has quit [Quit: Leaving]
<jemk> also the stability with the ddr3l boards not reaching 672mhz can be improved by fixing the delays, the controller can do training for that
<apritzel> that sounds promising
Da_Coynul has joined #linux-sunxi
jstein has quit [Ping timeout: 276 seconds]
Da_Coynul has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
popolon has quit [Quit: WeeChat 1.4]
Da_Coynul has joined #linux-sunxi