What to be perfomed in up_earlyserialinit?
Hi all, I've been working in the serial driver. And I've got a little confused about what is to be performed in *up_earlyserialinit. * I've been looking at other chips and I noticed that the *_lowsetup *function performs almost the same of this function and the latter is called earlier than the former in* _start*.*c*. So, I am not sure what to do in *up_earlyserialinit.* Besides it*, *I also noticed that the *setup* ioctl seems not to be performed for the console. Instead of this function, the console setup is done in the *_lowsetup *function. However, both have the same responsibilities, right? Thanks in advance, Sara
Re: What to be perfomed in up_earlyserialinit?
The primary purpose of xyz_earlyserialinit() is to make the serial console available for low level debug output before the serial driver is initialized. That happens much later. That is helpful mostly for debugging. Without early initialization of the serial console, there will be no output until nx_start() and up_initialize() are called. By the way, the naming up_earlyserialinit() is incorrect. That should be called esp32_earlyserialinit() or maybe esp32_early_serialinit(). The up_ prefix is reserved and should be used ONLY for functions called from the OS. All functions called internally without esp32 logic should begin with esp32_ (or xtensa or lx6 as appropriate for the scope of the function). See https://cwiki.apache.org/confluence/display/NUTTX/Naming+of+Architecture%2C+MCU%2C+and+Board+Interfaces for a more complete explanation. up_initialize() is properly named because it is called from the OS. up_earlyserialinit() is not called from the OS and is not correctly named. On 2/10/2021 8:35 AM, Sara da Cunha Monteiro de Souza wrote: Hi all, I've been working in the serial driver. And I've got a little confused about what is to be performed in *up_earlyserialinit. * I've been looking at other chips and I noticed that the *_lowsetup *function performs almost the same of this function and the latter is called earlier than the former in* _start*.*c*. So, I am not sure what to do in *up_earlyserialinit.* Besides it*, *I also noticed that the *setup* ioctl seems not to be performed for the console. Instead of this function, the console setup is done in the *_lowsetup *function. However, both have the same responsibilities, right? Thanks in advance, Sara
Re: What to be perfomed in up_earlyserialinit?
As I said, the early serial initialization is needed for boot-up debug output. Here is a little more detail: If the serial is not initialized, then up_putc will not work. In fact, any calls to up_putc() could hang. If the serial console is the syslog debug channel, then up_putc is called from syslog under certain conditions: * Syslog output from an interrupt handler * Syslog() is called with LOG_EMERG * Syslog() is called early in the initialization (while using the g_default_channel) up_putc is also used in most very low level startup logic in the PROGRESS macro that outputs the ABCDEF that you see when booting most NuttX systems. What happens if the serial device used by up_putc is not initialized? It will certainly fail to ouput anything but could also hang on a busy wait polling an uninitialized device.
strdup & free in protected build
Hi, I think that there is the following weirdness in strdup; The function is made to allocate memory from kernel or user-space heap according to where it is used, via lib_malloc. But, there is no similar transparent way to free the memory. Normally, when using strdup, you'd simply use "free", as also instructed in linux man page. But this would, of course, in protected build always try to free it from the user-space heap. Doing this is extremely bad, as not only it doesn't free anything, it also leaves the kernel side pointer into user side heap's nodelist, and may give that to someone else. Just spent half-a-day debugging a crash because of this... Now, as long as you know where your data is, this is perhaps not a problem. It is always possible to just call either free or kmm_free (or via lib_free macro). But the strdup may be also baked into a library, or a c++ class, which is intended to be used on both sides. I wonder if there is some nice way to avoid this kind of asymmetry? br, Jukka Laitinen
RE: strdup & free in protected build
You could use lib_free()Sent from my Galaxy
