Re: Use of rtems_fdt_* and sp01

[Chris Johns]

On 20/11/2022 10:25 am, Joel Sherrill wrote:
> On Sat, Nov 19, 2022, 4:19 PM Chris Johns  > wrote:
> 
> On 19/11/22 2:13 am, Joel Sherrill wrote:
> > On Fri, Nov 18, 2022, 8:49 AM Kinsey Moore  
> > >> 
> wrote:
> >     On Fri, Nov 18, 2022 at 12:44 AM Sebastian Huber
> >      
> >      >> wrote:
> >         On 18/11/2022 06:32, Kinsey Moore wrote:
> >         > On Thu, Nov 17, 2022 at 4:49 PM Chris Johns  
> >         >
> >         > 
>  >         >
> >         >     On 18/11/2022 2:39 am, Kinsey Moore wrote:
> >         >      > I recently added FDT support to the AArch64 ZynqMP 
> BSPs to
> >         >     support an optional
> >         >      > management console and managing ethernet parameters for
> LibBSD.
> >         >     Use of the
> >         >      > rtems_fdt_* functions implies use of malloc which adds 
> 4
> bytes in
> >         >     the TLS space.
> >         >      > The sp01 test uses rtems_task_construct and specifies a
> maximum
> >         >     TLS size of 0
> >         >      > bytes which causes a failure which the non-zero TLS 
> size is
> >         >     checked against the
> >         >      > maximum TLS size of 0.
> >         >
> >         >     Does this mean there exists a requirement a BSPs cannot
> internally
> >         >     use the heap?
> >         >
> >         >
> >         > That appears to be the case, at least practically. It works
> fine, but it
> >         > causes a test failure...
> >
> >         You can use the heap during system initialization. However, you 
> should
> >         avoid dependencies on errno, so instead of using 
> malloc()/calloc() use
> >         rtems_malloc()/rtems_calloc(). Independent of this, if the BSP
> >         initialization can easily avoid the heap, then it should not use
> the heap.
> >
> >         >
> >         >
> >         >     Maybe the test needs to be adjusted?
> >         >
> >         >
> >         > That's part of why I sent this to the list. I was unsure 
> whether
> it was
> >         > allowed or whether the test had bad assumptions baked into it.
> >
> >         The tests check specific aspects of the thread-local storage
> support and
> >         this works only if the BSP does not depend on TLS objects such 
> as
> errno.
> >
> >     This affects several other tests as well, so I guess my solution 
> here is
> >     either to alter the rtems_fdt_ wrappers to avoid dependencies on 
> TLS or
> >     proceed with the existing patch that uses the non-wrapped FDT 
> functions.
> >
> > I agree with Sebastian that fixing the bsp is right.
> >
> > But also rtems_ fdt methods should be changed to use rtems_malloc. That 
> would
> > leave those methods useful. They are broken now for many intended use 
> cases.
> 
> We are currently reviewing the support for ftbo files in Linux 
> (petalinux) with
> a view to seeing how we can support them on RTEMS. I see FDT being use 
> more and
> more in RTEMS and with a number of different use cases and flows there is 
> a need
> to try and unify how we handle them. I see benefits if we can support a 
> similar
> dtbo model as Linux and if that happens the specific area in question in
> rtems-fst can be move over to using it.
> 
> 
> FWIW Kinsey's patch to the rtems_fdt methods eliminated two coverity issues.

Yes and that is a worth while change. Thanks.

Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: TMS570 OpenOCD Flash Support

[Pavel Pisa]

Dear Devin Stafford

On Friday 18 of November 2022 19:07:13 Devin Stafford wrote:
> Hope all is well. Thank you for providing the patches and documentation for
> the TMS570 flash support. They have been of great help to me.

that is really pleasing for me, that my old effort in TMS570 area
that partially related to my not so open work under old former group
destroying many of my other investments, has found some user.
But pushing project forward to mainlineable state is big effort.
So I send the CC to RTEMS list where somebody other can have some
experience in this area.

I would personally liked to pour my hands or lead studnet, but until
I finish our ESA project, I am sillent even in more heartily projects
related to RTEMS... Sorry...

  https://gitlab.com/pikron/projects/sumintadc/deliverables

