Thought you guys might like to see a gratuitous pic of the SPMP8000 after decap. We’ll soon be posting some hi-res die photos but for now you’ll have to be satisfied by this sneak preview. The die ID says: SunplusmM LAC005 (or perhaps LACOOS) so get your google on!

We are still swamped with other projects and unable to post any updates on the SPMP8k project, but not to worry - SPMP8k development will continue soon!

Until then, we have a short article about an AES encryption trainer that we had lying around and decided to spruce up for your entertainment.
As you probably know, AES (the Advanced Encryption Standard) is the latest encryption standard endorsed by NIST, generator and owner of US standards.  It’s main advantage over the previous standard, DES, is the ease of hardware implementation.

It mainly consists of byte swapping, rotation, and XOR’s and is extremely annoying to try to trace.  It’s actually not too bad up until the MixRows phase if you’re using lookup tables but can be easy to get lost in if you’re not paying attention or taking good notes.  We were once looking for a way to inspect the output of each individual operation of each round - we resorted to hacking in printf’s into someone else’s code but didn’t like their implementation in a few points.

What we really wanted was a printout that closely followed the round-by-round example given in the official AES implementation pdf (FIPS 197), including an example of the AES key expansion.  That is a beautiful document with clear and concise descriptions of all aspects of the encryption - a truly excellent read.  In addition, examples of both the AES key expansion and state data for every round is given - but not the same example, unfortunately!  What we wanted was a similar style example printout for any input and key pair we could think of, for either encryption or decryption.  And we wanted to change keys and inputs on-the-fly and watch nuances propagate through the algorithm.  Not for any hacking sense, just to verify some ideas about optimizing some implementations of AES in FPGA’s and other circuitry.  In the end, we developed our own little tiny AES-128 encryptor/decryptor that pukes out all of the internals of key expansion and encryption rounds so you can inspect them line-by-line.

Behold the Openschemes AES-128 Trainer!

Fig 1 - Screenshot of Openschemes AES128 Encryption Trainer

The trainer is an AES encryptor/decryptor example program written in VB6.  We call it a trainer, or example program because it only works on one 16-byte block at a time so it is really no good for encryption.  In addition, the source code is optimized for readability and understanding instead of speed or efficiency.

Table lookups abound to avoid implementing Galois multiplication in VB - not a terrribly hard thing to understand but it really interrupts the flow of the read if you know what we’re saying…!  And the number one reason it’s unsuitable for heavy-duty encryption - it’s in VB!  It runs fast enough for our needs and still has a nice “hold on, I’m doing something” delay that makes you feel like something really important is going on. 

In case you’re unable to read the screenshot data, the default data filled in the key and plaintext fields are the hex data from the 00112233… example from the FIPS document.  The key expansion of hex key 000102030405060708090A0B0C0D0E0F follows:

Key Expansion Example:

00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
D6 AA 74 FD D2 AF 72 FA DA A6 78 F1 D6 AB 76 FE
B6 92 CF 0B 64 3D BD F1 BE 9B C5 00 68 30 B3 FE
B6 FF 74 4E D2 C2 C9 BF 6C 59 0C BF 04 69 BF 41
47 F7 F7 BC 95 35 3E 03 F9 6C 32 BC FD 05 8D FD
3C AA A3 E8 A9 9F 9D EB 50 F3 AF 57 AD F6 22 AA
5E 39 0F 7D F7 A6 92 96 A7 55 3D C1 0A A3 1F 6B
14 F9 70 1A E3 5F E2 8C 44 0A DF 4D 4E A9 C0 26
47 43 87 35 A4 1C 65 B9 E0 16 BA F4 AE BF 7A D2
54 99 32 D1 F0 85 57 68 10 93 ED 9C BE 2C 97 4E
13 11 1D 7F E3 94 4A 17 F3 07 A7 8B 4D 2B 30 C5

Followed by the fully annotated encryption workbook on the right side, showing the state of the ciphertext as it propagates through each round.  As in FIPS197,  the ciphertext (in hex) is 00112233445566778899AABBCCDDEEFF.  Workbook data for all ten rounds of AES-128 are as follows:

AES Encryption Internals Example:

Encryption Workbook…
round[0].in 00 11 22 33 44 55 66 77 88 99 AA BB CC DD EE FF
round[0].k  00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

