Posts
461
Following
145
Followers
149
The cat is not mine :(

I like cycling, powerlifting, bad video games and metal.
Otherwise, I occupy my time with various bits in RISC-V land.

~useless, placeholder, website: https://www.conchuod.ie/
2023 goal: get my squat back to 200 kg again
0
0
2
2022 contribution recap
Show content
I usually hate talking about anything that I've done, but reading Nathan's
yearly recap* inspired me to bite the bullet... so here's a wee bit of a
recap of my one, from what we in Ireland call a blow-in :)

* https://nathanchance.dev/posts/2022-cbl-retrospective/

## Linux

Before 2022, I had one driver and it's bindings upstreamed & had sent a v1 of
updating the initial PolarFire SoC/Icicle device tree to something closer to
reality.
2022 was a little different, and I've kinda dived into working upstream.
Overall it's been great, and I've spent the year learning non-stop.
Engaging with upstream has lead to development of my skills that my small
(and very busy) team at work was not able to provide.
By-and-large, everyone I've worked with has been nice and/or helpful, so thanks
to everyone that's helped me along the way :)

### Things I managed to finish

172 non-merge commits:
- 50 for devicetrees
- 45 for dt-bindings
- 113+ explicitly PolarFire SoC related

In summary:
- overhaul & peripheral additions to the PolarFire SoC/Icicle device tree
- upstreamed dts for other dev kits
- upstreamed PolarFire SoC clk, spi, i2c, rtc, reset, musb, sys controller &
hwrng drivers
- re-wrote PolarFire SoC's clk driver to actually match the clock parentage in
hardware & created a driver for fabric clocks in the process
- cleaned up all RISC-V device trees to the point that we were error free, in
the process doing a fair few of the 45 binding patches
- fixed RISC-V's topology reporting :)
- started the conversion process from SOC\_FOO to ARCH\_FOO & cleaned up a lot
of Kconfig.socs, but there's more work to be done there!
- fixes for when the above went wrong!

So a fair bit different to my previous years contributions :)

### Other efforts

160 other contribtions:
- 28 Acked-by
- 21 Reported-by
- 45 Tested-by, enough to feature in the top tests for one release...
- 81 Reviewed-by

Some of the above applies to issues people spotted with my contributions, but
the majority came in the second half of the year as I've gotten more involved
with reviewing stuff aimed at linux-riscv.

C3\_STOP was enabled for the RISC-V timer driver, sending me on a lengthy
bisection to find the root cause - it had been enabled as the letter-of-the-spec
compliant thead arch timer implementation needs it, but without the required
broadcast timer setup done! Between the SBI spec, the regression reports and
the various patches it took ~3 months to actually get fixed - but was a fun one
due to the confusion from all parties. Thanks in particular to Samuel Holland
for figuring out /why/ C3\_STOP broke stuff.

I initially took on applying patches for the mpfs devicetrees at some point
in Q2 or so. More recently, I have taken over all RISC-V devicetrees that are
without specific maintainership now that RISC-V dts patches are routed via the
soc tree. Ditto for drivers/{soc,firmware}, although the later does not yet
exist for RISC-V.. Hopefully that all makes Palmer's life easier and the patch
application time shorter!

### LPC

LPC was in my backyard this year, so I went along to that.
Not really one for public speaking, but I ended up talking about how what to
do with Kconfig.socs for RISC-V.
No intention of repeating that next year, that's for sure.
The main benefit of LPC though was meeting people for the first time.
In particular, meeting Palmer kicked off the work we've done in getting the
linux-riscv patchwork instance up and running.

### Patchwork/CI

After LPC, we wiped the patchwork instance of old content. Bjorn Topel ported
NIPA to the instance & I got it running in the Microchip FPGA CI. We've since
done a bit of work on finishing that port & sorting out some niggling issues
with the error reporting. Palmer runs a weekly patchwork sync meeting now & it
appears to have made both sides of the upstreaming process easier..

Additionally, I realised that RISC-V has little test coverage. I added a bunch
of pipelines to our internal CI that tests linux-next, stable kernels we care
about, and of course mainline. Found a few bugs in the process, including the
aforementioned C3\_STOP issue!

## QEMU

A handful of patches, perhaps 10-15. I fixed the direct kernel boot for
PolarFire SoC on recent kernels & did some general virt/spike machine dtb
cleanup. Maybe in 2023 I'll submit some more support for mpfs peripherals, but
that entirely depends on what I need to use QEMU to debug!

## OpenSBI

