Hi Branden,
VultureProg was mentioned - even a DIY emulator would be fairly straightforward; that's a nice microcontroller project.That seems a bit overkill, but then again flash chips seem to be more expensive then microcontrollers these days. I don't think I'm up to working on something like that right now though.
Not sure if that might be what you're looking for, but I have successfully used a memSIM2 emulator on a similarly old platform. It's basically an SRAM, some level shifters and a microcontroller to program the SRAM via USB. There's some open source software that can talk to the device; never tested the vendor software. Beware though that you must make sure that there are no +12V on the two pins that might be used for programming voltage; if +12V is present on the socket on the mainboard and you plug the emulator in there, it'll fry the emulator. I ended up plugging a socket with those two pins removed between the socket on the mainboard and the emulator.
Regards, Felix
While it looks like one of those emulators is available for surprisingly cheap compared to most (parallel) flash emulators, it is still quite a bit to spend on an old system just for messing around.
It seems kind of weird that it doesn't have proper isolation for the higher programming voltages commonly found on eeprom, though using a socket with those pins removed doesn't seem like too much work.
Peter Stuge wrote: Hi Branden,
I haven't had much luck in finding options for recovery. Ideally I'd like something like the dual switched bios in the old wiki but toggle-able electronically ie. gpio pin from spare router w/ Openwrt.
That's the product BIOS Savior RD1 from Taiwanese IOSS, switched by a jumper which could be replaced by e.g. a 2N7000 FET driven by a GPIO.
https://www.coreboot.org/Developer_Manual/Tools#BIOS_Savior https://www.overclockers.com/bios-savior/
There were a few different versions, IIRC one being for parallel 5V.
They seem no longer available, but you could add a watch on ebay or such.
I was thinking specifically of the "dual flash 'pie'" on that page,
Ah like this:
https://www.coreboot.org/Developer_Manual/Tools/Dual_Flash
Yes, that's a nice solution, if basic.
though really anything would be nice, even just the dip32 risers would probably come in handy.
A couple of "precision" style DIP32-sockets might do that job?
https://www.digikey.ca/en/products/detail/mill-max-manufacturing-corp/110-44... /947066
I'm thinking that ordering some dip32 and dip32-to-plcc32 sockets might be most cost effective for now. I think I already have some plcc32 parallel chips and I can get order more if I need and they are a lot easier to remove and insert then dip32 chips.
VultureProg was mentioned - even a DIY emulator would be fairly straightforward; that's a nice microcontroller project.
That seems a bit overkill, but then again flash chips seem to be more expensive then microcontrollers these days. I don't think I'm up to working on something like that right now though.
What capabilities do you have available? Any soldering equipment at all or not under current circumstances (hackerspace mention)?
I do have some basic soldering equipment and experience, but not a lot. I was hoping for some recommendations for more/better tools if I visited/joined the hackerspace.
Where are you located?
I'm in southern Manitoba, Canada.
Okay, so not Europe, but maybe I could send you something.
I just have a hard time justifying spending money just messing around with old hardware. Even just finding the correct hardware you want/need can be tricky a lot of the time.
I would really appreciate it if you think you have extra/spare hardware that I could use though.
I had been interested in checking out the hackerspace (skullspace) in Winnipeg sometime and seeing if anybody could help me with out with anything but never got around to it. It isn't really local to me though (~2hr drive), and isn't really an option right now for obvious reasons.
It's a great idea, I'm sure they would be able to help, but 2hr is not so great and yeah not feasible at the moment anyway.
I had still been considering messaging them, but I'm not sure that would help at this time.
That's great to hear. I hope you didn't need to build crossgcc-i386 on the P2B, though! :P
Well, it's got a gentoo install that has to build it's own updates, including the system compiler, as well as crossgcc-i386. .. It would probably be a lot faster if I could get a better cpu
You can use Gentoo releng's catalyst tool to build an i686 stage4 on any x86_64 build machine in half an hour or so, you'll just need to use a profile with i686 (17.0 should work) and possibly an older snapshot.
If you're interested in trying that I could help with a spec file, catalyst isn't very well documented.
I'm not sure that catalyst is really what I want, though it did occur to me now that you mentioned that I could probably use it for a different project.
It would be nice if you could just have portage/emerge on the client system request the build server to just make and send binary packages it wants to update - either everything or just whatever has a history of taking more then a certain amount of time on the client - even if it needed to cross compile and/or use qemu. I've seen at least one project that attempted this, but it was abandoned.
There's no way for emerge on the client to trigger catalyst on the build server, but the second half works out of the box; catalyst always creates binary packages, which are used by the client emerge by setting PORTAGE_BINHOST in make.conf.
So you have to trigger the build some other way (manually, or with other automation) but then have binary packages for easy installation on the client.
Well, that's the problem, there doesn't seem much in the way of automation for triggering the builds or for installing them, though it would be very nice if there was.
So far I've gotten by just by leaving it running to finish whatever it is working on,.
It works well - but takes a long time. :)
Yep, though it still destroys my raspberry pi v1 b, what a waste getting that thing was. Though I guess part (most?) of the problem is from poor io with the sd card & usb drive I'm using. I'll have to check the open rpi firmware again yet, maybe it's getting closer to usable, then maybe getting better storage could be justified.
Kind regards
//Peter
Thanks for the replies
Branden