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
FDCX has quit [Read error: Connection reset by peer]
pfdm has quit [Quit: Page closed]
stekern has quit [Ping timeout: 264 seconds]
stekern has joined #linux-sunxi
lkcl has quit [Ping timeout: 246 seconds]
hramrach has quit [Ping timeout: 240 seconds]
FDCX has joined #linux-sunxi
lkcl has joined #linux-sunxi
stekern has quit [Ping timeout: 272 seconds]
hramrach has joined #linux-sunxi
stekern has joined #linux-sunxi
speakman_ has joined #linux-sunxi
speakman_ has joined #linux-sunxi
speakman_ has quit [Changing host]
cajg_ has joined #linux-sunxi
keebler_ has joined #linux-sunxi
aesok has quit [Remote host closed the connection]
diego71_ has joined #linux-sunxi
morfoh_ has joined #linux-sunxi
honx has quit [Ping timeout: 250 seconds]
xeros has quit [Quit: xeros]
keebler has quit [Ping timeout: 250 seconds]
eagles0513875 has quit [Ping timeout: 250 seconds]
cajg has quit [Ping timeout: 250 seconds]
morfoh has quit [Ping timeout: 250 seconds]
speakman has quit [Ping timeout: 250 seconds]
diego71 has quit [Remote host closed the connection]
<Gerwin_J> okay...
wingrime has joined #linux-sunxi
honx has joined #linux-sunxi
eagles0513875 has joined #linux-sunxi
_BJFreeman has joined #linux-sunxi
_BJFreeman is now known as BJfreeman
xeros has joined #linux-sunxi
stekern has quit [Ping timeout: 246 seconds]
BJfreeman has quit [Quit: had a good time]
wingrime has quit [Ping timeout: 272 seconds]
stekern has joined #linux-sunxi
deasy has quit [Quit: Nom d'un quark, c'est Edmonton !]
oliv3r has quit [Ping timeout: 252 seconds]
oliv3r has joined #linux-sunxi
cajg_ is now known as cajg
popolon has quit [Quit: Quitte]
egbert has quit [Disconnected by services]
egbert has joined #linux-sunxi
FDCX has quit [Read error: Operation timed out]
FDCX has joined #linux-sunxi
eebrah has quit [Quit: Lost terminal]
<KBme> so now we will not be able to pull request, fork, see where forks are, and the cloning of the linux repo will be hella slow
<KBme> hurray
<KBme> also, no web interface
<KBme> no bug tracker
<KBme> no wiki
<KBme> that's progress for ya
egbert has quit [Ping timeout: 248 seconds]
egbert has joined #linux-sunxi
<KBme> not that i particularly like github
woprr has quit [Ping timeout: 260 seconds]
<wens> mnemoc will get cgit up for the web interface
woprr has joined #linux-sunxi
Gerwin_J has quit [Quit: Gerwin_J]
<libv> KBme: :)
<KBme> I hope he sets up something like gitlab, rather
<KBme> that would be actually useful
<KBme> instead of cgit, an interface that gives no more than I can get on the git commandline
navym has quit [Quit: ChatZilla [Firefox 25.0.1/20131112160018]]
ZetaNeta has quit [Ping timeout: 272 seconds]
TheSeven has quit [Read error: Operation timed out]
TheSeven has joined #linux-sunxi
wingrime has joined #linux-sunxi
<KBme> Turl, gcc 4.6 doesn't support cortex-a7
<KBme> god, this sucks
JohnDoe_71Rus has joined #linux-sunxi
<KBme> well, managed to compile linaro toolchain
<KBme> or at least gcc
Sonic1 has quit [Ping timeout: 248 seconds]
<WarheadsSE> it doesn't? hmm .. wonder how we built entire distributions with it...
<KBme> WarheadsSE, how did you really?
<KBme> well, doesn't sopport -march or mtune cortex-a7, i'm sure you can go more generic
<KBme> anyways, linaro gcc 4.6 does support it
<KBme> they backported it
Sonic1 has joined #linux-sunxi
tzafrir has joined #linux-sunxi
KBme has quit [Ping timeout: 252 seconds]
Black_Horseman has quit [Ping timeout: 246 seconds]
n01 has joined #linux-sunxi
n01 has quit [Ping timeout: 272 seconds]
printallthething has quit [Read error: Operation timed out]
printallthething has joined #linux-sunxi
Night-Shade has joined #linux-sunxi
Night-Shade has quit [Ping timeout: 248 seconds]
rellla has joined #linux-sunxi
netlynx has joined #linux-sunxi
HeHoPMaJIeH has joined #linux-sunxi
HeHoPMaJIeH has joined #linux-sunxi
HeHoPMaJIeH has quit [Changing host]
rellla has quit [Ping timeout: 240 seconds]
rellla has joined #linux-sunxi
wolfy has joined #linux-sunxi
<oliv3r> good morning all :)
<oliv3r> right, I totally missed that lkcl was here last night :( I backread, but had a few questions :)
nfet_ has quit [Ping timeout: 252 seconds]
<JohnDoe_71Rus> oliv3r: day
<oliv3r> lkcl: don't get me wrong, I understand where you are comming from, a little hippocryitcal witht he Gmail and samba/windows work in your past :p but I do get it. But just as you are pragmatical about using linked in, I think github serves the same purpouse here, to reach a bigger crowd. Now, I can't imagine github using their own server, I would be flabbergasted if they didn't use 'the' common git server. With their own hooks to their non-distributing
<oliv3r> lkcl: That said, If I send you an e-mail, from my outlook mail client, via our exchange server, will you refuse to read it? What about sending me mail? Your mail server is talking to my propriatery exchange server? Is that allowed? If so, why is it not allowed to send mail to linux-sunxi@googlegroups.com but it is allowed to send to some exchange server?
<oliv3r> I'm honestly asking a question to learn the why and why not.
<wens> seems like i have to make a different composite clock just for gmac
nfet_ has joined #linux-sunxi
<oliv3r> lkcl: since with such strict rules, a lot of forms of communications are restricted. Since a lot of mail servers out there run some form of exchange or other saas.
<oliv3r> anyway, lets forget even that, you are ok with dev@linux-sunxi.org which is great, but (and i shouldn't even go here :p) that just forwards to linux-sunxi@googlegroups.org so that is allowable?
<oliv3r> it's just a really entangled web and pretty much dissallows you from using anything really
<oliv3r> No cell-phones, no electricity, no gas, no water
<oliv3r> as the companies supplying you with these services use propriatery systems to deliver their goods (energy counter with propriatery software (even has gsm modem these days)) etc
<oliv3r> so while your goals are extremly noble and I do agree with them ...
n01 has joined #linux-sunxi
tomboy64 has quit [Ping timeout: 240 seconds]
<oliv3r> so now more important thigns, olimex Lime, 50 dev boards announced, but is it good to start stirring up the media outlets yet
<oliv3r> you won't be able to get it for atleast 2 weeks
<oliv3r> so it might frustrate the crowd
<oliv3r> Tsvetan: what do you think
<Tsvetan> Lime is not in mass production yet
<Tsvetan> but will be soon :)
tomboy64 has joined #linux-sunxi
_massi_ has joined #linux-sunxi
<oliv3r> yeah in 2x weeks
<oliv3r> The news is just very exciting
<oliv3r> that I want to start spreading the word :p
<oliv3r> Tsvetan: are all 50 units gone?
<Tsvetan> there are few left I think
<ganbold> Tsvetan: how much they cost?
<Tsvetan> ganbold EUR 30 000
<ganbold> ah, just found
<Tsvetan> as they are from limited edition :)))
<oliv3r> Tsvetan: if there only a few left, its practically sold out :p;
<oliv3r> Tsvetan: make sure to bring some to fosdem; i wanna buy one there :)
Quarx has joined #linux-sunxi
<Tsvetan> sure
<oliv3r> Tsvetan: do we need to add it to u-boot? i'm sure we'll need a fex file
<Tsvetan> oliv3r dimitar did the images, but I will ping him to contact you about u-boot etc
<Tsvetan> it would be great if LCD bug is also fixed for the LVDS displays with 2 channels
<oliv3r> patches welcome :p
<Tsvetan> as now this is made with external patch (again)
<Tsvetan> these patches never meet your style/requirements ;p
<oliv3r> Tsvetan: u-boot patch is really easy and fex patch too :p dimitar will do just fine; otherwise, i'll fix it up :)
<oliv3r> lime is too important :)
<oliv3r> oh from when is that mail
<oliv3r> 21 mnov, i haven't seen it
<Tsvetan> :))))
<oliv3r> looks fine to me
<oliv3r> though the .c file may be a dupe, let me check
speakman_ has quit [Ping timeout: 260 seconds]
speakman has joined #linux-sunxi
<oliv3r> hmm i never saw that mail, I promise :)
<n01> anyone preparing t-shirts for fosdem?
JohnDoe_71Rus has quit [Read error: No route to host]
<oliv3r> Tsvetan: i found the message in my trashbin; i really accidentally did that; sorry
<oliv3r> n01: oh god lol
<oliv3r> fatal: corrupt patch at line 59
<oliv3r> bah
<oliv3r> Tsvetan: i'll fix it ;)
<gzamboni> OT: does anyone knows how to make thunderbird run faster with large IMAP mailboxes ?? It's really slow, i already tried to compress large folders, to set a higher hd cache...
<gzamboni> i have 3 imap mailboxes with some ML and some filters set up to move messages to specific folders
<oliv3r> gzamboni: how large is large?
<oliv3r> i have 5k mails and not reall yany trouple
<oliv3r> filtering should really be done on the server itself, but erm
<oliv3r> i have my mailbox on a raid array, with really small chunk sizes, 2k i think
<gzamboni> let me check how large
<n01> gzamboni: I use mutt + offlineimap with mailboxes ~10k and it is pretty fast
<oliv3r> 16k chunk size :p
<oliv3r> so how slow is 'slow'
<gzamboni> i have 21gb in my personal thunderbird profile dir
<n01> wow
<gzamboni> i have emails up to 1998
<gzamboni> i will try to backup my profile and launch thunderbird, it will take some hours to download it all again but it shouldnt be fragmented
<n01> gzamboni: you can try with offlineimap
ZetaNeta has joined #linux-sunxi
<gzamboni> n01: let me check it
<oliv3r> gzamboni: well i occasionally wipe my thunderbird imap dir; once every few years
<oliv3r> that cleans old cashes out
<oliv3r> also remember to 'compact folders' in the GUI as that should clear cash took
<oliv3r> the point of thunderbird is that you don't need to download everything
<gzamboni> yes, i did set the compact folders option
<oliv3r> only the headers
<oliv3r> mails get downloaded 'on demand'
<oliv3r> make sure to enable server side search
<oliv3r> and disable 'global search' as that forces the client to download all messages and search locally
<gzamboni> humm, ok, i will check all that, and i will try out also offlineimap
<oliv3r> If you have folders with many emails inside, Indexing can slow down Thunderbird. Go To Preferences → Advanced → General tab and disable the Global search.
<gzamboni> humm , didnt know about the global search, thanks
<oliv3r> i think there was a second option
<oliv3r> 'synchronize and storage' tab, you can size that down
windyan has quit [Quit: 离开]
<oliv3r> i've never used offline imap, but that'll probably cache everything locally
<oliv3r> copy/cache so not sure if that helps
<gzamboni> i just set it up and wipped out data, it is downloading all headers...
<gzamboni> seems 20x faster already
<gzamboni> damn, i lost all my filters :P
<oliv3r> you deleted your entire profile?
<gzamboni> no, i did only rename the Imapmail dir
<gzamboni> ImapMail to ImapMail.bk
<oliv3r> did you bak it up?
<oliv3r> when it's done syncing, close it up
<oliv3r> and copy 'msgFilterRules.dat' back?
<oliv3r> but yeah, that's the proper way
<oliv3r> well 'proper'
<oliv3r> hno: i seem to be getting some dep. error; building u-boot twice is ok, but the first go I get: make[2]: Leaving directory `/silo/build/sunxi-bsp/u-boot-sunxi/common'
<oliv3r> make[1]: Leaving directory `/silo/build/sunxi-bsp/u-boot-sunxi'
<oliv3r> but i don't see an error
<oliv3r> make: *** [u-boot] Error 2
<oliv3r> second pass it's fine
<oliv3r> if i do make u-boot 1> /dev/null
<oliv3r> only a warning on do_gpio
<oliv3r> er cmd_gpio
<oliv3r> ah no i triggerd the error properly now: /silo/build/sunxi-bsp/build/A10-OLinuXino-Lime-u-boot/spl/lib/vsprintf.o: file not recognized: File truncated
<gzamboni> thanks oliver, i will do the restore the msgFilterRules.dat files
<gzamboni> they should do a graphical function to do the wipeout, maybe there is a plugin, i will search
FR^2 has joined #linux-sunxi
panda84kde has joined #linux-sunxi
tzafrir has quit [Ping timeout: 272 seconds]
<Tsvetan> great! thanks
<oliv3r> Tsvetan: no problem
<oliv3r> had to do some hacking and fix up the patch, as it did not even remotly apply :p but it's sorted now :)
maz_ has joined #linux-sunxi
<oliv3r> Tsvetan: if you could get us a patch for the fex file, we'll add it to sunxi-boards aswell
<Tsvetan> sure
<oliv3r> Tsvetan: btw, i only did a compile test; i don't have a board to test u-boot so if one of you can confirm it works; that'd be great
<Tsvetan> will do!
<HeHoPMaJIeH> oliv3r: it works fine i just tested it
<oliv3r> HeHoPMaJIeH: cool
<oliv3r> (you did actually pull the fresh tree right :p)
<oliv3r> and sorry again for missing the mail
maz_ has quit [Ping timeout: 246 seconds]
techn__ has joined #linux-sunxi
techn_ has quit [Ping timeout: 246 seconds]
deasy has joined #linux-sunxi
<HeHoPMaJIeH> yes i did it works as expected :)
arete74_ has quit [Ping timeout: 264 seconds]
<oliv3r> good :p
<oliv3r> mripard: i take it you didn't use my sun6i ccm defines/headers etc from my github did ya :)
<mripard> oliv3r: nah
<mripard> you told me you had it after I wrote it :(
<oliv3r> i told you MONTHS ago :p
<oliv3r> you forgot :(
<oliv3r> you forget about me!
<oliv3r> i'm in the process of replying to you :)
<oliv3r> but since you here now:
<oliv3r> i think the two overlap cleanly don't they?
<oliv3r> e.g. as in i think 1 register struct can be used for both? Your comments are better though :)
<mripard> yeah, I totally forgot :(
<oliv3r> but i don't know what's the recommended way to merge this
<oliv3r> have 2 structs, sunxi and sun6i
<oliv3r> or use the 'combined' one (e.g. my commit, with your comments)
<oliv3r> i do think my PLL5 P needs the a sun6i guard as that's clearly different
<wens> oliv3r: where did we get the CCM register offsets?
<mripard> I'd really prefer to have two different structures
<mripard> it's hard enough to get the register offset
<mripard> from the structure layout
<oliv3r> mripard: you are more experienced to go there :)
<mripard> we don't need to cripple it with ifdef everywhere
<oliv3r> the offsets are idetnical btw
<oliv3r> the differences are sun6i uses registers taht are marked 'reserved' on sunxi
<oliv3r> the PLL5 if guard I mention above will be needed eitherway
<oliv3r> it's for a define and the content of pll5 is differently handled for P
<oliv3r> wens: mripard :p
<wens> mripard: does the A31 ccm have a gmac clock like in A20?
<mripard> oliv3r: hmmm, ok then
<oliv3r> mripard: (the patch i linked above is really small)
<oliv3r> mripard: now this probably needs testing and some reviewing as I may have done it all wrong; but I done the gpio bit too
<mripard> wens: yep, it does
<mripard> pretty much the same register except for two things
<mripard> the pre-divide ratio isn't there
<mripard> and it at offset 0xd0 instead of 0x164
<mripard> oliv3r: see, a difference already !
<oliv3r> mripard: LOL really?
<oliv3r> wait let me double check that
<wens> i never tested the pre-divide and external clock input
<mripard> wens: then it's just the offset that differs.
<oliv3r> 0x164 is 'reserved'
<oliv3r> as for 0xd0, that's gps_clk
<mripard> on the A20?
<oliv3r> on sun4i for sure
<oliv3r> not so sure for a20
<wens> since it works without the external stuff, I'm inclined to ignore it, and just model it as 2 gates, versus a whole non-standard composite clock (div, mux, gate)
<oliv3r> but we do think they removed GPS from A20
<oliv3r> with GMAC clock taking the former gps clock, it seems that a20 physically removed the GPS, not left it as dead silicon
<wens> 0xd0 on A20 is reserved
<oliv3r> wens: yeah 0xd0 was 'GPS' clock
<oliv3r> wens: on sun6i that's repurpoused for gmac appearantly
<oliv3r> so it looks liek GPS -> GMAC -> reserved (sun4i -> 6i -> 7i)
<oliv3r> if that's how it evolved
<oliv3r> mripard: anyway, you probably best talk to hno how about this is properly done; I don't know nor am qualified to do so
arete74 has joined #linux-sunxi
rz2k has joined #linux-sunxi
<mripard> oliv3r: yeah, I'm expecting some feedback from him :)
<n01> mripard: are you familiar with regmap_* framework?
naobsd has joined #linux-sunxi
<mripard> n01: I was going to reply to you in private about this
<oliv3r> mripard: anyway, to summarize what I played with; added the clocks, added pinmux as there's a whole new bank; added P2WI controller (if you can test that and fix that somewhow that'd be cool :)
<mripard> n01: I looked into it a bit, but never used it.
<mripard> n01: why?
<oliv3r> added axp221 driver (a basic version of it)
<oliv3r> added some PMU work and i have some preliminary ram work; but I only finished about 60% fo that
<n01> mripard: for the axp driver I have a doubt about regmap_add_irq_chip and irq domains
<mripard> oliv3r: P2WI and PMIC interactions are relevant only if you have an SPL
<mripard> which is not really what I'm aiming for right now
<n01> mripard: eventually I'll drop you an email
<oliv3r> hmpf :p
<oliv3r> fine!
<oliv3r> :)
<oliv3r> mripard: i still think you should shun a31! you and hans G and your dirty a31, SHUN!
<mripard> n01: let me take a look
<n01> mripard: this is the skeleton for axp209 if you need https://github.com/carlocaione/linux/blob/sunxi-axp20x/drivers/mfd/axp209.c
<mripard> oliv3r: honestly, if I was to stop working on any SoC that has a PowerVR, I wouldn't have much work.
<oliv3r> mnemoc: pong btw
<oliv3r> mripard: lots to do for a20 :p
<oliv3r> mripard: i understand, it just makes me sad!
<mripard> why ?
<mripard> most of the work I do for the A31 isn't lost.
<oliv3r> it makes the powerVR based SoC attractive
<mripard> especially if IPs are reused in the future chips
<oliv3r> 'look, it works etc'
<oliv3r> yeah that's why i started a31 u-boot
<mripard> haha
<mripard> I wouldn't qualify the A31 as "working" :)
<oliv3r> mripard: i ment powerVR in general :)
tzafrir has joined #linux-sunxi
<oliv3r> mripard: think pengpod
<mripard> what about pengpod?
<oliv3r> the a31 based one
<oliv3r> blobs galore!
<oliv3r> 'but look, a fast a31 tablet'
<mripard> I have counter examples if you want.
<oliv3r> bring it! :D
AreaScout has joined #linux-sunxi
<oliv3r> mripard: do you have a gitorious account I can add you as?
<mripard> Intel Atoms, TI's OMAPs, most notably
<mripard> both selling quite well, and being into countless devices.
prasannapete has joined #linux-sunxi
<oliv3r> do atoms have the memory init blobs like the other intel CPU's?
<oliv3r> and ti is dirty! :(
<mripard> the powerVR being a pain to integrate, and imagination closing all about it is a fact
<mripard> but I won't stop using a SoC just because it has a powerVR
<mripard> just like I won't stop sending mails to people just because they use gmail.
<oliv3r> lol
<oliv3r> mripard: but you also don't have a problem in using the binary blob! :(
<mripard> I'd like to, but it's just not realistic
<oliv3r> atm not at all
<oliv3r> i don't think we have any open graphics driver yet; there's some really good work being done
<oliv3r> powerVR is just unlikly to get RE any time soon
<oliv3r> mripard: did you order your LIME allready :p
notmart has joined #linux-sunxi
<mripard> oliv3r: not yet
<mripard> but I definitely want to
<mripard> especially since I don't have any decent A10 board to hack on
<oliv3r> mripard: no cb1?
<oliv3r> well mine's broken
<mripard> nope
<oliv3r> i'll get mine at fosdem to skimp on shipping :p
<oliv3r> i really wanna try to turn it into an xbmc box though eventually
naobsd has quit [Ping timeout: 250 seconds]
<mripard> I have a hackberry
<oliv3r> is that A10?
<mripard> but it doesn't really qualify at "decent"
<oliv3r> howso?
<mripard> you have 0 schematics.
<mripard> (plus, I really like olimex boards.)
<oliv3r> yeah i do too
<oliv3r> OSHW :p
<oliv3r> mripard: but i'm now really interested in A23 and A60 as to what they will do with sun6i IP; e.g. memory controller etc
<juanfont> oliv3r, does the A23 have an CedarX unit?
<juanfont> s/an/a
<oliv3r> juanfont: extremly extremly likly it does
<oliv3r> it's a safe bet
<juanfont> so... somewhere in China there is an implementation of OpenMax over CedarX
<oliv3r> appearntly libcedarx supports or will? support openmax
<juanfont> having OpenMAX (xbmc, gstreamer,...) would be sooo nice
<oliv3r> dunno :)
<oliv3r> i doubt their openamx implementation will all the crappy ness of the current blob go away
<juanfont> true. but an operational xbmc may steal users from rpi
apo has quit [Read error: Operation timed out]
apo has joined #linux-sunxi
apo has quit [Remote host closed the connection]
apo has joined #linux-sunxi
<oliv3r> Turl: ping
apo_ has joined #linux-sunxi
kivutar has joined #linux-sunxi
patapovich has joined #linux-sunxi
apo has quit [Ping timeout: 272 seconds]
<patapovich> this sdk seems to have something omx related https://anonfiles.com/file/78f773e3ba2571cd609139fe6983dba9
<juanfont> ummm, lets see
<patapovich> not shure if it is enought
<juanfont> where it is from?
<patapovich> random discovery on google
<patapovich> looks like its for sun6i
JohnDoe_71Rus has joined #linux-sunxi
n01 has quit [Ping timeout: 260 seconds]
n01 has joined #linux-sunxi
popolon has joined #linux-sunxi
popolon has joined #linux-sunxi
jinzo has joined #linux-sunxi
patapovich has quit [Ping timeout: 250 seconds]
<Turl> oliv3r: pong
<oliv3r> Turl: ah crap i forgot again
<oliv3r> Turl: oh no wait i know
<oliv3r> tuis there a (memory_) test in your rootfs vs3?
<Turl> probably not
<Turl> but there may be tinymembench on there
<oliv3r> that probably tests your spatche
<oliv3r> standard memcpy : 305.2 MB/s
<oliv3r> standard memcpy : 305.2 MB/s
apo_ has quit [Ping timeout: 272 seconds]
<Turl> oliv3r: wait until the neon fill ones
<oliv3r> NEON fill : 1467.8 MB/s
<oliv3r> but fill isn't copy!
<oliv3r> NEON copy prefetched (64 bytes step) : 921.8 MB/s
apo has joined #linux-sunxi
<Turl> oliv3r: are you on A20 hw?
<oliv3r> a10
<Turl> ah
<Turl> a10 isn't affected by these patches
<Turl> :P
<oliv3r> ah, i should have known that
<oliv3r> mbus isn't configureable on a10 :p[
apo_ has joined #linux-sunxi
apo has quit [Ping timeout: 272 seconds]
apo_ has quit [Ping timeout: 272 seconds]
apo has joined #linux-sunxi
Tsvetan has quit [Ping timeout: 240 seconds]
Tsvetan2 has joined #linux-sunxi
<mnemoc> oliv3r: still around? regarding gitorious, how do I create repos? :(
<oliv3r> mnemoc: 'add repo'
<oliv3r> ?
<mnemoc> btw, git.sunxi.org is only a MIRROR, read-only.
<mnemoc> oliv3r: I can't see such option...
<oliv3r> there should be abutton on the top right where it says 'repostiories + add new'
<oliv3r> but
<oliv3r> i broke the permissions for the main thing :p
<oliv3r> allready submitted a ticket
<oliv3r> appearantly you can remove all rights from your main tree
<oliv3r> yeah that's different
<oliv3r> +linux-sunxi is our 'team'
<mnemoc> I'll setup now the automated syncing to those repos you set up
<oliv3r> cool
<mnemoc> oliv3r: can you disable tickets and wiki etc? to reduce fragmentation
<oliv3r> allready did
<mnemoc> thanks :)
<oliv3r> tickets not
<oliv3r> but i dont think that it exists
<jinzo> mnemoc, so the github is and will stay main dev. ?
<mnemoc> jinzo: yes
<mnemoc> the mirror syncs every 5m anyway
juanfont has left #linux-sunxi ["Saliendo"]
<jinzo> you still in germany if I may ask?
juanfont has joined #linux-sunxi
<mnemoc> jinzo: git.sunxi.org as main repo will kill the bw quota
<mnemoc> jinzo: yes
<jinzo> I hope stuff is getting better for you. At least I see you're back in linux-sunxi 'near-full-time' :P
<mnemoc> git.sunxi.org and gitorious mirrors are intended only for people who can't (or rejects to) use github
<jinzo> at least one man will be happy :)
<mnemoc> *g*
<mnemoc> github also tends to be blocked by the great firewall
<oliv3r> Turl: strange, on A20, NEON is the same speed as A10, yet memcpy is twice as fast
<mnemoc> and DoS'ed... those are the technical motivations to have official mirrors
<oliv3r> Turl: neon copy; neon fill is a bit faster
<oliv3r> i suppose bw wise the mirror priority should be github; gitorious; sunxi
<mnemoc> +1
<mnemoc> let's github pay the bigger bill :p
<jinzo> :D
<oliv3r> gitorious for those who have problems with github or have great firewall etc
<oliv3r> and if both are down or unreachable, a backup at sunxi
<jinzo> oh, regarding hosts etc. I'm using waveride.at VPS in Austria for ~half a year now. Cheap and works suprisingly well, don't know if I had 2 downtimes.
<oliv3r> i likei t
<oliv3r> Turl: but a10 and a20 run normally with yours and wens's patches
<oliv3r> Turl: i can't test is gmac a20 using MII patch those, as I don't have an ethernet cable or testing facilities atm
<oliv3r> i can test dhcp and ping a few ip's at the most
<netlynx> Anybody here that has hands-on experience with the PhoenixA20? Anybody that can confirm is it really for sale? (Is this PhoenixA20 store trustworthy? http://www.aliexpress.com/store/820844)
<oliv3r> only heard of it in passing and on the ML
<jinzo> Netlynx, aliexpress has by default escrow protection that at least somehow works - it's a bit of a tedious process but it's possible to get the money back if nothing gets shipped/the stuff shipped isn't good.
* mnemoc hopes olimex gives away a bunch of LIME boards in oliv3r's fosdem's talk
<mnemoc> die rpi die
<jinzo> :D
<jinzo> LIME looks very good indeed.
<oliv3r> Tsvetan2: ^ :p
<oliv3r> yeah i really hope it'll kick pi's ass
<oliv3r> but for that to happen; we need to do a lot of work
<oliv3r> xbmcpi
<jinzo> yeah, xbmc stuff would be a major seller. How's the video stuff going?
<mnemoc> for starters sunxi-3.10 and lima and cedarx re android 4.4 bindings
<jinzo> the I lost the name off my tounge at the moment
<jinzo> cedarx that's it :D
<jinzo> also A20's cedarx supports hw VP8?
<mnemoc> inexpensive oshw board running 100% free software!
<mnemoc> and latest android :p
<jinzo> :D
<oliv3r> mnemoc: that's probably a 2nd goal; i'd be happy with sunxi-3.4; mali and cedarX
Tsvetan2 has quit [Ping timeout: 260 seconds]
<oliv3r> then quickly going for libvpdau
<oliv3r> add lima asap; then go for 3.10 :p
<mnemoc> oliv3r: 3.10 is need to shield us from mainline bashing :(
<oliv3r> yeah but it requires a lot of work
<torbenh3> mainline bashing ?
<mnemoc> why are you idiots using that script.bin thing and not DT and mainline!
<mnemoc> sunxi-3.10 is intended as a hybrid
<oliv3r> i know!
<mnemoc> Turl offered to work on lima and cedarx re android bindings
<oliv3r> but we need to do a lot of work for it still :)
<torbenh3> ah that.
<mnemoc> oliv3r: it was for torbenh3 :p
<oliv3r> oh :p
<torbenh3> yeah that sentence is resonating in my head all the time :P
<oliv3r> wens: i can't reliably test your gmac/emac patches for u-boot
<oliv3r> wait, i can try doing dhcp request via u-boot
<mnemoc> torbenh3: we need a full featured kernel for normal humans, and a place to test not-yet-mainline-ready DT-based drivers
<mnemoc> torbenh3: 3.10 been next-android and LTSI is perfect to that stepping stone
<libv> mnemoc: we need a full featured kernel which people can run on (former) android devices almost straight away
<mnemoc> libv: sunxi-3.10 is androidized
<oliv3r> wens: i'm not getting bootp responses :(
<Turl> mnemoc: wait what? :)
<libv> others we might just put "We only support these 10 development boards and nothing else" on the front page of the sunxi wiki
<libv> mnemoc: it's my tangible reason for not liking mainlining and not liking being forced to use DT
<mnemoc> Turl: you forgot, but you did offer us to have a fully free AOSP 4.4 with bindings for fosdem
<libv> otherwise even
<Turl> mnemoc: o.O
<Turl> mnemoc: my mind must be getting ram corruption then :p
<oliv3r> Turl: start paniking and start hackign :)
<Turl> oliv3r: haha
<Turl> oliv3r: btw, if I can find the usb cable for my usb to sd reader I may be able to give gmac on cb2 a try
<oliv3r> Turl: stop everything you are doing and find that cable
<libv> mnemoc: do you have any contacts into mele? do you remember if tomcubie had good contacts?
<Turl> oliv3r: I'll gladly do so if you go pay my rent now :p
<mnemoc> libv: tom was an official reseller of mele, and I think he had good contacts
prasannapete has quit [Ping timeout: 260 seconds]
<libv> mnemoc: ok, i will poke him next time he is around to see whether he can have anyone look at the schematics of the A1000 for a minute
<libv> i mailed the european sales person, but i doubt anything will come of that
<Turl> libv: what's so interesting of the A1000 schematics?
<libv> Turl: the vga connector is blue
<libv> cryptic answer :)
<Turl> all of 'em are
<libv> Turl: nope
<libv> Turl: some are black
<libv> Turl: black was universal until like 1994
<libv> Turl: now why is a vga connector blue?
<Turl> I've never seen a black vga in my life
<JohnDoe_71Rus> seen black vga at monitors
<libv> Turl: i have some S3 Trio64V+ with black connectors
<oliv3r> Turl: hah, gotta manage to pay my own first :p
<libv> Turl: and some S3 Trio64V+ with blue connectors
<JohnDoe_71Rus> and and collapsible vga
<libv> Turl: DDC
<libv> Turl: blue means that DDC is wired up
<oliv3r> yeah black vga was hot after it was beige
<oliv3r> oh you mean there's actually a 'rule' for the color?
<libv> Turl: and i know exactly where i have to poke my S3 and Tseng cards to talk to a monitor, if they have a blue connector
<oliv3r> from what i saw on the olimex board, is that ddc was connected i think
<libv> i just never done anything with it yet
<libv> oliv3r: the A13 olinuxino?
<oliv3r> of course mele is a different beast
<libv> anyway, the vga connector is on a separate module on the mele
<oliv3r> a20 olimeiino micro
<oliv3r> but seperate module there too
<libv> oliv3r: there are about 6 wires running to that connector
<libv> oliv3r: 3 for rgb, 2 for h/vsync, and 1 for gnd
<libv> oliv3r: no ddc on that one
<Turl> libv: is DDC just an i2c?
<libv> Turl: yes
<Turl> libv: then you can guess/probe where is it connected? :p
<libv> Turl: i am not stupid, you know
<libv> Turl: i have gone through all unused io ports, and fully enabled them, to no available
<libv> whereas the known TWI2 pins did show a change with those actions
<libv> TWI2 is where cubietruck has DDC wired up
<oliv3r> ah yeah CT schematic i checked; i appologize libv, olimexino micro may not have it done properly
<libv> err, s/available/avail/
prasannapete has joined #linux-sunxi
<libv> 6 wires is the absolute bare minimum for VGA
<libv> 2 more wires and one would be able to actually find out what the monitor allows
iamfrankenstein has joined #linux-sunxi
<libv> anyway, the 2 ddc lines are wired to the motherboard, but then all traces vanish
<Turl> libv: does it work with android?
<libv> Turl: no, but that just might be allwinner software stupidity
<Turl> libv: it's odd that nobody complained about it so far
<libv> Turl: again, the vga module is separate from the motherboard and has exactly 8 wires
<libv> it's quite expensive to do those two extra wires
JohnDoe_71Rus has quit [Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org]
<libv> only to have them sitting dead on the motherboard
<Turl> libv: they also have a dead uart connector and a sata header if you think of it
<libv> Turl: dead or just not correctly wired/connectored up?
<libv> Turl: caps and resistors are missing and connector is missing
<libv> Turl: that's the cheap part
<Turl> libv: dead as in 'it's there, but not used'
<oliv3r> libv: my internet is down atm; installing squid on a box that does have wifi (cli only)
<oliv3r> where's hno when you need him :)
prasannapete has quit [Quit: prasannapete]
<libv> Turl: again, so no connector wired to it, and no caps/resistors on the path to it
<libv> Turl: the fully wired up connector is supposed to work
<oliv3r> libv: but yeah hitup hipboi, he might get in touch with allwinner
<libv> s/allwinner/mele/ :)
<mnemoc> oliv3r: "Sorry, only repository admins are allowed to do that".... can you create a sunxi-bsp ?
<oliv3r> mnemoc: nope, as I said before, i broke it :p
iamfrankenstein has quit [Read error: Connection reset by peer]
<oliv3r> mnemoc: or it let me break it; but I made a ticket allready
<oliv3r> mnemoc: and complaint that it's stupid that the UI lets you strip all rights :p
<oliv3r> libv: rgr
adb_ has joined #linux-sunxi
<oliv3r> tsve... crap he's not here, i wanna know what's inside that vga cable connector
<oliv3r> if there's no components, i can build one myself easily
<oliv3r> i'd still need to get the header though :(
<libv> oliv3r: what vga cable connector?
<libv> oliv3r: the a20?
<oliv3r> yeah
<oliv3r> could be some passives are needed
<libv> oliv3r: 6 wires: rgb, h/vsync, gnd
<oliv3r> maybe some chokes/resistors
<oliv3r> i doubt it does though
<libv> ...
<oliv3r> getting the micro-JST is the hardest part
<oliv3r> i would actually even expect that possible passives be on the PCB allready
<libv> oliv3r: yup
iamfrankenstein has joined #linux-sunxi
<libv> oliv3r: it makes no sense to put them in the actual connector
<oliv3r> interference?
<oliv3r> but as I said, I doubt it; vga is so simple :)
<libv> oliv3r: but it's 6 wires, the 5 signals are needed for getting anything on the screen and come from the DAC (rgb) and the crtc (h/vsync)
<oliv3r> it's good that they used this connector even, because the RGB wires, are from the analog tv encoder, which can do vga OR whatever else you want; so you can use it to do scart RGB
<libv> oliv3r: no room for ddc in there
<oliv3r> libv: yeah :( they could have added that atleast
<mnemoc> oliv3r: sync'ing in place.
<libv> oliv3r: yeah, you can do scart, but that's so 1990s
<oliv3r> my tv upstrairs in the bedroom only has composite or scart :p
<libv> :)
<oliv3r> and composite works, but svideo/RGB looks so much better
<oliv3r> so yeah, i really wanna hook up my tv that way at some point :)
<libv> i actually have an old, small CRT based TV, which i picked out specifically for its dual scarts
<oliv3r> dual scarts + 2 connectors at the front
<oliv3r> even stereo audio :p
<libv> because that meant that there was a 99% chance of it doing composite on one and s-video on the other
* Turl always gets confused when people mention scart
<oliv3r> Turl: how so?
<Turl> oliv3r: that thing doesn't exist over this side of the pond
<oliv3r> Turl: I know :p which is sad, because 'back in the day' there was nothing other then composite/svideo for that side of the pond
<libv> Turl: horribly overdesigned french thingie
<oliv3r> libv: scart is awesome :p
<libv> many signal pins are doubled up, one for input, one for output
<Turl> oliv3r: we had cable in
<Turl> :p
<oliv3r> thought they shouild have just used vga
<libv> then some shorting pins for signalling which is wired up
<libv> and then iirc, a 12V (!) pin functioning as HPD
ganbold_ has joined #linux-sunxi
<oliv3r> i belive so yeah
<Turl> oliv3r: we also had these composite looking thingy
<Turl> but there was one rca connector per color
<wens> oliv3r: which tree did you try? I can give it a go tomorrow
<libv> Turl: that's HDTV times already
<libv> Turl: scart is 80s and 90s and is still present on many modern tvs
<Turl> libv: I've seen that on thick tube tvs though
<libv> Turl: 4:3 or widescreen?
<libv> Turl: scart was designed to also allow for full rgb
<libv> Turl: in the _80s_
<Turl> libv: I don't recall
<libv> Turl: because it was french and became a defacto european standard
<oliv3r> Turl: i ran tinymembennch 200 times (when it's done) so looks good to me :)
<oliv3r> Turl: that's 'component' and i think it still in use for analog HD
<oliv3r> wens: i took your tree and cherry picked your patches and turl's
<oliv3r> wens: but bootp not working might be entirly the network here; it doesn't fail or crash
<oliv3r> so i'm inclined to push it anyway
<libv> Turl: as for strange connections
<libv> Turl: i have a iiyama vision master pro 453 here
<libv> Turl: a 19" flatfronted trinitron CRT
<libv> with...
<libv> a working dvi-d input
<oliv3r> O.o
<libv> absolutely unique.
<libv> there were some sony and ibm monitors with "DVI connectors" but that was dvi-a, so basically vga repackaged
<libv> i got that thing, new, 2 years before i started doing graphics driver development
<Turl> :)
<oliv3r> well what about LCD's with vga connectors
<oliv3r> while i obviously understand the 'why'
<libv> oliv3r: that was fun
<oliv3r> the whole digital -> vga -> digital is weird
<libv> oliv3r: it was expensive to add those analog to digital conversion bit
<libv> oliv3r: but only the cheapest came with only vga
<Turl> oliv3r: I'm using one now :$
<libv> early 2000s you couldn't buy an affordable panel with a digital connection
<libv> it probably cost a few EUR more for the vga->digital convertor, but they damn well refused to put dvi-d only panels on the market
<Turl> I should buy another hdmi cable and use the dvi to hdmi adaptor it brought with it
<oliv3r> i currently use displayport and dvi from my graphics card
<oliv3r> and i sure as hell hate displayport
<oliv3r> it has this really annoying feature, that the monitor pretends it's disconnected when you turn it off (but not when it goes into standby)
<oliv3r> or switch input on it (to say dvi or vga)
<oliv3r> now if i switch back/turn it back on, it doesn't properly announce that ti's connected again (or the drivers suck at picking it up again)
<libv> oliv3r: this is all pretty bad
<oliv3r> and i have to do a ctrl-alt-f1 - ctrl-alt-f7 to get it to come back up
<libv> oliv3r: different monitors respond differently
<libv> oliv3r: putting no load on analog lines, switching off the hpd pin, etc
<oliv3r> these are HP LP2475w's
<oliv3r> pretty fancy mo
<libv> oliv3r: all respond differently to DPMS signalling
<libv> oliv3r: then there are the various adapters... they are also likely to mess up the hotplug pins
<oliv3r> yeah
<oliv3r> but only displayport
<libv> even ati messed that up badly
<libv> this was dvi/hdmi
<oliv3r> the dvi stuff works 'fine' on the same monitor (i have 2)
<oliv3r> but even here at work, using win we've had the same thing happening
<libv> and for r500, they forgot to design hpd pin assignment into ATOMbios
<libv> so you would be able to get a full connector layout, but no clue about which pin was HPD
<libv> there were like 2, so you got lucky most of the time
<libv> for others we had a table which swapped them around
<libv> but...
<oliv3r> ah, so it's even likly it's something similar
<libv> since atombios didn't do it, it wasn't tested for either
<libv> so some boards just had broken HPD (a ddwg hard requirement)
<libv> and ati gave us at SuSE crap for using it, guessing the pin and for working around the swapped ones.
<libv> even though it work for 98% of r500 cards out there
<oliv3r> hehe
<libv> the hw supported it, some idiot forgot about it when designing a bios monstrosity, there was no testing support as ati tried to shove it under the rug, and it was used against driver developers because they wanted to use the available hw fully and properly and therefor exposed ATIs shortcomings...
<oliv3r> well looks like they are still struggeling with HDP
<libv> it's really simple, is this pin wired to the 5V pin?
<libv> but it gets messed up soo often :)
<libv> but then, where are my DDC lines on my _blue_ vga connector on my mele! :)
<oliv3r> hahah
<oliv3r> 'hidden'!
<oliv3r> i wanna know if a20 mele has the vga connector still on board
<oliv3r> e.g. same pcb
<libv> hehe, probably
<libv> and they damn well will never have been tested
<libv> i really think there is a chance that the connections just never reach the A10
<libv> but that would be a rather monumental failure :)
<oliv3r> hopefully you get a quick reply from mele
<libv> i think it more likely that it is muxed with something i haven't tested, like PIO pins that were in use
<oliv3r> but if it's a 4 layer pCB
<libv> oliv3r: i couldn't optically spot where these lead
<oliv3r> well those signals could run on layer 2 and 3
<oliv3r> and you'd never see them
<libv> right
<libv> i ran a program over all the available pins
<libv> if they were switched to input, i switched them to output, drove them high, left this for 5s, then restored the pin settings, and then went on to the next pin
<libv> no change on the multimeter
<libv> although the early H ports did kill my mmc, and i had to reboot after the full run :)
<oliv3r> hehehe
<oliv3r> well it has to be a pin like that as it's i2c
<libv> and i did see a change on the twi2 pins which are available slightly to the side of the vga connector
<libv> well, most early DDC implementations were just 2 io pins
<oliv3r> did you e-mail hipboi allready?
<libv> i2c/ddc is slow
<libv> ah, i was hoping for him to turn up here
<oliv3r> i'll pop him an email then :)
<libv> but true, i should mail him
<oliv3r> use his gmail though; or his radxa mail; i don't think he checks his cubietech mail anymore?
<libv> yeah :)
<libv> tapping it out right now
<libv> wait and see how this story ends.
<libv> it would be terrible, but funny, to find that these are just floating :)
<libv> hdmi has a special ddc bus, but it's not physically connected to the vga connector
<hno> oliv3r, what?
<hno> Squid-----
<hno> Squid? Install it, maybe tweak http_access a little to give you access. Also se http_port as some distributions makes it bind to localhost only by default. Configure your browser to use the proxy. Surf away.
<hno> then see cache_dir if you also want caching, but mostly makes sense if you have a network of more than one browser.
<oliv3r> hno: i fixed it :p i have 2 internal ip's but it does work out of the box :)
hansg has joined #linux-sunxi
<oliv3r> hey hans
<hansg> hi oliv3r
eebrah_ has joined #linux-sunxi
adb_ has quit [Read error: No route to host]
<mripard> oliv3r: please keep everyone in CC when you are sending mails.
<oliv3r> mripard: did i not do a reply-all?
rz2k has quit []
keebler_ is now known as keebler
keebler has quit [Changing host]
keebler has joined #linux-sunxi
<mripard> oliv3r: nope
<oliv3r> mripard: which mail are you revering to specifically
<mripard> the one you sent today :)
<mripard> about the A31
<oliv3r> oh yeah I didn't see the copy
<oliv3r> i accidentally did reply instead of reply-all :(
<oliv3r> sorry
torbenh3 has quit [Ping timeout: 246 seconds]
rings_IIV has quit [Read error: Connection reset by peer]
rings_IIV has joined #linux-sunxi
Sonic1 has quit [Ping timeout: 246 seconds]
eebrah_ has quit [Ping timeout: 246 seconds]
torbenh3 has joined #linux-sunxi
KBme has joined #linux-sunxi
<KBme> hi
<oliv3r> lo
<mripard> hansg: hi
adb_ has joined #linux-sunxi
<hansg> mripard, yes
<mripard> hansg: teammate ? :)
<hansg> mripard, I'm planning to get F-21 to support sunxi boards ootb using an upstream kernel (headless, don't think I'll have kms ready), and I'm working with him together on that, he does most of the Fedora ARM work
<hansg> No team mate, he also works for RH but he's in a different team. Like me he does the ARM stuff in his spare time / as a side project
Sonic1 has joined #linux-sunxi
<mripard> hansg: and F21 will be based on 3.14 ?
<hansg> mripard, yes that is the plan, if necessary we will ship with some patches for sunxi (assuming I manage to sell that to the Fedora kernel maintainers). u-boot will likely be a separate uboot-sunxi package for now
<oliv3r> hansg: what about downgrading to 3.4; will that be supported?
<mripard> hansg: nice :)
<hansg> oliv3r, maybe that depends if systemd keeps working with 3.4
<mripard> I expect a busy merge window then :)
<oliv3r> ouch; i have doubts :p
<hansg> oliv3r, the plan is to make upstream so good we won't care about 3.4 any more :)
<oliv3r> hansg: big goals, i like :)
<libv> hansg: have you thought about how upstream-only affects new device support?
printallthething has quit [Ping timeout: 272 seconds]
<libv> hansg: or are we, from now on, only limiting ourselves to a handful of development boards and a limited set of former android devices which were manually ported by us?
<libv> we are even
<hansg> libv, no I've not thought about that.
<libv> hansg: this upstream only strategy is going to kill one of the main features of allwinner hw.
<oliv3r> oh wow, I just realized, i've started my first wiki commit on the 24th of September. I've been with sunxi for more then a year!
<hansg> And no I don't plan to limit us to a limited list of devices, we can still gather fex files, and translate those (manually) to dts files. In the end there is not much difference between a fex and a dtb
<libv> hansg: _manually_?
<oliv3r> should be scriptable
<libv> hansg: anyone with basic linux knowledge can get a proper linux on their android device today
<libv> hansg: dt takes that away
<libv> and therefor kills the main reason for using allwinner, apart from it being cheap and ubiquitous
<hansg> Actually I've a ton of sunxi devices here at home, so one of the first step to better device support will be getting dts for those, but most are not useful without kms as they don't have an (easy) accessible serial port
<libv> hansg: this does need to get solved.
<oliv3r> i think mnemoc was working on a FEX -> dts script
<hansg> There really is not that much difference between a fex file and a dtb file. Both are compiled from some plain-text representation, both contain info needed to get the device going ... As oliv3r said we can probably write an automated script for this
<libv> and it's a difficult task that will see continuous evolution with upstream aditions
<oliv3r> for the adventurous, a webpage dts generator would even be viable :)
<mripard> libv: I'm sorry, but I don't get how it's affecting any of what's happening today
<mripard> you'll get a remix with the 3.4 kernel, just like you do
<hansg> We only need a handful of gpio's, we could also get things like how much sdcard slots there are, etc. from the fex file, but it would be better to ask the user, as this info is very unreliable in fex files
<mripard> the only exception being that some boards will work out of the box
<mripard> I really don't get how it's an issue.
<libv> mripard: so you are only gunning for a handful of boards?
<oliv3r> there is really one big problem with FEX files however that shouldn't be overlooked.
<libv> mripard: you are actually satisfied with that situation?
<oliv3r> often they are really crap, with lots of mistakes/errors
<mripard> libv: no, I'm going for "whatever board is submitted"
<hansg> Right, I still plan to do the remix for a while, it just won't get much of a focus wrt adding really new stuff (just rebase to latest Fedora + new boards from sunxi-boards
<libv> mripard: but you care in no way as to how they get submitted?
<mripard> libv: as a matter of fact, I am. All of my boards are working with the upstream kernel
<mripard> what about yours?
<libv> mripard: i do not claim to support upstream-only, as you well know.
<libv> mripard: so that argument is quite void
<libv> mripard: what boards are that?
<mripard> libv: no, you claim to support anything but upstream
<mripard> you've made a great job at undermining pretty much anything upstream related, for some reason.
<libv> mripard: with good reason, as it doesn't give average joe users a proper linux on their android device _today_
<libv> mripard: so list your hw, and it better have some android tablets in the mix
<hansg> libv, talking about upstream as you've probably heard I plan on writing a kms driver. At first this will be dumb framebuffer only, but in the end I would like to see lima run there. So we will need a drm interface to the mali (and some integration between the 2). Do you know of anyone looking into doing a drm interface for mali ?
<libv> hansg: nope, there is no drm interface for mali.
<mripard> libv: and so, with Fedora having allwinner support out of the box, the average joe will be even happier, because he will just have to take a look at the fedora wiki page and follow the instructions there
<libv> hansg: as it is pointless atm
<oliv3r> hansg: wow, big feat. will it be done by fosdem? :D
<libv> mripard: what hw do you support?
<mripard> again, how is that an issue?
<hansg> libv, this whole running patched-up android kernels thing is a dead end. You talk about users being able to use hardware ootb that way, how does that work out for A31 devices atm ?
<libv> mripard: so just a few development boards then?
<mripard> libv: whatever board is sent to me.
<mripard> if you want to change that, you know what to do
<oliv3r> yer both right though
<oliv3r> you do get that all right?
<hansg> It looks like we will have A31 devices working upstream before the linux-sunxi kernels will support them.
<oliv3r> 3.4 is important as it gets people up and running with all features today
<oliv3r> but the long term goal obviously is to have it mainlined
<libv> hansg: i have a fully free kms modeset working on vga atm
<libv> now adding gem so that i can implement the hwc
<hansg> libv, cool. Do you have a git tree with that somewhere?
<oliv3r> libv: did you hear from tom yet?
<libv> hansg: nope, not yet, it barely does anything.
<mripard> oliv3r: I know. But I don't get how upstreaming things and actually having people using the code we do takes anything away from 3.4
<libv> i just spent yesterday looking for DDC
<libv> on the mele a1000
<hansg> libv, well if it does vga out it does a ton more then my code (which currently is 100% vaporware for now)
<mripard> sure, 3.4 has more hardware support
<libv> and hotplug detection doesn't work either
<mripard> but others things happened only because we were doing mainline stuff as well.
<libv> mripard: you have not thought about any transition, now have you
<hansg> libv, I don't think any boards bother with hooking up ddc to the vga connector, despite the SOC having plenty of spare i2c controllers :|
<libv> hansg: cubietruck does
<libv> hansg: and please check the irclog of today
<hansg> libv, oh cool.
<libv> mripard: please start by writing a wiki page on how to create up a dts file from a .fex
<libv> i last did kms work back in 2009, in an unreleased via driver which i never got working beyond vga and dvi
<libv> and things really have not changed much, although they need a lot of changes to be sensible.
<libv> the most amazing thing though, is the complete and utter lack of testing tools.
<oliv3r> o/
<oliv3r> i have thought about transistion
<oliv3r> 3.10 :p
<oliv3r> but really, 3.10 with backported drivers, and forwardported fex support
<oliv3r> hence, mnemoc's suggestion to do a fex -> dt translator
<oliv3r> 3.10 will have 3.4 drivers (basically all we have now that is not mainlined) with fex support
<hansg> libv, I've read up on the irc log, I assume you referred to the ddc on vga bits? As said most vga connectors on sunxi devices don't have dcc hooked up (unfortunately), good to hear that the ct is a positive exception
<libv> oliv3r: either mripard and others doing dt stuff, have to actively do that work, or it will never work
<oliv3r> i am activily working on it :) but that darned thing called 'time'
<oliv3r> 5 other things i wanna get done first :p
<oliv3r> though 2 are parallel tasks :)
<libv> it needs to be solid, others we get even less device support
<oliv3r> (preparing fosdem/writing a book)
<hansg> libv, anyways. My plans are: 1) finish cleaning up the mmc driver for upstream, 2: dust of arokux usb patches for upstream, 3) start working on kms
<libv> otherwise
<mripard> libv: transition to an obscure thing documented on one wiki somewhere on the internet, to something standard, pretty much documented everywhere, and widely accepted by distributions will probably be a huge pain indeed....
<oliv3r> did those USB patches get ohci support finally? or is it still ehci only?
<hansg> So if you've some working kms code (be it on upstream or on 3.4) it would be great if you could publish it somewhere, and we really ought to coordinate on this.
adb_ has quit [Ping timeout: 252 seconds]
<hansg> oliv3r, ehci only, but adding ohci should be easy
<oliv3r> cool
<mripard> If you want more hardware support, either send me some boards, or do the patches yourself.
<libv> mripard: but look at what you are now making impossible, and what you could gain
<oliv3r> thing is, it'll be a while before the really hard bits will be mainlined like disp etc, and I feel that for those drivers the 3.10 transistion kernel will be curcial
<mripard> I'm not making anything impossible, I'm sorry
<mripard> you'll still have to tell me what is taken away from you.
<libv> mripard: so you really couldn't possibly care less about existing android devices
<libv> mripard: nice to know
<oliv3r> touchscreen support will be iffy either way, especially with blob-only devices
<Turl> libv: there's some android devices supported on mainline (like mele and mini xplus)
<libv> mripard: please spend some time with others on developing a fex to dts translator, it will only be truly useful if you actively work on it too, as otherwise that utility will be constantly broken as new features are added or things change slightly.
<mripard> oliv3r: actually, a script doesn't make more sense. Because you'd need to actively generate a DTS
<mripard> oliv3r: but a board with no DTS ever generated from it won't work
<oliv3r> generating a new board should be trivial with some script/tool; converting an existing one might be trickier
<libv> so it is technically impossible, is what you are saying?
<oliv3r> but if we have to manually translate 2 fex's per month i'd be supprised
<mripard> oliv3r: I think a small "bootloader" taking the fex file to generate the DTS at boot time would be more reasonable.
<oliv3r> not impossible
<hansg> mripard, interesting thought
<oliv3r> i just got that link whispered :p
<oliv3r> a80 with mali?
<mripard> oliv3r: and you can always retrieve the generated dt from /proc/device-tree
<libv> mripard: it should also be possible to pluck things from a running android device, right?
<mripard> libv: my door is always welcome to help someone wishful to work on a solution
<oliv3r> fex file is in ram/nanda
<mripard> but noone ever came to me wanting to do so
<mripard> all I got was criticisms.
<mripard> libv: you'd need access to the boot partition to store it permanently
<oliv3r> we're not that far yet to be fair
<mripard> and afterwards, you'd need a dt-enabled bootloader
<mripard> while this small layer would only "emulate" a fexed-kernel, from the bootloader point of view.
<torbenh3> access to the boot partition.... that would mean nanda support in mainline ? shiver....
<KBme> rellla, did you get the chance to test the kernel as compiled with gcc 4.6?
<Turl> oliv3r: where is it that it says mali?
<mripard> ie, just load the kernel and the fex file, boot it
<oliv3r> git grep ahci_host_priv
<oliv3r> wrong terminal!
<oliv3r> Turl: i was lied to! bad arete74 ! :p
<libv> mripard: from me because i see it as the a) wrong approach (developing things from scratch instead of rewriting - but this is how the open source world works and why i always run into conflicts with people who fail to rewrite gnarly code) b) it takes immediate and direct device bringup away from people
<libv> plaes had his device working in a matter of hours a few weeks ago
<libv> mdfe took just a look at our wiki a year ago and was happy except for the touchscreen (which we never bothered to figure out)
<libv> rwmjones would've had an easier time if he booted sunxi-3.4 first and got his eye in, before moving to mainline
<libv> it's this blind tunnel vision that really worries me, mainline or die
<oliv3r> I don' tthink it'll be mainline or die though
<libv> oliv3r: that's clearly how mripard feels today
<oliv3r> once mainline is in a healthy shape, where it can be easily used, it'll be all good
<libv> oliv3r: but it cannot be easily used unless we have an easy way to get to dt for new devices
<oliv3r> Turl: tinymembench still running in a loop so seems good; I will push it then
<mripard> libv: rwmjones is actually a nice example.
<mripard> libv: if he'd gone for 3.4 in the first place
<mripard> he would have never ever used it
<oliv3r> libv: but that problem we'll hopefully solve with the hybrid transition kernel that will be 3.10 :)
<libv> mripard: he wouldn't have asked some of the RTFM questions he did ask
<mripard> because he was interested in features that have been merged later in Linux.
<libv> mripard: he would've had 3.4 running in an hour
<mripard> libv: yes, probably
<oliv3r> but without KVM
<libv> mripard: and then could've stopped worrying about some of the steps
<oliv3r> and wasn't that one of his requirements?
<mripard> and without what he was looking for.
<libv> mripard: and then probably get to mainline faster
<oliv3r> but stop worryin' ya'll
<oliv3r> you distracting my hackin' :p
<oliv3r> it will be fine, I promise!
<mripard> libv: and honestly, we are all doing this on our spare time
<mripard> we don't have much time to dedicate on this
<mripard> so if I don't force myself into considering only mainline
<mripard> we won't go anywhere with it.
<libv> mripard: sure, but please see that i am really worried about this tunnel vision blindness
<hansg> I've got to go, talk to you all later. libv, please, pretty pretty please publish your kms work somewhere, I know it is not ready and I don't care I promise I won't complain about it :)
<libv> mripard: i am not telling you that you should be the main author of a fex to dts conversion tool, but you must be involved and actively contribute to it
<mripard> libv: I do agree with that
<mripard> all I really want is people actually using what other and I do.
<libv> mripard: that's about enabling them
<libv> mripard: this is why my lima stuff works on any kernel
<oliv3r> for a short term goal
<oliv3r> lets all try to work on something presentable @FOSDEM
<libv> and not just on the tip of mainline, because then no-one will ever actually get to using it
<oliv3r> so we can get more guys interested in contributing (other then just consuming, even though that's fine too)
<libv> it's why my mesa driver builds against 3 different mesa versions
<mripard> we can work on solutions. I guess we already discussed a bit about this today. But you also have to understand that we never ever had a useful discussion.
netlynx has quit [Quit: Ex-Chat]
<mripard> I'm definitely open to discussion
<oliv3r> does that mean 'irc meeting' :p
<oliv3r> quick call aaron :D
<mripard> I'm more than willing to help someone that would come and talk to me
<libv> mripard: well, it's clear in the last few weeks that everyone seems solely focused on mainline and that there is only going to be an increase in activity there while there is less and less support for fully working kernels
<binaryferret> Out of interest, how would someone who's rather new to linux internals but with development experiance begin contributing to linux-sunxi?
<hansg> oliv3r +1 I say lets all get together at FOSDEM, libv you normally do an xorg people dinner at friday evening, so how about a sunxi people dinner at saturday ?
<mripard> but that someone still has to come.
<oliv3r> hansg: i think tsvestan allready proposed that
<libv> hansg: it's not an xorg dinner :)
<libv> hansg: i go to this one place and tell a load of people that i am there :)
<libv> and then a whole crowd turns up
<oliv3r> mripard: o/ hpriv->clk what's the point? What if your platform has 2 clks? can you put two clks there?
<oliv3r> I should probably take the firday off from work to plan it as a travel day :)
<mripard> oliv3r: you can put only 1 clk in there
<Turl> libv: hah
<oliv3r> mripard: so that's useless for platform drivers then
<libv> mripard: so with that reality, the dt thing really becomes a problem, and this is why i am bringing this up now
<hramrach> binaryferret: write some patch and send it to the mailing list :)
<mripard> I don't really know what it's used for though.
<hansg> oliv3r, ah I missed tsvestan proposing that, did he propose saturday evening ? We really should coordinate this, Fosdem is too good of an opportunity for us all to not get together
<mripard> oliv3r: not if your driver only has one clock :)
<hansg> We could also get together Friday during the day, I can be there around 10 am
<oliv3r> mripard: ahci_platform.c uses it for the 2? SoC's it supports
<hramrach> some parts of the kernel are rather high-level and far from hardware, actually. And you get all sorts of error detection in the compiler and at runtime these days
<binaryferret> hramrach: Okdokey. hehe, guess I should keep my eyes open for anything that I have issues with then.
<oliv3r> mripard: but with the case of sunxi, that allready doesn't work, as we have the ahb_sata and sata clks
<mripard> oliv3r: but I think it's something that should be handled by the glue somehow
<oliv3r> mripard: allready did that
<oliv3r> mripard: :)
<oliv3r> just double checking before i rip it out (of ahci_platform.c for now)
<libv> does anyone have a wenku baidu account?
<oliv3r> not I sorry
<mripard> oliv3r: I guess it really depends on what clock you're talking about
<n01> binaryferret: are you familiar with kernel development? if you are willing I have a small driver that requires a bit of debugging (LRADC, it's not working and i dunno why, but I lost interest)
<mripard> I think the struct clk you pointed me to is more for the SATA clock than the AHB one
<rwmjones> libv: mripard: I was running 3.4 for quite a while
<oliv3r> mripard: i do see sata_mv etc use it as such yes
<arokux> hansg: hi :)
<rwmjones> however my aim is to get KVM running, so I need upstream kernels
<rwmjones> in fact I have everything running on my cubietruck now
<mripard> oliv3r: and it might make sense that this sata clock would be modified somehow by the ahci driver
<libv> rwmjones: ah, so you started with 3.4 to get your eye in?
<Turl> libv: try bugmenot.com
<binaryferret> n01: A little, I've been mucking along getting stuff running on a few A13 chinese tablets
<libv> rwmjones: working through the full build and such
<oliv3r> mripard: so there's 3 clocks in the case of sunxi, where the ahci clock isn't setup or changed or accessable in the 'normal' way?
<libv> Turl: whut?
<Turl> libv: for a whatever account
<binaryferret> n01: so been dabbling. I can take a look and have a bash though
<libv> Turl: i would like to dl a datasheet from wenku.baidu.com
<rwmjones> yes
<Turl> libv: try those usernames/passwords
<libv> Turl: aha, cool :)
<oliv3r> mripard: http://lxr.free-electrons.com/source/drivers/ata/ahci_platform.c?a=arm#L133 i see it being invoked here, I'll try to see if I can understand where that clk is coming from
<hansg> arokux, hi, as I stated above I plan to start looking into rebasing your ehci patches on top of the latest malinline + clean them up where necessary to get them ready for upstream submission
<n01> oliv3r: are you writing a book??
<oliv3r> n01: i'm starting yes :)
<arokux> hansg: I would like to do it by myself, if you do not mind
<Turl> oliv3r: about? :)
<Turl> oliv3r: LDD4? :P
<rellla> KBme: i'm compiling with 4.6 atm. but i can test it not until this evening. had to fix my emdebian toolchain, then /arch/arm/mach-sun7i/pm/standby/mem_printk.c
<hansg> arokux, I'll be going offline shortly, so drop me a mail if you've any remarks, and/or plan to start working on this yourself soon
<binaryferret> n01: Excllent, will have a look after work. Cheers.
<oliv3r> Turl: cubieboard (but i'll make it agnostic and prefer lime :p)
<arokux> hansg: ok
<n01> oliv3r: what about? :))
<KBme> pfff
<oliv3r> n01: think raspberry pi for dumimes
<rellla> KBme: now compile runs, let's see.
<KBme> it's so effing difficult to get a gcc going, unbelievable
<Turl> oliv3r: make it a wikibook ;)
<hansg> arokux, ah comments crossed, that is fine, but you've been silent on this for a while, and as I also said above I'm planning on getting sunxi device support in Fedora for F-21, using mainline, so I would like to see it get included into 3.14
<Turl> KBme: o.O
<rellla> mnemoc: what gcc version does sunxi-nightly use?
<KBme> yeah, i'm trying to get gcc-4.6 installed
<n01> oliv3r: gratz :D I'll buy it ;)
<oliv3r> Turl: probably not allowed by the publisher :p
<KBme> Turl, well, gmp, ppl, ppl-cloog, autocrap, …
<KBme> and especially if you want to install it side-by-side, it's a horror
<Turl> KBme: download tarball from linaro/codesorcery, unpack, add to PATH, ..., PROFIT! :)
<arokux> hansg: I see, there should be no time problems.
<KBme> heh
<KBme> hmmmmm
<swabbles> KBme: or use the Gentoo armv7a-hardfloat-linux-gnueabi stage3 tarball.
<KBme> Turl, yeah, i'll just do that.
<rellla> Turl: point me to a 4.6-armhf-tarball, i haven't found...
<KBme> you're right, just to see whether the kernel works better when compiled with gcc 4.6
<oliv3r> rellla: ! how's xbmc :p
<KBme> rellla, I don't think the kernel likes to be compiled with armhf anyways
<rellla> oliv3r: read back! :p stuck with a "oopsy" kernel atm
<oliv3r> ouch :(
<oliv3r> rellla: what kernel?
<hansg> arokux, so we can expect a new version from you soon ?
<swabbles> KBme: sunxi kernel?
<Turl> rellla: there should be some in https://launchpad.net/linaro-toolchain-binaries/+download
<hansg> arokux, and what about ohci support, shall I give that a shot, or ... ?
<KBme> swabbles, yes.
<swabbles> I've compiled it with a armv7a-hardfloat-linux-gnueabi toolchain. Works fine here.
<rellla> KBme: armel or armhf shouldn't matter?!
<KBme> rellla, I think the kernel disables hardfloat, but I'm not good enough to be sure
<rellla> oliv3r: stage/sunxi-3.4 randomly crashes on CT and CB2 when compiled with 4.7, so i'm trying 4.6 now.
<rellla> then let's go on
<arokux> hansg: yes, the problem was nobody was interested in this, so I've done some other things and recently was also busy with completely different stuff. now, that somebody wants to see it in mainline I'll be happy to finish the work. the ohci is very connected with ehci, so I'll do this too.
<hansg> arokux, sounds good, let me know if you need a hand with any of it
<arokux> hansg: thanks, I will!
<KBme> anyone here can confirm that the kernel disables the hardfloat extensions?
<KBme> I mean, the kernel compiles itself with softfloat for arm, whichever toolchain you use
<oliv3r> rellla: if you want, i can compile something for you, just to see if that's stable too;
<Turl> KBme: indeed
<oliv3r> rellla: i do have a kernel with rootfs that you can loop a tinymembench in, not that it'll do anything, but it allows you to test memory stability etc
<KBme> rellla, ^̮^ yay I was right ;)
<oliv3r> KBme: for the kernel (and u-boot) it shouldn't matter though? the kernel doesn't use any floats ...
<Turl> KBme: the kernel is float-free
<KBme> yep, all right.
<KBme> errr, can anyone point me to a binary distribution of the linaro toolchain
<oliv3r> hometime
<rellla> oliv3r: thanks... i've no problems to compile anymore. i've got a working 4.6-arm-linux-gnueabihf toolchain from emdebian here. kernel is ready, later i'll put it on A20...
<rellla> and then cry most likely :p
<rellla> Turl: thanks for the link, i found it already but no 4.6-armhf as i can see on a quick request...
<Turl> there's a point where they stop having the gcc version on the filename
<Turl> I bet one of those is 4.6 :)
<Turl> KBme: see above
<rellla> Turl: it's my evening's quest ;)
<libv> hrm, just saving images atm, that would work if it weren't for the chinese great firewall
<KBme> errr?
<KBme> what should I be seeing?
<KBme> Turl, ?
<rellla> gnueabi seems not to be hardfloat
<Turl> KBme: 12:23 Turl> rellla: there should be some in https://launchpad.net/linaro-toolchain-binaries/+download
<KBme> I don't care, I have a 4.7 hardfloat for my project, this is only for the kernel
<KBme> and for the kernel it doesn't matter
<KBme> Turl, the link I posted should be fine, though, no?
<Turl> KBme: yeah, I guess
<ssvb> oliv3r: tinymembench does not test memory stability, but just various types of misconfiguration affecting performance (that's why some operations are done in several different ways and we can compare them)
hansg has quit [Quit: Leaving]
<ssvb> oliv3r: if it caused a deadlock on unstable system, that was just coincidence :)
<ssvb> oliv3r: it is sensitive to memory timings, dram clock frequency, cache settings, automatic hardware prefetch, and other configuration knobs
<slapin> hi, all!
<slapin> http://www.kano.me - cubieboard-based anyone?
<slapin> mnemoc: ^
<slapin> lkcl: ^
<Turl> slapin: I saw this on the list the other day and thought of your tool http://sprunge.us/IBWY
<Turl> err ssvb ^
<Turl> sorry slapin
<ssvb> Turl: this looks a bit different, because it seems to affect cache flush operations initiated by software and not something that the processor does automatically on its own
<zumbi> finally! cubie3 arrived! is there a pre-built image out-there with best support?
<ssvb> Turl: still it's an interesting patch, because it might speed up migrating the buffers between CPU/GPU, and the things involving the use of DMA
<Turl> zumbi: cubie guys publish some on http://sprunge.us/IBWY
<Turl> fuu
<Turl> zumbi: on http://cubieboard.org/download/ sorry
<zumbi> Turl: ?
<zumbi> ok
<ssvb> Turl: :)
<zumbi> so, android or lubuntu choices
<Turl> zumbi: there's probably more on the wiki and on the cubie mailing list
<zumbi> ok -I'll dig some.. I was just wondering if there was a good known image..
<zumbi> it seems there are plenty of mixes around
<KBme> the android installed on the nand works fine ;)
slopez has joined #linux-sunxi
<ssvb> Turl: however it only affects "Flush the whole D-cache", which probably still has some good use if we want to flush cache for the buffer, which itself has bigger size than L2 cache
<ssvb> Turl: running some benchmarks would be really interesting :)
Fusing has joined #linux-sunxi
<Turl> ssvb: nice material for a post on your blog probably :)
<ssvb> Turl: heh, I have way too much material to write about, but somehow don't have the right mood to do this
<torbenh3> mmmm... this might improve the latency spikes, i am seeing in the pvr driver.
<libv> gah. NC :(
<ssvb> libv: what's up?
<libv> mele a1000 has DDC lines floating.
<libv> hipboi gave me a wenku baidu link with schematics of a board that the mele a1000 seems to be closely related to
<wingrime> libv: whats up with a80?
<wingrime> new news?
<libv> wingrime: why would i know?
<wingrime> who knows
<wingrime> oliv3r: ping
<Turl> wingrime: teclast t97 soon with a80
<libv> once i am done pulling all these images through the gcfw, i should stick them somewhere
<Turl> libv: which imgs?
<wingrime> Turl: nice,
<libv> Turl: 9 lines up.
<hramrach> hmm
<Turl> libv: schematics are on image format?
<hramrach> anyone has some idea about VGA on CT?
<hramrach> because it does not work with the stock fex so either some of the lines in that are wrong or there is something else fishy
<libv> Turl: wenku baidu.
<Turl> libv: I thought it was an scribd-like site
<wingrime> hramrach: andorid worked with VGA for me
<libv> Turl: i do not read chinese, and this seems the only way i can work it
<libv> Turl: i got through to some dling thing... but i couldn't figure it out, i think it wanted some money for the dl
<hramrach> yes, android worked. sunxi kernel did not
<hramrach> yes, I think it does
<hramrach> but is not wb in English as well? I don't read chinese either and it seemed quite obvious to me
<Turl> libv: I think it requires like 'credits' that you get when uploading things
<hramrach> you can read online but that makes working withe the document harder. Like when it's Chinese you can't translate it
paulk-collins has joined #linux-sunxi
rellla has quit [Quit: Nettalk6 - www.ntalk.de]
wingrime has quit [Ping timeout: 272 seconds]
<libv> well, if either of you want to give it a go, i can give you the url in privmsg
jinzo has quit [Ping timeout: 272 seconds]
<libv> nah, i will have to conclude that DDC is simply not wired up.
wolfy has quit [Quit: In viata nu conteaza daca pierzi sau castigi. Conteaza daca pierd sau castig eu... (Winston Churchill)]
rz2k has joined #linux-sunxi
jinzo has joined #linux-sunxi
jinzo has quit [Changing host]
jinzo has joined #linux-sunxi
<libv> so, Mele_A1000 page updated.
<libv> there is no blue connector.
<KBme> Turl, compiling with gcc 4.6 didn't help at all
<KBme> I get the same panic
<KBme> Turl, you interested in what the panic looks like?
adb_ has joined #linux-sunxi
<Turl> KBme: I can take a look if you want
<KBme> well, I used the emdebian gcc 4.6
<KBme> couldn't manage to make the linaro one work
kivutar has quit [Quit: Ex-Chat]
<KBme> Turl, there is the screen shot
<Turl> KBme: init is dying with a 0x200 exit code
* ssvb bought and just received a cubieboard1, it might serve as a better sample of reference Allwinner A10 hardware instead of Mele A2000
<KBme> Turl, err, so you are saying the problem is not with the kernel?
<Turl> KBme: looks more like an issue with your rootfs or ramdisk to me
<KBme> thing is I can mount the ramdisk fine by hand if init exits to an sh
<hramrach> I am using 4.7.2-5 from emdebian and seeing no panics unless I do something that obviously causes them
<Turl> KBme: your init binary does something ugly, I dunno what 0x200 is though
<KBme> it's a script
<KBme> but ok
<Turl> KBme: try booting with init=/bin/sh, does it work?
<hramrach> either way it fails so you need a different init ;-)
<Turl> KBme: can you use scripts as init?
<KBme> yes you can.
<Turl> KBme: is bin/sh on your ramdisk too?
<KBme> yep
<hramrach> if they don't fail and and have script support in kernel
<Turl> with +x?
<KBme> yeah, it runs fine
<KBme> if i give it a paramemter init exits to /bin/sh
<KBme> and i can toy around in the ramdisk
<Turl> maybe you're missing script support? how's that hramrach ?
<KBme> hmmm
<hramrach> it's pretty hard to not have it these days I guess. Don't know the option from the top of my head
<hramrach> would be under binary support
<ssvb> Turl: about memory testing, maybe I should try to make a standalone simple testing tool based on lima and use Mele A2000 as a test subject (it shows memory corruption with dram running at 480MHz when mali is in use)
<hramrach> yes, there actually is CONFIG_BINFMT_SCRIPT
<Turl> KBme: check if your expanded config has that
<KBme> ok
<KBme> there is no such line
<KBme> not with not set, not with =y
<hramrach> that's defconfig, not full config, right?
<KBme> hramrach, so you're saying you're compiling the kernel for cubietruck grom linux-sunxi stage/sunxi-3.4 with gcc 4.7 and it works fine for you? with a linux distro?
<KBme> hramrach, yeah, but that's what I use
<hramrach> yes, it works for me with debian
<Turl> ssvb: ah, nevermind, it's hardcoded enabled on 3.4, the option got added later on
<hramrach> did not build 3.4 for a while but last time I tried it worked
<Turl> err, KBme ^
<Turl> sigh autocomplete :/
<Turl> ssvb: such a tool would be nice
<KBme> yeah
<KBme> the kernel does work, I know that, if init exits to /bin/sh in initramfs it's fine
<KBme> i can mount the partitions and squashfs too
<KBme> this is why I'm puzzled as to why this is happening
<KBme> but ok, if you tell me it's init exiting, i'll try and check what can be wrong
<KBme> mayb simply the binaries are not working and when it switches root it doesn't work
n01 has quit [Ping timeout: 260 seconds]
<KBme> thing is the initramfs binaries are compiled with the same toolchain, same options so I'd be surprised
<KBme> also, rellla has the same problem.
HeHoPMaJIeH has quit [Remote host closed the connection]
<hramrach> I do not do initramfs
<hramrach> do you know anybody who does?
<hramrach> maybe the scripts to pack initramfs forget something crucial on your setup that does not happen on more standard setups
<hramrach> or you are missing a kernel feature the initramfs relies on that nothing lese really requires
<KBme> hramrach, but I can use sh in the initramfs
<hramrach> KBme: did you try turning on debug in the initramfs scripts? iirc passing something like debug=1 to the kernel does that
<KBme> and it works fine
<KBme> hramrach, yeah, but since I have no usb serial my work is really tough
<hramrach> yes, sh works. the script that is linked to /init fails
<hramrach> how did you get the failure message then?
<KBme> it's not linked
<KBme> that's the only thing I get
<hramrach> or copied or w/e
<KBme> I get no output
<hramrach> KBme: I don;t see any screenshot
<KBme> what do you mean?
<hramrach> http://dl.free.fr/dsCTw2aV0 shows some French babble but no picture of a console
<KBme> interesting
<KBme> for me it asks me to download a .jpg
<KBme> let me see, i'll try to put it up to a useful site
nove has joined #linux-sunxi
<KBme> there
<KBme> if you want I can put up a tarball of the project, it has a ./create_sdcard script that you can directly use to create a bootable sdcard for the cubietruck
<KBme> ah well, nvm
<KBme> I have some changes I haven't pushed, some ugly stuff because I've been trying to debug this thing for so long
panda84kde has quit [Quit: Konversation terminated!]
<KBme> so if I could manage this, plus get xbmc to install with cedar support, i'd be pretty well off
<KBme> man I wish I had a serial cable
Quarx has quit []
Tartarus has quit [Quit: ZNC - http://znc.sourceforge.net]
ccube has quit [Remote host closed the connection]
pfdm has joined #linux-sunxi
ccube has joined #linux-sunxi
<hramrach> KBme: did you try debug=1 on the kernel commandline? You can do that with boot.scr without any serial cable
<hramrach> it is an argument for initramfs so should be documented somewhere in initramfs-tools
<hramrach> btw I did manage to install xbmc with Cedar support but I was disappointed by the results. Too many files failed to play. ymmw
printallthething has joined #linux-sunxi
FR^2 has quit [Quit: Connection reset by peer]
Tartarus has joined #linux-sunxi
_massi_ has quit [Quit: Leaving]
Gerwin_J has joined #linux-sunxi
Gerwin_J has quit [Client Quit]
Gerwin_J has joined #linux-sunxi
jinzo has quit [Read error: Operation timed out]
jinzo has joined #linux-sunxi
alleycat has joined #linux-sunxi
n01 has joined #linux-sunxi
n01_ has joined #linux-sunxi
<rings_IIV> libv: I did some of the A1000 header found here http://rhombus-tech.net/allwinner_a10/hacking_the_mele_a1000/
<rings_IIV> I can pull up my notes if you need more details
n01 has quit [Ping timeout: 260 seconds]
n01 has joined #linux-sunxi
n01_ has quit [Quit: leaving]
Night-Shade has joined #linux-sunxi
rellla has joined #linux-sunxi
shineworld has joined #linux-sunxi
nove has quit [Quit: nove]
ZetaNeta has quit [Ping timeout: 246 seconds]
<lkcl> hansg: the eoma68 minidesktop feature board has I2C connected up to the VGA port as well.
alleycat is now known as wolfy
wolfy has quit [Ping timeout: 252 seconds]
fredy has quit [Excess Flood]
n01 has quit [Read error: Connection reset by peer]
n01 has joined #linux-sunxi
fredy has joined #linux-sunxi
<KBme> hramrach, well, i'm only interested in mp4 really
<oliv3r> KBme: but mp4 is a container
Fusing has quit [Ping timeout: 272 seconds]
<oliv3r> and cedarX doesn't care about the container
<oliv3r> what's the codec
lynxis has quit [Remote host closed the connection]
bluse has quit [Remote host closed the connection]
bluse has joined #linux-sunxi
lynxis has joined #linux-sunxi
y0g1 has joined #linux-sunxi
y0g1 has quit [Client Quit]
pfdm has quit [*.net *.split]
y0g1 has joined #linux-sunxi
<jinzo> probably h264? :P
calhemp has joined #linux-sunxi
jinzo has quit [Read error: Connection reset by peer]
<honx> is it correct that /dev/nand does not start at the actual beginning of the NAND memory and that stuff like the bootloaders are located before that, i.e. not accessible via /dev/nand ?
<honx> i'm currently trying to understand the boot sequence and how the documentation in the wiki goes together with the files available for download.
<calhemp> hi people i found this web
<calhemp> that are some allwinner prototype also, I didn't know before
<calhemp> I don't know who is the maker
calhemp has quit [Quit: ChatZilla [Firefox 26.0/20131205075310]]
<Night-Shade> honx: as I understand there is an embedded ROM in the SoC that loads the main boot loader from per set sections of the storage media
<Night-Shade> pre set even
<honx> yes, i understand that part. the BROM is hardcoded in the chip and then loads boot0
<honx> (or u-boot spl)
y0g1 has quit [Quit: WeeChat 0.4.2]
y0g1 has joined #linux-sunxi
<honx> on the sd-card image, i can see the u-bot spl (and its BT0 signature). the nand image however begins directly with the nand partition table, no boot0 signature. still, when i write it to /dev/nand, the brom correctly finds boot0 and starts it.
<honx> so i figure, /dev/nand is actually not the start of the physical nand flash and theres an invisible area before that that contains the nand boot0
y0g1 has quit [Client Quit]
y0g1 has joined #linux-sunxi
<Night-Shade> I've never really looked at the nand, I know that for SD cards the uboot / spl part fit in the 2k at the start of device between the part table and the first partition
<Night-Shade> if you want to confirm read the first 2k out of the nand and then blank them and see if it still works
<honx> thats the point, i overwrote /dev/nand with somethin that does not contain a bootloader and the bootloader still boots. hence my assumption that there is a nand part that is invisible to /dev/nand. i just asked here to confirm my theory..maybe someone knows for sure..
adb_ has quit [Ping timeout: 252 seconds]
FR^2 has joined #linux-sunxi
rellla has quit [Remote host closed the connection]
<oliv3r> honx: that is correct, but you can't really modify nand, only SD booting
<oliv3r> what night-shade said :)
<oliv3r> honx: and what you said is also true
<oliv3r> i see no wrong assumptions i don't think
<honx> what do you mean by "only SD booting"?
y0g1 has quit [Quit: WeeChat 0.4.2]
y0g1 has joined #linux-sunxi
<honx> as far as i understand, i could create a linux-image, flash it to nand and have the existing nand bootloader boot it, correct? i.e. operate the board without any sd card present..
y0g1 has quit [Client Quit]
y0g1 has joined #linux-sunxi
y0g1 has quit [Client Quit]
y0g1 has joined #linux-sunxi
<Night-Shade> could you do that by replacing the kernel with a chainloaded uboot?
notmart has quit [Quit: notmart terminated!]
tzafrir has quit [Ping timeout: 272 seconds]
rz2k has quit []
y0g1 has quit [Quit: WeeChat 0.4.2]
y0g1 has joined #linux-sunxi
<TheSeven> honx: which chip/board?
<TheSeven> most linux images do just that: use allwinner's boot1 to load u-boot (as if it were a linux kernel), and use that to load the actual kernel
<TheSeven> it's certainly doable, at least on most hardware
<honx> olinuxino a20
<TheSeven> honx: that's what I'm working on as well
<TheSeven> in my case I flashed android to it, but linux is no different from that point of view
<honx> any idea if all of nand is available via livesuite?
<Night-Shade> there are some MTD patches floating about that give you the whole nand
<honx> ok.
Black_Horseman has joined #linux-sunxi
Black_Horseman has quit [Changing host]
Black_Horseman has joined #linux-sunxi
<TheSeven> honx: "all of nand" as in what?
<TheSeven> livesuite is basically a way to boot code on the device
<honx> as in "also the part containing boot0 and boot1, and not starting at the partition table like /dev/nand does"
<TheSeven> that code is typically efex, which is a small operating system that's just used for flahing the nand
<TheSeven> there are binaries for efex which update boot0/boot1, so it's accessible in theory
<TheSeven> however I'm not sure what the point of that would be
<TheSeven> if you access it outside of the regular flash translation layer, you'll have to take care of bad block management and wear leveling yourself
<TheSeven> i.e. use a flash file system on it
<TheSeven> but to do that, you first need a bootloader that can actually boot from it
<TheSeven> that requires u-boot with MTD nand and UBI/ubifs support
<TheSeven> which hasn't been implemented yet AFAIK
<honx> its not so much about _modifying_ anything. i'd just like to understand what parts exist and how they work together...
<TheSeven> look at the source code then
<TheSeven> https://github.com/hno/allwinner-boot/tree/lichee-a20-dev contains the interesting bits
<honx> ok :)
<KBme> oliv3r, err let me see
<KBme> oh, I can't check right now. do you know what codecs are supported?
rings_IIV has quit []
<hno> honx, you can't do much nand stuff via livesuit. It's only doing it's own flash programming business (running on the board actually, not within livesuit on your PC).
<hno> honx, there exists code for both Linux and U-boot for accessing the boot0/boot1 area of NAND.
<hno> just not quite in a form that it can be integrated cleanly in the main trees.
<hno> TheSeven ^
wolfy has joined #linux-sunxi
<honx> hno: can you point me to a repo for that extended NAND access code?
<hno> but be warned that the main Linux driver there is for MTD, and still is missing important parts.
<honx> ah, tanks
<hno> making it somewhat unsuitable to use on MLC NAND, or any other MTD structure than UBI.
<hno> should be possible to dissect the boot0/boot1 part out from there however. It is mostly separate from the rest of the NAND driver.
AreaScout has quit []
paulk-collins has quit [Remote host closed the connection]
shineworld has quit [Quit: Leaving]
wolfy has quit [Ping timeout: 252 seconds]
n01 has quit [Ping timeout: 265 seconds]
ganbold_ has quit [Remote host closed the connection]
Gerwin_J has quit [Quit: Gerwin_J]
FR^2 has quit [Quit: und weg...]
Sonic1_ has joined #linux-sunxi
Night-Shade has quit [Ping timeout: 272 seconds]