<libv>
no, scrap that, it will at best play q3a demo
<libv>
picuntu is full of it
<servili007>
hehe, thought so :)
<servili007>
it's a heavy and awesome undertaking though
<libv>
well, i also took a non-standard approach
<libv>
i did not throw some things into gallium quickly
<libv>
i actually wanted lima to be competitive, performance wise, with the binary driver
<libv>
luckily the hw played along, and q3a ran as fast as it did first time round
<libv>
the hw also turned out to be a lot less obvious than some of its competitors
<servili007>
Yeah I read through some of your older posts about how it performed and scaled on the various platforms
<servili007>
the memory management as well
<libv>
from the beginning i had stipulated that, if the driver is 80% of the speed of the binary, the binary will not see much use anymore
<libv>
80% of the speed, with the same power usage, that is
<servili007>
I'd agree with that
<libv>
we actually might manage that, even with the extra overhead that mesa might impose
<servili007>
any concerns with further legal action?
<libv>
oh, none whatsoever
<libv>
i know what i am doing :)
<servili007>
hehe
<libv>
and ARM knew what i was doing since at least June 2011
<libv>
as i described in detail what i was doing, how i was doing it
<libv>
and all they could do was whine about the name when i gave them a few weeks notice before the big announcements at FOSDEM
<libv>
FOSDEM2012
<servili007>
right, remali?
<libv>
yes
<libv>
anyway, ARM management hates the project, but there is nothing that they can do to stop it, and they have been given many opportunities to proactively help lima, but utterly refused to do so
<libv>
lima is going to be very bad marketing for them
<libv>
in as far as it hasn't been already
<libv>
i should actually do with lima like i did with unichrome back in 2005
<libv>
sprinkle "$company does in no way endorse or support this project" everywhere
<servili007>
no doubt. I'm still amazed at how often we have someone put out hardware with half baked software, shun free open source help (yes it's a legal headache for them too), then see their product take off and not even concern themselves with bettering the software side
<naobsd>
(just a monologue: I want to try q3a on some boards with Mali)
<libv>
servili007: the arm code does not seem too bad tbh
<libv>
servili007: but it's a hassle to deal with binaries
<libv>
and it will not migrate to upcoming windowing systems and such
naobsd has quit [Quit: Page closed]
<servili007>
you mean you don't want precompiled, once and done drivers!?
<ssvb>
atiti: basically, g2d can do various 2d operations with arbitrary buffers in the physical memory
<oliv3r>
rz2k: i don't have push access to the kernel, only u-boot
<rz2k>
oh, sorry then :p
<oliv3r>
and if something gets properly reviewed on the ML; i don't mind pushing u-boot stuff from patches :)
^vincenzo^ has quit [Remote host closed the connection]
^vincenzo^ has joined #linux-sunxi
<oliv3r>
but yeah, there's tons of patches that need reviewing and mergin
<oliv3r>
but we need an 'overview' at the least
<ssvb>
atiti: and disp is responsible for making sure that you see the pixels from your framebuffer (which is also some area in the physical memory) on lcd, hdmi, vga or any other output device
<atiti>
sweeet, so the mixer processor can do scaling and colorspace conversions etc in hardware
<ssvb>
yes, it can
<oliv3r>
menmeoc asked if someone was able to have a tree, that he could pull; but nobody responded :)
<atiti>
and those memory regions the mixer works with gets displayed by the disp
<oliv3r>
so the disp engine could be rewritten, without affecting the fb driver, mali driver, cedar driver
<atiti>
nice, thanks ssvb
<ssvb>
atiti: disp can also do scaling and colorspace conversion on the pixel data sent to hdmi/lcd/...
<atiti>
in hardware?
<ssvb>
atiti: actually disp has also 'writeback' capability, so it can store the scaled and colorspace converted result back to the memory
<ssvb>
yes, disp and g2d are both hardware units, and some of their functionality is overlapping a bit
hipboi_ has joined #linux-sunxi
<atiti>
ah, i see
<ssvb>
disp provides better quality scaling if you check the documentation :)
<oliv3r>
ssvb: so disp could be rewritten and cleaned up without affecting much of the rest?
<ssvb>
oliv3r: disp has a shitload of weird ioctls, which need to be preserved if we want not to break android
<ssvb>
oliv3r: but if you mean the mainline kernel, then nobody stops anyone from reimplementing if from scratch
<oliv3r>
ssvb: interesting and curious :)
<oliv3r>
pff, android
<ssvb>
oliv3r: hipboi_ seems to be back :)
<ssvb>
Turl: ^
<oliv3r>
hipboi_: hey Tom!
<Turl>
ssvb: yep I'm talking with him :)
<ssvb>
ko :)
<ssvb>
ok
<hipboi_>
hi
<hipboi_>
yes
<hipboi_>
new life in Shenzhen now
<oliv3r>
hipboi_: good stuffs!
<oliv3r>
hipboi_: I never had a chance to thank you for c2 and uSD adapter; thanks :) arrived well in time :)
<oliv3r>
hipboi_: been using it to hack stuff allready, u-boot atm mostly :)
<hipboi_>
oliv3r, good to hear
<rz2k>
ssvb: lets make a local tree with all the patches in the tube and then I can test them on a13 and you can do same on a10
<rz2k>
then mnemoc will pull it
<oliv3r>
hipboi_: once my patches are merged we should have equal performance as boot0, so all is well :)
<ssvb>
oliv3r: except that the boot0 does not show great performance either
<Turl>
rz2k: ++
<oliv3r>
ssvb: well that's something we might not be able to help/fix
<oliv3r>
AW knows the memory details
<ssvb>
oliv3r: the memory latency for a20 is still worse than a10
<ssvb>
oliv3r: yes, there's nothing we can do
<oliv3r>
kinda sucks really :(
<oliv3r>
i mean we can randomly try and tune bits and pieces
<ssvb>
oliv3r, hipboi_: I wanted to post some a20 benchmarks in my blog, but currently I'm holding back because memory is likely still misconfigured and the cpu is likely underclocked
<ssvb>
oliv3r: randomly trying is not the best thing we can do
<hipboi_>
cpu clock is limited
<hipboi_>
problem of the chip itself
<oliv3r>
912 MHz highest reliable safe speed?
<hipboi_>
yes
<ssvb>
hipboi_: is this going to be resolved in future a20 revisions?
<oliv3r>
hipboi_: i know you probably can't tell, but is the dram controller AW's own IP, or is it someone elses
<hipboi_>
all the current a20 product is 912M
<hipboi_>
ssvb: it should be resolved in the future version of the chip
<oliv3r>
so A20 r2 could see higher clocks?
<oliv3r>
or will they skip a20 r2 and just go for a40 :)
<hipboi_>
they use A, B, C
<oliv3r>
this what we have now is revA? or allready revB
<hipboi_>
revA currently
<hipboi_>
allwinenr is punched by rockchips now
<oliv3r>
aye
<oliv3r>
but rockchips OSS support is much worse
<oliv3r>
so who knows
<oliv3r>
will AW do a revB for A20 or go to something new and not waste resources on the A20
<hipboi_>
so allwinner is promoting that it support OSS
<ssvb>
hipboi_: do you know what cpu clock frequency is used in Mele A5?
<hipboi_>
and their official weibo is posting open hardware
<oliv3r>
hipboi_: LOL
<hipboi_>
eoma, olimex, cubieboard
<oliv3r>
support is a strong word ;)
<hipboi_>
all list there
<oliv3r>
but yes, this is something we can use to our advantage
<oliv3r>
but they still need to help us with docs (and cedarX source)
<hipboi_>
a31 is treated as a failure at allwinner
<hipboi_>
so they came up a31s
<Tsvetan2>
hipboi_ but the price is very attractive, A31 in volume is about $15
<hipboi_>
rk3188 is 12$
<mripard>
hipboi_: what's the difference between the two?
<Tsvetan2>
right but they do not sell to mortals
<mripard>
(a31 vs a31s ?)
<oliv3r>
a31s 'for phablets' eva says
<Tsvetan2>
:)
<hipboi_>
a31s is 32bit memory
<hipboi_>
and one channel nand flash
<oliv3r>
so it's a castrated a31?
<Tsvetan2>
rockchip have some proxi lady on the phone Wendy Lin and she will connect you to salesman only if you know his Chinese name :))))
<hipboi_>
:D
<Tsvetan2>
chicken - egg problem :)))
<Tsvetan2>
a31s is crap
<hipboi_>
the biggest bug of a31 is the memory clock can not run high
<Tsvetan2>
no ethernet
<hipboi_>
the memory bandwith is limited
<libv>
pvr!
* libv
shuts up again
<Tsvetan2>
libv: hear hear :)))
<andoma>
:)
<libv>
Tsvetan2: to my first, or to my second statement? :p
<hipboi_>
rk3188 is mali
<hipboi_>
so...
<hipboi_>
and i visited rockchips last week
<ssvb>
hipboi_: rk3188 based cubieboard?
<oliv3r>
applying for a job there?
<libv>
hipboi_: are kernel and u-boot source available?
<oliv3r>
linux-sunxi shifts work towards rk thanks to hipboi :)
<hipboi_>
libv, kernel source available
<libv>
and if so, has a community developed even half as well as sunxi?
<libv>
how long will that community remain, or does that community have an established feeling like sunxi has these days
<Tsvetan2>
libv: nope
<Tsvetan2>
but there is #linux-rockchip channel
<Tsvetan2>
with few ppl there
<oliv3r>
i think it's 2 weeks old :)D
<Tsvetan2>
they have small progress
<oliv3r>
they started linux-rk because they where discussing rk inhere :)
<libv>
i think the sunxi movement is 1.5ys old by now
^vincenzo^ has quit [Remote host closed the connection]
<libv>
i think i ordered my mele exactly a year ago
<oliv3r>
no u-boot sources is ouch :S
^vincenzo^ has joined #linux-sunxi
<Turl>
I think I saw rk support on mainline
<Turl>
or maybe it was sth else
<Turl>
let me check
<ssvb>
the competition is good
<mripard>
Turl: yeah, it's been merged in 3.11 iirc
<hipboi_>
yes, it's mainlined
<hipboi_>
very initial
<libv>
yes, but for some reason shortlived communities which might vanish 3 months from now are not very productive
<mripard>
yet quite featureful already
<ssvb>
maybe we will see more oss friendly hardware, and the vendors will become less secretive?
<oliv3r>
what do we have for rk? same as initial sunxi 3.8 patch?
<mripard>
rockchip seems to use a lot of standards IP
<oliv3r>
ah, that helps
<mripard>
like they use the synopsys MMC controller
<oliv3r>
well allwinner might too, but they keep it secret what they use :S
<mripard>
so they already have SD support
<oliv3r>
i think one of the things AW should do, is list their own IP, so that atleast we can figure out what the other IP is
<Turl>
mripard: I think they just went shopping, then glued all IP together :)
<Tsvetan2>
libv: at $12 for 4 core Cortex-A9 while imx6 4 core cost $40 guess its only matter of time RK3188 to hit mainline
<Turl>
also hisilicon
<Turl>
dunno where they are from :)
<rz2k>
imx has a reason for that price
<mripard>
Tsvetan2: freescale has other guarantees however
<hipboi_>
rockchip will sell fifty million chips this year
<mripard>
like guaranteed 10 years supply or so, pin compatibility between each SoC in the same family, very good documentation
* rz2k
has a box with imx6, pci-e LTE modem and SATA harddisk
<Turl>
rz2k: 4G router? :p
<mripard>
operating temperatures are pretty good as well iirc
<rz2k>
somewhat
<Tsvetan2>
mripard: sure they cant sell so much as Rockchip and have higher expenses
<ssvb>
libv: why do you care (so much) if it's all the same mali?
Superpelican has joined #linux-sunxi
<libv>
ssvb: in order to be able to work with mali, i had to jump through a lot of hoops
<libv>
ssvb: the First_Steps and Binary_Drivers pages, and the sunxi-mali repos are results of that
<ssvb>
libv: but now it's not your problem anymore? as long as you have MP1, MP2, and MP4 hardware to test at least with some boards
<mripard>
Tsvetan2: I don't have hard numbers, but Freescale is pretty strong in the automotive/industrial markets
<ssvb>
libv: the rockchip community should be able to handle the basic adaptation
<libv>
ssvb: if everyone has the unbelievably short attention span that i notice so often, then i will soon have nothing left
<rz2k>
also dont forget that lower freescale's have E-Ink controller built in
<libv>
ssvb: and it is not my experience that communities who came into existence overnight produce useful results
<rz2k>
so many e-ink readers have imx5x or imx6s/dl
<libv>
ssvb: especially not in the shortlived soc world
<libv>
i am happy to be proven wrong
<ssvb>
libv: if rockchip really sells millions of these chips, then the SoC will be surely supported by somebody
<libv>
but the way in which some of my amalgamations of free-floating information got maimed on linux-sunxi.org, and the fact that i do from time to time still have to step in there to keep some sanity, does not make me very confident
^vincenzo^ has quit [Remote host closed the connection]
^vincenzo^ has joined #linux-sunxi
<libv>
ssvb: there have been many popular SoCs so far
<ssvb>
libv: frankly speaking, the mali documentation at linux-sunxi.org has been fine for more than a year
<Tsvetan2>
mripard: exactly high end automotive entertainment systems is FSC market and its probablt 1/200 of Rockchip/Allwinner tablet market size
<libv>
sure, none had the massive code disclosures as allwinner
<libv>
ssvb: i definitely do not agree with that
<ssvb>
libv: but there will be always some clueless and noisy people who fail no matter how good or foolproof is this stuff :)
<libv>
useful binary driver installation has only existed for a few months
<libv>
and absolutely no-one has stepped up to debianize it
<ssvb>
libv: the initial instructions provided by rz2k used to be very good
<libv>
which i find rather awkward
<oliv3r>
well the linux-sunxi community isn't producing as much as we could either
<ssvb>
libv: your new instructions are slightly better, but it's not a big deal
<libv>
and which is a sure sign of something having skewed significantly in the linux world in the last decade
<oliv3r>
mnemoc being busy doesn't help of course; but it's been a while since patches have been posted
* oliv3r
should get back to work and fix his driver :)
<libv>
ssvb: my new instructions?
<libv>
ssvb: it basically tells people to use the build system that was created to handle things properly
<libv>
but even that gets made more awkward or confusing than it needs to be
<libv>
from time to time
<Turl>
libv: binary blobs don't play too nice with DFSG :P
<ssvb>
libv: yes, there was not a *big* problem to begin with
<libv>
Turl: i said debianization, not uploading to debian servers
<Turl>
excuses aside, I think bfree was going to debianize some stuff
<libv>
Turl: that was 5 months ago
<Turl>
libv: well, we got emac on debian officially :)
<rz2k>
dont take me into this, I documented stuff that worked and nothing more. if that was not enough to have a magical cookie from libv, I am sorry for taking time. No one cared to delete that page at that time if it was awkwardly bad.
<rz2k>
great to see that it was replaced with better stuff
<libv>
rz2k: i am not critisizing you or what you documented
<libv>
it was already an improvement, and at least some knowledge documented
<ssvb>
rz2k: it took me just a few hours to get everything up and running with no prior experience, and your wiki page helped a lot, that's why I think it was good enough
<libv>
anyway, with all the difficulties that sunxi has already, for what seems an arm soc community with continuity, i am not too hopeful of other "communities" which spring up
<libv>
the androidization of the users has spread too far imho
<libv>
and the people with a clue will do actual code before anything else
<libv>
and there is no one handling the bits in the middle, noone doing the glue
<oliv3r>
i have to agree with libv here, our community is kinda dormant atm as it is :)
* oliv3r
shuts up again and starts to code more
<libv>
and i see no way to fix this, it's how the world has evolved in the last decade
<Turl>
oliv3r: fix SID and get it merged :P
<oliv3r>
Turl: i don't know how :p that's why i'm avoiding it
<oliv3r>
i'll go to the bathroom and look at it again
<oliv3r>
:p
<libv>
there is just one way to kind of deal with this, and that is the realization that SoCs and SoC vendors will play hopscotch every few weeks
<libv>
and that it is a waste of time to jump on every new SoC
<libv>
you end up scratching the surface, and then running off to the next SoC
<libv>
never achieving anything.
<libv>
just leaving a little mess every few meters, where others are then free to tread in
naobsd has joined #linux-sunxi
<rz2k>
about glue - I like freescale in this aspect, they have customized version of ubuntu 11.10 with everything already prepared to use. Like VPU drivers already compiled in gstreamer
<rz2k>
and many more
<hno>
oliv3r, yes, no work today. Still trying to get that vacation thing started...
<oliv3r>
hno: good! vacation is important :)
<oliv3r>
rz2k: that's still blob-glue
<oliv3r>
we want sources :)
<rz2k>
they have sources for each package
<rz2k>
you can grab it and build your own image
<libv>
rz2k: this is one of my gripes with hardkernel and their odroid
<libv>
rz2k: you can dl android and ubuntu images... and that's pretty much it
<mripard>
oliv3r: freescale is probably the architecture that have the better mainline support
<libv>
you have a really uphill battle to do anything else
<libv>
and good luck in a year or two, when you might want to use a newer distribution
<libv>
this is beyond the limitations of binaries though, you just get an image, and have no idea what is different from a standard ubuntu
hegemoOn has left #linux-sunxi [#linux-sunxi]
<rz2k>
oliv3r: they have only one problem - the GPU (vivante) drivers are only armEL, no armhf :( everything else, like gstreamer support, udev patches and etc is opensource @ download section
Superpelican has quit [Ping timeout: 246 seconds]
<rz2k>
libv: odroid never cared about the software quality, I bet because samsung itself doesnt care about it. for example, s5p-mfc in mainline kernel is horribly broken and will never work without 5 patches that you can get emailing the author of this driver.
<oliv3r>
rz2k: i bet there's no VPU sources :)
<rz2k>
oliv3r: its firmware blob that loads into some place of memory, everything else, iirc, is free.
<rz2k>
(frontend I mean)
<libv>
rz2k: yeah, my experience from the display side is the same, pretty f-ing useless indeed
<libv>
rz2k: but at least samsung actually employs people to deal with code
<libv>
allwinner on the other hand...
<libv>
we are their developers :p
<oliv3r>
i have that feeling too
<rz2k>
oliv3r: samsung's VPU s5p-mfc has same idea - blob loads at boot time and then you have v4l2 interface, but freescale actually gives you a frontend
<rz2k>
if anyone is interested, you can grab GK802 dongle
<oliv3r>
with cedarx-re work going on, that's actually possible in time
<ssvb>
oliv3r: I'm fine with being an unpaid allwinner developer as long as they at least provide full documentation
<ssvb>
oliv3r: not employing their own developers just makes things happen slower
<ssvb>
oliv3r: and sometimes it is even good, because frankly speaking, I'm a bit freaked out by samsung approach
<oliv3r>
what is samsung's approach?
<oliv3r>
i have no huge issue with it, but documentation, really
<Tsvetan2>
ssvb: allwinner would never understand why they need linux at all and things with Rockchip are x10 times worse than Allwinner, Rockchip is Allwinner 1.5 years ago
<oliv3r>
we need it if they want our help.
<ssvb>
oliv3r: no important documentation is available, and their developers are pushing the stuff of questionable quality to mainline :/
<rz2k>
oliv3r: actually, I dont think that it can be called a blob-driver, driver itself is free, only firmware that gets loaded into the VPU's memory is closed source.
<oliv3r>
allwinner is actually 'abusing' us if I belive hipboi, in that they are very open and support etc
<oliv3r>
rz2k: if you put the entire 'driver' int he blob and only have a shim that passes messages (think rpi-opengl blob)
<oliv3r>
in that regard, allwinners design isn't bad
hipboi_ has quit [Ping timeout: 248 seconds]
<ssvb>
oliv3r: basically samsung is kinda suggesting to take a back seat, and just consume whatever they toss over the fence
<rz2k>
i remember, Eva from allwinner actually sent people here when questions about linux kernel were asked in support :p
<ssvb>
oliv3r: and because they are only caring about android...
<oliv3r>
ssvb: ah ok, 'bow to samsung'
<ssvb>
oliv3r: about the raspberry pi firmware, I find it most amusing that the noisy people to complain about these 'blobs' were the beagleboard folks
<oliv3r>
really?
<oliv3r>
the irony
<oliv3r>
libv was quite verbose too :)
<rz2k>
lol
<mripard>
ssvb: except that you can boot the beagleboard without any blob
<ssvb>
oliv3r: omap chips used in beagleboard boot in non-secure mode thanks to some restrictive rom, and the access to a lot of hardware registers is locked out
<ssvb>
mripard: ^
<ssvb>
mripard: it caused some fckup when applying cortex-a8 errata workarounds, and also misconfigured dram controller in omap4430 simply had to remain misconfigured
FR^2 has joined #linux-sunxi
<libv>
oliv3r: i just pointed out the actual structure of the videocore graphics driver stack, and exposed that the rpi foundation was actually massively overplaying its hand
<libv>
oliv3r: airlied had to take it a few steps further, and spewed useless bullshit because of it
<libv>
"_i_ will never accept that in the kernel"... great, this while the same SoC has mach support...
<libv>
but what do you expect from brainless idiots who always have to be loud, whether they have something to say or not, who even go as far as killing real open source projects as they themselves are not seen to be leading them
\\Mr_C\\ has joined #linux-sunxi
<oliv3r>
so true
<oliv3r>
*code monkey goes back to code*
geecko has joined #linux-sunxi
<geecko>
491MB ram, yay :D
<geecko>
now zram
<Turl>
oliv3r: go go go :p
hipboi_ has joined #linux-sunxi
<oliv3r>
Turl: you better help me when i get stuck :)
* Turl
hands oliver a copy of torvalds' repo
<wingrime>
when we can expect new SoC form AW ?
<FR^2>
tomorrow.
<oliv3r>
Turl: the problme is, what i'm doing, nobody did i think
<oliv3r>
Turl: so little/no examples to follow
<oliv3r>
greg's blog post doesn't even explain it
<Turl>
oliv3r: implement soc bus support :p
<oliv3r>
if i did a 'normal' sysfs entry, easy, but binary ones are not done
<oliv3r>
Turl: hah
<oliv3r>
Turl: i lack skills for that :)
Quarx has joined #linux-sunxi
<Turl>
oliv3r: looked quite trivial to me
<oliv3r>
writing the whole framework
<Turl>
the framework is already there
<Turl>
just needs sunxi stuff :)
<oliv3r>
ohh
<oliv3r>
ok; i'll put it on my todo :)
<oliv3r>
let me get this stuff merged first :S
<wingrime>
Turl: who can do debianizing?
<wingrime>
Turl: I want see all staff only with debbootstrap
<wingrime>
oliv3r: cedar work faster with disp together
<atiti>
you guys are awesome :)
<ssvb>
wingrime: that was my patched mplayer fork, worked pretty good on a 252MHz ARM9E processor
<wingrime>
ssvb: cool, how you make it fly?
<ssvb>
wingrime: mplayer supports many video out plugins (the x11, xv, gl, fbdev, ... are all plugins), you just need to implement a new one
hipboi_ has left #linux-sunxi ["Leaving"]
<ssvb>
wingrime: but as I said, a "cleaner" solution is support for Xv overlay in the xorg driver
<ssvb>
wingrime: so that no modifications are necessary for mplayer
<wingrime>
ssvb: agree Xv can be used again when we drop disp
<ssvb>
wingrime: still it might be slowed down by an extra buffer copy
<atiti>
and X is a memory hog
<ssvb>
atiti: how so?
<wingrime>
ssvb: why X11 can't use memory mappings
<ssvb>
atiti: most of the memory in xorg is allocated on behalf of the applications
<ssvb>
wingrime: it uses shm
<atiti>
could be
<wingrime>
ssvb: as disp can be used for UYV , YCrCb , XV even for software decoding can do much help
<ssvb>
wingrime: yes
<ssvb>
wingrime: technically the scaling and colorspace conversion can be done quite efficiently with NEON (though it is not done yet in mplayer/ffmpeg!), but most important is video playback without tearing
eebrah is now known as eebrah|away
<wingrime>
ssvb: also I still have no idea how make cedarx work with mmu'ed memory
<wingrime>
ssvb: It will be cool remove reserved memory for it
dragonn has joined #linux-sunxi
<ssvb>
wingrime: cedarx will not work with mmu, it needs physically contiguous memory, which needs to be mapped to userland
<ssvb>
wingrime: CMA is the right keyword
<ssvb>
wingrime: without CMA we have to use boot time reservations
<wingrime>
ssvb: so mail need physically contiguous memory too?
<ssvb>
wingrime: no, mali is the most problem free driver with regards to memory reservations
<ssvb>
wingrime: mali has its own mmu and can work with arbitrary memory pages
<wingrime>
ssvb: CMA awalible on current 3.0/3.4 ?
<ssvb>
wingrime: no, but CMA can be backported
<ssvb>
wingrime: you can search the linux-sunxi mailing list for the older CMA related posts
<wingrime>
ssvb: interesting
<wingrime>
ssvb: it still not mainlained?
<wingrime>
ssvb: I see CMA have patches for 2.6.39
<ssvb>
wingrime: it is
<ssvb>
wingrime: one of the kernels after 3.4
<ssvb>
wingrime: don't remember which one exactly, but you can google for it
<rellla>
is linux-sunxi git repo not forkable atm?
<FR^2>
libv: I own a cubieboard2 (A20), where could I get the matching kernel (and modules)? In the installation I'm currently using the mali module is missing.
<wingrime>
libv: ops
Superpelican has quit [Read error: Operation timed out]
FR^2 has quit [Quit: Connection reset by peer]
hglm has joined #linux-sunxi
<hglm>
wingrime: I have the same experience with a Thumb2 kernel, it compiles but doens't boot, no console output. I think Thumb2 kernel has never worked for linux-sunxi. I added some comments to the wiki about this (http://linux-sunxi.org/ARM/Thumb-2#Status_of_Thumb-2_support_for_linux-sunxi). Userland Thumb-2 seems to work fine.
Black_Horseman has quit [Ping timeout: 264 seconds]
<oliv3r>
Turl: are you around?
<Turl>
oliv3r: sup
<oliv3r>
good
<oliv3r>
cause i looked over everything and I don't see why it doesn't work
<rz2k>
hglm: any chance for you to attach jtag?
<oliv3r>
let me get some pastebin magic going
<rz2k>
hglm: hno attached OpenOCD jtag via ftdi2232, iirc. other OpenOCD supported adapters should work too
<hglm>
rz2k:I only have a tablet, USB serial console gives no output but it is probably too late in the booting process.
<rz2k>
do you have any development boards with ftdi2232? like, Xilinx fpga kits, beageboard?
<rz2k>
they all use this MCU and it can be used for sunxi jtag
<rz2k>
s/beageboard/beagleboard/
^vincenzo^ has quit [Remote host closed the connection]
<rz2k>
busblaster from dangerous prototypes can be also used
^vincenzo^ has joined #linux-sunxi
<hglm>
rz2k, no I don't. I am not very experienced with remote debugging.
<rz2k>
you should try it if you are doing such low level stuff like thumb2 compiling
<hglm>
rz2k: Yeah it would be useful to see where it fails. I could also try disabling most drivers.
<oliv3r>
you changed the 'read' function to a 'show' function
<oliv3r>
so that's the reason it crashes then
<Turl>
yes, and had to skip all the kobj to platform stuff
<oliv3r>
yeah
<oliv3r>
well if its just to show a point; yeah
<Turl>
because it would return me null stuff somehow
<oliv3r>
if it has to be a textual sysfs entry, so it be, but i still prefer binary
<hno>
Hm.. is all of them having a printable string in char 4-11?
<Turl>
yeah ask greg :P
eebrah|away is now known as eebrah
<Turl>
hno: yeah PHY kind of makes sense in the context
<Turl>
but it might be just a coincidence
<atiti_>
what is that?
<atiti_>
unique serial number?
atiti_ is now known as atiti
<hno>
Turl, how does it make sense?
<Turl>
hno: well, PHY :P eth PHY
ganbold__ has joined #linux-sunxi
<Turl>
atiti: yes, or crypto keys if you wish to
<hno>
Turl, SID have nothing to do with ethernet.
<Turl>
atiti: also useful to identify SoC
<atiti>
Turl: sweet, is it guaranteed to be unique per SoC?
<oliv3r>
you can use SID for MAC address
<hno>
And no, at least char 4 is not printable on all.. 50% have 0x80 there.
<oliv3r>
i think hansg does that with ones that don't have one
<Turl>
hno: I know, but PHY "makes sense", if it said CAR it wouldn't
<hno>
oliv3r, not realy. You can generate a inofficial MAC from it, but it's not a MAC.
<Turl>
atiti: I dunno, some of them have all 0s, like they forgot to burn them :)
<oliv3r>
ok we do inoffcially
<Turl>
oliv3r: feel free to add to wiki btw, this is a10s olinuxino micro
<oliv3r>
but a manufacturer could store their real one, next to the soc ID and a short serial
<oliv3r>
Turl: thanks
<hno>
3 of my boards have all 9.
<hno>
all 0.
<atiti>
ah
<atiti>
that sucks kinda
torindel has joined #linux-sunxi
<hno>
oliv3r, yes, but it's easier to just stuff the MAC into the NAND.
<oliv3r>
of coruse
<oliv3r>
just 'an' option
<oliv3r>
also, this can be for those really low cost devices
slapin_nb has joined #linux-sunxi
<hno>
oliv3r, really low cost devices do not have ethernet.
<oliv3r>
it's just an option, not a requirement :)
hurtigbuffer has joined #linux-sunxi
<hno>
The SID could in theory be used for a trusted boot path, but from what I can tell it's not implemented.
ganbold has quit [Ping timeout: 248 seconds]
<hno>
so for now I consider it just an optional serial number in structured form.
ZaEarl__ has quit [Ping timeout: 248 seconds]
jelly-home has quit [Ping timeout: 248 seconds]
torindel_ has quit [Ping timeout: 248 seconds]
slapin_n1 has quit [Ping timeout: 248 seconds]
<oliv3r>
and entropy seeding :)
FR^2 has joined #linux-sunxi
notmart_ has joined #linux-sunxi
notmart has quit [Read error: Connection reset by peer]
atiti_ has joined #linux-sunxi
atiti has quit [Ping timeout: 276 seconds]
alcides has joined #linux-sunxi
eebrah is now known as eebrah|away
eebrah|away has quit [Read error: Connection reset by peer]
<hno>
oliv3r, it's not really an entropy source. But adding it to the entropy pool at least do no hurt..
<hno>
but do nothing to improve the entropy of a single server.
notmart_ has quit [Quit: notmart terminated!]
n01_ has quit [Read error: Operation timed out]
dragonn has quit [Ping timeout: 252 seconds]
dragonn has joined #linux-sunxi
dragonn has quit [Client Quit]
dragonn has joined #linux-sunxi
dragonn has quit [Read error: Connection reset by peer]
dragonn has joined #linux-sunxi
dragonn has quit [Client Quit]
dragonn has joined #linux-sunxi
dragonn has quit [Client Quit]
dragonn has joined #linux-sunxi
hglm has quit [Quit: leaving]
dragonn has quit [Ping timeout: 240 seconds]
vrga has joined #linux-sunxi
<vrga>
'lo folks. got a interesting one, is there a way to pull script.bin out of a pre-existing .img file provided by the tablet manufacturer? sadly, my tablet is proving to be unrootable, so i cant get it from there, and i havent found anything on the topic of working with it around the net.