BitHoist on Server

[historystamp]

Keep BitHoist in mind. Winter rolls around sooner than we all expect. It gave me a chance to learn PHP. Easier to learn & implement than I had expected.

I put PHP to work on another project I had been wanting to do for the last several years.


I think you can configure FTP to require a userid & password & limit access to one folder.

I'm not sure sure you can limit access enough in a shared environment. It's more of a gentlemen's agreement not to mess with other stuff. I get the impression that there is some protection, but there are known loop holes.

I'll read over this shared access stuff if I can find some library books on the subject. With the recession, libraries are not buying new books. Ten year old computer books don't do it.

Robert

[EagleMark]

Libraries have been taking a beating ever since the internet. Now with e books and such I think libraries are going to be antique stores... I used to enjoy going to library and reading all day and leave with a stack of books for the week, but the internet has replaced that...

Have FTP on my list to look into! I think the issue with 1project2many was CGI bin needed to be in main folder, but your dealing php so would just need absolute path from that folder correct?

[historystamp]

Announcing Beta version of BitHoist on GearHead-EFI server.

Check it out. Post comments & suggestions.

Free virtual beer for any bug reports.

Choose File -- Pick a bin file on your Personal Computer.
Upload

Picture 8.png

Here is the results.

Picture 7.png

I am using BitHoist with the -id option. Here is the complete list of options. Let me know if I need to specify any others. Half of them I do not know what they do or why they even exist.

Picture 9.png

[EagleMark]

It works!

Does not like LT1 bins, may have something to do with options, we need to get Robert Saar and 1projest2many to look at options!

[RobertISaar]

honestly, i have very little clue as to what a lot of those options mean.

[1project2many]

Most of the job of that software is manipulating calibration files. .bin as an extension indicates a file is stored as a binary file. But there are other data formats which were developed by various manufacturers to use with their hardware and / or software. Motorola, Intel, Tektronixs and others all have proprietary data formats. Bithoist will read a file in one format and write it in another acting as a converter between the formats. Almost all of the data used in the tuning community today is in binary format and there's little need for the average hotrodder to be switching between data formats so it's ok to leave the options -o and -b through -sig disabled.

Offsetting data can be helpful if trying to generate a file for disassembly in which the actual program line addresses match the addresses the program would occupy were it in the ecm. If the program actually starts at $8000 in the ecm, then make the first line $8000 instead of $0000 like it shows up in most hex editors. This might help identify various calibrations from different manufacturers although for most of the gm cals we use there's no need.

