One of our clients has a large eLearning website that we maintain.
They’re based out of Bangkok, so they flew me up for some onsite work, part of which culminated in this plugin here.

eFront is a Learning Management System, similar to Moodle.
Its billed as a User Friendly Learning System, although having used it, I’d say thats a bit of a white lie! 🙂

More on eFront here – http://www.efrontlearning.net/

eFrontWPI Plugin Overview

This plugin provides single login functionality for WordPress / BBPress and eFront

It will optionally create an eFront user if one does not exist (option to set this in plugin settings).
For login to function the WordPress user and password must be the same as the eFront username and password.

Plugin is based on the v1 api provided by eFront. Should work with v2 also.
To use the v2 api, simply change the eFront URL to the appropriate URI

IMPORTANT NOTE:
This plugin requires cURL (php5_curl) to be installed as a pre-requisite.

Instructions

Upload this folder into your wordpress / bbpress plugins folder.

Typically ->
[your wordpress folder]/wp-content/plugins/

Activate plugin, then go to eFrontWPI Plugin Settings, and enter the appropriate data:

* eFront URL should be the full URI for the eFront API on your server.
eg
http://www.yourservername.com/eFront/www/api.php
or
http://www.yourservername.com/eFront/www/api2.php

* Admin Login
The eFront Admin user (suggest create a user for the API to use)

* Admin Pass
The eFront Admin user pass

* Create User checkbox
Check if you want a user automatically created.

* Current eFront token
This is a read only field which shows the current eFront API token (if any).
This is a good way to check if the plugin is working – if you have a token, it should be working.

Download here – eFrontWPI v1.0

