<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!
<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>
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_SUN4I=y
<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>
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*.
<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>
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.