On 7/4/2023 1:28 am, Joel Sherrill wrote: > Random (and late) question. For this generic BSP, the bsp.h has this: > > LIBBSP_POWERPC_MOTOROLA_POWERPC_BSP_H > > as the bsp guard. libbsd uses that to configure the nexus device and > peripherals. Are there board model differences which need to be taken > into account? We would need a secondary define. The QorIQ has > examples of that I think.
There is more work needed in libbsd for the BSP variants. At the moment on the 6-freebsd-12 branch it is only the DEC tulip driver and the unknown PHY. We can use the RTEMS_BSP define to implement the specific changes when the time comes. I am not sure when that will be. This patch is about the legacy stack and compatibility and not libbsd. The tulip driver in libbsd is for version 3 (I think) and later silicon and the MVME2700 has rev 1 so I am not comfortable using it in production until it has a number of hours in testing. As a result I am making sure the legacy stack is fully functional with RTEMS 6 and it is. Nice work Vijay. This however effects the RTEMS and EPICS integration. Chris _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel