#riscv64 — Public Fediverse posts

so I want a RPi-like RISC-V board

(don't care about the RPi form factor, the board can be larger)

PINE64 or Milk-V, or does anyone have another preference?

#RISCV #riscv64

so I want a RPi-like RISC-V board

(don't care about the RPi form factor, the board can be larger)

PINE64 or Milk-V, or does anyone have another preference?

#RISCV #riscv64

so I want a RPi-like RISC-V board

(don't care about the RPi form factor, the board can be larger)

PINE64 or Milk-V, or does anyone have another preference?

#RISCV #riscv64

so I want a RPi-like RISC-V board

(don't care about the RPi form factor, the board can be larger)

PINE64 or Milk-V, or does anyone have another preference?

#RISCV #riscv64

so I want a RPi-like RISC-V board

(don't care about the RPi form factor, the board can be larger)

PINE64 or Milk-V, or does anyone have another preference?

#RISCV #riscv64

This week in #fedora #linux, not that much, mostly background work:

• Continued on #riscv64 installers, found two new Anaconda bugs related to the automatic enablement of repositories (even if those repositories are configured to be disabled).
• Some work for CentOS containers.
• Work on making Fedora work well with #systemd 's run0. Currently this is broken for many executables with entrypoint transitions most importantly rpm, dnf, etc. I've got something working locally but it's definitely going to need some discussion with SELinux folks.
• I also started tracking (in image-builder) upstream the support for systemd-style immutable systems (https://github.com/osbuild/image-builder/issues/2662) which I've been working on for a while, the intent is to build systems according to @pid_eins's blogpost: https://0pointer.net/blog/fitting-everything-together.html).

This week in #fedora #linux, not that much, mostly background work:

• Continued on #riscv64 installers, found two new Anaconda bugs related to the automatic enablement of repositories (even if those repositories are configured to be disabled).
• Some work for CentOS containers.
• Work on making Fedora work well with #systemd 's run0. Currently this is broken for many executables with entrypoint transitions most importantly rpm, dnf, etc. I've got something working locally but it's definitely going to need some discussion with SELinux folks.
• I also started tracking (in image-builder) upstream the support for systemd-style immutable systems (https://github.com/osbuild/image-builder/issues/2662) which I've been working on for a while, the intent is to build systems according to @pid_eins's blogpost: https://0pointer.net/blog/fitting-everything-together.html).

This week in #fedora #linux, not that much, mostly background work:

• Continued on #riscv64 installers, found two new Anaconda bugs related to the automatic enablement of repositories (even if those repositories are configured to be disabled).
• Some work for CentOS containers.
• Work on making Fedora work well with #systemd 's run0. Currently this is broken for many executables with entrypoint transitions most importantly rpm, dnf, etc. I've got something working locally but it's definitely going to need some discussion with SELinux folks.
• I also started tracking (in image-builder) upstream the support for systemd-style immutable systems (https://github.com/osbuild/image-builder/issues/2662) which I've been working on for a while, the intent is to build systems according to @pid_eins's blogpost: https://0pointer.net/blog/fitting-everything-together.html).

This week in #fedora #linux, not that much, mostly background work:

• Continued on #riscv64 installers, found two new Anaconda bugs related to the automatic enablement of repositories (even if those repositories are configured to be disabled).
• Some work for CentOS containers.
• Work on making Fedora work well with #systemd 's run0. Currently this is broken for many executables with entrypoint transitions most importantly rpm, dnf, etc. I've got something working locally but it's definitely going to need some discussion with SELinux folks.
• I also started tracking (in image-builder) upstream the support for systemd-style immutable systems (https://github.com/osbuild/image-builder/issues/2662) which I've been working on for a while, the intent is to build systems according to @pid_eins's blogpost: https://0pointer.net/blog/fitting-everything-together.html).

This week in #fedora #linux, not that much, mostly background work:

• Continued on #riscv64 installers, found two new Anaconda bugs related to the automatic enablement of repositories (even if those repositories are configured to be disabled).
• Some work for CentOS containers.
• Work on making Fedora work well with #systemd 's run0. Currently this is broken for many executables with entrypoint transitions most importantly rpm, dnf, etc. I've got something working locally but it's definitely going to need some discussion with SELinux folks.
• I also started tracking (in image-builder) upstream the support for systemd-style immutable systems (https://github.com/osbuild/image-builder/issues/2662) which I've been working on for a while, the intent is to build systems according to @pid_eins's blogpost: https://0pointer.net/blog/fitting-everything-together.html).

This week in #fedora #linux I've mostly been focused on the new Anaconda web ui for ostree installers and #riscv64.

• Debugged https://bodhi.fedoraproject.org/updates/FEDORA-2026-f149ba1d39 together with @adamw.
• RISCV work to get boot.iso to work on it.
• Found a race that seems to appear on slower systems only (or systems where plymouth isn't active) regarding TTYs in Anaconda: https://github.com/rhinstaller/anaconda/pull/7253
• FESco meeting.
• A pungi release with the necessary code to enable boot.iso builds without Lorax was made.
• Started taking a look at ways to make #systemd's run0 work better with SELinux, either through adjustments to libselinux/pam_selinux and/or complimentary changes to systemd https://lists.fedoraproject.org/archives/list/[email protected]/thread/X3ZD4LF26FG3ZRW7WY26FBQQ7ZBAGVE4/

This week in #fedora #linux I've mostly been focused on the new Anaconda web ui for ostree installers and #riscv64.

• Debugged https://bodhi.fedoraproject.org/updates/FEDORA-2026-f149ba1d39 together with @adamw.
• RISCV work to get boot.iso to work on it.
• Found a race that seems to appear on slower systems only (or systems where plymouth isn't active) regarding TTYs in Anaconda: https://github.com/rhinstaller/anaconda/pull/7253
• FESco meeting.
• A pungi release with the necessary code to enable boot.iso builds without Lorax was made.
• Started taking a look at ways to make #systemd's run0 work better with SELinux, either through adjustments to libselinux/pam_selinux and/or complimentary changes to systemd https://lists.fedoraproject.org/archives/list/[email protected]/thread/X3ZD4LF26FG3ZRW7WY26FBQQ7ZBAGVE4/

This week in #fedora #linux I've mostly been focused on the new Anaconda web ui for ostree installers and #riscv64.

• Debugged https://bodhi.fedoraproject.org/updates/FEDORA-2026-f149ba1d39 together with @adamw.
• RISCV work to get boot.iso to work on it.
• Found a race that seems to appear on slower systems only (or systems where plymouth isn't active) regarding TTYs in Anaconda: https://github.com/rhinstaller/anaconda/pull/7253
• FESco meeting.
• A pungi release with the necessary code to enable boot.iso builds without Lorax was made.
• Started taking a look at ways to make #systemd's run0 work better with SELinux, either through adjustments to libselinux/pam_selinux and/or complimentary changes to systemd https://lists.fedoraproject.org/archives/list/[email protected]/thread/X3ZD4LF26FG3ZRW7WY26FBQQ7ZBAGVE4/

This week in #fedora #linux I've mostly been focused on the new Anaconda web ui for ostree installers and #riscv64.

• Debugged https://bodhi.fedoraproject.org/updates/FEDORA-2026-f149ba1d39 together with @adamw.
• RISCV work to get boot.iso to work on it.
• Found a race that seems to appear on slower systems only (or systems where plymouth isn't active) regarding TTYs in Anaconda: https://github.com/rhinstaller/anaconda/pull/7253
• FESco meeting.
• A pungi release with the necessary code to enable boot.iso builds without Lorax was made.
• Started taking a look at ways to make #systemd's run0 work better with SELinux, either through adjustments to libselinux/pam_selinux and/or complimentary changes to systemd https://lists.fedoraproject.org/archives/list/[email protected]/thread/X3ZD4LF26FG3ZRW7WY26FBQQ7ZBAGVE4/

This week in #fedora #linux I've mostly been focused on the new Anaconda web ui for ostree installers and #riscv64.

• Debugged https://bodhi.fedoraproject.org/updates/FEDORA-2026-f149ba1d39 together with @adamw.
• RISCV work to get boot.iso to work on it.
• Found a race that seems to appear on slower systems only (or systems where plymouth isn't active) regarding TTYs in Anaconda: https://github.com/rhinstaller/anaconda/pull/7253
• FESco meeting.
• A pungi release with the necessary code to enable boot.iso builds without Lorax was made.
• Started taking a look at ways to make #systemd's run0 work better with SELinux, either through adjustments to libselinux/pam_selinux and/or complimentary changes to systemd https://lists.fedoraproject.org/archives/list/[email protected]/thread/X3ZD4LF26FG3ZRW7WY26FBQQ7ZBAGVE4/

It took a long time, but our #riscv64 builder managed to finish building the community packages. At the worst, it had a backlog of more than 800 packages, but it managed to churn along the last couple of weeks.

We had it running on a HiFive P550 for a while. Even though it had faster cores, we had to move it back to the MilkV Pionieer.

We're trying some other riscv64 systems as well, to see if they serve as better builders.

#AlpineLinux

It took a long time, but our #riscv64 builder managed to finish building the community packages. At the worst, it had a backlog of more than 800 packages, but it managed to churn along the last couple of weeks.

We had it running on a HiFive P550 for a while. Even though it had faster cores, we had to move it back to the MilkV Pionieer.

We're trying some other riscv64 systems as well, to see if they serve as better builders.

#AlpineLinux

It took a long time, but our #riscv64 builder managed to finish building the community packages. At the worst, it had a backlog of more than 800 packages, but it managed to churn along the last couple of weeks.

We had it running on a HiFive P550 for a while. Even though it had faster cores, we had to move it back to the MilkV Pionieer.

We're trying some other riscv64 systems as well, to see if they serve as better builders.

#AlpineLinux

It took a long time, but our #riscv64 builder managed to finish building the community packages. At the worst, it had a backlog of more than 800 packages, but it managed to churn along the last couple of weeks.

We had it running on a HiFive P550 for a while. Even though it had faster cores, we had to move it back to the MilkV Pionieer.

We're trying some other riscv64 systems as well, to see if they serve as better builders.

#AlpineLinux

It took a long time, but our #riscv64 builder managed to finish building the community packages. At the worst, it had a backlog of more than 800 packages, but it managed to churn along the last couple of weeks.

We had it running on a HiFive P550 for a while. Even though it had faster cores, we had to move it back to the MilkV Pionieer.

We're trying some other riscv64 systems as well, to see if they serve as better builders.

#AlpineLinux

I'm missing EC_fml13v01_20241227_v1.0.17.bin for the #deepcomputing #deepcomputingRiscVMainboard #riscv64

The original links is now 404 (meh, not nice) and I cannot find thie file on github anywhere.

Also filed as https://github.com/DC-DeepComputing/Framework/issues/51

I'm missing EC_fml13v01_20241227_v1.0.17.bin for the #deepcomputing #deepcomputingRiscVMainboard #riscv64

The original links is now 404 (meh, not nice) and I cannot find thie file on github anywhere.

Also filed as https://github.com/DC-DeepComputing/Framework/issues/51

I'm missing EC_fml13v01_20241227_v1.0.17.bin for the #deepcomputing #deepcomputingRiscVMainboard #riscv64

The original links is now 404 (meh, not nice) and I cannot find thie file on github anywhere.

Also filed as https://github.com/DC-DeepComputing/Framework/issues/51

I'm missing EC_fml13v01_20241227_v1.0.17.bin for the #deepcomputing #deepcomputingRiscVMainboard #riscv64

The original links is now 404 (meh, not nice) and I cannot find thie file on github anywhere.

Also filed as https://github.com/DC-DeepComputing/Framework/issues/51

I'm missing EC_fml13v01_20241227_v1.0.17.bin for the #deepcomputing #deepcomputingRiscVMainboard #riscv64

The original links is now 404 (meh, not nice) and I cannot find thie file on github anywhere.

Also filed as https://github.com/DC-DeepComputing/Framework/issues/51

This took me quite a bit of time, but I managed to boot postmarketOS on a currently unsupported devboard (commonly available for €25-30 where I live).

Little bit proud, but it's not a proper port yet, I ripped the kernel and other parts of the pre-init bootchain (fip.bin, u-boot, ...) from a pre-made Debian image for that device. I have a (mostly working) APKBUILD for that device's userland though. :)

#postmarketos #linux #milkv #riscv64

This took me quite a bit of time, but I managed to boot postmarketOS on a currently unsupported devboard (commonly available for €25-30 where I live).

Little bit proud, but it's not a proper port yet, I ripped the kernel and other parts of the pre-init bootchain (fip.bin, u-boot, ...) from a pre-made Debian image for that device. I have a (mostly working) APKBUILD for that device's userland though. :)

#postmarketos #linux #milkv #riscv64

This took me quite a bit of time, but I managed to boot postmarketOS on a currently unsupported devboard (commonly available for €25-30 where I live).

Little bit proud, but it's not a proper port yet, I ripped the kernel and other parts of the pre-init bootchain (fip.bin, u-boot, ...) from a pre-made Debian image for that device. I have a (mostly working) APKBUILD for that device's userland though. :)

#postmarketos #linux #milkv #riscv64

This took me quite a bit of time, but I managed to boot postmarketOS on a currently unsupported devboard (commonly available for €25-30 where I live).

Little bit proud, but it's not a proper port yet, I ripped the kernel and other parts of the pre-init bootchain (fip.bin, u-boot, ...) from a pre-made Debian image for that device. I have a (mostly working) APKBUILD for that device's userland though. :)

#postmarketos #linux #milkv #riscv64

This took me quite a bit of time, but I managed to boot postmarketOS on a currently unsupported devboard (commonly available for €25-30 where I live).

Little bit proud, but it's not a proper port yet, I ripped the kernel and other parts of the pre-init bootchain (fip.bin, u-boot, ...) from a pre-made Debian image for that device. I have a (mostly working) APKBUILD for that device's userland though. :)

#postmarketos #linux #milkv #riscv64

The irony: the entire RISC-V base ISA (RV64GC) is beautifully RISC: simple opcodes, fixed 32-bit instructions (+ compressed), load/store architecture, no flags, no implicit state. Then RVV comes along and throws all those principles out the window: global implicit state, microcode-like behavior, variable semantics of the same instruction.

Because vsetvli changes the semantics of all subsequent V-instructions based on the current VLEN configuration. For a JIT compiler in an Emulator and for an Emulator in general, this means having to continuously track the vtype state and react to any changes, a fundamental contradiction to the principle of statically analyzable instructions. It feels like the RISC-V Foundation sacrificed the simplicity and elegance of the RISC principle to create a powerful but extremely complex "super-SIMD" that is difficult to efficiently map in a JIT. A more traditional SIMD extension with fixed vector widths and clearly defined instruction semantics would have been much more JIT-friendly. The upcoming P extension does go in that direction, but it is primarily targeted at embedded and low-power applications rather than high-performance computing.

#riscv #riscv64 #emulation #pasriscv #object_pascal #delphi #free_pascal

The irony: the entire RISC-V base ISA (RV64GC) is beautifully RISC: simple opcodes, fixed 32-bit instructions (+ compressed), load/store architecture, no flags, no implicit state. Then RVV comes along and throws all those principles out the window: global implicit state, microcode-like behavior, variable semantics of the same instruction.

Because vsetvli changes the semantics of all subsequent V-instructions based on the current VLEN configuration. For a JIT compiler in an Emulator and for an Emulator in general, this means having to continuously track the vtype state and react to any changes, a fundamental contradiction to the principle of statically analyzable instructions. It feels like the RISC-V Foundation sacrificed the simplicity and elegance of the RISC principle to create a powerful but extremely complex "super-SIMD" that is difficult to efficiently map in a JIT. A more traditional SIMD extension with fixed vector widths and clearly defined instruction semantics would have been much more JIT-friendly. The upcoming P extension does go in that direction, but it is primarily targeted at embedded and low-power applications rather than high-performance computing.

#riscv #riscv64 #emulation #pasriscv #object_pascal #delphi #free_pascal

The irony: the entire RISC-V base ISA (RV64GC) is beautifully RISC: simple opcodes, fixed 32-bit instructions (+ compressed), load/store architecture, no flags, no implicit state. Then RVV comes along and throws all those principles out the window: global implicit state, microcode-like behavior, variable semantics of the same instruction.

Because vsetvli changes the semantics of all subsequent V-instructions based on the current VLEN configuration. For a JIT compiler in an Emulator and for an Emulator in general, this means having to continuously track the vtype state and react to any changes, a fundamental contradiction to the principle of statically analyzable instructions. It feels like the RISC-V Foundation sacrificed the simplicity and elegance of the RISC principle to create a powerful but extremely complex "super-SIMD" that is difficult to efficiently map in a JIT. A more traditional SIMD extension with fixed vector widths and clearly defined instruction semantics would have been much more JIT-friendly. The upcoming P extension does go in that direction, but it is primarily targeted at embedded and low-power applications rather than high-performance computing.

#riscv #riscv64 #emulation #pasriscv #object_pascal #delphi #free_pascal

The irony: the entire RISC-V base ISA (RV64GC) is beautifully RISC: simple opcodes, fixed 32-bit instructions (+ compressed), load/store architecture, no flags, no implicit state. Then RVV comes along and throws all those principles out the window: global implicit state, microcode-like behavior, variable semantics of the same instruction.

Because vsetvli changes the semantics of all subsequent V-instructions based on the current VLEN configuration. For a JIT compiler in an Emulator and for an Emulator in general, this means having to continuously track the vtype state and react to any changes, a fundamental contradiction to the principle of statically analyzable instructions. It feels like the RISC-V Foundation sacrificed the simplicity and elegance of the RISC principle to create a powerful but extremely complex "super-SIMD" that is difficult to efficiently map in a JIT. A more traditional SIMD extension with fixed vector widths and clearly defined instruction semantics would have been much more JIT-friendly. The upcoming P extension does go in that direction, but it is primarily targeted at embedded and low-power applications rather than high-performance computing.

#riscv #riscv64 #emulation #pasriscv #object_pascal #delphi #free_pascal

The irony: the entire RISC-V base ISA (RV64GC) is beautifully RISC: simple opcodes, fixed 32-bit instructions (+ compressed), load/store architecture, no flags, no implicit state. Then RVV comes along and throws all those principles out the window: global implicit state, microcode-like behavior, variable semantics of the same instruction.

Because vsetvli changes the semantics of all subsequent V-instructions based on the current VLEN configuration. For a JIT compiler in an Emulator and for an Emulator in general, this means having to continuously track the vtype state and react to any changes, a fundamental contradiction to the principle of statically analyzable instructions. It feels like the RISC-V Foundation sacrificed the simplicity and elegance of the RISC principle to create a powerful but extremely complex "super-SIMD" that is difficult to efficiently map in a JIT. A more traditional SIMD extension with fixed vector widths and clearly defined instruction semantics would have been much more JIT-friendly. The upcoming P extension does go in that direction, but it is primarily targeted at embedded and low-power applications rather than high-performance computing.

#riscv #riscv64 #emulation #pasriscv #object_pascal #delphi #free_pascal

It's 2026 now and time for an updated blog post for cross-compiling Chromium for RISC-V from scratch.

This blog post is much more simple compared with my previous blog post, because many RISC-V patches have been merged into Chromium mainline.

https://www.kxxt.dev/blog/cross-compile-chromium-for-riscv-2026/

#chromium #riscv #riscv64 #linux

It's 2026 now and time for an updated blog post for cross-compiling Chromium for RISC-V from scratch.

This blog post is much more simple compared with my previous blog post, because many RISC-V patches have been merged into Chromium mainline.

https://www.kxxt.dev/blog/cross-compile-chromium-for-riscv-2026/

#chromium #riscv #riscv64 #linux

It's 2026 now and time for an updated blog post for cross-compiling Chromium for RISC-V from scratch.

This blog post is much more simple compared with my previous blog post, because many RISC-V patches have been merged into Chromium mainline.

https://www.kxxt.dev/blog/cross-compile-chromium-for-riscv-2026/

#chromium #riscv #riscv64 #linux

It's 2026 now and time for an updated blog post for cross-compiling Chromium for RISC-V from scratch.

This blog post is much more simple compared with my previous blog post, because many RISC-V patches have been merged into Chromium mainline.

https://www.kxxt.dev/blog/cross-compile-chromium-for-riscv-2026/

#chromium #riscv #riscv64 #linux

I have that page about Arm cpu cores and their features.

RISC-V cpus has insane amount of extensions. I wonder when someone will make similar page about their details.

https://gpages.juszkiewicz.com.pl/arm-socs-table/arm-cpu-cores.html

#riscv64 #riscv

I have that page about Arm cpu cores and their features.

RISC-V cpus has insane amount of extensions. I wonder when someone will make similar page about their details.

https://gpages.juszkiewicz.com.pl/arm-socs-table/arm-cpu-cores.html

#riscv64 #riscv

I have that page about Arm cpu cores and their features.

RISC-V cpus has insane amount of extensions. I wonder when someone will make similar page about their details.

https://gpages.juszkiewicz.com.pl/arm-socs-table/arm-cpu-cores.html

#riscv64 #riscv

I have that page about Arm cpu cores and their features.

RISC-V cpus has insane amount of extensions. I wonder when someone will make similar page about their details.

https://gpages.juszkiewicz.com.pl/arm-socs-table/arm-cpu-cores.html

#riscv64 #riscv

I have that page about Arm cpu cores and their features.

RISC-V cpus has insane amount of extensions. I wonder when someone will make similar page about their details.

https://gpages.juszkiewicz.com.pl/arm-socs-table/arm-cpu-cores.html

#riscv64 #riscv

« Milk-V Titan : Powered by a 2 GHz UR-DP1000 octa-core RISC-V CPU, the Titan mini-ITX motherboard supports up to 64GB DIMM memory and M.2 NVMe storage (PCIe Gen4 x4), and features a PCIe Gen4 x16 slot for a graphics card or other expansion, Gigabit Ethernet, four USB 3.0 ports, a BMC, and more. »

› https://www.cnx-software.com/2026/01/12/milk-v-titan-a-329-octa-core-64-bit-risc-v-mini-itx-motherboard-with-a-pcie-gen4-x16-slot/

#RISC #RISCV #RISCV64 #MiniITX #Motherboard #OpenSource

« Milk-V Titan : Powered by a 2 GHz UR-DP1000 octa-core RISC-V CPU, the Titan mini-ITX motherboard supports up to 64GB DIMM memory and M.2 NVMe storage (PCIe Gen4 x4), and features a PCIe Gen4 x16 slot for a graphics card or other expansion, Gigabit Ethernet, four USB 3.0 ports, a BMC, and more. »

› https://www.cnx-software.com/2026/01/12/milk-v-titan-a-329-octa-core-64-bit-risc-v-mini-itx-motherboard-with-a-pcie-gen4-x16-slot/

#RISC #RISCV #RISCV64 #MiniITX #Motherboard #OpenSource

« Milk-V Titan : Powered by a 2 GHz UR-DP1000 octa-core RISC-V CPU, the Titan mini-ITX motherboard supports up to 64GB DIMM memory and M.2 NVMe storage (PCIe Gen4 x4), and features a PCIe Gen4 x16 slot for a graphics card or other expansion, Gigabit Ethernet, four USB 3.0 ports, a BMC, and more. »

› https://www.cnx-software.com/2026/01/12/milk-v-titan-a-329-octa-core-64-bit-risc-v-mini-itx-motherboard-with-a-pcie-gen4-x16-slot/

#RISC #RISCV #RISCV64 #MiniITX #Motherboard #OpenSource

« Milk-V Titan : Powered by a 2 GHz UR-DP1000 octa-core RISC-V CPU, the Titan mini-ITX motherboard supports up to 64GB DIMM memory and M.2 NVMe storage (PCIe Gen4 x4), and features a PCIe Gen4 x16 slot for a graphics card or other expansion, Gigabit Ethernet, four USB 3.0 ports, a BMC, and more. »

› https://www.cnx-software.com/2026/01/12/milk-v-titan-a-329-octa-core-64-bit-risc-v-mini-itx-motherboard-with-a-pcie-gen4-x16-slot/

#RISC #RISCV #RISCV64 #MiniITX #Motherboard #OpenSource

« Milk-V Titan : Powered by a 2 GHz UR-DP1000 octa-core RISC-V CPU, the Titan mini-ITX motherboard supports up to 64GB DIMM memory and M.2 NVMe storage (PCIe Gen4 x4), and features a PCIe Gen4 x16 slot for a graphics card or other expansion, Gigabit Ethernet, four USB 3.0 ports, a BMC, and more. »

› https://www.cnx-software.com/2026/01/12/milk-v-titan-a-329-octa-core-64-bit-risc-v-mini-itx-motherboard-with-a-pcie-gen4-x16-slot/

#RISC #RISCV #RISCV64 #MiniITX #Motherboard #OpenSource

PasRISCV now has its own local CLI debugger alongside the GDB remote server. It supports breakpoints, single-stepping, register & memory inspection, and allows simultaneous local CLI and remote GDB sessions. A public debugger API enables future graphical debugger frontends.

https://youtu.be/yznijHMKj_0

#riscv64 #riscv #emulation #pascal #object_pascal #debugger

PasRISCV now has its own local CLI debugger alongside the GDB remote server. It supports breakpoints, single-stepping, register & memory inspection, and allows simultaneous local CLI and remote GDB sessions. A public debugger API enables future graphical debugger frontends.

https://youtu.be/yznijHMKj_0

#riscv64 #riscv #emulation #pascal #object_pascal #debugger

PasRISCV now has its own local CLI debugger alongside the GDB remote server. It supports breakpoints, single-stepping, register & memory inspection, and allows simultaneous local CLI and remote GDB sessions. A public debugger API enables future graphical debugger frontends.

https://youtu.be/yznijHMKj_0

#riscv64 #riscv #emulation #pascal #object_pascal #debugger

PasRISCV now has its own local CLI debugger alongside the GDB remote server. It supports breakpoints, single-stepping, register & memory inspection, and allows simultaneous local CLI and remote GDB sessions. A public debugger API enables future graphical debugger frontends.

https://youtu.be/yznijHMKj_0

#riscv64 #riscv #emulation #pascal #object_pascal #debugger

PasRISCV now has its own local CLI debugger alongside the GDB remote server. It supports breakpoints, single-stepping, register & memory inspection, and allows simultaneous local CLI and remote GDB sessions. A public debugger API enables future graphical debugger frontends.

https://youtu.be/yznijHMKj_0

#riscv64 #riscv #emulation #pascal #object_pascal #debugger

Something is coming...

Yes, it's 4 AM right now. I've been doing this since around 1 AM.

Trust me, once it gets good, I'll properly reveal it.

It does have something to do with the #RISCV hardware I ordered recently.

I'll get somewhere with this, I promise, alright?

It may take longer than the hardware arrival, but I'll get there in the end.

#RISC #RISCV64 #Technology

Something is coming...

Yes, it's 4 AM right now. I've been doing this since around 1 AM.

Trust me, once it gets good, I'll properly reveal it.

It does have something to do with the #RISCV hardware I ordered recently.

I'll get somewhere with this, I promise, alright?

It may take longer than the hardware arrival, but I'll get there in the end.

#RISC #RISCV64 #Technology