8 ms·

Shoddy hardware here, not shoddy software.

by dannyw 5y ago

nousermane 5y ago
Short of decapping and studying RK808 silicon, there is probably no way to tell with certainty whether this is a hardware bug, or a software bug, in what could easily turn out to be ROM for an internal 8051 core.
- toxik 5y ago
  If it’s a ROM, it’s arguably hardware - hard as in immutable.
  - andy_ppp 5y ago
    Not sure software that can’t be changed turns into hardware!
    - saurik 5y ago
      Yeah, I feel that's at best "firmware", but I would be very confused by "hardware"... watch there be some amazing term like "steadyware" ;P.
      - mjevans 5y ago
        I thought it was... Hardware - Immutable without physical destruction Firmware - Possible, but abnormal, to change (maybe limited times, risky) Software - Easiest to update, often during normal system lifetime Wikipedia's definition disagrees though, since it agrees that ROM is firmware (I agree EPROM is firmware since it can be modified with more extreme measures), but I suggest that is less correct than the categorization I outlined as I would like to include FPGAs, etc.
        andy_ppp 5y ago
        So computer games delivered on cartridges are hardware? This is clearly ridiculous.
        jimktrains2 5y ago
        Is an asic designed in an hdl like vhdl or verilog not hardware to you?
        vlovich123 5y ago
        HDL is still code and can produce hardware or software. The ASIC is 100% hardware because the logic is embedded directly into physical components. The same logic running on an FPGA is software although conversationally one might talk about it as being closer to hardware.
        Nexxxeh 5y ago
        The cartridges are hardware, the game within is software. Although yes, sometimes. I mean some cartridges like Super FX (Starfox) or SA1 (Super Mario RPG) SNES cartridges include specific hardware accelerators.
        Wowfunhappy 5y ago
        The point GP is making is that the game within the cartridge is immutable. But, I actually think cartridges are a great demonstration of how the hardware-software divide isn't obvious. Byuu used to write about the importance of capturing a cartridge's mapping. The chips in different cartridges are also connected differently, and if you don't capture that information, they game can't be fully recreated. Emulators either have to guess or use a database of known titles.
        mjevans 5y ago
        The cartridge would indeed be Hardware, possibly with some bit of firmware or software storage are for game saves. Technically it might be entirely Firmware if the manufacturers decided to just use a single EEPROM chip for the whole thing, even if during normal operation the software on the chip only ever re-programmed a single page.
      - slver 5y ago
        "soft with crunchy bits here and there" ...ware
    - deleted 5y ago
      [deleted]
- marcan_42 5y ago
  I know auxiliary micros are everywhere these days, but there is very little chance an RTC is implemented this way. RTCs are by design extremely simple, low power CMOS logic since they need to run off of a button cell for a decade. It's just a bunch of counters chained together.
  - nousermane 5y ago
    Chip in question is power-management IC, with RTC being just one function of. Others are (programmable) power sequencing and suspend/resume state machine, all accessible via same I2C interface. Here is datasheet: http://rockchip.fr/RK808%20datasheet%20V1.4.pdf http://rockchip.fr/RK808%20datasheet%20V1.4.pdf
    - marcan_42 5y ago
      Yes, and the RTC portion is going to be part of a separate always-on power domain and designed to consume single-digit microamps of power (5uA for this one). It's not going to involve a microcontroller.
      - dTal 5y ago
        But not necessarily the part that, on-demand, converts whatever kind of tick the RTC uses to human-convention dates.
        marcan_42 5y ago
        That doesn't really make much sense as a design. If they were going to return calendar dates, they'd count in calendar dates. I can't think of a reason why someone would implement something like that, it's just not how these things are designed.
- kevin_thibedeau 5y ago
  It most likely is. Built in RTCs need to operate off battery backup without the main processor running. A general purpose support microcontroller would burn more energy than a hardware calendar state machine.
slver 5y ago
The real WTF is that something as fuzzy as the calendar was done in hardware. Our time-keeping methods are notoriously fickle, the only stable thing is how long a second takes, and so that's the only thing we should have in hardware.
- thanksforfish 5y ago
  Even the length of a second is unstable in some implementations: https://developers.google.com/time/smear https://developers.google.com/time/smear
  - slver 5y ago
    Nah the length of a second is fixed as precisely 9,192,631,770 periods of radiation of caesium-133. The leap second concept again comes from the calendar. All of those higher-level concepts can come from software. The hardware just needs a clock that tells us how many (normal) seconds passed since someone shoved a battery on the thing, and how many seconds passed since the computer was booted. That's all. Well, also assuming it's approximate, unless the computer has caesium in it. Most pain in system design comes from poor judgments of where to put what. Separation of responsibilities can be non-obvious at first.