round[1].in 00 10 20 30 40 50 60 70 80 90 A0 B0 C0 D0 E0 F0
round[1].sb 63 CA B7 04 09 53 D0 51 CD 60 E0 E7 BA 70 E1 8C
round[1].sr 63 53 E0 8C 09 60 E1 04 CD 70 B7 51 BA CA D0 E7
round[1].mc 5F 72 64 15 57 F5 BC 92 F7 BE 3B 29 1D B9 F9 1A
round[1].k  D6 AA 74 FD D2 AF 72 FA DA A6 78 F1 D6 AB 76 FE

round[2].in 89 D8 10 E8 85 5A CE 68 2D 18 43 D8 CB 12 8F E4
round[2].sb A7 61 CA 9B 97 BE 8B 45 D8 AD 1A 61 1F C9 73 69
round[2].sr A7 BE 1A 69 97 AD 73 9B D8 C9 CA 45 1F 61 8B 61
round[2].mc FF 87 96 84 31 D8 6A 51 64 51 51 FA 77 3A D0 09
round[2].k  B6 92 CF 0B 64 3D BD F1 BE 9B C5 00 68 30 B3 FE

round[3].in 49 15 59 8F 55 E5 D7 A0 DA CA 94 FA 1F 0A 63 F7
round[3].sb 3B 59 CB 73 FC D9 0E E0 57 74 22 2D C0 67 FB 68
round[3].sr 3B D9 22 68 FC 74 FB 73 57 67 CB E0 C0 59 0E 2D
round[3].mc 4C 9C 1E 66 F7 71 F0 76 2C 3F 86 8E 53 4D F2 56
round[3].k  B6 FF 74 4E D2 C2 C9 BF 6C 59 0C BF 04 69 BF 41

round[4].in FA 63 6A 28 25 B3 39 C9 40 66 8A 31 57 24 4D 17
round[4].sb 2D FB 02 34 3F 6D 12 DD 09 33 7E C7 5B 36 E3 F0
round[4].sr 2D 6D 7E F0 3F 33 E3 34 09 36 02 DD 5B FB 12 C7
round[4].mc 63 85 B7 9F FC 53 8D F9 97 BE 47 8E 75 47 D6 91
round[4].k  47 F7 F7 BC 95 35 3E 03 F9 6C 32 BC FD 05 8D FD

round[5].in 24 72 40 23 69 66 B3 FA 6E D2 75 32 88 42 5B 6C
round[5].sb 36 40 09 26 F9 33 6D 2D 9F B5 9D 23 C4 2C 39 50
round[5].sr 36 33 9D 50 F9 B5 39 26 9F 2C 09 2D C4 40 6D 23
round[5].mc F4 BC D4 54 32 E5 54 D0 75 F1 D6 C5 1D D0 3B 3C
round[5].k  3C AA A3 E8 A9 9F 9D EB 50 F3 AF 57 AD F6 22 AA

round[6].in C8 16 77 BC 9B 7A C9 3B 25 02 79 92 B0 26 19 96
round[6].sb E8 47 F5 65 14 DA DD E2 3F 77 B6 4F E7 F7 D4 90
round[6].sr E8 DA B6 90 14 77 D4 65 3F F7 F5 E2 E7 47 DD 4F
round[6].mc 98 16 EE 74 00 F8 7F 55 6B 2C 04 9C 8E 5A D0 36
round[6].k  5E 39 0F 7D F7 A6 92 96 A7 55 3D C1 0A A3 1F 6B

round[7].in C6 2F E1 09 F7 5E ED C3 CC 79 39 5D 84 F9 CF 5D
round[7].sb B4 15 F8 01 68 58 55 2E 4B B6 12 4C 5F 99 8A 4C
round[7].sr B4 58 12 4C 68 B6 8A 01 4B 99 F8 2E 5F 15 55 4C
round[7].mc C5 7E 1C 15 9A 9B D2 86 F0 5F 4B E0 98 C6 34 39
round[7].k  14 F9 70 1A E3 5F E2 8C 44 0A DF 4D 4E A9 C0 26

