<leviathanch>
we lack ddr mode support in our driver
<leviathanch>
since the implementation of the original chinese code
<leviathanch>
was inacceptable to be included into mainline
<leviathanch>
unless we do not find a little bit more spare time
<leviathanch>
we do not provide this feature
<leviathanch>
which means that all cards relying on ddr mode
<leviathanch>
will not work properly
hypophthalmus has quit [Quit: Leaving.]
<mrnuke>
leviathanch: I have no idea what ddr mode is, or how it's fixable, but what I can say is that it worked just fine with sunxi-devel before it was rebased on 3.14-rc3
<leviathanch>
mrnuke: yes!
<leviathanch>
mrnuke: it was working but had no chance to be mainlined
<leviathanch>
we will need to redo the chinese code
<leviathanch>
and reincorporate it into the recent driver
<Turl>
leviathanch: can you at least not hang the system meanwhile? :p
<mrnuke>
ooh, so old code was made in china?
<Turl>
mrnuke: AW is a chinese company :)
<Turl>
in case you didn't notice haha
<mrnuke>
Turl: kernel waits for root partition to mount due to "rootwait" parameter
<mrnuke>
Turl: I didn't realize the pre-rebase code was the chinese version.
<Turl>
mrnuke: ah, so it's not really hanging
<mrnuke>
Turl: well, without "rootwait" it reboots before it gets the chance to mount the root anyway
<mrnuke>
both pre- and post-rebase
t3st3r has joined #linux-sunxi
<mrnuke>
ooh DDR is sending data on both rising and falling edge, right?
dlan__ has joined #linux-sunxi
<Turl>
mrnuke: that must be it
dlan__ is now known as dlan^
<mrnuke>
so, no way to force the card in SDR mode?
hypophthalmus has joined #linux-sunxi
hypophthalmus has quit [Client Quit]
egbert has quit [Read error: Operation timed out]
egbert has joined #linux-sunxi
<Turl>
mrnuke: dunno :)
chinas has quit [Remote host closed the connection]
hypophthalmus has joined #linux-sunxi
hypophthalmus has quit [Quit: Leaving.]
pwhalen has quit [Ping timeout: 240 seconds]
pwhalen has joined #linux-sunxi
<memleak>
what is "nandinstall mod" ?
<memleak>
if something (a cubieboard image) does not support "nandinstall mod" can it be installed to nand or no?
FDCX has quit [Remote host closed the connection]
FDCX has joined #linux-sunxi
<wens>
mrnuke: it's not that pre 3.14-rc3 sunxi-devel was allwinner code, it's that hans ripped out DDR mode in 3.14-rc3
<memleak>
does anyone else here listen to dubstep while doing kernel development for cubieboard?
t3st3r has quit [Remote host closed the connection]
t3st3r has joined #linux-sunxi
<mrnuke>
wens: I still have a uImage with "Linux-3.13.0-rc6-10898-g1379355" from an old sunxi-devel which boots okay from MMC
<mrnuke>
same card, same hardware, same uboot config, same etc...
TheSeven has quit [Disconnected by services]
[7] has joined #linux-sunxi
souther has quit [Ping timeout: 244 seconds]
denkins has joined #linux-sunxi
mrnuke has quit [Ping timeout: 240 seconds]
hipboi has joined #linux-sunxi
mrnuke has joined #linux-sunxi
hipboi has quit [Read error: Connection reset by peer]
hipboi has joined #linux-sunxi
hipboi has quit [Read error: Connection reset by peer]
hipboi has joined #linux-sunxi
hipboi has quit [Read error: Connection reset by peer]
hipboi has joined #linux-sunxi
hipboi has quit [Read error: Connection reset by peer]
hipboi has joined #linux-sunxi
hipboi has quit [Read error: Connection reset by peer]
hipboi has joined #linux-sunxi
mrnuke has quit [Ping timeout: 240 seconds]
HeHoPMaJIeH has joined #linux-sunxi
HeHoPMaJIeH has quit [Changing host]
HeHoPMaJIeH has joined #linux-sunxi
mrnuke has joined #linux-sunxi
denkins has quit [Remote host closed the connection]
lynxis has joined #linux-sunxi
bluse_ has joined #linux-sunxi
Net147 has joined #linux-sunxi
<Net147>
sometimes when rebooting my A20 hangs for a minute or two. any ideas what may be causing it?
<t3st3r>
boot ROM waits for something until timeout?
<Net147>
it's when the machine is in the process of shutting down / rebooting. before u-boot starts again.
<Net147>
it tends to happen when I am running off SD card
<Net147>
previously I have been using NFS boot
<t3st3r>
[11:17:45] <Net147> it's when the machine is in the process of shutting down / rebooting. before u-boot starts again. <- sounds like it maybe stuck in bootROM, waiting for something?
<Net147>
I think the kernel is still running when it's hanging
<Net147>
I get no output after I type reboot and press enter and it stays like that for 2 minutes or so. then I get "<46>systemd-journald[72]: Received SIGTERM", "<6>EXT4-fs (mmcblk0p2): re-mounted. Opts: (null)", OCHI shuts down, ECHI shuts down and then it restarts the system
aaribaud has joined #linux-sunxi
<Net147>
it hanged for 5 minutes this time
Quarx has joined #linux-sunxi
<Net147>
nevermind, I think it's probably a service hanging...
FreezingCold has quit [Ping timeout: 240 seconds]
t3st3r has quit [Ping timeout: 265 seconds]
_massi_ has joined #linux-sunxi
sehraf has joined #linux-sunxi
sehraf has quit [Client Quit]
sehraf has joined #linux-sunxi
hipboi has quit [Read error: Connection reset by peer]
t3st3r has joined #linux-sunxi
FreezingCold has joined #linux-sunxi
ganbold has quit [Remote host closed the connection]
ganbold has joined #linux-sunxi
hipboi has joined #linux-sunxi
jemk has joined #linux-sunxi
t3st3r has quit [Remote host closed the connection]
t3st3r has joined #linux-sunxi
<rellla>
jemk: i tested your osd-performance code. seems much more optimized, (freaky) osd at least disappears completely after osd timeout. g2d crash still remains, even with timeout = 100. and it's not reproducible for me
popolon has joined #linux-sunxi
popolon has joined #linux-sunxi
Black_Horseman has quit [Quit: Zwi se logou mou!!!]
<jemk>
that shouldn't be a problem, there are no registers after 0x7ff
<jemk>
maybe you simply have reached the memory bandwidth limit and g2d doesn't get its data fast enough, i only have a 1280x1024 screen, so much less traffic there
_hipboi_ has quit [Read error: Connection reset by peer]
_hipboi_ has joined #linux-sunxi
<ssvb>
jemk: what happens if the timeout value is increased?
<jemk>
ssvb: it doesn't crash for even bigger images, tested up to 8192^2 which should be the hw limit
<jemk>
but i don't need to increase it for normal usage, others like rellla have crashes even with increased timeout
<rellla>
ssvb: i set timeout=100, but crashes, too. it's not while running the program, but after a restart. somtimes after the 2nd restart.
<rellla>
jemk: after the crash. it's fine, until the "wait g2d irq pending flag timeout" message appears in dmesg
<rellla>
i only can force it with (1+n) restarts. sometimes it even hangs after a reboot, but it's the only way to get rid of it. rmmod g2d_23 and sunxi_cedar_mod doesn't have any effect
<rellla>
and it's gone, when setting VDPAU_OSD=0 ;)
Net147 has joined #linux-sunxi
bbrezillon has joined #linux-sunxi
bbrezillon has quit [Client Quit]
notmart has quit [Quit: notmart terminated!]
xeros has quit [Ping timeout: 240 seconds]
notmart has joined #linux-sunxi
Quarx|2 has joined #linux-sunxi
Quarx has quit [Read error: Connection reset by peer]
<rm>
wens, maybe you're translating from the wrong chinese
<rm>
I think I remember you can choose either Traditional or Simplified as src language
<rm>
but in one case the result won't make any sense
<rm>
or no, wait
<rm>
it was an encoding issue
shineworld has joined #linux-sunxi
<rm>
with non-utf multibyte encodings, where I was picking the wrong one, and the decoded text still looked non-garbled etc
<rm>
just all the characters were wrong
<Turl>
ccaione: s/mondays/waking up early in mondays/
leviathanch has quit [Read error: Connection reset by peer]
leviathanch has joined #linux-sunxi
<ccaione>
well, every monday I wake up at 7am :)
<wens>
rm: nah, that's not the problem
<Turl>
ccaione: that's pretty late
<wens>
it's like whoever wrote it is babbling along without any full stops
<wens>
ccaione: let me know what you need, I only started the interrupts section
<wens>
might need mripard to hack up the push-pull interface first :p
<ccaione>
wens: +1 was for supporting you :P first I have to made AXP202/209 merged, it will take a while
<wens>
ccaione: let me rephrase, what part is most important
<ccaione>
wens: is the axp221 somehow compatible with axp202/209?
Black_Horseman has quit [Remote host closed the connection]
<wens>
it looks mostly the same, just a whole lot more outputs, more than double
<plaes>
could be for clocking different cores?
<mripard>
ccaione: it uses a weird i2c-looking bus
<mripard>
so it might be similar, but the way you actually talk to it is pretty different
<ccaione>
mripard: not a real one? weird. let me see it
<Turl>
wens: they use two AXP221 for the newer devices don't they?
<ccaione>
mripard: ^^^ that's why the axp,system-power-controller ;)
<mripard>
ccaione: on the schematics at least, the optimusboard has two different PMICs, with different part names
<mripard>
AXP806 and 809
<mripard>
so nope, still no need for your property :)
<ccaione>
hahhhah ok :D
<mripard>
hmm, not the schematics, a picture of the board
<Turl>
mripard: I was gonna ask you for the schematics :p
<mripard>
and I wonder if the 806 is not for the AC100 thing we have no idea what it's about :)
<mripard>
and the 809 being the main one
<Turl>
mripard: we know it's for suspend/resume/stuffs
<ccaione>
mripard: my chinese in not that good. Why do you say that it is a i2c-looking and not a real i2c?
<mripard>
ccaione: from the stuff I've seen, it's pretty much a plain i2c
<mripard>
except that at the end of each byte, you have a parity bit
<ccaione>
but, is this info in this datasheet?
<mripard>
probably
<mripard>
but it's all chinese to me :)
<ccaione>
hahhaah yeah
code-ninja has joined #linux-sunxi
<wens>
nothing in the A23 manual :/
<code-ninja>
hello everyone :). Since my last presence here, I have finally managed to make the FT5x touch panel to work on the A20. I can see the drags (like that box you get when you drag the pointer) but I'm unable to register touch events. Any ideas?
mkutsevol has joined #linux-sunxi
<code-ninja>
and it is totally uncalibrated by the way...
<code-ninja>
will changing the screen resolution work? My tablet's current script.fex shows 1024*600
<code-ninja>
it works like a charm on the A13
<code-ninja>
just build the SD card and you are done.
y0g1 has quit [Ping timeout: 255 seconds]
<oliv3r>
Turl: if you get to review my fedora chapter, make a big note i should switch to fedora2 0
code-ninja has quit [Read error: Operation timed out]
y0g1 has joined #linux-sunxi
pwhalen has quit [Ping timeout: 240 seconds]
<Turl>
oliv3r: I haven't heard a word from packt yet
pwhalen has joined #linux-sunxi
pwhalen has quit [Changing host]
pwhalen has joined #linux-sunxi
<Turl>
oliv3r: do you want to rewrite that chapter and need an excuse? :p
<Turl>
oliv3r: I can write them and ask what's up if you want btw
<Turl>
to them*
souther has joined #linux-sunxi
ganbold_ has joined #linux-sunxi
enrico_ has quit [Quit: No Ping reply in 180 seconds.]
<WarheadsSE>
mrnuke: I haven't built a kernel recently
<tyler-baker>
first reset the board, then reset it again :)
<tyler-baker>
trying to automate it so I can test the upstream kernel trees on it
<mrnuke>
WarheadsSE: I asked because there might be some b0rkag3 in the MMC layer with latest sunxi-devel
<hno>
tyler-baker, if you have rx (and gnd) connected while device powered on then there is all kinds of vierd current leakage going on with your uart cable partially powering the board.
<hno>
powrerd off I mean.
<tyler-baker>
hno: yeah that is what I was noticing
<hno>
There is a simple hardware fix. Olimex have done it on some of their boards.
<hno>
adding a diode and pullup resistor on the rx line, making sure that the UARD cable never drives any power into the board, only sink power when signalling a 0.
<tyler-baker>
hno: ah ok that makes perfect sense
<hno>
for most uses the diode is likely sufficient.
<mrnuke>
hno: that might interfere with UART signaling at ludicrously high baudrates (921600 and friends)
popolon has joined #linux-sunxi
popolon has quit [Changing host]
popolon has joined #linux-sunxi
<hno>
mrnuke, yes quite likely, and there is pads on the inside of the diode on those boards iirc.
<mrnuke>
but yeah, I've noticed LEDs randomly popping on when the UART is plugged in
<hno>
but normally the console is at 115200 where this is a non-issue.
<hno>
(the slower rise due to diode + pullup)
netlynx has joined #linux-sunxi
<tyler-baker>
hno: is it possible to remove the nand bootloader?
<tyler-baker>
hno: I've tried erasing the nand block device device from userspace but the bootloader still persists
<oliv3r>
mrnuke: the water bottle was my attempt to 'slow down'
<mrnuke>
oliv3r: considered getting a bigger bottle? :p
<oliv3r>
mrnuke: what do you remember specifically as a 'new fact'
<mrnuke>
the olimex LIME is tinyer than I imagined it
<oliv3r>
mrnuke: nothing much really then ;)
<oliv3r>
and the water bottle was sized fine, i need to be less nervous and talk slower :p
<oliv3r>
then again; i'd run out of time :)
<mrnuke>
oliv3r: well, I'm "crazy enough" to know everything :p
<mrnuke>
except why the MMC is freezing. Apparently I'm not insane enough for that
<oliv3r>
:p
<mrnuke>
but once I have the two logs and diff of driver between 2 branches, I'll attack the ML next
<oliv3r>
how's the coreboot coming?
FR^2 has quit [Quit: Connection reset by peer]
<mrnuke>
coreboot is pretty much done except the MMC. I think we might make that a GSoC project. The uboot code is completely unsuited for our needs
shineworld has quit [Quit: Leaving]
<mrnuke>
although I do have a branch were the MMC is plugged in, and I can boot whatever I want off it
<oliv3r>
oh that was quick then ;)
<hno>
tyler-baker, yes it is possible to disable the nand bootloader, but does not help SD booting. All you accomplish by that is that the device enters FEL boot mode when SD boot fails.
<oliv3r>
i guess we can use your cleanup of the dram stuff; to clean the u-boot stuff up :)
<oliv3r>
you tested all the pitfalls of rearanging stuff i'm sure :)
<hno>
The boot blocks are not addressable on the /dev/nand block device.
<tyler-baker>
hno: ack thanks for the info
<mrnuke>
oliv3r: I only cleaned up the udelay usage. I might need to pretty-ize the code once I add A20 support
<mrnuke>
oliv3r: but have no fear... If I make a change that I know for a fact will make me look super-intelligent, super-human, and the best hax03 ever, I'll port it to sunxi-uboot and submit it for review ;)
diego_r has quit [Ping timeout: 240 seconds]
<oliv3r>
sa-weet
shineworld has joined #linux-sunxi
shineworld has quit [Client Quit]
notmart has quit [Quit: notmart terminated!]
undrwater has joined #linux-sunxi
hypophthalmus has quit [Quit: Leaving.]
ykchavan has joined #linux-sunxi
<mrnuke>
alright. Mail sent. let the bikeshedding begin!
<oliv3r>
i dun see nothin'
<mrnuke>
linux-sunxi@googlegroups.com ?
<oliv3r>
i don't see it yet
<mrnuke>
could it be forwarded to /dev/null due to attachments?
netlynx has quit [Quit: Leaving]
<mrnuke>
or am I blocked from posting due to not being subscribed?
<oliv3r>
nope and nope
<oliv3r>
delayed or ggroups being retarded
<mrnuke>
daamn. i had some really good info there
tonikasch has joined #linux-sunxi
<tonikasch>
Hi! Do you know where to get latest xf86-video-mali? I'm trying to get it working on another device and have seen there are patches to make it work on 1.13 and later
<mrnuke>
Turl: thanks for the wisdom. I would have spent weeks analyzing the diff in the MMC driver, although the issue was somewhere else
<Turl>
mrnuke: anytime
<Turl>
mrnuke: so it was just the compatible? heh
<mrnuke>
yeah
<Turl>
leviathanch: ^ fixit! :)
<mrnuke>
is the patch fine like that, or should I send it to the list?
<Turl>
mrnuke: looks ok, it probably will need to be squashed into the original one for the next time leviathanch sends the mmc series
<Turl>
mrnuke: reply to "[PATCH v7 6/8] ARM: dts: sun4i: Add support for mmc" on linux-sunxi/lakml pointing out the error, attach the patch if you want to
<leviathanch>
Turl: ouch
<leviathanch>
yes, I will fix this
<leviathanch>
damnit
<leviathanch>
Turl: I'm just too busy right now at work
<leviathanch>
...
<leviathanch>
in order to publish another patchset
<leviathanch>
hmm
Fusing has quit [Ping timeout: 240 seconds]
Fusing has joined #linux-sunxi
<leviathanch>
the day after tomorrow
<leviathanch>
in the evening
<leviathanch>
I will publish another one
<leviathanch>
to merged into sunxi-devel
<Turl>
leviathanch: I'm in no hurry, I just didn't want it to be forgotten
<Turl>
ok :)
<leviathanch>
Turl: ok ;-)
<Turl>
mrnuke: there was some other person around here with mmc issues, you may want to let them know
<leviathanch>
Turl: we are missing Luc Verhaegens sunxi-kms as well
<leviathanch>
where is his driver anyway?!
<Turl>
leviathanch: it's for 3.4 isn't it?
<Turl>
we don't have DMA yet on any soc that's not A31
<leviathanch>
oh
<Turl>
hopefully to be solved on GSoC :)
<mrnuke>
Turl: not sure who that was. No one's nick here rings a bell
<mrnuke>
Anyhow, I've somehow managed to reply to a post in a list I am not subscribed to
<Turl>
I got your reply :)
<Turl>
mrnuke: you can use gmane to subscribe
<Turl>
NNTP is pretty quick
<mrnuke>
I don't want to subscribe (yet). I have too many folders and filters in my IMAP already :(
<Turl>
mrnuke: well it's not a subscription in the typical sense
<Turl>
you don't get any email
<Turl>
it's a newsgroup thingy
<Turl>
you can browse the subjects, read stuff you may care about, and reply (in theory, never tried)
<mrnuke>
so, it's all web based?
<Turl>
well it has a web interface
<Turl>
you can use a desktop newsgroup client as well
<mrnuke>
I'm actually surprised they made it as far as staging
<tonikasch>
hey, sorry to bother you but... do you know hypotetically which changes would be needed for sunxi mali gpu driver to be build in another arm platform? I have succesfully built it copying it to my kernel tree and adding own platform "arch-"/ file both in mali/mali/ and mali/ump/ but resulting mali.ko file makes system reboot with no message printed to /var/log/kern.log
<Turl>
tonikasch: as far as I recall there's nothing magical on the sunxi mali kernel driver
<Turl>
it's just the one from malidevelopers with the glue to make it work on sunxi
<tonikasch>
aha, ok, thanks, will keep trying, perhaps adding printk on each event on module, I guess not the ideal way but still learning all these things
<Turl>
tonikasch: make sure the memory reservation is correct
<Turl>
I think that's like the most critical thing you need to take care of
<tonikasch>
do you know what file(s) that is stated on?
<Turl>
mali/arch-blahblah/config.h; and the reservation is made on your board files/DT
<tonikasch>
ahh, thanks, that's it
bbrezillon has quit [Ping timeout: 240 seconds]
FreezingCold has joined #linux-sunxi
ganbold_ has quit [Remote host closed the connection]
<mrnuke>
Yay! zram works. Now let's check /dev/spidev
bertrik has quit [Remote host closed the connection]