I am keeping only RISC-V and teaching based ones to survive.

> I was able to confirm the functionality of the flash support with your
> patches via XDS100v2 using the TMS570L3137 HDK. I am now trying to use a
> Raspberry Pi to connect to the TMS570L3137 HDK from the RPi's GPIO to the
> TMS570L3137 HDK's external JTAG. I am able to find the JTAG Tap, but I get
> the following error message:
> [image: unsuccessful_old_openocd.png]

Great, the given old GDB version worked well even with FTDI based
adapters as I remember. I can send even technological data for our
JT_USB6 version

  https://pikron.com/pages/products/accessories.html

But XDS1000 standalone adapters from TI are not expensive, so that
can be a better/more accessible choice.

> When I use the same wiring setup and use the latest version of OpenOCD (so
> only debug support for the TMS570 and no flash support), I am able to find
> the TAP, examine the target, and receive no errors.  Here is that output:
> [image: successful_openocd.png]

That is great, that mainline supports TMS570 reliably now. There has been 
problem on big-endian R4 to access memory behind EIM (DRAM) in the
older version if I remember well. I have some hack in my patches, I think

  https://cmp.felk.cvut.cz/~pisa/tms570/openocd-patches/

> I have attached a logic analyzer for both instances, and the signals look
> similar for both.
>
> Therefore, I believe it is a software issue and was wondering if you have
> any advice to resolve this issue? I have attached my openocd.cfg file as
> well.

So to recapitulate, you are trying to use old TMS570 GDB
(working with XDS100v2) with raspberrypi-native JTAG interface
and there is a problem.

The first reported problem (on raspberrypi-native) is
Warn: Invalid ACK 0x6 in JTAG-DP transaction
I would expect, that low level JTAG transport is OK,
a correct part is reported, but the target stays in undefined
state probably. You can try to lower interface frequency
or adjust reset timing. I would expect that there can be
problem with incompatible, other default reset configuration
in old GDB for raspberrypi-native.
Try to look into corersponding
  openocd/scripts/interface/raspberrypi-native.cfg
if that doe snot help, then into interface sources.

Try to check what are mapping and options for reset
related section

# bcm2835gpio_trst_num 7
# reset_config trst_only

# bcm2835gpio_srst_num 24
# reset_config srst_only srst_push_pull

# or if you have both connected,
# reset_config trst_and_srst srst_push_pull

when you compare with

openocd/scripts/interface/ftdi/xds100v2.cfg

#
# Texas Instruments XDS100v2
#
# http://processors.wiki.ti.com/index.php/XDS100#XDS100v2_Features
#

interface ftdi
ftdi_vid_pid 0x0403 0xa6d0 0x0403 0x6010

ftdi_layout_init 0x0038 0x597b
ftdi_layout_signal nTRST -data 0x0010
ftdi_layout_signal nSRST -oe 0x0100
ftdi_layout_signal nEMU_EN -data 0x0020
ftdi_layout_signal nEMU0 -data 0x0040
ftdi_layout_signal nEMU1 -data 0x1000
ftdi_layout_signal PWR_RST -data 0x0800
ftdi_layout_signal LOOPBACK -data 0x4000

echo "\nInfo : to use this adapter you MUST add ``init; ftdi_set_signal 
PWR_RST 1; jtag arp_init'' to the end of your config file!\n"

There are configuration of nTRST, nSRST and PWR_RST signals for FTDI.
Check if equivalent signals are configured correctly for raspberrypi-native.
There can be difference between old and new GDB. Check PWR_RST influence.
Putting some enforced reset into raspberrypi-native could help.

Generally, the right direction is to forget about old GDB version
and make current mainline to support Flash on TMS570. But that
could be really huge project.

There are two main problems. My two patches are based on Andrey Smirnov
series which, as I know, did not reached mainline. There is lot of
work there. May it be, there is already equivalent enhancement included,
but it can be on different basis. needs to analyze understand existing
or add missing functionality.

The other problem are actual Flashing algorithm running on TMS570.
The library is available from TI only in a binary (ELF object archive/lib)
form. Distribution such "firmware" in GDB mainline can be a problem.
One option is to change mechanism to