PBO Firmware Audit (contents listing)

[mikez]

The portion of both available Patriot Box Office firmware updates that apply to NAND flash machines was the subject of our Binary Decomposition HowTo at: http://minimodding.com/BinaryDecomposition

The form of the six types of reports is described on our Lua File Audit page, at: http://minimodding.com/LFAreports

A tarball of the input text file for the report generator and all six reports output is available in our member's file gallery at: http://minimodding.com/tiki-download_file.php?fileId=127

Any special tools (like unyaffs and the lfa report generator) are also available from our member's file gallery under OSI approved licenses.
Oh, yeah, of course there are pages describing how to install those things also.

This announcement also appears in our PBO developer's forum, at: http://minimodding.com/tiki-view_forum.php?forumId=5

Now if someone would give me the links to the source code files (which should be available to any owner and are re-distributable). . . .

[visionlogic]

Since I'm a code dumba$$, this sounds like rocket science to me. What does this say/imply in laymen's terms?

[mikez]

It means:
*) What you can take apart, you can put together.
*) The functions and features are not a "manufacturer's closed shop"
*) That you don't have to wait for a manufacturer to "fix" something.
A consideration when your device only has gotten two updates (ASUS put out 6 updates last month).
*) It is fun to do, for people who like to do this stuff. People like retired rocket scientists - which I am. :)

[outatouch0]

Great post - hopefully it will help the very smart and talented people here do great things. :)



*) That you don't have to wait for a manufacturer to "fix" something.
A consideration when your device only has gotten two updates (ASUS put out 6 updates last month).


Only thing I wonder is what is contained in ASUS updates? IMHO just counting the updates doesn't tell us much...
Perhaps they took 6 updates to fix what PBO did in 1 or 2 (when ver3 comes out)?
Did the updates create more problems that needed updates?
Perhaps ASUS had more problems to be fixed than PBO? A cursory look at AVS forums - media players indicates to me that none of these are without problems.
Maybe someone on our forum has had other brands of this type player and can comment further? Is comparing the O'play to PBO "apples to apples" or "apples to oranges"?

[aasoror]

If O!Play / Xtreamer to the PBO isn't apples to apples .. nothing will be.

[mikez]

All good questions.

A bit of background would probably help -

Of the dozens of manufacturers churning out probably hundreds of models -
There are some very basic common points that they share:

*) There are very few manufacturers of SoC (System on Chip) devices that can do this type of heavy number crunching to make a picture on your TV (Realtek, Sigma Designs, (RaLink?) )

*) All of the low price devices run Embedded Linux to save on manufacturing costs. Some of the high dollar devices run WinCE.

*) It is (or can be) very expensive and time consuming to create an "Appliance Grade" (turn it on, it works forever) embedded computer system.
Nearly all manufacturers are using the same "code base" for their device's system.

*) The folks that developed that "code base" worked from an even smaller focus point, usually that provided by the SoC manufacturer (now your down to 2, 3? or a very few).

*) The vast majority of these SoC devices are licensed MIPS processor core designs.
So at the very root of all these things, is, count-em, 1 (one) original firmware configuration (usually the one provided by MIPS with their development boards to their licensees).

So what the end user sees on their screen may well be apples and oranges;
but at the root of things (pun intended) they are all trees;
in fact, they are all fruit trees.
My site, minimodding.com is where the tree surgeons gather.

This is in part one of the design considerations to identify files by their cryptographic hash sum.
From that a person can see that some (many?) of the files are bitwise identical across products and even across manufacturers.

For instance Patriot did not even bother to put their own name in the scripting of the bootcode update - it still has another company's product name in there. (More likely, their Linux Contractor forgot.)
If they had even changed one space character in the file, the sha1sum would not match others.

And, as you point out, everybody along the entire chain can make mistakes.
For instance, Patriot still hasn't learned how to spell: udpate.
I do not intend offend anyone, just an eye catcher when looking at the directory names in the firmware. I make many typo's every day myself.
Just fixed a few in this very post and probably still missed a few.

[outatouch0]

