<hno>
bhoj, I have not studied A31 yet, but if it's anything like the A10/A13 in boot order then SD card boot is before it even touches NAND.
<hno>
bhoj, we do not yet have an SPL for A31.
<wowon>
hno : Could you please tell me why my A10 based tablet could not boot smoothly from Sd card ? it boot from SD card ... but not smooth. I mostly need to do 'reset' for it to able boot from SD card. And so the reboot mostly stuck.
<hno>
wowon, both A10 and u-boot SPL is a bit picky about what SD cards you use. Try another card brand/model.
<wowon>
hno : Thankyou for your help ... I'll try that
<hno>
For example it seems some cards are too slow for the A10 to see them at power on, requiring a soft reset to detect the card.
<wowon>
hno : roger that
Wetomelo has joined #linux-sunxi
Wetomelo has left #linux-sunxi [#linux-sunxi]
BJfreeman has quit [Quit: had a good time]
resistencio has joined #linux-sunxi
<resistencio>
hello
<wowon>
yup
rz2k has joined #linux-sunxi
resistencio has left #linux-sunxi ["Ex-Chat"]
aholler_ has joined #linux-sunxi
aholler has quit [Ping timeout: 248 seconds]
TheSeven has quit [Read error: Operation timed out]
TheSeven has joined #linux-sunxi
<bhoj>
hno, thanks for the info.
bhoj has quit [Remote host closed the connection]
bhoj has joined #linux-sunxi
rz2k has quit [Read error: Connection reset by peer]
<oliv3r>
shineworld: was nofi; I was just thinking, if libvecore is a dedicated arm core, (other then it being a wasted resource when not decoding) it probably would need firmware, and haven't found it as of yet
eebrah|away is now known as eebrah
<wingrime>
oliv3r:ping
<oliv3r>
ssvb, not shine
<oliv3r>
wingrime: sorry was reading backlog
<oliv3r>
what's that? mmiotrace?
<shineworld>
I guess :)
<oliv3r>
wingrime: Mmiotrace was built for reverse engineering any memory-mapped IO device
<oliv3r>
oh!
<rm>
shineworld, + means "built from source with some commits or changes past this version"
<shineworld>
thanks for info
<oliv3r>
wingrime: nly x86 and x86_64 architectures
<oliv3r>
wingrime: that or, simply put, memory map a chunk of 'my' memory, call the function (like InitJpegHW() for example) and see what it writes where
<wingrime>
we need some one to dump IO map
<wingrime>
VE Engine IO space
<oliv3r>
I guess we can even fake SRAM in memory?
<oliv3r>
just need to learn a lot, and mostly; need a lot of time
<gzamboni>
hi, does anyone managed to make network boot work ?
<gzamboni>
i am getting a kernel panic
<gzamboni>
<1>Unable to handle kernel NULL pointer dereference at virtual address 00000007
<gzamboni>
i am getting also this two lines before: <6>Switched to NOHz mode on CPU #0
<oliv3r>
sorry, no
egbert_ is now known as egbert
_BJFreeman has joined #linux-sunxi
_BJFreeman is now known as BJfreeman
<hno>
lkcl, I should get the package today.
<hno>
gzamboni, sunxi kernels is not stable with CONFIG_NO_HZ last time I tried.
<gzamboni>
i am doing some try outs here :)
<hno>
wingrime & oliv3r, I would suggesting looking into what libv did for lima. The MALI libraries is also using a lot of mmap:ed accesses.
<lkcl>
hno: magic.
<hno>
lkcl, is there something running on the board? Or is the NAND image in bad shape?
* hno
remembers lkcl said he played with livesuit
BJfreeman has quit [Quit: had a good time]
<oliv3r>
hno: wingrime is allready making my ears smoke with details that are far beyond me :p
<oliv3r>
hno: glancing over it, it takes the mali calls, does something with them and forwards them to the kernel?
<oliv3r>
ah, i see
<oliv3r>
it hijacks mmap, ioctl and open from libc, i thought the driver would make direct kernel syscalls, bypassing libc, silly me
<oliv3r>
but in the case of cedarX, we actually have the driver, so we can hijack code directly there? :) libv :D
<hno>
oliv3r, I have not studied it in detail, but it obviously tracks mali mapped memory and ioctl accesses.
<hno>
oliv3r, mali kernel part is also open.
<oliv3r>
hno: then i'm curious why libv choose that approach
<oliv3r>
probably because its easier to combine everything in 1 wrapper
rellla has joined #linux-sunxi
<hno>
it is a lot easier to study things in userspace.
<hno>
for one thing you can easily dump the trace in a file.
<oliv3r>
so libvecore.so will always use libc/libbionic for those calls right? there's no way it does some realy special things via cedar.ko?
<oliv3r>
or otherwise
<hno>
it's very very unlikely it does direct syscalls.
<oliv3r>
but technically possible?
<oliv3r>
not that I doubt you ;)
<hno>
but if it mmaps I/O space then maybe there is hardware actions which do not involve a syscall at all.
<oliv3r>
such as?
<hno>
yes ofcourse it is technically possible to make direct syscalls, but requires a bit of inline assembly and gets quite messy with no gain to the developer.
<oliv3r>
then it's even more unlikly
<oliv3r>
:p
<hno>
mmap:ed I/O space can do anything the I/O module can. See for example pio.c in sunxi-tools. It has mmap support for playing directly with PIO (gpio etc) bypassing the kernel.
<oliv3r>
fel-pio you mean?
<hno>
No, just pio.c built natively for sunxi.
<oliv3r>
ah okay
<hno>
fel-pio is a wrapper to access PIO via FEL. Same program used in both cases for manipulating the PIO state but on case of fel-pio pio.c runs on the host and not the sunxi board (only a little fel wrapper runs on the sunxi board then to dump/restore the PIO state)
<hno>
It is possible to track even such I/O operations but requires some clever use of mprotect() in the LD_PRELOAD wrapper to trap accesses.
<oliv3r>
doubt that'll be needed thought
<ssvb>
wingrime: the kernel based tracer for cedarx is also going to work if you implement it for arm and if you don't like the existing userland solution so much
<hno>
Do the kernel module provide mmap access to I/O space or only SRAM?
<oliv3r>
ssvb: i think iainb was a) wrapping android, b) was using very old wrappers
<ssvb>
oliv3r: have you actually tried it?
<oliv3r>
hno: you mean if cedarx.ko maps only IO or both IO and SRAM? on sun7i readl is basically exposed via an IOCTL, so I guess anything goes; it's less clear (to me) how sun4i does sram
<ssvb>
oliv3r: it has a few bugs, but it surely can works in linux
<oliv3r>
ssvb: oh no i haven't ;p
<oliv3r>
i'll deffinatly use it as a base (if i continue with this, again, so much to do, so little time )
<ssvb>
oliv3r: the latest available linux armhf linux libvecore.so blob (the buggy one) is using thumb2
<oliv3r>
bummer :(
<gzamboni>
hno: i disabled CONFIG_NO_HZ and i still cant boot from the nfs share at my dev pc. http://pastebin.com/3AUv2AQn
<n01>
gosh, anyone willing to offer me a job?
<hno>
gzamboni, that's crashing during fbconsole initialization it looks like.
<ssvb>
oliv3r: if you are analyzing the disassembly of libvecore.so, then you should find a lot of details pretty fast
<oliv3r>
n01: hum?
<oliv3r>
ssvb: I was, both android and linux versions
<ssvb>
oliv3r: at least the details about how the decoding is set up are the first priority
<oliv3r>
ssvb: i wrote up what I know so far up on linux-sunxi
<oliv3r>
ssvb: also traced out calling graphs for jpeg
<oliv3r>
Just trying to find a way to put it up on the wiki
<n01>
oliv3r: lol, I am fed up with my current job, just complaining about life :D
<oliv3r>
n01: lol i see :)
<gzamboni>
:( nfs boot would avoid me from removing and putting the sdcard in each change.
<hno>
gzamboni, try disabling fbconsole in your kernel build.
<gzamboni>
let me try
<ssvb>
oliv3r: good, it's nice to see some progress
<oliv3r>
ssvb: heh, it's making my head smoke though; so dunno if there's progress really, or if there will be more :p
<oliv3r>
ssvb: want to setup my cubieboard and test some drivers first :)
<ssvb>
oliv3r: about the "firmware", I think it must be somewhere because this thing seems to be programmable (the decoding bugs exposed by decoding certain video formats can be fixed)
<oliv3r>
ssvb: i haven't found anything resembling it yet
<ssvb>
oliv3r: when doing code coverage tests, are all the relevant functions executed on the cortex-a8 core?
<oliv3r>
ssvb: que? :D
<ssvb>
oliv3r: using valgrind or something else, you can do some tracing and check which parts of code were involved
<oliv3r>
ah, i have no clue, am studying the asm :)
<ssvb>
oliv3r: you mentioned that you looked at jpeg, are you able to decode jpeg images using libvecore api and some simple test program?
<oliv3r>
ssvb: i looked at asmbly only
<oliv3r>
haven't compiled anything
<oliv3r>
only documenting/investigating
<rellla>
ssvb: weightp=1 issue isn't there with libhybris/android, right?
<ssvb>
rellla: yes, it's fixed with libhybris/android
<rellla>
oliv3r: :P
<oliv3r>
rellla: ok i was wrong! :p
<oliv3r>
but don't tell AW about libhybris yet, or they'll just wrap their android lib in libhybris and stop caring about native linux libs
* rellla
deleted the last line ....
<ssvb>
oliv3r: only looking at the code without trying to trace it is not very efficient
<hno>
Ah, nice. didn't remember CedarXWrapper.
<gzamboni>
hno: still didnt work. Do i have to remove the virtual memory paging ? i have a paging error now: http://pastebin.com/DTGSrvHZ
<oliv3r>
ssvb: well it's a combination of looking at assembly, and learning how to use IDA :)
<rellla>
i got answer from allwinner. any questions i should include in my response?
<oliv3r>
ssvb: next step is trying if we can mmap a file and call InitJpegHw();
<hno>
gzamboni, it's still failing in the same place.. which has nothing at all to do with NFS booting.
<ssvb>
oliv3r: maybe try some simple video codec first, such as mpeg1? make a simple test program, trace it and disassembly the relevant parts
<oliv3r>
ssvb: i think jpeg might be simpler, and i belive only mpeg2 and 4 are supported, didn't see any mpeg1 references yet
<gzamboni>
the only changes i did to the sun4i defconfig is CONFIG_IP_PNP=y and CONFIG_ROOT_NFS=y
<wingrime>
add printf for mpeg regs dumping or file write
<oliv3r>
All standards-compliant MPEG-2 Video Decoders are fully capable of playing back MPEG-1; interesting :)
<wingrime>
as AW call this before every access to VE
<oliv3r>
wingrime: is their crappy implementation actually an advantage to us? e.g. every single reg call; makes it easier to RE?
<wingrime>
yes,
<wingrime>
it REALY call this every time it write byte to MMIO
<ssvb>
oliv3r: but jpeg restart markers are a pita and inhibit huffman optimizations, so I guess this might be done entirely in software
<ssvb>
wingrime: just take the freaking tracer and run it
<wingrime>
JpegHwDec aslo call this every time
<oliv3r>
wingrime: makes sense, JpegDecodeRaw() { SetJpegFormat(); InitJpegHw(); JpegHwDec(); } is basically what is done
<wingrime>
but it not all
<oliv3r>
FillJpegHuffmanTable()
<wingrime>
read_markers
<wingrime>
first_marker
<wingrime>
get_dqt
<oliv3r>
yeah, but that's all mostly libjpeg() stuff
<wingrime>
get_dht
<oliv3r>
I doubt they changed much/anything there
<wingrime>
get_sof
<oliv3r>
but atleast that leaves us with reference code
<wingrime>
next_marker
<oliv3r>
get_soi() is dfeined, but not even used :)
<ssvb>
oliv3r: does it mean that you might have found the firmware? :)
<oliv3r>
ssvb: lol all the other get_ sources are called, but i think they simply used jdmarker.c and didn't bother with get_soi();
<oliv3r>
get_soi() is 5? assembly lines so I doubt that's the firmware :p
<ssvb>
oliv3r: yeah, it is possible that there is some dead code
<wingrime>
Jpeg maybe deadcode
<oliv3r>
lol
<wingrime>
H264 for example not call get_base every time
<oliv3r>
FillJpegHuffmanTable looks quite expensive, but only done on init; I wonder how much performance impact mjpeg has, as that does a lot of jpeg decoding
<ssvb>
oliv3r: make a simple test program first :)
<oliv3r>
yeah, that's probably next on the list :D
<oliv3r>
from my inital mpeg2 readings, it's based on mpeg2, so jpeg may aswell use mpeg2 Video Engine
<oliv3r>
since jpeg does YUV4:4:4 and YUV:4:2:2, but mpeg1 only does YUV:4:2:0 (thought that is the most common jpeg colorspace)
<wingrime>
olvi3r: it possible use small amount abilites form mpeg engine
<oliv3r>
if I would write a hardware accelerator with my little knowldge
<oliv3r>
i'd do components tbh; like huffman, idct, fft, motion estimation I think can be done too
<oliv3r>
all seperate functions that could work with tons of codecs
<oliv3r>
but that's just me :)
shine|coffee is now known as shine|listeningj
shine|listeningj is now known as shine|list_jazz
<ssvb>
oliv3r: the problem is that coordinating the work of all these components and passing data around may be pretty expensive
<oliv3r>
maybe, but in the case of the A10, you load 'data' into sram, i would not be supprised that the video engine does its work on the sram
<oliv3r>
so something like transform_colorspace(); for example, would do this in hardware on the sram. it's up to the client to retrieve this data/modfiy this data, or to call the next operation
shine|list_jazz has quit [Quit: Leaving]
<oliv3r>
you just leave the data in sram while it's being processed
<lunra>
In the case of the FFT, it would be nice if you could queue up a large FFT job, call doFFT() and the process is blocking until the coprocessor completes the task, but I'm not sure how you'd go about implementing that without some serious kernel hax
<oliv3r>
when everything is done, you replace it with the next bit
shineworld has joined #linux-sunxi
<oliv3r>
lunra: it's done in userpsace atm
<ssvb>
oliv3r, wingrime: are there really no attempts to get the address of some chunk of code and copy it somewhere to a fixed hardware address (to SRAM or anywhere else)?
<oliv3r>
ssvb: but this flexibility would allow you to use any 'component' of the hardware, to be used for anything else (who knows what)
<lunra>
like some kind of while(!*done_flag)sched_yield(); or something within the client program?
<oliv3r>
ssvb: i just saw references to SRAM, which is likly, since C1 is VE sram
<ssvb>
oliv3r: even if the data exchange is done via SRAM, the timing between kicking different hardware blocks (waiting for completion of one block before kicking the other) would be a bit of a challenge
<ssvb>
oliv3r: a dedicated core could just sit in a busy loop
<lunra>
It would be nice if we could find a raise interrupt flag so that the coprocessor does not have to busy loop. Anyway I best stop being an armchair soldier here XD
<rm>
ARM chair!
<lunra>
haha rm :D
<lunra>
brb, integrating a cubieboard in my chair
<oliv3r>
I-frames can be considered effectively identical to baseline JPEG images
<oliv3r>
there we go
<oliv3r>
now i undrstand
hipboi|cubie has quit [Ping timeout: 256 seconds]
_BJFreeman has joined #linux-sunxi
_BJFreeman is now known as BJfreeman
vicenteH has joined #linux-sunxi
sankasan has joined #linux-sunxi
<libv>
oliv3r: did ianb not choose the right tools?
<oliv3r>
libv: i think most of those questions have answered themselves partially
<oliv3r>
but where IS ianb! :(
hipboi|cubie has joined #linux-sunxi
<libv>
oh, and capture, then replay, then reproduction
<oliv3r>
aye, if only we had full cedar register level documentation, that would help a bunch
<oliv3r>
but i gota work on some other things first :S as I said, soo much to do, so little tim
<ssvb>
rellla: btw, about allwinner's cedarx replay, did it look like they are willing to cooperate?
<oliv3r>
trying to reproduce initially
<ssvb>
oliv3r, wingrime: if you are really committed to reverse engineering cedarx, I can help you with the ianb's hw registers access tracer
<oliv3r>
i'm affraid i'm atm lacking technical knowledge and rather focus on a10 'regular' support?
tinti has quit [Read error: Connection reset by peer]
hansg has joined #linux-sunxi
BJfreeman has quit [Quit: had a good time]
rz2k has joined #linux-sunxi
<hno>
gzamboni, yes,the kernel crashes & burns for me with 4.8. 4.7 works fine.
Undertasker has joined #linux-sunxi
ganbold_ has joined #linux-sunxi
vicenteH has quit [Ping timeout: 268 seconds]
Tartarus has quit [Excess Flood]
Tartarus has joined #linux-sunxi
_jm has joined #linux-sunxi
sankasan has quit [Quit: Leaving]
<shineworld>
I've just now updated uImage and modules from last github/linux-sunxi/linux-sunxi 3.0 applying them to github.com/cubieboard/openbox and when attach the ACCESSORY DEVICE I've got that [sw_udc] goes literally crazy with an infinite message loop in TTL debug port: http://pastebin.com/1WmTY89s
<shineworld>
and lsusb sign: Bus 001 Device 021: ID 18d1:0005 Google Inc.
<shineworld>
instead of usual: Bus 001 Device 021: ID 18d1:0003 Google Inc.
<shineworld>
also after have to removed connection and re-connect to PC for ADB
<shineworld>
TTL debug port at this point don't throw out nothing
<shineworld>
I'm finishing an ADK-Device simulator running on Linux if someone is interest to try what don't works in accessory support
eebrah is now known as eebrah|away
paulk-desktop has quit [Quit: Ex-Chat]
Yaku321 has joined #linux-sunxi
<shineworld>
seem don't exit by accessory mode so every time I connect the usb to computer the system re-enter in accessory mode with all data
<ssvb>
wingrime: nice, we just have one problem - to get an idea about the purpose of these hardware registers we still need a small jpeg decoder test program and a trace of its execution with a log of all registers access (how many times, which values, etc.)
<ssvb>
wingrime: with just disassembly alone you are moving into a guesswork territory too much
<wingrime>
now I have more ... whait I copy to paste
<ssvb>
just make this freaking jpeg example yourself
<ssvb>
what's the problem?
<libv>
wingrime: do you really think that i did mali by just pointing a disassembler at it and then calling it free software?
<libv>
wingrime: or did i first have to go and learn about opengles2 and render a triangle with a binary driver?
<wingrime>
do you realy think all posible with data flow ? in world there is some crypto / checksums that not even possible with dissasembler
tinti has joined #linux-sunxi
<libv>
wingrime: you said yourself that this jpeg stuff is supposedly trivial
<wingrime>
trivial but it may be dead code
<wingrime>
but mpeg decoder are same
<wingrime>
for mpeg124 and mjpeg and jpeg
<libv>
wingrime: you have some serious logical issues there
<wingrime>
maybe
<libv>
why, if it is dead code, are you bothering with it?
<libv>
why is supposed dead code a reason for disassembly and then misappropriation, and not for proper REing?
<wingrime>
becose jpeg stuff have shared things with mpeg
<wingrime>
many shared things
<wingrime>
FFT for example
<wingrime>
If i generaly understand jpeg decoding procedure it make much simpler understand general mpeg decoding
<wingrime>
and make sure that not use some sorts of firmware
<libv>
none of that explains why you chose to do what you are doing like you are doing it
<libv>
s/like/the way/
<wingrime>
I need firstly know registers that code touches
<wingrime>
and have it or not have some conditions here
<libv>
no.
<libv>
first you get a working jpeg decoder based on the binary.
<libv>
wingrime: if you are not willing to go through the motions, then please go away.
<wingrime>
libv: I have no intension write code for cedar I only want make some register reference
<wingrime>
at least now
<wingrime>
ssvb: are you still here
<ssvb>
yes
<wingrime>
what revisions numers a10 have
<wingrime>
I just find that logic check some unmbers that may be a10/cedar revisions
<ssvb>
better ask mnemoc
<wingrime>
for example 0x1623
<wingrime>
or 0x1620
<wingrime>
crap
<wingrime>
logic differs for cedar versions
<ssvb>
relax, that's the last thing to worry about at the moment
<wingrime>
good things
<wingrime>
I find that 4 bit at 0x0 reg are control reset logic
<wingrime>
now will looking for irq logic
ijc has quit [Read error: Operation timed out]
<wingrime>
realy funny
<wingrime>
ve have reg with version
<wingrime>
who can dump regs with uboot ?
<wingrime>
I not have uart now
ijc has joined #linux-sunxi
<wingrime>
I can add version detection to cedar driver
<wingrime>
avs here realy stud
_BJFreeman is now known as BJfreeman
sanka has joined #linux-sunxi
sanka has quit [Client Quit]
n01 has joined #linux-sunxi
<CountryGeek>
Q: so I wrote a pwm driver a couple of days ago not adhering to any standard (pwm not compiled into my kernel) and I'm working on an lradc driver now.
<CountryGeek>
How should I implement? Include in pwm driver, not adhering to any standards?
<CountryGeek>
New driver, not adhering to any standards?
<CountryGeek>
build a new kernel with iio and implement an iio driver?
eebrah|away is now known as eebrah
<n01>
CountryGeek: uhm, does not exist a pwm framework?
<CountryGeek>
There is one, but it wasn't compiled into my kernel (hansg port of Fedora), so I did a sysfs interface by hand
<CountryGeek>
:-[
<CountryGeek>
And I think the pwm interface has changed since 3.4 anyway
<CountryGeek>
I'm afraid that if I do a driver within the iio system that it won't be generally useful if that system isn't in many / any standard kernels
* CountryGeek
has a pcDuino
<CountryGeek>
n01 - what would you do?
<wingrime>
mnemoc: are you here?
<n01>
CountryGeek: (1) cannot you recompile the kernel with the framework? (2) if you want to mainline the driver you must use the framework :)
<ssvb>
TheSeven: what's wrong with your TV? which kernel version are you using?
<CountryGeek>
n01 - good point - that's my dilemma. I don't want to have to support the CountryGeek kernel though, just the pwm / lradc code.
<CountryGeek>
Do any boards ship with the iio subsystem enabled?
<CountryGeek>
* ship with kernels with
<n01>
CountryGeek: you just have to maintain the driver eventually, people willing to use it have to eventually recompile the kernel by themselves
<n01>
oor, of course, just enable it in defconfig :)
<CountryGeek>
n01 - k - maybe I'll reach out to hansg and see what Arch has enabled. That's the right answer
vinifm has joined #linux-sunxi
<CountryGeek>
n01 ??
<n01>
CountryGeek: I mean: if u write a driver for sunxi-pwm requiring the pwm framework to be enabled in the kernel, just modify the defconfig for sunxi enabling framework and driver
* n01
dinner-time
<CountryGeek>
n01 - Oh - k...
<CountryGeek>
Thanks!
<vinifm>
someone successfully cross compiled VLC for sunxi?
shineworld has joined #linux-sunxi
<wingrime>
4svb: where can I get mmio records form CedarXWrapper
<TheSeven>
ssvb: my TV set works with the A10, at least on android, but its panel resolution is just crappy. it is too dumb to configure overscan though, and I vaguely remember berrybooted linaro ubuntu getting clipped off at the edges
<TheSeven>
I'm more annoyed by a whole lot of PC monitors just refusing to work with the A10 (which do work fine with a raspberry pi), and by the unavailability of hardware-accelerated XBMC (at least back when I tried it, did something move in the meantime?)
<CountryGeek>
TheSeven: I'm not having any trouble like that with my pcDuino with Fedora - have you tried that?
<TheSeven>
which of my various troubles are you referring to?
<CountryGeek>
the stock Lubuntu looks like ass though
<CountryGeek>
"pc monitors refusing to work"
<TheSeven>
I think I generally just got a black screen, no matter which combination I tried
<TheSeven>
however I might be mixing up some of the ARM boards that I have sitting around here
<TheSeven>
I just remember that the only device that just worked out of the box with PC (DVI) monitors was the raspberry pi, which is just too crappy to do anything useful with it :P
* CountryGeek
is jealous hearing of "mixing up arm boards"
<TheSeven>
all the powerful boards (panda, cubie, odroid-x2) had some issues
<oliv3r>
CountryGeek: remember, we have the sunxi-3.0 and sunxi-3.4 kernels here (the one hansg uses), but those will eventually go away; effort is being put into rewriting the whole shebang for mainlining, which started at 3.10. if you want something useable now, use 3.4 and use your driver as is. submit it to the ML and let someone else or you, port it eventually to 3.11+ for eventual ML support.
<nove>
and have made a partial tracer using valgrind
<rellla>
ssvb: :)
<ssvb>
nove: welcome on board :)
<nove>
ssvb: let's make allwinner to change is name to allopen
<CountryGeek>
oliv3r: K - Hopefully the iio subsystem won't change that much. Currently working on getting a kernel with iio enabled.
<CountryGeek>
I was originally happy that I finished the driver, now I'm embarrassed that it doesn't adhere to standards :-[
<nove>
i did some traces with vp8, and i think i can see all
<oliv3r>
rellla: oh wow really, lets see if heis gonna pop by here :p
<ssvb>
nove: valgrind is a good choice
<nove>
ssvb: a bit slow, with the huge vlc
<nove>
in the traces that i made, is easy to see the vp8 bitstream and vp8 coefficients tables or what si called
<nove>
i think is a fixed function engine
<ssvb>
have you tried to replay these traces?
<nove>
not yet
<nove>
but
<nove>
i can't see where is the decoded frame
<wingrime>
nove: can you add special page for traces and one per trace with parameters and link to file
<nove>
that is other problem, how the the legally of sharing this
<wingrime>
actualy you did log
<wingrime>
not see any problem
<libv>
wingrime: you have a history of not seeing problems.
<nove>
libv, hi
<wingrime>
libv: do you see some copyright stuff in logs?
<wingrime>
you like stollman
<libv>
wingrime: well... you do not see me offering up replayed frames of q3a for instance...
<wingrime>
libv: problem that cedar have revisons
<nove>
that is a question that i would like to ask, how to RE cedar without making legal mistakes?
<wingrime>
some decoders have some if (verson == 0x1620)
<wingrime>
nova : best way analyze logs
<nove>
what can be done, and what can't be done, of the legal point of view
<wingrime>
rewrite code from dissassembly directly illigal
<wingrime>
do logs i think legal
<wingrime>
as read/write regs for testing
<TheSeven>
depends on whether you've accepted an EULA that has further restrictions, but generally there's a DMCA copyright exception that covers reverse engineering for compatibility purposes
<wingrime>
DMCA usa only
<TheSeven>
note that I may not give legal advice though
<TheSeven>
generally speaking, a "chinese wall" approach is typically used to avoid legal problems
<TheSeven>
one team documents stuff from reading disassemblies, another team reimplements the stuff from the documentation, pokes at the hardware, and possibly figures out further details
<wingrime>
TheSeven: one word about world: Russia
<wingrime>
I am there, so does not care
<oliv3r>
CountryGeek: any driver is a good driver ;) i had started on pwm; so if you post yours, i think i can mold it into 3.12 terms with the PWM framework :)
<nove>
yes, i understand the clean room way
<wingrime>
nove: black box
<oliv3r>
nove: i was still backreading, welcome! Check out our wiki, http://linux-sunxi.org espcially ianb's cedarX wrapper
<nove>
but i don't understand by per example, how lima is done
<CountryGeek>
oliv3r: But I'm working on a lradc driver now and would like to do it right the first time
<TheSeven>
nove: I don't think lima did really care about the legal aspects, from what I read they aren't doing a clean room approach at all
<CountryGeek>
Damn Fedora - missing libgcc.a for arm
<nove>
how can the people doing the reverse engineering, can then later write the drivers
<TheSeven>
nove: because nobody would care to go after the reverse engineers - they'd rather hunt down the commercial users of the driver with patent claims
<oliv3r>
CountryGeek: well the lrdac is basically a low-resolution DAC, and is abused as keyboard by tablets etc
<CountryGeek>
yeah - I want to use it as a DAC - dunno if it's got enough res or not...
<ssvb>
TheSeven: do you have a link confirming that "lima did really care about the legal aspects"?
<oliv3r>
CountryGeek: there is the input framework, and i'm sure there's some sort area where DACs go (i know there's digital pots etc in the kernel allready) but how to 'tie those two together' good quesiton. we do have the lrdac driver as sun4i-keyboard i belive
<oliv3r>
CountryGeek: lrADC, not dac :p
<TheSeven>
ssvb: "I don't think ..."
<CountryGeek>
oliv3r: wouldn't it go into the iio framework?
<libv>
i definitely cared about the legal aspects.
<nove>
then what is the best way to do cedar, without scaring allwinner?
<ssvb>
TheSeven: yes (sorry for a bad quote), but the link please :)
<oliv3r>
nove: i think libv didn't do the register bit, he actually puzzled it out, by sending data, capturing outputs etc, not reading asm etc
<CountryGeek>
oliv3r: What is your development environment like? Distro? Compilers?
<oliv3r>
nove: well i think the lima approach is best legally speaking. and scaring AW, i think they are actually violating the GPL with cedarx, there's most likly code in there that is copy/pasted from GPL code
<TheSeven>
ssvb: I don't have any particular link to back that up, but the general approach (dissecting that shader compiler, the same developer building a new one, directly comparing outputs, ...) seems equally fishy as most other RE projects to me, but I'm sure libv knows better, so better ask him
<oliv3r>
CountryGeek: gentoo, i installed the toolchain via crossdev and crosscompile using the sunxi-bsp
<TheSeven>
I'm looking at this mostly from a perspective about what I know about US copyright law (which isn't terribly much), no idea whether something else might apply here
<nove>
well, i don'r have any intention to touch the binary blob
<oliv3r>
nove: we have a page up on linux-sunxi.org about cedarX and our findings how things stick together
<libv>
as that was the only thing they had to state.
<libv>
i have used disassembly in my lima work
<oliv3r>
nove: you need to run the binary blob and compare outputs at the least :p
<nove>
oliv3r, yes, but not lookin inside
<libv>
but i have always used this as documentation to figure out what is going with the command stream i was looking at
<libv>
and i damn well make sure that this disassembled or manually decompiled stuff _never_ leaves this encrypted disk i am on
<libv>
as i do not own that code
<libv>
as i stated before...
<libv>
first you create a testcase
<libv>
then you grab what's flying about
<libv>
then you replay that
<libv>
then you pry apart what you just replayed.
<wingrime>
libv: paranoid soluton - live in russia
<libv>
and you keep a nice git history of how you go about prying this apart.
<libv>
wingrime: whatever.
<libv>
wingrime: i have 10kloc of limare, 2kloc of wrapper, a heap of test cases with the equivalent limare code, and an especially ported q3a to show for it
<wingrime>
libv: so much paranoid
<libv>
but before i did all that, i sat down, and thought things through, and even wrote up, in quite great detail, how i was going to tackle this.
<libv>
and i am still working that same plan 2 years on
<oliv3r>
libv: gotta remember that you are quite experience
rellla has quit [Remote host closed the connection]
<libv>
indeed, and i have employed targetted disassembly, objdump and loads of manual work, during the past 10ys, as needed, but never as a goal in itself, and i never let any code go out that i did not write myself to achieve the same hw results
<wingrime>
there is russian joke about it "termo-anal-cryptoanalysis" - soldering iron in your butt and you say any pass form any disk, so encrypted stuff not so helpfull like looks
<libv>
actually, compared to the hours of simply throwing stuff at the hw, trying to figure out how .tw or so code worked, or how the meagre docs that ATI was forced to hand us fitted together, i have done amazingly little assembly
<oliv3r>
libv: that's suprising, as around RE hangs this vibe of asm
<libv>
99.9% is throwing stuff at the hw and seeing what happens.
<wingrime>
libv: black box analysis
<libv>
wingrime: in soviet russia...
<wingrime>
libv: libv: try IDA
<wingrime>
libv: most powerfull instrument for RE
<libv>
wingrime: try a real brain instead.
<nove>
wingrime, why waste time to understand a complex binary, when the hardware is more simple
<libv>
oliv3r: anyway, ianb made a fantastic start with his wrapper
<wingrime>
I ask ianb toaday
<libv>
oliv3r: now it is mostly a task of writing tests, and seeing what falls out, and then reproducing again
shineworld has quit [Quit: Leaving]
<wingrime>
he send me some new info according logs
<wingrime>
and some logs
<wingrime>
I must think about freqency analysis
<ssvb>
nove: are you sure that this code is talking directly to hardware and not doing some kind of rpc communication with another programmable core?
<nove>
ssvb: in that case isnt the programmable core, the hardware
<wingrime>
ssvb: may be something in Opencores.org
<wingrime>
thay possible can steal some verilog code
<wingrime>
new dedicated core is open risc from opencores
<nove>
ssvb, still have to look more in detail
<nove>
ssvb, what i guess, is that for vp8 it use the same engine as h264, as is in the kernel sources side
<oliv3r>
libv: live and learn, i found it 'interesting' to twirl around the blob for a bit and see what was there, function names, how it all fits together etc. but ianb's wrapper seems deffinatly the way forward in this case
<lkcl>
wingrime: the technique that libv came up with is extremely effective. i did the same thing for the samba nt domains reverse-engineering. i did *not* need IDApro.
<lkcl>
the only point at which IDA was needed was for the crypto algorithms, and that turned out to be 30 lines of code.
<nove>
ssvb, is to early
<oliv3r>
ssvb: actually, there's something called ISP in the kernel bit of cedar. its s strange name, and might be something to program the Video Engine imo
<libv>
oliv3r: oh, it is extremely helpful to look at the structure of things by looking at symbols
<libv>
oliv3r: but that should never be the start of development
<lkcl>
the *entire* remainder of the 150,000 lines of code was done by replay bootstrapping, in a 2x2 matrix, one packet at a time, server-to-client, client-to-server.
<lkcl>
packet not understood: don't give a shit, just replay it at the relevant point in the conversation until it *is* understood.
<ssvb>
nove: I'm kinda curious about what they could screw up to trigger this bug
<oliv3r>
libv: if you know what you are doing, then yes, but if you are just curious first, you try to look under the skirt a bit first, so you can get an idea wha tthey did and what you can expect ;) it's all you got if oyu have zero experience
<oliv3r>
and it's fun to do :)
<oliv3r>
ssvb: you mean because the use the same codec software, and only the front end glue is differnt between those two libs?
<wingrime>
lkcl: Ida are pro instrument can do more with it when you know how to use 1) cross references 2) function types and arguments 3) decomiller on x86 4) comments, naming, auto strucures and constants
<nove>
lkcl: hi, what do you think that will be the reaction on allwinner to a a cedar RE project?
<oliv3r>
ssvb: i would not be supprised they took the webm code for VP8. i mean, heck, look at cedarX, it's all kinds of random code glued together
<oliv3r>
ssvb: and we _know_ they initially did the entire soc on an FPGA
<wingrime>
oliv3r: now *every* SOC have R&D on FPGA
<oliv3r>
so having a big fpga, and also add this pre-made verilog code ... why not. there's divx/h264 decoders on opencores too, and i don't even have to look to know there'll be mpeg2 cores too. so it's quite easy to just grab some of it
<oliv3r>
actually, as wingrime pointed out, they 'used' the openrisc core i think or what was it for the sr100 (from my head) so they deffinatly know where to get it