Byte patching an eeprom, need some help!

Hi there, new here, looks like the right forum to maybe provide a little help with my situation.

So here's what I'm up against.

I have been the proud owner of a Neo35 car jukebox since they were first introduced around 2001-02. This is a hard drive based mp3 player that can be removed from a vehicle (sleeve mounted) and used in other locations etc.

The main unit contains the IDE drive (I know, old right) and the mainboard, lcd display, and a few buttons. There is also a remote head unit for the car sleeve, which I have mounted in the dashboard of the truck, and it duplicates the display and controls on the main unit.

The CPU is a Hitachi SuperH SH-1 configured in PROM mode, and in addition to the DSP and other components on the main board, it is hooked up to a 29F040 flash eeprom that is in a 32 pin PLCC socket.

It was manufactured in the states by a company called ssiamerica, but apparently it is the same as another unit called the mstation by I think a company called traxdata.

The original OS as shipped was kind of buggy, didn't work all that well, so after a couple of years, the user community developed open source software for it called OpenNeo, which originally was a port from RockBox.

I have been running the open source software since it was released, waaay better than the stock OS. It went through several revisions, ending at ver 2.1 beta 14. Up until recently I was running beta 11.

I have been saving IDE drives for years now, as I need to replace them every once in awhile due to failures from bumpy roads.

The ssiamerica web site still exists, but they dropped the neo a long time ago. Similarily, around the time that Steve Jobs changed our world with idevices, the open source community also disappeared.

A couple months back, my drive died (expected) so I pulled it apart to install a replacement. It was at that time that I noticed that there was the beta 14 firmware on sourceforge, so I downloaded it, and went to flash it onto the neo. Thats when my troubles began, I should have left well enough alone. Oh well.

The method to update the neo was as follows. All you had to do was copy the new bin (renamed to either openuu.bin or neo35.bin) to the root of the drive. Then you would hold down the P (program) key when powering up, which would invoke the loader program. You would then select a menu item to program from the hard drive, and it would search the root directory for the file. If it found the file, it would tell you, then offer the option to proceed with a button push. Once done, it would write the new file to the eeprom, then say programming finished, reboot and away you go! Not this time unfortunately.

All I got was a blank screen. OK, I thought, I'll try it again. No go. same result. I could invoke the loader, but it was not able to write the flash successfully. I tried loading older versions, no go etc.

Not to be outdone, I thought well I'll just use my Willem programmer. Of course, this meant I had to get it working first, so after installing a LPT port on my win10 machine, and jury rigging the dll so it would actually work (it does) I tried my hand at it. I only know enough to be dangerous, and I managed to corrupt the eeprom on the first go.

I used the wayback machine and downloaded absolutely every page and file I could find, managed to get all the source code etc, even found some more bin files for both the loader and the main os, and found out a whole lot more, but there is still one part missing which is why I am here now. I am not a coder, and although I have gained a fundamental understanding of it all, the one thing I can't figure out is what bytes need to be at memory location 0000h on the eeprom although I know what they are supposed to do.

Normally, the loader boots first on power up and checks for the P button being pressed, if detected, the loader runs. If not it calls the main program which resides at a different location on the eeprom.

The loader is written starting at memory location 10000h and the main program is at 20000h. According to an obscure reference I found in an old forum post, there are some bytes at 0000h which "set up the CPU, then call the loader program". I cannot find anywhere what these bytes should be. I have seen references to vector tables, and in the source it talks about file alignment when writing to the eeprom, but I can't figure out the math to establish what it should be. It also makes mention of calling the routines at 10200h for the loader, and 20200h for the main program. I tried byte patching a jmp to those various addresses but nothing happens on power up. Now I am just pulling out my hair trying to figure this out. I am about to go on some very long drives, and need this thing to work again for my sanity.

Is there anyone here that might be able to provide some guidance? I can post or send all the info I have got. I would be very grateful, and so would my wife, who thinks I am avoiding her lately due to all this......

So a few questions to help me understand.
1) There is a hard drive which runs some kind of file system?
2) The bin file is copied to the hard drive?
3) There is a flash chip also in the device?
4) The flash chip is what runs the device or boots it up?
5) Do you know what the console prints in terms of operating system or boot loader information/version?
6) Can you boot the device if you do not push 'P'?
7) Has the flash chip been modified?
8) Are you able to unroll the bin file with binwalk?
9) Do you have reverse engineering skills and/or software?
10) Do you have a copy of the beta 11 or whatever the original binary file was?
11) Do you have the change logs for the binary files?
12) How many hardware configurations are there?
13) Was the hard drive replaced with compatible configuration and file system?

So a few questions to help me understand.
1) There is a hard drive which runs some kind of file system?

