Another DSO+DMM - Zeeweii DSO3D12, claimed 120MHz/250MSps (june 2023)

[tunk]

Zeeweii - the Fnirsi have fake specs (I think the real specs are
200MSps and 30MHz) and the lowest vertical setting is 100mV/div.

[Aldo22]

I plan to buy an Oscilloscope. What is the better choice Zeeweii DSO3D12 or Fnirsi 1013D?

Firstly, I don't understand how you can compare the two.
The Zeeweii is a “scopemeter” (DMM+oscilloscope), the Fnirsi is a touchscreen oscilloscope with some oddities.
Maybe you should first ask yourself what you generally prefer..
Neither of them are serious oscilloscopes in my opinion, but I would prefer the Zeeweii as a scopemeter.
https://www.beis.de/Elektronik/FNIRSI-1013D/FNIRSI-1013D_de.html

The cheapest “complete” oscilloscope is the Hantek DSO2C10.
It is far from perfect, but offers a hundred times more than these two.
Good oscilloscopes are somewhat more expensive:
https://www.batronix.com/versand/oszilloskope/Siglent-SDS804X-hd.html

[Fungus]

I plan to buy an Oscilloscope. What is the better choice Zeeweii DSO3D12 or Fnirsi 1013D?

It's a question of what you prefer - bigger screen or better specs.

I'd get the Zeeweii.

(nb. The FNIRSI specs for bandwidth+sample rate are complete lies)

[Aldo22]

In my view, the biggest problem with Fnirsi is not even a lie. It is the 50mV/div max. sensitivity from the specifications.
I have attached an example. This is the same signal three times.
With the Fnirsi you see at most the green signal (apparently, according to the text above, not even that works) and with the Zeeweii the yellow one. The gray one is from the Hantek.
With this poor sensitivity, you simply can't see many things.

[Atlan]

Sensitivity is 100mV, 50mV is just software multiplication *2. Alternative software for 1013 does not suffer from the deadband. 1013D has a huge advantage of a touch screen, by the time you set it up on Tamagotchi oscilloscopes, with 1013 you already have the measured and stored scope.

[GSN]

What problems does the 1013D have with the touch screen?

My understanding is that those screens often go out and, in general, the whole unit seems to easily brick itself. Reviews on US Amazon marketplace are not the greatest and it's marked as a "frequently returned" item. Most people reviewing those on YouTube are still on their first month and in the honeymoon period. Although I must admit that the touchscreen interface and the features look very tempting based on the review videos. Several people also mentioned that it's not quite true to spec.

I plan to buy an Oscilloscope. What is the better choice Zeeweii DSO3D12 or Fnirsi 1013D?

From what I've read, I believe that DSO 3D12 takes better measurements than 1013D, also less chances that it will stop working.

The cheapest “complete” oscilloscope is the Hantek DSO2C10.
It is far from perfect, but offers a hundred times more than these two.
Good oscilloscopes are somewhat more expensive: Siglent[/url]

And yes, for those looking for a better primary scope for not a whole lot more, Siglent or Rigol benchtop units seem to be a better choice, but they are not as portable as handhelds and don't run on batteries, so not the best for automotive or main panel work.

[black6host]

Here's the nice thing, get the Zeeweii, figure out what you really need and if it's more then get a Siglent or Rigol bench scope.  I have both and they both have their place as mentioned above regarding battery operated and portable or more feature oriented but desk bound.

[Fungus]

Sensitivity is 100mV, 50mV is just software multiplication *2. Alternative software for 1013 does not suffer from the deadband. 1013D has a huge advantage of a touch screen, by the time you set it up on Tamagotchi oscilloscopes, with 1013 you already have the measured and stored scope.

I don't want to downplay touch screens but i'll take issue with the "tamagotchi" comment.

Zeeweii's "Auto" buttons work really well and the DSO3D12 being discussed has separate buttons for horizontal+vertical.

[Atlan]

Yes, I see that it allows you to change the channel sensitivity and time base directly with the buttons. Moreover, the buttons are labeled. Compared to the z703, it looks like it has better control.

[motoge]

 How does the +Bandwidth.-Bandwidth display in automatic measurement mode?

The following response was received from the manufacturer:

Since such waveforms are actually debatable, I recommend using cursors for measurements. Press "Shift"->"s" to open the time cursor.
For example, in the image below, it is hard to determine whether the negative pulse width is A or B. With an oscilloscope, it is really hard to judge.
width-.jpg　　

