<Turl>
make sure you didn't dd the same thing twice
<xxiao>
it's still in the console where dd was run, let me try a pre-built combination, might be a toolchain issue
<xxiao>
i just used imx6 toolchain i had here
<hno>
it's possible sun4i is broken at the moment.
<hno>
you can try the sun4i branch.
RITRedbeard has quit [Read error: Connection reset by peer]
RITRedbeard has joined #arm-netbook
<akaizen>
any thoughts on openembedded or linaro? wondering if i should just use android since a lot of the base is ready and an app will be transferable to tablets
ZaEarl has quit [Ping timeout: 260 seconds]
Quarx has joined #arm-netbook
sspiff has quit [Remote host closed the connection]
pawel5870 has joined #arm-netbook
rellla has joined #arm-netbook
popolon has joined #arm-netbook
grevaillot has joined #arm-netbook
mysteryname has joined #arm-netbook
plan_b has joined #arm-netbook
sspiff has joined #arm-netbook
sspiff has joined #arm-netbook
sspiff has quit [Changing host]
<oliv3r>
The A10 has 32KiB ROM which contains some form of bootloader. I don't know if it could be called a 'bootloader' all it does is check various sources if they are bootable and boots them. I assume this bit is integrated into the A10 and can't be replaced? E.g. a true rom?
<lundman>
fel?
<mnemoc>
fel is the low level usb recovery app
<mnemoc>
you can "call" it
<lundman>
Tyrone?
<mnemoc>
:)
jlj has joined #arm-netbook
<mnemoc>
the BROM can't be replaced, but can be dumped
<mnemoc>
hno has some tools that parse it in sunxi-tools
tzafrir_laptop has quit [Ping timeout: 252 seconds]
<oliv3r>
ah! so the BROM is BOOTROM
<oliv3r>
now BROM makes sense :) I saw its reference int he register page
<oliv3r>
can I easily rename a wikipage? or is delete/re-create a better option?
<mnemoc>
oliv3r: tell me which and I can do it for you
<oliv3r>
but since this should in theory only relate to the A10 series, A10 makes the most sense atm
<oliv3r>
that is, A10/BROM
<rz2k>
hm, one chinese guy that I've mailed about imx6 said that NDA goes off (documentation & ref. designis will be available) at 15 october, is that right? steev?
<mnemoc>
as it's shared among all sunxi socs I would just leave it as a common BROM for now
<oliv3r>
you say this based on its content?
<mnemoc>
imo the diffs between A13's BROM and A10's BROM should be documented in the same document to avoid duplication
<oliv3r>
true, but atm we only have the A10 manual :)
<oliv3r>
is the BROM overwriteable at all? I would assume not so.
<mnemoc>
it wouldn't be ROM :)
<oliv3r>
well Flash-ROM isn't ROM is it!
<oliv3r>
how accurate is the a10 register guide at rhombus-tech?
<oliv3r>
they mention a CSDM (CoreSight Debug Module) at 0x3f50000 that isn't mentioned in the original document. It does have part of that region 'reserved' however
<mnemoc>
oliv3r: hno maintains it based on source code
<oliv3r>
Well source should trump datasheet :)
<mnemoc>
yup
<oliv3r>
same goes for GPS, GPS isn't listed in the datasheet either
<oliv3r>
i'll try to incorporate the rhombus-tech missing registers into the linux-sunx wiki one then
<mnemoc>
thank you
<oliv3r>
hopefully we have 1 reasonable accurate one then
<oliv3r>
and can redirect one to the other :)
<rz2k>
afaik csdm is undetachable part of Cortex-Ax core, needed for jtag tracing.
<mnemoc>
RT's wiki has the advantage of having a git backend, so hno can work on it when offline
<RaYmAn>
rz2k: it's definitely there, the question is whether it's at 0x3f50000 or not :>
<rz2k>
would be cool if guys like chipworks.com or ubmtechinsights.com look inside A10 :3
<oliv3r>
I thought a few days ago, the talk was about having the A10 specific stuff on the linux-sunxi wiki, as the RT wiki isn't really the place for this info ;) But that is a political issue that I won't get into :p
<oliv3r>
so I'll get to work :)
<mnemoc>
oliv3r: it's not really a political issue, RT goes is about the modules and mass produced devices using them
<mnemoc>
oliv3r: the a10 variant of the eoma68 is merely the first intended product
<mnemoc>
s/goes/goal/
<Turl>
mnemoc: I'l about to do a kernel build, any interesting patches you need tested? I'm gonna run it on my mele
<Turl>
I'm*
<mnemoc>
Turl: not really. sunxi-v3.0.42-r1 was just tagged. hopefully next will be .44 based
* hno
haven't had time to work much on the register guide.
<oliv3r>
I just try to work in as much as I can into 1 document, not sure about many things
gzamboni has joined #arm-netbook
<oliv3r>
hno, do you know from the top of your head the register size of the GPS? Is it safe to assume 1KiB? or os it more
<mnemoc>
oliv3r: to know about the gps you would need to RE the gpl-violating gps.ko_ in the 2.6.36 tree
<hno>
There is a ko?
<mnemoc>
yes
<Turl>
does GPS work?
<Turl>
I haven't seen a single A1X product with GPS
<hno>
no one knows.
<mnemoc>
i saw some GPS devices for cars with A10 inside, and tom was working on one that went into production last week
<oliv3r>
Well the GPS, according to the UBOOT source is between two 'reserved' regions, so I don't know the size. I just took a leap and guessed hno knew :)
<mnemoc>
lundman: btw, other 2 commits went on top of yours
<Turl>
that's iperf over GbE router
<Turl>
heh even mele->wifi'd laptop it pretty much maxes out too :)
<oliv3r>
Just throwing it out here (before commiting and let someone else sort it out :p) cpu.h in u-boot says, that the CPU Configuration starts after about 316Bytes in the timer register. Is it safe to assume, the timer register actually consists of both, with the split there? Or are is there some unidentified region in the timer, that has a few bytes for the CPU Configuration?/
<lundman>
on top?
<lundman>
mnemoc: thanks for doing the commits
<oliv3r>
hmm, platform.h defines the BROM twice, BROM_BASE and BROM_START :)
plan_b has joined #arm-netbook
<mnemoc>
lundman: i mean, after, and over the same files
<mnemoc>
oliv3r: happens a lot
<mnemoc>
oliv3r: if documenting the BROM you should really look at the bootinfo tool on sunxi-tools
<mnemoc>
oliv3r: if something is unclear, document it as such. don't take assumptions as facts
<mnemoc>
funny, he claims mksunxiboot is used to compile .fex files
rvalles has joined #arm-netbook
mSquare has quit [Read error: Connection reset by peer]
<mnemoc>
i remember that gnexus guy came one day to announce "the a10 forum" and left
<lundman>
:)
Almamuetya has joined #arm-netbook
mSquare has joined #arm-netbook
hp__ has joined #arm-netbook
von_fritz has joined #arm-netbook
pwhalen has quit [Ping timeout: 248 seconds]
<mysteryname>
Everyone here is probably very aware of this, but the mele A200 v1.7 does not play nice with most of the developments of linux. I've been reading that version 1.3 is much easier to boot Linux on.
<mnemoc>
i didn't know there was a mele a200 at all
<mysteryname>
A2000 sorry
<mnemoc>
ok
jquip has joined #arm-netbook
TomNL has joined #arm-netbook
<TomNL>
lundman: can i send xbmc 1080?
gzamboni has quit [Ping timeout: 240 seconds]
gzamboni has joined #arm-netbook
<lundman>
i dont know, can you?
<lundman>
you may though :)
* lundman
ducks
<lundman>
what is yourpreference? ftp, dcc, url, fsp, drop,
<hno>
mysteryname, hope to have that sorted out shortly.
<mnemoc>
hno: hi, about fb allocation you mean something like: http://sprunge.us/QPRa?diff ? (refactoring required)
gzamboni has quit [Ping timeout: 240 seconds]
<TomNL>
lundman i will drop it to filetea and send you the link in a minute
gzamboni has joined #arm-netbook
<hno>
mnemoc, something like that, except that FB_RESERVE should be set in Kconfig, and forced if MALI is enabled.
<mnemoc>
ok
<mnemoc>
better
<hno>
who asked about GPS? The module is compiled with debug info...
alcides has joined #arm-netbook
<oliv3r>
o/
<oliv3r>
well I asked about register size
<mnemoc>
asked who? :)
<mnemoc>
err
<mnemoc>
missed hno's line
<oliv3r>
lol
<mnemoc>
sorry :<
<oliv3r>
I'm reading ccmu_regs.h and notice some ppl's have tuning settings and some do not. (Just like the datasheet says) I know absolutly nothing about PLL's, but why is that?
<oliv3r>
For example, PLL6_SATA has no tuning information?
<lundman>
thank you
arokux has quit [Remote host closed the connection]
arokux has joined #arm-netbook
<lundman>
if it has debug, RE is too easy,no fun
<hno>
No difinitions for register names.
<oliv3r>
is this GPS unit built into the A10 SoC?
<hno>
Yes, but no information on how to use it or even what is required in hardware to uu
<oliv3r>
ah, so some external hardware is required
<hno>
yes
<oliv3r>
and none of the A10 devices in the wild (Mele etc) use the GPS?
<hno>
maybe some tablet. Don't know.
rvalles has quit [Read error: Connection reset by peer]
<oliv3r>
aww :(
<hno>
and they removed GPS in A13.
<oliv3r>
is A13 actually a different die? Or is it the same die, with things disabled?
rvalles has joined #arm-netbook
<TomNL>
lundman: i wonder if it will work on 1080p
<hno>
oliv3r it's different.
<hno>
similar, but different.
pwhalen has joined #arm-netbook
RITRedbeard has quit [Read error: Connection reset by peer]
oliv3r has quit [Ping timeout: 240 seconds]
RITRedbeard has joined #arm-netbook
<mysteryname>
hno: That's good news :D I've been bashing my head against the wall since I got one. I'm new to all of this.
<mnemoc>
so you bought alpha 12 cubieboard without knowing the plat?
<mnemoc>
12 alpha cubieboard*
jquip has quit [Ping timeout: 246 seconds]
plan_b_ has joined #arm-netbook
plan_b_ has quit [Client Quit]
oliv3r has joined #arm-netbook
<hno>
mnemoc, got i2c working in u-boot.
<oliv3r>
hmm, got reconnected there; hope didn't miss anything :)
<hno>
not much.
<oliv3r>
Right, if any body is bored and could just do a quick proof check if I missed something really obvious: http://linux-sunxi.org/A10/CCM
Quarx has quit []
<mnemoc>
hno: great! so now talking to the PMU should be simple, right?
<mysteryname>
mnemoc: Yes however I knew they would work as media centers, which I have passed onto friends. I have two, one for a media center and another for linux.
<oliv3r>
-sunxi/clock.h#L80 reads in the comment /* 0x34 PLL5 tuning2*/; shouldn't that read /* 0x38 PLL1 tuning2 */?
<oliv3r>
alsoif that is so, line 80 and 81 would also need to be swapped
Almamuetya2 has joined #arm-netbook
Almamuetya has quit [Ping timeout: 248 seconds]
sspiff has quit [Remote host closed the connection]
Quarx has joined #arm-netbook
ZaEarl has joined #arm-netbook
revident has joined #arm-netbook
plan_b has quit [Quit: Verlassend]
TomNL has quit [Quit: Think your current client is sexy? Check out Bersirc 2.2! [ http://www.bersirc.org/ - Open Source IRC ]]
<cat_x301>
mnemoc: i have just noticed that my patches for parsing command line are worthless :( but the good thing is that i am about to give them another kick :) but before would like to understand whether we care of default, hardcoded values for fbmem and g2dmem or not? if yes, the logic must be changed, otherwise the assumption is that these two are always provided via command line, if not -- no reservations.
Almamuetya2 has quit [Quit: Nettalk6 - www.ntalk.de]
<mnemoc>
cat_x301: mali has hardcoded size and address for itself and for fb. not sure if also for g2d
<mnemoc>
also not sure how cedarx deals with that
<cat_x301>
mnemoc: which would imply that we care? or the whole patchset is pointless.
<mnemoc>
i think that before doing the command line argument thing we should refactor the drivers to accept memory reserves as resources for the platform_device
plan_b has joined #arm-netbook
<mnemoc>
cat_x301: sure we care
<cat_x301>
mnemoc: platform_device would mean strict dependance
<cat_x301>
on platform
<mnemoc>
and should not?
<cat_x301>
mnemoc: dunno. will be there any sunXi which allows different settings across one platform?
<cat_x301>
s/across/for
<mnemoc>
i assume so
<mnemoc>
i just hate those reserve_*() and the foostart foosize exports
<mnemoc>
how to change their size from cmdline is another story
<mnemoc>
but suppose we can make the memory resources in platform_device command line driven too
<cat_x301>
mnemoc: what about having some Kconfig entry for definig these reservations?
<mnemoc>
doing it build-time-only is ugly
<cat_x301>
mnemoc: dt? :)
<mnemoc>
not before the end of the world :|
<cat_x301>
:D
<mnemoc>
I mean, dec.
<cat_x301>
mnemoc: so they did not cancel it this time.. well..
<cat_x301>
did anybody start to implement platform_devices?
<mnemoc>
not that i know
<cat_x301>
and my guess is that it should fall under arch/arm/plat-sunxi/
<mnemoc>
which itself will fall under "deprecated" since 3.7 :|
<mnemoc>
upgrade wants drivers (even if built-in-only), not plat/
<mnemoc>
s/upgrade/upstream/
<ibot>
mnemoc meant: upstream wants drivers (even if built-in-only), not plat/
<cat_x301>
so with 3.7 we go.
mSquare has left #arm-netbook [#arm-netbook]
<mnemoc>
the drivers approach will work in 3.0 too
<mnemoc>
I only mean it's future-proof
<cat_x301>
mnemoc: let me see what i can cook out of it.
<mnemoc>
btw, sent a little patch for fb mem reserve to the ML
<cat_x301>
mnemoc: what patch
<mnemoc>
but right now i need to finish some credit card processing stuff
<cat_x301>
mnemoc: i understood that we need completely different patchset now :)
<cat_x301>
mnemoc: shall it be based on those patches i've sent or new one? sorry for being annoying though..
<mnemoc>
i believe we need some refactoring first, so new set.
<mnemoc>
after understanding how the involved drivers deal with their mem
<mnemoc>
mali has platform_devices in... iirc 3 parts
<mnemoc>
fb, ve and g2d would need their own too
<mnemoc>
and mali's unified.
<mnemoc>
.oO( die memblock_reserve die! )o
<cat_x301>
mnemoc: ok, the plan: 1) i will discard patchset i've made; 2) will add fbmem command line parser to the code where relevant platform_device is declared.
<cat_x301>
it this is ok, will proceed with g2d and ve.
<mnemoc>
if i understood hno correctly undef'ing FB_RESERVED_MEM we don't need fbmem
<mnemoc>
fbsize*
<cat_x301>
mnemoc: what about fbstart?
<cat_x301>
ah, same
<mnemoc>
and that tiny patch on the ML does that
<mnemoc>
fbstart only matters to mali
* cat_x301
is reading discussion again..
<cat_x301>
conclusion: FB_RESERVED_MEM is not set, no memblock_reserve for fb, fbsize affects only non-mali config -- needs to be defined with fb platform_device + command line, fbstart affects mali config -- needs to be defined with mali platform_device + command line. do i miss something?
RITRedbeard has quit [Ping timeout: 246 seconds]
<mnemoc>
cat_x301: i can't follow you at hte moment :< ... but sound right... i guess
itamarjp has joined #arm-netbook
itamarjp has quit [Changing host]
itamarjp has joined #arm-netbook
* cat_x301
shuts up for a while..
gzamboni has quit [Ping timeout: 256 seconds]
gzamboni has joined #arm-netbook
<steev>
rz2k: i don't know - i'm covered under one that is more general
<plan_b>
is there a kernel that supports g_ether (usb gadget)
Quarx has quit [Ping timeout: 240 seconds]
plan_b has quit [Remote host closed the connection]
Quarx has joined #arm-netbook
RITRedbeard has joined #arm-netbook
RITRedbeard has quit [Read error: Connection reset by peer]
RITRedbeard has joined #arm-netbook
Undertasker has joined #arm-netbook
<Undertasker>
Hi. Does anybody know how to tweak the A10 HDMI output to VGA resolutions (like 1024x768)?
<Undertasker>
And RGB, if possible?
pwhalen has quit [Ping timeout: 260 seconds]
pawel5870 has quit [Remote host closed the connection]
<Undertasker>
Thought so, the valid resolutions are hardcoded in the driver. There's a table of resolutions, with corresponding parameters. But what are the right parameters for those resolutions?
pwhalen has quit [Client Quit]
gimli has joined #arm-netbook
plan_b has joined #arm-netbook
<rm>
rz2k, I'm afraid even the disp module isn't in charge here
<rm>
because you know that resolution table is originally from FEX/BINs
Quarx has quit []
<mnemoc>
the sys_config only tells the initial mode, and it has to be one of the blessed list
<mnemoc>
later you can change it using the tool rz2k pointed, which sends ioctl()s
<hno>
ther hardware supports pretty much any resolutions. But not sure on what colorspace outputs are available for HDMI
<hno>
have not seen any settings for that at all.
<techn_>
hno: do you know if vga's edid/dcc pin is connected?
<hno>
on what?
<techn_>
to A10
<hno>
A10 is a chip
<techn_>
.. is it even possiple that we can ged edid info from vga?
<hno>
what device are we talking about=
<mnemoc>
i do remember to have seen color type related code in the driver
<hno>
HDMI have an I2C but for EDID etc. Usually connected. Even CEC which is also usually connected but lacks driver.
<techn_>
hno: I'm asking about vga.. on mele or other boards which has vga
<techn_>
mnemoc: yes there is multiple color spaces possiple.. that disp branch has bt.709 colorspace implementation.. but it's broken, problem was that green screen :p
<hno>
I am not 100% sure what pins are connected in the mele VGA port.
<hno>
Olinuxino A10 do not have VGA EDID connected in it's currently published schematics.
<techn_>
hno: thanks.. so we cant get perfect solution for VGA :(
<hno>
I don't think it's too late to convince Olimiex to connect the VGA EDID to one of the i2c controllers.
<mnemoc>
+1
<mnemoc>
what about tom's?
<hno>
no idea.
<hno>
have not seen any schematics for the VGA addon board.
<mnemoc>
but is the edid pin available in the headers?
<hno>
There is no VGA specific EDID pin. But it's just an I2C channel.
<hno>
The HDMI controller have a dedicated EDID I2C controller, separate from the TWI controllers.
<techn_>
btw. What I noticed from other display drivers.. they are using gpio pins to emulate i2c for edid interface :/
<hno>
that would work as well.
<techn_>
i2c-algo-bit.h
<rz2k>
bitbanging i2c when we have actual i2c is sort of, wrong.
<techn_>
rz2k: yep.. It's weird that no-one uses real i2c with EDID
<techn_>
rz2k: Btw. I'm waiting new mali libs from Tom
<mnemoc>
that won't happen until people at allwinner returns from holidays, monday
<rz2k>
yeah there is chinese holiday going right now
<techn_>
I LD_PRELOAD'ed libdri2.. and missing symbol problem wen't away.. And I got es2gears running without picture :p
<rz2k>
I have es2gears without picture too
<rz2k>
es2tri crashes, es2_info crashes with memory corruption
<techn_>
other problems that I faced was that glGetString(GL_VERSION) returned NULL on SW which came with ubuntu..
<techn_>
But when I made my own test SW it worked
von_fritz has quit [Quit: vonfritz leaves, don't panic]
<cat_x301>
mnemoc: i am doing platfrom driver for fb and have some doubts what to do about this lcd<-->disp dependency, when lcd can also call __s32 Fb_Init(). We need to sort it out somehow.. wondeer why such dependency exists after all. The problem is that I am planning to turn Fb_init into fb_probe but this dependency drives me crazy.
<mnemoc>
cat_x301: techn_ is the expert there
<cat_x301>
techn_: ? :)
<techn_>
cat_x301: It drives me cracy too :D
<cat_x301>
techn_: any proposal?
<techn_>
Without clearing those dependencies whole disp modifying is pain
<cat_x301>
techn_: ok, will try to come up with something anyway.
<techn_>
I was thinking to make disp depend on {hdmi,lcd} .. currently dependency chain is disp<->lcd<-hdmi<->disp
<techn_>
or something like that
<techn_>
But sure.. I'm happy to help if you start doing that.. I havent had time yet :(
rellla has joined #arm-netbook
<cat_x301>
techn_: good. hope will produce some patches for analysis :)
<mnemoc>
cat_x301: please try to minimize the diff
<cat_x301>
mnemoc: oh, another challenge, but accepted :)
<techn_>
mnemoc: What I'm thinking it wont be minor diff :D
<cat_x301>
techn_: of course i can keep it as it is, by calling this same function from probe and focus on just providing platform_driver.
<mnemoc>
sure it won't be minor.... but hopefully won't imply touching every single line
<mnemoc>
or it will be impossible to review
<cat_x301>
mnemoc: actually i already decided -- i will not change things dramatically this time. just small additions to eliminate the need in fb_* externs
<techn_>
.. it includes removing those loops, which needs new c-file for simulating two heads in one framebuffer.. couple interfaces to remove those depencies..
<mnemoc>
:)
Undertasker has left #arm-netbook [#arm-netbook]
plan_b has quit [Quit: plan_b]
pwhalen has joined #arm-netbook
itamarjp has quit [Ping timeout: 260 seconds]
<cat_x301>
techn_: to get rid of such dep i think we need to init disp driver early, let say with core_initcall(), thus making it non-module. It would be easiest way. Otherwise some complexity is unavoidable.
<techn_>
or get rid of lcd/hdmi
<techn_>
in theory disp can be loaded without lcd or hdmi.. vga and tv interfaces
<mnemoc>
i actually see them as sunxi-disp <- {sunxi-lcd, sunxi-hdmi}
<techn_>
mnemoc: how? :)
<mnemoc>
disp providing the infrastructure and shared code
<techn_>
oh.. you are referring current initialization code
<mnemoc>
and then lcd and hdmi taking a head from it
<cat_x301>
mnemoc: how it is different from what i was sying?
<cat_x301>
s/saying/suggesting
<mnemoc>
i don't know, I'm still fighting the credit card processing code :|
<techn_>
I'm referring on fex file.. what are the possibities :)
<cat_x301>
mnemoc: ah, this is even more tricky, more dependencies :)
* cat_x301
joking on credit card
<mnemoc>
:)
<cat_x301>
techn_: to me it sounds like there are not that many: as mnemoc pointed out disp driver just provides necessary infrasctructure -- so it looks 100 percent as core driver.
<techn_>
I'm thinking possibility to use disp without lcd or hdmi
<cat_x301>
techn_: hmm..
<techn_>
but sure.. it can be thought like that.. core just provides vga and tv.. hdmi and lcd are just extensions
<mnemoc>
disp can load and live alone... but won't do anything
<mnemoc>
if that's the case vga and tv should probably be refactored out
<cat_x301>
techn_: what if we split disp into smaller chunks making it looking as real core. eg.
<mnemoc>
to be consistent
<mnemoc>
+1
<cat_x301>
mnemoc: you just said my words :)
<mnemoc>
i was faster :)
<cat_x301>
mnemoc: ;)
<techn_>
so if it's done so that disp is core.. who reads fex file? is it done on every heads probe function?
<mnemoc>
that's where platform_device plays it's role
<techn_>
or is core loading wanted heads?
<techn_>
yep
<cat_x301>
techn_: are you talking about this call parser_disp_init_para?
<techn_>
cat_x301: yes
<cat_x301>
techn_: ok. i think that mnemoc is right, it should go to platform init
<techn_>
ok.. now I understand more.. core reads fex file on startup and loads needed modules for heads.. and when everything is implemented corrertly user can remove/add heads by unloading/loading modules
<mnemoc>
also easier to migrate to DT in future
Undertasker has joined #arm-netbook
Undertasker has left #arm-netbook [#arm-netbook]
<cat_x301>
techn_: not really loads modules as such, but rather has info already before modules are loaded by user.
<cat_x301>
techn_: and modules loading order can be random after that
marmottus has left #arm-netbook ["And just like that, he's gone."]
<techn_>
cat_x301: not before hdmi->lcd dependecy is removed
<techn_>
:)
<techn_>
It's not direct dependency.. disp just expects that lcd is loaded before hdmi.. check "__s32 Fb_Init(__u32 from)"
<techn_>
and first if
<mnemoc>
forget about hdmi in the first iteration
<cat_x301>
techn_: oops, very true!
<mnemoc>
and make lcd use platform_device
<mnemoc>
once that works, make hdmi do the same
<mnemoc>
Fb_Init() needs to die
<techn_>
+1 :)
<techn_>
or reformated so that it initializes only wanted fb
<mnemoc>
yes, right.
rellla has quit [Quit: rellla]
<techn_>
btw.. there is situation where is only one fb and two heads
<techn_>
but it propably should work first in one fb and one head mode.. But dunno if de_bsp supports switching from that mode to two heads :/
<mnemoc>
right
revident has quit [Quit: Combustible lemons? Bah, I bring you weaponized asparagus!]
gimli has quit [Quit: Verlassend]
tzafrir_laptop has quit [Ping timeout: 245 seconds]
<akaizen>
Wheres the latest repo / bugtracker you guys are working from?
zewelor has left #arm-netbook ["-!- May the force be with You -!-"]
<WarheadsSE>
github
<akaizen>
which repo, there amery, hno, etc..
<akaizen>
Or are each of them working on separate parts
<mnemoc>
separate parts
<mnemoc>
hno hosts the info and u-boot repos, while I host the tools and kernel
<akaizen>
mnemoc: So I cleaned up some of the wikis, havent added them yet... which wiki is 'officail' now?
<akaizen>
official**
<mnemoc>
afaik there is no official wiki from allwinner
<akaizen>
Who cares about allwinner ;) I'm talking about official for the community
<akaizen>
Is it the linux-sunxi.org
<mnemoc>
that's my personal preference at least
<akaizen>
Works for me ;)
<mnemoc>
:)
<akaizen>
My notebook is broken and in the middle of moving so no time :(
<akaizen>
I gotta be at a desktop to get anything done
skorket has quit [Quit: Leaving]
<akaizen>
mnemoc: Any benefits to rebasing kernel-allwinner with 3.7?
<mnemoc>
no
<lundman>
we dont have a JB version yet?
tzafrir_laptop has joined #arm-netbook
<mnemoc>
lundman: Quarkx and Turl have
<lundman>
i should look at thaty for the audio work