2) The bin file is copied to the hard drive?


3) There is a flash chip also in the device?


4) The flash chip is what runs the device or boots it up?


5) Do you know what the console prints in terms of operating system or boot loader information/version?


6) Can you boot the device if you do not push 'P'?


7) Has the flash chip been modified?


8) Are you able to unroll the bin file with binwalk?


9) Do you have reverse engineering skills and/or software?



10) Do you have a copy of the beta 11 or whatever the original binary file was?


11) Do you have the change logs for the binary files?


12) How many hardware configurations are there?


13) Was the hard drive replaced with compatible configuration and file system?


What I need to establish is exactly how the bin file is positioned, and what the initial code bytes at 0000h are. The location I am pretty sure I know as stated in my original post, the code bytes at the beginning of the ROM memory space are not documented, and may possibly be determined by accurately determining the install routine that runs when the loader program is updated. This is documented in the source code, but I can't make enough sense out of it with my coding skill level to see if those initial bytes are even there. Obviously something needs to be there, the one comment I managed to unearth with the wayback machine refers to it but does not give any specific details about it.

I have the source code, I have the reference materials for the components (CPU & eeprom) I even have the proper compiler environment setup to compile code in a VM, but thats when I hit my wall. I don't know how to snip up pieces of code to generate those initial bytes, over even what to look for to figure it out from here.

Thanks for getting back to me though!

I don't have experience with eeprom's but I used a utility called MBR Tool on my laptop's hard drive (that is, the Master Boot Record). The MBR is the first sector of the drive (addresses starting at zero). Inadvertently I zeroed it. Later I found the laptop no longer displayed the startup choices I had seen before.

To get my laptop working again I had to let the utility fill the MBR with a 'generic' startup routine. After that the computer started up okay. When examining the MBR I see canned system messages such as 'no OS on disk', 'disk read error', etc. However it no longer displays the startup choices which once allowed me to re-install Windows, or restore corrupted system files.

I suspect the MBR is supposed to be filled with your jump addresses, startup routines, menu options, etc. Perhaps you only need to install your custom simple startup program at memory location 0000h on the eeprom?

If you have the source code:

https://www.renesas.com/en-eu/produ...mbler/compiler-package-for-superh-family.html

I can't help you to patch it, the program only runs under Windows and I only have Linux.

Brian.

Thanks for answering those questions. My guess currently is this is an embedded OS style device, where the hard drive is a secondary data drive. Generally in those devices what you have is three main components for booting up: CPU, RAM, and a ROM. The ROM contains a boot loader that is stored where the CPU is design to read after a power on reset. This boot-loader will read the image out the ROM into RAM and/or decompressing the image before jumping into the main program. The boot-loader is generally also capable of performing additional task such as updating the main image in the ROM. Some are able to do this via a RAM/ROM based file system, others TFTP, secondary file system (hard drive), etc. It is also possible for the boot-loader to just be just used to update the image but the execute is out of the main ROM directly and not RAM. Really it just depends.

The issue now kind of is that the boot-loader is not functional. Which means this device may be in a state known as bricked. Which does not mean dead or damaged more than likely it just means it does know how to turn itself on. The bin files themselves can be somewhat complex and many times are not able to be programmed into the ROM directly. This is why the boot-loader is so important. I asked about the hardware version/change logs to try to explain why the boot-loader would have failed to correctly upload the bin file.

You said that you have code, but you did not specify which type of code? Boot-loader code or main code or the binary file itself? Do the people who release the code mention a work flow for installing it?

betwixt, bluelasers, BradtheRad