[Fungus]

 How does the +Bandwidth.-Bandwidth display in automatic measurement mode?

The following response was received from the manufacturer:

Since such waveforms are actually debatable, I recommend using cursors for measurements. Press "Shift"->"s" to open the time cursor.
For example, in the image below, it is hard to determine whether the negative pulse width is A or B. With an oscilloscope, it is really hard to judge.
width-.jpg　　

That was an "impossible" waveform. Cursors are the ONLY way to measure that.

Any serious discussion of that waveform is pointless. 

[Dmitur]

I think there are still some bitmaps for the signal generator screens that are still hiding in the firmware somewhere (unit labels like KHZ, MHZ, % symbol, etc).

Well, I've found it...  Some of the images (there are tons of different solutions for similar tasks in the firmware) are stored in a slightly compressed and menu parametrized format (still 8bpp indexed colors). That is, it is already drawn immediately with cursor colors and other things, depending on program variables. The bad thing here is that the volume of the modified image is difficult to predict, in order to fit it into the same memory area as original.

And the converter into that image format will have to be written - it is proprietary (I'll try to describe it a bit later). The attachment contains an example of the image, rendered with different cursor positions (then firmware draws digits and waveform over it). I've found 3 such images: the background of a "small" generator (as in the attachment), on/off and Hz/kHz/MHz switches (these two are different images) - of a full screen one.

[Dmitur]

I'll try to describe it a bit later

Here is drawing function code, reconstructed in some sort of pseudocode:

Code: [Select]

Draw(uint16[] Image, uint32 Mask)
{
idx = 0;
outX = 0;
outY = 0;
maxX = Image[idx++]; // image width
maxY = Image[idx++]; // image height

while (outY < maxY)
{
len = Image[idx++];
code = Image[idx++];

color0 = (code >> 6) & 31;
color1 = code & 31;
zone = (code >> 11) & 31;
baseColor = code & 255;

zoneMask = 1 << zone;

while (len != 0) // note that pixel series may be wrapped to next outY!! It is possible to fill entire rectangle with 1 pair of len/code.
{
if ((code & 32) == 0)
        {
            if (code != 65503)
                SetPixel(outX, outY, baseColor);
        }
        else
        {
            if ((zoneMask & Mask) == 0)
SetPixel(outX, outY, color0);
else
SetPixel(outX, outY, color1);
        }
        len--;

        outX++;
        if (outX == maxX)
        {
            outX = 0;

            outY++;
            if (outY == maxY)
                return;
        }
    }
}
}
There are three such images:
fls file offset size description "Mask" at call
327368 1256 Hz/kHz switch main gen (1 << FreqMultiplier)
328624 708 On/Off switch main gen 1 == On, 2 = Off
329332 3864 menu base small gen (1 << (FreqMultiplier + 16)) | (1 << CurPos)

FreqMultiplier: 0 - Hz, 1 - kHz, 2 - MHz
CurPos = 0..8: 0..4 - frequency, 5 - frequency multiplier, 6..8 - duty.


I can’t imagine how to write a viewer of, and converter to this format without writing some sort of graphic editor. 

[taligentx]

Well, I've found it...  Some of the images (there are tons of different solutions for similar tasks in the firmware) are stored in a slightly compressed and menu parametrized format (still 8bpp indexed colors). That is, it is already drawn immediately with cursor colors and other things, depending on program variables. The bad thing here is that the volume of the modified image is difficult to predict, in order to fit it into the same memory area as original.

And the converter into that image format will have to be written - it is proprietary (I'll try to describe it a bit later).
(...)
I can’t imagine how to write a viewer of, and converter to this format without writing some sort of graphic editor. 

Wow nice job finding those, it's quite the hodgepodge of formats and compression schemes. For myself, I don't see the compressed images as having any serious issues that would warrant the effort to change them. Even if the firmware gets to a compilable state (this would be amazing!) and can have different memory sizes, it would still probably be low priority to rework these.

Also I'm sure you've already mapped this, but the boot logo is at offset 0x24D1C, 1792 bytes. It's also RLE compressed with a color index to the color palette that you found. I've added a script (tools/zrle2bmp.py) that will convert it to a standard RGB565 bitmap:

Code: [Select]

'''
zrle2bmp.py 1.0 - Convert Zeeweii compressed images to bitmap

Zeeweii DSO3D12 firmware contains both uncompressed and compressed image data. This script
converts Zeeweii's custom RLE compression to a standard RGB565 bitmap, keeping the original
color palette (offset 0x73F6C, 448 bytes).

Requirements: pip install pillow

Compressed image data format:
  - Header
    - Bytes 0-1: width
    - Bytes 2-3: height
  - Image data
    - Bytes 0-1: pixel run length
    - Bytes 2-3: color index from Zeeweii color palette

Compressed images:
  - Boot logo (offset 0x24D1C, 1792 bytes)

Offsets and sizes are based on firmware 3.0.6-III.
'''

import struct
import sys
from PIL import Image


# Zeeweii firmware color palette, RGB565
DSO3D12_PALETTE = [0x0000, 0xFFFF, 0xF800, 0x07E0, 0x001F, 0xFFE0, 0xF81F, 0x07FF, 0xCE59, 0xFE41,
                   0x2945, 0x630C, 0xA514, 0xD69A, 0x0969, 0x228E, 0x0250, 0x1D3A, 0xF81F, 0xFA80]


def convert_zrle(input_file, output_file=None):
    with open(input_file, "rb") as f:
        data = f.read()
   
    # Read width (2 bytes) and height (2 bytes), little-endian
    width = struct.unpack_from("<H", data, 0)[0]
    height = struct.unpack_from("<H", data, 2)[0]
    print(f"Decoding {width}x{height} image...")
   
    pixels = []
    idx = 4  # Start after width/height
   
    while idx < len(data):
        run_length = data[idx]
        color_index = data[idx + 1]
        idx += 2
       
        if color_index >= len(DSO3D12_PALETTE):
            print(f"Warning: Color index {color_index} out of bounds, using black.")
            color = 0x0000
        else:
            color = DSO3D12_PALETTE[color_index]
       
        pixels.extend([color] * run_length)
   
    # Verify pixel count
    if len(pixels) != width * height:
        print(f"Warning: Pixel count mismatch! Expected {width * height}, got {len(pixels)}.")
        pixels = pixels[:width * height]
   
    # Convert to raw RGB565 bytes
    bmp_data = b"".join(struct.pack("<H", p) for p in pixels)
   
    if output_file is None:
        output_file = input_file.rsplit('.', 1)[0] + ".bmp"
   
    # BMP header
    file_size = 72 + len(bmp_data)
    bmp_header = struct.pack(
        "<2sIHHIIiiHHIIIIIIIIII",
        b"BM", file_size, 0, 0, 70, 56, width, -height, 1, 16, 3, len(bmp_data),
        2835, 2835, 0, 0, 0xF800, 0x07E0, 0x001F, 0x0000)

    with open(output_file, "wb") as f:
        f.write(bmp_header)
        f.write(bmp_data)
   
    print(f"Image saved as {output_file}")


if __name__ == "__main__":
    if len(sys.argv) < 2:
        print("Usage: python3 zrle2bmp.py <input_file> [output_file]")
        sys.exit(1)
   
    input_filename = sys.argv[1]
    output_filename = sys.argv[2] if len(sys.argv) > 2 else None
   
    convert_zrle(input_filename, output_filename)

I've also updated the mod.fls - some new graphics, changed the persistence label to 3s (measured it), etc: https://github.com/taligentx/ZeeTweak

[taligentx]

Is there any difference in DSO3D12 units from Zeewei versus other sellers? I prefer Amazon and it seems like all units currently listed there are sold by other companies besides the manufacturer.

Zeeweii made hardware changes in the -III generation (for example, switching the FPGA from AG1KLPQ48 to AG32VF303), so older hardware (with v1.x firmware) is not compatible with the current v3.x-III firmware. The same happened with the DSO2512G.

If buying from a third-party seller, I would ask the seller if the scope is the current generation/firmware (just to have something in writing) and buy from a platform with a good return policy in case you get old stock.

[taligentx]

I've (not sure about legal status though) have disassembled firmware and discover it alot (not too difficult but labor-intensive work and still at square one).

Can you elaborate a bit on this? Process, tools, goals (any particular features you're looking to implement, etc). Disassembling/decompiling is such a useful skill, it'd be great to hear more about it.

I've been poking around just to get more familiar, but for example I've run into issues even at the first steps to disassemble c-sky. My notes so far:

• objdump (XuanTie): their csky-elfabiv2-tools-x86_64-*.tar.gz archives seem to have the only version of objdump that actually interprets both 16 and 32-bit instructions.
  
  • The W806 chip uses the XT804 core but this processor isn't explicitly listed in objdump --help.  ck800, ck803, ck805, ck807, ck810 all produce identical dumps, ck801/ck802 produce incorrect dumps. This GCC patch note is a handy overview of the variants, I used ck803 and attached the dump to this post.
  • Note: it's now possible to use an email address to download, many websites state that a domestic China mobile phone number is required but this is no longer the case.
• objdump (original): c-sky support is upstreamed and I've built the latest binutils with the target set to csky but objdump isn't handling 32-bit instructions at all.
  
  • Same issue noted on stackoverflow - the poster asked about this everywhere (stackoverflow, sourceware mailing list, c-sky github) and didn't get an answer. I felt their pain, reminds me of this XKCD comic.
• Ghidra + ghidra_csky plugin: claims to support the v2 ISA but doesn't correctly interpret some instructions as being 32-bit, the logic to detect this is simple so it's a little strange to have this issue.
• Rizin: supports c-sky as an mcore derivative, checked it briefly out in Cutter.
• IDA: doesn't support c-sky as far as I can tell

Also a few notes for wishlist features - if nothing else, to send to Zeeweii in case there's a non-zero chance that they'll keep working on the firmware:

• Serial data interface - there's no native USB like the DSO2512G but I've been flashing through the USB/serial chip at 2Mbit/s reliably so UART may be quick enough for some realtime data. If the number of UARTs is a constraint, may be possible to reallocate (choose UART between external or the voice chip, etc).
• DMM graphing - seeing DMM values over time would be useful, I'm a little surprised this isn't a more common feature on the 3-in-1 type scope meters.
• CH2 initial position - should be zeroed like CH1 but Zeeweii intentionally places CH2 a little higher when first enabled so you can see that it's there. It gets placed into normal position if you hit Auto after enabling CH2 but still counter-intuitive because the measurements are still correct as though the signal is centered even while the display is offset. This actually is already implemented by @timschuerewegen on the DSO2512G.
  
• Saved waveforms - move the image counter, currently obscures cursor measurements.  Could put it over the battery icon.

Edit: should probably actually attach the file

[Dmitur]

Also I'm sure you've already mapped this, but the boot logo is at offset 0x24D1C

No, I don't. Another different format... Interesting. But how did You find this logo picture, without knowledge how it is decoded?!

Process, tools, goals

I've started from this topic: https://reverseengineering.stackexchange.com/questions/14596/c-sky-cpu-reverse-engineering. And don't remember details - I made a lot of attempts and finally got a little confused. I think, it was the "objdump -D -b binary -m csky file.bin" line, with image1 input file, that worked. After getting the listing I focused on it. I think my listing is not ideal - sometime it looks very strange (worse, I couldn't find the full c-sky ISA manual, and the document I've found doesn't have all the commands which I see in the listing). But for the most part the text is understandable - enough for me, I didn't mean to get too deep into it.

A great help in disassembling is the fact that many subroutines contain a commands to load constants from program memory (lrw) - and these constants are most often located immediately after corresponding subroutine (since lrw command have pc relative form). So, code looks like this (from your listing):

Code: [Select]

801b3c8: 1050      lrw      r2, 0x2001dca8 // 0x801b408 - load const 0x2001dca8 from address 0x801b408
...
 801b3d2: 102f      lrw      r1, 0x2001a124 // 0x801b40c - load const 0x2001a124 from address 0x801b40c
...
 801b404: 783c      jmp      r15 // subroutines returns with "jmp r15". And "pop" instruction (I didn't read the manual carefully :-[ )
 801b406: 0000      bkpt // padding word - not a command actually, aligns constant block to dword address margin
 801b408: dca82001 st.w      r5, (r8, 0x4) // not a code, it is referenced at address 801b3c8 as a const. Least word first.

 801b40c: a124      st.b      r1, (r1, 0x4) // next two lines are not a code again, actually it is dword constant
 801b40e: 2001      addi      r0, 2 // referenced from 801b3d2
----------------------------
next_func:
 801b410: 14d2      push      r4-r5, r15 // subroutines often begins with push, but not always.
Sometimes large subroutine contains such a block of constants in the middle, but you can always check for the presence of a corresponding call to the subroutine with the bsr command to this address. This makes it easier to separate the listing into parts. Also, keep in mind, that most of code jumps relative to PC, but constants are referenced by absolute address. Our fls file consists of two images, the larger one (I didn't look at the smaller one at all) - Image1, our point of interest - loads in the controller at base address 0x8010400, so, for example, if some image located at offset 0x100 from image1 beginning, in code it is referenced by address 0x100 + 0x8010400 = 0x8010500. The last constant is what we should look for (so, offsets from beginning of fls file is not very convenient - you have to constantly recalculate).(Your listing is not affected by this problem) Well, and if You are interested, I can make a short list of functions whose purpose I was able to determine - this also significantly simplifies navigation in the text.

Goals... Initially I wanted to find a way to fix the graphics. But after it became clear that without recompilation it would not be possible to achieve much, and the program was written poorly and chaotically and picking at it became not so fun... I simply continued looking for graphics that had not yet been found - like the generator menu. I think I'll make an editor for this menu, anyway, and then it will probably time to stop. It's a very labor-intensive and time-consuming task, and there's no particular goal in sight, yes, You're right.

Also a few notes for wishlist features - if nothing else, to send to Zeeweii in case there's a non-zero chance that they'll keep working on the firmware:

• Serial data interface - there's no native USB like the DSO2512G but I've been flashing through the USB/serial chip at 2Mbit/s reliably so UART may be quick enough for some realtime data. If the number of UARTs is a constraint, may be possible to reallocate (choose UART between external or the voice chip, etc).
• DMM graphing - seeing DMM values over time would be useful, I'm a little surprised this isn't a more common feature on the 3-in-1 type scope meters.
• CH2 initial position - should be zeroed like CH1 but Zeeweii intentionally places CH2 a little higher when first enabled so you can see that it's there. It gets placed into normal position if you hit Auto after enabling CH2 but still counter-intuitive because the measurements are still correct as though the signal is centered even while the display is offset. This actually is already implemented by @timschuerewegen on the DSO2512G.
  
• Saved waveforms - move the image counter, currently obscures cursor measurements.  Could put it over the battery icon.

I don't think that first two of wishes achievable without Zeeweii's participation. But last two looks like they can be achieved by editing the binary code. I'll have to take a look.

Edit: should probably actually attach the file

I didn't see it at first... I like your listing. At first glance it looks better than the one I got.

I've been poking around just to get more familiar

And, I would say, taught me more than I taught you. Never heard about Cutter/Rizin (but it looks like the Cutter doesn't support c-sky for real). I'm parsing plain text listing, using Visual Studio Code just as good and fast text editor.

[birdy]

In my view, the biggest problem with Fnirsi is not even a lie. It is the 50mV/div max. sensitivity from the specifications.
I have attached an example. This is the same signal three times.
With the Fnirsi you see at most the green signal (apparently, according to the text above, not even that works) and with the Zeeweii the yellow one. The gray one is from the Hantek.
With this poor sensitivity, you simply can't see many things.

For sure 50/100mV/div is not really a good sensitivity. I agree on that. But I’m not sure are there a lot of signals where I need < 10mV/div…… and DSO3D12 is good enough for me.

[Dmitur]

• Saved waveforms - move the image counter, currently obscures cursor measurements.  Could put it over the battery icon.

Well. This counter have no fixed width (it depends of numeric values) and displayed relative to some upper-left corner - so, it is hard to put it exactly over battery icon. In original FW, coordinates of this block are [x0, y0] = [10, 18]. In attachment version relocated to [220, 0] (begins at trigger mode icon).

How to do it at your own (disclaimer for everyone: Don't do anything that you don't understand how it works or how to get things back!). There are 44 bytes in our fls (see image) three marked red - y0 coordinate (0x12 == 18), greens: 0xA == 10 == x0 coordinate, 0x9 == 10(x0) - 1(other instruction, it encoded with value, decremented by one) and 0x13 == 10(x0) + 10(space for '/' delimiter which is 10 for "large" font) - 1(value encoded decremented again). Drawing doesn't cut off at the screen borders, so you need to set the coordinates so that the text fits on the screen. Especially for y0, which should not be greater than 224.

• CH2 initial position - should be zeroed like CH1 but Zeeweii intentionally places CH2 a little higher when first enabled so you can see that it's there. It gets placed into normal position if you hit Auto after enabling CH2 but still counter-intuitive because the measurements are still correct as though the signal is centered even while the display is offset. This actually is already implemented by @timschuerewegen on the DSO2512G.

I don't understand the problem. Measurements are formed relative to the zero level. And the zero level for ch2 is slightly shifted so that the channels do not overlap. I immediately drag channels apart even more. Do you need the zero level to be set strictly to the center for both channels?

[Ricardo66]

Hello everyone.
How to check what is my current FW version?

Check version: Menu->DMM,and then long press "V(ch1)" button.

it doesn't work for me.I'm afraid I have an old version

[Toernfoernix]

Are you sure that you used the correct key sequence?
I received my Zeeweii DSO3D12 three weeks ago with firmware v3.0.6-III.
In the meantime I flashed successfully the ZeeTweak from taligentx. Many thanks !
Indeed the description of the key sequences could be a little bit ambiguous, since the outer left keys from „Stop“ to „DMM“ turn to function keys,
if the key „Menu“ is pressed.
In order to get the firmware release you should press button „Menu“ first, after that press button „DMM“ (= option „Set“ as displayed in the LCD).
You should now see the following window as depicted here: https://www.eevblog.com/forum/testgear/another-dsodmm-zeeweii-dso3d12-claimed-120mhz250msps/msg5783625/#msg5783625 - see first and second screenshot. Please note the red arrow at the "Set" option - that's important.
Finally long press the „V(ch1)" button (= lower part of the „ch1“ key) - the firmware release should be displayed.

[Ricardo66]

Thank you very much for the instructions. I was indeed pressing the wrong order of keys. I have version 3.0.6-III.

[levanking]

Hello everyone. I receive my DSO3D12 7 days ago. I have version 3.0.6-III.

[taligentx]

I've been playing around with the Ghidra-csky plugin, I was curious to see what it would take to get closer to the objdump disassembly listing. Here's a first pass at adding the missing instructions, the updated plugin is in Releases:

https://github.com/taligentx/ghidra_csky_ck804

The listing is much closer match to objdump now. Big caveat, the focus was on the listing so most of the new instructions don't have work code attached (they'll show up with a placeholder stub() in the decompiler output, also listed in Instructions.md above with a *). So far I've only filled out a few of the instructions with work code - stuff that seemed important for function boundaries and control flow (like bnezad).

Next steps are to figure out which instructions are highest priority to get better listing and decompiler output, I'm not familiar with assembly so I'm open to any and all input. There are tons of errors but it's a starting point.



Added a disassembly directory to the zeeweii repo, here's a barebones Ghidra project with the firmware disassembled (including bootloader) and memory mapped for sram, peripherals, etc. Steps: run Ghidra, install the ghidra_csky_ck804 plugin, restart and use File > Restore project with dso3d12_3.0.6_ghidra_v0.1.gar:

https://github.com/taligentx/ZeeTweak/

The memory mapping is complete overkill right now, Ghidra is showing references scattered everywhere (even in places that are supposed to be reserved) so until the disassembly and decompiler is happier I'll leave the memory as-is. The Program Tree window can set the view to just certain sections of the code. Speaking of memory, here's a firmware map:

https://github.com/taligentx/ZeeTweak/wiki/Zeeweii-DSO3D12-3.0.6-III-firmware-map

I noted the section that I suspect is the FPGA firmware, it's in a similar location as the previous gen firmware that used a different FPGA. Also, that section disassembles decently as RISC-V which would match up with the AG32VF303 MCU/FPGA.

Well. This counter have no fixed width (it depends of numeric values) and displayed relative to some upper-left corner - so, it is hard to put it exactly over battery icon. In original FW, coordinates of this block are [x0, y0] = [10, 18].

I'm amazed you found that by just looking at the assembly. Here's what Ghidra currently thinks of that section:

I think my listing is not ideal - sometime it looks very strange (worse, I couldn't find the full c-sky ISA manual, and the document I've found doesn't have all the commands which I see in the listing).

The objdump listing definitely has issues, after seeing how the Ghidra plugin works it looks flexible enough to do a better job. For the c-sky docs, I found the same issue, some missing instructions (bnezad, all DSP instructions). There's an updated ISA from Xuantie, it also has the DSP instructions (Xuantie E804 User Manual 2.0 2024):

https://github.com/taligentx/ZeeTweak/tree/main/disassembly/docs

Also translated the Winner Micro W80x manual which has the memory ranges. Neat to see stuff pointing at the peripherals like UARTs, GPIOs, etc.

[Dmitur]

Here's what Ghidra currently thinks of that section:

Oh, no. It's much easier to read, when you know what function (and its arguments) hides behind bsr 0x0123abcd. Same point in your listing:

And no, both of 0x8027400 and 0x8027320 happily returns. It's unclear, for which of two functions, Ghidra says that it doesn't return, but if it's for 0x8027320, maybe it's because of return via pop instead of jmp?

In txt file are most of the addresses I know. Some of them are not complete, there may be errors, but I hope it would be helpful.