sorear changed the topic of #riscv to: RISC-V instruction set architecture | https://riscv.org | Logs: https://libera.irclog.whitequark.org/riscv
<palmer> I have a C910, but haven't poked around with it yet
<palmer> (also a C906, also haven't messed with that)
radu242359 has quit [Ping timeout: 260 seconds]
<muurkha> thanks! "not really clear if there's HW" seem to be the general situation unfortunately
<muurkha> probably not what you were hoping for six years ago
ivii has quit [Remote host closed the connection]
<palmer> ;)
<palmer> hopefully someone sorts that out, it's been far too long
<muurkha> now that the C906 is shipping in volume, hopefully someone will Agner Fog it a bit
<muurkha> (fogging: like fuzzing, but to measure performance rather than correctness?)
<palmer> seems reasonable -- setting that sort of thing up has been on my TODO list for a while now, hopefully someone else does it ;)
<muurkha> haha
<palmer> maybe if I ever stop working at HW companies...
radu2423598 has joined #riscv
<muurkha> if you had a six-month sabbatical what would you do with it?
<palmer> I have a hobby project
<palmer> sort of a VM thing
<muurkha> oh?
littlebobeep has joined #riscv
seninha has joined #riscv
littlebobeep has quit [Ping timeout: 240 seconds]
geranim0 has quit [Remote host closed the connection]
seninha has quit [Quit: Leaving]
littlebobeep has joined #riscv
joev has quit [Ping timeout: 276 seconds]
joev has joined #riscv
JanC has quit [Remote host closed the connection]
JanC has joined #riscv
littlebobeep has quit [Ping timeout: 240 seconds]
seninha has joined #riscv
BOKALDO has joined #riscv
jacklsw has joined #riscv
aerkiaga has quit [Remote host closed the connection]
kaph has joined #riscv
haise01 has joined #riscv
kaph has quit [Ping timeout: 248 seconds]
X-Scale` has joined #riscv
X-Scale has quit [Ping timeout: 246 seconds]
X-Scale` is now known as X-Scale
EchelonX has joined #riscv
jacklsw has quit [Read error: Connection reset by peer]
seninha has quit [Remote host closed the connection]
kaph has joined #riscv
kaph has quit [Read error: Connection reset by peer]
kaph has joined #riscv
haise01 has quit [Ping timeout: 256 seconds]
kaph has quit [Ping timeout: 260 seconds]
kaph has joined #riscv
kaph has quit [Read error: Connection reset by peer]
littlebobeep has joined #riscv
zjason`` has joined #riscv
zjason` has quit [Ping timeout: 248 seconds]
zjason has joined #riscv
zjason`` has quit [Ping timeout: 248 seconds]
littlebobeep has quit [Ping timeout: 240 seconds]
crabbedhaloablut has quit [Ping timeout: 240 seconds]
pabs3 has quit [Read error: Connection reset by peer]
pabs3 has joined #riscv
psydroid has quit [Quit: Bridge terminating on SIGTERM]
acharles has quit [Quit: Bridge terminating on SIGTERM]
llamp[m] has quit [Quit: Bridge terminating on SIGTERM]
khem has quit [Quit: Bridge terminating on SIGTERM]
haliucinas has quit [Ping timeout: 272 seconds]
psydroid has joined #riscv
bauruine has joined #riscv
crabbedhaloablut has joined #riscv
bauruine has quit [Client Quit]
bauruine has joined #riscv
littlebobeep has joined #riscv
khem has joined #riscv
llamp[m] has joined #riscv
acharles has joined #riscv
prabhakarlad has joined #riscv
<geertu> conchuod: I merged in your mpfs-reset branch, and it boots fine
<geertu> There seems to be a problem with i2c, though
<geertu> "i2cdetect -y -a $n" ($n = 0, 1, or 2) doesn't detect any devices
<geertu> With $n = 0, it's also very slow.
palmer has quit [K-Lined]
hexteex has joined #riscv
frkazoid333 has quit [Read error: Connection reset by peer]
frkazoid333 has joined #riscv
huseyinkozan has joined #riscv
conordooley has joined #riscv
BOKALDO has quit [Quit: Leaving]
<conordooley> geertu Thanks. I take it you have the corei2c driver enabled?
pecastro has joined #riscv
<conordooley> The driver is in my tree but I forgot to enable it in the config (d'oh). I hadn't enabled it in the kconfig changes since the driver has not been accepted. If I set that and i2c=y & i2c_chardev=y, i2cdetect works but finds nothing.
<conordooley> I bet I know what it is, it originally used writeL/readL but I changed it to the byte versions & ran my test app, which worked.
<conordooley> But because it has 8 bit registers at 32 bit offsets something is causing it to keel over.
<geertu> conordooley: IC
<geertu> conordooley: BTW, SOC_MICROCHIP_POLARFIRE should not select VITESSE_PHY, as the latter depends on the board
huseyinkozan has quit [Quit: Konversation terminated!]
<geertu> conordooley: VITESSE_PHY is somsthing to enable in a defconfig file
ivii has joined #riscv
aerkiaga has joined #riscv
jacklsw has joined #riscv
jacklsw has quit [Changing host]
jacklsw has joined #riscv
jacklsw has quit [Read error: Connection reset by peer]
BOKALDO has joined #riscv
<conordooley> geertu we had a chat in here about the kconfig stuff, palmer suggested that I do it like that until kconfig.socs gets sorted out
hexteex has quit [Quit: Leaving]
<conordooley> palmer: if there was something you had in mind for that rework, I wouldn't mind spending some time poking at it...
riff-IRC has quit [Read error: Connection reset by peer]
riff-IRC has joined #riscv
jmdaemon has quit [Ping timeout: 250 seconds]
___nick___ has joined #riscv
radu2423598 has quit [Ping timeout: 248 seconds]
jjido has joined #riscv
pecastro has quit [Ping timeout: 260 seconds]
<conordooley> geertu, now I am confused - if I do i2cdetect -y -r 1 I can see a device at 0x10
<conordooley> And if I put a raspberry pi hat on the board, i2cdetect -y -r 2 and -y -a 2 return something for the device corresponding to 44000000.i2c
<conordooley> (I also dont see the poor speed for device 0)
pecastro has joined #riscv
seninha has joined #riscv
elastic_dog has quit [Killed (osmium.libera.chat (Nickname regained by services))]
elastic_dog has joined #riscv
jjido has quit [Quit: My MacBook Air has gone to sleep. ZZZzzz…]
<geertu> conordooley: Ethernet seems to be flakey. nfs: server not responding, still trying
<geertu> (using Debian nfsroot)
<geertu> conordooley: I was using i2cdetect -a. -r indeed works better.
radu2423598 has joined #riscv
<geertu> conordooley: "resets: maxItems: 29" in "dt-bindings: clk: microchip: mpfs: add reset controller support" looks bogus tome
<geertu> conordooley: "reset_spec->args[0] - 3u" may underflow. Better to check the range first, and subtract 3 at the end ("return index - 3;")
<conchuod> I'll have to reply to my patch an apologise for the noise so!
<conchuod> re: 29 resets, not sure where that came from when clocks is just 1!
<conchuod> Thanks for taking a look.
connection-test has joined #riscv
connection-test has quit [Client Quit]
littlebobeep has quit [Ping timeout: 240 seconds]
littlebobeep has joined #riscv
jacklsw has joined #riscv
littlebo1eep has joined #riscv
littlebobeep has quit [Ping timeout: 240 seconds]
littlebo1eep has quit [Ping timeout: 240 seconds]
bauruine has quit [Ping timeout: 252 seconds]
littlebobeep has joined #riscv
jjido has joined #riscv
EchelonX has quit [Quit: Leaving]
vagrantc has joined #riscv
haise01 has joined #riscv
littlebobeep has quit [Ping timeout: 240 seconds]
littlebobeep has joined #riscv
littlebobeep has quit [Ping timeout: 240 seconds]
palmer1 has joined #riscv
palmer1 has quit [K-Lined]
littlebobeep has joined #riscv
connection-test has joined #riscv
connection-test has quit [Client Quit]
littlebobeep has quit [Ping timeout: 240 seconds]
littlebobeep has joined #riscv
<conchuod> I assume the ethernet was flakey before checking out my branch?
palmer has joined #riscv
jacklsw has quit [Quit: Back to the real life]
<conchuod> s/was/wasnt
seninha has quit [Quit: Leaving]
littlebobeep has quit [Ping timeout: 240 seconds]
crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #riscv
palmer has joined #riscv
Andre_H has joined #riscv
seninha has joined #riscv
connection-test has joined #riscv
connection-test has quit [Client Quit]
<conchuod> palmer: idk if you saw since your name didn't tab complete earlier - but geert was not a fan of using the polarfire soc symbol to enable the PHY for the icicle
frkzoid has joined #riscv
<conchuod> I said that was your suggestion until the kconfig.socs got reworked, and then offered to spend some time poking at that rework (if you had something in mind for it)
palmer has quit [Remote host closed the connection]
frkazoid333 has quit [Ping timeout: 248 seconds]
___nick___ has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
___nick___ has joined #riscv
palmer has joined #riscv
palmer has quit [Remote host closed the connection]
palmer has joined #riscv
<palmer> conchuod geertu I got hit bit this matrix-appservice-irc security bug, everything's kind of broken right now
<palmer> so for the rework: the original idea behind Kconfig.socs was to provide an easy place for users to say "I want all the support for SOC X", and then just have one Kconfig to turn that on
<palmer> that also helps us maintain the defconfigs, because we know which bits of HW go with which SOCs
<muurkha> palmer: what sort of VM?
BOKALDO has quit [Quit: Leaving]
<palmer> mur
<palmer> oops
<palmer> oh, you mean the hobby thing
<palmer> it's sort of like a container/vm hybrid, just a hobby project
<dh`> "just"
<dh`> those are the projects that actually move the world forward when they get done :-|
<conchuod> palmer: right, so that was the original idea - but what has gone astray? People like me coming along and wanting to add things that aren't the soc's drivers etc?
vagrantc has quit [Quit: leaving]
<muurkha> yeah
tafa has quit [Quit: ZNC - https://znc.in]
tafa has joined #riscv
jmdaemon has joined #riscv
<palmer> ya, it's kind of two things: the select-based approach is a headache to maintain (you have to select all the dependencies, and they change), and also the users really care about boards (and there's going to be too many to enumerate in Kconfig)
___nick___ has quit [Ping timeout: 260 seconds]
enthusi has quit [Ping timeout: 256 seconds]
enthusi has joined #riscv
<conchuod> I see. Well, I will go and have a poke around then palmer. I've not had any comments on the list about that kconfig series, so I won't respin. But if I do I will drop the PHY addition.
<conchuod> Given the variety of boards that I have (and the likelihood of more) I'm p willing to at least *try* to preempt the issue before I bash my head against it
<conchuod> Is there anything you have your heart set *against*?
<palmer> on my end there's just sort of no good option: it's certainly easier for users if they con just push a button and have everything they need to boot, but that's not how any other port works and it's not really viable to maintain such a huge list
<palmer> so I'm OK if folks want to try and keep it alive, we don't have so many right now that it's really a problem, but I think in the long run we're going to give up
<conchuod> I figure it is easier to give up when "fixing" it is only a couple of socs
<palmer> well, it's easier to keep fixing it when there's a small number
<palmer> IMO it's one of those things where we've got a lot of new people involvied in RISC-V, so we''ve tried to provide some of these little helpers
<conchuod> I guess it is up to you, do you think it is worthwhile to at least /propose/ something different ~now?
<palmer> ya, if you have a better idea then go for it
<conchuod> I'd be careful about labelling anything I do as "better" haha
<palmer> IMO the current Kconfig.socs implementation is clearly not going to be viable long term, so we need something
<palmer> I'd just remove it entirely, IIUC that's essentially what everyone else does
<conchuod> tbf I don't really look at anything other than arm64 (and maybe that *isnt* something to emulate). Their kconfig.platforms is in the same vein but not nearly as specific or dependancy heavy as .socs
<conchuod> But the other side of that is a 1500 line defconfig..
<conchuod> more like 1300, but thats moot
<palmer> right, that's the other problem with this: some drivers are depending on the Kconfig.socs entries, which is the opposite polarity from how it was designed (but because arm does it that way, folks assume we were doing it that way too)
<palmer> so it's sort of just an odd mix: sometimes Kconfig.socs turns on everything you need, sometimes it allows you to turn on things you need
<palmer> I forgot about that bit, that's why we can't just remove Kconfig.socs
<muurkha> palmer: I've been prototyping some ideas for a container/VM hybrid based on software transactional memory and object capabilities; I'm interested to hear what direction you're exploring
<conchuod> And none of that really addresses someone with demonade-dev-kit who wants something random enabled - or is that simply not something you want to support?
lagash has quit [Ping timeout: 240 seconds]
lagash has joined #riscv
littlebobeep has joined #riscv
<conchuod> palmer: when you say "some drivers are depending on the Kconfig.socs" do you mean "some drivers kconfig entries depend on the SOC_ symbol"
<palmer> yes
<palmer> IIRC there's a handful you can grep for
<conchuod> Oh I know there are, I introduced some of them..
<palmer> ;)
<conchuod> In my defense, I am a copy cat!
<palmer> so that's not what we'd designed this for, but it's what arm does so there's not much way around it
<palmer> ya, no big deal -- it's just a bad idea to have stuff that looks like something else but behaves differently
<conchuod> Without watching every subsystem like a hawk I dont think it is going to be possible to avoid the introduction of more?
<palmer> it's fine, just fix what's there
<palmer> we can always have a cycle where we turn them all on as dummy configs and then drop them, or whatever
<conchuod> Sure, haha
<conchuod> The other one that is probably hand in hand is depending on riscv for no real reason
<palmer> at least for those there is some amount of ISA-specific driver stuff, but I agree some are RISC-V-specific despite not really having anything to do with the ISA
<conchuod> depends on (RISCV && SOC_MICROCHIP_POLARFIRE) || COMPILE_TEST
<palmer> ya, that's not really necessary
<palmer> but IIRC there was some review feedback that it's how we want to do things, and I don't really care that much
<conchuod> care too much about what, sorry
<palmer> the SOC_* dependencies in drivers
conordooley has quit [Quit: Client closed]
haise01 has quit [Quit: Leaving]
pecastro has quit [Ping timeout: 248 seconds]
pecastro has joined #riscv
jjido has quit [Quit: My MacBook Air has gone to sleep. ZZZzzz…]
radu2423598 has quit [Ping timeout: 260 seconds]
<conchuod> hmm, what about the opposite palmer? There are several drivers that do a "default SOC_STARFIVE" in the drivers kconfig entry. Would that not allow the SOC_ entries to enable the driver without having to carry something unwieldy in kconfig.socs?
<palmer> it just changes that "Kconfig.socs needs to enable the subsystem" problem from an error to a silent do-nothing
<palmer> not sure which is worse ;)
<conchuod> Does it though? Maybe I am misunderstanding, but if you remove the "depends on SOC_FOO" but have "default SOC_FOO" does that not present the option regardless of whether the user knows that kconfig.socs exists?
<palmer> I thought you were talking about compared to the select in Kconfig
<conchuod> Ehh I meant "remove the select from kconfig.socs, remove the dependancy on the symbol from the driver & add a default"
<palmer> the depends is a bit different, IIUC the logic there is to prevent users from being shown useless choices -- so if it's a RISC-V-only (or SOC_MICROCHIP-only) device, then just don't even allow it to be enabled
<palmer> IMO having both the select and the depends is odd, as then it's not really an option
<conchuod> Thats the way it is rn for starfive and canaan
<conchuod> and for some of the mpfs stuff too
<palmer> so looking at arm, it's kind of a mix as well
<palmer> maybe this is a good plumbers topic?
<palmer> this stuff isn't really arch/ material anyway, it's just sort of in there beacuse there's nowhere else to put it
<conchuod> I misread, starfive and canaan do depends on SOC_ and default SOC_ not select and depends*
<palmer> OK, so I think both default+depends and select are reasonable, but not select+depends or select+default
<conchuod> "maybe this is a good plumbers topic?" you're the one that knows best.. But it does sound like an opinions needed question.
<palmer> yep, it's more of a question for what users are looking for
<conchuod> Either way, you have the "what do we do with kconfig.socs" part & the "do we do selects in kconfig.socs or default+depends" parts
pecastro has quit [Ping timeout: 276 seconds]
<palmer> so for now I think we can just keep going with what we've been doing for Kconfig.socs, this ad-hoc thing
<palmer> there's not going to be that many more by the time Plumbers rolls around, we can just have a session there
<conchuod> I'll drop the kconfig.socs stuff entirely then from what I sent.
<palmer> that'll give folks time to talk stuff over, particularly as the arm64 stuff also seems a bit ad-hoc (just looking at ARCH_K3 -> TI_* -> TI_SCI_PROTOCOL, for example)
<palmer> depends+default seems like the way to go to me, but it's not what arm/arm64 are doing so it's worth a look
<conchuod> just from having looked through the options, making the SOC_ symbol turn on what *boot requirements* that are set up with depends+default & then expose whatever optional stuff there is makes some ense
<conchuod> sense*
<palmer> ya, that seems reasonable
<conchuod> s/depends+default/depends+default need
<palmer> I guess I'd just have the default be whatever the average user with that chip would want
<palmer> it's probably going to be most things, as if you have the chip you probably want drivers for most of the HW on that chip
<palmer> it's not like drivers are super expensive or anything
<palmer> so aside from something like a debug interface, it's probably worth just defaulting to on
<muurkha> expensive in the sense of taking up much space?
<conchuod> As a user, I think I would expect that selecting SOC_FOO would allow a FOO to boot but I dont think I would *expect* more - although that would be nice
<palmer> I guess I'd expect it to just make it do everything I want, otherwise what's the point ;)
<palmer> but I guess it'll depend on each kconfig entry
<palmer> (and at that point it's up to subsystem maintainers, which is nice)
<conchuod> I suppose, any "real" user is going to have a precise config anyway wth things they dont want turned off
<conchuod> So whats the harm in the "new" user getting everything
<conchuod> w.r.t. talking about it in september, do you need me to "request" talking about it or something like that?
<palmer> you can submit a talk to the MC
<palmer> I think it might already be on the list of possible topics, so if you don't lead it someone else might
<palmer> and ya, that's my theory: if you really care about packing a Linux image into some amount of space, you're going to be way deeper than just "make defconfig and see what happens"
<palmer> even distros don't use defconfig, it's really for kernel hacking -- and then you want everything on, because you want to make sure it all still probes ;)
<conchuod> ill have a look at the mc stuff tomorrow so, need to be up at 0530... sorry for derailing your ?afternoon? with this