ricardocrudo has quit [Remote host closed the connection]
enrico_ has joined #linux-sunxi
bamvor has joined #linux-sunxi
lemonzest has joined #linux-sunxi
arete74_ has joined #linux-sunxi
arete74 has quit [Read error: Connection reset by peer]
asmir has quit [Quit: WeeChat 1.0.1]
FlorianH has joined #linux-sunxi
soderstrom has joined #linux-sunxi
FR^2 has joined #linux-sunxi
naobsd has quit [Quit: naobsd]
FR^2 has joined #linux-sunxi
alex_____ has quit [Quit: Page closed]
alex_____ has joined #linux-sunxi
FlorianH has quit [Ping timeout: 240 seconds]
asmir has joined #linux-sunxi
Net147 has quit [Ping timeout: 272 seconds]
FlorianH has joined #linux-sunxi
Net147 has joined #linux-sunxi
<soderstrom>
Hi, I've been working on adding support for NextThingCo C.H.I.P (sun5i-r8-chip) board to Yocto's meta-sunxi. Yesterday my yocto version finally started "working", aka it boots but there are essentially no userspace applications availble (yoctos core-image-minimal-mtdutils with devicetree,zimage and kernel-modules builtin inside the rootfs). However I'm debating with myself about if it is in the rig
<soderstrom>
ht path to take. Maybe it should go into its own unique layer given that it differs significantly from other allwinner boards (biggest difference is that it does not use fex files, it uses device trees for everthing instead). Then again it is still a sunxi board. Maybe I'm trying to hard to keep it similiar to the way NextThingCo builds it. If anyone here has any advice in the matter I'm all ears.
<mripard>
I don't see what's specific about the CHIP compared to any other allwinner board running mainline
<mripard>
my knowledge of yocto is limited, but maybe you just need to add a new kernel recipe for mainline based kernels, and have the chip use that
<mripard>
(and I'm pretty sure there's one already)
viccuad has joined #linux-sunxi
<soderstrom>
Yocto needs machine configuration files, kernel and bootloader recipes. These I've added in my fork of the meta-sunxi layer. I'm pretty sure there isn't one available yet. C.H.I.P is really new, I only have a board since I kickstarted with a certain pledge level.
<soderstrom>
but then again, I might be missing something ofc ^^
caog has joined #linux-sunxi
<libv>
i thought that that pledge level was for "kernel developers", not for distribution developers :p
<soderstrom>
What makes it special you say, well one thing I already mentioned (fex files aren't used for C.H.I.P). Another difference is the way it repacks its images before using the fel (sunxi-tools). Personally I'm wondering if this repacking is really needed, maybe it could be done in a more ordinary fashion.
<soderstrom>
libv: haha
<soderstrom>
yes, they made a funny name there
<libv>
they did quite a few other "funny" things as well
<soderstrom>
any examples?
arete74_ has quit [Read error: Connection reset by peer]
<soderstrom>
:)
* soderstrom
loves to have fun
arete74 has joined #linux-sunxi
<libv>
claiming to have _always_ been all about open source, while this only happened once the flack of the GPL violations hit them hard and threatened to ruin their marketing campaign
IgorPec has joined #linux-sunxi
<mripard>
soderstrom: the kernel recipe and bootloader recipe ain't special, really.
<mripard>
soderstrom: and we repack the images that way to try to avoid as much as possible the issues we've encountered with MLC NAND
<mripard>
so again, nothing special, really
<mripard>
the only thing special about it is the DT name
<enrico_>
soderstrom: latest meta-sunxi already uses 4.1 and dts for the supported boards, i think that you just need to add the machine conf with the right values
<enrico_>
(if 4.1 already has supports chip, of course)
<mripard>
enrico_: it doesn't
<enrico_>
perfect hehe
<mripard>
preliminary support will be in 4.4, most of the support is in one of our branches
<enrico_>
well then it's just a custom src uri for that machine (more or less)
<soderstrom>
NiteHawk: yes it is, at least from what can be seen in public :)
<mripard>
NiteHawk: there's a 4.3 branch on that repo
<soderstrom>
mripard: You are correct
<mripard>
I know I'm correct, I'm the one who pushed it :p
<soderstrom>
ah
<soderstrom>
I see that now
<enrico_>
soderstrom: the only overcomplicated thing that i see there is the board fex handling (to support fex/no fex cases), but i don't know right now if there is a simpler way to do it
<enrico_>
about kernel and u-boot: it's one way to do it, another way could be with just adding:
<enrico_>
SRC_URI_chip = "....."
<enrico_>
in the "standard" recipes
<enrico_>
but if it works it would be ok for me to merge it and then clean it up later
arete74_ has joined #linux-sunxi
arete74 has quit [Read error: Connection reset by peer]
<soderstrom>
Well it works if you run the "bitbake chip-core-image" recipe. But it still needs a bit of handson work when flashing.
<enrico_>
do you mean that you can't flash the resulting ubi images because you need to "do something" on them?
<soderstrom>
no, mostly cause the rootfs is name "${MACHINE}-rootfs" and NextThingCo tools names it "rootfs" only, aka it won't find the correct boot partion withon change that name in chip-tools before flashing.
<enrico_>
ah ok
<soderstrom>
I have a branch of chip-tools for this too :)
<enrico_>
yes it makes sense to modify it in chip-tools then
ricardocrudo has joined #linux-sunxi
<soderstrom>
enrico_: Do you think it would be a good idea to add the yocto specific version of chip-tools under meta-sunxi/recipes-support/chip-tools? I doubt that my changes to it will be something wanted in the NextThingCo offical chip-tools. Then again I could make it more generic so it works both for buildroot and yocto.
<libv>
how does chip-tools fit under meta-sunxi?
<soderstrom>
libv: It doesn't really :/
<libv>
i am also amazed that they needed to clone our sunxi-tools instead of feeding code back to us
<NiteHawk>
hey, progress bars are hard
<soderstrom>
?
<libv>
NiteHawk: :)
<NiteHawk>
honestly, i wouldn't blame that on them. looks like they have a fast-moving target right now, and there might be more fundamental changes coming up that they'd need implemented fast. we might even eventually see a github PR...
ricardocrudo has quit [Ping timeout: 250 seconds]
kaspter has quit [Ping timeout: 250 seconds]
arete74 has joined #linux-sunxi
arete74_ has quit [Read error: Connection reset by peer]
asmir has quit [Ping timeout: 252 seconds]
JohnDoe_71Rus has quit [Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org]
marcin__ has quit [Remote host closed the connection]
<libv>
ah, i missed that
<libv>
but then again, i just looked at a document from nextthingco, and they refer purely to their fork of sunxi-tools
pmattern has joined #linux-sunxi
marcin has joined #linux-sunxi
a1d3s has quit [Ping timeout: 244 seconds]
a1d3s has joined #linux-sunxi
ninolein has quit [Remote host closed the connection]
ninolein has joined #linux-sunxi
<ssvb>
libv: it is perfectly normal for the developers who want to release a usable product and eliminate unnecessary risks
<NiteHawk>
that's what i was thinking too - more or less standard github practice
<ssvb>
NiteHawk: not just github, it's a common sense
<ssvb>
if you are responsible for releasing a product which is based on open source components, then you report bugs upstream and submit patches
pmattern has quit [Quit: No Ping reply in 180 seconds.]
IgorPec has joined #linux-sunxi
<ssvb>
but nevertheless you are responsible for the quality of the product and have to maintain it yourself, regardless of the upstream opinion about the features needed for you or the release schedule :-)
pmattern has joined #linux-sunxi
<ssvb>
libv: I don't really understand what is your problem with CHIP
<NiteHawk>
plus you can't always wait for changes to 'trickle down' your upstream
FR^2 has quit [Quit: Connection reset by peer]
<ssvb>
libv: if anything, CHIP is taking a huge risk because the price/features ratio is not that great for their hardware
<ssvb>
libv: they can only succeed using the Raspberry Pi model, which means providing really good support to the users
<SQUelcher>
Is there a device with h265-acceleration, which runs kodi on debian?
paulk-collins has joined #linux-sunxi
pmattern has quit [Remote host closed the connection]
pmattern has joined #linux-sunxi
<soderstrom>
SQUelcher: by device, are you refering to a specific SoC or a board? Anyways, if its a board your looking for then raspberry pi model b+ will work fine. With raspian (debian based distro), kodi is available.
<soderstrom>
s/your/you're/
<SQUelcher>
soderstrom: the raspi2 can't play h.26_5_ in hardware
<soderstrom>
ah, right it runs h264
<SQUelcher>
there are some board, but they only do acceleration with android
nashpa has joined #linux-sunxi
afaerber_ is now known as afaerber
fredy has quit [Excess Flood]
fredy has joined #linux-sunxi
<libv>
ssvb: my problem with the chip is that they only started caring about open source when they were hit by fallout from gpl violations, and instead of just admitting to that and being honest, they went and lied their asses off. they should've come to members of the linux-sunxi community beforehand, but, failing that, they should've played it open. Lying this nastily is not how one should act when one claims to be open
<soderstrom>
SQUelcher: seems like Mali-600 or higher should support H265, atleast ittiam systems managed to get it working with Mali-T600 GPU. https://en.wikipedia.org/wiki/Mali_%28GPU%29#Implementations, these are SoC implementations. so next step would probably be to check which boards use these SoCs and then see if they have a debian distro available. Unless someone knows better.
ssvb has quit [Ping timeout: 272 seconds]
<libv>
soderstrom: h265 is media encoding/decoding
<libv>
soderstrom: mali is a gpu
naobsd has joined #linux-sunxi
<libv>
these two things are not related
a1d3s_ has joined #linux-sunxi
a1d3s has quit [Ping timeout: 252 seconds]
<soderstrom>
true, but shouldn't the video encoding/decoding be in the gpu? (for hardware acceleration)
<libv>
soderstrom: what does the gpu acronym stand for?
<libv>
ah, heh, nm, even wikipedia adds to the madness
<libv>
soderstrom: mali is a 3d core
<libv>
the higher generations of mali even have unified shaders
<libv>
shaders are nothing more than floating point matrix/vector computational units, with some extra units attached which make it easier to read from pictures (textures)
<libv>
they could, theoretically, be used for everything
<libv>
but they are hopelessly inefficient at things for which much faster dedicated hw blocks exist
<libv>
colour space conversion can be done on the GPU, theoretically
<libv>
but after having thrown overlays out of the window in the last decade, people have now run back to overlays and are even using them extensively for compositing, as it really is a lot more useful and a lot more efficient to implement such operations in dedicated hw
<libv>
the same goes for video en/decoding.
<libv>
google around for gpgpu based h.265 video decoding, and find out what the minimal FOPS needed are for that, and what huge 3D core one would have to include on die to have that done fast enough
<soderstrom>
Yea, sorry I was just being confused. My mind merged the GPU with VPU for a while there
<libv>
this "we can do it all on the 3d core" madness was pretty prevalent in the second half of the 00s
<libv>
to the extent that they even dropped blitters (even though the hw for that is relatively simple, and the hw setup for that is even easier)
<libv>
when i did a stint of consulting for my old team from nokia, which then was at intel, i was halfarsedly tasked to support android hwcomposer through the halfarsed implementation of kms planes of the time
<libv>
i was lucky that pineview was still being sold, and that it came with such an old style display engine, as everything newer did not come with a useful display engine with a useful amount of overlays
a1d3s_ has quit [Ping timeout: 260 seconds]
<libv>
now the number of overlays is a selling point.
<soderstrom>
:)
<libv>
on sunxi, we have allwinners own media engine
<libv>
for which we had quite a bit shitthrowing contest as allwinner was, and still is, violating the LGPLv2
<libv>
i have no idea whether it does already support h265 and if so, which soc it appeared on, you will have to consult the wiki
pmattern has quit [Quit: No Ping reply in 180 seconds.]
pmattern has joined #linux-sunxi
a1d3s_ has joined #linux-sunxi
a1d3s_ has quit [Ping timeout: 255 seconds]
slopez_ is now known as slopez
vishnup has quit [Ping timeout: 246 seconds]
a1d3s_ has joined #linux-sunxi
solarnetone has quit [Read error: Connection reset by peer]
Nacho_ has quit [Remote host closed the connection]
Nacho_ has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
avph has joined #linux-sunxi
cnxsoft has quit [Quit: cnxsoft]
<libv>
NiteHawk: i would actually prefer to see the callback disappear, and be replaced by a boolean
reinforce has quit [Quit: Leaving.]
<libv>
and i have nothing against another global in a single file tool, especially for command line arguments
<NiteHawk>
yes, but siarhei seems to be a bit allergic against those :D
<libv>
the progress global could be handled in the call that eventually calls that callback
<NiteHawk>
but it makes sense from a practical point of view, especially if you'd have to introduce additional function parameters to deal with them otherwise (read: i'd prefer to keep it simple for a small tool like sunxi-fel)
<libv>
introducing just 2 places where this global is used, once to fill it after command line handling, once when the printing function is actually called
<libv>
instead of spreading its use all over the place
<libv>
it's a single file tool with command line arguments
<libv>
as long as we do not pass a tool specific struct around, globals are a necessity
<NiteHawk>
what's wrong with having "progress_cb = NULL", and assign it if "-p" or "--progress" is encountered?
<libv>
NiteHawk: there is only one function where this progress function is called
<libv>
why bother passing this everywhere and make for ugly code?
<NiteHawk>
two, or? read and write
<libv>
let me have a second glance :)
<NiteHawk>
ah, no - you're right. both boil down to usb_bulk_send()
<libv>
the global is used more often...
<libv>
hrm...
<libv>
for newline...
<NiteHawk>
point it, you potentially don't want the progress_callback for certain small transfers - that's where Alex is explicitly passing NULL
<libv>
yes, but there ..., bool progress_print) is much more logical
<libv>
doing away with callbacks and a typedef
<libv>
and aw_usb_read() does not check the value of progress
<libv>
if that is fixed, then it probably needs to get the newline as well
<libv>
so that code should be merged in to the progress bar code
<NiteHawk>
it's where actual output takes place anyway, so i find it natural to have that newline there too
IgorPec has quit [Ping timeout: 260 seconds]
<libv>
this patch should be rewritten and the committer should be nicely explained how he can make things better
<libv>
but i am really bikeshedding here
solarnetone has joined #linux-sunxi
<libv>
as i am doing exactly what i hate in other people, reviewing the shit out of trivial stuff while ignoring everything else
<NiteHawk>
well... peer review is always a problem of "good measure", to keep things consistent without trying to enforce your personal coding style to everyone else
vishnup has joined #linux-sunxi
vishnup has quit [Ping timeout: 246 seconds]
asmir has quit [Quit: WeeChat 1.0.1]
ssvb has joined #linux-sunxi
arete74_ has joined #linux-sunxi
arete74 has quit [Read error: Connection reset by peer]
a1d3s_ has quit [Ping timeout: 240 seconds]
Nacho_ has quit [Ping timeout: 240 seconds]
Nacho_ has joined #linux-sunxi
reinforce has joined #linux-sunxi
IgorPec has joined #linux-sunxi
soderstrom has quit [Quit: leaving]
arete74_ has quit [Read error: Connection reset by peer]
arete74 has joined #linux-sunxi
cubeast has quit [Remote host closed the connection]
MaDMaLKaV has quit [Ping timeout: 256 seconds]
MaDMaLKaV has joined #linux-sunxi
arete74 has quit [Read error: Connection reset by peer]
arete74_ has joined #linux-sunxi
IgorPec has quit [Ping timeout: 260 seconds]
caog has quit [Quit: Ex-Chat]
arete74 has joined #linux-sunxi
arete74_ has quit [Read error: Connection reset by peer]
reinforce has quit [Quit: Leaving.]
fredy has quit [Excess Flood]
fredy has joined #linux-sunxi
paulk-collins has quit [Ping timeout: 255 seconds]
_massi has quit [Remote host closed the connection]
arete74 has quit [Read error: Connection reset by peer]
arete74_ has joined #linux-sunxi
fredy has quit [Ping timeout: 240 seconds]
fredy has joined #linux-sunxi
pekka30 has quit [Ping timeout: 260 seconds]
enrico_ has quit [Quit: Bye]
\\Mr_C\\ has joined #linux-sunxi
rainbyte has quit [Ping timeout: 272 seconds]
rainbyte has joined #linux-sunxi
pmattern has quit [Remote host closed the connection]