01:38 <cyrozap> In case anyone's interested in the (non-GPU) ISA RE I was talking about last week, I finally got around to posting my scripts: https://github.com/cyrozap/mediatek-lte-baseband-re/tree/fadf466eb71b47e61c1bfd907f1326dcfeff9525/DSP/MD32

01:41 <cyrozap> Of possible interest are the objdump disassembler wrapper (`md32_dis.py`) and the script that tries to identify opcodes (`find_instructions.py`). It's a little specialized for the MD32, but it should be fairly straightforward to port to other ISAs and disassemblers, since it's mostly just a bunch of regexes.

01:42 <cyrozap> Apologies for the code quality, though--it's a bit spaghetti-like, and still in development.

01:45 <cyrozap> I think probably the most important parts of this code are how instructions are uniquely identified, since that took me a while to figure out how to do: Basically, instructions should be matched based on the mnemonic and the format of the arguments, since generally you're only ever going to have one format per opcode/bit pattern (of course there's exceptions, but I didn't encounter any with this ISA).

01:46 <HdkR> Research code is always messy, w/e

01:48 <cyrozap> Also, the code identifies new instructions by just flipping bits in the instruction until the disassembler identifies it as a different instruction (matched on mnemonic+arg format). Then you can use that list of (un)essential bits to generate a mask for the opcode.

01:51 <cyrozap> HdkR: I know, but generally I like to make sure things are clean so that other people can more easily understand what I've done. I've had to spend a lot of time picking apart other people's "research code" before, and would rather not inflict that kind of annoyance on others.

01:52 <cyrozap> I also want to make sure my projects have a high "bus factor", to make it easier for others to help and to reduce the chances that any work is unnecessarily duplicated.

01:56 <macc24> cyrozap: is this mediatek scp reverse engineering stuff?

01:56 <cyrozap> I've seen far too many interesting RE projects where it was just one person working alone, and then when they stopped for whatever reason (burnout, legal harassment, life stuff, etc.), there was basically no progress for years and years.

01:58 <cyrozap> macc24: Yes, though the MD32 is used in several places in MediaTek SoCs (VPU, sensor hub, one of the modem DSP cores).

01:59 <macc24> cyrozap: that's interesting, which SoC are you targeting?

02:02 <alyssa> cyrozap: "one format per opcode/bit pattern" Try Bifrost :<

02:03 <alyssa> Bifrost _does not have opcodes_

02:03 <alyssa> I cannot begin to explain how painful this makes things

02:07 <cyrozap> alyssa: What do you mean? Surely there's some way the processor identifies different instructions?

02:08 <cyrozap> Like, maybe the bits aren't always set in the same place, but they need to be set somewhere. Unless it's context-based or something?

02:08 <alyssa> It's bit patterns

02:10 <alyssa> cyrozap: See https://cgit.freedesktop.org/mesa/mesa/plain/src/panfrost/bifrost/ISA.xml

02:10 <alyssa> specifically the exact and mask fields

02:10 <alyssa> where we match on "instruction bits & mask = exact", up to ambiguitty

02:11 <alyssa> https://cgit.freedesktop.org/mesa/mesa/tree/src/panfrost/bifrost/gen_disasm.py#n42

02:11 <alyssa> ^^ That seems to work afaik

