LS1 Boost OS - Development

[Gampy]

Thank you, for the most part I don't care if it runs a vehicle or not, as long as it is a properly patched LS1BoostOS 76030003 bin.

If PCMHammerR20 works, and PCMHammerR21.2 doesn't, that leads me to believe the PCMHammer code base is broke and I (or someone) needs to fix it, I cannot fix PCMHammer (or at least look into it) without one, I don't know how to create one, don't care to know how either, I have no use for it other than to ensure it works in PCMHammer and fix PCMHammer if necessary.

-Enjoy

[In-Tech]

Hiya Gampy,
As I am listening to De Do Do Do Da Da Da Ya I am so happy to have found this place and all the great participants, you are one of my fave's

[Knackersjewels]

So I've just run it in the car, works fine, the OS definitely isn't happy on v21.

I'll need to find a wiring pinout for the 7603 OS, as it's different to VZ holden, the MIL and purge/vent pins don't seem to be the same, I'm getting dtcs for circuits, and no MIL on the dash

EDIT: looks like a comms issue, not wiring. Not getting fuel usage signal to the dash either, UART must be different

Keep in mind, this is in a VY, so fuel gauge is direct to dash, and DBC

[Gampy]

Thanks, I'll peek at it a bit later, I need to test my eyelids, they seem not to be staying closed long enough!

-Enjoy

[Gampy]

I just OS Wrote that bin (P59 76030003 VY L98 Manual Cammed.bin) successfully with R21.2, Now I am OS Writing back an Original 12587603 with my latest Assembly Beta, Successful, Now I am OS Writing that .bin (P59 76030003 VY L98 Manual Cammed.bin) with my latest Assembly Beta, Successful.

Hmmm ... Interesting. Situation isn't explained!
Am I drugged out and missing something here ??

Maybe I need to write the boost os, modify it's calibration, and write it again ??
That should be covered by my actions ...

-Enjoy

[antus]

The initial screen shot shows an "Intel 28F800B" detected, and then it says that the PCM size is 0.

The error comes from here, specifically pcmInfo.ImageSize

https://github.com/LegacyNsfw/PcmHacks/ ... er.cs#L221

Then we see "PCM and file are both the same hardware P01_P59" BUT it is using that because it has used the default clause, which dates back to the earliest days of PCMHammer, even ls1flash-free before that. That default clause, when an OSID is not recognised, contains:

https://github.com/LegacyNsfw/PcmHacks/ ... fo.cs#L843

Code: Select all

                default:
                    this.IsSupported = false;
                    this.KeyAlgorithm = 40;
                    this.Description = "Unknown";
                    this.ImageBaseAddress = 0x0;
                    this.ImageSize = 0;  <---------------------
                    break;

So, the simple fix is to get a description of what OSID naming conventions BoostOS does and will be using. Maybe section of some namespace for that purposes, like EFILive and HPTuners COS have done. Then we can add some logic that will detect BoostOS OSIDs and set ImageSize to 1024*1024 (1Mb). 76xxyyyy where 76 is P59 BoostOS, xx is major version, yyyy is minor version?

Then the better and additional part of the fix is to get rid of the default clause and error more clearly that an OSID is unknown. Also update that size comparison to compare against the size of the detected flash chip, not the image size looked up from OSID.

Edit: Having said that, clone write works for me also. I have also tested a calibration write, with the same file, and the results are as originally reported. So I guess this check is not triggered in the clone code path, but is in the cal code path. That in itself might also be a bug.

Edit2: Of course! Its related to the OS that is on the PCM. So if you are writing a BoostOS over a known OSID, such as your initial clone, then the check passes because the size was looked up from the PCMs original OSID. Then once it has BoostOS on it, you loose the ability to write because next time it'll not be able to find the BoostOS id. Fortunately, it looks trivial to improve this situation, as the flash chip type is retrieved only a couple of lines before hand and is in scope, so it's simple to refer to the flash size, rather than the size recorded against the OSID. It'll just take some time to clean this up properly and remove the size from the OSID. I can't see any reason hard coding this is necessary when we can always pull the flash chip type.

I still want to add BoostOS officially. Information about OSID naming convention is welcome, that can go in at the same time.

[Knackersjewels]

The initial screen shot shows an "Intel 28F800B" detected, and then it says that the PCM size is 0.

The error comes from here, specifically pcmInfo.ImageSize

https://github.com/LegacyNsfw/PcmHacks/ ... er.cs#L221

Then we see "PCM and file are both the same hardware P01_P59" BUT it is using that because it has used the default clause, which dates back to the earliest days of PCMHammer, even ls1flash-free before that. That default clause, when an OSID is not recognised, contains:

