Compensate for Rockchip calendar deviation on November 31st (2015)
git.kernel.org
git.kernel.org
[Edit] Not sarcasm, but when I was a young programmer I worked with a colleague on a system that detected short circuits in analogue circuit boards. Many of the variables in our code used the names of short people (Ronnie, Corbett, etc). We thought this hilarious. Our boss didn't, and gave us a stern lecture on the possible maintenance / legal ramifications.
Yeah, not funny.
Because the patch itself never made any such claim. It was the out-of-context headline here that implied it.
Not sure what you mean, the patch notes definitely make it sound like the Rockchip engineers did it intentionally...
Of course, naming variables funny names is probably a less good idea since variables will often have to convey meaning on their own. But that isn't true of the funny paragraph in this commit.
EDIT: I guess the submission title has been changed.
This is not correct. The last Protestant nation that adopted the Gregorian calendar was Sweden. The adoption was stepwise (including some oddities) and was complete in 1753 (less than 200 years). The Swiss canton of Grissons (which was half Protestant and half Catholic) adopted it in 1811. It was the Orthodox countries that took more than 300 years to adopt it. The last one was Greece in 1923.
Ever wondered why Calendar components in Microsoft's WinForms framework does not go further back then 1753? -- It was the first year when the British Empire fully used the Gregorian calendar (the transition was in 1752). Protestant software ...
Or more precisely, DOS is Protestant and Windows is Anglican, as discussed by Umberto Eco.
The Gregorian calendar was introduced in 1582 according to Wikipedia, so less than 200 by GP's comment.
[1] https://en.wikipedia.org/wiki/Monastic_Republic_of_Mount_Ath...
I hope it is not indicative of a dull and incurious mind that I have never wondered this.
Apparently the Rockchip chip has a bug, where November has 31 days. And you need to have this workaround in software.
Apologies to those who this confused - IMO that humor was one of the best features of the commit message.
It feels somewhat unfortunate that the post title has been changed and is now just bland and boring.
Somewhat on a tangent, why don't we use TAI in hardware, since UTC is discontinuous?
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.
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.
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.
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.
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.
Looks like it's caused confusion just 5 years later. Commit messages ideally shouldn't be like this, they're meant to be read by other humans in the future.
Like, I'm super tempted, to file my next bug as "Flaw in laws of universal order causing perfect software to misbehave in specific conditions"
No. The commit message is perfectly clear, the first line (the one highlighted in bold, which was also the subject line on the original mail) summarizes exactly what this is about, the first paragraph, although containing some mild sarcasm, is IMO perfectly clear about what the exact problem is and the second part explains how it is solved.
The only thing that is causing confusion is the headline on HN, by ripping a single sentence completely out of context.
EDIT: The title has now been changed to something less clickbaity. At the time I wrote this comment, it was "in 2013 Rockchip hardware engineers found that the new Gregorian calendar still contained flaws"
Imagine having to hotpatch a lot of the governments software because there's a new emperor.
Previous discussion: https://news.ycombinator.com/item?id=17430085
You know what most drivers do to those? They use them as second counters in the simplest way the driver writer could imagine.
And yet, more and more chips keep being made with over-complex RTCs
Popularity and/or intuitivity would be nice bonuses, but I'd value functionally correct/sane behavior more highly.
(I'm guessing this question belies my extreme ignorance of the field :), and that the RTCs in even eg basic Arduino etc designs are probably already reasonably decent.)
Edit: Just noticed the parent sibling comment about RTCs obviating divide/multiply logic. Much clicks into place now.
Edit: it's a power management IC for a SoC, not the SoC itself, but you often don't get much choice of those either since SoCs tend to be designed to pair with a specific PMIC. Whether the RTC is in the SoC or PMIC (or both) depends on the design.
That way no multiplication or division is necessary.
For any hardware with more than a few hundred bytes of RAM there is no need for it.
The MM:DD:YY HH:MM:SS 1/256 ticks format is unhelpful and annoying 99.9999% of the time. And is a source of bugs.
Another issue, is that while 28 is neatly divisible, 13 is not. What is half a year? When do you make up the numbers for Q3? etc. It introduces so much issues, that the net-benefit is hardly there.
Except that people can still be born and die and check in and out of hospitals on those days, so you have to be able to record those days, so they immediately get back onto the calendar but in a far uglier and more hacky way than the entire system that you just tried to replace.
Why not 8 days (5 work, 3 day weekend)? Or 6 days (4 + 2)
By the seventh day God had finished the work he had been doing; so on the seventh day he rested from all his work. Then God blessed the seventh day and made it holy, because on it he rested from all the work of creating that he had done.
[0] - https://www.discovermagazine.com/planet-earth/why-are-there-...
There are two definitions of seasons. In the simpler one, they start March 1, June 1, September 1, and December 1. (In the other, they are truer to astronomy and start about 20 days later.)
With 13 months in a year, that would be a lot messier.
Since there is symmetry to the year, it makes sense to divide it into a number of pieces that works well with that symmetry. 12 pieces makes sense because it's a multiple of 4.
If you look at the length of days as a function of year, it resembles a sine wave. You wouldn't create a unit of angular measurement where one full circle is 13 units. (You'd have trig identities like sin(x+13/4)=cos(x)!) There would be similar disadvantages if you divided a year into 13 pieces.
With the exception of February and an inversion after July, the pattern alternates binarily between 30 and 31. Thus, assuming zero-based months,
days = 30 + ((m+1 & 1) ^ (m > 6)) - (2 - isleap) * (m == 1);Kind of sad that we, as a planet, haven't managed to adopt a more uniform calendar. Here is my favourite: https://en.m.wikipedia.org/wiki/Symmetry454
Of course, "fix it in software" is cheaper. Sigh.
I know, I know, crap happens. But a review of something that basic should have been caught by someone at an earlier stage.
Can we call this calendar the “Juliun Calendar”?