ok so I disassembled boot5...

[bushing]

So, I was wrong earlier when I said that boot.pac and boot5.pac are encrypted ... it turns out if you skip the 7-byte header at the beginning of the file, it turns out fine.

I'd be happy to email the disassembled files to anyone who asks, but they weren't so helpful.  I've been sitting on this for a couple of days now, in the hopes that I could come up with some better answers, but I've decide I'm going down the wrong path.

I just read the patent that someone else here linked to, and here's my bigger-picture thoughts on the boot sequence of the PhatBox:

There are 5 places on-board the Phatbox that may be programmed:

• 2 flash ROM banks onboard the 8051 -- a 4k "emergency" bank and a 64k normal bank
  
• a PLD that's part of the IDE interface
  
• a PLD that's part of the headunit interface
  
• a 2-mbit (IE 256K) flash ROM chip that presumably contains the BIOS / boot code for the ARM
  

Here's where I think the code for each of these comes from:
4k bank: boot.pac or boot5.pac
64k bank: firmware.pac
IDE PLD: pre-programmed at factory through JTAG
headunit "glue" PLD: blank.bif/prog.bif
BIOS flash: programmed at factorty through ARM JTAG

Looking through boot5 didn't reveal much useful stuff.  It looks like the thing turns on, waits for 51d to boot up, and does some handshaking, eventually sending it a "start_ok" message.  It also has the capability to store a resume point, and send it back to 51d when it asks for it.   All this occurs over /dev/ttyS1, I'm now certain.

I still haven't been able to disassemble firmware.pac; I think it is encrypted, and that it is written in an encrypted format to the 64 K flash directly.

The Winbond '51 clone datasheet indicates it has the ability to "protect" that area of memory, and that if the protection flag is enabled, any attempts to read out the ROM contents will return "encrypted" data.  It doesn't indicate whether or not you could first turn on the "protect" flag and then upload ENCRYPTED data, but it's possible.  The only thing is, there's no further documentation about this encryption.  My guess is that they're just using a trivial cyclic XOR method.  These can be (relatively-speaking) simply cracked, but I don't think it's worth the effort at this point.  I think they actually ARE encrypting it to keep the details of the head unit interface proprietary, rather than obfuscating its involvement in the boot process (which doesn't start until 51d runs).  Since my interests are in the latter, not the former, I'll let this lie for now.

Ben

[ralph.deratt]

...
Looking through boot5 didn't reveal much useful stuff.  It looks like the thing turns on, waits for 51d to boot up, and does some handshaking, eventually sending it a "start_ok" message.  It also has the capability to store a resume point, and send it back to 51d when it asks for it.   All this occurs over /dev/ttyS1, I'm now certain.

Ben

Ben,
    From what I've seen I can confirm that there are startup messages between the arm and the 8051.  And that the are going over ttyS1, the second serial port on the arm.  I don't have a working logic analyzer at home, so I can't determine the baud rate.  Can you tell from the disassembly what the uart settings are?  (both ttyS0 and ttyS1)

On a related note.  I've hooked up to ttyS0, but I get nothing out.  I've checked it at least three times and I am certain that I'm connected to the right pins.  I have also confirmed that the VW Phatnoise pulls DCD,CTS,DSR to the correct levels.  

Has anyone been able to look at the linux sources to see if there is some special switch to turn on the the ttyS0 serial port?

RdeR

[judb]

Are you saying that you dont need a chip to correct the voltage swing to RS232 signal levels from what you can tell?

[bushing]

Ben,
     From what I've seen I can confirm that there are startup messages between the arm and the 8051.  And that the are going over ttyS1, the second serial port on the arm.  I don't have a working logic analyzer at home, so I can't determine the baud rate.  Can you tell from the disassembly what the uart settings are?  (both ttyS0 and ttyS1)

