LS1 Boost OS - Development

[bubba2533]

When I was doing Subaru stuff, I wrote a little utility that dumped the entire RAM to a file... Drove around for an hour or so, dumped RAM periodically, and eventually found a big unused space near the end.

It's not 100% deterministic, because it's hard to say whether some random undiscovered error handling routine will store a bunch of diagnostic data up there if something goes wrong, but it worked.

Anyway, I'll write something like that for the P01 / P59. Hopefully it will help us find some space that we can use.

Anyone know what the start and end addresses should be?

That’s a great idea and it would be awesome to have a utility like that to help.

I was thinking about ways to do it with pcm logger but it probably would have taken me days or weeks to get something to work.

Mode 34 supports 0xFF8000 - 0xFFC000. If that's also the memory range of the RAM chip, I should be able to dump the entire contents pretty quickly.

If the RAM chip covers more than 32k, then it might be worth finding the code that limits the mode 34 range, and then adjust the upper and lower bounds to allow mode 34 requests to cover the whole thing.

Yeah I can try to find the mode 34 code. I think there is unused space in the higher ram area that is shared ram with other chips, but I don’t want to mess anything up by using it unless there is no other way.

[bubba2533]

Well I think I found the Mode 34 routine at 0x41598...but there is a catch...

I did a search for 0xFF8000 and there were dozens of matches, but there was only a few matches for 0xFFC000 which made it really easy.

After looking at this code there is also a couple hard coded conditional tests. To get to the address limiting code the engine speed needs to be less than 200 rpm and the vehicle speed needs to be lower than 3 mph. There is some other code, but I don't know what it does.

That makes me think this won't work to get data while driving the vehicle, which is what I was hoping for. That would make me confident in finding an empty section that was logged as zero's and never changed throughout an entire drive. They must do those tests for some reason, and I have no idea what the results would look like.

[bubba2533]

What communication mode does PCM Logger use for logging of RAM addresses?

Maybe that could be utilized to cycle through all of the addresses in a range and I know that will work while driving.

[NSFW]

With my Subaru I treated it like data logging from RAM, and just started with the lowest RAM address and worked my way up to the highest, reading 4 bytes with each request. It worked, but it took about 20 minutes if I remember right.

For this, I was hoping to use Mode-34 messages to read about a kilobyte at a time. But, that 200 RPM check might be there because sending blocks of RAM would keep the ECU too busy to deal with spark plugs and fuel injectors.

I'll try the data logging approach.

[NSFW]

In the code on github, there's a little app called "VPW Explorer" that's basically just a scratchpad / playground for new ideas... I gave a "Dump RAM" button today. It's included in the attached zip file.

If you press it and wait about 15 minutes, it will read 32k starting at 0xFF8000, and save it to a file that has a timestamp in the name, e.g. "RAM-2022-04-09T18-28-43.bin"

So if you drive for an hour and save 4 files, they'll have unique names and you can compare them when you get home.

I think FF8000 is the base of the RAM chip, but I'm not 100% certain of that - it would be nice to have confirmation.

The PCM doesn't allow reading certain memory ranges - those will show up as FF.

EDIT - zip deleted, there's a bug.

[antus]

I think from memory last time I looked at this the pcm also needs to be security unlocked, because if it wasnt you'd be able read the security key out the param block mirror starting FF8000, so seed at FF8000 and key at FF8002. When I discovered this I thought I might have found a nice back door, but no.. it was covered. Also, not that you are talking about it but dont write to the mirror of the param block, if you dont get a crash and you key off the OS would copy your changes back to the param block of the main flash chip. If you were using it as scratch space that might be bad. It might be best to find an unused pid, and add your own ram read code that can return more 4 bytes in a single packet and doesnt have any of the restrictions on speed/rpm (which is used for engine not running), security unlocked, and read range.

[bubba2533]

Thanks NSFW I'll be sure to test it out!

However, I think after a handful of hours messing with the disassembly I've found a block of unused ram. Once I get my project up and running again I can test with that to verify the space is not used.

Yeah, I'm staying away from the Param Block areas. I think I have those areas mapped out now so I don't have to worry about them.

[NSFW]

The 'read RAM' request gets rejected for the FF8000 and FF8002 addreses, but there's a unique error code, so I just handle that and put 0xFFFF in the RAM.bin file for those addresses. It might be rejecting other addresses too, there are a lot of ranges that are 0xFF. (After I got the error code handled I didn't look into where else it was happening.)

Addresses that are 0xFF should be considered off-limits for now. Anything that always comes back as 0x00 is worth looking into. Between this tool and disassembly I think we can find usable ranges.

It might be straightforward to find the code that rejects requests for protected addresses and just replace it with NOPs.

Just for grins I'll try having it put 0x1234 into the RAM that it won't let us read, and see how that compares to the bins that I created yesterday.

[NSFW]

There's a bug in the RAM dump code in the zip file I uploaded yesterday. I'll add a new one shortly.

[NSFW]

Bugs fixed. Dumping RAM also takes half as long now because it's going 4 bytes at a time rather than 2.

'Blocked' address ranges are represented as EEEEEEEE now. There are some actual FFFFFFFF ranges in memory but I didn't notice any actual ranges of EE bytes, so this way it's clear which ranges are actually blocked.