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
terra854 has quit [Ping timeout: 260 seconds]
cptG has quit [Ping timeout: 256 seconds]
terra854 has joined #linux-sunxi
atsampson has quit [Ping timeout: 256 seconds]
terra854 has quit [Ping timeout: 260 seconds]
terra854 has joined #linux-sunxi
mozzwald_ has joined #linux-sunxi
egbert has quit [Disconnected by services]
robogoat_ has joined #linux-sunxi
montjoie_ has joined #linux-sunxi
uwe__ has joined #linux-sunxi
egbert has joined #linux-sunxi
[Awaxx]_ has joined #linux-sunxi
vbmithr_ has joined #linux-sunxi
mozzwald has quit [Write error: Broken pipe]
vbmithr has quit [Write error: Broken pipe]
uwe_ has quit [Write error: Broken pipe]
Pietrelinux has quit [Remote host closed the connection]
robogoat has quit [Remote host closed the connection]
[Awaxx] has quit [Remote host closed the connection]
montjoie has quit [Remote host closed the connection]
legobane has joined #linux-sunxi
atsampson has joined #linux-sunxi
ruben-ikmaak has joined #linux-sunxi
speakman_ has joined #linux-sunxi
gaby has joined #linux-sunxi
ikmaak has quit [Ping timeout: 265 seconds]
speakman has quit [Ping timeout: 265 seconds]
gaby_ has quit [Ping timeout: 265 seconds]
atsampson has quit [Ping timeout: 260 seconds]
apritzel has quit [Ping timeout: 245 seconds]
book`_ has joined #linux-sunxi
topi`_ has joined #linux-sunxi
book` has quit [Ping timeout: 265 seconds]
lkcl has quit [Ping timeout: 265 seconds]
topi` has quit [Ping timeout: 265 seconds]
atsampson has joined #linux-sunxi
apritzel has joined #linux-sunxi
_whitelogger has joined #linux-sunxi
apritzel has quit [Ping timeout: 260 seconds]
ninolein has quit [Ping timeout: 245 seconds]
ninolein has joined #linux-sunxi
jonkerj_ has joined #linux-sunxi
egbert has quit [Disconnected by services]
egbert has joined #linux-sunxi
huawei has quit [Ping timeout: 268 seconds]
agraf has quit [Ping timeout: 268 seconds]
fest has quit [Ping timeout: 268 seconds]
willmore has quit [Ping timeout: 268 seconds]
qschulz has quit [Ping timeout: 268 seconds]
Xilokar has quit [Ping timeout: 268 seconds]
joedj has quit [Ping timeout: 268 seconds]
jonkerj has quit [Ping timeout: 268 seconds]
plaes has quit [Ping timeout: 268 seconds]
honx has quit [Ping timeout: 268 seconds]
mcan has quit [Ping timeout: 268 seconds]
honx has joined #linux-sunxi
agraf has joined #linux-sunxi
Xilokar has joined #linux-sunxi
zoobab has quit [Ping timeout: 268 seconds]
aballier has quit [Ping timeout: 268 seconds]
bbrezill1 has quit [Ping timeout: 268 seconds]
slapin has quit [Ping timeout: 268 seconds]
marvs has quit [Ping timeout: 268 seconds]
cyrozap has quit [Ping timeout: 268 seconds]
alexxy has quit [Ping timeout: 268 seconds]
zzeroo has quit [Ping timeout: 268 seconds]
plaes has joined #linux-sunxi
plaes has joined #linux-sunxi
plaes has quit [Changing host]
alexxy has joined #linux-sunxi
aballier has joined #linux-sunxi
marvs has joined #linux-sunxi
jstein has quit [Remote host closed the connection]
fest has joined #linux-sunxi
qschulz has joined #linux-sunxi
cyrozap has joined #linux-sunxi
yann-kaelig has quit [Quit: Leaving]
mcan has joined #linux-sunxi
huawei has joined #linux-sunxi
joedj has joined #linux-sunxi
slapin has joined #linux-sunxi
zoobab has joined #linux-sunxi
willmore has joined #linux-sunxi
bbrezill1 has joined #linux-sunxi
zzeroo has joined #linux-sunxi
cnxsoft has joined #linux-sunxi
willmore has quit [Ping timeout: 250 seconds]
legobane has quit [Quit: Leaving]
willmore has joined #linux-sunxi
cnxsoft has quit [Remote host closed the connection]
cnxsoft has joined #linux-sunxi
jrg has quit [Ping timeout: 276 seconds]
jrg has joined #linux-sunxi
<wens> wonder why there's no debian package for xf86-video-armsoc
<MoeIcenowy> wens: what's the difference between this driver and xf86-video-modesetting?
<wens> MoeIcenowy: supposedly you provide some hardware specifics so it works better
<vagrantc> wens: generally because nobody's bothered to package it
<wens> vagrantc: probably
<vagrantc> wens: or it overly duplicates the functionality of another package without providing a significant benefit ...
<wens> also discovered there's no de facto source... every SoC has their own forked version :/
<vagrantc> that also sounds like a reason
jrg has quit [Ping timeout: 244 seconds]
<MoeIcenowy> wens: a upstream seems to exist
<MoeIcenowy> but only have support for exynos, kirin, sti and pl111\
<wens> MoeIcenowy: right, except no one bothers to get their stuff integrated
<MoeIcenowy> yes
<MoeIcenowy> (will mripard want to merge sunxi guys to it?
<wens> MoeIcenowy: we don't have a driver for that i think
<MoeIcenowy> mripard's WIP on it
* vagrantc had put in a RFP (request for package) for fbturbo at some point, as it at least made use of neon
<wens> MoeIcenowy: really?
<wens> hadn't heard
jrg has joined #linux-sunxi
<wens> anyway i should complain in another channel, since it's not sunxi-related
<MoeIcenowy> fbturbo is really useful...
<MoeIcenowy> even on mainline kernels ;-)
<vagrantc> fwiw, someone recently adopted the fbturbo bug: https://bugs.debian.org/760025
<wens> but fbturbo is still fbdev based, no?
jrg has quit [Ping timeout: 260 seconds]
jrg_ has joined #linux-sunxi
<wens> vagrantc: just 2 weeks ago!
jrg_ is now known as jrg
lkcl has joined #linux-sunxi
<MoeIcenowy> wens: yes, but it's some enhance
<MoeIcenowy> although I think ssvb's version policy prevented fbturbo from being packaged... He said he won't tag
<wens> MoeIcenowy: that doesn't prevent package maintainers from just getting a snapshot of the tree
<MoeIcenowy> wens: yes I did it for my distro
<wens> mripard: fyi the t-mali kernel driver from arm has DT bindings
orly_owl has joined #linux-sunxi
terra854 has quit [Quit: Connection closed for inactivity]
pg12 has quit [Ping timeout: 260 seconds]
pg12 has joined #linux-sunxi
<MoeIcenowy> apritzel: The upper port of Pine64 works with sun8i-a33-musb!
<MoeIcenowy> oh too happy that I forgot to look at the member list...
IgorPec has joined #linux-sunxi
terra854 has joined #linux-sunxi
cnxsoft has quit [Remote host closed the connection]
cnxsoft has joined #linux-sunxi
Gerwin_J has joined #linux-sunxi
vagrantc has quit [Quit: leaving]
quinward has quit [Quit: WeeChat 1.5]
TheSeven has quit [Ping timeout: 256 seconds]
TheSeven has joined #linux-sunxi
<ganbold> montjoie_: can you share H3 PRNG related codes?
TheSeven has quit [Ping timeout: 260 seconds]
TheSeven has joined #linux-sunxi
merbanan has quit [Ping timeout: 252 seconds]
repka has joined #linux-sunxi
merbanan has joined #linux-sunxi
repka has quit [Quit: Leaving]
JohnDoe_71Rus has joined #linux-sunxi
IgorPec has quit [Ping timeout: 250 seconds]
<MoeIcenowy> finally I pushed my code to GitHub
<MoeIcenowy> My network connection sucks
juri_ has quit [Ping timeout: 252 seconds]
juri_ has joined #linux-sunxi
Gerwin_J has quit [Quit: Gerwin_J]
reinforce has joined #linux-sunxi
<montjoie_> gQnbold I will update the sun8i-ce-experimental branch
montjoie_ is now known as montjoie
<montjoie> ganbold: sorry
<ganbold> ok
reinforce has quit [Remote host closed the connection]
reinforce has joined #linux-sunxi
IgorPec has joined #linux-sunxi
massi has joined #linux-sunxi
matthias_bgg has joined #linux-sunxi
as0d70apf has joined #linux-sunxi
yann has quit [Ping timeout: 256 seconds]
Leepty has joined #linux-sunxi
gianMOD has joined #linux-sunxi
apritzel has joined #linux-sunxi
f0xx has joined #linux-sunxi
yann has joined #linux-sunxi
florianH has joined #linux-sunxi
Mr__Anderson has joined #linux-sunxi
Mr__Anderson has quit [Ping timeout: 260 seconds]
Mr__Anderson has joined #linux-sunxi
orly_owl has quit [Quit: leaving]
ruben-ikmaak is now known as ikmaak
apritzel has quit [Ping timeout: 265 seconds]
corecode has quit [Ping timeout: 256 seconds]
corecode has joined #linux-sunxi
repka has joined #linux-sunxi
gianMOD has quit [Remote host closed the connection]
IgorPec has quit [Ping timeout: 250 seconds]
gianMOD has joined #linux-sunxi
Worf has joined #linux-sunxi
repka has quit [Quit: Leaving]
bugzc has quit [Ping timeout: 256 seconds]
repka has joined #linux-sunxi
apritzel has joined #linux-sunxi
premoboss has joined #linux-sunxi
iaglium has quit [Quit: Bed Time]
Mr__Anderson has quit [Quit: Leaving.]
IgorPec has joined #linux-sunxi
<ssvb> MoeIcenowy: who said he won't tag?
<ssvb> what kind of story is that? and which distro you are talking about?
<apritzel> MoeIcenowy: I put a preliminary fix in my -v6 branch yesterday, also rebased to 4.9-rc2
<ssvb> Wizzup: probably somebody has removed the CONFIG_SYS_UBOOT_BASE option as a part of cleanup? It may look kinda redundant because the SPI support is not enabled by default, but you can find a way to set it to 0x8000
<apritzel> MoeIcenowy: but I see massive issues with MMC, I will try my fixes to your calibration routine (or go to the sun5i compatible) next
<Wizzup> ssvb: ok, so 0x8000 is the right value
<Wizzup> ssvb: As in, I enabled SPI NOR Flash booting, because that is what I want
<apritzel> ssvb: Wizzup: SPI flash compiles and works for me
<ssvb> Wizzup: yes, you could have checked it in the older U-Boot tree which was compiling successfully for you ;)
<apritzel> well, after a tiny fix
<Wizzup> so there should be some way to do that - currently it is not possible with next because of the error I mentioned
<Wizzup> ssvb: right, yeah.
<Wizzup> ssvb: I was also trying to get my head around the difference between support for booting from nor flash and support for loading linux/etc from nor flash, from u-boot
<Wizzup> apritzel: the next branch from u-boot?
<ssvb> we don't have SPI boot support enabled in U-Boot by default because the SPL size has become way too large
<Wizzup> I have a working version, which is basically ~7 months ago using ssvb's commit as head
<Wizzup> right
<apritzel> Wizzup: latest HEAD, something like 2016.11-rc2
<apritzel> ssvb: really? I don't see much of a difference
<Wizzup> apritzel: my HEAD is 55cdcdaad
<apritzel> ssvb: it's slightly above 20K for me, being padded to 24K
<ssvb> apritzel: you can check for people complaining about SPL going over the size limit in the U-Boot mailing list, that's a regular occurrence
rah has quit [Quit: reboot]
<ssvb> apritzel: sometimes when they just want to add a little bit of debugging output
<apritzel> Wizzup: my head is later than that
<Wizzup> there is no new commit on the next branc
<Wizzup> git://git.denx.de/u-boot-sunxi branch next
gianMOD has quit [Remote host closed the connection]
<apritzel> Wizzup: my experience is that these branches become stale after the merge window
<Wizzup> right
<Wizzup> so I should go to master
<apritzel> yup
<Wizzup> will try lime defconfig and add spi nor
<Wizzup> thx
<NiteHawk> ssvb: working towards sunxi-tools v1.4, i'm about to squash-merge https://github.com/linux-sunxi/sunxi-tools/pull/60 - objections? if you got time, i'd also like your thoughts on #62 and #63
<ssvb> apritzel: well, we can suggest enabling SPI boot support for every sunxi board (so that it's always at least compile tested)
gianMOD has joined #linux-sunxi
rah has joined #linux-sunxi
<ssvb> NiteHawk: about version, the current "version" command in sunxi-fel is a little bit ambiguous
<NiteHawk> ssvb: right. we have program "--version", and SoC "ver[sion]" :/
<ssvb> people may be confused about what is the difference between the "--version" option and the "version" command, but I'm not sure what's the best way to address it
<NiteHawk> maybe just support "-V" and not the long option?
<NiteHawk> we could also take an entirely different approach: all our programs need arguments, and will print a usage help if none are given. why not make the (program) version part of that output?
<ssvb> maybe add a new "info" command as an alias for "version"? and then try to gradually deprecate "version"? though there are way too many wiki pages which suggest using "sunxi-fel ver"
<ssvb> yes, it's a good idea to just print the version information as a part of the help message
<NiteHawk> no. i think "sunxi-fel ver" is there to stay
<Wizzup> apritzel: do you also load linux/initramfs from spi nor flash?
<NiteHawk> also saves us form the mixed argument handling (short vs. long option, with some program currently only supporting -V)
<apritzel> Wizzup: I did this once as part of a FIT image, so using the SPL SPI code
<Wizzup> right, so not loading the kernel from u-boot, when loading u-boot from spl
<apritzel> Wizzup: but atm there is no sunxi SPI flash in U-Boot _proper_
<Wizzup> I see
<apritzel> the SPL is loaded from SPI flash, which then loads U-Boot proper from there, normally
<apritzel> usually via a legacy U-Boot image
<Wizzup> What do you mean, via a legacy u-boot image?
<ssvb> NiteHawk: well, "version" was not a very good name for this particular command to begin with, but I guess we are stuck with it for historical reasons
Leepty has quit [Remote host closed the connection]
<Wizzup> What I am trying to achieve is: load spl from nor flash, load u-boot from nor flash (this currently works), and then load *linux* from the same nor flash, from u-boot
<apritzel> Wizzup: so this requires SPI flash support from U-Boot proper
<ssvb> apritzel: BTW, I've been experimenting with FIT loading since a very long time ago
<Wizzup> but you're saying something like CONFIG_SPI_FLASH doesn't work?
<Wizzup> apritzel: right
Leepty has joined #linux-sunxi
<apritzel> Wizzup: doesn't sound like rocket science, though
<apritzel> just that nobody has a big enough itch yet
<Wizzup> I'd be interested in working on it. Not very familiar with u-boot though
<NiteHawk> ssvb: yes, that's what i meant. it would mean a somewhat disruptive change to rename that command. "info" would actually be slightly more appropriate in fact
<apritzel> I support most of the stuff is already around
<ssvb> apritzel: it just needs some tweaks, but I'm mostly unhappy about a major SPL size increase
<ssvb> apritzel: taking it into use was never a big problem :-)
<Wizzup> apritzel: support or suppose?
<apritzel> Wizzup: right: suppose
<Wizzup> ok, I presume you mean out of tree code or patches?
<ssvb> NiteHawk: well, that's why I suggest to add the "info" command as an alias without removing "version"
<apritzel> ssvb: I extended the FIT support here: https://github.com/apritzel/u-boot/commits/pine64-spl-wip
<apritzel> nora
<apritzel> normally FIT support in SPL isn't overly useful
<apritzel> but with those patches I can load an arbitrary number of images into RAM
<apritzel> so not only the dtb and U-Boot proper
<apritzel> but also ATF, kernel, initrd, you name it ...
<apritzel> Wizzup: I guess you can use many things that are around already
<apritzel> like SPI NOR flash code
<ssvb> right, just the FEL boot becomes a little bit more tricky with FIT support
<apritzel> ssvb: agreed, but I usually break it down for that
<apritzel> but I agree that is spoils the uboot command
<apritzel> it*
<ssvb> I have experimented with some fixes for that
<apritzel> ssvb: to support FIT/fdt in sunxi_fel?
<NiteHawk> ssvb: ah, now I got you. that's a neat idea
<ssvb> but I need to bring this up to the U-Boot mailing list
<apritzel> ssvb: or to transparently load the FIT and let the SPL do the rest?
<Wizzup> apritzel: on master I still get the same error, CONFIG_SYS_UBOOT_BASE not defined - same commit head on master it seems
<Wizzup> what branch are you on?
<Wizzup> apritzel: wrt 'spi nor flash code' that is around, do you mean the spi nor flash code in u-boot, or external work?
<ssvb> apritzel: it needs either a little bit of rework of the FIT support in U-Boot, or a change of the way how FEL boot is working
popolon has joined #linux-sunxi
<ssvb> apritzel: I'm not very happy with either approach at the moment, but I guess I just need to post some RFC patches
<Wizzup> apritzel: I'm working with allwinner a20 devices btw
<apritzel> Wizzup: which is probably the reason, as I am on the Pine64/A64
<apritzel> my head is 68ff827ec74f
<ssvb> Wizzup: check Kconfig options, maybe it's there?
<Wizzup> ssvb: doesn't look like it. hardcoding it (as you said) does work, obviously
<Wizzup> apritzel: are you using the main git.denx.de u-boot repo? I don't have a commit with that hash, and I just pulled from master
<Wizzup> ssvb: it seems to be defined for a few boards, in include/configs/<board>.h
<apritzel> Wizzup: 2016.11-rc2 should work as well
* Wizzup is going to see if he's using the wrong repo, no such tag
<Wizzup> ah-- I was using u-boot-sunxi.git.
<apritzel> prepend a "v"
<Wizzup> no, I'm using u-boot-sunxi.git instead of u-boot.git
<Wizzup> let me fix that
<ssvb> Wizzup: oh, it's CONFIG_SYS_UBOOT_BASE and not CONFIG_SYS_SPI_U_BOOT_OFFS
<Wizzup> ssvb: it could be that I was using the wrong repo. :-( Let me check now
<ssvb> Wizzup: sorry, I thought it was a different constant, still you can track when things stopped working
<apritzel> Wizzup: are you using multiple "git remote"s? That works for me fine, so I can usually find any commits or tags regardless of their origin
<Wizzup> apritzel: right, but I apparently did a clone of the u-boot-sunxi at the start of 2016, and never properly moved/used the u-boot.git one
<Wizzup> sorry for that
<ssvb> Wizzup: I can try to check what's up with sunxi SPI boot support in the current U-Boot master branch later today
<Wizzup> ssvb: (sorry, I'm a bit slow) on u-boot.git master I indeed get the same problem.
<Wizzup> ssvb: That'd be cool. I'll hardcode the value and try it when I get home
<ssvb> NiteHawk: about your "--version" support patches for sunxi-fel, they add a new shell script and make the makefile a little bit more complicated
<ssvb> NiteHawk: not that it's a big problem, but building for Windows might become more complicated
<terra854> Hello everyone
<NiteHawk> ssvb: yes, that's the cost of "git describe". i still preferred that over just having a "static" version include - would you prefer the latter?
<Wizzup> apritzel: in the master version of u-boot, I see 'Legacy SPI Flash Interface support', with an option for winbond (w25....) chips. I have such a chip
<Wizzup> I'll see if that maybe just works.
<ssvb> Wizzup: the SPL SPI support code does not care about the flash chip type
<Wizzup> right, but I'm talking about the u-boot that will be loaded by the spl
<apritzel> Wizzup: but you need sunxi SPI support in U-Boot
<Wizzup> apritzel: hmm
<NiteHawk> ssvb: apart from that NextThingCo fork we don't really support Windows so far, or?
<apritzel> that's what I meant: you have SPI flash support, but are missing the low level Allwinner IP block support
<Wizzup> apritzel: are you talking about nand or nor flash? Or does that not matter? (your mention of block support made me think you're talking about NAND)
<apritzel> Wizzup: the SPI IP block I meant, so the hardware that drives the SPI pins
<Wizzup> ok
<Wizzup> so if I'd want to load linux from spi nor flash, I'd have to figure out how to add that, or attempt to load a fit image (containing u-boot,linux, etc) from spl?
<apritzel> loading linux or initrd from a SPI NOR flash in general should work in U-Boot, just not from sunxi, because there is not sunxi SPI driver
<ssvb> Wizzup: SPI flash can be read in a generic way (with 24-bit addressing only), but writing to flash, enabling protection or using 32-bit addressing may be flash chip specific
<apritzel> and for the FIT part you need more patches because the SPL FIT support is basic
<apritzel> Wizzup: I have some hackish patches in the above mentioned pine64-spl-wip branch
<FergusL> I'll dare to ask again here but has anyone tested the microphone input on pine64?
<apritzel> FergusL: not sure how many people use the legacy kernel here
<Wizzup> ssvb: well, I'd only need to read from flash, but judging from what apritzel says, you're talking about not requiring chip-specific support, right? (wrt reading)
Net147 has quit [Quit: Quit]
<ssvb> Wizzup: the whole point is that the BROM is reading the SPL part from the SPI flash in a generic way, then the SPL is doing more or less exactly the same to load the main U-Boot part
<Wizzup> right
<apritzel> Wizzup: the problem here is that the SPL code is SPL specific, to keep the precious SPL code size small
<ssvb> Wizzup: this "follow the BROM approach" is SPI flash chip type independent, because if you happen to have some fancy SPI flash chip which needs some special non-standard treatment, then the BROM would be unable to load the SPL part in the first place
kimberlime has joined #linux-sunxi
<kimberlime> hi
<kimberlime> Has anyone worked with bpi device driver?
<terra854> If I read this correctly, you guys are trying to flash the bootstrap code into the embedded SPI in the SoC right?
<ssvb> apritzel: yes, and the small code size comes as a nice bonus
<apritzel> argh, any systemd wizard around to hint me where to enable serial console getty?
<KotCzarny> just remove systemds
<apritzel> the webs say it should work(TM)
<KotCzarny> easier
<KotCzarny> and better and safer
<apritzel> KotCzarny: I usually do that (by using either Ubuntu 14.04 or Slackware)
<Wizzup> apritzel: I see
<kimberlime> I was using kernel 3.x and could use gpio_direction_output method, but in kernel 4.6.3, the kernel freezes when I used it
<apritzel> but I can't bring that argument to Ubuntu 16.04 users
<Wizzup> ssvb: makes sense, and then I guess it's not a sensible approach for u-boot to use the same approach, since you may want to read from the more 'special' flash chips as well, because u-boot can support that (whereas the brom, and by extension the spl) cannot
<KotCzarny> educate the users?
Net147 has joined #linux-sunxi
<apritzel> Wizzup: the point is: how would you end using SPI NOR if you haven't been loaded from it?
<apritzel> Wizzup: the whole idea of what ssvb and me are after is to load the whole firmware stack from NOR flash
<ssvb> apritzel: that's easy, you boot from the SD card and want to fetch board-specific information from the SPI NOR flash, such as the dtb name
<ssvb> apritzel: we can not just boot from the SPI flash, but also use it for storing board-specific information even when booting from some other media
<Wizzup> apritzel: so then we seem to have similar goals :)
<ssvb> apritzel: for example, this could be a good start - http://lists.denx.de/pipermail/u-boot/2016-June/256723.html
<apritzel> ssvb: yes, but I don't see a problem here: I think U-Boot supports all kind of fancy SPI NOR flash chips already, it just lacks the lower SPI layer on sunxi, right?
iaglium has joined #linux-sunxi
<apritzel> so it doesn't matter whether we use fairly generic SPI NOR commands or chip specific ones
<ssvb> yes, we just need an SPI driver for U-Boot
<ssvb> and then board maintainers will have to add the SPI chip information to the device tree
Colani1200 has joined #linux-sunxi
<apritzel> which becomes interesting in case of you header-attached SPI chips ...
<ssvb> the key difference is that a more complete U-Boot driver can also *write* to SPI flash, and this may be flash chip type specific
<apritzel> ssvb: ah, good point
<apritzel> but maybe there is config symbol defining r/o access only?
<apritzel> though we need write access eventually ...
<apritzel> for storing the U-boot env and possibly EFI variables or the like in there
<ssvb> well, in principle SPI flash supports commands for runtime autodetection, but it is still not bulletproof
<Wizzup> Has any work started on a spi driver for u-boot (for sunxi)? I could perhaps spare a few days the coming week to play around with it (not that I have a lot of experience)
<ssvb> we can always have the detailed SPI flash chip type information stored in the SPI flash itself, after all we can *read* it in a generic way :-)
<apritzel> MoeIcenowy: so just for confirmation: my a64-v6-wip tree boots into userland on the Pine64, but only with the sun5i-a13-mmc compatible string (so even for SD cards)
<Wizzup> ssvb: ha
<apritzel> Wizzup: as I mentioned earlier: shouldn't be too hard
<apritzel> you probably have a SPI framework to attach to
<apritzel> and other drivers to copy from
<Wizzup> As in - take from allwinner's original u-boot fork?
<apritzel> the sunxi technical part is either in the manual or in ssvb's SPL patches
<apritzel> Wizzup: what is that? ;-)
<Wizzup> right
<apritzel> please ignore that, also I think they don't support tha
<apritzel> t
<Wizzup> ok
<apritzel> so your best bet is to look at any existing SPI driver for another SoC
<apritzel> and take it from there by copying and adjusting that
<apritzel> afk...
<Colani1200> Hi guys, I ran into a problem with my A10 based MK802ii. I compiled a recent mainline kernel (4.9RC2), but there seems to be a problem with the default cpufreq driver ("Generic DT based").
<Colani1200> The system will start until this point:
<Colani1200> cpufreq: cpufreq_online: CPU0: Unlisted initial frequency changed to: 624000 KHz
<Colani1200> cpufreq: cpufreq_online: CPU0: Running at unlisted freq: 384000 KHz
<Colani1200> After that, it freezes.
<Colani1200> when I compile with a different cpufreq driver, it boots up fine, but I don't have anything in /sys/devices/system/cpu/cpu0/cpufreq/
<Colani1200> So I guess there is a bug in the DT based driver or the .dtb file? Any idea how to fix this?
<Wizzup> apritzel: presumably the driver in linux (drivers/spi/spi-sun4i.c) is useful as well. I'll see if I can ... do something
jbizcocho has joined #linux-sunxi
<Wizzup> may need to arrange a scope
<jbizcocho> Hello everyone
<jbizcocho> Is anybody there?
<jonkerj_> lots of anybodys here :-)
jonkerj_ is now known as jonkerj
<jbizcocho> My name is Javier Bizcocho, I am Lead Technology Engineer at Imagination Technologies. My message is related with the Optimus A80, I guess it could be applied for any A80 based board. We realized that the A80 is basically stuck with in 3.4 kernel, due basically the lack of support for the GPU drivers. We've seen that, Kernel 4.4 efectively supports most (maybe all) of the drivers for this platform but the GPU, for obvious rea
<jonkerj> your line terminated after 'obvious rea'
gianMOD has quit [Remote host closed the connection]
<jbizcocho> Internally we have the latest drivers for this board (including Vulkan), so we wanted to know whether the community will like if we make a deployment for this 4.4 Kernel.
<jbizcocho> It looks like the board not very well supported, not eve uboot, but we think this is a very good SoC, we wanted to have feedback from the community.
<KotCzarny> im not authoritative, but this community is about open source (and gpl)
<jbizcocho> I can imagine. For the moment the idea will be to release a binary blob.
<KotCzarny> freely redistributable?
<jbizcocho> We will to discuss the details, so please don't quote me on this yet. Our idea is to release the binary blobs completely for free, this means that it can be use freely to generate your favourite Linux distro
<wens> i guess if you have issues with open source drivers, such as restrictive IP licenses or NDAs, you could follow what nVidia and ARM have been doing
apritzel has quit [Ping timeout: 245 seconds]
<jbizcocho> But we want to have proper feedback, to know whether the effort from our side will be used. If it's not worth it for the community we will keep it as now, just for internal purposes
<jbrown> jbizcocho: how about open-sourcing it? :-)
<jbizcocho> We want to help SunXi community to resurrect A80, be strongly believe is a very nice and reliable SoC, and the PowerVR GPU is quite decent.
<wens> jbizcocho: personally i think it is quite nice, and the effort would be appreciated
<jbizcocho> Despite my personal efforts, right now it will be just a close binary. I am personally an opensource guy, so don't worry we are making pressure from inside, but as I mention, for the moment it will be closed.
<wens> jbizcocho: i myself have 2 a80 boards that i work on
<KotCzarny> how about open source interface that wouldnt be stuck on particular kernel version?
<jbizcocho> This update will provide access to the latest version of the drivers, Vulkan included
<wens> jbizcocho: however given the higher price point of the a80, and the limited production run by allwinner, i don't think that many people have it :(
<jbrown> jbizcocho: well, don't forget to leave the debugging symbols in. Heheheh. (J/K!)
<jbizcocho> That is a nice idea <KotCzarny>, but let's gonna go one step at a time.
<wens> jbrown: that would probably lead to an insanely large blob lol
<KotCzarny> and while at it, make it universal, so one day it can drive older/newer chips too (i would love mainline for sgx530 :)
<ssvb> jbizcocho: what about GPU drivers for A31?
<jbizcocho> It's possible for the community, to put together a sensible guide to generate a complete guideline to generate an image for the A80?
<jbizcocho> ssvb: as I mention, one step at a time. Right now we would like to make a "proof of concept with A80"
<plaes> A31 would be faster
<jbizcocho> Not neccesarily
<ssvb> I think that A80 is pretty much unpopular because it was an expensive piece of hardware and was not very competitive with ODROID boards
<wens> it seems those ODROID boards have their own set of problems?
<wens> jbizcocho: A31 already has decent mainline support, with basic DRM/KMS going in the next release
<wens> (and probably audio)
<ssvb> well, nothing is perfect
<oliv3r_> Hi all!
<oliv3r_> ssvb: speak for yourself! You know I am :p
<oliv3r_> jk jk
<jbizcocho> For us A80 is already working, any SGX will take considerable bigger effort to make it possible
Putti has joined #linux-sunxi
<ssvb> still I believe that there are probably a lot more users having A31 hardware
<oliv3r_> jbizcocho: where does the A80 intrest come from? What i'm reading above is, that very few people actually have the A80
<jbizcocho> As I mention, If people like our drop from A80, It will be easier to consider other platforms
<jbrown> it seems to be (largely as an outsider in these matters) that it's a nice gesture, but it's "giving a man a fish"
<jbizcocho> A80 contains a later PowerVR GPU with newer technology and better performance Series 6, compared to SGX which is already outdated
<jbrown> as such, it's largely irrelevant
<jelle> jbrown: but it's closed source++ :)
<jelle> err jbizcocho
<oliv3r_> jbizcocho: I'm just thinking about the effort to adding docs/support etc, for a handfull of users if at that
<jbrown> also, it's more or less asking the community to do a pile of work for free
<jbrown> that won't be me, and maybe people are willing to do that, but don't count on it?
<plaes> jbizcocho: if SGX is outdated, then why not publish manuals and do the open source code drop?
<ssvb> jbizcocho: BTW, are you and your colleagues aware that there was PowerVR SGX DDK source code leak from LG some time ago?
DullTube has joined #linux-sunxi
<wens> plaes: IP license restrictions and stuff probably still apply?
<jbizcocho> I am sorry, that decision is not up to me.
<plaes> wens: not my problem :)
<wens> plaes: plus if it's outdated, it's probably not worth the effort to get stuff probably open sourced (filtering out proprietary stuff)
<ssvb> jbizcocho: of course, nobody could legally use these leaked sources, so they are worthless or even harmful for the open source community
<jbizcocho> Yes we are aware about LG leak
<plaes> also, MIPS platform will be dead soon, due to RISC-V adoption
<ssvb> I just wonder, wouldn't it be a good idea to just release these leaked sources officially with an appropriate open source license of your choice and let the open source community use them?
<plaes> yup ^^ :)
<oliv3r_> jbizcocho: so if i may be so bold to rephrase your question; You are asking if some of the community members have interest to write a 'getting started with mainline a80' documents' to help with PowerVR integration initially, and later add powerVR integration in the document?
oliv3r_ is now known as oliv3r
<wens> such a thing probably won't happen for another 6 months
<oliv3r> i guess one counter question could be 'whats in it for us' :)
<plaes> jbizcocho: limited manpower, limited number of A80 boards (which are also quite expensive)
<oliv3r> plaes: which brings up my question 'whats in it for us'. and i'm not talking about getting a80 boards
<plaes> indeed
<oliv3r> 'binary blobbed powervr support for a80!!1111' sounds neat, but not really 'for us' interesting i guess
<plaes> :D
<KotCzarny> unless at least partially its open sourced so it can be updated with kernel version
<plaes> yeah, when it's only for 4.4 then...
* jbrown had my experience with PowerVR binary blobs, and trying to get help with shitty bugged hardware from TI. Never again! :-p.
<jbrown> I imagine other people had similar experiences.
<ssvb> well, PowerVR blobs are (or were?) much worse than Mali blobs because even the DDX part is proprietary, and being tied to some specific version of Xorg is just awful
<ssvb> not to mention that 2D performance and reliability of proprietary drivers leaves a lot to be desired
apritzel has joined #linux-sunxi
<ssvb> who cares about a lot of FPS with just a single rotating horse demo if x11 desktop applications become sluggish?
<jbizcocho> There is a few things that I wanted to clarify
<jbizcocho> The guideline is just an idea that we give to the community. Generate an image for any platform is quite laborius and it requires experience. For our point of view it doesn't matter.
<jbizcocho> The kernel side of the drivers have been always opensource, so for any kernel 4.x it could be easy to recompile. Most of our drivers run on user-mode
<ssvb> BTW, do these drivers support full fledged OpenGL or OpenGL ES?
<jbizcocho> I just mentioned 4.4 because it happens to have also support for other drivers for the optimus
<jbizcocho> OpenGL ES and Vulkan
<jbrown> AFAIK there's essentially no open-source software that uses GLES
<jbrown> other than some stuff people ported to the OpenPandora, e.g.
<jbizcocho> Is a good moment to move to Vukan ;)
<ssvb> yeah, there is no software to run on these drivers
<jbrown> there's hardly any intersection between people who want to write OS software and people who want to do graphics stuff
<jbrown> so -- the level of interest isn't likely to be high.
<jbrown> Just IMO.
<jbrown> full OpenGL -- as a way of using ARM-based devices as something other than disposable toys, might be more interesting
<ssvb> I remember that Imagination Technologies promised full OpenGL drivers for years, but apparently never delivered
<wens> chrome seems to want gpus these days :/
<jbizcocho> Ok, thank you for your feedback guys.
<jbrown> ahh, I didn't consider that. Yeah.
<jbrown> jbizcocho: don't take anything I say too seriously btw :-). I have no horse in this race.
<wens> jbizcocho: about a80 mainline support, it is ongoing, but don't expect much progress, as it's mostly just me in my spare time
<MoeIcenowy> apritzel: eMMC with sun5i-a13-mmc also work?
<jbizcocho> Ok, no problem, thanks!
jbizcocho has quit [Quit: Page closed]
<apritzel> MoeIcenowy: I think it didn't work, but let me recheck the very same image on the BPi ...
<apritzel> (after lunch, that is ..)
<MoeIcenowy> and have you seen my branch?
<MoeIcenowy> I got also the upper port work with musb
repka has quit [Quit: Leaving]
<ssvb> MoeIcenowy: while you are here, could you please explain what is your problem with fbturbo?
<MoeIcenowy> ssvb: you have never tagged any stable version of fbturbo...
apritzel has quit [Ping timeout: 250 seconds]
mpmc has quit [Ping timeout: 256 seconds]
<MoeIcenowy> ah-oh I didn't see it...
<MoeIcenowy> sorry
<ssvb> well, it was 2 years ago and there are the whole 7 (!) commits in the master branch after that
<KotCzarny> :)
<KotCzarny> the best thing is that it works
<KotCzarny> and does what's advertised
<Wizzup> would it be possible for say, olimex, to fuse a different BROM with a different boot priority
<Wizzup> or is that something only allwinner can do
<Wizzup> I presume the latter
<ssvb> I probably should make a new release tag, because there are some bugfixes and also to make people feel that it is "actively" maintained
<KotCzarny> ssvb, please find some for emulating yuv!
<KotCzarny> :)
<KotCzarny> *some time
<MoeIcenowy> KotCzarny: fbturbo is only an enhanced fbdev, and I don't think it's the work of a fbdev driver
pekka10 has quit [Ping timeout: 256 seconds]
<ssvb> MoeIcenowy: it makes a lot of sense to have software emulated Xv support in general
mpmc has joined #linux-sunxi
<ssvb> it does not have much practical value on the sunxi platform though, because it's best to use hardware acceleration for this
<KotCzarny> that is, assuming there is hardware acceleration support
<ssvb> the hardware supports it :)
<wens> the display pipeline does support compositing a YUV buffer
<wens> it's not supported in the kms driver yet
<KotCzarny> how about new codecs not existing in ve ?
<wens> KotCzarny: software decoding?
<KotCzarny> yup
<wens> that's a separate issue
<KotCzarny> but on my bpim1 (mainline), video decoding takes much less than drawing on screen
<KotCzarny> (im not using cedrus)
<plaes> :D
<KotCzarny> its a bit better with x and fbturbo, but still
<wens> so i guess the question is how much work would it take to get Xv support to xf86-video-modesetting or xf86-video-armsoc
<ssvb> xf86-video-modesetting is dead
<MoeIcenowy> ssvb: nope, it's merged into the server itselt
<MoeIcenowy> itself
<wens> what?
<ssvb> it is being integrated into the X server, to make a single monolithic thing
<wens> oh
<ssvb> MoeIcenowy: yes, that's exactly what I'm tellin you :-)
<MoeIcenowy> Is there anyone using an exynos?
premoboss has quit [Ping timeout: 250 seconds]
<MoeIcenowy> or a hikey?
<MoeIcenowy> I think these two SoCs' armsoc driver may have Xv/
<MoeIcenowy> Exynos have even a G2D.
<Wizzup> I don't think there is working g2d for exynos atm
<MoeIcenowy> at least there's a driver for it in mainline kernel
<MoeIcenowy> a v4l2 driver
<ssvb> there is no software which can make use of it
<ssvb> it may be useful for compositing, but there are not APIs to hook it somewhere in the GNU/Linux software stack
<ssvb> Android is another story
<jbrown> does the Linux stuff on Steam generally want full OpenGL?
<buZz> yes
<jbrown> irrelevant on ARM I guess.
<buZz> steam doesnt work on ARM without exagear
<buZz> or wine
<jbrown> aha
<jbrown> ok.
<MoeIcenowy> the first problem is a ARM Linux-capable game engine ;-)
<buZz> just cause its available for linux, does not make it opensource
<MoeIcenowy> and the CPU performance
<buZz> MoeIcenowy: quite a couple exist
<jbrown> I didn't know about exagear
<jbrown> interesting.
<buZz> that -are- opensource, and work either with glshim or native in opengl-es
pekka10 has joined #linux-sunxi
<MoeIcenowy> glshim... only a half GL1...
<ssvb> AFAIK the only 2D acceleration API in Linux is X11 RENDER extension, but it's rather hard to implement it efficiently in drivers and it's getting deprecated in the long run
<MoeIcenowy> The only program I succeeded to run with glshim is glxgears
<ssvb> and then we have OpenGL ES, OpenGL and Vulkan
<wens> because everyone (TM) is doing GPU based compositing these days?
<MoeIcenowy> https://github.com/tobiasjakobi/xf86-video-armsoc here's someone working on g2d armsoc
<ssvb> MoeIcenowy: a lot of old 3D games work with glshim
<MoeIcenowy> ssvb: ah-oh
jonkerj_ has joined #linux-sunxi
vishnup has joined #linux-sunxi
<KotCzarny> it would be enough if some decent console emulator worked
<KotCzarny> insta game machine
<ssvb> MoeIcenowy: the g2d armsoc is most likely much slower than software rendering
<MoeIcenowy> ah-oh
gianMOD has joined #linux-sunxi
<ssvb> because it's very hard to to implement hardware acceleration in a way that it improves performance
<MoeIcenowy> I do not know well about graphics...
petr has quit [Ping timeout: 250 seconds]
petr has joined #linux-sunxi
mnemoc has joined #linux-sunxi
Jacmet_ has joined #linux-sunxi
rtp_ has joined #linux-sunxi
Uninstall_ has joined #linux-sunxi
zumbi_ has joined #linux-sunxi
diego71_ has joined #linux-sunxi
[Awaxx] has joined #linux-sunxi
[Awaxx] has quit [Changing host]
[Awaxx] has joined #linux-sunxi
p_rossak_ has joined #linux-sunxi
vishnup has quit [Ping timeout: 252 seconds]
hp197 has joined #linux-sunxi
gianMOD has quit [Ping timeout: 250 seconds]
vishnup has joined #linux-sunxi
iaglium_ has joined #linux-sunxi
bsdfox_ has joined #linux-sunxi
bsdfox_ has joined #linux-sunxi
bsdfox_ has quit [Changing host]
fire219_ has joined #linux-sunxi
valkyr1e_ has joined #linux-sunxi
iaglium has quit [*.net *.split]
lkcl has quit [*.net *.split]
jonkerj has quit [*.net *.split]
p_rossak has quit [*.net *.split]
[Awaxx]_ has quit [*.net *.split]
valkyr1e has quit [*.net *.split]
Uninstall has quit [*.net *.split]
fire219 has quit [*.net *.split]
_hp197 has quit [*.net *.split]
menomc has quit [*.net *.split]
Jacmet has quit [*.net *.split]
cajg has quit [*.net *.split]
diego71 has quit [*.net *.split]
bobryan has quit [*.net *.split]
zumbi has quit [*.net *.split]
FergusL has quit [*.net *.split]
rtp has quit [*.net *.split]
hramrach has quit [*.net *.split]
bsdfox_ is now known as bobryan
vishnup has quit [Ping timeout: 256 seconds]
vishnup has joined #linux-sunxi
cajg has joined #linux-sunxi
hramrach has joined #linux-sunxi
lkcl has joined #linux-sunxi
rtp_ is now known as rtp
<ssvb> NiteHawk: did you remove the boot.scr usage documentation on purpose or was it a mistake? https://linux-sunxi.org/index.php?title=FEL/USBBoot&curid=219&diff=18374&oldid=17155
gianMOD has joined #linux-sunxi
<NiteHawk> ssvb: ouch, that was a mistake of course :( the intent was to append the new information - i'll fix that!
DullTube has quit [Quit: Leaving]
<NiteHawk> thx for pointing that out
<ssvb> np
repka has joined #linux-sunxi
<NiteHawk> ssvb: i've reworked https://github.com/linux-sunxi/sunxi-tools/pull/62 . are you okay with #63 (license renaming and change to markdown)?
paulk-collins has joined #linux-sunxi
Gerwin_J has joined #linux-sunxi
vishnup has quit [Ping timeout: 256 seconds]
vishnup has joined #linux-sunxi
reinforce has quit [Quit: Leaving.]
fabo has quit [Read error: Connection reset by peer]
vishnup has quit [Ping timeout: 276 seconds]
vishnup has joined #linux-sunxi
Jacmet_ is now known as Jacmet
apritzel has joined #linux-sunxi
afaerber has quit [Quit: Ex-Chat]
JohnDoe_71Rus has quit [Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org]
<apritzel> MoeIcenowy: so the SD card works with sun5i-a13-mmc, but not the eMMC
<apritzel> and neither of them work with sun50i-a64-mmc
<oliv3r> Oh btw, now that it's no longer a secret
<oliv3r> the Ultimaker 3 was released last week feat. an Olimex Lime2-eMMC
<oliv3r> (running on a very outdated mainline kernel, but fixin' that in the next few weeks)
vishnup has quit [Ping timeout: 250 seconds]
aballier has quit [Quit: leaving]
vishnup has joined #linux-sunxi
aballier has joined #linux-sunxi
Worf has quit [Quit: Konversation terminated!]
<apritzel> MoeIcenowy: and: fixing your calibration routine helps as well for the SD card: it now runs with sun50i-a64-mmc
<apritzel> MoeIcenowy: but copying the BSP kernel behaviour and setting the delay to 0
<apritzel> for anything below HS200, that is
<MoeIcenowy> just set it to 0... WHAT THE HELL...
<apritzel> which is everything that the driver supports so far, anyway
<MoeIcenowy> I think the delay is 0 for all non-DDR modes
<apritzel> apparently the delays are only needed for higher modes
<MoeIcenowy> as "sample" clock is not meaningful for non-DDR
<apritzel> yes ;-)
<MoeIcenowy> and at that time sun50i-a64-mmc works just like sun5i-a13-mmc
<apritzel> indeed
<apritzel> so I was wondering if that calibration routines is useful at all - at least for now
<MoeIcenowy> but what should we do for up HS200?
<MoeIcenowy> apritzel: there's another possibility
<apritzel> so I have some patches
<MoeIcenowy> the values in allwinner's dt is pre-calibrated
<apritzel> which define clock delays for sun50i as well
<MoeIcenowy> the calibration routines is only internally used by Allwinner
<apritzel> and are all set to 0 for now
<apritzel> MoeIcenowy: so you think it's not meant for public consumption
<apritzel> ?
<MoeIcenowy> I don't know the reality
<apritzel> still weird
<MoeIcenowy> It's only my guess
<apritzel> I will push my patch on top of my repo
<apritzel> if you are OK with it, I send it to the list
<MoeIcenowy> I will look at them...
<MoeIcenowy> and I think the upper USB controller become a problem now
<MoeIcenowy> or we'd say "another problem"
<MoeIcenowy> Currently the problem is that, we have two solutions,
<MoeIcenowy> one is use the HCI pair, another is use MUSB
<MoeIcenowy> my ice-a64-v6 branch uses MUSB
<MoeIcenowy> which needs only a bugfix in phy-sun4i-usb and a dt work
<MoeIcenowy> but the controller itself is not so stable...
<apritzel> that was what my understanding: HCI is preferred over MUSB host mode
<MoeIcenowy> yes
<MoeIcenowy> but my original implementation used a parameter in phy to indicate the mode
<MoeIcenowy> (Hans want the capbility to switch to gadget mode runtime
<apritzel> I think we should put all controllers into the .dtsi
<MoeIcenowy> (but the mode switch is in musb, and the otg route switch is in phy
<apritzel> and let the board (or the boot loader/user?) decide
<apritzel> great
<MoeIcenowy> yes it's a way
<MoeIcenowy> but I think we make the bootloader do a lot ;-)
<apritzel> so for the Pine64 for instance we could go ahead with fixing it to HCI
<apritzel> because it's an A socket
<MoeIcenowy> but we should also have a overlay that set it to MUSB
<apritzel> exactly
<MoeIcenowy> as you can also use A-A cables
<apritzel> my thinking
<MoeIcenowy> (although my A-A cable failed to work on my Pine64
<apritzel> but the default case should be HCI because that's what people expect
<wens> MoeIcenowy: it should be doable, since musb and the phy driver are already calling each other :p
<apritzel> MoeIcenowy: mmh, mine worked
<MoeIcenowy> musb have also host mode ;-)
<MoeIcenowy> although not as stable as hci
<apritzel> for the BPI-M64 the situation is quite different: the "upper" port is really a microB
<apritzel> so the board .dts should default to use OTG
afaerber has joined #linux-sunxi
<MoeIcenowy> oh this time the A-A cable works
<MoeIcenowy> mysterious
<MoeIcenowy> apritzel: I think your method can work
<MoeIcenowy> we can have defaultly the phy on Pine64 specified to use HCI
<apritzel> does Pine64 actually advertise USB OTG for the Pine64 board?
<MoeIcenowy> apritzel: nope
<MoeIcenowy> but we're always using not-advertised functions
<MoeIcenowy> Pine64 didn't also advertise it can run mainline kernel ;-)
<MoeIcenowy> can a device tree overlay delete a property?
<apritzel> MoeIcenowy: no question about that for hacking reasons, but for the default we could just go with a common expectation
<MoeIcenowy> (on my v1 patch, the HCI controller is routed when "allwinner,otg-routed" property is specified in phy)
<wens> MoeIcenowy: grep for /delete in the dts directory
<wens> surely someone uses
<wens> * it
<MoeIcenowy> and according to your thoughts the Pine64 dts should have the property set, usb_otg disabled, {o,e}hci0 okay
<MoeIcenowy> wens: but they're not overlays
<MoeIcenowy> we won't provide two DTs for the same board to use different functions
afaerber has quit [Ping timeout: 256 seconds]
afaerber has joined #linux-sunxi
<MoeIcenowy> oh A64 DMA is different from A33...
<MoeIcenowy> added some registers
<MoeIcenowy> for TrustZone.
cnxsoft has quit [Quit: cnxsoft]
<oliv3r> i think i do
repka has quit [Quit: Leaving]
<oliv3r> MoeIcenowy: http://sprunge.us/YRBV this is how we used to do it for the PHY that we force into host mode
<oliv3r> and because we had to force the phy into host mode, the gpio's had to be deleted
<MoeIcenowy> oliv3r: the problem is that
whaf has quit [Ping timeout: 260 seconds]
<MoeIcenowy> on A64 we have two controllers to deal with OTG host
<oliv3r> ah :S
<apritzel> MoeIcenowy: needs to be cleaned up a bit, but you should get the idea: https://github.com/apritzel/linux/commit/d51db191c17ffa81974b3221ba2a2e8e094a41e9
<oliv3r> if i download an armbian 3.4 based image; how easy is it to use mainline u-boot with it?
<MoeIcenowy> apritzel: thx
<KotCzarny> oliv3r: plug'n'play
<apritzel> MoeIcenowy: I wonder if we should extend the MUSB driver to actually use the HCI driver when one tries to switch a sun50i-a64 MUSB into host mode?
<KotCzarny> and i think armbian uses mainline uboot on legacy images too
<oliv3r> nice; though I just realized; i have to change the fex file to get LCD working anyway
<apritzel> so the actual MUSB host mode would never be used
<KotCzarny> or in another words, mainline uboot can boot both kernels (legacy and mainline)
<oliv3r> KotCzarny: perfect; thanks
yann-kaelig has joined #linux-sunxi
<KotCzarny> the only gotcha would be situation where mainline uboot dont support particular soc/board and vendor one is needed
<oliv3r> this is lime2; so easy in that regard
<KotCzarny> yup
<oliv3r> just gotta remember how to hack together a LCD enabled fex file :)
<KotCzarny> you can even have both kernel configs in .env or .scr and select on presence of some dummy file
vishnup has quit [Read error: Connection reset by peer]
<KotCzarny> i had planned to make it selectable on gpio button, but at the time i was playing with it there was no gpio support for h3 in uboot
<wens> apritzel: isn't the id pin and mode setting stuff handled by the phy driver?
apritzel has quit [Ping timeout: 260 seconds]
nove has joined #linux-sunxi
whaf has joined #linux-sunxi
tkaiser has joined #linux-sunxi
<tkaiser> oliv3r: With Armbian you end up with an outdated Allwinner u-boot when trying to boot from NAND with legacy kernel. Otherwise it's mainline (2016.09 for almost all sunxi boards). Regarding fex settings for LCD simply look into Olimex examples/images.
<plaes> oliv3r: actually, there's code for mainline drm for lime2
<tkaiser> MoeIcenowy: apritzel: I doubt any Pine64 user will ever want to use gadget mode since no one knows what this is, what and where an OTG port is and where to buy the appropriate cable. But for BPi M64 or NanoPi A64 that's different though
<oliv3r> tkaiser: welcome! yeah looking into it already
<oliv3r> tkaiser: i got a nice 10" lcd wiht a lime2 that i'm going to use as my initial/reference board to build images for
<oliv3r> tkaiser: i was thinking u-boot because of /dev/fb0 but i think the 3.4 will need fex settings anyway
<oliv3r> but since i want to run limatester i'll need 3.4 anyway
<tkaiser> oliv3r: With 3.4 it's fex, yes. IIRC Olimex ships with a script in /root that does the necessary changes (exchanging script.bin or only the relevant lines, don't remember since the experience with their Debian image was a bit scary)
<oliv3r> tkaiser: i'm using armbian though :)
<wens> plaes: did you send out patches for it yet?
<tkaiser> oliv3r: since you mention lima-memtester: In Armbian we switched all DRAM settings back to 384 MHz since this is what Olimex themselve are actually using even on Lime2
<plaes> wens: nope, I haven't fully figured out how it works without u-boot
gianMOD has quit [Remote host closed the connection]
<oliv3r> tkaiser: yes and they even recommend their industrial customers to go with 384
<oliv3r> but both numbers are pulled out of dark rectums i think :)
<plaes> wens: though - do you mind if I send rfc-v2 ?
<oliv3r> 384 was like the lowest anybody uses so should be safe
<oliv3r> and 480 was like 'oh this works, so that's good'
<oliv3r> i want to make 480 crash with lima-tester
<oliv3r> and then see where lima tester runs sane
<oliv3r> and going to do that on a bunch of boards
<tkaiser> oliv3r: Good idea but I doubt we'll ever go away from 384 MHz -- wasted too much time with this (especially given those insane 480 MHz came from Olimex, was never corrected while they internally switched back to 384 MHz)
<wens> plaes: what do you mean? it should fully work without. if not then you're probably missing a clock or regulator
<oliv3r> tkaiser: i don't even think they supplied the 480 did they?
<plaes> well, my patchset was for LVDS
<oliv3r> tkaiser: anyhow, we want to have sane and stable u-boot configs in mainline u-boot
<wens> plaes: right
<wens> i think the bpi lcd has lvds, so i could probably test it
gianMOD has joined #linux-sunxi
gianMOD_ has joined #linux-sunxi
gianMOD has quit [Read error: Connection reset by peer]
<nove> only now looking at the contents of tinalinux repository, and first thing to notice is that isn't anymore called "cedarx" but now is by the name of "cedarc", https://github.com/tinalinux/package/tree/r16-v2.1.y/allwinner/liballwinner/LIBRARY/libcedarc, but the same never ending changing api for each versions, and no license
<oliv3r> what is tinalinux?
<tkaiser> oliv3r: The 480 MHz came from Olimex, ssvb started a discussion with Tsvetan and asked whether they want to adjust that since they're known to cause instabilities but to no avail. But currently we have the same situation with H3 boards. OPi PC got 624 MHz DRAM clock based on community testing while other H3 devices start with 672 MHz for no real reason.
<tkaiser> oliv3r: See link above ;)
<tkaiser> oliv3r: It's a sexy mixture of u-boot 2011.09, kernel 3.4.39, some Android and outdated OpenWRT stuff. Made for the internet of sh*t.
<KotCzarny> tkaiser: reason being 'it works on many boards, the rest? oh well'
<oliv3r> tkaiser: well i'll run some tests to see wether 480 is stable (it is not) and then send a patch (with evidence) to get it sorted in mainline u-boot
<oliv3r> if people wanna overclock their dram to get stuff done; fine, but the default in u-boot should be stable imo
<KotCzarny> yup, oc is for end users (and maybe seller's 'premium' tested boards, he he)
<ssvb> tkaiser: well, we are not sure if the original patch submitter was an Olimex employee, but there was an Olimex blog post claiming 533-something MHz and Olimex had been asked directly a few times whether 480MHz is really what they want to have in the mainline U-Boot
<KotCzarny> as is the case with x86 cpus/gpus
<oliv3r> ssvb: but they don't even recommend it to their own customers
<KotCzarny> who has time/manpower to carefully test hundreds of boards?
<ssvb> tkaiser: about the DRAM clock speed limit, with some parameters tuning I had my Cubietruck (Allwinner A20) clocking DRAM at 648MHz and passing stress tests with these settings
<tkaiser> ssvb: oliv3r: LOL: https://patchwork.ozlabs.org/patch/680990/
<oliv3r> tkaiser: again, ass pulling numbers; atleast it's a sane default
<ssvb> oliv3r: well, they could have said that in the mainline U-Boot mailing list too, but they opted to ignore the question (like it's kinda none of their business?)
<oliv3r> ssvb: bad rep?
<oliv3r> tkaiser: ironically, this is just around the time when i complained to olimex about the timings
vishnup has joined #linux-sunxi
<ssvb> another suspicious thing about Olimex boards is that they keep changing the ZQ resistors in different board revisions
gaby has quit [Quit: leaving]
<plaes> ouch
<ssvb> I also tried to ask about this, but was ignored again
gaby has joined #linux-sunxi
<oliv3r> ssvb: if you can get me up to speed
<oliv3r> i can ask them
<terra854> Hey guys, have you ever tried to compile a kernel with the -O3 flag enabled?
<oliv3r> ssvb: we are shipping many of their boards with our printers now, so we depend on proper predictable information
<oliv3r> ssvb: but it sounds like they had stability problems there too
<oliv3r> and blamed the ZQ resistors
<ssvb> well, there are external 240 Ohm resistors on the board, which are used to calibrate internal pull-up and pull-down impedance matching resistors both in the DRAM controller and in the DRAM chip during the ZQ calibration step
<oliv3r> i'm wondering if Stefan Mavrodiev is an employee
<ssvb> changing these external ZQ resistors affects the ZQ calibration result and is likely to affect DRAM reliability
<tkaiser> oliv3r: IIRC the original submissions were also from him. And the stuff ssvb outlines now is really not the best way to deal with DRAM timings (working best only when using vendor supplied OS images due to 'hidden settings')
<ssvb> because Olimex changed these resistors in some board revisions, they probably were trying to tune the DRAM impedance matching settings in a "hardware" way
<oliv3r> well remember, they are hardware guys
<ssvb> while the U-Boot DRAM initialization code can also tune some parameters in a "software" way
<tkaiser> oliv3r: Even hardware guys can answer questions ;)
<oliv3r> plaes: yeah he's a olimex oployee
<oliv3r> but that's why I'm saying, I have some weight now to put behind it
<oliv3r> ssvb: but with different resistors on different boards, do we still have a unified bootloader option?
<ssvb> we can always reduce the DRAM clock speed low enough, so that all these board variants work reliable
<oliv3r> well for now, i have to first prove instability
<oliv3r> and show that the lower freq. solves it
<oliv3r> ssvb: so if I send them an e-mail, asking that i notice there are different ZQ resistors on the various boards I have, why this was done? would that be satisfactory?
<oliv3r> ssvb: i'm gonna RTFM next; but Error: failed to run ioctl on /dev/fb0: Invalid argument
<oliv3r> is that to be expected?
<oliv3r> from lima-memtester :)
<ssvb> do you have /dev/fb0 ?
<oliv3r> ssvb: yes!
<oliv3r> not sure how it got there though; i'm guessing it's hdmi via u-boot
<ssvb> oliv3r: maybe no permissions? do you run the test as root?
<oliv3r> i do
<ssvb> you can try to debug it yourself :) which ioctl was that?
<oliv3r> i dunno the log isspammed horribly full
<oliv3r> and i just broke my sd card too :(
<oliv3r> gotta make a new one now
yann-kaelig has quit [Quit: Leaving]
<KotCzarny> how can one break sd card?
<KotCzarny> it's usually the port that gets damaged
<KotCzarny> ;)
<oliv3r> power off while it wasn't done shutting down :)
<oliv3r> so it's corrupted
<KotCzarny> ah, so its only fs corruption, not physical damage ;)
<oliv3r> ssvb: btw, the cube spins fine, it's just a while lot of errors (10 per second?) and i can't redirect the error to 2> /dev/null :(
<oliv3r> KotCzarny: yeah
<ssvb> oliv3r: about ZQ resistors, the Lime2 board seems to have the same 330 Ohm in all revisions
<tkaiser> terra854: Regarding kernel compilation. In case you deal with Allwinner's BSP kernel I would stay with the optimization level the BSP uses (since you can be assured that nothing else ever has been tested). With H3 BSP kernel when you switch from -O2 to -Os for example everything seems to work but HDMI output is blanked later
<ssvb> oliv3r: it must have been some other Olimex board
<oliv3r> ssvb: ok then the question becomes harder to ask :p
<oliv3r> since we only use lime2's :p
<ssvb> about the ioctl, maybe it's the one which is supposed to prevent the screen from blanking?
<oliv3r> btw, the ram freq. issue; is it related to heat at all? since all our boards have heatsinks
<oliv3r> ssvb: it's not that important, was just wondering if I did something wrong
yann has quit [Ping timeout: 260 seconds]
<ssvb> tkaiser: yeah, basically my understanding at that time was that Olimex could not care less about the mainline U-Boot as long as they are providing bootable images for their customers themselves
<oliv3r> back then, absolutly
<oliv3r> but wasnt there a blog post more recently, where they where supprised by the mainline status?
<oliv3r> ssvb: how hardd are you on the 80 character line limit in lima-memtester?
<oliv3r> tkaiser: that's the one
<ssvb> oliv3r: what about the 80 character line limit?
<oliv3r> i'm replacing printf("Error with fprintf(stderr, "Error
<oliv3r> and it make some lines longer then 80 chars :)
<oliv3r> to be fair, it's libv's limadriver code
<ssvb> aren't you putting the cart before the horse? is there anything there that needs to be fixed other than just printf cosmetics?
<oliv3r> exactly
<oliv3r> i am :)
gianMOD_ has quit [Remote host closed the connection]
<oliv3r> i want to be able to ./lima-memtester 2> /dev/null
<oliv3r> so i see the normal output, but don't care about the errors
<oliv3r> then again, i probably should just look at the ioctl error only :p
<oliv3r> ah but then i don't get the 'regular' output
<oliv3r> well i'm guessing it's the 2>/dev/null & 1>2 trickery
<KotCzarny> which output you want to discard and which to log and display?
<oliv3r> well close enough :p
<oliv3r> i could just | grep -v Error i suppose :p
<KotCzarny> remember there is also 'tee' command
<ssvb> still it would be great if you could identify the problematic ioctl rather than just hiding error messages
<oliv3r> yeah i decided to go that route :p
<oliv3r> but now your making me shave some yak's
yann has joined #linux-sunxi
<libv> oliv3r: that was done for android.
<oliv3r> libv: !! hi!
gianMOD has joined #linux-sunxi
<libv> remember that this code was writtenm before any of the mali based SoCs were running under a proper linux
<oliv3r> libv: i remember :)
<oliv3r> ssvb: bah your simple cmake .; make -j2 don't work if you need to crosscompile :p
premoboss has joined #linux-sunxi
<ssvb> sigh, apparently I need to add crosscompilation instructions to the readme file
<oliv3r> well it needs a little more then: cmake . -DCMAKE_C_COMPILER=arm-linux-gnueabihf-gcc
Leepty has quit [Remote host closed the connection]
<oliv3r> because while that compiles, it's missing includes then
jernej has joined #linux-sunxi
gianMOD has quit [Read error: Connection reset by peer]
<oliv3r> what's even worse though; lima-memtester 512M works great with 480MHz :p
gianMOD has joined #linux-sunxi
<KotCzarny> remember, it could fail when ran overnight
<KotCzarny> also, you need to visually check for pink background
<tkaiser> red -- and one Armbian user reported failing with 480 MHz after 30 minutes and with 456 MHz after 4 hours.
<ssvb> oliv3r: did you use "cmake . -DCMAKE_C_COMPILER=arm-linux-gnueabihf-gcc -DCMAKE_ASM_COMPILER=arm-linux-gnueabihf-gcc" in the end? or compiled natively?
massi has quit [Remote host closed the connection]
<ssvb> and as tkaiser said, it may take a bit of time until the problem is reproduced
<oliv3r> KotCzarny: yeah i'll let it run overnight
<oliv3r> ssvb: i used only the compiler, not the asm
<tkaiser> oliv3r: In case you parse the output look for FAILURE (and do not filter this out ;) )
ganbold has quit [Quit: This computer has gone to sleep]
<oliv3r> tkaiser: but even that fails :(
<ssvb> BTW, you don't need to run it with 512M because the size of the buffer does not matter much
ganbold has joined #linux-sunxi
<rellla> nove: call me a badboy, but it smells like a new license desaster again....
<oliv3r> ssvb: ah okay
<oliv3r> ssvb: http://sprunge.us/VeOR
premoboss has quit [Quit: Sto andando via]
<KotCzarny> 'trying to append licenses'
<KotCzarny> how hard could it be?
<KotCzarny> :>
IgorPec has quit [Ping timeout: 245 seconds]
<rellla> tkaiser: thanks...
gianMOD_ has joined #linux-sunxi
gianMOD_ has quit [Remote host closed the connection]
gianMOD has quit [Read error: No route to host]
Nacho has quit [Remote host closed the connection]
Nacho has joined #linux-sunxi
<nove> rellla: after seeing the header i get blind and can't see the rest, but for your second link that is trivial macro, and in my opinion FF is only two letters
apritzel has joined #linux-sunxi
<nove> rellla: but yes, this clearly shows the mess that results of having copy-pasted some ffmpeg source code
<rellla> nove: yeah, i do not want to accuse them, but i found it funny, that they prepend their own macro with FF instead of CDX for example, which lets me conclude some copy&paste from ffmpeg
reinforce has joined #linux-sunxi
<rellla> and i stated "smells like", which is kind of subjective
<apritzel> terra854: please don't mess with the optimization level in the kernel
<apritzel> terra854: unless you know _exactly_ what you do
<apritzel> terra854: besides: what do you expect? A faster machine? Because 3 > 2?
<KotCzarny> there is also -Ofast
<KotCzarny> ;)
<tkaiser> apritzel: should already be faster than armhf since 64 > 32
<KotCzarny> which includes even more funny optimizations
IgorPec has joined #linux-sunxi
<apritzel> terra854: I don't think that compiler optimization improves anything in the kernel performancewise
<apritzel> because performance issues are somewhere else and not in the code that the compiler generates
<apritzel> terra854: what's very likely though is that you break the kernel, possibly in a very subtle way
<KotCzarny> silent corruptions ahoy!
IgorPec has quit [Client Quit]
<plaes> A33 tablet I just received - http://i.imgur.com/Y5vkwfO.jpg :)
<plaes> screen doesn't work ;)
<KotCzarny> have you tried turning it off and on again?
<MoeIcenowy> plaes: What's the Wi-Fi?
<MoeIcenowy> A USB one
<MoeIcenowy> or a SDIO one?
<MoeIcenowy> Oh seems like SDIO
<plaes> dunno yet
<wens> any markings?
<plaes> still filing a complaint :)
<MoeIcenowy> plaes: screen doesn't work even under Android?
<plaes> well, if you take a look at the picture, then:
<plaes> 1) Cable isn't actually attached
<MoeIcenowy> yes...
<plaes> 2) screen connector is loose
<wens> more like the connector is broken
<MoeIcenowy> I think get another such screen is easy on alibaba
<wens> :(
<MoeIcenowy> but it may not be worthful outside China :-(
<plaes> wifi is SDIO
<MoeIcenowy> but even a dumb board is useful
vishnup has quit [Remote host closed the connection]
<MoeIcenowy> you can boot up a mainline kernel, load the g_serial module, and enable a console and getty on ttyGS0
<plaes> RTL8723BS
netchip has joined #linux-sunxi
<plaes> silead gsl1680 touchscreen
<MoeIcenowy> 8723bs... Interesting...
<MoeIcenowy> The second A33 tablet with 8723bs I have seen
netchip has quit [Client Quit]
<MoeIcenowy> The first one is a white-brand with "iNet D978 Rev02" board id
<MoeIcenowy> which I added to 4.9 kernel
netchip has joined #linux-sunxi
<plaes> iRULU eXpro X4
<MoeIcenowy> it's a aw tablet solution with bluetooth...
<plaes> ok, PCB markings V708_V1.0_0311 MAINBOARD_V1.0 PHT
<wens> hans mentioned the author would be expanding the rtl8xxx driver to cover sdio devices in the future
<wens> no timeline though
<apritzel> wens: the upstream driver you mean?
<apritzel> which supports only USB atm?
<MoeIcenowy> wens: you mean hadess?
<MoeIcenowy> oh it's not him
<plaes> rtl8xxxu
<MoeIcenowy> wens: now rtl8723bs has a out-of-tree but usable driver
<MoeIcenowy> and bluetooth can also work with a modified hciattach
<wens> apritzel: yes
<wens> MoeIcenowy: hans said he has no intention of merging that out-of-tree driver, even into staging
<MoeIcenowy> yes...
<apritzel> MoeIcenowy: that one looks not even remotely upstreamable, tbh
<MoeIcenowy> but Pine64 will soon need it :-(
<apritzel> I know, that's why I am asking
<MoeIcenowy> wens: excuse me, how can I send a patch target on current master
<MoeIcenowy> (I want to fix the pinmux problem imported when mripard merging my patch with allwinner,{drive,pull} removed)
JohnDoe_71Rus has joined #linux-sunxi
<MoeIcenowy> (the problematically merged patch has entered 4.9-rc
<apritzel> MoeIcenowy: I saw that LinusW merged parts of the series already
<apritzel> MoeIcenowy: not sure where to, exactly, but we may just stay patient
<MoeIcenowy> apritzel: it's not about A64 but A33, and I'm fixing the dt
<MoeIcenowy> and it still uses legacy binding
<MoeIcenowy> the pinctrl node do not work now.
<apritzel> I see, so it's 4.9 material
<MoeIcenowy> yes
<MoeIcenowy> and how should I mark the patch that describes it targets on 4.9 line?
<apritzel> just send it to the usual people and point out in the commit message (or after the "---" that it fixes 4.9
kaspter has joined #linux-sunxi
<wens> add a footnote when sending the patch, after ---
<apritzel> you could have a "fix ..." in the subject to make this clear
<apritzel> and an explicit: "Fixes: <commit id>" before your SOB
<wens> and Fixes: git-hash ("commit subject")
<apritzel> wens ;-)
<wens> oops, beat me to it
<MoeIcenowy> yes I added "Fixes"
<MoeIcenowy> (Oh the patch that fixes the A64 USB PHY may be also needed to be merged into 4.9 ...
<MoeIcenowy> (although there won't be any dt in 4.9 to use it
<netchip> This is offtopic for sunxi devices, but I'll ask it anyway. What's a good way to learn the assembly language for the ARMv8 instruction set?
<KotCzarny> buy armasm for dummies?
<apritzel> netchip: there used to be a concise document describing the instructions briefly, Google should still find it, try: "ARMv8 Instruction Set Overview"
<apritzel> well, concise, it's still 113 pages ;-)
<netchip> KotCzarny: Probably doesn't describe the ARMv8 64 bit instruction set...
<netchip> apritzel: Think I found it, thank you.
<KotCzarny> netchip, i was just kidding, no offense ;)
<netchip> KotCzarny: But I think I should buy something like that indeed, because it's the first time I dive into assembly
<apritzel> If the URL starts with a dodgy IP address: that's the one ;-)
<netchip> KotCzarny: Oh haha, none taken ;)
<netchip> apritzel: Yeah, found that one :P
<KotCzarny> doing asm code requires specific way of thinking
<MoeIcenowy> On the USB PHY side, A64 is so like H3...
<apritzel> that document was used officially by ARM before the detailed ARMv8 ARM was published
<apritzel> netchip: but as KotCzarny pointed out, you should be able to "think assembly" before using that
<apritzel> netchip: or you could play around with inline assembly, that allows you to test single instructions without the whole assembly boilerplate
<wens> i learned it the hard way, reading existing asm code and looking up what the instructions meant :|
<KotCzarny> stacks, registers, heaps, no longer c=7; b=c; now its series of loads and executions ;)
<netchip> apritzel: That's a smart idea yeah :)
<wens> KotCzarny: at least you still have push/pop :p
<netchip> I read a bit about it, the concept of registers doesn't sound too hard
<KotCzarny> classic: http://i.imgur.com/ZyeCO.jpg
<KotCzarny> asm is just like that ;)
leviathanch has joined #linux-sunxi
avph has quit [Ping timeout: 260 seconds]
<willmore> wens, I thought that was the easy way. ;)
<KotCzarny> and as apritzel have said, if you can, use c/c++ with optimized parts inbetween, unless you are doing some embedded project where space is critical
<wens> willmore: it involves banging one's head on the desk a lot :)
<netchip> KotCzarny: My goal is to understand the workings of a CPU, and to be able to understand very low level code :)
<KotCzarny> good luck!
<wens> netchip: not much of linux is in assembly though
<apritzel> ... and speak to you in 10 years again
<KotCzarny> its just switching bits on and off very fast
<netchip> apritzel: Well, as I am 17 y/o, I still have many years :P
<KotCzarny> with some shortcuts (compilcated instructions) to do more work in a cycle than othwerwise possible with simple instructions
avph has joined #linux-sunxi
<willmore> wens, it's how I've learned every language I've ever programmed in. In theory, I know I can read a book and figure it out, but it seems to work much better seeing how it's really done in practice. I also suffer from the 'blank paper problem'.
<netchip> KotCzarny: Of course, but learning how registers work, how the stack works, etc ...
<MoeIcenowy> maybe we will see AArch128 in 10 years ;-)
<MoeIcenowy> maybe not
<MoeIcenowy> If possible, have a CPU-related course at MOOC
<willmore> netchip, get one of those bluepill boards and program that. Cheapest way to get into ARM.
<MoeIcenowy> netchip: ^
<netchip> MOOC?
<willmore> Massively online... something.
<MoeIcenowy> online course platforms
<MoeIcenowy> just like Coursera, EdX and so on
IgorPec has joined #linux-sunxi
<netchip> willmore: Bluepill boards? Cortex M* boards?
apritzel has quit [Ping timeout: 250 seconds]
<MoeIcenowy> netchip: yes
<MoeIcenowy> although these courses usually do not use ARM, but you can easily understand ARM or other most ISAs after learning these
matthias_bgg has quit [Quit: Leaving]
<wens> computer architecture or organization textbooks like to use MIPS
<mdsrv_> true
<mdsrv_> because its simple yet efficient architecture
<wens> perhaps they might switch to RISC-V
<MoeIcenowy> yes... although my teacher used a more simple ISA ;-)
<mdsrv_> 51?
<MoeIcenowy> mdsrv_: much simpler than 51
<mdsrv_> z80?
<MoeIcenowy> the ISA is an education-only one called lc2k (Little Computer 2000)
<mdsrv_> oh
<wens> mdsrv_: yeah, 5-stage simple pipeline is easier to understand and simulate on paper
<mdsrv_> yep
<mdsrv_> mips r cool
<mdsrv_> mipses*
<MoeIcenowy> but cheap ARM hardwares are more easily to get
<MoeIcenowy> e.g. Allwinner ;-)
<mdsrv_> dont think so
<mdsrv_> u can buy much hardware with mips
<mdsrv_> stb
<mdsrv_> routers
<mdsrv_> etc
<MoeIcenowy> routers are too weak in performance
<mdsrv_> and stbs?
<MoeIcenowy> what's STB...
<mdsrv_> set top box
<MoeIcenowy> Oh I have never seen hackable MIPS STb
<mdsrv_> google for enigma2
<mdsrv_> going home
<mdsrv_> bbl.
yann-kaelig has joined #linux-sunxi
IgorPec has quit [Quit: Nettalk6 - www.ntalk.de]
gianMOD has joined #linux-sunxi
netlynx has joined #linux-sunxi
netlynx has quit [Changing host]
netlynx has joined #linux-sunxi
dh1tw has joined #linux-sunxi
|Jeroen| has joined #linux-sunxi
<willmore> netchip, yes.
<willmore> MIPS was based on a hypothetical architecture used in education. I have the text book lying around somewhere. Mauchly I think was the author. College was a long time ago.
<willmore> MoeIcenowy, I have a Patriot media center box that is MIPS based and easily hackable.
<KotCzarny> willmore: pbo ?
tsuggs has quit [Quit: No Ping reply in 180 seconds.]
<KotCzarny> i still own and use original one, funny how 400mhz soc could easily decode and play full hd movies
<MoeIcenowy> KotCzarny: must be hardware decoded
<KotCzarny> yup
<MoeIcenowy> Allwinner's F series is also in such situations
<MoeIcenowy> they're weak ARM9 cores
<KotCzarny> and talking about security, they have telnetd running with passwordless root account ;)
<KotCzarny> not that one can do much on them, but still
<nove> KotCzarny: some hardware video decoders (the one that have datasheets floating around), claim to only need 1MIPS (instruction per second) to configure the hardware
leviathanch has quit [Remote host closed the connection]
<MoeIcenowy> Three Chinese SoC vendors, Allwinner, Rockchip, and Ingenic (MIPS SoCs), all started at the portable media player market
<ssvb> willmore: what kind of CPU core is used in this Patriot box? I have https://wiki.openwrt.org/toh/asus/rt-n16 with a MIPS74K processor
<ssvb> willmore: and /proc/cpuinfo information is here - https://github.com/ssvb/tinymembench/wiki/Asus-RT-N16-(BCM4718)
dh1tw has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
gianMOD has quit [Remote host closed the connection]
<KotCzarny> mine has:
<KotCzarny> system type : Realtek Venus
<KotCzarny> cpu model : MIPS 24K V7.8
<KotCzarny> BogoMIPS : 269.51
<tkaiser> Reminds me of my former MIPS 'workhorse': https://commons.wikimedia.org/wiki/File:SGI_O2_with_monitor.jpg ;)
<ssvb> KotCzarny: it would be interesting if you can run tinymembench on it, just to see if it happens to have a beefy memory interface for the sake of handling media workloads :)
<ssvb> KotCzarny: but the processor itself is a plain MIPS24K (not even MIPS24KE), so it is missing interesting DSP ASE instructions
<KotCzarny> ssvb, if you provide compiled binary i can try (havent got mips sdk atm)
Andy-D_ has quit [Ping timeout: 244 seconds]
<ssvb> btw, is it little or big endian?
<KotCzarny> how do i check?
<ssvb> that's a good question
<KotCzarny> that suggests little endian
bugzc has joined #linux-sunxi
<JohnDoe_71Rus> tkaiser: yes. SG station looks like vacuum cleaner
<KotCzarny> wow, it has pvr inside
<tkaiser> KotCzarny: IIRC on nearly all MIPS generations endianess was a software thing. I believe IRIX was big endian
<ssvb> KotCzarny: just do something like "crossdev --kernel =3.18 --libc =2.20-r2 --binutils =2.24-r3 --gcc =4.8.5 --genv 'USE="-fortran -mudflap -nls -openmp multilib -sanitize"' -t mipsel-softfloat-linux-gnu" and you will have a suitable crosscompiler
<KotCzarny> tkaiser, but in this case software was compiled for LE
<ssvb> KotCzarny: the gcc/libc/binutils version may need to be bumped though (that was the command line which I used ages ago)
<mdsrv_> tkaiser: there is a hardware switch for little/big-endianess
<mdsrv_> in mips
<ssvb> KotCzarny: I have uploaded static binaries here - https://people.freedesktop.org/~siamashka/files/20161024-tinymembench-binaries
<ssvb> KotCzarny: but you should not trust me :)
<KotCzarny> ssvb, i trust you, more than pvr anyway
<KotCzarny> ;)
<KotCzarny> ok, where's my ethernet cable..
gianMOD has joined #linux-sunxi
Andy-D_ has joined #linux-sunxi
cptG_ has quit [Ping timeout: 244 seconds]
cptG has joined #linux-sunxi
<KotCzarny> and now, how do i copy anything from windoze
<tkaiser> KotCzarny: COPY /A?
<KotCzarny> does it work over network?
<tkaiser> KotCzarny: Just kidding, I gave up on this platform over 20 years ago (have only to deal with Windows Server from time to time)
<ssvb> KotCzarny: doesn't putty provide something like scp?
<KotCzarny> ssvb, sure, as long there is sshd on the other side
<KotCzarny> i only have telnetd
<KotCzarny> looking for some windoze compiled httpd
<KotCzarny> as at least wget is on the box
<tkaiser> And back then Windows (NT) was the only little-endian platform around (DEC Alpha and x86) ;)
<ssvb> oliv3r: about your "fatal error: asm/types.h: No such file or directory" problem, are you sure that you have a properly functioning crosscompiler?
<ssvb> oliv3r: I doubt that it is related to CMake
<KotCzarny> that looks like missing kernel/distro includes
jernej has quit [Quit: Konversation terminated!]
jernej has joined #linux-sunxi
<KotCzarny> ssvb:
<KotCzarny> /usr/local/etc/tmp # ./tinymembench-mipsel-softfloat-linux-gnu -h
<KotCzarny> FATAL: kernel too old
<KotCzarny> Bus error
<KotCzarny> hehe
<KotCzarny> and the other one has problem with endianness
<KotCzarny> Linux Venus 2.6.12.6-VENUS #3 Wed Feb 16 09:52:51 CST 2011 mips unknown
<KotCzarny> lrwxrwxrwx 1 root root 19 Mar 31 2011 /lib/libc.so.0 -> libuClibc-0.9.28.so
gianMOD has quit [Remote host closed the connection]
<ssvb> hmm, you still can try to build an archaic mips crosscompiler with ancient kernel headers and glibc
<ssvb> but how come that you have this device, but have not obtained a crosscompiler for it yet? ;)
<KotCzarny> there is only one word, laziness
<KotCzarny> i've got it cheap and it just plays movies
<KotCzarny> nice feature is native sata with space for 2.5" hdd inside
<KotCzarny> what one could wish more?
<KotCzarny> but more seriously, this thing is one big binary blob in the pvr style
gianMOD has joined #linux-sunxi
<KotCzarny> even network config is done via binary gui
<KotCzarny> (and trying to override it with ifconfid/iwconfig is pointless as bastard will periodically reset the settings)
IgorPec has joined #linux-sunxi
kimberlime has quit [Remote host closed the connection]
rkkang has joined #linux-sunxi
terra854 has quit [Quit: Connection closed for inactivity]
arete74 has quit [Ping timeout: 256 seconds]
arete74 has joined #linux-sunxi
my123_ has joined #linux-sunxi
my123_ has joined #linux-sunxi
my123_ has quit [Changing host]
my123 has quit [Ping timeout: 250 seconds]
my123_ is now known as my123
gianMOD has quit [Remote host closed the connection]
netlynx has quit [Quit: Ex-Chat]
<tkaiser> Can anyone capable of reading Chinese decipher what's written there on the 3rd image: http://forum.banana-pi.org/t/microsoft-show-bpi-m64-for-win-10-iot-at-maker-faire-shenzhen-2016/2389
<tkaiser> I wonder why a faked 'M$ IoT starter kit' should contain an Orange Pi Lite?
<KotCzarny> if you zoom in, it looks a bit like a64 on soc
<tkaiser> KotCzarny: Nope, on the cardboard box.
<KotCzarny> ahm
<tkaiser> The picture is from those sad sinovoip people who threw a BPi M64 on the table
<KotCzarny> maybe we are on the brink of flood of crap win10 allwinner iot boxes
<tkaiser> KotCzarny: That's for sure, Allwinner & MS somehow push A64 for their Win10 IoT stuff (where not even onboard hardware seems to work)
<tkaiser> But that's also not Microsoft there (they stopped their business in Shenzhen 2 years ago IIRC)
<KotCzarny> so.. crap leaked beta?
<tkaiser> No idea. Just curious why there's an Orange Pi Lite. I visit this crazy Banana forum from time to time for news about R40 / BPi M2 Ultra. But there are only weird things happening.
<tkaiser> But this Win 10 IoT stuff for A64 is even more weird: https://github.com/Azure/azure-iot-sdks/blob/master/doc/get_started/windows10-iot-core-pine64-csharp.md (you need an USB Wi-Fi dongle and 'make sure the "Use authentication" box is unchecked')
apritzel has joined #linux-sunxi
<nove> a red robot with a M
<nove> ah, is the logo of makerfair
* nove tought that was from the other M
gianMOD has joined #linux-sunxi
gianMOD has quit [Client Quit]
avph has quit [Ping timeout: 250 seconds]
avph has joined #linux-sunxi
JohnDoe_71Rus has quit [Quit: KVIrc 4.9.2 Aria http://www.kvirc.net/]
dr1337_ has joined #linux-sunxi
<willmore> KotCzarny, yep, that's it!
reinforce has quit [Quit: Leaving.]
|Jeroen| has quit [Quit: dada]
IgorPec has quit [Ping timeout: 252 seconds]
<willmore> ssvb, I have a box of Indy's in the basement, IIRC. I do not remember what cpu they used, but I'm pretty sure it's less than that O2.
nove has quit [Ping timeout: 252 seconds]
Gerwin_J has quit [Quit: Gerwin_J]
<indy> willmore, sgi indy? mips r4600 r5000, not sure if r4400
<willmore> tkaiser, don't forget VAX. That's why ALPHA was LE.
<willmore> indy, hey, good name. ;) Sorry for the accidental highlight.
<indy> willmore, :)
avph has quit [Ping timeout: 260 seconds]
<willmore> But, with a name like that, you should know. :)
dh1tw has joined #linux-sunxi
<indy> willmore, even indy was my first pc, origin of nick dates 10y earlier before sgi indy spotted light of sun :)
<willmore> You from Indy?
avph has joined #linux-sunxi
<indy> yes indiana jones
nove has joined #linux-sunxi
<apritzel> you are named after the dog? :-D
avph has quit [Ping timeout: 250 seconds]
avph has joined #linux-sunxi
afaerber has quit [Quit: Ex-Chat]
<indy> apritzel, :)
avph has quit [Ping timeout: 260 seconds]
<apritzel> NiteHawk: thanks for the explanation about passing env variables via sunxi-fel
<apritzel> I was wondering if passing key=value directly on the sunxi-fel command line has been considered?
avph has joined #linux-sunxi
f0xx has quit [Ping timeout: 260 seconds]
afaerber has joined #linux-sunxi
<igraltis1> ps aux
<igraltis1> :D
uwe__ is now known as uwe_
dr1337_ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
tkaiser has quit [Quit: jIRCii - http://www.oldschoolirc.com]
dr1337_ has joined #linux-sunxi
dh1tw has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
yann-kaelig has quit [Quit: Leaving]
Andy-D_ has quit [Ping timeout: 260 seconds]
netchip has quit [Ping timeout: 260 seconds]
MXfive has joined #linux-sunxi
jernej has quit [Ping timeout: 256 seconds]
FergusL has joined #linux-sunxi
dr1337_ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
dr1337_ has joined #linux-sunxi
afaerber has quit [Quit: Ex-Chat]
afaerber has joined #linux-sunxi
dr1337_ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
dr1337_ has joined #linux-sunxi
Andy-D has joined #linux-sunxi
Da_Coynul has joined #linux-sunxi
dr1337_ has quit [Ping timeout: 252 seconds]
Da_Coynul has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
p_rossak_ has quit [Ping timeout: 245 seconds]
p_rossak has joined #linux-sunxi
arossdotme-planb has quit [Ping timeout: 245 seconds]
arossdotme-planb has joined #linux-sunxi
<NiteHawk> apritzel: i did not consider that originally. but since the mechanism to transport uEnv data to U-Boot doesn't know anything about / rely on the origin of that data, we could extend on it
<NiteHawk> e.g. taking it from stdin or constructing the assignment "on the fly" from command line parameters is feasible
<apritzel> NiteHawk: I was also wondering about this magic header and the autodetection by sunxi-fel, can't we just use something like "writeenv" to make this more explicit?
<apritzel> because if I got this right, then any image which happens to match his heade string (by chance) is considered as U-Boot environmental data
jemk has quit [Ping timeout: 245 seconds]
jemk has joined #linux-sunxi
<ssvb> apritzel: we would need some reserved place in the address space to store this information
<ssvb> then we can construct this data on the fly from the command line and/or get rid of the address argument in the "writeenv" command, which is currently necessary for "write"
<NiteHawk> apritzel: correct - if a file starts with that "magic", sunxi-fel always considers it suitable for 'tagging' a uEnv-style data when uploading. and yes, a dedicated "writeenv" command would work too
<NiteHawk> the "#=uEnv" is inspired by the shell "shebang" and would allow a "uEnv.txt"-compatible text file that can be used both via FEL, and from U-Boot via file load and "import -t"
<NiteHawk> ..for 'tagging' as..
Da_Coynul has joined #linux-sunxi
<ssvb> apritzel: more explicit "writeenv" command may be also misused if the user accidentally feeds it with a wrong file
<ssvb> the probability of incorrect detection is very low, and even if it happens somehow, the sunxi-fel tool reports what it is doing in the log and the user can see that something unusual is happening
_whitelogger has joined #linux-sunxi
popolon has quit [Quit: WeeChat 1.4]
nove has quit [Quit: nove]
bobryan has quit [*.net *.split]
zumbi_ has quit [*.net *.split]
Uninstall_ has quit [*.net *.split]
juri_ has quit [*.net *.split]
plaes has quit [*.net *.split]
Xilokar has quit [*.net *.split]
atsampson has quit [*.net *.split]
ninolein has quit [*.net *.split]
topi`_ has quit [*.net *.split]
book`_ has quit [*.net *.split]
Colani1200 has quit [*.net *.split]
vbmithr_ has quit [*.net *.split]
jelly-home has quit [*.net *.split]
wens has quit [*.net *.split]
nihcas_ has quit [*.net *.split]
Guest76699 has quit [*.net *.split]
fl_0 has quit [*.net *.split]
cosm has quit [*.net *.split]
NiteHawk has quit [*.net *.split]
bugzc_ns has quit [*.net *.split]
pcduino has quit [*.net *.split]
Nyuutwo has quit [*.net *.split]
VargaD has quit [*.net *.split]
_whitelogger has quit [Excess Flood]
_whitelogger_ has joined #linux-sunxi
VargaD has joined #linux-sunxi
nihcas_ has quit [Ping timeout: 253 seconds]
nihcas_ has joined #linux-sunxi
<apritzel> ssvb, NiteHawk: if you are still awake, can you check #u-boot?
cptG_ has joined #linux-sunxi
<NiteHawk> apritzel: yup. but i'm not very experienced in u-boot
yann-kaelig has joined #linux-sunxi