<oliv3r>
i dunno, how would my logic analyzer lie?
<oliv3r>
rx and tx output exactly the same
<oliv3r>
this is using a USB uart device though
<wens>
shorted? echo?
<oliv3r>
shorted, would be internally if that
<oliv3r>
i'musing the olimex header
<oliv3r>
and have the LA connected directly to the pins
<oliv3r>
header*
<oliv3r>
let me try my other serial port
philippe_fouquet has quit [Remote host closed the connection]
Andy-D has quit [Read error: Connection reset by peer]
<oliv3r>
ahh, looks like a grounding issue
<oliv3r>
i grounded the 'other' pins and now it all looks good
saurabh_ has quit [Ping timeout: 244 seconds]
philippe_fouquet has joined #linux-sunxi
<oliv3r>
still strange that if i not ground pins 2-7, the rx pin makes noise identical to tx
<gzamboni>
oliv3r, my brother is having some noise in the beggining of a serial application hes doing with an olimex board, it does echo the firsts bytes
<oliv3r>
gzamboni: but this is a USB -> serial converter with only the logic analizer connected to the converter
<oliv3r>
so the olimex board isn't even connected, powered on :)
<gzamboni>
which pins are you grouding to make it disapear
<oliv3r>
i have an openbench logic sniffer, and have a 8 probe cables + gnd
<oliv3r>
i have gnd connected to gnd, pins 0 and 1 to tx, rx and pins 2 - 7 on GND
<oliv3r>
before i left pins 2-7 floating
<gzamboni>
hes using also the ttl usb adaptor first and he plans after to use the serial directly from the board
<oliv3r>
yeah
<oliv3r>
i was mostly just testing the logic analyser
<oliv3r>
so a USB ttl + serial_noise made sense :)
<gzamboni>
nice to know, he thought it was a software problem
<oliv3r>
nvm i'm still seeing noise on the rx
<oliv3r>
so somehow there's either data coming out of the tx
<gzamboni>
he told me that only the first 3 or 4 bytes came with noise, after it works fine
<oliv3r>
hmm, i increased the sampleing rate and now it looks better
<oliv3r>
na, this was a lot of noise
<wens>
oliv3r: cross talk?
<gzamboni>
sup wens, thanks for all the mainline patches nice work
<mripard>
wens: please stop answering through the linux-sunxi delivered mails. It just drops the original recipient
<mripard>
(and only saw your earlier reply because I was looking at the LAKML mails)
<wens>
always forget about that... :(
jemk has joined #linux-sunxi
<gzamboni>
mripard, another mainline guru, youre are the offical maintainer of the sunxi platform, right ?
popolon has joined #linux-sunxi
<oliv3r>
wens: i'm using a much much higher sampling rate and it appears to be okay now
<oliv3r>
wens: also, i see you picked up my A31 work; awesome to see this go to use
<oliv3r>
(for sun6i)'
<oliv3r>
wens: i'm just supprised I used: #define PRCM_APB0_GATE_PIO (0x1 << 0) and not BIT(0)
<mripard>
gzamboni: yep, why?
FR^2 has joined #linux-sunxi
<wens>
oliv3r: :)
<oliv3r>
wens: oh wait you took my u-boot stuff and put it into the kernel; yeah then it needs the BIT() macor :)
<mripard>
gzamboni: (I'm also boarding on a plane :P)
<gzamboni>
what does happens if the allwinner team get into the mainline, you will be allways the mainteiner
<gzamboni>
sorry, go ahead
<oliv3r>
not speaking for mripard but if AW would be working with mainline and offer code up to quality, I would expect that AW would take over as maintainer?
<oliv3r>
but I don't see that happening anytime soon :p
<gzamboni>
i saw you did progressed with all the dma code, awesome, it was too hard for me, i saw also that Turl got into the A10/A20 dma also, but i think it still not merged
<hramrach_>
hello
<wens>
we could look at mediatek, they came in too late and didn't get maintainer
<oliv3r>
well for now, we are all still dedicated to AW i suppose ;)
<hramrach_>
how can I save environment in u-boot?
<oliv3r>
wens: do you want me to reply to your main about the BIT() macro or send a patch?
<hramrach_>
can it write to a file?
<gzamboni>
hramrach_, saveenv ?
<wens>
oliv3r: since no one complained, you could send a patch for ijc to squash in?
<gzamboni>
you can create the txt file also
<hramrach_>
that writes to some random mmc block, right?
<oliv3r>
wens: sure, i'll grab those and add a patch
<wens>
a80 has 33 address lines, now i have to use 64bit values for all the values in the dt :|
<hramrach_>
which I can technically examine after the fact so I would know the environment was saved
<hramrach_>
hehe, 33
<hramrach_>
they did that on purpose for sure ;-)
<gzamboni>
you can orphan one of them :P
<wens>
or i could use ranges to map the 64bit values to 32bit values
<wens>
since only the memory goes above 4G
<hramrach_>
what is the memory size limit?
<wens>
8G
<oliv3r>
should be 8g
<oliv3r>
2^33
<wens>
dual channel 64bit memory bus... hmm...
<hramrach_>
not if you need that same space for IO as well
<oliv3r>
ohh, well yeah
<oliv3r>
i bet the io space goes to 1gb like before
<oliv3r>
so theoretically 7gb of ram
<oliv3r>
but physically probably limited to 4gb since you can't get 3gb module
<wens>
actually it's the first 512 mb
<hramrach_>
you can get 4gb x2 and trash 1gb
<wens>
they moved it a bit
<hramrach_>
nice
<oliv3r>
so you could get 7.5 gb of usable ram
<oliv3r>
in theory
<wens>
mripard: i get why you mostly don't send mainline patches to linux-sunxi
<hramrach_>
presumably Cortex A5 can do VFP4 and A9 not or the other way around
hipboi has quit [Ping timeout: 244 seconds]
<wens>
pushed a80 fex file to sunxi-boards
Renard has joined #linux-sunxi
hipboi has joined #linux-sunxi
<lauri>
Hi guys, I tried to compile sunxi-next and I got ./include/uapi/asm-generic/posix_types.h:66:5: warning: "__BITS_PER_LONG" is not defined [-Wundef]
<lauri>
or perhaps just someone could give me a compileable revision number?
<oliv3r>
wens: does the 'new' i2c like thing for power IC connection sound even remotly like SPMI?
<wens>
oliv3r: i don't know what SPMI is, or how it's different from the other i2c-like busses
montjoie[home] has quit [Ping timeout: 258 seconds]
<wens>
the latest should be compilable
montjoie[home] has joined #linux-sunxi
Zboonet has joined #linux-sunxi
Zboonet has quit [Remote host closed the connection]
Zboonet has joined #linux-sunxi
philippe_fouquet has quit [Remote host closed the connection]
<lauri>
wens: latest is not compilable, that's what I pointed out
<lauri>
wen: oh it was just updated
<lauri>
or not
bengal has joined #linux-sunxi
<wens>
what's your compiler version
<lauri>
GCC 4.7
<lauri>
it's from Emdebian repos
<wens>
hmm... mine works :/
<lauri>
gcc version 4.7.2 (Debian 4.7.2-5)
<lauri>
you have the same?
<wens>
same here
<wens>
check your environment (CROSS_COMPILE, ARCH) and check for missing files?
<hramrach_>
lauri: you probably have some untested combination of config options. try grep for the undefined symbols and figure out which option would define them or which option when left out would cease using them
<hramrach_>
It happens a lot on experimental kernels
ganbold_ has quit [Ping timeout: 245 seconds]
bengal has quit [Quit: Leaving]
MY123 has joined #linux-sunxi
naobsd has quit [Quit: Page closed]
<hramrach_>
btw just tried out using an a23 tablet as tablet
<hramrach_>
unlike the inet86vs the wifi on q8h actually works
<hramrach_>
but the performance is horrible
<hramrach_>
the tablet is practically useless
philippe_fouquet has joined #linux-sunxi
Zboonet has quit [Remote host closed the connection]
<ssvb>
hramrach_: yes, these cheaters are reportedly trying to conceal the fact that it is Cortex-A5 (also by tampering with /proc/cpuinfo), but there are many circumstantial evidences
philippe_fouquet has quit [Remote host closed the connection]
philippe_fouquet has joined #linux-sunxi
<ssvb>
hramrach_: and the performance is really bad, Cortex-A7 does not look slow anymore compared to this :)
philippe_fouquet has quit [Ping timeout: 244 seconds]
Black_Horseman has quit [Quit: Zwi se logou mou!!!]
Tintu has joined #linux-sunxi
<Tintu>
hello... i'm working with A20 Humming Bird... I want to connect resistive Touch Panel . I followed the fex guide and connected the LCD as pin description... Display working..But touch is not working... Any idea??? pls help...
<JohnDoe_71Rus>
kernel support the touch panel?
<hramrach_>
MY123: I guess I need another SoC. Or maybe they are using 16bit ram access or something similarily horrible
<MY123>
hramrach_: how many cores are there in that?
<Tintu>
hramrach_,dual core ..
<MY123>
If Dual-Core, Cortex-A5 is ruled out
<hramrach_>
MY123: I have a normal a23 tablet which has 2 cores per the spec
<hramrach_>
the leopard CPUs are supposedly quad-something claimed Cortex A9
<hramrach_>
A9 never made it into cheap tablet SoCs so this seems odd.
<MY123>
hramrach_: Did you extract U-Boot from that ?
<Tintu>
Cortex-A7
philippe_fouquet has joined #linux-sunxi
<Tintu>
How can we identify the kernel support the touch panel or not?
<hramrach_>
MY123: no. is u-boot from a23 tablet of any use? we have u-boot binaries for a23, u-boot sources for a23, and near zero success using those
<ssvb>
hramrach_: A9 is used in Rockchip tablets, and cheap is relative
<hramrach_>
maybe that's why the rk tablet has usable performance?
<MY123>
hramrach_: script.bin /fex/?
<Tintu>
I am a beginer to this... can u explain simply?..
<hramrach_>
Tintu: 90% of the time touch panel is not supported without additional work
<hramrach_>
1) defconfig has no or almost no touch drivers
<hramrach_>
2) some touchscreens need firmware
<Tintu>
what do u mean by additional work?
<hramrach_>
3) most touchscreen drivers are half-broken or not integrated into any sunxi kernel at all
Renard has quit [Remote host closed the connection]
<Tintu>
how can we add touch driver?
<hramrach_>
eg. to have a gsl touchscreen working you 1) extreact some blobs form the andriod image and pray you pick the right one 2) build out-of-tree driver 3) put a reference to the extracted blob in script.bin, load driver and pray it works
<hramrach_>
obviously, if more people try and extract the blobs we will have more data and better estimate what might work and what not
<hramrach_>
but even manufacturer firmware tends to rely on loading the right blob - if you install wrong firmware the touchscreen just does not work
<hramrach_>
I mean manufacturer ROM
<Tintu>
where can i put my driver c file ?
<hramrach_>
Tintu: what touchscreen interface do you have?
<Tintu>
4 wire resistive 4.3inch
<hramrach_>
then just enable the sunxi touchscreen driver
<Tintu>
how?
Renard has joined #linux-sunxi
<Tintu>
do u mean to edit fex file?
<hramrach_>
Tintu: that's normal kernel configuration option. read on configuring kernel and finding out if your kernel has a particular option enabled
<hramrach_>
yes, you have to configure it in fex too
<oliv3r>
libv: what's the -Wl flag to ld for? all my compilers (x86, cross-arm, arm) fail on it (unknown flag)
Gerwin_J has joined #linux-sunxi
ganbold_ has joined #linux-sunxi
pwhalen has quit [Ping timeout: 246 seconds]
philippe_fouquet has quit [Remote host closed the connection]
<libv>
oliv3r: in what respect?
<libv>
is that in some tool i wrote?
<mripard>
gzamboni: if they played it right, after sometime, yes, that would happen
<mripard>
gzamboni: (and I actually want that to happen)
<mripard>
gzamboni: but just becoming one, not replacing me, unless I get bored and don't want to do it anymore
Quarx has joined #linux-sunxi
<mripard>
oliv3r: it's really more about what you have done rather than who you are, really.
<mripard>
wens: and usually, I send the "features" patches to linux-sunxi, not the trivial boring ones.
<libv>
heh, open source has never been about who has actually done what.
<wens>
mripard: makes sense, get the bystanders excited :)
<libv>
heck, look at simos :)
<oliv3r>
mripard: that's why I said, if they prove that they are doing it and have done it for a while and doing it well
<mripard>
libv: I wasn't talking about open source in general, but kernel maintainership
<oliv3r>
libv: you are the serial expert, so i'm going to lean towards you here for moment ;)
<oliv3r>
i added a 2nd serial port, on uart5, i do get [ 0.382984] sunxi-uart.5: ttyS1 at MMIO 0x1c29400 (irq = 18) is a U6_16550A
<libv>
mripard: i sure hope so
<oliv3r>
but why I do get output on ttyS0, ttyS1 doesn't output anything (I think)
<libv>
mripard: but don't be too surprised if some people prefer sucking up to a vendor above anything else
Renard has joined #linux-sunxi
<libv>
gregkh pulled that on me with via once.
<libv>
i am not sure whether he would dare do that upstream
<libv>
but he made sure that both openchrome and unichrome could never work for about a year and a half in SLE and opensuse
philippe_fouquet has joined #linux-sunxi
hipboi has quit [Ping timeout: 245 seconds]
<libv>
given how people seem to also like sucking up at $vendor at any cost on our mailing list, you shouldn't be too surprised if something like that happens to you at some point in the future
pwhalen has joined #linux-sunxi
<oliv3r>
libv: could i have missconfigured the pullups/downs? i think i copied them from uart0, but i get just 0v on the serial 5 line
<libv>
oliv3r: i do not know :)
<libv>
oliv3r: i just wrote those simple things to help bring up devices
<oliv3r>
never used anything other then uart0 then :(
<oliv3r>
me neither
ganbold_ has quit [Ping timeout: 245 seconds]
<hramrach_>
yes, tablet keys are on lradc and it's now somewhat documented in fex guide
ganbold_ has joined #linux-sunxi
<gzamboni>
mripard, just asked by curiosity, i hope you wont get bored soon :)
<mripard>
libv: wait and see, but yeah, that's part of the risks
<oliv3r>
hmm, strange, i thought it was quite obvious since forever :)
hipboi has joined #linux-sunxi
<libv>
and we have our 44th ndhed device
<libv>
63 todo :(
<libv>
now for the files, and then i'll add julian calabys script to our uboot/scripts
diego_r has joined #linux-sunxi
<mripard>
wens: regarding ranges your ranges question, I'm not sure to get it. do you have your code somewhere?
<wens>
libv: what should we do for the newer devices that aren't/won't be supported for HW-pack / BSP builds?
<libv>
what do you mean, won't?
<libv>
wens: are you talking about a31/a23/...
<wens>
libv: that's right
<wens>
well i see your edit on the a31 hummingbird
<libv>
create manual build howtos that are SoC specific :)
<libv>
but for now, adding meminfo to sunxi-boards is good enough i think
<libv>
yeah, i did this for one device already
<hramrach_>
is there known way to boot an a23 device?
<hramrach_>
I tried fel but uploading u-boot failed
<MY123>
hramrach_: NAND
<libv>
hramrach_: i will stick your olinuxino patch into the boards repo in a minute, i need to go there anyway
<hramrach_>
MY123: like replacing the kernel there?
<MY123>
hramrach_: Yeah
<wens>
hramrach_: did your dram initialize correctly? you should see messages after running boot0 (or fes1.fex)
<hramrach_>
that would presumably work but kind of sucks
<libv>
is the brom built so that it doesn't pick the sd card before the nand?
<hramrach_>
wens: I saw initializing dram message and nothing after
<hramrach_>
I have no SD card image and no way knowing what random stuff written to the SD card does since the SD port has the only console pins
<hramrach_>
libv: I would like to test what dram and hpcr settings are useful on a10s but it's clear this change is needed and both dram and hpcr is in u-boot in different repo, anyway
<wens>
libv: the brom will pick sd before nand, just that you won't have a working console if you use SD
<libv>
on our q8hs?
<libv>
so no separate pins again :(
<wens>
you can confirm that it does pick sd, if you write a valid boot0 (valid signature and checksum) to one, stick it in and power on
<hramrach_>
on some there is no console
<wens>
libv: i don't think boot0 is coded to be able to use r_uart as the console
<mripard>
wens: your ranges thing looks ok to me
<libv>
oh, i see
<hramrach_>
the original rom uses SD uart
<libv>
wens: crap
<libv>
wens: let's wait and see how accomodating allwinner will be with respect to our demands for ram info
<wens>
libv: we're kind of stuck without u-boot spl :(
dack has joined #linux-sunxi
<wens>
on the up side, we seem to have some kind of driver for mbus (for sun6i/sun8i) in the A80 SDK
<hramrach_>
I can use the AW supplied SPL blob but maybe it is initializing the dram incorrectly for the device
<wens>
hramrach_: you have to have valid dram parameters in your fex file, and have updated your spl/fel blob with them
<hramrach_>
technically there is source but I don't know how to build a fel SPL in particular
<wens>
i could send you what i use
<wens>
but my u-boot is coded for r_uart
<wens>
let me see if i have one for uart0
<hramrach_>
I can use the AW u-boot, presumably
<wens>
mripard: oh good, i'll send out v2 and see if the DT people have any objections
<wens>
hramrach_: that's an option
<hramrach_>
or do we have something you can upload to FEL to read back the dram parameters
<wens>
the dram parameters are stored in the header of boot0 and u-boot
<wens>
you can interrupt the stock u-boot and dump them out
<hramrach_>
well, technically I have them so it should be possible to write a 'dram initialization' function that just dumps the output of meminfo back into the controller
<wens>
hramrach_: it's not that simple
<wens>
a few clocks have to be enabled, and not all the registers just store values
<wens>
a few have to be toggled a few times, and are self clearing, such as the dll init
<hramrach_>
I do not have a way to interrupt stock u-boot ohter than entering FEL
<wens>
stock u-boot doesn't give a prompt?
<hramrach_>
it gives but doe not react to anything but HW key
<hramrach_>
and HW key jumps to fel
<wens>
damn, just like mine when i first got it :(