Posts
464
Following
144
Followers
150
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/
@dwagenk or device tree & it's variants too...
0
0
1
https://www.devicetree.org/

Devicetree devicetree DeviceTree

How am I suppose to know when the organisation itself doesn't!
0
5
8
@monsieuricon been getting an error 500 accessing my "home timeline" on the social.kernel.org website. "Public timeline" works though. Any idea what may be the cause?
1
0
0
Back working this morning. DDR/DDR training issues perhaps?
0
0
0
Welp, my visionfive v2 might be a little on the kaput side?

Been running the same boot process since I got my board.
tftp a fitImage w/ initramfs and then boot w/ bootm as might be expected.

First time I powered it on today, it bootlooped once but then worked properly.
Rebooted it and since then it's been bootlooping in U-Boot non stop.
`bootm ramdisk` or `bootm loados` tend to be where it dies.

Randomly had it start working again just now, while manually entering the commands for a couple boots in a row.
Allowing autoboot, which runs the same commands, didn't.

Back to not working at all again now.

🤔
1
0
0
I hate outlook & I hate automatic replies.
0
0
3
https://social.kernel.org/notice/ARVWmKdhWckD0iaCWm

Looked at this again today, having fixed some build issues in the pinctrl driver. Looks like the patches posted to the ML do the right thing after all, woops!

I had been trying the "upstream" branch in their GitHub repo, so that I didn't have to fix the pinctrl driver in order to try the board out.
The branch is older than I thought it was, so perhaps it was not a good idea to do that & I came a cropper as a result.

I feel terrible about this sort of thing, I hope I didn't waste too much of their time.
0
1
2
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
Show older