One more thing on this subject:
We should try to check out datasheets of the target chip to find out what is protocol overhead and what is the firmware code block...
OR
I don't remember the chip's part number, but it should be revealed from inside of the box - right from the chip/Windows driver VEN_/DEV_ ID. I remember I found some other fw for this chip on the internet. We should try to upload that "other" firmware to the chip. It would not work for the ILDA decoder, but it should show us the way...
;-)
Blackhead
-----Original Message----- From: brmlab-bounces@brmlab.cz [mailto:brmlab-bounces@brmlab.cz]On Behalf Of Felipe Sanches Sent: Wednesday, December 15, 2010 6:02 AM To: Brmlab: Hackerspace Prague (main discussion) Subject: Re: [Brmlab] Laser Hacking #3
Awesome!!! Congratulations!
Now, we have to figure out the meaning of the usbinit log. Because simply using it without understanding it is similar to our previous condition of using proprietary software.
Actually, if our theory that this usbinit performs a firmware upload is correct, then it is precisely proprietary software that we are still relying on and that must be fixed.
The benefits of understanding the firmware upload protocol is that we can create our own free firmware for the device, which opens up several interesting possibilities for improving the laser display.
Well... I've been dealing a lot recently with this issue of devices that require non-free firmware in order to work properly. That means I already have some ideas of strategies that we can try:
Strategy 1:
Inspect the windows driver trying to find blocks of data that are similar to the usbinit log. This can be useful to give us a clearer idea of which bytes in the log are firmware code and which ones are just part of the fw upload protocol.
Strategy 2:
try to disassembly some portions of the usbinit log using a 8051 disassembler. Try to identify something that looks like valid code. Use that information to thing again about the structure of the firmware upload protocol.
Lets do it?
cheers, Felipe Sanches
On Wed, Dec 15, 2010 at 1:41 AM, niekt0 niekt0@hysteria.sk wrote:
Hi,
we spent night in brmlab and laser initialization from linux is finally working. Also we fixed some bugs. (everything is in svn)
We just pust a simple video on our youtube, check soup.brmlab.cz.
enjoy;)
n. On 12/14/10, Felipe Sanches juca@members.fsf.org wrote:
I am writting a blogpost about the laser projector project and I need some videos. Is it possible for you to shoot short videos (around 30 seconds or a minute) of these things, please?
- the simple vector drawing tool (run bedit.py and draw a bit)
- the wallburner (scerensaver) with bezier curves - it is example3.py
thanks, Felipe Sanches
On Mon, Dec 13, 2010 at 8:17 AM, Pavel Ruzicka ruza@ruza.eu wrote:
if you need some advice regarding chaosvpn/agoralink let me know. ive connected brmlab to that vpn
ruza
On 12/12/2010 07:59 PM, Ax wrote:
Laser was moved to other room and connected to server there. Results are quite impressive: http://picasaweb.google.com/axtheb/Brmlab Hopefully we can arrange working webcam and some vpn soon... Felippe, do you have access to agoralink/chaosvpn? Using that we can get you link quickly [http://brmlab.cz/project/chaosvpn] And, please, give me commit rights to the repo so I can put my util lib and the rocket game there.
Ax _______________________________________________ Brmlab mailing list Brmlab@brmlab.cz http://rover.ms.mff.cuni.cz/mailman/listinfo/brmlab
-- e-mail: ruza@ruza.eu www: http://ruza.eu http://brmlab.cz
Brmlab mailing list Brmlab@brmlab.cz http://rover.ms.mff.cuni.cz/mailman/listinfo/brmlab
Brmlab mailing list Brmlab@brmlab.cz http://rover.ms.mff.cuni.cz/mailman/listinfo/brmlab
_______________________________________________ Brmlab mailing list Brmlab@brmlab.cz http://rover.ms.mff.cuni.cz/mailman/listinfo/brmlab