ChanServ changed the topic of #linux-sunxi to: Allwinner/sunxi development discussion - Don't ask to ask. Just ask! - See | | Logs at
<Turl> foubarre: did you build your own kernel?
<foubarre> Turl: no. i used this image: . However, i need to compile a kernel module (iscsi-target) and m-a cannot find the headers.
<rm> just replace the whole kernel with
<foubarre> Turl: and i am way too noob to do this.
<rm> sor nvm
<rm> or nvm *
<Turl> rm: do you ship iscsi-target?
<rm> no, hence "nvm"
<rm> I just checked and I don't have iscsi-target
<rm> and no headers either
<foubarre> sorry, guys you lost me...
<rm> my next suggestion would be to compile a kernel yourself:
<rm> or just use my kernel, and aoe instead of iscsi
<rm> afk
<foubarre> aoe.. well why not. I just need to find an etherboot that can connect to an aoe server...
<foubarre> rm: ok, will try that tomorrow. thanks for your suggestion.
<foubarre> have a great day/night
foubarre has quit [Remote host closed the connection]
tinti has joined #linux-sunxi
egbert has quit [Disconnected by services]
egbert has joined #linux-sunxi
drachensun has quit [Quit: Leaving]
BJfreeman has quit [Quit: had a good time]
ZaEarl has quit [Quit: Ex-Chat]
[7] has quit [Disconnected by services]
TheSeven has joined #linux-sunxi
DidiBsAs has quit [Quit: Leaving]
hramrach_ has quit [Ping timeout: 240 seconds]
eebrah|away is now known as eebrah
hramrach_ has joined #linux-sunxi
Turl has quit [Read error: Operation timed out]
Turl has joined #linux-sunxi
eebrah is now known as eebrah|away
mturquette has quit [Read error: Operation timed out]
rz2k has joined #linux-sunxi
ganbold_ has quit [Ping timeout: 248 seconds]
hglm has joined #linux-sunxi
ganbold_ has joined #linux-sunxi
lebernie has quit [Quit: Bye]
rellla has joined #linux-sunxi
hglm has quit [Quit: leaving]
shineworld has joined #linux-sunxi
bsdfox_ has joined #linux-sunxi
bsdfox_ has joined #linux-sunxi
bsdfox has quit [Ping timeout: 264 seconds]
_BJfreeman has joined #linux-sunxi
_BJfreeman is now known as BJfreeman
paulk-desktop has joined #linux-sunxi
foubarre has joined #linux-sunxi
<foubarre> rm: awaken?
hglm has joined #linux-sunxi
<rm> hi
shineworld has quit [Quit: Leaving]
BJfreeman has quit [Quit: had a good time]
<foubarre> rm: hi. I have installed your kernel as you suggested yesterday. However aoe-tools won't install and i did not succeed in creating an aoe server. Did you succeed in that?
paulk-desktop has quit [Quit: Ex-Chat]
hglm has quit [Quit: leaving]
tek has joined #linux-sunxi
tek is now known as Guest89165
<rm> foubarre, what errors do you get?
<rm> what does "modinfo aoe" output?
lunra has left #linux-sunxi ["Channel pruning"]
ijc has left #linux-sunxi [#linux-sunxi]
rellla2 has joined #linux-sunxi
rellla has quit [Ping timeout: 260 seconds]
mdfe has joined #linux-sunxi
rellla2 has quit [Ping timeout: 245 seconds]
<oliv3r> mripard: you siad to use struct file's private_data; but how do I store anything there? How do I 'reach' it? the only place where it's available is IN the read function, I would love have placed it there
<foubarre> root@debian:/home/debian# modinfo aoe
<foubarre> ERROR: Module aoe not found.
<foubarre> rm: here is what oe says.
<ssvb> mripard: thanks for a legal "no strings attached" copy of a10 manual, that's an excellent news!
<rz2k> I missed something?
<rz2k> where I can get that :p
hglm has joined #linux-sunxi
<ssvb> rz2k: that's basically a green light for a feature complete G2D driver
tomeff has joined #linux-sunxi
tomeff has quit [Excess Flood]
tomeff has joined #linux-sunxi
tomeff has quit [Excess Flood]
tomeff has joined #linux-sunxi
tomeff has quit [Excess Flood]
tomeff has joined #linux-sunxi
tomeff has quit [Excess Flood]
tomeff has joined #linux-sunxi
tomeff has quit [Excess Flood]
tomeff has joined #linux-sunxi
tomeff has quit [Excess Flood]
tomeff has joined #linux-sunxi
tomeff has quit [Excess Flood]
tomeff has joined #linux-sunxi
<oliv3r> ssvb: those are the exact same files we have at btw :)
tomeff has joined #linux-sunxi
tomeff has quit [Excess Flood]
<rz2k> oliv3r: "for WITS only"
<hglm> Does the G2D driver do busy-waiting for command completion or is it fully parallel with CPU processing (using an interrupt or similar)?
<mripard> ssvb: oh, I had them for a few months, and since it was already on the, I didn't realise some people was holding back :(
<mripard> oliv3r: come on, use lxr/google, it's even in LDD
<oliv3r> i know its part of struct file *fd
<oliv3r> so I can USE it within the .read
<oliv3r> but where can I PUT it in there?
<ssvb> hglm: do you mean the current G2D driver from allwinner? it sleeps waiting for an irq, which is not terribly great design
<oliv3r> mripard: I don't do '.open', the sysfs driver does that bit
<oliv3r> i only do .read; which is a callback from the sysfs bit
<hglm> ssvb: I see, I guess sleeping is better than busy-waiting at least.
<oliv3r> mripard: people where holding back, since we didn't 'officially' have the A10 docs, those where leaked; A13 i think we did get 'officially' or atleast where 'oked'
orly_owl has quit [Ping timeout: 245 seconds]
<ssvb> hglm: from what I could see in the newer sources, A31 has an updated G2D hardware with the support for premultiplied alpha and command queue
<hglm> ssvb: OK, I guess command queue may help in an X-style driver.
<ssvb> hglm: I suppose it can prevent irq spam when doing lots of small graphics operations
<mripard> oliv3r: ah right, for the .open, I forgot that.
FergusL has left #linux-sunxi ["Quit"]
<oliv3r> that's why I have that nasty 'p' pointer globally (i forgot the static, that's long fixed)
<mripard> then do like the AT24 guys do, use container_of on the kobj passed to you rread callback
<oliv3r> ok i'll try to figure it out :)
<hglm> ssvb: It think it may also reduce context switches to the kernel and make it easier for the kernel scheduler to handle all those short sleep requests.
<ssvb> hglm: the use of blocking ioctls to do any graphics operation which sleep waiting for a completion is a braindead software design
<ssvb> hglm: software can be fixed, but hardware limitations in A10 are still going to cost some performance
<hglm> ssvb: Something like an OpenGL-like pipeline would be useful. Isn't there a 100% GPU rendering path in Android? Unlikely that it would perform great on an embedded GPU though.
<ssvb> hglm: G2D (Mixer Processor) has a fixed pipeline with limited features, there is no way to avoid fallbacks to CPU rendering for some operations in X
<ssvb> hglm: I'm not an Android guy and only briefly looked at gralloc implementation, there is a use of Mali mixed with G2D and display controller layers
<hglm> Maybe there can be some parallelism between CPU rendering and G2D (if the areas drawn do not intersect).
<oliv3r> ssvb: are there any plans to eventually rewrite the entire disp bit for mainlining? or is that just to much work?
<ssvb> hglm: we have all the hardware, like the pieces in a chess or tetris game, we just need to use it all efficiently :)
<ssvb> oliv3r: somebody will eventually do this some day
tomeff has joined #linux-sunxi
<ssvb> oliv3r: I'm more interested in experimenting with performance optimizations than rewriting code from one boring framework to another
<oliv3r> sounds far off :( :p
<oliv3r> ssvb: out of curiosity, how hard is it to simply display a bitmap(say in u-boot) with the stuff we have now?
<ssvb> oliv3r: don't know, I have never really looked in detail at what is minimally necessary to initialize the disp hardware and display something on lcd/hdmi/vga/...
<hglm> That would require initializing all the display controller registers, but you have no control over the output configuration (there's no BIOS). You would need HDMI code etc etc.
<oliv3r> mripard: can't do that either, sunxi_sid_read_byte(key) needs to know the register address, which isn't acceessible there
<oliv3r> ssvb: was just thinking of having some bitmap output in u-boot :)
<ssvb> oliv3r: why do you want to show it from u-boot?
<ssvb> oliv3r: couldn't you use initramfs for showing some logos, boot menu or other fancy things?
<oliv3r> u-boot splash screen :)
<oliv3r> its good for user-friendlyness
<hglm> Bootloaders usually let the BIOS initialize the graphics...not possible for an embedded chip unless there is display-controller ROM or something.
<mripard> oliv3r: the register address?
<mripard> you pass whatever you want with it
<oliv3r> so pass register address + offset to the read function?
<mripard> or a pointer to the structure, or the base address, or whatever you want, it's your call
orly_owl has joined #linux-sunxi
orly_owl has quit [Changing host]
orly_owl has joined #linux-sunxi
<oliv3r> but then, if ever, someone wants to use the function internally (and we export it) we don't want to pass the base address alonga ny more
<mripard> we'll take care of the "if ever" case when we will need it
<oliv3r> okay
hglm has quit [Quit: leaving]
<oliv3r> which would mean we'd end up with what we have now :p; unless there's a cleaner way
<mripard> I have something in mind to do so, but it takes a lot of code, and I only have a non-working draft right now
<oliv3r> for?
<mripard> handling properly the case of having a driver that needs a value stored in an external eeprom
<oliv3r> ah
<wingrime-android> have we nightes with a10/a13 kere
<wingrime-android> kernel
<wingrime-android> ?
<oliv3r> wingrime-android: pre-compiled? some have some
<oliv3r> but not officially no
<wingrime-android> this uimage for a10?
<oliv3r> mripard: what about a function, 2 parameters, 'set/get', 'baseadress' that has an internal static place for the base address (or similar) and we set/get that to obtain base address?
<oliv3r> wingrime-android: no idea
<oliv3r> i would assume so tbh
<wingrime-android> how much difficlt can be make single a13/a10 image
<oliv3r> it might actually be! :p
<oliv3r> but i think that is somethign from amery, and i belive he mostly uses a10
<wingrime-android> a20 coming
<wingrime-android> maintrain single kernel much better
<rm> afaik a10 or a13 is selected at compile time
<rm> in kernel's (menu)config
<wingrime-android> unify all then replace #indefs with cpu_is
<rm> # CONFIG_ARCH_SUN3I is not set
<rm> # CONFIG_ARCH_SUN5I is not set
<rm> I agree that having 1 kernel for all would've been ideal
<rm> and doesn't seem impossible
<wingrime-android> rm:we have bunch drivers that still not unified
<wingrime-android> clocks
<wingrime-android> i have send cedarx unufication but it have not aproved
tinti has quit [Quit: Leaving]
<wingrime-android> dma aproved
<wingrime-android> and mnemoc I think should leave 3.0 as *fix only*
shineworld has joined #linux-sunxi
drachenphone has joined #linux-sunxi
<mripard> oliv3r: it doesn't solve anything, where do you get the base address from when you call this function?
<mripard> and what happens when on some board, say, the mac address is not in the SID but on another eeprom?
drachenphone has quit [Ping timeout: 276 seconds]
drachenphone has joined #linux-sunxi
mdp has quit [Ping timeout: 264 seconds]
drachenphone has quit [Ping timeout: 246 seconds]
mdp has joined #linux-sunxi
paulk-desktop has joined #linux-sunxi
drachenphone has joined #linux-sunxi
<mnemoc> wingrime-android: can you give me the date and subject of the pending patchset ?
<mnemoc> wingrime-android: I can't abandon 3.0 until someone confirms android works fine over sunxi-3.4
drachenphone has quit [Ping timeout: 256 seconds]
<ssvb> mnemoc: now that I think about it, do we actually need to support android? does it have any real users?
<techn_> ssvb: most likely a13 users
<techn_> there is not much use for a13 and linux
<techn_> but sadly our a13 support isn't that great
<mnemoc> a10s is worse
<ssvb> if allwinner is providing 'official' android support and every android user is running allwinner kernels, then what's the point?
<mnemoc> there are android users who compile their own kernels too
<techn_> ssvb: atleast for my a13 tablet allwinners/device provider android is really bad :(
drachenphone has joined #linux-sunxi
<ssvb> techn_: does linux-sunxi kernel work better on it with android?
<techn_> ssvb: I havent found image that works without issues
<techn_> ssvb: my target is to get my a13 tablet working without issues.. among other things :p
<mnemoc> ssvb: at least people has the option to have (and improve) a gpl-compliant android system and not rely in the never-coming manufacturer upgrades
<mnemoc> so i like to believe android users also need us
<lkcl> hno: pingg. appreciate your advice on how to upload uEnv.txt over felboot
<mnemoc> lkcl: don't forget uEnv.txt support is part of u-boot's env. so if you have a u-boot env which doesn't load it, it won't work.
<shineworld> <mnemoc> wingrime-android: I can't abandon 3.0 until someone confirms android works fine over sunxi-3.4: I've tried last week but often reboot and something goes bad
<mnemoc> :(
<shineworld> I've to retray checking every settings in ***defconfig
<shineworld> because some are defined in batch of android path
<shineworld> I've manually added them but I could entered bugs
<ssvb> shineworld: does at least the current linux-sunxi 3.0 kernel work fine with android?
<shineworld> In cubie I'm using 3.0.76 BUT I've got some problems with accessory that doesn't work
<shineworld> really accessory mode doesn't work yet on 3.0.52+ and in 3.0.8 of my tablets
<shineworld> so I've tried with 3.4 but just not reach the Launcher2
<shineworld> Next week I've plained to reset all and try 3.4 more seriously
<lkcl> mnemoc: ack. hmmm, ok so the question is: how do i modify the standard u-boot env. i imagine it's possible to just drop it in (overwrite) as part of felboot.
<shineworld> because I'm interested about step-uip
<lkcl> mnemoc: do you know what offset in u-boot (the binary) that the standard env is located?
<lkcl> off the top of your head?
<shineworld> to finish : WHY ACCESSORY ? because there are some android users like me that uses android to interface the industrial world of machinery with that :)
<lkcl> 0002c1c0 ff ff ff fe ff ff ff 02 2c 20 00 62 6f 6f 74 63 |........, .bootc|
<lkcl> 0002c1d0 6d 64 3d 69 66 20 72 75 6e 20 6c 6f 61 64 62 6f |md=if run loadbo|
<lkcl> 0002c1e0 6f 74 65 6e 76 3b 20 74 68 65 6e 20 65 63 68 6f |otenv; then echo|
<oliv3r> mripard: well i'm just using this function to 'expose' the eeprom, the init would set up the base address, but it's basically only moving the static global variable into a static variable inside a function. so it's only moving it around a little. So don't even thinkit would help al lot; i'll browse over the at24 driver and see if it exposes the content of the eeprom anywhere
<oliv3r> anybody with an A31 device here atm and can boot into u-boot?
<lkcl> looks like it's..... 0x2c1cc
<lkcl> oliv3r: mine's still on its way, sorry. a1000-quad
<oliv3r> oh nice
<oliv3r> i need some memories dumped to see is all :)
<shineworld> ssvb, are you running android on A13 ?
<oliv3r> techn_: my a10 tablet doesn't work great either. old kernel, locks up if on standby for a few days (on power mind you) and wifi is very shitty after wakeup
<oliv3r> mnemoc: once i get a breakout board; i'll test 3.4 on my tablet; since i can't boot it now
<ssvb> shineworld: no, I'm not interested in android myself, but just wonder how we can try to avoid android regressions when fixing/unifying the drivers
<ssvb> shineworld: and android is holding back 3.0 deprecation, which is also a burden
<oliv3r> lkcl: we know where it should be
<drachenphone> Lkcl I think you use mkubootenv in u-boot/tools to sign a standard env then you can write to nandb
<shineworld> I'm hoping that kernel take care about android users.... sigh
<oliv3r> well once a* support is properly in mainline, it'll be good for alla ndroid users :p
<ssvb> shineworld: if somebody is regularly doing some sort of basic android smoke testing for new linux-sunxi kernels, that would be a bit more reassuring
<techn_> ssvb: anyway.. it's good to test regression on android too.. it reveals bugs :p
<lkcl> drachenphone: this is entirely in-memory. it is pre-nand boot. actually, i'm not going to touch nand at all.
<lkcl> oliv3r: thx
<ssvb> techn_: do you know anybody who is doing this?
<techn_> ssvb: but I hate our hacky kernel interfaces (disp)
<lkcl> oliv3r: ahh... right, yes - again, that's on sdcard. this is *in-memory*.
<oliv3r> mripard: this is how it's done in the at24 driver, right? Not sure on the naming, but why aren't those symbols exposed? maybe it's just old
<techn_> ssvb: I'm testing regression on android too
<oliv3r> lkcl: not on flash, but in actual ram?
<techn_> ssvb: atleast sometimes.. not frequently
<ssvb> techn_: thanks, that's good to know
<oliv3r> lkcl: and you are talking about post SPL right?
<techn_> ssvb: but usually I'll test only my own changes.. like this usb stuff, which I'm eventlyally submit
<lkcl> oliv3r: yes, in actual ram.
<oliv3r> then I don't know :p
<lkcl> and yes, post-spl, but post-spl *over usb-fel* :)
<lkcl> fel 0x2000 fel-boot.spl
<lkcl> fel execute 0x2000
<lkcl> fel write 0x4000000 u-boot.bin
<ssvb> techn_: maybe it is a good idea to start some sort of a wiki page with android support status and list the known working kernels (and the known issues if any)?
<lkcl> fel write 0x40020c1cc {squiggle, squiggle, u-boot default params?)
<lkcl> fel execute 0x4000000
<ssvb> techn_: I'm not testing my patches on android :( appears that I'm a bad guy
<lkcl> absolutely awesome, that. fuck livesuite. don't need it.
<techn_> ssvb: I think that's too much of work :p
<mripard> oliv3r: I already told you that I didn't want the symbols exposed
<oliv3r> mripard: i was comparing to the at24
<techn_> ssvb: I think testing on every combination is not expected.. we should have good review process ;)
<ssvb> techn_: review is not a complete replacement for real testing
<techn_> after we have a20 and a31 we have atleast 8 combinations to test.. which is too much for average developer :p
<techn_> oh.. I forgot a10s
<mripard> oliv3r: yeah, and on that part, the at24 is crap
<techn_> so it's 10 combinations
<techn_> atleast
<oliv3r> mripard: ok looking at a nother one then :p
<mripard> all of them are crap. It's the point
<mnemoc> techn_: that's the point of the stage branch. leave time to people to test in different devices
<mripard> there's no standard way of interacting in a generic way with an eeprom currently
<oliv3r> we need a 'memory framework' basically
<techn_> anyway I like our staging process.. It's great to have experimental and "working" versions
<mripard> you have to know in the driver using it which kind of eeprom you are using
_BJfreeman has joined #linux-sunxi
<mripard> yeah
<techn_> mnemoc: ^ :)
<mripard> oliv3r: and that's what I've begun to work on, but I didn't have much time lately to do so
<mnemoc> techn_: :)
_BJfreeman is now known as BJfreeman
<oliv3r> mripard: well as soon as you have more info on that, i'll happily port it over :p
<ssvb> techn_: it's fine as long as at least somebody is testing the stage kernels on android sometimes :)
<ssvb> techn_: and actually reports regressions as soon as they are introduced in timely fashion
<techn_> yeah.. testing every combination on every commit is too much with our resources .. I thing some delay is acceptable there
<oliv3r> mripard: irony of this all is, I was thinking the other day, why we didn't have an eeprom framework ;)
<techn_> hopefully everyone understands that ;)
<mripard> oliv3r: yeah, actually, that's your patches that made me work on it
<mripard> I had the problem for one customer, on another SoC
<mripard> but we hacked quickly something away
<oliv3r> mripard: ok i'll leave it all unexposed as it is and just pass the base address for now, until it gets rewritten to the new framework
<mripard> now, it's the second time I've been facing this issue in like 6 monthes
<mripard> it's too much :)
<oliv3r> well with SoC's coming out more and more with less memories etc, it becomes overy more important to have such a facility
<oliv3r> the most obvious example, is mac in eeprom
<oliv3r> or, as the comment on the at24, calibration data
<mripard> which is exactly what I've been facing for this customer
<mripard> we first had the mac in the SID equivalent
<mnemoc> the a10 sodimm from bdd has a 2k eeprom on i2c0, next to the axp209
<oliv3r> ok i'll no longer bugger you about any of that and clean it up so that it can be mainlined asap, and we can always port it later
<mripard> so we used something to retrieve the mac from this SID-like
<oliv3r> well once we know how to write data into the SID, it can be used for things like exactly this
<mripard> and then, we wondered if we could use the AT24 we had to put the mac in there
<mripard> and it was a pain, so we gave up
<oliv3r> ouch :p
<oliv3r> well if you get to do this for payed $work; then that's a very positive thing to put into the kernel
<mripard> well, it's a bit of both
<mripard> both work and hobby that is
<oliv3r> only hobby for me :(
<oliv3r> anybody got a job?
tomeff has quit [Read error: No route to host]
n01 has joined #linux-sunxi
hglm has joined #linux-sunxi
ganbold__ has joined #linux-sunxi
ganbold_ has quit [Ping timeout: 256 seconds]
mdfe has quit [Disconnected by services]
mdfe has joined #linux-sunxi
mdfe has quit [Disconnected by services]
mdfe has joined #linux-sunxi
hglm has quit [Quit: leaving]
<hno> lkcl, there is no default offset where default environment is stored in u-boot. Use the source.
<lkcl> hno: :)
<lkcl> hno: awwww okaaaay
<lkcl> hno: you checked in the params right? (for dram)
<hno> Yes.
<lkcl> yay
<hno> eoma68 board.
<drachenphone> Mripard I'm building your a31 kernel to test. Any special config?
<lkcl> hno: sunxi-current branch? no....
<hno> probably only pushed to my github repo.
<lkcl> hno: ahh ok
<hno> no, pushed to both.
<lkcl> it _is_ sunxi-current. doh
<hno> also pushed the env change to allow boot from ram.
<lkcl> ack. eh? oooo coool
<lkcl> *thinks*.
<lkcl> i .... eh?
<lkcl> que?
<hno> ?
<lkcl> env change for ram boot?
<hno> yes, to boot kernel + optional initrd from ram.
<lkcl> ohh yes. ok.
<lkcl> "if iminfo 0x44000000; then" \
<lkcl> - " if iminfo 0x4c000000; then ramdisk=0x4c000000; fi"\
<lkcl> + " if iminfo 0x4c000000; then ramdisk=0x4c000000; fi;"\
<lkcl> ok so.... *thinks*
<lkcl> ahh ok
<lkcl> iminfo is a command for detecting u-boot block signatures, right?
<hno> It's a command for showing info from an u-boot image. Errors if there is no identified image.
<lkcl> sooo... that would be going.... "if there's a u-boot image at 0x44000000"
<hno> yes
<lkcl> then if there's one at 0x4c000000 as well then that must be an initramdisk, so boot it
<lkcl> ok.
<hno> yes
<lkcl> dooo ii..... dooo ii neeed to dooo anything ellse......
<lkcl> i don't believe i do!
<lkcl> i think that's all that's needed. which is amazing.
<hno> there is no way to specify a root in rambooting currently, other than using an initramfs that sets the root.
<lkcl> i'm sure that'll be fine - i have to customise the initramfs anyway
<hno> should add some boot.scr support as well to ram booting.
<lkcl> he said....
<lkcl> hmmmm....
<hno> actually should replace that with a ram boot.scr support instead.
<hno> who knows what people want to ram boot. There is more than Linux kernels.
<lkcl> oh, hno: the board needs to be called a10-eoma68
<lkcl> because this is only the first eoma68 board: there will be more.
<hno> right. Or is it eoma68-a10?
<lkcl> errr.... true!
<lkcl> don't know :)
<lkcl> i seem to be putting a10-eoma68 all over the place, don't know why
<lkcl> you decide :)
shineworld has quit [Remote host closed the connection]
<lkcl> hno: can i mail you some mods to the script.fex for the Allwinner-info repo?
<hno> sure, or post the fex to sunxi-linux list for inclusion in sunxi-bords.
<hno> Allwinnet-info in not a stable repository. It is my dumping ground
<lkcl> hno: dumping-grounds work greaaaat for me :)
<lkcl> i'm still working on it
<hno> as you noticed things move elsewhere as they mature.
<hno> lkcl, I like eoma68-a10 better. makes it possibe to have names like eoma68-a45-16 (for a hypothetical future a45 board with 16g memory) etc.. and puts the focus on eoma68 and not the cpu model.
<mnemoc> +1
<hno> but I guess that would be an eoma68-a85, not 45...
* mnemoc still dreams with an a40...
<hno> mnemoc, 2d or 4d?
<mnemoc> hno: don't know what you mean by that, but the a40 of my dreams is an A20 but quad instead of dual
<oliv3r> little.BIG
<mnemoc> i doubt allwinner decided to target higher end
<n01> mripard: I was checking if the reserved WDT_CTRL_RESERVED bits are necessary and they actually are
ganbold__ has quit [Remote host closed the connection]
ganbold__ has joined #linux-sunxi
<lkcl> hno: ack ok
<lkcl> it's a hierarchy.
<lkcl> mnemoc: i was just thinking the same thing yesterday. the only problem is: memory bus bandwidth. that's a hell of a lot of data to get through a 32-bit bus. *but*, in some ways that's ok because if it's at the $7.50 price-point, what do you care?? :)
<lkcl> hno: 2 days is mature??? bloody hellfire :)
<Turl> WarheadsSE: ping
n01 has quit [Ping timeout: 264 seconds]
kendoll has joined #linux-sunxi
kendoll has quit [Quit: leaving]
ssvb has quit [Ping timeout: 264 seconds]
Undertasker has joined #linux-sunxi
shineworld has joined #linux-sunxi
Undertasker has left #linux-sunxi [#linux-sunxi]
ssvb has joined #linux-sunxi
Undertasker has joined #linux-sunxi
paulk-desktop has quit [Read error: No route to host]
paulk-desktop has joined #linux-sunxi
rz2k has quit []
hglm has joined #linux-sunxi
Skaag has quit [Ping timeout: 240 seconds]
zub has quit [Ping timeout: 252 seconds]
zub has joined #linux-sunxi
servili007 has joined #linux-sunxi
ganbold has quit [Ping timeout: 245 seconds]
drachenphone has quit [Quit: Bye]
shineworld has quit [Quit: Leaving]
tinti has joined #linux-sunxi
<oliv3r> n01: ping
paulk-desktop has quit [Quit: Ex-Chat]
ganbold has joined #linux-sunxi
mdfe has quit [Disconnected by services]
mdfe has joined #linux-sunxi
mdfe has quit [Disconnected by services]
mdfe_ has joined #linux-sunxi
Guest89165 has quit [Quit: Bye bye]
<oliv3r> mripard: does it matter, that if you have register block A), that's 0x400 large, but have a specific driver (wdt in this case) for a sub-range, that's only 0x10 large
Undertasker has quit [Quit: Leaving.]
BJfreeman has quit [Quit: had a good time]
_BJfreeman has joined #linux-sunxi
<oliv3r> mripard: and on that line, we have the PWM, 12 bytes, 1 generic control register, 1 additional for each PWM unit. sun4i has both PWM's, sun5i has only the first one. Also, PWM isn't even in the architectual overview. So what address do I define? I would think the base register, and then as range, 12 bytes, but you say use what the datasheet gives you, which is 0?
<oliv3r> With a messy datasheet that we have, do we really want to use those values as ranges? it's confusing :s
_BJfreeman is now known as BJfreeman
<Turl> oliv3r: what I do on clocks is set the register address for a clock and the range as size of the register, usually 0x4
<oliv3r> Turl: yeah, but mripard ripped me a new one! jk jk, but said 'the architecture int he pdf says it's 1k block, so define it as such'
<oliv3r> for the wdt, he accepted/set it to 0x10; which is wrong btw, since it should be 0x08 (only 2 bytes)
<oliv3r> and for PWM, it should be 0xc, 3 bytes. for SID, it should either be 0x10 (4 bytes) or 0x48, since that's including the 'write' register (that we don't use, so I still feel for 0x0c)
<oliv3r> and I was gonna play with the RTC next
<oliv3r> which is only 4 bytes I think, but is part of the timer register
<oliv3r> if i declare it 0x400 as mripard says, I'll overlap the WDT register allready
<oliv3r> which imo is more confusing, basically, I feel that we shouldn't go with the datasheet, since its crap really
<Turl> oliv3r: you should include all the relevant registers, even if you don't use them, because DT is a hardware description
<Turl> but I believe you should just include the relevant ones
<Turl> so, according to my copy of A10 user manual, it'd be 0x01C23800
<Turl> and 0x0c
<Turl> actually 0x0c+4
<Turl> that's 0x10
<Turl> oliv3r: I don't see any write register?
<Turl> ah, I see it on the A13 counterpart, that'd be 0x48 for A13 (or both if it's just incompleteness on the A10)
<Turl> I cannot make much sense of the write register though :)
hglm has quit [Quit: leaving]
vicenteH has quit [Read error: Operation timed out]
vicenteH has joined #linux-sunxi
tinti has quit [Ping timeout: 245 seconds]
<hno> The SID is efuses. Can only be written once and conditions required for enabling write is unknown.