Pro/Forums - View Single Post

MadMorgan · 10-14-2006, 07:56 PM

The PDC20265 will definately support lba48. Original promise driver was bugged but they released fixes for it later.
I'm rusty but could probably extract the updated op code if I had two flash images that I could diff. MB or fasttrack, and our bios. IDAPro FTW.
I'm fairly certain snap just used the bugged promise code, and then for whatever reason neglected to update when the fix was finally released.

As far as tearing up a system, I have one system giving 60000 errors, which someone stated is a mb. if that unit isn't usable anyway, I could care less.
Don't have the supporting hardware available any longer though. I think I'm limited to eproms lol.

I definately wouldn't be comfortable doing it unless I could get in there and emulate the NVRAM, or access that diag port so I would get more than one attempt at the bootloader. I'd have to send it out to the board house and see if they could even pull that flash and put a breakout in. SMT sucks at that density.

Then there would be the issue with recompiling the OS. I haven't touched 'make' in, oh.. too long. Besides, where would I get the source to even begin to recompile with the fixed driver.
This would be simple for adaptec to fix. but I doubt it can be accomplished without the source for the existing kernal. Adaptec won't because it would hurt revenues.

gigabit is probably a pipe dream. even if the pinout is the same, I'd have to imagine some of the supporting circuitry has to be different. same problem with a driver anyway.

So, I've just talked myself out of attempting this, lol. Probably the same ending as every other discussion regarding this subject. damned shame is all I can say.

Unless of course they updated the OS driver in one of the later releases, and the only problem is the bootloader still running the bugged code.
hmmmm.

10-14-2006, 07:56 PM	#382
MadMorgan Cooling Neophyte Join Date: Oct 2006 Location: Florida Posts: 5	Re: Snap OS 3.4.805, anyone? The PDC20265 will definately support lba48. Original promise driver was bugged but they released fixes for it later. I'm rusty but could probably extract the updated op code if I had two flash images that I could diff. MB or fasttrack, and our bios. IDAPro FTW. I'm fairly certain snap just used the bugged promise code, and then for whatever reason neglected to update when the fix was finally released. As far as tearing up a system, I have one system giving 60000 errors, which someone stated is a mb. if that unit isn't usable anyway, I could care less. Don't have the supporting hardware available any longer though. I think I'm limited to eproms lol. I definately wouldn't be comfortable doing it unless I could get in there and emulate the NVRAM, or access that diag port so I would get more than one attempt at the bootloader. I'd have to send it out to the board house and see if they could even pull that flash and put a breakout in. SMT sucks at that density. Then there would be the issue with recompiling the OS. I haven't touched 'make' in, oh.. too long. Besides, where would I get the source to even begin to recompile with the fixed driver. This would be simple for adaptec to fix. but I doubt it can be accomplished without the source for the existing kernal. Adaptec won't because it would hurt revenues. gigabit is probably a pipe dream. even if the pinout is the same, I'd have to imagine some of the supporting circuitry has to be different. same problem with a driver anyway. So, I've just talked myself out of attempting this, lol. Probably the same ending as every other discussion regarding this subject. damned shame is all I can say. Unless of course they updated the OS driver in one of the later releases, and the only problem is the bootloader still running the bugged code. hmmmm.