round[8].in D1 87 6C 0F 79 C4 30 0A B4 55 94 AD D6 6F F4 1F
round[8].sb 3E 17 50 76 B6 1C 04 67 8D FC 22 95 F6 A8 BF C0
round[8].sr 3E 1C 22 C0 B6 FC BF 76 8D A8 50 67 F6 17 04 95
round[8].mc BA A0 3D E7 A1 F9 B5 6E D5 51 2C BA 5F 41 4D 23
round[8].k  47 43 87 35 A4 1C 65 B9 E0 16 BA F4 AE BF 7A D2

round[9].in FD E3 BA D2 05 E5 D0 D7 35 47 96 4E F1 FE 37 F1
round[9].sb 54 11 F4 B5 6B D9 70 0E 96 A0 90 2F A1 BB 9A A1
round[9].sr 54 D9 90 A1 6B A0 9A B5 96 BB F4 0E A1 11 70 2F
round[9].mc E9 F7 4E EC 02 30 20 F6 1B F2 CC F2 35 3C 21 C7
round[9].k  54 99 32 D1 F0 85 57 68 10 93 ED 9C BE 2C 97 4E

round[A].in BD 6E 7C 3D F2 B5 77 9E 0B 61 21 6E 8B 10 B6 89
round[A].sb 7A 9F 10 27 89 D5 F5 0B 2B EF FD 9F 3D CA 4E A7
round[A].sr 7A D5 FD A7 89 EF 4E 27 2B CA 10 0B 3D 9F F5 9F
round[A].k  13 11 1D 7F E3 94 4A 17 F3 07 A7 8B 4D 2B 30 C5

ciphertext  69 C4 E0 D8 6A 7B 04 30 D8 CD B7 80 70 B4 C5 5A

Which should give you just about all the data you’d need for debugging your own AES hardware or software.  You can input the key as 16 hex bytes (32 characters) or 16 ASCII characters, or even convert back and forth with clever misuse of the software.  So this trainer should be able to generate encryption/decryption examples for damn near any AES128 situation you can think of.

For continued discussion as well as the source code and binaries (and a small puzzle from us to you!), please continue on to the next page.

Continued on Next Page         Jump to Page 2

1. Already rewritten the FRMorp to dump raw NAND pages
2. Muttered to yourself that we’re idiots for not releasing the raw tool

Well, you’re in luck.  We’re hereby releasing nandoori to the masses so high-speed raw USB nand dumping is now at your fingertips!  As we warned in previous articles, this tool can generate lots of data in a short time.  For example, if your device has 8GB of flash, you can dump the entire 8GB (2,097,152 pages at 4k per page) by using the command

nandoori 0×0 0×200000 slow.bin

Yes, this will take a long time.  And will probably contain mostly blank pages ($FF) so is not terribly worthwhile.  But the important thing is that you CAN do it if you want to.  And idiot-proofing is one thing that we’re totally against here at openschemes.  We’ll warn you of potential bricks (but the SPMP8k seems brick-proof so far) but otherwise, we think you should enjoy rebuilding your system after each horrible technical mishap.  One piece of advice that we always pass to new engineers is:

Make every mistake once.  From simple typos to connecting power supplies backwards - go ahead!  Boom, smoke, hooray!  From breaking the upstream build to all-layer-change disasters, feel free!  But only once.  Learn from your mistakes, fix the problem, and don’t let it happen again.

Follow that rule, and your first few engineering years will be hellish, as they would be anyway.  But after that, you’ll rise to the top and continue in an excellent path.

Enough musing, let’s get back to the tech.  nandoori expects arguments of a start page, a stop page, and an output file.  It will fetch a single page if start and stop are the same number.  It expects both numbers to be hex, although it is not required for them to start with 0x.  In our examples, we will always start with 0x just to be clear and unambiguous.

Some interesting pages are:

• 0×0 - The RedBoot PAT table.  This page lists all the pages that contain the RedBoot.mmc file from BOOT.IMG.
• 0×2 - One of the INIT PAT tables.  Hardwired to 0×2, so this must mean that the RedBoot PAT table cannot exceed 8k bytes, or the bootware cannot exceed 2044 pages and therefore cannot be larger than 8,372,224 bytes.  That’s pretty huge and pretty awesome if you ask us.
• 0×12 - The other INIT PAT Table.  For the actual DRAM init, IIRC.
• 0×80, 0×100, 0×180 - Three copies of DRAM config data plus RedBoot startup script.  Found when working on reflash.  We thought they were just used to store the ScanRam config, but it turns out the device won’t boot eCos if they’re blank.  Important enough to have three copies!
• 0×2000 - The ROFS PAT table for allocating SOFT.IMG.  Different format than RB’s PAT table.  Haven’t studied too much.
• 0×2080 - Start of SOFT.IMG.

