ChanServ changed the topic of #linux-sunxi to: Allwinner/sunxi development discussion - Don't ask to ask. Just ask! - See | | Logs at
<hno> Oh, the A13 manual includes the security system. nice.
<hno> And just found an undocumented register 0x01c00024 which is the uboot button.
<Turl> hno: I have POC code to hash stuff using the security system
<hno> Turl, nice!
<Turl> hno: stuffing data through a 32 bit fifo is pretty slow though
mdfe_ has quit [Remote host closed the connection]
<hno> Aha, 0x1c00024 can also return the chip id.
<Turl> hno: no docs on SDRAM controller that I can see, did you find that out by looking around on the registers?
<hno> This is the SRAM controller, or more likely (as hintet by doc headers) system control registers. Only the SRAM bits is somewhat documented.
<hno> The uboot button was found looking in BROM and confirmed by reading the register from u-boot shell.
<Turl> cool :)
<hno> The chip-id was found by accident looking at the raw register dumps in
<hno> "All to 1" section.. "whait, what does that 1623 value do there???"
<hno> then a little probing to find what makes it appear.
<hno> Added to the wiki.
<hno> Wonder why it's hidden by default.
<hno> doesn't make sense.
<Turl> indeed
<hno> And what is all those other registers doing? There is obviously plenty of registers here.
<hno> mnemoc, dint you ask for an easy to read chip id?
egbert has quit [Disconnected by services]
egbert has joined #linux-sunxi
<Turl> rm: re. email, I also got a couple, but they went directly to spam
<Turl> they certainly weren't hundreds though
<Turl> more like a couple
<Turl> hm, simple-framebuffer patches look interesting
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> root@debian:/sys/bus/platform/devices# fdisk /dev/nand
<lkcl> Device contains neither a valid DOS partition table, nor Sun, SGI or OSF disklabel
<hno> well.. no. And neither does MTD.
<lkcl> ok.... hmmm
<lkcl> parted?
<hno> MTD is not block storage.
<lkcl> hmmm.... ahhhh
<lkcl> ok.
<lkcl> ok... so how the heck do you set up partitions!! :)
* lkcl starts investigating....
<hno> For Allwinner NAND driver you use the nand-part program in sunxi-tools.
<lkcl> hno: euuuw :) that's gonna go down well in debian-installer :)
<lkcl> hipboi: thx
<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
<hipboi> hno, and i found a fix for that,!searchin/linux-sunxi/fel.c/linux-sunxi/6c4bvNiAzdY/sUgS4FnlHzsJ
<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 yet ;)
<rellla> you can disable cursor blinking and fb blanking. see
<rellla> i crashed my sd-card yesterday. but it's ok now, so i can test the inittab-version
<hramrach_> yes, cursor can be turned off but xbmc does not do that
<lkcl> could someone please point me at the GPL-violating binary nand driver in the a20 sources?
<lkcl> which file?
<hramrach_> yes, looks good
<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-android> and play around
wingrime has joined #linux-sunxi
<wingrime> try this
<wingrime> oliv3r: some magic stuff
<oliv3r> i don't have any setup that can do anything really
<oliv3r> i've only got u-boot + 3.10 right now for my cubie
<wingrime> oliv3r: withch registers are interesting ?
<wingrime> in SRAM iospace
<oliv3r> for cedarX?
<wingrime> generaly
<wingrime> withch are working and unknown
<oliv3r> 0x1c00000 0x54 long
<oliv3r> and then of course 0x01d00000 - 0x1d7fffff
<oliv3r> that's SRAM for cedarX
<wingrime> wait
<wingrime> SDRAM CLK:0xf1c20100 is:%x\n"
<wingrime> this reg are known?
Guest44089 is now known as tek_0
<oliv3r> you sure it starts at 0xf1c201000?
<oliv3r> that first F isn't supposed to be 0x01c2?
<wingrime> don't know
<oliv3r> becuase 0xf1c201000 is unknown in our memory map for now
<oliv3r> 0x01c201000 is the Clock Control MOdule
<oliv3r> i see
<oliv3r> but that's wrong
<oliv3r> or rather, that's virutal memory
<oliv3r> 0x01c2010018 is PLL4 clock gate
<oliv3r> just as your L1047 says, PLL4
<oliv3r> but appearantly, we need to enable PLL4, AHB, VE and SDRAM clocks
<oliv3r> oh
<oliv3r> OH
<oliv3r> ok
<oliv3r> i'll boot u-boot and see if i can enable those clocks
<wingrime> oliv3r: I think cedar use inner dma to copy mem and cedar JUST NEED POINTER TO MEM AND RET BUFFER
<wingrime> for macro cell
<oliv3r> wingrime: yes, I think using SRAM C1
<oliv3r> SRAM C1 is the memory they use to copy data back/forth
<oliv3r> so let me test
<oliv3r> gimme 10
<wingrime> oliv3r: SRAM only AS TEMP sorage
<oliv3r> i think i dissagree :p
<oliv3r> but that's just my gut feeling, and they may very well be wrong
<wingrime> oliv3r: you can dump sram when cedar worknig?
<oliv3r> well, we know cedar X needs HUGE amounts of memory
<oliv3r> in a min
<oliv3r> working on it
<oliv3r> anyway, we know we have to reserve memory for g2d, Framebuffer, mali AND VE!
<oliv3r> so we know VE 'needs' DRAM internally
<oliv3r> since you fully reserve it
<oliv3r> anyway, let me enable those 4 clocks and check VE
<oliv3r> what reg addres is MACC?
<wingrime> wiMACC_REGS_BASE = (REGS_BASE + 0x0E000)
<wingrime> 0x01C00000 + 0x0E000
<oliv3r> 0x01c0e000 ty
<wingrime> oliv3r: dump SRAM when cedar workoing
<wingrime> and more one
<oliv3r> that looks right, all 0 now
<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
<wingrime> oliv3r: try read VE VERSION
<oliv3r> AHB clock is all disabled :(
<oliv3r> well lets enable CCM_AHB_GATE_VE :D
<wingrime> USB access to SRAM mem
<oliv3r> yeah, it can use SRAM for buffering, but I think sram for USB is available without the clocks etc
<oliv3r> crap
<oliv3r> can't enable CCM_AHB_GATING1's CCM_AHB_GATE_VE
<oliv3r> can't write 1 to it
<wingrime> may be you need setup PLL
<oliv3r> i did'
<oliv3r> well only pll4
<oliv3r> need to know how to enable the AHB clock
<wingrime> usb use sram for fifo
<oliv3r> oh, i was writing the wrong registers :(
<oliv3r> lets start again :D
<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 :)
<wingrime> oliv3r: I want may dumps for page ))
<oliv3r> oh! i can write AHB_GATE_VE to 1 :)
<oliv3r> I wonder what CCM_VE_N does :S
<oliv3r> no go :(
<oliv3r> MACC_REG is still set t ozero with all clocks on
<wingrime> oliv3r: PLL config
<oliv3r> it's on
<oliv3r> i crashed my cubie :D
<wingrime> reset VE
<oliv3r> I did!
<oliv3r> it crashed my cubie
<wingrime> It means you have wrong PLL
<wingrime> settings
<oliv3r> i'll try again :)
<wingrime> you need dunp pll's from working cedarx
<oliv3r> stil crashes cubie
<oliv3r> i enable VE gate; then rset VE
<oliv3r> BAM crash
<wingrime> SRAM?
<oliv3r> 1 more thing i want to test
<oliv3r> yeah test SRAM with the VE gate on
<wingrime> oliv3r: yes
<wingrime> you still need sram enabled for cedar
<wingrime> and wiki, wiki
<oliv3r> lol
<oliv3r> wiki wiki
<oliv3r> but isn't sram enabled by default?
<wingrime> SRAM for cedar
<oliv3r> yeah that's mapped to cedar by default
<wingrime> not sure
<oliv3r> md 0x01c00000
<oliv3r> 01c00000: 7fffffff
<wingrime> It may be not mapped by default
<wingrime> try set VESRAM after CedarX gate on
<oliv3r> mtest is gone from my u-boot?
<oliv3r> VESRAM? You mean SRAM C1
<wingrime> yes
<wingrime> befor VE RESEET
<oliv3r> yeah that's always ampped to cedar
<oliv3r> ok, how do I do mtest in the latest u-boot?!
<oliv3r> oh i think it's 'loop' no
<oliv3r> now*
<oliv3r> hmm, loop just hangs
<wingrime> any success
<wingrime> ?
<oliv3r> nope
<oliv3r> giving up for now
<oliv3r> gonna test emac again; my cubie had functioning wired lan; but since 2 days, it doesn't work at all anymore
<oliv3r> [ 67.050229] wemac wemac.0: tx time out.
<oliv3r> :(
<oliv3r> could any cubieboard owner with wired LAN confirm dmesg | busybox grep -i wemac
<oliv3r> <6>[ 0.225522] wemac Ethernet Driver, V1.00 in file:drivers/net/sun4i/sun4i_wemac.c
<oliv3r> <7>[ 0.235941] wemac wemac.0: PHY SETUP, reg 0 value: ffff
<oliv3r> <7>[ 0.236947] wemac wemac.0: resetting device
<oliv3r> <7>[ 16.589195] wemac wemac.0: enabling eth0
<oliv3r> <4>[ 16.589220] wemac wemac.0: WARNING: no IRQ resource flags set.
<oliv3r> <7>[ 16.600167] wemac wemac.0: resetting device
<oliv3r> <6>[ 16.610592] wemac wemac.0: eth0: link up, 100Mbps, full-duplex, lpa 0xFFFF
<oliv3r> <6>[ 27.061947] NETDEV WATCHDOG: eth0 (wemac): transmit queue 0 timed out
<oliv3r> that's all I get, no ip, no connection nothing
<oliv3r> lights don't come on nothing
<wingrime> look like fex probem....
<wingrime> may be
<oliv3r> but I didn't touch fex
<oliv3r> I _guess_ i changed some register that the EMAC didn't like
<oliv3r> but it should reset after power on
<wingrime> we have some map in
<oliv3r> wingrime: lol yeah i wanted to get some info down
<oliv3r> but it all failed :(
<wingrime> please don't think that VE only for a10)
<wingrime> oliv3r: what problem with dumping
<wingrime> &
<wingrime> ?
<oliv3r> it's all 0 :p
<oliv3r> anyway, i'm looking at emac now why mine isn't working anymore :(
sanka has joined #linux-sunxi
<dwilkins> hno: RE: "don't re-implement pinmuxing control" - is the interface you're referencing in pinctrl.txt?
<oliv3r> dwilkins: what are you after specifically?
<dwilkins> hno told me to "don't re-implement pinmuxing" and looking for pinmuxing in the source is like finding a needle in a stack of needles
<dwilkins> Just trying to dial in this pwm patch
<oliv3r> i see the mail :)
shineworld has joined #linux-sunxi
<dwilkins> I've messed around with the fex files before, but there's no definition for pwm
<oliv3r> you'll have to add it ;)
<oliv3r> the fex files get parsed by a function in the kernel
<oliv3r> you can get settings from those for your pwm
mdfe has quit [Remote host closed the connection]
<oliv3r> see that for example
<dwilkins> k - thanks
<dwilkins> so - I need to update/test fex2bin / bin2fex / fexc to add a para_pwm section or something?
<dwilkins> oliv3r: no documentation on these script_parser_* functions?
<lkcl> Jan 1 00:00:23 localhost kernel: [ 13.660000] ep_matches, wrn: endpoint already claimed, ep(0xc07e74e8, 0xeeab4880, ep4-bulk)
<lkcl> Jan 1 00:00:23 localhost kernel: [ 13.680000] g_cdc gadget: acm/ee971f00: can't bind, err -19
<lkcl> anyone any ideas? this is "modprobe g_cdc" when there are *no* other gadget drivers loaded
<lkcl> very weird
<lkcl> someone kindly pointed out that the tasks of g_ether and g_serial are combined in g_cdc but that's the error i get (!)
<wingrime> oliv3r: I can confirm that a13 return ID right
<wingrime> unsing memdev2
<wingrime> I mean SDRAM chip ID
<oliv3r> dwilkins: no, fex2bin does it automatically right, just add it to the fex file, bin it, and parse it in your driver
<oliv3r> and wikiwiki
<wingrime> was aleady
<wingrime> I just checked myself
<oliv3r> wingrime: awesome
<oliv3r> i need to figure out what register broke my emac :(
<wingrime> also Secure section not wrokable
<wingrime> for a13
<wingrime> nand space writable!
<mnemoc> hno: nice! but distinguishing A10S from A13 is still a mistery. the sid voodoo in their tree doesn't really work :<
<wingrime> mnemoc: wee need some with a10s
<wingrime> I have any a10s HW
<mnemoc> tsvetan was going to send a couple of his a10s olinuxinos
<mnemoc> i'll update the soc-detect code to read the chip_id from cedarx and sramc and to dump the sid
<mnemoc> got a cubie back today
<mnemoc> then we can start collecting data
<wingrime> mnemoc: with cedarx it not so simple you need gate on, set pll and reset cedar
<mnemoc> :|
<wingrime> sram are easy
<wingrime> you simply need set 1 bit and read
<mnemoc> maybe we can query the disp controller to see if there is hdmi support or not
<mnemoc> a10s has hdmi, a13 doesn't
<wingrime> that we need just check some bits form disp
<wingrime> I don't know how undocumented stuff work
<mnemoc> not even allwinner knows. their soc-detect stuff only checks the sid
<mnemoc> and fails on it
<mnemoc> they are happy with per-soc branches
<mnemoc> we don't
hramrach_ has quit [Remote host closed the connection]
<wingrime> oliv3r: are you still here
<wingrime> ?
hramrach_ has joined #linux-sunxi
<oliv3r> wingrime: yeah
<oliv3r> wingrime: you mean the memory area for NAND? I just put that up earlier and its only a guess, but I think it's known that those 2k are usable
<oliv3r> how 'unbrickable' is the A10? Is it possible, in theory, that wrong register settings fry the PHY for emac?
<oliv3r> or did my mac just break out of bad luck
<oliv3r> i still think, it's quite possible one series is simply 'binned' chips, where some parts failed to work, and repurposed for other things
<wingrime> I find intersting address
<wingrime> page 83 a13 user man
<wingrime> writing first bit hung all
<oliv3r> cpu control register?
<oliv3r> i find it funny how the default value is '2' which is a 'reserved' bit
<oliv3r> wingrime: that is interesting
<oliv3r> because when I wrote the SRAM controler bit on the wiki; i used the a10 manual
<oliv3r> so it looks like the SRAM_CONTROL_024 or whatever is called is actually somewhat deocumented in the A13 datasheet
<oliv3r> usermanual*
<oliv3r> just the register offset is different/wrong
<oliv3r> they have 0x20 there
_BJfreeman has joined #linux-sunxi
<oliv3r> wingrime: you haev a13 right?
<oliv3r> can you load u-boot?
_BJfreeman is now known as BJfreeman
<oliv3r> do:
<oliv3r> md 0x01c00000 0x40
<oliv3r> Then do:
<oliv3r> mw 0x01c00000 0xffffffff 0x40
<oliv3r> followed by md 0x01c00000 0x40
<oliv3r> all to 0 isn't that interesting
<oliv3r> take special note of register 0x01c00024
<wingrime> oliv3r: open case, solder uart - too long
<wingrime> it "tablet"
<oliv3r> oh yeah
<oliv3r> i really am curious what your registers say there
ganbold_ has joined #linux-sunxi
ganbold__ has quit [Ping timeout: 256 seconds]
<lkcl> hno: ping. got an idea. boot.scr in ram, as a u-boot image, at a known location. if it exists, load and execute it. thoughts?
<lkcl> boot_ram only works (by default) as a final fall-back measure
tek_0 has quit [Quit: Bye bye]
<oliv3r> wingrime: A13 does not have 'secure ram'?
<oliv3r> i find that hard to belive
<mnemoc> who here was using rtl8188eu? can you test hansg drivers in stage/sunxi-3.4 please?
<oliv3r> not me
<oliv3r> mripard: + to skip all the questions about Davicom cards. If you say Y, seems like a typo ;)
<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
<oliv3r> mnemoc: cubieboard stock nand? u-boot?
<oliv3r> mnemoc: please more info :)
<wingrime> oliv3r: you just need make HARD reset
<wingrime> for emac
<wingrime> problem
<wingrime> turn off power
<wingrime> not simple reset
<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: sure
<wingrime> wait i cpoy/paste code
<wingrime> ./cedar2 0x01c0e0f2
<wingrime> this must return id
<wingrime> also I should add many regs dumping feature
tomeff has joined #linux-sunxi
<ssvb> wingrime: bad paste: test.c:30:1: error: stray '\302' in program
<wingrime> sory
<wingrime> wait a second
Undertasker has joined #linux-sunxi
rz2k has joined #linux-sunxi
<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> hi all, what happens, that i cannot set my mac address?
<rellla> dmesg shows it right, but ifconfig doesn't
<mnemoc> ifconfig is a pre-2.3 tool
<mnemoc> try `ip link`
<rellla> mnemoc, the same mac. but not that one of my kernel args line
<mnemoc> bad kernel args?
<rellla> hm. see my paste, line 87 and 181
<rellla> sry 27
<rellla> oh. there is sth wrong... wait 1min
fredy has quit [Ping timeout: 256 seconds]
fredy has joined #linux-sunxi
mdfe has joined #linux-sunxi
ganbold_ has quit [Remote host closed the connection]
<rellla> ok. so i don't understand whats wrong here:
<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> mnemoc, u-boot.bin + uImage + initramfs used in testing is at, just add your script.bin. (well, the one there works on cubieboard too...)
<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?
<foubarre> is what i get when installing the package...
<lkcl> hmmm.... i just did a "git pull" on stage/sunxi-3.4 and i'm not able to get a boot of the eoma68-a10 card any more. argh! :)
<lkcl> hno: what's gone into stage/sunxi-3.4 and what's a good tag to use?
<hno> no idea.
forcev_ has quit [Ping timeout: 264 seconds]
<hno> lkcl, I used b341bf8889e5e553d20f0e14115e5f4a3530ff10, but you can use "git reflog" to find what you had before.
<lkcl> ahh awesome
<lkcl> ahh yep that's the one
<lkcl> hno: thanks. saves me wandering about randomly :) i'd missed the one with the __devinit, i'd tried the 3.4.43-r0 tag
FunkyPenguin has quit [Ping timeout: 245 seconds]
FunkyPenguin has joined #linux-sunxi
forcev has joined #linux-sunxi
<hno> lkcl, there was a massive realtek wifi update, and some mmc changes.
<hno> it no longer found your mmc card?
<lkcl> hno: pretty much, yeah.
<lkcl> and without the __devinit i also can't get a boot going.
<mnemoc> 3.4.43-r0 is just after the version jump. can you try sunxi-v3.4.29-r2 ?
<mnemoc> that was the last before the latest version update
<mnemoc> changes between sunxi-v3.4.29-r2 and sunxi-v3.4.43-r0 are from upstream^2
<mnemoc> problem can be there
n01 has quit [Quit: leaving]
rellla has joined #linux-sunxi
<hno> mnemoc, the __devinit change is after, just before the last round of patches.
<mnemoc> yes, but he can cherry-pick it over sunxi-v3.4.29-r2
<mnemoc> i don't know if sunxi-v3.4.43-r0 boots for anyone
<mnemoc> i believe sunxi-v3.4.29-r2 does
<hno> what you want to find if 3.4.43 with __devinit fix do boot?
<mnemoc> people used to be able to boot 3.4
<hno> well, before the __devinit fix the kernel could not guarantee that hte code was there to boot.
<hno> as we were executing code in already freed memory.
<mnemoc> so I would like to know of luke problems are also present in the last 3.4.29, or if it's a regression of the 3.4.43 jump
<mnemoc> (because I don't trust -r0 tags)
<hno> well.. 3.4.43 do boot fine. But I never tried the -r0. Don't trust in booting kernels where the linker says things are broken.
<mnemoc> :)
<hno> building the last changes now to see if the MMC breaks for me as well.
<hno> mnemoc, the __devinit issue have been there for quite a while I think.
mdfe_ has quit [Remote host closed the connection]
rz2k has quit []
<lkcl> hno: ack. hmmm
drachensun has joined #linux-sunxi
<hno> lkcl?
shineworld has quit [Quit: Leaving]
<hno> crap... why do busybox no longer compile?
<hno> nevermind. seems it was just some garbage in my build dir. built fine now.
de has quit [Ping timeout: 256 seconds]
foubarre has quit [Remote host closed the connection]
Undertasker has quit [Ping timeout: 260 seconds]
<lkcl> hno: :)
<lkcl> oh right. i see the 3.4.29 thing. yeah let me try to get back to known-good working state first
<lkcl> arg i think it was a busybox issue (i'd recompiled busybox with more options...)
paulk-desktop has quit [Quit: Ex-Chat]
Undertasker has joined #linux-sunxi
Undertasker1 has joined #linux-sunxi
<oliv3r> erm i don't have a blackberry :0
<oliv3r> Turl: why do you think I have a blackberry :)
<mnemoc> oliv3r: different oliver
Undertasker has quit [Ping timeout: 276 seconds]
<oliv3r> there is only 1.
<oliv3r> mnemoc: do you have your cubie available?
<mnemoc> oliv3r: the other has address
<mnemoc> oliv3r: yes, but no power outlets. going to buy a power strip tomorrow
<hno> lkcl, probably. Seems to work for me.
<oliv3r> mnemoc: oh you need powe rbadly
<oliv3r> powe rit over USB
<mnemoc> my laptop can't feed enough power
<hno> It can't?
<mnemoc> i get red led, but nothing on the uart
<mnemoc> will try again tomorrow with my 4A hub.... once I get where to plug it's PSU
<hno> I don't hinki I ever powered my cubie using the power jack. Always USB I think.
<hno> hmm.. think it's time for bed. Letters are not quite coming out in the right order.
* mnemoc going to sleep too. good night
<hno> and what I have been working on works.. so yes.
<lkcl> hno: :)
<lkcl> night mnemoc
Undertasker1 has left #linux-sunxi [#linux-sunxi]
hglm has quit [Quit: leaving]
<oliv3r> nn all
<oliv3r> i should go too
<oliv3r> i'll whine about how to fix emac again tomorrow
BJfreeman has quit [Ping timeout: 245 seconds]
_BJfreeman has joined #linux-sunxi
_BJfreeman is now known as BJfreeman
<lkcl> ahhhh at laaast, serial console my frieeeeend
<lkcl> my very bestest frieeeeend :)
vicenteH has quit [Ping timeout: 264 seconds]