If O!Play / Xtreamer to the PBO isn't apples to apples .. nothing will be.

LOL :p

Yea, I like the fruit tree analogy

Part of what I wanted to point out is there are many references made to other players as if they are somehow faultless devices or something like that. As if one could return the PBO and get a WD, ASUS, etc. and their problems would be solved.

[mikez]

None can be significantly better as long as they are all basing the firmware on those development board builds.

That stuff is like an epidemic case of root rot running through all of the products that use it.
MIPS built theirs to demonstrate their core designs. . .
Realtek built theirs to demonstrate their SoC designs. . .
NONE where intended to run a consumer product.

And then there is the DvdPlayer application fungus. . .

But the economics just aren't there for a manufacturer to develop their own replacement system from the ground up unless they want a "loss leader" product to show that they know how many spaces to put in a *nix file name (none).

[The Globule]

It means:
*) What you can take apart, you can put together.
*) The functions and features are not a "manufacturer's closed shop"
*) That you don't have to wait for a manufacturer to "fix" something.
A consideration when your device only has gotten two updates (ASUS put out 6 updates last month).
*) It is fun to do, for people who like to do this stuff. People like retired rocket scientists - which I am. :)

This is all great...

...but for me, it boils down to this: How do I update the freaking boot code on my PBO?

Thanks.

[aasoror]

Now if someone would give me the links to the source code files (which should be available to any owner and are re-distributable). . . .

Here you are (http://patriotmemory.com/products/manuals/boxoffice/GPL_AP_267697.zip)...

[mikez]

That raises two key questions:

*) What state is you machine in?
+ Kernel up and running
+ ROM monitor/bootloader running
+ Neither of the above

*) Why?

Only in the third case above would you need to replace the ROM monitor/bootloader code.
In that case, you would have to write the PBO provided binary into RAM over the eJTAG port. You got an eJTAG cable, box, and software handy?
(ans: No, otherwise you wouldn't have to ask.)

The PBO provided binary could be loaded by the existing ROM monitor/bootloader if that is all that is running.
For that you need a connection to the serial port, the ROM monitor/bootloader only "talks" to the serial port.
You got a 3.3volt, low voltage serial to USB adapter cable handy?
** Now the second question becomes significant = if you have the properly function ROM monitor/bootloader code already running (as required by this state of recovery) - Why replace it?

If you are in state 1 - I.E: have a running kernel (which means you had to have a running ROM monitor/bootloader unless you loaded it over eJTAG) -
Then since the PBO provided "bootcode update" is in the same structural shape as the "UI firmware udpate [sic]" I suppose that you could do a "forced update" from USB stick with it, same as for the UI firmware udpate.
But again - Why?

If this forcing it fails, you will need that serial port cable;
Or if it fails after corrupting the existing ROM monitor/bootloader, you will need that eJTAG equipment.

So ask yourself three questions:
*) Why am I doing this?
*) Do I have my serial port cable hooked up and working if I need it?
*) Do I have my eJTAG equipment hooked up and working if I need it?
If satisfied with your own answers to the above - go for it!

The ROM monitor/bootloader lives in a write protect area of flash that also has hardware lock bits - - It lives under that much protection for a good reason;
So reconsider the answer you gave yourself to the the question: "Why?"

The Realtek ROM monitor/bootloader is a Realtek adaptation of the MIPS Yamon ROM monitor/bootloader.
You can get the user/reference/porting guide manuals from www.mips.com for free after registration, also free.
You can also get the Yamon source code from the same site but it has a "no re-distribute" clause in its license; you can't adapted it and re-distribute it.

[aasoror]

That raises two key questions:

*) What state is you machine in?
+ Kernel up and running
+ ROM monitor/bootloader running
+ Neither of the above

*) Why?



Why would you need the .16 bootcode replaced with the .18 bootcode ?
- boxes with bootcode .18 is sending lower voltage to the fan, thus running the fans at lower speeds, thus lower noise than same fan on .16 bootcode box.
- boxes with bootcode .18 is reported to run with HDDs more than 500GB, while boot .16 machines are having reliability problems with 640GB HDDs and 1TB HDDs.

