servili007 has quit [Read error: Connection reset by peer]
BJfreeman has quit [Quit: had a good time]
hipboi has joined #linux-sunxi
TheSeven has quit [Disconnected by services]
<Turl>
hi hipboi
[7] has joined #linux-sunxi
<hipboi>
Turl, hi
<hipboi>
morning
foubarre has quit [Remote host closed the connection]
shineworld has joined #linux-sunxi
de has joined #linux-sunxi
<de>
hey, are there sources for ft5x06_ts_2plus1 module anywhere?
foubarre has joined #linux-sunxi
<foubarre>
rm: Hi. I created my own kernel based on your cross compiling wiki tutorial. I installed packages i compiled, copied uImage to /boot, rebooted but uname -r still says i'm using the old kernel. Any idea of what happens?
<foubarre>
rm: (packages i compiled and installed are kernel, linux-headers)
paulk-desktop has joined #linux-sunxi
rellla has joined #linux-sunxi
rellla has quit [Remote host closed the connection]
rellla has joined #linux-sunxi
paulk-desktop has quit [Ping timeout: 256 seconds]
paulk-desktop has joined #linux-sunxi
<foubarre>
rm: nevermind. I was fooled by the "copy to /boot/ partition" that i read as "copy to /boot/ directory" due to slashes. I thought it was a path.
<foubarre>
rm: seems that it was the reason for not being able to use your firmware yesterday.
<foubarre>
rm: err kernel
foubarre has quit [Remote host closed the connection]
_BJfreeman has joined #linux-sunxi
_BJfreeman is now known as BJfreeman
<lkcl>
hno: morning. i think you're right about needing boot.scr in ram (felbootable)
hglm has joined #linux-sunxi
mdfe has joined #linux-sunxi
<hno>
hi hipboi We can very easily boot Cubieboard over FEL now.
<hipboi>
lol
<hipboi>
really good news
<hipboi>
so we have a small program to init dram
<hipboi>
and down to sdram?
<hno>
yes.
<hipboi>
nice
<hipboi>
and with mtd driver, so we can write to nand without livesuite?
<hno>
Yes, but there is still some pieces to sort out there.
<hno>
but it's getting close.
<hno>
(not closed)
<hipboi>
good to hear
<lkcl>
hno: that's really good, because i'm just exploring / modifying debian-installer
<hno>
hipboi, see usb-boot in sunxi-tools.
<hipboi>
ok
<lkcl>
a nand mtd would make it possible to install debian directly onto any A10 system's NAND.
<hno>
lkcl, yes, and is also possible using Allwinner NAND driver.
<lkcl>
*without* having to fuck around downloading 1gbyte random [and insecure] images off the internet
<lkcl>
hno: really? it gets recognised by fdisk?
<lkcl>
allwinner's nand driver is recognised by fdisk?
<hipboi>
lkcl, yes
shineworld has quit [Remote host closed the connection]
<lkcl>
nand-part. fuuuun. need a udeb for sunxi-tools..... fuuuun.
<lkcl>
cat /proc/mtd
<oliv3r>
Turl: yeah the write register is most likly for A13 ADN a10, but the write register should never be used in the kernel. I feel strongly that writing should be done 'offline' via FEL ideally only (unless someone goes experimenting of course)
<oliv3r>
Turl: but i think we miss 1 register for writing, 0x44 sets up the write and executes it, but 'what' would it write :p
<hipboi>
hno: when i use fel, i met Assertion `rc == 0' failed sometimes
<oliv3r>
hno: I don't think the efuses are write once; they can be, but I don't think they are in our case. look at atmel's AVR's. They have efuses that configure the chip, but can be changed (needs to be performed in a special way, can't do it while the AVR is executing stuff. Needs to be done from the ISP etc, but they can be changed.
<hno>
hipboi, you have awusb driver installed?
<hipboi>
hno, yes
<oliv3r>
hno: felboot works via libusb doesn't it?
<hno>
oliv3r, yes.
<hno>
hipboi, ok. I'll fix it up. There is some more pieces needed to play well with an kernel driver for the same device.
<hipboi>
hno: ok
<hno>
hipboi, should be fixed now.
BJfreeman has quit [Quit: had a good time]
<hipboi>
hno, you are quick :)
<hno>
simple problems are easier to fix now than to try to remember to fix later.
<hno>
oliv3r, and how does a 32-bit efuxe programming state machine write a 128bit SID?
<wingrime-android>
how about non aosp kernel basr
<wingrime-android>
based on clean linux
<wingrime-android>
pre solution before mainline
hglm has quit [Quit: leaving]
<hno>
wingrime-android, feel welcome to join in, but I think that effort is better spend on mainlining.
<hno>
there is a fair amount of dependenvies in the Allwinner code.
Yaku has quit [Ping timeout: 246 seconds]
<wingrime-android>
at such speed we will see mainline in 3 years
<wingrime-android>
somehow workable
<hramrach_>
rellla: yes, when started without X xbmc works ok
<hramrach_>
can't you patch that file to not check with glxinfo?
<hramrach_>
it's part of the repo ..
hipboi has quit [Quit: Leaving]
<hramrach_>
hmm, the problem is you get the console cursor blinking
<hramrach_>
and console powersaving does not seem to have hte option to not turn of screen at all
<rellla>
hramrach_: i'll patch it. no one but you told my about the FEH.py yet ;)
<hramrach_>
there are some setterm options for powersaving
<hramrach_>
but while the option to wake up works the option to disable powersaving does not seem to work
<wingrime-android>
oliv3r: how do you find hidden sram regs?
hglm has joined #linux-sunxi
ijc has joined #linux-sunxi
<oliv3r>
wingrime-android: I didn't, hno did :)
<oliv3r>
well i only wrote 00000 and 0xffffffff to them, and they revealed some interesting things
<wingrime-android>
there is any reason make this registers hidden?
<oliv3r>
hno: it writes it in 32 bit blurbs, you tell the write register which macro cell to program, and it does. You have 4? macro cells. problem is, we don't know which 32 bit register will get programmed OR it programs them in blocks of 8
<oliv3r>
wingrime-android: ask allwinner
<wingrime-android>
also we should re brom closely
<oliv3r>
wingrime-android: there's a assembly dump on hno's wiki
<wingrime-android>
it use that registers?
<oliv3r>
wingrime-android: we don't know :(
<oliv3r>
maybe try loading the disassembly into ida pro :p
<wingrime-android>
so how figured that registers do extractly that described?
<oliv3r>
i dumped the registers using u-boot
<oliv3r>
then I did in u-boot a 'write' to the SRAM configuration register
<oliv3r>
first i set everything to 0x00000; see what was left over
<oliv3r>
then a 0xffffff and see what bits where allowed to be changed
<oliv3r>
i wrote that on the wiki; and hno, the superbright man he is, noticed that and was like 'ohhh'
<oliv3r>
:)
<wingrime-android>
not sure that reg *only* that thing
<oliv3r>
ther'es more, but we don't know yet i'm sure
<wingrime-android>
back side effects
<oliv3r>
i mean look at 0x1c000c; those bits can be changed to 0xff and back
<oliv3r>
so there's 'something' there
<oliv3r>
same goes for the entire 0x1c00010 range
<wingrime-android>
ve can't say defenetly without verilog sources
<oliv3r>
and 0x1c00020 has + 0x1c0002c has some bits aswell
<oliv3r>
wingrime-android: we don't know what touches what :(
<oliv3r>
wingrime-android: also, I tried to mtest sram A, B, C and D
<oliv3r>
but sram C is off limits (unless you set a secret combination in sram)
<oliv3r>
i tried to set SRAM_CTL0_CFG to 0x0000 and 0xffff
<oliv3r>
but i could never mtest SRAM C1
<oliv3r>
same goes for some of the others
<wingrime-android>
are you saw cedarx driver
<oliv3r>
interestingly enough, SRAM D is for USB, and it's default set to 0; so it's usable by the bootloader, and later usable by the driver
<oliv3r>
nope
<wingrime-android>
he defenetly do something with sram as emac
<wingrime-android>
he=driver
<oliv3r>
oh yes
<oliv3r>
but we know this
<oliv3r>
SRAM C1
<wingrime-android>
also
<oliv3r>
that's 512 kiB space to be used by the VE
<hramrach_>
it might be inacessible to facilitate protected decoding in CedarX or some other lame thing like that
<wingrime-android>
cedar x only mapped ve iospace
<oliv3r>
i *GUESS*, that you put a macroblock (or 10) into sram C1, tell cedarX via registers that the data is there, cedarX does its math on it, and lets you know its done so you can copy the result from SRAM1
<wingrime-android>
all access to sram ctrl are in sources
<oliv3r>
hramrach_: exactly
<oliv3r>
actually, that theory doesn't work, because you can not ever write INTO C1 :p (unless you set some registers somewhere that I haven't figured out)
<wingrime-android>
oliv3r according last re
<wingrime-android>
may be
<oliv3r>
you probably have to 'unlock' it, put data in, lock it so cedarX can use it
<wingrime-android>
cedarx need only pointer to macrocell
<oliv3r>
since the blob does actually touch some SRAM
<wingrime-android>
oliver: cedar need to be clocked befor it
<oliv3r>
yeah
<oliv3r>
well it could also be, that CedarX NEEDS 512 kiB of memory, and thus sram C1 is used for that (and hence blocked)
<oliv3r>
i don't get why you can't unblock it though
<oliv3r>
then again, i'm not bright as some of you, so I may simple not have tried smart things yet :)
tek has joined #linux-sunxi
<wingrime-android>
oliv3r you can try dump sram on cedar working
<oliv3r>
wingrime-android: do you have a10s?
<wingrime-android>
nope
tek is now known as Guest44089
<oliv3r>
wingrime-android: i tried to enable the clock gate, but cedarX registers remained 0x0000
<oliv3r>
so you need to init more registers, but i don't have hardware decoding yet :p so don't know
<oliv3r>
would need someone with A10s and uart to see what u-boot has in SCONTROL_0024
<wingrime-android>
oliv3r: see cedarx driver io sequence
<wingrime-android>
ve-version reg are fist reg that cedarx read
<wingrime-android>
using mmio
<wingrime-android>
before 3 ioctrls
<wingrime-android>
you can fix driver to leave cedar running after init
<wingrime>
blob do IOCTL_ENABLE_VE, IOCTL_SET_VE_FREQ, IOCTL_RESET_VE,
<wingrime>
before read anything
<oliv3r>
let me check those IOCTL's 2nd; 1st, i only want to do L1047, enable those 4 clocks
<wingrime>
oliv3r: you also should set PLL right way
tinti has joined #linux-sunxi
<oliv3r>
yeah ppl4; AHB; VE; SDRAM;
<oliv3r>
oh wait, PLL4 IS for VE (don't know if anything else uses it
<oliv3r>
not sure what the difference is bewteen PLL4 (0x018) and CCM_VE_CLK (0x013c)
<ssvb>
wingrime, oliv3r: I tried to experiment with dumping cedarx sram earlier to check what it looks like (more like the code or data) but could not figure out how to do this
<oliv3r>
hexdump -C /dev/mem | less? :)
<oliv3r>
hmm, pll4 is all 0000
<oliv3r>
and don't know what values go where :S i could try the default value
<ssvb>
oliv3r: does it work for you? :)
<wingrime>
ssvb: can you dump pll4 whan cedar working
<wingrime>
?
<oliv3r>
ssvb: what work?
<oliv3r>
sun4i#md 0x01c00018 1
<oliv3r>
01c00018: 00000000 ....
<oliv3r>
sun4i#md 0x01c00018 1
<oliv3r>
01c00018: 21081000 ...!
<oliv3r>
sun4i#mw 0x01c00018 0x21081000 1
<oliv3r>
so that seems to work :p
<ssvb>
oliv3r: /dev/mem for cedarx sram
<oliv3r>
ssvb: don't know yet :p
<oliv3r>
setting up clock registers right now
<ssvb>
ok :)
<oliv3r>
i tried to mtest SRAM C1; but all i tried failed
<ssvb>
oliv3r: yes, I also did not have much success with SRAM C1, there is SRAM_CTRL_REG0 register which is supposedly used to switch SRAM between CPU and VE, but tweaking it did not help either
<oliv3r>
ssvb: we tried exactly the same thing then :p
<oliv3r>
i updated the SRAM Controller wikipage with some findings
<oliv3r>
see the notes on sram C
<ssvb>
oliv3r: ok, maybe wingrime will be more successful :)
<oliv3r>
we CAN write to SRAM D; but that's only 4 kiB so not very usefull
<oliv3r>
but USB controller uses it for fifo appearantly
<oliv3r>
i talked to mripard as he was did the emac for mainline, but he is not using the SRAM the emac uses
<oliv3r>
i think emac uses A3 and A4 however
<oliv3r>
well we know that sram a3 and a4 can be used by emac :)
<ssvb>
oliv3r: SRAM B is reasonably large and can be accessed without problems
<oliv3r>
yep
<oliv3r>
but we tested that ages ago
<ssvb>
right
<oliv3r>
dunno where the guy went, he was an ausie
<oliv3r>
before I had my cubie, but yeah sram B is usable by the SPL/U-boot for extra memory
<oliv3r>
so that doubles our available bootloader memory :)
<oliv3r>
we can get 4 more kiB from USB, giving us 132 kb so far :)
<oliv3r>
now if SRAM C1 can be made avaiable during boot; that'll be like BAM 640 kiB
<oliv3r>
DOS from SPL :D
<wingrime>
oliv3r: tthat makes a10 line super speed MCU or DSP
<wingrime>
usable without any external ram
<oliv3r>
lol first we gotta see if we can access it :)
<mnemoc>
oliv3r: btw, shouldn't we rename wemac to emac in sunxi-3.4 too?
<wingrime>
oliv3r: yes
<wingrime>
also
<oliv3r>
mnemoc: absolutly
<oliv3r>
mnemoc: in 3.9 it's renamed
<oliv3r>
i can do it for stage/sunxi-3.4
<oliv3r>
but right now my emac is broken it seems
<wingrime>
oliv3r: I make special version of memdev2 for cedar
<wingrime>
and it work
<wingrime>
I finaly get ID
<oliv3r>
wingrime: awesome
<wingrime>
But mine IOCTRL order was incorect
<wingrime>
I it need more one
<mnemoc>
oliv3r: unfortunatelly vendors tend to prefer to enable/disable the phy power in a #define within the driver instead of the corresponding entry in the .fex
<mnemoc>
oliv3r: that causes troubles to people when switching to our tree
<mnemoc>
oliv3r: I don't remmeber in detail, but removing the emac_power line in the .fex of people having ethernet troubles tends to fix things
<oliv3r>
mnemoc: right now, the 3.4 kernel keeps constantly dumping shit
<mnemoc>
:(
<oliv3r>
mnemoc: i .. need detail :p
<mnemoc>
i need power outlets :(
<oliv3r>
u-boot doesn't seem to work (but i'm a little light on how to use 'mii info etc'
<oliv3r>
nand android doesn't work anymore (it did before)
<oliv3r>
3.11 doesn't work either
<oliv3r>
it's like it's completly gone
<oliv3r>
mii dump 'thinks' all my phy registers are 0xffff
<mnemoc>
uh
<oliv3r>
so that emac_power line may be what I need? :)
<oliv3r>
but again, i use stock android and it no longer works :S I figured that one would be 'good'
<mnemoc>
check the .fex in sunxi-boards
<oliv3r>
ok
<oliv3r>
also, the 3.11 kernel doesn't even use emac_power/fex so that should work? but doesn't
* mnemoc
can't comment about sunxi-next stuff, never tried it
<oliv3r>
:p
<oliv3r>
well it uses dt instead of fex :p
<oliv3r>
so the fex can't be of influence :)
<wingrime>
oliv3r: I make dev2mem for cedar
<oliv3r>
but i'll check the stock fex
<oliv3r>
wingrime: awesome :D
<wingrime>
and sesms to be workable
<mnemoc>
in boards with phy power u-boot needs to be told what pin to setup
<mnemoc>
same for linux itself
<mnemoc>
no idea how the mainlined code deals with that
<oliv3r>
ok, well u-boot doesn't work either i think
<oliv3r>
i'll test stock-uboot
<wingrime>
oliv3r: if I give you my source can you play?
<mnemoc>
sad to see stefanro is no longer here
<oliv3r>
wingrime: working on mac :(
<oliv3r>
mnemoc: he gave up?
<mnemoc>
no idea
<mnemoc>
but not in /names
<oliv3r>
stock u-boot doesn't have mii commands :S can stock u-boot even do network boot?
<wingrime>
oliv3r: do HARD reset, disconnect power and all wires and wait some time
<mnemoc>
he made the initial driver used in u-boot and mainline
<oliv3r>
wingrime: i've waited 12 hours :p that not long enough?
<wingrime>
oliv3r: no ANY POWER
<oliv3r>
wingrime: yeap, i've disconnected the entire board over night
<wingrime>
1 min
<wingrime>
we have no fues
<wingrime>
so may be some emac eeprom ?
<oliv3r>
there's no mac/eeprom on cubieboard
<oliv3r>
mnemoc: i don't think it's PHY_POWER define, because i haven't changed stock nand
<oliv3r>
mnemoc: and it did work a few days ago
<mnemoc>
btw, can I use hno's fel-boot to boot 3.4?
<wingrime>
oliver: try downgrade uboot
<oliv3r>
maybe rz2 or hno know
<oliv3r>
wingrime: sotck is allt he same
<wingrime>
crap
foubarre has joined #linux-sunxi
<wingrime>
oliv3r: any way my tool is userspace
<wingrime>
can read and write cedar
<wingrime>
it do proper init to it
<wingrime>
just fixed memdev2
<wingrime>
ssvb: are you here?
<ssvb>
yes
<wingrime>
can you test tool
<wingrime>
I just successfully readed ID from cedar
<wingrime>
?
<foubarre>
hi. One module i compile (iscsitarget) asks for mach/timex.h. Any idea of what that is and what to do to have it? i can find it on the net, but not as an instalable package. It will certainly not be enough.
<wingrime>
it modifited memdev2 with some ioctrl ro cedar
<ssvb>
wingrime: Value at address 0x1C0E0F2 (0xb6f030f2): 0x1623
<ssvb>
wingrime: that's on the following hardware - [ 0.000000] chip-id: A10 (AW1623 revision B)
<wingrime>
as expected
eebrah|away is now known as eebrah
<wingrime>
I have 1625
<ssvb>
great
<wingrime>
you can try play arround
<wingrime>
for example 0xb6f03000 - reset/inner clocks reg
<wingrime>
sorry no
<ssvb>
maybe you should ask some a10s owners to check what revision they get reported?
<wingrime>
0x1C0E000
<wingrime>
now can
<ssvb>
yes, I can play around with cedarx regs, but don't see much purpose for it yet
<ssvb>
you are the reverse engineering guy ;)
<foubarre>
is this possible that timex.h is there only when high res timer is enabled on kernel compile?
<hglm>
ssvb: I did some benchmarks with the sunxifb driver. I posted some suggestions on github.
<ssvb>
wingrime: are you going to make a chip revision identification patch for u-boot and/or the kernel based on cedarx hw regs?
<ssvb>
hglm: yes, I will reply in a few minutes, thanks
<wingrime>
ssvb: such possible
<wingrime>
but we have simple "SRAM" way
<wingrime>
cedar need enable many clocks
<mnemoc>
wingrime: can you prepare a little "greeting" line for the cedarx kernel driver including this info?
<ssvb>
mnemoc: +1
<ssvb>
wingrime: ok, it's indeed good to have many options to select from, if sram works better then it makes sense to use it
<ssvb>
wingrime: btw, what happens if you try to "fake" the hw revision for cedarx blob on your a13 hardware (for example, pretend that it is a10)? will video playback break?
<mnemoc>
adding this kind of "greeting" we can easily collect info from bug reports
<mnemoc>
and help REing
<ssvb>
wingrime: I just wonder how big are the differences between the cedarx hardware on a10 and a13 in practice (will everything break? will some codecs break? anything else?)
<ssvb>
wingrime: or are just the addresses of some hw registers different and everything else is the same?
<wingrime>
ssvb: I know that mp4 have some diffs ass clocks have some diffs
<rellla>
mac adress is set randomly, although dmesg output seems to be ok
<mnemoc>
rellla: are you able to manually set that cb:cb:.... mac using userspace tools?
<mnemoc>
maybe it is invalid for some reason
<wingrime>
0x01c0e230 constain frame base POINTER
<wingrime>
ssvb: cedar also can read memory own way
<wingrime>
code build some memory block for it
mdfe has quit [Disconnected by services]
mdfe has joined #linux-sunxi
mdfe has quit [Disconnected by services]
mdfe_ has joined #linux-sunxi
<ssvb>
wingrime: yes, I'm pretty certain it can, the allocation of memory for frames is handled by the opensource code parts (kernel and userland), the cedarx hardware must be able to use these buffers somehow
tinti has quit [Read error: Connection reset by peer]
tinti has joined #linux-sunxi
<ssvb>
wingrime: the allocation is done as physically contiguous blocks from the reserved memory area, these physical addresses are passed to the cedarx blob as part of the video decoding process
<wingrime>
check_bs_dma_busy in blob))
<wingrime>
I think that addreess passed to 0x01c0e230
<rellla>
mnemoc: tried another mac_addr, the CB seemed to be invalid in a way. thanks
<rellla>
now it works
<wingrime>
0x01c0e228 constain dma base
<wingrime>
status
<wingrime>
i mean busyness
<ssvb>
wingrime: just try to verify everything you find with some simple test programs (just like you did for the hw revision check) and document it in the wiki
<wingrime>
too much conditions to do
<wingrime>
I still can't run warper right way\
<wingrime>
and need patch it
<ssvb>
some people prefer to start with recording the trace of hw registers accesses and attempting to replay it
<ssvb>
if it works, that's an important milestone which simplifies everything a lot
<ssvb>
trace/replay is a bit more reliable approach than just guessing and shooting in the dark
sanka has quit [Quit: Leaving]
wingrime has quit [Ping timeout: 248 seconds]
tinti has quit [Remote host closed the connection]
eebrah is now known as eebrah|away
Yaku has joined #linux-sunxi
Undertasker has quit [Read error: Connection reset by peer]
n01 has joined #linux-sunxi
Undertasker has joined #linux-sunxi
tomeff has quit []
Undertasker has quit [Ping timeout: 256 seconds]
Undertasker has joined #linux-sunxi
rellla has quit [Remote host closed the connection]
<hno>
mnemoc, fel-boot was tested using 3.4.
<mnemoc>
hno: awesome
<hno>
ssvb, there probably is only small cedarx differences, but there is clock module differences which will break if you try to mix.
Undertasker has quit [Ping timeout: 256 seconds]
<Turl>
mnemoc: can you check if that guy oliver with a blackberry is subscribed to the list?
<hno>
mnemoc, 19 seconds to kernel start for uploading a full linux-3.4 + busybox initramfs.
<mnemoc>
hno: nice!
<mnemoc>
Turl: 1m
Undertasker has joined #linux-sunxi
Undertasker has quit [Read error: Operation timed out]
<hno>
I haven't tested full usb boot on A13 yet, only loading u-boot.bin. But should work fine.
Undertasker has joined #linux-sunxi
<foubarre>
hello. I am compiling a kernel module under a sunxi based debian, from RM's website. File arch/arm/include/asm/timex.h refers to a mach/timex.h that is not present. Any idea of what i goofed?