Turl changed the topic of #linux-sunxi to: Allwinner/sunxi development discussion - Don't ask to ask. Just ask and wait! - See http://linux-sunxi.org | https://github.com/linux-sunxi/ | Logs at http://irclog.whitequark.org/linux-sunxi
physis has joined #linux-sunxi
blsd has left #linux-sunxi [#linux-sunxi]
bertrik has quit [Remote host closed the connection]
physis has quit [Remote host closed the connection]
ganbold_ has joined #linux-sunxi
mrsalomao has joined #linux-sunxi
mrsalomao has quit [Client Quit]
physis has joined #linux-sunxi
physis has quit [Ping timeout: 276 seconds]
egbert has quit [Disconnected by services]
egbert has joined #linux-sunxi
seere_ has quit [Ping timeout: 240 seconds]
book` has quit [Quit: ERC Version 5.3 (IRC client for Emacs)]
book` has joined #linux-sunxi
book` has quit [Remote host closed the connection]
book` has joined #linux-sunxi
book` has quit [Client Quit]
seere_ has joined #linux-sunxi
pseudomind has joined #linux-sunxi
book` has joined #linux-sunxi
TheSeven has quit [Ping timeout: 252 seconds]
TheSeven has joined #linux-sunxi
<slact> hi, i'm trying to get device info via USB in FEL mode on a new el-cheapo A23 tablet, and the fel tool is giving me an error:
<slact> sudo fel read 0x42400000 0x82d0 boot1.header
<slact> -> libusb usb_bulk_send error -7
<slact> agh, nevermind, it's in the wiki.
<slact> i can get to bot0, but not boot1 to dump stuff. there's a magic.bin on /dev/block/nanda, which fel segfaults on
<slact> (i have a read-only UART console to the device)
<Turl> slact: at least on some other devices (dunno about A23) you can get to fel by doing a bunch of magic button presses on the volume rocker and others
<slact> i did that, and got to fel from BOOT0
<slact> here's the cnsole output: http://pastie.org/9114063
<slact> looks like it's tuck in boot0
<slact> maybe I could jump to boot1 if i knew an address to exec...
<Turl> hmm where's boot1?
<Turl> I think it printed some spammy banner too
<slact> and i'd need to edit some memory along the way so that boot1 gets stuck in FEL mode ... if i'm understanding the boot process correctly
<Turl> slact: I think it was boot0 that initialized the ram though..
<Turl> but it's 1AM and I'm not sure now :)
<Turl> ask wens if he's around, he has been playing with A23 too
<Turl> he even wrote some uboot patches I think, check the list
<slact> yeah, i tried his sunxi-tools branch just an hour ago for a similar tablet
<slact> doesn't work on this one
<slact> any other way I can grab the necessities from a rooted android?
<Turl> slact: what necessities are you looking for though?
<Turl> is that a button next to the sd slot?
<slact> a10-meminfo : http://pastie.org/9114081
<slact> enough to build a bootable mmc
<slact> ( so, basically, u-boot-sunxi-with-spl.bin )
<Turl> slact: uboot is really really green though, wens just started working on it days ago
<Turl> there's no SPL for A23
<slact> can i grab it from the device?
<Turl> and kernel support on linux-sunxi is nonexistant at this point
<wens> there's no boot1 on A23
<slact> reuse a binary blob somewhere?
<Turl> oh here you are wens :)
<wens> boot0 does dram init, then chain loads u-boot
<slact> do you have any suggestions on what might be done?
<wens> I've tried using mmc boot0 from the A23 SDK, didn't get any output, so I'm assuming it doesn't work ATM
<slact> given that I have a read-only UART right now
<wens> what output are you getting on the UART?
<slact> http://pastie.org/9114063 when i tried getting to FEL mode
<wens> that's UART0, which is muxed with MMC0
<Turl> wens: remember the A31 had that weird uboot pin/button thing to boot from mmc, maybe A23 has something similar too
<slact> http://pastie.org/9114090 for a normal boot to android
<wens> what you need is to dump the dram parameters from NAND u-boot (the values from the FEX file aren't always right)
<slact> wens: right, that's why i was getting garbage with mmc activity
<Turl> good night guys
<slact> good night, and thanks for your help
<Turl> anytime :)
<wens> put them in your fex file, compile it and use Allwinner's tools to update a boot0 for fel mode
<slact> okay, let me parse that
<slact> can I dd all of nand and grab things from there?
<wens> the dram parameters are in a header portion of u-boot
<wens> I don't think you can get it from inside the OS
<slact> a10-meminfo gave me http://pastie.org/9114081
<slact> it looks kindof bogus
<wens> the dram controller is different, a10-meminfo doesn't work
<slact> figured
<wens> well see if you can find the TX for the UART (either using uMMC breakout or something)
<wens> if you do , you can interrupt u-boot during power up, by pressing 's'
<slact> yeah, guess i'll have to probe around
<slact> you're saying it's using another of the mmc's pins?
<wens> Turl: if I put an SD card in and power up, it hangs :p
<wens> you can try my fel boot0 if you want: http://wens.csie.org/a23-fel.img
slact has quit [Remote host closed the connection]
slact has joined #linux-sunxi
<slact> ok, going to give it a try
<slact> i dd'ed it onto an mmc, rebooted the tablet, and the console spat out some garbage
<slact> either i did something wrong or it didn't work
<wens> if not, get TX working, and dump 0x4a000030 ~ 0x4a0000b0 from u-boot, that'll be your dram parameters
<wens> that image is for fel mode, not mmc
<wens> since you're using a console shared with mmc, using mmc will only give you garbage output
<slact> sorry, i don't yet know what to do with that
<slact> oh right
<wens> get into fel mode
<wens> load the boot0 with the fel tool (load to 0x2000) and execute it
<slact> i see, will do
<wens> then you can build a u-boot without SPL, and load it to DRAM
<wens> you can do the above with the usb-boot script I think
<wens> my u-boot patches should work for you, just remember to remove the CONSOLE_ID=5 from the config
* wens getting lunch
<slact> ok, i'll try. thanks for your help!
\\Mr_C\\ has quit [Ping timeout: 252 seconds]
\\Mr_C\\ has joined #linux-sunxi
<slact> wens: your image worked. I've got script1.bin and boot1.header. thanks!!
<slact> and none of the uSD card pins were UART Tz
<slact> Tx
slact has quit [Remote host closed the connection]
slact has joined #linux-sunxi
slact has quit [Remote host closed the connection]
slact has joined #linux-sunxi
FreezingCold has quit [Quit: Out]
<slact> now i need to know the magic for bootinfo
FreezingCold has joined #linux-sunxi
<slact> bin2fex doesn't work either
FreezingCold has quit [Quit: Out]
physis has joined #linux-sunxi
<wens> what magic?
gzamboni has quit [Read error: No route to host]
physis has quit [Ping timeout: 252 seconds]
<slact> bootinfo says "Bad Magic"
<slact> 1 sec, i'll paste
FreezingCold has joined #linux-sunxi
<wens> not sure why your fex file fails to decompile
<slact> quick aside: is there a way to wrote to boot if I, say, wipe the bootloader on nand? a way to reflash nand?
<slact> i can share it
<wens> how did you get the boot1.header?
<slact> sudo fel read 0x42400000 0x82d0 boot1.header
<wens> that probably won't work with A23, as it doesn't have boot1
<slact> it did from your bootloader
<wens> what I mean is there's nothing to load
<slact> there are some useful-looking strings separated by nulls in it
<slact> followed by what looks like program data
<slact> so where do i read/ how might i discover where to read?
<slact> any strings to look for if i just dump ram?
gzamboni has joined #linux-sunxi
wingrime has joined #linux-sunxi
<wens> don't know
<wens> The A23 SDK doesn't include a boot1 when you build an image using it
<wens> The SDK is missing some things, so you might not be able to build an image on your own
<wens> but you can build their u-boot and update their boot0
<wens> that is about all I have now
pseudomind has quit [Quit: pseudomind]
<slact> where might i gram the a23 sdk?
<slact> grab
<slact> (and, by the way, thanks for your help. you're blazing the A23 trail)
<wingrime> wens: can you read pll settings for CPU?
<wingrime> wens: I just want know real freq
marcin__ has joined #linux-sunxi
marcin_ has quit [Ping timeout: 252 seconds]
physis has joined #linux-sunxi
diego71 has quit [Ping timeout: 240 seconds]
physis has quit [Ping timeout: 255 seconds]
diego71 has joined #linux-sunxi
<wens> slact: should be a link on the A23 page on the wiki
<slact> wens: the tarball over at http://dl.linux-sunxi.org ?
cubear has joined #linux-sunxi
leviathanch2 has joined #linux-sunxi
kuldeepdhaka has joined #linux-sunxi
ganbold has quit [Ping timeout: 276 seconds]
leviathanch2 has quit [Ping timeout: 240 seconds]
leviathanch2 has joined #linux-sunxi
Fusing3 has joined #linux-sunxi
<montjoie[home]> hello where I can find the A31 user manual and other AXX user manual ? I need to compare security system datasheet
jemk has joined #linux-sunxi
deasy has joined #linux-sunxi
leviathanch2 has quit [Ping timeout: 240 seconds]
leviathanch2 has joined #linux-sunxi
focus has quit [Ping timeout: 240 seconds]
libcg has joined #linux-sunxi
physis has joined #linux-sunxi
linkmauve1 has left #linux-sunxi [#linux-sunxi]
leviathanch2 has quit [Ping timeout: 240 seconds]
linkmauve1 has joined #linux-sunxi
linkmauve1 has quit [Quit: Gateway shutdown]
<libv> slact: please fix that device page
linkmauve1 has joined #linux-sunxi
xinj has joined #linux-sunxi
leviathanch2 has joined #linux-sunxi
torindel is now known as torindel2
torindel2 is now known as torindel
bertrik has joined #linux-sunxi
bertrik has quit [Changing host]
bertrik has joined #linux-sunxi
physis has quit [Remote host closed the connection]
leviathanch2 has quit [Ping timeout: 264 seconds]
leviathanch2 has joined #linux-sunxi
FreezingCold has quit [Ping timeout: 265 seconds]
physis has joined #linux-sunxi
leviathanch2 has quit [Ping timeout: 240 seconds]
physis has quit []
leviathanch2 has joined #linux-sunxi
leviathanch2 has quit [Ping timeout: 276 seconds]
xavia has joined #linux-sunxi
codyps has quit [Ping timeout: 252 seconds]
codyps has joined #linux-sunxi
xavia has left #linux-sunxi ["PART #interlock :PART #arduino :PART #wnydev :PART #buffalolab :PART #docker :PART #symfony :PART #virtuvia :PONG :dickson.freenode.net"]
physis has joined #linux-sunxi
Black_Horseman has quit [Quit: Zwi se logou mou!!!]
kuldeepdhaka has quit [Ping timeout: 264 seconds]
kuldeepdhaka_ has joined #linux-sunxi
physis has quit [Remote host closed the connection]
physis_ has joined #linux-sunxi
xavia has joined #linux-sunxi
forcev has quit [Ping timeout: 264 seconds]
FunkyPenguin has joined #linux-sunxi
physis_ has quit [Remote host closed the connection]
jemk has quit [Quit: leaving]
physis has joined #linux-sunxi
<wens> montjoie[home]: there is no "user manual" for A31, only a brief
physis has quit [Remote host closed the connection]
notmart has joined #linux-sunxi
notmart has quit [Changing host]
notmart has joined #linux-sunxi
<montjoie[home]> wens so how to develop driver for a31 ?
<bertrik> montjoie[home]: as I understand, hardware modules (like USB controllers, DRAM controllers, etc.) in many ARM SoCs is similar, so you can try to re-use and adapt an existing driver for example
<montjoie[home]> wens and for A10 ?
mmarker1 has joined #linux-sunxi
<wens> you can find manuals for A10, A20, A23 on the wiki (on each SoC's pages)
mmarker has quit [Read error: Connection reset by peer]
physis has joined #linux-sunxi
captainigloo has quit [Quit: Bye Bye]
captainigloo has joined #linux-sunxi
vector80 has quit [Remote host closed the connection]
leviathanch2 has joined #linux-sunxi
orly_owl_ has joined #linux-sunxi
orly_owl has quit [Disconnected by services]
orly_owl_ is now known as orly_owl
orly_owl has quit [Changing host]
orly_owl has joined #linux-sunxi
leviathanch2 has quit [Ping timeout: 252 seconds]
bonbons has joined #linux-sunxi
orly_owl_ has joined #linux-sunxi
orly_owl has quit [Ping timeout: 255 seconds]
orly_owl_ is now known as orly_owl
orly_owl has quit [Changing host]
orly_owl has joined #linux-sunxi
Net147 has joined #linux-sunxi
Net147 has quit [Client Quit]
Net147 has joined #linux-sunxi
Net147 has quit [Client Quit]
<Turl> wingrime: someone sent ir patches for mainline, is that you?
<wingrime> Turl: nope
<wingrime> Turl: I find some problem with loading / reloading as module
<wingrime> Turl: It onhold for this reason
<Turl> wingrime: maybe your code cleaner
<Turl> wingrime: see the patches
<wingrime> Turl: who knows
<Turl> wingrime: guy also seems from .ru
<wingrime> Turl: h..
<Turl> wingrime: if you can collaborate that would be great
<wingrime> Turl: thats patch are inapropriate for mainline
<wingrime> Turl: I just see crap
<wingrime> 1) decode in code ( I just send raw data to framework)
<wingrime> 2) thats not input subsustem
<Turl> wingrime: yes, patch does not look very good
<wingrime> Turl: Whats should I do ....
<wingrime> Turl: maybe I need send RFC
<Turl> that would be good
<wingrime> Turl: but problem still there
<Turl> wingrime: maybe he can help debug problem
wens has quit [Ping timeout: 252 seconds]
wens has joined #linux-sunxi
<wingrime> Turl: thats something I do incorrectly with platform structure
physis has quit [Remote host closed the connection]
<Turl> wingrime: send rfc then, many people can look at it
<wingrime> Turl: I need still rebase it
kuldeepdhaka_ has quit [Read error: Connection reset by peer]
orly_owl_ has joined #linux-sunxi
<wingrime> also, my git tree are suddenly broken
<wingrime> fatal: packed object f093cea0d0600797cc1574c6f85a25dac5c128fc (stored in .git/objects/pack/pack-451d60fcf22b7f93f77d52e9d75d9231743bd52d.pack) is corrupt
orly_owl has quit [Disconnected by services]
orly_owl_ is now known as orly_owl
orly_owl has quit [Changing host]
orly_owl has joined #linux-sunxi
<Turl> wingrime: to lists, not to me :p
<Turl> wingrime: ouch :(
<wingrime> Turl: how SSD can do that?
Gerwin_J has joined #linux-sunxi
<wingrime> Turl: ok, take a look at all, and I will rebase it against current mainline
<wingrime> Turl: I need reload kernel git again
<Turl> wingrime: maybe ssd is starting to fail? :/
wingrime has quit [Ping timeout: 252 seconds]
wingrime has joined #linux-sunxi
orly_owl has quit [Ping timeout: 252 seconds]
orly_owl has joined #linux-sunxi
aazzddgg has quit [Ping timeout: 264 seconds]
orly_owl_ has joined #linux-sunxi
physis has joined #linux-sunxi
notmart has quit [Quit: notmart terminated!]
orly_owl has quit [Ping timeout: 265 seconds]
eagles0513875 has quit [Ping timeout: 255 seconds]
orly_owl_ has quit [Ping timeout: 265 seconds]
orly_owl has joined #linux-sunxi
aazzddgg has joined #linux-sunxi
orly_owl has quit [Ping timeout: 240 seconds]
SuperpelicanJoll has joined #linux-sunxi
orly_owl has joined #linux-sunxi
eagles0513875 has joined #linux-sunxi
Gerwin_J has quit [Quit: Gerwin_J]
<wingrime> Turl: seems I have some nice suggest from Hans
<Turl> wingrime: yes :)
<Turl> brb
<SuperpelicanJoll> buZz: looks like the rtlwifi driver is indeed better
<SuperpelicanJoll> buZz: will try a kernel with rtlwifi instead as soon as I'm at my computer again
<SuperpelicanJoll> buZz: currently on my phone
<Turl> SuperpelicanJoll: you got a systemd phone? :p
<SuperpelicanJoll> Turl: yes
<SuperpelicanJoll> :)
<SuperpelicanJoll> and Wayland :)
xavia has quit [Ping timeout: 265 seconds]
<wingrime> SuperpelicanJoll: how wayland on sunxi?
<SuperpelicanJoll> wingrime: No, Wayland on my phone
<SuperpelicanJoll> (not a sunxi device)
<wingrime> SuperpelicanJoll: :(
<Turl> wingrime: he is using using Jolla
<SuperpelicanJoll> Qualcomm Snapdragon 400
<Turl> s/using //
xinj has quit [Ping timeout: 264 seconds]
<mnemoc> get an A31S phone!
<wingrime> mnemoc: I want only optimus board
* mnemoc wants an olinuxino a80 :p
<mnemoc> with sata!
<wingrime> yeax
<SuperpelicanJoll> mnemoc: Is there a A31S phone?
<SuperpelicanJoll> :P
<wingrime> thats will be awesome
<mnemoc> SuperpelicanJoll: yes
<SuperpelicanJoll> LOL
<SuperpelicanJoll> Android?
<mnemoc> SuperpelicanJoll: yes
<SuperpelicanJoll> :(
<SuperpelicanJoll> But A31 also has PowerVR graphics, doesn't it?
<mnemoc> SuperpelicanJoll: yes
<SuperpelicanJoll> :(
<SuperpelicanJoll> So what's this new A80?
<mnemoc> pvr too
<SuperpelicanJoll> :(
<mnemoc> but 4xA15+4xA7
<torindel> SuperpelicanJoll: usually all "better" chips have powervr :<
<SuperpelicanJoll> That's a shame
<mnemoc> cheaper
<SuperpelicanJoll> Well the Jolla has an Adreno :)
<mnemoc> snapdragon has adreno, yes
<SuperpelicanJoll> The Freedreno driver is said to be in a nice state
<SuperpelicanJoll> So maybe someday the Jolla will be able to use the oss freedreno driver
<SuperpelicanJoll> instead of android driver + libhybris
<SuperpelicanJoll> :)
<SuperpelicanJoll> It's a pity though that lima isn't as mature as freedreno yet
<SuperpelicanJoll> That would certainly benefit the sunxi community :)
<mnemoc> iirc rob clark started a bunch of year before libv
<linkmauve1> No, I asked them at FOSDEM and they wouldn’t get support from Qualcomm if they provided a free driver.
<linkmauve1> So Jolla will continue to use the blob instead.
<libv> mnemoc: rob clark was march 2012
<libv> i started march 2011
<mnemoc> libv: :o
<libv> rob did have register definitions in headers
<SuperpelicanJoll> Well they say the Mali 400 is a strange chip
<libv> and the basics of command submission was the same as radeon r600
<SuperpelicanJoll> So that might explain it
jemk has joined #linux-sunxi
<libv> which i, egbert and emmes freed 7ys ago
<SuperpelicanJoll> :)
<libv> plus, rob has a cozy job at redhat where part of his freedreno time is company time
<libv> and he is very good and highly motived
<libv> motivated
<mnemoc> and he doesn't get trapped in wiki editing :p
<libv> he never had to deal with the Xorg forkers
<libv> not as such anyway
<libv> but just to get things straight, i was the first to do arm gpus
<libv> by quite a margin
<mnemoc> when was the radeon stuff began?
<libv> everyone else has followed in my footsteps, and you will often see bits of lima code used by the other REing projects
<libv> mnemoc: there was the avivo project in march 2007
<libv> this was daniels, mjg5 and glisse
<libv> but it was very superficial
<libv> and didn't do much
<libv> amd had bought ati a year or so earlier already
<libv> so the avivo project was good extra motivation for amd
<libv> the code was gpled, and not really worth keeping, so we didn't, as amd didn't allow us to talk
<mnemoc> ow
<libv> in april 2007, a former suse teamlead, then at amd, gave egbert a phonecall
<libv> as luck had it, i was at suse for my jobinterview
<libv> amd was having trouble with ati, and the fglrx drivers image was bad for amds image and was thus bad for the server market
<libv> egbert was asked for some ideas and insight into freeing ati
<libv> we spent the next two days in nue brainstorming, and ended up writing a solid proposal to amd
<libv> which was made public on phoronix
<libv> amd liked this, but ati was working against it
<libv> ati, or at least part of ati, went and talked to redhat behind our backs
<libv> we at suse got to do it in the end, and at the end of july 2007, we got a cubic meter of ati graphics cards
<libv> and then 2 badly formatted very low level register documents of 500p each were reluctantly given over by ati
<libv> 6 weeks later, despite atis lack of cooperation, we were showing everyone a mostly working display driver
<libv> and ati couldn't backtrack anymor
<libv> it instead chose to increase cooperation with redhat and a few "community members"
<libv> to create a competing driver which did things more the ati way
<libv> the suse guys were consistently labelled the evil corporate drones
<libv> whereas direct C code was labelled legacy, and atombios bytecode was being called "scripts"
<libv> just a few weeks ago, people at coreboot were complaining about atombios.
<libv> and i got to state "where were you guys in 2007, when i was giving the world proper C code, and ati/redhat/xorg forkers were making sure that amd graphics are still binary blob dependant?"
AndroUser has joined #linux-sunxi
<mnemoc> :\
<linkmauve1> That was radeonsi?
<libv> but, the world remembers the "evil corporate novell guys"
<libv> and the heroes on the other side
<slact> libv: fix what device page? I didn't break anything... Nor have I extracted anything useful from it (yet)
<libv> slact: so you are not intending to improve that page?
<slact> oh, of course I am. I just don't have much to contribute right now
<slact> I looked all over for Rx, but still no luck
<libv> mjg5 now got a free software award, which is quite amazing
<libv> as he actively was trashing a proper open source driver, whereas supporting a heavily binary blob based, barely maintainable hack called radeon
<AndroUser> libv arw you working at sunxi-kms?
<libv> linkmauve1: that was radeonhd
AndroUser is now known as pirea
pirea is now known as pireaa
<linkmauve1> Ah yes, this one.
<libv> AndroUser: yes, although i spent most of the week in the woods, disturbing beavers and other wildlife
<slact> gotta go
slact has quit [Quit: ChatZilla [Firefox 31.0a1/20140320030203]]
<libv> heh
<Turl> libv: hah
pireaaaa has joined #linux-sunxi
pireaaaa is now known as pireaaa
<Turl> libv: at least it wasn't wiki-based procrastination :p
<linkmauve1> I do remember nobody liked it.
<libv> linkmauve1: which is quite amazing
<libv> linkmauve1: as that was definitely not the case
<libv> linkmauve1: quite a lot of people liked it, very much so
<libv> but as is with everything open source, noise wins
<linkmauve1> I wasn’t in the right circle at that time.
<libv> linkmauve1: people only remember the noise, and forget about those who actually spend time on delivering
<linkmauve1> That is very sad.
<libv> linkmauve1: we at suse wrote a highly structured and clean driver, and we had to figure _everything_ out ourselves
<pireaaa> libv have you uploaded somewhere source?
<linkmauve1> pireaaa, http://www.x.org/wiki/radeonhd/
<libv> as our ati contact, who was supposed to help us out, never gave us anything but excuses
<libv> behind our backs however, he was busy making sure that the competing faction was being fed some info
pireaa has quit [Ping timeout: 240 seconds]
<libv> we got to RE all the bits that werent in the bare register docs
<libv> and the competing driver then happily took our code and fixes
<libv> what the competing driver spent its time on was nasty hacks that say, got a mode running on the composite connection, once, if booted up correctly and this and that
<libv> and then big noise was made
<libv> and then users came to us to demand the same functionality
<pireaaa> libv is about source of sunxi-kms
<pireaaa> not radeonhd
<libv> pireaaa: when i am happy with it, you will get it.
SuperpelicanJoll has quit [Ping timeout: 252 seconds]
<pireaaa> okey :)
<pireaaa> libv sunxi-kms is a dri driver?
<libv> pireaaa: because mostly idiots created kms, yes, it is a drm (not dri) driver
<libv> clueful driver developers would've implemented halfway decent separation in functionality
<libv> but forkers aren't the most clued folk around
<pireaaa> and dri2 is an engine who use drm?
<libv> ???
<pireaaa> what is dri2?
<pireaaa> i want to understand what you must do
<libv> pireaaa: dri2 is a communication protocol between X clients, the X server and mesa, to handle buffers
<pireaaa> and your work have nothing to do with dri2, right?
<libv> mostly to synchronize the different bits, and to get things displayed with minimal overhead
<libv> pireaaa: my lima work has more to do with dri2
<pireaaa> lima, but sunxi-kms no
<libv> kms is just modesetting
<libv> but the kms driver and the display server do need to talk about what to display when
<pireaaa> disp driver is something like kms but not automated, right?
<libv> but dri2 is not the best match for that
<libv> whut?
<libv> that failed to parse
<libv> what is "automated" in this sense?
<libv> "modesetting" is a "display engine configuration"
<pireaaa> yes, but disp driver lack this engine, right?
<libv> disp is short for display
<libv> disp is an allwinner specific implementation of a driver for the sunxi display engine
<pireaaa> tnx
<libv> why do you find it so important to have sunxi-kms, if you do not really seem to know what that is supposed to do?
<libv> pireaaa: why do you find dri2 so important in this context?
<libv> pireaaa: what are you trying to achieve, and are you sure that sunxi-kms is the answer?
<mnemoc> libv: after sunxi-kms, how much would be missing to get a fb on mainline?
<pireaaa> dri2 is not imortant but i don' understand diference betwen dri2 and drm
pseudomind has joined #linux-sunxi
<wingrime> libv: nice story, right code not always wins, that sad, usualy for people enought "just works" no matter how
<libv> pireaaa: drm is the kernel side of things
<libv> pireaaa: it started as a bit of kernel code to do a tiny bit of buffer synchronization between drm clients (X, Mesa, and actual clients) and to do things like interrupt handling and command submission
pseudomind has quit [Client Quit]
<wingrime> libv: how much still to do for HDMI framebuffer console ?
<libv> dri is the X protocol extension to do synchronization on buffers directly, between X, Mesa and dri2 enabled X clients
<libv> dri is all in userspace
<libv> drm is kernel, with a userspace library
<libv> kms was badly mashed in with the rest
<libv> in the kernel, that is
<libv> wingrime: hdmi was trivial to enable, and was working in january already
<libv> wingrime: hdmi audio and other special things are left todo, as there are enough people interested in working on such a fancy feature
<wingrime> libv: I tryed enable HDMI from uboot, but without luck, where I missed
<libv> wingrime: kms and disp are kernel, not bootloader
<andoma> libv: does KMS support multiple planes with alhpa blending and scaling using standard APIs?
<andoma> or will such things always be vendor specific
<wingrime> libv: yes, yes, I just wanted to use hdmi testbars
<mnemoc> that's the compositor, not the mode setting
<libv> andoma: badly, yes
<wingrime> libv: but I enabled only HDMI, not any other display module, but on live linux, I was able to turn on testbars with single register write :(
<libv> it was a good attempt, but it's an unfinished thought
<libv> mnemoc: that is modesetting
<mnemoc> libv: oh
pireaaa has quit [Ping timeout: 240 seconds]
<libv> wayland does support kms planes, but only because android hwcomposer was kicking the crap out of wayland in both speed and power usage
<libv> which is why jbarnes from intel created kms planes
<libv> but as said, it's an unfinished thought
<libv> before kms planes, i think i was the last to actually implement overlays (in X-video)
<wingrime> libv: sad, I have no expiriance in linux video subsystem
libcg has quit [Ping timeout: 240 seconds]
<wingrime> mnemoc: I talking about practice at first
<wingrime> libv: how much radeon roots adreno have?
<mnemoc> all letters :p
<wingrime> mnemoc: ) nice catch, but I mostly about internals
bertrik has quit [Read error: Connection reset by peer]
<mnemoc> Turl: csr for sunxi.org in /srv/http/sunxi/sunxi.org/
pirea has joined #linux-sunxi
sehraf has joined #linux-sunxi
MSameer has quit [Excess Flood]
MSameer has joined #linux-sunxi
<libv> wingrime: command submission is broadly similar
<libv> registers are different though, but rob clark got lucky and got a header file with registers
<wingrime> libv: cedrus project now too lucky, we get autocomplite file ))
<libv> :) lucky :)
seere has joined #linux-sunxi
<libv> wingrime: how do you use this file btw?
seere_ has quit [Ping timeout: 252 seconds]
<wingrime> libv: grep | less
<wingrime> libv: it many bitfields names and some comments , but mixed
<libv> wingrime: so there are no existing tools that can turn this into something closer to c code
<libv> seems not too hard to implement
<wingrime> libv: the problem are - file is sorted by alphabet order
<wingrime> libv: now we know bit field names froms regs but not actual bit position
<libv> right :(
<libv> still, it's a step forwards
<wingrime> libv: now we know almost all registers that cedar have
<mnemoc> Turl: wake up!!!
<mnemoc> wingrime: awesome :D
<wingrime> libv: but vdpau itself not support all codecs we have, and we still feed to us only single frame, but cedar better work when big pice of video buffer are copied to lineral ram
<wingrime> *vdpau give to us only single frame at single time
<mnemoc> can libcedrus get decoupled from vdpau? any other standard that fits cedarx better?
<wingrime> mnemoc: this possible
<wingrime> libv: http://linux-sunxi.org/VE_Register_guide#MACC_VE_ARGB_CMD_QUEUE_START we are thinking about what is it
<mnemoc> an android hal wrapper library for cedrus would be awesome, but decoupling is probably required for that
<wingrime> mnemoc: but, almost for decoder, encoder still have some
<wingrime> mnemoc: only thing is required for decoding - video headers parsing
<wingrime> mnemoc: vdpau provides almost all parsed values
<wingrime> thats defenetly sunxi year
<mnemoc> :D
cubear has quit [Quit: Leaving]
pseudomind has joined #linux-sunxi
pseudomind has quit [Client Quit]
tomboy65 has joined #linux-sunxi
tomboy64 has quit [Ping timeout: 272 seconds]
wingrime has quit [Ping timeout: 276 seconds]
libcg has joined #linux-sunxi
[GuS] has joined #linux-sunxi
<[GuS]> Hi guys/girls!
<[GuS]> I have a question: I've a a10 allwinner tablet, which LCD is broken. So, i am using it to build an Android Box TV. So far is rooted, and has CWM installed. I use HDMI cable with my TV to see the display. The problem is, I dont have HDMI output in Recovery and i need it to flash Cyanogenmod.
<[GuS]> any ideas?
<JohnDoe_71Rus> set script.bin to hdmi main output?
<mnemoc> Turl: ping
leviathanch_ has joined #linux-sunxi
leviathanch has quit [Read error: No route to host]
<[GuS]> JohnDoe_71Rus: sorry for my question, but where is that file?
<[GuS]> JohnDoe_71Rus: mounting boot partition perhaps?
Fusing3 has quit [Ping timeout: 252 seconds]
Fusing3 has joined #linux-sunxi
<[GuS]> JohnDoe_71Rus: ok, found script.bin :)
<[GuS]> JohnDoe_71Rus: which value i should use to set HDMI to main?
<[GuS]> I am editing the .fex file
<[GuS]> I mean, in disp_mode or which one
<[GuS]> mmm i think in screen0_output_type...
orly_owl_ has joined #linux-sunxi
<[GuS]> JohnDoe_71Rus: thanks! worked just fine!
orly_owl has quit [Ping timeout: 264 seconds]
<Turl> mnemoc: busy, be back in ~1h
<mnemoc> >:\
<mnemoc> Turl: cu
cosm has joined #linux-sunxi
<cosm> hi, I have a question about xf86-video-fbturbo
<cosm> I'm not too familiar with X architecture, but as I understand, uncached framebuffer reads are quite rare
<cosm> so, am I correct in understanding that the code in /src/arm_asm.S isn't execute on any hot path?
<cosm> *executed
<ssvb> cosm: yes, but when they happen, then you are really screwed
<cosm> I'm asking because I think there should be room for optimising the existing code, but I'm not sure whether it's worth it
<cosm> ssvb: so when does it execute? is there a benchmark I could run to do some profiling of that code?
<ssvb> cosm: which hardware do you want to optimize it for?
FunkyPenguin has quit [Ping timeout: 255 seconds]
<cosm> ssvb: thanks for the link
<cosm> I'm mainly interested in RK3188 now, although I also use various other platforms
<cosm> all ARMv7
<ssvb> cosm: on Cortex-A9 the VFP code appears to be more efficient for uncached reads, but I would love to see the benchmarks from RK3188 to confirm this
<ssvb> cosm: so far I have only tested it on a single Cortex-A9 based SoC - Samsung Exynos4412
<cosm> alright, I can get back to with some results in a few hours
FunkyPenguin has joined #linux-sunxi
wickwire has joined #linux-sunxi
jemk has quit [Quit: leaving]
tomob has joined #linux-sunxi
pseudomind has joined #linux-sunxi
pirea has quit [Quit: Leaving]
pseudomind has quit [Quit: pseudomind]
Gerwin_J has joined #linux-sunxi
bonbons has quit [Quit: Leaving]
sehraf has quit [Quit: www.miranda-fusion.de ... be part of it...]
physis has quit []
physis has joined #linux-sunxi
FreezingCold has joined #linux-sunxi
tomboy65 has quit [Remote host closed the connection]
tomboy65 has joined #linux-sunxi
tomob has left #linux-sunxi [#linux-sunxi]
orly_owl_ is now known as orly_owl
orly_owl has quit [Changing host]
orly_owl has joined #linux-sunxi
physis has quit [Ping timeout: 252 seconds]
physis has joined #linux-sunxi
libcg has quit [Ping timeout: 264 seconds]
FreezingCold has quit [Ping timeout: 240 seconds]
<cosm> so yeah, VFP is faster on RK3188
Black_Horseman has joined #linux-sunxi
Black_Horseman has quit [Changing host]
Black_Horseman has joined #linux-sunxi
FreezingCold has joined #linux-sunxi