Porting Printing to Zephyr 🖨

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: ...

This week, I put the JTAG debugging and the rest of the libcups tests on hold in favor of getting ippeveprinter (a minimal print server example) up and running on Zephyr. Generally, what I have been seeing myself doing through this process and stage of development is removing all of the parts that would not be feasible to support right now and focusing on the actual application rather than all of the tests for libraries. This is because it’s become clear to me that time is going to be scarce over the next weeks as I have finals for my summer classes and then a significantly more difficult Fall term after that. ...

This week has definitely been less straightforward than the previous weeks as I continue testing libcups and figuring out a clear path forward for what needs to be ported and what can be left out. I have continued with getting through the other tests for libcups (at least the ones relevant to the print server application), exploring mDNS Responder use in libcups, and I have also been working on getting OpenOCD debugging with my debugger board. ...

As I alluded to in my previous post, I am now back in Santa Barbara (or rather Goleta). This means I have some additional resources from my lab and professors, but also a lot of additional responsibilities from my classes, dealing with my apartment, etc. This means that I will have a smaller amount of time to work on GSoC, but I will make sure to work on the project as much as I can and continue to keep you all updated. ...

Now that midterm evaluations have come out, it is time to reflect on my experiences and the progress that I’ve made. Overall, I am proud of the progress that I have made, but I know that there is a lot more work left to do. For this week, I have been able to get a test suite running for libcups. However, there is a lot more testing to be done since libcups is a lot more complex and less self-contained than other libraries like zlib or pdfio. ...

Although libcups has been the most challenging project to port and has taken a lot longer than I initially thought, I feel like I am finally a lot closer to getting the library operational. Even though I am not quite done with getting everything prepared for compilation unlike what I said I would do earlier, I have gone through and added code for all of the parts where Mbed TLS is needed. ...