02:12 <cyrozap> macc24: Well, pretty much any MediaTek SoC that supports LTE (I don't care about the pre-LTE SoCs). My current "favored" targets are the MT6737 (used in the Orange Pi 4G-IoT), the MT6797/Helio X20 (used in the 96boards MediaTek X20 development board), and the MT8183/MT6771/Helio P60 (used in the 2019 Amazon Fire HD 10, the Lenovo Chromebook Duet, and several other ChromeOS devices).

02:14 <macc24> cyrozap: i have linux running semi-usably on duet, but sound on internal speakers is missing and there are some panfrost glitches

02:15 <cyrozap> alyssa: That doesn't seem so bad--that's basically how this ISA works (or at least how I'm decoding it): https://paste.debian.net/hidden/98bba517/

02:21 <macc24> speaking of panfrost glitches, my screen froze and started doing weird things, this time i could switch to another tty from sway. it's on mesa git-2c9e7f73ad, some dmesg output, as far as i could get: https://bpa.st/BBMA

02:28 <cyrozap> alyssa: Yeah, looking more at the Bifrost XML, it seems similar to how this MD32's instructions are encoded. It's basically just a prefix code, so you sort the instructions by the number of mask bits, then go down the list from most mask prefix bits to least mask prefix bits, and return whatever instruction matches first. Assuming the hardware is deterministic, the software decoder shouldn't end up too

02:28 <cyrozap> terrible.

02:37 <cyrozap> Then again, maybe I'm missing something. I really only care about implementing a decoder in Ghidra, and maybe adding support to GCC, so I might not be hitting the pain points you are.

02:43 <alyssa> cyrozap: Meh, it's just *annoying*

02:44 <alyssa> And there are a bunch of weird edge cases, maybe to make the assembly seem nicer without affecting the hardware at the expense of the encoding itself not making sense

02:45 <alyssa> (The various BRANCH instructions are the biggest offenders..)

02:49 <alyssa> Once I hid everything behind the XML/Python the pain points went away. But I never appreciated how great 8-bit opcodes were :p

04:47 <kinkinkijduet> oh dear, im afraid i mightve started enjoying using chromeos on this duet

09:50 <raster> oh this is new

09:51 <raster> earlyz bug still there and now... the "early z bug areas" are coming up transparent rather than the glclear color (a darkish grey)

09:52 <raster> http://www.enlightenment.org/ss/e-5fc8b569f31941.17996297.jpg

09:53 <raster> http://www.enlightenment.org/ss/e-5fc8b59b4ef6f0.57866844.jpg

10:10 <bbrezillon> raster: on Bifrost?

10:12 <raster> thats midgard actually

10:12 <raster> i believe birfost was also broken last i checked

10:12 <raster> but i just rebased on mainline mesa and am building now

10:13 <raster> but interesting that the bug now is manifesting differently

10:13 <raster> with alpha :)

12:41 <raster> and on bifrost the bug is there .. but alpha is full not 0. so bug is there like it was originally. so midgard got some new funtimes added to the bug

13:28 <kinkinkijduet> x86 computer officially dead, looks like this duet is gonna be my main driver for a bit

13:29 <HdkR> neat

13:29 <kinkinkijduet> not super neat, had unpublished code and an almost finished album on it

13:30 <HdkR> Always back up your stuff

13:30 <HdkR> always always

13:31 <macc24> kinkinkijduet: dead as in?

13:31 <kinkinkijduet> cant use cloud backups for productions due to not having a good one, and the rats that killed it also killed my local backups

13:32 <kinkinkijduet> macc24 rats nested in the cable basement and under the gpu, was just woken up by digging noises, followed by a loud CLAP, followed by no more digging noises

13:33 <kinkinkijduet> investigated, they got into the psu somehow and shorted it with their bodies

13:33 <HdkR> Guess you just need new PSU hardware to bring back the drive data then?

13:33 <macc24> how the hell do you get rats inside computers?

13:34 <kinkinkijduet> macc24 the underside of this computer was protected by mesh and plastic for "configurability"

13:34 <macc24> oh

13:35 <kinkinkijduet> hdkr i inspected it, they also tore up the mobo, gpu, and heatsinks

13:35 <HdkR> Also, I finally have a 321 backup solution in place. B2 is actually not that bad

13:35 <macc24> the hdd should be fine

13:35 <kinkinkijduet> drives are probably fine but the kicker is i dont have another computer to put them in to retrieve data

13:36 <HdkR> Ruthless

13:36 <kinkinkijduet> so im just gonna save the drives

13:36 <macc24> cpu should be fine too

13:36 <macc24> ram hopefully too

13:37 <kinkinkijduet> this landlord has been refusing to call an exterminator for a month, and now this

13:38 <kinkinkijduet> considerinr renting-related laws here i definitely have a case to get reimbursed by him, if not out of court then by order of the court

13:40 <kinkinkijduet> big bummer though is that the total of all of the destroyed parts is only like... $1200, which while being enough that i cant afford it, is also too little to justify small claims

13:43 <macc24> rip

13:49 <raster> kinkinkijduet: now i see the use for RGB gaaaaaamer machines

13:49 <raster> you have glass panels and lights on all the time to see in your computer to look for the rats :)

23:04 <br> robmur01_: I don't plan to copy io-pgtable from linux:) For SMMU support I reused standard arm64 page management code in freebsd

23:04 <br> http://svn.freebsd.org/base/head/sys/arm64/arm64/pmap.c

23:05 <br> robmur01_: see pmap_senter() ... etc

23:05 <br> robmur01_: It looks like Mali GPU uses the same format ?

23:07 <br> I see a small difference however, e.g. PTE_TYPE_PAGE is not used in Mali case, and even last level of page tables uses BLOCK type ?

23:09 <br> Also I see you removed ARM_LPAE_PTE_AF bit for Mali pte