iT邦幫忙

2021 iThome 鐵人賽

DAY 28
0
Software Development

Port Alpine Linux to open source RISC-V platform系列 第 28

Alpine Linux Porting (2.1) clock is _not_ ticking

這篇開始基本上是進入持續分析有哪些未完善的部份需要進行補足。
依照這幾次的bootlog的部份分析,Alpine OpenRC-init的modloop以及hwclock/swclock兩個target是起不來的,且有錯誤顯示settimeofday是壞的。
modloop如名稱所示,是Alpine自己的世界觀中,如果有module需要runtime啟動、則從一個loopback去mount起來尋找,對於我目前的porting而言,我不太介意,但說後者會是我比較在意的部份。

簡單來說,syslog要啟動時,需要有正確的wall clock才有意義,OpenRC這邊給的第一條路是去呼叫userspace程式: hwclock來作wall clock設定;如果fail的時候,會啟動OpenRC自己的builtin:
https://github.com/OpenRC/openrc/blob/master/src/rc/swclock.c
其實也很簡單、就透過settimeofday這個POSIX規定的user API去設時間。

快速看過後,發現躺著這組東西在busybox的mailing list上:
http://lists.busybox.net/pipermail/busybox/2021-March/088583.html

籠統說來,這是一個musl-libc跟busybox造成的共同慘案。對於RISC-V32這種新世代的32平台來說,time_64t是基礎人權狀態,所以很多以前相關32/64相容的過渡性syscall直接是不存在的。但是目前musl-libc的compat32機制,是直接把settimeofday強制導向32版本:

int __settimeofday_time32() __asm__("settimeofday");

所以我的確有兩件事情要修正,第一件是要去修正musl的 arch/riscv32/bits/syscall.h.in,把 170 號的legacy settimeofday 槓掉、加上404號的 clock_settime64,但是這樣改完並不夠,因為目前整個使用邏輯是錯的,修正方向有兩條、一條是要去把compat32修好,另一條是apply那條patch、要busybox自己去call 404號syscall就好。

因為hwclock、也就是去找busybox做事是OpenRC的優先選擇,我決定這邊先apply busybox的部份。等下一篇開始驗證這套打通後,Alpine的OpenRC hwclock會不會正常運作起來。


上一篇
Alpine Linux Porting (2)
下一篇
Alpine Linux Porting (2.11) clock is _sorta_ ticking
系列文
Port Alpine Linux to open source RISC-V platform30
圖片
  直播研討會
圖片
{{ item.channelVendor }} {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言