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 el-sdboot.lds', 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 `fel-sdboot.lds', 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]
<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>
MACC_MPEG_JPEG_HUFFMAN_LOAD
<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>
MACC_MPEG_IQ_MIN_INPUT
<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>
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>
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: hdmi.audio=EDID:0 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>
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?
<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?