<lundman>
heh -j16, seriously.. they must have more than 16 cores
<lundman>
sunxi-3.0 branch is 3.0.42, so that is not what they use
<Turl>
I didn't even know RT had a kernel compile wiki page
<Turl>
order you should check when it comes to sunxi stuff is linux-sunxi wiki, then RT :P
<lundman>
well, with mele-v1.3 images, which is 3.0.8+, which kernel github branch should I use
<Turl>
lundman: sunxi-3.0
<lundman>
ok greatm, but they seem to have changed the partition layout, which /appears/ to be compiled into the kernel
<Turl>
the nand layout is read from nand
<Turl>
I'm sure of that
<lundman>
only thing I replace, is "nandc" which is the kernel and rootfs. The rootfs is the same, I just copy it back
<lundman>
so, i only change the kernel.
<Turl>
and the kernel modules on /system/
<Turl>
and the mali libs if necessary
<Turl>
not sure what version does your image have
<lundman>
those are not in /dev/nandc
<Turl>
/system is not on nandc indeed
<Turl>
/system is another partition
<Turl>
nandc just holds the bootimage and initramfs
<lundman>
i 'dd' in nandc, extrat initrb, put in my kernel, I 'dd' out nandc
<lundman>
kernel doesnt boot as the nand partitions are different
<Turl>
no idea really
<Turl>
partition layout usually doesn't change out of the blue
<lundman>
yeah, my best guess is that the table is compiled into the kernel. cos if it isnt, then ..
phh has quit [Ping timeout: 276 seconds]
rellla has joined #arm-netbook
<lundman>
unless, its the rootfs tacked on the end of the kernel that differs
<lundman>
or I'm supposed to make a bImage
<oliv3r>
hno, yeah i formatted and double checked everything, /data /system everything. i'll double check everything
<lundman>
bollox, git checkout means a complete recompile :)
pawel5870 has joined #arm-netbook
<oliv3r>
hno: just after installing the rom (which does not modify /data) /data is only 15MiB :S only strange thing i noticed, is that all partitions in the 4.0.4 livesuit image, dmesg reports -652933084 etc for their sizes. they did include a new nand driver though (2.10 vs 2.09)
<lundman>
but yes, they did. but no idea where that is stored, I thought mbr first
<mnemoc>
Turl: you lost me with the nand thing. what doesn't work?
<lundman>
mnemoc: when I replace "nandc" kernel, it no longer boots android
<mnemoc>
lundman: beware you need the uImage mangled into a different wrapping
<lundman>
kernels that used to boot (rather, nandc image) also no longer works
<mnemoc>
ow
<lundman>
when it mounts /system, there is no system there, as it appears the nand partition layout has changed
<mnemoc>
between 3.4 and 4.0, yes
<mnemoc>
not sure about 4.1
<mnemoc>
but possible too
<mnemoc>
2.3*
sspiff has joined #arm-netbook
<oliv3r>
oh, hno mentioned something about nandc being 'android specific stuff', but that confused me and I almost lost some sleep over it. to me, android is what agetty is to <distro>. Basically android IS a distro. the kernel (even though its an android kernel) is still linux, u-boot is still ubuut. so if nandc holds the kernel, how can that be 'an android thing'?
<oliv3r>
lundman: partition layout for me, has changed in the livesuit dump for my tablet between android 4.0.3 and 4.0.4, there's now 2 /data, they added 1 extra partition
<mnemoc>
yes, the main diff is in userspace
<mnemoc>
even when the kernel is poisoned linux and u-boot is just u-boot, they assume a completely different structure than any linux "distro"
<lundman>
yeah, but the only thing I change is the kernel.
<mnemoc>
it's a kernel+initramfs combo without wrapping
<mnemoc>
the problem is probably in the initramfs part
<lundman>
i used split_bootimg.pl so that I get their ramdisk.gz
<lundman>
but yes, the initramfs may have changed
<lundman>
i should strip that out of their code
<oliv3r>
lundman: I may have the same issue as you have actually, I think i need to also look at my ramdisk.gz to see what they are doing in /etc/vold.fstab
<oliv3r>
since that is what is responsible for mounting /data, right? i mean, it's not like the ramdisk mounts /system and /system then takes over to do certain things?
<mnemoc>
only extracting that initrd you'll know
merbzt has joined #arm-netbook
<oliv3r>
working on it :D
<mnemoc>
.oO(ramdisk in 2012?, come on)o
<oliv3r>
ramdisk/rootfs/initrd
<oliv3r>
all the same :p
<oliv3r>
tomato potato!
<oliv3r>
(i know technically it's all very different)
<mnemoc>
initrd=ramdisk
<mnemoc>
initramfs=cpio.gz extracted into tempfs
<oliv3r>
wasn't it initramfs these days
<oliv3r>
yeah!
<mnemoc>
lundman mentioned "ramdisk.gz"
<lundman>
ok not sure why, but work wanted me to wear some glasses, then they took 15+ photos of me
<mnemoc>
these days tmpfs, initramfs and devtmpfs gave the sanity back to early userspace
<mnemoc>
or HR having fun making something to ashame people
<mnemoc>
the generation of that ramdisk (and the build scripts injected in the kernel tree) should be moved back to android land, where they can be maintained properly
<lundman>
that they use static strings/device name is what is awkward here, but oh well
ceo16 has joined #arm-netbook
<mnemoc>
android begins with the a of awkward
<lundman>
hmm not sure I cut that right
<lundman>
ramfs: romfs filesystem, version 1 -1070305856 bytes, named \360m\300sqs
<mnemoc>
ouch
<ceo16>
I have the same problem with the mele a1000
<ceo16>
xbmc
<ceo16>
you solved?
<ceo16>
the cpu operates at 90/95
<ceo16>
I mean xbmca10
<mnemoc>
that probably means you aren't using the VPU for decoding or doing the fancy ui or both
<lundman>
wait, duh, the rootfs is cpio, not rom1fs
<oliv3r>
mnemoc: lundman probably called it ramdisk.gz probably, because split_bootimg.pl says: writing boot.img-kernel and boot.img-ramdisk.gz :p
<hno>
oliv3r, boot.img is an android image format. For u-boot you normally use uimage format (see mkimage command).
<lundman>
yeah THAT romdisk I copy theirs, but the kernel has roots/sun4i_rootfs.cpio.gz put on it
<mnemoc>
lundman: what? using the lichee3 branch???
<oliv3r>
hno: ahhh, ok, i thought boot.img was simply a dump of some android partition; now i understand you completly
<lundman>
yes?
<mnemoc>
lundman: why?
<lundman>
ask allwinner?
<mnemoc>
lundman: that's only there to let people build drop-in modules
<lundman>
linux-sunxi-3.0.8# ls -l rootfs/
<lundman>
-rw-r--r-- 1 root root 2243358 Oct 15 05:49 sun4i_rootfs.cpio.gz
<lundman>
-rw-r--r-- 1 root root 2243358 Oct 15 05:49 sun5i_rootfs.cpio.gz
<lundman>
its not something *I* did
<mnemoc>
lundman: it's not maintained, it's Qware's release some a couple of obviuslt fixes
<mnemoc>
lundman: because you are using the wrong branch if you want to build a full kernel
<lundman>
I'm just trying to replace the kernel in mele v1.3
<lundman>
and what branch would that be?
<mnemoc>
the default obviusly
<lundman>
named?
<mnemoc>
sunxi-3.0 these days
<mnemoc>
but it's what you get cloning the repo
<lundman>
you mean then one that compiled to 3.0.42+
<lundman>
so, no, not that one
<lundman>
mele v1.3 uses kernel 3.0.8+
<ceo16>
do you know how can I activate A10HWR1 in compiling?
<mnemoc>
lundman: yes, but a GPL violating one with tons of changed we don't have in our lichee3 branch
<mnemoc>
changes*
<lundman>
yes, but I want to just replace kernel in their mele v1.3, I dont care about licenses
<mnemoc>
lundman: that's why it should only be used to add simple modules to run over gpl-violating instalations
<mnemoc>
lundman: fine. but use sunx-3.0
<mnemoc>
lundman: lichee3 won't even give you sata
Quarx has joined #arm-netbook
<lundman>
so it seems the closest i can get to the kernel they are *still* using, is lichee-3.0.8-sun4i
<lundman>
sunxi-3.0 compiles to 3.0.46+ so, it will not work
<mnemoc>
lundman: why won't work?
<lundman>
the rest of the OS, including modules, are compiled against 3.0.8+
<lundman>
although, i suppose I could take out the modversion check
<mnemoc>
for userspace only the 3.0-android part matters
<mnemoc>
for the modules, install yours obviusly
<mnemoc>
you can't reuse the modules even if they are labeled "3.0.8+" too
<lundman>
then I have to modify more than just the nandc partition
<lundman>
so in that case, it'd be easier to hamstring module loading and hope the kernels are otherwise similar enough
<mnemoc>
up to you. but dropping in a freshly built 3.0.8+ from any public sources won;t work
<mnemoc>
they might be similar enough. yes
<lundman>
ok, the rootfs attached to mele v1.3 kernel is completely different from git. it has only a copy of config
merbzt has quit [Ping timeout: 246 seconds]
<lundman>
so basically, we don7t actually have the sources that mele uses for its android releases? I will have to find a way around that?
<mnemoc>
right. what we got is a release made in december by a company which received a tablet specific variant of the gpl-violating and nda protected lichee3 tree
popolon has joined #arm-netbook
<lundman>
ok, that explains why I had issues finding the exact branch used in the releases
<mnemoc>
the branch got some obvius fixes, and we then started moving on
<lundman>
yeah I will go with .46 branch, and just patch modloading to accept 3.0.8 and see what gives
<lundman>
actually sounds vaguelly familiar, maybe I did that last time
mysteryname has joined #arm-netbook
<mnemoc>
integrating parts from other sources, like the 2.6.36 tree, leaked patches and partial SDKs received by some board manufacturers without NDAs
<mnemoc>
but those SDKs are only intended to build modules, several parts are distributed as .o/.ko only
<hno>
mnemoc, which part is .ko only for mele?
<hno>
hard to follow as we don't have a source release for mele
<hno>
but is there any part in the mele kernel+modules we don't have usable source for?
<lundman>
man maybe setting up cross compile would be worth it.. this single core arm is tedious
<mnemoc>
no, nothing
<mnemoc>
but cedarx module is .ko in recent SDKs
<mnemoc>
but we have older sources
<mnemoc>
so we are fine
<hno>
lundman, cros-compile is only untarring a file and specifyoing the path to make.
<lundman>
well, after making a new VM running linux of some flavour
<hno>
why a VM?
<lundman>
dev here is osx
<hno>
nothing needs to be installed in the OS
<lundman>
cross compile linux of osx is painful
<lundman>
on
<hno>
ah
<mnemoc>
simplest is ubuntu as you can apt-get the toochain from linaro
<lundman>
what company makes CedarX ?
<mnemoc>
allwinner
<lundman>
heh
<lundman>
hmm no anonymous ftp login, no known ssh vuln
<hno>
mnemoc, a13 sdk have cedarx sun4i source, but .ko for sun5i.
<lundman>
heh allwinner has mysql open
<jelly-home>
poking around other people's ports is not nice
<lundman>
its my job
<hno>
not even legal here
<lundman>
VM service with webhostingpad
<jelly-home>
oh, you were hired to test their pens?
<lundman>
I give them good grade, that isp are doing well
<hno>
well, detecting that it is open is legal, using it not
<lundman>
yeah, how would that work, connecting to a port is illega
<mnemoc>
one could argue there is an implicit intention of wrong doing by scanning what ports someone has open
<specing>
Hacking allwinner.... hmmm
<lundman>
but i guess, these days, only hackers know about 'telnet'
<specing>
NETCAT!!! :D
<lundman>
such an evil command, clearly up to no good
<mnemoc>
socat :p
<specing>
netcat is so much better than telnet
<specing>
It can do UDP :)
<mnemoc>
socat can do ssl and serial too ;-)
<specing>
hmmm
<jelly-home>
and unix domain
<mnemoc>
and many many many other nice things
<mnemoc>
netcat does unix domain sockets too iirc
<mnemoc>
yes, with -U
<specing>
I seem to have socat installed...
<lundman>
hacker
<specing>
:)
<lundman>
jail for you boy
<lundman>
oh well, I'll leave that compiling and get ready to go home
<oliv3r>
a40? but i just got a new tablet! So no a15? :p
<grevaillot>
so, could be mali
<oliv3r>
oh i gotta read that, i'm all excited now
<oliv3r>
when are they gonna leak the user manual? :D
<oliv3r>
so little details? :(
<oliv3r>
i know android stores keymappings somewhere. are they also stored elsewhere? (script.bin comes to mind)
<mnemoc>
there are references to keys in script.bin, but they seem to be used by livesuit when composing boot1
<oliv3r>
ok, so you told me the partition table is stored somewhere before nanda
<oliv3r>
the rom i have, and CWM are all based on the 4.0.3 kernel or something close to it and that combo all works
<oliv3r>
when I use the 4.0.4 image, as said, the partition layout is changedd. vendor livesuit image works fine etc, but when i boot recovery, things get really strange, nande (which was a 1G /data before reboot) is now only 15M; also dmesg in the recovery mode only lists 8 disks instead of the 9
<oliv3r>
if the partition layout is stored on the nand, how can this be possibly different?
<cat1>
mnemoc: regarding oops in Issue #85, do you think it is something related to one of script.bin options or it is a bug somewhere in hcd code?
<mnemoc>
maybe both
<mnemoc>
bug triggered by script.bin option
<mnemoc>
the usb driver is one of the ugliest parts of the tree :<
<cat1>
mnemoc: any hint what that option is?
<cat1>
s/is/may be :)
<mnemoc>
no clue at all
<cat1>
mnemoc: thx :D
<mnemoc>
:)
lkcl has quit [Ping timeout: 240 seconds]
merbanan has joined #arm-netbook
<oliv3r>
is there a possible way that userspace or the kernel overrides the partition table stored in nand?
<mnemoc>
oliv3r: yes, there is a tool in sunxi-tools
<oliv3r>
i guess that's what they did then
<oliv3r>
did some resizing directly on the partitions, and then did some more runtime or something
<oliv3r>
:S
<oliv3r>
why ... WHY!
<mnemoc>
well.. that tool is ours
<mnemoc>
"they" do resizing using livesuit
n6pfk has quit [Read error: Connection reset by peer]
mikey_w has quit [Read error: Connection reset by peer]
<oliv3r>
well i don't understand, that if partition information is read from the nand, it can be different when booting different kernels
n6pfk has joined #arm-netbook
<mnemoc>
no, because all kernels will read the same partition table
mikey_w has joined #arm-netbook
<oliv3r>
well that's not what's happening here :p
<mnemoc>
o_o
<oliv3r>
i boot their kernel +userspace, i have 9 partitions, i boot recovery with actually a newer kernel (3.0.31+, maybe older nand driver though) and I get 8 partitions
<oliv3r>
also sizes (and names) differ obviously
<mnemoc>
uh
<oliv3r>
i know i really have to start compiling my own kernel +userspace :p
<oliv3r>
ah, and the 'new' data, is now located as nandj, which with the current kernel/userpsace i have no access too; that's why it keeps bootlooping
<oliv3r>
so i need to build a new kernel and new recovery image
<mnemoc>
but first boot from uSD our kernel and take an snapshot of the first blocks of your nand
<oliv3r>
i tried setting up uSD with CWM, but it wouldn't show anything on the display, so put that off for a while
<oliv3r>
tablets are hard to debug that way :S
<oliv3r>
i used hno's old uSD uboot
<mnemoc>
fbcon + usb keyboard?
<oliv3r>
i guess i can always try their kernel by cat'ing it to /dev/nandc
<oliv3r>
(their=the oem kernel)
<mnemoc>
s/oem/gpl-violating/
rellla has quit [Ping timeout: 255 seconds]
<oliv3r>
yes!
<oliv3r>
so that's really not an option
rellla has joined #arm-netbook
jelly has joined #arm-netbook
ceo16 has quit [Quit: Ex-Chat]
lkcl has joined #arm-netbook
<libv>
mnemoc: maybe i didn't look enough, but there seems little in the way of "here is a $linux_distribution image you can fling on your $device, so you can start playing straight-away" on linux-sunxi.org
<libv>
mnemoc: what are you using atm, what are you developing your kernel against?
<oliv3r>
so i've spend, what 3 days (well only a few hours really) messing with that stupid 4.0.4 live image, because i THOUGHT that 4.0.3 had a smaller /system partition. turns out, i was wrong and it's big enough after all :S can I get those hours back?
<oliv3r>
libv: i agree, some image for a uSD would be quite helpfull, 'you need atleast 1GB sd card, dd this file on it and you should have something quite usable most of the time
tzafrir_laptop has quit [Ping timeout: 255 seconds]
<libv>
is the april dated ubuntu image the most recent, immediately useful linux distribution for the mele?
<mnemoc>
I normally debootstrap precise to the devices
<lundman>
what happened to cnxsoft anyway, used to be something interesting every day, now there is barely one update a week
<mnemoc>
not very much into pre-built images myself
<libv>
from an emulator, or from the device?
<mnemoc>
device
<mnemoc>
cubieboard/1GB, mele a1000 and a13-olinuxino
<mnemoc>
libv: but on your side of the open source support things are rustier. we only have armel libs for cedarx (VPU) and r3p0/r3p1 armhf libs weren't built correctly :<
<mnemoc>
there is a missing symbol
<libv>
this requires an existing debian or debian-like installation on the device, i guess that the april ubuntu image for mele is a good start then
<libv>
how about display things?
arete74 has quit [Quit: leaving]
<mnemoc>
works fine. also fbcon
arete74 has joined #arm-netbook
<mnemoc>
i suppose not on that pre-built image from aprol
<mnemoc>
but building your own today is good
<libv>
has much work been done on the display side since... hrm... june is when we last talked about this i guess
<mnemoc>
in the common tree, sunxi-3.0.... and the wip/.../disp branch
e-ndy has joined #arm-netbook
<andoma>
mnemoc: ah, ok thanks
<mnemoc>
he fixed a bug on the disp branch yesterday so we can finally merge those changes to sunxi-3.0.... but he wants to do some cleanup first too
<andoma>
does these changes maintain the API exposed via /dev/disp ?
<mnemoc>
yes, no change there
rsalveti has quit [Ping timeout: 245 seconds]
<andoma>
sweet
pawel5870 has quit [Ping timeout: 240 seconds]
<mnemoc>
andoma: if you do tools to deal with that from userspace, please try to add them to sunxi-tools
<andoma>
mnemoc: i'm working on a mediaplayer so it's not really a tool per se
<mnemoc>
ah, ok
phh has joined #arm-netbook
pawel5870 has joined #arm-netbook
tzafrir_laptop has joined #arm-netbook
mSquare has quit [Ping timeout: 245 seconds]
andoma has quit [Ping timeout: 245 seconds]
merbanan has quit [Ping timeout: 265 seconds]
andoma has joined #arm-netbook
QingPei has joined #arm-netbook
mysteryname has quit [Ping timeout: 245 seconds]
mysteryname has joined #arm-netbook
andoma_ has joined #arm-netbook
merbanan has joined #arm-netbook
andoma has quit [Quit: leaving]
<ZaEarl>
I found an interesting manufacturer today. They're open source friendly. Their first box has a motherboard nearly identical to Mele. So if we have any questions on the Mele motherboard, theirs might be similar enough to be able to answer questions about it.
<mnemoc>
ZaEarl: also A10 based?
<ZaEarl>
yes
<mnemoc>
nice
<RITRedbeard>
Is there a more recent Debian/Ubuntu build for A10? I think I'm using the old one (wireless doesn't work, half the applications aren't working)
<ZaEarl>
I've had good luck with the miniand ubuntu image
drachensun has joined #arm-netbook
<mnemoc>
RITRedbeard: download a recent rootfs, extract it, and inject newer kernel
<mnemoc>
an "image" is only a fat and size-fixed form of extracted rootfs + kernel + uboot
merbanan has quit [Ping timeout: 252 seconds]
<mnemoc>
2GB+ instead of 100M.... quite absurd approach :|
<rzk>
without proper buf2 patch and wrong secure id
<rzk>
techn:
merbanan has joined #arm-netbook
<mnemoc>
rzk: does that mean hw accel is used?
<rzk>
yes
<rzk>
also thats r3p1
<rzk>
we have new libs
<mnemoc>
lost symbol problem fixed?
<rzk>
LD_PRELOAD'ed
<rzk>
libdri2
<mnemoc>
i see
<rzk>
before I dont remember, I had only black screen
<mnemoc>
:)
<mnemoc>
Turl: are our android libs compatible with r3p1?
<rzk>
techn somehow had something working, but its first time I see something moving around
<rzk>
another problem is that we have a bug with armhf. mali dies on everything except es2gears
* rzk
dd'd wrong image to SanDisk 16GB SDHC Class 10 and it died
newbie13 has joined #arm-netbook
<mnemoc>
o_O
hp__ has quit [Ping timeout: 276 seconds]
<rzk>
srsly, I dont get it, now it cant initilize anywhere (two linux pcs have buffer errors and kernel Oops on some sd scan thread with timeout of 25 seconds, windows just freezes explorer to death)
<mnemoc>
O_o
<rzk>
looks like sdhc stores valuable info at user accesible area that I've deleted with my new info from wrong image.
<cat1>
it is amazing how gadgets are blooming nowadays, isn't it
<cat1>
now anyboday can trash ridiculously expensive videconf eq :)
<mnemoc>
:)
<Turl>
I'm still surprised nobody made A10-powered phones
<L84Supper>
qualcom and mediatek
<lkcl>
Turl: with the MTK6250 and now the MTK6277, it's virtually impossible for them to compete
<lkcl>
L84Supper: yes, basically.
<Turl>
lkcl: now, yeah, a year ago?
<lkcl>
without an on-board I/Q Baseband processor and the associated high-accuracy timings circuits required for GSM, you can pretty much flat-out forget it
<lkcl>
Turl: even a year ago. qualcomm has all the patents. the cost of any GSM mobile phone? $15 of it is patent licensing fees to qualcomm.
<Turl>
it's china?
<lkcl>
ok, maybe that's 3G not GSM.
<Turl>
I doubt any of 'em pay patents :P
<lkcl>
Turl: that's probably the real reason why the U.S. is kicking up a storm against Huawei, citing "security reasons".
* lkcl
shrugs
<Turl>
huawei is big enough to actually be targetable
<Turl>
I haven't seen "MP5"/media players either
<Turl>
ipod touch/galaxy player clones
<lkcl>
yes and no... my guess is that they called the patent bluff, told qualcomm (or whoever) to take a flying leap. after all, even a court case against a BMW SUV clone, the judge told them "this car does not infringe" and that really was the end of the matter
<lkcl>
well, if no ODM has gone to the trouble of making a product for everyone to clone... :)
<lkcl>
Turl: many factories are simply incapable of doing design work, or of modifying a PCB beyond its original ODM / Evaluation unit
<lkcl>
they buy the designs off-the-shelf, and err... that's the end of it.
<lkcl>
so if the SoC vendor (in this case allwinner) never commissioned anyone to make an MP5/media player, never commissioned anyone to make an ipod touch / galaxy player clone
<lkcl>
then there *is* no reference design to buy "off-the-shelf", therefore there *is* no product available.
<lkcl>
you're assuming that PRC companies - the average PRC factory - has *any* design skills or initiative, where there is virtually none whatsoever.
<lkcl>
"new" products come out of china by a random process of osmosis and brownian motion.
<lkcl>
by sheer numbers, very occasionally an original design escapes out of the mele :)
L84Supper has left #arm-netbook ["puff of smoke"]
Quarx has quit []
Yakuzzi has quit []
<techn>
mnemoc: I was thinking same
<techn>
I thing BE and FE is doing the work
<mnemoc>
BE and FE been? :)
<techn>
*about g2d issue
<rm>
mnemoc, does the A13 even have HDMI?
<techn>
BE,colorspace converter.. FE,scaler
<mnemoc>
A12 does...
<rm>
re: mailinglist
<mnemoc>
but fair point
<mnemoc>
my brain only wanted a cheap excuse to claim "yes, we have MP on sun5i too!"
<mnemoc>
(mixing processor, 2d accelerator)
<drachensun>
1kc1: Is there source out for the MTK 6577 or 6575 anywhere that you know?
<drachensun>
I am pretty impressed with those phones and the price just keeps falling on and falling
<lkcl>
drachensun: the 6573 is all i could find (an ARM11). i'm still looking for the Cortex A9 stuff.
<lkcl>
alcatel are doing a stellar job of continuing to drop tarballs into that location (there's another 3 in the past 18 hours) so it's worthwhile keeping an eye on
<specing>
lkcl: thanks
<mnemoc>
lkcl: 6589 ;-)
<specing>
also I approve alcatel's use of XZ!
* specing
has an alcatel phone
rellla1 has joined #arm-netbook
<mnemoc>
lkcl: any update on the eoma68-a10 + mini eng-board ? :)
bsdfox\ has joined #arm-netbook
bsdfox has quit [Ping timeout: 265 seconds]
rellla1 has quit [Quit: rellla1]
ManoftheSea has quit [Ping timeout: 260 seconds]
rellla1 has joined #arm-netbook
ManoftheSea has joined #arm-netbook
<mnemoc>
techn: considering they aren't welcomed upstream, can we do it without a new typedef? :)
<techn>
?
<techn>
remove that typedef then?
<mnemoc>
it breaks the current style on the .c, but a clear `enum` will be more welcomed when mainlining days come
<mnemoc>
`enum disp_csc` for example
<mnemoc>
as it's not sunxi_ it's implicit it's not exported
<mnemoc>
s/exported/public/
<ibot>
mnemoc meant: as it's not sunxi_ it's implicit it's not public
rellla1 has quit [Quit: rellla1]
<mnemoc>
techn: but anyhow, is this the only missing bit to merge the disp branch?
<techn>
mnemoc: I checked convension.. typedef are not allowed for pointers or structs.. elsewhere it doesnt specify
<mnemoc>
fine then. i'm personally alergic to them, but I can deal with it :p
<mnemoc>
after a couple of months with this code i've before far more tolerat
<mnemoc>
tolerant*
<mnemoc>
s/before/become/
<mnemoc>
damn. I can't type :|
<techn>
mnemoc: yes. I think after that disp branch should be mergeable
<techn>
As you already have tested other outputs :)
<techn>
??
<mnemoc>
nope, i'm 100% trusting the maintainer
<mnemoc>
i rarely connect a display to my boards at all. so tests are: 1) compiles?, 2) doesn't oops on load?
<mnemoc>
and greenisj output is out of scope of that test suite ;-)
rellla1 has joined #arm-netbook
<techn>
I'm referring that bug.. Need to recheck that
<libv>
what would be needed for display testing is a set of tablets with a few different panels, a mele, an hdmi capable monitor with built in speakers, a vga monitor and cables with and without the ddc pins wired up, a dvi capable monitor without hdcp/audio, and a composite capable tv
<libv>
and it should be possible to program the a10 in such a fashion that it can be fooled into using the vga connector for s-video
<jelly-home>
a _very_ shitty connector with lots of features
<libv>
Turl: .eu is full of them
<Turl>
libv: must be a .eu thingy only
<libv>
Turl: high end .us devices also have it
<mnemoc>
.ar has their own weird standards....
<libv>
french designed, so vastly overdesigned
<libv>
has both up and down in the same connector
<Turl>
here display tech has come with, in pseudo chronological order, with aerial/cable, RCA, S-Video, YCbCr, VGA, DVI, HDMI
<Turl>
I think I didn't miss any
<Turl>
mnemoc: I'm not aware of any .ar only weird standard
<hno>
Turl & mnemoc, or redone as a transfer.
<hno>
s/or/OK,
<mnemoc>
Turl: ok ok. not .ar-only weirdness
<mnemoc>
hno: oh. neat!
pawel5870 has joined #arm-netbook
<mnemoc>
Turl: what did you pick for digital tv? japan's?
<libv>
and does, rgb (without sync - my synapses did hold up), s-video and cvbs, plus audio, and some extra signalling in one connector, really forwardlooking for having been designed in 1980
<mnemoc>
Turl: what? the whole south america conquered by the japos?
<libv>
in any case, very common in europe, and when you picked up a CRT TV with 2 scarts, you knew both did rgb, and one does s-video while the other does cvbs
<Turl>
mnemoc: it's like japan's but with H264 + HE-AAC