<Seppoz>
is sit importaint to have correct ram settings in script.bin?
kuldeepdhaka has quit [Ping timeout: 264 seconds]
akaizen has joined #linux-sunxi
sabayonuser has joined #linux-sunxi
sap has quit [Ping timeout: 268 seconds]
Black_Horseman has quit [Quit: Zwi se logou mou!!!]
<ccaione>
Turl: :P
akaizen has quit [Remote host closed the connection]
bbrezillon has joined #linux-sunxi
jemk has joined #linux-sunxi
jemk has quit [Quit: bye]
netlynx has joined #linux-sunxi
bertrik has joined #linux-sunxi
hero100 has joined #linux-sunxi
tomcheng76 has quit [Quit: leaving]
bonbons has joined #linux-sunxi
tomcheng76 has joined #linux-sunxi
ssvb has quit [Ping timeout: 265 seconds]
cabania has quit [Ping timeout: 255 seconds]
nicksydney has quit [Remote host closed the connection]
nicksydney has joined #linux-sunxi
ssvb has joined #linux-sunxi
maksimlin has quit [Remote host closed the connection]
sabayonuser has quit [Ping timeout: 240 seconds]
sabayonuser has joined #linux-sunxi
kivutar has joined #linux-sunxi
Night-Shade has joined #linux-sunxi
kz1 has quit [Ping timeout: 255 seconds]
deffrag has joined #linux-sunxi
deffrag__ has quit [Ping timeout: 240 seconds]
kz1 has joined #linux-sunxi
kuldeepdhaka has joined #linux-sunxi
kuldeepdhaka has quit [Max SendQ exceeded]
kuldeepdhaka has joined #linux-sunxi
kz1 has quit [Ping timeout: 265 seconds]
leviathanch2 has joined #linux-sunxi
kz1 has joined #linux-sunxi
kivutar has quit [Quit: Ex-Chat]
<bonbons>
On Cubietruck, with 3.4.79 kernel (as with 3.4.61) shutdown does not happen properly. The red power-led seems to remain powered by the rtc battery and pushing power button causes board to boot from nand instead of mmc
<hramrach>
bonbons: disconnect the UART cable
<bonbons>
the uart cable has only rx/tx and gnd connected
<bonbons>
and shutdown from android that's present on nand works fine
<hramrach>
as in if you boot android and shut it down the board powers down completely?
<bonbons>
hramrach: exactly (and even trying with disconnected uart I get same results)
<bonbons>
sometimes system even reboots instead of halting
<hramrach>
I wonder if changing pullup/pulldown options on the UART pins or shutting down the mmc controller or the UART would fix the problem
Seppoz has quit [Ping timeout: 252 seconds]
<hramrach>
but shutting down the uart will also prevent you from reading last kernel messages
<hramrach>
but nobody has fixed this so far
<hramrach>
and it can be fixed in hardware, too
<hramrach>
anybody around who understands the pin options?
<hramrach>
the thing that bugs me is that TX is output pin and RX is input pin but they have same pullup/pulldown settings - or do they have defaults and they change by pin type? And are they set correctly for UARTs?
Seppoz has joined #linux-sunxi
<Seppoz>
is there a way to pass memory size with kernel argument?
<hramrach>
yes, there is
<hramrach>
but it should be detected by u-boot
<hramrach>
if it is not you are doomed, probably
<hramrach>
because for it not to get detected you would need memory holes or something else totally wicked
<hramrach>
and it's not possible to read ram parameters from a schematic
<hramrach>
because alwinner did not release any document that would relate memory controller parameters to physical memory layout in any way
<hramrach>
there are things like bus width that hopefully mean what they say but rest is magic sauce
Seppoz has quit [Remote host closed the connection]
Seppoz has joined #linux-sunxi
<hramrach>
bonbons: with disconnected UART the board should power down completely
<Seppoz>
hramrach: so who would i ask on that?
<Seppoz>
i have 1 uboot that boots the kernel just fine
<hramrach>
if not you have some other power source there that does not let it power down
<Seppoz>
but with wrong ram size
<Seppoz>
all i want to fix is ram size
<Seppoz>
the uboot i have that works is binary
<hramrach>
read the ram parameters when booted with the binary u-boot
<Seppoz>
i did
<hramrach>
try booting regular u-boot with same parameters
<Seppoz_nowork>
what is your best guess what could cause this?
<Seppoz_nowork>
maybe searching on ram is wrong place?
bbrezillon has quit [Quit: WeeChat 0.3.7]
<Seppoz_nowork>
im wondering if it would be the kernel i would see atleast the eraly boot log isnt it
bbrezillon has joined #linux-sunxi
sappel has joined #linux-sunxi
sabayonuser has quit [Ping timeout: 268 seconds]
leviathanch2 has quit [Ping timeout: 245 seconds]
leviathanch2 has joined #linux-sunxi
<hramrach>
bonbons: you are probably one of the two or so people using battery with an a20 devboard. The driver and settings needs more testing
<bonbons>
:)
Black_Horseman has joined #linux-sunxi
Black_Horseman has joined #linux-sunxi
Black_Horseman has quit [Changing host]
<hramrach>
Seppoz_nowork: is that your kernel or the original kernel?
<oliv3r>
ijc: btw, while compiling the kernel; which does a -j4; the core does get to hot to touch; but i can hold my finger on it for 5+ seconds easy, so it's not HOT hot
<Seppoz_nowork>
hramrach:its mine
<Seppoz_nowork>
but its basically the origial
<Seppoz_nowork>
i just compiled
<wingrime2>
hramrach: you still have problems with vdpau?
<hramrach>
did not try yet
<hramrach>
I have problems booting my tablet
benn` has joined #linux-sunxi
<benn`>
who know how to fix "platform reg-20-cs-ldo2: Driver reg-20-cs-ldo2 requests probe deferral" ?
<Seppoz_nowork>
hramrach: so i finally managed to get it booting with my own uboot, but only 2012.10 works
<Seppoz_nowork>
any idea why?
<Seppoz_nowork>
what was changed with later release
<hramrach>
if you think you can use the additional testing I can try to build it but seems enough people got it working by now
<hramrach>
Seppoz_nowork: bisect is your friend
<hramrach>
I have no idea
<hramrach>
there were some SMP changes that made it possible to boot only with mainline kernel in the very latest u-boot but it never got into any release branch, hopefully
<hramrach>
benn`: is deferral a problem? that should mean that it depends on another hardware that has not been probed yet or something like that
<hramrach>
if the driver framework did not manage that automagically ordering the driver probes would be total hell
<bonbons>
has anyone played with sunxi_ir (various types of remote control, to capture e.g. sony remotes, jvc remotes, ...)?
xavia has joined #linux-sunxi
<bonbons>
out of the box I only get scancodes for twinhan remote control and a kenwood one, but none for the sony or jvc I have around
<Seppoz_nowork>
ok lets leave uboot for a while and go back to the actual problem
<Seppoz_nowork>
my system crashes with alot of messages like
<Seppoz_nowork>
i mean i know why but not why it crashes
<benn`>
hramrach: I traced this problem for few hous without success. It seem the axp20 driver probe failed
<hramrach>
Seppoz_nowork: there is no crash in the messages?
<Seppoz_nowork>
no, what i just pasted you is the output i get before the system is stuck
FreezingCold has quit [Read error: Operation timed out]
<hramrach>
benn`: deferral should in itself not prevent probing the driver but if it defers probe until something that never happens it may never probe. Maybe post link to the branch you are using? I don't have much idea about DT but when somebody who works on mainline comes around having the code at hand will help
<hramrach>
Seppoz_nowork: yes, it's stuck for no obvious reason. maybe try the latest kernel. it's 3.4.75 or what?
<hramrach>
also try disabling cpufreq, JUMP_LABEL and sleep if you have them
geecko has joined #linux-sunxi
<hramrach>
also how is the board powered? Sometimes replacing the power supply does wonders
<hramrach>
benn`: or is that not on mainline?
<benn`>
hramrach: I am using sunxi-3.4 kernel. I am quite sure it's a bug of the axp20 driver
<benn`>
hramrach: but I don't know how to fix it now :(
theskilledworker has joined #linux-sunxi
Black_Horseman has quit [Quit: Αποχώρησε]
<benn`>
deferral is caused by func really_probe(..) at drivers/base/dd.c
benn` has quit [Remote host closed the connection]
<Seppoz_nowork>
hramrach: it seems more likely that im doing something wrong, i just try to find out what is is
<oliv3r>
looks like the BSP still builds a 3.0 kernel
<ssvb>
oliv3r: this problem used to also cause build failures on parallel build because of competing gcc/binutils instances tasks overwriting the same object files
<oliv3r>
ok that needs to be updated
<oliv3r>
yeah i'm pretty sure i do not have those fixes
<oliv3r>
the bsp needs to reference the latest 3.4 kernel
<oliv3r>
mnemoc: ^^^
<ssvb>
but these build failures used to be not very frequently reproducible
fredy has quit [Excess Flood]
deffrag_ has joined #linux-sunxi
fredy has joined #linux-sunxi
<oliv3r>
ssvb: i imagine, well i'd have them in a VM, so i could zip it up and send it your way if I encounter stuff on something a little more up to date then 3.0
deffrag has quit [Ping timeout: 265 seconds]
<montjoie[home]>
Turl nothing changes with or without interupts
<oliv3r>
but i'm not gonna bump sunxi-3.4/HEAD as the main go to place for the BSP
<oliv3r>
mnemoc should do that :p
<oliv3r>
mnemoc: ^^
<Turl>
montjoie[home]: can you paste code and dmesg?
<loganaden>
is there a chance of rebuilding the firmware from source code ?
<montjoie[home]>
mripard I am sure
<montjoie[home]>
I will try sunxi-next also in cas of...
<oliv3r>
loganaden: well start by following the new device howto; the rest should follow from that quite easily
<Turl>
oliv3r: it's cheaper if you only put one chip :p
<oliv3r>
Turl: of course :)
<oliv3r>
it even has a socet for the A6100 or whatever the bluetooth/wifi is called on ct
<Turl>
oliv3r: if the SoC had 64M of RAM PoP style I'm sure they'd find a way to make android boot on that without external ram
<oliv3r>
lol
<oliv3r>
yeah :(
bonbons has joined #linux-sunxi
<mru>
pop is still an external chip
<loganaden>
oliv3r: is it possible to boot the latest android on that box ?
<oliv3r>
loganaden: if you put some effort into it; ab solutly
<oliv3r>
loganaden: but there is no 'standard' image you can flash and be done with it, well not that i know of, probably someone has done a generic a20 android iamge
cabania has joined #linux-sunxi
<Turl>
mru: so they're two things you buy and solder one over the other?
<Turl>
I thought they came as one unit already
<Turl>
must be because I'm not an EE but a software guy :p
<mru>
yeah, the usual ram vendors like micron sell pop packages suitable for various socs
<oliv3r>
i think they are solderd in the factory
<oliv3r>
but look at the rpi; that's poped mem
<mru>
pop has two main advantages over a traditional chip
<mru>
it saves pcb space
<mru>
and it simplifies pcb layout
<mru>
routing all those traces between the soc and the ram can get tricky
<oliv3r>
double stacked ram!
<oliv3r>
does that exist at all?
<mru>
and you free up pins for other uses
<oliv3r>
or reduce the pincount on the bottom :p
<mru>
you can get pop chips with ram + nand flash
<oliv3r>
e.g. reduce the chipsize usually
<mru>
but those are a single package
<mru>
I haven't ever seen a stack of 3 or more packages
<Turl>
heat may be an issue if you stack all the things
<oliv3r>
soc + ram + nand :)
<oliv3r>
or soc + ram + ram + nand
<oliv3r>
gotta have dual channel ram :)
<loganaden>
oliv3r: a20 all winner tech when it boots
<mru>
you can get dual channel ram + nand in a single pop package
<oliv3r>
mru: problem solved! see, that's what AW needs :)
akaizen has joined #linux-sunxi
<mru>
so far they've mainly been targeting the tablet market
<mru>
tablets have enough space that pop isn't needed