linux for riscv-32

[vithurson subasharan]

hi all,

I am currently developing a risc-v 32 bit processor for the FYP as FPGA implementation in which we can boot an OS. I need guidance regarding.

1. Is there any available linux version for RV32

2. Is RV32I with privileged instructions ,virtual memory etc. enough?

Thank you.

[Bruce Hoult]

As far as I know, any available pre-compiled linux for RISCV (e.g. http://riscv.mit.edu/debian/) is 64 bit, and also RV64IMA, because for processors powerful enough to run linux and with things such as MMUs the extra resources to be 64 bit instead of 32 bit are not a big overhead.

As far as libraries and apps, there shouldn't be any problem compiling your own for 32 bit, using any -march you want, including plain RV32I. I guess you'll need some other solution for atomics if you don't have the A extension. You'd probably need at least some simple atomic instruction such as CAS available -- although actually I think LR&SC from the A extension would be simpler to implement, even if you don't do the rest of A.

I don't know if anyone has done a 32 bit kernel yet. Probably not difficult to modify the RV64 one (easier than for a totally new architecture I mean). In this thread it was claimed that RV32 would be supported by the end of April: https://groups.google.com/a/groups.riscv.org/forum/#!topic/sw-dev/ssvYM8RFesk

--
You received this message because you are subscribed to the Google Groups "RISC-V SW Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sw-dev+unsubscribe@groups.riscv.org.
To post to this group, send email to sw-...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/sw-dev/.
To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/b36e1bb3-6512-46c6-8663-81bf60fb67f7%40groups.riscv.org.

[vithurson subasharan]

Thanks , I will look into this.. :)

[Bruce Hoult]

Of course if you only have a single processor you don't actually need any atomic instructions at all: you can simply temporarily disable interrupts. 

On Fri, Aug 11, 2017 at 3:23 PM, Bruce Hoult <br...@hoult.org> wrote:

As far as I know, any available pre-compiled linux for RISCV (e.g. http://riscv.mit.edu/debian/) is 64 bit, and also RV64IMA, because for processors powerful enough to run linux and with things such as MMUs the extra resources to be 64 bit instead of 32 bit are not a big overhead.

As far as libraries and apps, there shouldn't be any problem compiling your own for 32 bit, using any -march you want, including plain RV32I. I guess you'll need some other solution for atomics if you don't have the A extension. You'd probably need at least some simple atomic instruction such as CAS available -- although actually I think LR&SC from the A extension would be simpler to implement, even if you don't do the rest of A.

I don't know if anyone has done a 32 bit kernel yet. Probably not difficult to modify the RV64 one (easier than for a totally new architecture I mean). In this thread it was claimed that RV32 would be supported by the end of April: https://groups.google.com/a/groups.riscv.org/forum/#!topic/sw-dev/ssvYM8RFesk

On Fri, Aug 11, 2017 at 9:18 AM, vithurson subasharan <vith...@gmail.com> wrote:

hi all,

I am currently developing a risc-v 32 bit processor for the FYP as FPGA implementation in which we can boot an OS. I need guidance regarding.

1. Is there any available linux version for RV32

2. Is RV32I with privileged instructions ,virtual memory etc. enough?

Thank you.

--
You received this message because you are subscribed to the Google Groups "RISC-V SW Dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to sw-dev+un...@groups.riscv.org.

[Fabrice Bellard]

Hi,

You can get a working RISC-V 32 bit Linux kernel and busybox in the disk
image provided at https://bellard.org/riscvemu . You can also use a
complete 32 bit RISC-V system with X Window at https://bellard.org/jslinux .

Best regards,

Fabrice.

> --
> You received this message because you are subscribed to the Google
> Groups "RISC-V SW Dev" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to sw-dev+un...@groups.riscv.org

> <mailto:sw-dev+un...@groups.riscv.org>.

> To post to this group, send email to sw-...@groups.riscv.org

> <mailto:sw-...@groups.riscv.org>.

> Visit this group at
> https://groups.google.com/a/groups.riscv.org/group/sw-dev/.
> To view this discussion on the web visit
> https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/b36e1bb3-6512-46c6-8663-81bf60fb67f7%40groups.riscv.org

> <https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/b36e1bb3-6512-46c6-8663-81bf60fb67f7%40groups.riscv.org?utm_medium=email&utm_source=footer>.

[Bruce Hoult]

Cool! Seems like a lot of progress there since last time I looked.

I note that the busybox versions are compiled with the C extension, and the gcc defaults to that. I like this, but the original requester may not...

Also, the Fedora version is NOT using the C extension, and the gcc does not generate it by default (you can force with -march=RV64IMAC).

I was actually looking for another thread (on comp.arch) for the size of bash, grep and gzip binaries compiled for RV64GC to compare against a number of other architectures. I briefly thought your Fedora image might help with that. But no luck :(

 

On Fri, Aug 11, 2017 at 6:47 PM, Fabrice Bellard <fab...@bellard.org> wrote:

Hi,

You can get a working RISC-V 32 bit Linux kernel and busybox in the disk image provided at https://bellard.org/riscvemu . You can also use a complete 32 bit RISC-V system with X Window at https://bellard.org/jslinux .

Best regards,

Fabrice.

On 08/11/2017 08:18 AM, vithurson subasharan wrote:

hi all,
I am currently developing a risc-v 32 bit processor for the FYP as FPGA
implementation in which we can boot an OS. I need guidance regarding.
1. Is there any available linux version for RV32
2. Is RV32I with privileged instructions ,virtual memory etc. enough?
Thank you.

--
You received this message because you are subscribed to the Google
Groups "RISC-V SW Dev" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to sw-dev+un...@groups.riscv.org

<mailto:sw-dev+unsubscribe@groups.riscv.org>.

To post to this group, send email to sw-...@groups.riscv.org
<mailto:sw-...@groups.riscv.org>.
Visit this group at
https://groups.google.com/a/groups.riscv.org/group/sw-dev/.
To view this discussion on the web visit
https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/b36e1bb3-6512-46c6-8663-81bf60fb67f7%40groups.riscv.org
<https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/b36e1bb3-6512-46c6-8663-81bf60fb67f7%40groups.riscv.org?utm_medium=email&utm_source=footer>.

--
You received this message because you are subscribed to the Google Groups "RISC-V SW Dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to sw-dev+un...@groups.riscv.org.
To post to this group, send email to sw-...@groups.riscv.org.

Visit this group at https://groups.google.com/a/groups.riscv.org/group/sw-dev/.

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/598DD17B.4080302%40bellard.org.

[Fabrice Bellard]

The buildroot riscv32 and riscv64 distributions are compiled with the C
extension, so you can look at the size of the various binaries.

Best regards,

Fabrice.

> <mailto:sw-dev%2Bunsu...@groups.riscv.org>
> <mailto:sw-dev+un...@groups.riscv.org
> <mailto:sw-dev%2Bunsu...@groups.riscv.org>>.

> To post to this group, send email to sw-...@groups.riscv.org
> <mailto:sw-...@groups.riscv.org>

> <mailto:sw-...@groups.riscv.org <mailto:sw-...@groups.riscv.org>>.

> Visit this group at
> https://groups.google.com/a/groups.riscv.org/group/sw-dev/

> <https://groups.google.com/a/groups.riscv.org/group/sw-dev/>.

> To view this discussion on the web visit
> https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/b36e1bb3-6512-46c6-8663-81bf60fb67f7%40groups.riscv.org
> <https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/b36e1bb3-6512-46c6-8663-81bf60fb67f7%40groups.riscv.org>

> <https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/b36e1bb3-6512-46c6-8663-81bf60fb67f7%40groups.riscv.org?utm_medium=email&utm_source=footer

> <https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/b36e1bb3-6512-46c6-8663-81bf60fb67f7%40groups.riscv.org?utm_medium=email&utm_source=footer>>.
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "RISC-V SW Dev" group.
> To unsubscribe from this group and stop receiving emails from it,
> send an email to sw-dev+un...@groups.riscv.org

> <mailto:sw-dev%2Bunsu...@groups.riscv.org>.

> To post to this group, send email to sw-...@groups.riscv.org
> <mailto:sw-...@groups.riscv.org>.
> Visit this group at
> https://groups.google.com/a/groups.riscv.org/group/sw-dev/

> <https://groups.google.com/a/groups.riscv.org/group/sw-dev/>.

> To view this discussion on the web visit

> https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/598DD17B.4080302%40bellard.org
> <https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/598DD17B.4080302%40bellard.org>.

>
>
> --
> You received this message because you are subscribed to the Google
> Groups "RISC-V SW Dev" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to sw-dev+un...@groups.riscv.org

> <mailto:sw-dev+un...@groups.riscv.org>.

> To post to this group, send email to sw-...@groups.riscv.org
> <mailto:sw-...@groups.riscv.org>.
> Visit this group at
> https://groups.google.com/a/groups.riscv.org/group/sw-dev/.
> To view this discussion on the web visit

> https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/CAMU%2BEkxqVfdBT-S1zvkdRvFJ0US2ELG-tcV4PeNdfaUynRdMMQ%40mail.gmail.com
> <https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/CAMU%2BEkxqVfdBT-S1zvkdRvFJ0US2ELG-tcV4PeNdfaUynRdMMQ%40mail.gmail.com?utm_medium=email&utm_source=footer>.

[Bruce Hoult]

But in those, all the binaries are links to busybox.

        <mailto:sw-dev%2Bunsubscribe@groups.riscv.org>
        <mailto:sw-dev+unsubscribe@groups.riscv.org
        <mailto:sw-dev%2Bunsubscribe@groups.riscv.org>>.

        To post to this group, send email to sw-...@groups.riscv.org
        <mailto:sw-...@groups.riscv.org>
        <mailto:sw-...@groups.riscv.org <mailto:sw-...@groups.riscv.org>>.
        Visit this group at
        https://groups.google.com/a/groups.riscv.org/group/sw-dev/
        <https://groups.google.com/a/groups.riscv.org/group/sw-dev/>.
        To view this discussion on the web visit
        https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/b36e1bb3-6512-46c6-8663-81bf60fb67f7%40groups.riscv.org
        <https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/b36e1bb3-6512-46c6-8663-81bf60fb67f7%40groups.riscv.org>
        <https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/b36e1bb3-6512-46c6-8663-81bf60fb67f7%40groups.riscv.org?utm_medium=email&utm_source=footer
        <https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/b36e1bb3-6512-46c6-8663-81bf60fb67f7%40groups.riscv.org?utm_medium=email&utm_source=footer>>.


    --
    You received this message because you are subscribed to the Google
    Groups "RISC-V SW Dev" group.
    To unsubscribe from this group and stop receiving emails from it,
    send an email to sw-dev+un...@groups.riscv.org

    <mailto:sw-dev%2Bunsubscribe@groups.riscv.org>.

    To post to this group, send email to sw-...@groups.riscv.org
    <mailto:sw-...@groups.riscv.org>.
    Visit this group at
    https://groups.google.com/a/groups.riscv.org/group/sw-dev/
    <https://groups.google.com/a/groups.riscv.org/group/sw-dev/>.
    To view this discussion on the web visit
    https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/598DD17B.4080302%40bellard.org
    <https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/598DD17B.4080302%40bellard.org>.


--
You received this message because you are subscribed to the Google
Groups "RISC-V SW Dev" group.
To unsubscribe from this group and stop receiving emails from it, send

an email to sw-dev+un...@groups.riscv.org
<mailto:sw-dev+unsubscribe@groups.riscv.org>.

To post to this group, send email to sw-...@groups.riscv.org
<mailto:sw-...@groups.riscv.org>.
Visit this group at
https://groups.google.com/a/groups.riscv.org/group/sw-dev/.
To view this discussion on the web visit

https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/CAMU%2BEkxqVfdBT-S1zvkdRvFJ0US2ELG-tcV4PeNdfaUynRdMMQ%40mail.gmail.com
<https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/CAMU%2BEkxqVfdBT-S1zvkdRvFJ0US2ELG-tcV4PeNdfaUynRdMMQ%40mail.gmail.com?utm_medium=email&utm_source=footer>.

--
You received this message because you are subscribed to the Google Groups "RISC-V SW Dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to sw-dev+un...@groups.riscv.org.
To post to this group, send email to sw-...@groups.riscv.org.

Visit this group at https://groups.google.com/a/groups.riscv.org/group/sw-dev/.

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/598DE437.8060506%40bellard.org.

[Anton Krug]

Hi Bruce,

 

> As far as libraries and apps, there shouldn't be any problem compiling your own for 32 bit

 

How you would proceed in the case of gdbserver, I looked at the riscv Debian repository and it does have binutils, but not the gdbserver package. Would that be just as any other platform, getting source, configure (find dependencies and compile them as well) and then make  && make install? But looks like the build-essentials, gcc and other packages are missing in the repository.

 

Regards,

Anton

 

From: bruce...@gmail.com [mailto:bruce...@gmail.com] On Behalf Of Bruce Hoult
Sent: Friday, August 11, 2017 1:24 PM
To: vithurson subasharan <vith...@gmail.com>
Cc: RISC-V SW Dev <sw-...@groups.riscv.org>
Subject: Re: [sw-dev] linux for riscv-32

 

EXTERNAL EMAIL

As far as I know, any available pre-compiled linux for RISCV (e.g. http://riscv.mit.edu/debian/) is 64 bit, and also RV64IMA, because for processors powerful enough to run linux and with things such as MMUs the extra resources to be 64 bit instead of 32 bit are not a big overhead.

 

As far as libraries and apps, there shouldn't be any problem compiling your own for 32 bit, using any -march you want, including plain RV32I. I guess you'll need some other solution for atomics if you don't have the A extension. You'd probably need at least some simple atomic instruction such as CAS available -- although actually I think LR&SC from the A extension would be simpler to implement, even if you don't do the rest of A.

 

I don't know if anyone has done a 32 bit kernel yet. Probably not difficult to modify the RV64 one (easier than for a totally new architecture I mean). In this thread it was claimed that RV32 would be supported by the end of April: https://groups.google.com/a/groups.riscv.org/forum/#!topic/sw-dev/ssvYM8RFesk

 

 

On Fri, Aug 11, 2017 at 9:18 AM, vithurson subasharan <vith...@gmail.com> wrote:

hi all,

I am currently developing a risc-v 32 bit processor for the FYP as FPGA implementation in which we can boot an OS. I need guidance regarding.

1. Is there any available linux version for RV32

2. Is RV32I with privileged instructions ,virtual memory etc. enough?

Thank you.

--

You received this message because you are subscribed to the Google Groups "RISC-V SW Dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to sw-dev+un...@groups.riscv.org.

To post to this group, send email to sw-...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/sw-dev/.
To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/b36e1bb3-6512-46c6-8663-81bf60fb67f7%40groups.riscv.org.

 

--

You received this message because you are subscribed to the Google Groups "RISC-V SW Dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to sw-dev+un...@groups.riscv.org.

To post to this group, send email to sw-...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/sw-dev/.

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/CAMU%2BEkz08%2BknjokdRKocqLV-D82vh-rORRL4TTieNVNQZhzdzg%40mail.gmail.com.

[Bruce Hoult]

I don't know.

Some packages might not have been ported yet, others may not have been upstreamed. gdbserver sounds a little bit low level machine-dependent :-)

A quick google found: https://github.com/embecosm/riscv-gdbserver

On Fri, Aug 11, 2017 at 8:23 PM, Anton Krug <anton...@microsemi.com> wrote:

Hi Bruce,

 

> As far as libraries and apps, there shouldn't be any problem compiling your own for 32 bit

 

How you would proceed in the case of gdbserver, I looked at the riscv Debian repository and it does have binutils, but not the gdbserver package. Would that be just as any other platform, getting source, configure (find dependencies and compile them as well) and then make  && make install? But looks like the build-essentials, gcc and other packages are missing in the repository.

 

Regards,

Anton

 

From: bruce...@gmail.com [mailto:bruce...@gmail.com] On Behalf Of Bruce Hoult
Sent: Friday, August 11, 2017 1:24 PM
To: vithurson subasharan <vith...@gmail.com>
Cc: RISC-V SW Dev <sw-...@groups.riscv.org>
Subject: Re: [sw-dev] linux for riscv-32

 

EXTERNAL EMAIL

As far as I know, any available pre-compiled linux for RISCV (e.g. http://riscv.mit.edu/debian/) is 64 bit, and also RV64IMA, because for processors powerful enough to run linux and with things such as MMUs the extra resources to be 64 bit instead of 32 bit are not a big overhead.

 

As far as libraries and apps, there shouldn't be any problem compiling your own for 32 bit, using any -march you want, including plain RV32I. I guess you'll need some other solution for atomics if you don't have the A extension. You'd probably need at least some simple atomic instruction such as CAS available -- although actually I think LR&SC from the A extension would be simpler to implement, even if you don't do the rest of A.

 

I don't know if anyone has done a 32 bit kernel yet. Probably not difficult to modify the RV64 one (easier than for a totally new architecture I mean). In this thread it was claimed that RV32 would be supported by the end of April: https://groups.google.com/a/groups.riscv.org/forum/#!topic/sw-dev/ssvYM8RFesk

 

 

On Fri, Aug 11, 2017 at 9:18 AM, vithurson subasharan <vith...@gmail.com> wrote:

hi all,

I am currently developing a risc-v 32 bit processor for the FYP as FPGA implementation in which we can boot an OS. I need guidance regarding.

1. Is there any available linux version for RV32

2. Is RV32I with privileged instructions ,virtual memory etc. enough?

Thank you.

--

You received this message because you are subscribed to the Google Groups "RISC-V SW Dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to sw-dev+unsubscribe@groups.riscv.org.

To post to this group, send email to sw-...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/sw-dev/.
To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/b36e1bb3-6512-46c6-8663-81bf60fb67f7%40groups.riscv.org.

--
You received this message because you are subscribed to the Google Groups "RISC-V SW Dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to sw-dev+unsubscribe@groups.riscv.org.

To post to this group, send email to sw-...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/sw-dev/.

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/CAMU%2BEkz08%2BknjokdRKocqLV-D82vh-rORRL4TTieNVNQZhzdzg%40mail.gmail.com.

--

You received this message because you are subscribed to the Google Groups "RISC-V SW Dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to sw-dev+unsubscribe@groups.riscv.org.

To post to this group, send email to sw-...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/sw-dev/.

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/1DDB5E3A4442AF48B162E744C9B278BB19472FE5%40avsrvexchmbx1.microsemi.net.

[Bruce Hoult]

There's also a gdbserver directory inside the gdb directory here https://github.com/riscv/riscv-binutils-gdb

--

To unsubscribe from this group and stop receiving emails from it, send an email to sw-dev+un...@groups.riscv.org.

To post to this group, send email to sw-...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/sw-dev/.
To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/b36e1bb3-6512-46c6-8663-81bf60fb67f7%40groups.riscv.org.

--
You received this message because you are subscribed to the Google Groups "RISC-V SW Dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to sw-dev+un...@groups.riscv.org.

To post to this group, send email to sw-...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/sw-dev/.

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/CAMU%2BEkz08%2BknjokdRKocqLV-D82vh-rORRL4TTieNVNQZhzdzg%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "RISC-V SW Dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to sw-dev+un...@groups.riscv.org.

To post to this group, send email to sw-...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/sw-dev/.

[Richard W.M. Jones]

On Fri, Aug 11, 2017 at 07:11:11PM +0300, Bruce Hoult wrote:
> Cool! Seems like a lot of progress there since last time I looked.
>
> I note that the busybox versions are compiled with the C extension, and the
> gcc defaults to that. I like this, but the original requester may not...
>
> Also, the Fedora version is NOT using the C extension, and the gcc does not
> generate it by default (you can force with -march=RV64IMAC).

About Fedora, we're not planning any "official" 32 bit version, nor
even 32 bit libraries. When we re-bootstrap (after glibc+kernel
patches are upstream) we will enable the C extension. It was a
mistake in hindsight not to use it, but we weren't clear at that time
if C would be available in common 64 bit processors.

Rich.

--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines. Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v

[Anton Krug]

Hi Bruce,

 

That is dependant on the picoriscv32, even when I intend running the gdbserver with riscv64. I gave it a try and the instructions are not completed, so I opened issue there and we will see if it will compile something which will work.

--

To unsubscribe from this group and stop receiving emails from it, send an email to sw-dev+un...@groups.riscv.org.

To post to this group, send email to sw-...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/sw-dev/.
To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/b36e1bb3-6512-46c6-8663-81bf60fb67f7%40groups.riscv.org.

--
You received this message because you are subscribed to the Google Groups "RISC-V SW Dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to sw-dev+un...@groups.riscv.org.

To post to this group, send email to sw-...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/sw-dev/.

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/CAMU%2BEkz08%2BknjokdRKocqLV-D82vh-rORRL4TTieNVNQZhzdzg%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "RISC-V SW Dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to sw-dev+un...@groups.riscv.org.

[Anton Krug]

Hi Bruce,

 

I gave this riscv-binutils-gdb a try about 3 weeks ago and looks like the gdb is primary focus and the gdb-server part was forgotten for a moment. Looks like it’s broken at the moment, but if you have any insight please don’t hesitate to comment on the issue:

 

https://github.com/riscv/riscv-binutils-gdb/issues/96

 

 

Regards,

Anton

 

From: bruce...@gmail.com [mailto:bruce...@gmail.com] On Behalf Of Bruce Hoult

Sent: Friday, August 11, 2017 6:40 PM
To: Anton Krug <anton...@microsemi.com>

[knilaks...@gmail.com]

I have tried the TinyEMu32 bit version.I could generate the rootfs.

Is it enough to port the OS in zybo board?

I tried to boot from SD card,online source mention to copy Kernel files of the OS.

It used Linux kernel 4.6.2,but there is no riscv files boot files available in the /arch/    folder.

How can I further proceed in this?

[Sathya Narayanan N]

Dear experts,

Sorry for bugging in an old thread. is there a 32 bit version of linux for riscv ?

I saw one for 64 bit.

if not what would be the effort to get it one ?

regards,

Sathya

[Mark Corbin]

Hello Sathya

On 07/03/2019 07:02, Sathya Narayanan N wrote:

Dear experts,

Sorry for bugging in an old thread. is there a 32 bit version of linux for riscv ?

Buildroot [1] can build a 32-bit Linux system for RISC-V that boots under QEMU.

Regards

Mark

[1] https://buildroot.org/

I saw one for 64 bit.

if not what would be the effort to get it one ?

regards,

Sathya

On Friday, August 11, 2017 at 11:48:34 AM UTC+5:30, vithurson subasharan wrote:

hi all,

I am currently developing a risc-v 32 bit processor for the FYP as FPGA implementation in which we can boot an OS. I need guidance regarding.

1. Is there any available linux version for RV32

2. Is RV32I with privileged instructions ,virtual memory etc. enough?

Thank you.

--

You received this message because you are subscribed to the Google Groups "RISC-V SW Dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to sw-dev+un...@groups.riscv.org.
To post to this group, send email to sw-...@groups.riscv.org.

Visit this group at https://groups.google.com/a/groups.riscv.org/group/sw-dev/.

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/2c8e4268-a6f1-4434-a82e-236825296cda%40groups.riscv.org.

--
Mark Corbin
Embecosm Ltd.
https://www.embecosm.com

[Robert Henry]

I tried following Fabrice's instructions to build a 32-bit linux+busybox as found here https://bellard.org/tinyemu/buildroot.html

I am hosting on an ubuntu 18.04.2 x86_64 machine, kernel 4.15.0-47-generic

I download https://bellard.org/tinyemu/buildroot-riscv-2018-10-20.tar.gz and build. I eventually get a fatal compilation error:

/../misc/create_inode.c: At top level:

./../misc/create_inode.c:395:18: error: conflicting types for ‘copy_file_range’

 static errcode_t copy_file_range(ext2_filsys fs, int fd, ext2_file_t e2_file,

                  ^~~~~~~~~~~~~~~

In file included from ./../misc/create_inode.c:19:0:

/usr/include/unistd.h:1110:9: note: previous declaration of ‘copy_file_range’ was here

 ssize_t copy_file_range (int __infd, __off64_t *__pinoff,

         ^~~~~~~~~~~~~~~

Makefile:417: recipe for target 'create_inode.o' failed

Any ideas or help would be appreciated.

My end goal is to get a 32-bit linux produced rv32 core file so I can see what conventions it uses.

On Thursday, March 7, 2019 at 2:07:06 AM UTC-8, Mark Corbin wrote:

Hello Sathya

On 07/03/2019 07:02, Sathya Narayanan N wrote:

Dear experts,

Sorry for bugging in an old thread. is there a 32 bit version of linux for riscv ?

Buildroot [1] can build a 32-bit Linux system for RISC-V that boots under QEMU.

Regards

Mark

[1] https://buildroot.org/

I saw one for 64 bit.

if not what would be the effort to get it one ?

regards,

Sathya

On Friday, August 11, 2017 at 11:48:34 AM UTC+5:30, vithurson subasharan wrote:

hi all,

I am currently developing a risc-v 32 bit processor for the FYP as FPGA implementation in which we can boot an OS. I need guidance regarding.

1. Is there any available linux version for RV32

2. Is RV32I with privileged instructions ,virtual memory etc. enough?

Thank you.

--
You received this message because you are subscribed to the Google Groups "RISC-V SW Dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to sw-...@groups.riscv.org.

To post to this group, send email to sw-...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/sw-dev/.
To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/2c8e4268-a6f1-4434-a82e-236825296cda%40groups.riscv.org.

[Jim Wilson]

On Fri, Apr 19, 2019 at 9:09 AM Robert Henry <rrh....@gmail.com> wrote:
> /../misc/create_inode.c: At top level:
> ./../misc/create_inode.c:395:18: error: conflicting types for ‘copy_file_range’
> static errcode_t copy_file_range(ext2_filsys fs, int fd, ext2_file_t e2_file,
> ^~~~~~~~~~~~~~~
> In file included from ./../misc/create_inode.c:19:0:
> /usr/include/unistd.h:1110:9: note: previous declaration of ‘copy_file_range’ was here
> ssize_t copy_file_range (int __infd, __off64_t *__pinoff,
> ^~~~~~~~~~~~~~~
> Makefile:417: recipe for target 'create_inode.o' failed

The 32-bit glibc port is not upstream yet. Until that happens, any
attempt to build 32-bit linux is going to be a little tricky, and you
need to be willing to work around problems. Also keep in mind that
the 32-bit linux ABI isn't fixed yet, so any 32-bit work done now may
need to be updated later after the ABI is finalized.

That is a versioning problem between glibc and e2fsprogs. If you have
mismatched versions of them, then you get this build failure as both
have a definition of the copy_file_range function, and the definitions
are incompatible. I think if you upgrade from e2fsprogs-1.43 to
ef2fsprogs-1.44 the problem goes away as e2fsprogs renamed their
function to copy_file_chunk. Or alternatively, you can drop in a
patch for your e2fsprogs-1.43 version which is what I did when I ran
into this problem. Just drop the attached file into
buildroot/package/e2fsprogs and try rebuilding. But if the
instructions you are following are supposed to work, then you probably
didn't follow them correctly, or the instructions are specific enough
about what exact branches/commits that you are supposed to use to
reproduce. If that is the case, then you are probably just going to
hit more build failures from other versioning problems. You might
want to contact the author of the instructions you are following to
get better instructions.

I think the OpenEmbedded/Yocto port has some 32-bit support but I
haven't tried building that.

Jim

[Dennis Clarke]

On 4/19/19 12:38 PM, Jim Wilson wrote:
> On Fri, Apr 19, 2019 at 9:09 AM Robert Henry <rrh....@gmail.com> wrote:
>> /../misc/create_inode.c: At top level:
>> ./../misc/create_inode.c:395:18: error: conflicting types for ‘copy_file_range’
>> static errcode_t copy_file_range(ext2_filsys fs, int fd, ext2_file_t e2_file,
>> ^~~~~~~~~~~~~~~
>> In file included from ./../misc/create_inode.c:19:0:
>> /usr/include/unistd.h:1110:9: note: previous declaration of ‘copy_file_range’ was here
>> ssize_t copy_file_range (int __infd, __off64_t *__pinoff,
>> ^~~~~~~~~~~~~~~
>> Makefile:417: recipe for target 'create_inode.o' failed
>
> The 32-bit glibc port is not upstream yet. Until that happens, any

> attempt to build 32-bit linux is going to be a little tricky, ...


Are there clear docs anywhere on getting a Qemu/spike 64-bit rv64imafdc
going?

Dennis

[Jorg Brown]

> keep in mind that the 32-bit linux ABI isn't fixed yet, so any 32-bit work done now may

> need to be updated later after the ABI is finalized.

Just curious: given that other 32-bit RISC CPUs have long had stable Linux ABIs... what's the holdup with RISC-V?  That is, what technical detail is controversial?

--
You received this message because you are subscribed to the Google Groups "RISC-V SW Dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to sw-dev+un...@groups.riscv.org.

To post to this group, send email to sw-...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/sw-dev/.

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/CAFyWVaZiuMq23qCh_1%3Dsw1%3D4xKOMe3FDdDwCc%3DkbWU5pFds3Cw%40mail.gmail.com.

[Jim Wilson]

On Fri, Apr 19, 2019 at 10:44 AM Jorg Brown <jorg....@gmail.com> wrote:
> > keep in mind that the 32-bit linux ABI isn't fixed yet, so any 32-bit work done now may
> > need to be updated later after the ABI is finalized.
>
> Just curious: given that other 32-bit RISC CPUs have long had stable Linux ABIs... what's the holdup with RISC-V? That is, what technical detail is controversial?

There is the usual problem of finding volunteers to do the work.
SiFive doesn't have a 32-bit linux capable part, so we aren't trying
to push it through ourselves.

More specifically, there is the time_t problem. All current 32-bit
linux targets use a 32-bit time_t that will overflow in 2038. That
will need to be fixed soon, and when fixed, will cause an unfortunate
ABI break, for all current 32-bit linux targets. Since RISC-V is new,
we want to avoid the ABI break shortly after upstreaming our 32-bit
work, so we were waiting for the 64-bit time_t on 32-bit linux
infrastructure to be added to the linux kernel and glibc first. I
believe that work finished a month or two ago. So now we are back to
waiting for volunteers to be available to do the work. Zong Li of
Andes does have a patch set, and there is a version of it floating
around somewhere, but it needs to be updated to match current glibc
sources and tested and reviewed and all of that is a significant
amount of work. Hopefully Zong Li will find time to finish this. If
not, then someone else will have to finish it.

Jim

[Jim Wilson]

On Fri, Apr 19, 2019 at 9:51 AM Dennis Clarke <dcl...@blastwave.org> wrote:
> Are there clear docs anywhere on getting a Qemu/spike 64-bit rv64imafdc
> going?

Depends on exactly what you want. Are you an application developer
that wants to do native development on RISC-V? Are you an embedded
developer that wants to do cross development? Do you want a pre-built
linux? Do you want to build your own? Do you want to learn how to
build a linux distro from scratch? Are you a hardware developer
trying to get linux booting on your processor?

Spike has limited support for devices, and is primarily useful to
hardware developers. Software developers should use qemu.

If you want to do native development, then you should use qemu, and
you should also use a real distro (i.e. not freedom-u-sdk), such as
Fedora, Debian, OpenSuse, FreeBSD, etc. Fedora is what I use and has
good install docs.
https://fedoraproject.org/wiki/Architectures/RISC-V/Installing
You can find links to the others at
https://github.com/riscv/riscv-wiki/wiki/RISC-V-Software-Status#operating-systems

If you want cross embedded development, then you probably should look
at Yocto/OpenEmbedded or buildroot.

If you want to see how we (SiFive) builds our linux distro for our
HiFive Unleashed board, you can look at
github.com/sifive/freedom-u-sdk. This only supports qemu and the
Unleashed board at present. There is a v1_0 legacy branch that can
build an image that boots on spike.

Jim

[Robert Henry]

Thanks for all the replies and discussion.

I was able to follow Bellard's instructions https://bellard.org/tinyemu/buildroot.html and boot his build of 32-bit linux on his temu emulator.  The boot is very very fast.  I was then able to mount the 9p file system, copy in a rv32 binary, run it to generate a rv32 core dump, and capture the core dump back on my host machine, which was my end goal.

rv32 gdb can not read core dump files and find the note section with register contents.  After careful cross comparison of core dumps, I believe that the correct value for riscv-elfnn.c PRSTATUS_SIZE for 32-bit riscv here https://github.com/riscv/riscv-binutils-gdb/blob/82dcb8613e1b1fb2989deffde1d3c9729695ff9c/bfd/elfnn-riscv.c#L3532 should be 204, rather than 0(FIXME!).  All the other magic numbers in this region of riscv-elfnn.c appear to be correct.

[Jim Wilson]

On Fri, Apr 19, 2019 at 2:52 PM Robert Henry <rrh....@gmail.com> wrote:
> I was able to follow Bellard's instructions https://bellard.org/tinyemu/buildroot.html and boot his build of 32-bit linux on his temu emulator. The boot is very very fast. I was then able to mount the 9p file system, copy in a rv32 binary, run it to generate a rv32 core dump, and capture the core dump back on my host machine, which was my end goal.
>
> rv32 gdb can not read core dump files and find the note section with register contents. After careful cross comparison of core dumps, I believe that the correct value for riscv-elfnn.c PRSTATUS_SIZE for 32-bit riscv here https://github.com/riscv/riscv-binutils-gdb/blob/82dcb8613e1b1fb2989deffde1d3c9729695ff9c/bfd/elfnn-riscv.c#L3532 should be 204, rather than 0(FIXME!). All the other magic numbers in this region of riscv-elfnn.c appear to be correct.

Bellard's instructions refer to glibc-2.26 for 32-bit support, which
is an old obsolete copy of the 32-bit glibc port which is not ABI
compatible with the current 32-bit glibc port, and hence the number
204 that you got may be wrong. I think OpenEmbedded/Yocto is using
the current glibc-2.29 patches for 32-bit glibc support, along with
reasonably current linux kernel sources, and I'd be more inclined to
trust that number. But I don't have any better number for now, so I'm
willing to use that number for now, but keep in mind that everything
is subject to change until the 32-bit glibc support gets upstreamed.

Jim

[Dennis Clarke]

On 4/19/19 2:07 PM, Jim Wilson wrote:
> On Fri, Apr 19, 2019 at 9:51 AM Dennis Clarke <dcl...@blastwave.org> wrote:
>> Are there clear docs anywhere on getting a Qemu/spike 64-bit rv64imafdc
>> going?
>
> Depends on exactly what you want.

A baseline workable Linux with very few tools other than basic compiler
bits and a debugger. For learning and teaching. So Debian would be a
preferred distro here.

> Are you an application developer
> that wants to do native development on RISC-V?

Sure. Yes.

> Are you an embedded
> developer that wants to do cross development? Do you want a pre-built
> linux? Do you want to build your own? Do you want to learn how to
> build a linux distro from scratch? Are you a hardware developer
> trying to get linux booting on your processor?

Too many questions.

I just want to see a single RISC-V implementation that works in a
reasonably familiar way. Thus far I have not seen that. Anywhere.

>
> Spike has limited support for devices, and is primarily useful to
> hardware developers. Software developers should use qemu.

I thought qemu was using spike under the covers. Maybe it is.
Maybe not.

>
> If you want to do native development, then you should use qemu, and
> you should also use a real distro (i.e. not freedom-u-sdk), such as
> Fedora, Debian, OpenSuse, FreeBSD, etc. Fedora is what I use and has
> good install docs.
> https://fedoraproject.org/wiki/Architectures/RISC-V/Installing
> You can find links to the others at
> https://github.com/riscv/riscv-wiki/wiki/RISC-V-Software-Status#operating-systems
>

OKay, perhaps Fedora is a start but I am not a fan of anything that
comes from the Red Hat folks. Too many years wasted dealing with RHEL
and their support folks.

> If you want cross embedded development, then you probably should look
> at Yocto/OpenEmbedded or buildroot.
>
> If you want to see how we (SiFive) builds our linux distro for our
> HiFive Unleashed board, you can look at
> github.com/sifive/freedom-u-sdk. This only supports qemu and the
> Unleashed board at present. There is a v1_0 legacy branch that can
> build an image that boots on spike.
>

I think I should look at qemu here.

qemu-4.0.0-rc2 claims :

$ bin/qemu-system-riscv64 -machine help
Supported machines are:
none empty machine
sifive_e RISC-V Board compatible with SiFive E SDK
sifive_u RISC-V Board compatible with SiFive U SDK
spike_v1.10 RISC-V Spike Board (Privileged ISA v1.10) (default)
spike_v1.9.1 RISC-V Spike Board (Privileged ISA v1.9.1)
virt RISC-V VirtIO Board (Privileged ISA v1.10)
$

So there I see "Spike" twice and Sifive in there and something called a
VirtIO board. I have to guess that the SiFive stuff is portable to the
SiFive hardware, what there is of it. The rest of the options to qemu
are baffling. A ton of reading required I guess.

I'll take a look at the Fedora instructions. I have managed to boot a
FreeBSD rv64g type thing on qemu but there wasn't much workable in
there. Certainly no compiler.

So I will take a long look at Fedora merely because there isn't anything
else and nothing from the Debian folks. Yet. The FreeBSD folks have some
docs but none of that works if you follow their docs.

Entirely too much work just to get a workable baseline thing with a
compiler and a debugger just to look at "hello world".

Dennis

[Karsten Merker]

On Mon, Apr 22, 2019 at 01:19:30PM -0400, Dennis Clarke wrote:
> On 4/19/19 2:07 PM, Jim Wilson wrote:
> > On Fri, Apr 19, 2019 at 9:51 AM Dennis Clarke <dcl...@blastwave.org> wrote:
> > > Are there clear docs anywhere on getting a Qemu/spike 64-bit rv64imafdc
> > > going?
> >
> > Depends on exactly what you want.
>
> A baseline workable Linux with very few tools other than basic compiler
> bits and a debugger. For learning and teaching. So Debian would be a
> preferred distro here.

https://wiki.debian.org/RISC-V#Setting_up_a_riscv64_virtual_machine
describes the necessary steps in a "copy-and-paste-it" manner.
As a sidenote: I intend to rework the "kernel and BBL" section to
make use of OpenSBI and U-Boot plus the now-available pre-built
Debian kernel packages instead of BBL and a self-built kernel,
but that might take some weeks as Debian is in deep-freeze-mode
for the upcoming release right now and other things currently
have a higher priority. Nonetheless things work as they are
described in the wiki right now; moving from BBL to
OpenSBI+U-Boot just makes things nicer ;-).

> > Spike has limited support for devices, and is primarily useful to
> > hardware developers. Software developers should use qemu.
>
> I thought qemu was using spike under the covers. Maybe it is.
> Maybe not.

Spike and Qemu are two completely independent implementations.
Qemu is able to emulate a spike-compatible system, but there are
only rather narrow use-cases for that. For the purpose of
application development, you'll probably want to use Qemu's
"virt" machine type (examples are in the Debian wiki, see above).

> qemu-4.0.0-rc2 claims :
>
> $ bin/qemu-system-riscv64 -machine help
> Supported machines are:
> none empty machine
> sifive_e RISC-V Board compatible with SiFive E SDK
> sifive_u RISC-V Board compatible with SiFive U SDK
> spike_v1.10 RISC-V Spike Board (Privileged ISA v1.10) (default)
> spike_v1.9.1 RISC-V Spike Board (Privileged ISA v1.9.1)
> virt RISC-V VirtIO Board (Privileged ISA v1.10)
> $
>
> So there I see "Spike" twice and Sifive in there and something called a
> VirtIO board. I have to guess that the SiFive stuff is portable to the
> SiFive hardware, what there is of it. The rest of the options to qemu
> are baffling. A ton of reading required I guess.
>
> I'll take a look at the Fedora instructions. I have managed to boot a
> FreeBSD rv64g type thing on qemu but there wasn't much workable in
> there. Certainly no compiler.
>
> So I will take a long look at Fedora merely because there isn't anything
> else and nothing from the Debian folks. Yet.

Haven't you received my reply to your question on the debian-riscv
mailinglist (https://lists.debian.org/debian-riscv/2019/04/msg00006.html)?

Regards,
Karsten
--
Ich widerspreche hiermit ausdrücklich der Nutzung sowie der
Weitergabe meiner personenbezogenen Daten für Zwecke der Werbung
sowie der Markt- oder Meinungsforschung.

[Jim Wilson]

On Fri, Apr 19, 2019 at 2:52 PM Robert Henry <rrh....@gmail.com> wrote:

> rv32 gdb can not read core dump files and find the note section with register contents. After careful cross comparison of core dumps, I believe that the correct value for riscv-elfnn.c PRSTATUS_SIZE for 32-bit riscv here https://github.com/riscv/riscv-binutils-gdb/blob/82dcb8613e1b1fb2989deffde1d3c9729695ff9c/bfd/elfnn-riscv.c#L3532 should be 204, rather than 0(FIXME!). All the other magic numbers in this region of riscv-elfnn.c appear to be correct.

I reproduced your result using a 32-bit open embedded build, and
committed a patch to FSF Binutils to fix this.
https://sourceware.org/ml/binutils/2019-04/msg00219.html

Jim

[Dennis Clarke]

On 4/22/19 2:05 PM, Karsten Merker wrote:
> On Mon, Apr 22, 2019 at 01:19:30PM -0400, Dennis Clarke wrote:
>> On 4/19/19 2:07 PM, Jim Wilson wrote:
>>> On Fri, Apr 19, 2019 at 9:51 AM Dennis Clarke <dcl...@blastwave.org> wrote:
>>>> Are there clear docs anywhere on getting a Qemu/spike 64-bit rv64imafdc
>>>> going?
>>>
>>> Depends on exactly what you want.
>>
>> A baseline workable Linux with very few tools other than basic compiler
>> bits and a debugger. For learning and teaching. So Debian would be a
>> preferred distro here.
>
> https://wiki.debian.org/RISC-V#Setting_up_a_riscv64_virtual_machine

That fails fast and early :

root@nix:~#
root@nix:~# mmdebstrap --architectures=riscv64
--include="debian-ports-archive-keyring" sid /opt/riscv64-chroot "deb
http://deb.debian.org/debian-ports/ sid main" "deb
http://deb.debian.org/debian-ports/ unreleased main"
I: automatically chosen mode: root
I: riscv64 cannot be executed, falling back to qemu-user
I: running apt-get update...
done
I: downloading packages with apt...
done
I: extracting archives...
done
I: installing packages...
.
.
.

Says riscv64 cannot be executed.
Sort of looks like a dead on arrival process?

Dennis

[Dennis Clarke]

Yes .. this process is broken and does not work unless there is special
secret knowledge and magic :

root@nix:~#
root@nix:~# sh -c "cat >/etc/ld.so.conf.d/riscv64-linux-gnu.conf <<EOF
> /usr/local/lib/riscv64-linux-gnu
> /lib/riscv64-linux-gnu
> /usr/lib/riscv64-linux-gnu
> /usr/riscv64-linux-gnu/lib/
> EOF
> "
root@nix:~# ln -s /usr/riscv64-linux-gnu/lib/ld-linux-riscv64-lp64d.so.1
/lib
root@nix:~# vi /root/.sbuildrc
root@nix:~# cat /root/.sbuildrc
$crossbuild_core_depends = {
riscv64 => ['gcc-riscv64-linux-gnu:native',
'g++-riscv64-linux-gnu:native', 'dpkg-cross:native'],
};
root@nix:~#
root@nix:~#
root@nix:~# sbuild --build=amd64 --profiles=cross --host=riscv64
-bash: sbuild: command not found
root@nix:~#

Most likely it is best to wait until there exists actual installer image
for real hardware someday. Meanwhile FreeBSD "current" sort of works.

Dennis

[Arnd Bergmann]

Linux-5.1-rc contains my patch d4c08b9776b3 ("riscv: Use latest system
call ABI"), which changes the kernel to export only the 64-bit time_t
based system calls. All other 32-bit architectures support both
32-bit time_t and 64-bit time_t in the kernel now, and restoring the
"#define __ARCH_WANT_TIME32_SYSCALLS" line would make it
possible to run an existing user space again.

I also have an experimental musl port at
https://git.linaro.org/people/arnd.bergmann/musl-y2038.git/
that should work with this (only tested on x86). This will no
get upstreamed in this form, but if anyone is interested in
doing the proper port, I can help describe what needs to be
done for it.

For glibc, the tricky part is doing it in a way that doesn't clash with
the conversion of the other 32-bit architectures that are now adding
support for 64-bit time_t in addition to the 32-bit existing time_t
based interfaces. This is in the process of getting added now that
the system calls are there, but it can use help.

Arnd

[Dennis Clarke]

On 4/23/19 5:19 PM, Karsten Merker wrote:

> There is absolutely no failure or error visible in what you have

OKay. It certainly looked like an error. Hardly clear but then again
the capital "I" should mean Iowa or perhaps Iodine and most likely INFO
would have been more clear.

I know that I am really bashing my face into a brick wall on this.
Sometimes there is no other way forwards. Certainly with a very very
edge case circumstance like anything-RISC-V.


> What happens if you simply let mmdebstrap complete? Do you
> encounter any actual errors? If yes: which specifically?

I seemed to do "good stuff" but I was not clear if this was a error
situation or not. Would I simply plow forwards and then two days
from now find out that the foundation was crooked? So why bother.

root@nix:~#
root@nix:~# mmdebstrap --architectures=riscv64
--include="debian-ports-archive-keyring" sid /opt/riscv64-chroot "deb
http://deb.debian.org/debian-ports/ sid main" "deb
http://deb.debian.org/debian-ports/ unreleased main"
I: automatically chosen mode: root
I: riscv64 cannot be executed, falling back to qemu-user
I: running apt-get update...
done
I: downloading packages with apt...
done
I: extracting archives...
done
I: installing packages...

done
I: downloading apt...
done
I: installing apt...
done
I: installing remaining packages inside the chroot...
done
I: cleaning package lists and apt cache...
done
done
root@nix:~#

root@nix:~# file /opt/riscv64-chroot/bin/uname
/opt/riscv64-chroot/bin/uname: ELF 64-bit LSB pie executable, UCB
RISC-V, version 1 (SYSV), dynamically linked, interpreter
/lib/ld-linux-riscv64-lp64d.so.1, for GNU/Linux 4.15.0,
BuildID[sha1]=8f08bad4c395a81ac5729d513f1c0816cdbfc2c0, stripped
root@nix:~#


root@nix:~# readelf -delV /opt/riscv64-chroot/bin/uname
ELF Header:
Magic: 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00
Class: ELF64
Data: 2's complement, little endian
Version: 1 (current)
OS/ABI: UNIX - System V
ABI Version: 0
Type: DYN (Shared object file)
Machine: RISC-V
Version: 0x1
Entry point address: 0x1c4c
Start of program headers: 64 (bytes into file)
Start of section headers: 25624 (bytes into file)
Flags: 0x5, RVC, double-float ABI
Size of this header: 64 (bytes)
Size of program headers: 56 (bytes)
Number of program headers: 8
Size of section headers: 64 (bytes)
Number of section headers: 27
Section header string table index: 26

.
.
.

Dynamic section at offset 0x5e10 contains 27 entries:
Tag Type Name/Value
0x0000000000000001 (NEEDED) Shared library: [libc.so.6]
0x0000000000000001 (NEEDED) Shared library:
[ld-linux-riscv64-lp64d.so.1]
0x0000000000000020 (PREINIT_ARRAY) 0x6b80
0x0000000000000021 (PREINIT_ARRAYSZ) 0x8
.
.
.

Version needs section '.gnu.version_r' contains 2 entries:
Addr: 0x0000000000000be0 Offset: 0x000be0 Link: 6 (.dynstr)
000000: Version: 1 File: ld-linux-riscv64-lp64d.so.1 Cnt: 1
0x0010: Name: GLIBC_2.27 Flags: none Version: 3
0x0020: Version: 1 File: libc.so.6 Cnt: 1
0x0030: Name: GLIBC_2.27 Flags: none Version: 2
root@nix:~#


That actually looks good.

What I will do is build a new piece of hardware for this experiment and
then return with a new subject line. Something like "clean room build"
or similar. I am hoping to see a repeatable non-baffle-gab process.


Dennis

[Karsten Merker]

[Re-sent as the original message got dropped by the listserver]

There is absolutely no failure or error visible in what you have

quoted. To the contrary, what you have quoted shows that
mmdebstrap is working as intented and installs packages into the
chroot. It clearly says "I: riscv64 cannot be executed, falling
back to qemu-user". This is no error message, just an
information for the user - mmdebstrap checks whether code for the
target architecture (in this case riscv64) can be natively
executed on the host architecture (in this case amd64) and only
runs it in qemu-user if it cannot be executed natively, as using
qemu-user is slower than native execution. Obviously an amd64
CPU cannot natively execute riscv64 code, so mmdebstrap has to
use qemu-user in this case and tells you that with the
aforementioned message.

What happens if you simply let mmdebstrap complete? Do you
encounter any actual errors? If yes: which specifically?

Regards,
Karsten
--
Hiermit widerspreche ich ausdrücklich der Nutzung sowie der Weitergabe

[Karsten Merker]

[Re-sent as the original message got dropped by the listserver]

Please see my reply to your previous email in this thread - there
isn't any failure or error in what you have quoted; the line
"I: riscv64 cannot be executed, falling back to qemu-user" is purely
informational and _not_ an error.

> Yes .. this process is broken and does not work unless there is special
> secret knowledge and magic :
>
> root@nix:~#
> root@nix:~# sh -c "cat >/etc/ld.so.conf.d/riscv64-linux-gnu.conf <<EOF
> > /usr/local/lib/riscv64-linux-gnu
> > /lib/riscv64-linux-gnu
> > /usr/lib/riscv64-linux-gnu
> > /usr/riscv64-linux-gnu/lib/
> > EOF
> > "
> root@nix:~# ln -s /usr/riscv64-linux-gnu/lib/ld-linux-riscv64-lp64d.so.1
> /lib

Nothing from the mmdebstrap run that you have quoted further
above indicates any sort of brokenness in the process and there
is also no secret knowledge involved. The ld.so configuration
that you have quoted directly above (which, JFTR, is from
https://wiki.debian.org/RISC-V#Pre-built_toolchains) is only
necessary for a completely different use-case, namely using
Debian's multiarch features and a cross-toolchain to build,
install and transparently excute riscv64 packages side-by-side
with amd64 packages inside an amd64 root filesystem. This is
something that is e.g. used by Debian developers during
bootstrapping a new architecture.
A chroot such as the one created by mmdebstrap is a completely
separate entitiy from the host's root filesystem, so adding or
not adding the aforementioned ld.so config in the host rootfs
doesn't have any influence at all onto the chroot creation
process performed by mmdebstrap.

> root@nix:~# vi /root/.sbuildrc
> root@nix:~# cat /root/.sbuildrc
> $crossbuild_core_depends = {
> riscv64 => ['gcc-riscv64-linux-gnu:native', 'g++-riscv64-linux-gnu:native',
> 'dpkg-cross:native'],
> };
> root@nix:~#
> root@nix:~#
> root@nix:~# sbuild --build=amd64 --profiles=cross --host=riscv64
> -bash: sbuild: command not found
> root@nix:~#

This is again from a completely different context, i.e.
https://wiki.debian.org/RISC-V#Using_pre-built_toolchains_with_sbuild.
It describes how to configure sbuild (a tool used for building
Debian packages in a clean environment) to automatically pull in
cross-build dependencies when using it to cross-build Debian
packages for the riscv64 architecure on an amd64 host. This
again has absolutely nothing to do with setting up a riscv64
chroot/virtual machine.

If the description provided at

https://wiki.debian.org/RISC-V#Creating_a_riscv64_chroot

doesn't work for you for whatever reason, please provide a
complete log of the commands that have led to an error and the
exact error message so that it is possible to debug the issue.
To make sure that the description in the Debian wiki is correct,
I have just again run the steps described there by copying and
pasting them from the wiki to a Debian/sid amd64 system and they
have worked flawlessly for me.

[Dennis Clarke]

>> .
>>
>> Says riscv64 cannot be executed.
>> Sort of looks like a dead on arrival process?
>
> There is absolutely no failure or error visible in what you have
> quoted. To the contrary, what you have quoted shows that
> mmdebstrap is working as intented and installs packages into the
> chroot.

Hold on ... I don't want to pollute a working Debian Linux boxen here
and thus I am building a new fresh unit with which to hack at this.

I promise I shall return with a faster bigger and ssd based system with
Debian sid on it and then I would be happy to try this again step by
step by step to get a bootable rv64imafdc virtual machine. With a local
and native compiler and even gdb would be considered essential.


--
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
GreyBeard and suspenders optional