Hardver bug az RK808-ban, avagy a Rockchip november 31-éje

Bug

Rockchip RK808

Érdekes problémára kellett a napokban a Linux kernel fejlesztőinek kerülő megoldást, azaz workaround-ot találniuk. Kiderült, hogy XIII. Gergely pápa Gergely-naptárát egy kicsit újraértelmezték 2013-ban a Rockchip mérnökei, ezért a Rockchip RK808 chip szerint az eredetileg 30 napos november hónap 31 napos.

Julius Werner egy ironikus megjegyzést mellékelt a workaround-ja mellé, amelyben kifejti, hogy a naptárreformok széleskörű elterjedéséhez sok-sok idő kell, például a Gergely-naptáréhoz is több száz év kellett, így várnunk kell addig, amíg az összes vallás és operációs rendszer kernel elismeri a Rockchip által javasolt változtatást. Viszont addig is vissza kell alakítanunk a Rockchip dátumait a Gergely-naptár formátumára.

Részletek itt és itt.

( asch v | 2015. 12. 26., szo – 11:40 )

Egyik matektanárom kedvenc helyettesítő-beugró témája volt az öröknaptár. Fejből nyomta, hogy mikor milyen nap van.

Nekem eddig egyszer kellett naptárat implementálnom egy beágyazott cuccba. Halálos szívás. Egy meglévő lib alapján generáltam táblázatokat. Csináltam hozzá hihetőségi teszteket is. A vége az lett, hogy a tesztek kihozták, hogy az eredeti lib egy távoli jövőbeli időpontban szétcsúszik. Na mindegy, az már nem az én bajom lesz :-).

És miért akarnál te olyan időt, ami nem ugrál? Az emberiség ugráló időt használ, mert így kényelmes, és így illik a megfigyelésekhez. Ez az ún. wall time.

A tudomány számára az időmérésnél meg csak az eltelt idő (elapsed time) számít, az meg mindegy, hogy a kísérlet közben a falióra és az emberi időszámítás mit mutat.

Egyáltalán nem mindegy: https://en.wikipedia.org/wiki/Leap_second

Aki kitalálta hogy a számítógép órájának UTC alapján kell mennie az nem volt normális. Minden eszköznek TAI alapján kellene működnie és arról kellene UTC-t számolni, ha ki akarjuk írni az időt a felhasználónak. Google nem véletlenül használ leap smeart, ők sem keresik a bajt. Még szerencse hogy van GPS time (=> TAI), csak kár hogy a rendszer órájának szinkronizációja után, az akkor is UTC szerint fog járni, mert csak.

Persze aki szeretne (rendszertől függően) 60-as másodpercet látni az időben vagy látni az időt megállni, az továbbra is választhatná az UTC alapot. Csak a többieknek ne kelljen ezzel szívni. Ennél már csak az a jobb ha local time szerint járatjuk az órát, sőt akkor már állítgassuk át téli/nyári időszámítás alapján is, ugorjunk órákat, sőt bizonyos "okos" helyeken csak perceket. Véletlenül se csak kiíráskor konvertáljunk, legyen ez az óránk!

( Finder | 2015. 12. 27., v – 11:26 )

Soha sem ertettem, hogy ezek a chip-ek miert hasznalnak ennyire bonyolult RTC-ket. Vegeredmenyben egy 64b-es masodperc szamlaloval jobban lehetne dolgozni ha ugyis rendes operacios rendszer fog futni rajtuk ami hasonloan tarolja az idot. Helyette mehet a BCD <-> binary atvaltas, time_t-re atszamolas, es a rengeteg specialis eset lekezelese, mert hiaba "okos" az RTC, ha a ilyen es ehhez hasonlo bugok vagy tervezesi hibak vannak benne....

+1

Sőt, rendes oprendszer sem követelmény. Mikrokontrollerre is úgy valósítottam meg téli-nyári időt, naptári napokat tudó órát, hogy bázis időhöz képest másodpercben mértem az időt, majd abból számoltam ki mindent. Annyira nem vészes a dolog. Az egészet assembly-ben írtam.

Sőt, az 1970-01-01 00:00:00-t is megtartottam bázisnak, viszont nincs időzóna, csak helyi idő. 32 bites pozitív egésszel 136 évet lehet ábrázolni, így 2105 végéig még jó.

Azért tegyük hozzá, ahol az idő szükséges, de nem valami fő funkció, ott jól jöhet a hardware-es segítség.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

( BaT | 2015. 12. 27., v – 19:03 )

Pedig megszokhatták volna már, hogy sokszor a hardver hiányosságait a szoftver fogja korrigálni. :)

Engem ezzel a patch-csel kapcsolatban csak az zavar, hogy egy linux fejlesztő önkényesen kijelölte 2016 január 1-ét Rockchip Epoch-nak, anélkül, hogy erre a gyártó adott volna javaslatot. Ha rajtam áll, én előbb megkerestem volna a gyártót, hogy egyrészt ismerjék el a hibát, másrészt adjanak ki hivatalos útmutatást, hogy hogyan kell azt kezelni. Akkor nem lenne probléma abból se, ha esetleg több rendszer használja az RTC-t, mert mindenkinek ugyanúgy kellene implementálnia a szoftvert hozzá.