[+] rom pseudocode

[kelas]

lets have some fun, shall we not

[kelas]

obviously, most of this is well-known by now, and is generally or academic interest.

except maybe one thing.

8801e6ca            interrupts-extended
8801e6fc            interrupt-parent

this is not meant to be, and these two strings i have no immediate rational explanation for. but if my gut doesn't fail me, this might mean that we actually have a more useful chip than it is currently conjectured to be.

which is useful enough as it is :)

(by the way, @lizhirui, the guy responsible for the amazing linux-0.11 work, sadly decided to give a total blah-blah instead of a proper explanation when asked why he gave up on running the kernel in S-mode - where kernels actually belong on RISC-V, and by the way this is actually totally doable on k210. there's one thing to be understood about the Kendryte chip - if something seems broken to the point of being undocumented, this only means it is undocumented for the exact opposite reason.)

@lizhirui no offense, please. if i'm not mistaken, running a kernel in machine mode on RV must mean that you're down to translating sv39 in software. you'll agree this is an unbearable performance tax for an embedded context-switching system, especially if we know that the hardware for it is there - we're simply not told how to cut the corner called "how to delegate or at least efficiently proxy all external interrupts to S-mode".

which is not something one cannot figure out without visual aids, frankly speaking.

Only M and U mode can be used in practice.

I don't think so.

https://github.com/kelas/k210-sdk-stuff/blob/5feab3fdd0a5c57767dbba20ab78abb5a8ffee9e/rom/STRINGS.txt#L67

[Forty-Bot]

Did you use ghidra to generate the pseudocode? If so, do you have a link to your project anywhere?

8801e6ca interrupts-extended 8801e6fc interrupt-parent

These strings are from the device tree at 8801d000. Unfortunately, it is not usable because it contains errors. E.g. it has clock-frequency = <26000000>; and the same for timebase-frequency, but clock-frequency is actually 390000000 and timebase-frequency is actually 7800000. Similarly, the memory is documented incorrectly; it implies that there are four total banks totalling 16M, when two of the banks are (un)cached aliases of each other. In addition, the compatible strings are not very helpful, since many devices are designware IP and not custom.

by the way, @lizhirui, the guy responsible for the amazing linux-0.11 work, sadly decided to give a total blah-blah instead of a proper explanation when asked why he gave up on running the kernel in S-mode

And so what do you think the issue is?

[laanwj]

Thanks for the PR!

[laanwj]

@lizhirui no offense, please. if i'm not mistaken, running a kernel in machine mode on RV must mean that you're down to translating sv39 in software.

That's an option, but not necessary, I think. The MPP bit in mstatus works, and makes it possible to read/write (but not execute) from memory as if in U mode, from M mode.

That said, it doesn't really translate to how Linux does things. The amount of changes needed to get a modern Linux kernel to run on the K210 with MMU support seemed enormous to me, so I gave up on it myself. Also they've already stated that support for none/old-standard RISC-V MMUs won't ever be merged upstream which is demotivating.

[Forty-Bot]

(from @lizhirui's reddit post)

The kernel is running machine mode not supervisor because of bug of K210(When the K210 is running in supervisor mode,the global interrupt switch is out of control and always "on",I checked the source code of spark of rocketchip of K210 and found the corresponding logical error).

(from the sifive plic binding)

A hart context is a privilege mode in a hardware execution thread. For example, in an 4 core system with 2-way SMT, you have 8 harts and probably at least two privilege modes per hart; machine mode and supervisor mode.

Hypothesis: The contexts on the K210 are

0 - Hart 0 M-mode
1 - Hart 1 M-mode
2 - Hart 0 S-mode
3 - Hart 1 S-mode

If you try and claim an interrupt from S-mode but do it via the M-mode claim register, then SEIP will never get cleared.

[kelas]

Thanks for the PR!

not at all — and I also totally appreciate why nobody's in a hurry to merge this little piece of public heresy :)

[kelas]

Did you use ghidra to generate the pseudocode? If so, do you have a link to your project anywhere?

yes, a combination of the excellent r2 work from this very repo (due to @laanwj i think) and some quick ghidra make do, plus some obvious pseudocode brush-up.

and no, i don't help ghidra grow — i let someone from the three-letter shop do it, at the taxpayer's grace. what a god-awful piece of software.

8801e6ca interrupts-extended 8801e6fc interrupt-parent

[device tree] not usable because [...] many devices are designware

yes, but let's give Canaan folks some credit for what they pulled off. they taped out an rv64gc in late 2018 - to my knowledge, they were simply the first to get there, and that defies quite a bit of gravity in my book. in late 2019, sifive's 64-bit board sent a handful people back $999, and is now a collectible item (i know i'll never sell mine), and the icicle soc is just in for $499, but omg it smells libero lock-in from 10 miles downwind, ugh 🤢

but look, it's late 2020, and esp32s2 control unit is an rv32 core — now, that is tremendous. we're getting there, and 🦾 can be pwned by nvidia all the way up until it goes click.

And so what do you think the issue is?

i think the issue is that either @lizhirui or canaan or both or me read the text of that particular privileged spec draft somehow backwards, which wasn't too difficult. it was a real mess.

i wasn't interested in porting linux proper anyway, if western digital guys couldn't get the right hints from canaan and went for broke, then it's probably just worth sitting it out - what i think is happening is canaan keeping something better under the wraps, and they know how to keep a low profile - besides, it doesn't look like the middle kingdom is short on domestic demand to start flooding the global markets with absurdly cheap silicon too soon (fair enough, considering:)

what i have though is her majesty xv6 running more or less by the book on a k210 board, and that I am willing to share at some point. the patch is pretty compact.