On a related note.  I've hooked up to ttyS0, but I get nothing out.  I've checked it at least three times and I am certain that I'm connected to the right pins.  I have also confirmed that the VW Phatnoise pulls DCD,CTS,DSR to the correct levels.  

Has anyone been able to look at the linux sources to see if there is some special switch to turn on the the ttyS0 serial port?

RdeR

Frome reading /usr/src/linux/Documentation/serial-console.txt, it looks like the system (indeed, any Linux system without a graphics card) should default to using the first serial port as /dev/console.

From reading the busybox source:

# Start an "askfirst" shell on the console (whatever that may be)\n" \
"       ::askfirst:-/bin/sh\n" \

askfirst is the same thing as respawn, except it prints out a message saying "Press enter to start a shell on this console".  (You may have seen this on linux boot cds.)

So, we should be getting that, as well as all the boot messages, on the first serial port.  HOWEVER, they could be using kernel parameters to redirect /dev/console -- no way to check that until we figure out what code is loading / booting the kernel.

[ralph.deratt]

Are you saying that you dont need a chip to correct the voltage swing to RS232 signal levels from what you can tell?

Yes you need a RS232 chip to convert the 3.3v signal to the correct levels.  But I've been dealing with serial ports for a while, so I know what the data looks like.  For a quick hack I used a simple transistor and a couple of resistors to make a simple inverter/level shifter.  I also looked at the output with an oscilloscope.

The TXD0 pin just goes high and that's it.  The second serial port on the other hand is sending/receiving data, but it's to/from the Winbond W78E516B.  

My thought was that phatnoise has some pin tied low that "disables" the output of /dev/console to /dev/ttyS0, but I too lazy to dig through the source right now...  PB1 (pin 19 ) and PB2 (pin 18 ) might be involved.


Vince, Can you give us any clues...


RdeR

[bushing]

Ben,
     From what I've seen I can confirm that there are startup messages between the arm and the 8051.  And that the are going over ttyS1, the second serial port on the arm.  I don't have a working logic analyzer at home, so I can't determine the baud rate.  Can you tell from the disassembly what the uart settings are?  (both ttyS0 and ttyS1)

Well... as for ttyS1...

from 51d:

Code: [Select]


set_serial_speed:                       @ CODE XREF: openserport+20
p
.text:00009840 termio_struct   = -0x58
.text:00009840
.text:00009840                 STMFD   SP!, {R4-R8,R10,LR} @ Store Block to Memory
.text:00009844                 SUB     SP, SP, #0x3C   @ Rd = Op1 - Op2
.text:00009848                 MOV     R1, SP          @ termios_p
.text:0000984C                 MOV     R5, R0          @ Rd = Op2
.text:00009850                 BL      tcgetattr       @ Branch with Link
.text:00009854                 MOV     R7, #0          @ Rd = Op2
.text:00009858                 MOV     R8, #010000     @ Rd = Op2
.text:0000985C                 MOV     R10, #1         @ Rd = Op2
.text:00009860                 CMP     R0, R7          @ Set cond. codes on Op1 - Op2
.text:00009864                 ADD     R8, R8, #2      @ r8=B115200
[...]
.text:000098F4                 MOV     R1, R8          @ speed
.text:000098F8                 MOV     R0, R6          @ termios_p
.text:000098FC                 BL      cfsetospeed     @ Branch with Link
.text:00009000                 BL      cfsetispeed     @ Branch with Link

from /usr/include/bits/termios.h:
#define  B57600   0010001
#define  B115200  0010002


to be continued....

[bushing]

from boot5:

Code: [Select]


                                                       main_4k:                                ; CODE XREF: RESET

code:002E                 mov     SCON, #0x50 ; 'P' ; serial port mode 1: 8-bit UART, baud rate set by timer
code:0031                 mov     PCON, #0x80 ; 'À' ; SMOD=1, multiplies baud rate x 2
code:0034                 mov     TMOD, #0x21 ; '!' ; timer 1: 8-bit autoreload (used to set baud)
code:0034                                                                                   ; timer 0: 16-bit timer
code:0037                 mov     TH1, #0xFF      ; Timer 1, High Byte
code:003A                 mov     TL1, #0xFF      ; Timer 1, Low Byte
code:003D                 setb    TR1             ; together, the above 6 statements set the bit rate to 57600