The include and exclude addresses can be used for calibrations that are made in segments such as the MEFI, or (as I've been told) the Northstar and OBDII cals. These cals have shorter sections inside which have their own checksums. For these programs it could be useful to specify only the sections of cal that are already identified or are relevant to identifying the cal. Again, at this time almost all the cals we work on do not require this additional functionality.

The -mask option is part of the -id process although I haven't spent a ton of time trying to work out how. This is a probably a diagnostic function to be used when teaching bithoist about new calibrations.

All said and done, IMO for the purposes of identifying a calibration -id is the only option that should be enabled.

[historystamp]

Here is what I've been able to figure out on how to use the command options. Just for the record.



-- typical invocation


mac $ ./BitHoist -id Sunbird.bin
File 'Sunbird.bin'
Address: 0xc000,0xffff
CRC: 0xf3680b8f
Mask ID: 58
ID byte: 0x58
Sum word: 0xd1ee
Sequence: Dec 3, 1990 #1420 (0D2A058C)
Scan ID: 3411
BCC: AUWR3607 (stock)




-- Print Tektronix format of hex to terminal


mac $ ./BitHoist -t -stdout Sunbird.bin
%2A6EE4C0000D530D2A058CD1EE58800A9715F100E8
%2A6CE4C0105FD03AF8A002000D00FF00EB001000AB
... clipped ...




-- Note BitHoist sends "normal" output to stderr.
-- To redirect all to stdout, do:


mac $ ./BitHoist -id Sunbird.bin 2>&1
File 'Sunbird.bin'
Address: 0xc000,0xffff
CRC: 0xf3680b8f
Mask ID: 58
ID byte: 0x58
Sum word: 0xd1ee
Sequence: Dec 3, 1990 #1420 (0D2A058C)
Scan ID: 3411
BCC: AUWR3607 (stock)




-- all to a file


mac $ ./BitHoist -id Sunbird.bin >myout 2>&1
mac $ cat myout
File 'Sunbird.bin'
Address: 0xc000,0xffff
CRC: 0xf3680b8f
Mask ID: 58
ID byte: 0x58
Sum word: 0xd1ee
Sequence: Dec 3, 1990 #1420 (0D2A058C)
Scan ID: 3411
BCC: AUWR3607 (stock)




-- When you run with the -id parameter, you will get the range of
-- addresses of the binary data in the bin file. Use 0x before a
-- number to indicate hex.


mac $ ./BitHoist -t -stdout -r 0xc000,0xc04f Sunbird.bin
%2A6EE4C0000D530D2A058CD1EE58800A9715F100E8
%2A6CE4C0105FD03AF8A002000D00FF00EB001000AB
%2A6864C0200017005B2A30000AE0080C0906000000
%2A6054C0304493CAB862FFFDFD320A14647800C804
%2A6F44C040B00BB8A0404F7C101EA703E9043C90BF
%0781010




-- Run with mask option


mac $ ./BitHoist -mask Sunbird.bin
---- cut here ----
0xc000, 0x10000, 0xc000, 0xc002, 0xc006, 0xc008, 0x80290058, 0xb4bb275c,
#ifndef rez
1, 1,
#endif
begin
0xc000, 0x10000
end,
begin
sumlo, sumhi
end,
---- cut here ----

[historystamp]

Does not like LT1 bins, may have something to do with option

Please post bins.

I'd like to see how they fail, so that I can collect a list of enhancements.

The BitHoist code has provided mostly unfathomable to me. It's written in C without comments. Correction, I did find two comments in the code. I don't count the copyright statements.

I think that it doesn't analyze modified bins per comment by 1project2many. I'm assuming these bins need to be added.

I've found references to a program to add a new bin to "database" of bins. ( The "database" is an .h file. ) I get the impression there was a separate program to make the addition which I do not have. My current thought is to run a new bin through BitHoist. Write a program to reformat the data to the format BitHoist expects to find.

I think I'm taking a summer break though. I'll continue on getting the current implementation squared away on the server.

Robert

[EagleMark]

Maybe Robert would know if it has to do with the Motorola Hex output option? I seem to remember LT1 being motorola or two chips or?

Here's a link to Lt1 bins
http://www.gearhead-efi.com/Fuel-Inj...rmation-EE-EEB

It may just need the bin database updated as the program is probably older then 1994 when LT1 in $EE came out. then this would need 16197427 $0E and $0D bins etc... we have a ton of bins if you can figure out how to get them in database...

[RobertISaar]

94-95 LT1 BINs are actually 2 64KB BINs stacked on top of each other, one for each processor in the PCM.

that's about all i got. i'm not really certain of what it being accomplished here, i'll start reading from the beginning again.

[1project2many]

Based on some of the ID's bithoist has done for me, the mask is identified by looking at the locations of the various table headers and the ID is called out based on scan ID and identified mask. I don't know how to identify headers other than testing for all possible combinations and calculating a checksum or result to match against a database. If a mask is ID'd then the next step is checking scan ID against the database. Finally, the GM checksum is calculated based on the data against the chip and compared to the checksum for the stock calibration in the database.

First test is to run the same .bin through bithoist with altered scan IDs. That would tell us if the ID follows the scan id once the mask is identified. Then you could take a stock .bin and alter table header data (I could help with this) and see what result -id generates.

I'm sure we can figure out how to put more cals in the database.

[RobertISaar]

i actually just did some of that... ran a BFBD file through, info came out correct. changed the mask ID to AA, no results. changed to 8D, no results.

it didn't like my 94-95 3100 flash BINs either. LOL.

[1project2many]

If the mask ID is wrong but the checksum is correct it will (usually) report what the correct mask ID should be. I'm talking about changing the actual table headers, the data which would tell the ecm for example "table begins at $4111 and is 16 cells by 16 cells."

[RobertISaar]

yeah, i read it wrong the first time over.

i just changed the mask ID using the TP hex editor from A1 to AA/8D, so the checksum updated when it was saved.

[EagleMark]

I have a known stock chip (ADSU out of my truck) and it came back as stock. Same chip with HiWay Lean Cruise came back as ? and a few choices so it can and does pick up stock chips!

But another I thought to be stock came back as same chip but did not indicate stock?

So we will need to come up with instructions and guidelines for what it will do and what results mean?