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 0.9.90.1 [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>
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
<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!
<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
<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
<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]
<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.
<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
<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
<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>
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
<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: 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
<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
<Turl>
CONFIG_BINFMT_SCRIPT maybe?
<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>
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
<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>
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 0.9.90.1 [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...
<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?