On Mon, Nov 9, 2015 at 8:30 PM, Pavel Pisa <p...@cmp.felk.cvut.cz> wrote: > Hello Martin, >> + TMS570_POM.GLBCTRL = 0 | (TMS570_POM_GLBCTRL_OTADDR(~0) & >> + pom_global_overlay_target_address_start); >> >> I don't see the point of doing (0 | something). > > This is to highlight that register value is not only the base > of overlay target address. The following expression > contains all information based on our headers using > RTEMS standard for fields values. > > TMS570_POM.GLBCTRL = TMS570_POM_GLBCTRL_ON_OFF(0) | > TMS570_POM_GLBCTRL_ETO(0) | > (TMS570_POM_GLBCTRL_OTADDR(~0) & > pom_global_overlay_target_address_start); > > It has same value and effect as simplified one. > But if you prefer this form then I change code.
I'd rather do TMS570_POM.GLBCTRL = (TMS570_POM_GLBCTRL_OTADDR(~0) & pom_global_overlay_target_address_start); but that's just me. >> In any case, is there a reason why you're seting the OTADDR in >> tms570_initialize_and_clear if you're gonna overwrite it later in >> tms570_pom_remap (or, in our case, not use it at all)? I think simply >> setting TMS570_POM.GLBCTRL to zero would be clearer. > > The OT base address is global decision so even if following > region setup code is implemented such way, that it looks for > the first available POM region it has to allocate overlay > target in memory foolowing OT base address. So code reflect > this information that decision is global. If there more SRAM > memory reserved than even overlay target can be allocated > dynamically. I do not expect that we need such mechanism > soon or in middle time horizon. But I want to document hat. Ok. > The older version of Technical Refence Manual is unclear. > It take me some time to find the problem by comparison with > manuals for newer TMS570 family members when we introduced > TMS570 BSP. Manual version SPNU499B from November 2012 > (Revised August 2013) is already clear Indeed, I'd been reading SPNU499A. > Have you some plans to integrate or cooperate on bare (no loader) > startup code integration to mainline RTEMS BSP? It seems that > HalCoGen licensing has dramatically changed for latest versions > (so after review by others) it could be possible to reuse parts > of the generated code. Other option (may it be better fitting RTEMS > code style) is incrementally rewrite/write own code. We've always been on the side of cleaning up the Halcogen code and using that. That's what we're using right now, and it's working fine for us. I haven't looked at the TI license since last time we discussed this, but if it's now RTEMS-compatible then great. Keep in mind, though, that we're using a TMS570 USB kit (http://processors.wiki.ti.com/index.php/TMS570LS31x_USB_Kit), which may require different Halcogen code than your HDK. For instance, we set BSP_PLL_OUT_CLOCK to 180 MHz instead of the 160 you're using. If we're gonna migrate the Halcogen code, we should probably have a separate tree for each board. I currently don't know if we're gonna be able to contribute to the migration (if there's one). We'll get back to you on this. > If you intend to use 4.11 for production, please, test our changes > and suggest if they are appropriate for 4.11. Are you planning to merge this to 4.11? I don't know how the RTEMS team manages their branches, but I assumed any changes to 4.11 are bug-fixes instead of new features. _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
