<oliv3r>
which is just a rename or split from something else
<oliv3r>
appearantly, they use/store the 'security id' to detect which soc it is
<mnemoc>
nice
<mnemoc>
oliv3r: can you commit your changes on top of my soc-detect?
<mnemoc>
that looks a lot like a10s' code
<oliv3r>
mnemoc: it's the same code
<mnemoc>
a13's didn't have the writel, a10s' does
<oliv3r>
mnemoc: but I said i'm going to BREAK it
<oliv3r>
There is one on chip 128-bit EFUS for security application.
<oliv3r>
It can also be used as root key or for other purposes.
<mnemoc>
define break
<oliv3r>
e.g.
<oliv3r>
there's no guarantee it will be un-changed
<oliv3r>
e.g. it might be unique per chip; yes
<oliv3r>
it also means, anybody can change it to suit their needs
<oliv3r>
e.g. store a unique device ID or a sha key or god knows what
<oliv3r>
so you cannot depend on it to be guaranteed to detect a device from it
<mnemoc>
as long as it's done after the initial soc detection....
<oliv3r>
it's 'flash (efuses)
<mripard_>
oliv3r: remember that an EFUSE can be changed only once
<oliv3r>
so you could in theory program your mac address to that (or partially)
<mnemoc>
an eeprom on twi0 is more civilized :p
<mripard_>
(on a bit per bit basis)
<oliv3r>
mripard_: the datasheet makes you belive it is not write once
<oliv3r>
mripard_: and efuses are re-programmable most of the time (from what I know from AVR's)
<mnemoc>
oliv3r: is it possible you don't touch the bits that are used for soc-detection?
<oliv3r>
mnemoc: i'm just saying, IF you can modify it (more then once) then you cannot reliably detect the SoC from it :)
<mnemoc>
;'(
<mnemoc>
:'(
* mnemoc
hates oliv3r now
<oliv3r>
but the strange thing is AW uses it too
<oliv3r>
mnemoc: i don't have to break it; but we can't guarantee it :)
<mnemoc>
please try to avoid it. soc detection is important
<mripard_>
oliv3r: the point of efuses is precisely that once it's been changed once, you can't switch back to the previous state
<mripard_>
and that's why it's used for such hardcoded values
<mripard_>
that should never change
<mnemoc>
+1
<oliv3r>
mripard_: the manual says 'can also be used as roto key or for other purposes'
<oliv3r>
mripard_: I agree that that if you have write once fuses; sure
<oliv3r>
mripard_: but if these are reprogrammable fuses; you cannot rely on them for detection
<oliv3r>
and since even the datasheet says 'it can also be used as' it doesn't sound to me its 'write once''
<mripard_>
oliv3r: yes, I agree on that
<mripard_>
(the soc-detection part)
<oliv3r>
mripard_: i do fully agree that it should n't be changeable from the kernel (you can't protect it against mmap I suppose)
<mripard_>
test it, you'll see :)
<oliv3r>
mripard_: have you probed it? have you tried writing to it more then once?
<mripard_>
not on this one
<mripard_>
but I've already used efuses on other platforms
<oliv3r>
mripard_: i just know from AVR development, you can change the efuses to set the chip up in a certain way, and you can change that more then once :)
<oliv3r>
mripard_: yes, I do agree, I have seen write once, fuses too
<mripard_>
ok, I didn't know abouth this AVR use of fuses
<mripard_>
anyway, the easiest thing to know how it works is to test it I guess :)
torindel has quit [Ping timeout: 240 seconds]
torindel has joined #linux-sunxi
<oliv3r>
mripard_: yeah i'll be happy to test it :p
<oliv3r>
once i know if there's any unused bits so i can't break anything; if it's write once, and i change my ID, i'll be screwed :p
<oliv3r>
but i guess modifiing a single bit should be okay if it's not used by soc detect
<oliv3r>
if it is write once (which I highly doubt) then it's programmed factory wise and it can be used for soc-detect just fine; but otherwise, it's unreliable and shouldn't be used imo, sorry mnemoc :(
<mripard_>
oliv3r: remember, it's on a bit per bit basis
<mripard_>
so if the value stored is 0x42
<mripard_>
you could very well change it to 0x43
<mripard_>
(but not to 0x40)
<mripard_>
but anyway
<mripard_>
someone that modifies the fuses should know what he's doing
<mripard_>
(and this is why I told you to make the whole fuses thing read only to the user space)
<oliv3r>
mripard_: for soc detect, they use only 2 of the 4 regs
<oliv3r>
so i hope the other 2 are unused and i can test with one of those
<oliv3r>
mripard_: i fully agree, only read calls
<oliv3r>
mripard_: and again, we can't protect against mmap (can we?) but was thinking of writing to it only via FEL mode
<oliv3r>
make a little tool that can set it (i don't think it should be secret thing :p) with a big fat warning 'be carefull'
<mripard_>
no, someone using /dev/mem will have access to this
<mripard_>
but someone using devmem fall into the category "knows what he's doing" to me :)
<oliv3r>
mripard_: i agree
<oliv3r>
devmen and /dev/mem are the same right? or are you refering to two different things?
<oliv3r>
mnemoc: the writel is to setup the clocks; which i don't quite understand why that matters :p
<mnemoc>
oliv3r: what disturbs me is that the current soc-detect fails on techn's A13
<mnemoc>
and I have no clue where my a13-olinuxino is atm
<oliv3r>
mnemoc: i don't have any A13 so can't test even if I knew what to try
<oliv3r>
mnemoc: but once i'll dig into this sid thing more; you can read it and see what his sid really is
<oliv3r>
mnemoc: but if my theory is right, it could be, that he (maybe by accident, or the factory somehow) forgot to/overwritten the e-fuses and it doesn't match anymore
<oliv3r>
mripard_: i'll give you one thing though; the chinglish from the manual is hard to read. the actual root registers are marked 'read' meaning read only. Happy-joy. BUT there's an SID Program Control Register with 2 writable sections. 4 bits; 'program index; the index value of 32-bits electrical fuses hardware macrocell' and 1 bit for: 'write '1' to start software program and automatically clear to '0' after program.
ibrah has joined #linux-sunxi
<oliv3r>
the rest of the bits are hidden 'undifined' so it looks like that bit0 allows you to write to it, where's the 'index' tells you which efuse you will write to
<mripard_>
mnemoc: I'm not 100% sure, but I thought f2fs was meant for block devices
<mripard_>
so I'm not exactly sure it makes sense to put it on top of some NAND
<mnemoc>
mripard_: uhm.... I'll need to read about f2fs is more detail then :<
<oliv3r>
well you are supposed to also use it on SSD's? or will it only be for mtd type devices?
<mripard_>
oliv3r: yes, it's meant for flash-based block devices
<mripard_>
so SSDs, eMMCs, MMC, etc.
<oliv3r>
i thought that it wasn't like j2ffs or those, since those are pure mtd devices (that lack trim etc) where as f2fs was for things like SSD's because ext assumes certain things and it slows things down; but i'm not all that into it either
<oliv3r>
but isn't /dev/block/nand a flash-based block device?
<oliv3r>
well aw's attempt to write one, where it should have been a mtd device since there's probably no smart controller behind it?
<oliv3r>
the nfc nand driver is an ugly hack anyway and should die :p
<oliv3r>
mnemoc: in your test code (for the A13) try reading sw_get_chip_id and dump those hex's to the concole; atleast then you know what techn has in his a13
<mnemoc>
oliv3r: yes, will do
torindel has quit [Ping timeout: 252 seconds]
torindel has joined #linux-sunxi
<oliv3r>
mnemoc: the mini-module i'm writing will initially be against mripard_ 3.10 stuff; so won't be useable for you anyway :(
<mnemoc>
np
<oliv3r>
so sw_get_chip_id() might be easiest as that is allready in the kernel and easily accesable
<oliv3r>
what's the best 'new' way to do kernel debug printing/printing. it uses to be printk; but checkpatch whines that you should use printk +kern_level; but once you do that, it complains that you should use netdev_... or dev_ or pr_; where is this properly documented! the howto on that is old and still talks about printk
<oliv3r>
i'd assume that netdev is only for networking stuff (ethernet, wifi etc); but well assumptions and mothers
hipboi has quit [Remote host closed the connection]
ibrah has quit [Ping timeout: 258 seconds]
<oliv3r>
ssvb: have you done anything ith the 'image enhancement engine'?
<oliv3r>
with regard to the f2sf driver, it's usefull still, for sata users. I guess it can be used on the nand device, but i doubt it'll be usefull; it probably assumes there's a 'smart flash controller (trim etc)' underneath
ibrah has joined #linux-sunxi
zumbi has quit [Ping timeout: 255 seconds]
grevaillot has quit [Ping timeout: 255 seconds]
traeak has quit [Ping timeout: 255 seconds]
focus has quit [Ping timeout: 255 seconds]
ssvb has quit [Ping timeout: 260 seconds]
ibrah has quit [Read error: Connection reset by peer]
grevaillot has joined #linux-sunxi
horon has joined #linux-sunxi
focus has joined #linux-sunxi
traeak has joined #linux-sunxi
ssvb has joined #linux-sunxi
Guest24544 is now known as fredy
bsdfox has quit [Ping timeout: 240 seconds]
ibrah has joined #linux-sunxi
ibrah has quit [Ping timeout: 252 seconds]
<oliv3r>
would it be possible to boot the kernel 'oldstyle'? e.g. place a uImage (or bImage) on nanda, inform boot.ini to boot that (like they appearantly did with 2.3) If i include my initramfs in my kernel, that shouldn't pose any issue, should it? (just finding a why to boot a custom kernel :(
torindel has quit [Ping timeout: 245 seconds]
<Turl>
oliv3r: yeah but you'd only be able to boot 3.0 with aw mem hack detection on
<oliv3r>
Turl: that's better then not booting anything :)
<oliv3r>
Turl: read ^^ i asked you something but allready forgot :D
torindel has joined #linux-sunxi
<hramrach>
oliv3r: I suspect f2fs is made exactly for stuff like the nand on sunxi
<oliv3r>
hramrach: i thought that it wasn't made for low level flash devices (like mtd)
<hramrach>
it is somewhat smart - in part due to hardware checksumming, in part due to the kernel driver which does bad block management
<oliv3r>
our nand driver is more like mtd isn't it
<hramrach>
the mtd driver implements the smartd the SSD usually has in software in the Linux kernel
<hramrach>
*smarts
<hramrach>
so in the end you get similar interface
<hramrach>
and what a2fs has over other filesystems is tuning for the flash block size
<hramrach>
which is hidden only by some very over-engineered SSDs
<oliv3r>
i thought mtd didn't do the smarts
<oliv3r>
that's why you want j2ffs ontop of it
<oliv3r>
since that does wear lvling etc
<hramrach>
well, the nand dirver has wear levelling and stuff
<hramrach>
maybe the ordinary mtd does not
<hramrach>
or at least bad block management
<oliv3r>
i know some of the smarts are supposed to be in the fs; like j2ffs as you access the raw flash; or so I recall the mtd layer to be
<hramrach>
drivers/block/sunxi_nand/src/logic/
<oliv3r>
oh i'm sure the nand driver has it in there
<hramrach>
they use fat so they must
<oliv3r>
heh yeah
<ssvb>
oliv3r: I have no clue what this 'image enhancement engine' could possibly be, do you mean disp layers or maybe g2d (mixer processor)?
<oliv3r>
with firefox and the built in pdf viewer it should
<oliv3r>
otherwise, it's the A13 user manual (a10 has it too) and it's called 'IEP - Image Enhancement Processor' page 364 (A13)
<ssvb>
oliv3r: ok, thanks, so looks like it's something from 'drivers/video/sunxi/disp_iep.c'
<ssvb>
oliv3r: a lot of this stuff is under CONFIG_ARCH_SUN5I in the kernel
<mnemoc>
maybe the latest a10-dev uses it too
<mnemoc>
those #ifdef came from unifying the drivers. and sun5i's came from a newer sourcedrop than sun4i's
<oliv3r>
ah so we do have 'some' support for it; i thought it was more of an 'hardware offloading' engine for impage processing
<ssvb>
oliv3r: I may be wrong, but it looks like some kind of colors/luminance adjustment feature (based on the feedback from the ambient light sensor)
<oliv3r>
ah yeah if you'd install that, you could use it for that; i just glanced over it, and thought it was some image enhancement thing (Digital camera, CSI-cams) etc
ganbold__ has joined #linux-sunxi
<oliv3r>
but in the code i only see flicker this and flicker that :p
<oliv3r>
so maybe it's image-enhancement + flikker filter :p
gzamboni has quit [Read error: Connection reset by peer]
ganbold_ has quit [Remote host closed the connection]
hansg has joined #linux-sunxi
<ssvb>
Turl: just curious, have you already tried to test the quality of PRNG? The documentation seems to claim that it is "160-bit hardware PRNG with 192-bit seed"
<oliv3r>
Turl: i rememberd; i was curious where your crytpo repo is at :)
hramrach has quit [Ping timeout: 276 seconds]
<Turl>
oliv3r: there's no such repo yet
<Turl>
ssvb: I tried to, but my mele doesn't have any toolchain, so I just dumped several hundreds of MBs of crypto to a file and fed the test from that, but it wasn't enough, so I gave up
<oliv3r>
Turl: have yo dumped your example code somewhere? :)
<oliv3r>
has anybody ever said that disp is a huge mess? cause, and I don't know much about all this stuff; this has to be a huge mess :S
<oliv3r>
disp_tv.c looks like some copy of disp_vga.c (or vice versa) with only half of the stuff initialized n stuff
<Turl>
it has silly prints and stuff, might want to clear it up a little and add code to seed it
<Turl>
ssvb: ^
<oliv3r>
Turl: just wanna try it and see how you've tested things :)
<oliv3r>
Turl: i have lots ot learn :)
<oliv3r>
ssvb: /*
<oliv3r>
* 0 -256 (256: no dimming; 0: the most dimming)
<oliv3r>
* IEP-drc backlight dimming rate:
<oliv3r>
*/
<oliv3r>
i think this is sun5i only
wingrime has joined #linux-sunxi
<oliv3r>
Turl: why do you use those WRITE and READ macro's instead of writel and readl; are those kernel only things?
<Turl>
yeah
<Turl>
I'm doing a simple userspace test :)
shineworld has quit [Quit: Leaving]
<oliv3r>
ok, was just wondering :)
vicenteH has joined #linux-sunxi
ZaEarl has joined #linux-sunxi
<ssvb>
Turl: thanks, I'll try to check it later today
<ssvb>
Turl: IMHO the most interesting use of the sunxi security system would be to try hardware accelerating LUKS disk encryption
<libv>
ssvb: seems like you've been spending a lot of time on the xf86-video driver :)
<ssvb>
libv: yeah, spent last two weeks trying to get reasonable performance for moving windows and scrolling (via G2D and NEON)
<libv>
how is that working out?
<libv>
how useful is g2d turning out to be?
<ssvb>
at least G2D is faster than CPU for copying data
<libv>
so you're not too happy with it
<ssvb>
well, I never had any high expectations
<libv>
has it been working as pretty much as expected, or are there further issues than the missing operations for full composite support?
<ssvb>
properly accelerating composite is going to be a tough challenge
<ssvb>
"accelerating" means "making graphics faster" for me, and not just "moving pixels using the g2d hardware"
<wingrime>
libv: DMA is fastest way copy something not g2b
<wingrime>
*G2D
<libv>
for me it is using existing hw as optimal as possible, and offloading the cpu as much as possible
<libv>
wingrime: openchrome still stupidly carries around some amd k7 and p4 assembly
<mnemoc>
if we can save CPU cycles that can be used for something else, it's a win imo
<libv>
wingrime: i just made sure i mapped things correctly for the memory controller to properly handle things
<libv>
ah, dma, sorry, i too should learn to read instead of dream
<wingrime>
:)
<libv>
wingrime: do we have a dma engine which can deal with stride changes?
<ssvb>
libv: yes, but offloading the cpu is not so easy, unfortunately the exa framework is a horrible cpu hog and thus is not suitable for 2d acceleration
<libv>
because that is usually the issue
<libv>
ssvb: tell me about it :)
<wingrime>
libv: dma have many modes " copy " " fill "
<libv>
ssvb: anholt killed some optimised paths for XAA to "improve layering", but in reality he made benchmarks look better for EXA
<libv>
back in 2008 or so
<wingrime>
libv: in summer I played with dma on msp430
<wingrime>
libv: that dma engine can fill copy blocks , by event, autoinrementing or decrementing
<libv>
wingrime: there are many possibilities for DMA, they could be really dumb, or they could end up being called a full 2d engine
<wingrime>
libv: I send symbols to uart withouy cpu
<wingrime>
libv: and recive it to mem block
<libv>
ssvb: but beware though, we do not need yet another 2d acceleration infrastructure
<wingrime>
libv: dma is great thing
<ssvb>
libv: I will probably add some EXA code to the driver, just for testing an functional validation of G2D features, but it's hardly going to have any practical value for acceleration
<libv>
ssvb: keithp once told his own management and suse management that suse, the only credible enterprise desktop linux provider of the time, to go change its business model
<libv>
because we did not want to take the performance hit of EXA for a driver update to the enterprise desktops
<libv>
and because we had 5-7y support on those things
<libv>
ssvb: copywindow is what anholt made slow on XAA
<wingrime>
mnemoc: there is small problem related soc architectue
<wingrime>
mnemoc: all devices share single bus
<ssvb>
libv: the same can be of course done with exa (and much easier), but enabling exa means a rather measurable overall performance loss
<wingrime>
mnemoc: when G2D or DMA or CedarX write to mem, or read it use bus for it
<wingrime>
mnemoc: and cpu work for a low speed
<libv>
ssvb: how well does this tie in with, say, dri2?
<libv>
i could imagine that a lot of things are in the meantime hacked into those higher level calls
egbert_ is now known as egbert
<ssvb>
libv: g2d is also useful for copying dri2 buffers, and actually the desktop graphics cards are doing this instead of real buffers swapping (at least for windows, fullscreen is a bit easier)
<ssvb>
libv: I looked at radeon and nouveau
gzamboni has joined #linux-sunxi
<wingrime>
ssvb: disp have some layers support
<wingrime>
ssvb: and swapping
<libv>
ssvb: i am just worried that maybe people stuck some things into those pScreen hooks in the meantime, and the sunxi own implementation might not get that
<libv>
wingrime: ssvb is well aware of that
<wingrime>
libv: I prefer use opengl es for layers
<libv>
?
<ssvb>
wingrime: you mean the other way around?
<wingrime>
libv: use mali as 2d engine
<wingrime>
libv: that more modern way
<wingrime>
libv: comparea 2d engines
<wingrime>
libv: OpenGL compositing
bsdfox has joined #linux-sunxi
bsdfox has joined #linux-sunxi
<libv>
wingrime: that's useless dogmatic bs
<libv>
wingrime: that's just the 3d core makers trying to make themselves more important
<ssvb>
libv: for the pScreen hooks, I think it's safe to assume that we are setting them immediately after the fb module (and maybe eventually cannibalize the whole fb module)
<ssvb>
libv: trying to be too general and versatile is going to cost performance
<wingrime>
libv: maybe
<libv>
wingrime: radeon r600 was a dog, and ati would've done much better if it kept useful parts of its 2d engine alive
<wingrime>
libv: but I have a13 that lack g2d (((
<oliv3r>
isn't 2d nowadays emulated on 3D hardware (radeon)?
<libv>
but this is the late 2000s kind of stupidity
<oliv3r>
i thought the open grahpcis card was going to do that too
<wingrime>
livb: I have r600 some times ago, that card died
<oliv3r>
wingrime: I guess if your DE is fully 3D based, it won't matter (compiz etc)
<libv>
oliv3r: because people cannot be bothered with a) doing a proper job of even the boring work b) power never was an issue for them
<libv>
context switches... well... they rather not talk about that
<libv>
i saw the first things about the img rogue in 2010
<oliv3r>
i can imagine that; but if your DE is fully 3D accelerated, do we even need one?
<libv>
guess what... the design came with a blitter
<libv>
as having something simple to the side to deal with copying stuff around, is much much more efficient
<libv>
especially when talking to the same mmu
<libv>
mobile makes all of that very important
<libv>
same thing with overlays
<libv>
i think i was one of the last people in xf86 land to deal with overlays...
<wingrime>
libv: g2d can handle simple desktops but not KWin and GNOME 3 in composite modes
<libv>
until android used overlays, and intel demanded feature parity from wayland as well
<oliv3r>
i just wonder if that not all will go away
<libv>
oliv3r: it just came back.
<oliv3r>
2D and overlays?
<libv>
yes, big time
<oliv3r>
isn't android 4 all about '3D'?
<oliv3r>
i thought that the entire UI was done on the 3D engine
<libv>
oliv3r: renderscript
<oliv3r>
same for gnome 3/compiz etc
<libv>
oliv3r: status bar is often an overlay
<libv>
saves massive
<libv>
intel is really rather f-ed on that one
<libv>
their gen3 hw had some nice powerful overlays
<libv>
more recent ones didn't need it anymore, as "it could all be done on the 3d engine for free" (which was a big lie)
<wingrime>
ssvb: I will be glad if you implement "xv"
<libv>
now the hwcompositor of surfaceflinger can only use layers in very specific situations
<wingrime>
that make possible watch video on cpu without cedar
<ssvb>
wingrime: first I'm going to push the NEON optimized "backend" for CopyWindow/CopyArea, this should make A13 users *much* happier :)
<libv>
yikes, a13 really is aimed at 800x480, isn't it
<oliv3r>
libv: i wouldn't be spprised
<oliv3r>
i got lucky with my tablet with an A10 and hdmi out
<oliv3r>
though I don't think with stock firmware, you could ever use that
<ssvb>
libv: I believe some of the A13 tablets also have hdmi
<libv>
a10s?
<libv>
still pretty bad
<libv>
also mali MP1 is really struggling on 720p :)
<libv>
60fps while combining 2 textures is simply out of the question :)
<libv>
so i guess that compositing 2 images using the mali-mp1 on sunxi, is not going to be useful
<libv>
not with a single pp and only 320MHz
<ssvb>
libv: kwin_gles does not look too bad for basic window effects on mele a2000
<ssvb>
maybe not 60fps, but quite usable
<libv>
so being able to combine 2 layers in the crtc, without requiring a third buffer with the result in between, and with it happening as the pixels are pushed out, and not having to wait for some other engine to complete beforehand... that is a really huge win
<libv>
memory bandwidth needs go up, but you wasted that anyway when compositing on the 3d engine
<libv>
so layers are an insanely good optimization
<ssvb>
wingrime: something still has to render the content on the offscreen pixmaps
<ssvb>
wingrime: and then your gles compositing window manager can use these offscreen pixmaps as textures, combine them in some fancy way and add flashy effects and animations
<ssvb>
wingrime: the compositing window manager introduces an extra intermediate layer in the graphics stack for the sake of adding eye candy
<ssvb>
wingrime: the content of windows for X11 applications is still rendered by CPU (or possibly G2D)
<ssvb>
wingrime: of course you can also have native GLES applications, but they also suffer a bit from the extra overhead introduced by the compositing manager
<oliv3r>
I kenw it came from textures, I didn't know you could accelerate rendering those textures; in that case, even gnome 3 etc on desktops would still need a hardware 2D engine to make all that fast?
simosx has joined #linux-sunxi
simosx has quit [Changing host]
simosx has joined #linux-sunxi
<ssvb>
wingrime: that's why the hacks like "unredirect fullscreen windows" exist to remove this overhead
<libv>
oliv3r: it could all get a lot faster, but becomes more complicated and intricate as you do
<libv>
people just take the easy way out, and state "we can do all of that on the 3d engine", and then afterwards wonder why performance is crap
<ssvb>
wingrime: to make it even more funny, hardware video overlays do not work right with compositing window managers
<ssvb>
wingrime: with the compositing window manager, you can for example watch your video on a side of a rotating cube, isn't this awesome?
<ssvb>
wingrime: the simple hardware overlays obviously can't handle this and need to be disabled
<ssvb>
wingrime: the desktop gpu manufacturers eventually decided that the hardware overlays are the things of the past and are not needed anymore
<ssvb>
wingrime: but unfortunately mobile devices spoiled all the fun for them
<ssvb>
wingrime: the users of these pesky mobile devices care about the performance and power consumption for some reason :)
<ssvb>
wingrime: so the hardware overlays seem to be coming back
<libv>
ssvb: depends on how the overlays are built up and how they are used
<libv>
ssvb: if there is a separate colour conversion and filter/scaler, then 3d compositors would happily take that
<libv>
and the compositor should be smart enough to realize when it can fall back to overlays or layers, whether or not it needs colour conversion or extra filtering/scaling
<libv>
this adds complexity, and a willingness to do the right thing at the right time
<libv>
which is what many people do not want to deal with
<libv>
99% of the time, alpha-compositing layers are useful and provide a huge advantage
<libv>
the old way Xv was implemented of course doesn't really fit in all this
<oliv3r>
hometime, then I have to figure how to use device tree from a module :)
<oliv3r>
so see ya all laters :)
<ssvb>
libv: maybe I'm wrong, but in X server there seems to be no way for the compositing manager to communicate with DDX for enabling efficient use of alpha-compositing layers
<mnemoc>
cu oliv3r
<ssvb>
I believe alpha-compositing layers are useful for standalone embedded applications which run on top of framebuffer and can use layers for the things like subtitles or osd
paulk-desktop has joined #linux-sunxi
<libv>
ssvb: there isn't, indeed
<libv>
ssvb: and nobody has bothered to implement it
<libv>
ssvb: and it was added as an afterthought to wayland as well
<libv>
because android had it
<paulk-desktop>
hi
<paulk-desktop>
what's the kernel format for the free uboot?
<paulk-desktop>
the preinstalled one seems to use android bootimage format
<paulk-desktop>
but I guess the one from github uses uImage, correct?
<paulk-desktop>
ah, it's written down
<mnemoc>
uImage
hansg has quit [Quit: Leaving]
<wingrime>
mnemoc: are you tryed merge my cedarx unification
<wingrime>
?
<mnemoc>
haven't had time to look at that yet
<mnemoc>
wingrime: i would actually to "graduate" some patchsets in stage/ before adding more stuff there
<wingrime>
3 days ago
<wingrime>
[PATCH] sunxi:pm: unify sun4i and sun5i pm
<wingrime>
4 days ago
<wingrime>
I like see some comments
<wingrime>
on maillist but none
simosx has quit [Quit: Αποχώρησε]
ganbold___ has joined #linux-sunxi
ganbold__ has quit [Ping timeout: 256 seconds]
<mnemoc>
wingrime: what about the _avc.c part?
<wingrime>
mnemoc: it broken
<wingrime>
and was
<wingrime>
I wan't unify ot first than fix
<mnemoc>
have you reviewed newer cedarx code in the lichee/*-dev branches?
<wingrime>
last time I reviewed dev I not found something intersting
<wingrime>
if you wan't I see again
<mnemoc>
just to keep you busy :p
<mnemoc>
so you reviewed lichee/{a10,a13,a10s}-dev for cedarx changes already?
<mnemoc>
nothing fixing avs.c?
<wingrime>
a10-dev not have sun4i on drivers/media/video
<mnemoc>
check the history
<wingrime>
a130-dev have sun5i
<mnemoc>
they DELETED a lot of code to turn it blobs
<mnemoc>
s/it/them/
<mnemoc>
reviewing only the HEAD of those branches is pretty much useless
<mnemoc>
btw, if you have some time, can you see if we screwed up sun5i reboot in 3.4 when unifying core.c?
eebrah has joined #linux-sunxi
<wingrime>
mnemoc: who report that?
<mnemoc>
there is a thread on the ML and also a ticket on github
<mnemoc>
when I redid the unification for core.c I remember a #ifdef exception for sun5i
<mnemoc>
I think hans missed that on 3.4
<mnemoc>
s/core.c/3.0/
<wingrime>
mnemoc: I have reboot if I have xorg with non sunxi-video running
<wingrime>
hang and reboot on suspend
<mnemoc>
a13?
<wingrime>
yep
<wingrime>
It looks disp
<rellla>
mnemoc, wingrime: only difference between sunxi-3.0 and latest deleted a10-dev/sun4i_cedar.c are what Turl said already: http://paste.debian.net/245480/
<wingrime>
easy to add
<wingrime>
but it give full access to kernel mem
<wingrime>
not realy secure
ganbold___ has quit [Remote host closed the connection]
<mnemoc>
paulk-desktop: please submit patches disabling it on all defconfigs
<mnemoc>
well... 1 patch
<paulk-desktop>
where do I submit that?
<paulk-desktop>
I don't have a github account
<mnemoc>
linux-sunxi's mailing list
<paulk-desktop>
okay
<wingrime>
mnemoc: why not simply move mach/ramconsole to plat ?
<paulk-desktop>
I'll subscribe to it first
<paulk-desktop>
wingrime, well are you sure it'll work on sun5i as well?
<wingrime>
it simply pre-allocated block
<wingrime>
in mem
<mnemoc>
wingrime: if it works on sun5i, sure
<mnemoc>
but it should be disabled by default anyway (imo)
<wingrime>
mnemoc: as I see code in core
<wingrime>
so no proble
<wingrime>
it will work
<mnemoc>
the code is #ifdef protected and intended for sun4i only :)
<wingrime>
mnemoc: see carefully
<wingrime>
it simply reserve mem block
<mnemoc>
ok. move it to plat, test it, and submit the patch. I'll apply it :)
<oliv3r>
libv: btw, with regards to the comeback of 2D engines, efl has a chance again :p it looked awesome while still being relative light. I do miss e16
<oliv3r>
Turl: atag memhack you mean btw, right? boot.axf only boots bImage (or zImage, not uImage i'm assuming) so if I have that with integrated initramfs and integrated kernel commandline, do I need anything else? starting memory address? the ini parameters are on the wiki i belive
<wingrime>
mnemoc: done
<wingrime>
mnemoc: don't forget add "reported by"
<wingrime>
that patch i made on "stable" branch
<oliv3r>
wingrime: remember to commit your patches with -s
<oliv3r>
or if you use git email to use -s :)
<wingrime>
I done it this time)))
<oliv3r>
:D
<mnemoc>
does the CEC stuff work?
<mnemoc>
the diff between stage and not-stage is growing too big and want to merge most of it...
<oliv3r>
mnemoc: i'll test hansg's patches hopefully tonight
<oliv3r>
just need to figure out a working test setup]
<oliv3r>
though that'll make stageing even bigger :p
wingrime has quit [Ping timeout: 256 seconds]
torqu3e has quit [Quit: torqu3e]
torqu3e has joined #linux-sunxi
shineworld has joined #linux-sunxi
shineworld has quit [Read error: Connection reset by peer]
shineworld has joined #linux-sunxi
n01 has joined #linux-sunxi
leowt has quit [Quit: leowt]
bsdfox has quit [Ping timeout: 255 seconds]
ibrah has joined #linux-sunxi
eebrah has quit [Ping timeout: 255 seconds]
ibrah has quit [Ping timeout: 248 seconds]
n01 has quit [Quit: leaving]
paulk-desktop has quit [Quit: Ex-Chat]
ibrah has joined #linux-sunxi
ynezz has joined #linux-sunxi
bsdfox has joined #linux-sunxi
bsdfox has quit [Changing host]
bsdfox has joined #linux-sunxi
shineworld has quit [Remote host closed the connection]
ibrah has quit [Read error: No route to host]
ibrah has joined #linux-sunxi
<oliv3r>
hmm, 3.8+ requires bc to compile; even more interesting is that I didn't have it