<ssvb>
techn_: but it's mmap for /dev/disp, and not /dev/fb0
<ssvb>
techn_: I can't reproduce any problem by stuffing characters and then erasing them via writing to /dev/tty0
<ssvb>
is there any other mapping for the framebuffer?
<techn_>
it could be easier reproduce with 60mhz
<ssvb>
aha, will try that
<ssvb>
techn_: is it mk802 specific or maybe somebody has seen this on the other a10 devices?
soooga has joined #arm-netbook
<ssvb>
techn_: do you have CONFIG_FB_SUNXI_RESERVED_MEM enabled?
stefanro1 has joined #arm-netbook
drgreenthumb has quit [Ping timeout: 245 seconds]
stefanro has quit [Ping timeout: 248 seconds]
<ssvb>
techn_: in any case, it might be so that the kernelspace mapping of the framebuffer is cached (and used by fbcon), while the userspace mapping is writecombine
<ssvb>
so it does not even boot for me without CONFIG_FB_SUNXI_RESERVED_MEM
XenGi is now known as XenGi_
hg_5 has quit [Ping timeout: 265 seconds]
<buZz>
hehe i have that sticky pixel problem aswell
<buZz>
supereasy to reproduce; 1) type a multiword command on (fbdev) console 2) ctrl-left a word 3) delete its first character 4) tada, sticky pixels
penguin42 has quit [Quit: Leaving.]
<ssvb>
buZz: thanks, I'll try that
<ssvb>
actually I have already reproduced the problem by enabling write-allocate cache policy, but that's a bit artificial :)
<ssvb>
buZz: thanks a lot, your testcase is clearly easily reproducible
<ssvb>
now let's fix it
merbzt has quit [Ping timeout: 260 seconds]
XenGi_ is now known as XenGi
dfletcher has joined #arm-netbook
dfletcher has quit [Changing host]
dfletcher has joined #arm-netbook
dfletcher is now known as drgreenthumb
<buZz>
yay oncoming improvement \o/
jlj has quit [Ping timeout: 240 seconds]
jlj has joined #arm-netbook
jlj has quit [Ping timeout: 264 seconds]
<L84Supper>
buZz: I was just looking at your model for the cubieboard case
<L84Supper>
buZz: what tool are you designing with?
jlj has joined #arm-netbook
<Turl>
re. (00:58:18) bsdfox_: [18:20:54] wow changing mali clkdiv from 4 to 3 improved my glmark2 score from 25 to 44
<Turl>
bsdfox_: I think it's the default on some devices
<hramrach>
I guess the cable is connected correctly
<hramrach>
gnd is connected to gnd and if rx and tx were swapped nothing would be visible
<hramrach>
swapping rx and gnd does not make any difference
<hramrach>
tx is obviously correct since messages are transmitted
<hramrach>
at least I can confirm that u-boot built with gnueabihf works no worse than u-boot shipped on tha flash
hansg has joined #arm-netbook
<hramrach>
which mailing list?
<techn_>
hramrach: newermind.. I though that you had problem with usb
<techn_>
hramrach: telnet client problem?
<hramrach>
I used this one in the past
<hramrach>
and it worked
jlj_ has quit [Ping timeout: 255 seconds]
jlj has joined #arm-netbook
jlj has quit [Ping timeout: 252 seconds]
jlj has joined #arm-netbook
jlj has quit [Ping timeout: 264 seconds]
jlj has joined #arm-netbook
jlj has quit [Ping timeout: 276 seconds]
jlj has joined #arm-netbook
<hramrach>
also there is something wrong with boot messages
<hramrach>
I see them on the serial port until the serial port is initialized
<hramrach>
the last message being <6>sunxi-uart.0: ttyS0 at MMIO 0x1c28000 (irq = 1) is a U6_16550A
<libv>
first boot tends to be ok
<libv>
so known annoyance, please fix :)
<hramrach>
I get DVI output whan I load the dri modules as described on the Mali400 page
<libv>
you mean disp modules, right?
<hramrach>
there is like half dozen
<hramrach>
hdmi, dri, whatnot
<hansg>
hramrach, the hang on loading the serial driver sounds familiar, try disabling the serial console, make sure you've no console=ttyS0 on your kernel cmdline anywhere, and make sure the modules for DVI out are loaded automatically, then you'll like see a lot of these messages on the dvi console: "
<hansg>
">>> no handle, treat it handle over"
<hramrach>
hansg: I do want the serial console
<hansg>
I've been debugging this issue today, as I've one A10 based "machine" which does this always
<hramrach>
but it is not working
<hansg>
Even on the first boot
<hramrach>
I get the messages until that point and then long delay and login prompt
<hansg>
hramrach, I've a fix, I'm just finalizing it, expect a patchset send to the list in a few minutes
<hramrach>
thanks
<hramrach>
but I suspect a more basic problem as well
<hansg>
hramrach, ah, different problem. If you do get a serial login prompt, then the problem is that you should add a console=ttyS0 to the kernel cmdline
<hramrach>
I even u-boot does not accept serial input
<hramrach>
I do have that
<hramrach>
but the console messages stop when the port is initialized
<hansg>
hramrach, ah, that is yet another problem (u-boot not accepting serial input)
<hramrach>
login is not accepting serial input either
<hansg>
hramrach, be sure to add 115200, ie: console=ttyS0,115200
<hramrach>
that I possibly don't have
<hansg>
As for not accepting serial input, make sure you're not using hardware flowcontrol on the serial port. IE cu will use that if it was set on the port before
<hansg>
And since there are no handshaking lines that won't work.
<hansg>
Also check your cables. The first step in debugging this is to make u-boot accept serial input
<libv>
the vanishing of the serial output is a known issue
<hramrach>
as far as I can tell the cable is connected correctly
ganbold__ has joined #arm-netbook
<libv>
with me it happens on reboots, but not on a cold boot
<hramrach>
It happens every time for me
<hramrach>
no serial input whatsoever
<hansg>
hramrach, what serial terminal app are you using ?
<libv>
then these are two separate issues
<hramrach>
cu
<hramrach>
can't find the options for hardware control
jlj has quit [Ping timeout: 252 seconds]
<hansg>
hramrach, right, cu does not have any. I've been bitten by this too, to fix, do: "stty -F /dev/ttyUSB0 -crtscts", and then start cu
<hansg>
Assuming you're using a usb<->serial convertor
ganbold___ has quit [Ping timeout: 252 seconds]
jlj has joined #arm-netbook
<hramrach>
doe not change aything
<hramrach>
ah, only slow now
<hansg>
so you've input now ?
<hramrach>
yes, it works now. Thanks
<hansg>
:)
<hansg>
libv, I've just (seconds ago) send a patchset fixing various issues with the sunxi serial port code, perhaps it fixes the console-output disappearing problem ?
<hansg>
I started looking at it because of a stuck interrupt issue I was having. But I also found it addressing a completely wrong pointer in sw_serial_pm, so my fixes may help.
<hramrach>
uh, the cmdline is not passed
<specing>
ARM uarts are quite complex
<hramrach>
no, wrong terminal
<hramrach>
I have only console=ttyS0 so there is even areason for it disappearing
<specing>
I remember I couldn't get it to run properly (it only printed square boxes to my terminal) after fiddling with that cortex-m4f's registers through GDB for 8h
<hramrach>
if the default speed is different
<hramrach>
it is pretty much working here
<hramrach>
less package version 444-4 ;-)
<hramrach>
the apt is slow /o\
<hramrach>
can I make one of the leds into hdd light?
<hramrach>
I guess that's too board-specific :s
<hramrach>
teh serian even works with u-boot now
<hramrach>
yeah, with correct console parameters I get all output
provel_ has joined #arm-netbook
<hramrach>
there is something wrong with the serial still
<hramrach>
the screen size is incorrect
hansg is now known as hansg_afk
<hramrach>
seens the edid works correctly \o/
jlj has quit [Ping timeout: 255 seconds]
jlj has joined #arm-netbook
jlj has quit [Ping timeout: 255 seconds]
jlj has joined #arm-netbook
<hramrach>
how do I set up serial so that the remote and can talk to the local terminal emulater and get stuff like screen size?
<hramrach>
nothing I saw so far does that
<hramrach>
you have choice of cu that does pretty much nothing but atleaset is simple and minicom which is rather baroqua, asinine, and in the end has no feature over cu
<buZz>
minicom can turn on/off flow control though ;)
<hramrach>
stty can do that too
<buZz>
yes
<hramrach>
and with cu you can specify which port you want to open
<hramrach>
so it's one feature gained for one lost
<buZz>
minicom can do that aswell
<hramrach>
no, it cannot
<buZz>
minicom -D /dev/ttyUSB0
<hramrach>
you have to do that in the menu
<buZz>
etc
<hramrach>
oh, so they at least fixed that
<buZz>
about 6 years ago :D
<hramrach>
that's about the time when I gave up using that
<buZz>
you can also use screen as serial terminal
<buZz>
but i dont know any that send screensize
<hramrach>
that's cool
<hramrach>
screen does not?
<buZz>
havent checked
<provel_>
hum... is there a way to redirect mele a2000 serial output to conserver ?
<buZz>
but serial terminal is not so mainstream
<hramrach>
how not mainstream?
<buZz>
provel_: you can log serial data with minicom etc
<hramrach>
every PC has that
<hramrach>
:p
<buZz>
hramrach: about 20 years ago many ppl still used serial terminals daily
<buZz>
but now, not so much
<provel_>
buZz : yes, but I want to log serial data in transmission... without serial cable
<hramrach>
I use it every time my PC is dying
<specing>
provel_: attach a MCU to it
<buZz>
yes, not daily
<hramrach>
I would use it more if it worked
<buZz>
thats nice, go fix it :)
<hramrach>
cba fixing it
<hramrach>
you can use ssh too
ZaEarl has joined #arm-netbook
<buZz>
ssh is not a serial terminal
<hramrach>
it is not
<hramrach>
but when hte system is not dying it works pretty much as nicely as serial terminal
<buZz>
i use ssh 24/7
hg_5 has joined #arm-netbook
<hramrach>
hmm, does not work with screen either
jlj has quit [Ping timeout: 260 seconds]
<hramrach>
hmm, I get the sticky pixels all right
jlj has joined #arm-netbook
Quarx has quit []
ganbold__ has quit [Remote host closed the connection]
<penguin42>
are there any standard setups for doing networking via otg ports connected to a host pc?
<penguin42>
(something like the adb ppp setup does?)
<hramrach>
none that I know of
<hramrach>
but you could do ppp over the serial port
<hramrach>
if you have the cable
<hramrach>
or slip
<penguin42>
well, I haven't got serial on this board - I guess I could pop it open, but I'm guessing there is a usb-gadget to run a serial port emulation, and that would be perfect - then I wouldn't need to go via USB-ether
<hramrach>
maybe look at the usb gadget docs in kernel then
<hramrach>
would be cool to emulate enough ports so that you can have console *and* ppp *and* power with a single standard mini-usb cable
<penguin42>
hramrach: Well exactly
jlj has quit [Ping timeout: 260 seconds]
<hramrach>
I do have a serial cable so not really an issue
<penguin42>
right, but the bitrate on serial is YAWN
jlj has joined #arm-netbook
<penguin42>
I've got a 400mbps USB connection here
<hramrach>
good enough for terminal
<hramrach>
eternet for networking
<penguin42>
yeh, so I wanted to avoid the ethernet altogether
<hramrach>
would have to set up routing on the PC
<hramrach>
but cool nontheless
<specing>
I've uploaded kernels over serial before
<penguin42>
that's easy enough
<penguin42>
specing: But it's not a fun and edifying experience
<specing>
10KB/s for a 3MB image = ~ 5 minutes
<penguin42>
exactly
<penguin42>
ooh, there is a g_ether driver
<specing>
it was still faster than transferring it over scp, flashing and rebooting
<specing>
last time I tried g_ether and g_serial on A10 it didn't go well
<specing>
it didn't work
<penguin42>
this is an rk3066
<specing>
ah
<hramrach>
maybe it improved
<penguin42>
specing: But doesn't adb use g_serial or similar?
<hramrach>
and if it did not maybe it can be fixed
<specing>
penguin42: no
<penguin42>
what does it do?
<specing>
idk
<specing>
all I know is that g_serial didn't work for me
jlj has quit [Ping timeout: 260 seconds]
<specing>
thus my Gentoo/A10 efforts were abandoned due to no rx port to login
<penguin42>
hmm the gadget stuff can be done in user space (gadgetfs)
<hramrach>
you can send ppp frames over anything that can deliver data
<hramrach>
no need to have actual serial port
<penguin42>
such as pidgeons
jlj has joined #arm-netbook
<specing>
rfc 1149
<hramrach>
indeed
<hramrach>
or adb
hansg_afk has quit [Quit: Leaving]
merbzt has quit [Ping timeout: 276 seconds]
<hramrach>
how do you get the patches from google gropus in um-mangled form?
<netchip>
hey
<netchip>
how can I locate the UART pins?
<hramrach>
ho
<hramrach>
reading schematics?
jlj has quit [Ping timeout: 260 seconds]
<netchip>
hramrach, do you have any examples?
jlj has joined #arm-netbook
<hramrach>
no. I just read some wiki pages saying where the pins are
<hramrach>
for what device?
<netchip>
I don't mind which, I jsut want to learn how to locate them ;)
<netchip>
especially for Allwinner/Exynos
<penguin42>
netchip: You're generally looking for a set of 3-4 pins; a rx, tx and ground and maybe some flow control pins
<hramrach>
it's generally very hard with BGA chip and multiple layer PCB to trace the connections so you just look for something that looks slike a serial header
<specing>
< netchip> how can I locate the UART pins?
<hramrach>
and shows how the pin voltages changes over time
<netchip>
specing, AdamOutler (check Youtube for the livestream) located the pins by trying
<hramrach>
so you can compare the graph you get with what you think a serial line would look like
<netchip>
but I think that's pretty inefficient
<specing>
netchip: I did the same thing
<netchip>
ah
<netchip>
specing, he did with his bus pirate...
<netchip>
just trying until he got something useful
<specing>
just that I have better equipment
<netchip>
in his console
<hramrach>
given device with few pins it's quite efficient
<jelly-home>
specing: just $200? What kind of sampling freq
<specing>
jelly-home: 20 MHz :)
<RaYmAn>
usually there aren't that many left over test points that it's an issue
<hramrach>
good enough for serial
<RaYmAn>
(trying them all that is)
<jelly-home>
good enough for serial ;-)
<netchip>
<hramrach> given device with few pins it's quite efficient - oscilloscope or bus pirate?
<hramrach>
either
<hramrach>
or just connecting a serial cable, whatever
<specing>
well my A10 board has over 500 test points
<netchip>
ah...
<specing>
took me 4 days to go through all the pins/uarts
<netchip>
well, how do you know the voltage on the pins? Maybe you blow the board up, I don't know...
<specing>
because the stock kernel couldn't use more than 4 UARTs at the same time
<specing>
netchip: you measure it
<hramrach>
it's in the chip datasheet
<hramrach>
and you read the volatge so you don't blow it
<netchip>
with bus pirate?
<specing>
netchip: oscilloscope
<hramrach>
you don't connect tx
<netchip>
Yeah but if you don't have an oscilloscope?
<specing>
netchip: UARTs should output 1 when idle
<specing>
just measure it with a multimeter
<penguin42>
netchip: Well if you know the pins on the chip where the uarts are connected then you can do continuity to your test pins to find them
<RaYmAn>
specing: they don't always
<penguin42>
netchip: You have to be careful not to blow the chip though
<netchip>
so
<netchip>
I can look into chip's manual, search for UART voltage, adjust my Bus Pirate on that and go try all the pins?
<hramrach>
you don't see the pins on bga chip
<hramrach>
basically
<netchip>
How do I even know I have UART without an oscilloscope?
<hramrach>
it's in chip datasheet
<hramrach>
it may not be on any pin, sure
<RaYmAn>
you hope you have the right speed and wait for data to pop up :P
<specing>
RaYmAn: they do in my experience
<specing>
RaYmAn: even A10
<hramrach>
but most devices will have one for factory testing
ZaEarl has quit [Ping timeout: 276 seconds]
<specing>
RaYmAn: they have to be enabled, though
<RaYmAn>
specing: yeah..I've seen few devices where enabled *and* sending data registered as 0 all the time. Same when not sending data. That is, as far as a multimeter is concerned
<netchip>
OK, what are the steps to locate UART on my SGS3, for example? Let's say I have only a Bus Pirate
<specing>
RaYmAn: multimeters have <10 Hz sample freq
<specing>
don't rely on them
<RaYmAn>
I know :) You were the one who mentioend multimeter ;)
<netchip>
RaYmAn, you did
<netchip>
anyway
<netchip>
1) I disassemble my device
<specing>
RaYmAn: yeah, but if you don't have a scope...
<netchip>
2) I go look for possible UART locations
<netchip>
3) If I think I found them, I check chip's manual for voltage
<netchip>
4) I adjust my bus pirate for the voltage
ZaEarl has joined #arm-netbook
<netchip>
5) I try them.
<netchip>
right?
<RaYmAn>
specing: sure, my point was that you can't always rely on that, though it might help you narrow it down
<specing>
skip 2
<netchip>
Ah
<netchip>
I just check them with volt meter
<netchip>
:)
<netchip>
shouldn't be hard
<specing>
netchip: I found my tx on the line to the G-sensor
<hramrach>
with a serial cable I would try to connect the gnd to something that looks like ground on the pcb and the rx pin to random pins on the board
<hramrach>
if you connect to board tx and have the speed right you will see the boot messages
<hramrach>
unless they went out of their way to turn that off
<specing>
use this to spam serial ports with a single character
<netchip>
hramrach, yeah ofcourse but to test
<hramrach>
and if you are searching for the pin it's not in the manual
<specing>
(from android)
<netchip>
ah
<netchip>
so you see them?
<netchip>
but if i have to adjust the rates
<netchip>
it costs hours (fictive) to locate them
<hramrach>
likely the rate is going to be one of the usual 115200 or 9600
<netchip>
well
<netchip>
i'll order BP
<specing>
the link I gave does 9600 by default
<netchip>
and test asap ;)
soooga has quit [Quit: Leaving]
<rm>
mnemoc, hey
<rm>
mnemoc, does stage-3.0 also contain the EDID patches?
<hramrach>
you can look at the log
<mnemoc>
rm: yes, both stage branches include the same changes
eebrah has joined #arm-netbook
<hramrach>
I don't see them in the 3.0 branch but may be just me
<hramrach>
oh, now I see them
<netchip>
is this channel Allwinner only btw?
<hramrach>
no
jlj has quit [Ping timeout: 276 seconds]
jlj has joined #arm-netbook
jlj has quit [Ping timeout: 256 seconds]
jlj has joined #arm-netbook
hansg has joined #arm-netbook
* penguin42
tries to figure out where the rk3066 dev guys are
<specing>
penguin42: in china
<penguin42>
specing: Well there seem to be various half communities for it - but they're all only part setup so far
<penguin42>
specing: http://code.google.com/p/rk3066-linux/ is kind of promising but most of the links are dead, and the forum doesn't work - but they have working binaries, there is a forum on armtvtech
<L84Supper>
maybe devs with docs that work for an OEM?
lkcl has quit [Ping timeout: 272 seconds]
<penguin42>
maybe, I've got the sorurce tree out of the git
Sv has quit [Read error: Connection reset by peer]
<RaYmAn>
there are a bunch of cm people working on it, but that's mostly android based of course. (Though, iirc custom kernels and such as well)
<Pulser>
penguin42, that link is a binary kernel AFAIK
<RaYmAn>
then gralloc and hwcomposer etc to get hw features
<netchip>
EGL and gralloc is kinda one
<netchip>
no gralloc is no gfx
<L84Supper>
netchip: Chrome is Gentoo just FYI
<netchip>
L84Supper, ?
<netchip>
Google Chrome OS = gentoo?
<mnemoc>
techn_: I'm a bit puzzled regarding the last HACK: patch on 3.4. hansg's mangled patch or ssvb's revert
<L84Supper>
netchip: Google has been gobbling up any free Gentoo devs
<hramrach>
yes, the 3.4 patch does not apply for me
<mnemoc>
techn_: but after that I'll merge it before the new set from hansg
<L84Supper>
netchip: it's a fork based on Gentoo
<netchip>
L84Supper, Isn't gentoo just one bunch of source packages, connected with emerge?
<hramrach>
but it's supposed to fix the fbcon corryption
<netchip>
that's how I see gentoo
<L84Supper>
yeah, just a bunch of 1's and 0's
<penguin42>
L84Supper: Thanks for th elinks
<netchip>
who can help solve my camera problem on Android?
<netchip>
(dev related)
<netchip>
OK, here it comes
<mnemoc>
hramrach: you mean the HACK: patch updated for 3.4 doesn't apply on stage-3.4?
<RaYmAn>
chromeos use gentoo for building all the packages and stuff, but the final image is free of most gentoo-isms =P No emerge/portage etc
<netchip>
http://pastebin.ubuntu.com/1504101/ 1) Camera wrapper calls proprietary blob 2) Blob calls function in blob 3) Function makes media server crash
<hramrach>
mnemoc: yes, that does not apply for me. either it was mangled on send or by google
<netchip>
is my theory right?
jlj has quit [Ping timeout: 252 seconds]
<penguin42>
L84Supper: Yeh it's AndrewDB's image I've booted; and I think got the tree source from the the picuntu link - but it's all a bit weirdly linked from each other
<Pulser>
there are a number of files missing source, where they have pre-compiled .o files made from .uu uencoded files
<Pulser>
it's not GPL compliant, and it stops you easily editign the source for them
<L84Supper>
Pulser: just getting them posted, since they don't seem to be organized at any one site
<penguin42>
L84Supper: Ah that's nice, the thing I was missing was the how to make an image
<Pulser>
yeah sure
<Pulser>
penguin42, what board are you working with?
<penguin42>
Pulser: An mk809 - just got it over the weekend
<Pulser>
right, rk3066 based?
<Pulser>
I have been working with codeworkx on CM for the mk802iii which is quite similar as I understand it
<Pulser>
but we are a bit sick of the amount of "cheap botches"
<Pulser>
like putting the usb slave on the same line as the wifi chip
<penguin42>
Pulser: Yeh rk3066
<Pulser>
so you cannot be connected to PC while using wifi
<Pulser>
etc
<Pulser>
and when using adb to debug it, that's not much use
<penguin42>
Pulser: Yeuch that's nasty
<Pulser>
blobbed up bits of source are annoying
<Pulser>
their MTD...
<Pulser>
UGH
<Pulser>
UGH!
<Pulser>
their MTD is the worst
<Pulser>
closed source
<Pulser>
and broken
<penguin42>
Pulser: Yeh, I won't have another chance to fight it until next weekend, but I should have a spare powered usb hub and uSD by then which will make life easier
<penguin42>
MTD?
<Pulser>
penguin42, the onboard storage
<penguin42>
Pulser: HTF can you make a flash interface so wacky?
<Pulser>
ie. the nand
<Pulser>
penguin42, oh trust me... you can :P
<Pulser>
rockchip managed lol
<hramrach>
ItWorks(tm)
<penguin42>
Pulser: Yeh I noticed the /proc entry for the flash stuff - looks like they did their own wear stuff?
<hramrach>
on a demo session you can read the whole content of the nanad ;-)
<Pulser>
those are not buildable unfortunately
<Pulser>
they are missing a load of stuff
<penguin42>
Pulser: So any idea what AndrewDB's kernels are?
<RaYmAn>
Pulser: the rk29 driver doesn't work?
<Pulser>
RaYmAn, codeworkx said it won't
<Pulser>
it is missing a method or two
<hansg>
mnemoc, what do you mean with "hansg's mangled patch" ? I just "ported" the original patch to 3.4
<Pulser>
can't recall which
<Pulser>
and it's also .uu'd
rz2k has joined #arm-netbook
<Pulser>
penguin42, AndrewDB's kernels came IIRC from a rikomagic guy in the UK
<hramrach>
hansg: what I Get from the ML does not apply
<mnemoc>
hansg: yes, failed to find a better term. .... adjusted patch :)
<mnemoc>
hansg: I just pushed it to stage/sunxi-3.4
<hramrach>
then I get it there I guess
<penguin42>
Pulser: AH, so they aren't built from the git hub he has?
<hansg>
mnemoc, btw about the serial patches, am I the only one who has actually seen the A10 running Linux hang filling the (hdmi attached) console with those: ">>> no handle, treat it handle over" messages ?
<Pulser>
penguin42, I think they are tbh
<Pulser>
but I am not sure how he has mtd working (does he???)
<Pulser>
doesn't his stuff boot off SD?
<mnemoc>
hansg: no, that's known
<hansg>
I've seen this both on my (just arrived) mini-x, as well as occasionally on the gooseberry
<hansg>
mnemoc, ok, well it is fixed now :)
<mnemoc>
hansg: it's part of the incomplete forward port of the hackery in 3.0
<penguin42>
Pulser: Ah, it's possible - I've not had a full boot yet (due to missing a spare uSD and USB hub due to a screwed up Amazon reseller....)
<mnemoc>
hansg: give me a minute to show you allwinner's "fix" :)
<Pulser>
damn
<Pulser>
penguin42, I don't think there are mtd drivers that work
<Pulser>
if there are, I'd love to know
<Pulser>
but wifi is annoying us, as is the sheer amount of messups
jlj has quit [Remote host closed the connection]
<Pulser>
stupidity etc
<hramrach>
for me the stage 3.4 kernel works. At least I can boot it, get HDMI output, etc
<penguin42>
Pulser: OK, I'm not too fussed with that tbh for starters; If I can build an image I can write to the recovery I'll be reasonably happy for starters
<Pulser>
right
<Pulser>
we worked out how to do that
<Pulser>
though this is "android style" images
<Pulser>
I dunno if that helps you
<penguin42>
Pulser: Yeh I'm happy with that for starters
<Pulser>
ie. kernel + ramdisk in the package
<Pulser>
sure
jlj has joined #arm-netbook
<Pulser>
apparently that was harder to do, but we figured it out
<Pulser>
I am sure others will have to, but I don't know if it's documented
<hansg>
mnemoc, ah cool, well then my guess that they are using a designware uart ip block was correct, I did not even know that, but I just looked through other 8250 drivers in the kernel to find something similar and got lucky :)
<penguin42>
Pulser: Well when I get a chance to have a fight next weekend, I'll see how far I get
<penguin42>
Pulser: The most annoying thing with the shipping image is that there is no apparent way to cause it to do adb connection at boot, so I have to fetz with a mouse/keyboard to set the little tick to turn adb on so I can reboot to recovery
<Pulser>
indeed
<Pulser>
well. we fixed that IIRC
<hansg>
Looks like I accidentally fixed that one then :) Just a quick copy and paste of 8250_dw.c really
<Pulser>
we modified boot.img to change usbmode to 2
<Pulser>
that will make it a slave
<Pulser>
but in the process, that stops wifi working
<Pulser>
:P
<Pulser>
RE adb you might need to sort out drivers and stuff
<penguin42>
Pulser: Fortunately I'm not too fussed about wifi either :-)
<Pulser>
hehe
<Pulser>
:)
<Pulser>
meh it just annoys me how stupidly it's designed
<Pulser>
that they put the wifi on the same bus
<penguin42>
Pulser: I just want connectivity back to my host and something I can load a kernel and user stuff onto; so as far as hardware goes some boot space and a USB connection should be enough :-)
<Pulser>
sure
<penguin42>
oh and the HDMI is nice for when it doesn't work, I guess....
<Pulser>
yeah just get yourself a boot.img, and set the usb mode into 2
<Pulser>
also... our board has UART on it :)
<Pulser>
dunno if yours will
<Pulser>
that can be handy, but the terminals are fragile iirc
<penguin42>
I guess it probably does, haven't broken the case yet
<Pulser>
oh
<Pulser>
mk802iii opens so easily
<Pulser>
and the manual even tells you to do it if you brick it :P
<techn_>
hansg: did you try 1080i @ 50hz and 60hz with those ppl codes?
<penguin42>
Pulser: This is an 809
<techn_>
Could not find a matching pll-freq for 72658000 pclk, and 74183000 pclk
<penguin42>
Pulser: It didn't come with what you could call a manual :-)
<hansg>
techn_, no I did not try those
<Pulser>
well when I say a "manual"
<hansg>
techn_, through edid, or hardcoded to those resolutions?
<Pulser>
I mean some poorly translated .doc online
<Pulser>
that has a shaky photo
<penguin42>
Pulser: Ah
<techn_>
hansg: edid.. allwinner seems to be using hardcoded ones
<Pulser>
short pins 6 and 7 of the NAND
<Pulser>
it cannot see the NAND
<Pulser>
so goes to a mask download mod
jlj has quit [Ping timeout: 240 seconds]
<Pulser>
e
<Pulser>
throw it a bootloader and firmware, and it flashes up
<penguin42>
Pulser: That's kind of reassuring
<netchip>
ohai Pulser
<techn_>
hansg: 74250000 for both
<Pulser>
well
<Pulser>
that's our device
<Pulser>
I strongly suggest you find out if that's possible on yours
<mnemoc>
hansg: would you like to apply similar fixes in sunxi-serial for 3.0? :) for the sake of consistency
<hansg>
techn_, right, I made sure my pll code could (should, not all tested) handle all the hardcoded modes. As for EDID, well if the tv/monitor gives us modes the pll cannot do, we sort of loose
<penguin42>
Pulser: Yeh, I'll *try* not to fuck it up that badly
<hansg>
mnemoc, I'm fine with someone cherry-picking them into 3.0. TBH the last time I tried to build 3.0 it would not even build with my .config (which is derived from the standard F-18 kernel .config, so it has a lot of stuff enabled)
<penguin42>
Pulser: Rather broken site - falling over quite badly
<Pulser>
penguin42, oh right
<Pulser>
well it looks like it can be recovered
<Pulser>
I just googled MK809 recovery :P
<hansg>
mnemoc, I guess I can run some tests using a defconfig
<Pulser>
netchip, no, because i know what you will be asking
<Pulser>
penguin42, hmmm
<netchip>
Pulser, No opportunity? :(
<Pulser>
right yeah that site is derped too
<Pulser>
netchip, our decision is final
<penguin42>
Pulser: Anyway, no biggy - I'll figure it out, as I say only turned up yesterday
<hansg>
techn_, btw, are those the preferred modes for that TV ? My main focus is on getting the preferred / native modes working. You really don't want to be running at a non-native resolution with LCD-s
<Pulser>
penguin42, yeah it's not too bad
<Pulser>
you'll be sick of the device in about a week btw
<techn_>
hansg: native
<Pulser>
from trying to undo their dirty hacks
<netchip>
Pulser, like in forever?
<penguin42>
Pulser: Haha probably; what I really want to do is do some user space triaging, but I also want to play about with gadget driver stuff - so we'll see
<Pulser>
penguin42, yeah... if you are happy to play in userspace you might not hate it too much
<Pulser>
gadget and drivers... good luck :P
<hansg>
techn_, and also the preferred (first dtd) mode? I would expect the preferred mode to be 1080p (and hope that one does work ...)
<penguin42>
Pulser: yeh :-)
<techn_>
preferred is 1080p
<hansg>
and does that work ?
<techn_>
and it works
dyoung-away has quit [Read error: Operation timed out]
<hansg>
Good, then IMHO the 1080i modes not working is not a big loss. Since picking a non preferred mode should involve user intervention anyways they can pick the hardcoded 1080i modes (assuming those are working)
jinzo has quit [Read error: Operation timed out]
<techn_>
some videoplayer software could switch to 1080i if video is same format
<penguin42>
Pulser: Anyway, thanks for the hints - I'll be back next weekend and have more of a poke
<Pulser>
alright :)
penguin42 has quit [Quit: Leaving.]
jinzo has joined #arm-netbook
dyoung has joined #arm-netbook
<hansg>
techn_, what we can do is, when the device had a DTD with a 1080i mode with an unsupported clock, advertise the matching hardcoded 1080i modes in the available mode list instead
jinzo has quit [Ping timeout: 251 seconds]
jinzo has joined #arm-netbook
jinzo has joined #arm-netbook
jinzo has quit [Changing host]
tinti has joined #arm-netbook
tinti has quit [Client Quit]
datagutt has quit [Quit: kthxbai]
lkcl has joined #arm-netbook
<mnemoc>
hansg: in sunxi-boards mk802-ii was renamed to mk802ii (to match u-boot's board) a couple of weeks ago
<mnemoc>
hansg: also cleaned up a bit
jlj has quit [Ping timeout: 276 seconds]
jlj has joined #arm-netbook
<techn_>
hansg: did you test usb_host_init_state=0 with latest stage
jlj has quit [Ping timeout: 246 seconds]
jlj has joined #arm-netbook
eebrah has quit [Read error: Connection reset by peer]
ajmitch_ is now known as ajmitch
jlj has quit [Ping timeout: 240 seconds]
<hansg>
techn_, yes, still the same issue, the device only shows up in lsusb after modprobing the driver manually
<hansg>
mnemoc, let me rebase my patches on top of that and then I'll resend the entire set
<techn_>
strange.. for me it didn't show up on lsusb
<hansg>
techn_, not even after a modprobe of the driver ?
<techn_>
no
jlj has joined #arm-netbook
<hansg>
techn_, well I've been sitting on my fex file patches for a while (testing + cleanup before posting them), so maybe what you had was a regression from the unification fixed by the recent patches to restore the enable/disable functionality. I believe my testing was all done prior to the unification, and then again post unification + fixes
<hansg>
techn_, but even after the latest fixes I still need a manual modprobe, note that listing the module in /etc/modules also counts as a manual modprobe
<hansg>
With my changes the driver will simply autoload without being mentioned anywhere (other then being present in /lib/modules of course)
<techn_>
oh.. how that autoloading works?
<hansg>
mnemoc, techn_, hmm looks like the usb_host_init_state change already made it in mk802ii.fex as part of the cleanups
<hansg>
techn_, the same as all usb drivers are loaded. USB subsys detects the device (so it shows up in dmesg, lsusb) then sends a udev event for the new device which contains the device alias like this: usb:v2001p3307.... which udev then passes to modprobe
<hansg>
And modules declare device aliases they are compatible with, ie:
<ssvb>
mnemoc, hansg, techn_: are the framebuffer related modules (disp, hdmi, ..) expected to be safely loadable/unloadable at runtime?
<hansg>
USB is a true plug and play bus, all devices must answer to certain commands on their control endpoint, which allows querying things like the product and vendor id.
<techn_>
ssvb: atleast not one-by-one
<hansg>
ssvb, I've not audited them for this, but looking at the overall code quality of all sunxi code, I would say no
<hansg>
ssvb, what is possible with more recent sunxi kernels is to actually build them into the kernel which is preferable IMHO
<techn_>
but I think libv did that somehow.. since he send patch to allow it
<mnemoc>
a couple of drivers have been fixed to survive unloading/reloading, but in general they just crash
<techn_>
mnemoc: could you take those mine uart patches when you take hansg's
<techn_>
there was also patch to allow load/unload :/
<libv>
ssvb: i am happily loading/unloading them on both hdmi and lcd-ed devices
<mnemoc>
techn_: somehow I was expecting a v2 of yours :p
<techn_>
mnemoc: That one patch was decided to drop.. but I think other ones was good? :/
<mnemoc>
techn_: ok. please remind me tomorrow :)
netchip has quit [Quit: Leaving]
<ssvb>
mnemoc: yeah, I wanted to provide v2 patch, but you were too fast to apply it to the stage branches :) so I'm a bit confused about what to do
jlj has quit [Ping timeout: 252 seconds]
<mnemoc>
ssvb: the stage branches are rebased. if you want so, I can just remove them
<ssvb>
mnemoc: also I want to test modules unloading, and somehow this does not seem to work for me with or without this patch
jlj has joined #arm-netbook
<mnemoc>
ssvb: only the HACK: patch is in question of you have doubts about others too?
mtndew` is now known as sadmtndew
<mnemoc>
s/of/or/
<ibot>
mnemoc meant: ssvb: only the HACK: patch is in question or you have doubts about others too?
<ssvb>
mnemoc: yes, only the HACK patch
<ssvb>
mnemoc: ok, just give me a few hours to test it a bit better
<hansg>
ssvb, btw, I love the hack patch, I had already noticed the issue and it was bugging the hell out of me, so I'm very happy to see it fixed
<ssvb>
mnemoc: the reverted upstream patch may be preferable, because 1) it was in the mainline kernel at one time 2) it shows the warning when questionable ioremap are attempted
sadmtndew has left #arm-netbook [#arm-netbook]
<hansg>
Not sure if having a WARN_ON which we know will trigger in there is a good idea, that means that every time someone boots a sunxi kernel he will see a backtrace
<hansg>
This is bound to cause a lot of bug reports
<ssvb>
hansg: yes, that's a good point
<techn_>
but partly it's bug :)
<hansg>
Interesting, I just got an EDID checksum error, looks like we need to do a retry on those, and we should not do a WARN_ON when we do get one as it is not a kernel bug, so a backtrace is not helpful
<hansg>
Of course I will likely be able to never reproduce this, so guess how well the retry code path will get tested ...
<techn_>
hmm.. dynamic edid seems to be finished.. only thing is that memory allocation part :/
<hansg>
BTW am I the only one seeing list corruption warning related to process_worker / process_one with 3.4 ?
jlj has quit [Ping timeout: 260 seconds]
<mnemoc>
ssvb: I'll skip your HACK patch when merging the stage branches tomorrow. take your time ;-)
<ssvb>
mnemoc: ok, thanks
<ssvb>
when is the next merge going to happen in the case if we miss this one?
<mnemoc>
ssvb: there is no strict schedule
freakazoid0223 has joined #arm-netbook
<mnemoc>
there isn't much people sending patches, so stage branches get spawned as soon as a not-trivial patch arrives, and they get merged soon after people starts asking here when will it be merged :p
jlj has joined #arm-netbook
<mnemoc>
s/people/devs/
eFfeM has joined #arm-netbook
<techn_>
mnemoc: I'll send dynamic mode setting patches.. take them to new stage after review.. ok? :)
<mnemoc>
techn_: ok
focus_it has joined #arm-netbook
<ssvb>
techn_: this sounds really cool, bring it on :)
<techn_>
ssvb: now what we miss feature wise is dual screen support, dual fb support and blanking :/
<techn_>
but I think I'll focus next on cleanup
<techn_>
and thanks :)
focus_it has quit [Quit: Leaving]
<techn_>
ups.. found malloc bug.. resending new patch tomorrow :p
<hramrach>
how do you make a gpio led connect with a led trigger?
provel_ has quit [Quit: leaving]
pcat has quit [Ping timeout: 272 seconds]
hramrach has quit [Remote host closed the connection]
lkcl has quit [Ping timeout: 240 seconds]
hramrach has joined #arm-netbook
hansg has quit [Remote host closed the connection]
eFfeM has quit [Quit: Leaving.]
hramrach has quit [Remote host closed the connection]