https://github.com/LegacyNsfw/PcmHacks/ ... fo.cs#L843

Code: Select all

                default:
                    this.IsSupported = false;
                    this.KeyAlgorithm = 40;
                    this.Description = "Unknown";
                    this.ImageBaseAddress = 0x0;




Love your work, that makes sense. I haven't tried v21 again with the calibration modified slightly, and v20 works with every write option.
                    this.ImageSize = 0;  <---------------------
                    break;

So, the simple fix is to get a description of what OSID naming conventions BoostOS does and will be using. Maybe section of some namespace for that purposes, like EFILive and HPTuners COS have done. Then we can add some logic that will detect BoostOS OSIDs and set ImageSize to 1024*1024 (1Mb). 76xxyyyy where 76 is P59 BoostOS, xx is major version, yyyy is minor version?

Then the better and additional part of the fix is to get rid of the default clause and error more clearly that an OSID is unknown. Also update that size comparison to compare against the size of the detected flash chip, not the image size looked up from OSID.

Edit: Having said that, clone write works for me also. I have also tested a calibration write, with the same file, and the results are as originally reported. So I guess this check is not triggered in the clone code path, but is in the cal code path. That in itself might also be a bug.

Edit2: Of course! Its related to the OS that is on the PCM. So if you are writing a BoostOS over a known OSID, such as your initial clone, then the check passes because the size was looked up from the PCMs original OSID. Then once it has BoostOS on it, you loose the ability to write because next time it'll not be able to find the BoostOS id. Fortunately, it looks trivial to improve this situation, as the flash chip type is retrieved only a couple of lines before hand and is in scope, so it's simple to refer to the flash size, rather than the size recorded against the OSID. It'll just take some time to clean this up properly and remove the size from the OSID. I can't see any reason hard coding this is necessary when we can always pull the flash chip type.

I still want to add BoostOS officially. Information about OSID naming convention is welcome, that can go in at the same time.

[Knackersjewels]

And Bubba, It'd be awesome if I could get a few tips on how the launch control is implemented, I had an issue where I enabled it at >70% tps, and it would spark cut while driving. Especially bad if downshifting, and giving a boot full, where rpm was higher than the launch rpm, the ecu would cut spark, but because rpm was 2000 above the launch limit, it would keep cutting spark even once the rpm was below launch rpm, I had to shut the car off to get it to reset to normal. Hope that makes sense.

I've since set the launch tps to 98%, but I feel it's either something I set incorrectly, or a glitch that may need addressing.

[bubba2533]

Then we see "PCM and file are both the same hardware P01_P59" BUT it is using that because it has used the default clause, which dates back to the earliest days of PCMHammer, even ls1flash-free before that. That default clause, when an OSID is not recognised, contains:

https://github.com/LegacyNsfw/PcmHacks/ ... fo.cs#L843

Code: Select all

                default:
                    this.IsSupported = false;
                    this.KeyAlgorithm = 40;
                    this.Description = "Unknown";
                    this.ImageBaseAddress = 0x0;
                    this.ImageSize = 0;  <---------------------
                    break;

The OSID's were added quite some time ago I believe, but there hasn't been an official release since that time.

https://github.com/LegacyNsfw/PcmHacks/ ... 2C1-L566C1

Code: Select all

                // usa 12586243
                case 12587603:
                case 12587604:
                case 76030003:
                case 76030004:
                case 76030005:
                case 76030006:
                case 76030007:
                case 76030008:
                case 76030009:
                    this.KeyAlgorithm = 40;
                    this.Description = "12586243";
                    this.ImageSize = 1024 * 1024;
                    break;

And Bubba, It'd be awesome if I could get a few tips on how the launch control is implemented, I had an issue where I enabled it at >70% tps, and it would spark cut while driving. Especially bad if downshifting, and giving a boot full, where rpm was higher than the launch rpm, the ecu would cut spark, but because rpm was 2000 above the launch limit, it would keep cutting spark even once the rpm was below launch rpm, I had to shut the car off to get it to reset to normal. Hope that makes sense.

I've since set the launch tps to 98%, but I feel it's either something I set incorrectly, or a glitch that may need addressing.

I made a video going over all the features. Let me know if you still have questions after reviewing that. https://youtu.be/EWI_rwSQsas (there are timestamps for most features).

[antus]

The OSID's were added quite some time ago I believe, but there hasn't been an official release since that time.

Thanks we'll have to get on to that. Make some decisions about what goes in to the next release and make it happen. If there hasn't been one in the next month or so, chase me up on it. We'll need to consider asm kernels, their stability, what goes in, and at this stage NSFW has made the releases, so I assume he'd do it again when we say we are ready and develop branch is in a healthy and tested state.