focus_it has quit [Remote host closed the connection]
<Turl>
is there any reason to keep r2 libs around still?
L84Supper has quit [Quit: <puff of smoke>]
L84Supper has joined #arm-netbook
<ssvb>
hramrach: ARGB cursors should be fixed now, it was one of the problems preventing real direct rendering without memory copy overhead for gnome-shell
<ssvb>
hramrach: now I just need to implement DRI2 buffers swapping in this roundabout way required by the mali blob
stefanro has quit [Ping timeout: 256 seconds]
<Turl>
ssvb: gnome shellcan run on gles? neat
stefanro has joined #arm-netbook
<ssvb>
Turl: yes, at least in linaro/ubuntu
cnxsoft has joined #arm-netbook
mSquare has joined #arm-netbook
gsilvis has quit [Read error: Connection reset by peer]
gsilvis has joined #arm-netbook
<Turl>
ssvb: what's the performance like?
<ssvb>
Turl: not very good, it seems to be quite heavily stressing the CPU (even with redundant memory copies eliminated)
<Turl>
:(
mSquare has quit [Ping timeout: 248 seconds]
mSquare has joined #arm-netbook
sv has joined #arm-netbook
discopig has quit [Ping timeout: 276 seconds]
mSquare1 has joined #arm-netbook
mSquare has quit [Ping timeout: 252 seconds]
sv is now known as discopig
Avernos_ has joined #arm-netbook
Avernos has quit [Ping timeout: 240 seconds]
cnxsoft has quit [Quit: cnxsoft]
Avernos has joined #arm-netbook
Avernos_ has quit [Ping timeout: 248 seconds]
aholler_ has joined #arm-netbook
aholler has quit [Ping timeout: 248 seconds]
mSquare has joined #arm-netbook
mSquare1 has quit [Read error: Connection reset by peer]
KoH__ has joined #arm-netbook
KoH_ has quit [Ping timeout: 248 seconds]
mSquare has quit [Ping timeout: 248 seconds]
eebrah has joined #arm-netbook
abesis2 has quit [Ping timeout: 256 seconds]
Eigen has joined #arm-netbook
mSquare has joined #arm-netbook
<libv>
Turl: there is little pain in supporting r2p4 as well
<libv>
and i will have to make this build a lot more complex, but that's fine, as the way the test was handled so far was suboptimal anyway
Eigen_ has joined #arm-netbook
fragmint has quit [Read error: Connection reset by peer]
Eigen has quit [Ping timeout: 240 seconds]
cnxsoft has joined #arm-netbook
Eigen_ has quit [Remote host closed the connection]
fragmint has joined #arm-netbook
abesis has joined #arm-netbook
pcat has quit [Read error: Operation timed out]
sky770 has joined #arm-netbook
rellla has joined #arm-netbook
sky770 has quit [Read error: Connection reset by peer]
<sky770_ORIG>
Turl: but I am still looking forward to a Cubieboard with 2GB of RAM (and a A20 will be icing on the top :D)
sky770_ORIG is now known as sky770
<focus>
To get a pl2303 USB-RS232 converter working, I need CONFIG_USB_SERIAL_PL2303=m in kernel config. Anybody know what that means?
<Turl>
focus: it means what you said
<oliv3r>
so far, no A20 cubieboard though :(
<oliv3r>
WHEN! WHEN!
<Turl>
make menuconfig and enable it
<focus>
Turl: I plead ignorance, what must I do next - find kernel config file, add the line and recompile the kernel?
<Turl>
focus: make whatever_defconfig; make menuconfig
<Turl>
then choose it on the pretty menus
<Turl>
then compile kernel
<zumbi>
mnemoc: hey, what's up?
<focus>
This for pengpod - so I guess download his kernel to the pengpod from here https://github.com/npeacock/linux-sunxi, and then do what you tell me to do?
<Turl>
yeah, make pengpod_a10_max_defconfig; make menuconfig; choose, compile
<focus>
Turl: thanks - I work on that
mSquare has quit [Remote host closed the connection]
Brandon15811 has quit [Excess Flood]
Brandon15811 has joined #arm-netbook
rellla2 has joined #arm-netbook
rellla has quit [Ping timeout: 264 seconds]
eebrah has joined #arm-netbook
z72ka has joined #arm-netbook
cnxsoft has joined #arm-netbook
<hramrach>
ssvb: I can't say I see some general performance improvement but at least the animated 'beachball' cursor looks way better now :)
<hramrach>
thanks :)
<ssvb>
hramrach: these fixes were just needed to ensure that the cursor always stays on top and never goes under disp layer
<ssvb>
hramrach: it avoids the memory copy done on CPU, but also shows that we need real double buffering to get correct rendering in gnome-shell instead of using the same buffer and treating buffers swap as no-op
herdingcat has quit [Quit: Leaving]
<ssvb>
hramrach: or more like to get correct picture visible at any time, this is exposed only by gnome-shell so far (for example kwin_gles or other gles applications don't seem to be affected)
<ssvb>
hramrach: but I'll try to get it working later today
<hramrach>
hmm, I don't see what is wrong with that mali expectation
<hramrach>
except you might need to allocate new buffer before doing swapbuffers I guess
<hramrach>
hmm, I wonder if the semantics are defined for this
<hramrach>
in the GL spec or wereever
<hramrach>
you expect that for N buffernigh application has allocated N buffers and cycles between
<hramrach>
but in fact the buffers are not cycled that way and you can get any random buffer
<hramrach>
so mali just goes with that an only allocated the back buffer to which it is going to render
<hramrach>
maybe it's just DRI2 bug it does not work
<ssvb>
the code in the DDX driver is just a simple backend which allocates or destroys buffers
<ssvb>
we have a DRI2 framework in the X server which decides what exactly needs to be created or destroyed
<hramrach>
which is likely largerly untested except with the current X drivers
<ssvb>
and there is a bit of misunderstanding between the mali blob and this DRI2 framework
<hramrach>
so when you do something differently you are likely to hit a bug
<hramrach>
basically swapbuffers should move the back buffer one place towards the front as I understand it
<ssvb>
what we need to do now is adding an ugly workaround in the DDX driver, so that it would handle the buffers not exactly in the way it is asked, but in the way the mali blob seems to intend to incorrectly request them
<hramrach>
I still don't see what is incorrect with what the mali blob does
<hramrach>
it alocates back buffer, renders, swaps buffers, and allocates new back buffer for rendering, right?
fragmint has quit [Ping timeout: 245 seconds]
<ssvb>
the mali blob happens to be rendering to the already destroyed buffer, this can't be right
<ssvb>
because it thinks that this destroyed buffer is actually the correct one
pcat has quit [Ping timeout: 252 seconds]
<hramrach>
so it tracks the buffers incorrectly
<hramrach>
or maybe thinks there are actually only two buffers :s
<hramrach>
and just tosses the buffere obtained with getbuffers
fragmint has joined #arm-netbook
<ssvb>
there are two buffers, but the way mali blob requests them, we first get 4 buffers created, then 2 of them are immediately destroyed
<ssvb>
the mali blob thinks that it has two buffers, but one of them is correct and another one is destroyed from the X server point of view
fragmint has quit [Read error: Connection reset by peer]
<ssvb>
and the second correct buffer just remains unused
<hramrach>
hmm, so on getbuffers you get front *and* back even if you requested only back
<ssvb>
yes, that's something weird in DRI2
<hramrach>
and when you swap the backbuffer gets destroyed?
<hramrach>
that's really odd
<ssvb>
yep
<ssvb>
anyway, I'll try to handle some sort of workaround in the DDX
<hramrach>
that sounds like dri2 bug
<hramrach>
swapbuffers has no business destroying backbuffers
<ssvb>
you are free to debug it and contribute a fix :)
<hramrach>
what would be the point of backbuffers then /o\
<ssvb>
the old backbuffer gets destroyed when you request a new one, not when you swap it
Ershov has joined #arm-netbook
popolon has joined #arm-netbook
<hramrach>
but it's supposed to be on hte front now?
<ssvb>
that's what the mali blob thinks
<hramrach>
well, technically the blob never requested a front buffer so it is not required that the front buffer pointer is valid
<hramrach>
but you are supposed to draw to the back buffer so what does it use the buffer for?
fragmint has joined #arm-netbook
eebrah has quit [Remote host closed the connection]
Ershov has quit [Ping timeout: 248 seconds]
Ershov has joined #arm-netbook
Ershov has quit [Read error: Connection reset by peer]
<hramrach>
oh yeah, the disks using this cable are called ZIF interface disks
<hramrach>
but FFC connector should give you the results you want
<hramrach>
they are more like SIF, anyway
<hramrach>
it's not like you put the cable on the connector and it just drops in as is the case with the CPU ZIF sockets ;-)
focus has quit [Quit: Leaving]
focus has joined #arm-netbook
<oliv3r>
with the CPU sockets you still have to lock the lever in place, so it's quite similar :p
<oliv3r>
so it's not a LVDS intervace, but disk interface!
tinti has joined #arm-netbook
<focus>
Hi, is there some instructions somewhere to set up cross compiler so I can compile a kernel on a x86? I left my Pengpod at home + I don't think I got enough space on that left now.
<hramrach>
oliv3r: it may be any interface. it just connects wires
<RaYmAn>
focus: plenty, it's pretty generic, so google it :)
<focus>
I suppose I should have :( too lazy
<focus>
My excuse is that this be first time I be doing it.
<oliv3r>
focus: pure kernel? ARCH=arm make menuconfig
<oliv3r>
ARCH=arm make :)
<focus>
I know how to use Eclipse. So I probably try that - or is it better to go command line?
<rm>
know how to derp deplipse
<hramrach>
I don't think eclipse has LInux kernel plugin ;-)
<rm>
click the above link, the instruction you need is the 1st result
<rm>
afk
<focus>
rm: looks like it be what I need. I work on it - thanks.
<w00tc0d3>
my desktop environment is getting way more 'elite' everyday oO I even don't want it lol
<w00tc0d3>
gnome 3 3 days ago -> awesome wm -> now configuring dwm oO
hipboi has joined #arm-netbook
herdingcat has joined #arm-netbook
cnxsoft has joined #arm-netbook
<focus>
anyone - 1GB RAM, but what max flash size A10 can support?
<hramrach>
thre is a datasheet somewhere - in chinese
<hramrach>
but large flash nand sizes are impractical - expensive
<hramrach>
there are 2 SDIOs so you can use one SD card as flash - at least 32G SDHC supported, maybe SDXC
<hramrach>
2+
<hramrach>
not sure how many really
<focus>
hramrach: I want min 16GB, 32GB ideal - but internal type - not the external SD card type
<hramrach>
you can mount SD slot inside case
<focus>
hramrach: the issue is the wearing - but then again F2fs is here, so may be its not a big issue once someone ports it to the A10
<hramrach>
the SD card can be replaced - infinite life
<hramrach>
soldered nand has limited write cycles
<focus>
But as you know, I'm building KiCAD boards, and I wanted to give the bigger option
<focus>
hramrach: you got a point there about replacing it on demand
<hramrach>
also 2GM ram is supported, theoretically
fragmint has quit [Read error: Operation timed out]
<hramrach>
but the memory controller is undocumented so nobody knows how to set it up
<focus>
May be I settle for the doable and then worry about the extended on 2nd iteration :(
<hramrach>
you may still have issues if you don't use the AW reference design
<hramrach>
differnt trace length or something - different timing parameters -undocumented
<focus>
hramrach: I bought the $1000 wits-tech dev kit
<hramrach>
I don't know what the kit includes
<focus>
The company wants a product built asap
<hramrach>
maybe you should have picked TI or something then
<focus>
The kit includes a beefed up tablet like device with lots of IO, 7" screen, a DVD with Android and the minimal lychee linux, plus board layout guides and other material that wits will email
<hramrach>
some company that can give you the docs for the outside interface at least
<focus>
TI is too expensive for the company
<hramrach>
board layot guides should help then
<focus>
The best now looking to be A10 or iMX6 series with its 6000 page documentation + much lower prices than what is advertised on web pages. Quad core is $18 I believe, dual is $14 and single is down to about $8.
<mnemoc>
what does the wits' kit give you that isn't already publicly avaialbe?
<focus>
Volume prices
<focus>
mnemoc: yep BIG Mistake!! - I found out about this IRC through some link in Aliexpress.
<mnemoc>
focus: :)
<hramrach>
plus perhaps the layout guides
<focus>
You known when working for company, the pressure is on, so the money gets spent with limited knowledge about all the things out there
<hramrach>
mining stuff from the interwebs costs money too
<mnemoc>
it's kind of facepalm-ish that wandboard doesn't make a quad variant, sell the so-dimm separatedly and neglects to include sata connector on their board
fragmint has joined #arm-netbook
<hramrach>
I find hardware design facepalmish most of the time
<hramrach>
but then I don't do it
<mnemoc>
:)
<w00tc0d3>
aight
<hramrach>
and I somewhat understand that once you send the PCBs for product run you have to live with what was designed there until next rev
<w00tc0d3>
finally a proper GTK theme
<focus>
hramrach: my aim is to release everything in open source KiCAD so anyone can make it to their own heart's content. I mean you want quad core? Sure put 4 A10's on the friggin board!! :))))
<hramrach>
would be interesting project to make that work
<hramrach>
but not very practical I suspect
<hramrach>
what interconnect would you use?
<hramrach>
spi?
<focus>
I fully intend - and very practical - because I am also building infrastructure prototyping boards
<focus>
hramrach: it is down to the person. You could put ethernet for each CPU - now you got 1 with LCD and 3 additional ones as headless servers!!!!!!! :)))))
<focus>
Quad core as you never seen em before!
<focus>
The one with LCD will run slow because it must share LCD RAM access and updates with software, but the other 3 do not, and run 10x quicker
<hramrach>
well, basically a tiny mosix cluster
<hramrach>
or what was the linux custering calles
<focus>
Or use the ports to directly talk to each other with a special protocol anyone can design (my intended focus of R&D)
<hramrach>
gpio interconnect, hmm
<focus>
Thats not clustering per se - the CPUs would have micro relays to power them out. They come on line if they need to be doing some serious work only.
<focus>
Currently the SoM2 board is currently reached stage of infrastructure break out board to build and test boards to destruction / prototype functions around it.
<focus>
I get 10 SoM boards built later this week with the CPUs soldered on at the factory.
<focus>
Then the fun begins :)
<hramrach>
good luck with that
<hramrach>
not sure what I would do with such device but I am sure you have some use cases since you are designing it ;-)
<focus>
We are hardware engineers and like software engineers we have 'ethics' about sharing. No one holds back a datasheet by convention. But ARM holds back and that is incredibly annoying. So when this project is finished, I'd be a lot happier because all engineers can design their own boards without being left out of the race.
rz2k has joined #arm-netbook
<hramrach>
as a not hardware designer I am more interested in actual application of such board
<hramrach>
at least teh design looks intereting but that would not be enough incentive to buy one I guess ;-)
aluclinux has joined #arm-netbook
<focus>
hramrach: may aim is Internet of Things IoT.
<focus>
I define IoT as innards of a capacitive tablet
<focus>
with Linux running on it
<focus>
So I can design any applications with say Gambas and then as I press the buttons on the tablet interface, it does something.
<focus>
So no need for real buttons on switches
<focus>
I got me a pengpod and it already does all that!!
<focus>
If I got a 5" and 7" innards of a capacitive tablet with linux running, then my company can use it by dropping the thing into their equipment to control it.
<pucko>
which dist can I use to crosscompile the sunxi-kernel?
<focus>
hramrach: The gambas program already communicates via serial RS232 optically isolated - so when it controls equipment, it just needs to run RS232 and send out messages, and log the responses and display them on the front panel
<focus>
Targe cost about $30, because all I want are the innards - no battery etc.
<RaYmAn>
pucko: any, assuming you have a suitable crosscompiler available.
z72ka has quit [Quit: Leaving.]
<bfree>
pucko: debian+emdebian works as described at http://linux-sunxi.org/Debian (and with gcc 4.7 for kernel 3.4 anyway) ... ubuntu also is painless
aluclinux has left #arm-netbook [#arm-netbook]
<bfree>
zumbi: are you trying to use the stock debian kernel packaging? it's a bit over the top and adds extra hassles (and if I remember right the docs bit triggered the cross-build problems) :-/ have you seen https://github.com/bfree/linux-sunxi-fll ? though I admit I've been compiling natively ;)
<zumbi>
bfree: yes, and no
<zumbi>
bfree: I have modified stock packaging to just create linux-image and linux-headers packages
<zumbi>
I have not seen that github tree
<bfree>
https://github.com/bfree/linux-sunxi-debian is as far as I bothered going with the debian style packaging ... imho it's just madness really until building a mainline kernel with a view to getting patches to debian
XenGi_ is now known as XenGi
<bfree>
zumbi: I actually have a new config now for sun4i since last night (well native compile finished while I slept) which has expanded it out to something more like a distro kernel (way more modular, needs an initrd) ... just have to actually install the package and test it works before pushing up the new config (which makes build time about 2.5 times longer)
<hramrach>
cheaper but sufficient for the application
<zumbi>
bfree: cool! I'll have a look
<zumbi>
bfree: those packages should probably go under l-s.o/debian
<bfree>
zumbi: I've barely begun sunxi-tools, which is the only other piece to make it enough to go from scratch to booting in to it (i.e. fexc) ... but that should be fairly easy
<zumbi>
bfree: right, not sure if at olimex someone was trying to work on those
<zumbi>
bfree: I started doing olinuxino mx233 board
<bfree>
zumbi: well I'd rather the fuller kernel and not just defconfig ... and I've only touched sun4i as that's all I have. and some docs and testing would also be useful before attempting to promote them (i.e. a proper repo in packages.l-s.o/debian)
<zumbi>
bfree: I have no sunxi hw
<zumbi>
but I would like to attempt to build images for developers
<zumbi>
then we can test-fix them
<zumbi>
but if no packages, no images, no test, no fix
<zumbi>
FOSS motto, release often, release early
<bfree>
zumbi: the big gap you might see in that github was me waiting for my cubieboard ;)
<zumbi>
:)
<zumbi>
bfree: I am pretty short on time for this stuff
<zumbi>
but still I think its worth doing
<zumbi>
but no hassle
<focus>
hramrach: need the sata for big devices with mass data storage such as security cams
<pucko>
bfree: I'll try debian then
<pucko>
current kernel have constants oops
<hramrach>
SATA is definitely best storage option on A1x so if you need store data locally, sure
<hramrach>
reportedly it can do up to 50MB/s but MMC and NAND is limited to ~10MB/s
anunnaki has quit [Ping timeout: 248 seconds]
<hramrach>
not sure about the nand, may be due to the installed nand chip
<hramrach>
but getting fast chips is difficult anyway
<focus>
hramrach: 128GB SATA SSD is about $120 - store 1 picture a second for 1 year from web cam :)
<mnemoc>
hramrach: i get 120MB/s with externally powered 3.5" drive, and someone in #cubieboard reported 200MB/s with ssd
<focus>
install and forget security
<focus>
On pengpod I got apache working
<hramrach>
anybody has any idea how large cards does A1x support?
<hramrach>
there is supposedly sdxc about which kernel babbles that it's not working every time you insert sdhc card
<focus>
So I reckon a simple web program on A10 + 128GB SSD + webcam and you got 1 year remotely accessible camera with LCD touch screen to tell you if you had visitors
<hramrach>
plus you can write the software so that it overwrites the old pics with the new pics after a year
<focus>
hramrach: yep! + its IoT so it can contact other IoT and let them know to turn on the lights :)
<focus>
Beeelllion of IoT devices being held back because of a lack of ARM documentation - soon to change with this IoT on KiCAD
<hramrach>
there is 128GB sdxc for sale
<focus>
They shoot themselves in the foot holding back documenation. I could have done this half a year ago if it wern't for lack of info
<hramrach>
but I doubt anybody tried that with an A10 device
<hramrach>
as a SoC maker you get chip info under NDA
<hramrach>
so you make some driver that somewhat works so you can demonstrate the SoC
Avernos has quit [Ping timeout: 248 seconds]
<hramrach>
and produce some marketing-speak datashit that does not reveal anything you are not allowed to
<hramrach>
and next year you license new chip core with docs under NDA and star making that, and forget about the old one
<hramrach>
maybe some SoC maker figures out that focusing on docs and fixing stuff makes better product
<hramrach>
but I am not so sure better product sells better
<hramrach>
it's marketing what sells stuff, not quality
<hramrach>
the market is moving too fast for quality to have impact
tinti has quit [Quit: Leaving]
<Gumboot>
I got my SATA up to 220MB/s. 50MB/s is rust-based?
<hramrach>
hmm, micro-sdxc is up to 64GB so far
<hramrach>
Gumboot: depends on the disk and driver you test with I guess
<hramrach>
good to know it goes higher
<Gumboot>
I should probably have done read speed tests when I had the fancy SSD plugged in.
<Gumboot>
(had to remove that for lack of power for writes)
<Gumboot>
I guess I could try harder to contrive a test which goes directly to the cache.
<Gumboot>
Also, I dare say that a lot of SoC vendors have a very strong disincentive to release any source code they _could_ simply because of all the negative PR it generates.
<hramrach>
does releasing source code generate bad press?
<Gumboot>
Yes.
<Gumboot>
Everything that is released can point to taint in things that aren't.
<Gumboot>
Which means that people just demand even more.
<Gumboot>
Releasing a little bit is just stirring that shit for yourself. It's not worth it.
cnxsoft has quit [Remote host closed the connection]
rsalveti_ has joined #arm-netbook
<hramrach>
if they can't really release the code there is not much point trying to go half-way and releasing GPL violating tree with every driver they have written in object form and claiming it's GPL and using the GPL licensed kernel symbols
<Gumboot>
Nobody criticises a completely closed system as much as one where they've not been able to do a thorough job of openening it.
<hramrach>
well, the system which was OpenWRT was thoroughly criticised for being closed
<Gumboot>
If you don't want shit flung at you, you should stay closed.
<hramrach>
they only released the code on demand from people complaining
rsalveti has quit [Ping timeout: 248 seconds]
rsalveti_ is now known as rsalveti
<hramrach>
also the NDAs and general secrecy is to avoid patent litigation. Patent trolls cannot sue you for info you have not released
<L84Supper>
I don't anything changing in China much over the next few years so I'd just get used to it and adapt.
<hramrach>
technically they could but they will focus on easier targets
<L84Supper>
in China they are more concerned about somebody copying their work too easily vs complying with the GPL
<hramrach>
copying is one thing
<Gumboot>
I don't think the drivers are an interesting thing to rip off, compared to the hardware.
<hramrach>
I don't think not releasing the drivers will stop anybody, in fact
<Gumboot>
Unless you're talking winmodems.
<hramrach>
but releasing htem is work (=cost) and most of the time they are not allowed
<Gumboot>
Releasing things under GPL is especially expensive because of the extensive review process.
<L84Supper>
if you could actually convince a supplier there that by releasing source would vastly increase their sales they would do it in a heartbeat, they just follow the easiest path to the money, nothing more
<Gumboot>
There's a whole lot of strict partitioning that has to be done.
<Gumboot>
L84Supper: They wouldn't simply go ahead and breach NDA. You have to convince the whole chain.
<hramrach>
it would allow more quality and longer lived products based on their chips
<focus>
hramrach: holding on to datasheets is not a done thing in chip circles - its a new thing in SoC circles. Billions get invested into making chip, and you want engineers out there producing products to create demand to get a return on chip manufacturing investment
<hramrach>
but the market is about spitting out cheap junk as fast as you can
<focus>
holding on to datasheets is like shooting yourself in the foot.
<Gumboot>
hramrach: Or expensive junk.
<hramrach>
spittoung out cehap junk and selling as expensive as you can
<L84Supper>
Gumboot: with money being the bottom line you'd be surprised by how suddenly creative the process of leaking source would become
<focus>
i think its big corporations forcing hardware companies to sign their NDAs and then forcing them to let other sign NDAs down the chain.
<L84Supper>
face and money, what else is there?
<focus>
probably media companies worst offender with their graphics chips and encoders - I really don't understand how it all works - but I know its a new thing
<hramrach>
well, you get to negotiate the terms when buying the chip IP
<hramrach>
but at that time not much thought is spent on the way the software side will be done I suspect
<focus>
hramrach: opencores.org - no need to buy any ip except for ARM core and graphics
<hramrach>
so they sign the NDA and are done with it
<focus>
yes I guess - too easy to sign NDA
<focus>
Lock out Linux through NDAs
<focus>
Lock out open source developers through NDAs
<L84Supper>
GPL is far from their focus, how does releasing source and the GPL increase their profits?
<L84Supper>
even if there was no NDA?
<hramrach>
yes, long term support is not the goal
<focus>
more products get made - more chip sales
<L84Supper>
thats not true
<L84Supper>
that's fantasy
* mnemoc
believes the only way is a shame campaign against ARM itself for implicitly supporting the GPL violations of their licensees
<focus>
L84Supper: to argue that way is to let the reverse be true also - i.e. no datasheets leads to more product sales :)
<mnemoc>
as it's not something than can be solved by legal or economic measures. only PR
<L84Supper>
hire Carl Rove or get Glen Beck to smear ARM with some GPL commie nonsense, it could work in the USA
<hramrach>
focus: no, good datasheet availability has very limited impact on chip sales
<focus>
mnemoc: or just one chip maker breaking ranks and publishing everything including graphics controller. It could be Microchip and their PICs with a 1GHz chip. All others must fail including ARM!!!!!!!
* libv
is getting somewhere with mali-libs now
pwhalen has joined #arm-netbook
<mnemoc>
libv: eh?
<libv>
if all goes well with autodetection: make; make install is all you need now
<mnemoc>
\o/
<hramrach>
because most manufacturers are fine producing devices with half-working GPL-violating software
<libv>
make config VERSION=r3p0 ABI=armhf EGL_TYPE=x11; make; make install is the worst case scenario
<focus>
hramrach: its price and datasheets and software together. Allwinner had price, and software grew around it and datasheets get leaked. It is best available save for iMX6 now which may has datasheets + low price but not the very big software support around it
<libv>
gets you a fresh libUMP.so.[23] as well
<hramrach>
focus: I agree A10 is best available at the moment. AW or ARM had no part in that incident most likely, however
<focus>
If Microchip bring out a Linux chip fully documented, then ARM will fail overnight. PIC chip has register names and names for bitfields - something which no ARM has - so software is not portable between chips!!!
<focus>
hramrach: yep! In fact they feed off it!! They tell me about sunxi site! Despite not being their own!
<libv>
focus: more !!!
<zumbi>
bfree: paste failure log
<zumbi>
bfree: while I was able to build mx233, when doing sunxi, it tried to build x86 instear arm arch
<focus>
I ask Microchip to bring out a 1GHz chip - but trolls jumped on it and spoiled the conversation
<hramrach>
what was the multicore chip with no grahics core again?
<focus>
hramrach: that problem is about to be nuked!! The KiCAD files will allow you to drop multiple CPUs to a board with copy and paste. One of those CPUs could be 100% graphics rendering chip with custom software. In fact it can 2 or more!! :)))
<focus>
So you have one CPU with LCD, and 1 or two doing the graphics rendering and talking through GPIO pins to the chip with LCD. Problem about 3D rendering sorted!
<focus>
No more graphics accelerators needed.
<focus>
If you want to spend $200 on a graphics card, then just get a card built with 20 A10's on it :))))
<bfree>
zumbi: I guess you want a whole build log, and that will take a little while to do on -j1 (for a clean log)? just the relevant part erroring out is dull, just a "file format not recognised" when arm-linux-gnueabihf-strip is called on the scripts/bin2c
<focus>
A lot more data bandwidth between one CPU and RAM than lots of cores and one RAM.
<hramrach>
focus: but problem getting all the data to hte display in the end
<focus>
So 20xA10 each with 1GB RAM has astonishing power.
<hramrach>
could do some whacky LVDS interconnect, though
<libv>
focus: sure...
<zumbi>
bfree: ok
<libv>
focus: so what will be driving the display then?
<focus>
hramrach: should not be a problem, because images are built up on a pipeline and so all it does is parallel rendering and physics to make it real
<focus>
the final bit of the rendering is bit blitting to update the LCD. That can be a meager LCD + A10
<libv>
focus: well, make it so!
<hramrach>
focus: I will believe when I see it happen
<libv>
focus: go! go and do it!
<focus>
libv: who said I won't ? :)))
<libv>
focus: i haven't said so, but i will
<bfree>
zumbi: I'll do it -j12 (VM with 6 cpus) ... will probably be good enough for this actually (and takes ~12minutes, rather then probably a couple of hours for -j1)
<hramrach>
I guess you could also make a LVDS interconnect that concentrates data from multiple processors ;-)
<libv>
focus: then go, quickly.
<hramrach>
so each scans out its bit and you compose it into a single image
<focus>
After the first SoM is out, the second is or third is copy paste x 10 or x20 board; muahahahah they said it could not be done.. but it can!!
<libv>
focus: you forgot an extra !!!
<libv>
it's very important to get the number of ! right
<hramrach>
you can cut&paste 20 boards next to each other
<hramrach>
and get 20 single chip computers on a single PCB
<hramrach>
the interconnect is the difficult part
<hramrach>
some companies like Cray or SGI were making their living on that
<focus>
hramrach: yes divide the processing - between processors with intelligent algorithms - that effectively becomes an R&D vehicle for students wanting to build their own 3D graphics engines
<hramrach>
and SGI still was last time I checked
herdingcat has quit [Quit: Leaving]
<focus>
hramrach: they did not have 1GHz ARM with 1GB RAM for $20 to make it happen
<hramrach>
the scanout speed for 1080p is more than the speed of the RAM interface on A10 it seems
<hramrach>
so you can't make an A10 cut & paste picture data from multiple buffers into one in real time
<focus>
hramrach: that is why the data has to be pumped into a A10+LCD through GPIO. The A10 pastes it into the RAM and the HDMI blits it to screen.
<libv>
?
<focus>
I mean controllers blitz it to LCD or the HDMI
<focus>
from the RAM at a fast rate
<hramrach>
does not seem viable
<libv>
focus: what happened to all those other projects you have been talking about over the last 6 months?
<focus>
The data to the RAM does not need to be updated at high speed
<hramrach>
but I am not very familiar with the A10 bandwidth bottelnecks
<hramrach>
focus: the data to the ram needs to be updated at tehscanout speed for realtime rendering
<focus>
libv: some drew blanks - but others are racing. I am not sure where I am on each
<hramrach>
sometimes you can use compression but sometimes you simply need the whole thing
<libv>
you're the one doing "things", right?
<libv>
how can you not be sure where you are?
<focus>
hramrach: the way it works the data gets pumped from CPU to CPU where each bit is added.
<hramrach>
the last one needs to work at full scanout speed
<focus>
So a intense scrolling screen for a racing sim can be built by one CPU, and then another CPU does the road, etc.
aesok has joined #arm-netbook
<hramrach>
but at the end one CPU needs to feed it to the LVDS/HDMI
<hramrach>
at speed surpassing the RAM IO speed
<focus>
The rate of flow of information is not that bad - about quarter to half of the CPU taken up in data transfer the remainder is rendering CPU cycles
<focus>
I did some calculations once - it were not too bad
<libv>
what bus are they all using to communicate?
<hramrach>
GPIO :-D
Marex has quit [Ping timeout: 245 seconds]
<focus>
Not all pixels need to be updated - so it can be almost no bandwidth at times
<hramrach>
ssvb: there seems to be a problem reported with artifacts high-dotclock modes reported
Marex has joined #arm-netbook
<hramrach>
eg. you can scan out at 1080i but not 1080p
<hramrach>
maybe the problem is elsewhere
<focus>
the scanout is handled by the final CPU + LCD/HDMI contoller - how the data gets into that RAM to be scanned out can be very slow.
<hramrach>
but since the clock syncs but part of the data is bad it reminds me of those old SDRAM GPUs which had about the same issue
<hramrach>
lower the dot-clock and artifacts gone
<focus>
so if a scene is not updating, the scanout remains high frequency high bandwidth, but you may be moving only 100 pixels at a time so the second CPU is hardly going to get taxed, same with GPIO pins
<ssvb>
hramrach: I can scanout 1080p, but there seem to be some kind of buffer underruns in the display controller if the the GPU and/or CPU is accessing memory at the same time
<ssvb>
hramrach: 50Hz works more reliable than 60Hz for 1080p
<hramrach>
so about the speed of the ram IO
<hramrach>
but you cannot update it from the CPU
<focus>
It is updated by the CPU - thats how games software works
<focus>
without accelerators
<focus>
but not clever
<hramrach>
focus: the problem is in the worst case you have to update everything
<hramrach>
because either everything has chenaged or too much ahas cahnged to calculate the difference
<focus>
hramrach: thats true even in complex games - crysis frame rate drops to about 12fps on complex scenes on medium graphics cards
<focus>
So as things get complex, the frame rate drops
<hramrach>
with A10 the usable frame rate drops to 0 because the memory bandwidth is occupied by scanout
<hramrach>
ssvb: which device?
<hramrach>
or rather what ram speed the Mele default 360MHz?
<focus>
not usually hramrach: the penpods have lCD scanout and it plays videos reasonably well - so its rendering it in software and allowing scanout hardware to function at the same time
<ssvb>
hramrach: I'm clocking the memory at 480MHz
<hramrach>
well, so driving the monitor somewhat affects benchmark (like -30%) but gives you display artifacts
<ssvb>
how do you get artifacts? is there a reproducible test case?
<hramrach>
I don't have a 1080 capable screen so can't check
<focus>
display artifacts are normally taken care of by clever software - not so clever software == artifacts
<hramrach>
ssvb | hramrach: I can scanout 1080p, but there seem to be some kind of buffer underruns in the display controller if the the GPU and/or CPU is accessing memory at the same time
<ssvb>
hramrach: in this case how do you know there is a problem?
<hramrach>
I don't know how did you notice the underruns
<focus>
stripes on screen
<hramrach>
on an S3 trio I had this issue that right part of the screen showed stripes of garbage
<hramrach>
with high dot clocks
<hramrach>
on modern discrete graphics cards there is some watermak logic that suspends the GPU when there is not enough memory bandwidth to process the scanouts
<hramrach>
but A10 does not have that or it is not documented
<libv>
ssvb: 480MHz really is a great one
<hramrach>
cubieboard comes clocked at that speed according to sunxi wiki
<hramrach>
not sure how to check
<Turl>
use the sunxi memory tool thingy that prints stuff about the memory
<bfree>
zumbi: ooops, I did it -j1 ... bah, may as well let it finish anyway now for the cleaner log
<ssvb>
libv: we probably need to collect some statistics about cpu and memory overclocking stability, based on a few reports so far it looks like the cpu is not really overclockable but the ram is
<zumbi>
bfree: thanks, I'll have a look later on, gotta go now
jelly has quit [Remote host closed the connection]
<libv>
ssvb: indeed
rellla2 has quit [Remote host closed the connection]
<hramrach>
well, some people say the CPU is overclockable to ~1.2GHz
<ssvb>
the memory chips used in Mele A2000 are DDR3-1333, Allwinner-A10 SoC specs say that it supports up to 400MHz (DDR3-800), I have no idea why the vendor is clocking memory in Mele at 360MHz by default (maybe they just don't need memory bandwidth for their primary use cases?)
<hramrach>
not sure how helpful that would be
<hramrach>
probably
<hramrach>
and safety margin
<hramrach>
lower clock = more complying parts = less costs for trashed hardware
<libv>
ssvb: yeah, could be
<rm>
maybe lousy PCB layout
<rm>
I remember Tom once said
<ssvb>
or it could be that they were hunting some software bug, decided to clock down the memory speed to check if it helps, somehow fixed the bug but forgot to restore the memory clock speed to the original settings :)
<rm>
one of the strength of the A10 (A13 etc), is that even a mediocre electrical engineer can design a stable board with it
<rm>
gths*
<hramrach>
they provide a reference design
* mnemoc
wonders about the eoma68-a10 card :|
<libv>
ssvb: is there a difference in powerdraw?
<ssvb>
libv: I have not measured it
<hramrach>
Mele is not battery powered so not much of a concern anyway
<L84Supper>
he said "mediocre electrical engineer" that would require step up :)
<rm>
I don't remember the exact words
<rm>
but I got that bit to mean the A10 is kind of solid and rather tolerant to various blunders of PCB designers
<focus>
mnemoc: eoma has a few problems - thats why I design infrastructure board to break out all the pins of A10 and thrash out all the issues.
<L84Supper>
getting it work is one thing, getting it stable over a wide temp range and conditions is another
<mnemoc>
focus: that can only be done if you marry one particular soc, eoma is supposed to be soc-agnostic
<focus>
Actually I never design final boards first and test boards second - so I don't know why all rush to build final boards first.
<mnemoc>
but (in theory) it should have been trivial that "even a mediocre electrical engineer can design a stable [eoma68] board with it"
<focus>
The high speed stuff close to the CPU, low speed stuff is all pinned out - at least I hope so!
<mnemoc>
but after more than a year, it didn't happen, and ended up been designed closed by wits-tech :|
<focus>
SAD!!!!!!!
<mnemoc>
and in the wrong formfactor
<focus>
and loose money for Allwinner - because they don't do datasheets
<focus>
Doh! Going in circles!!
<L84Supper>
that is mostly due to the attitude of the mastermind behind eoma68
<hramrach>
I think if he was really bent on making the board he would have one by now
<hramrach>
there is Olinuxino, Cubieboard, ..
<hramrach>
Mele, MK802 and clones ..
<mnemoc>
and cpinc rogers com so-dimm + reference carrier board
<mnemoc>
as a not-EE I can't tell if something is hard/easy in that arena... i can only be sad
<focus>
I nearly fell into same trap of no info - but some people come forward with info and I was able to finish BGA diagram
vinifm has joined #arm-netbook
<hramrach>
oh, and that pcduino thing
<mnemoc>
hramrach: uh. first time I hear about that one
<hramrach>
was on the ML
<mnemoc>
focus: /q
<hramrach>
they don't specify SoC but by the features and price it looks like AW A1x
<hramrach>
prohibitive shippping costs outside US and somewhat more expensive board but for US people it might be good deal
<focus>
mnemoc: you be right. Its the only way things get done.
<specing>
Beyond Semiconductor, a company founded in 2005, and based in Ljubljana, Slovenia
<specing>
WTF
<specing>
here?!?
<specing>
no way...
<jinzo>
yeah, you didn't know of them?
<jinzo>
A year or so ago they had quite a big hiring action
<specing>
Or maybe they found a way to use the 2um fab at uni :D
<jinzo>
they're part of the uni lj incubator (or at least were)
* specing
scratches head
<jinzo>
I tought everyone knows them around here :P
<jinzo>
(and note, I don't think they're actually making the silicon, probably only license it out - and quite some big licensees.)
<roxfan>
ba is based on openrisc btw
<specing>
I see mentions of wishbone, yes
<jinzo>
don't know much about it, but I sure hope they'll be GPL compliant
<jinzo>
because that's their only way of making a dent in this market with BA25
<jinzo>
imo.
<specing>
otherwise we can go bang at their door :)
<jinzo>
yeah, they were listed at the LUI building (that's accross the Mobitel devops center and besides the slovenian defence ministry)
<jinzo>
but I don't think they were actually located there.
vinifm has quit [Read error: Connection timed out]
vinifm has joined #arm-netbook
anunnaki has quit [Ping timeout: 248 seconds]
hp__ has quit [Ping timeout: 264 seconds]
<hramrach>
specing: as for vaporware they offer an evb with 600MHz dualcore processor
Eigen has quit [Remote host closed the connection]
<hramrach>
that's not impressive performance-wise
<hramrach>
for the core to be useful they should pack more in the chip and up the clock a bit
<hramrach>
well, the 600MHz one could do something too
<hramrach>
but is simewhat behind the competition performance wise
<hramrach>
hmm, the ba cores are mentioned in th news but cannot find anything actually using them. Cannot find even news mentioning ic1 but it's also very unsearchable
<hramrach>
pff
<roxfan>
there was some wireless chips company bought by nxp recently