<xxiao>
"We want to talk with you. We are hiring hundreds of entry- and mid-level cyber professionals from across the US now!"
<xxiao>
linkedin hiring inmail
<xxiao>
"Engage in full-spectrum cyber operations. Work side-by-side with elite military and cyber professionals."
WarheadsSE has quit [*.net *.split]
pwhalen has quit [*.net *.split]
Turl has quit [Excess Flood]
Turl has joined #arm-netbook
WarheadsSE has joined #arm-netbook
pwhalen has joined #arm-netbook
<Turl>
mnemoc: fuu gotta adjust all of the remotes now >.<
tuliom has quit [Quit: Konversation terminated!]
tekzilla has quit [Ping timeout: 240 seconds]
tekzilla has joined #arm-netbook
<Turl>
RaYmAn: ping?
drachensun has quit [Ping timeout: 265 seconds]
QingPei has joined #arm-netbook
mysteryname has joined #arm-netbook
gimli has joined #arm-netbook
Quarx has joined #arm-netbook
bsdfox\ has joined #arm-netbook
bsdfox has quit [Ping timeout: 260 seconds]
rellla has joined #arm-netbook
QingPei has quit [Quit: Leaving.]
QingPei has joined #arm-netbook
popolon has joined #arm-netbook
<RaYmAn>
Turl: ?
<jelly-home>
are YOU a cyber professional
<orly_owl>
we all are
popolon has quit [Quit: Quitte]
<mnemoc>
Turl: tell me about it.... I have over a dozen of different working trees :<
<mnemoc>
Turl: and need to setup some mirroring to ease the transition
<mnemoc>
what do you think about 'allwinner-v3.0-android-v2' renamed to 'sunxi-3.0'?
<mnemoc>
hno: will u-boot follow? :)
cromo has joined #arm-netbook
<hno>
mnemoc, to the shared organisation? Sure, will push a stable release there in a couple days.
<cromo>
I compiled the newest xbmca10 yesterday to try out how it works under 1080p, but it behaves strange - the xbmc theme picture seems properly scaled to 1080, but the visible area is still cropped to 720, with rest of it being black. Anyone tried it yet and can confirm that?
<lundman>
the new 1080p code didnt work for me
<cromo>
and what were the symptoms?
<cromo>
same as mine?
<lundman>
actually, mine didnt want to start when i set script to 1080p
<lundman>
the manual code change 2 weeks earlier did work fine though
<cromo>
the script.bin you mean? I used the a10_display tool
<lundman>
oh
<lundman>
yeah I change script.bnin
<cromo>
not sure if that makes any difference though
<mnemoc>
script.bin is .... safer, as your choice is the default from start
<mnemoc>
dynamic changes may trigger bugs
<mnemoc>
f* google, f* linaro/android!
<cromo>
mnemoc: and so it appears that the dynamic change to 1080 does not change entirely _everything_
<mnemoc>
cromo: poke techn :)
<lundman>
ye
<mnemoc>
cromo: he is the sunxi-disp maintainer
<lundman>
i have a 1080p script.bin on ftp
<mnemoc>
lundman: please share patches, not full .bin ... as they aren't cross-device
<lundman>
huh?
<mnemoc>
fex to fex diffs
<lundman>
the instruction for bin->fex->bin is well documented
<mnemoc>
sure, but people will try to inject yours anyway
<lundman>
but if he has a a2000 and want a faster test, i have the bin for it
<mnemoc>
true
<cromo>
lundman: would you mind trying to boot 720, switching dynamically to 1080 and then observing the result with xbmca10?
<lundman>
doubt that works, if you look at the source to read resolution
<lundman>
also, mele is at work :)
<cromo>
lundman: I didn't look at the source much, I assumed it reads the fb resolution?
<oliv3r>
anybody messed with the linux livesuit build yet? I got 'unsupported OS' but worked around that. working out how to get from the DKMS -> working kernel module now. See http://linux-sunxi.org/Builroot bottom paragraph for what i did so far
<cromo>
besides, it actually does start and from the xbmc logs I can see it detects the 1080p correctly
<mnemoc>
oliv3r: please move that to [[livesuit]]
<cromo>
lundman: I have a1000, I think it's the same as a2000?
<mnemoc>
yes
<oliv3r>
good point
<oliv3r>
can you undo my change?
<mnemoc>
it would harm your karma :)
<oliv3r>
can i undo it myself?
<mnemoc>
yes
<mnemoc>
stupid android kernel maintainers decided to truncate and diverge their 3.4 branch. f* them all
<hno>
mnemoc, pleae gibe u-boot a spin again. Have restructured the SPL quite a bit, making use of the common SPL framework now available.
<mnemoc>
hno: sunxi or wip/update ?
eFfeM has joined #arm-netbook
eFfeM has quit [Client Quit]
mysteryname has quit [Read error: No route to host]
mysteryname has joined #arm-netbook
cromo has quit [Ping timeout: 245 seconds]
<orly_owl>
any a10 based nas/raid units available?
<lundman>
:)
<orly_owl>
that smile means no
<orly_owl>
|:
<mnemoc>
with only one sata?
<lundman>
want a a10 kernel with zfs built in?
<orly_owl>
mnemoc: how many sata ports does a10 support?
<mnemoc>
1
<lundman>
1
<orly_owl>
ok then
<lundman>
5-4
ZaEarl has quit [Read error: Connection reset by peer]
<lundman>
plus usb though
<orly_owl>
true
<orly_owl>
not sure how good a usb nas/raid would be
<orly_owl>
im thinking 4 hdd
<mnemoc>
if you connect an external raid device which emulates a single sata, you can have a NAS :)
<orly_owl>
any other socs/chipsets that are good for this then?
<hno>
mnemoc, sunxi
<orly_owl>
that external raid device would have a chipset or a soc though
<lundman>
yeah a little 5 sata port card would be nice
ZaEarl has joined #arm-netbook
<lundman>
or 6
<orly_owl>
a pcie card?
<hno>
it's mainly storage processors that have that many SATA ports in this segment. But those are SoCs as well.
<mnemoc>
my raid1 has a JMB352 inside and works nicely
<lundman>
nothing stopping them from making one for us
<orly_owl>
them?
<hno>
lundman, connected to what?
<lundman>
the magic fairies, or whatver
<lundman>
a10 board with 6 sata would be useful
<lundman>
its not useful now ;)
<mnemoc>
the imx6q support >1 sata iirc
cromo has joined #arm-netbook
<cromo>
The /sys/class/graphics/fbcon/subsystem/fb0/modes shows U:1280x720p-60 after dynamically changing the resolution with a10_display tool to 1080p. Is this normal?
<rz2k>
cromo: 1080p in native linux is not supported due to mess in sunxi-disp.
<rz2k>
max you can get is 720p
<rz2k>
1080 will be 720 in left-upper corner
<cromo>
I think this could be the reason for xbmca10 to misbihave - the hdmi out is 1080p, xbmca10 correctly detects the 1080p, but the fb is still limited to 720p
<cromo>
yep
<cromo>
exactly that
<lundman>
you nailed it
<cromo>
so how come booting straight away with 1080 (via script.bin) make any difference?
<rz2k>
cromo: if you have time & knowledge, you can debug disp modes and find why this happens. also 1080p in android works for some reason.
<cromo>
becasue I assumed it does from empat0's commits
<rm>
1680x1050 over VGA does work
<rm>
but you absolutely have to set the resolution in script.bin
<cromo>
time, yes, knowledge - not sure, most of my programming experience comes from high level languages
<rm>
all those silly knobs (fbset, xrandr, xorg.conf....) they do nothing
<rm>
(silly to Allwinner, I assume)
<rm>
but you still have to set the same res everywhere
<cromo>
I am really tempted to switch to odroid-x
<rm>
only that script.bin is the most important place, without the resolution set there, you will get all kinds of silly effects
<lundman>
ahh so its not just me interested in odroid-x
<rz2k>
odroid doesnt have 3d acc. in native linux, afaik.
<lundman>
but then, the new allwinner mentioned in here sounds good
<cromo>
hmmm
<cromo>
what chip does the cotton candy use?
<cromo>
hmm, 199$
<rz2k>
considering dual core arm and mali400 it is old exynos
<hno>
rz2k, xmbc do not "need" 3d. But is nicer with it.
<cromo>
rz2k: it's single core arm I think
<mnemoc>
for a media center the having more arm cores shouldn't affect anything
<mnemoc>
the important things are made by the VPU and GPU anyway
<mnemoc>
anyone wants to dive into fixing usb on 3.4? :< ... now there is a bug report about a panic merely conencting a usb storage :'(
orly_owl has quit [Quit: leaving]
<cat1>
mnemoc: i made an attempt to reproduce the problem but in my case it did not go any further than this:
<cat1>
[ 58.390000] ehci_irq: port change detect
<cat1>
[ 58.450000] The port change to OHCI now!
<cat1>
[ 58.900000] usb 3-1: device descriptor read/64, error -62
<cat1>
[ 58.750000] usb 3-1: new full-speed USB device number 2 using sw-ohci
<cat1>
suspect some power shortage, need to measure..
<mnemoc>
ouch
<mnemoc>
btw, I'm renaming the main branches to sunxi-3.0 and sunxi-3.4
<mnemoc>
amery's repo will keep a mirror with the old name for some weeks, the ease the transition
<mnemoc>
names*
<mnemoc>
tried with a Y usb cable?
<mnemoc>
to feed power
<cat1>
nope, i am afraid i have some very ancient external usb hd that behaves similarly on my wife's laptop too..
penguin42 has joined #arm-netbook
penguin42 has quit [Quit: Leaving.]
tuliom has joined #arm-netbook
vgrade_ has joined #arm-netbook
mysteryname has quit [Ping timeout: 244 seconds]
gimli has quit [Ping timeout: 245 seconds]
<cat1>
mnemoc: regarding that usb problem: what is that kernel version Linux version 3.4.12-apx6+? I do run Linux version 3.4.12+ and dmesg looks significantly different.. and btw no problem mounting usb hdd whatsoever.
<mnemoc>
good point
<mnemoc>
can you comment about it on the ticket?
<cat1>
mnemoc: done
<mnemoc>
thanks :)
MMlosh has quit [Ping timeout: 260 seconds]
MMlosh has joined #arm-netbook
<cat1>
mnemoc: that was not difficult at all, but now i need to help my wife with translating some chemistry related document, this is gonna be a task! :D
<mnemoc>
but still trying to adapt my working tree to the changes and the split between my wip/ branches and linux-sunxi's
<mnemoc>
trees*
<mnemoc>
i hope this move doesn't confuse people much
<Turl>
mnemoc: so now the tree on amery will be deleted after a while?
<Turl>
or will you keep it up for your own experiments and wips?
<mnemoc>
I'm going to keep the old named branches working as a mirror for a while
<mnemoc>
and keep it for my own wip/s and experiments
<mnemoc>
but only mirror sunxi-3.0 and sunxi-3.4, not the wips, mirrors, etc
<mnemoc>
i don't like it to be called "amery's kernel" :<
rellla has quit [Ping timeout: 246 seconds]
cromo has joined #arm-netbook
<cromo>
techn: I played with fbset however still can't get the 1920 set properly: I switched the mode with a10_tool first, then with fbset, but in the result I have screen divided in 4 parts, two upper repeating the console, two lower showing nothing.
<rm>
cromo, and in script.bin?
<rm>
switched there?
<cromo>
script bin is 720, not swtiched there
<Turl>
mnemoc: woo finally finished gc'ing
<rm>
well here's your problem then
<rm>
as I said earlier you ABSOLUTELY HAVE TO switch in script.bin
<rm>
without it none of your listed means will have the desired effect
<rm>
you will get only various weird glitches
<mnemoc>
Turl: :D
<cromo>
I assumed it is not, from what techn wrote, because once you have it set in script there's no point in using the a10_tool?
<rm>
...maybe?
<cromo>
anyways, where do I find some info about what to change in the script to have 1080?
<cromo>
is it only the [disp_init] or semewhere else, too?
<rm>
maybe techn is working on a10_tool so that it can switch resolution even despite what's in script.bin
<mnemoc>
techn: for sunxi-tools please :)
<Turl>
mnemoc: did we merge the atag tools in the end?
* Turl
doesn't recall what happened
<mnemoc>
i don't even remember that thing
cromo_ has joined #arm-netbook
cromo has quit [Ping timeout: 245 seconds]
<cromo_>
I changed the screen0_output_mode from 720p to 1080, it changed nothing. lundman, I remember you offered to share your mele script.bin with 1080 already in?
tuliom has joined #arm-netbook
cromo has joined #arm-netbook
<cromo>
damn, I had script.bin alongside evb.bin and the latter one is used for booting
cromo_ has quit [Ping timeout: 245 seconds]
<cromo>
or so it seems
<mnemoc>
check your u-boot env
<mnemoc>
our u-boot, and normal nanda's u-boot, uses script.bin
<cromo>
I updated the uboot
<cromo>
but it probably has old env
<mnemoc>
but some images flying around decided using evb.bin (evaluation board) was smart
<mnemoc>
you can see in the wiki how to wipe it from mmc
<cromo>
I will look at it later
<mnemoc>
in nand it's a raw partition, don't remember which
<cromo>
thanks
<cromo>
I diffed the evb and the script.bin
<cromo>
script.bin comes from nightly builds of hwpack
<cromo>
and there are some differences indeed
<mnemoc>
fix your u-boot to use script.bin
<cromo>
brb, reboot
<hno>
mnemoc, it's a separate partition in nand. "env".
<mnemoc>
or wipe it out. it's simpler, and you'll get a branch new one with boot.scr, uEnv.txt and ext2/ext3 support ;-)
cromo has quit [Ping timeout: 245 seconds]
ibrah has joined #arm-netbook
rellla has joined #arm-netbook
<rm>
tickless kernel does not boot
<mnemoc>
and again only with that changed
<rm>
I have disabled tickless now, but enabled PREEMPT :p
<rm>
if that does not boot either, I am labeling them as non-working for 3 more years, thnx
<mnemoc>
and the exact same everything else disabling those two works fine?
<mnemoc>
what's on the console?
<mnemoc>
"does not boot" isn't very helpful to fix things
<Turl>
rm I run NO_HZ on all the things
<Turl>
never had any issues :<
<rm>
do you also use CPUFREQ?
<Turl>
ye
<Turl>
and DVFS
<Turl>
and PREEMPT
cromo has joined #arm-netbook
<cromo>
ha! got xbmca10 running in 1080p just fine :))
<ManoftheSea>
The olimex-stm is 20 euro, this one is $40
<mnemoc>
and adding it to the mini... $4?
<mnemoc>
5?
<ManoftheSea>
adding to the mini?
<ManoftheSea>
What do you mean?
<mnemoc>
the stm32
<mnemoc>
as part of the eng board instead of hacked in over usb
<ManoftheSea>
"hacked in"?
<mnemoc>
connected
<ManoftheSea>
It isn't hacked in.
<ManoftheSea>
It's a standard usb connection.
<mnemoc>
yes. ok
<ManoftheSea>
I
<mnemoc>
i only mean that it's cheaper to make a good eoma68 eng board that buying separated things
<ManoftheSea>
I'm trying to hack up a micro-board in kicad, it's basically a bunch of connectors.
<ManoftheSea>
It's cheaper, if you know what you're doing.
<ManoftheSea>
I don't.
<mnemoc>
neither do i ;-)
<ManoftheSea>
So, a connector board seems pretty easy, and a cheap stm board is easy to connect via usb
<ManoftheSea>
and those other boards have their own expansion modules.
<ManoftheSea>
I wouldn't want to try to be "arduino-compatible" when the maple, the olimex, the one you posted, all already do it.
<mnemoc>
when I mnetioned the need of the stm32 in the from-start eng board was to develop the "EC" firmware
<mnemoc>
not to be abused as arduinoish controller
<mnemoc>
it's for the controller of the laptop board
<mnemoc>
or tablet, or tv
<mnemoc>
there are already plenty cheaper boards to do arduino like tasks
<mnemoc>
starting with the olinuxinos
<mnemoc>
or the r-pi
* ManoftheSea
chuckles at mnetioned from mnemoc
<mnemoc>
:p
<ManoftheSea>
mnemoc: right, and there are plenty of stm32f boards to do that EC firmware dev.
<ManoftheSea>
That are several revisions in, already
<mnemoc>
true
<mnemoc>
ok
<mnemoc>
but please add a hub
<ManoftheSea>
oh yeah, definitely
<ManoftheSea>
I've pulled a 7 port datasheet.
<mnemoc>
i know there are plent external usb hubs already too :p
<ManoftheSea>
I think it's multi-TT, at that
<mnemoc>
but it's annoying
<mnemoc>
nice
<ManoftheSea>
yeah, the hub is really useful for a micro board
<penguin42>
multi-tt?
<ManoftheSea>
some downstream can be 1.1, other's 2.0
<mnemoc>
and as the io board has power we can feed the usb ports too
<ManoftheSea>
right. I think the chip does that.
<mnemoc>
ManoftheSea: but who will we do the backlight of the lcd connected to the micro-eng?
<ManoftheSea>
as it has provision for ganged mode or not.
<mnemoc>
s/who/how/
<ibot>
mnemoc meant: ManoftheSea: but how will we do the backlight of the lcd connected to the micro-eng?
<ManoftheSea>
mnemoc: it'd have to be on the STM side.
<mnemoc>
ok
<ManoftheSea>
Though, you could wire it up with a GPIO.
<ManoftheSea>
perhaps.
<ManoftheSea>
I dont' know how backlights are currently done. It doesn't seem to be part of the LVDS link.
<ManoftheSea>
So... it's either GPIO from the micro-board or USB device at the STM32 side.
<ManoftheSea>
I guess it could be I2C. I'm not really sure.
<mnemoc>
stm32 side sounds more likely than a boolean gpio
<ManoftheSea>
I don't know enough about lcd panels.
<mnemoc>
i don't know anything ;-)
<mnemoc>
but i would expect it to not work as a boolean
<ManoftheSea>
But, I plan to put a connector for everything coming from the PCMCIA. I'd like them to be the right connectors.
<ManoftheSea>
So, that means it will be that TI chip.
<ManoftheSea>
er, converter chip that goes RGB to LVDS, and then an LVDS connector.
<ManoftheSea>
At which point, a dev could add their lcd screen.
<mnemoc>
olimex is going to sell cheap (~55E) panels for the A1X olinuxinos
<mnemoc>
or mimic's arduino lcd connector
<mnemoc>
lvds is too fancy at this stage
<mnemoc>
imo
<mnemoc>
but if the stm32 is in a different board that can be... complicated
<ManoftheSea>
too fancy?
<ManoftheSea>
LVDS is how you connect to a panel.
<mnemoc>
but they aren't easy to buy for a hobbiest...
<mnemoc>
or they are? .oO
<ManoftheSea>
well, amazon is full of "replacement laptop screen"
<ManoftheSea>
I don't know if there's a standard pinout for those, though.
<Turl>
mnemoc: are struct definitions well suited for a .h?
<Turl>
s/definition/array initialization/
<ibot>
Turl meant: mnemoc: are struct array initializations well suited for a .h?
<mnemoc>
Turl: no
<penguin42>
generally I'd put initializations in .c
<mnemoc>
extern goes in the .h
<Turl>
yeah but extern ... stuff[*hardcode stuff here*][2] :(
<mnemoc>
you don't want to repeat the symbol on every .c including the header
<Turl>
otherwise sizeof and friends complain
* Turl
will have to live with a macro :P
<mnemoc>
extern T a[N][M]; is fine
<mnemoc>
just be sure to use the same N/M when actually defining the a
<Turl>
yeah that's why I don't like it :<
<mnemoc>
but as a general rule, globals are evil
<Turl>
mnemoc: it's a table
<ManoftheSea>
ok, according to this TI led controller chip, dimming is achieved by PWM
<penguin42>
hmm do you need the N in the extern, or will it let you get away with out it
<ManoftheSea>
So, I'd call that a USB device on the STM32F.
<mnemoc>
Turl: tables are usually static
<ManoftheSea>
Also... the STM32F is a handy little chip. As long as we assume someone will write the code, I could probably build a robot to build a pyramid. On Mars.
<mnemoc>
Turl: it seems to me you are approaching your problem the wrong way
<mnemoc>
Turl: even when I don't know what you are doing
cromo has quit [Quit: Page closed]
<mnemoc>
Turl: needing the world to know the size of a table hardcoded in a header is BAD
<mnemoc>
only the code where the static table lives should deal with it
<mnemoc>
and in that case ARRAY_SIZE() works well
<mnemoc>
ARRAY_SIZE(A) been (sizeof(A)/sizeof(A[0]))
<mnemoc>
but only in the same .c
<Turl>
mnemoc: keeping all the tables together seems like a logical idea to me
<penguin42>
Turl: You can do things like; int foo[][2]; in the header; and in the .c file you can do int foo[][2]={{1,2},{2,3}}
<penguin42>
Turl: That way the header doesn't need to know the outer array index (just tested)
<Turl>
penguin42: yeah but if you use sizeof it complains because [] :)
<mnemoc>
Turl: no clue what you are doing, but global tables are just as bad as global variables
<mnemoc>
just don't
<penguin42>
Turl: Right, but then it depends what you are doing with the table; if you terminate the table by a magic number rather than relying on size it's fine
<mnemoc>
Turl: fine, add a function in that .c to grant access
<mnemoc>
check size, etc
<mnemoc>
callers don't need to know
<Turl>
that function is the only table user
<mnemoc>
then move the function
<mnemoc>
or refactor it between both places
<mnemoc>
exporting one function is saner than exporting table and size
<Turl>
cpu-freq-table.c holds tables only, and I think it makes for cleaner code that way as all the 'tunables' are in one place
<Turl>
if sun5i has different clock freqs and divs you'd just need a different cpu-freq-table.c
<mnemoc>
Turl: how will that work since 3.7 when multiplatform is required?
<mnemoc>
same kernel for A10, A12, A13, A10s, A15, ...
<Turl>
I haven't looked at 3.7 but I suppose you could have something somewhere on the init path assign the right table to the variables depending on cpu
<mnemoc>
global tables are wrong
<Turl>
if(A10) table= ...
<Turl>
elif(A13) table= ...
<mnemoc>
but i can't force you to understand it
<mnemoc>
Turl: that's better
<mnemoc>
table = sunxi_a10_table(&l);
<mnemoc>
get a pointer to the table, and it's length
<mnemoc>
no global table involved
<mnemoc>
but an access function
<mnemoc>
it can also be sun4i_tablet(&l); and the accessor will decide if it's A10 or A10s
<ManoftheSea>
what's A10s?
<ManoftheSea>
is that plural, or is that like iPhone 3s
<mnemoc>
"small"
<mnemoc>
a new variat of the A10
<mnemoc>
but we don't know anything about it beside what is in the product page :<
Quarx has quit []
<mnemoc>
sadly it seems they removed SATA
<ManoftheSea>
so it's an A13?
<mnemoc>
nope. A10
<mnemoc>
but will less pins and features removed, aimed at hdmi dongles and settop boxes
<ManoftheSea>
I mean, I thought that was the reasoning behind the a13. It's a small a10
<mnemoc>
A13 has different packageing
<mnemoc>
and it's tablet oriented
<mnemoc>
the A10s doesn't have LCD
<mnemoc>
only hdmi
<ManoftheSea>
LCD? Do you mean the two RGB outs?
<mnemoc>
the a13 is larger than the a10
<mnemoc>
no rgb either
<mnemoc>
Turl: but going back to the extern. extern struct cpufreq_dvfs dvfs_table[]; doesn't work? you have a sentinel, so you don't need the lenght
<mnemoc>
it's probably a good idea to replace the length of the other tables with sentinels too
<mnemoc>
looping by index suchs
<mnemoc>
sucks
<ManoftheSea>
Ok, shit. LVDS isn't a standard connector. I'm looking at a panel from '09, it's a 40 wire connection.
<ManoftheSea>
It uses 2 channels of 18-bit color LVDS.
ibrah has quit [Ping timeout: 248 seconds]
<ManoftheSea>
there's no indication of where the other 2 pairs would go, for a 2-channel 24-bit screen.
<mnemoc>
one way is to search for a common connector used in cheap panels and provide easy locations to buy :p
<ManoftheSea>
arg.
<ManoftheSea>
mnemoc: no, I think the connector is defined by the panel.
<mnemoc>
or adopt arduino's header
<mnemoc>
or olimex's lcd header
<mnemoc>
both are 0.1" pins
<ManoftheSea>
yeah, but those are industrial type things. I was thinking toward the laptop board.
<mnemoc>
for a laptop board you need to marry one lvds, yes
<mnemoc>
i was thinking in the eng boards
<ManoftheSea>
right. DVI it is.
<mnemoc>
btw, this is why i called lvds connector a fancy choice
<mnemoc>
people wouldn't have inexpensive options
<ManoftheSea>
when did you call it fancy?
<mnemoc>
19:44:48 < mnemoc> olimex is going to sell cheap (~55E) panels for the A1X olinuxinos
<mnemoc>
19:45:19 < mnemoc> or mimic's arduino lcd connector
<mnemoc>
19:45:36 < mnemoc> lvds is too fancy at this stage
<mnemoc>
19:48:00 < ManoftheSea> too fancy?
<mnemoc>
19:45:43 < mnemoc> imo
<mnemoc>
even when for an EE a DVI is fancier in the sense of more layers
<ManoftheSea>
ok.
<ManoftheSea>
layers... on the board?
<ManoftheSea>
what?
<mnemoc>
no no... sorry. layer in the software sense. abstractions. conversions
<mnemoc>
lvds is "native"
<mnemoc>
to get anything else you need to add extra stuff in the board
<mnemoc>
i don't know about electronics... i'm only a C ape
<ManoftheSea>
RGB is native.
<ManoftheSea>
But it doesn't go far enough.
<ManoftheSea>
So, convert to DVI, plug in to standard monitor.
<mnemoc>
sounds good
<ManoftheSea>
LVDS is apparently for when we mate with a screen.
<ManoftheSea>
as you said, I agree.
<mnemoc>
it could even be dvi looking like hdmi
<ManoftheSea>
looking like?
<mnemoc>
normal hdmi connector
<mnemoc>
instead of large dvi connector
<mnemoc>
but without audio, so not strictly hdmi
<mnemoc>
there are cheap adapters
<mnemoc>
many do that thing
<mnemoc>
also saves them from paying hdmi royalties
<mnemoc>
i thought i had to keep trying to convince you :p
<mnemoc>
so ttl/rgb to dvi with hdmi connector... can we reach ~1080p with that?
<ManoftheSea>
no.
<mnemoc>
:(
<ManoftheSea>
Well...
<ManoftheSea>
As far as I can tell, RGB-TTL is only expected to reach 1400x1050
<mnemoc>
still better than the 1366x768 of my laptop...
<mnemoc>
and we can always hook the 1080p on the real hdmi on the other side of the card
<ManoftheSea>
right... but from my uneducated vantage, it looks like all EOMA will be max 1400x1050, on the internal connector.
<ManoftheSea>
Yes, you can have a loopback cable.
<mnemoc>
considering lkcl aims at smart tvs too, the max 1400x1050 sounds ugly
<hno>
Next step is LVDS instead of TTL I suppose.
<mnemoc>
and why didn't we get lvds pins in the eoma68 header instead?
<hno>
Because cheap panels are TTL?
<mnemoc>
ok
<hno>
And because TTL is a common denominator for many possible SoCs.
<ManoftheSea>
Because RGB can go to LVDS, DVI, etc.
<ManoftheSea>
I suppose there's DVI->LVDS.
<ManoftheSea>
But... probably because a lot of chips put out RGB, rather than LVDS, and the conversion is another chip on the EOMA card.
<ManoftheSea>
This converter claims to require 3.3V at 1/4 A, or... a little under a watt?
<ManoftheSea>
when you only have a 4 W budget, that's expensive
<mnemoc>
how would resolution detection/change work with the rgb/dvi?
<ManoftheSea>
also... you need two lvds channels. that's... 10 wires?
<ManoftheSea>
mnemoc: I don't know how it works with anything else.
<ManoftheSea>
I've heard the term EDID.
<ManoftheSea>
I think that's across I2C.
<mnemoc>
but that is on the dvi side
<mnemoc>
the guy talking rgb needs to be... informed
* mnemoc
puzzled
<penguin42>
mnemoc: I don't think there is a standard way of determining the size of an LCD that's directly connected
<mnemoc>
it was told that we would need to hardcode the info about the panel in the eeprom
<mnemoc>
but having dvi in between... it's not hardcoded anymore
<penguin42>
mnemoc: Well that's all that happens on dvi; the i2c eeprom is in the monitor
<mnemoc>
:)
<penguin42>
mnemoc: And some of them are dumb enough to let you overwrite them
<mnemoc>
LD
<mnemoc>
:D
<penguin42>
you occasionally come across a monitor with the wrong EDID info and all hell breaks loose (whether that's accidental or someone being nasty...)
<ManoftheSea>
ok, so... If the device is DVI, it has an i2c EEPROM with device tree that specifies, "look for edid"
<mnemoc>
then in 3.4 we can merge them it to plat-sunxi
<mnemoc>
well... maybe sending it to ML first for comments and testing is better
<Turl>
mnemoc: just compared the sun4/5i pre-patches
<Turl>
mnemoc: they're *identical* except for the comments holding the copyright, because one says sun4i and the other says sun5i on the path
<mnemoc>
happens a lot :p
<mnemoc>
that why I prefer to unify before cleaning/fixing/improving
<Turl>
yeah
<mnemoc>
Turl: what about moving the prepatch part into a driver?
<mnemoc>
unified
<Turl>
driver?
<mnemoc>
drivers/cpufreq/cpufreq-sunxi
<mnemoc>
but bool instead of tristate (not m)
<Turl>
doesn't make much sense imo
<mnemoc>
that's actually the modern way of doing things in linux arm. everything is a driver
<Turl>
and I don't see any other arch doing it that way
<mnemoc>
check at more recent trees
<mnemoc>
arch/arm/mach-foo/ are been emptied
<Turl>
there's db8500-cpufreq.c
<mnemoc>
and arch/arm/plat-foo/ been destroyed
<mnemoc>
part of the multiplatform effort were no globals are allowed
<mnemoc>
where*
<mnemoc>
Turl: thing is in 3.0 we don't have a plat-sunxi
<mnemoc>
so we can't unify the cpufreq things without moving them to the drivers space
<mnemoc>
adding plat-sunxi in 3.0 makes little sense considering we need to move 3.4 away of it anyway
<Turl>
mnemoc: we'd need to move the ccmu thingy to a driver first from what I'm looking
<mnemoc>
:)
<mnemoc>
so we know "what's next" toward mainlining ;-)
<Turl>
:P
<Turl>
I'm not too familiar with the ccmu code though, and the short scrambled names scare me :)
<Turl>
need to start reading and see what can I do there
<mnemoc>
remember, no cleanup, no improving. only relocating
<mnemoc>
and adapting to allow it
<mnemoc>
Turl: another way is simply to apply the same cleanup in sun4i and sun5i cpufreq and unify in plat-sunxi in 3.4 first and then jump to drivers/
<hno>
mtd is making my head spin a little. Need to get a little more familiar with NAND to make sense of the interface.
<mnemoc>
hno: adding raw access to the nand in u-boot will give you the missing knowledge to be able to write an mtd driver ;-)
<Turl>
mnemoc: I'd like some basic testing first though, before duplicating all the things :)
<mnemoc>
:)
<Turl>
*hint* :P
<mnemoc>
Turl: and send it to the list for comments
<mnemoc>
Turl: I can't test it at the momemnt :< ... need to finish some pending $work$ before monday begins :-/
<techn>
Maqs: also xbmca10 is good example
<mnemoc>
the relocation of the repos and today's chat already consumed more than the sunxi time I had :\
<Turl>
mnemoc: :(
<techn>
mnemoc: are we getting any new developers via cubiecoard/olinuxo? :)
<mnemoc>
doesn't look like it yet
<techn>
atleast xbmca10 progress should bring more testers :)
<mnemoc>
if only we would have armhf cerdarx libs they could test even more :|
ceo16 has quit [Ping timeout: 248 seconds]
<hno>
mnemoc, adding raw nand access to uboot is writing an mtd driver.
<hno>
but mtd surely would benefit from a somewhat higher level nand interface, operating at command level rather than signal level.
dw4rf has joined #arm-netbook
newbie has joined #arm-netbook
newbie is now known as Guest96895
<mnemoc>
hno: i was mostly thinking is boot1 dumping
<mnemoc>
but yes, that can be done with the mtd driver too
hp__ has quit [Ping timeout: 276 seconds]
<mnemoc>
assuming we kill legacy nand support
<hno>
Ah, just found code showing how to read the boot area using aw driver.
<mnemoc>
\o/
ejstacey has quit [Ping timeout: 260 seconds]
zenitraM has quit [Ping timeout: 256 seconds]
cncman has joined #arm-netbook
<cncman>
i'm designing a pcb with allwinner a10,is it possible not to put nand flash and boot from microsd??
<hno>
cncman, yes.
<cncman>
great
<cncman>
i can't get cheap flash modules
<hno>
if you don't have nand then you can easily have two SD slots. One for OS and one for removable storage.
<mnemoc>
you can also have two microsd slots (internal/external)
<mnemoc>
meh
<hno>
B)
<mnemoc>
:)
<cncman>
i'm going to do more research ,thx a lot
<hno>
cncman, MMC2 controller is on the same pins as NAND.
<hno>
boot order is MMC0, NAND, MMC2, SPI-
<hno>
Wonder if it works to push the NAND I/O with CPU instead of DMA.
<mnemoc>
-# CONFIG_SUN5I_A12 is not set
<mnemoc>
-CONFIG_SUN5I_A13=y
<mnemoc>
^---- "nuclear" defconfigs...
<rz2k>
cncman: please check your datasheet, if you are designing with public available ones - be aware that ddr pins are messed up there.
<rz2k>
probably olimex a10-olinuxino can be used as reference design
<mnemoc>
the only open schematics actually used to make boards already is the cubie's
<mnemoc>
there is no prototype of the a10-olinuxino yet
<rz2k>
forgot that Tom released schematic :p
<mnemoc>
and the eoma68-a10 ended up been closed :<
<cncman>
opss, ddr pins are messed up?? wtf
<mnemoc>
the real cards i mean
<cncman>
and where can i find the good datasheets?
<mnemoc>
cncman: nowhere
<cncman>
olinuxino released a preview version of schematics
<cncman>
of a10
<mnemoc>
cncman: the "reference design" is the good datasheet
<mnemoc>
yes
<rz2k>
cncman: in datasheets floating around ddr3 pins are wrong. use cubieboard schematic as a reference. or contact Allwinner and buy 10K pcs and get official datasheets without mistakes.
<cncman>
mmm..i don't have the allwinner official reference design
<mnemoc>
cncman: olimex's schematics are based in the known good info
<cncman>
rz2k: i have 100 chips, small fish for allwinner to contact
<hno>
rz2k, last I heard the datasheet is correct, just using a different terminology than what's normal.
<hno>
rz2k, there is no other "official" datasheet for the pinouts.
* mnemoc
hates having to do webapps :|
zenitraM has joined #arm-netbook
ejstacey has joined #arm-netbook
gimli has joined #arm-netbook
zenitraM has quit [Ping timeout: 264 seconds]
zenitraM has joined #arm-netbook
ejstacey has quit [Remote host closed the connection]
<Turl>
"Awesome HKTDC Fair video covdrage coming up. Here's I'm playing on the awesome new $149 Archos Gamepad that runs on awesome RK3066 with Mali400mp4. Perhaps it can emulate all consoles perfectly up to N64, PSX and Dreamcast! Thin, light, form factor is awesome!"
<Turl>
150$ for a 4-core mali? not bad :P
<ZaEarl>
rk3066 has taken over the market
<mnemoc>
ZaEarl: and the news from allwinner? :<
<techn>
what is price point for sun6i?
<ZaEarl>
anybody's guess at this point, but using the a7 cores are very small, so it should be a good price.
<mnemoc>
ZaEarl: did any factory confirmed you it's a quad a7?
<cat1>
techn: please give me any ideas why i still get this :)
<penguin42>
mnemoc: it would be a little odd choice; but I guess it lets you claim quad core and a good quad core without being as large/complex as an A(
<techn>
cat1: you dont have that buf2 commit?
<cat1>
i guess i do as i am using sunxi-3.4
<cat1>
techn: or it is not there..
<mnemoc>
penguin42: the A7 is the little brother of the A15
<mnemoc>
penguin42: so i suppose it counts as better than an A9
<penguin42>
mnemoc: That depends how you look at it; the A7 is the little brother; but as I recall it's performance is supposed to be somewhere between A8 and A9
<techn>
cat1: I didn't find it with quick check :(
<cat1>
techn: uh-oh.. mnemoc? :)
<mnemoc>
afaik 3.4 doesn't include 2 buffers support
<mnemoc>
fixes are in the next_mali branch for 3.0
<cat1>
mnemoc: ah, but why we cannot take them into 3.4?
<mnemoc>
if they aren't good enough for 3.0 yet, why would they be good for 3.4?
<ZaEarl>
mnemoc, yes, they've told me it's quad a7, but these are basically marketing people. they've been wrong before.
<cat1>
mnemoc: dunno, but maybe it would be good to maintain 3.4 at the same level of usability as 3.0...
<mnemoc>
cat1: that's exactly where it is
<mnemoc>
cat1: 3.0 still has r2p4, as 3.4
<mnemoc>
and no "2 buffers"
<mnemoc>
once techn/rz2k tell me to merge something from next_mali to 3.0, I'll do it for 3.4 too
<ZaEarl>
for an arm server I'd choose a15, but for a mobile device running on battery, a7 is an excellent choice
<mnemoc>
i think a7 is a good choice for allwinner's target too
<hno>
many-little :)
<mnemoc>
:p
<cat1>
mnemoc: sorry, my bad, i forgotten this.. i just remember it was working for me in 3.6, but now i realized that i merged next_mali..
<mnemoc>
:)
<mnemoc>
cat1: push techn/rz2k to get that mergeable :p
<mnemoc>
at least the dual buffer for r2p4
<mnemoc>
i've never ever ever tried x11/mali myself.
<mnemoc>
so it's not my call to decide
mysteryname has joined #arm-netbook
The-Compiler has quit [Remote host closed the connection]
The-Compiler has joined #arm-netbook
<techn>
question is that is should me move to r3p0 since there is working android libs for that :p
<mnemoc>
yes, need to keep same version on both worlds
<rz2k>
actually we can provide both r2p4 and r3p0/1, afaik we have r2p4 just sort of "integrated" in kernel build but it is another build invoking makefiles and such stuff detachable from kernel. I was able to build working r3p1 drivers just for test without libs and they loaded up.
n6pfk has quit [Remote host closed the connection]
mikey_w has quit [Read error: Connection reset by peer]
<rz2k>
buf1/2 stuff can be ifdef'ed with selection of r2 or r3
gimli has quit [Remote host closed the connection]
<rz2k>
also some time ago we had mali in /modules/
<mnemoc>
we need it in tree to be able to do drm/ump integration
<mnemoc>
android doesn't care, but x11 does
<rz2k>
ump is also builds ok with our kernel
<rz2k>
from r3p1
<rz2k>
I've copied our setup from r2p4 to right place in ump and it worked
<mnemoc>
i like the idea of updating to r3p0 better :p
<mnemoc>
we only need it to work "as-good" as r2p4
<rz2k>
yeah, but only sort-of working opengles x11 is r2p4 on armel...
<mnemoc>
:<
<mnemoc>
what i don't understand is why cat1 is getting those dual-buffer errors in 3.4
<mnemoc>
having r2p4
<rz2k>
probably he grabbed my x11 drivers repo with build script :p
<hno>
mnemoc, I keep getting moderation requests for linux-sunxi, but apparently have no permission to moderate?
<cat1>
rz2k: nope, i did not :)
popolon has joined #arm-netbook
<mnemoc>
hno: i think the permission error happens when messages are already moderated/passed
<rz2k>
cat1: r2p4 x11 doesnt have GET_UMP_SECURE_ID_BUF2 ioctl at all
<cat1>
rz2k: maybe because i am using r3p0?
<rz2k>
%)
<mnemoc>
cat1: doh
<hno>
mnemoc, I don't see the last message ("LiveSuite uses awusb driver that has some trivial bugs") accepted.
<mnemoc>
uhm
<rz2k>
mnemoc: hno has same error as me.
<cat1>
mnemoc: rz2k: yeah, it is a bit messy.. but rather in my head :)
<techn>
linux x11 libs doesnt work (missing symbols).. noone linux framebuffer libs
<cat1>
rz2k: thanks, but it does not apply cleanly against 3.4 :(
<techn>
*none has tried
<mnemoc>
cat1: make a next_mali upon 3.4 and test it. your fixes in 3.4 should also apply to 3.0's
<rz2k>
mm, you mean DRM commit? because there can be actually some changes in DRM between 3.0.42 and what you use. previous issue with DRM was caused by changes in DRM between 2.6.38 and 3.0.x
<mnemoc>
and eventually both get merged
<cat1>
rz2k: nope, the previous, fb one
<rz2k>
here you need poke hno as author of disp-ump and techn as guy who fixed it to r3 :p
* hno
knows nothing about disp-ump, only haced up the basics to show how to split ump from disp.
<cat1>
rz2k: no worries, i think i will manage to merge it, but probably a bit later today, it is 2:18AM here already :)