Reason I ask is that I believe I identified a bug/issue with the FireBee that myself, Orion, and another user (I believe Oehansen) are having the exact same problem. Many times when cold booting our FireBees it will hang. To get the FireBee to boot we have to boot into EmuTOS once completely and reboot normally in my case into TOS404 for MiNT. The solution we are doing we each discovered on our own and do it slightly different but in the end it is pretty much the same problem and solution.

Now why do I ask about the location of the Date and Time in ROM? In my situation when I have to do my special start up routine to get my FireBee to boot the Date and Time will be 08-01-2010 12:44PM. The day before I would have set the FireBee to the proper date and time. It's known that the FireBee's Date and Time will drift slightly but I would expect that I would be a couple of minutes slow at the most the follow day not 5 years slow! Back to Orion he believes his battery is dead. I am not 100% sure if Orion put a voltmeter to test his battery or not. Mine acts like it is dead but my battery is fine and acts like it is dead.

Is the Date and Time issue causing the system not to boot or the system not booting causing the Date and Time to reset? To me it doesn't matter all that much. What does matter is that I believe is causing our FireBees not to boot properly without extra help is the area in ROM where the Date and Time are stored. Back to the main question or to rephrase the question, what in ROM do I need to reflash to correct the area in ROM that stores the Date and Time? BaS or FPGA?

Time and date are not stored in ROM. It's the PIC that holds it when off.

The PIC is a separate, small microcontroller that acts as real time clock and power controller. When you shut down your Firebee, the main processor (Coldfire) requests the PIC to cut mains power from the system, then the PIC goes into low power mode and (basically) only preserves time and NVRAM while waiting for you to hit the power button again. In low power mode, it can sustain from the internal battery up to four months even if disconnected from mains.

That said, there is a known problem with recent BaS_gcc that sometimes prevents FireTOS to cold boot for no apparent reason while EmuTOS comes up without problems. For now, I unfortunately was unable to find whats causing this.

If your mainly using FireTOS, I'd recommend (although it hurts) to flash original BaS instead of BaS_gcc. BaS_gcc has advantages when using EmuTOS (like "true" ST-RAM, faster networking in MiNT, bug fixes for MMU support and other things) but doesn't improve anything for FireTOS since the latter reinitializes all the settings that BaS_gcc does later on anyway.

Long story short: for FireTOS usage, better use original BaS for now until the problem is identified and fixed. Make sure you flash it from FireTOS, not EmuTOS.