<mnemoc>
look at the source of the tool to repartition
<mnemoc>
we will need to act differently is the version of the partition table is 0x10 instead of 0x9
<lundman>
0x10 is the nand source version.
<lundman>
so my guess is they moved the mbr to some other block
<mnemoc>
lovely
<mnemoc>
hunt it down :)
<mnemoc>
once the tool can read the new partition table, we can adapt the kernel driver to support both
<lundman>
why cant they just share the updated version
<mnemoc>
try
<lundman>
ok, none of my source tree has a newer version of NAND_VERSION_1
<lundman>
I'd better go take a look at the mbr
<lundman>
well, its not from nanda
<mnemoc>
?
<lundman>
just wondering where this mbr is stored
<mnemoc>
/dev/nand
<mnemoc>
before nanda
<lundman>
no such device
<mnemoc>
in our kernel it does
<mnemoc>
it was added to be able to repartition from linux
<lundman>
in miniand with nand, but no raw device
<mnemoc>
no idea what kernel "miniand" uses
<mnemoc>
going to sleep now
<mnemoc>
good night
<lundman>
3.0.36+ at the moment
<mnemoc>
no idea. i've never seen anyone from that company asking or collaborating with us. no idea what's source they use, what changes they do or what troubles they have
<mnemoc>
now good night for real
<lundman>
not even android boot gives a "nand" device
<Turl>
"nand" is a kernel thing
<Turl>
you need the lastestestest sunxi-3.0
<lundman>
i might have that, but since I can't boot it, it gets awkward :)
<Turl>
and on android it'd usually be /dev/*block*/nand
<lundman>
yes, and it has no top-level
itamar_ has joined #arm-netbook
<lundman>
ah yes, I see.. i need the newer kernel
merbzt has quit [Ping timeout: 252 seconds]
cheng has joined #arm-netbook
tzafrir_laptop has quit [Ping timeout: 260 seconds]
mSquare has joined #arm-netbook
tekzilla has quit [Ping timeout: 260 seconds]
tekzilla has joined #arm-netbook
tzafrir_laptop has joined #arm-netbook
cheng has quit [Quit: Leaving]
<lundman>
ok, /dev/nand does have MBR
ZaEarl has quit [Ping timeout: 260 seconds]
drachensun has quit [Quit: Leaving]
ol1ver has quit [Ping timeout: 252 seconds]
oliv3r has quit [Ping timeout: 252 seconds]
cheng has joined #arm-netbook
<lundman>
mbr has no surprises. 'our' layout x4
<lundman>
I take that back, mbr is like their layout, not our
ol1ver has joined #arm-netbook
itamar_ has quit [Ping timeout: 246 seconds]
<lundman>
ok there is no reason our kernel should return this weird mbr
sspiff has quit [Ping timeout: 252 seconds]
leszcz has quit [Read error: Operation timed out]
ZaEarl has joined #arm-netbook
ol1ver has quit [Ping timeout: 272 seconds]
pawel5870 has joined #arm-netbook
Svet has joined #arm-netbook
bsdfox has quit [Read error: Connection reset by peer]
ol1ver has joined #arm-netbook
discopig has quit [Ping timeout: 276 seconds]
<mnemoc>
lundman: there must be something...
<mnemoc>
lundman: the repartition tool is based in kernel code.. you can play from there
<lundman>
yeah I think I have found it
<lundman>
just waiting for compile so I can boot and try
<mnemoc>
userspace is simpler :p
rzk has quit [Ping timeout: 245 seconds]
<lundman>
the fix was in the kernel :)
andoma_ is now known as andoma
<lundman>
ah ok, lets try then
<lundman>
ok this time I will dd it to nandc, then reboot
<mnemoc>
/dev/nand gives you free access to the mbr, and the partitioning tool mutated over kernel code
<mnemoc>
there is zero need to experiment with this on kernel space
<lundman>
box uname -a
<lundman>
Linux localhost 3.0.42+ #9 PREEMPT Tue Oct 16 06:55:29 UTC 2012 armv7l GNU/Linux
<mnemoc>
git grep user_type drivers/block/sunxi_nand shows only 2 references :<
<lundman>
i have not seen any 2s
<mnemoc>
let me look at my mele
<mnemoc>
that's old enough
<lundman>
unsigned int user_type; //标志当前盘符所属于的用户
<lundman>
"Flag letter belongs"
ZaEarl has joined #arm-netbook
<mnemoc>
lundman: keep your local change and send a mail to the list CCed to Tom asking if he knows something
<mnemoc>
in the mean time I'll try to see if I have any 2s
<ZaEarl>
mnemoc, I don't understand. When I look at github, I see discussions in pull requests and comments in commits. Seems nice and organized like that.
<lundman>
yeah I mean, the safe option is to just add "1", and keep 2. but it sort of feels like the 2 is a misstake
<lundman>
I could also IDA their kernel and see what values they test for
<mnemoc>
ZaEarl: things get rebased, links get broken
<ZaEarl>
bummer
<mnemoc>
ZaEarl: in the ML you have proper interleaved discussion over the actual patch
<mnemoc>
in plain text
<lundman>
dang
<lundman>
kernel changed too much, can't load 3.0.8 modules in 3.0.42 without hanging :)
<mnemoc>
expectable...
<lundman>
so, a dead end
<lundman>
guess it is time to move onto some other project
sspiff has joined #arm-netbook
sspiff has quit [Changing host]
sspiff has joined #arm-netbook
sspiff has quit [Remote host closed the connection]
<mnemoc>
lundman: what that doesn't evolve and move forward?
<lundman>
hmm?
<mnemoc>
"guess it is time to move onto some other project"
<mnemoc>
you lost me there
<lundman>
we dont have "their" sources for android 3.0.8 kernel. and I can't boot our 3.0.42 kernel
<mnemoc>
tried from uSD?
<lundman>
never managed to boot android from SD actually
<lundman>
but I suppose I could add 42 modules to nandX somewhere
<mnemoc>
android... :|
pwhalen has quit [Ping timeout: 255 seconds]
<hno>
mnemoc, I have not been able to test the reboot issue in depth.
<mnemoc>
hno: but at least reproduce one?
<mnemoc>
i'm starting to wonder if i've burned out my cards
popolon has joined #arm-netbook
<mnemoc>
s/one/once/
popolon has quit [Client Quit]
sspiff has joined #arm-netbook
mid7tester has joined #arm-netbook
mid7tester has quit [Client Quit]
<lundman>
dang, loading the .42+ modules on android makes it panic, after loading UMP
sspiff has quit [Remote host closed the connection]
<mnemoc>
gosh. the code of this nand-part is horrible
<mnemoc>
so I guess we need to accept the 3 values
<mnemoc>
does that really solve your nand detection problem?
popolon has joined #arm-netbook
<lundman>
yep it did
<lundman>
ok, so the real answer is to handle 3
<lundman>
if you boot .42 kernel, it will not "show you" system, data and cache, as it skips type==1
<lundman>
so I would say we need it
silentaa has joined #arm-netbook
<mnemoc>
want to send a patch yourself? It's your fix after all
cheng has quit [Quit: Leaving]
ZaEarl has joined #arm-netbook
ZaEarl_ has joined #arm-netbook
ZaEarl has quit [Read error: Connection reset by peer]
oliv3r has joined #arm-netbook
cat_n9 has joined #arm-netbook
avernos has quit [Ping timeout: 246 seconds]
avernos has joined #arm-netbook
avernos has quit [Changing host]
avernos has joined #arm-netbook
tzafrir_laptop has quit [Ping timeout: 276 seconds]
ZaEarl_ has quit [Ping timeout: 260 seconds]
vgrade_ has quit [Ping timeout: 252 seconds]
newbie has joined #arm-netbook
newbie is now known as Guest32116
rellla has quit [Ping timeout: 255 seconds]
rellla has joined #arm-netbook
hp__ has quit [Ping timeout: 276 seconds]
Guest32116 has quit [Ping timeout: 276 seconds]
<libv>
.fex is not as funny as the fermi microcode (fuc) the nouveau guys keep talking about, but gets bonus points for the father ted reference :)
<mnemoc>
o_O
jeremb has joined #arm-netbook
<jeremb>
hi everyone, I have a question, are phoenixcard images and livesuit the exact same thing or does the phonixcard image contains more things?
<mnemoc>
phonixcard turns a livesuit image into an installer card with phonixcard image format
ZaEarl_ has joined #arm-netbook
<jeremb>
because I am trying to build a custom image for the MK802 II but it's never flashed correctly when I burn it with PhoenixCard
<jeremb>
so normally the same .img file can be both used in LiveSuit and Phoenix card ?
<mnemoc>
afaik, yes. I've never used either
<mnemoc>
in sunxi-tools there is a tool that parses phoenixcard images (already on card, or dd-able)
<mnemoc>
it might show you what's on yours
<jeremb>
so it's strange because I take the official MK802II rom, I unpack/repack it with unimg.exe then burn it with PhoenixCard and it never get flashed on my device...
<mnemoc>
test without repacking it
<jeremb>
it works
<mnemoc>
then the repacking is broken
<jeremb>
phoenix_info tells me that both the original img and the repacked one are not valid phoenixcard images
<mnemoc>
maybe different format version
<mnemoc>
not supported by the other tools yet
<mnemoc>
pretty common when dealing with obscure proprietary formats/tools
<jeremb>
so any advice how I can repack the image? maybe another tool? or method?
<ZaEarl_>
try LiveSuit
<jeremb>
unfortunately it's not easy to to switch the device to LiveSuit mode as there is no hardware button to do it
<ZaEarl_>
that's interesting. what device?
<mnemoc>
you can make a bootable card jumping you directly to FEL mode
<ZaEarl_>
that's a good idea
<jeremb>
MK802II
<jeremb>
yep I'll try that but I would like to make a PhoenixCard compatible img to easily share my ROM with others
<ZaEarl_>
so they took the reset button off II? Lame.
tzafrir_laptop has joined #arm-netbook
<jeremb>
there is a recovery button, but it boot the device in recovery mode, not in FEL mode
<jeremb>
@mmemoc thanks
Svet is now known as Sv
<mnemoc>
jeremb: unfortunatelly for your problem most people here focuses in the open source side of sunxi (A10/A10s/A12/A13/...), CM in the case of android, and not really into modifying closed images.
ZaEarl_ has quit [Read error: Connection reset by peer]
ZaEarl_ has joined #arm-netbook
techn_ has joined #arm-netbook
techn has quit [Ping timeout: 252 seconds]
ZaEarl_ has quit [Ping timeout: 260 seconds]
<libv>
hrm, with "Building_Debian_From_Source_Code_for_Mele" adjusted for linux-sunxi github stuff and with a linaro rootfs, i managed to get something booting
<mnemoc>
alcides: but it was announced like a month ago
<alcides>
yes... but still away of the goal... only 50%
<RaYmAn>
I honestly think the majority of people that could potentially be interested in backing it has already seen it.
<rm>
would be nice
<rm>
but I just plain do not believe them
<lundman>
:)
<RaYmAn>
what part?
<rm>
and I don't believe I will get anything in return for any money sent
<mnemoc>
it's nice they use openness as flag
<RaYmAn>
mnemoc: definitely, but they still seem kind of low on details
<jelly-home>
I don't really see how their coprocessors are different from gpgpu solutions
<RaYmAn>
I mean, is it a custom soc with everything in same package (including paralella) or is it some standard soc with parallela as external chip etc
<RaYmAn>
jelly-home: can you program gpgpu cores individually?
<mnemoc>
it's a dual a9 soc + grid of their own not-arm cores called Epiphany
<RaYmAn>
mnemoc: yes, but that's kind of vague
<jelly-home>
RaYmAn: I don't want to... "parallel" usually means the same thing in parallel
<RaYmAn>
well, that is still one of the major differences.
<rm>
they are under no real obligation to deliver anything
<rm>
the most you can do about that is do a "direct message" or "post a public comment"
<RaYmAn>
sure, it's like that with any and all kickstarter projects
<RaYmAn>
Heck, you have the same issue if you preorder something and the company goes bankrupt
<libv>
mnemoc: boosting it to 1G helps avg performance... but... the whole machine tends to stall quite often
<rm>
RaYmAn, no
<libv>
mnemoc: i am currently worried about mmc not being stable
<rm>
on preorders+bankruptcy you can certainly get a refund
<rm>
complicated, but still
<libv>
90% waiting... mmcqd/0
<RaYmAn>
rm: only if there's enough money left :P
<rm>
right
<mnemoc>
libv: using latest u-boot or something older? what kernel branch?
<libv>
latest u-boot, latest 3.0
<RaYmAn>
most companies doing kickstarter projects will pretty much be f*cked if they don't deliver though - community backlash etc, so presumably roughly equivalent to backruptcy
<mnemoc>
strange. I work purely on uSD on my 3 test devices and none has similar troubles
<libv>
aah, i forgot one step, but that should not affect mmc performance
<libv>
there are no modules or firmwares in this rootfs
<mnemoc>
that shouldn't affect anything
<libv>
i will try another sd card and replay some things, and document things on the linux-sunxi wiki
<mnemoc>
thanks
itamar_ has joined #arm-netbook
ssspiff has joined #arm-netbook
sspiff has quit [Ping timeout: 246 seconds]
<oliv3r>
mnemoc: you linked Cpufreq up there somewhere, but the github link on that page does no longer work :(
<mnemoc>
issue tracker moved from amery to linux-sunxi orga
<mnemoc>
back in 20m
rz2k has joined #arm-netbook
pwhalen has joined #arm-netbook
cat_n9 has quit [Ping timeout: 256 seconds]
ssspiff has quit [Ping timeout: 246 seconds]
sspiff has joined #arm-netbook
cat_n9 has joined #arm-netbook
QingPei has joined #arm-netbook
cat_n9 has quit [Ping timeout: 246 seconds]
cat_n9 has joined #arm-netbook
<oliv3r>
mnemoc: you back?
<oliv3r>
long 20m
hp__ has joined #arm-netbook
<mnemoc>
oliv3r: ?
leszcz has quit [Ping timeout: 246 seconds]
<oliv3r>
wb :)
<oliv3r>
mnemoc: i've sent you a pull-request on sunxi-tools
<oliv3r>
over on github
<mnemoc>
oliv3r: i would prefer if you can send it to the ML for discussion
<RaYmAn>
if I'm reading that right, they actually implemented a kernel driver to do exactly what libusb does in userspace? :/
<oliv3r>
nope, this is the awusb driver from allwinnertech; i just cleaned it up and gave it a home on github (it came from tom's i belive)
<oliv3r>
oh, they, i thought you ment me; i belive so
<mnemoc>
but it's required by livesuit and buggy, so something we probably need to maintain to avoid chaos
<oliv3r>
but they based it on 'something' existing
<oliv3r>
i'll get the patch into the mailing list, but leave the pull-request as is for now; if no real comments come (like my previous mail) you can still pull it and work can be done from there
<RaYmAn>
mnemoc: I'm looking forward to the day when we have a fully open solution for livesuit-like recovery
<oliv3r>
and yeah, i do think it should have a 'home' somewhere, sunxi-tools sounds sensible.
<oliv3r>
hometime
<mnemoc>
instead of getting this in the tools packages it might be a good idea to turn sunxi-boards into our own BSP package
<mnemoc>
s/packages/package/
<ibot>
mnemoc meant: instead of getting this in the tools package it might be a good idea to turn sunxi-boards into our own BSP package
<mnemoc>
and work as glue to our other packages, including android, buildroot, "hwpacks", ....
<mnemoc>
but ML
<mnemoc>
RaYmAn: of course that is the ultimate goal
<rz2k>
Turl: you've asked yesterday about if that es2gears is cpu
<rz2k>
[ 159.870000] UMP<2>: New session opened [ 159.870000] Mali<2>: Session starting [ 161.090000] Mali<2>: Mali PM: OS runtime resumed
* rz2k
digging in to r3p1 debug options
leszcz has joined #arm-netbook
<Turl>
rz2k: UMP is just a memory allocator
<jeremb>
speaking about livesuit, there is now a Linux version, it should be easier to reverse engineering it
<mnemoc>
can you try the wip/linux-sunxi-3.0/disp branch?
<rz2k>
Turl: previously we had total fail with Mali itself
<rz2k>
UMP opens session but then libgles dies
<rz2k>
now I'm running glmark2-es2 successfully right now
<Turl>
change your governor to performance
<Turl>
then monitor load with htop or similar
<Turl>
it shouldn't eat all of your cpu
<rz2k>
also afaik libraries that I use right now (default mali r3p1 armhf) cant do anything on CPU
<rz2k>
glmark2 score:43
<rz2k>
thats with mali_div=4, default one from mele a2000 script.bin
<Turl>
isn't the default =3?
<rz2k>
with 3 it will be 320mhz with 4 300mhz, but dont quoute me on this one.
<Turl>
just 20mhz difference?
<rz2k>
I just grabbed default script from nanda and using it.
<Turl>
I thought it was 960 or something of that sorts / div
* rz2k
pokes mnemoc as a local mali mem/div expert
<Turl>
I once was playing with it and --'d the value
<Turl>
my mali didn't like it :)
<mnemoc>
i'll ignore you all until I get confirmation wip/linux-sunxi-3.0/disp can be merged :p
ol1ver has quit [Ping timeout: 246 seconds]
<rz2k>
interesting
<rz2k>
glmark2-es2 eats 3%-9% of CPU
mSquare has quit [Ping timeout: 240 seconds]
ol1ver has joined #arm-netbook
<rz2k>
but X eats everything else entirely
<mnemoc>
at 1GHz?
<rz2k>
yep
<mnemoc>
:(
<rz2k>
looks like on each frame update x11 mali driver does some serious math or whatever
<rz2k>
or its just monkeycoded as usual
ol1ver has quit [Read error: Connection reset by peer]
<rz2k>
previously on mesa sw rasterization glmark2 had 100%
<Turl>
maybe 'mali' is just dummy fb handling + mode setting
<Turl>
mode setting would be handled by disp though
<libv>
gl does not claim or require that different combinations of hardware and software create pixel perfect and identical renderings of the same scene
<rz2k>
all kudos go to author of glmark2
<libv>
i know
<libv>
it's that greek linaro guy
<Sv>
sunxi is nice, i've been playing around with a hackberry
rsalveti has quit [Read error: No route to host]
<techn_>
rz2k: latest should be x11 libs
rsalveti has joined #arm-netbook
<techn_>
.. yesterday, we got new r3p0/1 libs from Tom.. They seem to work now.. not perfect but working
<mnemoc>
r3p0? meaning we can merge that to the main branch and finally replace r2p4?
<techn_>
yes! but main branch looses cedarx :(
<techn_>
as libs are armhf only :(
<techn_>
or :)
<techn_>
I'm testing r3p0 and it seems glmark and es2gears works
<mnemoc>
uhm... not nice... that would trigger a fork :<
<mnemoc>
so will need both :|
<mnemoc>
sucks
<Turl>
ehm
<Turl>
how is it different than the current situation?
<Turl>
cedar never worked on armhf?
<mnemoc>
cedarx is still armel only
<mnemoc>
r2p4 is armel/armhf
<mnemoc>
r3p0/p1 is armhf only
<Turl>
you can probably bug tom to make a r3p0 armel
<Turl>
:)
<mnemoc>
techn_: ----^ ?
<Turl>
after all android runs on it
<mnemoc>
there is no connection between building for android and building for linux/armel
<Turl>
android is -mfpu=soft iirc
<mnemoc>
it's not about optimizations, it's about bionic vs. glibc, and x11 vs whatever android uses
<Turl>
s/fpu/float-abi/
<ibot>
Turl meant: android is -mfloat-abi=soft iirc
<Turl>
s/soft/softfp/
<ibot>
Turl meant: android is -mfpu=softfp iirc
<mnemoc>
different toolchain, different env
<Turl>
meh :< doesn't cache last sedfix
<Turl>
-mfloat-abi=softfp mnemoc
<Turl>
so there's no 'technical reason' it has to be armhf only
<mnemoc>
the technical reason is that he uses ubuntu/armhf to build the libs natively
<Turl>
crosscompilation? :P
<mnemoc>
don't ask that much
<Turl>
I'll build the bins myself
<Turl>
just get me the source :P
<mnemoc>
ARM blessed people only
<Turl>
yeah I know :'(
* ManoftheSea
is still sad about the lack of display options on EOMA
<ManoftheSea>
or, higher res ones, anyway.
itamar_ has quit [Remote host closed the connection]
<merbanan>
mnemoc: would it be possible to do a binary translation from armel to armhf ?
<mnemoc>
in the sense that it's not impossible, yes. but unlikely considering viable time constrains ;-)
<merbanan>
just so it would be abi compatible
vgrade_ has joined #arm-netbook
<mnemoc>
it's probably harder than making allwinner opensource cerdarx
<merbanan>
mnemoc: one can always hope
<Turl>
you could use android libs with libhybris
<mnemoc>
i doubt they work that deep down in the stack
Yakuzzi has joined #arm-netbook
QingPei has left #arm-netbook [#arm-netbook]
cat_n9 has quit [Ping timeout: 272 seconds]
Gujs_ has joined #arm-netbook
<techn_>
mnemoc: I could ask armel libs.. do we want x11 or framebuffer libs?
<mnemoc>
x11
Gujs_ has quit [Read error: Connection reset by peer]
<mnemoc>
asking for both only increases the odd of not receiving any
<mnemoc>
odds*
<Sv>
yes
<techn_>
.. why ARM has made this so hard.. libs for every different platform :(
Sv is now known as discopig
<Turl>
because
<jelly-home>
what's wrong with hardfloat?
<libv>
techn_: well, egl is where the rub is
<libv>
is the egl X11 based, or fb, or wayland, does it tie in with the 2d engine or not
Yakuzzi has quit [Remote host closed the connection]
Yakuzzi has joined #arm-netbook
<mnemoc>
jelly-home: problem isn't with hf. problem is we have to deal with closed libraries. for cedarx we still only have debian/armel libs
<mnemoc>
jelly-home: and for mali r3p0/1 we only have ubuntu/armhf libs
<mnemoc>
so until we get cedarx libs for armhf our only option to move forward to r3p0/1 is to get new mali libs for debian/armel to match cedarx
<mnemoc>
or keep both in the kernel
<mnemoc>
making the drm/ump integration even messier
<techn_>
mnemoc: btw. any progress getting armhf cedarx? :/
pawel5870 has quit [Read error: No route to host]
pawel58701 has joined #arm-netbook
<mnemoc>
techn_: you have more contact with Tom than I :|
<mnemoc>
but afaik the only dev within AW who can build them isn't very.... friendly
<discopig>
cpufreq really enjoys itself on A10, it keeps setting the cpu to 60mhz
<mnemoc>
otoh eva is happy telling everyone they are collaborating with gimli and that's enough
pawel58701 has quit [Read error: Operation timed out]
<techn_>
gimli: you have armhf cedarx libs? or could you get them via your contact? :)
<mnemoc>
it can be equally broken libs, we only need them recompiled, not fixed
<gimli>
techn_: nope
<mnemoc>
fixed is better obviusly
<techn_>
mnemoc: I didn't understand that guy who had problems with latest commit.. Do we have a problem?
<mnemoc>
not that i know
cat_n9 has joined #arm-netbook
Quarx has quit []
Yakuzzi has quit [Remote host closed the connection]
Yakuzzi has joined #arm-netbook
<techn_>
xbmc seems to crash..
<techn_>
#3 0x41935528 in ump_reference_release () from /lib/libUMP.so
<techn_>
#4 0x40ace42a in _egl_platform_map_dri2_buffer () from /lib/libGLESv2.so.2
<techn_>
..
<techn_>
#10 0x40ac8b22 in eglMakeCurrent () from /lib/libGLESv2.so.2
<techn_>
#11 0x007886d2 in CWinSystemX11GLES::RefreshEGLContext() ()
<techn_>
#13 0x007881bc in CWinSystemX11GLES::CreateNewWindow(CStdStr<char> const&, bool, RESOLUTION_INFO&, bool (*)(XBM
<techn_>
#12 0x00788b36 in CWinSystemX11GLES::SetFullScreen(bool, RESOLUTION_INFO&, bool) ()
cat_n9 has quit [Ping timeout: 245 seconds]
<techn_>
rz2k: have you tried xbmc?
<techn_>
Oct 16 21:06:04 linaro-alip xbmc.bin: ASSERT EXIT:
<techn_>
Oct 16 21:06:04 linaro-alip xbmc.bin: In file: arch_011_udd/ump_frontend.c function: p¡AÂ() line:39745208
<techn_>
Oct 16 21:06:04 linaro-alip xbmc.bin: Error in mapping pointer (not mapped)
<rz2k>
no, linaro's xbmc tries to initialize libGL, not gles
<techn_>
I'm using linaros xbmc
<techn_>
or trying to use :)
cat_n9 has joined #arm-netbook
<lkcl>
ManoftheSea: that's because you're misunderstanding things. EOMA goes up to the maximum permitted on an RGB/TTL interface, which, on a TI OMAP CPU is 2048x2048 @ 30fps.
<lkcl>
ManoftheSea: it's the SoCs which limit the maximum resolution, *not* the EOMA-68 specification.
<ManoftheSea>
that makes me a little happier.
<ManoftheSea>
lkcl: I have part of a schematic of, well basically of a USB hub.
<ManoftheSea>
But it's the necessary part of the micro board.
<ManoftheSea>
It takes the D+ and D- lines from the PCMCIA header and feeds it to a 7-port, multi-TT USB hub.
<ManoftheSea>
But, I don't know how to finish the board with footprints and connectors.
<ManoftheSea>
Actually, I should mail this to the list.
j1nx_ has joined #arm-netbook
Yakuzzi has quit []
<Turl>
woot, someone deduped the sun[45]i usb stack :)
<hno>
Turl, what?
<Turl>
hno: check the mailing list
<rz2k>
rm: you wanted 1080p on vga?
<rm>
not me
<rz2k>
damn, anyway I have it running
<Turl>
rz2k: it was lundman probably
<rm>
rz2k, I wanted uhm
<rm>
1650x1050 on HDMI
<rm>
can you do that? :)
<rm>
1680x1050*
<rz2k>
nope if it is not in the modes list :/
<techn_>
rz2k: Even that wont help
<rz2k>
interesting thing is, X works on 1080p, when console is still in 720p in left-upper corner
<rm>
rz2k, do you have any success setting 75 Hz on VGA?
<libv>
because 9y ago i heard "no, it cannot be done, we will need to rely on the modes programmed in the bios"
<Turl>
9y ago only?
<hno>
Turl, got it. Nice.
<libv>
it took another 3-4 for people to realize that this was bogus, and that i was bang on :)
<libv>
3-4 years even
<hno>
rz2k, the console driver probably is missing some hook to react on the resolution change.
<hno>
libv, we did custom video modes on EGA. Don't know a single graphics card that have had hardcoded resolutions.
revident has joined #arm-netbook
<libv>
hno: where were you in the first half of the 2000s?
<hno>
Long away from video cards. GPUs isn't my thing.
<libv>
this is display, not gpu
<libv>
in any case, remember life before randr1.2 (however limited and shortsighted that was), before that happened people refused to believe different
<hno>
randr1.2 on EGA would be something..
<libv>
so today i am quite weary of people stating "no, cannot happen"
<libv>
especially when it often is just about one person spending 3-4ds testing mode after mode, figuring out how the pll ticks and what its limits are
<techn_>
Turl: there is much to improve.. but first I was thinking to get rid of that wip/disp branch
<Turl>
the kernel is full of allwinner quality code :)
<ManoftheSea>
Byond "Quality"
<libv>
Turl: it seems better than the code VIA threw out in 2003. there were actual register tables there, dumped straight from the VIA vga BIOS...
rsalveti_ has joined #arm-netbook
<libv>
in any case, what is hdmi wired to?
<Turl>
libv: A10 I believe
<libv>
a special hdmi block which is not documented, i suspect, due to hdcp
rsalveti has quit [Ping timeout: 245 seconds]
rsalveti_ is now known as rsalveti
<libv>
the tv-encoder most likely drives the vga connector
<mnemoc>
Turl: in the kernel those gcc-isms are welcomed. many others too. they call it the gnu99 standard :p
<Maqs>
apropos kernel for allwinner.. to replace an existing kernel, is it enough to build a new uImage and replace the old one?
<hno>
libv, most my video card hacking was in 1985-1990 or so. But have not seen any evidence that cards are less flexible in their timing & resolution capabilities overtime.
<libv>
hno: i have dealt with external tv encoders which really only did accept a few fixed modes
<libv>
so in some rare cases it does happen
<mnemoc>
Maqs: you also need to replace the modules
<Turl>
mnemoc: didn't know that
<Maqs>
mnemoc: ok, done.. but somehow it doesn't seem to work.. i don't get any output, so i cannot tell what's the problem :-/
<mnemoc>
Maqs: booting from nand? what branch?
<hno>
libv, ah, yes, can imagine finding that in such things. Probably still seen in USB connected TV encoders.
<Maqs>
sunxi-3.0, booting from sdcard
<hno>
doubt the hardware as such is limited, but likely a firmware imposing it's own rules.
<libv>
hdmi seems to be freely programmable, but it will take quite a bit of work getting things that far :)
<libv>
as hdmi seems to be its own block
<mnemoc>
Maqs: do you see u-boot's output? what defconfig did you use?
<Maqs>
i just added a few things to what came from /proc/config.gz, compiled it, copied arch/arm/uImage
<hno>
The A10 display blocks seem very freely programmable indeed. But hidden far down behind many layers of odd abstractions.
<ManoftheSea>
Hey guys, if you're discussing the graphics and the A10... can you confirm how much res you can put out a single TTL/RGB?
<hno>
coming from an history of several operating systems and desire to oversimplify things in obscure ways.
<Maqs>
defconfig doesn't seem to compile due to some "usb glue" stuff
<Maqs>
it's an mk802 (a10)
<mnemoc>
Maqs: sun4i_defconfig works fine
<mnemoc>
Turl: still, that particular switch() would look better with ifs
<Maqs>
strange
<hno>
ManoftheSea, unknown what pixelrate the A10 accepts to output in TTL mode. Quite likely it does whatever you ask it to do, but signal levels might not be too great at higher frequencies.
<Maqs>
there is an '#error "missing bus glue for ehci-hcd"'
<hno>
Maqs, how are you building?
<Turl>
Maqs: are you using a 3.0 config on 3.4?
<Maqs>
nope, it's 3.0 both
<Maqs>
only defconfig did not work, the /proc/config.gz compiled just fine
<Maqs>
but does not run
<hno>
sun4i_defconfig, or defconfig?
<Maqs>
i don't get any output at all, my monitor just keeps searching for a source
<Maqs>
gotta check that..
<mnemoc>
monitor :)
<mnemoc>
Maqs: less greed. try a serial console first
rellla1 has joined #arm-netbook
<Maqs>
i don't have any idea how to do that ;)
popolon has quit [Quit: Quitte]
<Maqs>
i did "make ARCH=arm sun4i_defconfig"
popolon has joined #arm-netbook
<Turl>
plug your uart to ttl adaptor and "screen /dev/ttyUSB0 115200"
<mnemoc>
Maqs: and CROSS_COMPILE= ?
<Maqs>
i compiled it on the mk802
<Maqs>
ARCH=arm should be redundant, too.. i guess..
<hno>
split mrporper and sun4i_defconfig in their own make steps. the other can be mixed.
<Maqs>
k
* Turl
never makes modules, yet they're built the same
<hno>
modules_install builds modules
<Turl>
I just make uImage
<Maqs>
btw, may that have to do with armhf?
<hno>
Maqs, no
<Maqs>
i had to patch uboot to compile, as they use -msoft-float
<hno>
Turl, so you don't install modules?
<hno>
Maqs, you should not need to patch that
<hno>
armhf gcc supports -msoft-float as well.
<Maqs>
it does, but uboot seems to need some other things
<Turl>
hno: I install them manually using 'adb push'
<Maqs>
or is partly compiled hf, partly sf
<Turl>
hno: and my mele doesn't use any modules
<Turl>
I =y all the stuff I need
<libv>
hno: i ran into the same issue today, it clashed with some libs at link time
<cat1>
techn_: hmm.. have no idea where this symbol should come from.. symbol lookup error: /usr/lib/libEGL.so.1: undefined symbol: _mali_clz_lut, do you? :)
<techn_>
cat1: which lib you are using?
<hno>
libv, -msoft-float?
<cat1>
techn_: i guess one that comes with this dir mali_opengl_hf_lib sorry, but do not remember where i download it from ;)
<techn_>
cat1: I'll update latest to linux-sunxi
<cat1>
techn_: what is the latest-and-greatest recommendation for egl libs?
<techn_>
one moment..
<cat1>
techn_: ah, cool, thanks!
<libv>
hno: yes, u-boot built fine against a hf gcc, but during linking it fell over due to sf vs hf
<Maqs>
for uboot, i just commented out the -msoft-float in arch/arm/cpu/armv7/config.mk
<libv>
Maqs: s/soft/hard/ would've also worked
<libv>
to the same result :)
<hno>
wonder why they hardcode soft-float,
<libv>
true
<Turl>
one uboot to rule them all in the future?
<libv>
seems like that would fix u-boot build then :)
<libv>
hno: make it so :p
<hno>
one u-boot for all would be something.. but at least there is much less code duplication than a year ago.
<techn_>
cat1: I cant upload to wiki
<cat1>
techn_: maybe we should create temporary repo on github for binaries exchange?
<techn_>
I'll email to you and mnemoc
<techn_>
check your priv
<rz2k>
I was wrong or that was a bug, but fbcon works in 1080p, but in wrong colors
<rz2k>
green is blue
<techn_>
rz2k: what you are testing?
<rz2k>
my script.bin with vga 1080p
<techn_>
ah
<techn_>
Test wip/disp :)
<techn_>
It may even have fix for that problem :p
<mnemoc>
techn_: give me your ssh key to give you access to upload to dl.linux-sunxi.org
<cat1>
mnemoc: can we now have something really up-to-date in sunxi-3.4?
<mnemoc>
cat1: once next-mali is approved i'll merge it on both...
<cat1>
let's vote now? :P
<mnemoc>
it's not about votes, it's an agreement
<cat1>
if next-mali is not broken why not let it go?
<hno>
Maqs & libv: u-boot soft-float issue is really an gcc packaging issue. To link with -msoft-float you need the soft-fload libs installed (gcc-multilib package on Ubuntu)
<hno>
but probably works just fine to build u-boot armhf.
<mnemoc>
cat1: not my call, i don't use mali at all
<libv>
cat1: define "not-broken" with respect to graphics drivers
<Maqs>
hno: well, it works with hard-float
<Maqs>
(now) ;)
<libv>
cat1: what utopic world have you been living in so far?
<cat1>
libv: definition: it does not behave worse than in master sunxi-3.4
simosx has joined #arm-netbook
simosx has quit [Changing host]
simosx has joined #arm-netbook
<mnemoc>
cat1: but cuts off people using cedarx
<cat1>
mnemoc: and in which branch it is working? ;)
<mnemoc>
afaik is kind of works on sunxi-3.0 with armel userspace
<cat1>
mnemoc: ok, but i am asking for 3.4
<libv>
hno: removing -msoft-float from the config.mk, should solve the issue i guess, if a hf gcc defaults to hf for linking as well
<mnemoc>
cat1: i suppose it works in the same degree there too ;-)
<hno>
hf gcc defaults to hf linking yes.
<libv>
cat1: what stops you from merging locally yourself?
<cat1>
libv: i am loosing baseline constantly :)
<cat1>
libv: but otherwise nothing, sure i can do whatever
<hno>
Can't we throw in both mali versions?
<mnemoc>
hno: i think we will end up doing that
<libv>
heh, external mali.ko anyone?
* hno
have been saying that all along..
<mnemoc>
i suppose we can do it with one bool CONFIG_
<hno>
mnemoc, if this continues I think we will end up with 4 mali versions. So a dropdown.
<mnemoc>
problem with external mali is that we can't do the integration with disp/drm...
<rz2k>
3 versions, r2p4, r3p0 and r3p1 :)
<libv>
mnemoc: what integration?
<libv>
mnemoc: maybe drm/kms is simply a broken model
<hno>
rz2k, right now yes.
<libv>
said the guy who came up with quite a few of the core ideas that eventually filtered into randr1.2 and kms
<mnemoc>
libv: the driver expects pre-cutted off memory chunk, and some special ioctrl()s
<rz2k>
lol. lets not go into linux graphics stack discussion, this will end in great holywar.
<hno>
and a little further down the line 4 versions to match the different distribution types. 1 armel, 1 android el, 1 armhf, 1 android hf.
* mnemoc
cries
<libv>
mnemoc: surely the reserved memory can be reserved regardless of when the module is built?
<libv>
mnemoc: what ioctls would that be?
<mnemoc>
libv: it's a VERY large % of the total ram... not something to do when mali won't be used
<hno>
mnemoc, welcome to the land of binary blobs. Embrace one and they soon eat you full.
<mnemoc>
libv: ump related, to deal with some buffers
* cat1
tends to agree with mnemoc: we'd rather keep mali within.
<hno>
mnemoc, the ump fb ioctl is decoupled already, remember?
<mnemoc>
libv: 64MB+32M+16MB
<libv>
but ump and mali should be built externally, and mali depends on ump, and ump depends on memory being reserved for mali
<libv>
this at least is my simplified view of the world, never actually having touched the mali kernel driver
<mnemoc>
if we manage to fix mali's memory reserving to be done by the driver instead of pre-mmu...
<libv>
it could be pre-mmu
<Turl>
hno: there's no such thing as android hf as far as I'm aware
<libv>
the memory could still be reserved from config
<mnemoc>
Turl: android 5.0 is comming
<Turl>
android 5 is unlikely to hit anytime this year
<Turl>
and I haven't heard anything about it being hf either
<Turl>
it's gonna be a pain if that's true :P
<hno>
should work fine to reserve mali memory using mem= boot parameter.
<libv>
either the memory is reserved and ump is happy when loading, or ump refuses to load
revident has quit [Quit: Combustible lemons? Bah, I bring you weaponized asparagus!]
<hno>
ump is not cause to memory reservation issues, that one plays friendly. mali.ko is.the bad boy.
<mnemoc>
and the drm driver?
<mnemoc>
kicked out too?
<libv>
mnemoc: seems that they all belong to the same graphics stack
<hno>
do that actually do anything at allö?
<Turl>
wasn't the drm thing a dummy interface?
<libv>
mnemoc: again, because intel and redhat cannot see things differently, doesn't mean that we have to give ourselves more pain than necessary dealing with the binary blobs
<libv>
we can only be flexible at the kernel side, so this is where we need to make sure that we are flexible, despite shortsightedness upstream
<libv>
when i finally do get a mesa/gallium based lima driver out, it will build externally
* mnemoc
seriously pissed off by hipboi disappearance. we only need a r3p0 armel driver to not need this discussion.... and he is supposed to be the most interested one on have proper open source support for sunxi
<libv>
which will piss off quite a lot of people, and i have had BS thrown at me for my plans already, even though i only briefly mentioned this at fosdem
<mnemoc>
:)
<libv>
but in the latter case, the person doing so had to give in that his reasons for giving me crap was his own view of the world being wrong
<cat1>
libv: are you working on lima?
<mnemoc>
cat1: he is lima
<Turl>
mnemoc: wasn't he moving or something?
<mnemoc>
Turl: he ended up staying in zuhai
<libv>
mnemoc: :)
<libv>
cat1: not often enough :p
<cat1>
libv: i did not even get how to compile is from the sources :D
<libv>
but that's sadly more about company politics than anything else
<libv>
cat1: yes, the android ndk is not really made for this sort of thing
<hno>
Maybe he did return to Allwinner as well?
<libv>
cat1: also, lima is still fully about finding out how everything fits together
<libv>
there is no working driver there, there is some code to test driver like functionality
<cat1>
libv: ah, kinda playground.
<libv>
cat1: at this stage, nothing else is possible yet
<mnemoc>
Turl: would it be possible to build both .ko? mali_r2p4.ko, mali_r3p1.ko without much change?
<hno>
mnemoc, yes.
<cat1>
libv: yeah, i understand.
<Turl>
mnemoc: you'd need new kconfig variables
<Turl>
and make some makefile guards so they don't clash or something
<mnemoc>
Turl: would you take the challenge? ;-)
<libv>
what versions has allwinner seen already?
<Turl>
mnemoc: why do you need r2p4 still?
<mnemoc>
for people using cedarx on linux :<
<mnemoc>
or trying to...
<cat1>
mnemoc: so the plan would be to keep separate github repo with all mali parts in there? this actually might work..
<rellla1>
trying to ;-)
* mnemoc
cries
<Turl>
'git revert' works wonders :)
<cat1>
mnemoc: not that loud :)
<mnemoc>
cat1: no no... that's what I want to avoid at all cost
<Turl>
mnemoc: we should try to ask tom for softfp libs
<Turl>
problem solved :)
<cat1>
mnemoc: ok, checking this possiblity out then ;)
<mnemoc>
cat1: I was thinking more of a CONFIG_MALI + bool CONFIG_MALI_LEGACY
<Turl>
mnemoc: in reality r3p0 is old already :< we need new android, softfp, hardfp r3p1 libs
<rellla1>
Turl: added links to r2p4 armel libs in the wiki. afaik this one is used in most of the xbmc/cedarx "tries"
mysteryname has joined #arm-netbook
specing has quit [Ping timeout: 276 seconds]
<libv>
in any case, shoring up mali enough to make it multi-version compatible, is possible but not very feasible in the current constellation, especially not going forward with arm throwing new kernel space drivers over the hedge
<libv>
it's going to be much easier with ump, mali, and mali_drm modular, with a limited changeset needed for initialization that is compatible with the linux-sunxi kernel, so that these changes can be thrown into new arm "heaps"
<libv>
also, without a decent open userspace driver, there is no upstreaming for these bits anyway
tuliom has joined #arm-netbook
<hno>
Turl, seems so. Looks shiny. Sadly the shop is still closed.
<mnemoc>
the second batch should be arriving this week iirc.... but i fear it's already sold
<mnemoc>
those days he decided to silently open aliexpress' sho[
<hno>
hope he has been busy this week testing and shipping the first batch.
<mnemoc>
:)
<libv>
hrm... according to the mmu init of 3.0. mali uses 64mb, g2d uses 16 and lcd uses 32 (i am sure that this must be display instead though)
<mnemoc>
yes, lcd means fb
<libv>
mnemoc: so your 64 + 32 + 16 of earlier, of that, only the 64 is handed to ump, right?
<mnemoc>
don't know how ump gets them
<mnemoc>
the chunk in removed (not reserved) from meminfo, the kernel never see it
<libv>
sure
<mnemoc>
and the references to that address/size are hardcoded mali's config.h
tzafrir_laptop has quit [Ping timeout: 248 seconds]
<mnemoc>
libv: so this style is.... normal?
<libv>
on via unichrome, on amd hammer/k8 chipsets, asked the k8 how much memory we really had, the unichrome how much was reserved for it, and then mapped that last bit, and got mad cpu<->igp bandwidth :)
<mnemoc>
doh
<libv>
(the openchrome guys still haven't caught on to that one ;p)