hno changed the topic of #linux-sunxi to: Allwinner/sunxi development discussion - Don't ask to ask. Just ask! - See | | Logs at
naobsd has quit [Quit: Page closed]
soul has quit [Quit: No Ping reply in 180 seconds.]
Soru has joined #linux-sunxi
Guest82596 is now known as zumbi
tinti has quit [Quit: Leaving]
egbert has quit [Ping timeout: 246 seconds]
egbert has joined #linux-sunxi
derethor_ has quit [Remote host closed the connection]
Soru has quit [Ping timeout: 252 seconds]
Soru has joined #linux-sunxi
BJfreeman has quit [Quit: had a good time]
piyushverma has quit [Quit: Konversation terminated!]
egbert has quit [Disconnected by services]
egbert has joined #linux-sunxi
<Turl> interesting week for sunxi :)
<Turl> n01: you've got mail :p
Soru has quit [Ping timeout: 240 seconds]
Soru has joined #linux-sunxi
TheSeven has quit [Disconnected by services]
[7] has joined #linux-sunxi
piyushverma has joined #linux-sunxi
piyushverma has quit [Client Quit]
Soru has quit [Ping timeout: 246 seconds]
soul has joined #linux-sunxi
oliv3r has joined #linux-sunxi
oliv3r has quit [Read error: Operation timed out]
eebrah_ has quit [Ping timeout: 260 seconds]
oliv3r has joined #linux-sunxi
tzafrir has quit [Ping timeout: 264 seconds]
<oliv3r> 0bah, the internet, was down :()
<oliv3r> now i have to backread the log online
<oliv3r> Turl: why is it an interesting week?
gzamboni has quit [Read error: No route to host]
rellla has joined #linux-sunxi
<oliv3r> rz2k rz2k
<oliv3r> damnit where is everybody
n01 has quit [Ping timeout: 248 seconds]
n01 has joined #linux-sunxi
n01 has quit [Read error: Connection reset by peer]
n01 has joined #linux-sunxi
n01 has quit [Client Quit]
<rellla> Turl: yeah, why interesting week? because wiki spam accounts grow? :p
<oliv3r> i don't recall any other interesting news :)
shineworld has joined #linux-sunxi
<rellla> another fine interesting news is, that mnemoc appears again in my sidebar...
<oliv3r> yeah, but he hasn't spoken since he logged on 3 days ago
<oliv3r> so i hope he lurks :)
jinzo has joined #linux-sunxi
jinzo has quit [Changing host]
<oliv3r> bummer, no cubie truck developer boards ;)
theOzzieRat has quit [Ping timeout: 245 seconds]
theOzzieRat has joined #linux-sunxi
<oliv3r> mripard_: read/reply to your email :p and appearantly
<oliv3r> the arm and m68k people aren't impressed with greg's comment :) so i guess I can't fix it
<hno> hi oliv3r. /me is busy at work trying to catch up before vacation.
<mripard_> oliv3r: both comments are different actually
<mripard_> Russell says that it should be a platform device, like I told you :)
<mripard_> and Geert says that the race exists to a whole bunch of other drivers.
<oliv3r> mripard_: i never dissagreed with you; I have no clue, what do I know :p
<oliv3r> well what they both say, ther eis no proper solution yet then
<oliv3r> mripard_: and with mail i ment the a31 mail :)
<oliv3r> hno: no worries, the patches I've sent you aren't crucial and only go into the a20 branch anyway
<oliv3r> hno: but you will be happy ot know, u-boot work on sun4i and sun7i; haven't tested it on sun5i as i lack hardware (any sponsor out? :)
<mripard_> but thinking a bit more about that, and discussing about it with others, maybe GKH was actually meaning to say that since you don't register your device against a particular framework, you have your sysfs file registered against the bus side of the driver, while it should be registered against the device side of it
<mripard_> that's the only way we could think of in which greg's answer actually makes any sense
<oliv3r> ok, but how do I do that?
<oliv3r> not use module_platform_driver anymore I suppose?
<mripard_> register against a framework, so either the misc framework
<mripard_> or mtd
<hno> oliv3r, no worries. I'll test it on sun5i tonight.
eebrah_ has joined #linux-sunxi
<oliv3r> mripard_: eeprom framework :p
<mripard_> but mtd is a bit overkill for this if you ask me
<oliv3r> hno: when will you be back from vacations?
Superpelican has joined #linux-sunxi
<mripard_> oliv3r: I'm not even sure we should have an eeprom framework anymore
<oliv3r> mripard_: how so?
<mripard_> MTD makes a lot of sense for these as well.
<mripard_> so maybe just add some DT bindings to MTD, and that's it.
<oliv3r> so mtd or misc
<mripard_> yeah
<oliv3r> mtd it probably then :)
<hno> oliv3r, 3 weeks vacation starting on monday, but I hope to spend tome time on sunxi during vacations.. but will likely not be online on irc much.
<oliv3r> i'll try to read into it
paulk-desktop has joined #linux-sunxi
<mripard_> but let the discussion go on, russell went pretty hard on him, I'm pretty sure it won't stop there
<mripard_> :)
<oliv3r> lol
* oliv3r grabs popcorn
<oliv3r> well atleast I feel less stupid
<oliv3r> hno: ok, i'll take that into account then when wanting to poke you for stuff
<oliv3r> hno: will you read e-mail to accept patches?
<oliv3r> mripard_: so ideally, you'd want to move the at24 etc eeprom drivers from misc stuff, to the mtd framework
<oliv3r> ideally if time permits
<hno> oliv3r, I do plan to read email, but maybe not every night.
<mripard_> oliv3r: yes, and there's actually already an AT25 driver in mtd
<mripard_> and one in misc/eeprom
<oliv3r> hno: do enjoy your vacation!
<mripard_> I don't really get why
<oliv3r> ah taht's cool; ok i'll move it over to the mtd framework
<hno> mripard_, yes there is eeprom drivers little everywhere.... both mtd and non-mtd.
<hno> for same chips.
<mripard_> hno: yeah, it's the "for the same chips" that confuses me the most actually
<mripard_> there's a lot of historical frameworks/drivers for chips that have never been moved to newer framework, it's not perfect, but pretty much ok
<mripard_> but having to maintain two different drivers for the same hardware is not really the usage in the kernel
<mripard_> anyway.
Superpelican has quit [Remote host closed the connection]
<mripard_> hno: enjoy your holidays :)
<oliv3r> lol
shineworld has quit [Quit: Leaving]
<oliv3r> mripard_: but yeah, a31 dram controller might be a lot of trouble, specially with the different registers as I mailed you for :S
<mripard_> you mailed me about the clocks, didn't you?
<oliv3r> aye
<mripard_> it still is in my Inbox, waiting for me to find some time to look at that
<oliv3r> ok i'll just assume the same registers as we had before and change it later where needed
tzafrir has joined #linux-sunxi
theOzzieRat has quit [Ping timeout: 252 seconds]
theOzzieRat has joined #linux-sunxi
shineworld has joined #linux-sunxi
soul has quit [Read error: Connection reset by peer]
hansg has joined #linux-sunxi
Soru has joined #linux-sunxi
shineworld has quit [Remote host closed the connection]
leowt has joined #linux-sunxi
hansg has quit [Quit: Leaving]
<oliv3r> mripard_: can a mtd device be read-only? I'm looking at the various drivers under 'maps' where some bios mappings are done, but they all are writeable i think, and mtd.h clearly states, in mtd_info 'writesize cannot be 0'
rz2k_ has joined #linux-sunxi
<oliv3r> rz2k_: more mtd news on ML
<rz2k_> hi
<rz2k_> yep, I saw
notmart has joined #linux-sunxi
notmart has joined #linux-sunxi
notmart has quit [Changing host]
<oliv3r> mripard_: btw, i think the current dram clk gate we have (offset 0x0100) is actually dram1 and at 0x0f4 is dram0 but that's undocumented currently
leowt has quit [Read error: Connection reset by peer]
leowt has joined #linux-sunxi
<mripard_> oliv3r: I never used the mtd framework, but I'd say that you just don't define a write callback
<mripard_> (and the erase one, obviously)
<oliv3r> well the 'map' drivers simply map a device region
<oliv3r> you don't have callbacks :)
<oliv3r> just probe which sets up the memory area to map
<oliv3r> mripard_: i'm really worried about those registers for a31; though i think the upside is, the 'new' registers don't overwrite any of the old ones, they used previous unknown/reserved areas
<mripard_> oliv3r: true, plat-ram looks very similar to what you should do
<oliv3r> aye
<oliv3r> that's what i looked at
<oliv3r> i liked it, it's very simple
\\Mr_C\\ has quit []
<oliv3r> but that worried me
<oliv3r> 'minimal writable flash unit size'
<oliv3r> which is not allowed to be 0 :S
<rz2k_> oliv3r: commented on mtd
<mripard_> oliv3r: but you have to pass MTD_WRITEABLE for mtd_write to let you through
<rz2k_> there are many mindf#cks in NFC driver
<mripard_> so just to give that flag, and that's it
<oliv3r> mripard_: Ohh, i was searching for 'flags' so that's probably where :)
<oliv3r> but searching for 'flags' is hard :S
<oliv3r> mripard_: but i put sid on a break for today; while interesting, i really want to get the first PoC for dram_sun6i.o to you :)
<oliv3r> rz2k_: cool; will read; but I think while those chinese guys deserve a medal for doing what they did so far, cooperation is very limitied is it not?
<mripard_> it's less critical than it used to be on my side, I managed to have a bootloader chain working
<rz2k_> yeah, they really did great thing with sharing this all
<oliv3r> mripard_: :(
<oliv3r> mripard_: i've spent many hours on this!
<oliv3r> mripard_: looks even more interesting :)
<oliv3r> don't understand why that is under 'chips' when the name even says 'map' so it should be under map imo
<rz2k_> biggest problem with allwinner NFC is that we need a particular ECC_MODE for each particular type of chip
<rz2k_> so this crappy nand_id.c/h thing is going to stay
<rz2k_> mtd will not solve this problem
<oliv3r> i'm supprised mtd doens't have a way to handle that
<mripard_> oliv3r: nah, I mean it's important, really, as a community that we have that support.
<mripard_> I'm using boot0/boot1 and so on, it's a pain
<oliv3r> heh
<oliv3r> i'll keep going then :p
<mripard_> all the work you're putting into this is appreciated, and important :)
<oliv3r> just wish we had dramc docs; it's a pain dabbling in the dark
<mripard_> what I meant was just that if you want to take some rest with it, you can :)
<oliv3r> hehe, well i wanna finish the poc
<oliv3r> then make an mtd driver ;)
<oliv3r> and start the entire process all over :p
_BJFreeman has joined #linux-sunxi
_BJFreeman is now known as BJfreeman
eebrah_ has quit [Remote host closed the connection]
eebrah_ has joined #linux-sunxi
eebrah_ has quit [Read error: Connection reset by peer]
<hramrach__> jelly-home: if nobody answered while in a split .. you get board info by copying the script.bin from nanda and running a10_meminfo on adroid
<hramrach__> there is a page about that on the wiki
techn_ has joined #linux-sunxi
tinti has joined #linux-sunxi
BJfreeman has quit [Quit: had a good time]
leowt has quit [Quit: leowt]
tinti has quit [Ping timeout: 276 seconds]
\\Mr_C\\ has joined #linux-sunxi
n01 has joined #linux-sunxi
specing has quit [Ping timeout: 245 seconds]
specing has joined #linux-sunxi
rz2k_ has quit [Quit: leaving]
<oliv3r> hno: mripard_ btw, i stopped and sent you what i had, because the next step is 'ddr voltage setup' which is just nasty and should be elswhere really :p
Tsvetan is now known as TsvetanAway
tinti has joined #linux-sunxi
rellla has quit [Quit: Nettalk6 -]
Superpelican has joined #linux-sunxi
<Superpelican> oliv3r:How do I find out what I should choose as load address and entry point when converting a zImage to an uImage with mkimage?
leowt has joined #linux-sunxi
_BJFreeman has joined #linux-sunxi
rz2k has joined #linux-sunxi
_BJFreeman is now known as BJfreeman
cajg has quit [Ping timeout: 268 seconds]
cajg has joined #linux-sunxi
leowt has quit [Quit: leowt]
leowt has joined #linux-sunxi
Superpelican has quit [Ping timeout: 268 seconds]
Soru has quit [Ping timeout: 276 seconds]
gzamboni has joined #linux-sunxi
theOzzieRat has quit [Ping timeout: 240 seconds]
theOzzieRat has joined #linux-sunxi
Soru has joined #linux-sunxi
Superpelican has joined #linux-sunxi
leowt has quit [Quit: leowt]
<oliv3r> Superpelican: LOADADDR=0x40008000
<Superpelican> oliv3r:Is that for all sunxi devices?
<Superpelican> oliv3r:And what's the entry point, then?
<oliv3r> i belive you can leave it blank
<oliv3r> in doubt, extract one and see what it prings
<Superpelican> oliv3r:So load address is the same for all A10 devices?
<Superpelican> and setups/kernels
<oliv3r> yes
<Superpelican> :)
<Superpelican> that makes things a lot simpler
<Turl> oliv3r: MTD driver can write bootloader now :) that's why it's interesting
<Turl> and n01 got a rtc driver :)
<oliv3r> Turl: and i have to rewrite the sid driver to an mtd driver
ibrah has joined #linux-sunxi
n01_ has joined #linux-sunxi
<mripard_> oliv3r: you should look at your mails.
<oliv3r> yeah; greg said that he was wrong
<oliv3r> i just need to pass some group attr
<oliv3r> but i like the mtd approach more
<mripard_> ok
<mripard_> too bad that when you're this close to get something merge, you throw it all away to start over :)
<oliv3r> LOL
<oliv3r> that is mean
<Superpelican> oliv3r:So I could just set entry point to 0? And is the load address suppose to be different from the place the uImage is loaded? :"fatload mmc 0 0x48000000 uImage"
<oliv3r> Superpelican: use ''
<mripard_> oliv3r: that's not mean, it's a fact
<oliv3r> to split an android boot.iimg
<oliv3r> mripard_: well YOU said to rewrite it as misc/mtd
<oliv3r> so you excited me in that regard :)
<oliv3r> ok, i'll keep it as it is
<oliv3r> can always re-write it later
<mripard_> oliv3r: no, I said I thought greg meant that way.
<mripard_> and obviously, he doesn't :)
<oliv3r> lol
<oliv3r> well but still
<oliv3r> sid looks like an eeprom
<oliv3r> yo uwanted an eeprom framework
<oliv3r> but mtd might do the same and the better
<oliv3r> so the mtd framework sorta is an eeprom framework
<oliv3r> and we wanted to port the sid driver to your eeprom framework
<oliv3r> so porting it to the mtd framework kinda makes sense too
<oliv3r> just not sure what 'default attribute groups' are
<oliv3r> let me check the groups field
<Superpelican> oliv3r:Is this useful:
<oliv3r> that's the ini file from nanda :)
<oliv3r> run split_bootimg on an android boot.img; it will output you the proper parameters
<bfree> Superpelican: on cubie1 I've just been using "-a 0x40008000 -e 0x40008000" with mkimage and it doesn't seem to matter exactly where you tell u-boot to load it (within reason anyway)
<bfree> I think I just grabbed those values from what a kernel "make uImage" did ;)
<Superpelican> bfree:THanks
Superpelican has quit [Ping timeout: 256 seconds]
Superpelican has joined #linux-sunxi
<Superpelican> bfree, oliv3r:I've extracted an uImage from the tinycore linux image that boots on my tablet
<Superpelican> bfree, oliv3r:With the file utility it shows that it's load address and entry point is indeed 0x40008000
tzafrir has quit [Ping timeout: 268 seconds]
<Superpelican> bfree, oliv3r:So that should work on my tablet
<oliv3r> Superpelican: yeap :)
<Superpelican> Got the uImage now, now going to partition my uSD card like then hope my kernel works ;)
<bfree> btw exists now and supports sun4i with emac (cubie anyway, or should, I've not installed it yet to be 1000% sure something between rc4 and rc7 didn't break something) ... I'll be killing my 3.10 off as soon as it appears in experimental and I've checked it (not sure what black hole it has disappeared into atm in terms of that)
<Turl> bfree: :D awesome
<bfree> aaaaah ooops sorry, I've pebkac'd ... too many digits, tired eyes, who knows what, but that above link is rc4 (no emac). rc7 built earlier today alright but hasn't appeared in the archive yet ... the wait continues
<Superpelican> oliv3r:but "bootm 0x48000000" from FirstSteps wiki page is not 0x40008000
<Superpelican> oliv3r:typo on the wiki? Or is it suppose to be different?
<bfree> Superpelican: it is different, that's fine (I use 0x41000000 and 0x48000000 in different setups, both are fine, follow the wiki)
<Superpelican> bfree:Thanks for confirming
<Superpelican> bfree:Does u-boot-sunxi support ext4 as rootfs?
<Superpelican> hmm, answering myself:seems to be supported:
jemk has joined #linux-sunxi
<bfree> Superpelican: "ext4load mmc 0:2 0x41000000 uImage-3.10-rc4-armmp" works for me with a recent sunxi u-boot ;)
<Superpelican> bfree:Great, I just booted the kernel on the tablet :D
<Superpelican> Some errors, but hey, I've made it to the ash shell! ;)
<Superpelican> with sun4i rootfs
Superpelican has quit [Quit: Konversation terminated!]
rz2k has quit []
<oliv3r> mripard_: is it safe to assume this is what greg speaks of:
<mripard_> not this one for what?
<mripard_> you don't have to call any function.
<oliv3r> well that's the attribute group i think
<oliv3r> or was looking at
<oliv3r> well he says pdev->dev
<oliv3r> which isn't device_driver as you sa
<mripard_> stop randomly dropping functions, and tell me what you actually wanna do
<oliv3r> lol
<oliv3r> ok greg says 'Set the
<oliv3r> "groups" field in your platform device->device structure, and all will
<oliv3r> work properly'
<oliv3r> so pdev->dev, which is a struct device; not struct device_driver
<oliv3r> (and I wasn't randomly droppin' functions :(
<oliv3r> which leads to: const struct attribute_group **groups; /* optional groups */
<oliv3r> so we need a const struct attribute_group
<oliv3r> device_create_bin_file(&pdev->dev, &sid_bin_attr); passes an attribute_group
<oliv3r> sorta
<mripard_> but he also said that the race was occuring after you call device_register
<oliv3r> but then i don't understand, i can make an attribute_group; but where to add it?
<mripard_> and device_register is called before your probe function
<mripard_> so whatever you do in probe, you'll still have the race he mentionned
<oliv3r> but where else to pput it :(
<mripard_> I showed you already :)
<oliv3r> you did?
<mripard_> in the plaform_driver->driver struct
<oliv3r> but why did greg say pdev->dev
<oliv3r> oh wait
<oliv3r> i see
<mripard_> platform_ *driver*
<mripard_> not platform_device
<oliv3r> ok that makes sense
<oliv3r> then i have no idea what greg's talkign about :p
<mripard_> I don't either, but here, unless I'm missing a big point, device_register is called way before probe()
<mripard_> so you'll end up with the race he mentionned
<mripard_> so either his explanation about the race was wrong
<mripard_> or his last mail was
<mripard_> which is the link I gave you some time ago ;)
<oliv3r> aye
<oliv3r> but its' better when I link it
<oliv3r> it means i follow :d
<mripard_> true :)
jemk has quit [Read error: Operation timed out]
hramrach__ has quit [Ping timeout: 240 seconds]
hramrach__ has joined #linux-sunxi
<oliv3r> does a struct bin_attribute fit into
<mripard_> nope, only a struct attribute fits here obviously.
<oliv3r> bah
<oliv3r> ok, gotta find a way to glue those two together then
<mripard_> easy
<mripard_> bin_attribute has a struct attribute embedded in it
<oliv3r> yeah but
<oliv3r> how
<oliv3r> i mean, .attr = bin_attribute.attribute?
<mripard_> yeah
<oliv3r> and whoever invokes the stuffs does some reverse fancy stuff
<oliv3r> kinda like container_of?
<mripard_> well, not completely, since one is a pointer and the other isn't but yeah.
<mripard_> I think so
<mripard_> look at the code if you want to find out :)
<oliv3r> :p
<oliv3r> i didn't know you where allowed to do trickeries like that :D
notmart has quit [Quit: notmart terminated!]
<mripard_> how would you do object oriented programming in C otherwise ? :)
<oliv3r> :p
<mripard_> h/wi20
<mripard_> grmbl.
<oliv3r> i find it so awesome that free-electrons lxr always shows up top
<oliv3r> what's wrong wit wip/a20?
<mripard_> nah
<mripard_> i meant to type /window 20
<oliv3r> that many? ouch
<mripard_> much more :)
<oliv3r> all on freenode?
<mripard_> ~10 on freenode
<oliv3r> how is multiserver support these days, i still run 3 seperate irssi's for 3 networks
<oliv3r> it used to be iffy back int he day
<mripard_> never had any problems
<mripard_> and I've used it for like 8 years
tzafrir has joined #linux-sunxi
<oliv3r> i'll sadly admit this may be from 8-10 years ago
<oliv3r> mripard_: you know what free-electrons should invtent
<oliv3r> SD-card reader for the brain
<oliv3r> easy upload of all kernel skill
<mripard_> nah
<mripard_> that would ruin our business model :)
<oliv3r> you'd sell the brain-probe!
<mripard_> but I would surely benefit from it.
<oliv3r> :p
<Turl> oliv3r: :P I usually have 20something-30 on my irssi
<oliv3r> i have 6 right now :p
<Turl> most on freenode, a couple on OFTC
<Turl> I admit I don't read most of them, I'm just there for "pingability" :P
<oliv3r> lol
<oliv3r> well i joined the team-hacksung and replicant ones only to get some info
<oliv3r> and since it takes hours usually; i haven't left there yet
<oliv3r> i'm in olimex because i was waiting for tsvetsan to confirm me something
<oliv3r> there 1 down :p
n01_ has quit [Ping timeout: 248 seconds]
paulk-desktop has quit [Quit: Ex-Chat]
ojn has quit [Ping timeout: 240 seconds]
BJfreeman has quit [Ping timeout: 252 seconds]
_BJFreeman has joined #linux-sunxi
_BJFreeman is now known as BJfreeman
<Turl> mripard_: hi
ibrah has quit [Ping timeout: 248 seconds]
<Turl> mripard_: do these patches you just sent improve the situation with the "too round" times when eg. pinging?
<mripard_> Turl: indeed
<mripard_> the clocksource addition actually
<mripard_> but I'm really wondering how it could work in the first place
uwe_ has quit [Read error: Operation timed out]
<mripard_> I'm off to bed now, sorry
<Turl> mripard_: great :)
<Turl> mripard_: good night :) I'll give them a try in a bit
uwe_ has joined #linux-sunxi
uwe_ has quit [Ping timeout: 240 seconds]
tinti has quit [Quit: Leaving]
uwe_ has joined #linux-sunxi
Soru has quit [Ping timeout: 256 seconds]
Soru has joined #linux-sunxi
hramrach__ has quit [Ping timeout: 240 seconds]
hramrach__ has joined #linux-sunxi
zrafa has joined #linux-sunxi
vicenteH has quit [Ping timeout: 240 seconds]