hno changed the topic of #linux-sunxi to: Allwinner/sunxi development discussion - Don't ask to ask. Just ask! - See | | Logs at
auxym has quit [Disconnected by services]
auxym_ is now known as auxym
BJfreeman has quit [Quit: had a good time]
mturquette has quit [Quit: leaving]
egbert has joined #linux-sunxi
egbert_ has quit [Ping timeout: 260 seconds]
<derethor> hi guys.. can you paste a /proc/cpuinfo from an A13? i need to check something, and I dont have the UART cable here now
techn__ has quit [Ping timeout: 264 seconds]
_BJFreeman has joined #linux-sunxi
_BJFreeman is now known as BJfreeman
<Turl> derethor: I have an A10 and an A10S handy, are they any use?
<Turl> A10S is sun5i like A13
MadSpark has quit [Ping timeout: 264 seconds]
<Turl> derethor: well can't hurt I guess,
<Turl> night
TheSeven has quit [Disconnected by services]
[7] has joined #linux-sunxi
naobsd has joined #linux-sunxi
naobsd has quit [Ping timeout: 250 seconds]
BJfreeman has quit [Ping timeout: 252 seconds]
\\Mr_C\\ has quit []
\\Mr_C\\ has joined #linux-sunxi
naobsd has joined #linux-sunxi
<naobsd> hmm, script.bin in new Android image for CB2 has many difference from previous image...
<ssvb> oliv3r: ping
<ssvb> I wonder why the firmware in nand provides better memory performance (~2GB/s memset) -
<ssvb> in both cases the CPU is clocked at 1GHz
<ssvb> hno: ^
<ssvb> do we have the exact sources of u-boot, which is preinstalled in NAND of CubieBoard2?
rz2k has joined #linux-sunxi
jemk has joined #linux-sunxi
Superpelican has joined #linux-sunxi
rz2k has quit []
paulk-desktop has joined #linux-sunxi
Superpelican has quit [Ping timeout: 264 seconds]
heffer_ is now known as heffer
eebrah|away is now known as eebrah
Superpelican has joined #linux-sunxi
<oliv3r> bbl
<oliv3r> ssvb: in an hour or so
oliv3r has quit [Quit: leaving]
_BJFreeman has joined #linux-sunxi
_BJFreeman is now known as BJfreeman
_BJFreeman has joined #linux-sunxi
BJfreeman is now known as Guest22985
_BJFreeman is now known as BJfreeman
Guest22985 has quit [Ping timeout: 252 seconds]
oliv3r has joined #linux-sunxi
Superpelican has quit [Quit: Konversation terminated!]
Superpelican has joined #linux-sunxi
jemk has quit [Ping timeout: 248 seconds]
e-ndy has quit [Remote host closed the connection]
ibrah has quit [Read error: Connection reset by peer]
ibrah2 has joined #linux-sunxi
rellla has joined #linux-sunxi
jemk has joined #linux-sunxi
BJfreeman has quit [Quit: had a good time]
Soru has quit [Read error: Operation timed out]
Soru has joined #linux-sunxi
jemk has quit [Remote host closed the connection]
Superpelican has quit [Ping timeout: 276 seconds]
jemk has joined #linux-sunxi
vincenzo has quit [Quit: Konversation terminated!]
vincenzo has joined #linux-sunxi
cajg has quit [Ping timeout: 240 seconds]
heffer has quit [Ping timeout: 260 seconds]
[hawk] has joined #linux-sunxi
rellla has quit [Remote host closed the connection]
vincenzo has quit [Ping timeout: 248 seconds]
[hawk] has quit [Ping timeout: 260 seconds]
[hawk] has joined #linux-sunxi
cajg has joined #linux-sunxi
techn_ has joined #linux-sunxi
Superpelican has joined #linux-sunxi
Superpelican has quit [Read error: Operation timed out]
Undertasker has joined #linux-sunxi
Undertasker has left #linux-sunxi [#linux-sunxi]
ibrah2 has quit [Read error: Connection reset by peer]
auxym has left #linux-sunxi [#linux-sunxi]
francis__ has joined #linux-sunxi
francis__ has quit [Client Quit]
auxym has joined #linux-sunxi
<oliv3r> ssvb: pong
<ssvb> oliv3r: well, I have just sent some info to the mailing list
<oliv3r> ssvb: i see; did you try my branch?
<oliv3r> i have some additional fixes in my branch
<ssvb> you tried to do some DRAMC refactoring, so I thought you know some information about this stuff
<ssvb> ok, if it contains some functional changes, then it is surely worth testing
<oliv3r> luke ported some initial things over, but not everything
<oliv3r> i took his stuff, compared it to the allwinner code and added the missing pieces
<ssvb> hmm, where is the original allwinner code?
<oliv3r> that's the 'add missing pieces' patch
<oliv3r> note, this is boot0, not u-boot-spl
<oliv3r> but if you look at my commits, you see some things are clearly different
<oliv3r> unfortunatly, some of those don't have meaning (lack of docs)
<ssvb> thanks, so there are multiple implementations of DRAMC init code
<ssvb> I wonder which one is used by the CubieBoard2 firmware, because it seems to provide better performance
<oliv3r> i have sent hno my patches, he hasn't reviewd and added them yet :)
<oliv3r> also, the ccr register you mention, isn't touched in my patch
<oliv3r> (in the one i linked)
<oliv3r> bit5 is causing you a speed difference (among others) so lets see what boot0 does with that
<oliv3r> hmm, i'm pretty sure i added that
<oliv3r> but it's for 2T or 1T mode
<oliv3r> ohh, i write it to the wrong register in my patch
<oliv3r> i thik
<oliv3r> i'll have to investiage
<oliv3r> yeah i think you found a bug on my end :)
<ssvb> good :)
<oliv3r> i'll fix it later tonight
<ssvb> thanks for your comments, I'll try to run some more tests later, but now it's my turn to leave for ~1 hour
<oliv3r> tpr4 is used for 2 things
<oliv3r> 2T or 1T mode
<oliv3r> and for secret stuffs :)
<oliv3r> bah, it was only a really small thing I've overlooked
<oliv3r> nothing major :(
jemk has quit [Ping timeout: 256 seconds]
<oliv3r> that said, if the memory + controller support it, we can run 1T mode (I think that's better then 2Ton a10 too)
<oliv3r> ssvb: pull from my tree now (i push --frorced) and test your performance if you don't mind
\\Mr_C\\ has quit []
paulk-desktop has quit [Quit: Ex-Chat]
\\Mr_C\\ has joined #linux-sunxi
Superpelican has joined #linux-sunxi
auxym has quit [Quit: Lost terminal]
wingrime has joined #linux-sunxi
Superpelican has quit [Remote host closed the connection]
Superpelican has joined #linux-sunxi
Soru has quit [Ping timeout: 256 seconds]
Soru has joined #linux-sunxi
derethor has quit [Read error: Connection reset by peer]
derethor has joined #linux-sunxi
Soru has quit [Ping timeout: 268 seconds]
soul has joined #linux-sunxi
jukivil1 is now known as jukivili
soul has quit [Ping timeout: 246 seconds]
jemk has joined #linux-sunxi
Soru has joined #linux-sunxi
eebrah is now known as ibrah
ibrah is now known as eebrah
paulk-desktop has joined #linux-sunxi
<Black_Horseman> Hello
<ssvb> oliv3r: the memory is still slow with your branch :(
<oliv3r> ssvb: then we need to compare all memory registers, could you get me cubie1 and cubie2 dram-controller dumps?
<oliv3r> so we can compare?
<ssvb> oliv3r: I don't have cubie1, only mele a2000 with 512MB RAM
<oliv3r> same difference :p
<oliv3r> but yeah, i ment to say a10 vs a20 really
<oliv3r> actually, i have both so i'll do boot0/1 boots on both and compare
<ssvb> I guess it makes sense to configure cubie2 as only 512MB?
<oliv3r> c1 and c2 are identical, except for CPU, so that's best for comparing
<oliv3r> i guess i need instructions for your memory benches :) wiki wiki?
<oliv3r> dont' know if i have time for all that today; got a terrible headache and need to sort some private stuff before july 1st
<ssvb> oliv3r: or alternatively a simple memset benchmark is very easy to implement in just a few lines of code
<ssvb> oliv3r: if the buffer is large (at least bigger than a few megabytes), then you should get ~1.6GB/s speed with the current u-boot and ~2GB/s with the cubie firmware
<jemk> ssvb: take a look at mbus clock (ccm reg 0x15c). they are different too, and if it realy means something like memory bus there could be a reason
ibrah has joined #linux-sunxi
<jemk> and the relation 300mhz at nand and 240mhz at uboot matches the 2gb/s to 1.6gb/s
rz2k has joined #linux-sunxi
<oliv3r> i merged all settings from boot0, so it should be identical
<ssvb> jemk: that's a good point
<Turl> I wonder what's A31 mem perf like :)
<Turl> jemk: is there any document with a20 clocks?
<jemk> Turl: dont know, i used wiki and comments from boot0 source
<Turl> I guess I'll have to live with headers then :)
\\Mr_C\\ has quit []
<Turl> seems pretty register-compatible with sun4i from a really quick look, they added the new ones on the bottom
ibrah has quit [Read error: Connection reset by peer]
<Turl> oliv3r: did you complete wiki with A20 clocks?
<oliv3r> Turl: nope
<oliv3r> no docs no wiki :p i could have used the ccmu.h
<ssvb> Turl: yeah, thanks for the link
<oliv3r> anyway, we know the mbus regs
<oliv3r> it's on the wiki
<Turl> oliv3r: k np :)
<ssvb> good, I'm just new to this stuff :)
<Turl> oliv3r: is it also used on A10?
<oliv3r> Turl: yes
<oliv3r> the a13 doc mentions it
<Turl> I don't recall seeing it on the A10 ccmu
<oliv3r> mbus = memory bus
<Turl> wonder if... :)
<oliv3r> it's quite important i think
<jemk> 0x15c doesnt exist on a10, i already tried
<Turl> let me see on my A10s
<oliv3r> mbus 2, 0x160 is for dual channel
<oliv3r> i don't belive a13 has mbus, but a10 does not
<Turl> (which has crappy perf compared to the A10)
<ssvb> is it a good idea to try to match axi clock speed with mbus?
<ssvb> if everything runs at asunchronous clocks, then the performance probably might be not too great
<Turl> # devmem 0x01c2015c 32
<Turl> 0x82000001
<oliv3r> what does 0x160 say
<Turl> 0
<Turl> I wrote 0x82000000 to it and my board still works..
<oliv3r> makes sense, single channel only :p
<oliv3r> i'll hook up c1 and c2 tomorrow :p
<jemk> A10: 01c2015c: 00000000 00000000 ........
<Turl> ah nvm i was reading it wrong
<oliv3r> which is even from sun4i and sun5i
ibrah has joined #linux-sunxi
<oliv3r> i do have to double check the defines, as i think i've put up pll5
<ssvb> jemk: yes, that was it, now I get 2GB/s with u-boot
<oliv3r> so you fixed it ssvb?
<jemk> :( sad, then my a10 cant get more speed this way.
<oliv3r> ssvb: you changed SRC_PLL5 to SRC_PLL6 in that line i pasted ^
<ssvb> oliv3r: just as jemk noticed, the current u-boot has it as "(0x1 << 31) | (0x2 << 24) | (0x1)", I changed it to "(0x1U<<31) | (0x1<<24) | (0x1<<0) | (0x1<<16)" from boot0
<Turl> well it does exist
<Turl> I did devmem 0x01c2015c 32 0x80000000
<oliv3r> ok but my branch has 0x1 << 24
<ssvb> oliv3r: your cleanup branch probably needs an ifdef for sun7i there
<oliv3r> (bit 24 is pll)
<Turl> and now my perf is crap :D
<Turl> 58MB/s C fill
<oliv3r> of course it exists, it has to
\\Mr_C\\ has joined #linux-sunxi
<ssvb> Turl: :)
<Turl> oliv3r: this is an A10S
<oliv3r> oh yeah
<oliv3r> but still a10 has to have it too
<Turl> let me check in my mele
<jemk> but at least not at 0x15c, writing there doesnt change anything, readback 0
<oliv3r> ssvb: i lie, I have 2 << 24; e.g. pll5
<Turl> ah, I don't have any cool tool to poke memory on it
<oliv3r> i'll check the lichee source
<Turl> oliv3r: PLL5 is the dram pll
<Turl> so they're kinda synced if you do that
<oliv3r> well appearantly, a20 likes pll6 *2
<oliv3r> ssvb: ifdef-ed it and pushed it
<Turl> pll6 is sata :P
<oliv3r> performance numbers don't lie!
<ssvb> oliv3r: have you verified the performance?
<oliv3r> mbus might be fixed in stone on a10
eebrah is now known as eebrah|away
<oliv3r> ssvb cubies are tucked away :(
<oliv3r> i think a10's mbus simple is hardcoded and not exposed
<oliv3r> something they changed in sun5i
<jemk> downclocking a10 to 816mhz instead of 1008mhz gives almost 200mb/s extra memset perf
<jemk> then axi is divided by 2 instead of 3, so its much faster
<jemk> do we have any official upper limit for axi clock?
<ssvb> I think there are comments about 450MHz in the sources
<jemk> 1008/2>450 :(
<ssvb> well, but that's not too much higher
<ssvb> dram is already overclocked in cubie 400 -> 480
<Turl> devmem 0x01c20120 32 0x80004900
<Turl> devmem 0x01c2015c 32 0x81000000
<Turl> hangs the board :(
Superpelican has quit [Ping timeout: 252 seconds]
auxym has joined #linux-sunxi
<auxym> is it possible to chroot from opensuse into a debian-armhf rootfs with qemu
<auxym> ?
<Turl> auxym: yes
<auxym> opensuse doenst appear to have static qemu though. im getting /bin/bash not found right now. ill keep digging around i guess
<Turl> on debian there's a package with static qemu which also sets up the binfmt part
<auxym> yeah... thats the problem. im running opensuse so i cant get that debian package
<Turl> you could download it, unpack it and use the binaries though
<Turl> they're static after all :)
<Turl> ssvb, oliv3r feeding A10S off "PLL6*2" doesn't seem to work, even when PLL6 is on bypass mode (which should be like feeding off osc24M, which works)
<auxym> good idea, ill look into that
ibrah has quit [Ping timeout: 260 seconds]
paulk-desktop has quit [Quit: Ex-Chat]
ibrah has joined #linux-sunxi
ibrah has quit [Client Quit]
ibrah has joined #linux-sunxi
eebrah|away is now known as eebrah
winocm has joined #linux-sunxi
<Black_Horseman> Hello
<Black_Horseman> is there any "how to" showing how i can add on cubie an on/off switch????? and how i can power up cubie with usb hub and hdd????
<Black_Horseman> with one power supply and cable?
<Black_Horseman> thank you for your time, in advance
<hramrach__> there is no easy way to add another power switch, sadly
<hramrach__> what hdd do you want to power?
<hramrach__> a SSD would run fine off Cubie with the provided SATA cable and decent power supply
<hramrach__> for rotating HDD you better get a beefy power supply that gives like 5V/3A and connect both HDD and cubie to the PSU with some split cable or connect the hub the the PUS and power both cubie and HDD off hub
derethor has quit [Read error: Connection reset by peer]
derethor has joined #linux-sunxi
<jelly-home> s/would/does/ for me
<jelly-home> tried an old 2.5" 5400 hdd and it worked as well
<hramrach__> some disks can spin up wihtout requiring horrendous amount of power and som just can't
<hramrach__> after all, they were desgned for notebooks which can give more than 1.5A power to them. It just drains the battery.
<hramrach__> then you connect them to USB port and they won't spin up
<hramrach__> well, SSDs don't spin up so it would be odd if they did not work
Superpelican has joined #linux-sunxi
eebrah is now known as eebrah|away
<Black_Horseman> bsck
Superpelican has quit [Read error: Connection reset by peer]
<Black_Horseman> hramrach__ at the shop that sells cubie told me that 5V/2.1A will be adecuate for a 2.5" hdd an keyboard and mouse
<hramrach__> it depends on the HDD and the quality of the PSU
<Black_Horseman> but i want also to power up a usb hub for gamepad or joystics
<hramrach__> if you already have the PSU you can just try how it works
<Black_Horseman> well i do not have the parts yet
<Black_Horseman> i am waiting to be paid my salary first
rz2k has quit []
<hramrach__> I ordered some power brick from DX but it did not come so I bought a 35W PSU at a local store instead and it works well
rz2k has joined #linux-sunxi
<libv> hivemind...
<hramrach__> 35W is a bit overkill for a single board but I want to power pretty much anything 5V for what I can find an USB cable off it
<libv> any ideas on what the lima driver should use to detect that it is running on sunxi?
<rz2k> dmesg | grep chip-id
<hramrach__> cpuinfo has arch too
<libv> hrm, smells a bit funky to do that from a C library
<hramrach__> /proc/cpuinfo
<libv> at runtime
<rz2k> you somehow want to grab this
<libv> ah, not which specific chip
<libv> but just that this is sunxi and not for instance exynos or another platform
<hramrach__> cpuinfo should be good enough
<libv> the existence of "/dev/disp" seems a bit... ...awkward...
<rz2k> yes then cpuinfo
paulk-desktop has joined #linux-sunxi
<hramrach__> there should be better place than that but don't think Linux grew something for hw identification
<hramrach__> you get
<hramrach__> Hardware: sun4i
<hramrach__> in /proc/cpuinfo
rellla has joined #linux-sunxi
rellla has quit [Remote host closed the connection]
<Turl> libv: proving for /dev/disp should be enough I'd say
<Turl> b*
<Turl> (that's why you want to know if it's sunxi or something else right?)
<libv> it's the difference between trying to use ump and mapping the fb directly
<Turl> old(ish) exynos used ump too from what I know
<Turl> mixed with fimc and other stuff
<Turl> in any case, you can abstract the check and expand it later on if e.g. /dev/disp disappears
wingrime has quit [Ping timeout: 252 seconds]
<oliv3r> libv: if you want to probe from userspace, i don't think you can yet (reliably) we have some soc-detect stuff in amery's branches, but haven't exported that to userspace. with mainline you can ask the device-tree
<oliv3r> with 3.4 .. tehre's ways, but i think your limited to /proc/cpuinfo from userspace; unless you don't mind probing registers :) then the sramc reg is pretty clear
<oliv3r> Turl: seems to confirm, that sun4i has mbus hardcoded and not modifyable, and only sun5i exported those settings
rz2k has quit [Ping timeout: 264 seconds]
<oliv3r> what I don't understand, is that our current u-boot-spl, sets the mbus registers for both; when really, for sun4i it shouldn't touch them.
Soru has quit [Ping timeout: 264 seconds]
soul has joined #linux-sunxi
Soru_ has joined #linux-sunxi
soul has quit [Ping timeout: 252 seconds]
<Turl> oliv3r: it's all 0, maybe gets lost on the bus?
gzamboni has joined #linux-sunxi
<ssvb> oliv3r: what can be done about this? to be honest, these dram initialization antics are yet another unpleasant surprise for me :)
<Turl> oliv3r: the sun5i one seems pretty worthless, PLL6*2 does not seem to work at all
<Turl> at least during my trials today, it always hanged the board, even if pll6 was super slow
<Turl> switching to osc24 worked fine, but why would you want to do that? :P
Soru_ has quit [Read error: Operation timed out]
<Turl> ssvb: have you tested sunxifb on A20?
<ssvb> Turl: yes, there should not be any problem with it
<ssvb> right now it fails the disp version check and refuses to use any sunxi features
<Turl> ssvb: how does it perform compared to A10?
<Turl> ah
<Turl> did AW rework disp much?
<ssvb> at least G2D seems to be exactly the same as in A10
<ssvb> which unfortunately means that there is still no premultiplied alpha support :(
Soru has joined #linux-sunxi
<ssvb> I had some hopes for it, because I mistakenly looked into sun6i sources and assumed that sun7i should have the same upgrade for G2D
<oliv3r> ssvb: what do you mean exactly
<ssvb> Turl: the version check ioctl is an extra linux-sunxi feature, it does not mean that the disp hardware is different
<ssvb> Turl: it's just that we are a bit too paranoid and don't want to use unknown disp stuff without checking it first
<ssvb> Turl: I believe that we should not have any problems with disp
<ssvb> oliv3r: about what?
Soru__ has joined #linux-sunxi
<oliv3r> 21:49 < ssvb> oliv3r: what can be done about this? to be honest, these dram initialization antics are yet another unpleasant surprise for me :)
<ssvb> oliv3r: nevermind, it's more like the case of "you don't want to know what happens at the sausage factory" :)
<ssvb> now I know a little bit more, and it makes me sad
Soru has quit [Ping timeout: 276 seconds]
<oliv3r> ssvb: ah, yeah
<oliv3r> well that's only for a10
<oliv3r> and imo, a10 is kinda obsolete
<oliv3r> sure we can't beef up performance more
<oliv3r> but our efforts should be focused on a20 for now
<oliv3r> and any performance gain we can get for a10, is nice to have
derethor has quit [Quit: Leaving]
derethor has joined #linux-sunxi
<derethor> hi
<derethor> did you read my last line?
<derethor> dont know what happen here with xchat
<hramrach__> the m-h repo is obsolete and bitrotten
<hramrach__> it does not even checko out
<oliv3r> matson hall still publishes random stuff to his github in random repo's
<oliv3r> a shame really that his efforts aren't focued more here
<derethor> i am building it
<derethor> what is that exactly?
<derethor> i see it is a fork from allwinnerbuildroot
<derethor> it is a different buildroot than the ?
<hramrach__> it's probably part of the larger repo which is broken
<hramrach__> it was modified to work on sunxi presumably which is why it is forked
<derethor> ok, it generates an img
<derethor> why is broken?
<hramrach__> it refers to some sub-repos that no longer exist
<derethor> ah, ok
<derethor> so, what is the best way to build an image for the allwinner?
<hramrach__> this is the main repo
<hramrach__> derethor: what kind of image?
<hramrach__> and what kind of allwinner device?
<derethor> like an embebbed device, on a13 olinuxino
<hramrach__> and what kind of image?
<derethor> something like the , a simple sdcard with some commands
<hramrach__> android sd card? or linux? or?
<derethor> linux, like a simple router
<hramrach__> there are quite good quides for that on
<derethor> i see, the allwinner-buildroot is an independent code, it took some ideas from buiildroot, but it is not a fork
<hramrach__> building Android SD cards does not work that well but Linux should be ok
jemk has quit [Remote host closed the connection]
<Turl> derethor: you can use buildroot (the official one) to make your rootfs and then use it to make a sdcard with uboot and a kernel
<derethor> i will try, never tried buildroot before
<derethor> the architecture, is arm little endian, right?
<derethor> for the cortex a8
auxym has quit [Quit: Lost terminal]
paulk-desktop has quit [Ping timeout: 252 seconds]
rz2k has joined #linux-sunxi
derethor has quit [Read error: Connection reset by peer]
rz2k has quit [Read error: Connection reset by peer]
Soru__ has quit [Ping timeout: 256 seconds]
<libv> oliv3r: cpuinfo also seems a bit too much hassle
<libv> although... open, mmap, and a strchr...
* libv fires up the odroid to see what it states at cpuinfo
<libv> it is amazing how incredibly backwards all these things are in the arm world
<libv> arm has lived in a cage for its whole life
<oliv3r> well, is there a common way to expose this info normally?
<libv> display stuff is at least 10 years behind
<oliv3r> as said, with mainline, you have device-tree
<libv> no standardization, no pciids or dmi
<oliv3r> but if you need something exposed to userspace, i'm sure we can think of some way to expose this stuff
<libv> it would need to be pretty generic
<oliv3r> i bet there isn't something yet though :)
<oliv3r> well it would be only for 3.4 kernels
<libv> devicetree might hold the answer, yes
<libv> hah
<libv> Hardware: ODROIDX2
<libv> great
<libv> which f-ing SoC is this then!!!
<libv> everyone will have just random strings...
<libv> at least "sun%di" makes some sense
<oliv3r> well we can hack something into 3.4; add something to cpuinfo
<oliv3r> like the serial number
<oliv3r> 'sun4i'+some serial number from sid if available
<libv> again, i need to be able to see which family of SoCs i am running on
<libv> for now, cpuinfo for sunxi is useful
<oliv3r> well we'd embedd 1625 into the serial number
<oliv3r> serial number currently is 0
<oliv3r> or 'revision' 1624
<oliv3r> would that work?
<libv> and everything else is going to be exynos
<oliv3r> also 0 atmm
<libv> oliv3r: it needs to work across _all_ SoCs containing a mali
<oliv3r> well i don' tthink there is that :)
<oliv3r> so i can only help you identify sun*i :)
<libv> that will be some really nast slow shit
<oliv3r> reading rev. from cpuinfo?
<libv> oliv3r: i do not even need a rev
<oliv3r> well we can put '1625' for sun4i into the rev
<libv> i need to know some limited things like, which /dev/fb%d should i use, how should i map fb
<libv> for that it suffices that i know that this is a sun[457]i
<libv> everything else will then be exynos...
<libv> until the next soc comes by...
<libv> and then the mess starts
<oliv3r> probe devicetree, if not available, check /proc/cpuinfo
<oliv3r> i guess that's all we have
<libv> i was the first to add pci subsystem ids to linux graphics drivers btw
<oliv3r> :D
<libv> and i added that to flashrom as well
<libv> so i know the pain of maintaining such info
<libv> even across a few well known but often shabbily implemented bits of standard infrastructure
<oliv3r> well mali is connected to the ahb bus isn't it?
<oliv3r> so for arm, you'd have lsahb :)
<libv> linaro 13.04 doesn't know it
<libv> so no, not an option
<libv> anyway... i am going to implement this now in as sensible a way as i currently can muster, and wait and see what happens with the future
<libv> but i smell a big pile of steaming crap ahead
<oliv3r> well i'm gonna send a patch for 3.4/3.0 that puts the soc ID into revision id; it kinda makes sense :)
<libv> oliv3r: i will not end up using that
<oliv3r> yeah, but i guess its' still good to have
<libv> "Hardware: sun%di" will do
<oliv3r> and probably use that string to change the name from sunxi to sun[4567]i
<oliv3r> if we don't allready have that
<libv> oliv3r: it reads sun4i on my mele
<libv> oliv3r: abusing Rev: for something else also seems wrong
<oliv3r> how is it abusing
<oliv3r> revision 16250; 16251 for sun4iA, sun4iB
<libv> well, first off, is this Hardware: supposed to be SoC or board?
<oliv3r> well it says 'cpuinfo' so should be purly about the soc?
<libv> but an SoC is not a cpu
<libv> and many more than just hardkernel will be abusing this free string as well
<oliv3r> point taken; what do other socs have there?
<oliv3r> because as said, it's all 0 now
<libv> now if you are just stating revision, you would have to write either 0,1 or 0xa,0xb or 0x61, 0x6b
<oliv3r> the sunxi socs revision data is kinda .. mysterious
<libv> 1625x is more like an Allwinner model number, not a revision
<oliv3r> yeah true
<libv> so it smells wrong from a lot of angles
<oliv3r> well serial number then; the current serial numbers are allready model number + some unique fluff
<libv> but then the whole arm and autodetection stuff is a cesspit anyway
<libv> oliv3r: so the serial number which is written onto the top of the chip?
<oliv3r> the serial number that's programmed into the chip via fuses
<libv> oliv3r: which you cannot read unless you open up your device and ...
<libv> ok
<libv> ok
<libv> cpuinfo serial might be 64bits only
<oliv3r> it is
<oliv3r> we can't store the whole thing
<libv> and only few vendors actually burn it
<oliv3r> i would think, put model number in the high 64 bits, and the bit that looks the most like a serial in the lower half
<oliv3r> it's supposed to come like that from the AW factory
<oliv3r> but somehow AW sells 'unmarked' chips
<libv> it seems like something that will not help anyone
<libv> "Hardware: sun%di" is enough for lima
<libv> and i think few other userspace programs need to know more detail
<oliv3r> what does the hardware: say right now? sunxi or sun4i
<libv> the latter
<oliv3r> ok
servili007 has joined #linux-sunxi
<oliv3r> my guess, is that's it's a compile time thing atm
<oliv3r> e.g. fixed string
<oliv3r> not an issue for you right now :)
<libv> all i need to know is hot to properly access fb
<oliv3r> but a unified kernel will have issues with that :)
<libv> s/hot/how/
<libv> unified kernel can only happen with dt i guess
<libv> man... it's going to be a really smell mess.
<oliv3r> actually, we are quite far
<libv> ah, for sunxi?
<libv> i do not care beyond sunxi tbh
<oliv3r> yeah for sunxi of course
<oliv3r> other socs, mainline yeah
<servili007> hey guys, I've been making my own debian debootstrapped builds. Trying to switch to linaro now, but once x starts, I just get a blinking cursor. Is it attaching to the wrong display? building 3.4 kernels with mostly stock sun4i config, same result on 3.0 iirc and across 3 different sun4i devices
<libv> so playing with cpuinfo for sunxi seems both awkward and not really useful atm
<libv> servili007: have you read /var/log/Xorg.0.log ?
<libv> servili007: have you followed the binary drivers guide properly?
<oliv3r> libv: i guess there isn't much that can be done really until mainline comes with dt
jlj has joined #linux-sunxi
<servili007> libv: if it's the same issue I had when I tried this in the past, logs will come up with screen not found. I'll verify shortly. I'm using the BSP running through updated submodules and my edits. It should be building everything properly. Debian sure seems to think so anyway
<libv> oliv3r: and until that kernel has become ubiquitous
<libv> servili007: work through binary drivers
<libv> servili007: that is older than the bsp, iirc
<servili007> libv:I thought bsp builds them for you at hwpack install?
<libv> err
<libv> more recent
<servili007> okay
<jlj> is there a way to make a hwpack with the 3.4 kernel when using sunxi-bsp builder?
<servili007> jlj: yeah, you checkout 3.4
<jlj> servili007: do you know the syntax? like "make kernel34" or such?
<servili007> enter the linux-sunxi folder and do a git checkout origin/sunxi-3.4
<jlj> ah okay
<jlj> and then just run make again?
<servili007> yep
<jlj> okay, thanks!
<servili007> I'd clean up first
<servili007> switch over
<servili007> then reconfigure/rebuild
<jlj> ok
<jlj> by the way do you know a rootfs that has a ssh server running by default?
<jlj> seems like it's turned off in linaro
<libv> jlj: it is disabled in all basic debians
<jlj> libv: I kinda thought so :|. well ok
<libv> but i do not know an answer to that question myself
naobsd has quit [Quit: Page closed]
<libv> i was lucky enough to always haev serial so far
<servili007> I jumped for a cubieboard right when the a20 came out. Wanted to kick myself but I love sun4i lol
<servili007> and not having to solder my own serial etc is nice
<servili007> of course, I wouldn't love the a10 at all without the linux sunxi project :P
<Turl> newer kernels have the SoC bus to expose all this info
<oliv3r> Turl: lsbus?
<Turl> no, something on /sys you can cat though
<Turl> oliv3r: I linked you to a patch to add it some time ago
<Turl> libv: can't you just feature probe? if(file_exists(/dev/ump)) use_ump() else alloc_fb()
<libv> Turl: ump is always loaded when disp is loaded
<Turl> libv: so?
<Turl> libv: dont you want to use ump when available and fb when not?
<Turl> this whole 'detect the SoC' convo reminds me of UA sniffing on the web
<Turl> that's why I'm suggesting feature detection :)
<oliv3r> 2011; what version is that available on :)
<libv> Turl: mapping the whole framebuffer gives me the ability to somewhat pageflip
<oliv3r> we can always backport it to our 3.0 and 3.4 kernels
<libv> Turl: and... exynos also has ump
<libv> Turl: so no, checking for /dev/ump in itself is not a sensible thing
<Turl> libv: why do you want to use sth else for exynos then?
<libv> anyway, the logic itself is pretty clear
<libv> Turl: because mapping the fb on exynos is a sure fire way to not get anything displayed on the fb
<libv> ah, right
<libv> the fb hw address is 0x00000000
<libv> but i need to know more than just that
<libv> i need to map /dev/fb6 on exynos4 to talk to hdmi
<Turl> 6 fb? o.O
<libv> it's a mess.
<oliv3r> :(
<libv> samsung needs some proper open source devs
<oliv3r> they are actually hiring
<oliv3r> but you have to move to south korea
<Turl> yeah, I hear people bitching about the insignal crap frequently :P
<Turl> what's worse is that samsung themselves don't use it
<Turl> or at least not as is
<libv> oliv3r: i am quite well aware that samsung is hiring
<libv> have been so for 6m now
<oliv3r> Suwon, South Korea
<libv> but i refuse to move
<oliv3r> hehe
<oliv3r> i imagine
<libv> i would be moving every 2 years
<oliv3r> moving to s. korea is pretty big
<libv> for _no_ reason
<libv> i already moved for SuSE
<libv> and i got not even 23 months out of that one
<libv> despite bringing them a pile of AMD cash
<libv> then i was at nokia for a bit...
<libv> and we all know how that went
<Turl> :P
<libv> so no, no matter how big the company, i do not move anymore.
<oliv3r> i don't blame you
<oliv3r> :)
<oliv3r> but yeah not only is it far away
<oliv3r> s. korea, language etc
<oliv3r> family far away
<libv> they better accept me working from home and travelling 25% of the time, or they are getting to keep the sort of idiots who messed up exynos4 fb support
<oliv3r> partner who might not want to
<oliv3r> libv apply with that notion ;)
<libv> my gf will follow me wherever i move to, but i do not want to put her through that
<libv> i do not want to put myself through that either
<libv> life here in nue is good, loads of fun linux geeks around
<libv> moving is just pointless
<libv> for open source work, you should be used to working from home, provided that you do not become too lonely and demotivated at said home
<oliv3r> will you ever move back to .be?
<libv> and travelling once every X weeks for teammeetings is actually fun
<libv> because that ends up being a whole week of just the team and nothing else
<libv> if the right balance is found, it is a fantastic way of working
<libv> (meego graphics adaptation team was great for that, other teams inside meego were not as good)
<oliv3r> well flying to s. korea a few times a year from .de can be quite pricey
<libv> oliv3r: not very likely
<libv> oliv3r: does not need to always be korea
<oliv3r> well in samsungs case :p
<libv> and the "not very likely" is me moving back to belgium
<libv> belgium is a flat and wet place
<oliv3r> lol
<libv> with few linux geeks
<oliv3r> what about left behind friends+family
<libv> i visit family a few times per year, and family tends to visit here quite often
<oliv3r> oh 3.10 is out
<oliv3r> bed time though
<oliv3r> nn :)
<libv> few friends remain after 6 years, people move on
* Turl git syncs
<libv> anyway, think thoroughly before accepting a job that requires that you relocate
<libv> or one that requires that you are nda-ed up from here to eternity and that you will end up not being able to do any proper open source work anymore in future
<libv> these days you are lucky if you have a big company pay you for more than 2 years
<libv> and if you relocated or signed away your work and an external future... then that's it.