mikehollinger 5y ago
> Shoddy hardware here, not shoddy software. Mm-hmm. Story time! Let me tell you about my favorite chip bug that was resolved with firmware. :-) My first assignments out of college were on firmware for complex enterprise-class servers. I wrote power/thermal/clock control code, and was quite proud of doing integration tests like overclocking or underclocking a 256-core computer, and having it not crash. :-) We got a bug, though, that the system would crash down on first boot when it had been left unpowered in a thermal chamber overnight at the minimum ambient operating temperature. This simulated it sitting in a loading dock or warehouse before getting "rolled into the lab" for install. We all assumed condensation was a problem, but were able to disprove it by controlling the humidity in the chamber. Someone thought that some capacitors or the power supply weren't producing a clean signal, but we also disproved that. Interestingly, the system would boot up just fine if the engineers immediately shut it down and restarted it. If we tried to repeat the test on the same day, it'd pass. It only failed if we waited overnight. Looking closer at the crash, the crash reason was due to a thermal limit being tripped. The hardware was detecting an overtemp on one of the main processors. This was strange, because the test was a "cold start" test, and it wasn't triggering any warnings. The problem processor also changed each day/night we repeated the test. We actually were forced to wait ~8 hours between test windows because timing was inexplicably tied to reproducing the fail. I checked everything, confirmed that we'd programmed the correct warning and limit values, and while talking it out with the hardware engineer and explaining my logic, my hardware colleague who wrote the VHDL realized what was going on. The thermal sensor we were using had a margin of error that turned out to be +/- 10 degrees C. When the system was left at 5 degrees C overnight and started, the sensor's first readings might be 5 C +/- 10... and for an 8-bit unsigned register value, would result in an underflow, immediately tripping the hardware checker which was implemented as an 8-bit unsigned comparison. Rather than change the VHDL, we turned off the built-in thermal protection which thankfully had its own dedicated mode bits, and implemented a firmware protection scheme where my code (which could mask off the high order bit) would check the temp and set warning/error bits. If the high order two bits were set, we'd ignore the sensor value and just log an informational event. If the sensor didn't report an in-range value after a certain amount of time, we'd report that the sensor was bad, and fall back to a "failsafe" operating mode, iirc. It wasn't as fast as the hardware, so we had to add more margin, but it saved having to re-spin the processor. That code's still running in a bunch of machines out in the world today. :-) I should also say that all of the above discusses registers and logic that are outside of the architected state of the computer that normal software has no access to.

Shoddy hardware here, not shoddy software.

by dannyw 5y ago

Shoddy hardware here, not shoddy software.

Short of decapping and studying RK808 silicon, there is probably no way to tell with certainty whether this is a hardware bug, or a software bug, in what could easily turn out to be ROM for an internal 8051 core.

toxik 5y ago
If it’s a ROM, it’s arguably hardware - hard as in immutable.
- andy_ppp 5y ago
  Not sure software that can’t be changed turns into hardware!
  - saurik 5y ago
    Yeah, I feel that's at best "firmware", but I would be very confused by "hardware"... watch there be some amazing term like "steadyware" ;P.
    - mjevans 5y ago
      I thought it was... Hardware - Immutable without physical destruction Firmware - Possible, but abnormal, to change (maybe limited times, risky) Software - Easiest to update, often during normal system lifetime Wikipedia's definition disagrees though, since it agrees that ROM is firmware (I agree EPROM is firmware since it can be modified with more extreme measures), but I suggest that is less correct than the categorization I outlined as I would like to include FPGAs, etc.
      - andy_ppp 5y ago
        So computer games delivered on cartridges are hardware? This is clearly ridiculous.
        jimktrains2 5y ago
        Is an asic designed in an hdl like vhdl or verilog not hardware to you?
        vlovich123 5y ago
        HDL is still code and can produce hardware or software. The ASIC is 100% hardware because the logic is embedded directly into physical components. The same logic running on an FPGA is software although conversationally one might talk about it as being closer to hardware.
        Nexxxeh 5y ago
        The cartridges are hardware, the game within is software. Although yes, sometimes. I mean some cartridges like Super FX (Starfox) or SA1 (Super Mario RPG) SNES cartridges include specific hardware accelerators.
        Wowfunhappy 5y ago
        The point GP is making is that the game within the cartridge is immutable. But, I actually think cartridges are a great demonstration of how the hardware-software divide isn't obvious. Byuu used to write about the importance of capturing a cartridge's mapping. The chips in different cartridges are also connected differently, and if you don't capture that information, they game can't be fully recreated. Emulators either have to guess or use a database of known titles.
        mjevans 5y ago
        The cartridge would indeed be Hardware, possibly with some bit of firmware or software storage are for game saves. Technically it might be entirely Firmware if the manufacturers decided to just use a single EEPROM chip for the whole thing, even if during normal operation the software on the chip only ever re-programmed a single page.
    - slver 5y ago
      "soft with crunchy bits here and there" ...ware
  - deleted 5y ago
    [deleted]
