Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
From:   Zhangjin Wu <falcon@tinylab.org>
To:     w@1wt.eu
Cc:     aou@eecs.berkeley.edu, falcon@tinylab.org,
        linux-kernel@vger.kernel.org, linux-riscv@lists.infradead.org,
        linux@weissschuh.net, palmer@rivosinc.com,
        paul.walmsley@sifive.com, paulmck@kernel.org
Subject: Re: [PATCH 0/2] tools/nolibc: riscv: Fix up compile error for rv32
Date:   Sat, 20 May 2023 22:31:54 +0800
Message-Id: <20230520143154.68663-1-falcon@tinylab.org>
In-Reply-To: <20230519094030.GA24947@1wt.eu>
References: <20230519094030.GA24947@1wt.eu>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Feedback-ID: bizesmtp:tinylab.org:qybglogicsvrsz:qybglogicsvrsz3a-3
Precedence: bulk

Hi Willy,

> Hi Zhangjin,
> 
> On Fri, May 19, 2023 at 01:00:18AM +0800, Zhangjin Wu wrote:
> ...
>
> > * To let it compile for rv32, we still need to apply one of such actions:
> >     * Revert the kernel commit d4c08b9776b3 ("riscv: Use latest system call ABI"),
> >       but it is not the right direction, that commit has removed all of the time32 syscalls,
> >       and let C lib (e.g. glibc) provide the same C APIs based on the other time64 syscalls
> > 
> >     * If not really use any of the time32 syscalls, defining __ARCH_WANT_TIME32_SYSCALLS
> >       macro will let it compile, but this is buggy for the current implmentations are based
> >       on time32 syscalls!
> > 
> >     * Really implement the C APIs for rv32, based on the time64 syscalls, just like glibc.
> >       This commit c8ce48f06503 ("asm-generic: Make time32 syscall numbers optional") shows
> >       us which functions should be re-implemented.
> > 
> > So, the work todo for rv32 is:
> > 
> > * Rebasing all of the old time32 syscalls based C APIs on the new time64 syscalls,
> >   but they are not simply mapped one by one, glibc is a good reference.
> > 
> > * Add standalone rv32 test support in tools/testing/selftests/nolibc/
> 
> I'm not the right one to judge how to best support rv32 but at least I just
> don't want to go backwards. I'm just having a probably stupid question, but
> how relevant is rv32 ? I mean, all the boards I've seen to date were based
> on rv64 even the smallest embedded ones, so I'm sincerely wondering if there
> exists at all any rv32 devices capable of running Linux. Because if that's
> not the case, maybe we should instead declare that we only support rv64 ?
> If such devices exist however, I'm all for us supporting them well.
>

Firstly, as the commit c8ce48f06503 ("asm-generic: Make time32 syscall
numbers optional") shows:

    We don't want new architectures to even provide the old 32-bit time_t
    based system calls any more, or define the syscall number macros.

So, this is not rv32 specific, more and more architectures are trying to
use the generic unistd.h (include/uapi/asm-generic/unistd.h), but rv32
may be the first new architecture variant who have no time32 syscalls.

Second, I did search some rv32 socs/boards from two companies, they are
bl602/bl616/bl702, esp32-c2/c3/c6, some of them even have 532KB sRAM which is
enough for nolibc-based app + linux kernel, I have gotten 334K rv64 vmlinuz
(+nolibc hello.c) in the tinylinux work for riscv, the future work may be
running linux on such a real rv32 board ;-)

Best regards,
Zhangjin Wu

> Thanks,
> Willy