[The Globule]

What state is you machine in?
Kernel up and running

The PBO provided binary could be loaded by the existing ROM monitor/bootloader if that is all that is running.
For that you need a connection to the serial port, the ROM monitor/bootloader only "talks" to the serial port.
You got a 3.3volt, low voltage serial to USB adapter cable handy?

Yes, I do :p

** Now the second question becomes significant = if you have the properly function ROM monitor/bootloader code already running (as required by this state of recovery) - Why replace it? :confused:

You are in state 1 - I.E: have a running kernel
Then since the PBO provided "bootcode update" is in the same structural shape as the "UI firmware udpate [sic]" I suppose that you could do a "forced update" from USB stick with it, same as for the UI firmware udpate.

I supposed the same but the PBO does not load the boot code update from the the USB stick, only the UI Firmware is updated :(

If this forcing it fails, you will need that serial port cable;

The ROM monitor/bootloader lives in a write protect area of flash that also has hardware lock bits - - It lives under that much protection for a good reason;
So reconsider the answer you gave yourself to the the question: "Why?"

Because there is a good reason Patriot updated the boot code on their device

The Realtek ROM monitor/bootloader is a Realtek adaptation of the MIPS Yamon ROM monitor/bootloader.
You can get the user/reference/porting guide manuals from www.mips.com for free after registration, also free.

Ok, I got the Yamon utility but it looks like it is for the eJTAG interface only. (I'd rather use the TTL serial port)

So here is my question again: How do I update the boot code on my PBO?

- Boot Code and UI firmware are loading at boot up and the PBO is working (I can telnet it)
- I will have a USB to 3.3v TTL interface available with working cable
- I have the new Boot Code in *.bin format

Which com software should I use?
What is the step by step procedure to get it done?

Thank you for helping.

[mikez]

These machines are not structured the same as computers.
Once the bootcode loads and runs something else, that is the end of its execution and control. done, overwith.

Now there may be something else that has a relationship between those release numbers and the problems reported, but it is not the "bootcode" part of the releases.

As you can see from browsing the six reports in your spreadsheet (each of the reports can be opened by any spreadsheet program, Linux, Mac or Windows).
There is a lot more structure and content to those firmware images than "bootcode".
One of the many reasons for producing the reports to begin with.

Since the problem areas you point out are all controlled at runtime by the Linux kernel, and since the builder is not savvy enough to change the kernel modification string in the version number. . .

Get the people who reported the problems to give you the full output of the command:
uname -a
Which will contain the build sequence number (undependable - the builder can reset that) and the date-time stamp of the builds creation (dependable - set by the kernel build system).
You will find a correlation between the build date-times and the problems.

It is just an artifact of poor packaging and naming that they appear to be related to the "bootcode" revision.

Read the reports yourself and you will see what I am writing about.

Repeat the study yourself, I provided complete details on how to do it.

Use the ROM monitor/bootloader commands to load each different version into ram (without burning to flash) and run the machine under them.
Note the differences and report back on the PBO developer's forum, someone there will help you - this isn't the place, this is a company fan-club site.

[mikez]

So here is my question again: How do I update the boot code on my PBO?

- Boot Code and UI firmware are loading at boot up and the PBO is working (I can telnet it)
- I will have a USB to 3.3v TTL interface available with working cable
- I have the new Boot Code in *.bin format

Which com software should I use?
What is the step by step procedure to get it done?

Thank you for helping.[/COLOR]

I don't have a clue, I don't own one of the machines.

I would suggest that you follow whatever instructions the PBO support people give you in reply to your question. They shipped the package, they surely know how to use it.

[outatouch0]

Note the differences and report back on the PBO developer's forum, someone there will help you - this isn't the place, this is a company fan-club site.

This forum may be a lot of things but FAN SITE :eek: is DEFINITELY NOT one of them.

Oh and you can go ahead and say anything here - even TOS violations.... nobody is "listening"

[The Globule]

I would suggest that you follow whatever instructions the PBO support people give you in reply to your question.

That is the problem, right there: PBO support is ignoring request for this process. The basic answer is to RMA the product to them.
In my experience, it is always better to have a DIY way out.


They shipped the package, they surely know how to use it.

You would think so, right? :rolleyes:

[mikez]

Software sources filed under "manuals" -
duh, glad I asked, would never have guessed that one.

Thanks for the link, will see if I can learn anything from the three files in that directory.

[mikez]

That is the problem, right there: PBO support is ignoring request for this process. The basic answer is to RMA the product to them.
In my experience, it is always better to have a DIY way out.



You would think so, right? :rolleyes:
Sounds like you got the background and a real problem -

Join my site where we have other PBO owners with enough technical background and the accumulated technical references.
I am sure our members can walk you through the changes and then we can add the information to our growing number of public HowTo pages.

No problem with linking back to that HowTo from here - your only one of nearly 300 web-sites linking to our technical content.
- - - -

I think I am beginning to see a pattern in all of this -
my guess is those "firmware updates" are produced by a third party, under contract and sent to Patriot;

Then whoever posts things at Patriot, posted what they where sent and
did not realize they where a "two part" package -
one update part for the factory service department
and one update part for the customers.

[aasoror]

I don't have a clue, I don't own one of the machines.




Join my site where we have other PBO owners with enough technical background and the accumulated technical references.


With all my respects .. now you got me confused ..
You are running a developers site for a product that you don't actually have access too .. you are building on "PBO owners with enough technical backgrounds" to help other PBO owners not to mention helping you materializing your ideas ... ?!

Your generic answers are really appriciated, and I admire your efforts considering that you don't even own the product, but (as I have been to your forum .. ) the members there are already members here .. even with the same screen name.

So if you really need to get traffic to your site, I suggest spending some money and get your own PBO then you can cook whatever ROMS/Firmware you want, because trust me (as I have been there before) you can't guide someone through cooking a custom ROM, you either know how to do it or you dont, and currently all the users here (and on your so called developers site) wont just take the risk.

Insulting the members here by saying that this is a company fan site, when don't even have the basic hands-on the device isn't what I can call smart advertising. If it weren't for this "fan club" you wont have been able to get the "source code" that should be helpful for any reverse compiling of the firmware.

You are welcomed if you are willing to share your expertise with us, else, I would look somewhere else for free advertising to your website ;)

Peace out.

[The Globule]

my guess is those "firmware updates" are produced by a third party, under contract and sent to Patriot;

Then whoever posts things at Patriot, posted what they where sent and
did not realize they where a "two part" package -
one update part for the factory service department
and one update part for the customers.

I believe you are right.

[mikez]

Yup - sounds like -

If it where done in-house, at least Patriot would have put their own name in the scripts. :D

That also explains the misspelled directory name -
If the "receiving department" at Patriot had split what they received into the two parts, that directory name would not even appear in either package.

Well, it has been a fun day - but I only posted here to announce the available of the report.
It is interesting to meet a group of users with lots of good questions.
Hope everyone has gained something from this thread, but I have to go back home and type where I belong now. :)

