lpc32xx and rtems-libbsd
Kirspel, Kevin
Kevin-Kirspel at idexx.com
Fri Aug 19 01:08:25 UTC 2016
I have created a libbsd port for a modified version of the lpc32xx BSP. The lpc code from FREEBSD 10 was backported to FREEBSD 9.3 because FREEBSD 9.3 did not support ARM LPC processors. I ran into some issues that I would like to run by the group.
Issue 1 - the order of declared modules in nexus-devices.h does not guarantee that they will come up in that order on boot up.
a. The lpc code consists of multiple modules that need to be instantiated in a particular order. When running the libbsd testsuite (mainly dhcp01 and usb01), the boot up order of the modules was different for each test. In one case it was OK but the other was not.
b. To have some control over the ordering, I added order support to RTEMS_BSD_DEFINE_NEXUS_DEVICE (RTEMS_BSD_DEFINE_NEXUS_DEVICE_ORDERED). This is modeled off of what FREEBSD does for DRIVER_MODULE (DRIVER_MODULE_ORDERED). A small change to rtems-kernel-nexus.c was needed to support this.
Issue 2 - rtems_bsd_get_mac_address() , rtems_bsd_get_task_priority(), and rtems_bsd_get_task_stack_size() are application dependent. Are we against creating a configuration structure to initialize these things before rtems_bsd_initialize() is called? At a bare minimum, the RTEMS BSP could set some variables used by libbsd.
Kevin Kirspel
Electrical Engineer - Sr. Staff
Opti Medical
235 Hembree Park Drive
Roswell GA 30076
Tel: (770)-510-4444 ext. 81642
Direct: (770)-688-1642
Fax: (770)-510-4445
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20160819/2a2c9881/attachment.html>
More information about the devel
mailing list