dogukan has quit [Remote host closed the connection]
Kedleston has quit [Ping timeout: 255 seconds]
zjason`` has joined #riscv
czy` has joined #riscv
uzix has joined #riscv
uzix has joined #riscv
uzix has quit [Changing host]
Bigcheese has joined #riscv
loki_val has joined #riscv
foxbat_ has joined #riscv
kgz has quit [Ping timeout: 264 seconds]
josuah has quit [Ping timeout: 264 seconds]
mahk has quit [Ping timeout: 264 seconds]
epony has quit [Ping timeout: 264 seconds]
zjason` has quit [Ping timeout: 264 seconds]
crabbedhaloablut has quit [Ping timeout: 264 seconds]
jfsimon has quit [Ping timeout: 264 seconds]
czy has quit [Ping timeout: 264 seconds]
foxbat has quit [Ping timeout: 264 seconds]
koolazer has quit [Ping timeout: 264 seconds]
Bigcheese_ has quit [Ping timeout: 264 seconds]
koolazer has joined #riscv
epony has joined #riscv
Kedleston has joined #riscv
kgz has joined #riscv
JanC_ has joined #riscv
JanC is now known as Guest8158
Guest8158 has quit [Killed (mercury.libera.chat (Nickname regained by services))]
JanC_ is now known as JanC
Tenkawa has quit [Quit: Was I really ever here?]
Kyuvi has quit [Quit: Client closed]
Kyuvi has joined #riscv
pakcjo has joined #riscv
<pakcjo>
Hi
<pakcjo>
I don't think this is the correct place to ask for help, but maybe someone could redirect me to it, I'm trying to get a working environment with qemu, but not sure where to start
maxinux has quit [Read error: Connection reset by peer]
<wbx>
pakcjo: use buildroot or openadk
<wbx>
pakcjo: do you want to emulate with or without MMU?
<pakcjo>
with, if possible
<wbx>
pakcjo: then both buid environments are okay for it to use.
<wbx>
s/buid/build/
<wbx>
pakcjo: what is your plan?
<pakcjo>
wbx: well, not sure, i'm rather new to all of this, got a book about asm programming for risc-v and I have been playing around with it. I know I can probably have a working linux environment inside qemu, but not sure what I need to get it running, probably a rootfs? bios and kernel?
<wbx>
rootfs and kernel should be enough, qemu delivers a bios
<another|>
sbi should come packaged with qemu indeed
kgz has quit [Ping timeout: 255 seconds]
BootLayer has quit [Read error: Connection reset by peer]
koolazer has quit [Ping timeout: 255 seconds]
TMM_ has quit [Ping timeout: 255 seconds]
koolazer has joined #riscv
TMM_ has joined #riscv
ldevulder has quit [Ping timeout: 255 seconds]
<pakcjo>
oh, ubuntu booted ;)
mlw has joined #riscv
<pakcjo>
and managed to boot the fedora image as well, without the loader and bios... Thanks, I think with this i could create a minimal rootfs for my needs
<sorear>
does anyone else think that adding device tree bindings for ISA extensions on an ad-hoc basis as they are used in linux (as opposed to when the corresponding extension is ratified, whether or not there is a current kernel user) is likely to make things needlessly difficult for firmware maintainers
davidlt has joined #riscv
davidlt has quit [Remote host closed the connection]
jedix has quit [Read error: Connection reset by peer]
jedix has joined #riscv
shamoe has quit [Quit: Connection closed for inactivity]
davidlt has joined #riscv
crossdev has joined #riscv
crossdev has quit [Remote host closed the connection]
crossdev has joined #riscv
Kyuvi has joined #riscv
<dh`>
if there are going to be device tree bindings for cpu properties, it seems like they should be specified along with the extensions in question
ezulian has joined #riscv
<jrtc27>
then linux folks will define their own thing in place of *that* because risc-v did something stupid
<jrtc27>
(half-/s)
<sorear>
meanwhile ACPI still believes that interoperable machine parsing of ISA strings is possible
<sorear>
can't wait to find out how many parsers are broken by them deciding to reinstate B as a single-letter extension
Kyuvi has quit [Ping timeout: 250 seconds]
JanC_ has joined #riscv
JanC is now known as Guest2759
Guest2759 has quit [Killed (molybdenum.libera.chat (Nickname regained by services))]
JanC_ is now known as JanC
ldevulder_ is now known as ldevulder
mlw has quit [Ping timeout: 268 seconds]
mlw has joined #riscv
jmdaemon has quit [Ping timeout: 256 seconds]
motherfsck has quit [Ping timeout: 252 seconds]
iooi_ has joined #riscv
iooi__ has joined #riscv
iooi has quit [Ping timeout: 264 seconds]
iooi__ is now known as iooi
Kyuvi has joined #riscv
iooi_ has quit [Ping timeout: 252 seconds]
heat has joined #riscv
MaxGanzII has joined #riscv
heat has quit [Remote host closed the connection]
heat has joined #riscv
prabhakar has quit [Quit: Connection closed]
prabhakar has joined #riscv
prabhakarlad has joined #riscv
KREYREN has quit [Remote host closed the connection]
KREYREN_ has joined #riscv
epony has joined #riscv
motherfsck has joined #riscv
motherfsck has quit [Ping timeout: 255 seconds]
motherfsck has joined #riscv
heat has quit [Remote host closed the connection]
heat has joined #riscv
motherfsck has quit [Ping timeout: 264 seconds]
motherfsck has joined #riscv
Andre_Z has joined #riscv
davidlt has quit [Ping timeout: 255 seconds]
motherfsck has quit [Ping timeout: 264 seconds]
prabhakarlad has quit [Quit: Client closed]
prabhakar has quit [Quit: Connection closed]
psydroid has joined #riscv
motherfsck has joined #riscv
prabhakar has joined #riscv
prabhakarlad has joined #riscv
<conchuod>
sorear: I don't think there's a problem with adding bindings for extensions as they are ratified.
<sorear>
i'm coming at this from a perspective of "device tree describes the hardware, so you shouldn't need to change it if the hardware is fixed"
<conchuod>
"specified along with the extensions" sounds like letting RVI define the bindings, in which case, refer to Jess' comment...
<conchuod>
sorear: it pretty much comes down to people being motivated to write the patches, and at present we only have the stick of requiring the binding for linux kernel support and no real carrot to encourage it on ratification.
naoki has quit [Quit: naoki]
<sorear>
i think they're pushing ASN.1 now
<conchuod>
sorear: wtf is that called again?
<sorear>
can you rephrase the question?
<conchuod>
What is that "feature" called again? (I wanna find the GitHub repo for it)
<conchuod>
That stuff predates me, I think Palmer told me it was rejected for linux and since then has been kinda dead. I did see it become active again recently
epony has quit [Read error: Connection reset by peer]
<sorear>
the repository that was current the last time I looked is archived now and I'm not sure of the continuity
<conchuod>
Yeah, I was looking in non-isa for it, thanks.
<conchuod>
This thing says that it expects bootloaders to use this to generate a DT
<sorear>
what possible purpose could signing the configuration structure in isolation (not as part of a larger attestation/quote system) serve?
<conchuod>
I don't really understand the point of this in DT land.
davidlt has joined #riscv
<conchuod>
If you're gonna read this and then create a DT from it, you need to be able to map RVI notation to DT notation for arbitrary properties in your bootloader.
<conchuod>
If I was a bootloader dev, I would be saying "just give me the DT in the first place"
<sorear>
please comment, you're in MAINTAINERS so your word is worth a lot more than mine
<conchuod>
Comment where, on the RVI lists?
<sorear>
yes, or the github issue tracker
<sorear>
tech-config
<conchuod>
Apparently there's a u-boot poc, but no code linked. I'll keep an eye on it..
<conchuod>
Seemingly it just makes a node that contains the asn.1 information and expects you to read /sys to get it in Linux.
<davidlt>
oh, this is "RISC-V Unified Discovery Task Group Repository"
<davidlt>
I almost forgot this was a thing
shamoe has joined #riscv
<davidlt>
Why U-Boot needs this? I thought this is for lower-end software bits.
<conchuod>
Something has to parse the structure and populate the DT.
<conchuod>
I would have expected something below u-boot to provide it to u-boot, but then I guess u-boot would then also have to be capable of patching it into a DT for the next stage also. For a PoC I think U-Boot is a good choice.
<conchuod>
sorear: I'd like to see this PoC before I comment on it, but I think the idea (or at least the level they're pitching it at) is pretty flawed. The PoC of just converting the ASN.1 table to DT nodes that subsequent boot stages or the OS don't even understand seems silly.
<conchuod>
We don't need yet another userspace interface for this stuff & it doesn't help the OS discover what it is running on.
<sorear>
preaching to the choir
czy` has quit [Quit: ERC 5.5.0.29.1 (IRC client for GNU Emacs 29.2.50)]
czy has joined #riscv
pakcjo has quit [Ping timeout: 268 seconds]
Andre_Z has quit [Quit: Leaving.]
epony has joined #riscv
Schnick has quit [Remote host closed the connection]
Schnick has joined #riscv
pakcjo has joined #riscv
prabhakarlad has quit [Ping timeout: 250 seconds]
prabhakar85 has joined #riscv
prabhakarlad has joined #riscv
prabhakar has quit [Ping timeout: 268 seconds]
Tenkawa has joined #riscv
prabhakarlad has quit [Ping timeout: 250 seconds]
prabhakar85 has quit [Ping timeout: 264 seconds]
shamoe has quit [Quit: Connection closed for inactivity]
KREYREN_ has quit [Remote host closed the connection]
KREYREN_ has joined #riscv
Tenkawa has quit [Quit: Was I really ever here?]
prabhakarlad has joined #riscv
<conchuod>
sorear: Another thought - this whole thing works using a CSR but there's no way of being sure that the CSR is actually mconfigptr.
<conchuod>
They might pick a CSR that has already been reserved for standard M mode use, but we know that people don't obey the rules and that later extensions come along and retroactively reserve CSR regions etc (AIA does this for some interrupts for example);
epony has quit [Remote host closed the connection]
<sorear>
mconfigptr is part of ss1p12, mandatory to implement but reads as zero until the config spec is done
<sorear>
it's a moot point though because you can't do anything in M-mode without compile time knowledge of the ISA
<conchuod>
What about something like platform-generic opensbi?
<sorear>
there's already a million #ifdefs in there
junaid_ has joined #riscv
epony has joined #riscv
prabhakar has joined #riscv
<sorear>
and nobody is going to want to run an ASN.1 parser prior to the S-mode start, at best the config blobs will be converted to another format at .... ... compile time
<conchuod>
I don't recall what csr does what, can you get the spec version first and then based on that know that mconfigptr exists?
<conchuod>
How about just canning it?
BootLayer has joined #riscv
<sorear>
canning what?
<sorear>
and do you mean "can" as in "cancel" or as in "precompile"
<conchuod>
the former
<sorear>
so you're now advocating for canceling the unified discovery TG?
<conchuod>
half in jest, yes
<conchuod>
😇 we can just use mconfigptr as a pointer to the dtb
<sorear>
opensbi assumes that priv spec csrs are either implemented as standard or cause illegal instructions, in particular menvcfg taken as evidence for Sm1p12
<sorear>
(which is fine for them, as long as they documented it somewhere)
epony has quit [Remote host closed the connection]
Leopold has quit [Remote host closed the connection]
Leopold has joined #riscv
<conchuod>
Okay, nice.
davidlt has quit [Ping timeout: 260 seconds]
ntwk has quit [Ping timeout: 252 seconds]
crossdev has quit [Remote host closed the connection]
<conchuod>
sorear: btw where does "Sm1p12" come from? Like what is the origin of that term? Is it mentioned in spec document or is it handy shorthand that contributors are using?
<sorear>
it should probably be added to 30.7/30.8 in the unpriv ISA where Sxxx extensions in general are defined
<sorear>
(Zxm*** doesn't seem to be used at all in any other spec, so...)
<conchuod>
Hmmge
<conchuod>
Thanks
<conchuod>
My next question is "is it valid to put sm1p12" in your isa string?
<conchuod>
meh, silly use of "s there
lagash has quit [Ping timeout: 268 seconds]
<sorear>
you could ask someone in a position to answer authoritatively.
<conchuod>
Rhetorical question really.
<conchuod>
I don't think anyone cares enough
<conchuod>
Or at least, anyone that is responsible for those documents cares enough.
josuah has joined #riscv
davidlt has joined #riscv
<sorear>
you're assuming that they're psychic, or that they follow IRC, which is almost the same thing
mlw has quit [Ping timeout: 268 seconds]
mlw has joined #riscv
junaid_ has quit [Remote host closed the connection]
<conchuod>
Eh, no.
<conchuod>
I'm basing it on the reaction of the powers at be when I raised my concerns about the isa strings to them.
<conchuod>
s/at/that/
<sorear>
when, where?
KombuchaKip has quit [Quit: Leaving.]
davidlt has quit [Ping timeout: 255 seconds]
<conchuod>
About a year ago, whenever I started complaining about riscv,isa on lkml.
<conchuod>
Where, I am not sure. I think it was off-list :/
KombuchaKip has joined #riscv
jedix has quit [Ping timeout: 255 seconds]
jedix has joined #riscv
<sorear>
you could raise an issue on riscv-isa-manual to document Sm*** and make sure Zxm*** is actually being used. or I could do it in 1d100 months
epony has quit [Remote host closed the connection]
davidlt has joined #riscv
epony has joined #riscv
Leopold has quit [Ping timeout: 264 seconds]
Leopold_ has joined #riscv
wingsorc has joined #riscv
wingsorc has quit [Client Quit]
heat has quit [Read error: Connection reset by peer]
heat has joined #riscv
vagrantc has joined #riscv
ldevulder has quit [Ping timeout: 268 seconds]
JanC has quit [Ping timeout: 260 seconds]
JanC has joined #riscv
ldevulder has joined #riscv
heat has quit [Remote host closed the connection]
heat has joined #riscv
forestfuturist has joined #riscv
BootLayer has quit [Quit: Leaving]
lagash has joined #riscv
Kyuvi has quit [Quit: Client closed]
epony has quit [Remote host closed the connection]
epony has joined #riscv
ntwk has joined #riscv
<forestfuturist>
you know, i was wondering
<forestfuturist>
on x86, you can boot whatever os you want because bios/uefi are pretty much always on there
mlw has quit [Ping timeout: 264 seconds]
<forestfuturist>
on arm, that is not really the case, and it can be hit-and-miss whether you'll be able to boot anything not directly provided by the manufacturer. most arm smartphones can't just run a linux distro for example.
<forestfuturist>
what's the situation like regarding that on riscv?
<courmisch>
it's not the case on embedded x86 AFAIK
<courmisch>
it'll be the same on RV as elsewhere: servers get UEFI, embedded gets custom mess
Kyuvi has joined #riscv
<forestfuturist>
like, what are the plans to prevent another arm-like mess to happen on riscv?
<sorear>
on x86 you can boot PC operating systems on clones of the IBM PC
<sorear>
they meaningfully broke backward compatibility at least twice, once with APM/ACPI (I've paged out most of the details) and again with EFI (although compatibility mode is still fairly common)
<forestfuturist>
i asked on reddit about it, and got some infos, but maybe someone here knows some more details?
shamoe has quit [Quit: Connection closed for inactivity]
<sorear>
there's preparation for a third significant break in "x86S" which removes 16-bit support
<forestfuturist>
someone mentioned the OS-A platform, is that a solution to this dilemma? and what role does u-boot play?
<sorear>
arm has the Server Baseline Boot Requirements (I think it might have been renamed/rescoped) which theoretically allows you to boot an EFI Arm64 OS image on any compatible machine
<forestfuturist>
like, can the OS-A platform and u-boot ensure there will largely not be fragmentation on boot freedom in riscv's case?
<sorear>
OS-A is basically riscv's SBBR. it'll provide compatibility if anyone actually bothers to use it
<forestfuturist>
what's sbbr?
<sorear>
one line up
<forestfuturist>
oh sorry
<conchuod>
I think, just like arm, you're gonna see a lot of fragmentation in some markets.
<forestfuturist>
i mean, i know some fragmentation is probably inevitable considering riscv lets you do whatever you want with it
<forestfuturist>
but
<conchuod>
idk, maybe fragmentation is not the right word, but incompatibility between what the vendor provides and what is eventually upstreamered setc.
<conchuod>
s/setc/etc/
<sorear>
ultimately riscv is designed to be a research platform, not a platform for wide binary compatibility
prabhakarlad has quit [Quit: Client closed]
<forestfuturist>
i have to admit, i'm a layperson and a lot of the terminology goes over my head, so i hope my questions are not too dumb
<sorear>
if you don't need cmpxchg16b or AVX x86_64 was subject to first sale 20 years ago a couple months ago :)
<sorear>
better to focus on comparative advantage rather than try to be all things to all people
<forestfuturist>
i tried to read all this stuff, but i seem to be missing the nuances sometimes
<forestfuturist>
if vendors implement OS-A, does that mean that any system implementing OS-A can be targeted by a single binary compiled for it, or could there be still fragmentation even on OS-A systems?
<forestfuturist>
and what exactly is u-boot? is it a replacement of uefi/bios or just an initial step before uefi/bios?
<davidlt>
It's a firmware, that also implements some (but not all) UEFI interfaces/services
<forestfuturist>
like, let's say smartphone vendors make their phones OS-A, does that mean i can install the exact same linux distory on a OS-A pc and an OS-A smartphone?
<forestfuturist>
*linux distro
<davidlt>
Is OS-A still a thing?
<conchuod>
They should really start archiving or w/e the dead specs on github. It can get pretty confusing as to what is still in development.
<sorear>
UEFI is a _boot interface_, not a boot stage in its own right
<davidlt>
I think we have now: Boot and Runtime Services (BRS), Server SoC, RISC-V Server Platform
<sorear>
we might still have OS-A-SEE unless that was folded into CoVE in its entirety
<davidlt>
riscv-platform is: This repository has been archived by the owner on Nov 1, 2023. It is now read-only.
<conchuod>
Oh nce
<forestfuturist>
so os-a is not current anymore?
<sorear>
if you have an OS-A/SBBR compliant smartphone, you can install OS-A/SBBR distros on it, this is unlikely to exist though
<forestfuturist>
i guess my question is: what spec currently takes the role of uefi/bios in riscv, especially for pc and smartphone chips?
<sorear>
UEFI.
<forestfuturist>
wait there is uefi on riscv?
<sorear>
yes
<sorear>
it was originally developed for Itanium and ported to a few other architectures
<davidlt>
Yes, there is ACPI, UEFI, SMBIOS, etc.
<davidlt>
It boots and talks the same way as x86_64 and aarch64
<davidlt>
Instead of x86_64-v2/v3/v4 variants, we have RISC-V Profiles
<davidlt>
Like RVA20/22/23
<davidlt>
There is also "RVB" (not ratified) and we also have (had?) RVB for smaller micro-controller stuff IIRC.
<sorear>
RVB is an ISA profile, it doesn't address booting or non-ISA hardware at all
<davidlt>
Yes, that's way we have BRS spec
<forestfuturist>
so what spec replaced os-a?
<davidlt>
and Server SoC, and Server Plaform, and a few hours
<sorear>
I think OS-A is BRS
<sorear>
but if you're looking for questions to have single answers you're in the wrong field
___nick___ has joined #riscv
<davidlt>
The stuff shifted from one place to another, got split into more parts, thus I don't know where exactly the old "OS-A" stuff landed (or in how many places).
<sorear>
it might look like mathematics but layer 8 is actually a kind of politics
<davidlt>
The top level spec (at least for servers) is Server Platform
<davidlt>
That will reference all others
<sorear>
(and I'd describe RVB as extremely large microcontroller or small application cores - it omits important server features like the vector extension but includes a lot of other things like virtual memory that you don't normally see on microcontrollers)
jfsimon1981_b has quit [Remote host closed the connection]
<davidlt>
I think RVB (not RVM) was designed for those that want to run Linux, et.c but not implement expensive features like vectors.
<forestfuturist>
i know that vendors are free to implement whatever they want. what i care about is whether there already is a standard in place that vendors can rally around if they wish, or if that is still in the future
<forestfuturist>
especially for pc and smartphone chips
<sorear>
that's server-soc
___nick___ has quit [Client Quit]
<sorear>
which despite the name also applies to pcs and laptops
<forestfuturist>
and smartphones too?
<sorear>
you could use it for a smartphone, but google is almost certainly going to force their own standard on the world
<davidlt>
yeah, Google will have their own
<davidlt>
incl. their own ISA decisions
<davidlt>
Currently they are going with RVA22 + Vector + Vector Crypto IIRC, but not freezing ABI (somewhere). Non expert here.
<sorear>
there's UEFI and SBBR for arm64 but apple doesn't use them for their laptop/phone chips
___nick___ has joined #riscv
<forestfuturist>
hmmm
<davidlt>
Currently things are moving fast, multiple specs (ISA and non-ISA), things are yet to settle for a nice good baseline.
<davidlt>
Majority of specs are around server (which incl. anything PC-like) as those things are built on standards.
___nick___ has quit [Client Quit]
<forestfuturist>
so, what has to happen so linux will be useable on pretty much all riscv smartphones and pc's? what's the missing part to prevent another arm-phone situation where you can pretty much only boot the vendor's custom image and nothing else? is it a standard that needs to be implemented on the riscv side, or something that needs to be done on the linux side?
<sorear>
regulation
<jrtc27>
standards don't make vendors follow standards
<sorear>
there is no technical solution here
<jrtc27>
vendors follow standards because it's the easiest way to make their thing work
<davidlt>
Well, that's up to companies to make a standards and work on it through RVI
___nick___ has joined #riscv
<davidlt>
that's true
<jrtc27>
ie you need a standard that vendors are using and that addresses their needs
<forestfuturist>
are the standards already in place by riscv, or is there something major missing? besides the fact that vendors are free to ignore those standards i mean
<davidlt>
for smartphones and their OS/bootflow/etc? Nothing.
<davidlt>
There is Android and it boots, how it does it? I don't know.
<davidlt>
For the servers standards are work in progress, none of them are ratified yet.
<forestfuturist>
i mean, imagine i was a foss friendly vendor, is there a template/standard implemented by riscv that i could target for max compatibility? or is something like that planned for pc and mobile?
<forestfuturist>
or is at least anything in planning phase like that?
<davidlt>
For binaries?
<davidlt>
For the binaries you check Server Platform and Server SoC specs. That will tell which RVA profile is implemented, and what additional requirements are.
<forestfuturist>
imagine i was a foss-friendly vendor, i go "gee whiz, i want my phone to be able to run any linux distro you could run on a pc!" what specs/platforms would i target?
<davidlt>
Standards for phone don't exist, so you most likely end up running U-Boot, which implements UEFI.
epony has quit [Remote host closed the connection]
<davidlt>
It tells what ISA extensions are mandatory, optional, conflicting, etc.
<davidlt>
There are other non-ISA things too like Zic64b (cache block size)
<davidlt>
Then Server Platform Spec will require you to implement some of optional ones too.
<Tenkawa>
Question for you all.. Has anyone worled with the Milk-V Mars CM yet? Trying to determine if I got the right version before I get home and can put my good test equipment on it (It wont boot completely).. Its only saying the DRAM is a 4GB model however I bought the 8GB model... can anything in SPI/firmware/etc misidentify the DRAM at this point or do I need to try to identify the board part #?
<forestfuturist>
so concerning above scenario, would i have to target a platform or is targetting a profile enough?
<sorear>
Zic64b is ISA, it's needed to interpret Zicbom etc
<Tenkawa>
er worled/worled
<Tenkawa>
er worked
<sorear>
if you're building hardware, you use a platform
<davidlt>
Tenkawa, it could be that DTB is from 4GB of board.
<Tenkawa>
davidlt: I thought that might be the case
<Tenkawa>
Thanks for confirming that could be a potentia
<Tenkawa>
l
<Tenkawa>
I have a test image waiting at home
<davidlt>
Tenkawa, that was a common problem with VF2 some time ago, but the latest U-boot (upstream) should be able to patch DTS with proper memory capacity.
<Tenkawa>
Yeah I had to do that dts update on the VF2
<davidlt>
Well, actually this a new board thus the patching might not work.
<Tenkawa>
I can I should (if I can get kernel source) identify if the memory addresses look right though.. in theory
<forestfuturist>
what platform would i target for phones, and which one for pc? are they the same?
<Tenkawa>
davidlt: I'm going to start working on identifying mainline dts differences to get it working
<Tenkawa>
I am running it with a waveshare board that I also use for an ARM64 BPI CM so hopefully
<Tenkawa>
I can make some progress using the same base for both
<davidlt>
forestfuturist, today Google is going with RVA22 + Vector + Vector Crypto as a starting point.
<davidlt>
Servers are probably RVA23 or RVA24 (once ratified), not fully sure.
<davidlt>
Otherwise no vendor defined what is a smartphone platform for RISCV.
<davidlt>
RVA24 is most likely the next major ISA profile from RVI point of view.
<forestfuturist>
davidlt so this is essentially the platform (even though it's not formalized yet) google targets for smartphones?
<davidlt>
it's not really a full platform description, just ISA that Google picked to start work for Android.
<sorear>
" today Google is going with RVA22 + Vector + Vector Crypto as a starting point." that's a profile, not a platform
<sorear>
if you want a platform, use the server platform, it's close enough to what you need for a high end smartphone and it covers the google profile, unless there's a google platform
<sorear>
i will not help you research whether there is a google platform or not, it's good exercise
<forestfuturist>
following scenario: this "platform" or a platform resulting from it become the de-facto standard for smarphones, most vendors implement it. could a linux distro compile their distro to be compliant with that platform, and it would then automatically work on ALL smartphones using that platform, or is there another component that would need to be standardized? does such a platform include an universally valid bootflow for sai
<forestfuturist>
platform?
<sorear>
a platform includes the boot flow but not driver support
prabhakarlad has joined #riscv
<forestfuturist>
i guess the point i don't get from a technical standpoint is: what exactly (besides isa) causes almost all pc's to be able to run any linux distro, but on smartphones it's the opposite in that it's almost never compatible? what's the part that makes this so hard to do for smartphones?
<forestfuturist>
drivers?
<forestfuturist>
and can riscv solve this?
<sorear>
pc vendors don't use shovelware as part of their business model
<sorear>
this is the main difference, i think
<sorear>
if phones followed a platform, you could run stock android on them, and then they wouldn't have shovelware
pakcjo has quit [Ping timeout: 264 seconds]
<sorear>
see previous comments about regulation and lack of technological solutions to political/economic problems
<forestfuturist>
so specifically, does it fail at the level of drivers, firmware, bootloader? which part is currently unstandardized which would need to be (at least within one and the same platform) for this issue to not occur?
<forestfuturist>
again i'm sorry for the unsophisticated questions, i actually struggle with the terminology nuances
<sorear>
it fails at the level of politics
<forestfuturist>
and thanks for helping me out so far :)
<sorear>
even if they implement a standard platform, it'll have a secure boot-based lockout, because they have no business incentive to support third-party OSes
<Tenkawa>
sorear: everything after the platform level is going to be a dice roll at that point at "who supports what"
<Tenkawa>
It will fall to money and viability
<forestfuturist>
which parts lie outside the platform level is what i don't understand i guess. drivers? what about firmware?
<sorear>
firmware is part of the platform to the extent that it affects boot interfaces
<forestfuturist>
so essentially it fails at drivers. or is there something else besides that?
<forestfuturist>
like, if i throw a linux iso on an sd and try to boot that on an unsupported smartphone, what's the missing part it fails at? drivers?
<sorear>
I've already explained more than once why it won't work with mass-market hardware and what you should do if you're trying to build foss-friendly hardware. If my explanations were unclear, please ask for clarification instead of repeating irrelevant questions.
<sorear>
I think most of them just won't support boot from SD
<Tenkawa>
I came from the telecom industry and that industry has even more considerations why I would agree with sorear on that
<forestfuturist>
how am i supposed to ask for clarification besides specifying a previous question's aspect i didn't understand, you know, for further clarification. i thought that was self-evident.
davidlt has quit [Ping timeout: 255 seconds]
<sorear>
I meant to sleep three hours ago, nothing here is self-evident
<forestfuturist>
i see, understandeable then no hard feelings
<forestfuturist>
i just wonder if there's something riscv can proactively do to counteract an arm-like incompatibility situation from emerging. like, if there's something they could standardize that vendors at least could use if they wish to do so.
<forestfuturist>
like, what's the current gameplan by riscv to promote os freedom on their chips?
<sorear>
the relevant standards already exist or are at an appropriate stage of development for the maturity of the market. I don't believe there is anything that can be done in terms of standards development that would give _better_ compatibility than arm.
<sorear>
riscv's gameplan is "riscv and os freedom have nothing to do with each other and it's not our problem to solve"
___nick___ has quit [Ping timeout: 264 seconds]
mlw has joined #riscv
<forestfuturist>
so as a final recap: the closest to a standard we currently have is server platform or server soc for pc and smartphone, as well as google's profile for smarphones, correct?
<sorear>
i think so
<forestfuturist>
thanks for your patience ;)
<sorear>
ditto
<forestfuturist>
nah all good you were gracious with a noob like me, most wouldn't have had the patience, i appreciate it :D
<forestfuturist>
let's hope the future of riscv brings lots of good things!
ezulian has quit [Ping timeout: 255 seconds]
<Tenkawa>
forestfuturist: lets also encourage people be patient... For all who were around like those of us who were... ARM took quite a few years even to get well adopted and it had massive backing.
<Tenkawa>
Fortunately we'll be able to use a lot of what we have learned in ARM
<forestfuturist>
good point
<forestfuturist>
Is BRS part of Server Platform and Server SoC for the boot-related stuff, or does it have nothing to do with them and is just for small microcontrollers?
<jrtc27>
Tenkawa: using what we learned in ARM, lol good one
<jrtc27>
RISC-V is slowly rediscovering things people learnt in the Arm world years ago
<forestfuturist>
jrtc27 yeah but i'm confused on it's relation to the other platforms i mentioned: i don't get whether it's a standalone thing, or if it's just part of the boot process for Server Platform and Server SoC and thus included.
<Tenkawa>
jrtc27: without RPI/ARM we would be years behind whrre we are now.. there is "no" way you can refute that
<jrtc27>
"The Boot and Runtime Services (BRS) specification defines a standardized set of software capabilities ..."
<jrtc27>
platforms are more than just software
<jrtc27>
ergo it's a subset of a platform for servers
<Tenkawa>
jrtc27: RISC-V wouldn't have even been a thought
<Tenkawa>
People learned and have a foundation for the concepts now because of that exprerience.
<forestfuturist>
yeah, but is brs as a platform included within Server Platform and Server SoC?
<Tenkawa>
er experience
<jrtc27>
sure, but how many years did it take to get cache maintenance, page table attributes, an interrupt controller that's not "my first PIC", the ability to set timer interrupts from supervisor mode without taking 1000s of cycles in firmware?
<jrtc27>
all things anyone working with serious computers can tell you are things you need
<jrtc27>
(well, other than possibly the option of doing coherent dma, but....)
<Tenkawa>
jrtc27: I said it took time... but without it... we would still be in the stone ages
<jrtc27>
but why did we have to re-learn all of that rather than just do it at the start?
<Tenkawa>
Because at that time corporations (like the ones I worked for) had no interest in anyone learning..
<Tenkawa>
I never said I liked the situation...
<Tenkawa>
I wish this would've happened about 20 years ago... then I would've been able to do a lot more
mlw has quit [Ping timeout: 264 seconds]
<Tenkawa>
jrtc27: hey unrelated but someone was curious... Is there any Lichee support in FreeBSD yet?
<jrtc27>
we have no t-head support at all
<Tenkawa>
Ok.. That's what I thought
<jrtc27>
patches are welcome, so long as the custom extension gunk doesn't overly intrude on things
<Tenkawa>
I will probably get one if I can ever find one at a decent rate here.
Kyuvi has quit [Quit: Client closed]
<conchuod>
smaeul: you ever gonna send that sifive maintainers patch I sent you a few months back to the list?