marcan_42 5y ago
I know auxiliary micros are everywhere these days, but there is very little chance an RTC is implemented this way. RTCs are by design extremely simple, low power CMOS logic since they need to run off of a button cell for a decade. It's just a bunch of counters chained together.
- nousermane 5y ago
  Chip in question is power-management IC, with RTC being just one function of. Others are (programmable) power sequencing and suspend/resume state machine, all accessible via same I2C interface. Here is datasheet: http://rockchip.fr/RK808%20datasheet%20V1.4.pdf http://rockchip.fr/RK808%20datasheet%20V1.4.pdf
  - marcan_42 5y ago
    Yes, and the RTC portion is going to be part of a separate always-on power domain and designed to consume single-digit microamps of power (5uA for this one). It's not going to involve a microcontroller.
    - dTal 5y ago
      But not necessarily the part that, on-demand, converts whatever kind of tick the RTC uses to human-convention dates.
      - marcan_42 5y ago
        That doesn't really make much sense as a design. If they were going to return calendar dates, they'd count in calendar dates. I can't think of a reason why someone would implement something like that, it's just not how these things are designed.
kevin_thibedeau 5y ago
It most likely is. Built in RTCs need to operate off battery backup without the main processor running. A general purpose support microcontroller would burn more energy than a hardware calendar state machine.

slver 5y ago

The real WTF is that something as fuzzy as the calendar was done in hardware. Our time-keeping methods are notoriously fickle, the only stable thing is how long a second takes, and so that's the only thing we should have in hardware.

thanksforfish 5y ago
Even the length of a second is unstable in some implementations: https://developers.google.com/time/smear https://developers.google.com/time/smear
- slver 5y ago
  Nah the length of a second is fixed as precisely 9,192,631,770 periods of radiation of caesium-133. The leap second concept again comes from the calendar. All of those higher-level concepts can come from software. The hardware just needs a clock that tells us how many (normal) seconds passed since someone shoved a battery on the thing, and how many seconds passed since the computer was booted. That's all. Well, also assuming it's approximate, unless the computer has caesium in it. Most pain in system design comes from poor judgments of where to put what. Separation of responsibilities can be non-obvious at first.

mikehollinger 5y ago

> Shoddy hardware here, not shoddy software. Mm-hmm. Story time! Let me tell you about my favorite chip bug that was resolved with firmware. :-) My first assignments out of college were on firmware for complex enterprise-class servers. I wrote power/thermal/clock control code, and was quite proud of doing integration tests like overclocking or underclocking a 256-core computer, and having it not crash. :-) We got a bug, though, that the system would crash down on first boot when it had been left unpowered in a thermal chamber overnight at the minimum ambient operating temperature. This simulated it sitting in a loading dock or warehouse before getting "rolled into the lab" for install. We all assumed condensation was a problem, but were able to disprove it by controlling the humidity in the chamber. Someone thought that some capacitors or the power supply weren't producing a clean signal, but we also disproved that. Interestingly, the system would boot up just fine if the engineers immediately shut it down and restarted it. If we tried to repeat the test on the same day, it'd pass. It only failed if we waited overnight. Looking closer at the crash, the crash reason was due to a thermal limit being tripped. The hardware was detecting an overtemp on one of the main processors. This was strange, because the test was a "cold start" test, and it wasn't triggering any warnings. The problem processor also changed each day/night we repeated the test. We actually were forced to wait ~8 hours between test windows because timing was inexplicably tied to reproducing the fail. I checked everything, confirmed that we'd programmed the correct warning and limit values, and while talking it out with the hardware engineer and explaining my logic, my hardware colleague who wrote the VHDL realized what was going on. The thermal sensor we were using had a margin of error that turned out to be +/- 10 degrees C. When the system was left at 5 degrees C overnight and started, the sensor's first readings might be 5 C +/- 10... and for an 8-bit unsigned register value, would result in an underflow, immediately tripping the hardware checker which was implemented as an 8-bit unsigned comparison. Rather than change the VHDL, we turned off the built-in thermal protection which thankfully had its own dedicated mode bits, and implemented a firmware protection scheme where my code (which could mask off the high order bit) would check the temp and set warning/error bits. If the high order two bits were set, we'd ignore the sensor value and just log an informational event. If the sensor didn't report an in-range value after a certain amount of time, we'd report that the sensor was bad, and fall back to a "failsafe" operating mode, iirc. It wasn't as fast as the hardware, so we had to add more margin, but it saved having to re-spin the processor. That code's still running in a bunch of machines out in the world today. :-) I should also say that all of the above discusses registers and logic that are outside of the architected state of the computer that normal software has no access to.