Thanks for your assistance, I am grateful. What I have setup at the moment is an older version of linux running on VirtualBox on my Win10 machine. I have source code (from the archived copy of the old, now defunct, website and chat forum for the open source community that existed over 10 years back. The source code I have covers many versions of the main os as it evolved over a couple years, and I have 2 versions of the loader/updater. According to what I understand from the scant documentation, the makefiles, and the few old forum posts I could find that even mentioned anything at all, compiler versions can matter, as newer compiler releases produce slightly different code in certain places occasionally, so according to the rockbox user website, you get better results from their downloadable pre-configured compiler environment. Either one would work in this case for sure, if the specific routine I need even exists there. This is the part I need help with, understanding the code I have to determine the point in the code that writes bytes to the first segment of an eeprom via the method I described in my original post. When these players were sold, they came preloaded with the os and bootloader on the eeprom, naturally so that it would function as intended for the end user. Therefore, the update utility, was already there, and was the *only* documented method for writing new firmware to the eeprom.

In my case, I lost that functionality including the ability to update it as intended when I corrupted the eeprom a month or so back, if that still worked, I probably would have it working by now. Unfortunately, I also don't have a copy of the original dump, as part of the reason things got messed up was that the chip wasn't making proper contact in the programmer socket, consequently I never even got a good read, and it got worse when I wrote the bin to it in that condition. I now am fully aware of that particular issue, and the quality of my reads and writes to it are reliable. I know where the file is to be written on the eeprom, and I can get it there no problem. The part I don't know is what code needs to be at the beginning of the eeprom to get things going, this isn't something that happened while the old forum was still alive, I can't find any of the old players there, I was a member on that forum at the time. From reading the responses here, I agree, the initial code that gets run must copy the loader and os to ram, then execute them there. Thats exactly what I need to figure out, is how to generate that exact code to copy things to ram on startup, then execute at 10200h. If you guys can help me do that, well alright! :grin: Does anyone here read and write code? C++ evidently.

So this is not really adding up anymore. C++ would not likely be the operating system and almost definitely not the boot-loader. Those are traditionally written in C or assembly at least on lower level devices. While in theory they can be written in C++, but that would be C more or less due the level of stripping required. Bare metal is another option with the same issues for C++. Generally C++ would be an application code more than likely, which would run in the operating system. The operating system would handle the update not the boot-loader. Can I ask your background is in terms of software and hardware? Why do you believe that those addresses are important?

So I mean if this is written in C++ then theoretically it may not have a boot-loader. There could be a sub routine that works in the same manner. Boot-loaders by definition do not really care too much about what they are loading. The are just small programs that run first to load code. Whether or not that code is an operating does not really matter. In the world of lower level systems just about anything is possible. Generally when things start to move towards file systems you are looking at an Operating System. This is done to accelerate development in many cases. Linux is common, but there are others out there. Then is real time operating systems and versions in between. Its not white or black, which is cool.

Many people here can read code in many languages. Me personally I know several, C++ is one them. However I am somewhat curious as to why the code is not posted already. I am also concerned about if the code is allowed to be posted depending on how it was acquired. Some of this topic is supposed to be about general purpose advice. I am somewhat hesitant to talk about the specifics of some reverse engineering stuff out of concern for legal issues.

Another thing that I am scratching my head at is this boot loader incompatibility. So the bin file was a generated program by you? Sometimes there is good amount of knowledge that the boot loader assumes about the binary file, however most are designed to detect and reject invalid files. Compile settings could do it, I guess. There is some basic initialization performed by the boot-loader that may be assumed by the program loaded. If this is incompatible then an issue may exist. However generally speaking so long as they do not over write one another they are not likely to interfere too much. One runs after the other finishes.

- - - Updated - - -

You can support file systems without an operating system, but given that this is using a hard drive I am guessing that this is not an Arduino here. So some of what I am saying is taking other stuff into account.

After re-reading your post: You did not attempt to update the system image with a user-space application, right?

- - - Updated - - -

So I forgot that we were talking about a SH-1 here. There is actually no real reason why this would or would not be running an operating system. It is possible to interface with the IDE drive outside of a high class processor, but it would probably be slow.

According to the relevant page on sourceforge right now, which is where I downloaded the beta 14 binary I wish to eventually use,

"It is written for the SH-1 processor in standard c with c++ style comments compiled with gcc."

I have that exact environment already set up, I just don't know what to enter into it. Generating what I have gets me no further than where I am right now. What I need is buried somewhere in the routine for updating the loader software, which I have the source for, and hopefully includes the section that writes the initial startup routine to the beginning of the eeprom memory space, and that only happens when this software is run as intended. That is not possible on a machine that cannot run the loader. So, if I send you the code, which I obtained legitimately from a public archive, would you be willing to see if you can create a makefile that will output that initial code? I can also post it here, if thats allowed, it is all open source I promise, nothing that doesn't belong to me legally. The wayback machine at the internet archive would not host illegal files.

We can look - but make no promises. I can use C and C++ but I'm not familiar with assembly language for the SH-1 series. Given the complexity of disk operating systems, it is quite likely it uses a 'standard' OS with extra code running as an application under it. For example, my TV, Blu-Ray player, security DVR and satellite receiver all run under embedded Linux but have their own persona defined by applications. In most cases, the lower memory area is reserved for vector tables and disk parameters so your problem may be nothing more than it being unable to correctly access the IDE drive. Bear in mind that incorrect disk parameters usually leads to total read failure because the drive heads don't know where to go, it rarely leads to partial operation.

Brian.

Hi again, in this case IDE access is not the issue. That function gets established once the bootloader/updater or main os runs. My issue is figuring out the code routine I need to put on the eeprom that gets them going in the first place. Its late here now, I will review the forum posting rules, and if its ok by that Ill post some source for you to look at. I also can put links to the hardware reference manuals too.