[aasoror]

I believe you are right.

+1 , its a no news though, Patriot involvement (or lack of involvement) in the firmware development was deducted several months ago already.

[mikez]

HowTo updated with link and credits:
http://minimodding.com/BinaryDecomposition#Archivist.

Many thanks,
Mike

[mikez]

The prefixed binary of the "bootcode update" image is a Realtek modification of the MIPS Technologies, Inc. Yamon ROM monitor/bootloader.

It does not appear to qualify under the terms of the MIPS, Yamon license to be re-distributable, except by Realtek/MIPS licensees.

Until a statement from Realtek can be located that places that code under an OSI approved license, the only safe assumption to be made is that it is a "closed source" modification of Yamon.

The Yamon license (and the source code) is available at www.mips.com

The HowTo has been updated to reflect that situation:
http://minimodding.com/BinaryDecomposition#Copy_off_the_binary_prefix.

But that should not matter with respect to the reason for the "How do I load the 'bootcode update'" question.
The "bootcode" itself is not involved with those problems, because the Linux kernel takes over the operation of the machine once it loads.

What is happen here, is that running the image named: "bootcode update" replaces the:
(1) the bootcode
(2) the kernel
(3) the entire set of system and application files.
It is something in the second and third items above being changed that "fixes" the reported problems.

