Porting Printing to Zephyr 🖨

Project Overview The main objective of this project is to bring OpenPrinting’s open source printing stack to resource-constrained systems using the Zephyr RTOS. This is motivated by the current lack of embedded, real-time print server solutions, which could open the door to highly efficient and closely coupled print server and printer hardware development. Furthermore, the boundaries for power and resource consumption in printing would be pushed further with the elimination of the overhead of operating systems like embedded Linux. For this project, only the topic of running a print server on Zephyr is explored, but future work in hardware integration is ripe for exploration. ...

This is another short status update on PAPPL and the project in general. I have mainly spent this week modifying PAPPL source code to fit the current use case on Zephyr. The project I have does compile (although many of the allocated stacks/pools are shrunk due to the increased memory requirements). Currently, I am dealing with some issues related to thread local storage/stack pointer stuff as seen below: D: (): zsock_getaddrinfo: host: , service: 8000, hints: 0x3c5f31f0 D: (): socket: ctx=0x3fccd3f8, fd=8 I: Listening for connections on ':1012871920'. E: ** FATAL EXCEPTION E: ** CPU 0 EXCCAUSE 28 (load prohibited) E: ** PC 0x420a50ae VADDR 0xc E: ** PS 0x60c20 E: ** (INTLEVEL:0 EXCM: 0 UM:1 RING:0 WOE:1 OWB:12 CALLINC:2) E: ** A0 0x820b74e8 SP 0x3c5f3510 A2 0x3fcd3c90 A3 (nil) E: ** A4 0x3c5f34e0 A5 0x3fcd4890 A6 (nil) A7 0x4207f3e0 E: ** A8 0x820b7460 A9 0x3c5f30c0 A10 0x3fcd3c90 A11 0x3c5f34e0 E: ** A12 0x1 A13 0x1 A14 0xa0 A15 0xc E: ** LBEG 0x400556d5 LEND 0x400556e5 LCOUNT 0xfffffffc E: ** SAR 0x1e E: ** THREADPTR (nil) E: >>> ZEPHYR FATAL ERROR 0: CPU exception on CPU 0 E: Current thread: 0x3fcc22d0 (unknown) E: Halting system The main things that I have had to remove or will need to remove in the future are listed here: ...

This is a short status update on testing for libcups and PAPPL for the week (I can’t write that much since it is currently midterm season for me). Firstly, I have implemented the semaphores for sys_heap functions that I mentioned earlier. However, I have not extensively tested the new multithreaded sys_heap behavior with these semaphores. It seems like there are no current conflicts with the WiFi thread running in the external heap and the main thread interacting with the external heap at least. ...

I had to combine these two weeks into one report since I generally do not have much time to work during the first half of the week since that’s when I have to spend the most time on schoolwork (now that the academic term has fully begun). I was able to focus on testing during the last few days and have discovered some important information, and I should be able to progress to testing PAPPL relatively soon. ...

From what I could gather this week when working on ippeveprinter, it is likely not going to be running on Zephyr any time soon. The reality is that ippeveprinter is 8k lines of code without some kind of modular testbench and that it is clearly not written for embedded systems (besides embedded Linux devices, which have traits of traditional computer systems). It has also become a debugging nightmare to get through since logs are not clear as to what exactly is going wrong and there is not much comparison with regular ippeveprinter on Linux since most of the logs disappear if nothing goes wrong. Furthermore, step-through debugging is not the best when testing a real-time connection HTTP connection that can timeout. Lastly, it takes a lot of overhead time just to reset my testing setup since ippfind can often have trouble finding ippeveprinter. ...

This week has definitely had many ups and downs in terms of this project and my work now that I am officially starting my Fall quarter. Surprisingly (or unsurprisingly due to reasons I will get into), I have not had that much time to work on this project despite classes being basically nonexistent in terms of assignments (with the exception of the embedded systems course ECE 153a that makes me go into Vivado even before the first lecture). The main thing that has been taking up my time is working on a new initiative with the ACM student chapter at UCSB, which involves managing communications with much of the faculty from two departments and many meetings for event planning. ...

I had more time this week to work on and debug the DNS-SD services and functionality of ippeveprinter. I was able to figure out how to get ippeveprinter recognized as a printer by CUPS, but I’ve also had a lot more issues with processing jobs. First, I noticed that I have to load a test.conf file, or else seemingly every job will fail when running on my local machine. It turns out that the load_ippserver_attributes is very memory-intensive, and I was only able to get it to work after increasing a bunch of stack sizes in the kconfig (see source code). This means that I have only about 5% of my DRAM available for the heap, and I am also unsure if my pthread stacks are large enough to handle the HTTP functions either. ...

As I alluded to in my previous post, I did not have much time to work on ippeveprinter this week, but I did manage to figure out what was wrong before. Now, mostly DNS-SD and networking work remains to be done. As for the previous issue I faced, I figured out that it was caused by a lack of available stack memory for ippeve_main and that I actually had to malloc the stack myself since the default pthread_attr allocation method conflicts with the net management allocations for some reason (if I allocate one, the other will fail to allocate unless I set the stack size low enough). ...

Although I was not able to work very much this week, I was able to delve further into running ippeveprinter, and I also have an update on JTAG debugging. I was able to resolve the previous issues about pthreads for now, as well as most of my previous issues with debugging, but there is now a whole new suite of issues for me to deal with. ippeveprinter After running ippeveprinter in a pthread, I noticed that I would either get stuck somewhere spinning indefinitely or get the following store-prohibited error: ...

This week was mainly spent trying to figure out all of the small issues in trying to translate ippeveprinter and libcups functionality over from Linux. I’ve learned more about how Zephyr handles concepts like pthreads and how they can be a lot more difficult to deal with than on Linux. I also recently received my ESP32s3 board, so I have also been testing the application there as well. ippeveprinter Update Luckily, it seems that using the previously mentioned syscalls like pipe, dup, and execve are not entirely necessary for the functioning of ippeveprinter since those are only used to execute user-defined bash commands for incoming print jobs. However, something else has become the main problem with implementing the rest of ippeveprinter: pthreads. Since libcups uses pthread keys to manage its globals, I’ve had issues every time I’ve tried to initiate and store globals. Mainly, pthread_setspecific will return EINVAL since to_posix_thread(pthread_self()) will fail. Inside of pthread_self: ...