So, up there I had thought that the bit rate was 57.6k, but I got that logic from here: http://www.8052.com/tutser.phtml

I'm not sure what the crystal rate is on the 8051, and I'm more confident in my reading the ARM assembly, so I'm going to go with that 115200.

For ttyS0, the "default" baud rate in linux is 9600, again assuming this isn't changed in the kernel boot parms.

Hope this helps!
Ben

[ralph.deratt]

Hey bushing,
   Can you check if the arm code enables uart1 in the SYSCON1 register?

On a related note... I believe that the attempts to run a busybox program to "touch" or "cat" a file have failed because the drives are mounted read only.  (that's the way the empeg does it).  So trying to "touch" a file in the data partition probably won't work.  

It makes sense that the drives are mounted read only, because there's no need for the phatbox to "write" to the drives.  All state info can be stored in the tiny 24LC02 serial eeprom.


On the other hand, outputing to /dev/ttyS0 might work.  

RdeR

[bushing]

Hey bushing,
    Can you check if the arm code enables uart1 in the SYSCON1 register?

On a related note... I believe that the attempts to run a busybox program to "touch" or "cat" a file have failed because the drives are mounted read only.  (that's the way the empeg does it).  So trying to "touch" a file in the data partition probably won't work.  

It makes sense that the drives are mounted read only, because there's no need for the phatbox to "write" to the drives.  All state info can be stored in the tiny 24LC02 serial eeprom.


On the other hand, outputing to /dev/ttyS0 might work.  

RdeR

Where can I read more about SYSCON1?  Google isn't being very helpful.  

It appears that the linux serial driver code sets it when it initializes that port, which makes sense -- the question would be, does it initialize the port?

Can't say for sure, but here's part of their linux kernel build config file:

Code: [Select]


CONFIG_SERIAL_CLPS711X=y
CONFIG_SERIAL_CLPS711X_CONSOLE=y


So, unless they've disabled it in the kernel boot parms, it should be enabled.

(None of the phatbox user-level code touches it, as far as I can tell.)

The ro idea is an interesting one, and one I hadn't considered.  Unfortunately, to know for sure, we'd have to see the kernel boot parms, which is also where the console location is, etc, etc, etc.  However, doesn't it write out files like error_log.txt and box_id_mru.txt?  (I don't see any code to remount it rw before/after that.)

I wasn't aware of the serial EEPROM -- anyone have more info on it?  The usermode utils don't seem to use it -- instead, the "state", at least that required to support resume, is actually sent to the 8051 for savekeeping.  (This is described in the patent, actually.)

-b

[ralph.deratt]

I wasn't aware of the serial EEPROM -- anyone have more info on it?  The usermode utils don't seem to use it -- instead, the "state", at least that required to support resume, is actually sent to the 8051 for savekeeping.  (This is described in the patent, actually.)

Actually the eeprom hangs off the 8051.

As to SYSCON1, it's decribed in the EP7312 user manual which is on the Cirrus logic web site.

I don't currently have a phat box connected to a head unit, so I can't send commands, but I can get it to boot up and enter the ready state.  Any Ideas about running a command?  I'll redirect it to ttyS0 and then to console to see if there is a difference.

RdeR

[A543]

You guys are like brain surgeons on the Phatbox.  I'll just hang in the observation room and munch on some Jr. Mints.

[Paul]

Please do not eat anything (including Jr. Mints - refreshing as they are) in the observation room.

We've had some problems in the past with food being dropped into the server...

[judb]

okay first off, this might sound nitpicky but its an 8052 controller, not an 8051.. second from the data sheet on the 8052 chip:

"The instruction set of the W78E516B is fully compatable with the standard 8052.  The W78E516B contains a 64K bytes of main Flash EPROM and 4K bytes of auxilary Flash EPROM which allows the contents of the 64KB main Flash EPROM to be updated by the laoder program located at the 4KB auxiliary Flash EPROM ROM."

So thats what is being updated from the TTYS1 connection.  

The partitions are NOT mounted read only.  you can using alternate rc.sh scripts (that run the phatd, and is located on the phatsys partition) increment the logging level of the phatbox and that data gets written to a file in /dos (the phatsys partition mount point)  so I can say with 100% sureness that they are mounted Read Write.  The ramdisk might not be read/write but I dont know and I dont think it is important for it to be.

From what I read of the way the 8052 gets flashed I THINK the data gets written decrypted and then a protection flag is set that makes it where you can not dump that data out of the EPROM when the flag is set.  It might be possible to stroke the data off the serial port leads, OR to use the JTAG interface to dump it off the ARM CPU while its in memory.

Thoughts?

[judb]

in case you guys missed it, theres a FAQ section of the boards and this Thread has most of the datasheets for the surface mounted chips on the phatbox.. everything I could read the part numbers off of I tracked down and Para linked it in the FAQ for you guys.. hope that saves you some time...

[ralph.deratt]

in case you guys missed it, theres a FAQ section of the boards and this Thread has most of the datasheets for the surface mounted chips on the phatbox.. everything I could read the part numbers off of I tracked down and Para linked it in the FAQ for you guys.. hope that saves you some time...

Yup, seen the FAQ.  They need to add the user manual for the EP7312  It can be can be found here

Also the links to the pictures in the FAQ seem to be broken.  

It's a good start, but there is still stuff missing.  The jumper numbers don't seem to match my VW phatnose, e.g. JP8=JP4.  

RdeR

[ralph.deratt]

okay first off, this might sound nitpicky but its an 8052 controller, not an 8051.. second from the data sheet on the 8052 chip:

Fine

"The instruction set of the W78E516B is fully compatable with the standard 8052.  The W78E516B contains a 64K bytes of main Flash EPROM and 4K bytes of auxilary Flash EPROM which allows the contents of the 64KB main Flash EPROM to be updated by the laoder program located at the 4KB auxiliary Flash EPROM ROM."

So thats what is being updated from the TTYS1 connection.  

Nope, the messages the move across ttyS1 in a normal boot are just cmd/response between the EP7312 and the W78E516.  There not enough data for a flash reprogram.

From what I have measured, the W78E516 is responsible for booting up, turning on the power for the EP7312, powering up/down the harddrive,processing the head unit commands, and powering down the unit.

The partitions are NOT mounted read only.  you can using alternate rc.sh scripts (that run the phatd, and is located on the phatsys partition) increment the logging level of the phatbox and that data gets written to a file in /dos (the phatsys partition mount point)  so I can say with 100% sureness that they are mounted Read Write.  The ramdisk might not be read/write but I dont know and I dont think it is important for it to be.

Is there any chance that the files are symlinked back to a file on the ram disk?  Just because you can write to a file on a partition, it doesn't mean that it's mounted read-write.  

I have no idea if the partitions are mounted r/w or ro, but in a mobile environment, it just doesn't make sense to mount things r/w.  

From what I read of the way the 8052 gets flashed I THINK the data gets written decrypted and then a protection flag is set that makes it where you can not dump that data out of the EPROM when the flag is set.  It might be possible to stroke the data off the serial port leads, OR to use the JTAG interface to dump it off the ARM CPU while its in memory.

Thoughts?

I don't think "flashing" applies.   I can say with reasonable confidence that the W78E516 is not being flashed as part of the boot process.  Unless of course the forceupdate file is present.


So I still need a test case that I can use to send something to the serial port. e.g.

ls -al > /dev/ttyS0

How do I get the pb to execute such a command?

RdeR

[ralph.deratt]

[...]
Is there any chance that the files are symlinked back to a file on the ram disk?  Just because you can write to a file on a partition, it doesn't mean that it's mounted read-write.  

I have no idea if the partitions are mounted r/w or ro, but in a mobile environment, it just doesn't make sense to mount things r/w.  

Doh! I was wrong and Judd was right.  I just mounted the ram disk and the fstab shows that /dos partition is being mounted with the default (rw).  

overall the boot looks really simple.  It just does a  mount -a for /proc and /dos and calls rc.sh.  rc.sh mounts /dos/DATA and executes /dos/phatd


On the upside, busybox on the ramdisk, does have a symlink for the shell...

So now the command I'd like to execute is:

whoami > /dev/ttyS0

RdeR

[judb]

If someone could create a bash executeable for this arm arch and stick it in the phatsys partition i think that should give us a shell...  I still can't get any serial output but I am sure that the cable I made is a peice of crap.  My Digital Multimeter doesnt refresh fast enough to tell me the voltage levels on the TX of the UART1 lead to the JP8 so I am still not sure if we need a converter chip.

[ralph.deratt]

If someone could create a bash executeable for this arm arch and stick it in the phatsys partition i think that should give us a shell...

 

Here's a ls of the /bin directory from the ramdisk:

./bin:
[@        chown@  dmesg@   gzip@      mkdir@  ps@     sh@     tar@     uname@
@    test@    vi@ echo@    hostname@  mknod@  pwd@    sh
cat@      date@   false@   kill@      more@   rm@     sleep@  touch@   zcat@
chgrp@    dd@     grep@    ln@        mount@  rmdir@  stty@   true@
chmod@    df@     gunzip@  ls@        mv@     sed@    sync@   umount@


sh is in busybox, But I don't see how putting it on the phatsys partition will cause it to get executed.

here's the contents of /etc/inittab
::sysinit:/etc/init.d/rcS
::respawn:-/bin/sh
::ctrlaltdel:/sbin/reboot
::shutdown:/sbin/swapoff -a
::shutdown:/bin/umount -a -r

what does the "-" do in front of /bin/sh?

here's the contents of /etc/init.d/rcS
#!/bin/sh

/bin/mount -a

/dos/rc.sh

here's the contents of /etc/fstab
proc            /proc   proc    defaults 0 0
/dev/hda1       /dos    vfat    defaults 0 0

I still can't get any serial output but I am sure that the cable I made is a peice of crap.  My Digital Multimeter doesnt refresh fast enough to tell me the voltage levels on the TX of the UART1 lead to the JP8 so I am still not sure if we need a converter chip.

Your serial cable is probably working because there is nothing coming out of ttyS0 on a normal boot.  To test your cable, connect it to the second serial port, ttyS1.  Pins 11 or 13 on the W78E516.  The levels are 3.3v.  You'll see a small number of bytes moving  between the arm and the 8052 when the PB boots.


RdeR

[judb]

# /bin/sh invocations on selected ttys
#
# Note below that we prefix the shell commands with a "-" to indicate to the
# shell that it is supposed to be a login shell.  Normally this is handled by
# login, but since we are bypassing login in this case, BusyBox lets you do
# this yourself...
#
# Start an "askfirst" shell on the console (whatever that may be)
#::askfirst:-/bin/sh
# Start an "askfirst" shell on /dev/tty2-4
#tty2::askfirst:-/bin/sh
#tty3::askfirst:-/bin/sh
#tty4::askfirst:-/bin/sh

since no TTY is listed its going to go to the /dev/console device with is redirected to ttys0 in the ramdisk dev directory.

I swear there was some place in one of the startup files that i looked in (i think it was /etc/profile) that checks for /dos/bash in order to really give you a shell.. I think that will keep us from having true shell access until we get a bash exe in place.