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>
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>
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
<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
<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? linux-sunxi.org/FirstSteps :"fatload mmc 0 0x48000000 uImage"
<oliv3r>
Superpelican: use 'split_bootimg.pl'
<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>
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 linux-sunxi.org/FirstSteps then hope my kernel works ;)
<bfree>
btw http.debian.net/debian/pool/main/l/linux/linux-image-3.10-rc4-armmp_3.10%7erc4-1%7eexp1_armhf.deb 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 dl.linux-sunxi.org 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?