<ssvb_>
and regarding fedora on mele a2000, I'm still experimenting with it
<calris_>
ssvb_: What's the general gist of the problem? Is it related to the performance difference between xf86-video-mali and xf86-video-sunxifb?
<calris_>
ssvb_: And would you expect there to always be a dedicated xf86-video-sunxifb, or would you expect your work to be folded into the generic xf86-video-mali?
<ssvb_>
no, it's for most parts related to low default memory clock speed on mele, and the scanout for large screen resolution stealing a lot of memory bandwidth
<ssvb_>
the problems would have been even more severe with xf86-video-mali, but you are lucky not to use it yet
<calris_>
ssvb_: Can I force a lower resolution? Would that solve the issue? (I can deal with lower res as it's just for browsing, email and document editing)
<calris_>
ssvb_: Thanks! I'll give it a try tonight :)
<ssvb_>
just edit uEnv.txt on the first fat partition from the SD card and remove the EDID: part from "disp.screen0_output_mode=EDID:1280x720p60" to make it use 1280x720p60
<ssvb_>
one more problem is the CPU frequency scaling, the processor sits on 408MHz and does not want to go up according to the cpufreq applet even if I try scrolling in firefox
<calris_>
ssvb_: Can frequency scaling be disabled and just run the thing at maximum clock permanently?
<ssvb_>
it seems to increase the clock frequency to 1GHz only if I try pulling the scrollbar really hard
<calris_>
ssvb_: I'm not too concerned about power conservation (it's not a tablet after all)
<ssvb_>
yes, it should be possible to change the frequency scaling governor to "performance"
<calris_>
ssvb_: And what about memory clock?
<calris_>
ssvb_: Does that need a bump up as well?
<ssvb_>
the default mele u-boot configures it to 360MHz, but the hardware seems to be able to go up to 480MHz without problems (though we don't have much statistics)
<ssvb_>
an updated u-boot is needed to try higher memory clock speed, afaik it can't be simply changed by just editing a config file
<calris_>
ssvb_: Yes, I'm familiar with U-Boot and I figured as much...
<calris_>
ssvb_: It should not be that hard to add code to dynamically set it from an environment variable
<ssvb_>
various Allwinner A10 devices use different memory clock speed (from 360MHz in Mele to 480MHz in cubieboard), the reason why 360MHz is used for Mele is unknown
<ssvb_>
but it really does affect 2D graphics performance a lot
<calris_>
Henrik Nordström was doing a lot of work on U-Boot for the A1x
<calris_>
Might be worth asking him
<ssvb_>
I think hno just takes the same memory settings as used in android, obtained by a10-meminfo tool
<ssvb_>
techn_: apparently the changes to the layers actually take effect only on next vsync (which kind of makes a lot of sense)
<ssvb_>
techn_: looks like proper tear-free XV support is a lot easier than I thought before and do not require any changes to the current kernel :)
<calris_>
ssvb_: Do you know how script.bin fits in with the whole boot process?
<calris_>
It looks like we should be able to set the final mem clocks in script.bin
<ssvb_>
calris_: script.bin is generated from .fex text file, but memory clock settings from .fex actually have no effect
<calris_>
ssvb_ :(
<ssvb_>
if you experiment with changing the memory clock speed, make sure to verify that the relevant hardware registers are really configured for the right clock speed (via a10-meminfo)
<ssvb_>
or by running memory benchmarks
<calris_>
When is script.bin processed? It looks like it's loaded into memory along with the kernel so I'm assuming the kernel process it
<ssvb_>
I'm not that much familiar with this stuff, but it sounds right
<ssvb_>
if you want to run a quick test, just patch a single line in u-boot, and recompile u-boot
<ssvb_>
at least this works for me :)
<calris_>
ssvb_: btw, it looks like the memory clock has to be a multiple of 24 (360 -> 384 -> 408 -> 432 -> 456 -> 480)
<ssvb_>
yes
<calris_>
ssvb_: I don't have access to a build machine... Won't have for some time
<calris_>
But I should be able to hack the u-boot binary with a hex editor :)
<calris_>
Just need to find struct dram_para dram_para in the image
ZaEarl has joined #linux-sunxi
<calris_>
OK then - I've been trawling around the U-Boot and Linux kernel sunxi code and have a question...
<calris_>
Why use script.bin? Is there any reason not to use FDT?
<calris_>
This seems to be the parser for script.bin
<calris_>
If FDT was used instead, it opens up all kinds of opportunities to process stuff in U-Boot and move stuff out of the kernel command line
egbert has quit [Disconnected by services]
egbert_ has joined #linux-sunxi
<ZaEarl>
calris_, FDT is going to take some time to rewrite for.
<calris_>
ZaEarl: Yes, I understand that :)
<calris_>
ZaEarl: The underlying question is - will FDT do everything script.bin already does?
<ZaEarl>
I have no idea, but I do know script.bin is very early in the boot, so it might be too early for FDT.
<calris_>
I don't think there is an issue there - I think FDT is available very early in the linux kernel as well
<calris_>
I am also wondering if the SDRAM timings can be changed on the fly (say from 360 to 480)?
torqu3e has quit [Ping timeout: 245 seconds]
<ZaEarl>
when I say boot, I mean before the kernel boots
torqu3e has joined #linux-sunxi
<calris_>
script.bin is loaded into memory by U-Boot so the kernel can pass it - It is not really used until kernel entry
<calris_>
In contrast, U-Boot can process an FDT (edit and insert nodes)
<calris_>
In theory, you could add script.bin processing to U-Boot, but you won't get it into mainline (it's FDT or nothing :))
torqu3e has quit [Ping timeout: 245 seconds]
torqu3e has joined #linux-sunxi
<ZaEarl>
does boot0/boot1 make use of script.bin?
<calris_>
Well the boot sequence is BROM reads the U-Boot SPL from the SD Card as raw pages (starting at an 8k offset I think) and then U-Boot SPL reads U-Boot from the SD Card file-system
<calris_>
Don't forget that script.bin can be called anything, but is referenced by a U-Boot environment variable (e.g. load1=fatload mmc 0 43000000 evb.bin)
calris_ has quit [Quit: Page closed]
calris_ has joined #linux-sunxi
<calris_>
It will be interesting to see what amery, hno, and rzk think
torqu3e has quit [Ping timeout: 245 seconds]
torqu3e has joined #linux-sunxi
<calris_>
I'll try changing the monitor resolution and setting the governor to performance when I get home
calris_ has quit [Quit: Page closed]
anunnaki has quit [Ping timeout: 256 seconds]
christopher has joined #linux-sunxi
christopher is now known as Guest16605
Guest16605 is now known as anunnaki
ZaEarl has quit [Ping timeout: 264 seconds]
rellla has joined #linux-sunxi
rellla2 has joined #linux-sunxi
rellla has quit [Ping timeout: 264 seconds]
<oliv3r>
zaearl 90% sure it does
<oliv3r>
could be it uses cardscript.bin though
carlo_ is now known as n01
hansg has joined #linux-sunxi
theOzzieRat has quit [Read error: Connection reset by peer]
theOzzieRat has joined #linux-sunxi
<calris>
oliv3r: 99.9% sure it doesn't:)
<oliv3r>
let me put it this way, boot0 and boot1 do use 'some' script and could be that it is only cardscript.bin
<oliv3r>
though don't think we have done much/anything with that and know naything about it
<oliv3r>
i did find cardscript.fex in livesuit images and on github
<oliv3r>
or ... let me re-grep the source for it ;)
<oliv3r>
it might be that cardscript.fex is used for the brom even
<mnemoc>
the brom is supposed to be rom :)
<mnemoc>
but livesuit does probing and "patches" the included boot0/boot1
<mnemoc>
that's why we use a10meminfo to read the dramc registers and complete the dram_para section of the .fex
<mnemoc>
neither boot0/boot1 or u-boot use the script.bin on nanda. only the kernel does
rellla2 has quit [Ping timeout: 245 seconds]
hipboi has joined #linux-sunxi
<calris>
mnemoc: but the kernel does not use the dram_para section as far as I can tell
<hipboi>
calris: yes
rellla has joined #linux-sunxi
<mnemoc>
we use the dram_para section as reference for u-boot
<mnemoc>
wb hipboi
<calris>
hipboi: is there any reason the kernel could not re-time dram based on script.bin?
<calris>
Also, is there any reason (in the long term) to not use Device Tree?
<calris>
U-Boot can process an FDT, so in theory we could convert FEX to FDT and have U-Boot process it (and the kernel)?
<mnemoc>
calris: long term is FDT. part of the mainlining effort
<oliv3r>
calris: did you ask this on the mailing list? I did reply there :)
<calris>
Yes
<mnemoc>
calris: sunxi-3.0/sunxi-3.4 are not long term. they are to have something functional and maintianed today, to be used to unify the different SDKs/source drops/sun?i code, and to produce generic sunxi drivers that can be used as reference for the mainlining effort
<oliv3r>
calris: i answerd you then on the ML :p
<hipboi>
calris: as long as the program run in the dram
<oliv3r>
mnemoc: google is working on 3.8 atm (which should have our first mainlining commit?) we gonna branch that anytime?
<hipboi>
you can can config dram again
<oliv3r>
hipboi: you mean if the program is loaded (and running FROM) dram you can retime it? I would assume it would be running from the sram and only then you could reconfigure it.
<calris>
oliv3r: I would love to, but I am sans a dev machine, and family is top billing :)
<hipboi>
oliv3r: sorry, i mean can't
<mnemoc>
oliv3r: I don't think it's a good idea to waste energy in a "legacy" 3.8
<oliv3r>
hipboi: ah, okay, crucial but makes more sense :)
<calris>
So how does U-Bot manage it?
<hipboi>
if the kernel runs, the kernel can not re-config the dram
<oliv3r>
mnemoc: legacy? well 3.8 seems like it will be the next android kernel
<mnemoc>
oliv3r: imo it's more important to unify all we have a sunxi-3.4, and mainline the stuff
<oliv3r>
mnemoc: absolutly, just thinking about future code drops, which may be based on 3.8
<hipboi>
phonexcard
<mnemoc>
calris: u-boot-sunxi has per-board config, decided on build time
ganbold_ has joined #linux-sunxi
<mnemoc>
calris: and we can "convert" the verified/completed dram_para in a .fex into a board.c for u-boot-sunxi
<mnemoc>
eventually we will convert all .fex files in sunxi-boards into .dts
<mnemoc>
but the drivers are still modeling their FDT representation, during the mainlining process
RaYmAn_ has joined #linux-sunxi
torindel_ has joined #linux-sunxi
<mnemoc>
oliv3r: 3.8 is just too different. the effort to port the 3.4 stuff up there is equivalent to the effort to make the support mainlineable
<oliv3r>
true true
<mnemoc>
oliv3r: that's why I think it will only be a distraction
<n01>
so, does u-boot-SPL reconfigure the DRAM?
RaYmAn has quit [Disconnected by services]
<mnemoc>
n01: it initializes the DRAM
RaYmAn_ is now known as RaYmAn
<mnemoc>
n01: it's not a re- thing. it's the first time
torindel has quit [*.net *.split]
ganbold has quit [*.net *.split]
<n01>
ok, but if we want to retime it?
<oliv3r>
hipboi: phoenixcard? only for flashing?
<n01>
we should do it in SPL since u-boot runs from DRAM?
<hipboi>
oliv3r: yes
<mnemoc>
hipboi: hipboi just said it's possible to reconfigure it on runtime. there is no public documentation, so you would need to experiment
<oliv3r>
to boot into fel mode?
<n01>
wait, I understood it is NOT possible (<hipboi> oliv3r: sorry, i mean can't)
<mnemoc>
n01: ok
<hipboi>
mnemoc: not possible
<oliv3r>
n01: u-boot configures dram; the kernel cannot configure dram (from what hipboi said)
<oliv3r>
which makes perfect sense
<mnemoc>
ack
<oliv3r>
so while the kernel can configure mostly everything, dram will have to be set up by u-boot
<hipboi>
mnemoc: if you are running in DRAM, you can jump to sram, and then reconfig the dram
<n01>
ok, got it
<oliv3r>
maybe you could do some super magic :p
<oliv3r>
put the system into suspend and have a specialised firmware that runs in sram? Isn't that what standby does anyway? a special program that refreshes dram
<oliv3r>
does it change memory settings too? to make it more power efficient (e.g. downclock it)? if so then you technically could do it while running (sleepign) linux
<mnemoc>
oliv3r: I suppose the dram will be wiped when reconfigured
<mnemoc>
oliv3r: and your suspend goes to hell
<hipboi>
mnemoc: yes, dram will be wiped
<oliv3r>
then it's impossible to do it from a standby state, but hibernate state!
<oliv3r>
it would be extremly slow though, and not very practical
<mnemoc>
oliv3r: hibernate to nand or sd? :p which will die faster?
<oliv3r>
mnemoc: just speaking theoretical
<oliv3r>
we should document that rreconfiguring ram wipes memory
<mnemoc>
oliv3r: [[DRAMC]]
<oliv3r>
fine, i'll do it :p
<oliv3r>
i wrote a quick note
<oliv3r>
just so that 'something' is up in the wiki
<oliv3r>
i'll go work on the fex_guide some more
<oliv3r>
since I received oh so much feedback
<n01>
oliv3r, wiki on linux-sunxi?
<oliv3r>
n01: yes :)
<n01>
:) great
<RaYmAn>
hm
<oliv3r>
mnemoc: quick Q, why is '[target]' red and [card_burn_para] black on the wiki
<RaYmAn>
hipboi: so that means ram console never worked and never will work on a10?
<oliv3r>
(font color) I don't see why
<oliv3r>
RaYmAn: what's a ram console?
<oliv3r>
RaYmAn: and why does it need to reconfigure the ram?
<hipboi>
RaYmAn: ram console
<RaYmAn>
oliv3r: it's an android kernel feature. It basically logs all kernel messages to a special buffer in ram, that's usually kept across reboots.
<hipboi>
RaYmAn: what's that
<RaYmAn>
It's an invaluable tool to debug kernels on devices that lack UART :)
<RaYmAn>
iirc mainline kernel has a similar feature now as well
<mnemoc>
oliv3r: try <nowiki />
<RaYmAn>
it's accessed as /proc/last_kmsg
<oliv3r>
mnemoc: i think everything is <pre> atm, which shouldn't be a problem?
<oliv3r>
just one <pre> is rendered red, the others black and I don't see a difference
<mnemoc>
oliv3r: <pre> only affects font. <nowiki> saves you from getting the INI section considered a link
<oliv3r>
RaYmAn: oh that's fancy, and if reconfiguring the ram wipes it, then I doubt it can work I guess.
<mnemoc>
Turl submited the ramconsole thing for A10. not sure what use did he give it
<oliv3r>
mnemoc: i'm fine with either or, but it simply is not concistent, and I don't understand why :)
<mnemoc>
oliv3r: we don't want [card_burn_para] as a link
<oliv3r>
[target] isn't a link though (is it?!)
<oliv3r>
nope, [product] nor [target] are links or even clickable
<RaYmAn>
oliv3r: I guess my question was mostly "wth!? a10 wipes ram on re-init?" because it's rather uncommon for at least mainstream SoC's to do this.
<mnemoc>
oliv3r: weirdnesses of mediawiki's parser?
<n01>
back to my original doubt: we can re-init it just in SPL?
<mnemoc>
n01: the SPL does init it
<mnemoc>
n01: but the SPL can't read script.bin
<n01>
ok, let's say we want to retime DRAM
<mnemoc>
n01: it's limited to sram
<oliv3r>
mnemoc: must be
<mnemoc>
n01: adjust the board parameters in u-boot-sunxi and recompile
<mnemoc>
and dd the spl again
<mnemoc>
n01: but you could teach u-boot to rewrite the "header" of the spl and inject the new values, and reset
<mnemoc>
berryboot does hotpatching of the spl
<n01>
ok, I'll check the code then :)
<mnemoc>
beware you can "brick" it
<mnemoc>
if the spl can't init the dram with your value it will die
<n01>
yes, I know, tnx
<oliv3r>
anybody any clue what 'ndqs' could mean? It might be something relating to nand ddr clock signal, but im' guessing it's simply the nand clock signal? just what would ndqs mean
paulk-desktop has joined #linux-sunxi
<oliv3r>
a nother question. all fex files use Port C, pin 0 - 18 (and some) for the nand controller (mux 2!), however nand_spi is linked to PC23 on mux 3! PC23 mux 3 however is SPI_CS0?!
<oliv3r>
also, funny fact, there's a typo in the default fex file, ctp_screen_rotate is typo'd to cpt_screen_rotate. Every. Single. Fex copied that mistake and nbody has atleast correct it in their own version. (Havne't found could that does read either cpt OR ctp)
hipboi has quit [Quit: Leaving]
hipboi has joined #linux-sunxi
hramrach has quit [Remote host closed the connection]
hramrach has joined #linux-sunxi
<calris>
OK, question time...
hipboi_ has joined #linux-sunxi
<oliv3r>
calris: ask: )
hipboi has quit [Ping timeout: 264 seconds]
<calris>
Sorry, looking a U-Boot code... trying to figure out where sunxi_dram_init(void) is called from
<calris>
Is it in SPL build?
<calris>
Finally! Yes, it is SPL...
<calris>
So, getting back to my point from earlier today (a long time ago) there seems to be no way to configure SDRAM timings outside a rebuilt of the SPL
<calris>
Pity...
<n01>
:)
<calris>
Hmmm, but SPL can read the file system (to load U-Boot)
<calris>
Why not read an SDRAM config?
<calris>
It seems to me that boards are defined by dram_para and a string in checkboard()
<calris>
Why not move these to a tiny binary file on the file system?
<hipboi_>
because spl is too small
<hipboi_>
to add file system support
<hipboi_>
maybe it can
anunnaki has quit [Ping timeout: 248 seconds]
<calris>
How is U-Boot loaded?
shineworld has joined #linux-sunxi
<hipboi_>
read from mmc
<calris>
From FAT32 file system y SPL?
<calris>
s/y/by
<hipboi_>
fat32 support is possible for some spl
<hipboi_>
but on sunxi is a little big
<hipboi_>
so no fs support on sunxi spl
<hipboi_>
just read raw data
<calris>
Ah, I see
<calris>
Maybe reserve one SD page of raw data?
<calris>
How many bytes does BROM read for SPL?
<n01>
cannot dd also script.bin and read it raw by SPL?
<hipboi_>
calris: it depends on the header of the data, up to 20k
<hipboi_>
n01: yes, it's possible
<calris>
n01: yes, but not enough room in SPL to add processing code
<calris>
hipboi_: 20k is huge!
<n01>
ok, I see
<hipboi_>
calris: i think there is enough room for parsing script.bin code
anunnaki has joined #linux-sunxi
<calris>
hipboi_: surely we can fit FAT file system...
<hipboi_>
calris: yes, you can try to optimize the fs in uboot and build a spl with fat support and the size in 20k
<calris>
hipboi_: do you know where the SPL code to read U-Boot is?
<hipboi_>
yes.. in board.c
<calris>
hipboi_: all I see is code to select boot device
<hipboi_>
read the print from spl
<hipboi_>
and grep the code for the print
<calris>
I'm browsing on github :(
anunnaki has quit [Ping timeout: 258 seconds]
<calris>
Hmmm
<calris>
Time to drop SPL and add file system support :)
<calris>
s/drop/strip
<calris>
Stu
<calris>
Stupid auto-correct
<calris>
(And fat fingers)
plan_b has joined #linux-sunxi
<calris>
Can't find the copy code...giving up and going to bed
jochensp has quit [Read error: Operation timed out]
<libv>
ah, that seems like someones brainfart, will point him to that :)
<Dave77>
how many commands do I have to type to build a kernel?
<hipboi_>
who is the guy of mer on sunxi?
<mnemoc>
libv: please. I would like to see decent content there :)
<libv>
he threw me that link an hour ago, and then dropped off, i guess he went home to pick up some more clothes or something (a full 300m walk - it's good to live in the city), or they decided to discharge him
<zumbi>
libv: are you one of those guys reversing some gpu driver?
<libv>
anyway, this will be continued, he was doing build/packaging on mer for ages before, but never had any actual hw to play with
<libv>
zumbi: yes, mali
<zumbi>
ah.. nice
<zumbi>
I heard next allwinner chips are going to be based on mali chips
<zumbi>
going away from sgx nightmare
<hipboi_>
what next chip?
<libv>
zumbi: i am not sure why they chose sgx for the quad a9
<libv>
was arm asking too much money, and was img willing to throw too much money?
<libv>
because that thing is a maintenance nightmare
<hipboi_>
just being different from rock chip
ganbold__ has joined #linux-sunxi
<zumbi>
hipboi_: not sure...
<libv>
a20 will be hugely popular
<libv>
a10 x2.something is exactly what we need
<zumbi>
I was in china last weekend, saw the market flooded with A31s
<hipboi_>
really?
<oliv3r>
Libv do you know anything with regards to the fex 'lcd[0-1]' section?
<zumbi>
hipboi_: quad core a7
<hipboi_>
i just don't think a31 floods the market
<libv>
oliv3r: nope, only that it worked on my a7hd out of the box, grep the kernel for references for it
<oliv3r>
zumbi: so how do you know that A31+ (anything after A20, A31) won't be powerCRap) anymore?
<oliv3r>
libv just working on cleaning up the Fex_Guide on the wiki and there 's quite some parameters that mean nothing to me or don't know what they could mean
<oliv3r>
libv: I do hope A20 (and it's double breathren if designed the A40) will be hugely popular. I think the A10 (and most probably A20) are pretty decent SoC's for OSS guys
<hipboi_>
yes, the time of A10 will not happen again...
<hipboi_>
maybe this is the best chip of allwinner ever
<oliv3r>
hipboi_: you don't think A20 will be as popular as the A10 was?
<oliv3r>
hipboi_: why do you feel that way? Because you don't work there anymore :p (jk)
<hipboi_>
oliv3r: ...
<oliv3r>
i think one of the reasons its so popular (price aside) is it's linux support; while other socs (AMLogic) have some GPL support
<oliv3r>
none are as good as for the A10
<libv>
a10 was cheap
<hipboi_>
a10 is popular because at the right time and the right need
<hipboi_>
now popular because of all of you
<hipboi_>
the sunxi community
<libv>
hipboi_: and you :)
<hipboi_>
everyone here see it
<oliv3r>
hipboi_: the sunxi-community?
<hipboi_>
allwinner sold the second most arm chips in 2012
<hipboi_>
just after apple
<oliv3r>
well if it has anything to do with linux-sunxi; then hopefully they notice and remember that for the A20
<oliv3r>
though I think the recent code leak may be 'a way' from them to do that
<zumbi>
oliv3r: just people was saying..
hramrach has quit [Ping timeout: 276 seconds]
<zumbi>
oliv3r: I was with guy from armdevices.net
<oliv3r>
well I guess they _could_ use the adreno GPU, as that has comming support aswell :)
<oliv3r>
hipboi_: if they wanna o anything else for the sunxi community, code leak for cedarx
<libv>
oliv3r: adreno is owned by qualcomm
<zumbi>
oliv3r: I saw adreno got in mesa.. that's cool
<libv>
so it will have no other vendors
<zumbi>
oliv3r: but, well, rumour was about mali
<libv>
yeah, rob clark is a work animal
<libv>
i would've actually understood it if the a31 came with a vivante
<libv>
but pvr...
<zumbi>
FSL mx5x has adreno, someone needs to make it work there
<libv>
imgtec must've paid dearly for that one
<zumbi>
I am using vivante now
<libv>
zumbi: that deal was made before amd sold off the imageon
<zumbi>
yes
torqu3e has quit [Read error: Connection reset by peer]
<libv>
oliv3r: what do you need to know about this section anyway?
<oliv3r>
i was just cleaning it up, adding descriptions to things I could figure out (it was originally translated from chinese only)
<oliv3r>
libv: so just wanted to see if you knew anything to make it (more) complete/accurate
torqu3e has joined #linux-sunxi
<shineworld>
hipboi_, what is reference seller of allwinner in europe ? better, in Italy ?
<shineworld>
allwinner chips I mean
<hipboi_>
no reference sellers, i think
<shineworld>
only direct contact using allwinner homepage contacts ?
<hipboi_>
i think so
<theOzzieRat>
mnemoc, did you see I resubmitted the spi patch?
<shineworld>
I'm in prototype stage (in which cubieboard is optimal) but after that I need to choose if continue with Allwinner chips or move to freescale iMX6...
<hipboi_>
shineworld: what kind of product?
<shineworld>
HMI (Human Machine interface) pannels for industry using android and arm soc
<hipboi_>
android?
<shineworld>
yes
<shineworld>
a little bit modified
<hipboi_>
then i think no difference between the socs...
plan_b has quit [Quit: plan_b]
<shineworld>
depends by price and soc usability in industrial field (noise immunity, emissions...)
<shineworld>
and overall support of communities
<hipboi_>
i think price is not important for you
<shineworld>
I'm used with freescale and renesas chips but support is very limited
<shineworld>
could be an item in decision balance
<shineworld>
sometime price is very important for customer
<hipboi_>
then stick with allwinner
<shineworld>
I will do...
<hipboi_>
there will be cubieboard a20
<hipboi_>
cubie nuc - a31
<shineworld>
yeah, I know that is it pin to pin compatible
<shineworld>
cubie nuc is a today surprise for me
<shineworld>
never listen before
<hipboi_>
nuc, next unit computing
<shineworld>
when will be available I will try it surely
<shineworld>
my next step, after android OS, will be to run RTEMS os in cubieboard
christopher_ has joined #linux-sunxi
<shineworld>
a step at time....
<mnemoc>
theOzzieRat: yes. patch is good. thanks!
<theOzzieRat>
mnemoc, cool. just one more question, was patch 1/2 ok, or should I resubmit that as well?
<theOzzieRat>
ok, remember it needs Lorenzo Nava's patch first
<mnemoc>
hipboi_: will you consider an a20 nuc? also with *all* pins available? can you add one of the usb hosts also available on pins? to be able to pass usb to an extension board
<theOzzieRat>
I have 2 more patches ready that add interbyte delays and full duplex support, but am going to do a bit more testing before submitting.
<hipboi_>
a20 unc? hmm
<mnemoc>
if I haven't merged these 3 when you get the new stuff finished. please resubmit the whole serie (including lorenzos'
<mnemoc>
hipboi_: a20 has vga and sata, a31 doesn't
<hipboi_>
yes, we consider add vga for a31
<n01>
is linux-sunxi the only ml for submitting patches?
<libv>
vga is unbelievably important for demoing
<theOzzieRat>
mnemoc, I will probably wait until they get merged. I also have other things to work on.
<mnemoc>
also, the availability of usb on pins greatly incresases the capabilities on the extension board
<mnemoc>
theOzzieRat: ok
<libv>
as even if projectors have dvi/hdmi in, nobody wires those to where the speakers are
<mnemoc>
libv: this nuc thing is also VESA mount compatible, so it's awesome for thin clients
<mnemoc>
on cheap old LCDs
FergusL has joined #linux-sunxi
<libv>
mnemoc: nuc is what, networkable micro controller?
<mnemoc>
nuc is the brand name of intel's minipc
<libv>
ah, next unit of computing
<mnemoc>
yes, that thing
<libv>
hah, via was right, wasn't it :)
<hipboi_>
network micro controller...
<libv>
too bad that they messed it up, all the time :)
<hipboi_>
we have bought one
<hipboi_>
actually it's a good device
<mnemoc>
nah, micro controller is is something different. this thing is an small desktop computer
ganbold__ has quit [Remote host closed the connection]
ganbold__ has joined #linux-sunxi
<mnemoc>
but low power and extendable and hackable
<mnemoc>
sexy^3
<mnemoc>
hipboi_: on the "why A20" I forgot the mali vs. pvr "detail" and the impact that has in the linux desktop user
<hipboi_>
yeah, like the old time, manufacture provide the schematic and open source software
<oliv3r>
shineworld: just realize, that A31 support will be mmmediocre (well no GPU support, since its power VR :p)
<hipboi_>
oliv3r: shineworld uses android
<mnemoc>
at least it has g2d
<mnemoc>
brb
<mnemoc>
hope hipboi will manage to get us armhf drivers for the GPU and VPU of these new socs :)
<mnemoc>
and updates for A10/A13
<mnemoc>
:)
<libv>
mnemoc: we might get away with using the odroid crap
<oliv3r>
it'll still be crap
<oliv3r>
crap to stay away from ideally
<shineworld>
don't finish to support android ...
<oliv3r>
shineworld: A31 uses the PowerVR GPU. So 3D support wil be limited to binary blobs
<shineworld>
the CPU closed-source is always a big issue
<shineworld>
GPU
<shineworld>
but actually I don't need 3D features
<oliv3r>
well you are using android ;)
<oliv3r>
the A20 has mali core, and could have open source drivers at some point :)
<oliv3r>
(currently doesn't)
<shineworld>
yeah, I've found open-mali project on the net
<shineworld>
early - stage
<oliv3r>
shineworld: libv is the author of the lima (open-mali) driver :)
theOzzieRat is now known as OzzieRatZzzz
<shineworld>
wow, happy to know
<libv>
arm was unhappy with us using remali as a name, one lawyer thought there might be the possibility of a trademark problem there
<libv>
libremali was just too nice not to do it
<shineworld>
call it liberas-nos-a-mali
<oliv3r>
I like lima though :)
<libv>
lima gets us all sorts of peruvian perverts in the irc channel, but apart from that it is quite catchy
<oliv3r>
it is
hramrach has joined #linux-sunxi
Dave77 has quit []
hipboi_ has quit [Quit: Leaving]
ZaEarl has joined #linux-sunxi
<mnemoc>
OzzieRatZzzz: can you send a patch to enable spi on defconfigs?
egbert_ is now known as egbert
_jm has joined #linux-sunxi
<_jm>
I would like to contribute script.bin and meminfo for mele A100 if you're interested.
<oliv3r>
_jm: looks identaical except for the ram settings (which makes sense, you should diff it against an A1000/A2000 (not the g, as that has 2 gig)
<oliv3r>
but you left
<mnemoc>
the 'g' has 1G, vs. 512MB of the traditional
<mnemoc>
there are no 2GB A10 devices
<oliv3r>
sorry, typo :p
<oliv3r>
2x the ram; 1 gig -> 2gig!
<mnemoc>
:)
<oliv3r>
i think i messed up our 'recently changed' page list :p
<oliv3r>
lots on my name :p
<oliv3r>
luckly i did some changes under 'small change'
<mnemoc>
tons of blobs, some .rar files and named .tar
<wingrime>
techn_: I ask Quarx test it
<mnemoc>
interestingly the ip is based in zhuhai
Vijay has joined #linux-sunxi
<mnemoc>
just like aw itself
<Vijay>
Hello All!
<Vijay>
Hope everyone is doing good. I have a query about Redhat Linux 6!
<Vijay>
Could anyone of you would be able to suggest me some solutions for it?
n01 has quit [Ping timeout: 255 seconds]
zenitraM has joined #linux-sunxi
<wingrime>
Vijay: you can port our kernel to Redhat basis?
<mnemoc>
i suppose he can just use hansg's packages for fedora
<hramrach>
hello
<hramrach>
wingrime: how do you wake up from cpu_do_idle()
<wingrime>
uart with console_no_suspend
<hramrach>
Vijay: we have nice Fedira images for A10. I bet it is not RH officially supported platform so running RH on it is pointless. For other platforms there are other channels
<Vijay>
It's RHEL 6.4.
<wingrime>
you must configure any supporting interrupt
<hramrach>
only uart?
<wingrime>
any device that have interpurt and non sleep
<wingrime>
suspend image, do this stuff
<hramrach>
or tell the device not to suspend
<wingrime>
suspend image by aw save some devices registers , configure it to int mode , than enable it to IRQ controller
<hramrach>
ok so my guess is that to enable wakeup from cpu_do_idle some devices that are supposed to be used to wake up the cpu should be told to not suspend when the PM state is standby (as opposed mem)
<hramrach>
uart has code for not suspending when no_console_suspend is enabled
<wingrime>
not sure
<wingrime>
it simply use interpurt
<wingrime>
and whan we not to suspend it simply accepts it
<hramrach>
chinese :<
<wingrime>
hramrach: you realy understand what means "IRQ" or "interrupt"?
<techn_>
Laws in other nations obviously differ as well. For example, A 17-year-old youth was convicted in Finland of attempted computer intrusion for simply port scanning a bank. He was fined to cover the target's investigation expenses. The Moulton ruling might have differed if the VC3 machine had actually crashed and they were able to justify the $5,000 damage figure required by the act.
<wingrime>
techn__: very often some worms do it itself without human on pc
<wingrime>
techn__: than IPs connected to Internet directly and have everyday scanning
<wingrime>
techn__: if you simply leave ssh connected to internet you will see everyday activity from china try brureforce it
<wingrime>
techn__: so don't care ))
<techn_>
yeah.. that case is 15 years old.. nowadays there is more bigger security conserns
<wingrime>
it looks like it buisness center network
<oliv3r>
i see so many break in attempts every day on my IP
<oliv3r>
http, ssh etc
<oliv3r>
Warning: you may need to install module-init-tools
<techn_>
ok.. its different on that android target
<techn_>
you'll need that boot.scr.. create boot.cmd file with correct android settings
<mnemoc>
boot.scr is totally optional
<mnemoc>
and using uEnv.txt is (by far) a better option anyway
<techn_>
mnemoc: even if android is used? android has rootfs in different partition?
<mnemoc>
uhm. ok. android :<
<techn_>
oliv3r: fixing that android stuff is on my todo list ;)
<mnemoc>
techn_: imo we should fork android_device_allwinner_common and make it a shared device/allwinner, and then automatically create a $board subdir with a template using common/
shineworld has joined #linux-sunxi
<Turl>
mnemoc: does stage have that patch too?
<mnemoc>
Turl: yes
<techn_>
mnemoc: On my todo list is to make working a13 android image
<calris_>
Great - So we have 16.3kB .text (code) + 2.2kB .rodata (Read-Only Data) + 356 Bytes .data (initialised read-write data) + 1.3kB .bss (zero'd read-write data)
ZaEarl has joined #linux-sunxi
<calris_>
printf() is ~1.5kB
<calris_>
If you want to get really aggressive and remove all serial output in SPL, you would shave of at least 2k (plus the read-only text strings on top of that)
<calris_>
Can you upload u-boot.map - I want to see how big FAT is
<calris_>
I don't see why it needs mmc_berase() - 388 Bytes
<Turl>
<4>[ 14.280000] MALI PHYSICAL RANGE VALIDATION ERROR: The range supplied was: phys_base=0x49001000, size=0x00600000
<Turl>
<4>[ 14.300000]
<Turl>
any ideas of a recent change that might've caused it?
<mnemoc>
e836a5c5ee5b9686c51005f9066aa5a26455ec23 is the only directly related
<mnemoc>
Turl: look at the range of commits from hansg dated 2013-02-09
<mnemoc>
those played with mem reservations
<mnemoc>
Turl: but as your tree was already pretty old maybe trying an older tag is a good idea
<mnemoc>
like sunxi-v3.0.57-r1
<calris_>
mnemoc: Feel up to shredding SPL and adding ext4 (which covers ext2, ext3 and ext4) support?
<mnemoc>
calris_: u-boot-sunxi is hno's realm. I prefer to not step in there :)
<mnemoc>
but considering we will need (eventually) to read the .dts too it's an step that must be taken
<calris_>
mnemoc: I don't blame you - I spent four years hacking U-Boot :)
<mnemoc>
:)
<calris_>
I can't see .dts processing fitting into SPL
<calris_>
Even ext4 is going to be a major squeeze
<Turl>
fa096c492c191699a95275bc2a914d4bfe0f047a looks like a possibly first bad
<Turl>
let's see
<mnemoc>
in the same way you want the spl to read dram initialization parameters from the .bin, future u-boot for sunxi will need to do the same from dts
<calris_>
Adding ext4 to SPL will enable the creation of a generic u-boot.bin and u-boot-spl.bin with all board specific parameters in files in /boot which can be edited in Linux