TMS570 BSP updates and LwIP support

[Martin Galvan]

On Mon, Nov 9, 2015 at 8:30 PM, Pavel Pisa <pisa at 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.