Hi, firstly great work on all this. Ive only just become a roomba owner and was reading this thread with great anticipation...
I was only halfway through page 1 when I started trying to guess where the "iRobot have asked me to stop" post would come :p
I just assumed it would be the last post just before all the secrets popped out, and yup, there it was. Still, you have to respect how far they let you go!
Just wanted to share the output from my 4000 series,
processor-sleep
key-wakeup 0100000000000000
slept for 1806 minutes 843 ticks
2006-08-19-1814-L
Roomba board revision: 1 (dirt-cheap-roomba)
battery-current-quiescent-raw 519 battery-current-zero 505
device-detect
2006-08-19-1814-L
This was using a BT dongle and waking it up with the DD pin.
I was a little surprised to see the dirt-cheap-roomba comment! Has anybody else seen this?
Anyway, off to play with the SCI now.
Greg's Scratchpad Thread on Roomba Comm Hacking
-
electronrancher
- Posts: 2
- Joined: April 4th, 2007, 4:11 pm
anyone still reading this thread?
it looks like i'm coming into the game rather late, but i'll still try to revive this discussion. i recently bought a roomba red (4100) and it's fantastic!
however, i can't help thinking that with a bit more control over the system i could really have some fun. sure playing music on the bot is sure a great time, but it gets old quick
i have no intent of posting copyrighted code, algorithms, or other information detrimental to irobot. however, if i write my own random bytes and pass them to the bootloader i don't see how that would violate any agreements. sure the bot will die spectacular deaths from time to time, but as long as i don't molest the bootloader block my happy little bot is only an osmo away from being revived.
personally, i suspect that the bootloader is using most of the same techniques as 99% of other bootloaders i've seen.
1) Trap the reset vector and redirect to bootloader
2) Wait a while to see if we get SCI comm or some other signal that we want to access the bootloader.
3) If SCI comm is a bootloader command, continue in bootloader. Now we have a few basic functions such as erase flash and write flash. I'd love to have a read flash, but iRobot seems tight enough to avoid this simple error.
4) If no good comm, jump to the real software.
there are two basic ways of doing this..
A) Bootloader stored somewhere at the top of flash, and the program software needs to have a long jump as it's first instruction. This is dangerous since a bad write may not put this long jump back so you can't get to the loader. Based on G's experiments of stage 3-ing his roomba with the loader still living - this is probably not the case.
B) Bootloader entirely contained in low flash, and the program software always exists above it. Safer, since the loader has no need to erase itself but it means the software can't be located at it's usual spot - sometimes interrupts, etc have to be annoyingly redirected.
I can't tell just yet, but I do note that Freescale's demo loader cleverly starts in low flash, then copies it'self to RAM and relocates the RAM high so the remainder of the low flash block can be manipulated. It's always tempting to use demo code, so I would not be surprised if iRobot's loader uses a similar technique.
it looks like i'm coming into the game rather late, but i'll still try to revive this discussion. i recently bought a roomba red (4100) and it's fantastic!
however, i can't help thinking that with a bit more control over the system i could really have some fun. sure playing music on the bot is sure a great time, but it gets old quick
i have no intent of posting copyrighted code, algorithms, or other information detrimental to irobot. however, if i write my own random bytes and pass them to the bootloader i don't see how that would violate any agreements. sure the bot will die spectacular deaths from time to time, but as long as i don't molest the bootloader block my happy little bot is only an osmo away from being revived.
personally, i suspect that the bootloader is using most of the same techniques as 99% of other bootloaders i've seen.
1) Trap the reset vector and redirect to bootloader
2) Wait a while to see if we get SCI comm or some other signal that we want to access the bootloader.
3) If SCI comm is a bootloader command, continue in bootloader. Now we have a few basic functions such as erase flash and write flash. I'd love to have a read flash, but iRobot seems tight enough to avoid this simple error.
4) If no good comm, jump to the real software.
there are two basic ways of doing this..
A) Bootloader stored somewhere at the top of flash, and the program software needs to have a long jump as it's first instruction. This is dangerous since a bad write may not put this long jump back so you can't get to the loader. Based on G's experiments of stage 3-ing his roomba with the loader still living - this is probably not the case.
B) Bootloader entirely contained in low flash, and the program software always exists above it. Safer, since the loader has no need to erase itself but it means the software can't be located at it's usual spot - sometimes interrupts, etc have to be annoyingly redirected.
I can't tell just yet, but I do note that Freescale's demo loader cleverly starts in low flash, then copies it'self to RAM and relocates the RAM high so the remainder of the low flash block can be manipulated. It's always tempting to use demo code, so I would not be surprised if iRobot's loader uses a similar technique.
-
THX-1138
- Robot Master
- Posts: 2805
- Joined: June 23rd, 2005, 8:16 pm
- Location: United States of America
Welcome to RoombaReview.com electronrancher!Definitely revive this thread! As long as we stay kosher I am all for it. Currently I can not contribute much in means of programming (Majored in Electrical Engineering : Power Plants, High Voltage transmission and distribution) but anything else I will dip my hand into is fair game. gssincla contributed much to this thread, as well as vic and surely will get response from him soon. Enjoy your stay, looking forward to new ventures.
-
vic7767
- Robot Master
- Posts: 15556
- Joined: January 14th, 2006, 7:31 pm
- Location: Haughton Louisiana - USA
lectronrancher, along with THX-1138 and myself, welcome to this thread. Your assumption about the bootloader function is shared by several of us in the hacker forum. Thats why we have all held on to our OSMO cpu hardware and usually have both the Blue and the Gray/Black standing by in case of an emergency flash. Just about ready to test the OSMO with the BDM function and see if it is locked. Then gssincia got loaded down at work and as you can see his last post was just after getting married and new work projects.
-
electronrancher
- Posts: 2
- Joined: April 4th, 2007, 4:11 pm
thanks for the welcome, guys!
before i go erasing my firmware, i'd first like to know that i could bring the roomba back alive.
since my bot is a roomba red (mfg after october 05) it would typically not use either osmo - they are recommended for older bots. but for a bot that had been stage 3'd, i assume an osmo would be the only way (as of today) to re-load it to a working state.
but what about the scheduler remote - does it have the full firmware to install or just the scheduler upgrade? i'd prefer to buy a scheduler remote but if it does not contain the full firmware i think i will need an osmo as well.
i couldn't tell from gssincla's experiments, but if anyone has a scheduler and an osmo would you mind stage 3'ing your bot and seeing if scheduler brings it fully back, or do you need to osmo first?
before i go erasing my firmware, i'd first like to know that i could bring the roomba back alive.
since my bot is a roomba red (mfg after october 05) it would typically not use either osmo - they are recommended for older bots. but for a bot that had been stage 3'd, i assume an osmo would be the only way (as of today) to re-load it to a working state.
but what about the scheduler remote - does it have the full firmware to install or just the scheduler upgrade? i'd prefer to buy a scheduler remote but if it does not contain the full firmware i think i will need an osmo as well.
i couldn't tell from gssincla's experiments, but if anyone has a scheduler and an osmo would you mind stage 3'ing your bot and seeing if scheduler brings it fully back, or do you need to osmo first?
-
vic7767
- Robot Master
- Posts: 15556
- Joined: January 14th, 2006, 7:31 pm
- Location: Haughton Louisiana - USA
electronrancher, we have some knowledge based on the earlier robots that the scheduler upgrade does not add the Circle dance or the Open Interface software that is contained in the OSMO. The firmware you have already contains the ROI and I'm not sure you would be able to recover from a stage 3 command. You might want to see if you could find an earlier Roomba possibly on ebay to play with. I'm sitting here with 5 Roomba Reds all of which were rescued from the circle dance and were obtained on ebay at a very low cost.
It's been a while since I've been involved with any reverse engineering (the original xbox), but it looks like the same misinterpretations are still around. I don't think the law (in the US) has changed significantly in the last few years (though there have been some affirming cases of interest).
First I'd suggest looking at Chamberlain v. Skylink, which basically ruled that the anti-circumvention clause is only enforceable if it they can "demonstrate that the trafficker's device enables either copyright infringement or a prohibited circumvention." This makes it clear that there are two classes of circumvention: prohibited and not. Also check out LexMark v. SCC, which rules out the possibility of using copyright to restrict interoperation.
What this means to us:
1) it is (and always has been) illegal to distribute copyrighted data (like firmware files) in their original or any transcribed form (ie: encrypted or not)
2) the DMCA makes it illegal to distribute (not create) a utility that enables copyright infringement (by, for instance, uploading and/or decrypting an encrypted firmware file)
3) the DMCA does *not* make it illegal to reverse engineer the protocols required for interoperability, or to provide the algorithms or encryption keys required to interoperate with such devices.
So, I can write a utility which encrypts unencrypted firmware images such that they will work when loaded into the Roomba. I can provide a utility which downloads those encrypted firmware images and installs/flashes them. I can upload, decrypt, and disassemble firmware files as a required step in the creation of interoperable firmware. I cannot release that uploaded/decrypted firmware in any form. I cannot distribute the program I used to access/decrypt the firmware file.
I can publish all of the details about the encryption process. I can publish none of the tools allowing the decryption process. If the cipher is symmetric (the same tool does both tasks) then my right to interoperate trumps the restrictions on circumvention.
-SpeedBump
First I'd suggest looking at Chamberlain v. Skylink, which basically ruled that the anti-circumvention clause is only enforceable if it they can "demonstrate that the trafficker's device enables either copyright infringement or a prohibited circumvention." This makes it clear that there are two classes of circumvention: prohibited and not. Also check out LexMark v. SCC, which rules out the possibility of using copyright to restrict interoperation.
What this means to us:
1) it is (and always has been) illegal to distribute copyrighted data (like firmware files) in their original or any transcribed form (ie: encrypted or not)
2) the DMCA makes it illegal to distribute (not create) a utility that enables copyright infringement (by, for instance, uploading and/or decrypting an encrypted firmware file)
3) the DMCA does *not* make it illegal to reverse engineer the protocols required for interoperability, or to provide the algorithms or encryption keys required to interoperate with such devices.
So, I can write a utility which encrypts unencrypted firmware images such that they will work when loaded into the Roomba. I can provide a utility which downloads those encrypted firmware images and installs/flashes them. I can upload, decrypt, and disassemble firmware files as a required step in the creation of interoperable firmware. I cannot release that uploaded/decrypted firmware in any form. I cannot distribute the program I used to access/decrypt the firmware file.
I can publish all of the details about the encryption process. I can publish none of the tools allowing the decryption process. If the cipher is symmetric (the same tool does both tasks) then my right to interoperate trumps the restrictions on circumvention.
-SpeedBump
I saw that, and my concern is more that people not be coerced into giving up their right to tinker through lack of understanding.
I'm interested in doing data gathering using the Roomba, but I can't do so through the SCI. I'd need access to the raw sensor inputs and the ability to timestamp transitions highly accurately (in the millisecond or better range). I'm not at all interested in the iRobot code and behaviors, but I can't gather the data I want without firmware level access, and iRobot has made it nearly impossible to get that type of access without decrypting their existing firmware.
I had hoped there would be a way to create a boot loader that could provide both the security iRobot seems to think necessary and the possibility of unencrypted firmware. However it doesn't look as though the freescale CPU can revoke read access to any portion of the flash (for example the location where the bootloader/decrypt keys are stored). Lacking this means that allowing any unsecured executable code compromises the encryption method. Given that, the only way forward is a one-way method...you could unsecure but never then go back to iRobot's encrypted firmware. I doubt iRobot has much interest in allowing that, but perhaps...
I'm interested in doing data gathering using the Roomba, but I can't do so through the SCI. I'd need access to the raw sensor inputs and the ability to timestamp transitions highly accurately (in the millisecond or better range). I'm not at all interested in the iRobot code and behaviors, but I can't gather the data I want without firmware level access, and iRobot has made it nearly impossible to get that type of access without decrypting their existing firmware.
I had hoped there would be a way to create a boot loader that could provide both the security iRobot seems to think necessary and the possibility of unencrypted firmware. However it doesn't look as though the freescale CPU can revoke read access to any portion of the flash (for example the location where the bootloader/decrypt keys are stored). Lacking this means that allowing any unsecured executable code compromises the encryption method. Given that, the only way forward is a one-way method...you could unsecure but never then go back to iRobot's encrypted firmware. I doubt iRobot has much interest in allowing that, but perhaps...
-
vic7767
- Robot Master
- Posts: 15556
- Joined: January 14th, 2006, 7:31 pm
- Location: Haughton Louisiana - USA
No they really didn't discuss the mechanics involved but Greg and I discussed it and naturally we both already had BDMs. We thought that once one of our Roombas crapped out it would become a candidate for flashing. This hasn't happened yet. But, now that I have a 535 model all the earlier ones are worried !
-
Gordon
- Robot Master
- Posts: 4304
- Joined: April 6th, 2005, 2:02 am
- Location: Santa Ynez, CA USA
- Contact:
JU1 test access
Hey there lads, Vic & SpeedBump: Have you ever noticed on the Disco's main_PWB, at a position roughly 20mm from the SW-corner of U8 (the MCU) there is a curious six-via (large vias) 2X3 array of test-pads called JU1?
Scooba's PWB also has this array.
While rev-engrg the circuits of which I have been interested, the ckt between JU1 and U8 just popped out of the tracing; so I thought I'd draft its schematic and ask if anyone can make sense of what to do with it. A little googling gave hints that a partial BDM connection might do something here (don't ask for details--I've already forgotten them, since the googling was done months ago!).
See the attachments. If this looks interesting, I can scrutinize the hardware to ensure the JU1 circuit is complete.
EDIT: The hardware has been re-examined. Two resistors have been added to Schematic_14 (version 071019).
{Schematic14,Schematic#14}
Scooba's PWB also has this array.
While rev-engrg the circuits of which I have been interested, the ckt between JU1 and U8 just popped out of the tracing; so I thought I'd draft its schematic and ask if anyone can make sense of what to do with it. A little googling gave hints that a partial BDM connection might do something here (don't ask for details--I've already forgotten them, since the googling was done months ago!).
See the attachments. If this looks interesting, I can scrutinize the hardware to ensure the JU1 circuit is complete.
EDIT: The hardware has been re-examined. Two resistors have been added to Schematic_14 (version 071019).
{Schematic14,Schematic#14}
- Attachments
-
- Pull-up res R247 and filter-res R249 are new in this version.
- schematic#14.gif (11.97 KiB) Viewed 9928 times
-
- JU1_photo_detail.jpg (71.83 KiB) Viewed 9928 times
Last edited by Gordon on February 25th, 2009, 12:51 pm, edited 3 times in total.
-
vic7767
- Robot Master
- Posts: 15556
- Joined: January 14th, 2006, 7:31 pm
- Location: Haughton Louisiana - USA
Thanks Gordon,,,, if and when you get time it would be great if you could check if the circuit is complete. I suspect it is but not sure. Also I believe it is a test point access to the MCU. Greg and I discovered that the MCU is locked to BDM access but we can always gain access to the MCU once the pinout is known.
Greg used his BDM to dump the contents of the bootloader program contained in the OSMO. Here's a pic of that J test port.
The leads on the right have the following assignment:
White - VDD
Black - BGND
Red - RESET
Green - GND
Greg used his BDM to dump the contents of the bootloader program contained in the OSMO. Here's a pic of that J test port.
The leads on the right have the following assignment:
White - VDD
Black - BGND
Red - RESET
Green - GND
- Attachments
-
- OSMO_BDM.JPG (118.71 KiB) Viewed 9948 times
-
Gordon
- Robot Master
- Posts: 4304
- Joined: April 6th, 2005, 2:02 am
- Location: Santa Ynez, CA USA
- Contact:
Its been checked, and I found two resistors missing! A repaired version is shown above.vic7767 wrote:Thanks Gordon,,,, if and when you get time it would be great if you could check if the circuit is complete.
Yes, it seemed likely that all bases would be covered!... Also I believe it is a test point access to the MCU. Greg and I discovered that the MCU is locked to BDM access...
What does that mean?... but we can always gain access to the MCU once the pinout is known.
Pray tell, what do those four wires connect to when that OSMO is doing something?Greg used his BDM to dump the contents of the bootloader program contained in the OSMO. Here's a pic of that J test port.
The leads on the right have the following assignment:
White - VDD
Black - BGND
Red - RESET
Green - GND
The 2X3 array of pads which I thought curious, also boils down to four connections, but assignments differ a bit:
Pad-[1,1] = sys_gnd
Pad-[1,2] = filtered ~+5V output
Pad-[1.3] = +5V_reg output
Pad-[2,1] = sig to MCU (U8) pin-23*
Pad-[2,2] = not used
Pad-[2,3] = not used
------------------------
* Pin-23 is the Background Debug, Tag High & Mode pin.
------------------------
Well, Vic, don't struggle to educate me in this arena, I don't have any plans to mess with the MCU--except, maybe, to stimulate some of its inputs, then watch what related outputs do!
-
vic7767
- Robot Master
- Posts: 15556
- Joined: January 14th, 2006, 7:31 pm
- Location: Haughton Louisiana - USA
There is a nice little device made by P&E Micro that provides the BDM function, connects to the leads on the OSMO and when the OSMO is powered (9 volt battery) the BDM is connected to a PC via USB cable. P&E software downloads the OSMO image as well as the communications program and bootloader program. Of course it's in MCU machine language instructions.
- Attachments
-
- USB_BDM.jpg (103.02 KiB) Viewed 9916 times
-
biolizard89
- Posts: 20
- Joined: December 20th, 2007, 3:33 pm
- Location: Oklahoma, USA
- Contact:
Hey, I'm wondering if there's been any progress lately on the firmware updater or a homebrew firmware. I'm using a Create, can I assume that a firmware updater for a Roomba will work on a Create? Would a homebrew firmware likely be written in ASM or C/C++? I'm hoping C/C++ just because it's more readable (and thus an ASM-illiterate person such as myself could comprehend it), but I suppose when system resources are scarce, ASM could be necessary. Does any of this stuff involve physical or electrical mods to the Roomba/Create? How much RAM does the MCU have access to? iRobot told me the amount of SRAM, but they didn't give me the amount of standard RAM.
I would absolutely LOVE to have an open-source C/C++ firmware for the Create. Mainly because I'm unable to use a command module or remote control of any kind, but I'd love more complex behavior than is supported in OI scripts on my Create. I don't care if I void the warranty, I've voided the warranty on most of my robotics equipment years ago. Nor do I care if I permanently remove the iRobot software; I have no use for it. I don't need anything really complex, just some C++ libraries for the MCU that provide reasonably high-level access to the sensors and motors (e.g. a function to set a motor's PWM, or read a drop sensor's value).
Hope this project isn't abandoned.
Thanks in advance.
I would absolutely LOVE to have an open-source C/C++ firmware for the Create. Mainly because I'm unable to use a command module or remote control of any kind, but I'd love more complex behavior than is supported in OI scripts on my Create. I don't care if I void the warranty, I've voided the warranty on most of my robotics equipment years ago. Nor do I care if I permanently remove the iRobot software; I have no use for it. I don't need anything really complex, just some C++ libraries for the MCU that provide reasonably high-level access to the sensors and motors (e.g. a function to set a motor's PWM, or read a drop sensor's value).
Hope this project isn't abandoned.
Thanks in advance.
-Biolizard89
-
vic7767
- Robot Master
- Posts: 15556
- Joined: January 14th, 2006, 7:31 pm
- Location: Haughton Louisiana - USA
Biolizard89, there was a little off-line work done where a OSMO image was dumped into an .S file, a small updater program was written, a Roomba could be sent commands to place it into a pre OSMOed stage and the .S file pumped into the Roomba.
Then concerns began to occupy the thread about folks getting the firmware update program and then finding a .S file of an OSMO image without buying it so the project has stopped.
You could still use a Roomba or Create and read about how to erase the MCU memory. Once that is done you have access to reprogram the MCU with whatever machine language instructions you want to compile.
Then concerns began to occupy the thread about folks getting the firmware update program and then finding a .S file of an OSMO image without buying it so the project has stopped.
You could still use a Roomba or Create and read about how to erase the MCU memory. Once that is done you have access to reprogram the MCU with whatever machine language instructions you want to compile.
-
biolizard89
- Posts: 20
- Joined: December 20th, 2007, 3:33 pm
- Location: Oklahoma, USA
- Contact:
Hmm, this is very interesting. How worried should I be about bricking the Create if I try this? (I do not own the Create which I would be experimenting on; my school owns it; therefore I don't want to have to come to them after doing something stupid and say "Sorry, I just bricked your Create!") If I totally can't get anything to work, will an OSMO allow me to restore the MCU's program? Would I have to dump something from the MCU or OSMO first for that kind of restoration to work? Is there any information available on erasing and reprogramming the MCU (sorry if I'm being dense; I could not find any information on it except for the MCU part number)? Does anyone have documentation on the memory mapping or hardware for the Create, e.g. how to access motors and sensors? (I'd love to try messing with it in C++, but I don't know where to start.) And does reprogramming the MCU involve any physical or electrical mods to the Create?vic7767 wrote:Biolizard89, there was a little off-line work done where a OSMO image was dumped into an .S file, a small updater program was written, a Roomba could be sent commands to place it into a pre OSMOed stage and the .S file pumped into the Roomba.
Then concerns began to occupy the thread about folks getting the firmware update program and then finding a .S file of an OSMO image without buying it so the project has stopped.
You could still use a Roomba or Create and read about how to erase the MCU memory. Once that is done you have access to reprogram the MCU with whatever machine language instructions you want to compile.
Thanks for the fast reply!
-Biolizard89