When we use this tool, it’s either for inspecting a single page of nand, such as..

nandoori 0×0 0×0 RBPAT.bin

Or for checking the validity of our flash tools by comparing before and after for the entire boot section, such as…

nandoori 0 0×300 BOOT.bin

Your usage may vary, these are just some simple examples.

Please keep in mind that the SPMP8k uses block-wise nand.  In our case, one block is 0×80 (128) pages.  This means that the smallest bit of flash that you can erase is one block: 0×80 pages, or 512k (524,288 bytes).

We mention this because we will soon release a raw write tool that can be used for flashing byte-wise backups of your device for the extra paranoid.  It will take nandoori dumps as input and write them to the device.  If it does not have 0×80 pages worth of data to write, you will be left with blank nand where you should have code = fail!  So if you are intending to back up your device, or parts of your device - PLEASE MAKE THEM MULTIPLES OF 0×80 PAGES (512k).

For general hax0ring, use any page length you want.  It’s only for backups intending to be rewritten that the 128-page multiple must be used.  OK - continue on to page 2 for the source and executables.  Enjoy your spicy and delicious nandoori!


Continued on Next Page            Jump to Page 2       

It looks like quite a few people have already gotten the FRMorp tool up and running, which is fantastic!  However, when we tried to compile and run it under Linux, it was less than perfect out of the box - sorry!

After a little twiddling and recompiling, we’ve got a new version that should work on either win or on Linux.  Some notes for the Linux side, and other improvement notes:

• You need libusb and the dev libs.  Try yum install libusb* if you can’t link.
• Makefile included, as we kept forgetting to type -lusb when building
• You must run as sudo or su in order to have authority to detach the standard USB driver and use LIBUSB.  Else you’ll die with error -1.
• Uncomment the #define LIN line at the top when building on Linux and the extra detach instruction will be automatically included.
• Made the bombout error messages a little more verbose to help those that may be debugging on Linux.

Other than that, there’s not much else to say.  make  ./frmorp   enjoy.  Zip file on page 2.

Continued on Next Page…    Jump to Page 2   

What is needed is the reverse of FRMPro - a tool that, via USB, can extract the Bootware IMG file and the Software IMG file quickly and simply.  That is exactly what you’ll get with

FRMorp - USB IMG Dumper for the SPMP8k

What, no link?  Well, we have to put it on the second page to count the article views.  It’s even gotten worse since so many people are using adblockers to remove our Google ads.  C’mon people, they pay for the cost of the site.  Or would, someday, we’re hoping.  But if you guys keep stripping the ads off this page then we can guarantee you that eventually, you’ll kill off the site.  We’re not EDN here with heinous full-page takeovers, just simple ads in between the pages of the articles.  Some of them are actually pretty good, cheap USB logic analyzers and the like.  We’ll keep weeding out the stupid ones whenever we see them, too.

Soapbox OFF!  Back to the tech.  FRMorp - get it, the reverse of pro?  We’re hilarious, we know!  FRMorp is designed to get back the BOOT_Vxx.IMG and SKxx_yy_zz.IMG files that are programmed into the device using FRMPro.  For this and other articles, we will call this the BOOTware and the SOFTware.

Now this data is not just two files in a directory somewhere - it’s actually broken up and placed in various locations in low flash memory.  The program does a fair bit of reconstruction, so if you want to read through the source you may want to use this article as a guide.

There are three main functions in FRMorp.  They were written in such a manner that they *should* be easily rippable to new programs, or compiled to a lib or dll for general-purpose usage.  The main functions are:

