<bsdfox>
I'm suspecting that almost the entire PHnn port is available
cubiefan has joined #linux-sunxi
<cubiefan>
hello
<cubiefan>
I am using cubieboard
<cubiefan>
and... I'm trying to set resoultion to 480x272 through cvbs pin
<cubiefan>
but there's no option. what should I do?
<bsdfox>
I think you might need to do that in script.bin/fex
jinzo has quit [Ping timeout: 248 seconds]
jinzo has joined #linux-sunxi
<cubiefan>
hmm.. there's no option like 480x272
<cubiefan>
I've tried using EDID kernel arguments but it didn't work
<bsdfox>
does it seem safe to enable all the LCD0/LCD1 GPIO pins on a mele that doesn't (right?) use them? then toggle in output mode to see what I can find?
<cubiefan>
bsdfox//maybe not
<bsdfox>
yeah probably a bad idea
<bsdfox>
I think if I go through this and find any gpio that's not used I might be ok.. http://bob.drinksbeer.org/script.fex although I see PH22 in there for MMC. I'll have to check that pin to see if it's used during boot
<bsdfox>
hmm definitely not used when reading my sd card so not sure what's up with that
rz2k has quit []
ZaEarl has quit [Ping timeout: 264 seconds]
wingrime has joined #linux-sunxi
<mripard>
Turl: \o/
<wingrime>
mriprd: what wrong with IRQ-ctrl
<wingrime>
mriprd: why irq pending flag not cleaned ?
<wingrime>
mripard: why touchscreen driver should touch IRQ registers to do that
<wingrime>
?
<mripard>
hmmmm, they should not.
<mripard>
they should only clear their own, and never poke into the interrupt controller
<wingrime>
mripard: you can see ts-drivers for sunxi thay all clean IRQ pending flag (thay defenetly shoud not do that)
<mripard>
do you have some precise example in mind?
<wingrime>
mripard: ft5_ts driver
<wingrime>
mripard: see irq handler
<wingrime>
mripard: I tryed remove that , but I hung,witch means flag not cleaned by default
<wingrime>
mripard: Irq code must do that
<mripard>
ah, you're right, it shouldn't do that
<mripard>
but I don't think they declared an irqchip driver for the external interrupt
<mripard>
so instead of having one single driver that takes care of all of that, like you suggested, and like it should be
<mripard>
every driver needs to poke into the PIO IRQ registers
<wingrime>
this MAJOR issue
<mripard>
it seems to be a pattern at allwinner, they do this for most of the subsystems, like clocks, muxing, etc.
<mripard>
I know, but the way the external interrupts work in hardware is... tricky
<mripard>
I still haven't figure out exactly how to correctly handle that
<wingrime>
mripard:where Irq code for aw placed?
<mripard>
for linux-sunxi or mainline kernel?
<wingrime>
for linux-sunxi
<mripard>
as far as I know, the SoC interrupt controller is in arch/arm/mach-sun3i/core.c
<mripard>
and there's no support for the PIO external interrupts, except what you saw
<wingrime>
mripard: it strange that It hung without clear
christopher has quit [Remote host closed the connection]
n01 has joined #linux-sunxi
n01 has quit [Ping timeout: 248 seconds]
<techn__>
Turl: http://pastebin.com/YA8HVFrq , Recovery boots correctly to GUI but OS shows black screen with this log
mdfe has joined #linux-sunxi
<techn__>
mali's group/user seem to be root/root..
<oliv3r>
argh, i can't get why my kernel won't boot. I know that hexdump shows a completly different header, and 'file' doesn't recognize it as a kernel either (the boot.img kernel) but that does boot, whereas mine doesn't. It can't be that it's compressed, it's double the size, and debug info shouldn't make the kernel twice as big? and make it not being able to identify as kernel :S
<mnemoc>
the anger of the dark side...
rellla has joined #linux-sunxi
<oliv3r>
how can I liberate my kernel if a liberated kernel refuses to boot :D
<oliv3r>
i should check the guys chithub and see how he built the kernel, the .config isn't enough
<oliv3r>
still, twice the kernel; and it's not a kernel file says its' data
ol1ver has joined #linux-sunxi
<mnemoc>
what device? what kernel? what bootloader?
<ol1ver>
inet97f-ii; boot0/1, 3.0.62+
<mnemoc>
that's a13, right?
<ol1ver>
a10
<mnemoc>
weird
<ol1ver>
i'm uploading closeup of available pins now; but i probed them with all 8 uarts on; nothing responded
<mnemoc>
did you replace nanda's linux/u-boot.bin with lichee-dev's ?
<ol1ver>
i did not touch u-boot.bin
<ol1ver>
i did replace script.bin
<ol1ver>
but i'm running a custom kernel allready!
<ol1ver>
first thing i don't get is why his kernel is twice the size, and doesn't have the kernel 'header' its uncompressed, i can see strings
<mnemoc>
why don't you invest your energy in our kernel instead of a random fork?
<ol1ver>
that's what I'm trying to do
<ol1ver>
i'm trying to boot our kernel
<ol1ver>
but uboot appears to not load it, i'm getting stuck at the displaying the u-boot bitmap
<mnemoc>
if you are booting 3.0 with "stock" u-boot.bin you need to enable the ignore atag_mem thing
<ol1ver>
now your talking
<ol1ver>
where do i find info on that?
<mnemoc>
but replacing the broken by design stock u-boot.bin is *highly* recomended
<ol1ver>
can't find atag_mem on the wiki
<mnemoc>
.config
<ol1ver>
well i can't brick mine anyway right; i can boot via SD so that's good
<mnemoc>
CONFIG_SUNXI_IGNORE_ATAG_MEM
<ol1ver>
ok so i'll start replacing u-boot then
<mnemoc>
that enables allwinner boot hacks in sunxi-3.0
<mnemoc>
but it's not present in 3.4
<ol1ver>
well the thing is, i pulled /proc/config.gz from the running kernel
<ol1ver>
and loaded that
<mnemoc>
an ancient fork
<ol1ver>
true
<mnemoc>
including allwinner hacks by default
<ol1ver>
ok, u-boot first then
<ol1ver>
u-boot loads normal kernels then; correct?
<mnemoc>
should
<ol1ver>
which repo holds the lichee u-boot?
<mnemoc>
u-boot-sunxi
<mnemoc>
there are 3 important branches
<ol1ver>
the wiki mentions two branches, NAND and MMC-only
<mnemoc>
lichee-dev (fixed nand drop-in, not improved), sunxi (stable, mmc-only, clean and with nice features), and sunxi-current (development, cleaner, newer, still mmc-only, DTS and tftp capable)
<ol1ver>
so which one should I use, if i want to boot android from nand (and regular linux from SD
<ol1ver>
i'd assume lichee-dev; since the others are all mmc-only
<ol1ver>
ah, board setup is quite different, i'll have to redo it
<ol1ver>
do'h
<ol1ver>
but $work first
<ol1ver>
do we want a patch for that tree at all?
<mnemoc>
we still need it. so, yes
<mnemoc>
fixes only, ... but maybe uEnv.txt might be a good idea
<mnemoc>
brb
wingrime has quit [Ping timeout: 276 seconds]
<techn__>
whee.. a13 boots to cwm10 gui :)
<techn__>
now cleanup and patch bomb
<mnemoc>
techn__: are you testing new kernel right now? can you give a shot to a patch I just wrote?
<techn__>
mnemoc: I'm now using allwinner-dev-teams kernel with couple cherry-picks from our tree
<mnemoc>
ok :(
<techn__>
but plan is to test with our kernel at some point
<techn__>
I thought it was easier to boot with android "verified" kernel
<mnemoc>
yes
n01 has joined #linux-sunxi
rellla has quit [Remote host closed the connection]
eebrah has quit [Ping timeout: 260 seconds]
E3toSleep is now known as Epsylon3
<Epsylon3>
mnemoc : do we have infos on the CM9 rom available on cubieboard.org ?
<Epsylon3>
its a 3.0.42 kernel
<mnemoc>
afaik he just built Turl's
sky770 has joined #linux-sunxi
<Epsylon3>
nice :)
<Epsylon3>
20121028
eebrah has joined #linux-sunxi
<n01>
uhm, wemac.0: WARNING: no IRQ resource flags set.
<n01>
is this normal?
<techn__>
Turl: need help
<techn__>
Turl: How I can have nande and nandh automaticly formated to ext4? now I need to format them via recovery after flash.. and boot to recovery needs UART with sunxi devices?
<techn__>
ok.. no need for UART seems to work with adb
<techn__>
but I think it should work without recovery after flash
<cubiefan>
hellow is there any way to support 480x272 resolution for cubieboard?
<cubiefan>
edid arguments didn't worked
<techn__>
cubiefan: which interface?
n01 has quit [Quit: Reconnecting]
n01 has joined #linux-sunxi
eebrah has quit [Ping timeout: 264 seconds]
vinifm has joined #linux-sunxi
ZaEarl has joined #linux-sunxi
rellla has joined #linux-sunxi
brian_ has quit [Ping timeout: 245 seconds]
mdfe has quit [Ping timeout: 252 seconds]
<bsdfox>
Epsylon3, I've got GPIO working and have a little python script toggling pins but I've only found 3 that seem to be broken out. There are lots of pads unpopulated.. any advice on figuring out what pins these might go to (need to define parameter for gpio export in the bin/fex)?
<ol1ver>
bsdfox: you did look at linux-sunxi.org/A10/PIO
<bsdfox>
I did not
<sky770>
..
shineworld has joined #linux-sunxi
<techn__>
mnemoc: your 5/7 patch looks pretty dangerous :p
<Turl>
it might be pure, it might be constant mnemoc
<mnemoc>
I actually have that book. but no idea on which box :p
<Turl>
yeah, the book is awesome :)
ganbold___ has quit [Remote host closed the connection]
<mnemoc>
so my evil 5/7 needs __attribute__ ((const)) to let sunxi_is_foo() checks efficient
<mnemoc>
not that anyone would notice the diff anyway
<Turl>
linux has __attribute_const__ you can use
<mnemoc>
wtf static struct gpio_eint_data gpio_eint_list[] is in the .h?!
<mnemoc>
(w)hy
<Turl>
mnemoc: what about detecting the soc version just once early on boot, and then making the macros simple (soc_version == SUNXI_VER_...)
<Turl>
?
<mnemoc>
exporting the version symbol?
<mnemoc>
isn't that illegal these days?
<mnemoc>
anyhow, I still need someone to test this things work before thinking too much in how to make it more efficient :p
<mnemoc>
wip/sunxi-3.[04]/soc-detect on my github if anyone has the chance to test on A10S or A13 hw
cubiefan has quit [Ping timeout: 245 seconds]
rellla has quit [Remote host closed the connection]
<techn__>
Turl: how you would like patches to allwinner-common?
<Turl>
techn__: pull request is okay, otherwise email me (turl at linux sunxi) and tell me what you need added on the repo, preferably with github links to commits
<techn__>
ok..I'll send patches for sun5i support
<techn__>
and couple renamings to sunxi :p
ganbold_ has quit [Remote host closed the connection]
ganbold_ has joined #linux-sunxi
wingrime has joined #linux-sunxi
ganbold__ has joined #linux-sunxi
ganbold_ has quit [Remote host closed the connection]
<bsdfox>
my sata drive is clicking much more often after using PH17 :D
<wingrime>
bsdfox: You can set spinup / spindown
<wingrime>
bsdfox: or it bug ?
<wingrime>
bsdfox: than show dmesg
<Dreadlish>
or your power source is not much efficient ;)
<bsdfox>
wingrime, no I think PH17 is SMC_VCCEN
torqu3e has quit [Quit: torqu3e]
<bsdfox>
the drive spins down as soon as I toggle PH17
<bsdfox>
reboot fixed whatever the drive was doing on its own afterward
<wingrime>
bsdfox; simply set in to "1" and forgot
<bsdfox>
wingrime, I'm probing my mele looking for usable GPIO
<bsdfox>
so far I've only found four- PH10, PH20, PH22, PH23
<wingrime>
bsdfox: simply find PCB schme
<bsdfox>
four is enough to do SPI so I might stop
<bsdfox>
wingrime, is it available somewhere? I've looked
mdfe has joined #linux-sunxi
<Turl>
bsdfox: you cannot mux random ports to spi though
<bsdfox>
I can bit bang it if necessary
<Turl>
there's spi pins on PA, PB, PC and PI from what I can see on the docs
<bsdfox>
Turl, if I could locate an unused hardware SPI bus that'd be ideal but I haven't yet
<bsdfox>
and I don't want to have contention from sd card or whatever else is SPI in the mele
<wingrime>
bsdfox: you can use SPI with many slaves
<wingrime>
bsdfox: you must use "cs\"
<bsdfox>
wingrime, yeah I know but I don't want to get involved with the chip selects for the builtin functions
<bsdfox>
it looks like a couple i2c busses are available so maybe I'll just use those
<wingrime>
i2c as I remeber can be used without cs , addresses only
<bsdfox>
yup
<wingrime>
bsdfox: a13 have 3 i2c and 3 spi
<wingrime>
bsdfox: you must check docs for wires
<wingrime>
bsdfox: a13 have MAJOR advantage it TQFP package
<wingrime>
I want that tool for firmare hacking for zet6221 (in datascheet)
<ol1ver>
so when using ATAG; use the bImage or the regular uImage
<mnemoc>
that's unrelated
<mnemoc>
with IGNORE_ATAG thing core.c will read the memory size from the DRAMC register instead of trusting the bootloader
<ol1ver>
ok so i can still try both kernels (uImage or bImage
<mnemoc>
afaik bImage is for boot.img, and uImage when loaded directly
<Turl>
as far as I recall bImage is compatible with zImage
<Turl>
uImage is an uboot wrap thing
<Turl>
for android boot.imgs you need zImage or bImage if you want it to be slower to boot :p
<Turl>
(actually if uboot loads the full partition, it might be faster to use a bImage hm)
<ol1ver>
well i haven't figured out what bImage is, but uImage is just the kernel with a u-boot header. the stupid thing is, it's half the size of bImage :)
<ol1ver>
atm i dont' care how fast its boot, as long as it bots :)
<Turl>
what were you using to make bootimgs?
<ol1ver>
mkbootimg from android
<ol1ver>
well i hacked it around a bit
<ol1ver>
didnt' wanna pull and build the entire android repo yet so
<Turl>
yeah but what are you passing to it as kernel? :p
<Turl>
zImage, bImage, uImage, Image or what? :)
<ol1ver>
i downloaded sha.c sha.h to build libmincrypt.a
<ol1ver>
then downloaded mkbootimg.c and mkbootimg.h and cooked all that together to get mkbootimg :)
<Turl>
do you want a mkbootimg binary?
<ol1ver>
should be legit
<ol1ver>
i found a perl script, that splits a bootimg
<ol1ver>
i took the boot.img from my tablet, split it using the perl script, and got the bImage and ramdisk, the ramdisk works, the kernel looks allright, so looks like splitimg works
<ol1ver>
recombinding them also yields me a bootable boot.img so mkbootimg should be fully functional
<ol1ver>
Turl: initially i did all my experimenting with uImage
<ol1ver>
which now, i know is stupid :)
<ol1ver>
i need bImage
<Turl>
:P
<Turl>
try with a zImage too
<Turl>
should be the size of a uImage but compatible :)
<ol1ver>
i have replaced u-boot.bin on nanda/linux/u-boot.bin with a 3.4 compatible one from mnemoc's repo
<ol1ver>
i can string the extracted bootimg, and the sizes are nearly the same
n01 has quit [Ping timeout: 248 seconds]
<ol1ver>
so that seems to be okay
<ol1ver>
i'll now use the atag version
<ol1ver>
btw, bImage isn't from arch/arm; but is in the sun4i_crane_defconfig-linux/bImage
<ol1ver>
i'll ommit 'pagesize' i have added it cause the original did have it
<techn__>
mnemoc: "sunxi: BROM Ver: 1100 1100 1625" and "cf8563 1-0051: retrieved date/time is not valid." are only differences with soc-detect and stage branchs
<techn__>
cf8563 print could be normal :/
<ol1ver>
so it's nearly the same as vmlinux, not supprising as it matches in size
<Turl>
ol1ver: but I'm 99% confident you can use zImage too and it will work
<ol1ver>
first get something booting :)
<ol1ver>
then expermient
<ol1ver>
btw, i can boot 3.0 and 3.4 using the fedora rootfs from sd fine
<ol1ver>
still nothing, stuck at the bmp screen :S
<ol1ver>
i guess i have to wait for my sd -> uart breakout board
<Turl>
ol1ver: did you make disp, lcd and hdmi modules built in? (=y)
<ol1ver>
would that help? the kernel doesn't even boot
<ol1ver>
it gets stuck at the bmp screen
<Turl>
how do you know it doesn't even boot?
<Turl>
maybe it booted just fine and it's failing to load the disp modules, so you won't see any change on your screen :)
<ol1ver>
you sure? i thought the moment the kernel loads, the bmp goes away
<ol1ver>
it 'clears' the screen
<Turl>
I think that happens when disp kicks in
<ol1ver>
nah
<ol1ver>
while i was playing with it
<ol1ver>
i kept moving the modules dir back and forth (modules.old etc)
<ol1ver>
to keep the original modules (with disp) and make room for the new ones
<ol1ver>
i forget doing that a few times
<ol1ver>
so i had a booting kernel, which cleared the screen but failed to display the CM10 bootanimation, due to missing screen
<Turl>
in any case, you don't lose anything by trying :P
<ol1ver>
yeah i did try adb a few times, but nothing :S
<ol1ver>
(that's how i knew i forgot to change the modules back :)
<techn__>
oliv3r: adb could work when screen is black
<ol1ver>
yep it does
<ol1ver>
but i'll give it one more shot, with built in dsp stuff
<techn__>
ok.. now I understand.. we have API's changed
<techn__>
but I'm not sure if they are fatal changes :/
<ol1ver>
techn__: ?
<ol1ver>
how's the disp called? CONFIG_?
<techn__>
oliv3r: different mali than half year ago
<ol1ver>
for android?
<ol1ver>
regular linux boots and works fine
<techn__>
kernel space.. so you'll need same version malilibs to user space
<ol1ver>
yeah but i'm not even getting that far
<techn__>
I think bootanim needs mali also
<Turl>
yeah it does
<ol1ver>
what about the bit before that?
<ol1ver>
isn't bootanimation an android thing?
<Turl>
yeah it is
<ol1ver>
well i know from the working kernel, it takes a good 5-10 seconds before the bootanimation comes