<wigyori_>
dlan: do you feel like these could be backported to 6.6, or are there already too much dependencies in the kernel releases inbetween?
wigyori_ is now known as wigyori
<dlan>
wigyori: yes, it's possible (shouldn't cost too much effort).. but I'd personally like to focus on a more recent version (target mainline) first..
<wigyori>
dlan: absolutely - i was just wondering whether an openwrt target could be put together with backporting your patchset
psydroid2 has joined #riscv
<dlan>
then you can just stick to 6.1.. I heard rumor that vendor has motivation to support lastest 6.6-LTS (but un-confirmed), you probably can wait
<wigyori>
ah okay - if they are rumoured to make that step, will wait
<conchuod>
Probably 6.6 to get vector with back ports of core arch code @dlan ?
Leopold has joined #riscv
Andre_Z has quit [Quit: Leaving.]
<lu_zero>
what's sure is that that 6.1 needs few fixes/backports in any case :\
ldevulder has quit [Quit: Leaving]
<conchuod>
lu_zero: For what?
BootLayer has joined #riscv
<courmisch>
anybody poked the custom matrix extension on K1?
<ja_02>
dlan do u know if chen uses IRC or discord? it looks like you two have done a bunch of work on this and chens branch looks mostly for upstream.
<ja_02>
also they have an ASN which is cool. i have wanted to get an AS number but cant justify the price, or have they money for that matter lol
<dlan>
ja_02: he is in this channel occasionally, we can wait him to send out first dt/basic patch..
<ja_02>
ok ill wait then
<dlan>
conchuod: em.. have no plan for 6.6 currently.. will see if have time later (low priority)..
<conchuod>
dlan: Ye, I wouldn't really bother either. Let some vendor that wants stuff on 6.6 handle backporting support ;)
YangyuChen[m] has joined #riscv
<YangyuChen[m]>
<ja_02> "dlan do u know if chen uses..." <- I'm here.
<YangyuChen[m]>
Sorry, I didn't watch IRC frequently.
coldfeet has joined #riscv
<YangyuChen[m]>
I have done a initial support just for a full cpu node on dts with uart node. And I have a patched opensbi with vendor drivers to turn ZICBOZ on. But it may takes a lot of effort to make this board usable with some drivers for USB, PCIe, MMC, Ethernet.
Andre_Z has joined #riscv
<YangyuChen[m]>
I just do some kernel stuff when I'm free. I'm a Ph.D. student in Computer Architecture. So maybe I will just do a minimal kernel with minimal device support (uart+ethernet is enough) to run some CPU benchmarks to have an evaluation for my own needs about my research purpose. Just like what I did for K230 with minimal dts with CPU + UART + USB node so we can have the USB Ethernet on board to work. I also submitted these minimal patches
<YangyuChen[m]>
to the mainline. In other words, I have too much time to provide full device support. So, this effort may need others to do.
<YangyuChen[m]>
If I can get ethernet to work on some board, I will have a chance to use NFS as rootfs to run a distro. However, I know many people do not like this way to boot.
<YangyuChen[m]>
* words, I don't have too
<YangyuChen[m]>
In other words, I don't have too much time to provide full device support. So, this effort may need others to do.
<conchuod>
nfs is good as a kernel dev with lots of boards ;)
<YangyuChen[m]>
Yeah. I use chroot with qemu-user on my x86 machine to compile some software.
<conchuod>
Also, if spacemit is going to produce multiple socs (or the bpi board is going to be popular), I would love to have someone actually maintain the platform, rather than the k230 where there doesn't seem to be much interest in supporting drivers etc for it.
<YangyuChen[m]>
I think so. K230 is lake of cores and ram. I can't even run SPECCPU 2006 on it.
<courmisch>
maybe kernel and uboot people see NFS as normal, but I think most of us in user-space need TF, MMC or PCIe
<YangyuChen[m]>
So maybe providing a minimal dts will be a good way to start and attract more developers to put their efforts to have more drivers to work.
<conchuod>
YangyuChen[m]: the biggest annoyance for me with boards is when the bootloader doesn't support tftp booting.
<YangyuChen[m]>
Maybe some developers taking too much efforts on how to make the uart runs on K1. It does not compatible with ns16550 which will have no interrupt to work.
<courmisch>
not sure how I should feel about the fact that people still use my k230 bootstrap 6 months on
<YangyuChen[m]>
conchuod: Oh. Actually the vendor U-Boot can do tftp.
Leopold has left #riscv [#riscv]
<conchuod>
k230 or k1?
<YangyuChen[m]>
Just type space
<YangyuChen[m]>
Then it will stops
<YangyuChen[m]>
K1
<conchuod>
I forget if the k230 does or not. I should turn it on...
<courmisch>
k230 has TFTP, vendor uses it
<conchuod>
courmisch: Yeah, but I suppose not all that different to the vendor's k210 support
<YangyuChen[m]>
K230 can did it either. But they uses M-Mode U-Boot
<courmisch>
they even left their IP and username in the config file
<YangyuChen[m]>
So you need to warp it on OpenSBI as S-Mode payload
<courmisch>
conchuod: I have not used k210, so that's not evocative to me, TBH
<YangyuChen[m]>
I use tftp to pull fw_payload.bin generated by OpenSBI
<conchuod>
ohh ye, it's opensbi -> linux. I remember there being something "unfriendly" about it.
<courmisch>
if you use vendor SDK (or my garbage based on it) kernel is SBI hard-coded payload
<YangyuChen[m]>
Yes. The M-Mode U-Boot support is not well.
<courmisch>
uboot SPL -> uboot -> SBI -> Linux
<YangyuChen[m]>
But as a developer which needs to do some hacky things on SBI, actually I like M-Mode U-Boot.
<conchuod>
I don't mind having m-mode u-boot either. I just don't like not having s-mode u-boot as well.
<YangyuChen[m]>
I would like this: U-Boot SPL -> U-Boot S-Mode -> SBI + U-Boot S-Mode -> Linux
<YangyuChen[m]>
I would like this: U-Boot SPL -> U-Boot M-Mode -> SBI + U-Boot S-Mode -> Linux
<courmisch>
why make things simple when you can make them complicated, alright
<conchuod>
courmisch: It's nice when you want to develop SBI to have a fully featured U-Boot on these boards to tftp it etc.
<conchuod>
YangyuChen[m]: The U-Boot I have on my canmv does not appear to have ethernet support.
<YangyuChen[m]>
conchuod: You may need `usb start`.
<YangyuChen[m]>
Since the ethernet is a usb ethernet.
Stat_headcrabed has quit [Quit: Stat_headcrabed]
<YangyuChen[m]>
I do the same stuff on Apple Silicon Macs with m1n1+uboot to have mainline linux to run. An RTL8152 USB 1Gbps ethernet adaptor will works well on U-Boot. But some new USB ethernet with 2.5Gbps ethernet like RTL8156 does not work now. I'm not sure what chips on canmv-k230, but it works on its vendor U-Boot.
<courmisch>
RTLB USB and works well in the same sentence
<courmisch>
I must be reading wrong
<YangyuChen[m]>
Oh. RTL8152 works well. But RTL8156 not.
Stat_headcrabed has joined #riscv
<conchuod>
YangyuChen[m]: Oh neat, that works. All I need to is build the kernel wrapped in the opensbi payload I guess.
<YangyuChen[m]>
RTL8152 is common on gigabit ethernet. But now you can buy some new usb ethernet adaptors with 2.5Gbps at nearly same price which has RTL8156 inside. But it does not works well on U-Boot.
<YangyuChen[m]>
conchuod: Yes. I found this on my shell history `make CROSS_COMPILE=riscv64-linux-gnu- PLATFORM=generic FW_FDT_PATH=../linux/arch/riscv/boot/dts/canaan/k230-evb.dtb FW_PAYLOAD_PATH=../linux/arch/riscv/boot/Image FW_TEXT_START=0x0`