1. getBOOTFSfile - Given a starting page in nand flash, getBOOTFS file will go searching for a PAT - page allocation table.  If it finds one, it will dump all the data that is marked in that file’s PAT to a file on your HDD.  Normally, you get RedBoot’s PAT from the first good page.  You get the first assistant program we called DRAM_Init1 from the first good page after RedBoot’s PAT.  And another assistant we called DRAM_Init2 from the first good page after 0×12.  So getBOOTFSfile is called 3 times with the arguments 0, n+1, and 0×12 to get three files: RedBoot.mmp, DRAM_Init1.mmp, and DRAM_Init2.mmp.  These are the constituents of BOOT_Vxx.IMG.
2. packBOOTimg - This was going to be a seperate tool, but we said WTF.  Give it the names of the three bootware files from getBOOTFSfile, and it will pack you up the full bootware img file BOOT.IMG.  This file contains the 3 files from above, but adds some stupid headers and a completely retarded checksum that Sunplus must have throught of after drinking melamine-tainted milk or something.  FRMPro requires these headers and checksum, so we must pack the files or learn to flash ourselves.  Soon, my friends, soon.
3. getSOFTimg - This one is still VERY primitive.  As far as we can tell, the device reads page 0×2000 to find the length of the software partition, and then the ROFS is blindly written starting at page 0×2080.  But that seems highly unreliable due to bad blocks in the nand, etc.  So for now, getSOFTimg also reads blindly.  The output that we get is a perfect binary comparison to what we flash to the device, but someday this routine may need to be updated with some additional smarts.

That’s where we need your help.  If you dump an IMG that is not a perfect binary comparison to what you’ve programmed into your device then we REALLY want to hear from you.  We’ll send you nandoori and you’ll make us some raw data dumps that we will use to debug the issue and update the FRMorp tool.

But please, go easy on us.  If you see we’re already flooded with users commenting about bad dumps, please don’t post duplicate issues.  Once we address their problems with an update, then please DO post if that update does not cure your problem as well.

Thanks in advance!

Ok folks, time for the obligatory page turn and more info on FRMorp and how to use it.

Continued on Next Page…      Jump to Page 2    

It really is the 3rd pin on the 4th side, but we’re not interested in counting the number of pins to see if it’s the 334th or 212th or what.  Here’s the pic.   Let us know if your device does not use this pin location, that could be very interesting info.

But back to our problem - what will we do?  We can try to hex edit our 8000_MMI.RAP file but boo hoo, it just gets rejected.  And that only means one thing:

Checksum.

We love ‘em.  Sometimes.  They’re like a lock on a door that has no reason to be there.  It just makes people wonder what’s inside.  And once certain people get to wondering what’s inside…  Well, then it’s become a challenge, hasn’t it?

Today we will only talk about simple checksums using summation.  XOR is not too bad, but when you get into hashing things it all becomes much more difficult, and the article would be MUCH longer.

We rate this one a 2 - simple , but tries to be a bit tricky.  Worth a try, and great for beginners.

Barring any other ability to see into the brains of the device, one way to determine the algorithm for a checksum is to investigate the differences required to pass/fail.
Change a byte.  It should fail.  Now make a couple educated guesses about a second byte to change, and see if any of those pass.  Use the data from those trials to extend further guesses until you have the algorithm.  Some canned guesses for you to start with are:

DIFF: If the original byte increased by 1, decrease the byte next to it by 1.  You must also try the byte 2 down, 4 down, etc  for word, dword, etc sized checksums.  This is best for the type of checksum where the entire file is summed, and then a checksum is computed that will make the sum equal to 0, or $FFFFFFFF, or some magic number.

SUM: If the original byte increased by 1, you would also increase the “test” byte by 1 as well.  This is good for locating checksums where all bytes in the file are summed up and the sum is stored somewhere.  If you increase the sum by 1, you can increase any corresponding byte in the file by 1 and pass.

For very simple patches like nopping out an instruction or two, you can probably get away with just those two techniques and compute out your new sum, where it is either + or - the value of the change you are making.

That’s breaking a window.  We want a key.

By checking which bytes we need to diff, we quickly found that this checksum was 32-bits wide.  ie - incrementing byte n required byte n+4, or n+8, etc  to be decremented in order to pass.

Looking at the headers of a few files showed one bunch of bytes that had no reason to be there, and was always different.  Sure we accidentally changed the time/date byte once or twice and scratched our head when our sum didn’t work.  But we got it eventually.

The checksum initially looked like a simple CHK32, but running that checksum on our file did not give matching data.  We began modifying single bytes further down the file until…  Bang!  We failed.  Did we give up and die, or did we crack another beer and keep going?

