kito-cheng has quit [Quit: Connection closed for inactivity]
davidlt has quit [Ping timeout: 260 seconds]
davidlt has joined #fedora-riscv
jcajka has joined #fedora-riscv
<davidlt[m]>
VarLad: There is IRC to Matrix bridge, but technically this channel should become a Matrix channel with a bridge to IRC.
<davidlt[m]>
VarLad: See the topic, there is a link to the logs. Thus even if you disconnect it's easy to check on what was happening in the channel without any bnc, Matrix bridge, etc.
<davidlt[m]>
VarLad: We don't officially support the Lichee SBC, but I believe there is Fedora build for it. Fu Wei could know more. fuwei
<davidlt[m]>
rwmjones Conan Kudo : request for Matrix room and IRC bridge to Libera.Chat (fedora-risc) channel: https://pagure.io/irc/issue/70
<Eighth_Doctor>
excellent
<javierm>
davidlt[m]: what would it take for the Lichee SBC to be supported btw? Just to get all its support in mainline?
<javierm>
davidlt[m]: I've been using the fedora build (I think made by Fu Wei?) and is working well for me but I noticed that's using a heavily patched kernel
<davidlt[m]>
javierm: correct. I do believe that D1 is now bootable from upstream (I might be wrong). At least with upcoming 6.0 (or 6.1) I would expect it to boot.
<davidlt[m]>
javierm: I don't have one too, and I not sure where to get one in EU.
<davidlt[m]>
Ah, Seeed studio has it :)
<davidlt[m]>
But out of stock.
<javierm>
davidlt[m]: I got it from Amazon Spain but noticed that it's not available in other EU countries
<javierm>
davidlt[m]: but if the problem is only HW availability, I'm happy to help with testing, fixing, etc
<davidlt[m]>
Looking at Amazon Spain I see it's going for 53-76 EUR, that's expensive ;)
<javierm>
davidlt[m]: yeah, I got it for 42 IIRC
<davidlt[m]>
You will be able to get a board with better performance compared to Unmatched for a similar price, I think. JH7110 based stuff.
<javierm>
a few months ago. Still quite expensive but the cheaper I could find for a riscv machine :)
<davidlt[m]>
Yeah, IIRC you would need at least 1GB model for this to work properly.
<davidlt[m]>
There will be newer T-HEAD products on the market sooner than later too.
<javierm>
davidlt[m]: yeah, mine is only 512 MiB but from a memory POV isn't worse than the rpi zero
<javierm>
that is, dnf doesn't work and it gets OOM killed but micro-dnf works
<davidlt[m]>
There are basically two things we need to figure out: (1) does unpstream 6.0 kernel can boot the board (not all features are required); (2) figure out how to properly assemble disk image for this [easy one]; (3) one more, we need to figure out how to build the bootstack for it in Fedora.
<javierm>
it's slow but usable. Just like the Cortex A armv7 machines from a decade ago :P
<davidlt[m]>
Yeah, DNF needs at least 1GiB. There were recent complains about this.
<davidlt[m]>
Nah, this is a single core in-order core. Systemd hates those :)
<javierm>
hehe
<davidlt[m]>
The most popular boards will be JH7110 based ones (VisionFive V2 and PINE64 Star64).
<javierm>
davidlt[m]: cool. I can take a look to (1) and (2) then. If not this weekend then likely the next one
<davidlt[m]>
Those contains SiFive core IP with U74-MC (way newer compared to FU740 in Unmatched).
<davidlt[m]>
javierm: yeah, try to build upcoming 6.0 kernel and boot that. For example you could use OpenEmbedded or Buildroot to speed this investigation.
<davidlt[m]>
If it boots, we need to enabled the proper config in kernel-ark repostory so our default kernels work.
<davidlt[m]>
There is a question about bootstack. U-Boot is probably ours. OpenSBI GENERIC probably works, but I am not sure if there are other bits (e.g. that do DDR init, etc.).
<davidlt[m]>
For SiFive FU540 and FU740 DDR init stuff is open source and lives within upstream U-Boot repo.
<davidlt[m]>
That's not the case for JH7100 (the chip in BealgeV). That's done in lower boot, before SPL happens IIRC.
<davidlt[m]>
Fu Wei most likely knows all the bits as he prepared a disk image.
<davidlt[m]>
I am not happy to take in vendor patches if they are not posted for upstream review, and if they are not well reviewed.
<davidlt[m]>
So if the are missing pieces, but those are smallish, not affecting other SoCs, published on the mailing list I am OK to pull them in.
<javierm>
davidlt[m]: so I guess first step is to do some u-boot upstreaming so that we can use the fedora u-boot package images
<davidlt[m]>
"because DRAM init has not yet been reverse engineered, we are using the BSP's boot0 as SPL"
<davidlt[m]>
So it seems we cannot avoid some binary blobs assembling boot loader chain.
<javierm>
I see, sigh
<javierm>
davidlt[m]: all this can be done independently though from enabling the needed bits in kernel-ark
<davidlt[m]>
Yeah, it's all parallel stuff.
<javierm>
we won't be able to boot images yet without sorting out the boot stack but at least can't get rid of a fork
<javierm>
davidlt[m]: cool. I'll try to make some progress now that understand what's needed. Thanks!
<javierm>
don't have that much time to hack on this but tinkering with a new arch is always fun :)
<davidlt[m]>
cool. Kernel should be somewhat easy, it's just lots of compile and testing. Requires time and compute.
<davidlt[m]>
I just hope GRUB2 next release contains all needed bits for RISC-V.
<davidlt[m]>
I believe boothardid UEFI protocol and LoadFile2 is not yet in.
<javierm>
davidlt[m]: yeah, I'm a fedora kernel developer so I'm used to that process
<davidlt[m]>
I have kernel-ark port, but don't have time to make a PR yet. I think we might have chatted about this a year ago in fedora-kernel :)
<davidlt[m]>
javierm: I am adding more boards and thus creating more accounts to fedora.riscv.rocks. Miro has been bootstrapping Python for a week or more now.
<davidlt[m]>
I was happy to have some time to work on other stuff as Miro was working on Python, but that very quickly evaporated :(
<davidlt[m]>
My current goal is to get as many builders online as I can to have more folks working on it.
<davidlt[m]>
Thus at some point I should be able to create you an account too.
<javierm>
davidlt[m]: awesome. There's no rush since I can do progress with my normal fedora FAS
<davidlt[m]>
javierm: I plan to rebase my kernel-ark stuff once 6.0 shows up. If you keep reminding me I might finally send a PR. Things don't change. Actually it would be way easier to send the current v5.18 based stuff and adjust for v6.0.
<javierm>
davidlt[m]: up to you. That's for ther other riscv boards right? Since AFAIU the D1 stuff didn't land until 6.0 ?
<davidlt[m]>
Yeah, we mainly support SiFive HiFive Unmatched.
<davidlt[m]>
The next big boards (i.e. high impact to the community) is JH7110, StarFive VisionFive V2 and PINE64 Star64.
<davidlt[m]>
That will be followed by Intel/SiFive Horse Creek, which should be a performance king.
<davidlt[m]>
That's OoO cores (P550) with Intel 4 (7nm) process.
<davidlt[m]>
There will be other boards too (there are/will be two new BeagleBoards too).
<davidlt[m]>
Some more T-HEAD based boards/products should show up too.
<davidlt[m]>
JH7110 is better (up to 1.5x) than FU740 / Unmatched, for several times cheaper price point.
<javierm>
davidlt[m]: what SoC would the new beagle boards use ?
<davidlt[m]>
Horse Creek should win any performance benchmarks based on the fact it's on 7nm process, but that cannot be cheap :)
<davidlt[m]>
javierm: not sure I could reveal that. drewfustini is that a public knowledge?
<javierm>
davidlt[m]: no worries
<javierm>
just in case was public info
<davidlt[m]>
javierm: I think, one of those should be quite interesting IIRC.
<davidlt[m]>
Until those happen I personally plan to focus on JH7110 stuff (should be widely popular) and Intel/SiFive Horse Creek (something that any developer will love for the speed of it).
<davidlt[m]>
I expect to add boards based on these SoCs into Fedora/RISCV Koji infra too.
<javierm>
davidlt[m]: I still think that XuanTie C906 / D1 could be interesting also due its price point, even if performance is bad
<javierm>
also the rpi zero-ish form factor is nice for IoT / maker projects
<davidlt[m]>
Note, that StarFive posted yesterday to kernel mailing list JH7110 minimal support.
<javierm>
yeah, saw the thread archive you shared
<davidlt[m]>
Sure, and it's gaining upstream support. I am not against it :)
<davidlt[m]>
I am just against a full blown vendor BSP kernel patches without any upstream review :)
<javierm>
davidlt[m]: absolutely!
<javierm>
now, if we need blobs to boot then that's a big downside in my book
<javierm>
hopefully it could grow proper u-boot SPL support
<davidlt[m]>
Again, small things I understand (e.g. a new DT compat string, etc.), but not large chunks of invasive kernel driver changes.
zsun has joined #fedora-riscv
zsun has quit [Quit: Leaving.]
<davidlt[m]>
djdelorie: do you have a swap file created?
<davidlt[m]>
I see webkitgtk restarted, maybe due to memory capacity issues.
<kalev>
davidlt[m]: can you try to capture the webkitgtk build log somehow to see when it exactly runs out of memory? there are a few knobs to turn to get it to build but would be good to know where it runs out of memory
<davidlt[m]>
kalev: in the past I used to reduce debug info verbosity, but I wanted to see on the current boards it could work :)
<davidlt[m]>
I guess, that's was not the case.
<davidlt[m]>
dmesg probably would show OOM info.
<kalev>
ah, like -g1 or so? let's just put it in the upstream spec file in that case
<davidlt[m]>
Yes
<davidlt[m]>
Let me bring back old changes and see if that makes it go
* kalev
nods.
jcajka has quit [Quit: Leaving]
<davidlt[m]>
hm... somehow gethostbyname is failing and thus killing some packages in testing
<davidlt[m]>
something to look at later on
matrixbridge has joined #fedora-riscv
matrixbridge has left #fedora-riscv [#fedora-riscv]
matrixbridge has joined #fedora-riscv
matrixbridge has left #fedora-riscv [#fedora-riscv]
nirik[m] has joined #fedora-riscv
<nirik[m]>
Test from matrix
<nirik>
Test from irc
Kevinsadminaccou has joined #fedora-riscv
<davidlt[m]>
oh!
<davidlt[m]>
Test
<davidlt[m]>
Okay, it seems this works!
<davidlt[m]>
We have #riscv:fedoraproject.org matrix room bridged to the IRC channel.
<nirik>
shall I make you a mod?
<davidlt[m]>
Sure. Richard ( rwmjones ) too.
<nirik>
he will need to connect to the matrix room first I think... can do it then
<rwmjones>
nirik: I can see your messages from both:
<rwmjones>
18:17 < nirik[m]> Test from matrix
<rwmjones>
18:17 <@nirik> Test from irc
<rwmjones>
so looks like it's working thanks
<rwmjones>
let me join matrix again ..
RichardJones[m]1 has joined #fedora-riscv
<RichardJones[m]1>
testing
<RichardJones[m]1>
this is the account that should be admin
<rwmjones>
why is my nick on matrix all wrong, one sec ...
<rwmjones>
anyway, it's: @rwmj:matrix.org
<davidlt[m]>
nirik: I think the mod should be @davidlt:matrix.org account instead of @davidlt[m]:libera.chat (but I am not an expert in Matrix)
<nirik[m]>
ah yeah, let me fix.
<davidlt[m]>
I am connected via IRC, via Matrix bridge to IRC and via Matrix too :D
<rwmjones>
nirik[m]: for me it should be @rwmj:matrix.org
<davidlt[m]>
I am here in all 3 ways :D
<nirik[m]>
rwmjones: nice profile pic. 😉
<davidlt[m]>
The only difference is that Matrix IRC bridge shows me folks from IRC. The room doesn't.
<nirik>
it sometimes takes a while to sync that in the background
<davidlt[m]>
ah, ok.
<davidlt[m]>
Well maybe (probably not) I will get messages from IRC in the correct order :)
<rwmjones>
interestingly if I join using both the matrix website and the android app it only shows me once
<rwmjones>
i guess 2001:470:69fc:105:: must be an element IP