Two minor docs fixes! Not much to speak of really. I'd imagine that 2023 will
be relatively similar contribution wise.

## U-Boot

Not really much to speak of here either. Apart from porting trivial bugfixes
from Linux to U-Boot, I re-worked the clock driver for MPFS so that it could
handle both the incorrect devicetree that was upstreamed originally & the one
which aligns with the dt-binding. If only things weren't upstreamed before
their bindings were approved...

Beyond stuff that is directly $dayjob related, I think I have single review tag
in the whole year. Hopefully there'll be more there in 2023.

As with Linux, I have set up internal CI to test U-Boot versions that we care
about.

## Conclusion

As you can tell, one thing absorbs most of my time in terms of upstream work. I
don't see that changing in 2023. Perhaps in 2023 I'll submit a driver written in
Rust. I struggle for motivation without a goal, so writing one would be a nice
jump into more interesting Rust code than the two TUI apps I wrote in 2022. One
of those runs my board farm and, while basic, is something I use every day.
Or perhaps I'll check out rustSBI...
0
3
9
The devel branch doesn't get to a login prompt for reasons I have yet to determine, but it does have uart output and gets mostly there, but it's not a recent kernel so of little use to me!
0
0
0
https://social.kernel.org/notice/ARTnwlSzwjbS0yDXJA

I figured out my problem... The Quick Start Guide says use a particular uart, U-Boot uses said uart & the "devel" branch of the StarFive GitHub uses it too.
But for some reason the patches for Linux do use a different uart as stdout-path!
1
0
0
@pdp7

Not much (at least compared to some friends)
```
call plug#begin()
Plug 'preservim/vim-colors-pencil'

Plug 'dnlhc/glance.nvim'
Plug 'airblade/vim-gitgutter'
Plug 'folke/which-key.nvim'
Plug 'lewis6991/gitsigns.nvim'
Plug 'vim-airline/vim-airline'
Plug 'cloudhead/neovim-fuzzy'
Plug 'neovim/nvim-lsp'
Plug 'neovim/nvim-lspconfig'
Plug 'nvim-lua/plenary.nvim'
Plug 'nvim-telescope/telescope.nvim', { 'branch': '0.1.x' }
Plug 'nvim-treesitter/nvim-treesitter'
Plug 'nvim-telescope/telescope-fzy-native.nvim'
Plug 'sindrets/diffview.nvim'
Plug 'sharkdp/fd'
Plug 'kyazdani42/nvim-web-devicons'
Plug 'kyazdani42/nvim-tree.lua'
Plug 'tpope/vim-fugitive'
call plug#end()
```
0
0
1
@pdp7 Ohh, don't worry - I am scratching the surface too. Got a about a dozen plugins only, mostly stuff like treesitter, telescope, & a couple other bits to make code searching easier.
1
0
1
@pdp7 I was wondering how a wandering mailbox worked ;)
0
0
1
@pdp7 Yup. https://github.com/neovim/nvim-lspconfig + clangd. s/clangd/rust-analyzer when I try to write Rust.
0
0
1
@palmer I've now got u-boot to a satisfactory point, but had trouble getting a usable kernel out of what was posted to the list. Couldn't get their ones in GitHub to work either, so that's enough for now.
0
0
0
Tried the JH7110_VisionFive2_devel branches, no joy getting to a login prompt there either :( I guess I shall have to wait until things stabilise a bit lol
0
0
0
I take that back, both are non-functional in linux. gmac0 is just able to get an IP. Perhaps taking the latest code from the lists wasn't the best idea!
1
0
0
hmm, so only gmac1 seems to work for me in u-boot, but only gmac0 in linux. That's not so good!
1
0
0
visionfive 1 didn't either IIRC, mildy annoying given their u-boot is fairly old and given the boards age, out of tree.
1
0
0
Doesn't come with support for "tftp" in the default config :(
1
0
0
@palmer nope, just arrived today. Need to swap out whatever default bootloader setup it's got to something TFTP-able before I do anything else w/ it.
1
0
0
Finally :)

This time without a dirty mat!
2
0
4
The diagnostics from clangd really suffer from too many false positives. Mostly ends up getting ignored, even when it's right, as a result :/
0
0
1
@gmarkall That sounds perfect really. Better than my face appearing, thats for sure!
0
0
0
@ljs all of mine are named after characters in Bob the Builder. I never even watched Bob the Builder as a kid...
I like seeing what people's message-ids are, shows personality :)
0
0
1
@ljs meh, there's nothing cringe about it imo
0
0
1
Show older