Which will YOU do?

Continued on Next Page…      Jump to Page 2  

It seems that when people want to change their device configuration, they are opening the IMG file and hex editing the XML’s.  That will certainly work, but is probably rather difficult for the beginner.

Another approach would be to dump your device or dump an IMG file to the full directory of files, edit them as you please, and then repack into an IMG and reflash the device.  At that point, you are free to add/remove/replace any images, binaries, or XML you like.  I smell a lot of background image customization tools on the horizon!

As we mentioned, one very slow way to get a full backup of software from an unknown device is to dump it via the serial port.  It works, and today we successfully repacked a file  dump into a new IMG and flashed that image to our semi-bricked PMP to bring it back to life.  But the process takes time.

If you happen to have your IMG file on hand, you can dump it to your hard drive in just seconds using the sprdump tool.  This is the tool that we mentioned in the last article, and we’ve received permission from the author to release it.  But in order to estimate how many people have actually downloaded it, we must force you to go to the next page.

Continued on Next Page…       Jump to Page 2

One interesting note is that there are three filesystems on the flash:

BOOTFS: Bootcode (2nd stage) and Redboot.  Starts at page 0.
RO(M)FS: System Software.  Starts at page 0×2000
FAT: The Mass storage you can see over USB.   Takes up the rest of the flash.

The first fielsystem is BOOTFS - this is our name by the way, just calling it the first thing that comes into mind.  This filesystem resides in the first few pages of flash.  It consists of several one-page (4k) functions and then the RedBoot binary.  This is what you’d find in the firmware files such as BOOT_V15.IMG.

The ROM bootstrapper (+++MMP RomCode…) searches the first few NAND pages to try to find the magic bytes 33 CC AA 55.  This signifies the start of a set of very crude allocation tables which point to two binary files responsible for initializing the DRAM, and the RedBoot binary.

Bootstrapper loads and executes the DRAM_Init() from flash, and once it has 16MB of DRAM, it load RedBoot into that and hands off control.

RedBoot either gets interrupted by you for nefarious purposes, or it loads a script which tells it to boot /IMAGE/8000_MMI.RAP.   Woo, directories - now we’re getting fancy!
This second filesystem is called ROMFS (we saw ROFS somewhere too) but it does not seem to be compliant with the actual ROMFS that was around long before the SPMP.  It’s still a fairly simple filesystem though, and can be explored through RedBoot by mounting the device /dev/nf2 and using the ls commands as we’re sure you’ve already done.

ROFS/ROMFS seems to be the whole kit & kaboodle of the eCos platform, containing executables, codecs and emulators as well as tons of XML files for configuration.  This filesystem is what is contained in the big (>50MB) software files generated by the SKLOGO tool.

But SKLOGO simply takes different binary chunks and pastes them together - other than hex editing (which seems to work pretty well ala Jaime) it is difficult to make significant changes to the file system.  And that’s something that you KNOW we’re going to want to do.

In order to have free reign over the filesystem, it is easiest to unpack the entire ROFS filesystem to it’s individual files and directories and modify it at well.  Then, it’s pretty easy to use the Sunplus tools to repack and reflash your new filesystem to the device.

SIDE NOTE:

We were very disappointed/entertained to see the following entries in the directory dump:

/IMAGE/GAME/GAME_CONFIG.TXT 22963
/IMAGE/GAME/GBA_BIOS.BIN 16384
/IMAGE/GAME/GPSP.BIN 776004

Because it means that not only has Sunplus ripped off GNU/eCos, they have also ripped off Exophase as well as Nintendo.  I mean, couldn’t you have changed it to data.dat1 and data.dat2?  No shame..  Still a nice IC tho, so we’re happy to continue plugging along in the hopes of getting SOMETHING legal onto this little device.

The bright side is that we’ve invented a new game: Take a shot whenever you find something pirated, stolen, or used without permission in the Sunplus ‘8k PMP.  We’ve been hammered for days.

OK, OK - on to the dump tool..   Let us preface this with the warning that if you already have a copy of your firmware, there are much easier ways to extract it’s goods than the following tool.  This tool is a glorified console script that can also convert ASCII to bin.  Downloading the entire software will take time.  (5.25*Size)/115.2kbaud as a rough estimate, where 5.25 is a rough multiplier based on the ascii conversion and overhead.

