-
Notifications
You must be signed in to change notification settings - Fork 70
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Introduce serial driver for STM32F429 #64
Conversation
Hi George, we won't be able to accept this patch as it is. Here's some background on the intended future functionality of debug and debug messages in uVisor:
Solution:
I am very much interested in your opinion on my suggestion. If you like it we'll add a ticket for delegation of debug and subsequently you could move your code into a deprivileged box. |
@meriac , thanks for your information. According to your suggestion, the scenario of message printing for uVisor is very similar to interrupt handling. The total scenario could be as followings:
The last two steps are also used in isr multiplexer in interrupt handling to run the correct irq handler. For other boxes which need to print messages, debug box could provide secure gateway for them to do this. In secure gateway, context switch can be triggered by svc call and the debug box will be loaded to handle the messages. The only problem now is that the data which could be transferred by svc call is very limited. The easiest way is that only one character is transferred in each debugging request but it will be inefficient when there are a large number of messages to print out. There should be a mechanism like share memory to solve this problem. I am very glad to discuss with you about this topic and appreciate more advice from you. |
Currently only LED blinking and semihosting can be used to represent the status of uVisor; however neither of them is convenient in debugging. For efficient debugging, Serial is a good solution and its interface is defined first in this commit. The detail implementations of serial interface is still empty and will be fulfilled in the future.
…M32F429 HAL in mbed project will be ported to implement the serial driver in STM32F429. The two header files with hardware configurations and definitions in this commit are ported first for subsequent HAL porting.
GPIO is the fundamental device of all. Its headers should be ported first.
RCC is used to setup clock of device; therefore its header files should be added here.
The header files are included for using by defining the macros in hal configure header.
Uart is chose as the hardware device for serial io but we only use blocking mode to implement serial io. Remove other functions which are unnecessary to reduce dependency.
Provide mapping from current HAL definitions to legacy definitions for backward compatibility. Some HAL drivers still use old definitions and therefore
Before the configuration api for hardware pins and ports are imported from mbed project, the header files with their definitions should be introduced first.
This api from mbed project is designed to setup the hardware pins. Besides, it could also be used to query the configurations of these pins.
This kind of table could be used for device configuration and information query.
The GPIO api from mbed project provides a hgih level and easy-to-use interface for development of other peripheral device.
The serial io will be implemented by uart with blocking mode. The other functions like interrupt handling are disabled in building.
Currently uart with blocking mode is easy and good enough for debugging. Besides, uVisor should not handle peripheral interrupts directly and could only just forward these interrupts to boxes which have registered handlers before.
38e016f
to
b9ea8aa
Compare
@georgekang for sending debug messages down to the unprivileged debug box:
If you want, we can discuss the details of debug messages via a dedicated box. My Skype user name is "milosch.meriac". |
@meriac, thanks for your reply. Here are my questions about debug box.
It looks good but it also means debug box has the authority to access 'str'. Is it possible that the memory space of 'str' is inaccessible from debug box and memory fault would happen when debug box reads the data of 'str' in this situation? My skype account is "georgekang03", and I have added your account in my Skype list. Maybe we can arrange meeting to discuss more details about the design of debug box. |
@georgekang we have three options:
UVISOR_EXTERN void __secure_message_putc(char c)
{
...
}
/* the gateway to the secure function */
void secure_message_putc(char c)
{
secure_gateway(debug_box_name, __secure_message_putc, c);
} |
Please continue discussion at #70 |
Serial is a convenient tool to output log message in developing. It
is more friendly in using and can provide more data than original tools,
LED blinking and semihosting.
Serial now is only available on STM32F429 and its driver programs are
ported from mbed project. (https://github.com/mbedmicro/mbed.git)
Currently serial output can be enabled when the variable "SERIAL_DEBUG"
in Makefile of stm32f4/uvisor is set as "enable". Serial input is
not supported but we may need it for interactive interface in the future.
UART_4 is selected as default serial device with PC_10 as tx pin
and PC_11 as rx pin and the default baud rate is 115200.