Diff between building from just poky vs poky + meta-rriscv?

[InspireSemi]

Building the toolchain + rootfs images I noticed that the latest poky release has support for qemuriscv64/32.

In building with that you get a toolchain: poky-glibc-x86_64-core-image-minimal-riscv64-qemuriscv64-.... Building with meat-risv as a layer you gete: poky-altcfg-glibc-x86_64-core-image-minimal-riscv64-qemuriscv64-...

I think the rest of the artifacts have the same names, core-image-minimal-qemuriscv64.rootfs... for example.

What is the difference between building with meta-riscv as a layer and building without it for riscv64/32?

[kraj]

meta-riscv serves few purposes. add support for features which are not moved to oe-core, eventually the common pieces move to core, e.g. until RISCV32 was not yet upstream in musl, we still supported it with patches applied to musl from meta-riscv. Eventually, it is now in musl upstream, so when poky gets the version of musl which has RV32 support, we drop it.

Secondly, it supports some RISCV64 SBCs and tries to ensure that common pieces still work e.g. openSBI, u-boot, kernel etc and upstream packages can be used for BSPs. It host any other package thats specific to RISCV e.g. bbl

It also has additional tunes which may not be supported by core

Common BSP policies that board makers can use to write their BSPs, so it acts as template for RISCV BSP layers

[InspireSemi]

Sounds like the meta-riscv is there as a catch-all for things that are not supported upstream (poky), examples bbl, RISCV SBCs. If / When an item is pushed upstream it gets dropped from meta-riscv.

Sounds like support is first implemented in meta-riscv layer and then moved over to poky (maybe) and dropped from meta-riscv.

Is it fair to say meta-riscv is a superset of poky for riscv64/32?

Marc Karasek Principal Software Engineer M: 678.770.3788

[A close up of a sign Description automatically generated] www.inspiresemi.comhttp://www.cryptocoretech.com/

THIS MESSAGE IS INTENDED ONLY FOR THE USE OF THE INDIVIDUAL OR ENTITY TO WHICH IT IS ADDRESSED AND MAY CONTAIN INFORMATION THAT IS PRIVILEGED, CONFIDENTIAL AND/OR EXEMPT FROM DISCLOSURE UNDER APPLICABLE LAW. If the reader of this message is not the intended recipient or agent responsible for delivering the message to the intended recipient, then you are hereby notified that any dissemination or copying of this communication is strictly prohibited. If you have received this electronic transmission in error, please delete it from your system without copying it and notify the sender by reply e-mail so that our address record can be corrected. Thank you.

From: Khem Raj @.> Sent: Thursday, August 15, 2024 7:11 PM To: riscv/meta-riscv @.> Cc: Marc Karasek @.>; Author @.> Subject: Re: [riscv/meta-riscv] Diff between building from just poky vs poky + meta-rriscv? (Issue #485)

This is the first time you received an email from this sender @.**@.>). Exercise caution when clicking links, opening attachments or taking further action, before validating its authenticity.

meta-riscv serves few purposes. add support for features which are not moved to oe-core, eventually the common pieces move to core, e.g. until RISCV32 was not yet upstream in musl, we still supported it with patches applied to musl from meta-riscv. Eventually, it is now in musl upstream, so when poky gets the version of musl which has RV32 support, we drop it.

Secondly, it supports some RISCV64 SBCs and tries to ensure that common pieces still work e.g. openSBI, u-boot, kernel etc and upstream packages can be used for BSPs. It host any other package thats specific to RISCV e.g. bbl

It also has additional tunes which may not be supported by core

Common BSP policies that board makers can use to write their BSPs, so it acts as template for RISCV BSP layers

— Reply to this email directly, view it on GitHubhttps://url.avanan.click/v2/___https:/github.com/riscv/meta-riscv/issues/485%23issuecomment-2292434319___.YXAzOmluc3BpcmVzZW1pOmE6bzo1NzI1YTA1M2ZhMGUwYjk3YjdjN2FlZjhjZWQ4ZDZiNzo2OjdkMzg6NTkzYWFjYTMxMDY5MjFkMmM2ZjU3MGRjYTJkNmYyMzdkNjQwMjdlN2FkNjcyYTRiMjY5ZWVkNzlmZTZmMjY2MzpoOlQ6Tg, or unsubscribehttps://url.avanan.click/v2/___https:/github.com/notifications/unsubscribe-auth/AR3S6YY3XERO6QHGJLARWHTZRUYRBAVCNFSM6AAAAABMS6RVKGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEOJSGQZTIMZRHE___.YXAzOmluc3BpcmVzZW1pOmE6bzo1NzI1YTA1M2ZhMGUwYjk3YjdjN2FlZjhjZWQ4ZDZiNzo2OmIwOGQ6NDFiNTc2YWQ4ODA2Njk2NzM1ZDRhODcxZGYzOTFjMjg3NDIzYmMxMDQ2MWFmY2U3ZGY0ZWFlN2VmZDFmM2Y3ZjpoOlQ6Tg. You are receiving this because you authored the thread.Message ID: @.**@.>>

[kraj]

@InspireSemi yes, one of the intention is to push things upstream as core tenet of RISCV ecosystem in general. However, this is a continuous process especially at this stage of RISCV development. Its not a superset but it complements poky's core support for wider RISCV implementations.