Running in no mmu linux ?

[sivansh11]

I noticed that this project can run on elks, would running on no mmu linux be possible ? I have not been able to get it to work, tho I am targeting a non supported environment (rv64ima).

[ghaerr]

I'm sure you can port Microwindows to run on no mmu linux, but you may have to write a screen driver for the specific platform you're running on. The code base is very portable, can run on bare hardware, and can be configured to run without a C library, however the system is dependent on specific drivers for keyboard, mouse and graphics display (screen) present.

I have not been able to get it to work,

More information would be needed in order to comment further on that.

[sivansh11]

can run on bare hardware

Can you elaborate, so does it come with a file system, so is it like a mini os in itself ?

More information would be needed in order to comment further on that.

Yeah, so the issue is with fork function call, since I am targeting uclinux (no mmu linux), there is no fork system call, and so it wont compile.

/microwindows/src/nanox/client.c: In function ‘GrOpen’:
/microwindows/src/nanox/client.c:330:29: error: implicit declaration of function ‘fork’ [-Wimplicit-function-declaration]
  330 |                         if (fork() == 0) {
      |                             ^~~~

I based my config on config.linux-fb (since I do have /dev/fb0, I am assuming this version targets it ?), I use riscv64-buildroot-linux-uclibc-gcc as my COMPILER in Arch.rules.
Assuming it creates an executable, I need to add -elf2flt=-r in CFLAGS since I can only run bflt binaries, not elf binaries.

I guess my question is what all needs to be modified to make it compatible with uclinux, maybe adding a new rule/option to use clone/posix_spawn over fork ? (I dont think vfork will work here since it suspends the parent process), the option can be similar to HAVE_SHAREDMEM_SUPPORT (no mmu means no shared memory).

[rofl0r]

since I am targeting uclinux (no mmu linux), there is no fork system call, and so it wont compile.

posix_spawn(3p) is no-MMU compatible and could be used instead if the purpose is launching other processes (it won't work for other purposes like daemonizing).

[ghaerr]

Hello @sivansh11,

The particular code you're referencing with fork is just a convenience function to automatically start the Nano-X server and isn't at all required for proper functioning. You can see the code is guarded above with AUTO_START_SERVER. To keep moving forward, just turn this feature off by setting the corresponding line in include/mwconfig.h:

#define AUTO_START_SERVER   0   /* =1 to automatically start Nano-X on GrOpen */

I based my config on config.linux-fb (since I do have /dev/fb0, I am assuming this version targets it ?),

Yes, that should work, but you may have to fiddle with config depending on exactly how your hardware and system is configured. Hopefully, the Linux framebuffer driver is fully implemented, in which case the screen driver in drivers/scr_fb.c will auto-configure to the SCREEN_PIXTYPE you've got set in config.

That all needs to be modified to make it compatible with uclinux,
I use riscv64-buildroot-linux-uclibc-gcc as my COMPILER in Arch.rules.

Feel free to edit Arch.rules as well as config in order to get the compiler defines that might be required to keep the compilation moving forward. We can straighten out a final port after you get it up and running.

so does it come with a file system, so is it like a mini os in itself ?

No, not at all. The project can be configured to remove many features that may not be found in the external environment, including running on bare hardware. In the latter case, the project doesn't support loading images from files, for instance, since there are no "files" on bare hardware. All of this is controlled in include/mwconfig.h, Arch.rules, and config.

posix_spawn(3p) is no-MMU compatible and could be used instead

That can be added later, should you want server auto-start. For embedded environments, it's never needed. For extremely small environments without UNIX sockets, you can set LINK_APP_INTO_SERVER=y which will create a single executable of a combined app and nano-X server.

[sivansh11]

I need to add -elf2flt=-r in CFLAGS

I was wrong here, I need pass a bunch of flags to both LDFLAGS and CFLAGS

CFLAGS=-fPIC
LDFLAGS=-pie -Wl,-elf2flt=-r -static

Aside from this, I modified Arch.rules

TOOLSPREFIX = ~/dev/buildroot/output/host/bin/riscv64-buildroot-linux-uclibc-

and set AUTO_START_SERVER 0

I got it to compile and output bflt binary for nano-X

on running, I am not getting any output or warning, I am not sure if the issue is with my environment (I am writing a riscv emulator) or if this is expected output ?

[ghaerr]

No, that doesn't look very good - nano-X normally clears the screen to black on startup. You might try setting LINK_APP_INTO_SERVER=y in config and remaking everything. This will compile the server into each application, so that when you run an application it doesn't depend on any UNIX sockets or communication with the nano-X server in order to run.

This will likely result in the same thing, in which case you'll have to insert printf() into the driver/scr_fb.c to see how far through the fb_open() function occurs. This is because I have no idea if the default screen driver is compatible with your system. In general, drivers/scr_fb.c uses /dev/fb0 but that also depends on what kernel FB driver you've got setup and compiled in. All that gets complicated and answers for that are found on Linux FB discussions.

Is this a desktop system? I don't hardly have any information to help you with.

[sivansh11]

Is this a desktop system? I don't hardly have any information to help you with.

No, I am writing a riscv emulator, I am adding things as I need them. I compiled my Linux kernel with simple fb drivers

[ghaerr]

Cool. RISC V seems like a nice architecture for that. In that case, I would suggest looking at whether the address returned from the ioctl() in the fb_open routine gets accessed - Nano-X writes directly to that address, so you should quickly be able to determine whether your framebuffer is being written or not in your emulator.

[ghaerr]

In order to test your FB driver and emulated frameuffer, there are simpler projects, such as https://github.com/aligrudi/fbpdf that might be useful. Compile it on a desktop, then get it working on your emulator. Then Nano-X should run.

[rofl0r]

fbpdf relies on mupdf library, which in turn relies on a plethora of other libraries, so it's probably not that easy to set it up. otoh, gnuboy has a very simple framebuffer driver and no external deps (if one disables the audio driver and picks fb backend) so it might be easier to set up. https://github.com/rofl0r/gnuboy/ . the only external thing one needs to test is a gameboy rom.

[ghaerr]

Also, you can use dd data directly to the framebuffer, if it's in the same RGBA etc format as the framebuffer: dd if=X of=/dev/fb0. Writing very simple C programs is also possible to write all bits 1 for WHITE and all 0 for black, etc for the size of the framebuffer.

[sivansh11]

I can confirm that my framebuffer works

cat /dev/urandom > /dev/fb0

writes random pixels to the screen

I am not able to get fbpdf to work because compiling mupdf is giving me some troubles, I got fbgnuboy to compile but running it is giving me a segmentation fault (which is honestly very confusing, tho I believe this is a different issue and not related to fb)

I also tried LINK_APP_TO_SERVER
I tried running nxclock, similar issue as before

gets stuck
I dont think it is ever accessing the region of memory where the framebuffer is mapped.

I have to mention that I dont have a working keyboard setup in my emulator, right now I am kinda "hacking" it by rerouting uart to tty1, do you think this could be an issue ?

[sivansh11]

here is me writing random colors to screen

[ghaerr]

I am kinda "hacking" it by rerouting uart to tty1, do you think this could be an issue ?

Set KEYBOARD=NOBKD and MOUSE=NOMOUSE in config, could be hanging in the keyboard driver.

[sivansh11]

Set KEYBOARD=NOBKD and MOUSE=NOMOUSE in config, could be hanging in the keyboard driver.

doing so gives me a bunch of undefined errors

/home/sivansh/dev/buildroot/output/host/riscv64-buildroot-linux-uclibc/bin/ld.real: /home/sivansh/dev/microwindows/src/lib/libnano-X.a(srvevent.o): in function `GsDeliverKeyboardEvent':
srvevent.c:(.text+0x6f8): undefined reference to `kbddev'
/home/sivansh/dev/buildroot/output/host/riscv64-buildroot-linux-uclibc/bin/ld.real: /home/sivansh/dev/microwindows/src/lib/libnano-X.a(srvevent.o): in function `GsDeliverRawMouseEvent':
srvevent.c:(.text+0x1554): undefined reference to `mousedev'
/home/sivansh/dev/buildroot/output/host/riscv64-buildroot-linux-uclibc/bin/ld.real: /home/sivansh/dev/microwindows/src/lib/libnano-X.a(srvevent.o): in function `GsHandleMouseStatus':
srvevent.c:(.text+0x1684): undefined reference to `mousedev'
/home/sivansh/dev/buildroot/output/host/riscv64-buildroot-linux-uclibc/bin/ld.real: /home/sivansh/dev/microwindows/src/lib/libnano-X.a(devmouse.o): in function `GdCloseMouse':
devmouse.c:(.text+0x0): undefined reference to `mousedev'
/home/sivansh/dev/buildroot/output/host/riscv64-buildroot-linux-uclibc/bin/ld.real: /home/sivansh/dev/microwindows/src/lib/libnano-X.a(devmouse.o): in function `GdGetButtonInfo':
devmouse.c:(.text+0x10): undefined reference to `mousedev'
/home/sivansh/dev/buildroot/output/host/riscv64-buildroot-linux-uclibc/bin/ld.real: /home/sivansh/dev/microwindows/src/lib/libnano-X.a(devmouse.o): in function `GdMoveMouse':
devmouse.c:(.text+0x70): undefined reference to `mousedev'
/home/sivansh/dev/buildroot/output/host/riscv64-buildroot-linux-uclibc/bin/ld.real: /home/sivansh/dev/microwindows/src/lib/libnano-X.a(devmouse.o):devmouse.c:(.text+0x1bc): more undefined references to `mousedev' follow
/home/sivansh/dev/buildroot/output/host/riscv64-buildroot-linux-uclibc/bin/ld.real: /home/sivansh/dev/microwindows/src/lib/libnano-X.a(devkbd.o): in function `GdOpenKeyboard':
devkbd.c:(.text+0x0): undefined reference to `kbddev'
/home/sivansh/dev/buildroot/output/host/riscv64-buildroot-linux-uclibc/bin/ld.real: /home/sivansh/dev/microwindows/src/lib/libnano-X.a(devkbd.o): in function `GdCloseKeyboard':
devkbd.c:(.text+0x10): undefined reference to `kbddev'
/home/sivansh/dev/buildroot/output/host/riscv64-buildroot-linux-uclibc/bin/ld.real: /home/sivansh/dev/microwindows/src/lib/libnano-X.a(devkbd.o): in function `GdGetModifierInfo':
devkbd.c:(.text+0x20): undefined reference to `kbddev'
/home/sivansh/dev/buildroot/output/host/riscv64-buildroot-linux-uclibc/bin/ld.real: /home/sivansh/dev/microwindows/src/lib/libnano-X.a(devkbd.o): in function `GdReadKeyboard':
devkbd.c:(.text+0x30): undefined reference to `kbddev'