[Letux-kernel] Successfully booting LetuxOS on Star64 (RISCV) board
H. Nikolaus Schaller
hns at goldelico.com
Sun Feb 8 13:48:17 CET 2026
> Am 08.02.2026 um 10:51 schrieb H. Nikolaus Schaller <hns at goldelico.com>:
>
> Hi Paul,
>
>> Am 07.02.2026 um 19:37 schrieb H. Nikolaus Schaller <hns at goldelico.com>:
>>
>>
>>
>>> Am 07.02.2026 um 19:25 schrieb Paul Boddie <paul at boddie.org.uk>:
>>>
>>> On Saturday, 7 February 2026 16:41:23 CET H. Nikolaus Schaller wrote:
>>>> Well, here is the first issue while running apt-get upgrade...
>>>>
>>>> Never seen such on other processors.
>>>
>>> [...]
>>>
>>>> [ 929.737878] [<ffffffff80b35e64>] __memset+0x60/0xfe
>>>> [ 929.737884] [<ffffffff802bba74>] folio_zero_new_buffers+0x70/0xae
>>>> [ 929.737891] [<ffffffff802bbb32>] block_write_end+0x80/0x8c
>>>> [ 929.737897] [<ffffffff8032f136>] ext4_da_do_write_end.isra.0+0x32/0x248
>>>> [ 929.737906] [<ffffffff8032f3a4>] ext4_da_write_end+0x58/0xd2
>>>
>>> [...]
>>>
>>> A paging error in the kernel, I guess. Such fun to debug, I'm sure!
>>
>> Indeed this will be a lot of fun...
>
> It seems to be quite repeatable. I just have to boot and run some disk activity (systemd background operations also seem to suffice). So it is confined to be either some SD card issue or in ext4 FS itself.
>
> I tried older kernels. 6.18.8 has the same effect. 6.12.68 or 6.6.122 do not boot.
>
>>
>> Well, I have a working 6.1.something kernel from DietPi but I am not sure if I can (re)construct that.
>> But what I can do is to compare the device trees... There may be something missing...
>
> What I observed is that the current setup uses starfive/jh7110-starfive-visionfive-2-v1.3b.dtb. I got this from looking into the U-Boot variables of the DietPi setup.
> But there is also jh7110-pine64-star64.dtb.
> I gave it a try. Well, the problem arrived only a little later after boot:
>
> [ 1325.400723] Oops - store (or AMO) access fault [#1]
> [ 1325.400737] Modules linked in: cdns3 cdns_usb_common roles snd_soc_simple_card snd_soc_simple_card_utils phy_jh7110_dphy_rx cdns3_starfive pcie_starfive clk_starfive_jh7110_vout dwmac_starfive stmmac_platform stmmac clk_starfive_jh7110_isp pcs_xpcs clk_starfive_jh7110_aon jh7110_trng spi_cadence_quadspi sfctemp jh7110_pwmdac spi_pl022 clk_starfive_jh7110_stg phy_jh7110_usb phy_jh7110_pcie snd_soc_spdif_tx drm configfs drm_panel_orientation_quirks backlight
> [ 1325.400806] CPU: 2 UID: 42 PID: 15741 Comm: store Not tainted 6.19.0-rc8-letux+ #5492 NONE
> [ 1325.400816] Hardware name: Pine64 Star64 (DT)
>
> [ 1325.400887] [<ffffffff80b35e64>] __memset+0x60/0xfe
> [ 1325.400893] [<ffffffff802bba74>] folio_zero_new_buffers+0x70/0xae
> [ 1325.400900] [<ffffffff802bbb32>] block_write_end+0x80/0x8c
> [ 1325.400906] [<ffffffff8032f136>] ext4_da_do_write_end.isra.0+0x32/0x248
> [ 1325.400915] [<ffffffff8032f3a4>] ext4_da_write_end+0x58/0xd2
> [ 1325.400921] [<ffffffff801c6c2a>] generic_perform_write+0x90/0x1fe
> [ 1325.400931] [<ffffffff8031cb62>] ext4_buffered_write_iter+0x56/0xe4
>
> Next idea is to try ext3 and not ext4...
I did and also ext2 - both on a different µSD to exclude hardware issues.
Unfortunately I now got:
[ 469.998096] status: 0000000200000120 badaddr: ffffffd600000000 cause: 0000000000000007
[ 469.998100] [<ffffffff80b35e64>] __memset+0x60/0xfe
[ 469.998107] [<ffffffff8020b46a>] do_anonymous_page+0x12e/0x37a
[ 469.998115] [<ffffffff8020d3f0>] do_pte_missing+0xac/0x282
[ 469.998121] [<ffffffff8020d616>] handle_pte_fault+0x50/0x164
[ 469.998127] [<ffffffff8020e000>] __handle_mm_fault+0x11e/0x1a2
[ 469.998133] [<ffffffff8020e0e4>] handle_mm_fault+0x60/0x16a
[ 469.998139] [<ffffffff80023342>] handle_page_fault+0xc4/0x502
[ 469.998147] [<ffffffff80b37048>] do_page_fault+0x1e/0x36
[ 469.998153] [<ffffffff80b41736>] handle_exception+0x146/0x152
[ 469.998165] Code: 1007 82b3 40e2 0797 0000 8793 00e7 8305 97ba 8782 (b023) 00b2
[ 469.998172] ---[ end trace 0000000000000000 ]---
[ 469.998177] Kernel panic - not syncing: Fatal exception in interrupt
So it is not FS acitivity related here.
Google AI tells that the badaddr ffffffd600000000 is too systmatic...
And, that the boot loader and OpenSBI v1.2 could be too old for modern kernels.
Especially for handling memory size (the board has 8GB but kernel tells it has 4GB).
A final suggestion was to reduce to mem=2G. WIth that, the boot process crashes after approx. 2 seconds.
And the final final hint was about checking the power supply...
Which all means this ends the "fun" session for now. It is changing into "a lot of work" to be done (i.e. have our own LetuxOS Boot system and hope it helps).
BR,
Nikolaus
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.goldelico.com/pipermail/letux-kernel/attachments/20260208/9e048c34/attachment.htm>
More information about the Letux-kernel
mailing list