{"id":22787662,"url":"https://github.com/robertlipe/riscv7","last_synced_at":"2025-04-15T23:47:10.167Z","repository":{"id":46161636,"uuid":"323218803","full_name":"robertlipe/riscv7","owner":"robertlipe","description":"UNIXv7 ported to RISC-V, specifically the Longnan Nano SBC","archived":false,"fork":false,"pushed_at":"2023-03-30T05:28:35.000Z","size":4837,"stargazers_count":12,"open_issues_count":6,"forks_count":0,"subscribers_count":4,"default_branch":"main","last_synced_at":"2025-03-29T02:51:26.949Z","etag":null,"topics":["c","hacktoberfest","historic","risc-v","risc-v-assembly","unix"],"latest_commit_sha":null,"homepage":"","language":"C","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"other","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/robertlipe.png","metadata":{"files":{"readme":"README","changelog":null,"contributing":null,"funding":null,"license":null,"code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null}},"created_at":"2020-12-21T03:18:26.000Z","updated_at":"2025-03-26T22:47:49.000Z","dependencies_parsed_at":"2023-01-20T08:01:29.723Z","dependency_job_id":null,"html_url":"https://github.com/robertlipe/riscv7","commit_stats":null,"previous_names":[],"tags_count":0,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/robertlipe%2Friscv7","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/robertlipe%2Friscv7/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/robertlipe%2Friscv7/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/robertlipe%2Friscv7/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/robertlipe","download_url":"https://codeload.github.com/robertlipe/riscv7/tar.gz/refs/heads/main","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":249173060,"owners_count":21224481,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["c","hacktoberfest","historic","risc-v","risc-v-assembly","unix"],"created_at":"2024-12-12T00:59:49.033Z","updated_at":"2025-04-15T23:47:10.148Z","avatar_url":"https://github.com/robertlipe.png","language":"C","funding_links":[],"categories":[],"sub_categories":[],"readme":"This is the (not-yet working) port of UNIXv7 system to RISC-V.\n\nIt's currently targeting the GD32V as found on the Longnan Nano, a\nsuper-inexpensive ($5-ish) SBC that includes a full USB-C controller,\nincluding OTG. This makes it possible to appear as a mass storage device,\na serial port, or other USB peripherals. This is more powerful than\ndevices like the K210 or BL602 which require an external USB-\u003eSerial\nadapter that can support none of these. RISCv7 does not (yet) use any of\nthis awesomeness.\n\nThere are some remnanats in the code of me starting with the K210. That\nis a 64-bit part that has 8MB of RAM and 2 cores. While I may go back to\nthat part some day (more RAM and protected mode would be nice) I learned\nearly on that there were a lot of structures with implicit sizes that\nburst into flames with int \u003e 32 bits. In the name of focus, I went down\nto a single part.\n\nAn early design choice was to NOT design my own ABI and calling convention.\nNor did I choose to torture myself with ancient Make. Relying on a sane\nGNU make on the host is fair game. It's easy to find riscv64-gcc in\nprepackaged binaries (Mac: Homebrew. Debian has a package) where 32-bit\ntools are harder to find. The tools support 32-bit modes so the convenience\nof calling riscv32-gcc over riscv64-gcc with -march=rv32imac -mabi=ilp32 to\nget 32-bit code isn't worth it[1]. The ABI is \"whatever these tools do\". Like\nthe early UNIXes, binary compatibilty isn't a concern; I may change system\ncall numbers or visible symbols pretty much at whim.\n\nSimilarly, I've not fought a fierce battle to keep the code K\u0026R. As this\ncode is meant to be educational (it certainly has been for this author)\nmore than historical purity, familiarity with ANSI function declarations,\njudicious use of declarations, va_arg, not relying on implicit int, the\npresence of 'void', the absence of 'register' and so on are all considered\ngood taste. Indeed, especially with 64-bit being in sight, implicit int\nand such can lead to really screwy stack frames so we're just trying to\nhead that off.\n\nI started development thinking I would write ALL the code myself and not\nrely on any namby-pamby vendor code. That quickly got old. In sys/n200\n(another unfortunate naming choice) is code for the Nucleisys 200 core as\nused in the GD32V, the Gigadevice libraries for interfacing with SPI, DMA,\nand more, as well as some other third party libraries. There is evidence\nin this directory of several failed experiments with different abstractions.\n\n\nI've been happily using the SEGGER Mini EDU JTAG device. Using something\nlike Openocd with an FTDI board is probably possible, but that's what I\nstarted with.\n\nThe best way to build the kernel is to be in usr/sys/conf and run make.\nThere is a convenience script named 'upload' which does the obvious thing,\ncalling Jlink with the appropriate fiddly parameters. 'run_nano' does a\nbuild, uploads the kernel to the board, and starts a GDB server.\n\nFor debugging, there are x/ and z/ subdirectories (bad, I know...) that\nhave .gdbinits that offer convenience macros to reboot the kernel, reload\nit (via GDB), start the remote debugging, and automatically have breakpoints\non panic and other places you hope to not be. These will probably need\ncustomized to a developer's system and style.\n\nLittle attention has been given to user-space so far. I expect most of it\nwill fall into place. crt0.S for these parts is straight-forward. I just\nneed to work through things like the global for errno and the assembly\ncode that sets it, the header tension between usr/include and usr/sys/h,\nand signal handlers that need to decode interrupted instructions so that\nthe $PC can be set right. There is also the need for standardized kernel\nexception frames.\n\n\n\nStatus \u0026 Known problems:\n\nBoot is working.\n\nTimer interrupts are working.\n\nThe display is mostly working. It's too small to be really useful, but\ndisplaying interrupt ticks or enter/exit style prints can still be handy.\nThe display is NOT hooked as a console device with ANSI escape sequences\nnor is it even hooked as a serial console. It's shoved into putchar()\ninside sc.c,.\n\n\nMemory management is a mess.  The code I started from, Robert Nordier's\n386 port of UNIXv7 has some hard coded page numbers in memory layout\nin the kernel. This has proven hard to undo.\n\nThe code currently gets to the point where it trampolines the assembler\ncode to start an exec() to load and run.\n\nSometime the LCD doesn't wake properly. I think there's something missing\nin the reset sequence. As embarrassing/ridiculous as this sounds, building\nand running gd32vf103inator/examples/LonganNano will \"fix\" the display.\nOnce it's run and whacked the LCD (DMA? SPI?) once, the LCD will literally\nrun for days and across hundreds of load/run cycles.\n\nThe chip has a hardware scroll, but I cannot make it scroll in the axis it\nneeds to scroll. Horizontal scroll is not very useful in a UNIX console.\nOne possible way to implement scrolling is to define a text frame buffer\n(maybe with 8-bit color like CGA or VGA) and fully redraw the screen on\na scroll. I'm not sure if that's a good use of our memory budget.\n\nSD card support is working at a proof-of-concept level. I can open\na DOS-formattted memory card and read files and directories from it.\nI've not implemented partition table support. With SD cards being so\ncheap, I'm not sure it makes sense. More importantly, I've not implemented\nany \"real\" UNIX-level disk support. Even being a serial device attached\nto SPI, SD is so crazy fast relative to the VAX disk that I'm not sure\nthat just spin-waiting a DMA-driven interface isn't the way to go. Shimming\nthe code in tf_card.c for disk_read() and disk_write() for synchronous\nreads and writes may be OK.\n\nThere is no root filesystem created by the build process. The kernel is\njust injected into flash memory and executed. It works at a reasonable\nspeed because flash is copied to SRAM on boot. SRAM is apparently cheaper\nthan caches at this size. (!!)\n\nSegger's equivalent of ARM's Semihosting would probably be good\nto implement for debugging.\n\n[1] For more info on RISC-V embedded chains, see \n  https://riscv.org/wp-content/uploads/2015/02/riscv-software-stack-tutorial-hpca2015.pdf\n  https://github.com/riscv/riscv-gnu-toolchain\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Frobertlipe%2Friscv7","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Frobertlipe%2Friscv7","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Frobertlipe%2Friscv7/lists"}