<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"
<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 :)
<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...
<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?
<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!
<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]
<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
<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>
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>
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....
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
<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
<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.
<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>
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)
<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
<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
<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.
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