And with only a few exceptions, (some proprietary applications) those portions are all "open source". Meaning the problem should be solvable.

[The Globule]

Thank you Mikez,
I hope someone will look at it and tell us how to do the update.

[mikez]

After a bit more thought, I can think of one possible way that those problems could be connected with the actual ROM monitor/bootloader code.

The MIPS cores have configurable iCache, dCache and TLB units.
Now Linux presumes those are hardware, or at least properly initialized "soft" hardware.

If the bootloader code where mis-configuring those devices. . . .
But at this point we hit the "closed source barrier".

The same sort of thing might be happening to any other "soft" hardware in the SoC (like a disk interface or a fan interface) that is only initialized by the bootcode and treated as if it was in fact, "hard" hardware by the kernel.
But here we run into the barrier that these Realtek chips are still under NDA.

Is the disk using the eSATA interface?
There have been problems with other machine brands using the 1073 chip's eSATA interface (I have two of them myself).

[The Globule]

Again, I believe you are right.
I also think the bootcode is initializing some hardware config before the UI system is loaded in memory and this is were the problem lies.

[The Globule]

Is the disk using the eSATA interface?
There have been problems with other machine brands using the 1073 chip's eSATA interface (I have two of them myself).

There is no eSATA interface on the PBO.
Only one internal SATA, one external USB 2.0 to use the PBO as external HD and two external USB 2.0 host ports.

[mikez]

Most likely the same port hardware, I think the only difference it the connector.

[mikez]

Again, I believe you are right.
I also think the bootcode is initializing some hardware config before the UI system is loaded in memory and this is were the problem lies.
I see that the server date-time shows that both -P01 and -P02 where (last) posted on Nov. 30, 2009.

ASUS reported receiving a "SDK update from Realtek" on Nov. 27, 2009 -
If that happens to include a "fix" for the Realtek bootcode -

I doubt that there was time to include it in either of the -P01 or -P02 builds.
You may have to wait for Patriot to ship a -P03 build.

ASUS is having theirs built by a contractor in Tiawan and it took them nearly 10 days (Dec. 7th) to turn out a corrected package that time.
So unless Patriot's contractor got it sooner, or works much faster. . .
Those fixes are not in anything posted Nov. 30th.

Don't you just love closed source? :(

[mikez]

I can refine that build date information a bit now -
The build date-time stamps in the binaries:

-P01:
801388AC 00000000 "Sep 4 2009"
801388B8 00000000 "14:15:26"
801388C4 00000000 "00.01.04"

-P02:
80139810 00000000 "Oct 26 2009"
8013981C 00000000 "21:15:13"
80139828 00000000 "00.01.04"
Hmm... 21:15? Somebody was working late!

So if the information from ASUS is correct, and Realtek didn't issue the fix until November...

[mikez]

Thank you Mikez,
I hope someone will look at it and tell us how to do the update.

PM tpublic - he is a member here and I know he has a working serial
port connection on his PBO from his blog on my site.

Perhaps he can give you links to directions, or the directions themselves.

He never posted any information in his blog about how he set up his serial
port connection or how he did the updates.
Perhaps he posted them here or elsewhere.

[mikez]

We have a first hand report with the details now:
New link:
http://minimodding.com/tiki-view_forum_thread.php?forumId=32&comments_parentId=1492

[The Globule]

mikez,

You are the man!

Thank you for looking this up for us. :confused:

[mikez]

A new user, a first post, it didn't exist when this thread was started.

Although it is on a Teknihall PO-1036 box, the post is using the PBO -P02 image, so it should work.

If works on a different brand (also with 128Mbyte flash) it should
work on the PBO - after all, it is the PBO firmware.
http://www.teknihall.com/index.php?id=794&K=1

Still need a photo so that people can see where to hook up the serial
port cable on a PBO - and tpublic hasn't yet replied to me.