We’re talking hours, folks.  About 6-7h if your RS-232 port is reliable.  If you’re like us and want an exact copy of one device to another, then this is a little faster than a nand dump so it might be a viable option.  A more likely use would be to download all the XML config data for your device to merge into a resource directory of another firmware.  But IMO, letting an inanimate object work itself to death all night while we sleep is not a big deal.

If you’re not scared off yet, then please

Continue to Next Page…   Jump to Page 2

At this point, you’re probably ready to do some actual development.  Great!  One thing you may come to realize (if this is your first embedded project) is that you start with NOTHING.  Absolutely nothing. You can write all the software you want, but if you are writing in C you will quickly find that even the most trivial built-in functions need to be implemented specifically for your device.  We’ll start this article with a short discussion of how to get a small toolbox full of functions, and then continue with a C example program that can use those functions.

The end result of all this effort will be a console interaction such as the following.

RedBoot> go -c 0×200000
+do_go
image sel: 0, image_sel_set: 0
rmvb enable!
Mask interrupts on all channels
ID-CACHE sync and invalidate
set up a temporary context. workspace_end=0×00effdd0, entry=0×00200000
switch context to trampoline. workspace_end=0×00effd80

Hello World, SPMP8k is alive!
Enter some text to see if I can read.
I’ll set the timeout to about 30 seconds for you slowpokes
Input> I am a hax0r of ultimate skillz

Result was 0×1, your input was
I am a hax0r of ultimate skillz
Done…  Bye!

Program completed with status 0
RedBoot> 

Awesome.  Gratuitous self indulgence using only two functions: printf and gets.  Should be a breeze.

Let’s first consider printf - Printf has grown to quite a sophisticated function, parsing an arbitrary number of parameters, formatting, converting variables to various types of ASCII output.  You can find printf source code online, but it always depends on another function called putc - put character.

This is the even lower-level guy, taking one character from your string and doing the grunt work of getting it displayed.  This is custom for each device and usually consists of things like checking a display buffer (or UART buffer in our case of serial port), setting up the device, stuffing our character into a register, and optionally marking or signalling that there is now a new character for the hardware device to display.  Whew!

You can certainly write the code to do this type of thing, but it takes some work and is probably not suitable for a beginner.  If you have the skills - go for it!  But if you’re just starting out and your head is already swimming, let us show you a little cheat.

Since we presently need to have RedBoot running to execute a program anyway, we can just call RedBoot’s printf function.  In fact, by downloading the RedBoot source code you can look up all the support functions it contains, and how to call them.  Now THAT’s a hell of a jump start.

The only remaining requirement is to find where those functions are located in RAM while RedBoot is running.  Our first program will act as a little parasite that will attach to Redboot and call it’s functions.  In order to call those functions, we must locate ourselves in memory close enough to call RedBoot, but far enough away that if we start making variables, buffers, our stuff does not overwrite RedBoot’s memory.  That sometimes causes spectacular crashes and interesting hangups, but is mostly just a pain in the ass.

Keep in mind that your device may have a different RedBoot version, or may have a different memory layout.  When you start calling memory locations directly, you’ve got to make sure you have the right one.

You will first need a RAM dump of the section of memory that contains RedBoot.  You get a hint during the startup text when you see the line that says:

RAM: 0×00000000-0×00f00000, [0×00200000-0×00f00000] available

It looks like RedBoot has taken the first 2MB for itself, and left the user the next 14MB.  In order to be safe, we should dump the entire section - we’ll find RedBoot’s exact location later.  Tell your terminal program to start capturing text, and fire the incredibly slow dump of the first 2MB.

RedBoot> dump -b 0×0 -l 0×200000

Go do something else for about ten minutes, or sit around and watch glassy-eyed as the text scrolls past.  An alternative dump method would be to use arm-elf-gdb if you have it.  Just disconnect your terminal software and use the following commands, where is the /dev/ name or COMx name of the PC serial port you are using.

arm-elf-gdb

(gdb) target remote

Remote debugging using

0×0003bcd0 in ?? ()
(gdb) dump binary memory myfile.bin 0×0 0×1fffff

We found long dumps to be problematic in gdb, which is a bummer because we use it almost exclusively for everything else.

Continued on Next Page…          Jump to Page 2