hno changed the topic of #linux-sunxi to: Allwinner/sunxi development discussion - Don't ask to ask. Just ask! - See | | Logs at
mturquette has quit [Ping timeout: 248 seconds]
mturquette has joined #linux-sunxi
rz2k has quit []
philhug has quit [Quit: Changing server]
BJfreeman has quit [Read error: Connection reset by peer]
piyushverma has joined #linux-sunxi
piyushverma has quit [Ping timeout: 246 seconds]
piyushverma has joined #linux-sunxi
piyushverma has quit [Read error: Connection reset by peer]
piyushverma has joined #linux-sunxi
piyushverma has quit [Read error: Connection reset by peer]
TheSeven has quit [Disconnected by services]
[7] has joined #linux-sunxi
wingrime has joined #linux-sunxi
hamburger2000 has joined #linux-sunxi
hamburger2000 has quit [Max SendQ exceeded]
hamburger2000 has joined #linux-sunxi
hamburger2000 has quit [Max SendQ exceeded]
tinti_ has quit [Ping timeout: 256 seconds]
hamburger2000 has joined #linux-sunxi
hamburger2000 has quit [Max SendQ exceeded]
_BJfreeman has joined #linux-sunxi
_BJfreeman is now known as BJfreeman
BJfreeman has quit [Quit: had a good time]
mturquette has quit [Changing host]
mturquette has joined #linux-sunxi
wingrime has quit [Ping timeout: 252 seconds]
wingrime has joined #linux-sunxi
wingrime has quit [Ping timeout: 246 seconds]
\\Mr_C\\ has quit []
wingrime has joined #linux-sunxi
eebrah has quit [Ping timeout: 241 seconds]
n01|away is now known as n01
gzamboni has joined #linux-sunxi
stekern has quit [Read error: Operation timed out]
stekern has joined #linux-sunxi
gzamboni has quit [Remote host closed the connection]
gzamboni has joined #linux-sunxi
<oliv3r> Turl: ping
n01 has quit [Read error: Operation timed out]
Quarx has joined #linux-sunxi
gzamboni has quit [Read error: Connection reset by peer]
n01 has joined #linux-sunxi
<oliv3r> mnemoc: ping! where are you!
<oliv3r> or anybody for that matter
<n01> \0
eebrah|away is now known as eebrah
notmart has joined #linux-sunxi
notmart has quit [Changing host]
notmart has joined #linux-sunxi
<wingrime> ask
<wingrime> mnemoc: have we night builds in ?
eebrah is now known as eebrah|away
n01 has quit [Ping timeout: 256 seconds]
<oliv3r> wingrime: we used to
<oliv3r> last compile was 28th of april
<oliv3r> possibly last time there was a commit
<oliv3r> mnemoc you slacker!
<wingrime> oliv3r: a just ask ad a13_mid
<wingrime> *add
<rm> here are some from 23 May
eebrah|away is now known as eebrah
<wingrime> rm: I still want normal nightes
<wingrime> "latest"
<wingrime> such typo
<wingrime> sudo:x:27:amery,techn,hno,turl,oliver
vicenteH has joined #linux-sunxi
<oliv3r> i don't think anything is actually built on
<oliv3r> i belive mnemoc has a different built box
<oliv3r> but yeah, daily builds on change is good
<wingrime> oliv3r: "on change"
<wingrime> we can make bisect
<wingrime> oliver: could you send patch that enables PM in config
<wingrime> for a13
<wingrime> it still have no PM and cpu freq
<wingrime> in default
gzamboni has joined #linux-sunxi
<oliv3r> wingrime: hramrach_ is doing the default config patches
<oliv3r> but mnemoc won't merge my patch until hramrach's patch is in
<oliv3r> and those patches keep evolving
<wingrime> oliv3r: I upload some tools
<wingrime> cedar2.c can read cedar register and do right IOCTL before
<oliv3r> oh very neat
<wingrime> but it so cedar reset every time it called
<wingrime> so use cedar2.c for first
<wingrime> it leave cedarx on
<wingrime> than use devmem2.c
<oliv3r> hno: YOu say you need sodlering iron, wire and a scalpel. Is it to break the trace between R24's two pads? r23 and r24 are not solderd, r24 has the coppy going between it, shorttening it; r23 is unpopulated
<oliv3r> ok so we can also do cedar2x on; write registers for idct, read result, check data?
<oliv3r> hno: also, one of the r23 pads connects to 2.5V
<wingrime> yes
<wingrime> oliv3r: but it better if you extend cedar2.c to make it jpeg Poc
<oliv3r> maybe use cedar2c yeah
<oliv3r> but i want to use pure and 'hack in' jpeg poc
<oliv3r> since allwinner also uses libjpeg; makes it much easier/logical
<oliv3r> but i want to start by ONLY doing idct
<oliv3r> idct only is easy and can be followed
<oliv3r> hno: from the pcb it looks like it's 2.5V -> R23.1 - R23.2 -> R24.1 -> R24.2 -> GND
<oliv3r> with - meaning open
<oliv3r> so don't see T9 going anywhere, but my eyes are tired :p
<wingrime> oliv3r: just include lib jpg
<wingrime> oliv3r: i realy have no real example only for idct
<wingrime> oliv3r: it do whole jpeg
<oliv3r> bah
<oliv3r> but i'm sure it's possible by the register names
<oliv3r> i cannot imagine that cedar dus a full frame jpeg
<oliv3r> or full macroblok(s)
tzafrir has quit [Ping timeout: 246 seconds]
<wingrime> oliv3r: "JPEG Decoding process" in
<wingrime> you just need configure , copy data and press "START"
<oliv3r> lol
<oliv3r> yeah
<oliv3r> and for a start, that's awesome
<oliv3r> aand I should write that soon :)
<oliv3r> but
<oliv3r> sec
<wingrime> yes . but Mpeg engine clock init / reset still not in wiki
<oliv3r> anyway, if we have idct only support
<oliv3r> we can write generic fft using idct if i'm not mistaken
<oliv3r> if we have generic fft, we can offload audio decoding too :)
<wingrime> oliv3r: idct only can be done in 200 cup cycles , onlt it will have small impact
<oliv3r> yeah but it's only as a PoC :)
<oliv3r> and then there's context switches etc etc, so even offloading that is still nice :p
<wingrime> olvi3r: I still have no Idea how do idct only (register bits)
n01 has joined #linux-sunxi
piyushverma has joined #linux-sunxi
piyushverma has quit [Ping timeout: 246 seconds]
<oliv3r> wingrime: i'll try to find time to do full jpeg PoC
<wingrime> oliv3r: can you upload you trace to cedarx-traces
<wingrime> for mjpeg
<wingrime> and mark it as a10
<wingrime> if can do it on a20
<wingrime> add a20 trace too
<oliv3r> wingrime: we have a jpeg trace
<oliv3r> the other guy made it
<oliv3r> i haven't been able to make or replay a trace yet
<wingrime> oliv3r: you upladed to cedar-trace only mjpeg file , nor trace itself
piyushverma has joined #linux-sunxi
leowt has joined #linux-sunxi
<leowt> hno: it is the memory =P
<hno> oliv3r, yes, the scalepl is for breaking R24, and the wire is for making a 0R resistor on R23.
<hno> R35 (next to R23) is also interesting. That's JTAG_SEL.
<hno> leowt, your speed problems?
<leowt> hno: yep
<leowt> MemFree: 2592 kB
<leowt> doesnt help much
<leowt> xD
<leowt> MemTotal: 362044 kB
tzafrir has joined #linux-sunxi
<oliv3r> ssvb_: funny to see you on phornonix :)
<oliv3r> leowt: that's more then i have, i think mine is at 315 M normally
<oliv3r> leowt: but memfree is of course before caches
<ssvb_> oliv3r: :)
<leowt> oliv3r, anyways i am good to see that it is not a 2d acell problem
<oliv3r> and yeah that was me :p but i'm sure you guessed it
<leowt> =)
<oliv3r> leowt: the big advantage with 1G is, that you only have to substract the video memory once; so you actually really get 512 additional mb
<oliv3r> so you'll end up with 700 or 800 free MB which is plenty
<oliv3r> 300 MB is just very tight
<leowt> yep
<leowt> i can see that
<leowt> by the way
<leowt> is allwinner getting friendly over the work being done over their abandoned kernels?
<leowt> how is that relationship?
<oliv3r> that specific one, very bad :0
<oliv3r> we've done a lot of work on 3.0 and 3.4 kernels
<oliv3r> tehy didn't use those, they simply continued with their own kernels
<leowt> or not using at all
<leowt> xD
<leowt> u just dont understand
<leowt> * i just
tinti_ has joined #linux-sunxi
<leowt> so much dirty work was fixed
<oliv3r> not using at all; not even patches that fixes horrid bugs
<leowt> they would only gain
<oliv3r> on the upside, we now have a20 hardware slowly getting into develoeprs hands
<oliv3r> so we can backport/merge new drivers
<leowt> and the vendor relation continues to be the same?
<leowt> it seems like rockchip is about to take a more friendly approach
<leowt> well, i mean legal approach
<leowt> xD
<oliv3r> leowt: how so?
<oliv3r> does it have an unsigned bootloader?
<leowt> dunno yet
<oliv3r> full GPL sources?
<oliv3r> GPL video decoder?
<leowt> but i would only ask for sources
<leowt> even with blobs
<leowt> like the other vendors
<oliv3r> we only currently have 2 blobs with allwinner; mali (duh) cedarx userspace
<leowt> yeah but we still have to wait until someone release the source
<leowt> and a unmaintained one
<oliv3r> leowt: allwinner has released source
<oliv3r> they gave us their git tree
<oliv3r> what more could you want?
<oliv3r> all gpl licensed
<leowt> wen?
<leowt> when?
<oliv3r> so technically; they are quite compliant
<hno> Allwinner frequently releases full kernel + u-boot sources.
<oliv3r> a few months ago, march 2nd or so
<hno> we have A20 sources later than that.
<oliv3r> it's up on amery's github under the import/lichee-3.3/ bits
<oliv3r> and that!
<leowt> because i remember the times
<leowt> that i was here
<leowt> a10
<leowt> there was no official sources
<oliv3r> the only 'better' thing that could happen with that regard, is give is git fetch access :) (read-only)
<hno> Allwinner released A10 kernel + u-boot sources before this channel existed.
<leowt> hmm
<leowt> so i was confused than
<leowt> *then
<oliv3r> Turl: anti-pattern! andy responded what it is, it's instead of: if (statement); if (!statement) (see his respons for details
<lioka> wrt 8192cu: sunxi-v3.4.43-r0 contains v3.3.2_3192.20120103 version, although v3.4.4_4749.20121105 is available
<lioka> is there anyplans to update things ?
<oliv3r> those look really old
<oliv3r> oh 8192cu
<oliv3r> erm, what's upstream status for it?
<oliv3r> does upstream have full 8192cu sources?
<oliv3r> if so, backport them and submit them to the ML; mnemoc will happily merge them
<lioka> oliv3r: by upstream you mean ?
<oliv3r> vanilla linus 3.11 kernel
<oliv3r> Turl: ping
<rm> upstream is rtl8192cu
<lioka> oliv3r: it is full-sized rtlwifi there, i doubt it is doable honestly
<rm> linux-sunxi has both rtl8192cu and 8192cu
paulk-desktop has joined #linux-sunxi
<rm> the latter is directly from Realtek, I assume
<oliv3r> lioka: well feel free to submit a patch porting the newest 8192cu to 3.4 for us
<oliv3r> rm: i would agree
<lioka> rm: yes, i mean RTL8192CU_SW
<oliv3r> so lioka i would suggest trying rtl8192cu :)
<lioka> oliv3r: tried on hackberry, doesn't seem to work. 8192cu otoh works, but now i've got another pad with rtl8188, and things went really bad
<lioka> as for patching newest realtek sources to sunxi-3.4 -- there are some sunxi-related tweaks, it seems
<rm> sooo you want someone else to dig into that mess
<rm> the plan is to abandon 8192cu completely
<rm> if it works for you, then just be happy
<rm> that it is not removed yet
<rm> no use chasing the latest version just for the sake of it
<oliv3r> the quicker you can use the vanila version, the sooner
<oliv3r> the better*
<lioka> i see. well, that's what i want to know
<oliv3r> if ours is to old, you can try backporting it
jemk has joined #linux-sunxi
<lioka> yep. may i suggest, that there is no sunxi-specific other than script_parser_fetch("usb_wifi_para", ... or sw_usb_enable|disable ... -- that sort of stuff ?
<lioka> s,suggest,assume, sorry
<oliv3r> yeah, all drivers need that hacked in
<oliv3r> until we move to sunxi-next
<oliv3r> which will be devicetree dependany
n01 has quit [Ping timeout: 255 seconds]
leowt has quit [Quit: leowt]
<Turl> lioka: I updated the realtek one some time ago, sec
<Turl> oliv3r: pong
<oliv3r> Turl: i love irssinotifier :)
<Turl> oliv3r: :)
<lioka> Turl: thanks, that's useful
<oliv3r> Turl: anyway, andy explained antipattern and what he ment
<oliv3r> but tbh; part of his review (while he addressed very valid points) was a little bit nitpicking imo
<oliv3r> here
<Turl> yeah I was reading it on tb :)
<oliv3r> :p
<oliv3r> so nitpicking?
<oliv3r> :)
sud0x3 has joined #linux-sunxi
rz2k has joined #linux-sunxi
vicenteH has quit [Ping timeout: 248 seconds]
sud0x3 has quit [Read error: Connection reset by peer]
n01 has joined #linux-sunxi
<Turl> oliv3r: well, the smallest a patch is, the more it looks like nitpicking :p
<hno> lioka, which rtl8188? 8188cus and rtl8188eu requires different drivers.
<oliv3r> Turl: true true, but should i change those things (again)? i kinda disagree :p
leowt has joined #linux-sunxi
<Turl> well, not having huge hunks inside an if certainly helps readability
leowt has quit [Client Quit]
<oliv3r> well
<Turl> it's esp. important on big functions :p
<oliv3r> obviously yyeah
<hno> rm, I have never got the vanilla driver to work reliably with the rtl8188cus, annoys me greatly. Backported rtlwifi from upstream but still no joy (but a bit better).
<oliv3r> Turl: ok in that context, i 100% agree
<oliv3r> well, i would do goto exit: :p
<oliv3r> but yeah; absolutly
<oliv3r> and in probe we do that
<oliv3r> this is how i want to submit it now with all comments in
<oliv3r> is it worth it to use antipasta on that
<oliv3r> antipattern*
\\Mr_C\\ has joined #linux-sunxi
<hramrach_> wingrime: try testing the a13 defconfig if you have time
<mripard_> oliv3r: you still have that p_sid_reg_base thing.
<oliv3r> mripard_: yeah, the only way to get rid of it, is to use it as a parameter to sunxi_read, which i kinda want to avoid
<mripard_> silently ignoring comments is pretty rude, especially when you are on the wrong side of the patch
<Turl> oliv3r: it does look neater don't you think?
<mripard_> oliv3r: you had everything needed in v1 to do so
<mripard_> or at least, reply to people that tell you this
<mripard_> because I did, twice, now on your v2, russell told you so
<mripard_> and *everytime*, you simply ignored us
<mripard_> and sent a new version of this patch, with still the same global pointer
<hno> Turl, the if condition has two major bugs. One new.
<oliv3r> mripard_: actually, I've allready added a comment why this is needed
<mripard_> but the point is, it's *not* needed.
<mripard_> in the current code at least
<oliv3r> mripard_: ok i'll change it to be not required and pass it as var along
<Turl> I don't see the other issue, at least not looking just at that function
leowt has joined #linux-sunxi
<Turl> oliv3r: the thingis, you're not exporting it today. so it's like overengineering :) if you ever need to export it you can add the pointer
<Turl> thing is*
<oliv3r> Turl: yeah i went with mripards version! :p
<oliv3r> you people just don't like german cars do you :p
<mripard_> oliv3r: the point I was trying to make was not a technical one actually. On a general basis, when you feel that the way the comment goes is not the one you want, say it
<oliv3r> german overengineering!
<mripard_> don't discard it
<oliv3r> mripard_: sorry :(
<oliv3r> mripard_: you are right of course
<mripard_> it just pisses off people for nothing, while we could have a nice discussion about this part
<mripard_> and actually agree :)
<oliv3r> yeah, but i'm just this little dev in the land of the giants
<mripard_> Most of the time, it doesn't matter
<mripard_> as long as you ask for explanations
<oliv3r> yeah but when you feel insignificant, you only look up :)
<mripard_> everyone has to start at some point :)
<hramrach_> stand on a piece of furniture ;-)
<oliv3r> lol
<Turl> hramrach_: hahah
<oliv3r> mripard_: i don't find rullel commenting specifically on the global far, only that it was non-static at some point accidentally
<hno> Turl, look at offset.
<oliv3r> where I did reply it wasn't supposed to be static
<oliv3r> offset <= SID_SIZE
<hno> Yes. What values can offset have?
<oliv3r> 0 - SID_SIZE
<hno> No, what values can offset have?
<hno> not which values are valid.
<lioka> hno: 8188cus
<mripard_> oliv3r: "
<mripard_> So what happens if you have two of these devices?"
<oliv3r> mripard_: ah yeah, i completly forgot about that, not ignored!
<Turl> hno: ~ -MAX_INT/2 - MAX_INT/2? or does the const play tricks on us?
<hno> const does not matter.
<oliv3r> hmm, very good point, I do the size > 0 and offset < SID_SIZE on line 78 in the sysfs read function, but if you do it 'internally' you can poke anything in there
<oliv3r> so you could have negative numbers there indeed
<Turl> hno: should be unsigned int right? so <0 does not happen
<hno> unsigned int is easier to deal with yes.
<Turl> also would prevent funny values when >>
<hno> oliv3r, the other if is also botched. if (likely(size > 0) && ((size + pos) <= SID_SIZE)) {
<Turl> nvm my last comment
<oliv3r> pos could be negative
<Turl> sid_key is unsigned already
<hramrach_> hehe, picking apart a poor driver
<oliv3r> yeah but you only ioread into that
<oliv3r> hno: so the proper thing is to put guards in both places then
<Turl> oliv3r: or just make it unsigned :) guaranteed it'll never be negative
<oliv3r> Turl: allready done :p
leowt has quit [Quit: leowt]
<hramrach_> you need jdk 1.6 for android build? the reals thing? not openjdk, not 1.7? /o\
<Turl> hramrach_: openjdk works just fine
<Turl> that's the buildsystem bitching only :)
<hramrach_> 1.6 or 1.7?
<oliv3r> Turl: to come back to your question, is it not nicer to have that antipattern there; I think i prefer in this case the 'pattern' there. Only run do_something(); when you are within your parameters
<oliv3r> Turl: you say 'in this confeined space are you only allowed to do something'
<Turl> hramrach_: I think I'm using 1.7 atm, pretty sure .6 works too
<hramrach_> 1.6 is *old*
<oliv3r> Turl: whereas the other way around you say, 'you fail if you don't, otherwise, do what you want'
<hramrach_> but I would not be surprised if you required something that was current at the time ICS was developed
<hramrach_> the matson-hall repo is correct or is there one more recent one?
<Turl> oliv3r: if you ever worked with specification, theorems and that kind of stuff, the antipattern looks more like a precondition
<hno> oliv3r, I would drop the sid_read_byte function, it's only 2 lines if ignoring the double conditions..
<Turl> hramrach_: if you're building ics you'll probably need openjdk6
<hramrach_> it says to build ics on the Android guide
<hramrach_> I don't really care what version comes out as long as it's bootable
<oliv3r> hno: well the idea was that you can export the read function so you can call it elsewhere, use it as Key or MAC for example (if not 0) or an eeprom framework even
<hno> Ok. Yes then it's needed. And likewise the static pointer.
<oliv3r> I added a comment clarifying the global pointer
<oliv3r> * To have sunxi_sid_read_byte not depend on any other parameters we keep a
<oliv3r> * pointer here. This allows sunxi_sid_read_byte to be exported if needed.
vicenteH has joined #linux-sunxi
<hno> oliv3r, what about this:
<hno> Err.. should be >=
<mripard_> oliv3r: still, you don't export that function in your patch
<hno> and C uses |, not ||... should go to bed.
<hno> Or.. brain not fully functional.
<oliv3r> hno: how is your cold
<oliv3r> mripard_: so just don't write it for whats to come; and patch it in later is what your saying
<hno> || is correct.
<hno> oliv3r, better but giving me a bad headache today.
<hramrach_> or even make a separate patch that adds the export and uses it in wemac
<oliv3r> hno: yep it is
<oliv3r> hno: drink some hot tea, go to sleep
<oliv3r> hramrach_: well you want it in a generic way, so that it works with any driver I guess
<oliv3r> hramrach_: i mean, we can't rewrite all drivers to use sunxi_sid_read_byte() :) i'm sure the e1000 guys won't approve :p
leowt has joined #linux-sunxi
<hramrach_> e1000 does not need it. it has on-board eeprom
<oliv3r> hramrach_: ok, random_nick_without_eeprom()
<mripard_> hramrach_: yet, his point is valid
<mripard_> the a10s-olinuxino stores the mac in an at24
<mripard_> and not the sid
<oliv3r> mripard_: on your suggestion; i'll rip it out and we can always patch it back in later
<oliv3r> when your eeprom framework is useable :)
<oliv3r> hno: i think i like your approach better; mine fails as soon you supplier wrong parameters, yours tries to fullfill until it no longer can't
<oliv3r> the a20-olinuxio-micro has a at24 near the rtl; so its likly it does that too
<hramrach_> also you don't get random_nic_without_eeprom on sunxi. only wemac
<oliv3r> hramrach_: my a20 has an atmel at24
<oliv3r> the board is made for a10's so in theory, it can have an a10
<oliv3r> the mac is stored in the at24
<oliv3r> so here I have a emac + !sid
<oliv3r> :)
<mripard_> yeah, and why not some other random board using an AT25 at some point
<hramrach_> yes, there should be probably a DT entry that associates the mac with some random eeprom on the board or the sid
<mripard_> hramrach_: yeah, precisely what I had in mind as well :)
<Turl> hramrach_: or uboot can take care of wherever the mac is and feed it as a string on dt :)
<oliv3r> mripard_: how is your eeprom framework coming along?
<mripard_> Turl: yeah, that's another approach
<Turl> mripard_: I've seen >1 patches using mac address as a dt prop
<mripard_> but we like to be as independant as possible of a given bootloader
<oliv3r> still, it would have been nice it the driver was atleast somewhat future proof :(
<mripard_> Turl: yes, local-mac-address
<mripard_> it's a "standard" dt property
<mripard_> and usually, yeah, the bootloader patches the device tree at runtime to fill this property
<hno> Turl, u-boot don't like hunting down MAC addresses very much..
<Turl> there's an of_set_mac_address even :p
<Turl> hno: how does uboot get a mac for eg. tftp?
<hramrach_> plus the kernel can read the eeprom and sid all right so no need for u-boot to do it
<mripard_> hno: I don't know much about about u-boot, but at least two architectures do that already
<hno> Turl, you set one.
<hramrach_> it might possibly have code for reading the sid but unless netbooting is implemented reading random roms in u-boot is superfluous
<Turl> hramrach_: we have netboot since like last year
<hno> hramrach_, netboot is there..
<hramrach_> u-boot can netboot?
<Turl> hramrach_: yes
<hno> yes.
<hramrach_> cool
<Turl> I use it to develop and test directly
<hramrach_> which branches?
<Turl> I set it up long time ago and already forgot what the env looked like
<hramrach_> -current only or sunxi as well?
<hramrach_> well, if we do have netbooting then setting the mac in u-boot kind of makes sense. it needs to be able to figure it out anyway
<hno> U-boot stand on MAC addresses:
<hno> - board-specific location (eeprom, dedicated flash, ...)
<hno> Note: only used when mandatory due to hardware design etc...
<hramrach_> it's mandatory due to hardware design :/
<hno> - environment ("ethaddr", "eth1addr", ...) (see CONFIG_ETHADDR)
<hno> Note: this is the preferred way to permanently store MAC addresses
<hno> But will likely add something for the A20 OLinuXino, it actually have a real MAC address EEPROM. But the I2C driver needs to be improved a bit first.
<mripard_> ho, about the i2c
<mripard_> it's the same controller than the one used in the marvell chips
<oliv3r> mripard_: have you confirmed this allready?
<mripard_> only with a slightly different register layout
<mripard_> oliv3r: yep
<oliv3r> cool
<oliv3r> will you merge them or merge them later?
<oliv3r> never saw the answer to your qquestion
<mripard_> I don't know, I'm waiting for Wolfram answer
<hno> mripard_, I know they are similar. But learnt it after the driver was written.
<mripard_> same thing here
<bfree> Complete build of working 3.10 Debian package with EMAC from net-next is now up at It supports nbdroot anyway. / on nfs should also be fine but I didn't test it. armmp is the kernel flavour for sunxi.
<hno> and iirc there is some other small differences, not only register offsets.
<mripard_> I didn't catch any
<hno> oliv3r, file I/O is expected to return what is possible. Not reject all if you try to read more.
<oliv3r> hno: yeah i allready changed it to your suggestion, it's much better
n01 has quit [Ping timeout: 256 seconds]
leowt has quit [Quit: leowt]
<hno> mripard_, looked again, and differ in register offsets, clocking and the sunxi have some more functions (none used)
<Turl> bfree: great :) thanks
<bfree> Turl: well thank you for discovering how I could confirm it really works ;)
<mripard_> hno: yeah, the enhanced feature thing
<mripard_> the newer versions of the marvell controller have some kind of extensions to have a saner behaviour and not get an interrupt each time you have to do something
<mripard_> also
<mripard_> maybe the two are related, I'd need to look closer on this.
<mripard_> what clocking changes are there?
<mripard_> when I looked at it, the clock computation function looked like what was documented into the allwinner datasheet
jemk has quit [Read error: Operation timed out]
<hramrach_> hmm, there seems to be jb-cubieboard branch but repo init refuses to use it
leowt has joined #linux-sunxi
hansg has joined #linux-sunxi
hansg has quit [Client Quit]
piyushverma has quit [Ping timeout: 256 seconds]
piyushverma has joined #linux-sunxi
wingrime has quit [Ping timeout: 276 seconds]
wingrime has joined #linux-sunxi
tinti_ has quit [Ping timeout: 260 seconds]
leowt has quit [Quit: leowt]
jemk has joined #linux-sunxi
<hramrach_> the jb repo is somehow broken
tinti_ has joined #linux-sunxi
tinti_ has quit [Ping timeout: 240 seconds]
<lioka> 87 files changed, 19294 insertions(+), 42449 deletions(-)
<lioka> duh
<hramrach_> hmm, interesting
<hramrach_> thanks
eebrah is now known as eebrah|away
<hno> eft and lctl do not seem to exist in marvell orion/kirkwood. I do use lctl to check bus status.
<hno> mripard_^
<hno> lioka, ?
<lioka> hno: stats from rtl8192cu update
<lioka> half of them whitespaces of course
<mripard_> hno: ah, what are you using it for?
<hramrach_> bus status :p
<hramrach_> hmm, ok
<hramrach_> small percentage of repos down translates to inability to build android I guess
<mripard_> hramrach_: yeah, but I mean, there's already some bus error notification in the interrupt status
<jemk> wingrime, jpeg decoding with cedar:
<hramrach_> nice :) libjpeg-turbo-hyper ;-)
<jemk> its far away from an real libjpeg replacement, but its poc
<ssvb_> jemk: looks great, thanks
leowt has joined #linux-sunxi
<ssvb_> jemk: can you try to document it on the wiki?
_BJfreeman has joined #linux-sunxi
_BJfreeman is now known as BJfreeman
<ssvb_> jemk: I mean the things that are done in set_quantization_tables(), set_huffman_tables(), etc.
<jemk> i'll try, but especially these things are hard to explain
<ssvb_> thanks!
<ssvb_> the purpose of the hardware registers, the valid range of input data and corner cases cedarx can accept, the way how these registers are linked to the data structures described in jpeg spec, ...
<ssvb_> jpeg is a rather simple, so it can be used for practice before moving to more difficult codecs
<jemk> valid ranges corner cases, good question, i dont really know yet
<ssvb_> I believe these can be tried with specifically crafted input files
<ssvb_> I tried to play around with at least jpeg idct implementations for fun some time ago -
tinti has quit [Quit: Leaving]
<Turl> lioka: the one on linux-sunxi is 'sanitized' I think
tinti has joined #linux-sunxi
<Turl> lioka: you can diff with -w
<ssvb_> jemk: it does not mean that you should do really extreme experiments, but we preferably would want to know whether cedarx can deal with the common jpeg bitstream variants used in the wild
<ssvb_> btw, is arithmetic coding not supported at all?
tinti has quit [Remote host closed the connection]
<jemk> progressive didn't work
<hno> mripard_, to verify that the I2C bus is idle.
<jemk> i didn't test arithmetic coding
tinti has joined #linux-sunxi
<jemk> as said, its only first proof of concept
<ssvb_> yeah, it is a really great milestone (after a working cedarx tracer), I just wondered about what are your next plans
<hno> mripard_, but looking at that code again I do not think it works....
<mripard_> hno: which code?
<mripard_> the mv64xxx one?
<mripard_> I have some patches here that ran and i2cdetect/i2cdump successfully yesterday
<mripard_> I don't have my logical analyzer here however
<mripard_> so it need to be confirmed
<mripard_> but it looks ok
<hramrach_> maybe the code to check bus status
zumbi_ has joined #linux-sunxi
zumbi_ is now known as Guest99492
<hramrach_> hmm, gihub is suposed to be online but android still does not sync
jemk_ has joined #linux-sunxi
<hramrach_> maybe they hav a download limit? the andriod stuff is large and seems to be fetched fully again when re-synced
piyushverma has quit [Ping timeout: 246 seconds]
zumbi has quit [Ping timeout: 246 seconds]
jemk has quit [Ping timeout: 246 seconds]
jemk_ is now known as jemk
n01 has joined #linux-sunxi
<ssvb_> jemk: sorry for pestering you, I'm just too excited and the first fully open source proof of concept hw accelerated jpeg decoder is a really great news
* ssvb_ shuts up
<hno> mripard_, my code using lctl
drachensun has quit [Quit: Leaving]
<jemk> ssvb, np, ill do more when i have time, but i have to do other things too
<Turl> ssvb_: that reminds me I need to post my SS proof of concept tools :p
drachensun has joined #linux-sunxi
<Turl> ssvb_: :)
<ssvb_> Turl: thanks :)
<ssvb_> just wonder, why not github?
<Turl> ssvb_: because it does not go down so often :)
<ssvb_> :)
<Turl> ssvb_: also, free private repos :p
<Turl> I use it to version university projects and other miscellaneous things
n01 is now known as n01|away
bsdfox\ is now known as bsdfox
bsdfox has quit [Changing host]
bsdfox has joined #linux-sunxi
bsdfox is now known as bsdfox\
<oliv3r> jemk: well done!
_BJfreeman has joined #linux-sunxi
<hramrach_> does anybody know a version of netcat that can really listen?
BJfreeman has quit [Read error: Connection reset by peer]
<Turl> hramrach_: can't all of them do?
<hramrach_> like when the connection ends it does another accept()
<Turl> hramrach_: while(1) nc...? :P
_BJfreeman is now known as BJfreeman
<hramrach_> I guess I really want tcpd
<oliv3r> jemk: you did everything in user space, only used the driver's ioctl's to setup the engine?
<hramrach_> but running tcpd as user does not work and runnig the command as root does not work
<hramrach_> unix :/
<hramrach_> maybe crafting special tcpd config
lioka has quit [Quit: leaving]
<hramrach_> no, tcpd insists on config in /etc
<hramrach_> bah
<hramrach_> so special tcpd build in prefix
<jemk> oliv3r: yes, i use the original kernel driver, only wanted to test if it works, not to develop a full replacement
<oliv3r> jemk: yeah of course, but job well done
<Turl> hramrach_: what port? if <1024 you need root
<oliv3r> Turl: if my probe function fails only at the last step; do I have to call '.remove();' somehow?
<Turl> oliv3r: as long as you return your probe with an error you should be ok I think
<oliv3r> ah, ok good
<Turl> (and assuming you use devm_ things and the like)
<oliv3r> platform_ and devm_ yeah
leowt has quit [Quit: leowt]
eebrah has joined #linux-sunxi
eebrah has quit [Client Quit]
BJfreeman has quit [Read error: Connection reset by peer]
_BJfreeman has joined #linux-sunxi
_BJfreeman is now known as BJfreeman
mdp has quit [Ping timeout: 256 seconds]
Quarx has quit []
n01 has joined #linux-sunxi
mdp has joined #linux-sunxi
n01 has quit [Remote host closed the connection]
mdp has quit [Ping timeout: 255 seconds]
mdp has joined #linux-sunxi
<rz2k> slapin_n1: hno: i *might* have a success with olinuxino nand and mtd
<rz2k> my mtd partitions just survived ext4 format, dd if=/dev/urandom of=img.img and reboot
<rz2k> and it didnt stuck on ECC as it was before
<rz2k> now testing ubi
n01_ has joined #linux-sunxi
rellla has joined #linux-sunxi
leowt has joined #linux-sunxi
<leowt> do contain the stuff needed to build android for a13?
<rz2k> ping Turl for that question
<leowt> rz2k: tnks, gotta go now, but will be back soon
leowt has quit [Quit: leowt]
eebrah|away is now known as eebrah
<hno> rz2k, ext4 on mtd?
tzafrir has quit [Ping timeout: 260 seconds]
<rz2k> just for testing mtdblock
<rz2k> (i know that ext4 on mtd is superbad idea)
tinti has quit [Quit: Leaving]
<hno> ext4 on mtd is not a superbad idea by definition, but mtdblock on mtd is...
tinti has joined #linux-sunxi
rellla has quit [Remote host closed the connection]
jemk has quit [Quit: bye]
hramrach_ has quit [Ping timeout: 240 seconds]
hramrach_ has joined #linux-sunxi
shineworld has joined #linux-sunxi
shineworld has quit [Quit: Leaving]
gzamboni has quit [Read error: Operation timed out]
<oliv3r> what is the difference between ext4 on mtd, and ext4 on mtdblock on mtd?
<oliv3r> also, ext4 on mtd is no issue at all; if its read only :)
tzafrir has joined #linux-sunxi
wingrime has quit [Read error: Operation timed out]
<hno> oliv3r, you can't do block filesystems such as ext4 on mtd.
<hno> you need a FTL between.
<oliv3r> but isn't ext4 a block fs?
<hno> mtdblock is the simplest possible FTL you can make.
<hno> yes ext4 is a block filesystem. So it can't run directly ontop of mtd.
<oliv3r> well you said 'ext4 on mtd is not superbad; but mtdblock on mtd is
<hno> Yes.
<oliv3r> i thought, as you said, you always need mtdblock inbetween
<oliv3r> so it confused me
hramrach_ has quit [Ping timeout: 240 seconds]
<hno> ext4 on mtdblock on mtd is extremely superbad idea, but it's not really ext4 fault.
<hno> anything on mtdblock is a bad idea, even read-only.
eebrah is now known as eebrah|away
<oliv3r> why even when read-only?
<oliv3r> I mean, you only write once, after that, it shouldn't matter any longeR?
notmart has quit [Quit: notmart terminated!]
<hno> because even if only reading you still need to relocate blocks and in most cases also handle bad blocks somehow. Reading from a NAND wears the data stored in the accessed page(s) so you need to periodically rewrite it. Erasing a block wears the NAND cells as such.
<oliv3r> ah ok that makes perfect sense
<oliv3r> except for the 'relocating blocks after read'
<hno> meant reloate pages/sectors. nand uses block for a larger element..
<oliv3r> yeah erase blocks
<oliv3r> but if you don't write, i don't see why you have to relocate them
<hno> because the stored levels in the NAND cells gets worn out the more you read.
<oliv3r> i know they wear from writing, didn't know from reading
<oliv3r> ah, didn't know that
<oliv3r> NOR doens't have that problem does it
<hno> It's mainly a problem for MLC cells.
<oliv3r> ok, learned something again :)
<oliv3r> mripard_: i did find 1 use for sunxi; but it's used internally; the entropy fill is done in the same driver
<oliv3r> mripard_: so technically, 2 users, the sysfs read + entropy
paulk-desktop has quit [Quit: Ex-Chat]
<hno> oliv3r, entropy fill from where?
tkoskine has quit [Ping timeout: 248 seconds]
<oliv3r> linus actually suggested to use the sid to fill the kernel entropy pool with
tkoskine has joined #linux-sunxi
<oliv3r> even if it can be 0 on some devices, it's still okay to do it
<oliv3r> that way, you have device specific 'random' entropy added to your kernel pool
<oliv3r> quite nifty
<oliv3r> i think it's safe to say that our sid's are 'random' enough for this purpose
<hno> it's not random. Highly predictable. But OK as a one-time seed to the entropy pool.
<oliv3r> how is it highly predictable?
<oliv3r> i haven't found a pattern for bits 192-256 yet
<oliv3r> the other bits do follow some pattern
<oliv3r> 0x4848 seems to be something specific to a10 and a20 aswell a10s and a13 use 7030 and 3030 respectivly there
<hno> Where is the list of known SIDs again?
hramrach_ has joined #linux-sunxi
<oliv3r> was looking at it too
<oliv3r> 0x80 and 0x50 is predictable too
<hno> Intereting that LKCL got his A20 programmed but the samples sent to Olimex was apparently blank.
<oliv3r> i noticed
<oliv3r> when he pasted his sid here; i thought that all a20 should have been
<oliv3r> maybe they clearhim
tinti has quit [Remote host closed the connection]
<hno> what do you mean?
<oliv3r> with the T9 pin routed as it is; i wouldn't be supprised
<oliv3r> him = it
<hno> why?
<oliv3r> maybe they know HOW to do it, or accidentally do it?
<oliv3r> they did route it out properly it seems
<oliv3r> so tehy may know more; if i see tsvetsan on irc i'll ask him
tkoskine has quit [Ping timeout: 276 seconds]
<oliv3r> btw, i think i know why my adb cable wasn't working; the moment i connect my minitor (hub) to my PC the usb driver crashes
tkoskine has joined #linux-sunxi
<hno> They don't know. But they did ask Allwinner about the purpose of the pin and got answer.
<oliv3r> oh really
<oliv3r> i also asked; and got asked how many sales etc I would have
tinti has joined #linux-sunxi
<bfree> just put a big chunk of updates in ... kernel up to date with sunxi-3.4 and u-boot to 2013.07~git + sunxi-current (one flat patch for sunxi) ... old versions still in for now just in case
<bfree> and ftr < BTS> Opened #711998 in linux-image-3.10-rc4-armmp 3.10~rc4-1~exp1 by Niall Walsh <niallwalsh@users.b...> «net: Add EMAC ethernet driver found on Allwinner A10».
<hno> oliv3r, yes.. Olimex is already past that barrier which helps. But they dod not get any programming information.
<hno> Wasn't aware they even got information on what voltage to connect. But they must have got that 2.5V from somewhere.
<oliv3r> yeah
<bfree> there really are tooooo many sunxi boards/targets now in u-boot sunxi-current, build time gone through the roof ;)
<hno> bfree, I know... and there will be more.
<oliv3r> i'm really gonna try to work on dram read from mmc (raw); should reduce it enormously
<hno> Just having it in a identified section of the SPL is sufficient.
<hno> i.e. as part of the header.
<hno> loke boot0/boot1 does it.
<bfree> hno: says Merge Window is open with -31 days remaining ;) don't suppose there's any chance of sunxi making it in?
<bfree> I'm clueless about them ... I kinda presume it's going to have to wait now for 2013.10 at the earliest?
<hno> All of it is not possible in that timeframe. But maybe the core support can make it so that it's at least possible to boot boot0->boot1->u-boot->serial load. maybe even tftpboot.
<hno> SPL support and MMC driver needs a fair bit of work.
<oliv3r> but if you inject it into a header, you need tomodify your binary. if we reserve 1k beteween spl and u-boot for example, we can have a static exe
<hno> what is the difference? We do add a header anyway.
<hno> and if it's in the header then it will be loaded automatically at a known location in memory.
<oliv3r> you only write a small blob too the mmc?
<oliv3r> 1 binary per platform people can dl and use, unmodified, md5-able
<hno> I build u-boot-spl.bin, then pass that to mksunxiboot which adds the header.
leowt has joined #linux-sunxi
n01_ has quit [Ping timeout: 248 seconds]
<hno> in theory there can be one single u-boot-spl.bin for all a10+a13+a10s+a20 boards, but one for each soc generation is no problem at all.
<leowt> Turl: u there?
<bfree> hno: thanks for the update (and your work in general on it of course)
<hno> bfree, thanks.
<oliv3r> right now, only dram settings are diff per gen
<Turl> leowt: sup
<oliv3r> i2c-eeprom with mac + 'spd'
<leowt> is this a13 ready?
<leowt> Turl:
<leowt> someone pointed to ping you about that
<Turl> leowt: probably not, someone here (rz2k I think?) sent me pull reqs for sun5i support but I forgot completely about them :P
<Turl> you should find them as pull reqs on github
<oliv3r> lazy turl
<Turl> the repos might be a bit bitrotten, I haven't touched them in a while
<Turl> oliv3r: :p
<leowt> Turl: i am trying to get around android
<leowt> if you help me out a bit i could do that
<oliv3r> still have to fix my build
<hno> oliv3r, 'spd'?
<oliv3r> the memory on ddr bars sfor pc's
<oliv3r> it stores memory tomongs
<hno> ah, that. Yes would be nice but that's cost reduced away in these platforms...
tkoskine has quit [Ping timeout: 260 seconds]
<oliv3r> probe for ic2-eeprom, probe eeprom for spd signature, read dram_para. 0robe for mac signature, read mac
tkoskine has joined #linux-sunxi
<oliv3r> yeah, but olimex has it ;)
<oliv3r> oh many things todo tomorrow
<hno> yes, but with mac only.
<hno> a very convenient way to get registered macs in low volume.
<oliv3r> is the atmel toed to i2c?
<hno> which atmel?
<oliv3r> the eeprom next to the phy
<hno> Yes.
<hno> TWI1.
<hno> i2c address 0.
<oliv3r> if its eeprom, we can program it
<oliv3r> so make backup, reprogram :)
<hno> Yes. But usually the first page with MAC is write protected.
<hno> I haven't looked into the specific one used by Olimex.
<oliv3r> ah, you buy yhe chip 'as' a mac
<oliv3r> i thought oli programmed it
<oliv3r> let me read the cjip (inbned now) brb
<hno> Seems that chip do not support per page write protect, so should be fully reprogrammable.
<hno> wp pin is tied to gnd (read-write).
<hno> And it's an 11 address bits device, which is interesting from a driver perspective.
<hno> what I don't quite understand is why Olimex have it on a separate i2c bus. Could coexist on TWI0 together with the AXP just fine.
mdfe has joined #linux-sunxi
leowt_ has joined #linux-sunxi
leowt has quit [Ping timeout: 252 seconds]
leowt_ is now known as leowt
<oliv3r> many twi available so use em? but i wondered the same
<oliv3r> should ask :)
oliv3r has quit [Read error: Operation timed out]
oliv3r has joined #linux-sunxi
mripard_ has quit [Ping timeout: 256 seconds]
mripard has joined #linux-sunxi
<oliv3r> hno: did you find datasheet? i read atml h134 1f.. nothing close to the usual at24 or at34
<hno> but I only looked in schematics, haven't looked at what is on the board.
<rz2k> Turl: nope, that wasnt me, I dont usually do android stuff
<Turl> rz2k: it was techn, just checked
<Turl> leowt: any specific thing you need help with?
<leowt> im trying to figure out what specific bits go into android source from the hw vendor. i am reading some doc about android's architecture to get to know it better
<leowt> Turl: will ping you tomorrow, what is your local time?
<Turl> leowt: GMT-3, 20:20 now
<leowt> Turl, cool, tomorrow then, tnks ;)
tinti has quit [Remote host closed the connection]
leowt has quit [Quit: leowt]