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

 ( trey | 2015. december 26., szombat - 9:18 )

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.

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

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 :-).

Ezért tart itt ez a világ ;-)

/sza2

Ennél csak egy rosszabb van, a leap seconds. Hiába akarsz te olyan időt, ami nem ugrál, még Linux-ot sem tudod TAI alapra állítani. NTP-ről nem is beszélve..

É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!

+1

Nem értem ez hol probléma. A usernek úgy megy az idő, ahogy kéri (tipikusan datetime UTC), amikor meg timeout-ot mérünk, akkor monotonic clock- ot használunk. A leap second-öt pedig elnyeli a time_t szabványosan. Logokban nem szép, de minden működik.
--
http://naszta.hu

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

32 biten csak 2038-ig vagy jó.

Update: most nézem, hogy előjel nélküli: ott az intervallum mérésnél lehet túlcsordulás cserébe...
--
http://naszta.hu

Azt elfelejted, hogy ott előjeles a dolog, így tudnak ábrázolni 1970 előtti időpontokat is. A kommentelő pedig előjel nélküli 32 bites egészet használ, úgy valóban 136 év a határ, (2038-1970) * 2 = 136.
Szerk: látom neked is leesett.

Vannak megoldások, ahol nem „rendes operacios rendszer fog futni”.
Ott kicsit 1xűbb ez a megoldás. És nem kevés ilyen van.

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á.

Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Chris Zhong <zyw@rock-chips.com>

HTH

--
trey @ gépház

Nem tudom, hogy ez min és hogyan segítene. Az a kiemelt Reviewed-by: sor nem abban a patchben van, ami kijelöli 2016. jan. 1-jét RockChip epochnak.

Utal arra, hogy tartják a kapcsolatot. A cég tud a problémáról, ellenvetést a részükről nem láttam.

--
trey @ gépház