hno changed the topic of #linux-sunxi to: /Allwinner/sunxi development discussion - Don't ask to ask. Just ask and wait! - See | | Logs at
\\Mr_C\\ has joined #linux-sunxi
egbert_ has quit [Ping timeout: 246 seconds]
egbert has joined #linux-sunxi
egbert has quit [Ping timeout: 246 seconds]
egbert has joined #linux-sunxi
BJfreeman has quit [Read error: Connection reset by peer]
akaizen has quit [Remote host closed the connection]
naobsd has quit [Quit: Page closed]
\\Mr_C\\ has quit []
TheSeven has quit [Disconnected by services]
[7] has joined #linux-sunxi
uwe__ has joined #linux-sunxi
uwe_ has quit [Ping timeout: 256 seconds]
\\Mr_C\\ has joined #linux-sunxi
deasy has joined #linux-sunxi
deasy has quit [Remote host closed the connection]
fredy has quit [Excess Flood]
fredy has joined #linux-sunxi
akaizen has joined #linux-sunxi
rellla has joined #linux-sunxi
techn_ has joined #linux-sunxi
deasy has joined #linux-sunxi
ganbold_ has joined #linux-sunxi
wingrime has joined #linux-sunxi
sanka has joined #linux-sunxi
mirceac has joined #linux-sunxi
<mirceac> hello everybody
<mirceac> I have a question, maybe someone can help me
<mirceac> so in short I have an A13 tablet that doesn't have the modules for usb-serial and btooth that will help me connect an external GPS adapter
<mirceac> the tablet is rooted and it has android 4.0.4 with kernel 3.0.8+
sanka has quit [Read error: No route to host]
<mirceac> I have quite good knowledge of linux and programming but almost none of the android development
sanka has joined #linux-sunxi
<mirceac> so if anybody can hold my hand for compliling and installing those modules I'll be really greatful
<mirceac> I think that adding usb-serial and bt modules to an A13/A10 device it deserves a Wiki article, it seems to me that is a very searched topic with almost none answers
<mirceac> I volunteer to document the process and ecentually contribute some compiled modules.
heffer has quit [Remote host closed the connection]
heffer_ has joined #linux-sunxi
heffer_ has joined #linux-sunxi
<rah> is there a way to get kernel output over the USB connection on an Allwinner tablet?
mirceac has quit [Quit: Page closed]
bamvor has quit [Ping timeout: 255 seconds]
bamvor has joined #linux-sunxi
libv has quit [Ping timeout: 260 seconds]
libv has joined #linux-sunxi
techn_ has quit [Read error: Connection reset by peer]
techn_ has joined #linux-sunxi
geecko has joined #linux-sunxi
<geecko> hi
naobsd has joined #linux-sunxi
<rah> rah@myrtle-ubu:~/pengpod/sunxi-tools$ make fel-sdboot.sunxi
<rah> make: *** No rule to make target', needed by el-sdboot.elf'. Stop.
<rah> urg
<rah> rah@myrtle-ubu:~/pengpod/sunxi-tools$ make fel-sdboot.sunxi
<rah> make: *** No rule to make target `', needed by `fel-sdboot.elf'. Stop.
<rah> how do I make an fel-sdboot image?
ganbold__ has joined #linux-sunxi
ganbold_ has quit [Remote host closed the connection]
deasy has quit [Quit: Quitte]
<oliv3r> mornin' all
jemk has joined #linux-sunxi
rellla has quit [Quit: Nettalk6 -]
<wingrime> jemk: ping
<jemk> wingrime: pong
<wingrime> jemk: about testing condition
<wingrime> jemk: you tryed this on working system?
<jemk> wingrime: the sram things? on uboot
<wingrime> jemk: nice
<jemk> the ve sram contains 132 kB of read only constant data, looks like a ROM
<wingrime> also, warps around only means that address bus hi-bits wires not connected
<wingrime> jemk: 64 kB writable?
<jemk> 62kb
<jemk> and many short parts with constant zero areas between them
<wingrime> jemk: can you try dump it when we use jpeg /mpeg
<jemk> thats a little bit hard with uboot
<wingrime> jemk: you can use /dev/mem
<wingrime> *kmem
<jemk> omg, of course...
<jemk> didn't think about that
<wingrime> jemk: devmem2.c can write / read using kmem
<wingrime> jemk: if you leave jpeg/mpeg code unreleased
<rah> anyone know how to get a Mele A1000G into FEL mode?
<wingrime> jemk: also, you can try with uboot read cedarA
<wingrime> sram
<wingrime> oliv3r: ping
<wingrime> hno: ping
<jemk> wingrime: same procedure with ACE sram, only 6.75 kiB useable
hipboi has joined #linux-sunxi
<wingrime> jemk: please no dots in size, you can use bytes
<wingrime> 6750 B
<wingrime> jemk: so, last untested thing, BIST,
<wingrime> build-in-self-test
<wingrime> jemk: there some <unknown> plls
<wingrime> clocks
<wingrime> oliv3r: !!!
<wingrime> CCM_AHB_GATE_BIST
<wingrime> jemk: ^
<oliv3r> Built In Self Test?
wingrime has quit [Ping timeout: 245 seconds]
wingrime has joined #linux-sunxi
<wingrime> jemk: any results?
<jemk> wingrime: no, i don't find the right clock
kaspter has joined #linux-sunxi
<oliv3r> right clock for?
mouchon has joined #linux-sunxi
<jemk> c3 sram
<wingrime> oliv3r: BIST
<jemk> BIST is something different
<wingrime> oliv3r: gate are present
<oliv3r> ISP/BIST you mean?
<wingrime> yes
<jemk> c3 sram is for isp
<oliv3r> or built in self test
<oliv3r> maybet aht's why i couldn't get C1 and C2 to work either, because i hadn'ts etup the clocks for it
<wingrime> oliv3r: question witch clock for it
<oliv3r> i would have assumed SRAM always works
<jemk> oliv3r: see wiki, it works after enabling right clocks
<oliv3r> so if you setup the proper clocks for ACE/VCE, then maybe you can use them
<wingrime> oliv3r: see wiki, jemk get cedarA and cedarV s-ram works
<oliv3r> oh you updated it allready?
<oliv3r> good good :)
<oliv3r> so your looking for the BIST clock now?
<wingrime> yes
<jemk> not bist, isp
<wingrime> oh yes, but BIST also must have some clock
<oliv3r> BIST or ISP
<oliv3r> you can remap it
<jemk> wiki is confusing there, bist is some sort of memtest and is for all srams
<oliv3r> ah, quite possible
<jemk> c3 is "isp" sram, not "isp/bist"
<oliv3r> could be very well a naming issue
<oliv3r> the manual is really shit :)
<wingrime> bist possible not s-ram only,
<wingrime> CPU
<oliv3r> well there's bit 25, 27-31 that could be ISP
slapin_nb has quit [Remote host closed the connection]
<wingrime> oliv3r: it good chance figure
<wingrime> oliv3r: becose only correct clock will enable isp sram
<oliv3r> well it could also be hidden in CCM_AHB_GATE1
<oliv3r> if you only needt o enable Gate0 and Gate1 clocks to get sram working, just set them to 0xffff
<wingrime> oliv3r: I thinking about strange thing , move DRAM init from spl, to main uboot image
<wingrime> oliv3r: if we can fit uboot in s-ram , (with hacks ) so, we can make DRAM settings dynamic
<oliv3r> u-boot SPL fits fully in SRAM
<oliv3r> we can do 'falcon' mode now, and skip u-boot and do SPL -> kernel (needs a little work though
<wingrime> oliv3r: we have secure s-ram
<oliv3r> that we knew
<oliv3r> yeah but the BROM can only read 24k max
<oliv3r> so that's your limitation
<wingrime> oliv3r: I not saying drop SPL
<wingrime> oliv3r: I only think move DRAM init from SPL to uboot main image
<oliv3r> but how do you think that can be done
<oliv3r> SPL loads u-boot INTO dram
<oliv3r> so if you move dram init from SPL, how can SPL load u-boot? :)
<oliv3r> unless you mean, load u-boot into SRAM-B
<wingrime> yes
<oliv3r> but then you'd break falcon mode
<oliv3r> and falcon mode is pretty cool
<oliv3r> you don't need u-boot anymore, you just do SPL -> kernel
<wingrime> falcon use SRAM-B ?
<oliv3r> spl loads kernel into DRAM
<oliv3r> maybe even into sram2 if you wanted too i suppose :) run kernel from SRAM2 :D
<wingrime> why not make SPL that load kernel to SRAM-B
<oliv3r> i think i n theory you can
<wingrime> *uboot-image
<oliv3r> if you can fit the kernel into sram-b2
<oliv3r> you can't load u-boot in sram-b2
<oliv3r> the whole point of SPL is to init dram, so the kernel can accessi t
<oliv3r> you don't even need u-boot
<wingrime> there hole between a and b blank, also 24 kb Limiy
<wingrime> my idea , make SPL load uboot to SRAM-B
<oliv3r> but what's the advantage?
<oliv3r> you'd only break stuff
<oliv3r> you'd break falcon mode :)
<wingrime> auto-dram callibration
<oliv3r> you can do that from SPL if you'd wanted to
<oliv3r> the problem is, we know nothing of the DRAM controller
<wingrime> oliv3r: also, new PM suspend routines for a20 have interesting things
<oliv3r> oh?
<wingrime> look at new code
<jemk> oliv3r: someone claims dram controller is same as in rockchip, so used ip cores in wiki
<jemk> s/so/see/
<wingrime> Wilswang
<wingrime> maybe I saw this name in some AW code ......
<oliv3r> well, it's quite possible of course jemk, but 'claim' is a bit strong
<oliv3r> though I highly doubt AW wrote their own dramc
<oliv3r> and for that matter, I doubt it even more that rockchip wrote their own dramc
<oliv3r> i wonder if the real IP is allready in u-boot/kernel
<oliv3r> that would make things very interesting to say the least
<wingrime> oliv3r: main idea , move DRAM init from spl to uboot - where you can parse dram config from env variable
<wingrime> oliv3r: so, you more not required build spl and uboot for every board
<oliv3r> ahh, no, what you want is SPL, TPL and U-boot :)
<oliv3r> make a TPL that can handle much more
<rah> if I keep hitting "1" when I boot my A31 board (Mele A1000G), it goes into some odd mode where it gives out a USB-SCSI disk over the USB port
<rah> anyone know anything about this?
<oliv3r> e.g. SPL loads a TPL that does no longer have the 24k restriction
<oliv3r> rah A31 boots into fel mode very differently then any other chip. check the wiki
<rah> oliv3r: I have
<rah> oliv3r: I've seen the bit you're thinking of, I was just reading it
<rah> oliv3r: regardless, it still goes into this odd mode with a USB-SCSI disk
<rah> oliv3r: as you can imagine, I'm curious about what it's doing
<wingrime> oliv3r: TPL bad idea, make things more complicated than was
<wingrime> oliv3r: idea , SPL not init DRAM and load uboot to SRAM-B
<wingrime> oliv3r: uboot, read env from mmc,and init dram for it
<wingrime> oliv3r: but there better solution , auto-detect
<oliv3r> but that's exactly what you are suggesting
<oliv3r> but we allready talked about auto-detect
<oliv3r> big problem is, we don't know what registry does what
<oliv3r> right now, you just load some 32bit value in a register, modifiying everything at once
<oliv3r> anyway, u-boot is more like a front-end to the SPL
<oliv3r> the SPL does all the work
<oliv3r> u-boot gives you a console to do extra things
<wingrime> DRAMC_get_dram_size(void)
<oliv3r> fixed :)
<oliv3r> always returns 1G i think
<wingrime> PM suspend code have DRAM controller register names
<oliv3r> that's what I used to document most
<oliv3r> but there's still tons we don't know what they do
<wingrime> oliv3r: I looked at rockchip man
<wingrime> registers not match
<oliv3r> :(
fredy has quit [Excess Flood]
<oliv3r> well maybe they use different ordering
fredy has joined #linux-sunxi
<wingrime> oliv3r: but rockchip manual rather cool
<oliv3r> oh?
<wingrime> it first time I see Verilog module interface described
<oliv3r> of all IP?
<wingrime> maybe
<wingrime> I see input-output wires described
<wingrime> for module
<wingrime> verilog have no variables, only registers and vires
<wingrime> you connect modules using wires
wigyori has quit [Read error: Operation timed out]
wigyori has joined #linux-sunxi
<wingrime> thats realy crap, registers not even like
PiyushVerma has quit [Write error: Broken pipe]
PiyushVerma has joined #linux-sunxi
hipboi has quit [Ping timeout: 256 seconds]
<wingrime> jemk: any success in isp?
<jemk> wingrime: no, gone back to my h264 decoder, it isn't worth the effort just to find another few kb of ram
<wingrime> jemk: blank a - 48kb , blank b 64 kb , cedarx 62 kb + ACE 6 kB
<wingrime> jemk: my current u-boot = 202 kb
<wingrime> jemk: thats all 180 kb
Black_Horseman has joined #linux-sunxi
Black_Horseman has joined #linux-sunxi
<oliv3r> it's highly unlikly cedarX uses ISP sram anyway
<wingrime> oliv3r: uboot teoreticaly fit
<oliv3r> u-boot is 224 kb
<oliv3r> yousure?
<wingrime> oliv3r: you can turn-off many things
<oliv3r> not many
<wingrime> emac , tftp , fat, ...
<oliv3r> at which point, you only have left, SPL :)
<wingrime> )
<wingrime> make SPL read dram settings form mmc, and make me happy
<oliv3r> that's in the planning :)
<wingrime> hm.. I have more good ida
<wingrime> *idea
hipboi has joined #linux-sunxi
<wingrime> oliv3r: we can add dram init structure somewhere with in 48 kB
<wingrime> oliv3r: just attach it to spl end
<oliv3r> problem is, BROM only loads 24k
<wingrime> oliv3r: ok
<oliv3r> so if you can't fit in 24k, you need TPL
<wingrime> oliv3r: you not understand
<wingrime> oliv3r: now spl is 21kb
<oliv3r> 23k :p
<wingrime> you find, some small place for dram struct)
<wingrime> idea, make some tool, that will write structure at and of 24kB
<oliv3r> you can't
<oliv3r> at byte 24.0 next section starts
<wingrime> no still no
<wingrime> now you flash 2 image - spl + uboot
<oliv3r> u-boot starts at 32k
<wingrime> it possible make 3rd image that will wirte last 512b of SPL sector
<oliv3r> hno think we should embedd it into the SPL via mkbootimg
<oliv3r> i wanna see if we can fit the struct in the 7k marker
<oliv3r> so SPL can only be 23.5k
<wingrime> oliv3r: binary struct
<wingrime> not text
<wingrime> only need regs
<oliv3r> yes, but that means, u-boot-spl can only be 23.5k, since at 24k, u-boot starts
<oliv3r> or 23.9k
<oliv3r> but if you put it at 7k, that's fine
<oliv3r> BROM always starts at 8k - 24k
<oliv3r> but once you've loaded spl, you can read anywhere, so 7k is readable too
<oliv3r> i don't know how big the partition tables are however, what the bottom limit is
<oliv3r> 8k is chosen because of the BROM, it's hardcoded there
<wingrime> oliv3r: crap
<wingrime> oliv3r: more one idea, fail-safe for SPL
<oliv3r> but 7k should be fine, i don't think the partition tables reach that far
<wingrime> jemk: you mpeg decoder vpdau works?
<wingrime> oliv3r: falcon use sram-b?
<jemk> wingrime: yes, it basicaly works, but without any x integration (output allways in top left corner)
<jemk> h264 works too, but only very limited set of videos and always has artifacts in b-frames
<oliv3r> falcon mode, basically doesn't load u-boot; SPL inits DRAM, 'falcon' loads kernel to dram and starts dram
<oliv3r> so u-boot is entirly gone
fredy has quit [Excess Flood]
fredy has joined #linux-sunxi
<wingrime> jemk: any sound sync works?
robb83 has joined #linux-sunxi
<jemk> wingrime: that's job of player (mplayer in my case), so yes
<wingrime> jemk: but mplayer must send some view port parameters?
<jemk> wingrime: look at the vdpau api documentation, it gives an xdrawable
<wingrime> jemk: if we have no Xorg running?
<jemk> but i didn't want to write a full vdpau implementation, that would first need better kernel drivers for both cedar and disp
<jemk> wingrime: vdpau only works with x running
<jemk> i only did this for testing, its no real usable player (well, it is, but very hacky)
<wingrime> jemk: map regs to userland not allowed, but before we can make cedar driver in kernel we need new disp mainline driver
<wingrime> jemk: have no idea who will handle such work
<wingrime> jemk: but workable player can help us with bug reports
<wingrime> jemk: also, a10,a13 have some differences in decoders
<wingrime> jemk: Have h264 decoder some interesting things , or we still need only configure all headers right and call run() ?
<wingrime> jemk: and you played with MPEG4?
<jemk> wingrime: all headers (many!), some framebuffer and reference frame list and call run, but i think there will be more for higher profiles
<jemk> wingrime: mpeg4, no
<wingrime> jemk: can you publish it
<wingrime> jemk: maybe I will play with it
<jemk> wingrime: as soon as i have cleaned up my hacks at least a little bit
<jemk> wingrime: i used a lot of tricks to make it work, cause i still have no idea where some flags come from
<wingrime> jemk: I hope you will make some header
<wingrime> jemk: and will not use register offsets directly)
<jemk> wingrime: therefor i would need some names, but that is hard if i dont know what it does
<wingrime> jemk: are you have some tool for H264 headers dump
<wingrime> ?
<jemk> wingrime: the vdpau using player has to do most header parsing, only slice header is parsed by my code
<jemk> wingrime: but there i only parse what i needed till now
<wingrime> jemk: thats make things easy
<wingrime> jemk: are you using my .sed script for cleanup?
<jemk> wingrime: well, the slice header is pretty big too, so not that easy as i first thought when i chose vdpau as test environment
<jemk> wingrime: vaapi would have been easier
<jemk> wingrime: your sed script doesn't help much, have you ever seen an h264 trace? they are much more complicated
<wingrime> jemk: I can easy add all known regs to script
<wingrime> jemk: can you send h264 trace are you using
<jemk> wingrime: but you can't let sed parse the ram writing to get some sort of ram dump
<jemk> the ve sram throug regs 0x2e[0,4] i mean
<wingrime> jemk: I can move to python to do many sort of things
<wingrime> jemk: even some cedar emulator, to show register state
<wingrime> at any moment
stekern has quit [Ping timeout: 245 seconds]
stekern has joined #linux-sunxi
<wingrime> tons of headers
akaizen has quit [Remote host closed the connection]
deasy has joined #linux-sunxi
mouchon has left #linux-sunxi [#linux-sunxi]
mouchon has joined #linux-sunxi
<wingrime> jemk: also, raw write function are NOT same that MPEG ones?
<wingrime> jemk: see offset are same
<wingrime> jemk: ^
<wingrime> 0x01e4
<wingrime> vs 0x02e4 MACC_H264_RAM_WRITE_DATA
<wingrime> may be structure allike
<wingrime> so, we only use MACC_MPEG_JPEG_HUFFMAN_CTRL for 0
<wingrime> can you try ?
<wingrime> with MPEG engine
<jemk> wingrime: i think they have same function, yes. the huffman control register behaves exactly like autoinc pointer
<wingrime> jemk: they behaves allike , so can we figure that we write to VE-SRAM ?
<jemk> wingrime: yes, i tried, they write to sram, but to different locations, so there is some offset
<wingrime> nice
<wingrime> can behave alike too
hipboi has quit [Remote host closed the connection]
akaizen has joined #linux-sunxi
akaizen has quit [Ping timeout: 264 seconds]
n01 has joined #linux-sunxi
_BJFreeman has joined #linux-sunxi
_BJFreeman is now known as BJfreeman
akaizen has joined #linux-sunxi
fredy has quit [Excess Flood]
fredy has joined #linux-sunxi
pacopad has joined #linux-sunxi
sanka has quit [Quit: Leaving]
vinifr has joined #linux-sunxi
vinifr_ has joined #linux-sunxi
vinifr has quit [Ping timeout: 264 seconds]
jemk has quit [Ping timeout: 276 seconds]
BJfreeman has quit [Ping timeout: 268 seconds]
n01 has quit [Ping timeout: 264 seconds]
popolon has joined #linux-sunxi
<hno> oliv3r, it turns out that we actually have quite a bit more than 24KB to play with in SPL.
<oliv3r> hno: what do you mean?
<oliv3r> does the BROM not have an 8-32k limit?
<hno> that there is no problem to grow SPL by several KB more.
<oliv3r> the 8k start limit is hardcoded however, is it not?
<oliv3r> what's before those 8k, besides the partition table
<hno> Yes. Or.. I think it also looks at another offset but not sure.
<hno> in NAND it looks at three offsets.
<oliv3r> so how much more headroom do we have?
<oliv3r> is there room for fat/ext read-only driver?
<oliv3r> DOS/GPT partition table parsing?
<hno> Easy to check if you have a board nearby. Boot to u-boot, then "mw.l 0 0xDEADBEEF 2000;reset". Halt at u-boot again and check memory contents.
<hno> I don't think FAT will fit.
<oliv3r> well BROM reads the SPL header and copies the number of bytes in the header to sram
<oliv3r> but we also thought there was an artificial limit of 24k, or so we thought
<hno> Does not seem so. But BROM do use some of the upper SRAM but it's some more KB margin.
<oliv3r> that's good to know though
<oliv3r> i wish lkcl_ could have gotten the BROM src code, that way wwe could check :)
<oliv3r> lkcl_: ^
ykchavan has joined #linux-sunxi
<hno> It's fairly small. Not to hard to follow.
jinzo has joined #linux-sunxi
<hno> but takes time.
vinifr_ has quit [Ping timeout: 245 seconds]
vinifr_ has joined #linux-sunxi
<hno> oliv3r, FAT do not fit. With FAT the SPL alone (without Falcon) is 33.5KB.
vinifr_ has quit [Ping timeout: 264 seconds]
<oliv3r> so we can't grow 10k :p
<wingrime> hno: can it fit sram-b ?
<oliv3r> wingrime: BROM can't read it into sram-B, brom can only read it into sram a
<hno> sram B is not even enabled at this stage.
<wingrime> hno: I think move DRAM init to uboot image and make spl load uboot to sram-b
<wingrime> hno: than configure dram using env variables
<hno> u-boot do not fit in sram-b.
<oliv3r> if you want to do something like that, you'd could create some kind of memory parser module, that you load into sramb instead of u-boot, which would then probe memory, but we know hardly anything about the dramc to be able to pull that off
<oliv3r> hno: what about creating a valid 32kb SPL (with appended known data) and load that as normal, then check how much is still valid? I don't quite understand your memory write + reset tactic, unless BROM always reads the same amount, at which point I don't understand why the size is even in the header ;)
geecko has quit [Quit: Quitte]
<Turl> oliv3r: if you poison the ram and then let it boot again, you can check how much is still poisoned and you can use that to know how much you can expand :)
<hno> BROM uses the size field. But it uses some of the memory for buffers etc.
<hno> we can't go over the area used for buffers.
<oliv3r> Turl: well if the BROM reads only <size> bytes, you should in thoery find that after your poisoning attack
<hno> oliv3r, the poisoning attack is a quick method to find a reasonable border for how large size can be. Then try if it works.
vinifr_ has joined #linux-sunxi
<oliv3r> so what about appending random data, setting the size to 32k and see how much gets actually loaded
<hno> That have no chance of working, as you will be writing over the data area used by BROM, including stackspace.
<hno> and data buffers, etc.
<hno> Stack is at 0x8000 from what it looks like.
<oliv3r> is that modifiyable with gcc?
<oliv3r> having stack etc in sram-B
<oliv3r> only pure data in sram-A?
<hno> can't modify BROM.
<oliv3r> oh BROM's stack
atiti has joined #linux-sunxi
<wingrime> hno, I have better idea
<hno> ok?
<wingrime> hno: brom may have some read routines we can call
<oliv3r> that sounds kinda hackish
<oliv3r> only to save a few bytes
<wingrime> hno: why not simple call it ?
<hno> For one thing BROM differs significantly between the different CPUs. Second that code is not designed to be called and we know nothin about it's calling conventions or requirements.
<hno> third, we do have all code we need in u-boot already.
<hno> extendion the SPL header to include the SDRAM parameter struct we today embed within the SPL code is a +/- 0 bytes change. It's just moving the struct from code to a fixed location.
<hno> and updating mksunxiboot to fill in the header.
<wingrime> differences can be avoided using signature search
<hno> ?
<wingrime> find read routine by hash
<wingrime> code call declarea - i think cdecl
<hno> finding the routines is not that hard, identifying the routines and how they may be used is.
<wingrime> hno: 90% routines are same that we have in a20 sdk
<hno> cdecl is not actual code, not part of the loaded image.
<wingrime> hno: only problem can be that brom overwrite vars and stack
<wingrime> at end
<hno> wingrime, I don't see why bother. We have a fairly complete SPL already, and not out of space yet.
<wingrime> hno: have one uboot and one spl for all boards )
<hno> that we can already do.
<hno> but user still need to provide per board data.
<wingrime> hno: also we have not much board configs, and we can try all and ch
<wingrime> in spl
<hno> it's not that easy to probe.
<wingrime> we can use lowest dram clock and timings , only check size and bus wide
<hno> and everyone is screwed..
<wingrime> hno: dram can be recofigured online
<wingrime> hno: you can also se new pm code for a20
<hno> wk
<wingrime> hno: it even use watchdog in dram problem case
<hno> wk
* hno don't see his keyboard in the dark
<wingrime> hno: also cool have universal spl for unsuported boards
<hno> wingrime, dram controller can be reconfigured under some specific conditions. a) Code is running from SRAM. b) SDRAM is put in self-refresh mode.
<wingrime> hno: you can always copy some code block to it like PM suspend
<hno> which is why PM is a separate standalone binary. Fully self-contained and loaded into SRAM.
jemk has joined #linux-sunxi
<wingrime> hno: yes, but it can be fixed , kernel support such things
<wingrime> hno: kernel loader will put it there
<wingrime> hno: see __tcmfunc
<hno> wingrime, sure, everything is possible with infinite hours to get things working.
<wingrime> hno: uboot have SPL framework , why not use dram routines already in SRAM
<hno> personally I am not comfortable with even probing bus width & size. Have had sufficient issues with the DRAM controller locking up on me.
<wingrime> hno: ok 512 is fine too, only try width
<hno> what is it you want to accomplish?
<wingrime> hno: load board using only script
<hno> script where?
<wingrime> sunxi script
<hno> ?
<wingrime> or uboot env variable
<wingrime> hno: I mean fex
<hno> we are moving away from fex.
<oliv3r> mainline doesn't do fex
<oliv3r> so in that regard, it doesn't matter
<hno> not spending a single second on making code that depends on fex.
<wingrime> ok, uboot env variable
<wingrime> or uboot special command
<wingrime> for dram reconfig
<wingrime> or, better dt , leave it on kernel
<wingrime> it does not maters , general idea make spl and uboot universal
<hno> kernel is not an option. There is more kernels than Linux to care about.
<wingrime> provide universal spl+uboot for unknown board with width probe and watchdog protection
<hno> wingrime, so help out by polishing up the u-boot code so that same binary runs on all CPUs. That would get us 99.9% of the way.
<wingrime> hno: also, a10 uboot normaly stated on a20 , (realy saw myself on uart)
<hno> main u-boot do work. SPL do not quite work..
<wingrime> hno: sam MMC card
<wingrime> *same
<hno> Cubieboard SPL locks up on Cubieboard2. Tried that by accident some days ago.
<hno> and that's the same board, same DRAM, same everything except for CPU..
<wingrime> hno: you readed backlog? jemk turn on sram-c for cedarV and cedarA
<wingrime> hno: it worsk but need gate and clock
Colani1200 has joined #linux-sunxi
<hno> wingrime, haven't read that yet.
<wingrime> 62kb in sram c1
<wingrime> and 6kb in c2
<hno> Which isn't much.
<hno> u-boot is ~220KB today.
<hno> and likely growing.
<wingrime> with tcp-stack
<wingrime> and many fs
<hno> There is networking support because many people need it.
<wingrime> do you saw lk (litle kernel) loader?
<hno> and not that many FS:es, only FAT and ext*.
<hno> no I haven't seen lk.
<Turl> lk is from qcom people
<wingrime> thats more androidis
<hno> there is many small bootloaders for various platforms.
<hno> U-boot SPL is a generic one..
<oliv3r> not to mention that the kernel is running from dram, reconfigure dram, Poof, kernel gone
atiti has quit [Ping timeout: 264 seconds]
<wingrime> oliv3r: have you saw DRAMC_retraining
<wingrime> form new PM
<oliv3r> hopboi said, if you reconfigure dram, it resets everything inc. content
<Turl> hop hop!
Black_Horseman has quit [Quit: Zwi se logou mou!!!]
<hno> it is possible to do almost full DRAM reconfigure at deep suspend state like PM is doing.
<oliv3r> but where do you keep the kernel etc?
<oliv3r> during hibernate i can imagine, you load everything from disk anyway
<hno> in such mode the DRAM controller is fully shut down and the DRAM is set to self-refresh mode.
<hno> no, it's deep suspend, not hibernate.
<hno> data is still in SDRAM.
<hno> and CPU is still running code, but from SRAM.
<oliv3r> hipboi said that dram gets reset on reconfigure
<wingrime> oliv3r: actualy there mouch interesting
<hno> some of the steps normally done during DRAM configuraiton must not be done as those disturbs content. But other than that it works.
<wingrime> oliv3r: don't understand that dramc and ddr3 chip are different things
<hno> dramc is just the CPU interface to the DDR3 chips.
<hno> and some DMA glue.
<oliv3r> tom was very specific, he said all content is likly lost, or atleast cannot reliably be retriefed
rz2k has joined #linux-sunxi
<wingrime> oliv3r: if you set #reset on ddr3 offconse you lose info
<wingrime> oliv3r: ddr3 have own controller that recive commands
<oliv3r> i'm just repeating what hipboi said; which is the most reasonable info we have
<hno> depends... but yes you should not reset the DRAM. Just configure the DRAM controller and then switch over to active DRAM refresh instead of self-refresh.
<wingrime> oliv3r: in PM suspend code even turn off dramc PLLs
<hno> but this is very CPU specific code, touching delicate pieces which we have absolutely no documentation for except for some code that we know have been brokein in many releases.
<wingrime> oliv3r: after you set ddr3 chip in auto refresh mode
<wingrime> hno: but pm works on a10
<hno> wingrime, I seriously doubt pm worked at all in the early a10 releases, or in the early a20 releases.
<wingrime> hno: dramc problematic , you can't test it fully on FPGA
<hno> yes.
robb83 has quit [Quit: - A hand crafted IRC client]
<wingrime> most FPGA have own dramc
<hno> but the early A10 release was long after release of the ASIC.
<wingrime> my a13 have 0x55 in mask revision reg
<hno> wingrime, I can tell you this, I will focus on the SPL we have and making it easier to configure. Not planning to look into probing at this time. Might look into multi.platform support but likely not.
<wingrime> hno: you want use some 3rd image for spl settings in bin format?
<oliv3r> well we'll have a universal A10 spl and a20 spl soonish
<oliv3r> that'll configure timings from somewhere
<oliv3r> that's a good start imo
Colani1200 has quit [Quit: cu]
<wingrime> oliv3r: strange comments in PM code
<wingrime> //select dram controller 1
<oliv3r> dual channel :)
<wingrime> mctl_write_w(SDR_SCSR, 0x16237495);
<oliv3r> SPL has that too
<wingrime> see at magic value
<oliv3r> you configure SDR_SCSR with 1 big value
<wingrime> 0x1623
<oliv3r> 1623 :)
<wingrime> can we have not one version of dramc in single chip ?
Fergus has joined #linux-sunxi
<oliv3r> we simple don't know :(
<oliv3r> dram is a big black box, we should be happy this works so far
<oliv3r> i doubt AW knows anything more
<Fergus> Hi, I enabled two screens (one hdmi and one TV) in script.bin/fex,only one is plugged, is it normal that it blocks bootup ?
<wingrime> hno: DRAMC_retraining func in PM code do full reconfig
<Fergus> it boots, I can see the boot messages on the screen but then it stops. (using Cubian)
<wingrime> hno: if I have some time , I try hack this , trying change speed on woring kernel after suspend
<wingrime> hno: if it will successed , I try write some kernel driver for it
<wingrime> oliv3r: ^
<oliv3r> wingrime: if you can reconfigure the dramc runtime, that'd be very cool :) but I wouldn't waste too much time on it now, there's sooooo much things we have to do
<wingrime> oliv3r: see PM code,
<wingrime> it save DRAM regs in variables and init it again
<rz2k> Fergus: sounds like a deadlock in /dev/disp
<rz2k> Fergus: are you sure you are running whatever you want (xorg?) on needed framebuffer since you now have two of them?
<Fergus> no I'm not sure I'm running whatever I want, there is no X server, I expected it to boot and simply give a command prompt
<Fergus> also, it seems to have worked once without anything connected to the board (cubie 2), I could ssh to it and then I plugged an hdmi screen and it was stuck during boot up, and now even with everyting unplugged, it isn't working, I tried reverting back to the original script.bin file with no luck
<Fergus> rz2k ^
<rz2k> no one tested two screens setup really hard
<rz2k> I only remember ssvb poking around it and it was working, last changes to sunxi-3.4 might have broken that
<Fergus> rz2k: well, my goal really wasn't to have two screens, it was just to test the screen output, but now erh... it's like there is nothing left. /dev/disp doesn't exist
<rz2k> hmmm
<rz2k> thats really not ok
<rz2k> maybe it crashed upon load? check dmesg
<hno> wingrime, i will move DRAM parameters to the SPL header.
<hno> and no, PM code do not do a full reconfig.
<hno> almost, but not full.
<Fergus> rz2k: yes, but since I had the boot messages in front of me, I assumed I'd see it. But I'll still check the logs
<Fergus> back to original script.bin again, still not booting. With cubian, the green led blinks to indicate it's booting up
<Fergus> hm, it seems it's not even booting "enough" to start writing to /var/log/messages
<ssvb> rz2k: in fact I'm regularly using the dual monitor setup, not just poking around
<ssvb> Fergus: do you have enough memory reserved for the framebuffer?
<hno> wingrime, used parts of the PM code when making the SPL. boot0 has almost the same, but some steps more.
<rz2k> ssvb: soz, didnt speak with you about sunxi in ages :p
<Fergus> ssvb: uh, erh, I didn't check this
<ssvb> Fergus: with the current way the memory reservation is implemented, you can easily crash the kernel by a minor misconfiguration
<Fergus> what else than putting the default script.bin file back could revert the changes ?
<ssvb> Fergus: also check the "sunxi_fb_mem_reserve=XXX" kernel cmdline option
<Fergus> it used to boot perfectly, I could ssh to it etc... basically I've just modified the script file, it booted up once without a screen, then plugged in a screen and now it won't boot anymore, even with screen unplugged
<ssvb> Fergus: sunxi_fb_mem_reserve option sets the size of the framebuffer memory reservation, and this size should be large enough to allocate the framebuffers
<Fergus> " EXT4-fs (mmcblk0p1): re-mounted. Opts: (null)" that's the last boot message displayed. It seems it's also there on "working" configuration (I still have the dmesg logfrom the last working boot)
<ssvb> Fergus: if you don't have enough framebuffer memory, the kernel just dies when it tries to initialize disp
<ssvb> Fergus: check 'fb0_framebuffer_num' and 'fb1_framebuffer_num' variables in the fex file, and also the color depth and the screen resolution
<ssvb> Fergus: using this information you can check how much memory is really needed
<ssvb> Fergus: and if sunxi_fb_mem_reserve (measured in MB) is less than that, then your system blows up
<ssvb> Fergus: as a simple test, you can just increase 'sunxi_fb_mem_reserve' to make sure that you have a lot of headroom
<Fergus> fb0 and fb1 have fbx_framebuffer_num = 2 . format is 10, ARGB8888 ; Where is sunxi_fb_mem_reserve ? is it a line to add there ?
<ssvb> sunxi_fb_mem_reserve is a kernel cmdline option
<Fergus> Okay, in boot.cmd ?
<ssvb> yes
<ssvb> but you also need to create boot.scr from it
<Fergus> "disp.screen0_output_mode=EDID:1280x800p60" there's already this, haven't changed anything there
<ssvb> the current kernel cmdline options are printed as one of the first messages in the kernel log
<Fergus> okay, got it
<Fergus> anyway, thanks for your help !
<ssvb> btw, what is the native screen resolution of your monitors?
<Fergus> not sure about that, also, I have one monitor only now. should be 1680*1050. (it's dvi and I use a hdmi -> dvi adapter, shouldn't be an issue there afaik...)
<Fergus> what is the tool to use to make it a boot.scr ? is it in sunxi-tools
<ssvb> ok, 1680x1050 * 4 bytes per pixel * 2 framebuffers (fb0_framebuffer_num value) = ~14MB
<ssvb> and for the second monitor (even if you have not plugged it in), the screen resolution is determined by the fex file
<wingrime> hno: I think I remove some magic today
<wingrime> hno: roch chip have nice man
<wingrime> for dram
<Fergus> the current fex file has the second monitor disabled (type/mode=0)
<wingrime> and it close to ours
<ssvb> Fergus: ok, so you reverted back to the single monitor configuration? I believe that this works fine for most people, is well tested and you are not expected to encounter any troubles
<Fergus> yes, the thing is I still have troubles :| I'd assume (unless the card itself is fried) there is something somewhere in the system set to some state that fails
<ssvb> Fergus: maybe try some known good image as a start?
<Fergus> yes, of course I can still reflash the sd card with the Cubian image
<Fergus> because I know it works, I used it since I received the cubie
<ssvb> Fergus: well, just with the dual monitor configuration, the insufficient framebuffer reservation size could be the culprit
<ssvb> Fergus: with a single monitor configuration, you are having a common configuration, which is already well tested
<Fergus> ok, and it's normal the issue persist even with screen uplugged and fex back to default
<Fergus> ?*
<Fergus> the boot.cmd already has this: disp.screen0_output_mode=EDID:1280x800p60
<ssvb> have you created script.bin from your fex file and written it to the SD card?
<hno> wingrime, link?
<ssvb> Fergus: if you forgot something, you probably still can have the problematic dual monitor script.bin
<Fergus> ssvb: yes, I backed up the original script.fex, I compiled the sunxi-tools on my other laptop, used the fex2bin util to create the .bin file that I copiedback to the sd card
<Fergus> from the original fex file, that is
<ssvb> Fergus: just double check everything and try it again, also keeping backups is a good idea
<wingrime> hno: wait I add some info to wiki
<Fergus> yep, I always convert bins back to fex to make sure it's back to default
deasy has quit [Quit: Quitte]
<Fergus> I'm using "bin2fex foo > foo.bin" to write the files, is that ok ?
<wingrime> TPR0 are same
<wingrime> *almost
<wingrime> TPR2 default reg value same that we have
<oliv3r> wingrime: but it's very very hard to make guestimates if we dont' even know that it IS the same one
<wingrime> oliv3r: default values same
<wingrime> oliv3r: and more important values are standatd timing parameters form
<wingrime> dram vendor
<wingrime> I think this magic same
<hno> wingrime, hmm... this DMC manual is clearly a direct copy-paste from whoever provided the IP block. Do you think Allwinner used the same IP provider for their DRAM controller?
<wingrime> hno: very close
<wingrime> hno: but TPR0-2
<wingrime> hno: reg info 100% same that we have
<wingrime> see
<wingrime> dram_tpr0 = 0x30926692
<wingrime> we have
<wingrime> 0x3092666e
<wingrime> rock chip have default
<libv> not sure why they chose the name lima
<libv> but it's different things...
<wingrime> hno: looks like this ddr3 standat values
<rm> assholes
vinifr_ has quit [Ping timeout: 245 seconds]
<rm> also I remember this was not called Lima initially
<Turl> libv: they don't look like trademark trolls, but maybe dropping them a line so they're aware would be good
<Turl> rm: it was named Plug, and they renamed themselves after they got trademark issues :P
<libv> it's different things, nothing i can do
<rm> yes
<rm> <Turl> libv: they don't look like trademark trolls <- just like giant assholes
<rm> "we like this cute name you have there, so we're taking it"
<Turl> rm: maybe they didn't even bother checking, considering their first name was Plug :P
<rm> I don't think one can be working in the field of ARM SoC and ARM-based sticks and not hear of the Lima driver
<wingrime> hno: aw use different registers map for dram
<wingrime> hno: BUT
<oliv3r> same ip, homebrew wires/regs?
<wingrime> oliv3r: does not matter
<oliv3r> wingrime does rockchip doc entire dramc?
<hno> similarities here and there.
<hno> oliv3r, rock chip doc seems fairly complete
<wingrime> oliv3r: hno: this man describe magic tpr0-2 emr1-3 and odt-en an zq
<oliv3r> not exactly strange, ddr3 is standard. ip function is the same
<Turl> rm: when you consider it's a headless appliance..
<oliv3r> or purpose
<hno> oliv3r, there is too much similarities to be a coincidence.
<wingrime> oliv3r: yes dram_tpr2 = 0x1a0c8 match too with default Rock chip
<hno> DLLCR* registers seems to match pretty close as well.
<hno> down to bit field locations.
<wingrime> hno: (tpr0-2) so, this values are timings in cycles between sort DDR3 commands
ykchavan has quit [Remote host closed the connection]
<Fergus> ssvb: oh ! it booted with the framebuffer memory setting
<wingrime> hno: dram_odt_en = 0
vinifr_ has joined #linux-sunxi
<hno> Hm.. DLLCR do not fully match. The ENABLE/RESET bits do not match what Allwinner is doing. If Allwinner DRAMC would be the same then the DLLs would be left in RESET state..
<hno> wingrime, yes odt is on die termination.
<hno> appears unused in DDR3 setups.
<rah> instead of getting FEL mode, my A31 TV box is giving me a USB Storage device on the USB bus
<wingrime> DDR_PHYCTL_MR1 may be same as dram_emr1 = 0x4
<rah> I thought it was an odd new mode, different from FEL
<rah> but apparently it looks like this is what it's doing in what one would expect to be FEL mode
<hno> rah, boot1 has USB storage support on all Allwinner devices, and support for entering that via button press at boot.
<wingrime> hno: can it be different IP version?
<hno> rah, how did you try to activate FEL mode?
jemk has quit [Remote host closed the connection]
<rah> does anyone have any idea why there's a USB Storage device appearing?
<wingrime> broken nand
<hno> wingrime, more likely originally based on the same IP and then have diverged..
<ssvb> wingrime: that's a very nice catch
<hno> rah, see above.
<wingrime> hno: or AW stealed RockChip Verlog and make it not like
<rah> hno: I can enter that mode by either pressing a button on the bottom of my box (which has a circular arrow label, that I would expect to be "reset"), and also by sending a '1' character over the serial port on boot
<rah> well, when I say "pressing" I mean holding it down on power-on
<rah> hno: what can this mode be used for?
<hno> rah, sorry, not very familiar with A31.
<rah> hno: you said this USB Storage mode was on all Allwinner devices?
<hno> rah, '1' during boot is usb-storage mode, not FEL.
<hno> '2' is FEL mode.
<rah> hno: wiki is wrong then
<rah> "The Allwinner boot1 boot loader enters FEL mode if you send the letter '1' on the console during startup."
<hno> both are handled by the boot1 bootloader in NAND.
* rah tries '2'
<rah> what appears on the serial port when the machine goes into FEL mode?
<rah> does it report that it's going into FEL mode?
<hno> __inf("Jump to fel\n");
<hno> so I guess so.
<rah> [ 6.522] Jump to fel
<rah> hah
<rah> eraly jump fel
<rah> tsk tsk
<hno> wingrime, what about it?
<wingrime> hno: rebrended china tablets with a10 + linux
<wingrime> = 200$
<rah> well this is odd
<hno> wingrime, yes.
<hno> rah, what is odd?
<rah> it reports FEL mode on the serial port but I'm still getting just a USB Storage device on the USB bus
<wingrime> hno: croudfunding )
<wingrime> hno: 7k$ for this site ))
<rah> there's the serial output
<rah> hno: any idea?
<Turl> rah: I'd say you're in fel
<Turl> maybe your pc needs to reenumerate? try unplugging and plugging again
<rah> Turl: tried
<rah> it loses the storage device but it doesn't come back
<rah> (after plugging in again)
<rah> I've had it wrong
<rah> the USB Storage device appears when I plug the USB cable in
<rah> even if the power supply is not plugged in
<Turl> maybe go to fel mode without plugging in and then plug in
<Turl> devices get power via the otg connector too
<rah> right
<hno> rah, is there anything on the console port when you use that button at power on?
<rah> hno: yes, in that codepad paste
<hno> I thought you used '2' there?
<rah> I did
<rah> oh
<rah> sorry
<rah> no I don't think there is
<hno> disconnect USB & power. Hold button. Connect power. Connect USB. lsusb
<rah> ok, now the serial port is just spewing gobbledygook out
<rah> even after unplugging the board for a few seconds
<hno> odd.
<hno> That's a full boot with lots of interference.
<rah> I know it's a full boot
<rah> it's the interference that concerns me
<hno> check your GND connection.
<rah> it's not going away :-/
<rah> there is no ground
<rah> or do you mean serial ground?
<hno> Yes.
<hno> You should only connect GND and TX (RX on your cable).
<hno> Leave RX (TX on your cable) disconnected for now.
<rah> ah, better
<rah> thanks
<hno> Most serial cables provide sufficient power on their TX wire to power up half the board.
<rah> 22:33 < hno> disconnect USB & power. Hold button. Connect power. Connect USB. lsusb
<rah> I get nothing on the serial port
<rah> except one strange character
<rah> I get the USB Storage device on the USB bus
<rah> �
<hno> What does lsusb report?
<hno> if it was boot1 that gave the USB device then you should have got lots of output.
<hno> thats your FTDI cable only...
<rah> d'oh
<hno> just a plain lsusb without options please.
<rah> second is everything; plain lsusb
<hno> That is odd.
<hno> Do this device have a NAND or an eMMC as internal storage?
<rah> leaving USB out, going into FEL mode by pressing '2', and plugging in USB, gives me just the same, the USB Storage device
<rah> this has NAND IIRC
<rah> bootcmd set setargs_nand
<rah> Hit any key to stop autoboot: 0
<rah> that's from u-boot
<hno> just let it boot normally, log in and cat /proc/partitions
<rah> umm
<rah> how would one log in? :-)
<rah> adb?
<hno> quite likely you have a shell by default on the console. no need to log in.
<hno> byt adb also works.
<hno> but ..
<rah> no shell on the console unfortunately
wingrime has quit [Ping timeout: 240 seconds]
<rah> adb doesn't look like much help because guess what I get on the USB bus :-)
<rah> USB Storage device :-)
<hno> when it boots normally?
<rah> yup
<hno> no other USB port?
<hno> because I think this port goes to a Genesys USB storage controller, not the A31..
<hno> Do your TV box have hard drive support?
<hno> because having the Genesys USB storage controller makes some sense then.
<hno> rah?
<rah> right
<rah> it does have a SATA connector on it
<rah> and there are two other ports
<rah> I've just gone through the android settings and it's got USB debugging enabled
<rah> however, the other USB ports are USB A
<hno> It is possible one of them really is an OTG port.
<hno> it is also possible that there is no OTG port at all, meaing no FEL mode.
<rah> or that the port is on the board internally
<rah> which would mean soldering
<hno> also possible.
<hno> Mele A1000 have the OTG port internally.
<rah> is it dangerous to connect a USB host port to a USB host port?
<hno> not really, assuming you get the wires right.
<rah> hmm
<hno> you can see which controller the ports are attached to via /sys
<hno> just plug some device you recognise in each port and look in /sys/bus/usb/...
<rah> I don't have a shell on the device :-/
<oliv3r> android?
<oliv3r> just install connectbot or terminal emu via fdroid
<oliv3r> aw devies are all root
<rah> ok, I'll try that
<rah> tomorrow :-)
<rah> thanks for the help
Fergus has quit [Quit: Page closed]
<hno> rah, often there is a silent shell on the serial port. Just try type some commands.
<rah> hno: ok, I'll try that as well, thanks
jinzo has quit [Quit: Leaving]