Note The above link may break this afternoon while I create a
forum for this manufacturer's box - but I'll post a correction here when
I finish breaking the old one.

[mikez]

We have a first hand report with the details now:
The above link may break when I give that model its own forum, but
will cross-reference it in our Snippets Index (see: top bar : how to : snippets).
New link to Entity's post:
http://minimodding.com/tiki-view_forum_thread.php?forumId=32&comments_parentId=1492

[The Globule]

I edited and posted the Bootcode update procedure here (http://www.patriotmemory.com/forums/showthread.php?t=3060). :p

[The Globule]

Still need a photo so that people can see where to hook up the serial port cable on a PBO.

Here (http://www.hornettek.com/products/images/phantom_06.jpg) you are.
The TTL Serial port is on the upper left by the fan.

The pic is from a unit identical to the PBO

[mikez]

Here (http://www.hornettek.com/products/images/phantom_06.jpg) you are.
The TTL Serial port is on the upper left by the fan.

The pic is from a unit identical to the PBO
Ah, they give you the pin header (like ASUS does) already soldered in place.
I can't read the legend from that angle, but it looks like there is silk screened something
on the board, I presume the connector pins are marked.

[The Globule]

Yes, the pins are in and they are marked. :cool:

[MasterCATZ]

I am a bit late here

but could any one Direct me to a way to Backup the Firmware Via Realtek Rom Monitor ??

I have a Bricked unit .. and no Firmware I can Find on the net Suits it .. and wondering if its possible to reverse engineer a Firmware update from Working box

my Main Issue seems to be unit hardly has any space

I made a modded Firmware for it and got the size down to 16meg but it still did not take it ( pulled out usr Directory and changed mounting so it could load the big stuff externally firmware worked on my 256meg box .. which didn't need it !! )

REALTEK ROM Monitor, Revision 0000.1107.0007.
Copyright (c) Realtek Semiconductor Corp. - All Rights Reserved.

For a list of available commands, type 'help'.

Compilation time /version= Mar 18 2009 16:49:59 /0000.1107.0007

MAC address = 00.11.22.33.44.55

Processor Company ID/options = 0x01 (MIPS Technologies, Inc.) / 0x00

Processor ID/revision = 0x90 / 0x6c

Endianneós = Little
Flash memory size = 16 ÍByte

SDRAM size = 64 MByte

First free SDRAM address = 0x800888f0


Firmware kept failing here

Got firmware package file, "/mnt/usbmounts/sda1/install.img"
configuration.xml
install_a
AVHDD Verona installer (src rev:***64MB version...

303707)......Apr 1 2010 22:37: Memory address 0x40000000

01
call pli_init
pli initializFreeing memory...

ation...
try_to_free_pages: free 498

try_to_free_pages: free 1

try_to_free_pages: free 1

try_to_free_pages: free 45

try_to_free_pages: free 0

done (545 pages freed)

1. start remap DVR zone...

fastmode is 100...

map_done is 0...

map_fail is 0...

In my system...
[time] t=000.336
chip_id = 1282
SB2 DEBUG CONTROL(0)= 0x0 --> 0x0
SB2 DEBUG CONTROL(1)= 0x0 --> 0x0
SB2 DEBUG CONTROL(2)= 0x0 --> 0x0
SB2 DEBUG CONTROL(3)= 0x0 --> 0x0
SB2 DEBUG CONTROL(4)= 0x0 --> 0x0
SB2 DEBUG CONTROL(5)= 0x0 --> 0x0
SB2 DEBUG CONTROL(6)= 0x0 --> 0x0
SB2 DEBUG CONTROL(7)= 0x0 --> 0x0
SB2 INT = 0x0 --> 0x0
SB2 start addr(0)= 0x121e63a4 --> 0x0
SB2 end addr(0)= 0x1efb897d --
€@@@@@@@@@@À@@@@@@ `@``@@`@`@``À` `@`` Àààààààðààààààààà Ààààààààà€ðààààààààààààààààà€Àààðààààààààðààààà