<WarheadsSE>
arokux2: this is why Arch Linux ARM strongly suggest only connecting ground, tx, rx across the board
rz2k has quit []
egbert has quit [Disconnected by services]
egbert has joined #linux-sunxi
mouchon has quit [Quit: Page closed]
TheSeven has quit [Read error: Operation timed out]
TheSeven has joined #linux-sunxi
ykchavan has joined #linux-sunxi
TheSeven has quit [Disconnected by services]
[7] has joined #linux-sunxi
ykchavan has quit [Quit: Leaving]
_whitelogger has joined #linux-sunxi
provel_ has quit [Quit: Lost terminal]
vrga has joined #linux-sunxi
vrga has left #linux-sunxi [#linux-sunxi]
atiti__ has quit [Ping timeout: 248 seconds]
_BJFreeman has joined #linux-sunxi
_BJFreeman is now known as BJfreeman
mahdichi has joined #linux-sunxi
<Tsvetan>
are the EOMA68 and Cubie boards CAD files released? As I read at linux-sunxi.org that they are ¨Comunity frendly opensource hardware¨
mahdichi has quit [Ping timeout: 250 seconds]
<Tsvetan>
to be opensource hardware they have to release unconditionally their CAD files, can who made this statement on the linux-sunxi.org point me to the repo with the CAD files for these boards?
rellla has joined #linux-sunxi
eebrah_ has joined #linux-sunxi
<hno>
Tsvetan, table have been messed up by someone.
<Tsvetan>
yes, I saw the history wingrime did this mess :)
<Tsvetan>
but I though - hey they may have released their CAD files after all, let me ask
<hno>
No.
<Tsvetan>
ok, then I will fix the main page, I think there is also typo in ¨comunity frendly¨
<Tsvetan>
ah you already did it :)
shineworld has joined #linux-sunxi
<hno>
I only clicked the undo button.
shineworld has quit [Client Quit]
BJfreeman has quit [Quit: had a good time]
Quarx has joined #linux-sunxi
<oliv3r>
goooood morning
<oliv3r>
arokux2: if you want to ise gpio_init, then you put gpio clear PH15 there, and gpio set PH15 in cpu_eth_init, before sunxi_emac_init()
<oliv3r>
arokux2: but you can't just randomly patch the gpio in, because not every board has PH15 connected to PHY power :)
<oliv3r>
The exynos 5420 has now a T628! nice
<hramrach__>
mornin
mouchon has joined #linux-sunxi
<mnemoc>
moin
pirea has joined #linux-sunxi
<mnemoc>
so many mails to read.... :\
<oliv3r>
lol
<oliv3r>
mnemoc: how's your internet
<oliv3r>
mnemoc: yeah, also grep fror your name; i made metnions/requests in messages :)
<oliv3r>
poor CPU's are melting here toay :(
<theOzzieRat>
i2c
<theOzzieRat>
oops
bsdfox_ has quit [Ping timeout: 246 seconds]
<theOzzieRat>
<hno> fact: Computers are not digital. <-- yes they are, they either work or they don't ;)
pirea has quit [Ping timeout: 276 seconds]
<oliv3r>
the line between digital and anlaog is very thin
mturquette has quit [Ping timeout: 256 seconds]
FunkyPenguin has joined #linux-sunxi
eebrah_ is now known as eebrah
forcev has quit [Ping timeout: 264 seconds]
notmart has joined #linux-sunxi
notmart has joined #linux-sunxi
notmart has quit [Changing host]
yuuki has quit [Read error: Connection timed out]
\\Mr_C\\ has quit []
mturquette has joined #linux-sunxi
\\Mr_C\\ has joined #linux-sunxi
FR^2 has joined #linux-sunxi
cajg has quit [Ping timeout: 246 seconds]
\\Mr_C\\ has quit [Ping timeout: 276 seconds]
atiti__ has joined #linux-sunxi
cajg has joined #linux-sunxi
<arokux2>
oliv3r, the serial2usb converter spoiled my board, without it everything works as expected.
<oliv3r>
arokux2: i read :)
<oliv3r>
clearing first, then setting isn't per-say bad, it may slow you down. but i was right :)
<oliv3r>
i said that clearing before setting may simply be a hardware requirement
<oliv3r>
in your case, it was, but not intended; )
<arokux2>
oliv3r, then why you commented on cpu_eth_init? :P (btw, one could just use #ifdef CONFIG_MELE_A1000, it is defined)
<arokux2>
oliv3r, well... who knows what happens if the power is comming from an unexpected source? later i noticed that after plugging the converter the leds on phy flush
<oliv3r>
arokux2: that would have the really big downside though (and we do it atm all the time) that you'd have a u-boot specifically for mele; 1 generic u-boot to run on all is much nicer :)
<oliv3r>
i should check my cubieboard without rs232; maybe my phy starts working again
<oliv3r>
and i should add that diode myself too
<oliv3r>
arokux2: well you 'set' it in cpu_eth_init; but clear it on gpio_init
<arokux2>
oliv3r, ah, now I see what you mean. but there are different setting for sdram anyway.. how to cope with that?
\\Mr_C\\ has joined #linux-sunxi
<oliv3r>
arokux2: will be handled soon :)
<oliv3r>
arokux2: i just need some time
<oliv3r>
and board specific ram settings, are SPL only
<arokux2>
oliv3r, you are working on upstream uboot? or there is architecture in place already for that (general ram settings)?
<hramrach__>
for me the serial to usb converter that came with cubieboard seems to work ok
<hramrach__>
as in I have the boards connected all the time and they boot
<arokux2>
hramrach__, does ethernet works after boot with converter connected to cubie from the very beginning?
<hramrach__>
I can connect to it over ssh
<oliv3r>
arokux2: what do you mean upstream u-boot? As far as I know, hno's intention is to mainline our changes asap, but the code has to be qualitifly good
<oliv3r>
hramrach__: arokux2 has a mele that uses 1 gpio to power on/off the ethernet PHY
<hramrach__>
cubie does not. afaik it is always powered on
<arokux2>
oliv3r, don't you need some uboot api to be able to make it board-generic and pass those ram parameters to it the same way as dev. tree is passed to the kernel? or you are saying that spl being non-generic is not a problem?
<hramrach__>
spl is probably too small to be generic
<hramrach__>
but all it needs is to detect and initialize the dram controller and required clocks
<hramrach__>
so it has room for loading the rest of u-boot
<hramrach__>
it needs to load from somewhere, too. so driver for at least one storeage device is needed
<arokux2>
hramrach__, does the rest of u-boot need some kind of device tree?
<hramrach__>
the rest of u-boot is not very space constrained so can have pretty much anything
<hramrach__>
but it uses serial, storage, power, and some buttons
<hramrach__>
serial port is selected at compile time, so is storage, and power can be detected. buttons are most questionable because different devices can potentially have them connected to different pins or even on i2c
<hramrach__>
also you might want to use ethernet to netboot or use gpio leds for blinkenlights even in u-boot
<hramrach__>
presumably ethernet is supported to some extent but I never tried netbooting
<oliv3r>
rellla: ping
<rellla>
oliv3r: pong
<oliv3r>
arokux2: we don't have enough room in the binary to do much magic
<oliv3r>
rellla: have you tried the geexbox xbmc image?
<hno>
hramrach__, u-boot netbooting is supported on a10, a10s and a20.
<arokux2>
hramrach__, netbooting should work with A10, there is an article on wiki.
<hno>
and will be supported on a13 as well when there is a working usb host driver...
<oliv3r>
arokux2: we will end up with 2 or 3 versions of u-boot SPL; but that's okay
<oliv3r>
arokux2: 1 for mmc boot, 1 for nand boot, 1 for SPI boot
<oliv3r>
no point in having 1 SPL being able to boot from 2 locations
<arokux2>
oliv3r, with one u-boot binary for all "boards", with boards meaning sun4i boards, or all the boards?!
<rellla>
nope. but i could provide a branch in my repo which includes 1) the fix as in the geexbox image, and a 2nd one that could fix the blueish issue, too imo
<oliv3r>
sun457i looks feasable; sun6i might less
<rellla>
oliv3r: so others can do a test run... my freetime isn't enough for that atm
zeRez has joined #linux-sunxi
<rellla>
i also can provide some testable binaries for debian wheezy if wanted.
<oliv3r>
rellla: i'm testing the geexbox image and works quite well :)
<oliv3r>
550 used space
<rellla>
oliv3r: but it's just workaround and no fix imho
zeRez has quit [Client Quit]
<oliv3r>
rellla: of course; but its better then what we have
<oliv3r>
in any case, i just hope there's no work duplicated on their and our end
<mnemoc>
oliv3r: using the phone as modem, but 3g coverage is good here. (in the hostel is was almost zero) .... but 1951 unread mails :|
<oliv3r>
no network or media files to test against however
<oliv3r>
shall try wifi and tvheadend tonigh
<rellla>
and i'll push the fixes
<oliv3r>
in any case, more cooperation is good :)
<oliv3r>
haven't seen him join this channel yet :(
<oliv3r>
anyway, last thing I would want to see 'take this and that patch from geexbox, take that and this patch from rellla and if you mix it up with this special sauce you get the best'
<rellla>
there must be one point to bring it all together. i did a @warped-rudi in github issues, so he might get a popup...
<oliv3r>
:)
<rellla>
if there weren't the proprietary licensing issues with aw, there would be a chance to get it all upstream \o/
<oliv3r>
the mali libs?
<hramrach__>
seems we don't have OTG support in 3.4 kernel on a20
<oliv3r>
window animations aren't as smooth as I'd think they should be
<rellla>
no i think they claim on cedarx. ask gimli, why he isn't continuing.
<hramrach__>
window animations are evil
<hramrach__>
you don;t need them but they are very taxing on the hardware
<rellla>
window animations in where?
<oliv3r>
when going from settings -> main menu
<oliv3r>
cedarX is GPL infringing anyway
uwe__ is now known as uwe_
<hramrach__>
maybe wingrime reverses enough of it to get at lest some useful formats working
<hramrach__>
I mean it would be awesome if it worked on *every* h264 movie that is not totally broken
<hramrach__>
you can decode mpeg2 in neon probably and stay away from odd formats but there needs to eb at least something it can decode for the cedar thing to be useful
<oliv3r>
i would offload mpeg2 too cedarx
<hramrach__>
if it works, fine
<oliv3r>
if you want to use XBMC
<oliv3r>
and use it to watch TV
<oliv3r>
you get sd and hd streams
<hramrach__>
as things loook righ now it probably will
<oliv3r>
sd in mpeg2; hd in h264
<hramrach__>
but it's not essential
<oliv3r>
if you put sd on the CPU
<oliv3r>
there is not much left for system to use
<hramrach__>
it can dedqal with it
<hramrach__>
*deal
<oliv3r>
if you do video + xbmc overlay + some navigating in the overlay
<oliv3r>
i doubt it
* hramrach__
built a20 and a10 kernel from same source
<hramrach__>
I wonder what was teh kernel used for F19 images
<hramrach__>
maybe I should have used the F19 config as well
<oliv3r>
hramrach__: hansg wip 3.4 afaik
<arokux2>
oliv3r, by saying one u-boot binary for all "boards", with boards meaning sun4i boards, or all the boards out there?!
<hramrach__>
the nand driver I added does not work
<hramrach__>
but that was kind of least of my worries
<hramrach__>
I will try to boot the kernel when I get to the board
<hramrach__>
I suspect I will need manual poweroff a few times
<rellla>
oliv3r: to watch hd streams you have to deal with 1080i. who is capable for that on a10?
<oliv3r>
cedarx :p
<oliv3r>
which means we also need the deinterlacer to work properly
<oliv3r>
arokux2: the SPL will be identical for sun457i yes; that's the plan
<arokux2>
oliv3r, I'm sorry, but how it can be identical because of different ram settings?
_whitelogger has joined #linux-sunxi
e-ndy has joined #linux-sunxi
heffer has quit [Changing host]
heffer has joined #linux-sunxi
utente has joined #linux-sunxi
ijc has joined #linux-sunxi
<Turl>
mripard: ping
<oliv3r>
rellla: the 3 supplied screensavers all crash; only the 'dim' one works?
<oliv3r>
arokux2: secret magic sauce :)
<oliv3r>
arokux2: we supply the dram parameters via either i2c memory chip, header on the binary or 1k blok somewhere on the mmc/flash
<oliv3r>
rellla: windowed mode is the only option for video mode, and you no longer can change resoluition/refresh rate
<oliv3r>
clicking on it once will say' keep new resolution' but you change from windowed mode to windowed mode (no other choices)
Quarx has quit [Read error: Connection reset by peer]
tzafrir has joined #linux-sunxi
<hno>
oliv3r, SPL header is the most suitable place IMHO. Using I2C requires configuration to know which I2C controller on what pins, i2c address and where the data is at that address...
<oliv3r>
hno: yeah but it would be still very cool to have ;)
<oliv3r>
but yeah, i2c might a little far fetched
<ssvb>
oliv3r: can memory timings be possibly stored somewhere in the security fuses?
<Turl>
oliv3r: it'd be cool to have teleporting machines too
<oliv3r>
ssvb: fuses are read-only :)
<oliv3r>
Turl: omg hell yeah
<ssvb>
oliv3r: hmm, and nobody can re-program them in any way?
<oliv3r>
Turl: we have i2c in spl; so reading memory settings from i2c isn't that far fetched
<oliv3r>
ssvb: we are speculating you have to apply a specific voltage (2.5) to the efuse-vdd pin to write, and pull it to gnd otherwise
<Turl>
oliv3r: but you'd need an i2c eeprom on each board - not going to happen for most of them
<oliv3r>
ssvb: but it's all untested and nobody tells us anything abou tthat
<oliv3r>
Turl: you check if there's info there, you check if there's info elsewhere?
<hno>
ssvb, possibly, but non-trivial to program them without desoldering the CPU..
<oliv3r>
Turl: olimeino has eeprom
<Turl>
oliv3r: yeah but does all the "you check if..." fit? :)
<hno>
oliv3r, reading memory settings using i2c is not far fetched. But there is no defined standard for it so you still need configuration on where to find the info.
<oliv3r>
if you store the memory timings in some package with a header and a magic value
<hno>
oliv3r, to read the data you need to know
<oliv3r>
and go over the i2c controller and check for memory chips, then read the memory chips?
<hno>
a) Which I2C bus it's attached to
<hno>
b) Which PIO pins needs to be configured for that bus
<hno>
c) Clock speed the chip supports
<hno>
d) Address of the chip
<hno>
e) Type of chip (but mostly generic so not much of an issue)
<hno>
f) Offset in the chip where the data is, and format of the data.
<ssvb>
hno: maybe try multiple places for checksum protected memory timings block, and if nothing is found - resort to some safe default (maybe combined with autodetection)
<oliv3r>
a) scan all; b) that's kinda a killer if not default, c, always the slowest only reading a few bytes, d) scan all :), f) scan all of it, search for a magic value, we define the format
<oliv3r>
but yeah it's maybe more trouble then its worth
<hno>
ssvb, imho it's a pointless discussion unless involving hardware manufacturers. And of the available manufactures only Olimix might be interested.
<hno>
Olimex.
<hno>
oliv3r, you then end up with a very long delay scanning the hardware. Likely tenths of seconds.
<oliv3r>
but yeah, hardware manufactures would need to be onboard
<oliv3r>
so you can agree to 1 sort of standard place where the memory chip to be probed would be at
<oliv3r>
it's only somewhere on the 'nice to have' list :p
<oliv3r>
low on the list at that
<hno>
Most hardware manufactures have no interest. For them the problem is already solved.
<hno>
by storing the data in the SPL header in NAND.
<oliv3r>
well we can alwyas still say 'if you connect a generic type of eeprom to the first i2c bus that is shared with the AXP bus, you can store your memory timings using this format (using this tool)
<hno>
for what benefit?
<oliv3r>
but yeah, only parties like cubie, olimex, rhombus would even be remotly interested
<oliv3r>
memory timings are board specific
<oliv3r>
the data should be stored as closed to the board as possible imo
<hno>
NAND is quite close...
<oliv3r>
pretty much like SPD sits on a ram module
<hno>
There is no RAM modules on these boards.
<oliv3r>
its a comparission
<oliv3r>
the board IS the rammodule :)
<hno>
yes
<oliv3r>
can't we access some generic storage bytes from the AXP? :)
<arokux2>
I wonder when there will be BIOS-like facility for arm boards
<oliv3r>
nope
<oliv3r>
not likly
<Turl>
oliv3r: they're implementing UEFI these days
<arokux2>
oliv3r, defining a location for storage of some basic system settings you are actually creating BIOS
<oliv3r>
Turl: uefi for really cheap embedded arm devices?
<oliv3r>
arokux2: that's stretching it a bit :p
<ssvb>
hno: can the things like ram size and bus width be safely probed in u-boot for autodetection?
Black_Horseman has quit [Remote host closed the connection]
rellla has quit [Ping timeout: 248 seconds]
<ssvb>
hno: if yes, then we can add the conservative 360MHz dram timings and have universal flashable images for all kind of a10 devices
<ssvb>
I believe that's what oliv3r wants in the long run, am I right?
<oliv3r>
ssvb: almost
tinti_ has quit [Ping timeout: 248 seconds]
<oliv3r>
that should be the fallback mode
<oliv3r>
i want to store a binary blob just before u-boot (7k marker if that's possible at all) check magic + version or something, and load memory timings from there
<oliv3r>
if magic/version/crc fails, we check the header for conservative 360 failsave settings
<oliv3r>
this way, you can always overwrite your u-boot without worrying about memory timings
<oliv3r>
and if you have tweaked settings, you don't overwrite them constantly
tinti_ has joined #linux-sunxi
<oliv3r>
in theory, you can always change your conservative header timings and ignore the 7k ones
<oliv3r>
ssvb: make sense?
<ssvb>
storing something before u-boot implies that the user will overwrite it when doing dd for the whole sd card image
<oliv3r>
then they are creating a new image anyway
<arokux2>
why to store outside of uboot at all if you need to store different information anyway? having everything in uboot makes it simpler..?
<oliv3r>
im' thinking of usecases like 'here, download this new u-boot, it should fix issue xyz you are having'
<oliv3r>
arokux2: but having it all in u-boot makes it that you don't have a generic u-boot for all
<oliv3r>
which is what we have now to begin with
<arokux2>
oliv3r, why there should be one? as generic as possible, but there is a limit i.e. ram settings
<ssvb>
oliv3r: I'm talking about the casual users, they surely would prefer to download a single image from a single place and just write it to the sd card (either using dd in linux, or some flashy windows gui tool)
<oliv3r>
actually, having save defaults means you don't even need a header around u-boot really
<oliv3r>
arokux2: there won't be memory timings in u-boot at that point anymore
<oliv3r>
ssvb: save u-boot header is there to protect them :)
<oliv3r>
ssvb: and you mean like hansg's image?
<Turl>
oliv3r: I dunno if 'really cheap', but they're certainly arm embedded :P
<oliv3r>
ssvb: but he does the same thing, write u-boot, write rootfs and, write u-boot blob
<oliv3r>
Turl: pff, I mentioned the new octa 5420 HOURS ago :p :)
<ssvb>
oliv3r: hmm, does hansg's image not ask the user about the type of his device anymore?
tinti_ has quit [Ping timeout: 276 seconds]
<arokux2>
oliv3r, you are saying that instead of cd uboot && make mele_a1000 && dd ... there will be cd uboot && make && dd uboot && dd <ram parameters>
<oliv3r>
ssvb: it still does, you run a setup, that fills in the blanks to wwhat write to where
<Turl>
oliv3r: but you didn't poke libv did you? :P
<arokux2>
for the user the last one is more complicated i think...
<oliv3r>
arokux2: yes, but that last dd is optional
<oliv3r>
Turl: no :(
<oliv3r>
arokux2: a user does './setup.sh'
<oliv3r>
a user has a 'safe u-boot that always works'
rellla has joined #linux-sunxi
<oliv3r>
IF they want faster timings etc, then that's available to them
<ssvb>
oliv3r: asking something might be very puzzling and challenging for some users :) it might be hard for them to tell the difference between 512MB and 1GB Mele for example
<oliv3r>
it's much better then 'for this device, you need this u-boot, but for that device, you need that u-boot, but you can also use this u-boot on that device'
<oliv3r>
ssvb: hansg's image still asks the user via a menu what their device is
<rellla>
oliv3r: i never did a test with screensavers, and i remember that windowed mode thing. you cannot change that much ;)
<oliv3r>
ssvb: but good point, the safe conservative setting will only support 512mb as we can't detect it
<rellla>
time to find some developers to improve the whole thing.
<ssvb>
oliv3r: or the user might have a 512MB hardware, and think that selecting the 1GB option will give him a magic upgrade :)
<rellla>
at one place.
<oliv3r>
rellla: i also can't change resolution at all, but when I do change windowed mode, i get some really low 1/4 res (and only in the left bottom corner)
<oliv3r>
ssvb: hey, i didn't say it was a perfect idea, but it's better then what there is now :)
<oliv3r>
besdies, every manufacturer can still store his memory timings in a blob
<oliv3r>
pretty much how it is now, basically, we split the u-boot binary, and the memory timings appart
<oliv3r>
which is why I kinda still like the eeprom idea, it's on the board, not easily changable and should be tuned and safe by the manufacturer :)
<oliv3r>
ssvb: but I do really like your conservative safe memory timings and 512mb ram fallback mode idea
<ssvb>
oliv3r: is it really impossible to detect 1GB ram size? (for example by attempting to set dramc this way and performing a quick memtest)
<rellla>
oliv3r: so don't do it ;) iirc hansg mentioned, that the xbmc isn't compatible with the changed kernel disp driver anymore. but don't know what he meant exactly. maybe some iotcl's ...
<oliv3r>
ssvb: that I do not know, memory size check would be very awesome, but i think that should be step 4 :p
<rellla>
maybe this is the reason, why we can't "interact" with resolution.
hipboi has joined #linux-sunxi
<arokux2>
personally i think there is no point in this additional blob, because you still need to generate it separately. so unless all the other boards will support your storage mechanism (which is not going to happen) the "cd u-boot && make mele_a1000" is the easiest one for both the users and developers.
<oliv3r>
rellla: ah ok; so how do I force the resoltion down? override edid info?
<Turl>
raise*
<Turl>
hi mripard
<arokux2>
they have 10% on the first day
<oliv3r>
830 USD is a bit to beefy for me
<oliv3r>
even though the features are really nice
<arokux2>
S4 costs $620 now
<Turl>
oliv3r: it's supposed to be like a F1 though, with sapphire screen instead of glass and what not :p
<oliv3r>
s4 is to beefy for me :)
<arokux2>
but: if I have a desktop at home, why do i need integration?
<oliv3r>
Turl: i don't care if it shits diamonds :p, in a year or 2 it'll be obsolete
<ssvb>
arokux2: if there is a well defined place to store this information, it can be done once by a competent user/developer and then reinstalling the system is going to be easier
<oliv3r>
then again, i'm trying to buy an s2 for ~ 175 becaus I feel that's enough :)
<oliv3r>
arokux2: users will not evern do a 'make xyz'
<oliv3r>
users download from 'this dodgy site'
<oliv3r>
and they expect it to just work
<oliv3r>
yes, us developers will have to perform 2 or 3 extra steps, but thats' what we do
<oliv3r>
it offers a LOT of flexibilty
<arokux2>
oliv3r, i do not see flexibility. there are same number of commands.
<ssvb>
arokux2: and if eventually some manufacturers start to support the same "standard" out of the box, then this will give them a competitive advantage when attracting noob users :)
<Turl>
oliv3r: but in a year or two you'll be buying ubuntu edge 2 :p
<oliv3r>
not for 830 :p
vinifr_ has joined #linux-sunxi
<oliv3r>
i'm not spending more hten half a months paycheck on a phone that i use that little :)
vinifr has quit [Read error: Connection reset by peer]
<oliv3r>
(I love my android phone and do use it)
<oliv3r>
but i'm not one of those people that spends half their day on it :)
<oliv3r>
turl: i like the idea, i love the specs, but the price is too much for my pocket :)
<arokux2>
without games the hardware on flagship smartphones is useless anyway, i think
<Turl>
oliv3r: you need a bigger pocket I'd say :P
<oliv3r>
also, i'm not quite sure if i'm really extactic with canaconical and their whole 'mir/unity' thing :)
<oliv3r>
rellla: with hansg's kernels, we can simply overrride everything via EDID
<ssvb>
arokux2: the users want random xbmc+lots_of_other_shit images from dodgy sites prepared for some a10 device branded as X to also work on their a10 device branded as Y
<oliv3r>
rellla: oh we can look at that ioctl then
<oliv3r>
ssvb: exactly. I call it the 'xda culture' :p
<oliv3r>
god, when I first started to delve into custom roms, kernels etc and went over XDA, i found myself in some alternate reality
<rellla>
oliv3r: is there something, that has changed for setting and getting these infos with hansg's patches?
<oliv3r>
I thought, this is all linux, I know this shit, should all be easy
<arokux2>
ssvb, then those dodgy sites should do appropriate packaging.. and for them the sequence of commands doesn't matter
<oliv3r>
but it's like this mystical dark secret society
<oliv3r>
'download this potion, it will make you strong'
<oliv3r>
rellla: i know nothing of disp, but let me check those ioctl's
<ssvb>
arokux2: all users must be competent and intelligent enough to build their own u-boot, kernel and userland packages, unfortunately we are not there yet...
<oliv3r>
ssvb: LOL
<arokux2>
ssvb, ? a second ago you were saying the users want to download a ready to use package?
mnemoc has joined #linux-sunxi
<oliv3r>
arokux2: ssvb actually, those ROM's are created by people who have half a clue
<oliv3r>
sarcasm :)
<arokux2>
now, they also need to be able to compile? :)
<oliv3r>
(i hope)
<libv>
ah, good. no more pvr
<arokux2>
libv, how is the development of lima?
<libv>
slow
<oliv3r>
libv: too much heat there?
<libv>
i've not been overly motivated in the last few months
<oliv3r>
libv: why not :( it's such an exciting project!
<arokux2>
libv, i wonder to which extent the code you develop now (or the info you find out) is applicable to new Mali 6XX GPUs?
<libv>
a factor of many things, but part is i guess the lack of response to me blogging about ARM managements position towards lima
<libv>
the world just doesn't care.
<libv>
arokux2: some bits will be, some bits won't. most of all, we will have the massive advantage of experience
<arokux2>
libv, *we* or you? :)
<oliv3r>
libv: are you kidding? there's lots of people who care
<libv>
we being me and cwabbott
<oliv3r>
i know a lot of people right here care great deals
<oliv3r>
hell i'll even buy you two beers at fosdem!
<libv>
here, yes
<libv>
but that's not a representative demographic
<oliv3r>
well there's always the 'who cares if its propriatery' crowd :S
<libv>
people are much much more interesting in being binary compatible with android drivers
<oliv3r>
google should have used the regular X drivers for their android thingie
<hramrach__>
X is dead
<oliv3r>
they've split the community for the worse
<hramrach__>
I can see why they did not want to
<oliv3r>
X, wayland, that bit
<hramrach__>
wayland was not there back then
<oliv3r>
hramrach__: X isn't dead, and it wasn't when android first started doing 3D
<libv>
which is pretty much like adding VBE support to a proper modesetting (i refused that 8 years ago, and got forked, and then had an insane amount of crap thrown at me, the crap stuck, but the fact that i was the one who delivered proper modesetting to the world has been ignored completely)
<libv>
+driver
<libv>
the lima situation is not too different from unichrome or radeonhd.
<oliv3r>
libv: there's only a handfull of people who actually care about things like that, RMS, me, those kinds
<oliv3r>
I appreciate what you have done for us a great deal
<hramrach__>
while X is backwards compatible with X11R5 (theoretically, in practice any old client will ikely expose a but or unbearable performance regression) it's dead
<oliv3r>
it's like those tree-huggers. We all know they have the right ideas, all they want to do is save the planet. Most of the population just simply doesn't care (until they find out it does actually affect them)
<oliv3r>
ignorant people are a hard audiance
<libv>
oliv3r: 10ys in, looking back only reveals the same stories repeating.
<jelly-home>
the fact that creating a usable open sauce driver will make more money for the people disliking the fact such a driver exists at all must be disheartening
<oliv3r>
libv: just know, that your work is being appreciated at great lengths by people who do care, even if they are not verbal or in great numbers
<oliv3r>
ignore them
<oliv3r>
they are stupid and selfish
<oliv3r>
to me, OSS eventually is about the greater good of things
<oliv3r>
its always the small people, small groups that fight for that
<oliv3r>
and always get tons of shit
<oliv3r>
just the other day "why are developers wasting time porting this or that program to linux, that's not a desktop OS, we only need windows support"
<blunden>
libv: the mali drivers are troublesome on Android too, probably the worst of all the GPUs used commonly in Android devices
<oliv3r>
just because there's so many more tools (re: a person) doesn't mean what you are doing isn't good
<oliv3r>
libv: ignore those idiots that talk shit; just remember, to some of us, you are a hero
<oliv3r>
you started a revolution, look how freedreno is comming along, thanks to your motivation!
<ssvb>
hramrach__: today X is more alive than wayland (which has not really born yet), and we don't know what's going to happen tomorrow
<arokux2>
although I agree with everything oliv3r is saying, after some time you need to make your living with oss, and that is what probably bothers libv
<hramrach__>
ssvb: have you seen the insides and how stagnant the project is due to backward compatibility cruft?
<oliv3r>
hramrach__: ssvb the whole XFree86 -> Xorg thing was an amazing and revolutionary step forward
<oliv3r>
arokux2: i don't think libv is complaining that he's not making a million dollars because he wrote lima
<hramrach__>
there are whole classes of bugs that are patently unfixable
<libv>
all this kms shit is based on my views on modesetting, and this occupies a large part of the intel crowd.
<oliv3r>
arokux2: remember, quite some OSS developers do this on the side, in their free spare time
<libv>
no-one would be working for ati/amd today if i had failed to provide a working driver against all odds in radeonhd
<libv>
each time i got either crap or indifference.
<libv>
looking back, i have to be happy to have gotten just indifference
<oliv3r>
while the outcome hasn't been what we would have hoped for
<oliv3r>
you did start the revolution, you just said so your self, KMS is basically your brainchild
<libv>
oliv3r: no, kms wouldn't have had such a really shitty and poor start in life if an actual experienced graphics driver developer had been involved from the start
<oliv3r>
libv: look at it this way, the path indicated by history, led you to where you are now with lima!
<libv>
not to mention randr1.2
<ssvb>
hramrach__: it was enough for one guy to have a look at the benchmark results, check the code and spot some obvious performance issues
<libv>
it took 3 years before X folk figured out that some tracking for modes might actually make sense.
<libv>
noone knew why a given modeline came out at the end
<libv>
nah, it's the same story repeating.
<ssvb>
hramrach__: only Intel is consistently doing more or less good job, the other drivers severely lag behind for various reasons
<arokux2>
libv, big forces are needed to make big changes
<arokux2>
ssvb, because intel driver is done by intel
<oliv3r>
libv: i disagree.
<oliv3r>
libv: your work on lima is golden
<libv>
arokux2: no, politics and corporate affiliation are always victorious versus technical superiority and community work
<oliv3r>
people that care about this stuff, know about it and praise you
<arokux2>
imho, you cannot expect people to develop same quality drivers (in some cases without docs) for free in their free time
<oliv3r>
finish what you've started, be proud of what you have accomplished.
<libv>
oliv3r: a driver is never ever finished.
<oliv3r>
libv: in the end, you'll be able to say, look, this is the proper way, and it works
<libv>
oliv3r: and before you can blink, the next generation is there.
<oliv3r>
well close to that
<libv>
this is sissifus (spelling?) labour
<arokux2>
libv, I see. it's how the world functions. just do what makes fun for you. do not dream about "what if everything and everybody were ideal"
<oliv3r>
but do remember, people appreciate greatly what you have done in the past, and even more so what you have done for lima
<oliv3r>
and they can't wait for your next appearance at fosdem
<libv>
no.
<libv>
i ranted at one of my good friends last weekend, about how this history repeats... He only came to nuernberg 3ys ago, and did not know the radeonhd story properly yet.
<libv>
he was pretty certain that it was redhat that freed ati.
<libv>
which is soo the opposite of reality...
<oliv3r>
:S
<libv>
but this is what the world remembers.
<arokux2>
"and before you can blink, the next generation is there" yes, this always bothers me. many people work on A10 now, but till the time it is properly mainlined it won't be there, probably..
<oliv3r>
missinformation is a bitch
<arokux2>
but hey, what is the difference for us, if the fun is just to work on these projects
<arokux2>
having it mainlined and used by everybody is secondary...
<oliv3r>
ssvb: :D
<oliv3r>
arokux2: thirtary
<oliv3r>
arokux2: i want an opensource and free platform
<oliv3r>
and while many people don't care abou that, and are fine with some crappy proprarity implementation, having it OSS is what is important to me
rellla2 has joined #linux-sunxi
<arokux2>
oliv3r, it is a long term process. compare the situation of today with that of 10 years ago
<oliv3r>
one of the reasons I chose A10, was because it featured a mali, which libv was working on
<arokux2>
eventually systems will get more and more open
<ssvb>
oliv3r, hramrach__: the problems can't be fixed until they are acknowledged, and the OSS crowd is usually just happy that the opensource radeon driver is supposedly better at 2d than the proprietary fglrx (which is a complete disaster)
<ssvb>
very few people have a clue
<libv>
ssvb: yet SuSE is unable to support the radeon driver in an enterprise setting today, and is forced to ship fglrx
<libv>
it is much more reliable, and they can actually get support.
<libv>
which is exactly what we wanted to change just over 6 years ago.
<libv>
but which ati prohibited by working with some individuals from amongst others, redhat
<arokux2>
libv, couldn't you organize a consulting company and give them the same support on radeon?
<libv>
arokux2: why would i?
<libv>
arokux2: do you know the crap politics behind this story?
<arokux2>
libv, no. I've just got an impression, that you would like to see radeon used..
<oliv3r>
distantiate yourself from the politics, politics always suck. it's always about the money, the power and the pride
<libv>
arokux2: i am the guy who brought up the modesetting of radeonhd, from scratch
<libv>
arokux2: radeonhd had a lot of its code copied over to radeon afterwards (for no technical benefit, just to have a competing driver by other factions of the open source "community")
<libv>
but this with ATI flair added.
<libv>
what we fixed properly, which sometimes proved that ATI was doing crap, was done the crappy ATI way
<libv>
the things that were unavoidable, were silently taken over.
<libv>
where we spent weeks of work testing things to death, it took radeon minutes to take it over
<libv>
arokux2: read up on radeonhd, and see the massive amount of crap all over the interweb
<libv>
and then read the original proposal we wrote to amd, and see the problem: we wanted to replace fglrx for most purposes
<libv>
radeon and the radeon kms driver are that crappy because they are not supposed to replace fglrx in production, but are supposedly enough to silence the open source anti-ati marketing
rellla2 has quit [Remote host closed the connection]
<libv>
and the noisemakers who happily slung crap at a proper open source software project, who are still happily working on this code, happily went along with ATI on that
<arokux2>
what is the point for ati to have both, radeon and fglrx?
<libv>
arokux2: i just said so
<libv>
fglrx is what they do, radeon is what they allow so that they do not get too much crap flung at them.
<arokux2>
libv, are they providing complete docs for the GPUs to public, at least?
<libv>
arokux2: nope
<oliv3r>
well radeon is superior in the 2D department allready :)
<libv>
arokux2: they are not ever since radeonhd was shut down
<libv>
arokux2: all you get is the shader isa
<libv>
arokux2: which is released by a team which had brought up compute
<ssvb>
oliv3r: radeon 2d acceleration is still beaten by the software rendering :)
<arokux2>
this is news to me..... I've always hoped to see an open source driver for ATI cards, because of docs provided to public!
<oliv3r>
libv: still, when you pointed the verbally finger to ARM with your lima work, you where awesome, don't let them feel they've won :(
<libv>
and this team was newly formed by amd shortly after the ati acquisition, by some folk from ati and quite a lot of external folk
<libv>
arokux2: free docs is because of me and egbert eich
<libv>
arokux2: when we wrote the proposal to amd, we though "now or never"
<libv>
ati hated that of course.
<arokux2>
"brought up compute" -- what is "compute"?
<libv>
arokux2: these days it is called gpgpu computing and opencl
<libv>
arokux2: and ati provided some register level documentation for a while, as that was our requirement
<libv>
as soon as we were out of the picture, ati stopped.
<libv>
trying finding register level information for hw newer than rv670
<ssvb>
oliv3r: if you look at http://i.imgur.com/hED57SD.png then you can see that it improved from being ~2.1x slower to just being ~1.3x slower overall (on AMD E-450, which has a pretty weak CPU)
<libv>
or even that, rv670 was never released
<libv>
i should actually be able to release this, as we only received documentation which was meant to go out
<arokux2>
libv, I've never seen news on this
<libv>
this was our requirement
<libv>
arokux2: the world doesn't care.
<arokux2>
libv, well, I care!
<libv>
arokux2: and the noisemakers and ati wouldn't want you to know, as it would expose the fact that they made a pact with the devil
<libv>
arokux2: the developers of radeon actually are playing a (small) part in AMD losing grip on ATI
<libv>
well, have played, amd lost grip. period.
<arokux2>
although I have nvidia at work, my flash crashes if accel is enabled. if it is off, then youtube videos are not scaled properly, so I care.. because if it were open src driver i'd get it fixed in a day
<libv>
the fact that they are now appearing as red everywhere instead of green, should tell you enough
<libv>
"global provide of innovative graphics, processors and media solutions"
<oliv3r>
| AMD
<arokux2>
ATI Technologies was acquired by Advanced Micro Devices (AMD) in 2006.
<libv>
arokux2: but former ati now runs the show
<libv>
amd paid more for ati than their own stock market value 2ys down the line
<libv>
ati was almost bust
<hno>
oliv3r, I'd rather have the DRAM info in the SPL header so it's checksummed with the rest of SPL.
<arokux2>
"former" ATI? are there two ATIs or what?
<libv>
yet in 2007-2008 it was clear that ati was more of a trojan horse than anything else
<oliv3r>
rellla: display resultion is read straight from the register, but that's only the current size (which looks right to me)
<arokux2>
libv, so currently no GPU manufacturer is providing documentation to the public?
<oliv3r>
nope, we (FOSS people) are always screwed
<libv>
arokux2: intel is
<oliv3r>
oh really?
<libv>
arokux2: they started doing it after we started with radeonhd
<oliv3r>
well we're still screwed :p
<arokux2>
well, apart from intel
<arokux2>
this changes a lot for me
<libv>
and the amd gpgpu people are still providing shader docs
<hno>
but no register details?
<arokux2>
and once again proves phoronix is a shitty resource on the subject
<libv>
hno: nothing on display, power management, engine management, etc
<libv>
and this is exactly the part that we at suse wanted to be free
<oliv3r>
arokux2: duh :p phoronix is 'nice to read, but always remember it's a tabloid'
<libv>
because we needed a working display at decent powerusage, before 3d acceleration
<libv>
enterprise customers, as well as normal home users, need a working display before anything else.
<arokux2>
oliv3r, nice to read? no analysis, just copied together pieces from other sites and autogenerated tests results with again no analysis
cajg has quit [Quit: fonts ballsed]
<hno>
Yes, what is the point in stopping people from getting 2d framebuffer working well?
<oliv3r>
arokux2: it's entertaining from time to time
cajg has joined #linux-sunxi
<libv>
hno: the mode of working of ati internally.
<libv>
with atombios, and their complete fork of the previous gen codebase with each new gen
<arokux2>
can somebody recommend a book on GPU architecture?
<libv>
arokux2: nope
<hno>
libv, fork and screw up worse seems to be default mode of operation in operations originating in hardware logic design...
<oliv3r>
"my precious"
<libv>
arokux2: what is out there that claims to be such is just crap
<libv>
hno: i was against atombios from the start
<hno>
anyone with sane mind would be..
<libv>
why, technically, because of the ati mode of working, where fglrx and atombios were brought up simulatenously, and ati made a new codetree for each new gen
<libv>
so basically, we had to be bug compatible with the fglrx driver to be able to use atombios as effectively
<libv>
and we almost forced ourselves to make a complete fork, or go somewhat in that direction, for each new gen
<libv>
and this even for simply bugs in atombios
<libv>
and not for hw bugs.
<libv>
plus, this was 2007, finally the world was convinced that depending on VBE + hacks for modesetting was stupid
<libv>
if i, who started all of that, had taken on atombios, can you imagine what crap i would've gotten?
<libv>
and so those who would've thrown that crap instead went with ati
<libv>
and started throwing crap at us for not using atombios
hipboi has quit [Quit: Leaving]
<libv>
and then, 6 years on, the world remembers that these idiots "freed" ati...
<oliv3r>
your friend does not equal the world :(
<libv>
and that this evil novell corporation had some secret deal with the other evil corporation (whether that is amd or ati is not clear, probably the "evil corporate part of amd", not the friendly open source part of amd), so that novell could press its microsoft hacked software onto everyone
<libv>
luckily the heroes of redhat and the xorg community and the friendly open source faction inside amd put a stop to that.
<oliv3r>
so what was that novell <-> microsoft deal?
<libv>
it happened before i joined suse
<libv>
but...
<libv>
microsoft was starting to play out its patents
<libv>
and saw the treath of linux
<libv>
threat even
<libv>
and suddenly it ran into novell, which, along the way, had acquired all those unix patents
<libv>
and then suddenly microsoft and novell came to an agreement where microsoft would not sue novell
<libv>
for linux ip
<libv>
and microsoft bought 60mil suse enterprise licenses per year
<libv>
now how is that bad for free software?
<libv>
how could microsoft sue canonical or redhat after that?
<libv>
and it was a nice injection of cash into open source software
<libv>
ask yourself, who could possibly gain from this noise?
<ssvb>
better software does not always (easily) wins, there is still always lots of politics involved, one of the recent examples is libjpeg vs. libjpeg-turbo
<oliv3r>
libv: for what its worth, I was much younger when radeonHD first came out, still using r300 at the time and was excited about anything opensource radeon. I vividly remember however, that this radeonHD was doing things in a much more sane way, not using some propriatry 'atombios' interface
<libv>
also remember, the SCO trials were ongoing, and novell defended things quite well there
<libv>
and later on, companies like redhat signed similar deals with microsoft, but less or no money changed hands
<libv>
but noone speaks of that
<libv>
i hate novell myself, it was a stupid bank that mismanaged suse
<oliv3r>
cooperate world :(
<libv>
it bought up companies, sucked them out, and then wondered where the business went
<libv>
it hasn't succeeded in killing suse, although it got real close
<libv>
but all the ms&novell crap was totally unjust
<libv>
and can only be explained in one way.
<libv>
suse was huge around the dotcom boom, probably even bigger than redhat, but redhat had the better strategy and was on its way to be the linux monopolist
<libv>
novell, with many billion in the bank, bought suse, and ensured its long term survival
<arokux2>
libv, just to clarify, so radeonhd isn't developed anymore?
<libv>
suddenly suse was back by a company an order of magnitude bigger than rh
<libv>
and then microsoft starts giving suse 60million a year, for free.
<libv>
arokux2: by the start of 2009, amd was in severe financial trouble
<libv>
it sold of its foundries
<libv>
it also cut down on this mismanaged and out of control open source partnership with suse
<libv>
as luck had it, novell also decided to cut 20% of developers at the main suse location
<libv>
here.
<libv>
so it ended there and then.
<libv>
mshopf had just brought up the first triangle on the r600
<libv>
but history also forgot all about that one.
<arokux2>
libv, and since 2009 nobody maintains/improves it?
<libv>
2 years on, a redhat employee even abused his freedesktop.org admin rights to maim the radeonhd repository.
<libv>
arokux2: there were some further fixes, but not much
<libv>
arokux2: and the world was already fully on the noisemakers side
<libv>
noise and crap is always victorious over noble goals and technical prowess.
<arokux2>
libv, that were developing radeon?
<libv>
which brings is right back to the start of this.
<libv>
arokux2: yes.
<libv>
arokux2: but now development slowed down seriously
<libv>
as noone was solving the tough bits for them anymore.
<arokux2>
libv, and radeon uses atombios, something that is bad and you do not like?
<libv>
it has more extensive use of atombios, yes
<libv>
and bad structure
<libv>
but even they had to give in and recode some bits in proper C
<libv>
because anything else was not workable in a proper driver.
<libv>
arokux2: they are still using gpio bitbanging to talk to DDC, egbert eich is the only person on the planet who figured out how to use the i2c engine...
<libv>
they are still messing about with plls...
<arokux2>
libv, sorry, i'm not that deep into inner workings of the hardware
<libv>
"if we set this pll, with this parameters, it is unstable" "what if you approach this one parameter from the other end"
<arokux2>
libv, but nvidia is even worse, providing nothing, isn't it?
<libv>
they have a table where some chip revision, on some resolutions, the pll parameter calculation is done from the opposite side, in the hope that the unstability is not reached
<libv>
arokux2: yes, and no
<libv>
arokux2: nvidia provides a much more decent and useful binary
<libv>
arokux2: and it does not require a full system update for a new driver
<libv>
and you can revert to an older driver
<libv>
neither intel or ati are providing all of that
<arokux2>
libv, well, then nvidia gpus will be bought more frequently
<libv>
they are
<arokux2>
at least i was recommending them all the time to my friends
<libv>
and tegra is the best supported mobile gpu
<libv>
with an nvidia employee claiming that even the 3d engine will be opened up in time
<arokux2>
i do not understand what is the point for ati to develop it's own driver and then to support (although a little) radeon
<libv>
again, marketing
<libv>
what we learned along the way was that the bad ati image was hurting amd server cpu sales
<libv>
the current radeon driver, and the 4 employees working on it, are just a figleaf
<arokux2>
server?! what server has to do with GPUs?
<libv>
first off: more and more
<libv>
secondly, the image of amd was being dragged down by the bad image of ati binary drivers
<arokux2>
libv, more and more, but because of GPGPUs not because of graphics, or?
<libv>
yes
<libv>
anyway, the open source strategy for amd was done for two reasons
<arokux2>
ok, i see
<libv>
one, to get rid of this big stain on the reputation, two, to find a corner where ati could be gotten under control
<arokux2>
that's already something
<libv>
if we had known this from day one, we would've never started
<arokux2>
4 employees vs. 0 at nvidia..
<libv>
arokux2: 4 employees providing the figleaf, a small army providing a driver which still is not too appreciated
<libv>
arokux2: versus a small army providing a binary driver which mostly works
<arokux2>
libv, if interested people could improve the driver from ati, but nothing could be done with nvidia's one. so there is an additional advantage here..
<libv>
yes
<libv>
but it is a small advantage compared to what we at suse had envisaged
<libv>
and had painfully worked towards
<arokux2>
libv, yes, I see this point.
bsdfox has joined #linux-sunxi
<oliv3r>
libv: so what makes your lima work comparing it with ati history?
<oliv3r>
everybody knows lima = libv!
<libv>
oliv3r: it really is me against the world, and it is not on the corporate radar of some enterprise linux vendors
<libv>
so at least i will not get endless amounts of baseless crap thrown at me
<libv>
but history will be rewritten, i am sure of that
<arokux2>
libv, why do you care? if you have fun doing it then do it, if not, find another project that will make fun to you!
<libv>
arokux2: a project the size of this is not something that can survive on "just a bit of fun"
<arokux2>
libv, imho, you never know if your work will "change the world"
<arokux2>
even in science it took years (and more) before people realized that someone had a brilliant idea
<arokux2>
sometimes that person was lucky to be alive at this time :)
<libv>
arokux2: in science there is a strict policy about acclamation
<oliv3r>
libv: did you know allwinner is touting 'GPL compliance' and 'We are so awesome, look at these opensource hardware boards' on their website now?
<libv>
this does not exist in open source software, even though some like to think so
<libv>
the last 10ys have extensively proven this to me
<arokux2>
policy in science?
<arokux2>
which policy?
vinifr_ has quit [Quit: Saindo]
<arokux2>
i'm not talking about you proving some algorithm can be faster - that would be accepted immediately
<libv>
arokux2: write any scientific paper, and you have a references list which is usually quite long
<arokux2>
i'm talking about big ground changing ideas
<libv>
at least in the last century or so, such things can be traced back quite easily
<libv>
heck, i dug up the word modesetting recently...
<libv>
was never used before 2004.
<libv>
guess who started using it first
<arokux2>
you said it was you
<oliv3r>
AMD! :p jk jk
<libv>
and the reason for the awkward name was worries by the X community that display would crash with the X concept of XDisplay
<libv>
arokux2: i stated that the basic ideas behind kms were formed by my work on unichrome
<arokux2>
anyway, I'm very disappointed to here amd/ati support on the docs side seazed
<arokux2>
hear*
<libv>
arokux2: thank alex deucher, dave airlie, adam jackson, matthew garrett, daniel stone, benjamin herrenschmidt for that
<arokux2>
but how can those 4 ppl at amd work on radeon without docs?
<libv>
they are using internal documents and fglrx code and personel
<arokux2>
libv, so by putting it into code they are making docs public..?
<libv>
no, they are making information public
<libv>
not docs
<libv>
but they are only making information public for things which are needed at that time, not for things which are nice to have
<libv>
and just code is, longterm, harder to maintain than code and docs
Soru has joined #linux-sunxi
<oliv3r>
and who best knows this as the devs here from sunxi
<arokux2>
oliv3r, don't we have datasheet now?
<hramrach__>
also it does not work
<hramrach__>
try to hibernate a machine with radeon graphics but instead of powering off properly cancel the hiberantion
<hramrach__>
the system resumes immediately
<Turl>
arokux2: yeah, but it's hardly the best in class :)
<hramrach__>
and the crappy atombios locks up your card 90% of the time
<hramrach__>
but it presumably works for the developers
<arokux2>
go for nvidia guys and spread the world, this is the only thing that could be done
<oliv3r>
arokux2: our datasheets are ... crap, missings bits, mistakes etc. Also we only have A10 and A13. There is no A20 or A31 datasheet
<hramrach__>
and what do you get from nVidia?
<oliv3r>
arokux2: with nvidia, you atleast know you won't get anything from nvidia?
<hramrach__>
a binary driver that does not do xrandr
<Turl>
mturquette: ping
<hramrach__>
and tegra2 tablets just don't work
<hramrach__>
they promise drivers but I don't see that happening
<hramrach__>
the nvidia blob gained xrandr like a year ago, maybe
<Turl>
hramrach__: tegra2 is kind of obsolete these days
<hramrach__>
everything is obsolete or too new to work well
<arokux2>
oliv3r, A20 is pin compatible with A10 doen't it say it has same data sheet?
<Turl>
hramrach__: that's the mobile world these days
<hramrach__>
it's not different with any graphics
<Turl>
hramrach__: at least a 2yo PC GPU is still considered decent
<Turl>
a 2yo phone is crap :)
<ssvb>
hramrach__: +1
<hramrach__>
that's for the most part because the drivers are not available for current OS release
<hramrach__>
it was working 2y ago and would work still but you are stuck wit old and buggy software
<Turl>
hramrach__: that doesn't hold true
<oliv3r>
pin compatible yes, register compatible? not entirly
<Turl>
hramrach__: software vendors bloat their applications over time
<oliv3r>
arokux2: if they where, the drivers would just work, and wouldn't need fixin' :p
<hramrach__>
not over 2 years
<Turl>
hramrach__: try using the facebook app on a 2y old android phone without pulling your hair
<arokux2>
oliv3r, but it worked for cubieboard
<oliv3r>
why would you want ot use facebook
<oliv3r>
arokux2: erm, no
<Turl>
esp. if said phone was mid/low range back then
<Turl>
oliv3r: it was just an example :p
<hramrach__>
try using anything facebook without pulling your hair
<oliv3r>
Turl: oh i know, my gf uses it :p
<oliv3r>
Turl: but on an S2 it splenty fine, on a GIO it's hairpulling
<Turl>
hramrach__: on a quad core with 2G ram it works "fine" :)
<Turl>
yeah an S2 would be fine
<hramrach__>
not for my definition of "fine"
<hramrach__>
it's fb
<oliv3r>
arokux2: cubieboard is using the allwinner 3.3 kernel. The 3.3 kernel is a fork of 3.3, + their a10 patches ontop, forked those again, and then modified/fixes those
<Turl>
we're talking about the app performance here, you can keep your opinions of the service itself for later :)
<hramrach__>
who on earth with osme sanity left would use fb/
<hramrach__>
I have no opinion on performance of app that can be only used to acces a service I don't use
<Turl>
hramrach__: people who need to communicate with people who think facebook private groups and fb messenger are an effective comm means :(
<arokux2>
oliv3r, i meant they just replaced A10 with A20 and everything worked on the hardware side.. i thought on the software side it should have been the same, but apparently not...
<hramrach__>
by not joining in I make them ineffective means of communication with me :p
<Turl>
hramrach__: it ain't that easy :)
<hramrach__>
arokux2: the hardware inside the chip has evolved somewhat. the interface to the outside is mostly unchanged
<arokux2>
hramrach__, I thought if the same pin does the same job, than the software should be the same too
<hramrach__>
heh, I have cardfail on a10
<hramrach__>
and nandfail too
mouchon has left #linux-sunxi [#linux-sunxi]
<hramrach__>
it spins printing FS errors :/
<arokux2>
btw, has anybody built in the initramfs into the uImage with success?
<ssvb>
arokux2: no it does not work this way
<ssvb>
arokux2: a simple analogy, if the PCI-E interface is exactly the same, does it mean that the graphics cards can use identical drivers?
<arokux2>
ah, ok
<hno>
Turl, no, it's ~4 years with NVidia, after that you are stuck on old drivers and can only hope it's possible to shoehorn them to work in current OS:es.
<hramrach__>
I have link flipping on wemac now
<hramrach__>
hmm, flipping link was cable problem
<rellla>
utente: ok. so created two branches with two possible fixes of the bluescreen issue. i'll try if the compile at least
<utente>
rellla, good boy
<utente>
rellla, where the howto? is enoug to follow the same info on xbmc page of linux-sunxi?
<Turl>
hno: well, you can keep on using old drivers in windows
<rellla>
simply compile it as you ever did.
<hno>
Turl, sometimes.. but many times display drivers do break in next windows..
<arokux2>
as with winxp to win7 transition
<hno>
or win7 to win8..
<arokux2>
interesting...
<hno>
but now we are getting offtopic.
<Turl>
you can keep your old windows for like 10 years (xp anyone? :)
<Turl>
hno: agreed
<hno>
Back on topic direction the 3D support in Linux is far better on this laptop than the Windows drivers, making it possible to use it still.
<arokux2>
this laptop being?
utente has left #linux-sunxi ["Sto andando via"]
<hno>
some old Intel chipset.
<hramrach__>
Turl: you can keep pold windows so long as MS supplies patches for them. they are threatening to discontinue XP for a few years already
utente_ has joined #linux-sunxi
<arokux2>
why do you need patches? :)
<hramrach__>
because everything as solid as a sieve
<arokux2>
normal ppl do not need patches
<hramrach__>
no, they need them more than anyone
<hno>
hramrach__, why? You don't like botnets?
<arokux2>
hramrach__, or what will happen to them?
<arokux2>
me and my friends when still on windows never used updates
<arokux2>
and never had problems
<hramrach__>
they will get crapload of viruses every time they fire their web browsers and go to non-trivial number of web sites
<hno>
my friends using windows with all updates and anti-virus sofftware and firewalls still gets owned...
<hramrach__>
sure
<arokux2>
hno, this is strange
<hramrach__>
not installing updates leaves the door wide open even to old suff, still
<hno>
arokux2, quite often you don't notice unless you look at your network.
<hno>
which makes the static nature and short lifespan of most Android devices a scary topic..
Soru has quit [Ping timeout: 264 seconds]
<hramrach__>
there are viruses for them, of course
<hramrach__>
that install into the nand and are pretty much undetectable :)
<Turl>
hno: my GM45 notebook (Q3 '08 chip) works great with GNOME Shell and the like
<hramrach__>
especially with all these restrictions on non-rooted devices which hide the flash from the user :)
<hno>
Turl, ofcourse, that's not NVidia.
<Turl>
hno: it supposedly can even decode h264 in hw with some shady branch of libva
<hramrach__>
I had lots of trouble with Intel graphics around that chipset age - like 915/945
<hramrach__>
but I guess they worked on it since then
<hno>
hramrach__, driver has improved considerably in the last couple years.
<Turl>
I jumped from an i810 or so to GM45, been happy overall with intel graphics
<hno>
Fedora ~13 had lots of issues with composing window managers. Fedora 16+ is very smooth.
<hno>
Correction. F15/F16 had lots of issues. F17+ is smooth.
<WarheadsSE>
Well if that is the iMX6, then the PHY is limited to ~ 400mbps in reality
<WarheadsSE>
it's in how the phy/buffer was actually attached
<arokux>
that's ok, my internet is 25mbs and its for home with up to two persons
<arokux>
I could use mele a1000 as router + access point (if wifi card allows this), with usb2ethernet, i can get 2 PHYs so I do not need to buy usb2wifi adapter for my desktop PC
<rm>
a1000 as router + access point (if wifi card allows this) <- yes it does but you will need a patched hostapd
<hno>
arokux, yes the wifi supports AP mode via an old realtek hosapd. If you get the mainline driver working then modern hostapd versions will work as well, but have not seen any good results with the mainline driver.
* WarheadsSE
hasn't tried it on Arch yet
<hno>
the issues seen is at driver level, not distribution dependent.
<WarheadsSE>
Yeah, just saying I haven't tried it
<WarheadsSE>
since I am generally the one messing with the sunxi family, it usually falls to me
<arokux>
hno, then this will be my task to fix the driver! then I could actually put mele to good use :)
<hno>
arokux, I tried backporting the current mainline driver, and things did improve a bit allowing clients to associate and even obtain IP from the dhcp server, but traffic jams after some packets exchanged.
_BJFreeman has joined #linux-sunxi
_BJFreeman is now known as BJfreeman
<hno>
arokux, you can find the backported driver in my sunxi-3.4-rtlwifi branch.
<arokux>
hno, ok, thanks a lot. why have you backported it anyway? was it not present in old 3.0.8 kernel? or it was easier to backport from mainline to 3.4 then to move from 3.0.8 to 3.4?
<ykchavan>
I followed these instructions http://linux-sunxi.org/Buildroot . I got sun4i_'linux_cubieboard.img' file with almost nothing in it.\
<ykchavan>
How can I create ubuntu images using these steps?
<arokux>
ykchavan, have you got log of the build? can you upload it somewhere and put link to it here?
<ykchavan>
sure
<ykchavan>
arokux, what I can tell without looking at log is that rootfs added here does not have many files
<ykchavan>
allwinner-buildroot/target/skel has not many files in it.
<arokux>
ykchavan, well, it is how its creator wanted it to be...
<arokux>
but you need ubuntu image for cubieboard?
<arokux>
ykchavan, wait, this is some windows shit
<ykchavan>
arokux, I am interested to build ubuntu img and not installing it.
<arokux>
ykchavan, I see, but you do not want to build it from source, right?
<ykchavan>
I do want to build from source.
<arokux>
ykchavan, for that you need to build 1) u-boot, 2) kernel 3) rootfs
<arokux>
ykchavan, for the build you need a toolchain - a compiler which will run on your desktop but output binaries suitable to run on ARM
<ykchavan>
I built u-boot and kernel for cubieboard. The rootfs I am using is very small and it does not have many files. I want rootfs to create ubuntu image.
<arokux>
then find rootfs: either ubuntu one or from linaro
<ykchavan>
ok
<ykchavan>
I thought buildroot is the standard here as it is mentioned wiki and none other build system.
<hno>
arokux, those instructions are for building and SD card however. Livesuit images is slightly different.
<arokux>
but ykchavan wants an SD card, right?
<hno>
ykchavan, the small test system used by cubieboard manufacturing is buildroot based. And I think Allwinner also uses buildroot for compiling the kernel.
<hno>
SD card images is a lot easier to compose than livesuit images.
<ykchavan>
I see.
<arokux>
ykchavan, you wanted an SD or livesuit image?
<ykchavan>
I want livesuit image. But if sd card is easier, I will try that.
<hno>
begin with sd card. Then look into livesuit if still needed. You can also transfer the system from sdcard to nand after booting from sd if desired.
<ykchavan>
I made one livesuit image(using wiki page) and flashed on cubieboard nand which had minimal files in rootfs. It did not have any GUI utilities.
<ykchavan>
Let me stop livesuit image creation efforts and try sdcard images.
<ykchavan>
Thanks for your help. I might bother again in future.
<ykchavan>
hno++
bsdfox_ has quit [Ping timeout: 268 seconds]
<hno>
ykchavan, feel free to ask here any time. Just ask (see topic).