As I’ve been reasonably successful in the past at figuring out file systems from flat files, I thought I’d have a go at the Dell Mini 3i 1.5 Firmware that surfaced at damipan (http://www.namipan.com/d/DELL_MINI3I_OMS1.5.rar/a5ba3b06ab0bfc9baeb2f09b44f54aa40bac3457ee8ebc04)

The rar file unzips to a MFF file.

This I’m probably guessing is probably named after Marvell File Format or Marvell Flasher File.
Here’s my initial work on the file system of MFF format, based on DELL_Mini3i_OMS1.5.mff

Initial 80 bytes [0x0 – 0x080] (MFF HEADER)

0x00 – 0x03 : 3 Bytes Header MFF
0x03 – 0x07 : Still to figure out, probably file length or crc.
Have to grab another firmware file to check though..

0x08 : Number of files? 9 listed, so quite probably…
Rest of header padded out with zero’s to end of 80 bytes.

[0x80 – 0x180] File Allocation Table
0x80 – our first file. Looks like 0x100 / 256 bytes per file listed, padded with 0x0’s

File listing looks like this:

File header (for each file)
8 bytes, then filename, padded with 0’s to fill 256 bytes length

First 4 bytes – offset in MFF of start of file.
Second 4 bytes – length of file.

Remaining files repeat from next 256 byte intervals.

eg
0x180 – 0x280
0x280 – 0x380
…

[0x80 + 9 files x 0x100 bytes = 0x980] Start of Data.

How did I work this out?

HEADER | Filename (not in hex below as easier to read)
80 09 00 00 34 BB 00 00 | Tavor Flasher_Samsung_ONENAND_h.bin

0x0980 is the start of our first file data, so the first 2 bytes are definitely File Start.
0xBB34 looks quite possibly like File Length.

We can check this easily with one of the plain text files.

Flash_Protection_table.ini is prefixed with 63 EA AD 09 4B 00 00 00

So it should start at 0x09 AD – hmm, readable text starts at offset 9AD D564.
Not quite right. Start offset looks close though.

Lets look at another one.

Tavor_saar_onenand.ini – prefix says
64 d5 ad 09 6f 01 00 00

Ah, 0x9 AD D5 64 is actually our Tavor_saar_onenand.ini content. Cool, a match. So, the first 4 bytes are definitely our location pointer.

Lets look at the Flash protection table again Flash_Protection_table.ini

63 EA AD 09 | 4B 00 00 00
Should start at 09 AD EA 63, and go for 4B length. Bingo, it does 🙂

Our file contents for that area are:

[PROTECTED_REGION_0]
Block_Offset=0x100000
Length=0x20000
Mode=SKIP_BLOCKS

So, now we can start to split the files apart into their associated parts.

factory_BENZ2GWIFI.fbf is probably going to be the most interesting, as its the largest.

That starts at 0xC564, length of 0x09AD1000 and starts with “Marvell_FBF”
Basic math says that 0x9ADD564 (0x09AD1000 + 0xC564) should be our end of file.
Well, it is, as we know flash protection table.ini starts at 9add564.

So, should be fairly easy with that info to write an unpacker tool to rip out the first interior files from the MFF file format.
Some of the files inside are also “packed”, but those appear to be fairly easy to rip apart also 🙂

I’m guessing with a bit more work I’ll be able to replace parts of the firmware with different versions quite soonish.

The file I’m using off of namipan has the following files inside:

TavorFlasher_SAMSUNG_ONENAND_h.bin
TavorFlasher_SAMSUNG_ONENAND_TIM.bin
factory_BENZ2GWIFI.fbf
Tavor_SAAR_OneNAND.ini
factory_BENZ2GWIFI.mff.mlt
magic_fbf.ini
magic_fbf_inner.ini
NTIM_fbw.ini
Flash_Protection_Table.ini

I’m guessing that our fbf file will probably be able to be split into parts as per our ntim_fbw.ini data.
FBF = Flash Binary Format?

some interesting files listed
ntim.bin – non trusted image module?
blob_full.bin – from the borq’s blob gz?
Tavor_M05_Poleg_AI_B0_Flash.bin – tavor = our product chip, as we’re running on a Marvel PXA935 (aka Tavor-P65)

Interesting thing of note – our OEM UniqueID: 0xF00F00 in Unicode is what glyph?
Hint – its not an orange, or a pear 😉

NTIM_fbw.ini

Version: 0x030102
Trusted: 0

Issue Date: 0x08142006
OEM UniqueID: 0xf00f00
Boot Flash Signature: 0x4e414e02
Number of Images: 10
Size of Reserved in bytes: 0x40

Image ID: 0x54494D48
Next Image ID: 0x4F424D49
Flash Entry Address: 0x0
Load Address: 0x5c008000
Image Size To CRC in bytes: 0x0
Image Filename: NTIM.bin

Image ID: 0x4F424D49
Next Image ID: 0x4F534C4F
Flash Entry Address: 0x20000
Load Address: 0x5c013000
Image Size To CRC in bytes: 0x0
Image Filename: obm_full.bin

Image ID: 0x4F534C4F
Next Image ID: 0x5349474E
Flash Entry Address: 0x80000
Load Address: 0x83000000
Image Size To CRC in bytes: 0x0
Image Filename: blob_full.bin

Image ID: 0x5349474E
Next Image ID: 0x494D4549
Flash Entry Address: 0x00120000
Load Address: 0x84000000
Image Size To CRC in bytes: 0x0
Image Filename: signature_full.bin

Image ID: 0x494D4549
Next Image ID: 0x4152424C
Flash Entry Address: 0x00100000
Load Address: 0xBFEE0000
Image Size To CRC in bytes: 0x0
Image Filename: reliable_full.bin

Image ID: 0x4152424C
Next Image ID: 0x47524249
Flash Entry Address: 0x00140000
Load Address: 0xBF600000
Image Size To CRC in bytes: 0x0
Image Filename: arbel_full.bin

Image ID: 0x47524249
Next Image ID: 0x62746C67
Flash Entry Address: 0x00840000
Load Address: 0xBFF00000
Image Size To CRC in bytes: 0x0
Image Filename: tavor_full.bin

Image ID: 0x62746C67
Next Image ID: 0x70636C67
Flash Entry Address: 0x00A00000
Load Address: 0xBF300000
Image Size To CRC in bytes: 0x0
Image Filename: bootlogo_full.bin

Image ID: 0x70636C67
Next Image ID: 0x464F5441
Flash Entry Address: 0x00A20000
Load Address: 0x8F300000
Image Size To CRC in bytes: 0x0
Image Filename: prechangelogo_full.bin

Image ID: 0x464F5441
Next Image ID: 0xFFFFFFFF
Flash Entry Address: 0x0EA40000
Load Address: 0x80100000
Image Size To CRC in bytes: 0x0
Image Filename: fota_full.bin

Reserved Data:
0x4F505448
0x00000002
0x55415254
0x00000010
0x00004646
0x00000001
0x50524F49
0x00000020
0x00000002
0x00000000
0x00000000
0x00000000
0x00000001
0x00000000
0x5465726D
0x00000008

Flash_Protection_Table.ini

[PROTECTED_REGION_0]
Block_Offset=0x100000
Length=0x20000
Mode=SKIP_BLOCKS

magic_fbf_inner.ini

[INTEL_FLASH_DEVICE_INPUT_FILE]
Number_of_Images=20

[IMAGE_HEADER_0]
Start_Address=0xfa00000
Image_Length=0x80000
EraseBlocks=1
WriteImage=0
VerifyWrite=0

[IMAGE_HEADER_1]
Start_Address=0xdd40000
Image_Length=0x800000
EraseBlocks=1
WriteImage=0
VerifyWrite=0

[IMAGE_HEADER_2]
Start_Address=0xeb40000
Image_Length=0x8c0000
EraseBlocks=1
WriteImage=0
VerifyWrite=0

[IMAGE_HEADER_3]
Filename=NTIM.bin
Start_Address=0x00000000
EraseBlocks=1
WriteImage=1
VerifyWrite=0

[IMAGE_HEADER_4]
Filename=Arbel_NVM_SAC_NOCOMMRTC.bin
Start_Address=0x00140000
EraseBlocks=1
WriteImage=1
VerifyWrite=0

[IMAGE_HEADER_5]
Filename=blob
Start_Address=0x00080000
EraseBlocks=1
WriteImage=1
VerifyWrite=0

[IMAGE_HEADER_6]
Start_Address=0x0bd40000
Image_Length=0x02000000
EraseBlocks=1
WriteImage=0
VerifyWrite=0
[IMAGE_HEADER_7]
Filename=opl.img.yaffs
Start_Address=0x0bd40000
EraseBlocks=1
WriteImage=1
VerifyWrite=0

[IMAGE_HEADER_8]
Filename=ramdisk_len.img
Start_Address=0x00c40000
EraseBlocks=1
WriteImage=1
VerifyWrite=0

[IMAGE_HEADER_9]
Filename=ramdisk-recovery_len.img
Start_Address=0x00cc0000
EraseBlocks=1
WriteImage=1
VerifyWrite=0

[IMAGE_HEADER_10]
Start_Address=0x00d40000
Image_Length=0x08000000
EraseBlocks=1
WriteImage=0
VerifyWrite=0
[IMAGE_HEADER_11]
Filename=system.img.yaffs
Start_Address=0x00d40000
EraseBlocks=1
WriteImage=1
VerifyWrite=0

[IMAGE_HEADER_12]
Filename=TAVOR_LINUX_NTOBM.bin
Start_Address=0x00020000
EraseBlocks=1
WriteImage=1
VerifyWrite=0

[IMAGE_HEADER_13]
Filename=Tavor_M05_Poleg_AI_B0_Flash.bin
Start_Address=0x00840000
EraseBlocks=1
WriteImage=1
VerifyWrite=0

[IMAGE_HEADER_14]
Start_Address=0x08d40000
Image_Length=0x03000000
EraseBlocks=1
WriteImage=0
VerifyWrite=0
[IMAGE_HEADER_15]
Filename=userdata.img.yaffs
Start_Address=0x08d40000
EraseBlocks=1
WriteImage=1
VerifyWrite=0

[IMAGE_HEADER_16]
Filename=zImage
Start_Address=0x00a40000
EraseBlocks=1
WriteImage=1
VerifyWrite=0

[IMAGE_HEADER_17]
Filename=prdcfg.bin
Start_Address=0x00940000
EraseBlocks=1
WriteImage=1
VerifyWrite=0

[IMAGE_HEADER_18]
Filename=precharge_logo.out
Start_Address=0x00a20000
EraseBlocks=1
WriteImage=1
VerifyWrite=0

[IMAGE_HEADER_19]
Filename=logo_pic.gz.out
Start_Address=0x00a00000
EraseBlocks=1
WriteImage=1
VerifyWrite=0

Lastly, hi to the people at http://www.allphone.com.cn 😉

As I’ve been busy with real life ™, its been a while since I took a trip to the computer mall to see what new goodies I could play with.

A friend is in town from Beijing, so took him down to the Shanzhai hell (or heaven depending on PoV) that is Qiu Jiang lu.

I wasn’t aware that you could buy Keychain video recorders for 80rmb, but you can. Apparently they’re even cheaper in eBay – although I don’t see how its possible, given that the factories here are pricing higher than they sell for in the States. Rejects?

Anyhow, I bought 2 keychain video camera’s, and an MP3 looking one.

Dissected one and it contains the Anyka AK3651B as the main chip.

The AK36xx series is an SoC (System on a Chip).

As Anyka appears to be deathly afraid of giving out any useful information about their products, I’ve had to piece together info from what I found online.

Their own product page here – http://www.anyka.com/enProShow.asp?sortFlag=110&sortName=Application%20Processor&id=105
says the following:

32-bit Microprocessor Core
Integrated I/D cache
Memory Management Unit (MMU)

Video Coprocessor
MPEG4.SP codec
H.263 codec
Motion JPEG codec

Audio Coprocessor
MP3 decoder
WMA decoder
AAC/AAC+ decoder
AMR codec
Real-time audio stream in PCM/ADPCM format

Image Coprocessor
JPEG HW codec

Glueless Dual LCD Displays
Supporting MPU LCD
Supporting RGB LCD
Programmable LCD size and refreshing rate

Connectivity
USB 2.0 HS OTG
I2S master/slave
UART
SPI
MMC/SD

Embedded ADCs and DACs
SAR ADC for touch panel and voltage detect
Sigma-Delta ADC for microphone
Sigma-Delta DACs for stereo

Built-in Power Amplifier/Headphone Driver

External Memory Support
Supporting SDRAM
Supporting Nand Flash (SLC/MLC, with hardware ECC)

Package
LQFP 128-pin/144-pin，FBGA 100-pin/144-pin

Appears that they’re mostly used in MP3/MP4 players, which is why most of my googling on specs was ruined by whiny users asking for someone to please help them with their foobar’d player.

The first useful links on these are at Chuck’s pages here – http://www.chucklohr.com/808/

He’s done a lot of useful work collating information, although some of his deductions are a little strange, so take some things with a pinch of salt. Lots of good info though.

The main source of info on the hardware side is at http://www.readerme.com, they have a most excellent section of downloads which provide more information on the chips than anything else out there!

We gave them a call and had a chat (one of the benefits of being located in China, is that we obviously speak Chinese in the office!).
They don’t speak great Mandarin though – so it was bad cantonesedarin or Mandonese? Hmm, have to come up with a word for that! (similar to Chinglish but mixing Cantonese and Mandarin).

Both sides were laughing but we could at least talk to each other. “Mo man tai, dui ma?”

They actually don’t sell products, they only do design work for others, but, thats good to know.
They did point us in the direction of a few trading companies that could do FOB export, but shipping quantities are in the x,000’s so not so useful yet.

I’ll see if I can find the actual factories making these tomorrow. (Although when I say we, I mean the staff).
They did prove to be an excellent source of data on the chips though if one takes a look at the PDF’s on their site.

The golden data trove is here – http://www.readerme.com/html/html/%E7%9B%B8%E5%85%B3%E4%BA%A7%E5%93%81%E5%8E%9F%E7%90%86%E5%9B%BE%EF%BC%8C%E8%B4%B4%E7%89%87%E5%9B%BE.html

According to Anyka (安凯 in Chinese) the 36xx chips are a series, so they should have similar functionality.

While I don’t have data sheets, or a BSP, I can read the PDF’s at least to get an idea of where things are laid out.

AK3631B

AK3651B

They do look similar, so probably only minor differences in functionality (probably the newer ones are cheaper?).
Again, hard to check, as Anyka datasheets appear to be hens teeth.

I may give them a call also, and see if they’ll be willing to give us some info about their products, but I’m not holding my breath on that one.

I’ve also poked around a bit in the firmware files using strings, and taking a look at headers, and have come up with some preliminary conclusions.

I’m guessing their SoC is ARM5 based, given what i have found (haven’t decompiled yet, but looks like that).

Some common strings in the firmware’s from start:

00000 06 00 00 EA FE FF FF EA

Googling “06 00 00 EA FE FF FF EA” comes up with some other people talking about firmware for pxa312 devices, which have exactly that in their boot loader, so, seems likely.

The PXA312 is ARMv5TE…

I’m guessing some playing around with radare (http://radare.nopcode.org/get/radare.pdf.html) should get some more info about whats going on.

Running strings on the firmware files available shows interesting info:

strings /Documents/Keychain\ Camera/cx311V2.04/Spiboot_36XX.bin
ANYKA362
6KA49
start read cfg
file cnt:%d
file name:%s
Cannot find BIOS
read file info fail
load bios ……
map:%d
file len:%d
ld addr:0x%x
Load bios from spiflash successfuly!
read BIOS fail
spi boot start
system clock: %d
BIOS

Thats our 4k bootloader, which obviously loads our 1M bios image from SPI flash memory (SPI = Serial Peripheral Interface)
More on SPI here.
http://en.wikipedia.org/wiki/Serial_Peripheral_Interface_Bus

Hmm, more reasons for me to get a Bus Pirate now…

We have a flasher also, although its Windows based.
I’m guessing some USB sniffing will lead to some magic byte handshake sequence to get into the bootloader via USB, as the BIOS strings point to that.

eg:

“The setup packet is not 8 byte!”

Also amusing is that its fairly easy to find the FAT32 code embedded in at least one of the firmwares

EB xx 90 … -> 55 AA (in Sprint1M.bin)

The flasher tool is also nice enough to give us an idea of layout in the 1M flash chip.

You’ll need to install the Anyka M3 USB driver to talk to the chip, which appears to have the following attributes via USB:
Vendor ID: 0471
Product ID: 0666 (the product of the beast? hehe)

This is a bit naughty, as 0471 is in theory already taken by Philips (or NXP) according to http://www.linux-usb.org/usb.ids

Its also astoundingly obvious that they used driverworks to make the driver. (From the oh so copied in China vid/pid, and the strings left in the driver). An example of this here http://www.baiheee.com/OpenSource/Easy%20USB%2051%20Programer/Easy%20USB%2051%20Programer_DriveOurBoard.htm

Want to bet someone read those instructions and its been repeated ad nauseum?
Sadly, its so easy to see the minimal effort that’s gone into things.

Back to our flasher, it says that our 1M chip is laid out as follows:

###Project Name
project name = chaoxian

###Devie Number
device channel = 8

###COM
com bOpen = 0
com base = 1
com count = 1
com baud rate = 38400

path producer sundance2 = producer_sundance2.bin
path producer sundance2A uboot = producer_sundance2A_uboot.bin
path producer sundance2A umass = producer_sundance2A_umass.bin
path nandboot sundance2= Spiboot_36XX.bin
path nandboot sundance2A= Spiboot_36XX.bin

bios run addr = 0x30500000
bios start addr = 0xc0000
bios end addr = 0x1c0000
bios backup start addr = 0x1c0000
bios backup end addr = 0x2c0000

chip type = AK_3225
chip uboot = 1
chip power off gpio = 255
chip usb2 = 0
chip get aid = 0
chip update = 0
chip select loop = 1
chip select nand0 = 1
chip select nand1 = 1
chip select nand2 = 1
chip select nand3 = 1
chip gpio_ce2 = 255
chip gpio_ce3 = 255

ram size = 8
ram row = 12
ram column = 8
ram bank = 4

moduleburn DownloadMode = 2
moduleburn bDownloadFLS = 1
moduleburn bDownloadEEP = 1
moduleburn baudrate = 921600
moduleburn gpio_dtr = 85
moduleburn gpio_module_igt = 109
moduleburn gpio_module_reset = 87
moduleburn path_fls = LCG2.fls
moduleburn path_eep = LCG2.eep

fs start addr = 0x6c0000
fs reserver block = 64
fs nonfs reserve size = 4

partition count = 0

download_to_udisk count = 0

download_to_nand count = 3
download_to_nand1 = 0, Spring1M_bios.bin, 0x30500000, BIOS
download_to_nand2 = 0, Spring.bin, 0x30000000, MMI
download_to_nand3 = 0, AkResData.Bin, 0x0, RES

download_to_mtd count = 0

nand supported count = 0

If we take a look at that, our Spring1M_bios.bin starts off at C000
(bios start addr = 0xc0000)
(Deduct a 0 as we’re not offset by 0x300000000)

A look in a hex editor at that position shows:

Note the 32bit word value – 0xE1A0C00D

Thats classic ARM, so we _know_ its arm based…

romStart [0xe1a0c00d] mov r12,r13

Our next line of code is exactly the same as listed here http://code.google.com/p/milestone-overclock/wiki/Disassembly

e1a0c00d mov ip, sp
e92dd8f0 push {r4, r5, r6, r7, fp, ip, lr, pc}

So its looking like we can basically disassemble the code using arm-none-linux-gnueabi-objdump

I’ll leave that for another day, but with a bit more work we could compile our own code for this as we now have a good idea of the target cpu.

The next step would be to get into the bootloader or debug mode via USB, and see what can be seen.

Tools used:

0xED – http://www.suavetech.com/0xed/0xed.html
A nice fast and compact hex viewer for OSX.

strings – built into most *nix based systems.

Grey matter – Available to all, unused by many 😉

Now hopefully I can get back to the Webcam firmware stuff as I’ve been promising to do.

Although I was supposed to be on a plane today heading home, I did something silly and got the dates wrong.
So, after a nice scenic trip yesterday evening to the airport and back, I get to do it all over again tonight.
Although that was a total pain, I did get to spend another day in Shanghai, and luckily enough, it coincided with the new Apple Store opening in the IFC center over in Pudong.

Overall impression – this is good!
I spoke with a number of the staff, and talked about the usual issues here (service, service, service…), and they were all quite understanding, and Apple’s genuinely trying to improve on things – hence their own store, and support in Shanghai (finally).

Shanghai has the biggest Genius bar in the world now. Unfortunately the store is a bit lacking compared to others in Shanghai – no iPad, no iPhone (other than the official one), but they do carry software and iMac’s / Laptops in lots of configurations.
I know where my next iMac is coming from 🙂

Downsides of the store – the moat outside is going to claim lots of victims. Its so subtle that you miss is – who’s idea was that?
We already saw unhappy victims with wet feet while we were leaving. I expect that to be changed in the near future, or the store will have to provide a shoe drying facility!

I also had the only iPad in the store (and possibly China at that point) that could play flash. Ok, there were only 2 iPad’s in the store, but still.. 😉

Photo’s of the store on flickr, which I would upload, but China is being finicky again. Grrr
Should be on the sidebar though.

http://www.flickr.com/photos/sheedl/sets/72157624448891934/

During the research into LCD updating on the T6x IBM’s, I learned a few new things.

One of those was that I had some of the parts lying around the office necessary to make a projector.
As my office desk typically looks like a mad scientist uses it, I thought I may as well add some more goodies to fill the missing bits.

First up was an LED light off taobao. As the 100 watt ones are still a little pricey, I’m going with a 50w one for testing purposes.
Visitors to the office who still have LED driven holes burned into their retina’s agree that yes, it is quite bright.

Probably not bright enough for our purposes, but good enough for testing.

Some photos of that here –

The hokey CPU fan cooler hooked up to the back adds to the effect.

The LED comes in a variety of color temperatures, ranging from yellow white, pure white, through to blue white, we chose pure white, as thats closest to what they normally use in projectors.

Projector and fan came to about 400rmb including shipping. Seller was quite nice to deal with too, and advised us which would be best for the purpose.

Now that our lighting requirements were minimally in place, we looked at the next requirement.

LCD screens.

As the 2 or 3 people that read this blog are aware, I just bought some rather nice QXGA LCD’s. These would be quite nice to use for a projector, but, unfortunately, getting hold of controllers for them is a little bit harder than I thought it would be.
I did manage to find some, but the prices are a little high, so I put that on the back burner for now. I will be looking into that again in the near future though.

First, a little detour onto the subject of LCD’s.

Essentially LCD’s are mass produced these days by a small handful of manufacturers, and the controllers for LCD’s are also mass produced.
Controllers pretty much come in a few different capacities, but essentially they’re all the same featurewise.
You buy a controller based on the maximum resolution it can handle, then program it for the LCD you have.

Controllers are dirt cheap – most can be found for 20rmb low end eg SVGA, through to 120rmb for medium end – eg 1920×1200 /DVI+VGA.
This means that most laptop screens can easily be reused as desktop screens for reasonably cheap prices.

TV’s are also essentially exactly the same as screens now, so the hardware is exactly the same.
Controllers for TV are usually a little more expensive, but not overly so. I bought a multi-input (HDMI, VGA, Tuner etc) with USB for 200rmb.
Different chipsets do better jobs at HD, but its very very generic stuff these days.

You need an invertor board for the lighting (if its not an LED based LCD) – those go for 10-20rmb.
You need a controller card to drive the LCD. (Most sellers will make you a cable for your specific LCD, and program the controller for a minimal charge)
You need a power supply (typically 12v 3amps+-).
Lastly you need a case.

We gave this a test run with a salvaged a 14″ LCD from a hosed laptop.
We bought a controller board (20rmb), power supply + empty screen casing (130rmb) off taobao. While it wasn’t necessarily worth it to do that, we did learn that its fairly easy.

Programming controllers is also pretty straightforward, but I’ll probably expand on that in another post.

As I wanted an HD capable projector I looked at what the smallest size HD screen (WUXGA) available on the market today is – that happens to be the Samsung LTN154U1
I got mine for about 500rmb.

Most people will be wondering right now at this point how an LCD screen is going to be used in a projector.

Essentially LCD’s are transparent – an LCD screen typically comes sold ready to use. This means its shipped with lighting built in, plus a reflective back surface.
We’re going to need to denude the LCD off all that – I’m going to have to disassemble the LCD display, and take out all the non-essentials. What I’ll end up with will be transparent, and fairly delicate.
Hopefully I won’t break anything when I take the LCD out of the casing, and remove the lighting, backing etc. Breaking it will be costly!

Next we’ll need a way to shine our light source through the LCD.
While we have a strong light – it won’t be very useful as is, as the light will mostly be concentrated in the center of wherever its pointed at.
So, we need a way to disperse the light in a directed way.

Typically this is done with a Fresnel. Fresnels are rather cool lens typically made out of plastic. They magnify or reduce anything passed through them.
We’ll be using a fresnel in front of the LED light to disperse the light evenly through the LCD.
Once its through the LCD, we’ll be using another Fresnel to concentrate the light back into a smaller focal area, so that we can throw it through a lens, and see something on a screen.

For a 15.4″ screen, we need a 400×320 sized 330mm Fresnel, and a 500mm Fresnel.
The 330mm (aka our collimator) will be placed in front of the light source, the LCD will be placed 10-15mm in front of that, then finally the 500mm (aka our collector) to concentrate the light + display output into a nice ready to use focal area for our rather expensive triplet lens.
We’re using a 500mm triplet as the lens, mostly as all the projector websites are using those for 15.4″ screens.

Fresnels were fairly cheap – 80rmb each or so.

The lens was rather more expensive. Ours was close to 600rmb with shipping!
When it arrived, we saw why. It definitely feels like its worth the money.. Unfortunately ours arrived with a crack from shipping, so we had to send it back. The replacement should arrive in a day or three.

While I haven’t setup the fresnels yet in action, I did test out the controller board, and LCD.

Photo’s below of everything.

While I haven’t built any casing yet, I’m fairly confident we should be able to knock something up quickly to house all the parts.
Hopefully ours will be sturdier than this professional build I saw online –

As someone I know was interested in getting a new (old) laptop, I did some trawling of the intertubes, and saw that there were quite a few IBM Thinkpad’s in nice condition available on Taobao.

After checking away the requirements (one of which was not to go down in resolution to the crap they sell nowadays), I decided on a T6x series.

A T60 with a 1400×1050 screen was about RMB2500 on Taobao with fairly decent spec’s – DVD Writer, Bluetooth, Fingerprint Reader, SATA, Extended Battery. 3 month warranty, with a replacement 7 day swap for another unit. I sent my staff to go take a look at the shop, they liked, and I was soon the owner of an ex-corporate laptop that looked like it came from Singapore originally (according to the model / software licence sticker on the laptop). It even came with a legitimate licenced copy of Windows.

As I had ordered one for test purposes to see what the quality was like, I was pleasantly suprised. The one I received is pretty much in mint condition. In fact its in such good condition, that I decided I would keep it for myself!

Read more »

I’ve uploaded a zip of my built test image here. I’ve only included telnetd, and ftpd, as the sshd binary is very large, and won’t fit into our rom image space!

If someone is willing to test, feel free.

Test Rom with FTPD and TELNETD binaries added

This rom is 700k+- vs the normal 550kb. So this may / may not overwrite the web ui.

As China’s firewall is being particularly obnoxious this week as to what I can view on the web, I can’t actually get to the info I need to see where they typically write the UI to in rom.

In theory, we should be able to write to the same base address via the boot loader.

The original rom is written here –

Image: 6 name:romfs.img base:0×7F0E0000 size:0×0008D000 exec:0×7F0E0000 -a

And I’m pretty sure that the UI gets written somewhere after this, and not as a separate image. I’d have to run Windows and a sniffer to test this though (using their firmware update software).

Our boot logs show that linux blkmem driver is set to view the whole area from 0×7F0E0000 through to 0x7F16D3FF, so we should easily have 200kb to waste^Hplay with.

From my boot logs:

Blkmem 1 disk images:
0: 7F0E0000-7F16D3FF [VIRTUAL 7F0E0000-7F16D3FF] (RO)

Obstensibly, this should be a matter of going to the bootloader over serial, then uploading our img file.
Suggest rename from testrom.img to romfs.img to be consistent.

It should be something like this:

bootloader > del 6
(delete the current romfs.img)

bootloader > fx 6 romfs.img 0x7f0e0000 0x7f0e0000 -a
Waiting for download
Press Ctrl-x to cancel … (while it waits, you have to select Transfer > Send File in Hyperterminal menu, choose the Xmodem protocol and select my rom image)
CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC
Flash programming …

bootloader> boot

Then see what happens in the logs.

It should boot, then attempt to run telnetd and ftpd.
That probably WON’T work just yet, as they’ll complain about missing /etc/ config files.

You might also be missing the UI (as I think this gets written somewhere after our romfs.img in flash)

Send me the serial logs in the comments, and I can fix that up, and repackage.

I also know why the alleged clones (NB they’re not f..king clones sigh, they’re all made by 1 manufacturer here for different people, including FOSCAM) don’t work. The linux.bin for older firmware is set to boot from 0x7f0D0000 as opposed to 0x7f0e0000, so image 6 and 7 both need to be reflashed.

Also of note is that the newer units have gone cheaper, and use 2M flash, previous units had 4M.
uCLinux reports 8M, but its not talking about Flash, just RAM

Be prepared to brick (not completely, as we have a bootloader, and can reflash the original firmware) if it doesn’t work.

If my rom above doesn’t work initially for you, try flashing this linux.zip before reverting, and see if that helps it boot.

eg

bootloader> del 7

bootloader> fx 6 romfs.img 0x7f0e0000 0x7f0e0000 -a
Waiting for download
Press Ctrl-x to cancel ... (while it waits, you have to select Transfer > Send File in Hyperterminal menu, choose the Xmodem protocol and select my rom image)
CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC
Flash programming ...


Why aren’t I doing this?

Mostly as I don’t currently have a good serial connection, I’m waiting on headers. Currently I have to hold the serial ports onto the board with fingers, and thats less than reliable!

I should get around to fixing that soonish though, I’m interested in testing this myself…

I’d also appreciate the French contingent adding some info. I’m particularly interested in paillassou’s board photos, and any other firmware people have found for these so I can compare.

I can’t get to Picasa, GadgetVictims, IrishJesus now in China. Grrr.

Yes, I know, use a VPN or proxy… Unfortunately what we do precludes doing so, as I’d probably get told off by our beloved government here, and thats not worth the risk…

Comments please.

So far in this series, we’ve learnt a few things.
First, is that this hardware is quite nice for hacking purposes, as they’ve left the uBoot in a nice state, and have easily accessible debug ports.
Second is that doing this kind of thing isn’t really that complicated, and can be quite fun.

We’re pretty much ready to start doing our own coding, as we know how the images are packed, and we can use the uBoot to either flash onl the romfs on or own, or alternately roll a complete linux + romfs binary image.

For that, we’ll need to be ready to roll up our sleeves, and actually do some development (finally!).

Getting a development environment setup is our next step, as we’re ready to test out adding binaries.

I’m using Debian, but most Linux environments should be similar. OSX is BSD based, and more of a pain due to Apple not putting everything needed in the normal places, so I’m doing this in a VM on my Macbook under Debian.

Go grab a copy of “NUC700 Series MCU uCLinux BSP.zip” from here http://www.metavert.com/public/NO-SUPPORT/

Setup a VM for Debian (not going to cover that) or install Debian or similar.

Copy the zip file to /home in the OS you use.

cd /home
mkdir N745
cd N745
unzip ../NUC700\ Series\ MCU\ uCLinux\ BSP.zip

You should now see something like this:

:/home/N745/NUC700 Series MCU uCLinux BSP# ls -al
total 68
drwxr-xr-x 6 root root 4096 2009-05-15 20:02 .
drwxr-xr-x 3 root root 4096 2010-04-30 02:23 ..
drwxr-xr-x 3 root root 4096 2009-05-15 20:06 bootloader
drwxr-xr-x 2 root root 4096 2009-05-15 20:03 bsp
drwxr-xr-x 2 root root 4096 2009-05-15 20:02 doc
drwxr-xr-x 4 root root 4096 2009-05-15 20:02 mkrom
-r--r--r-- 1 root root 44632 2009-03-27 11:49 NUC700 uClinux BSP Release Note.pdf
debian:/home/N745/NUC700 Series MCU uCLinux BSP#

Unfortunately the build *really* doesn’t like long filenames, so lets move all this to the N745 folder, and get rid of the annoyingly named folder.


/home/N745/NUC700 Series MCU uCLinux BSP# mv * ..
/home/N745/# cd ..
/home/N745/# rm -r NUC700\ Series\ MCU\ uCLinux\ BSP/


We still need to unzip the BSP, as its compressed, so go into bsp


/home/N745/# cd bsp
/home/N745/bsp# tar -xzvf NUC700BSP.tar.gz
NUC700BSP/
NUC700BSP/arm_tools.tar.gz
NUC700BSP/install.sh
NUC700BSP/arm_tools_3.3.tar.gz
NUC700BSP/build.tar.gz
NUC700BSP/applications.tar.gz
NUC700BSP/uClinux-dist.tar.gz


Yay, yet another bloody subdirectory. Sigh.


/home/N745/bsp# cd NUC700BSP
debian:/home/N745/bsp/NUC700BSP# ls -al
total 183300
drwxr-xr-x 2 shanghaiguide shanghaiguide 4096 2009-03-26 22:38 .
drwxr-xr-x 3 root root 4096 2010-04-30 02:29 ..
-rw-r--r-- 1 shanghaiguide shanghaiguide 29521418 2009-03-26 21:55 applications.tar.gz
-rw-r--r-- 1 shanghaiguide shanghaiguide 43742203 2009-03-26 21:22 arm_tools_3.3.tar.gz
-rw-r--r-- 1 shanghaiguide shanghaiguide 36108739 2009-03-26 21:11 arm_tools.tar.gz
-rw-r--r-- 1 shanghaiguide shanghaiguide 5643452 2009-03-26 21:24 build.tar.gz
-rwxr--r-- 1 shanghaiguide shanghaiguide 4370 2009-03-26 22:31 install.sh
-rw-r--r-- 1 shanghaiguide shanghaiguide 72439431 2009-03-26 20:53 uClinux-dist.tar.gz
debian:/home/N745/bsp/NUC700BSP#


Run the install – I’ve decided to install the whole shebang to /home/N745

Note – The observant amongst you will notice I’m running this as root.
This is NOT recommended. I’m running under a VM solely created to play with this, so I don’t really care if I break it (as I can roll back to the initial install image fairly easy in vmware). Don’t do this yourselves (unless you want to break things).


debian:/home/N745/bsp/NUC700BSP# ./install.sh
firstly install arm_tools.tar.gz -->/usr/local/
wait for a while
successfully finished installing arm_tools.tar.gz
now begin to install build.tar.gz,applications.tar.gz and uClinux-dist.tar.gz
Please enter your absolute path for installing build.tar.gz, applications.tar.gz and uClinux-dist.tar.gz:
/home/N745
/home/N745 has existed
please wait for a while, it will take some time
whole installation finished successfully!
debian:/home/N745/bsp/NUC700BSP#


We finally have our build environment unzipped, and its sitting in nuc700-uClinux.

debian:/home/N745# cd nuc700-uClinux/
debian:/home/N745/nuc700-uClinux# ls -al
total 24
drwxr-xr-x 6 root root 4096 2010-04-30 02:31 .
drwxr-xr-x 7 root root 4096 2010-04-30 02:31 ..
drwxr-xr-x 7 root root 4096 2009-03-25 00:44 applications
drwxr-xr-x 2 root root 4096 2009-03-26 21:23 image
drwxr-xr-x 12 root root 4096 2009-03-26 04:54 romdisk
drwxr-xr-x 10 root root 4096 2009-03-26 06:50 uClinux-dist
debian:/home/N745/nuc700-uClinux#

uClinux-dist has the default binaries we want, plus we need to configure the kernel, so lets visit there first (the more adventurous can look at the other folders)


debian:/home/N745/nuc700-uClinux# cd uClinux-dist/
debian:/home/N745/nuc700-uClinux/uClinux-dist# ls -al
total 84
drwxr-xr-x 10 root root 4096 2009-03-26 06:50 .
drwxr-xr-x 6 root root 4096 2010-04-30 02:31 ..
drwxr-xr-x 2 root root 4096 2009-01-22 23:27 bin
drwxr-xr-x 3 root root 4096 2009-03-26 06:50 config
-rw-r--r-- 1 root root 18007 2009-01-22 23:29 COPYING
drwxr-xr-x 3 root root 4096 2009-01-22 23:27 Documentation
drwxr-xr-x 11 root root 4096 2009-01-22 23:29 freeswan
drwxr-xr-x 5 root root 4096 2009-01-22 23:29 lib
drwxr-xr-x 15 root root 4096 2009-03-26 06:50 linux-2.4.x
-rw-r--r-- 1 root root 3228 2009-01-22 23:28 MAINTAINERS
-rw-r--r-- 1 root root 7977 2009-01-22 23:27 Makefile
-rw-r--r-- 1 root root 4935 2009-01-22 23:29 README
-rw-r--r-- 1 root root 1654 2009-01-22 23:29 SOURCE
drwxr-xr-x 158 root root 4096 2009-01-22 23:28 user
drwxr-xr-x 4 root root 4096 2009-03-12 03:54 vendors
debian:/home/N745/nuc700-uClinux/uClinux-dist#


Looks like it should be fairly easy, right?
Wrong.

The default build doesn’t work. Why would it be that easy.

You’ll end up with issues like:

entry-armv.S:782: Error: Internal_relocation (type 210) not fixed up
(OFFSET_IMM)
entry-armv.S:784: Error: Internal_relocation (type 208) not fixed up
(IMMEDIATE)

So, we need to make sure we start off fresh.
Also, note that we’re building for an N745 cpu, so we’ll need to configure that at the make config stage.
Lastly, and EXTREMELY important, is that we’ll need to put our required tools in the path.

DO NOT FORGET TO DO THIS
sample PATH below:

PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/local/arm_tools/bin


debian:/home/N745/nuc700-uClinux/uClinux-dist# PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/local/arm_tools/bin

[A gazillion pages of info later, we have a build environment!]


We’re finally ready to use our weapon of mass destruction.


debian:/home/N745/nuc700-uClinux/uClinux-dist#make
...

It should compile without issue.

Next step is to mount our created rom image, and copy the binaries off, or just go to the compiled folders, and get the binaries.

I’ve done this step already, and have a zip file of a few useful files ready.

-rwxr-xr-x 1 root root 110888 2010-04-30 03:50 ftpd
-rwxr-xr-x 1 root root 55164 2010-04-30 03:52 ping
-rwxr-xr-x 1 root root 1201904 2010-04-30 03:51 ssh
-rwxr-xr-x 1 root root 1219864 2010-04-30 03:51 sshd
-rwxr-xr-x 1 root root 118004 2010-04-30 03:45 telnet
-rwxr-xr-x 1 root root 45460 2010-04-30 03:45 telnetd

file *
ftpd: BFLT executable – version 4 ram
ping: BFLT executable – version 4 ram
ssh: BFLT executable – version 4 ram
sshd: BFLT executable – version 4 ram
telnet: BFLT executable – version 4 ram
telnetd: BFLT executable – version 4 ram

Download that here – arm7-nettools

All we need to do now is mount our romfs image, unzip the arm7-nettools.zip, copy the arm7 bFLT binaries over to bin, add telnetd, sshd, and ftpd to our /bin/init, and rebuild by running genromfs on our filesystem.

We can then finally flash our new romfs, and test it out.

Don’t forget that romfs is a read only file system, so we can’t modify it by mounting it. We need to mount, copying everything to elsewhere, do our required bits and pieces, then rebuild.

eg

mount -o loop -t romfs still_unsure.img /mnt/test -r

mkdir /mnt/new
cd /mnt
rsync -arv /mnt/test/ new
cd new/bin
wget http://www.computersolutions.cn/blog/wp-content/uploads/2010/04/arm7-nettools.zip
unzip arm7-nettools.zip
rm arm7-nettools.zip

[We need to also edit init]
pico init

Add

sshd&
telnetd&
ftpd&

eg –
cat init
mount -t proc none /proc
mount -t ramfs none /usr
mount -t ramfs none /swap
mount -t ramfs none /var/run
mount -t ramfs none /etc
mount -t ramfs none /flash
mount -t ramfs none /home
camera&
sshd&
telnetd&
ftpd&
sh

Change to the next directory up, and lets run genromfs

genromfs -d new -f testrom.img
debian:/mnt# ls testrom.img
testrom.img
debian:/mnt# ls -al testrom.img
-rw-r–r– 1 root root 3329024 2010-04-30 04:18 testrom.img

In theory, this should be usable (famous last words!).

Unfortunately, I can’t try testing on that at home, as all the equipment is at the office, but that should be fairly easy.

Probably also some small config issues to sort out, as ftpd, telnetd and sshd will probably choke without their related /etc/whatever config files needed, but we can sort that out via serial on the debug ports.

Spent a while checking out the different binaries available for the different OEM versions.
Some interesting things I’ve found.

If I take a look at a sample kernel – eg
lr_cmos_11_14_1_46.bin

ls -al lr_cmos_11_14_1_46.bin
-rw-r--r-- 1 lawrence staff 1350539 Mar 15 13:47 lr_cmos_11_14_1_46.bin


Our file size for the file i have is 1350539 bytes.

A hexdump of the header shows:

00000000 42 4e 45 47 01 00 00 00 01 00 00 00 77 cb 0b 00 |BNEG……..w…|
00000010 00 d0 08 00 50 4b 03 04 14 00 00 00 08 00 3a 2e |….PK……..:.|
00000020 87 3b 3b e7 b8 16 03 cb 0b 00 bc d9 18 00 09 00 |.;;………….|

PK is the standard file header for Zip compression (as Zip was invented by Phil Katz)
Zip fingerprint in hex is – 0x04034b50, which matches nicely in our second line – 50 4b 03 04

On the offchance it contained a zip file, I tried unzipping from the start of the PK.

We can totally misuse dd to write from an offset of 20 bytes to a test.zip file as follows:


lawrence$ dd if=lr_cmos_11_14_1_46.bin of=test.zip skip=0x14 bs=1

Unfortunately this didn’t unzip.

However…

zipinfo test.zip
Archive: test.zip 1350519 bytes 1 file
-rw------- 2.0 fat 1628604 b- defN 7-Dec-09 05:49 linux.bin
1 file, 1628604 bytes uncompressed, 772867 bytes compressed: 52.5%

Says there is a valid zip file there, so we’re getting somewhere. It should be something like 772867 bytes + whatever Zip header / footer file bits in size.

If we take a look at the Zip file format, it says that the end of directory (aka end of zip file) marker is 0x06054b50

ZIP end of central directory record

Offset Bytes Description[4]
 0 4 End of central directory signature = 0x06054b50
 4 2 Number of this disk
 6 2 Disk where central directory starts
 8 2 Number of central directory records on this disk
10 2 Total number of central directory records
12 4 Size of central directory (bytes)
16 4 Offset of start of central directory, relative to start of archive
20 2 ZIP file comment length (n)
22 n ZIP file comment

If we search the file for that, we get:
000bcb70 78 2e 62 69 6e 50 4b 05 06 00 00 00 00 01 00 01 |x.binPK………|

So, from our Start PK 03 04 through to PK 05 06 we’re at position 0x14 through 0x0bcb79

If we write that out now –
dd if=lr_cmos_11_14_1_46.bin of=test.zip skip=0x14 bs=1 count=0x0bcb79

Then try unzip test.zip – we have a winner!

lawrence$ unzip test.zip
Archive: test.zip
inflating: linux.bin
lawrence$ ls -al test.zip
-rw-r--r-- 1 lawrence staff 772985 Apr 30 03:28 test.zip
lawrence$ ls -al linux.bin
-rw-------@ 1 lawrence staff 1628604 Dec 7 05:49 linux.bin


So, we know that the file has a header, then a zip file (which uncompresses to linux.bin, and has our linux binary), then more data.

If we take a look at what follows – ie the rest of the data in the original file after the end of the zip, it doesn’t look compressed

000bcb79 00 00 00 00 01 00 01 00 37 00 00 00 2a cb 0b 00 |……..7…*…|
000bcb89 00 00 2d 72 6f 6d 31 66 73 2d 00 08 cf a0 98 16 |..-rom1fs-……|
000bcb99 76 dd 72 6f 6d 20 34 62 31 63 62 36 38 66 00 00 |v.rom 4b1cb68f..|
000bcba9 00 00 00 00 00 49 00 00 00 20 00 00 00 00 d1 ff |…..I… ……|
000bcbb9 ff 97 2e 00 00 00 00 00 00 00 00 00 00 00 00 00 |…………….|
000bcbc9 00 00 00 00 00 60 00 00 00 20 00 00 00 00 d1 d1 |…..`… ……|
000bcbd9 ff 80 2e 2e 00 00 00 00 00 00 00 00 00 00 00 00 |…………….|
000bcbe9 00 00 00 00 00 c9 00 00 00 80 00 00 00 00 8c 88 |…………….|
000bcbf9 9d 47 73 77 61 70 00 00 00 00 00 00 00 00 00 00 |.Gswap……….|

…

000bd969 50 7d 64 68 63 70 63 00 00 00 00 00 00 00 00 00 |P}dhcpc………|
000bd979 00 00 62 46 4c 54 00 00 00 04 00 00 00 40 00 01 |..bFLT…….@..|
000bd989 11 70 00 01 37 60 00 01 50 e8 00 00 28 00 00 01 |.p..7`..P…(…|
000bd999 37 60 00 00 02 b5 00 00 00 05 00 00 00 00 00 00 |7`…………..|
000bd9a9 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |…………….|
000bd9b9 00 00 1f 8b 08 00 f4 6b 45 3f 02 03 dc 5b 0f 70 |…….kE?…[.p|
000bd9c9 14 d7 79 7f bb 77 a7 bf 07 9c fe f0 c7 48 a0 95 |..y..w…….H..|
000bd9d9 50 88 5c 23 b3 02 19 64 23 e0 84 30 76 72 b8 9c |P.\#…d#..0vr..|
000bd9e9 31 50 6c 2b 58 06 d7 25 84 d6 ea 80 6d 02 8c 7d |1Pl+X..%….m..}|
000bd9f9 48 02 64 17 b0 00 91 12 17 fb b6 29 ed 60 86 c6 |H.d……..).`..|
000bda09 4c aa 74 34 0e 71 0e 90 03 d3 d2 54 fc 51 87 30 |L.t4.q…..T.Q.0|

In fact it looks like more files…

bFLT is our flat ELF header…, and the other bits in-between look suspiciously like more files, and folders.
So, we probably have a filesystem in there.

Its late, and thats all for today, but it looks like we might even get to play around with both the linux image and the web UI image.

Just had another thought though – if you recall, our romfs size was 0x0008D000

Image: 6 name:romfs.img base:0x7F0E0000 size:0x0008D000 exec:0x7F0E0000 -a

What do we see here – in our header? 00000010 00 d0 08 00


00000000 42 4e 45 47 01 00 00 00 01 00 00 00 77 cb 0b 00 |BNEG……..w…|
00000010 00 d0 08 00 50 4b 03 04 14 00 00 00 08 00 3a 2e |….PK……..:.|


Seem to have a match, no? 0x 08 d0 00
I’m going to bet that our 0x 00 0b cb 77 also has some meaning too in our header 20 bytes, especially as the linux.bin zip file size is close to that at 0x00 0b cb 79.

Its highly probable I’ve miscounted something with the offset, and thats going to turn out to be the zip file size.

Now I’ve gotten this far, I’m too excited to go to sleep (its 4am here now!)

Lets try the filesystem from where we left off (aka from 0x0bcb79)
dd if=lr_cmos_11_14_1_46.bin of=unsure_what_filesystem.img skip=0x0bcb79 bs=1

mount -r unsure_what_filesystem.img
mount: unsure_what_filesystem.img: unknown special file or file system.

Nope.

Kyle’s blog comment has this gem in

however the ‘-romfs-’ tag is offset by 0×14

so I used the line

fx 6 romfs.img 0x7f0a0000 0x7f0a0014 -a

the system then rebooted correctly…”

Lets use that as the start.

hexdump -C unsure_what_filesystem.img |more
00000000 00 00 00 00 01 00 01 00 37 00 00 00 2a cb 0b 00 |……..7…*…|
00000010 00 00 2d 72 6f 6d 31 66 73 2d 00 08 cf a0 98 16 |..-rom1fs-……|
00000020 76 dd 72 6f 6d 20 34 62 31 63 62 36 38 66 00 00 |v.rom 4b1cb68f..|

-rom1fs- starts at position 0x12 [which is another indicator that I’m off by 2 bytes somewhere – as they mention 0x14 bytes, and the 12bytes prefix I have prior to the -rom1fs- are going to be from our second file header, I’ll bet…
0x0bcb79 – 2 = 0x0bcb77, which is what the previous header said, so that really makes me think thats the filesize now!

Our ROMFS works out to be 577 536 bytes, which is 0x8D000, which is also what the boot loader said, so getting a lot of good confirmation on these figures!]

Write that out to another file:
dd if=unsure_what_filesystem.img of=still_unsure.img skip=0x12 bs=1

Still doesn’t mount on my Mac, however, some more googling for rom1fs uclinux got me here

http://romfs.sourceforge.net/

Which specifically mentions –

Embedded projects using romfs

uClinux, the microcontroller Linux, is a port of the kernel, and selected user-space programs to capable, embedded processors, like some “smaller” Motorola m68k, and ARM systems.

ROMFS looks like:

offset content
+—+—+—+—+
0 | – | r | o | m | \
+—+—+—+—+ The ASCII representation of those bytes
4 | 1 | f | s | – | / (i.e. “-rom1fs-“)
+—+—+—+—+
8 | full size | The number of accessible bytes in this fs.
+—+—+—+—+
12 | checksum | The checksum of the FIRST 512 BYTES.
+—+—+—+—+
16 | volume name | The zero terminated name of the volume,
: : padded to 16 byte boundary.
+—+—+—+—+
xx | file |
: headers :

struct romfs_super_block
{

__u32 word0;

__u32 word1;

__u32 size;

__u32 checksum;

char name[0]; /* volume name */

};

Which looks to be a *very* good match for what that header has!
So, its in ROMFS format from the -rom1fs- start header.

(Mostly from here – http://zhwen.org/?p=articles/romfs)

Unfortunately my OSX box appears to be missing romfs support, so I can’t check it without going back to the office.

mount -o loop -t romfs still_unsure.img /mnt
mount: exec /System/Library/Filesystems/romfs.fs/Contents/Resources/mount_romfs for /mnt: No such file or directory

Booted up my Debian VM, and tried again.

debian:/mnt/hgfs/FI8908，FI8908W# mount -o loop -t romfs still_unsure.img /mnt/test -r
debian:/mnt/hgfs/FI8908，FI8908W# cd /mnt/test/
debian:/mnt/test# ls -al
total 4
drwxr-xr-x 1 root root 32 1969-12-31 18:00 .
drwxr-xr-x 4 root root 4096 2010-04-29 16:19 ..
drwxr-xr-x 1 root root 32 1969-12-31 18:00 bin
drwxr-xr-x 1 root root 32 1969-12-31 18:00 dev
drwxr-xr-x 1 root root 32 1969-12-31 18:00 etc
drwxr-xr-x 1 root root 32 1969-12-31 18:00 flash
drwxr-xr-x 1 root root 32 1969-12-31 18:00 home
drwxr-xr-x 1 root root 32 1969-12-31 18:00 proc
drwxr-xr-x 1 root root 32 1969-12-31 18:00 swap
drwxr-xr-x 1 root root 32 1969-12-31 18:00 usr


We have a winner!

Full file listing below:

.
|-- bin
| |-- camera
| |-- dhcpc
| |-- ifconfig
| |-- init
| |-- iwconfig
| |-- iwpriv
| |-- mypppd
| | |-- chap-secrets
| | |-- options
| | |-- pap-secrets
| | `-- pppd
| |-- route
| |-- rt73.bin
| |-- sh
| |-- wetctl
| `-- wpa_supplicant
|-- dev
| |-- console
| |-- display
| |-- dsp -> dsp1
| |-- dsp0
| |-- dsp1
| |-- fb0
| |-- hda
| |-- hda1
| |-- hda2
| |-- hdb
| |-- i2c0
| |-- i2c1
| |-- key
| |-- keypad
| |-- lp0
| |-- mixer -> mixer1
| |-- mixer0
| |-- mixer1
| |-- mouse
| |-- mtd0
| |-- mtd1
| |-- mtdblock0
| |-- mtdblock1
| |-- nftlA1
| |-- nftla
| |-- null
| |-- ppp
| |-- ppp1
| |-- ptmx
| |-- pts
| |-- ptyp0
| |-- ptyp1
| |-- ptyp2
| |-- ptyp3
| |-- ptyp4
| |-- ptyp5
| |-- ptyp6
| |-- ptyp7
| |-- ptyp8
| |-- ptyp9
| |-- ptz0
| |-- rom0
| |-- rom1
| |-- rom2
| |-- sda
| |-- sda1
| |-- sda2
| |-- sdb
| |-- sdb1
| |-- sdb2
| |-- smartcard0
| |-- smartcard1
| |-- tty
| |-- tty1
| |-- ttyS0
| |-- ttyS1
| |-- ttyS2
| |-- ttyS3
| |-- ttyp0
| |-- ttyp1
| |-- ttyp2
| |-- ttyp3
| |-- ttyp4
| |-- ttyp5
| |-- ttyp6
| |-- ttyp7
| |-- ttyp8
| |-- ttyp9
| |-- urandom
| |-- usb
| | |-- lp.sh
| | |-- lp0
| | |-- lp1
| | |-- lp2
| | |-- lp3
| | |-- lp4
| | |-- lp5
| | |-- lp6
| | |-- lp7
| | |-- lp8
| | `-- lp9
| |-- usi
| |-- video0
| `-- video1
|-- etc
|-- flash
|-- home
|-- proc
|-- swap
|-- usr
`-- var
`-- run

13 directories, 97 files

While I obviously can’t run any binaries locally, I can look at the text files to confirm that the ROMFS hasn’t just gotten the filesystem correct.

debian:/mnt/test/bin# cat init
mount -t proc none /proc
mount -t ramfs none /usr
mount -t ramfs none /swap
mount -t ramfs none /var/run
mount -t ramfs none /etc
mount -t ramfs none /flash
mount -t ramfs none /home
camera&
sh


debian:/mnt/test/bin# file camera
camera: BFLT executable - version 4 ram gzip


Looking *very* good.

Thats all for tonight, but it looks like we can easily add bits to the firmware using genromfs, dd, and a hex editor, or just genromfs, and someone willing to test a rebuilt user rom with an extra binary. Probably going to be telnetd as ssh requires a kernel recompile 🙁

Next step, actually doing that, and testing.

I’m definitely going to bed now – its 5:30am.

Tomorrow is a holiday though (in China), so happy May holidays!

I’ve finally received my 2nd camera, so I can now start working properly on it (assuming I get some free time too!)

High resolution photos of the board are below:

Main parts used are:

RAM – Winbond W9812G61H-6 (2M)
According to the data sheet, that 2M X 4 BANKS X 16 BITS SDRAM @ 3.3V / 166MHz/CL3
Data sheet is here – http://jp.ic-on-line.cn/IOL/datasheet/w9812g6ih_4223255.pdf

Flash – Spansion S29AL016D (2M)
Other boards are populated with different providers – some people have Samsung flash…
Mine has the Spansion onboard both units. Its programmable onboard (via the uBoot)
Data sheet here – http://www.datasheetpro.com/259722_view_S29AL016D_datasheet.html

Sound Card – ALC203
This is obviously used as the BSP for the Novotel provides sample code for that card, making their life easier…
Data sheet here – http://realtek.info/pdf/alc203.pdf

Wired Ethernet – Davicom DM9161AEP (10/100 Ethernet)
Data sheet here –
http://www.davicom.com.tw/userfile/24247/DM9161AEPProductBrief_v1.0.pdf

8 Port Relay Driver (for the motors etc) – ULN2803
Data sheet here – http://www.rentron.com/Files/uln2803.pdf
More info / explanation here – http://wiki.answers.com/Q/What_is_Relay_driver_ULN2803

Wifi – RALINK 2571 (on daughterboard). Wireless G
This is a USB based chipset, so we’re using 4 usb connector pins for this one.
No datasheet, as Ralink are dicks.

CPU – ARM7 N745CDG (Arm 7 by Nuvoton)
Lot of info for chip available at Nuvoton.

W90N745 makes use of the ARM7TDMI microprocessor core of ARMR and 0.18um production to achieve standard operation at 80MHz. 128-Pin LQPF packing is also used to save electricity and lower costs. The built-in 4KBytes I-Cache and 4KBytes D-Cache of W90N745 can also be set as On-Chip RAM according to the needs of product developers. With regards to system integration, W90N745 is suitable for network-related applications such as management switch, IP cameras, VoIP and printer servers.
Features
* One Ethernet MAC
* One USB 2.0 full speed Host controller
* One USB 2.0 full speed Host/Device controller
* AC97/I2S
* 4 UARTs
* I²C Master
* 31 GPIOs
* Power Management

Data sheets – http://www.nuvoton.com/hq/enu/ProductAndSales/ProductLines/ConsumerElectronicsIC/ARMMicrocontroller/ARMMicrocontroller/NUC745A.htm
The uclinux sample distribution and files can be downloaded here – http://www.metavert.com/public/NO-SUPPORT/NUC700%20Series%20MCU%20uCLinux%20BSP.zip

I’m just waiting on a JLINK USB adaptor, then I’m ready to roll.

[Updates]

David M from comments at http://irishjesus.wordpress.com/2010/03/30/hacking-the-foscam-fi8908w/#comments provided his rom sizing from his device, I’ve got some notes on that here.

MAC Address : 00:30:10:C1:D0:39
IP Address : 0.0.0.0
DHCP Client : Enabled
CACHE : Enabled
BL buffer base : 0×00300000
BL buffer size : 0×00100000
Baud Rate : -1
USB Interface : Disabled
Serial Number : 0xFFFFFFFF

For help on the available commands type ‘h’

Press ESC to enter debug mode …

bootloader > ls
Image: 0 name:BOOT INFO base:0x7F010000 size:0×00000038 exec:0x7F010000 -af
Image: 7 name:linux.bin base:0x7F020000 size:0x000BB334 exec:0×00008000 -acxz
Image: 6 name:romfs.img base:0x7F0E0000 size:0x0008D000 exec:0x7F0E0000 -a

My notes:

Image: 0 name:BOOT INFO base:0x7F010000 size:0×00000038 exec:0x7F010000 -af

[Image 0 is 38 bytes (small!).
Boot info is not the bootloader – 38bytes is way too small for that.
It actually stores our bootloader config settings.
eg ip address, cache setting, boot loader buffer address etc.
Our initial settings are below:

MAC Address : 00:30:10:C1:D0:39 (should be changed, this Mac range belongs to Cisco!)
IP Address : 0.0.0.0 (unset)
DHCP Client : Enabled (pulls ip from dhcp..)
CACHE : Enabled (onboard chip cache)
BL buffer base : 0×00300000
BL buffer size : 0×00100000
Baud Rate : -1 (unset / so defaults to 115,200,8,n,1)
USB Interface : Disabled (NC745 has no USB for bootloader)
Serial Number : 0xFFFFFFFF (unset)

-af indicates Active (a) , and is a Filesystem image (f)]

Image: 7 name:linux.bin base:0x7F020000 size:0x000BB334 exec:0×00008000 -acxz
[Image 7 is our OS – Linux 2.4.20 ucLinux Not sure why Maverick didn’t build on 2.6, there is more hardware support. Probably time dependant – 2.6 may not have been available, plus the Nuvoton sample code is also 2.4 based…

-axcz says active (a) executable (x) copied to ram (c) compressed (z) ]

Image: 6 name:romfs.img base:0x7F0E0000 size:0x0008D000 exec:0x7F0E0000 -a

[Our rom image – aka userland stuff. This is where we’ll be putting our own code. Looks like its stuck quite high up in the flash, although doesn’t need to be given size of the Linux rom. We have plenty of room available.

We’ll need to make appropriate changes to Image 6 size on flashing

-a says active partition.]