from:"Christian Mauderer"




On 19/02/2021 22:11, Joel Sherrill wrote:



On Fri, Feb 19, 2021 at 3:07 PM Christian Mauderer <mailto:o...@c-mauderer.de>> wrote:


On 19/02/2021 19:52, junkes wrote:
 > On 2021-02-19 18:40, Gedare Bloom wrote:
 >> Advise how you built. We are starting to see some bitrot breakage in
 >> configuration. The cutover to waf will come soon, and I don't expect
 >> rtems6 release to support autoconf build of rtems itself. I suggest
 >> you change over to waf build of rtems kernel if you haven't yet.
 >
 > I use a build system from Christian Maurer:
 > https://gitlab.com/c-mauderer/rtems-simulation-environment
<https://gitlab.com/c-mauderer/rtems-simulation-environment>

It's not really a build system but only a Makefile that collects the
commands so that I can run some quick tests. Please also note that this
is no official repo. So don't be surprised if it changes or breaks.


This is exactly why I haven't been prone to share my rtems-cron-helpers
which includes a build_bsp script which makes waf and autoconf look the
same from the command line. It also can run the tester. Saves me a lot of
keyboarding  :)

--joel


The repository is based on a Makefile that we used for a customer in an 
open source project:


  https://github.com/grisp/grisp2-rtems-toolchain/

So it's out in the wild anyway ;-)




 >
 > define build_toolchain
 >  rm -rf $(RSB)/rtems/build
 >  cd $(RSB)/rtems && ../source-builder/sb-set-builder \
 >      --prefix=$(PREFIX) \
 >      --log=$(RSB)/b-rsb-toolchain-$(1).log \
 >      $(RTEMS_VERSION)/rtems-$(1)
 >  rm -rf $(RSB)/rtems/build
 >
 > define build_bsp
 >  cd $(SRC_RTEMS) && ./waf clean || true
 >  cd $(SRC_RTEMS) && ./waf bsp_defaults --rtems-bsps=$(1)/$(2) >
 > config.ini
 >  cd $(SRC_RTEMS) && sed -i \
 >      -e "s|RTEMS_POSIX_API = False|RTEMS_POSIX_API = True|" \
 >      -e "s|CLOCK_DRIVER_USE_FAST_IDLE =
 > True|CLOCK_DRIVER_USE_FAST_IDLE = False|" \
 >      -e "s|BUILD_TESTS = False|BUILD_TESTS = True|" \
 >      config.ini
 >  cd $(SRC_RTEMS) && ./waf configure --prefix=$(PREFIX)
 >  cd $(SRC_RTEMS) && ./waf
 >  cd $(SRC_RTEMS) && ./waf install
 > endef
 >
 > define build_libbsd
 >  rm -rf $(SRC_LIBBSD)/build
 >  cd $(SRC_LIBBSD) && ./waf configure \
 >      --prefix=$(PREFIX) \
 >      --rtems-bsps=$(1)/$(2) \
 >      --enable-warnings \
 >      --optimization=2 \
 >      --rtems-version=$(RTEMS_VERSION)
 >  cd $(SRC_LIBBSD) && ./waf
 >  cd $(SRC_LIBBSD) && ./waf install
 > endef
 >
 >
 > I would like to switch to waf. But this is not available for the
 > kernel with RTEMS5 and unfortunately it does not work with RTEMS6.
 > Heinz > ___
 > users mailing list
 > users@rtems.org <mailto:users@rtems.org>
 > http://lists.rtems.org/mailman/listinfo/users
<http://lists.rtems.org/mailman/listinfo/users>
 >
___
users mailing list
users@rtems.org <mailto:users@rtems.org>
http://lists.rtems.org/mailman/listinfo/users
<http://lists.rtems.org/mailman/listinfo/users>


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

Re: MVME2500 (qoriq_e500) no longer boots with RTEMS6


On 19/02/2021 17:30, Heinz Junkes wrote:

When I use the kernel from RTEMS6 my MVME2500 (qoriq_e500)
does not boot anymore and hangs:

VME2500=> run rtems_myTests
reading mvme2500.dtb
12363 bytes read in 13 ms (928.7 KiB/s)
Speed: 1000, full duplex
Using eTSEC1 device
TFTP from server 141.14.128.9; our IP address is 141.14.128.89
Filename 'ticker.img'.
Load address: 0x1000
Loading: #
 6.4 MiB/s
done
Bytes transferred = 60182 (eb16 hex)
WARNING: adjusting available memory to 3000
## Booting kernel from Legacy Image at 1000 ...
   Image Name:   RTEMS
   Created:  2021-02-18  20:18:21 UTC
   Image Type:   PowerPC Linux Kernel Image (gzip compressed)
   Data Size:60118 Bytes = 58.7 KiB
   Load Address: 4000
   Entry Point:  4000
   Verifying Checksum ... OK
## Flattened Device Tree blob at 2000
   Booting using the fdt blob at 0x2000
   Uncompressing Kernel Image ... OK
   Loading Device Tree to 03ff9000, end 03fff04a ... OK
…

no more output


Just a wild guess: Can you compare the addresses of the binaries. Maybe 
for some reason a wrong linkcmds is used. arm-rtems6-objdump -h app.exe 
should give you the relevant information.





Heinz


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


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

Re: MVME2500 (qoriq_e500) no longer boots with RTEMS6


On 19/02/2021 19:52, junkes wrote:

On 2021-02-19 18:40, Gedare Bloom wrote:

Advise how you built. We are starting to see some bitrot breakage in
configuration. The cutover to waf will come soon, and I don't expect
rtems6 release to support autoconf build of rtems itself. I suggest
you change over to waf build of rtems kernel if you haven't yet.


I use a build system from Christian Maurer:
https://gitlab.com/c-mauderer/rtems-simulation-environment


It's not really a build system but only a Makefile that collects the 
commands so that I can run some quick tests. Please also note that this 
is no official repo. So don't be surprised if it changes or breaks.




define build_toolchain
 rm -rf $(RSB)/rtems/build
 cd $(RSB)/rtems && ../source-builder/sb-set-builder \
     --prefix=$(PREFIX) \
     --log=$(RSB)/b-rsb-toolchain-$(1).log \
     $(RTEMS_VERSION)/rtems-$(1)
 rm -rf $(RSB)/rtems/build

define build_bsp
 cd $(SRC_RTEMS) && ./waf clean || true
 cd $(SRC_RTEMS) && ./waf bsp_defaults --rtems-bsps=$(1)/$(2) > 
config.ini

 cd $(SRC_RTEMS) && sed -i \
     -e "s|RTEMS_POSIX_API = False|RTEMS_POSIX_API = True|" \
     -e "s|CLOCK_DRIVER_USE_FAST_IDLE = 
True|CLOCK_DRIVER_USE_FAST_IDLE = False|" \

     -e "s|BUILD_TESTS = False|BUILD_TESTS = True|" \
     config.ini
 cd $(SRC_RTEMS) && ./waf configure --prefix=$(PREFIX)
 cd $(SRC_RTEMS) && ./waf
 cd $(SRC_RTEMS) && ./waf install
endef

define build_libbsd
 rm -rf $(SRC_LIBBSD)/build
 cd $(SRC_LIBBSD) && ./waf configure \
     --prefix=$(PREFIX) \
     --rtems-bsps=$(1)/$(2) \
     --enable-warnings \
     --optimization=2 \
     --rtems-version=$(RTEMS_VERSION)
 cd $(SRC_LIBBSD) && ./waf
 cd $(SRC_LIBBSD) && ./waf install
endef


I would like to switch to waf. But this is not available for the
kernel with RTEMS5 and unfortunately it does not work with RTEMS6.
Heinz > ___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users


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

Re: Trouble with addr_abort exception on arm/imx7 BSP with simple RTEMS code

Hello Stefan,

On 19/02/2021 21:29, Stefan Akatyschew wrote:
Yeah, there was no timer entry in the FDT, hence I created it (only 
filled with clock-frequency) manually. I forgot to attach the fdt list 
output before my changes in my last mail:

No timer entry doesn't sound right. Normally the timer entry should 
exist like here:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/imx7s.dtsi#n152

It seems that phytec decided to move it to soc/timer at least in some FDTs:

https://stash.phytec.com/projects/PUB/repos/linux-phytec-fsl/browse/arch/arm/boot/dts/imx7s.dtsi?at=BSP-Yocto-FSL-iMX7-PD18.2.0#366

If that is the case for you, you might have to create a patch for 
bsps/arm/imx/start/bspstart.c. Basically you would have to change the 
search for the timer node from:

node = fdt_path_offset(fdt, "/timer");

to

node = fdt_path_offset(fdt, "/timer");
if (node < 0) {
  node = fdt_path_offset(fdt, "/soc/timer");
}

or alternatively search for a "compatible" node.

Regarding WAF and SMP: I can't follow unfortunately, I only ran "./waf 
configure --rtems=..." and saw the missing SMP output there.

Sorry, I might have asked that already: Which version of RTEMS do you use?

If it is the 5 release, you should have a something like like

./configure --target=arm-rtems5 \
--prefix=${PREFIX} \
--enable-posix \
--enable-rtemsbsp=imx \
--disable-networking \
--with-rtems-smp
make

or similar to build your BSP. For the current master with the waf based 
build system, you will have calls like

./waf bsp_defaults --rtems-bsps=arm/imx > config.ini
# edit config.ini to fit your needs - for example ENABLE_RTEMS_SMP
./waf configure --prefix=${PREFIX}
./waf

Best regards

Christian

Kind regards,
Stefan
On Feb 18 2021, at 9:52 pm, Christian Mauderer  wrote:

On 18/02/2021 21:03, Stefan Akatyschew wrote:
 > Hello Christian,
 > I'm very grateful for the script, it seems to work with the load
adress
 > 0x8080 and I don't get the previously described error. Thank you!
 > Unfortunately though I got the Fatal error 3072, as described here:
 > https://www.mail-archive.com/users@rtems.org/msg02837.html
 > <https://www.mail-archive.com/users@rtems.org/msg02837.html>
 > But could "resolve" that, by setting up /timer/clock-frequency in
the ftd:
 >   run loadfdt
 >   run loadimage
 >   fdt addr 0x8300
 >   fdt resize
 >   fdt mknode / timer
 >   fdt set /time clock-frequency <0x007a1200>
 >   bootz ${loadaddr} - ${fdt_addr}

That's odd. Normally U-Boot should already add that. Only barebox didn't
seem to add it on the i.MX6UL/ULL. But barebox also didn't initialize
the timer. So if the clock-frequency is missing, you might need a bit
more than just adding the field. It is possible that U-Boot then also
doesn't call the timer_init:

https://gitlab.denx.de/u-boot/u-boot/-/blob/2dddc1bb296308/arch/arm/mach-imx/syscounter.c#L63

Maybe only certain U-Boots did call that and add the clock-frequency? I
can't say fur sure which version has been used on the i.mx7 boards that
have been used for the original BSP development.

Maybe you want to try the patch that I added for initializing the system
counter on i.MX6ULL:

https://git.rtems.org/rtems/commit/bsps/arm/imx/start/bspstart.c?id=7b99d7619ec3ff1143db003a541505367f8004d5

It should work on an i.MX7 too if the counter hasn't been initialized.

 > I just chose the value for the clock-frequency out of the fdt
 > /clock-osc/clock-frequency. Not sure if that is the correct value, I
 > also tried some others, but I always get the error code 263
 > (BSP_ARM_FATAL_GENERIC_TIMER_CLOCK_IRQ_INSTALL) . (I fiddled it
 > together, so please correct if I did any mistakes)
 > That also seems to fit the description of JunBeom, but I couldn't
follow
 > with Step 2. Do I have to just get the current u-boot sources,
make the
 > change and normally build it? I used the imx7 u-boot image
provided by
 > PHYTEC and am not sure if there are necessary custom changes for the
 > imx7 Board or the fdt information is needed to be provided. I looked
 > quiet a while on the internet, but couldn't find much guidance on
that
 > process. Can someone please give me pointers on how to proceed
from here?

I think the problem in that thread has been that U-Boot for some reason
started in a different mode. But note that JunBeom didn't get an
interrupt. He didn't have a problem installing the interrupt handler.

Installing the interrupt handler can fail for different reasons. The
most likely one

Re: xilinx_zynq_a9_qemu RTEMS6 no console input/output

2021-02-19 Thread Christian MAUDERER


Am 19.02.21 um 13:06 schrieb Heinz Junkes:

Sorry. The settings for several targets are in the defaults.

and for ARM-Cortex-A9 the default value is

CLOCK_DRIVER_USE_FAST_IDLE = True


That should be dependent on the BSP. Most likely for most simulator BSPs 
it's True.


Best regards

Christian




Sorry for the noise ….
Heinz


On 19. Feb 2021, at 09:45, Christian MAUDERER 
 wrote:

I think some of the simulator BSPs have an option that enable some kind of time 
laps as soon as the idle routine is reached.

In the new waf build system it's the option CLOCK_DRIVER_USE_FAST_IDLE in the 
config.ini.

I'm not 100% sure how it would have been disabled in the old build system. I 
assume you have to pass CLOCK_DRIVER_USE_FAST_IDLE=0 to the configure call.

Best regards

Christian




--

embedded brains GmbH
Herr Christian MAUDERER
Dornierstr. 4
82178 Puchheim
Germany
email: christian.maude...@embedded-brains.de
phone: +49-89-18 94 741 - 18
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users

Re: xilinx_zynq_a9_qemu RTEMS6 no console input/output

2021-02-19 Thread Christian MAUDERER


Hello Heinz,

Am 19.02.21 um 09:57 schrieb Heinz Junkes:

Sorry, I should have seen…

Yes, it works as you wrote.

Now I just need to clarify the timing problem with fileio keyboard input


Like I said: I would start at the CLOCK_DRIVER_USE_FAST_IDLE option. If 
you use my environment, the config.ini is generated and edited 
automatically. So you either have to change that or add a lin in the 
build_bsp function that changes the value.




Vielen, vielen Dank für Deine Hilfe,


Kein Problem.

Christian


Heinz



On 19. Feb 2021, at 09:45, Christian MAUDERER 
 wrote:


If you start the script just like it is, it assumes that you want to connect a 
gdb. In that case qemu is started with parameters that restart after the 
application terminates.

If you want to run an application without gdb, you have to pass "-p 0" to the 
script. This disables the gdb port and sets the -no-reboot option of qemu.




--

embedded brains GmbH
Herr Christian MAUDERER
Dornierstr. 4
82178 Puchheim
Germany
email: christian.maude...@embedded-brains.de
phone: +49-89-18 94 741 - 18
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users

Re: xilinx_zynq_a9_qemu RTEMS6 no console input/output

2021-02-19 Thread Christian MAUDERER

Hello Heinz,

Am 19.02.21 um 09:31 schrieb junkes:
I'll try your suggested approach. Maybe this will bring us closer to the
matter.

In the meantime, with your setup it works great. Only too well ;-)

Good to hear.

e.g. ticker.exe restarts itself automatically again and again endlessly.

The restart depends on the options for qemu. If you used the script from
debug/qemu.sh:

If you start the script just like it is, it assumes that you want to
connect a gdb. In that case qemu is started with parameters that restart
after the application terminates.

If you want to run an application without gdb, you have to pass "-p 0"
to the script. This disables the gdb port and sets the -no-reboot option
of qemu.

fileio.exe also endlessly, no input is accepted.
Everything seems to run "too fast". Problem with delays/timing?

I think some of the simulator BSPs have an option that enable some kind
of time laps as soon as the idle routine is reached.

In the new waf build system it's the option CLOCK_DRIVER_USE_FAST_IDLE
in the config.ini.

I'm not 100% sure how it would have been disabled in the old build
system. I assume you have to pass CLOCK_DRIVER_USE_FAST_IDLE=0 to the
configure call.

Best regards

Christian

Heinz

On 2021-02-19 08:39, Christian MAUDERER wrote:

Hello Heinz,

Am 19.02.21 um 07:53 schrieb junkes:

Hello Christian,

I checked with gdb.

start with
sudo ~/QEMU/rtems/6/bin/qemu-system-arm -M xilinx-zynq-a9 -S -s -m
256M -no-reboot -serial null -serial mon:stdio -nographic -kernel
./arm-rtems6/c/xilinx_zynq_a9_qemu/testsuites/samples/fileio.exe

other terminal:

$ ~/QEMU/rtems/6/bin/arm-rtems6-gdb
./arm-rtems6/c/xilinx_zynq_a9_qemu/testsuites/samples/fileio.exe

GNU gdb (GDB) 10.1.90.20210205-git
...

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from
./arm-rtems6/c/xilinx_zynq_a9_qemu/testsuites/samples/fileio.exe...

(gdb) target rem localhost:1234
Remote debugging using localhost:1234
bsp_start_vector_table_end ()
at
../../../../../../../../../kernel/c/src/lib/libbsp/arm/xilinx-zynq/../../../../../../bsps/arm/shared/start/start.S:192
192 mov r0, #0

(gdb) c
Continuing.
< no output
^C
Program received signal SIGINT, Interrupt.
bsp_vector_table_begin ()
at
../../../../../../../../../kernel/c/src/lib/libbsp/arm/xilinx-zynq/../../../../../../bsps/arm/shared/start/start.S:73
73 ldr pc, .Lhandler_addr_undef

(gdb) bt
#0 bsp_vector_table_begin ()
at
../../../../../../../../../kernel/c/src/lib/libbsp/arm/xilinx-zynq/../../../../../../bsps/arm/shared/start/start.S:73
#1 0x0010481c in zynq_mmu_config_table ()
Backtrace stopped: previous frame identical to this frame (corrupt
stack?)

(gdb)

That looks a bit like there has ben either an exception or the code
hasn't been load. Can you try the following gdb commands:

# Reset the system and load binary
monitor system_reset
load

# Set some useful breakpoints (maybe you have to skip some libbsd ones)
b _ARM_Exception_default
b _ARMV4_Exception_data_abort_default
b bsp_interrupt_handler_default
b bsp_reset
b _Internal_error_Occurred
b _Terminate

# run program
continue

If you reach one of the breakpoints do a `bt` like you did above.

Same behavior on MVME2500 with RTEMS6:

VME2500=> run rtems_myTests
reading mvme2500.dtb
12363 bytes read in 13 ms (928.7 KiB/s)
Speed: 1000, full duplex
Using eTSEC1 device
TFTP from server 141.14.128.9; our IP address is 141.14.128.89
Filename 'ticker.img'.
Load address: 0x1000
Loading: #
6.4 MiB/s
done
Bytes transferred = 60182 (eb16 hex)
WARNING: adjusting available memory to 3000
## Booting kernel from Legacy Image at 1000 ...
Image Name: RTEMS
Created: 2021-02-18 20:18:21 UTC
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 60118 Bytes = 58.7 KiB
Load Address: 4000
Entry Point: 4000
Verifying Checksum ... OK
## Flattened Device Tree blob at 2000
Booting using the fdt blob at 0x2000
Uncompressing Kernel Image ... OK
Loading Device Tree to 03ff9000, end 03fff04a ... OK

no further output ...

That's odd. Especially because it is an entirely different target.

Best regards

Christian

Will now try your install target ...

Heinz

On 2021-02-18 22:28, Christian Mauderer wrote:

Hello Heinz,

On 18/02/2021 21:38, junkes wrote:

Hallo Christian,
thank you for testing. This is "my procedure":

hm. There doesn't seem to be a big difference to mine. If you are
interested, take a look at the install target in the Makefile in:

https://gitlab.com/c-mauderer/rtems-simulation-environment

It's basically just building the same stuff. Differences:

I use the waf based build system for the BSP. But that shouldn't
really matter at the moment. But note that you might have to switch
somewhen i

Re: xilinx_zynq_a9_qemu RTEMS6 no console input/output

2021-02-18 Thread Christian MAUDERER

Hello Heinz,

Am 19.02.21 um 07:53 schrieb junkes:

Hello Christian,

I checked with gdb.

start with
sudo ~/QEMU/rtems/6/bin/qemu-system-arm -M xilinx-zynq-a9 -S -s -m 256M
-no-reboot -serial null -serial mon:stdio -nographic -kernel
./arm-rtems6/c/xilinx_zynq_a9_qemu/testsuites/samples/fileio.exe

other terminal:

$ ~/QEMU/rtems/6/bin/arm-rtems6-gdb
./arm-rtems6/c/xilinx_zynq_a9_qemu/testsuites/samples/fileio.exe

GNU gdb (GDB) 10.1.90.20210205-git
...

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from
./arm-rtems6/c/xilinx_zynq_a9_qemu/testsuites/samples/fileio.exe...

192 mov r0, #0
(gdb) c
Continuing.
< no output
^C
Program received signal SIGINT, Interrupt.
bsp_vector_table_begin ()
at
../../../../../../../../../kernel/c/src/lib/libbsp/arm/xilinx-zynq/../../../../../../bsps/arm/shared/start/start.S:73

73 ldr pc, .Lhandler_addr_undef
(gdb) bt
#0 bsp_vector_table_begin ()
at
../../../../../../../../../kernel/c/src/lib/libbsp/arm/xilinx-zynq/../../../../../../bsps/arm/shared/start/start.S:73

#1 0x0010481c in zynq_mmu_config_table ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb)

That looks a bit like there has ben either an exception or the code
hasn't been load. Can you try the following gdb commands:

# Reset the system and load binary
monitor system_reset
load

# run program
continue

If you reach one of the breakpoints do a `bt` like you did above.

Same behavior on MVME2500 with RTEMS6:

no further output ...

That's odd. Especially because it is an entirely different target.

Best regards

Christian

Will now try your install target ...

Heinz

On 2021-02-18 22:28, Christian Mauderer wrote:

Hello Heinz,

On 18/02/2021 21:38, junkes wrote:

Hallo Christian,
thank you for testing. This is "my procedure":

hm. There doesn't seem to be a big difference to mine. If you are
interested, take a look at the install target in the Makefile in:

https://gitlab.com/c-mauderer/rtems-simulation-environment

It's basically just building the same stuff. Differences:

I use the waf based build system for the BSP. But that shouldn't
really matter at the moment. But note that you might have to switch
somewhen in the near future because it is planned to remove the old
autoconf / automake based build system.

Beneath that I use a qemu build from the upstream sorces because the
version from RSB doesn't build cleanly on Arch Linux (something about
docs). But I tried it with the binary build by RSB and that works too.

I'll think a bit about it and let you know when I find something other
that might be a problem. But at the moment, I'm running out of ideas.

Maybe you can try to attach a gdb to your qemu and see whether the
application runs and only doesn't produce output?

Best regards

Christian

### Installation RTEMS6 / EPICS7 (xilinx_zynq_a9_qemu)

Installation RTEMS6 and EPICS 7 incl. rtems tools, kernel, bsp and
libbsd

ubuntu 20.04.1

---

**Installing rtems source builder and build rtems-powerpc tools**

mkdir QEMU
cd QEMU
git clone https://github.com/RTEMS/rtems-source-builder.git rsb
cd rsb
git checkout master
git pull
cd rtems
../source-builder/sb-set-builder --prefix=$HOME/QEMU/rtems/6
6/rtems-arm

RTEMS Source Builder - Set Builder, 6 (61dcadee0825)
Command Line: ../source-builder/sb-set-builder
--prefix=/home/junkes/QEMU/rtems/6 6/rtems-arm

Python: 2.7.18 (default, Aug 4 2020, 11:16:42) [GCC 9.3.0]
Build Set: 6/rtems-arm
Build Set: 6/rte

Re: xilinx_zynq_a9_qemu RTEMS6 no console input/output

2021-02-18 Thread Christian Mauderer

estsuites/rhealstone/configure.ac
   9/119: autoreconf: testsuites/psxtests/configure.ac
  10/119: autoreconf: testsuites/psxtmtests/configure.ac
  11/119: autoreconf: testsuites/sptests/configure.ac
  12/119: autoreconf: testsuites/mptests/configure.ac
  13/119: autoreconf: testsuites/samples/configure.ac
  14/119: autoreconf: testsuites/tmtests/configure.ac
  15/119: autoreconf: c/configure.ac

     ...
     110/119: autoreconf: c/src/lib/libbsp/powerpc/mvme3100/configure.ac
     111/119: autoreconf: c/src/lib/libbsp/powerpc/haleakala/configure.ac
     112/119: autoreconf: c/src/lib/libbsp/powerpc/mpc8260ads/configure.ac
     113/119: autoreconf: c/src/lib/libbsp/powerpc/mpc55xxevb/configure.ac
     114/119: autoreconf: c/src/lib/libbsp/powerpc/qoriq/configure.ac
     115/119: autoreconf: c/src/lib/libbsp/powerpc/gen5200/configure.ac
     116/119: autoreconf: c/src/lib/libbsp/powerpc/qemuppc/configure.ac
     117/119: autoreconf: c/src/lib/libbsp/powerpc/virtex/configure.ac
     118/119: autoreconf: c/src/lib/libbsp/powerpc/virtex4/configure.ac
     119/119: autoreconf: cpukit/configure.ac
     Bootstrap time: 0:00:27.754820

     cd; cd QEMU
     mkdir -p build/b-xilinx_zynq_a9_qemu/
     cd build/b-xilinx_zynq_a9_qemu/
     ../../kernel/configure --prefix=$HOME/QEMU/rtems/6 
--target=arm-rtems6 --enable-rtemsbsp=xilinx_zynq_a9_qemu --enable-posix 
--enable-c++ --disable-networking --enable-tests


config.log:

     This file contains any messages produced by compilers while
     running configure, to aid debugging if configure makes a mistake.

     It was created by rtems configure 6.0.0, which was
     generated by GNU Autoconf 2.69.  Invocation command line was

   $ ../../kernel/configure --prefix=/home/junkes/QEMU/rtems/6 
--target=arm-rtems6 --enable-rtemsbsp=xilinx_zynq_a9_qemu --enable-posix 
--enable

     -c++ --disable-networking --enable-tests

     ## - ##
     ## Platform. ##
     ## - ##

     hostname = Krikkit
     uname -m = x86_64
     uname -r = 5.8.0-43-generic
     uname -s = Linux
     uname -v = #49~20.04.1-Ubuntu SMP Fri Feb 5 09:57:56 UTC 2021

     /usr/bin/uname -p = x86_64
     /bin/uname -X = unknown
     ...

     make -j17 all
     make install

rtems-libbsd
     cd;cd QEMU
     cd rtems-libbsd
     git remote -v
     origin    https://github.com/RTEMS/rtems-libbsd.git (fetch)
     origin    https://github.com/RTEMS/rtems-libbsd.git (push)
     git checkout master
     git pull
     git checkout 6-freebsd-12
     git submodule init
     git submodule update rtems_waf
     ./waf configure --prefix=$HOME/QEMU/rtems/6 
--rtems-bsps=arm/xilinx_zynq_a9_qemu --buildset=buildset/default.ini

     ./waf
     ./waf install


qemu-testing:

no ouptut and must be killed by other terminal:

$ qemu-system-arm -no-reboot -serial null -serial mon:stdio -net none 
-nographic -M xilinx-zynq-a9 -m 256M -kernel 
arm-rtems6/c/xilinx_zynq_a9_qemu/testsuites/samples/hello.exe

qemu-system-arm: warning: nic cadence_gem.0 has no peer
qemu-system-arm: warning: nic cadence_gem.1 has no peer


On 2021-02-18 21:10, Christian Mauderer wrote:

Hello Heinz,

Odd. I just tested it with the current master of rtems, libbsd, rtems
source builder and qemu and it worked fine. The only thing that I had
to change compared to your command was adding the "-serial null"
before the second "-serial mon:stdio". Note that it's "null" and not
"none" like for network. I made that mistake when trying to adapt your
command line the first time and received no output.

Beneath that I have an

    export QEMU_AUDIO_DRV=none

in my script that starts qemu. I'm not sure why and it seems that it
is no longer necessary. But maybe you want to try it.

If both don't help:

Which version of rtems are you using and how do you configure your
BSP? Which version of qemu are you using?

On 18/02/2021 18:21, Heinz Junkes wrote:
Thanks, unfortunately I also have the same behavior with -serial null 
-serial on:stdio.

So I use it with RTEMS5 which worked so far.

I had found this in the mail list and tried it ;-)


The patch below seems to be for the xilinx_zynqmp* BSP and not for the
xilinx_zynq_a9_qemu.

Best regards

Christian



Heinz

Qemu's machine definition uses the second UART in the memory map as the
primary UART. This follows from the hardware itself where the second
UART in the memory map is UART 0. This switches the tester to using the
correct UART.
---
tester/rtems/testing/bsps/xilinx_zynqmp_ilp32.ini | 2 +-
tester/rtems/testing/bsps/xilinx_zynqmp_lp64.ini  | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/tester/rtems/testing/bsps/xilinx_zynqmp_ilp32.ini 
b/tester/rtems/testing/bsps/xilinx_zynqmp_ilp32.ini

index 5ff0e86..35869ed 100644
--- a/tester/rtems/testing/bsps/xilinx_zynqmp_ilp32.ini
+++ b/tester/rtems/testing/bsps/xilinx_zynqmp_ilp32.ini
@@ -35,4 +35,4 @@
bsp   = xilinx_zynqmp_ilp32
arch  = aar

Re: Trouble with addr_abort exception on arm/imx7 BSP with simple RTEMS code

2021-02-18 Thread Christian Mauderer

On 18/02/2021 21:03, Stefan Akatyschew wrote:

Hello Christian,
I'm very grateful for the script, it seems to work with the load adress 
0x8080 and I don't get the previously described error. Thank you!
Unfortunately though I got the Fatal error 3072, as described here: 
https://www.mail-archive.com/users@rtems.org/msg02837.html 
<https://www.mail-archive.com/users@rtems.org/msg02837.html>

But could "resolve" that, by setting up /timer/clock-frequency in the ftd:
   run loadfdt
   run loadimage
   fdt addr 0x8300
   fdt resize
   fdt mknode / timer
   fdt set /time clock-frequency <0x007a1200>
   bootz ${loadaddr} - ${fdt_addr}

That's odd. Normally U-Boot should already add that. Only barebox didn't 
seem to add it on the i.MX6UL/ULL. But barebox also didn't initialize 
the timer. So if the clock-frequency is missing, you might need a bit 
more than just adding the field. It is possible that U-Boot then also 
doesn't call the timer_init:

https://gitlab.denx.de/u-boot/u-boot/-/blob/2dddc1bb296308/arch/arm/mach-imx/syscounter.c#L63

Maybe only certain U-Boots did call that and add the clock-frequency? I 
can't say fur sure which version has been used on the i.mx7 boards that 
have been used for the original BSP development.

Maybe you want to try the patch that I added for initializing the system 
counter on i.MX6ULL:

https://git.rtems.org/rtems/commit/bsps/arm/imx/start/bspstart.c?id=7b99d7619ec3ff1143db003a541505367f8004d5

It should work on an i.MX7 too if the counter hasn't been initialized.

I just chose the value for the clock-frequency out of the fdt 
/clock-osc/clock-frequency. Not sure if that is the correct value, I 
also tried some others, but I always get the error code 263 
(BSP_ARM_FATAL_GENERIC_TIMER_CLOCK_IRQ_INSTALL) . (I fiddled it 
together, so please correct if I did any mistakes)
That also seems to fit the description of JunBeom, but I couldn't follow 
with Step 2. Do I have to just get the current u-boot sources, make the 
change and normally build it? I used the imx7 u-boot image provided by 
PHYTEC and am not sure if there are necessary custom changes for the 
imx7 Board or the fdt information is needed to be provided. I looked 
quiet a while on the internet, but couldn't find much guidance on that 
process. Can someone please give me pointers on how to proceed from here?

I think the problem in that thread has been that U-Boot for some reason 
started in a different mode. But note that JunBeom didn't get an 
interrupt. He didn't have a problem installing the interrupt handler.

Installing the interrupt handler can fail for different reasons. The 
most likely one in this case is that the entry for the interrupt is also 
missing in the FDT.

How does the timer entry of your FDT look like? Is there even an timer 
entry?

Regarding the SMP flag, I found it here on the quick-start guide: 
https://ftp.rtems.org/pub/rtems/releases/5/5.1/docs/html/user/start/bsp-build.html 
<https://ftp.rtems.org/pub/rtems/releases/5/5.1/docs/html/user/start/bsp-build.html>

Ah, sorry. I missed that you are using the 5 release and not the latest 
master. In that case I assume the waf call has been for libbsd, right?

Best regards

Christian

Thanks again for the great help so far!
Kind regards,
Stefan
On Feb 8 2021, at 8:41 am, Christian MAUDERER 
 wrote:

Hello Stefan,

Am 07.02.21 um 20:35 schrieb Christian Mauderer:
 > Hello Stefan,
 >
 > On 07/02/2021 19:31, Stefan Akatyschew wrote:
 >> Hey Christian,
 >> no problem, thanks a lot for your reply!
 >> Here it starts, right after loading the elf file:
 >> Just to be sure there is no mistake in my setup, I attached the
 >> complete listing shown (start.S), as well as my .cmm script to load
 >> the binary.
 >
 > That looks like there is a bug in the setup of your debugger.
 >
 > The i.MX7 BSP normally runs out of SDRAM. It expects to be
started by a
 > U-Boot on the i.MX7. If I understand your trace script correctly, it
 > resets the board, then it loads the application. This will try to put
 > the application into a SDRAM that is not yet initialized. It's a
bit odd
 > that Trace32 doesn't throw an error when you try to access the
code there.
 >
 > For boards with a boot loader (like U-Boot) I most of the time
use the
 > following approach:
 >
 > - Make sure that there is an application that can be loaded by
the boot
 > loader (Linux Kernel, RTEMS application, ...)
 > - If the BSP needs an FDT (i.MX does need one): Make sure that one is
 > loaded too.
 >
 > In the debug script:
 >
 > - Reset and halt the board
 > - Set a breakpoint at the location where the Kernel would start
(in that
 > case 0x8020; for Linux may

Re: xilinx_zynq_a9_qemu RTEMS6 no console input/output

2021-02-18 Thread Christian Mauderer


Hello Heinz,

Odd. I just tested it with the current master of rtems, libbsd, rtems 
source builder and qemu and it worked fine. The only thing that I had to 
change compared to your command was adding the "-serial null" before the 
second "-serial mon:stdio". Note that it's "null" and not "none" like 
for network. I made that mistake when trying to adapt your command line 
the first time and received no output.


Beneath that I have an

export QEMU_AUDIO_DRV=none

in my script that starts qemu. I'm not sure why and it seems that it is 
no longer necessary. But maybe you want to try it.


If both don't help:

Which version of rtems are you using and how do you configure your BSP? 
Which version of qemu are you using?


On 18/02/2021 18:21, Heinz Junkes wrote:

Thanks, unfortunately I also have the same behavior with -serial null -serial 
on:stdio.
So I use it with RTEMS5 which worked so far.

I had found this in the mail list and tried it ;-)


The patch below seems to be for the xilinx_zynqmp* BSP and not for the 
xilinx_zynq_a9_qemu.


Best regards

Christian



Heinz

Qemu's machine definition uses the second UART in the memory map as the
primary UART. This follows from the hardware itself where the second
UART in the memory map is UART 0. This switches the tester to using the
correct UART.
---
tester/rtems/testing/bsps/xilinx_zynqmp_ilp32.ini | 2 +-
tester/rtems/testing/bsps/xilinx_zynqmp_lp64.ini  | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/tester/rtems/testing/bsps/xilinx_zynqmp_ilp32.ini 
b/tester/rtems/testing/bsps/xilinx_zynqmp_ilp32.ini
index 5ff0e86..35869ed 100644
--- a/tester/rtems/testing/bsps/xilinx_zynqmp_ilp32.ini
+++ b/tester/rtems/testing/bsps/xilinx_zynqmp_ilp32.ini
@@ -35,4 +35,4 @@
bsp   = xilinx_zynqmp_ilp32
arch  = aarch64
tester= %{_rtscripts}/qemu.cfg
-bsp_qemu_opts = %{qemu_opts_base} -serial null -serial mon:stdio -machine 
xlnx-zcu102 -m 4096
+bsp_qemu_opts = %{qemu_opts_base} -serial mon:stdio -machine xlnx-zcu102 -m 
4096
diff --git a/tester/rtems/testing/bsps/xilinx_zynqmp_lp64.ini 
b/tester/rtems/testing/bsps/xilinx_zynqmp_lp64.ini
index 8db82b6..cd2d268 100644
--- a/tester/rtems/testing/bsps/xilinx_zynqmp_lp64.ini
+++ b/tester/rtems/testing/bsps/xilinx_zynqmp_lp64.ini
@@ -35,4 +35,4 @@
bsp   = xilinx_zynqmp_lp64
arch  = aarch64
tester= %{_rtscripts}/qemu.cfg
-bsp_qemu_opts = %{qemu_opts_base} -serial null -serial mon:stdio -machine 
xlnx-zcu102 -m 4096
+bsp_qemu_opts = %{qemu_opts_base} -serial mon:stdio -machine xlnx-zcu102 -m 
4096


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


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

Re: xilinx_zynq_a9_qemu RTEMS6 no console input/output

2021-02-18 Thread Christian MAUDERER


Hello Heinz,

Am 18.02.21 um 15:32 schrieb junkes:

I just started testing RTEMS6 with xilinx_zynq_a9_qemu.

When I run the examples (in bsp or rtems-libbsd) there is no console 
in/out-put.


  qemu-system-arm -no-reboot -serial mon:stdio -net none -nographic -M 
xilinx-zynq-a9 -m 256M -kernel 
build/arm-rtems6-xilinx_zynq_a9_qemu-default/commands01.exe

qemu-system-arm: warning: nic cadence_gem.0 has no peer
qemu-system-arm: warning: nic cadence_gem.1 has no peer

... nothing happens here


I'm not 100% sure but it's possible that the BSP wants to use a second 
serial port. My call for qemu for this BSP looks like that:


qemu-system-arm -no-reboot -net none -serial null -serial mon:stdio -M 
xilinx-zynq-a9 -m 256M -nographic -kernel media01.exe


Or if I want to attach a debugger:

qemu-system-arm -gdb tcp::1234 -S -net none -serial null -serial 
mon:stdio -M xilinx-zynq-a9 -m 256M -nographic -kernel media01.exe


Note the "-serial null" before the second "-serial mon:stdio".



Have to kill -9 from other shell, no CTRL-C :
Killed


Qemu catches CTRL-C and forwards it to the application. You have to use 
screen-like combinations like CTRL-A followed by h to get help or CTRL-A 
followed by x to exit the emulator.


Best regards

Christian




Heinz
___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users


--

embedded brains GmbH
Herr Christian MAUDERER
Dornierstr. 4
82178 Puchheim
Germany
email: christian.maude...@embedded-brains.de
phone: +49-89-18 94 741 - 18
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users

Re: Trouble with addr_abort exception on arm/imx7 BSP with simple RTEMS code

2021-02-07 Thread Christian MAUDERER

Hello Stefan,

Am 07.02.21 um 20:35 schrieb Christian Mauderer:

Hello Stefan,

On 07/02/2021 19:31, Stefan Akatyschew wrote:

Hey Christian,
no problem, thanks a lot for your reply!
Here it starts, right after loading the elf file:
Just to be sure there is no mistake in my setup, I attached the 
complete listing shown (start.S), as well as my .cmm script to load 
the binary.

That looks like there is a bug in the setup of your debugger.

The i.MX7 BSP normally runs out of SDRAM. It expects to be started by a 
U-Boot on the i.MX7. If I understand your trace script correctly, it 
resets the board, then it loads the application. This will try to put 
the application into a SDRAM that is not yet initialized. It's a bit odd 
that Trace32 doesn't throw an error when you try to access the code there.

For boards with a boot loader (like U-Boot) I most of the time use the 
following approach:

- Make sure that there is an application that can be loaded by the boot 
loader (Linux Kernel, RTEMS application, ...)
- If the BSP needs an FDT (i.MX does need one): Make sure that one is 
loaded too.

In the debug script:

- Reset and halt the board
- Set a breakpoint at the location where the Kernel would start (in that 
case 0x8020; for Linux maybe 0x8000 - check the U-Boot output 
for that)
- Start the board and let it run till the breakpoint. This will execute 
the boot loader and let it do all the basic setup.

- Load the application for debugging.
- Let the CPU run.

I can take a look whether I have some debug script for an i.MX7 on my 
work PC tomorrow.

A simplified version of the script that I would try:

_FILE="path/to/app.exe"

global 

if ""==""
(
="1"

RESet
SYStem.RESet
SYStem.CPU IMX7DUAL-CA7
SYStem.Option ResBreak OFF
SYStem.Option WaitReset 30.0ms
SYStem.JtagClock CTCK 10MHz
CORE.ASSIGN 1.
)

break.IMPLEMENTATION PROGRAM ONCHIP
sys.mode down
sys.mode up
go.direct
wait 1s
Break.direct
go 0x80004000; You most likely have to adapt that based on what
 ; your U-Boot currently loads.
wait !run()

data.load "_FILE"
break.set _Terminate

enddo

Best regards

Christian

Another question, I wonder why when I run waf configure, it tells me 
"Checking for RTEMS_SMP  : no", when I built my 
BSP with the option "--with-rtems-smp"?

--with-rtems-smp was for the old make based build system. For the waf 
based one I think you have to set RTEMS_SMP = True in the config.ini.

Where did you find the --with-rtems-smp switch? It's quite possible that 
there is a  there a bug in the documentation?

On this occasion also, in case you missed it, the ssl certificate for 
ftp.rtems.org expired a few days ago.

I forwarded the information to our internal list. There has been just 
recently a certificate update for devel.rtems.org. Most likely the 
ftp.rtems.org has been missed.

Best regards

Christian

Kind regards,
Stefan

On Feb 6 2021, at 12:38 pm, Christian Mauderer  wrote:

    Hello Stefan,

    sorry for not answering earlier. I somehow missed the mail.

    On 02/02/2021 18:02, Stefan Akatyschew wrote:
 > Hey together!
 >
 > I'm new to RTEMS and just hit some errors, I just can't figure 
out.

 > Since I will probably lure around a bit longer, I wanted to give
    short
 > introduction, so you can estimate what to expect from me: I'm a
 > nearly-finished(tm) EE undergrad from Germany, not having any
    hands-on
 > experience on RTOS, my embedded knowledge is confined to some 
hobby
 > STM32/PIC projects and the usual microcontroller stuff they 
teach at

 > uni. Not a great starting point for something as advanced as
    RTEMS, I'm
 > aware, but I'm eager to learn it. Besides embedded stuff I'm also
    into
 > the RF electronics :)

    It's not a too bad starting point either. It's quite similar to 
the one

    I had when I had my first contact with RTEMS.

 > Goal of my engagement with RTEMS: Setting up a small SMP Demo
 > Application on the Phytec Zeta i.MX7d Board
 > 
https://www.phytec.eu/product-eu/single-board-computer/phyboard-zeta/

 > for a university project, though after getting to know RTEMS, I
    hope to
 > be able to stick around after that, the applications in
    (aero)space, are
 > exactly what I'm passionate about! Also I hope after I get to run
 > everything, I can compile and publish my 
documentation/experience to

 > help others with the i.MX 7, since the road has been rather rocky
    for me
 > now.
 >

    I hope I didn't add too much stones to the road. I worked quite a 
bit on

    the imx BSP when I added i.MX 6 and some of the changes haven't been
    extensively tested on i.MX 7.

 >
 > So to my actual problem: I hav

Re: Trouble with addr_abort exception on arm/imx7 BSP with simple RTEMS code

2021-02-07 Thread Christian Mauderer

Hello Stefan,

On 07/02/2021 19:31, Stefan Akatyschew wrote:

Hey Christian,
no problem, thanks a lot for your reply!
Here it starts, right after loading the elf file:
Just to be sure there is no mistake in my setup, I attached the complete 
listing shown (start.S), as well as my .cmm script to load the binary.

That looks like there is a bug in the setup of your debugger.

The i.MX7 BSP normally runs out of SDRAM. It expects to be started by a 
U-Boot on the i.MX7. If I understand your trace script correctly, it 
resets the board, then it loads the application. This will try to put 
the application into a SDRAM that is not yet initialized. It's a bit odd 
that Trace32 doesn't throw an error when you try to access the code there.

For boards with a boot loader (like U-Boot) I most of the time use the 
following approach:

- Make sure that there is an application that can be loaded by the boot 
loader (Linux Kernel, RTEMS application, ...)
- If the BSP needs an FDT (i.MX does need one): Make sure that one is 
loaded too.

In the debug script:

- Reset and halt the board
- Set a breakpoint at the location where the Kernel would start (in that 
case 0x8020; for Linux maybe 0x8000 - check the U-Boot output 
for that)
- Start the board and let it run till the breakpoint. This will execute 
the boot loader and let it do all the basic setup.

- Load the application for debugging.
- Let the CPU run.

I can take a look whether I have some debug script for an i.MX7 on my 
work PC tomorrow.

Another question, I wonder why when I run waf configure, it tells me 
"Checking for RTEMS_SMP  : no", when I built my BSP 
with the option "--with-rtems-smp"?

--with-rtems-smp was for the old make based build system. For the waf 
based one I think you have to set RTEMS_SMP = True in the config.ini.

Where did you find the --with-rtems-smp switch? It's quite possible that 
there is a  there a bug in the documentation?

On this occasion also, in case you missed it, the ssl certificate for 
ftp.rtems.org expired a few days ago.

I forwarded the information to our internal list. There has been just 
recently a certificate update for devel.rtems.org. Most likely the 
ftp.rtems.org has been missed.

Best regards

Christian

Kind regards,
Stefan

On Feb 6 2021, at 12:38 pm, Christian Mauderer  wrote:

Hello Stefan,

sorry for not answering earlier. I somehow missed the mail.

On 02/02/2021 18:02, Stefan Akatyschew wrote:
 > Hey together!
 >
 > I'm new to RTEMS and just hit some errors, I just can't figure out.
 > Since I will probably lure around a bit longer, I wanted to give
short
 > introduction, so you can estimate what to expect from me: I'm a
 > nearly-finished(tm) EE undergrad from Germany, not having any
hands-on
 > experience on RTOS, my embedded knowledge is confined to some hobby
 > STM32/PIC projects and the usual microcontroller stuff they teach at
 > uni. Not a great starting point for something as advanced as
RTEMS, I'm
 > aware, but I'm eager to learn it. Besides embedded stuff I'm also
into
 > the RF electronics :)

It's not a too bad starting point either. It's quite similar to the one
I had when I had my first contact with RTEMS.

 > Goal of my engagement with RTEMS: Setting up a small SMP Demo
 > Application on the Phytec Zeta i.MX7d Board
 > https://www.phytec.eu/product-eu/single-board-computer/phyboard-zeta/
 > for a university project, though after getting to know RTEMS, I
hope to
 > be able to stick around after that, the applications in
(aero)space, are
 > exactly what I'm passionate about! Also I hope after I get to run
 > everything, I can compile and publish my documentation/experience to
 > help others with the i.MX 7, since the road has been rather rocky
for me
 > now.
 >

I hope I didn't add too much stones to the road. I worked quite a bit on
the imx BSP when I added i.MX 6 and some of the changes haven't been
extensively tested on i.MX 7.

 >
 > So to my actual problem: I have the before mentioned i.MX 7d
Board and a
 > Lauterbach Power Debug Interface with trace32, to directly flash my
 > binaries onto the SRAM. I'm using their i.MX7d SABRE
configuration file,
 > which successfully worked with their sample binary and slightly
modified
 > it (mainly deactivating ETF on-chip tracing).
 >
 > I've built the RTEMS 5 toolchain according to your quick-start
guide (
 > https://docs.rtems.org/branches/master/user/start/index.html),
with some
 > slight modifications arm/imx7 on my Ubuntu 18.04 VM (kernel built
from
 > sources, somehow didn't work otherwise). I also built the
simplest demo
 > application from 2.7, which went

Re: Trouble with addr_abort exception on arm/imx7 BSP with simple RTEMS code

2021-02-06 Thread Christian Mauderer


Hello Stefan,

sorry for not answering earlier. I somehow missed the mail.

On 02/02/2021 18:02, Stefan Akatyschew wrote:

Hey together!

I'm new to RTEMS and just hit some errors, I just can't figure out. 
Since I will probably lure around a bit longer, I wanted to give short 
introduction, so you can estimate what to expect from me: I'm a 
nearly-finished(tm) EE undergrad from Germany, not having any hands-on 
experience on RTOS, my embedded knowledge is confined to some hobby 
STM32/PIC projects and the usual microcontroller stuff they teach at 
uni. Not a great starting point for something as advanced as RTEMS, I'm 
aware, but I'm eager to learn it. Besides embedded stuff I'm also into 
the RF electronics :)


It's not a too bad starting point either. It's quite similar to the one 
I had when I had my first contact with RTEMS.


Goal of my engagement with RTEMS: Setting up a small SMP Demo 
Application on the Phytec Zeta i.MX7d Board 
https://www.phytec.eu/product-eu/single-board-computer/phyboard-zeta/ 
for a university project, though after getting to know RTEMS, I hope to 
be able to stick around after that, the applications in (aero)space, are 
exactly what I'm passionate about! Also I hope after I get to run 
everything, I can compile and publish my documentation/experience to 
help others with the i.MX 7, since the road has been rather rocky for me 
now.




I hope I didn't add too much stones to the road. I worked quite a bit on 
the imx BSP when I added i.MX 6 and some of the changes haven't been 
extensively tested on i.MX 7.




So to my actual problem: I have the before mentioned i.MX 7d Board and a 
Lauterbach Power Debug Interface with trace32, to directly flash my 
binaries onto the SRAM. I'm using their i.MX7d SABRE configuration file, 
which successfully worked with their sample binary and slightly modified 
it (mainly deactivating ETF on-chip tracing).


I've built the RTEMS 5 toolchain according to your quick-start guide ( 
https://docs.rtems.org/branches/master/user/start/index.html), with some 
slight modifications arm/imx7 on my Ubuntu 18.04 VM (kernel built from 
sources, somehow didn't work otherwise). I also built the simplest demo 
application from 2.7, which went without problems (well, after many 
hours of troubleshooting stupid mistakes). Now after flashing the binary 
directly to the SRAM with my Lauterbach Debugger (without RTEMS OS 
Awareness yet), I end up in the exception routine 
"_ARMV4_Exception_data_abort_default", with the following 
call-tree-hierarchy:




Can you hit "Up" once and take a look at the code location and send a 
screen shot. Best thing would be the mode that shows assembler 
istructions too. And maybe the window with the CPU registers.


Best regards

Christian

I also tried removing the printf (just letting it count an integer up 
and overflow), since I was confused why RTEMS would call a uart_write 
function otherwise, but that didn't change anything and actually doesn't 
even get to the Init rtems_task.


I already looked on the internet, the documentation and the mailing-list 
archive for help (not nearly finished reading through the complete 
Classic API Guide and User Manual, that'll take some time). 
Unfortunately I'm also new to the Lauterbach Debugger, which seems to be 
a beast of its own, so I unfortunately can't provide any useful on-chip 
trace data yet. I hope anyone can point me to the, probably rather 
obvious, mistake I'm making, any help is appreciated!



Last but not least, thanks for your awesome work on RTEMS!

Kind regards,
Stefan


Attached some maybe useful outputs:

stefan@rtems-vm:~$ arm-rtems5-gcc --version
arm-rtems5-gcc (GCC) 7.5.0 20191114 (RTEMS 5, RSB 5.1, Newlib 7947581)

./waf configure --rtems=$HOME/rtems/5 --rtems-bsp=arm/imx7
Setting top to   : 
/home/stefan/VCS/rtems-bp/first-test
Setting out to   : 
/home/stefan/VCS/rtems-bp/first-test/build

RTEMS Version    : 5
Architectures    : arm-rtems5
Board Support Package (BSP)  : arm-rtems5-imx7
Show commands    : no
Long commands    : no
Checking for program 'arm-rtems5-gcc'    : 
/home/stefan/rtems/5/bin/arm-rtems5-gcc
Checking for program 'arm-rtems5-g++'    : 
/home/stefan/rtems/5/bin/arm-rtems5-g++
Checking for program 'arm-rtems5-gcc'    : 
/home/stefan/rtems/5/bin/arm-rtems5-gcc
Checking for program 'arm-rtems5-ld' : 
/home/stefan/rtems/5/bin/arm-rtems5-ld
Checking for program 'arm-rtems5-ar' : 
/home/stefan/rtems/5/bin/arm-rtems5-ar
Checking for program 'arm-rtems5-nm' : 
/home/stefan/rtems/5/bin/arm-rtems5-nm
Checking for program 'arm-rtems5-objdump' : 
/home/stefan/rtems/5/bin/arm-rtems5-objdump
Checking for program 'arm-rtems5-objcopy' : 
/home/stefan/rtems/5/bin/arm-rtems5-objcopy
Checking for program 'arm-rtems5-readelf' : 
/home/stefan/rtems/5/bin/arm-rtems5-readelf
Checking for program

Re: RTEMS SMP support for XEN BSP

2021-01-25 Thread Christian MAUDERER


Hallo Amirhossein,

Am 21.01.21 um 07:18 schrieb amir taghavi:

Hello,

It seems that SMP is not supported on XEN BSP, so I want to know why 
this feature is not implemented for this BSP.


Short answer: Most likely no one needed it yet. Therefore no one 
implemented or tested it.


I had a look at the XEN BSP: It has been added by Jeff Kubascik end of 
2019. He didn't seem to be very active since then but I added the mail 
address he used for the commits back then on CC so maybe he will provide 
some more information.



And if it's possible, can anyone help me with enabling or implementing it?


What did you try to enable it?

A clean way would be to check what startup code is used, whether there 
are some special drivers that might make problems and so on. But from a 
first glance, the BSP doesn't seem to use too much special stuff. So you 
might want to just try to turn on RTEMS_SMP during configuration and see 
what happens.


Best regards

Christian



best regards
Amirhossein

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



--

embedded brains GmbH
Herr Christian MAUDERER
Dornierstr. 4
82178 Puchheim
Germany
email: christian.maude...@embedded-brains.de
phone: +49-89-18 94 741 - 18
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users

Re: libbsd: "swi6: Giant task queue" suspend if removing SD Card

2021-01-07 Thread Christian Mauderer


Hello RUI Zhengxin,

On 07/01/2021 04:43, RUI Zhengxin wrote:

Hi all,
We find "swi6: Giant task queue" suspend if removing SD Card.
libbsd5.1 is running at beagle bone hardware, the sdhci driver is 
attached success.
*sdhci_ti0:  mem 0x4809c000-0x4809c3ff irq 78,4 on 
simplebus0*

*mmc0:  on sdhci_ti0*
The console show the message when removing sd card
*emerg: mmcsd_detach: FIXME*


Like the message suggests: Removing SD cards is currently not 
implemented. The part of the subsystem is just removed and replaced by a 
BSD_PANIC("FIXME"). It's a bit back since I last touched that subsystem 
but if I remember correctly, it would be quite a bit of work to add that 
support.


Best regards

Christian



the task state is show by task command

SHLL [/] # task
ID       NAME                 SHED PRI STATE  MODES    EVENTS WAITINFO
--
0a010002 BSWP                 UPD  250 EV     P:T:nA   NONE
0a010003 BRDA                 UPD   15 EV     P:T:nA   NONE
0a010004 MDIA                 UPD  200 EV     P:T:nA   NONE
0a010005 TIME                 UPD    8 MTX    P:T:nA   NONE   Giant
0a010006 IRQS                 UPD    6 SYSEV  P:T:nA   NONE
0a010007 _BSD swi6: task queu UPD   10 EV     P:T:nA   NONE
0a010008 _BSD swi5: fast task UPD   10 EV     P:T:nA   NONE
0a010009 _BSD config_0        UPD   10 WK     P:T:nA   NONE   -
0a01000a _BSD thread taskq    UPD   10 WK     P:T:nA   NONE   -
0a01000b _BSD swi6: Giant tas UPD    8 *SUSP*   P:T:nA   NONE

In this case, if we excute the ifconfig command, the shell is hang.
SHLL [/] #
SHLL [/] # ifconfig

We log the board by telnet, the task state is:
TLNT [/] # task
ID       NAME                 SHED PRI STATE  MODES    EVENTS WAITINFO
--
0a010002 BSWP                 UPD  250 EV     P:T:nA   NONE
0a010003 BRDA                 UPD   15 EV     P:T:nA   NONE
0a010004 MDIA                 UPD  200 EV     P:T:nA   NONE
0a010005 TIME                 UPD    8 MTX    P:T:nA   NONE   Giant
0a010006 IRQS                 UPD    6 SYSEV  P:T:nA   NONE
0a010007 _BSD swi6: task queu UPD   10 EV     P:T:nA   NONE
0a010008 _BSD swi5: fast task UPD   10 EV     P:T:nA   NONE
0a010009 _BSD config_0        UPD   10 WK     P:T:nA   NONE   -
0a01000a _BSD thread taskq    UPD   10 WK     P:T:nA   NONE   -
0a01000b _BSD swi6: Giant tas UPD    3 *SUSP*   P:T:nA   NONE
0a01000c _BSD kqueue_ctx task UPD   10 WK     P:T:nA   NONE   -
0a01000d _BSD swi1: netisr 0  UPD   10 EV     P:T:nA   NONE
0a01000e SCRx                 UPD   10 MSG    P:T:nA   NONE   22010001
0a01000f SCRx                 UPD   10 MSG    P:T:nA   NONE   22010002
0a010010 _BSD softirq_0       UPD   10 WK     P:T:nA   NONE   -
0a010011 SHLL                 UPD    3 *MTX*    P:T:nA   NONE   Giant

SHLL is hang for mutex is owned by swi6: task queu




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


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

Re: RTEMS Fatal Error on IMX7D SABRE Board.

2021-01-06 Thread Christian Mauderer


Hello,

On 06/01/2021 13:25, jameszxj wrote:

Hi,

 > Hello,
 >
 > On 06/01/2021 10:04, jameszxj wrote:
 > > Hi,
 > >
 > > I can't find "timer" node in your devicetree.
 > > Function arm_generic_timer_get_config() in file bspstart.c will find
 > > node "/timer"
 > > and get "clock-frequency" value for system tick.
 >
 > note that at least the clock-frequency is added by U-Boot on the i.MX7
 > during boot and is not in the typical device tree sources.
 >
 > On i.MX6UL/ULL there is still an ugly hack necessary:
 >
 > 
https://github.com/grisp/rtems/commit/02270d5ec82684007ae9973070a6f29428be1543

 >
 > It's on my TODO-list to avoid that patch, but I haven't done that yet.
 >

I add the timer_init in bsp, but the tick interrupt still seems pending.
When I type something in shell, ticks will come.


Sounds like some low power mode. I would suggest to check the settings 
in the CCM. Check whether the system enters low power mode on a WFI 
instruction and disable that feature. Especially interesting would be 
the CCM_CLPCR.MASK_CORE0_WFI and similar bits. If these seem to be 
correct, I would check the CCGR* registers.




 > >
 > > -- Original --
 > > *From:* "JunBeom Kim (EmbedCoreTech)" ;
 > > *Date:* Wed, Jan 6, 2021 04:46 PM
 > > *To:* "'jameszxj'";"'users'";
 > > *Subject:* RE: RTEMS Fatal Error on IMX7D SABRE Board.
 > >
 > > Dear James,
 > >
 > > As I know before, because this BSP is tested on Phytec??s 
PhyBOARD-i.MX7

 > > board, I am considering to purchase this board, too.
 >
 >
 > The last test on that board is some time back because I currently don't
 > have access to it (working from home). So also I would hope it, I
 > wouldn't guarantee that it runs out of the box.
 >

thanks.

 >
 > >
 > > Best Regards,
 > >
 > > JunBeom
 > >
 > > *From:*JunBeom Kim (EmbedCoreTech) 
 > > *Sent:* Wednesday, January 6, 2021 5:39 PM
 > > *To:* 'jameszxj' ; 'users' 
 > > *Subject:* RE: RTEMS Fatal Error on IMX7D SABRE Board.
 > >
 > > Dear James,
 > >
 > > I used two files(imx7d-sdb.dts and imx7d.dtsi) for making 
imx7d-sdb.dtb.

 > >
 > > There is clock-frequency configuration in imx7d.dtsi.
 > >
 >
 >
 > Again: Normally U-Boot should add that clock-frequency.
 >
 >
 > > Best Regards,
 > >
 > > JunBeom
 > >
 > > *From:*users >

 > > *On Behalf Of *jameszxj
 > > *Sent:* Wednesday, January 6, 2021 4:13 PM
 > > *To:* users mailto:users@rtems.org>>
 > > *Subject:* Re:RTEMS Fatal Error on IMX7D SABRE Board.
 > >
 > > Hi,
 > > I use IMX7 bsp on my imx6ull board. I have encountered maybe the same
 > > problem. Please check your device-tree, BSP needs "clock-frequency" at
 > > node "timer".
 >
 > Do you use an i.MX6ULL with U-Boot or Barebox? They might have slightly
 > different behavior regarding the timer.
 >

I use barebox.


OK. Barebox definitively doesn't initialize the timer. Odd thing is that 
I don't remember that it switches on a power save mode. But maybe 
something changed in a more recent version ...


Best regards

Christian



 > >
 > > But I encountered another problems, theARMv7-AR Generic Timercan not
 > > generate interrupt.
 > > imx7d has the same core with imx6ull??if your board run RTEMS
 > > successfully, please let me know, thanks.
 >
 > As you might have seen above, I'm using the BSP on i.MX6ULL based
 > boards. The board uses Phytec Phycore i.MX6UL/ULL modules (different
 > variants in different projects). One of the projects is an open source
 > one and you can find all sources at:
 >
 >?0?2 ?0?2 ?0?2 https://github.com/grisp/grisp2-rtems-toolchain
 >
 > >
 > > -- Original --
 > >
 > > *From:*"JunBeom Kim (EmbedCoreTech)"  > >;
 > >
 > > *Date:*Wed, Jan 6, 2021 01:05 PM
 > >
 > > *To:*"users"mailto:users@rtems.org>>;
 > >
 > > *Subject:*RTEMS Fatal Error on IMX7D SABRE Board.
 > >
 > > Hello,
 > >
 > > After I purchased i.MX7D SABRE board, I am trying to test RTEMS 
kernel using

 > > lastest RTEMS kernel and source builder for RTEMS 6.0
 > >
 > > As I knew before, RTEMS BSP for i.MX7D was not tested for i.MX7D SABRE
 > > board.
 > >
 > > When I tested this, my testing result is in below;
 > >  rtems.img is made by calling mkimage.
 > >
 > > At this time, I am trying to debug RTEMS BSP using GDB with J-Link 
probe.
 > > There is problem for executing start.S assembly code as source code 
level.

 >
 > Can you try to set a breakpoint on at least _Terminate and do a
 > backtrace (bt in gdb)? I think the _ARM_Exception_default could be a
 > useful one too.
 >
 > Best regards
 >
 > Christian
 >
 >
 > >
 > > Please advise me.
 > >
 > > ~
 > > U-Boot 2020.10 (Jan 05 2021 - 09:44:38 +0900)
 > >
 > > CPU:Freescale i.MX7D rev1.3 1000 MHz (running at 792 MHz)
 > > CPU:Commercial temperature grade (0C to 95C) at 38C
 > > Reset cause: POR
 > > Model: Freescale i.MX7 SabreSD Board
 > > Board: i.MX7D SABRESD in non-secure mode
 > >

Re: RTEMS Fatal Error on IMX7D SABRE Board.

2021-01-06 Thread Christian Mauderer


Hello,

On 06/01/2021 10:04, jameszxj wrote:

Hi,

I can't find "timer" node in your devicetree. 
Function arm_generic_timer_get_config() in file bspstart.c will find 
node "/timer"

and get "clock-frequency" value for system tick.


note that at least the clock-frequency is added by U-Boot on the i.MX7 
during boot and is not in the typical device tree sources.


On i.MX6UL/ULL there is still an ugly hack necessary:

https://github.com/grisp/rtems/commit/02270d5ec82684007ae9973070a6f29428be1543

It's on my TODO-list to avoid that patch, but I haven't done that yet.



-- Original --
*From:* "JunBeom Kim (EmbedCoreTech)" ;
*Date:* Wed, Jan 6, 2021 04:46 PM
*To:* "'jameszxj'";"'users'";
*Subject:* RE: RTEMS Fatal Error on IMX7D SABRE Board.

Dear James,

As I know before, because this BSP is tested on Phytec’s PhyBOARD-i.MX7 
board, I am considering to purchase this board, too.



The last test on that board is some time back because I currently don't 
have access to it (working from home). So also I would hope it, I 
wouldn't guarantee that it runs out of the box.





Best Regards,

JunBeom

*From:*JunBeom Kim (EmbedCoreTech) 
*Sent:* Wednesday, January 6, 2021 5:39 PM
*To:* 'jameszxj' ; 'users' 
*Subject:* RE: RTEMS Fatal Error on IMX7D SABRE Board.

Dear James,

I used two files(imx7d-sdb.dts and imx7d.dtsi) for making imx7d-sdb.dtb.

There is clock-frequency configuration in imx7d.dtsi.




Again: Normally U-Boot should add that clock-frequency.



Best Regards,

JunBeom

*From:*users mailto:users-boun...@rtems.org>> 
*On Behalf Of *jameszxj

*Sent:* Wednesday, January 6, 2021 4:13 PM
*To:* users mailto:users@rtems.org>>
*Subject:* Re:RTEMS Fatal Error on IMX7D SABRE Board.

Hi,
I use IMX7 bsp on my imx6ull board. I have encountered maybe the same 
problem. Please check your device-tree, BSP needs "clock-frequency" at 
node "timer".


Do you use an i.MX6ULL with U-Boot or Barebox? They might have slightly 
different behavior regarding the timer.




But I encountered another problems, theARMv7-AR Generic Timercan not 
generate interrupt.
imx7d has the same core with imx6ull，if your board run RTEMS 
successfully, please let me know, thanks.


As you might have seen above, I'm using the BSP on i.MX6ULL based 
boards. The board uses Phytec Phycore i.MX6UL/ULL modules (different 
variants in different projects). One of the projects is an open source 
one and you can find all sources at:


https://github.com/grisp/grisp2-rtems-toolchain



-- Original --

*From:*"JunBeom Kim (EmbedCoreTech)" >;


*Date:*Wed, Jan 6, 2021 01:05 PM

*To:*"users"mailto:users@rtems.org>>;

*Subject:*RTEMS Fatal Error on IMX7D SABRE Board.

Hello,

After I purchased i.MX7D SABRE board, I am trying to test RTEMS kernel using
lastest RTEMS kernel and source builder for RTEMS 6.0

As I knew before, RTEMS BSP for i.MX7D was not tested for i.MX7D SABRE
board.

When I tested this, my testing result is in below;
 rtems.img is made by calling mkimage.

At this time, I am trying to debug RTEMS BSP using GDB with J-Link probe.
There is problem for executing start.S assembly code as source code level.


Can you try to set a breakpoint on at least _Terminate and do a 
backtrace (bt in gdb)? I think the _ARM_Exception_default could be a 
useful one too.


Best regards

Christian




Please advise me.

~
U-Boot 2020.10 (Jan 05 2021 - 09:44:38 +0900)

CPU:Freescale i.MX7D rev1.3 1000 MHz (running at 792 MHz)
CPU:Commercial temperature grade (0C to 95C) at 38C
Reset cause: POR
Model: Freescale i.MX7 SabreSD Board
Board: i.MX7D SABRESD in non-secure mode
DRAM:1 GiB
PMIC: PFUZE3000 DEV_ID=0x30 REV_ID=0x11
MMC:FSL_SDHC: 0, FSL_SDHC: 1, FSL_SDHC: 2
Loading Environment from MMC... *** Warning - bad CRC, using default
environment

Video: 480x272x24
In:serial
Out:serial
Err:serial
Hit any key to stop autoboot:0

=> fatload mmc 0 0x8080 rtems.img
36463 bytes read in 23 ms (1.5 MiB/s)

=> fatload mmc 0 0x8300 imx7d-sdb.dtb
33369 bytes read in 22 ms (1.4 MiB/s)

=> bootm 0x8080 - 0x8300
## Booting kernel from Legacy Image at 8080 ...
Image Name:RTEMS
Image Type:ARM Linux Kernel Image (gzip compressed)
Data Size:36399 Bytes = 35.5 KiB
Load Address: 8020
Entry Point:8020
Verifying Checksum ... OK
## Flattened Device Tree blob at 8300
Booting using the fdt blob at 0x8300
Uncompressing Kernel Image
Using Device Tree in place at 8300, end 8300b258

Starting kernel ...


*** FATAL ***
fatal source: 6 (RTEMS_FATAL_SOURCE_BSP)
fatal code: 3072 (0x0c00)
RTEMS version: 6.0.0
RTEMS tools: 10.2.1 20201222 (RTEMS 6, RSB
d3dc0bc3861362978cdf65725e4ba2b64e283d32, Newlib 415fdd4)
Executing thread is NULL
~

Best Regards,
JunBeom Kim

___
users mailing list
users@rtems.org

Re: Advice on JTAG debugging RTEMS for ARM (beaglebone)

2020-12-29 Thread Christian Mauderer

On 29/12/2020 05:43, Chris Johns wrote:

On 29/12/20 3:24 pm, James Fitzsimons wrote:

Hi Chris,

Thanks very much for your reply and advice.

On Tue, 29 Dec 2020 at 11:58, Chris Johns mailto:chr...@rtems.org>> wrote:

 > I'm using TI Code Composer Studio to load the RTEMS application image via
 XDS100
 > V3.0 debugger. If I reset the program counter and step through the 
startup
 code
 > I see it error on the bsp_fdt_get() call.

 Is this a crash or is an error reported? We should report an error and not
 crash.

Neither - the processor continues running, just not executing anything useful.

 > My IDE isn't copying an fdt image to the expected location the way uboot
 would,
 > and so this makes sense. My question is how do other people get around
 this problem?
 >
 > Has anyone else used a similar setup and solved this issue?

 I have not hit this issue but I saw this as a problem with the approach 
taken of
 loading an FDT via the bootloader. It would have been nice to have a way to
 integrate an FDT into the IMFS (or executable) rather than an external 
load.

Agreed - this would make it much easier to debug things. Even just having this
as an option
to support debugging would be useful.

 Another approach is to boot using uboot and have it load the FDT and RTEMS
 executable then jump to it. If you can connect via JTAG, reset the 
processor,
 set a hardware break point on the entry point to RTEMS, and start the 
processor
 running from reset it should trigger when uboot jumps to RTEMS. The entry 
point
 is at a fixed address. When the breakpoint is hit delete it and then you 
can set
 further break points in your application.

Thanks for this suggestion - I've managed to get this working pretty much as you
described.
I build the SD card image and boot from that, then connect via JTAG, reset and
break on Init().
It's a pretty clunky process, but at least I have actual on device debugging
working now instead of
having to rely on printf debugging.

Excellent and thanks for reporting it back to us. Yes it is clunky however
anything else would need time spent adding IMFS support or directly linked in
support and no one has done that.

The imxrt BSP uses an FDT that is build into the binary. It should be 
possible to use a similar approach on custom applications for the BBB. 
To do that in an application I would expect that you have to do the 
following (I did not test it but it should work):

1. Convert the dtb that you want to use to a c file:

rtems-bin2c -C -N bbb_dtb path/to/your.dtb bbb_dtb.c

2. Compile that bbb_dtb.c in your application.

3. Add the following to your application (for example where you define 
the Init task):

-
#include 

extern const unsigned char bbb_dtb[];

void bsp_fdt_copy(const void *src)
{
/* Do nothing */
}

const void *bsp_fdt_get(void)
{
  return bbb_dtb;
}
--

Be aware of the licensing: The FDTs for BBB that I know are all GPL. So 
linking it in as a blob will most likely put your application under the 
terms of GPL.

The licensing is also the reason why I would have problems adding an FDT 
blob and an option to link it in directly to the RTEMS repository. If 
you have a FDT that is not GPL please let me know.

Best regards

Christian
___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users

Re: stm32h7 bsp - network driver for RTEMS legacy networking

2020-11-27 Thread Christian Mauderer

Hello John,

On 27/11/2020 18:43, John Nathen wrote:
> Hi,
> 
> I'm new to RTEMS and started playing with RTEMS on the STMH32H743ZI
> Nucleo board using the stm32h7 BSP a few weeks ago; I've got a few basic
> programs (LED Blink, console output...) to work on this board with minor
> changes in the configuration.
> 
> The network driver for this BSP is implemented for libbsd, but I want to
> use the RTEMS legacy networking due to memory constraints.
> 
> I've started to develop a networking driver that supports the RTEMS
> legacy networking but haven't made much progress as I'm new to RTEMS.
> 
> I was wondering if anyone has already done a driver implementation or
> has any suggestions or inputs on how to proceed.

Note that the STM32H7 BSP is one of the newest BSPs. I doubt that anyone
tried to use it with the legacy stack yet.

Please also note that there have already been some discussions whether
the legacy stack should be removed. See

  https://lists.rtems.org/pipermail/devel/2020-October/062611.html

for one of the latest. I don't think that it will be removed soon as
long as it don't make some trouble. But I would strongly advice against
starting a serious project with it.

If libbsd is really too heavy (did you try the minimal config by the
way?) you might should look into lwIP instead.

That said: If you still want to use the legacy stack, you might want to
try to just backport the libbsd driver. For that I would suggest to take
a look at some of the drivers that have been ported in the other
direction so you can find the differences. For example the if_atsam or
some of the ffec drivers:

  https://git.rtems.org/rtems-libbsd/tree/rtemsbsd/sys/dev/atsam/if_atsam.c
  https://git.rtems.org/rtems-libbsd/tree/rtemsbsd/sys/dev/ffec

The structure is quite similar between both stacks.

Best regards

Christian

> 
> Any help would be appreciated.
> 
> Best Regards,
> John
> 
> ___
> users mailing list
> users@rtems.org
> http://lists.rtems.org/mailman/listinfo/users
> 
___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users

Re: stm32h7 bsp - simple led blink example not working on stm32h7 nucleo board

2020-11-04 Thread Christian Mauderer

Hello John,

On 02/11/2020 10:46, John Nathen wrote:
> Hi,
> 
> I am new to rtems and am planning to use rtems on a project with the
> stm32h7 mcu. I cloned the latest sources from git and built the
> arm-rtems6, gcc 10.2 toolchain and also built the stm32h7 bsp using the
> new waf build system.
> 
> Everything works fine and I can build the (modified for stm32h7) LED
> blink example application. However, the resulting .bin file, after
> conversion from exe to bin using objcopy, does not work - no blinking led.

Which LED sample is that? I assume one of the examples in rtems-examples?

https://git.rtems.org/rtems-examples/tree/led

If yes: The samples in that directory only implements the LED for some
boards. It defaults to just printing "LED ON" and "LED_OFF" for all
other boards. If you take a look at

https://git.rtems.org/rtems-examples/tree/led/led.h

stm32f4 has an implementation. But stm32h7 does not. So maybe take a
look at the console output whether "LED ON" and "LED OFF" is printed.

Best regards

Christian

> 
> I then decided to try the stm32f4 discovery board:
> If I use the rtems5.1 release version with arm-rtems5, gcc 7.5 and the
> configure based build system, I can get the led to blink on this board.
> It also works even if I clone the latest rtems source and use the
> configure based system with arm-rtems5.
> 
> If I use the latest master with arm-rtems6, gcc 10.2 and build the
> stm32f4 bsp using the new waf build system, the led blink example does
> NOT work!
> 
> I then tried to 'force' rsb to build arm-rtems6 using the gcc 7.5 and
> tried to build the stm32f4 bsp using waf. This resulted in a number of
> linker errors - multiple definition of __getreent  _Semaphore_Wait and a
> few others. Also, undefined reference to _init and so on.
> 
> I tried to solve it based on the suggestions given for the __getreent
> (crt0.o issue). But still get a number of errors.
> 
> I am hoping to get some suggestions on how to proceed further.
> 
> Thanks in advance.
> 
> John
> 
> 
> ___
> users mailing list
> users@rtems.org
> http://lists.rtems.org/mailman/listinfo/users
> 
___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users

Re: RTEMS 5.1 documentation in docs.rtems.org

2020-10-28 Thread Christian Mauderer

Hello Jan,

On 28/10/2020 07:51, jan.som...@dlr.de wrote:
> Hello,
> 
> If colleagues have RTEMS related questions, I like to direct them to 
> docs.rtems.org to read the fine manual.
> I noticed that in the releases section of the page 5.1 is not yet included.

You are right that there seem to be some missing links on the "All
Releases" section and for the 5 branch. To be honest: I have no idea
where that would have to fixed.

> Since with the work on RTEMS 6 the active branch documentation is diverging, 
> could you please also add the 5.1 documentation there?

If you need something urgently: If you click on the "Latest Release
Manuals" on the rtems.org start page, you reach the documentation for
5.1 that is saved on ftp.rtems.org:

  https://ftp.rtems.org/pub/rtems/releases/5/5.1/docs/html/

Best regards

Christian

> 
> Best regards,
> 
>  Jan
> 
> 
> 
> Deutsches Zentrum für Luft- und Raumfahrt e. V. (DLR)
> German Aerospace Center
> Institute for Software Technology | Software for Space Systems and 
> Interactive Visualization | Lilienthalplatz 7 | 38108 Braunschweig | Germany
> 
> Jan Sommer
> Telephone +49 531 295-2494 | Telefax 0531 295-2767 | jan.som...@dlr.de
> DLR.de/SC
> 
> ___
> users mailing list
> users@rtems.org
> http://lists.rtems.org/mailman/listinfo/users
> 

-- 

embedded brains GmbH
Herr Christian Mauderer
Dornierstr. 4
D-82178 Puchheim
Germany
email: christian.maude...@embedded-brains.de
Phone: +49-89-18 94 741 - 18
Fax:   +49-89-18 94 741 - 08
PGP: Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users

Re: How to use lvgl on pc386 BSP.

2020-09-09 Thread Christian Mauderer

On 09/09/2020 06:16, Chris Johns wrote:
> On 9/9/20 3:45 am, jan.som...@dlr.de wrote:
>> They got a bit delayed due to the work for the RTEMS5 release and because 
>> there were some discussions about branch naming for FreeBSD.
> 
> Are the patches OK? Maybe a post to devel to list what is needed and I can 
> take
> a look. I have lost track of what is where.

Hello Chris,

I think we are loosing more than one patch. Maybe we should start
thinking about some kind of patch tracking or pull request system. I'll
start a thread on devel for further discussion.

Best regards

Christian

> 
> Thanks
> Chris
> 

-- 
----
embedded brains GmbH
Herr Christian Mauderer
Dornierstr. 4
D-82178 Puchheim
Germany
email: christian.maude...@embedded-brains.de
Phone: +49-89-18 94 741 - 18
Fax:   +49-89-18 94 741 - 08
PGP: Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users

Re: How to use lvgl on pc386 BSP.

2020-09-07 Thread Christian Mauderer

Hello Karel,

On 07/09/2020 11:33, Karel Gardas wrote:
> On 9/7/20 11:22 AM, Christian Mauderer wrote:
>> Hello Karel,
>>
>> note that rtems-littlevgl is still quite new and most likely _only_ used
>> on BBB and (with an external display driver) on the imx. I don't think
>> anyone tried it on pc686.
> 
> Yes, I'm kind of aware of that.
> 
>> On 07/09/2020 11:06, Karel Gardas wrote:
>>>
>>> Hello,
>>>
>>> I'm trying to compile rtems-littlevgl on pc686 BSP from RTEMS 5.1
>>> release built with RSB -- hence with libbsd compiled in.
>>>
>>> I'm hitting following compilation failure:
>>>
>>> ../../lv_drivers/indev/evdev.c:16:10: fatal error: dev/evdev/input.h: No
>>> such file or directory
>>>  #include 
>>>   ^~~
>>> compilation terminated.
>>>
>>
>> I checked the evdev/input.h. That one should definitively be there if
>> libbsd is installed. There is no condition for that file. Are you sure
>> that libbsd is compiled and installed correctly? To check that please
>> make sure that "libbsd.a" in the $PREFIX/i386-rtems5/pc686/lib directory
>> exists.
> 
> 
> $ ls -la sfw/rtems/5.1/i386-rtems5/pc686/lib/libbsd.a
> -rw-r--r-- 1 karel karel 104094278 Aug 31 19:57
> sfw/rtems/5.1/i386-rtems5/pc686/lib/libbsd.a
> karel@silence:~$ find sfw/rtems/5.1 -name 'input.h'
> karel@silence:~$
> 
> so looks like libbsd for BBB and for pc686 is really a bit different.

I have analyzed a bit more:

We have two main libbsd branches:

- master
- 6-freebsd-12

Same for the release. There it is

- 5
- 5-freebsd-12

The first one tracks the latest FreeBSD development branch. The later
one tracks the stable FreeBSD 12 branch.

It seems that the evdev stuff is only on the first branch (master and
5). So if you compiled 5-freebsd-12 (which is not unlikely - I would
recommend that for application development) the evdev support is _not_
there. That's exactly what you see.

Depending on your application, you might want to think about switching
to the current master instead of the release. But note that I didn't
compile the PC BSP there. So I'm not sure how well it works. i386 is
normally not a platform that I use for RTEMS applications.

Best regards

Christian

> 
>>> when I disable USE_BSD_EVDEV in build/i386-rtems5-pc686/lv_drv_conf.h I
>>> hit following error:
>>>
>>> ../../lv_drivers/display/fbdev.c:23:10: fatal error: sys/consio.h: No
>>> such file or directory
>>>  #include 
>>>   ^~
>>> compilation terminated.
>>>
>>
>> Do you need the input devices? Or the libbsd framebuffer? Or only one of
>> them?
> 
> I'm just playing with RTEMS stuff on PC. The hope is to get grab of the
> platform in order to create some nice demo in Haskell -- which port is
> slowly progressing.
> 
> So yes, first framebuffer output would be nice to have and then
> including input devices. Testing on PCs, notebooks with their keyboards
> and touchpads/trackpoints and desktop PC with USB keyboard/mouse and if
> that's not supported well, then even with PS/2 keyboard/mouse.
> 
>> There is an option to compile without drivers in case you have a custom
>> display connected. 
> 
> I'm hoping in standard VESA framebuffer on pc686 BSP to work well for this.
> 
> Thanks,
> Karel
> ___
> users mailing list
> users@rtems.org
> http://lists.rtems.org/mailman/listinfo/users
> 
___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users

Re: How to use lvgl on pc386 BSP.

2020-09-07 Thread Christian Mauderer

Hello Karel,

note that rtems-littlevgl is still quite new and most likely _only_ used
on BBB and (with an external display driver) on the imx. I don't think
anyone tried it on pc686.

On 07/09/2020 11:06, Karel Gardas wrote:
> 
> Hello,
> 
> I'm trying to compile rtems-littlevgl on pc686 BSP from RTEMS 5.1
> release built with RSB -- hence with libbsd compiled in.
> 
> I'm hitting following compilation failure:
> 
> ../../lv_drivers/indev/evdev.c:16:10: fatal error: dev/evdev/input.h: No
> such file or directory
>  #include 
>   ^~~
> compilation terminated.
> 

I checked the evdev/input.h. That one should definitively be there if
libbsd is installed. There is no condition for that file. Are you sure
that libbsd is compiled and installed correctly? To check that please
make sure that "libbsd.a" in the $PREFIX/i386-rtems5/pc686/lib directory
exists.

> 
> when I disable USE_BSD_EVDEV in build/i386-rtems5-pc686/lv_drv_conf.h I
> hit following error:
> 
> ../../lv_drivers/display/fbdev.c:23:10: fatal error: sys/consio.h: No
> such file or directory
>  #include 
>   ^~
> compilation terminated.
> 

Do you need the input devices? Or the libbsd framebuffer? Or only one of
them?

There is an option to compile without drivers in case you have a custom
display connected. Like I said: It's still a quite new repository
therefore there are not yet a lot of combinations. We still have to find
out what's normally used.

Best regards

Christian

> 
> I've configured example with:
> 
> ./waf configure --prefix=$HOME/sfw/rtems/5.1 --rtems-bsp=i386/pc686
> 
> 
> Errors above makes me curious if libbsd for pc686 and libbsd build for
> beagle bone black are different as it looks like mine's (pc686) is
> missing some framebuffer related code. Please correct me if I'm wrong.
> 
> Thanks,
> Karel
> ___
> users mailing list
> users@rtems.org
> http://lists.rtems.org/mailman/listinfo/users
> 

-- 

embedded brains GmbH
Herr Christian Mauderer
Dornierstr. 4
D-82178 Puchheim
Germany
email: christian.maude...@embedded-brains.de
Phone: +49-89-18 94 741 - 18
Fax:   +49-89-18 94 741 - 08
PGP: Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users

Re: Fwd: JTAG error with arm-rtems-gdb

2020-06-18 Thread Christian Mauderer

Hello Mario,

On 18/06/2020 12:13, Mario Palomares wrote:
> Hello Christian,
> 
> What you say about cache invalidation problems makes sense, but i am not
> sure if that is muy problem since the debug messages give me some kind
> of error. Anyway i will ask again and see if someone answers.
> 
> In relation to SMP debugging with openOCD i haven´t tried it yet,
> nevertheless as far as i know by default openOCD sets one GDB server for
> each CPU so not sure how you could debug with one session all cores. I
> have seen that openOCD has an rtos support that would let you debug SMP
> applications, RTEMS is not in the list of supported RTOS but there is a
> generic RTOS that could do the trick
> 
> -rtos hwthread

I haven't really tested out multi core debugging with OpenOCD on RPi or
a similar system. But when you mentioned hwthreads: I remember that I
had some other gdb server once that was using that and it worked quite
well. So maybe it's a good direction in case you want to do SMP debugging.

Best regards

Christian

> 
> ¿Is this the way you are proceeding?
> 
> Pavel, i have included you in the thread since i saw you managed to
> debug programs on the RPI through JTAG. To sum up all previous messages
> just say that right know i have the JTAG conexion established and the
> GDB attached to it, but i can only set Hardware Breakpoints, Software
> breakpoints never get established, did you experienced this?. Christian
> suggests there can be some cache invalidation problems.
> 
> Regards,
> Mario
> 
> 
> El mar., 9 jun. 2020 a las 8:36, Christian Mauderer
> ( <mailto:christian.maude...@embedded-brains.de>>) escribió:
> 
> Hello Mario,
> 
> I haven't followed the whole thread. I'm sorry if I maybe ask some stuff
> that has been already mentioned.
> 
> On 05/06/2020 12:18, Mario Palomares wrote:
> > Hi again, i have finally achieved something
> >
> > Apparently the problems i had when connecting with GDB derived
> from the
> > OpenOCD version i had installed. I first tried to compile the code
> from
> > source but i got compilation errors and afer a while looking for the
> > error i gave up and install the binaries from apt. The versión of
> apt is
> > a little old and gave me some errors with some newer commands so I
> > installed the xpack version. That one was up to date but gave me the
> > error i mentioned with GDB.
> > In order to apply some patched the openOCD users recommended me i
> had to
> > solve the compilation issue. In the end the problem was that i had the
> > RTEMS toolchain path the at the beggining of my PATH env
> variable. Since
> > openOCD requires autotools for compiling, it was using the first
> > automake it encunters on that, the one generated by the RSB and that
> > automake version is too old for the compilaiton of OpenOCD.  So in
> case
> > anybody tires, add the RTEMS toolchain path at the end.
> 
> With the RTEMS toolchain at the end you might have problems compiling
> some RTEMS stuff. I normally use a script to set up an environment just
> for RTEMS. The script sets the PATH, changes the prompt (that I see it's
> an RTEMS-environment) and starts a new shell.
> 
> >
> > Don´t know why but the autocompiled openOCD version (even without the
> > patches) works well with GDB and the connection is established
> > correctly. I have debugged some bare metal programs without problems.
> > But there is just one problem/limitaiton, in the case of RTEMS
> > executables, i am only able to debug the program with Hardware
> > Breakpoints but software breakpoints won´t be established.
> 
> I had a simmilar problem once with another chip (ATSAME70 - Cortex-M7).
> After quite some time a colleague found out that OpenOCD had problems
> with the cache handling. The software breakpoint has been added but the
> cache hasn't been invalidated. With that the cached code didn't have a
> breakpoint. As a workarround I told openocd to fall back to hardware
> breakpoints with the following command in gdb:
> 
>     monitor gdb_breakpoint_override hard
> 
> > The
> > difference bettwen the RTEMS executable and my bare metal programs is
> > that i don´t switch back to SVC mode (i stay in HYP mode), and
> > obiously i don´t have an operating system. So right know i don´t
> know if
> > there is some kind of  memory protection by RTEMS or if there is some
> > limitation in OpenOCD with boards in SVC mode (i have asked there
> but i
> > g

Re: RaspberryPi with U-Boot and FDT

2020-06-09 Thread Christian Mauderer



On 09/06/2020 15:52, jan.som...@dlr.de wrote:
> 
> 
>> -Original Message-
>> From: users [mailto:users-boun...@rtems.org] On Behalf Of
>> jan.som...@dlr.de
>> Sent: Tuesday, June 9, 2020 3:01 PM
>> To: users@rtems.org
>> Subject: RaspberryPi with U-Boot and FDT
>>
>> Hello,
>>
>> I recently updated my RaspberryPi2-Setup to a more recent version.
>> So far we used u-boot and ran the ELF-binary directly using the "bootelf"
>> command.
>> Now with the commit "362cf319d4 - bsp/raspberrypi: Updated the console
>> API" it seems the console driver has been changed to require a FDT to be
>> available.
>> I assume, I now need to build an u-boot image with mkimg and then pass the
>> FDT address to it.
>> So far, I had no success. I created the image file with:
>>
>> arm-rtems5-objcopy -R -S --strip-debug -O binary ticker.exe ticker-fdt.bin
>> cat ticker-fdt.bin | gzip -9
>> mkimage -A arm -O rtems -T kernel -a 0x0020 -e 0x0020 -n RTEMS -d
>> ticker-fdt.gz ticker-fdt.img
>>
> 
> I compared my mkimage call with the one from altera-cyclone BSP 
> (https://docs.rtems.org/branches/master/user/bsps/bsps-arm.html#altera-cyclone-v-intel-cyclone-v)
> I changed mine to use "-O linux" too and now it works.

Yes, that should be the relevant change. All systems with FDT should use
Linux for the format of the image. All that don't use a FDT can still
use Linux. So rtems is more or less legacy for older releases.

> 
>> And tried to run it with
>>
>> bootm ${loadaddr} - ${fdt_addr}
>>
>> Has someone experience how to get it working with u-boot?
>> Do I need to configure something additionally in the rtems configuration?
>>
>> Best regards,
>>
>>Jan
>>
>>
>> Deutsches Zentrum für Luft- und Raumfahrt e. V. (DLR)
>> German Aerospace Center
>> Simulation and Software Technology | Software for Space Systems and
>> Interactive Visualization | Lilienthalplatz 7 | 38108 Braunschweig | Germany
>>
>> Jan Sommer
>> Telephone +49 531 295-2494 | Telefax 0531 295-2767 | jan.som...@dlr.de
>> DLR.de/SC
>>
>> ___
>> users mailing list
>> users@rtems.org
>> http://lists.rtems.org/mailman/listinfo/users
> ___
> users mailing list
> users@rtems.org
> http://lists.rtems.org/mailman/listinfo/users
> 
___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users

Re: Fwd: JTAG error with arm-rtems-gdb

2020-06-09 Thread Christian Mauderer

 debugging to work with the Pi2 1.2 (A53), it will also probably
> work with the Pi 3 models.
> 
> __ __
> 
> Alan
> 
> __ __
> 
> *From: *Mario Palomares <mailto:palomares.mari...@gmail.com>
> *Sent: *Sunday, May 17, 2020 12:38 PM
> *To: *users@rtems.org <mailto:users@rtems.org>
> *Cc: *Alan Cudmore <mailto:alan.cudm...@gmail.com>
> *Subject: *Fwd: JTAG error with arm-rtems-gdb
> 
> __ __
> 
> __ __
> 
> -- Forwarded message -
> De: *Mario Palomares*  <mailto:palomares.mari...@gmail.com>>
> Date: dom., 17 may. 2020 a las 18:33
> Subject: Re: JTAG error with arm-rtems-gdb
> To: Alan Cudmore  <mailto:alan.cudm...@gmail.com>>
> 
> __ __
> 
> Hi Alan,
> 
> __ __
> 
> I have done what you told me (set up the whole environment) and
> it worked. 
> 
> First i have to configure the RPI to boot on 64 bit mode (just
> setting a parameter on config.txt) and later on could establish
> GDB connection with the gdb the aaarch64 toolchain offers.
> Gdb-multiarch also worked.
> 
> __ __
> 
> It seems the problem is on that amrv8-a53 clusters working in 32
> bit mode. I don´t know if openOCD has support for amv8-a cores
> working in 32 bit or if i have to change my configuration file.
> 
> __ __
> 
> Does this make sense to you?
> 
> __ __
> 
> As an alternative in case this doesn´t work i am currently
> trying to use the remote debugging through libdebugger but i am
> experiencing some problems when building the rtems-libbsd
> library. Should i ask here or create another subject?.
> 
> __ __
> 
> Regards, 
> 
> Mario
> 
> __ __
> 
> El sáb., 16 may. 2020 a las 15:58, Alan Cudmore
> (mailto:alan.cudm...@gmail.com>>) escribió:
> 
> Hello Mario,
> 
> Did you try bringing up the complete bare metal environment
> in the Bare Metal Raspberry Pi 3b JTAG blog entry?
> 
> I would verify that that environment with the bare metal
> Aarch64 examples work before trying to get the 32 bit RTEMS
> binaries to work.
> 
> It seems like these should work on the Pi2 with the A53 cores
> 
> https://metebalci.com/blog/bare-metal-rpi3-programming/
> 
> But the UART example might not work due to the differences
> between how the uarts are used on the Pi2 and 3.
> 
>  
> 
> Does the ARM multiarch GDB work with Aarch64? Maybe try the
> Aarch64 GDB mentioned in the bare metal RPI3 blog entry?
> 
>  
> 
> Alan
> 
>  
> 
>  
> 
> *From: *Mario Palomares <mailto:palomares.mari...@gmail.com>
> *Sent: *Saturday, May 16, 2020 7:41 AM
> *To: *users@rtems.org <mailto:users@rtems.org>
> *Subject: *JTAG error with arm-rtems-gdb
> 
>  
> 
> I am tryining to debug RTEMS programs on mi RPI2 through a
> JTAG conexion with OpenOCD. Right now i have the connection
> correctly established and i can connect through a telnet
> client. Whenever I try to connect through arm-rtems5-gdb i
> get the following error
> 
>  
> 
> warning: while parsing target description (at line 4):
> Target description specified unknown architecture "aarch64"
> warning: Could not load XML target description; ignoring
> Truncated register 16 in remote 'g' packet
> 
>  
> 
> The configuration file i use for the RPI can be found in
> this page 
> 
> https://metebalci.com/blog/bare-metal-raspberry-pi-3b-jtag/. :
> 
> I can´t use the configuration file proposed here:
> 
> 
> https://github.com/ppisa/rpi-utils/blob/master/jtag-debug/rpi2/rpi-jt_usb5.cfg
>  by
> Pavel because my RPI is a RPI2 v1.2 which has the same SoC
> that the RPI3. If i try Pavels configuration file the
> connection fails.
> 
>  
> 
> I have installed gdb multiarch and tried with it but no
> luck, when i set the architecture to aarch64 i get:
> 
>

Re: RTEMS Toolchain Building Error

2020-05-13 Thread Christian Mauderer

Hello Jianxun Yan,

On 12/05/2020 20:47, Jianxun Yan wrote:
> Dear all,
> 
> Tried to build RTEMS 5 on Fedora 32 and got error.
> 
>   * ../source-builder/sb-set-builder  --prefix=$HOME/development/rtems/5
> 5/rtems-arm
> 
>  …
> 
> Config: tools/rtems-gdb-9.1-1.cfg
> 
> Package: arm-rtems5-gdb-9.1-x86_64-linux-gnu-1
> 
> Building: arm-rtems5-gdb-9.1-x86_64-linux-gnu-1
> 
> Error: building arm-rtems5-gdb-9.1-x86_64-linux-gnu-1
> 
> Build FAILED

That's a really short error message. You might want to think about
adding the "--log=some_log_file.txt" option to your sb-set-builder call.
That will generate a really detailed (>40MB) log file for the whole
build. You'll be interested in the last maybe 80 lines of this file.
There should be some error message there that gives more details what
went wrong.

Best regards

Christian Mauderer

> 
>  
> 
> Does anyone know what caused the problem?
> 
> Thanks,
> 
> J. Yan
> 
> Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for
> Windows 10
> 
>  
> 
> 
> ___
> users mailing list
> users@rtems.org
> http://lists.rtems.org/mailman/listinfo/users
> 

-- 

embedded brains GmbH
Herr Christian Mauderer
Dornierstr. 4
D-82178 Puchheim
Germany
email: christian.maude...@embedded-brains.de
Phone: +49-89-18 94 741 - 18
Fax:   +49-89-18 94 741 - 08
PGP: Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users

Re: Interested in contributing to Beaglebone BSP

2020-05-05 Thread Christian Mauderer

On 05/05/2020 06:38, Chris Johns wrote:
> On 4/5/20 12:50 am, Vijay Kumar Banerjee wrote:
>> On Sun, May 3, 2020 at 8:12 PM Christian Mauderer > <mailto:o...@c-mauderer.de>> wrote:
>>
>>     I don't think that would be a good idea before the release. After the
>>     release we should work on a 1.6 build set.
> 
> What about 5.2? :)

I don't have a problem adding it to the 5.2 release as a backport. But
currently I don't think that you would be happy about open patches for
5.1, correct?

> 
>>     The 1.6 only needs libyaml
>>     (or libjson?) which is no default package on FreeBSD. So we need a
>>     solution for that on FreeBSD hosts.
>>
>> I didn't test it with FreeBSD. Yes, after the release we can make a best
>> for 1.6.0 and mention libjson/libyaml as a dependency. We'll just have
>> to figure out a way to check from RSB if the package is present, I hope
>> we'll find some example in the repo already.
> 
> GDB and Python is a example. It is complicated so I hope it provides a
> suitable example
> 
> https://git.rtems.org/rtems-source-builder/tree/source-builder/config/gdb-common-1.cfg#n70
> 
> 
> The `rtems-build-dep` script may help.
> 
> In the bare devel/qemu build set there are checks against pkgconfig and
> if a library is not found on the host it is built for you.
> 
> I hope this helps.
> 
> Chris
> ___
> users mailing list
> users@rtems.org
> http://lists.rtems.org/mailman/listinfo/users

-- 

embedded brains GmbH
Herr Christian Mauderer
Dornierstr. 4
D-82178 Puchheim
Germany
email: christian.maude...@embedded-brains.de
Phone: +49-89-18 94 741 - 18
Fax:   +49-89-18 94 741 - 08
PGP: Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users

Re: Interested in contributing to Beaglebone BSP

2020-05-04 Thread Christian Mauderer

Hello James,

On 04/05/2020 12:26, James Fitzsimons wrote:
> Hi Christian and Vijay,
> 
> Firstly thank you so much for your replies they were extremely helpful
> and much appreciated.
> 
> On Mon, 4 May 2020 at 02:50, Vijay Kumar Banerjee  <mailto:vi...@rtems.org>> wrote:
> 
> 
> On Sun, May 3, 2020 at 8:12 PM Christian Mauderer  <mailto:o...@c-mauderer.de>> wrote:
> 
> 
> Note that the repo works only most of the time. It's more of a
> test repo
> for me that just collects the necessary commands and
> repositories so I
> don't have to type everything manually.
> 
> The dtc that I build there currently doesn't work. I removed the
> step
> from the makefile so that the host dtc is used again
> 
> 
> Understood. it is extremely useful for people getting started with rtems
> on the BeagleBone though! On my Ubuntu 18.04 host the system dtc was
> version 1.4.5 which also didn't support the -@ option, so I took Vijays
> advice and downloaded and built 1.6.0 which solved the problem.

It's only relevant if you want to build overlays (which I do in my
repo). That is necessary for example when you want to use HDMI. If you
don't want HDMI you can just build the base FDT without the -@ option
and load only that. That should work fine too. If it doesn't work you
found a bug.

>  
> 
> That's correct. The -@ or --symbols is only there in newer dtc
> versions.
> Out of interest: Where did you find that the option is
> deprecated? It is
> still there in 1.6.0.
> 
> 
> That must be my mistake. I was sure I read that the other night but
> can't find the website or thread I was reading now so it was probably
> either bad information or my misinterpretation - apologies for that.

No problem. I would have just tried to move to an alternative if that
option would have been deprecated.

Best regards

Christian

> 
> >     If I then run the following steps in the makefile manually,
> >     bootstrap and bsp complete, but libbsd fails with the
> following error:
> >
> >     [1497/2193] Compiling freebsd/sys/netpfil/pf/pf_lb.c
> >     ../../freebsd/sys/arm/freescale/imx/imx6_ccm.c:54:10:
> fatal error:
> >     arm/freescale/imx/imx_ccmvar.h: No such file or directory
> >      #include 
> >               ^~~~
> >     compilation terminated.
> >
> > This bug was recently fixed in the rtems-libbsd ( for both
> master and
> > 5-freebsd-12 branches), if you update to recent HEAD of the
> libbsd, then
> > this error will hopefully not be there.
> 
> 
> Thanks for this. I thought my rtems-libbsd repo was up to date, but I
> did a git pull --recurse-submodules and now make libbsd succeeds.
> Loading the hello world test app onto the board produces the expected
> output in a terminal session, so I think I am now in a position to make
> a start on the eQEP driver. 
> 
> Many thanks for your help!
> 
> Regards
> James Fitzsimons
>  
___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users

Re: Interested in contributing to Beaglebone BSP

2020-05-03 Thread Christian Mauderer

Hello James and Vijay,

On 03/05/2020 14:33, Vijay Kumar Banerjee wrote:
> Hi James
> 
> On Sun, May 3, 2020 at 4:30 PM James Fitzsimons
> mailto:james.fitzsim...@gmail.com>> wrote:
> 
> Hi Christian,
> 
> I tried to make a start this evening but I hate to say I ran into
> trouble getting my rtems environment setup, and after attempting to
> debug this for a couple of hours I thought I might see if you (or
> anyone else on the list) had some ideas.
> 
> I started by forking
> your https://gitlab.com/c-mauderer/rtems-bbb gitlab repo and running
> make setup.

Note that the repo works only most of the time. It's more of a test repo
for me that just collects the necessary commands and repositories so I
don't have to type everything manually.

The dtc that I build there currently doesn't work. I removed the step
from the makefile so that the host dtc is used again.

> 
> Everything progresses fine up until the "dtb" step in the makefile.
> At that point I get the following error:
> 
> make -C /home/james/Documents/rtems/rtems-bbb//devicetree
> MACHINE=arm install
> make[1]: Entering directory
> '/home/james/Documents/rtems/rtems-bbb/devicetree'
> /home/james/Documents/rtems/rtems-bbb//install/rtems/5/bin/dtc -@ -o
> 
> /home/james/Documents/rtems/rtems-bbb//install/rtems/5/fdt/am335x-i2c-overlay.dtbo
> /home/james/Documents/rtems/rtems-bbb/devicetree//am335x-i2c-overlay.dtso
> /home/james/Documents/rtems/rtems-bbb//install/rtems/5/bin/dtc:
> invalid option -- '@'
> Usage: dtc [options] 
> 
> A bit of googling turned up some information that the -@ option is
> deprecated, and sure enough running ./install/rtems/5/bin/dtc --help
> shows that the version of dtc built (Version: DTC 1.4.1-gf2f0fdf1)
> does not have the @ option. I tried modifying the makefile in the
> devicetree directory so the last two lines look like this:
> 
> The -@ option is required to generate the symbols without which there
> will be errors in applying the overlay. The -@ option is not present in
> version 1.4.1, you can build 1.4.6 from the source. I recently added the
> rsb recipe for 1.4.6 but there's no bset present and the devel/dtc
> builds the 1.4.1 . 

That's correct. The -@ or --symbols is only there in newer dtc versions.
Out of interest: Where did you find that the option is deprecated? It is
still there in 1.6.0.

> 
> Christian: Can we make a bset for dtc-1.4.6 which can be separately
> build like build/dtc-1.4.6.bset ?

I don't think that would be a good idea before the release. After the
release we should work on a 1.6 build set. The 1.6 only needs libyaml
(or libjson?) which is no default package on FreeBSD. So we need a
solution for that on FreeBSD hosts.

> 
> $(TARGETDIR)/%.dtbo: $(MAKEFILE_DIR)/%.dtso
> 
> $(PREFIX)/bin/dtc -o $@ $<
> 
> 
> Now running $make dtb gives the following output:
> 
> make[1]: Entering directory
> '/home/james/Documents/rtems/rtems-bbb/devicetree'
> /home/james/Documents/rtems/rtems-bbb//install/rtems/5/bin/dtc -o
> 
> /home/james/Documents/rtems/rtems-bbb//install/rtems/5/fdt/am335x-i2c-overlay.dtbo
> /home/james/Documents/rtems/rtems-bbb/devicetree//am335x-i2c-overlay.dtso
> Error:
> 
> /home/james/Documents/rtems/rtems-bbb/devicetree//am335x-i2c-overlay.dtso:2.2-8
> syntax error
> FATAL ERROR: Unable to parse input tree
> Makefile:24: recipe for target
> 
> '/home/james/Documents/rtems/rtems-bbb//install/rtems/5/fdt/am335x-i2c-overlay.dtbo'
> failed
> make[1]: ***
> 
> [/home/james/Documents/rtems/rtems-bbb//install/rtems/5/fdt/am335x-i2c-overlay.dtbo]
> Error 1
> make[1]: Leaving directory
> '/home/james/Documents/rtems/rtems-bbb/devicetree'
> Makefile:96: recipe for target 'dtb' failed
> make: *** [dtb] Error 2
> james@opportunity:~/Documents/rtems/rtems-bbb$
> 
> I'm not quite sure where to go from here though.
> 
> If I then run the following steps in the makefile manually,
> bootstrap and bsp complete, but libbsd fails with the following error:
> 
> [1497/2193] Compiling freebsd/sys/netpfil/pf/pf_lb.c
> ../../freebsd/sys/arm/freescale/imx/imx6_ccm.c:54:10: fatal error:
> arm/freescale/imx/imx_ccmvar.h: No such file or directory
>  #include 
>           ^~~~
> compilation terminated.
> 
> 
> This bug was recently fixed in the rtems-libbsd ( for both master and
> 5-freebsd-12 branches), if you update to recent HEAD of the libbsd, then
> this error will hopefully not be there.
> 
> Best regards,
> Vijay
>

Re: Interested in contributing to Beaglebone BSP

2020-04-26 Thread Christian Mauderer

Hello James,

On 26/04/2020 12:05, James Fitzsimons wrote:
> Hi Christian,
> 
> Thanks for your reply.
> 
> On Wed, 22 Apr 2020 at 23:29, Christian Mauderer
>  <mailto:christian.maude...@embedded-brains.de>> wrote:
> 
> Hello James,
> 
> On 20/04/2020 13:13, James Fitzsimons wrote:
> > I am interested in adding support for the eQEP (Enhanced Quadrature
> > Encoder Pulse Module) which I am using to decode the quadrature
> encoders
> > on my motors.
> 
> That one isn't implemented yet and I don't know of any current work on
> it. So feel free to go ahead.
> 
> 
> Thanks for the encouragement - I will start with the eQEP drivers. 
> 
>
> > I will eventually also need support for the ADC, PRU (I see some work
> > has already been done on that by a GSoC project),
> 
> There has been some work on PRU. I'm not entirely sure about ADC.
> 
> > and ideally the TI
> > WiLink 8 WL1835MOD wireless chipset - although I realise that might be
> > extremely difficult.
> 
> That depends: What kind of interface is used for that? And is the chip
> already supported in FreeBSD?
> 
> 
> I have done a bit of research and can't find any FreeBSD support for it.
> There are obviously linux drivers but I realise these are not suitable
> for porting to RTEMS

I had a look at the Linux drivers. They are GPL only. So you are right:
They wouldn't be accepted in RTEMS. In theory you could use a private
repo for a port of the drivers but expect a lot of maintenance effort if
you want to keep them up to date.

You should think about asking on a FreeBSD mailing list whether someone
is working on a driver. Maybe someone is working on it and there already
exists a partial or complete driver in some private or separate repository.

>  
> 
> If it is an USB interface and it is supported in FreeBSD adding it
> shouldn't be much work. If it is an SDIO it will get a bit more
> difficult but still possible in a decent time frame. If FreeBSD doesn't
> know anything about it you will have a really hard time. WLAN drivers
> are _very_ complex and the need a lot of detail knowledge about the
> chipset and the regulations.
> 
> 
> I'm pretty sure it uses an SDIO interface, but as you say without the
> FreeBSD support it may be a bit of a long shot.
>  

Yes, seems to be SDIO. We had a GSoC project regarding SDIO two or three
years ago. The student managed to do most of the work for a SDIO support
in libbsd. But we could only partially merge it because at that point
the libbsd was too far behind FreeBSD. One extra difficulty has been
that SDIO was a compile time option in FreeBSD back then. You might want
to take a look at the project and whether you can re-use some parts of
it if you want to add the SDIO stuff.

> 
> > Are drivers for these features something that would be welcome in the
> > BBB BSP, and if so any tips for getting started?
> 
> Of course. Peripheral drivers are nearly always welcome.
> 
> For the PRU you might should contact the GSoC student working on the
> topic. For WLAN: Please check the interface and FreeBSD support. I don't
> know exactly what the eQEP does. But if there is a FreeBSD driver for it
> you might want to check that one too and maybe port it via libbsd
> (except the eQEP is a really simple module and it's a lot simpler to
> write the driver yourself in the BSP)
> 
> 
> I'll make a start on the eQEP module (quadrature decoder for reading
> encoders) and if that goes well I'll reach out to Nils Hölscher about
> the PRU work.

Sounds good. Feel free to ask questions on the mailing list anytime you
think necessary. And although I don't think that you have too much
overlap please keep an eye on this years GSoC projects and whether there
is any influence on your code or vice versa.

Best regards

Christian Mauderer

>  
> Thanks and regards, 
> James Fitzsimons
> 
> 
> 
> ___
> users mailing list
> users@rtems.org
> http://lists.rtems.org/mailman/listinfo/users
> 
___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users

Re: Interested in contributing to Beaglebone BSP

2020-04-22 Thread Christian Mauderer

Hello James,

On 20/04/2020 13:13, James Fitzsimons wrote:
> Hi all,
> 
> I'm interested in contributing to the BeagleBone BSP by adding drivers
> for some of the missing features. I am working on a robotics project
> using the BeagleBoneBlack wireless and becoming frustrated by Linux. I
> would love to be able to use RTEMS, which I have dabbled with a bit in
> the past.
> 
> I am interested in adding support for the eQEP (Enhanced Quadrature
> Encoder Pulse Module) which I am using to decode the quadrature encoders
> on my motors.

That one isn't implemented yet and I don't know of any current work on
it. So feel free to go ahead.

> 
> I will eventually also need support for the ADC, PRU (I see some work
> has already been done on that by a GSoC project),

There has been some work on PRU. I'm not entirely sure about ADC.

> and ideally the TI
> WiLink 8 WL1835MOD wireless chipset - although I realise that might be
> extremely difficult.

That depends: What kind of interface is used for that? And is the chip
already supported in FreeBSD?

If it is an USB interface and it is supported in FreeBSD adding it
shouldn't be much work. If it is an SDIO it will get a bit more
difficult but still possible in a decent time frame. If FreeBSD doesn't
know anything about it you will have a really hard time. WLAN drivers
are _very_ complex and the need a lot of detail knowledge about the
chipset and the regulations.

> 
> Are drivers for these features something that would be welcome in the
> BBB BSP, and if so any tips for getting started?

Of course. Peripheral drivers are nearly always welcome.

For the PRU you might should contact the GSoC student working on the
topic. For WLAN: Please check the interface and FreeBSD support. I don't
know exactly what the eQEP does. But if there is a FreeBSD driver for it
you might want to check that one too and maybe port it via libbsd
(except the eQEP is a really simple module and it's a lot simpler to
write the driver yourself in the BSP).

Best regards

Christian

> 
> Cheers,
> James Fitzsimons
> 
> ___
> users mailing list
> users@rtems.org
> http://lists.rtems.org/mailman/listinfo/users
> 

-- 
----
embedded brains GmbH
Herr Christian Mauderer
Dornierstr. 4
D-82178 Puchheim
Germany
email: christian.maude...@embedded-brains.de
Phone: +49-89-18 94 741 - 18
Fax:   +49-89-18 94 741 - 08
PGP: Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users

Re: libbsd VLAN tagging

2020-04-22 Thread Christian Mauderer

On 22/04/2020 09:47, Matthew J Fletcher wrote:
> Hi,
> 
> How would an application using libbsd add VLAN tags to transmitted
> frames so an external switch chip could process them ?
> 
> Is there an application / libbsd interface for this or does it require
> the driver to be modified.

Hello Matthew,

in theory it should be the same interface like on FreeBSD:

https://www.freebsd.org/doc/handbook/network-vlan.html

But as far as I know it needs driver support:

https://www.freebsd.org/cgi/man.cgi?query=vlan=4=freebsd-release-ports

Best regards

Christian

> 
> 
> regards
> ---
> Matthew J Fletcher
> 
> 
> ___
> users mailing list
> users@rtems.org
> http://lists.rtems.org/mailman/listinfo/users
> 
___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users

Re: Multi-networking Interface support?

2020-04-18 Thread Christian Mauderer

Hello HungLE,

On 17/04/2020 18:44, Hung LE-Dinh wrote:
> /Dear,
> 
> Can RTEMS support multi-networking interface?
> 
> I have a zynq-7000 board with 2 ethernet port, and I want to build a
> simple router on it using RTEMS. Can I do that?

Yes you can do that if you use libbsd (I think that should be the right
network stack for Zynq). Just configure your interfaces and use

sysctl net.inet.ip.forwarding=1

like you would on FreeBSD. Don't forget to set up your routes correctly
on all systems on both sides of the router.

In theory you should be able to to quite a lot of stuff with pf too
(like NAT). Take a look at the testsuite/pf* files in libbsd to see how
to set up pf in RTEMS and at the FreeBSD handbook to find out how to
write pf rules:

https://www.freebsd.org/doc/handbook/firewalls-pf.html

Note that RTEMS isn't designed to be a highly secure system. If you want
to create a router that is connected directly to the internet you might
should think thoroughly whether it's the right choice.

Best regards

Christian

> 
> Thank for your time.
> 
> HungLE
> /
> 
> 
> 
> ___
> users mailing list
> users@rtems.org
> http://lists.rtems.org/mailman/listinfo/users
> 
___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users

Re: GSoC 2020 regd.

2020-03-06 Thread Christian Mauderer

Hello Yogeshwaran,
On 07/03/2020 07:15, Gedare Bloom wrote:
> Hello Yogeshwaran,
> 
> On Fri, Mar 6, 2020 at 8:50 PM Yogeshwaran L  wrote:
>>
>> Hello,
>>
>> I'm Yogeshwaran and currently doing my master's in Computer Engineering, 
>> specializing in systems programming from the University of Florida. I'm 
>> interested in implementing keyboard/mouse support for the Raspberry Pi BSP. 
>> I have experience working in C and also have a background in computer 
>> architecture, system programming and virtual computers. Is any one 
>> interested in mentoring for this project?
>>
> Thanks for your interest! Please have a look at
> https://devel.rtems.org/wiki/GSoC where we have tried to consolidate
> information about our involvement with GSoC. After you review open
> projects and consider the project you have in mind, please register
> and discuss your project on the de...@rtems.org mailing list (which is
> where we consolidate discussions related to active development of
> RTEMS itself). There you may find some possible mentors who may
> respond with respect to your idea to implement keyboard/mouse support
> for RPi.

I agree with Gedare: You should start with the usual steps for GSoC like
described in the wiki. After that the project should be discussed on
de...@rtems.org.

If you suggest the project, please also take a look at what already
exists (or ask for it on devel). For example I know that someone already
did something with keyboard and mouse:


https://git.rtems.org/rtems-libbsd/commit/?id=29c0cffe57a04e487f5a5a61f7d12e5e067712a0

I have no idea how well it is already integrated and whether it works on
RPi. You should add Kevin Kirspel to CC if you post on devel regarding
this project.

> 
> For a project that focuses on a specific target, we request that you
> complete the "Getting Started" activity to demonstrate that you can
> run the RTEMS version of "Hello World" on that target.
> 
> Gedare
> 
>> Thank you.
>> ___
>> users mailing list
>> users@rtems.org
>> http://lists.rtems.org/mailman/listinfo/users
> ___
> users mailing list
> users@rtems.org
> http://lists.rtems.org/mailman/listinfo/users
> 
___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users

Re: Error While building BSP | erc32 | sparc-rtems-4.11.3

2020-01-27 Thread Christian Mauderer

On 27/01/2020 12:17, Bran S wrote:
> On Monday, 27 January 2020, Christian Mauderer
>  <mailto:christian.maude...@embedded-brains.de>> wrote:
>> I noted that you have a RTEMS 4.11 toolchain. But it seems that you use
>> the instructions for the RTEMS master (which has a Version 5). Did you
>> use a matching RTEMS 4.11 branch for your build?
> 
> 
> I used the tar files:
> 
> https://ftp.rtems.org/pub/rtems/releases/4.11/4.11.3/rtems-4.11.3.tar.xz
> curl
> https://ftp.rtems.org/pub/rtems/releases/4.11/4.11.3/rtems-source-builder-4.11.3.tar.xz
> 

Without testing it myself: If you want to use the releases please try
with the release documentation:

https://docs.rtems.org/releases/rtems-docs-4.11.3/user/start/index.html

> I have now instead built it using the the git repo as mentioned in the
> quick-start document. It is running fine, with some minor issues:

Great.

> 
> 1) Five BSP erc32 tests fail, namely:
> 
> dl06.exe
> dl09.exe
> terminos09.exe
> psxfenv01.exe
> psxmsgq03.exe
> 
> 2) On running `sparc-rtems5-gdb hello.exe` and doing `target sim`
> gdb shows: Undefined target command: "sim"
> 
> Going through archives I found that others have also faced the same
> problem and using `sparc-rtems5-sis` was suggested as a workaround.
> I tried and it solved the problem.
> Although I am not clear on why these problems occurred.

I haven't really noticed these problems and never tested it. So I can't
really say anything regarding that.

Best regards

Christian

-- 

embedded brains GmbH
Herr Christian Mauderer
Dornierstr. 4
D-82178 Puchheim
Germany
email: christian.maude...@embedded-brains.de
Phone: +49-89-18 94 741 - 18
Fax:   +49-89-18 94 741 - 08
PGP: Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users

Re: Error While building BSP | erc32 | sparc-rtems-4.11.3

2020-01-27 Thread Christian Mauderer

On 24/01/2020 19:56, Bran S wrote:
> Hi Guys,
> 
> I am trying to build and run rtems.
> Followed the steps as mentioned at
> https://docs.rtems.org/branches/master/user/start/index.html
> 
> Getting this error while doing make as mentioned here
> https://docs.rtems.org/branches/master/user/start/bsp-build.html
> 
> gmake[2]: Entering directory
> '/home/user45/quick-start/build/b-erc32/sparc-rtems4.11/c/erc32'
> gmake[2]: *** No rule to make target 'all'.  Stop.
> gmake[2]: Leaving directory
> '/home/user45/quick-start/build/b-erc32/sparc-rtems4.11/c/erc32'
> gmake[1]: *** [Makefile:286: all-recursive] Error 1
> gmake[1]: Leaving directory
> '/home/user45/quick-start/build/b-erc32/sparc-rtems4.11/c'
> make: *** [Makefile:410: all-recursive] Error 1
> 
> Full logs are at https://justpaste.it/7ao05
> 
> This was my configure command:
> $HOME/quick-start/src/rtems-4.11.3/configure
> --prefix=$HOME/quick-start/rtems/4.11 --enable-maintainer-mode
> --target=sparc-rtems4.11 --enable-rtemsbsp=erc32 --enable-tests
> 
> My $PATH var includes: /home/user45/quick-start/rtems/4.11/bin
> 
> As the error mentions No rull to make target 'all'
> I checked the
> '/home/user45/quick-start/build/b-erc32/sparc-rtems4.11/c/erc32'
> directory and it doesn't contain any Makefile. Although a make directory
> is present in there.
> Any ideas about what is causing this ?
> 
> Thanks
> 

Hello Bran,

I noted that you have a RTEMS 4.11 toolchain. But it seems that you use
the instructions for the RTEMS master (which has a Version 5). Did you
use a matching RTEMS 4.11 branch for your build?

Best regards

Christian
-- 

embedded brains GmbH
Herr Christian Mauderer
Dornierstr. 4
D-82178 Puchheim
Germany
email: christian.maude...@embedded-brains.de
Phone: +49-89-18 94 741 - 18
Fax:   +49-89-18 94 741 - 08
PGP: Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users

Re: USB device mode

2020-01-11 Thread Christian Mauderer

Hello Tony

On 10/01/2020 16:57, Tony Whittam wrote:
> Hi,
> 
> Does anyone know of an example project with a USB device implemented
> with rtems-libbsd? 

I played around with it about 2 years ago for some hours. But I didn't
invest enough time into it to get it running. For implementing a USB
device it is most likely necessary to import the usb_template system
from FreeBSD. See the top two commits on this branch for the work I did
back then:

  https://gitlab.com/c-mauderer/rtems-libbsd/commits/20170707-cdce

Note that since then the structure of libbsd changed a bit
(libbsd_waf.py was removed). So these patches won't work directly on the
most current libbsd.

With these patches I was at least able to have some first live signs
between host and (in this case) a Beagle Bone Black board. I then
stopped that (hobby) work because something other more interesting
interrupted.

> 
> I have built rtems-libbsd for the realview_pbx_a9_qemu and for the
> altcycv_devkit. The USB examples in the testsuite all appear to be USB
> host-mode tests. What I want to do is to create a system that will
> present a USB composite device that I can connect to a USB host. The
> composite device is to have a USB bulk IN endpoint, a USB bulk OUT
> endpoint and a USB HID IN endpoint. I'm trying to find out whether I can
> do this on RTEMS. I have all the relevant USB descriptors from my
> implementation that uses USB gadgets on Linux. I want to port the
> application to an RTOS.

With the current state of the libbsd it might would be easier for you to
find out whether it works with FreeBSD. As soon as it is clear how it
works there it is only a small step to port the necessary parts to RTEMS
via libbsd.

> 
> Thanks,
> 
> Tony
> 
> 
> Confidentiality Notice: 
> 
> The information contained in this message, including any attachments
> hereto, may be confidential and is intended to be read only by the
> individual or entity to whom this message is addressed. If the reader of
> this message is not the intended recipient or an agent or designee of
> the intended recipient, please note that any review, use, disclosure or
> distribution of this message or its attachments, in any form, is
> strictly prohibited. If you have received this message in error, please
> immediately notify the sender and/or Rapt Touch Ltd via email
> at i...@rapttouch.com  and delete or destroy
> any copy of this message and its attachments.

PS: Note that a confidentiality Notice on a public mailing list is quite
pointless. See the Mailing list policies regarding that too:
https://devel.rtems.org/wiki/RTEMSMailingLists

Best regards

Christian
___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users

Re: Mounting/Accessing SD-Card on BBB

2019-08-15 Thread Christian Mauderer

Hello Nils,

does some other access to the file system work? Like a ls on the console
or creating a file. Can you do a `cat` on some text file on the file
system? If not: Does it work for a file in the root file system (should
be a IMFS)?

Best regards

Christian

On 15/08/2019 15:54, Nils Hölscher wrote:
> Hi,
> 
> I when my app wants to open a file on the SD card dev=mmcsd-0-0 rtems
> freezes.
> Exact call is:
> fd = open(file, O_RDONLY);
> With file being the pru binary I want to upload.
> 
> Thanks,
> Nils
> 
> On Tue, 13 Aug 2019 at 17:56, Christian Mauderer
>  <mailto:christian.maude...@embedded-brains.de>> wrote:
> 
> Hello Nils,
> 
> a third possibility: You could start a FTP server and push the file
> via network.
> 
> Best regards
> 
> Christian
> 
> Am Dienstag, 13. August 2019 schrieb Nils Hölscher:
> > Hi,
> >
> >
> > Thanks for the input I will try the SD card first.
> > That way I won't have to alter the code when I want to run other
> stuff on the pru.
> >
> >
> > Best,
> > Nils
> >
> >
> > On Tue, 13 Aug 2019 at 17:32, Gedare Bloom  <mailto:ged...@rtems.org>> wrote:
> >
>     > You can also build the PRU image into the RTEMS binary. See
> > examples-v2.git/file_io/crc/init.c
> >
> > On Tue, Aug 13, 2019 at 8:46 AM Christian Mauderer
> mailto:l...@c-mauderer.de>> wrote:
> > >
> > > Hello Nils,
> > >
> > > that's a bit odd. I attached an expected output below. Some guesses:
> > >
> > > - Did you add FAT file system to your application?
> > > - Is there some odd formatting on the SD? Normally at least the FAT
> > > partition used by U-Boot should be visible.
> > > - Is your BDBUF configuration OK?
> > > - Do you have enough file descriptors?
> > >
> > > Beneath that: If you only need something where you can put some
> files,
> > > you can try to connect a USB stick instead. Maybe that works better.
> > >
> > > Best regards
> > >
> > > Christian
> > >
> > >
> > > media listener: event = DISK ATTACH, state = INQUIRY, src = mmcsd
> > > media listener: event = DISK ATTACH, state = SUCCESS, src =
> mmcsd, dest
> > > = /dev/mmcsd-0
> > > media listener: event = MOUNT, state = INQUIRY, src = /dev/mmcsd-0
> > > mmcsd0: 4GB  at mmc0
> > > 24.0MHz/4bit/65535-block
> > > media listener: event = MOUNT, state = FAILED, src = /dev/mmcsd-0
> > > media listener: event = PARTITION INQUIRY, state = INQUIRY, src =
> > > /dev/mmcsd-0
> > > media listener: event = PARTITION INQUIRY, state = SUCCESS, src =
> > > /dev/mmcsd-0
> > > media listener: event = PARTITION ATTACH, state = INQUIRY, src =
> > > /dev/mmcsd-0
> > > media listener: event = PARTITION ATTACH, state = SUCCESS, src =
> > > /dev/mmcsd-0, dest = /dev/mmcsd-0-0
> > > media listener: event = MOUNT, state = INQUIRY, src = /dev/mmcsd-0-0
> > > media listener: event = MOUNT, state = SUCCESS, src =
> /dev/mmcsd-0-0,
> > > dest = /media/mmcsd-0-0
> > > media listener: event = DISK ATTACH, state = INQUIRY, src = mmcsd
> > > media listener: event = DISK ATTACH, state = SUCCESS, src =
> mmcsd, dest
> > > = /dev/mmcsd-1
> > > media listener: event = MOUNT, state = INQUIRY, src = /dev/mmcsd-1
> > > mmcsd1: 4GB  0x> at
> > > mmc1 48.0MHz/8bit/65535-block
> > > media listener: event = MOUNT, state = FAILED, src = /dev/mmcsd-1
> > > media listener: event = PARTITION INQUIRY, state = INQUIRY, src =
> > > /dev/mmcsd-1
> > > media listener: event = PARTITION INQUIRY, state = FAILED, src =
> > > /dev/mmcsd-1
> > > media listener: event = DISK ATTACH, state = INQUIRY, src =
> mmcsd1boot
> > > mmcsd1boot0: 2MB partion 1 at mmcsd1
> > > mmcsd1boot1: 2MB partion 2 at mmcsd1
> > > mmcsd1rpmb: 131kB partion 3 at mmcsd1
> > >
> > >
> > > On 13/08/2019 13:30, Nils Hölscher wrote:
> > > > Hi,
> > > >
> > > > Thanks for the help.
> > > > I tried to use your code, but I always get "ERROR: SD could not be
> > > > mounted after timeout"

Re: Mounting/Accessing SD-Card on BBB

2019-08-13 Thread Christian Mauderer

Hello Nils,

a third possibility: You could start a FTP server and push the file via network.

Best regards

Christian

Am Dienstag, 13. August 2019 schrieb Nils Hölscher:
> Hi,
> 
> 
> Thanks for the input I will try the SD card first.
> That way I won't have to alter the code when I want to run other stuff on the 
> pru.
> 
> 
> Best,
> Nils
> 
> 
> On Tue, 13 Aug 2019 at 17:32, Gedare Bloom  wrote:
> 
> You can also build the PRU image into the RTEMS binary. See
> examples-v2.git/file_io/crc/init.c
> 
> On Tue, Aug 13, 2019 at 8:46 AM Christian Mauderer  wrote:
> >
> > Hello Nils,
> >
> > that's a bit odd. I attached an expected output below. Some guesses:
> >
> > - Did you add FAT file system to your application?
> > - Is there some odd formatting on the SD? Normally at least the FAT
> > partition used by U-Boot should be visible.
> > - Is your BDBUF configuration OK?
> > - Do you have enough file descriptors?
> >
> > Beneath that: If you only need something where you can put some files,
> > you can try to connect a USB stick instead. Maybe that works better.
> >
> > Best regards
> >
> > Christian
> >
> >
> > media listener: event = DISK ATTACH, state = INQUIRY, src = mmcsd
> > media listener: event = DISK ATTACH, state = SUCCESS, src = mmcsd, dest
> > = /dev/mmcsd-0
> > media listener: event = MOUNT, state = INQUIRY, src = /dev/mmcsd-0
> > mmcsd0: 4GB  at mmc0
> > 24.0MHz/4bit/65535-block
> > media listener: event = MOUNT, state = FAILED, src = /dev/mmcsd-0
> > media listener: event = PARTITION INQUIRY, state = INQUIRY, src =
> > /dev/mmcsd-0
> > media listener: event = PARTITION INQUIRY, state = SUCCESS, src =
> > /dev/mmcsd-0
> > media listener: event = PARTITION ATTACH, state = INQUIRY, src =
> > /dev/mmcsd-0
> > media listener: event = PARTITION ATTACH, state = SUCCESS, src =
> > /dev/mmcsd-0, dest = /dev/mmcsd-0-0
> > media listener: event = MOUNT, state = INQUIRY, src = /dev/mmcsd-0-0
> > media listener: event = MOUNT, state = SUCCESS, src = /dev/mmcsd-0-0,
> > dest = /media/mmcsd-0-0
> > media listener: event = DISK ATTACH, state = INQUIRY, src = mmcsd
> > media listener: event = DISK ATTACH, state = SUCCESS, src = mmcsd, dest
> > = /dev/mmcsd-1
> > media listener: event = MOUNT, state = INQUIRY, src = /dev/mmcsd-1
> > mmcsd1: 4GB  at
> > mmc1 48.0MHz/8bit/65535-block
> > media listener: event = MOUNT, state = FAILED, src = /dev/mmcsd-1
> > media listener: event = PARTITION INQUIRY, state = INQUIRY, src =
> > /dev/mmcsd-1
> > media listener: event = PARTITION INQUIRY, state = FAILED, src =
> > /dev/mmcsd-1
> > media listener: event = DISK ATTACH, state = INQUIRY, src = mmcsd1boot
> > mmcsd1boot0: 2MB partion 1 at mmcsd1
> > mmcsd1boot1: 2MB partion 2 at mmcsd1
> > mmcsd1rpmb: 131kB partion 3 at mmcsd1
> >
> >
> > On 13/08/2019 13:30, Nils Hölscher wrote:
> > > Hi,
> > >
> > > Thanks for the help.
> > > I tried to use your code, but I always get "ERROR: SD could not be
> > > mounted after timeout".
> > > Even after raising the waiting time.
> > >
> > > The sources I use start here:
> > > https://github.com/nilhoel1/rtems-pru/blob/pruss-shell/main.c#L110
> > >
> > > And my uart output is:
> > > ""
> > > waiting for SD...
> > >
> > > usbus0: 480Mbps High Speed USB v2.0
> > > usbus1: 480Mbps High Speed USB v2.0
> > > media listener: event = DISK ATTACH, state = INQUIRY, src = mmcsd
> > > media listener: event = DISK ATTACH, state = SUCCESS, src = mmcsd, dest
> > > = /dev/mmcsd-0
> > > media listener: event = MOUNT, state = INQUIRY, src = /dev/mmcsd-0
> > > ugen0.1:  at usbus0
> > > ugen1.1:  at usbus1
> > > uhub0: 
> > > on usbus0
> > > uhub1: 
> > > on usbus1
> > > media listener: event = MOUNT, state = FAILED, src = /dev/mmcsd-0
> > > media listener: event = PARTITION INQUIRY, state = INQUIRY, src =
> > > /dev/mmcsd-0
> > > media listener: event = PARTITION INQUIRY, state = SUCCESS, src =
> > > /dev/mmcsd-0
> > > media listener: event = PARTITION ATTACH, state = INQUIRY, src =
> > > /dev/mmcsd-0
> > > media listener: event = PARTITION ATTACH, state = SUCCESS, src =
> > > /dev/mmcsd-0, dest = /dev/mmcsd-0-0
> > > media listener: event = MOUNT, state = INQUIRY, src = /dev/mmcsd-0-0
> > > media listener: event = MOUNT, state = FAILED, src = /dev/mmcsd-0-0
> > > m

Re: Mounting/Accessing SD-Card on BBB

2019-08-13 Thread Christian Mauderer

Hello Nils,

that's a bit odd. I attached an expected output below. Some guesses:

- Did you add FAT file system to your application?
- Is there some odd formatting on the SD? Normally at least the FAT
partition used by U-Boot should be visible.
- Is your BDBUF configuration OK?
- Do you have enough file descriptors?

Beneath that: If you only need something where you can put some files,
you can try to connect a USB stick instead. Maybe that works better.

Best regards

Christian


media listener: event = DISK ATTACH, state = INQUIRY, src = mmcsd
media listener: event = DISK ATTACH, state = SUCCESS, src = mmcsd, dest
= /dev/mmcsd-0
media listener: event = MOUNT, state = INQUIRY, src = /dev/mmcsd-0
mmcsd0: 4GB  at mmc0
24.0MHz/4bit/65535-block
media listener: event = MOUNT, state = FAILED, src = /dev/mmcsd-0
media listener: event = PARTITION INQUIRY, state = INQUIRY, src =
/dev/mmcsd-0
media listener: event = PARTITION INQUIRY, state = SUCCESS, src =
/dev/mmcsd-0
media listener: event = PARTITION ATTACH, state = INQUIRY, src =
/dev/mmcsd-0
media listener: event = PARTITION ATTACH, state = SUCCESS, src =
/dev/mmcsd-0, dest = /dev/mmcsd-0-0
media listener: event = MOUNT, state = INQUIRY, src = /dev/mmcsd-0-0
media listener: event = MOUNT, state = SUCCESS, src = /dev/mmcsd-0-0,
dest = /media/mmcsd-0-0
media listener: event = DISK ATTACH, state = INQUIRY, src = mmcsd
media listener: event = DISK ATTACH, state = SUCCESS, src = mmcsd, dest
= /dev/mmcsd-1
media listener: event = MOUNT, state = INQUIRY, src = /dev/mmcsd-1
mmcsd1: 4GB  at
mmc1 48.0MHz/8bit/65535-block
media listener: event = MOUNT, state = FAILED, src = /dev/mmcsd-1
media listener: event = PARTITION INQUIRY, state = INQUIRY, src =
/dev/mmcsd-1
media listener: event = PARTITION INQUIRY, state = FAILED, src =
/dev/mmcsd-1
media listener: event = DISK ATTACH, state = INQUIRY, src = mmcsd1boot
mmcsd1boot0: 2MB partion 1 at mmcsd1
mmcsd1boot1: 2MB partion 2 at mmcsd1
mmcsd1rpmb: 131kB partion 3 at mmcsd1


On 13/08/2019 13:30, Nils Hölscher wrote:
> Hi,
> 
> Thanks for the help.
> I tried to use your code, but I always get "ERROR: SD could not be
> mounted after timeout".
> Even after raising the waiting time.
> 
> The sources I use start here:
> https://github.com/nilhoel1/rtems-pru/blob/pruss-shell/main.c#L110
> 
> And my uart output is:
> ""
> waiting for SD...
> 
> usbus0: 480Mbps High Speed USB v2.0
> usbus1: 480Mbps High Speed USB v2.0
> media listener: event = DISK ATTACH, state = INQUIRY, src = mmcsd
> media listener: event = DISK ATTACH, state = SUCCESS, src = mmcsd, dest
> = /dev/mmcsd-0
> media listener: event = MOUNT, state = INQUIRY, src = /dev/mmcsd-0
> ugen0.1:  at usbus0
> ugen1.1:  at usbus1
> uhub0: 
> on usbus0
> uhub1: 
> on usbus1
> media listener: event = MOUNT, state = FAILED, src = /dev/mmcsd-0
> media listener: event = PARTITION INQUIRY, state = INQUIRY, src =
> /dev/mmcsd-0
> media listener: event = PARTITION INQUIRY, state = SUCCESS, src =
> /dev/mmcsd-0
> media listener: event = PARTITION ATTACH, state = INQUIRY, src =
> /dev/mmcsd-0
> media listener: event = PARTITION ATTACH, state = SUCCESS, src =
> /dev/mmcsd-0, dest = /dev/mmcsd-0-0
> media listener: event = MOUNT, state = INQUIRY, src = /dev/mmcsd-0-0
> media listener: event = MOUNT, state = FAILED, src = /dev/mmcsd-0-0
> media listener: event = DISK ATTACH, state = INQUIRY, src = mmcsd
> media listener: event = DISK ATTACH, state = SUCCESS, src = mmcsd, dest
> = /dev/mmcsd-1
> media listener: event = MOUNT, state = INQUIRY, src = /dev/mmcsd-1
> media listener: event = MOUNT, state = FAILED, src = /dev/mmcsd-1
> media listener: event = PARTITION INQUIRY, state = INQUIRY, src =
> /dev/mmcsd-1
> media listener: event = PARTITION INQUIRY, state = SUCCESS, src =
> /dev/mmcsd-1
> media listener: event = PARTITION ATTACH, state = INQUIRY, src =
> /dev/mmcsd-1
> media listener: event = PARTITION ATTACH, state = SUCCESS, src =
> /dev/mmcsd-1, dest = /dev/mmcsd-1-0
> media listener: event = MOUNT, state = INQUIRY, src = /dev/mmcsd-1-0
> media listener: event = MOUNT, state = FAILED, src = /dev/mmcsd-1-0
> media listener: event = DISK ATTACH, state = INQUIRY, src = mmcsd1boot
> uhub0: 1 port with 1 removable, self powered
> uhub1: 1 port with 1 removable, self powered
> ERROR: SD could not be mounted after timeout
> ""
> 
> Thanks,
> Nils
> 
> On Mon, 12 Aug 2019 at 18:01, Christian Mauderer  <mailto:l...@c-mauderer.de>> wrote:
> 
> On 12/08/2019 07:28, Nils Hölscher wrote:
> > Hi,
> >
> > Can anyone help me with this?
> > I need to access the BBB's SD-Card, so that I can load my pru
> example on
> > the pru.
> >
> > Thanks,
> > Nils
> >
> 
&g

Re: Mounting/Accessing SD-Card on BBB

2019-08-12 Thread Christian Mauderer

On 12/08/2019 07:28, Nils Hölscher wrote:
> Hi,
> 
> Can anyone help me with this?
> I need to access the BBB's SD-Card, so that I can load my pru example on
> the pru.
> 
> Thanks,
> Nils
> 

Hello Nils,

take a look at the following application:

https://gitlab.com/c-mauderer/rtems-bbb/blob/master/apps/wifi-sample/init.c#L64

https://gitlab.com/c-mauderer/rtems-bbb/blob/master/apps/wifi-sample/libbsdhelper.c#L122

You should mainly need the stuff from the libbsdhelper_init_sd_card()
and libbsdhelper_wait_for_sd().

Please note that the SD card needs quite some time to initialize on BBB.
I haven't had a look at it why that is the case.

Best regards

Christian
___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users

Re: stm32 external SRAM

2019-06-25 Thread Christian Mauderer



On 25/06/2019 04:35, Jython wrote:
> printf("data  test return %04x\n", memTestDataBus(0x6802));
> 
>    
>     printf("addr bus test return %04x\n",
> memTestAddressBus(0x6800, 1024*1024));
> 
> 
> memtest all passed at application mode,
> 
> when SRAM init function moves to bsp_start_hook_1 then not work
> Can i do init_main_osc in bsp_start_hook_1?

The function seems not to use any odd stuff so most likely yes. But make
sure that it doesn't need some initialized memory. Maybe you'll have to
take a look at it with objdump to make sure of that.

> 
> On Tue, Jun 18, 2019 at 1:25 PM Christian Mauderer
>  <mailto:christian.maude...@embedded-brains.de>> wrote:
> 
> On 18/06/2019 07:17, Jython wrote:
> >     void SRAM_fsmc_setup(void)
> >     {
> >     unsigned char FSMC_Bank;
> >         int i = 0;
> >
> >         // enable port clk
> >         RCC_AHB1ENR |= 0x0f << 3;
> >         RCC_AHB3ENR |= 1;  // enable fsmc clock
> >
> >         // af A0-A18
> >         stm32f4_gpio_config temp = STM32F4_PIN_FSMC(5, 0,
> >     STM32F4_GPIO_AF_FSMC);
> >        
> >
> >         for(i = 0; i < 6; i++)  //pf0-5
> >         {
> >            
> >            
> >             temp.fields.pin_first = STM32F4_GPIO_PIN(5, i);
> >             temp.fields.pin_last = STM32F4_GPIO_PIN(5, i);
> >             stm32f4_gpio_set_config();
> >         }
> >
> >         // A6 PF12
> >         temp.fields.pin_first = STM32F4_GPIO_PIN(5, 12);
> >         temp.fields.pin_last = STM32F4_GPIO_PIN(5, 12);
> >         stm32f4_gpio_set_config();
> >
> >         // A7 PF13
> >         temp.fields.pin_first = STM32F4_GPIO_PIN(5, 13);
> >         temp.fields.pin_last = STM32F4_GPIO_PIN(5, 13);
> >         stm32f4_gpio_set_config();
> >
> >         // A8 PF14
> >         temp.fields.pin_first = STM32F4_GPIO_PIN(5, 14);
> >         temp.fields.pin_last = STM32F4_GPIO_PIN(5, 14);
> >         stm32f4_gpio_set_config();
> >
> >         // A9 PF15
> >         temp.fields.pin_first = STM32F4_GPIO_PIN(5, 15);
> >         temp.fields.pin_last = STM32F4_GPIO_PIN(5, 15);
> >         stm32f4_gpio_set_config();
> >
> >
> >         // PG0-5    A10-A15
> >         for(i = 0; i < 6; i++)
> >         {
> >             temp.fields.pin_first = STM32F4_GPIO_PIN(6, i);
> >             temp.fields.pin_last = STM32F4_GPIO_PIN(6, i);
> >             stm32f4_gpio_set_config();
> >
> >         }
> >
> >
> >         // a16 - pd11
> >         temp.fields.pin_first = STM32F4_GPIO_PIN(3, 11);
> >         temp.fields.pin_last = STM32F4_GPIO_PIN(3, 11);
> >         stm32f4_gpio_set_config();
> >
> >         //A17
> >         temp.fields.pin_first = STM32F4_GPIO_PIN(3, 12);
> >         temp.fields.pin_last = STM32F4_GPIO_PIN(3, 12);
> >         stm32f4_gpio_set_config();
> >         //A18
> >         temp.fields.pin_first = STM32F4_GPIO_PIN(3, 13);
> >         temp.fields.pin_last = STM32F4_GPIO_PIN(3, 13);
> >         stm32f4_gpio_set_config();
> >        
> >         // address bus end
> >
> >
> >         // dbus setting
> >         // D0 PD14
> >         temp.fields.pin_first = STM32F4_GPIO_PIN(3, 14);
> >         temp.fields.pin_last = STM32F4_GPIO_PIN(3, 14);
> >         stm32f4_gpio_set_config();
> >
> >         // D1 PD15
> >         temp.fields.pin_first = STM32F4_GPIO_PIN(3, 15);
> >         temp.fields.pin_last = STM32F4_GPIO_PIN(3, 15);
> >         stm32f4_gpio_set_config();
> >
> >         // D2 PD0
> >         temp.fields.pin_first = STM32F4_GPIO_PIN(3, 0);
> >         temp.fields.pin_last = STM32F4_GPIO_PIN(3, 0);
> >         stm32f4_gpio_set_config();
> >
> >         // D3 PD1
> >         temp.fields.pin_first = STM32F4_GPIO_PIN(3, 1);
> >         temp.fields.pin_last = STM32F4_GPIO_PIN(3, 1);
> >         stm32f4_gpio_set_config();
> >
> >         // D4-12  Pe7
> >         for(i = 4; i < 13; i++)
> >         {
> >             temp.fields.pin_first = STM32F4_GPIO_PIN(4, i+3);

Re: stm32f4 __wfi

2019-06-24 Thread Christian Mauderer

On 24/06/2019 02:47, Jython wrote:
> that's to say EXTI wakes up from sleep function because interrupt
> handler log out
> but _CPU_Thread_Idle_body does not exit ?  want to know what is the
> sleep/idle exit condition?

The idle task is the task with the lowest priority. So it runs if no
other higher priority task (basically every task) is in the position to
run. In your case, your main task has been send to sleep with the
`sleep(10)` call. It should become active again after 10 seconds.

I vaguely remember that there was something about disabling some timing
mechanisms in your system. If you disabled the wrong parts, a sleep(10)
might never wake up again because it's missing it's timer that
determines whether 10 seconds passed. In that case you might want to
wait for some synchronization object instead (a signal, a mutex, some
event, ...) that you send from your interrupt.

PS: I re-added the user list on CC. I hope that is OK for you.

Best regards

Christian

> 
> On Fri, Jun 21, 2019 at 7:09 PM Christian Mauderer
>  <mailto:christian.maude...@embedded-brains.de>> wrote:
> 
> On 21/06/2019 11:53, Jython wrote:
> > i got it ,  i have coded some low power applications with
> stm32cube last
> > year,
> > may i just want to know more about the sleep and why it does not
> stop by
> > EXTI , maybe i need to rewrite sleep function ?
> 
> `sleep()` just suspends your current task. So you will reach (after a
> task switch) the idle loop.
> 
> >
> > On Fri, Jun 21, 2019 at 3:16 PM Christian Mauderer
> >  <mailto:christian.maude...@embedded-brains.de>
> > <mailto:christian.maude...@embedded-brains.de
> <mailto:christian.maude...@embedded-brains.de>>> wrote:
> >
> >     On 21/06/2019 02:58, Jython wrote:
> >     >
> >     > handler
> https://gist.github.com/goog/7bf5ec55139a3ed43e36be5b2eee318b
> >
> >     There are some things that I would strongly discourage in that
> interrupt
> >     handler (printk as long as it is not only a temporary debug
> output,
> >     delay, ...) but it shouldn't be the problem. I assume that you
> already
> >     checked, that you are testing for the right flag in the first
> if. So I
> >     would expect that you get your debug output if your interrupt
> occurs.
> >
> >     >
> >     > the main loop code
> >     > https://gist.github.com/goog/d83786e0eb2c97ad3126ded1987b5078
> >
> >     Same again: Some details but nothing that I would see as a
> cause for
> >     your problem.
> >
> >     >
> >     > when i pressed key, printf("loop begin\n"); does not print
> immediately
> >     > so the sleep function does not break
> >
> >     Note that printf is a interrupt driven print. So if you have
> problems
> >     with _some_ interrupts not waking up your device you might not
> get an
> >     output or maybe only a "l".
> >
> >     I agree with the mail from "groups chichak.ca
>     <http://chichak.ca> <http://chichak.ca>".
> >     It's a problem that is
> >     very chip specific and not really a RTEMS specific one. So it
> might
> >     would be a good idea to search for "STM32 not waking up" in the ST
> >     forums.
> >
> >     >
> >     >
> >     >
> >     > On Thu, Jun 20, 2019 at 10:47 PM Christian Mauderer
> >     mailto:l...@c-mauderer.de>
> <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de>>
> >     > <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de>
> <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de>>>> wrote:
> >     >
> >     >     On 20/06/2019 16:43, Jython wrote:
> >     >     > sleep function at the ending of loop, the loop did not
> begin
> >     >     intermediate
> >     >
> >     >     So just that I understand it correctly: Your have a loop
> in a
> >     task that
> >     >     sends your processor to sleep at the end of the loop.
> Then you
> >     wake up
> >     >     the processor via an interrupt and the interrupt handler is
> >     executed.
> >     >     But you don't reach the loop again?
> >     >
> >     >     I think I remember some discussion where you wanted t

Re: stm32f4 __wfi

2019-06-21 Thread Christian Mauderer

On 21/06/2019 11:53, Jython wrote:
> i got it ,  i have coded some low power applications with stm32cube last
> year,
> may i just want to know more about the sleep and why it does not stop by
> EXTI , maybe i need to rewrite sleep function ?

`sleep()` just suspends your current task. So you will reach (after a
task switch) the idle loop.

> 
> On Fri, Jun 21, 2019 at 3:16 PM Christian Mauderer
>  <mailto:christian.maude...@embedded-brains.de>> wrote:
> 
> On 21/06/2019 02:58, Jython wrote:
> >
> > handler https://gist.github.com/goog/7bf5ec55139a3ed43e36be5b2eee318b
> 
> There are some things that I would strongly discourage in that interrupt
> handler (printk as long as it is not only a temporary debug output,
> delay, ...) but it shouldn't be the problem. I assume that you already
> checked, that you are testing for the right flag in the first if. So I
> would expect that you get your debug output if your interrupt occurs.
> 
> >
> > the main loop code
> > https://gist.github.com/goog/d83786e0eb2c97ad3126ded1987b5078
> 
> Same again: Some details but nothing that I would see as a cause for
> your problem.
> 
> >
> > when i pressed key, printf("loop begin\n"); does not print immediately
> > so the sleep function does not break
> 
> Note that printf is a interrupt driven print. So if you have problems
> with _some_ interrupts not waking up your device you might not get an
> output or maybe only a "l".
> 
> I agree with the mail from "groups chichak.ca <http://chichak.ca>".
> It's a problem that is
> very chip specific and not really a RTEMS specific one. So it might
> would be a good idea to search for "STM32 not waking up" in the ST
> forums.
> 
> >
> >
> >
> > On Thu, Jun 20, 2019 at 10:47 PM Christian Mauderer
> mailto:l...@c-mauderer.de>
> > <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de>>> wrote:
> >
> >     On 20/06/2019 16:43, Jython wrote:
> >     > sleep function at the ending of loop, the loop did not begin
> >     intermediate
> >
> >     So just that I understand it correctly: Your have a loop in a
> task that
> >     sends your processor to sleep at the end of the loop. Then you
> wake up
> >     the processor via an interrupt and the interrupt handler is
> executed.
> >     But you don't reach the loop again?
> >
> >     I think I remember some discussion where you wanted to put a
> sleep into
> >     your idle loop? Maybe you have a double sleep?
> >
> >     >
> >     > On Thursday, June 20, 2019, Christian Mauderer
> mailto:l...@c-mauderer.de>
> >     <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de>>
> >     > <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de>
> <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de>>>> wrote:
> >     >
> >     >     On 20/06/2019 13:25, Jython wrote:
> >     >     > do have service routine,  handler can printk log, 
> >     SLEEPONEXIT is 0
> >     >
> >     >     So your handler is called? But it seems that the processor
> >     wakes up
> >     >     then. How does the "won't stop sleep mode" look like?
> >     >
> >     >     >
> >     >     > On Thu, Jun 20, 2019 at 5:19 PM Christian Mauderer
> >     >     mailto:l...@c-mauderer.de>
> <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de>>
> >     <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de>
> <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de>>>
> >     >     > <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de>
> <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de>>
> >     <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de>
> <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de>>>>> wrote:
> >     >     >
> >     >     >     On 20/06/2019 10:57, Jython wrote:
> >     >     >     > a GPIO EXTI line,
> >     >     >     > rtems idle phrase called __wfi, does it make
> stm32 enter
> >     >     standby mode?
> >     >     >     > so key can not wake up it from sleep function
> >     >     >
>

Re: stm32f4 __wfi

2019-06-21 Thread Christian Mauderer

On 21/06/2019 02:58, Jython wrote:
> 
> handler https://gist.github.com/goog/7bf5ec55139a3ed43e36be5b2eee318b

There are some things that I would strongly discourage in that interrupt
handler (printk as long as it is not only a temporary debug output,
delay, ...) but it shouldn't be the problem. I assume that you already
checked, that you are testing for the right flag in the first if. So I
would expect that you get your debug output if your interrupt occurs.

> 
> the main loop code
> https://gist.github.com/goog/d83786e0eb2c97ad3126ded1987b5078

Same again: Some details but nothing that I would see as a cause for
your problem.

> 
> when i pressed key, printf("loop begin\n"); does not print immediately
> so the sleep function does not break

Note that printf is a interrupt driven print. So if you have problems
with _some_ interrupts not waking up your device you might not get an
output or maybe only a "l".

I agree with the mail from "groups chichak.ca". It's a problem that is
very chip specific and not really a RTEMS specific one. So it might
would be a good idea to search for "STM32 not waking up" in the ST forums.

> 
> 
> 
> On Thu, Jun 20, 2019 at 10:47 PM Christian Mauderer  <mailto:l...@c-mauderer.de>> wrote:
> 
> On 20/06/2019 16:43, Jython wrote:
> > sleep function at the ending of loop, the loop did not begin
> intermediate
> 
> So just that I understand it correctly: Your have a loop in a task that
> sends your processor to sleep at the end of the loop. Then you wake up
> the processor via an interrupt and the interrupt handler is executed.
> But you don't reach the loop again?
> 
> I think I remember some discussion where you wanted to put a sleep into
> your idle loop? Maybe you have a double sleep?
> 
> >
> > On Thursday, June 20, 2019, Christian Mauderer  <mailto:l...@c-mauderer.de>
> > <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de>>> wrote:
> >
> >     On 20/06/2019 13:25, Jython wrote:
> >     > do have service routine,  handler can printk log, 
> SLEEPONEXIT is 0
> >
> >     So your handler is called? But it seems that the processor
> wakes up
> >     then. How does the "won't stop sleep mode" look like?
> >
> >     >
> >     > On Thu, Jun 20, 2019 at 5:19 PM Christian Mauderer
> >     mailto:l...@c-mauderer.de>
> <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de>>
> >     > <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de>
> <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de>>>> wrote:
> >     >
> >     >     On 20/06/2019 10:57, Jython wrote:
> >     >     > a GPIO EXTI line,
> >     >     > rtems idle phrase called __wfi, does it make stm32 enter
> >     standby mode?
> >     >     > so key can not wake up it from sleep function
> >     >
> >     >     Please take a look at the reference manual of your chip.
> Most
> >     likely
> >     >     it's "RM0090 Rev 18" but make sure that's the right part
> number:
> >     >
> >     >        
> >     https://www.st.com/resource/en/reference_manual/dm00031020.pdf
> >     <https://www.st.com/resource/en/reference_manual/dm00031020.pdf>
> >     >
> >     >     On page 127 there is a description of "Entering
> low-power mode":
> >     >
> >     >         "Low-power modes are entered by the MCU by executing the
> >     WFI (Wait
> >     >         For Interrupt), or WFE (Wait for Event) instructions, or
> >     when the
> >     >         SLEEPONEXIT bit in the Cortex ®-M4 with FPU System
> Control
> >     >         register is set on Return from ISR."
> >     >
> >     >     There is also a description for "Exiting low-power
> mode". For
> >     WFI "any
> >     >     peripheral interrupt acknowledged by the NVIC can wake
> up the
> >     device."
> >     >     So your interrupt has to be set up.
> >     >
> >     >     Your code seems to enable the interrupt. But have you
> registered a
> >     >     interrupt service routine? Otherwise you might get problems
> >     with an
> >     >     unhandled interrupt on wakeup.
> >

Re: stm32f4 __wfi

On 20/06/2019 16:43, Jython wrote:
> sleep function at the ending of loop, the loop did not begin intermediate

So just that I understand it correctly: Your have a loop in a task that
sends your processor to sleep at the end of the loop. Then you wake up
the processor via an interrupt and the interrupt handler is executed.
But you don't reach the loop again?

I think I remember some discussion where you wanted to put a sleep into
your idle loop? Maybe you have a double sleep?

> 
> On Thursday, June 20, 2019, Christian Mauderer  <mailto:l...@c-mauderer.de>> wrote:
> 
> On 20/06/2019 13:25, Jython wrote:
> > do have service routine,  handler can printk log,  SLEEPONEXIT is 0
> 
> So your handler is called? But it seems that the processor wakes up
> then. How does the "won't stop sleep mode" look like?
> 
>     >
> > On Thu, Jun 20, 2019 at 5:19 PM Christian Mauderer
> mailto:l...@c-mauderer.de>
> > <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de>>> wrote:
> >
> >     On 20/06/2019 10:57, Jython wrote:
> >     > a GPIO EXTI line,
> >     > rtems idle phrase called __wfi, does it make stm32 enter
> standby mode?
> >     > so key can not wake up it from sleep function
> >
> >     Please take a look at the reference manual of your chip. Most
> likely
> >     it's "RM0090 Rev 18" but make sure that's the right part number:
> >
> >        
> https://www.st.com/resource/en/reference_manual/dm00031020.pdf
> <https://www.st.com/resource/en/reference_manual/dm00031020.pdf>
> >
> >     On page 127 there is a description of "Entering low-power mode":
> >
> >         "Low-power modes are entered by the MCU by executing the
> WFI (Wait
> >         For Interrupt), or WFE (Wait for Event) instructions, or
> when the
> >         SLEEPONEXIT bit in the Cortex ®-M4 with FPU System Control
> >         register is set on Return from ISR."
> >
> >     There is also a description for "Exiting low-power mode". For
> WFI "any
> >     peripheral interrupt acknowledged by the NVIC can wake up the
> device."
> >     So your interrupt has to be set up.
> >
> >     Your code seems to enable the interrupt. But have you registered a
> >     interrupt service routine? Otherwise you might get problems
> with an
> >     unhandled interrupt on wakeup.
> >
> >     I only skimmed through the power controller chapter. But it
> seems that
> >     if you have SLEEPDEEP bit set, you will enter a deeper sleep mode
> >     where peripheral clocks can be disabled. In that state it's
> possible
> >     that only special pins (like the WKUP) can wake up the processor
> >     again. Please have a detailed look at that chapter to find out all
> >     traps.
> >
> >     Best regards
> >
> >     Christian
> >
> >     >
> >     >
> >     >     void keys_init()
> >     >     {
> >     >         // config gpio
> >     >     stm32f4_gpio_set_config(_key1);  // PA12
> >     >     stm32f4_gpio_set_config(_key2);
> >     >         stm32f4_gpio_set_config(_key3);
> >     >     stm32f4_gpio_set_config(_key4);
> >     >
> >     >       
> >     >         //  SYSCFGEN and exit map
> >     >     (*(uint32_t*)0x40023844) |= 1<<14;
> >     >       
> >     >         SYSCFG_EXTICR3 = 0;
> >     >         SYSCFG_EXTICR4 = 0;
> >     >       
> >     >
> >     >
> >     >         // EXIT INIT
> >     >     EXTI_IMR |= (1<<12);
> >     >     EXTI_RTSR |= (1<<12);
> >     >
> >     >         EXTI_IMR |= (1<<11);
> >     >     EXTI_RTSR |= (1<<11);
> >     >
> >     >         EXTI_IMR |= (1<<10);
> >     >     EXTI_RTSR |= (1<<10);
> >     >
> >     >         EXTI_IMR |= (1<<9);
> >     >     EXTI_RTSR |= (1<<9);
> >     >
> >     >
> >     >         //NVIC_Init
> >     >         //NVIC it group2
> >     >
> >     >     SCB_AIRCR = 0x05FA | 0x500;
> >     >     // ip Interrupt priority register x
>

Re: stm32f4 __wfi

On 20/06/2019 13:25, Jython wrote:
> do have service routine,  handler can printk log,  SLEEPONEXIT is 0

So your handler is called? But it seems that the processor wakes up
then. How does the "won't stop sleep mode" look like?

> 
> On Thu, Jun 20, 2019 at 5:19 PM Christian Mauderer  <mailto:l...@c-mauderer.de>> wrote:
> 
> On 20/06/2019 10:57, Jython wrote:
> > a GPIO EXTI line,
> > rtems idle phrase called __wfi, does it make stm32 enter standby mode?
> > so key can not wake up it from sleep function
> 
> Please take a look at the reference manual of your chip. Most likely
> it's "RM0090 Rev 18" but make sure that's the right part number:
> 
>     https://www.st.com/resource/en/reference_manual/dm00031020.pdf
> 
> On page 127 there is a description of "Entering low-power mode":
> 
>     "Low-power modes are entered by the MCU by executing the WFI (Wait
>     For Interrupt), or WFE (Wait for Event) instructions, or when the
>     SLEEPONEXIT bit in the Cortex ®-M4 with FPU System Control
>     register is set on Return from ISR."
> 
> There is also a description for "Exiting low-power mode". For WFI "any
> peripheral interrupt acknowledged by the NVIC can wake up the device."
> So your interrupt has to be set up.
> 
> Your code seems to enable the interrupt. But have you registered a
> interrupt service routine? Otherwise you might get problems with an
> unhandled interrupt on wakeup.
> 
> I only skimmed through the power controller chapter. But it seems that
> if you have SLEEPDEEP bit set, you will enter a deeper sleep mode
> where peripheral clocks can be disabled. In that state it's possible
> that only special pins (like the WKUP) can wake up the processor
> again. Please have a detailed look at that chapter to find out all
> traps.
> 
> Best regards
> 
> Christian
> 
> >
> >
> >     void keys_init()
> >     {
> >         // config gpio
> >     stm32f4_gpio_set_config(_key1);  // PA12
> >     stm32f4_gpio_set_config(_key2);
> >         stm32f4_gpio_set_config(_key3);
> >     stm32f4_gpio_set_config(_key4);
> >
> >       
> >         //  SYSCFGEN and exit map
> >     (*(uint32_t*)0x40023844) |= 1<<14;
> >       
> >         SYSCFG_EXTICR3 = 0;
> >         SYSCFG_EXTICR4 = 0;
> >       
> >
> >
> >         // EXIT INIT
> >     EXTI_IMR |= (1<<12);
> >     EXTI_RTSR |= (1<<12);
> >
> >         EXTI_IMR |= (1<<11);
> >     EXTI_RTSR |= (1<<11);
> >
> >         EXTI_IMR |= (1<<10);
> >     EXTI_RTSR |= (1<<10);
> >
> >         EXTI_IMR |= (1<<9);
> >     EXTI_RTSR |= (1<<9);
> >
> >
> >         //NVIC_Init
> >         //NVIC it group2
> >
> >     SCB_AIRCR = 0x05FA | 0x500;
> >     // ip Interrupt priority register x
> >
> >     //(*(volatile uint8_t*)0xE000E417) = 0xe0;  //23
> >         //(*(volatile uint8_t*)0xE000E428) = 0xe0;  // 40
> >         (*(volatile uint8_t*)0xE000E417) = 0x50;  //23
> >         (*(volatile uint8_t*)0xE000E428) = 0x50;  // 40
> >
> >
> >
> >     // 23 40 Interrupt set-enable register x (NVIC_ISERx)
> >         // nvic enable interrupter number
> >         // 0xE000E100
> >         (*(volatile uint32_t*)0xE000E100) |= (1<<23);
> >         (*(volatile uint32_t *)0xE000E104) |= (1<< (40%32));
> >     }
> >
> >
> > On Thu, Jun 20, 2019 at 4:05 PM Christian Mauderer
> mailto:l...@c-mauderer.de>
> > <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de>>> wrote:
> >
> >     On 20/06/2019 05:28, Jython wrote:
> >     > hi, it seems that exit key interrupt won't stop sleep mode, why?
> >     >
> >     > [...]
> >     >
> >
> >     What do you mean by "exit key interrupt"? I don't know the
> STM32F4 that
> >     well. So please give some more details.
> >
> >     I would expect that either only specific interrupt sources can
> wake up
> >     the processor from a deep sleep mode or that you can configure
> which
> >     peripherals are still active. If your "exit key" is a GPIO
> line with
> >     interrupt capability you should have a look at whether the
> module is
> >     still active.
> >
> >     Best regards
> >
> >     Christian
> >
> >     ___
> >     users mailing list
> >     users@rtems.org <mailto:users@rtems.org>
> <mailto:users@rtems.org <mailto:users@rtems.org>>
> >     http://lists.rtems.org/mailman/listinfo/users
> >
> 

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

Re: stm32f4 __wfi

On 20/06/2019 10:57, Jython wrote:
> a GPIO EXTI line,
> rtems idle phrase called __wfi, does it make stm32 enter standby mode?
> so key can not wake up it from sleep function

Please take a look at the reference manual of your chip. Most likely
it's "RM0090 Rev 18" but make sure that's the right part number:

https://www.st.com/resource/en/reference_manual/dm00031020.pdf

On page 127 there is a description of "Entering low-power mode":

"Low-power modes are entered by the MCU by executing the WFI (Wait
For Interrupt), or WFE (Wait for Event) instructions, or when the
SLEEPONEXIT bit in the Cortex ®-M4 with FPU System Control
register is set on Return from ISR."

There is also a description for "Exiting low-power mode". For WFI "any
peripheral interrupt acknowledged by the NVIC can wake up the device."
So your interrupt has to be set up.

Your code seems to enable the interrupt. But have you registered a
interrupt service routine? Otherwise you might get problems with an
unhandled interrupt on wakeup.

I only skimmed through the power controller chapter. But it seems that
if you have SLEEPDEEP bit set, you will enter a deeper sleep mode
where peripheral clocks can be disabled. In that state it's possible
that only special pins (like the WKUP) can wake up the processor
again. Please have a detailed look at that chapter to find out all
traps.

Best regards

Christian

> 
> 
> void keys_init()
> {
> // config gpio
> stm32f4_gpio_set_config(_key1);  // PA12
> stm32f4_gpio_set_config(_key2);
> stm32f4_gpio_set_config(_key3);
> stm32f4_gpio_set_config(_key4);
> 
>
> //  SYSCFGEN and exit map
> (*(uint32_t*)0x40023844) |= 1<<14;
>
> SYSCFG_EXTICR3 = 0;
> SYSCFG_EXTICR4 = 0;
>
> 
> 
> // EXIT INIT
> EXTI_IMR |= (1<<12);
> EXTI_RTSR |= (1<<12);
> 
> EXTI_IMR |= (1<<11);
> EXTI_RTSR |= (1<<11);
> 
> EXTI_IMR |= (1<<10);
> EXTI_RTSR |= (1<<10);
> 
> EXTI_IMR |= (1<<9);
> EXTI_RTSR |= (1<<9);
> 
> 
> //NVIC_Init
> //NVIC it group2
> 
> SCB_AIRCR = 0x05FA | 0x500;
> // ip Interrupt priority register x
> 
> //(*(volatile uint8_t*)0xE000E417) = 0xe0;  //23
> //(*(volatile uint8_t*)0xE000E428) = 0xe0;  // 40
> (*(volatile uint8_t*)0xE000E417) = 0x50;  //23
> (*(volatile uint8_t*)0xE000E428) = 0x50;  // 40
> 
> 
> 
> // 23 40 Interrupt set-enable register x (NVIC_ISERx)
> // nvic enable interrupter number
> // 0xE000E100
> (*(volatile uint32_t*)0xE000E100) |= (1<<23);
> (*(volatile uint32_t *)0xE000E104) |= (1<< (40%32));
> } 
> 
> 
> On Thu, Jun 20, 2019 at 4:05 PM Christian Mauderer  <mailto:l...@c-mauderer.de>> wrote:
> 
> On 20/06/2019 05:28, Jython wrote:
> > hi, it seems that exit key interrupt won't stop sleep mode, why?
> >
> > [...]
> >
> 
> What do you mean by "exit key interrupt"? I don't know the STM32F4 that
> well. So please give some more details.
> 
> I would expect that either only specific interrupt sources can wake up
> the processor from a deep sleep mode or that you can configure which
> peripherals are still active. If your "exit key" is a GPIO line with
> interrupt capability you should have a look at whether the module is
> still active.
> 
> Best regards
> 
> Christian
> 
> ___
> users mailing list
> users@rtems.org <mailto:users@rtems.org>
> http://lists.rtems.org/mailman/listinfo/users
> 

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

Re: stm32f4 __wfi

On 20/06/2019 05:28, Jython wrote:
> hi, it seems that exit key interrupt won't stop sleep mode, why?
> 
> [...]
> 

What do you mean by "exit key interrupt"? I don't know the STM32F4 that
well. So please give some more details.

I would expect that either only specific interrupt sources can wake up
the processor from a deep sleep mode or that you can configure which
peripherals are still active. If your "exit key" is a GPIO line with
interrupt capability you should have a look at whether the module is
still active.

Best regards

Christian

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

Re: stm32 external SRAM

2019-06-17 Thread Christian Mauderer

On 18/06/2019 03:25, Jython wrote:
> my linkscmd is https://gist.github.com/goog/aad6dae4c418255dd6fb2b23bf2e6f08
> 
> void BSP_START_TEXT_SECTION bsp_start_hook_1(void)
> {
>   SRAM_fsmc_setup();
>   bsp_start_copy_sections();
>   bsp_start_clear_bss();
> 
>   /* At this point we can use objects outside the .start section */
> }
> 
> 
> but now my code run disordered

Which one?

The SRAM_fsmc_setup()? In that case please note that you are in a very
early initialization step. So most system services won't work and global
variables are not initialized yet.

Or your later application code? In that case: Did you do a memory test
to check your RAM initialization? For example the routines from Michael
Barr from here work well:
http://www.esacademy.com/en/library/technical-articles-and-documents/miscellaneous/software-based-memory-testing.html

> 
> On Mon, Jun 17, 2019 at 2:45 PM Christian Mauderer
>  <mailto:christian.maude...@embedded-brains.de>> wrote:
> 
> If you put any sections into the external RAM that need initialization,
> you have to init the RAM before the BSP copies it's sections. The STM32
> BSP copies it's sections in bsp_start_hook_1(). So either put it in
> bsp_start_hook_0 or in bsp_start_hook_1 before the copy_section calls.
> Attention: You can't use much in these functions. They are in a very
> early initialization stage. So be careful what you put there.
> 
> If you only want malloc to allocate memory from there, there might is a
> later point where you can do that.
> 
> On 17/06/2019 08:32, Jython wrote:
> > Thank you and the example! that is to say put extern sram init in
> > bsp_start( void ) function?
> >
> > On Mon, Jun 17, 2019 at 1:04 PM Christian Mauderer
> >  <mailto:christian.maude...@embedded-brains.de>
> > <mailto:christian.maude...@embedded-brains.de
> <mailto:christian.maude...@embedded-brains.de>>> wrote:
> >
> >     On 17/06/2019 03:05, Jython wrote:
> >     > STM32:
> >     >     112KB at 2000 
> >     >     16KB at 2001 C000
> >     >
> >     > external sram : 1MB at 0x6800
> >     >
> >     >  does MEMORY layout support RAM2?
> >
> >     Hello Jython,
> >
> >     you can distribute the regions to the two RAMs. For example
> this BSP
> >     does that:
> >
> >   
>  
> https://git.rtems.org/rtems/tree/bsps/arm/lpc32xx/start/linkcmds.lpc32xx_phycore
> >
> >     Please note that you have to take a detailed look at what is
> used till
> >     your external RAM initialization run and what not. But if you
> put your
> >     external RAM initialization in an early enough step, you
> shouldn't get
> >     problems with that.
> >
> >     Best regards
> >
> >     Christian
> >
> >     >
> >     > On Fri, Jun 14, 2019 at 10:13 PM Christian Mauderer
> >     >  <mailto:christian.maude...@embedded-brains.de>
> >     <mailto:christian.maude...@embedded-brains.de
> <mailto:christian.maude...@embedded-brains.de>>
> >     > <mailto:christian.maude...@embedded-brains.de
> <mailto:christian.maude...@embedded-brains.de>
> >     <mailto:christian.maude...@embedded-brains.de
> <mailto:christian.maude...@embedded-brains.de>>>> wrote:
> >     >
> >     >     If you have already added the chip and it is initialized
> >     during startup,
> >     >     you most likely have to add a section for it in your linker
> >     command
> >     >     file. Depending on where your internal RAM is located and
> >     where the
> >     >     external one is: If they are continuous that can be enough.
> >     >
> >     >     Best regards
> >     >
> >     >     Christian
> >     >
> >     >     On 14/06/2019 04:42, Jython wrote:
> >     >     > we have added 1M ram by FSMC,  and want to manage it by
> >     system malloc
> >     >     > controler
> >     >     >
> >     >     > On Fri, Jun 14, 2019 at 10:26 AM Mr. Andrei Chichak
> >     >     mailto:gro...@chichak.ca>
> <mailto:gro...@chichak.ca <mailto:gro...@chichak.ca>>
> >     <mailto:gro...@chichak.ca <mailto:gro...@chichak.ca>
> <mailto:gro...

Re: stm32 external SRAM

2019-06-17 Thread Christian Mauderer

If you put any sections into the external RAM that need initialization,
you have to init the RAM before the BSP copies it's sections. The STM32
BSP copies it's sections in bsp_start_hook_1(). So either put it in
bsp_start_hook_0 or in bsp_start_hook_1 before the copy_section calls.
Attention: You can't use much in these functions. They are in a very
early initialization stage. So be careful what you put there.

If you only want malloc to allocate memory from there, there might is a
later point where you can do that.

On 17/06/2019 08:32, Jython wrote:
> Thank you and the example! that is to say put extern sram init in
> bsp_start( void ) function?
> 
> On Mon, Jun 17, 2019 at 1:04 PM Christian Mauderer
>  <mailto:christian.maude...@embedded-brains.de>> wrote:
> 
> On 17/06/2019 03:05, Jython wrote:
> > STM32:
> >     112KB at 2000 
> >     16KB at 2001 C000
> >
> > external sram : 1MB at 0x6800
> >
> >  does MEMORY layout support RAM2?
> 
> Hello Jython,
> 
> you can distribute the regions to the two RAMs. For example this BSP
> does that:
> 
> 
> https://git.rtems.org/rtems/tree/bsps/arm/lpc32xx/start/linkcmds.lpc32xx_phycore
> 
> Please note that you have to take a detailed look at what is used till
> your external RAM initialization run and what not. But if you put your
> external RAM initialization in an early enough step, you shouldn't get
> problems with that.
> 
> Best regards
> 
> Christian
> 
> >
> > On Fri, Jun 14, 2019 at 10:13 PM Christian Mauderer
> >  <mailto:christian.maude...@embedded-brains.de>
> > <mailto:christian.maude...@embedded-brains.de
> <mailto:christian.maude...@embedded-brains.de>>> wrote:
> >
> >     If you have already added the chip and it is initialized
> during startup,
> >     you most likely have to add a section for it in your linker
> command
> >     file. Depending on where your internal RAM is located and
> where the
> >     external one is: If they are continuous that can be enough.
> >
> >     Best regards
> >
> >     Christian
> >
> >     On 14/06/2019 04:42, Jython wrote:
> >     > we have added 1M ram by FSMC,  and want to manage it by
> system malloc
> >     > controler
> >     >
> >     > On Fri, Jun 14, 2019 at 10:26 AM Mr. Andrei Chichak
> >     mailto:gro...@chichak.ca>
> <mailto:gro...@chichak.ca <mailto:gro...@chichak.ca>>
> >     > <mailto:gro...@chichak.ca <mailto:gro...@chichak.ca>
> <mailto:gro...@chichak.ca <mailto:gro...@chichak.ca>>>> wrote:
> >     >
> >     >     A 407 doesn’t normally have external RAM.
> >     >
> >     >     ARMs have flash at 0 and the 407 has RAM at 0x2000 
> as you
> >     >     discussed earlier.
> >     >
> >     >     If you want to work with external flash or RAM, you have
>     to set up
> >     >     the FSMC or FMC to support it, but that isn’t a part of
> the dev
> >     >     board that Sebastian used for the BSP port.
> >     >
> >     >     The external memory is going to be very specific to your
> board.
> >     >     Which board are you working with?
> >     >
> >     >     A
> >     >
> >     >     > On 2019-June-13, at 06:23, Christian Mauderer
> >     >      <mailto:christian.maude...@embedded-brains.de>
> >     <mailto:christian.maude...@embedded-brains.de
> <mailto:christian.maude...@embedded-brains.de>>
> >     >     <mailto:christian.maude...@embedded-brains.de
> <mailto:christian.maude...@embedded-brains.de>
> >     <mailto:christian.maude...@embedded-brains.de
> <mailto:christian.maude...@embedded-brains.de>>>> wrote:
> >     >     >
> >     >     > On 05/06/2019 02:55, Jython wrote:
> >     >     >> Hello!
> >     >     >>
> >     >     >>     2. In the normal (non-debugging) case, the linker
> >     script still
> >     >     >>        places the
> >     >     >>
> >     >     >>    .text section near zero, but places the start of the
> >     .data and
> >     >     .bss
> >     >     >>

Re: stm32 external SRAM

2019-06-16 Thread Christian Mauderer

On 17/06/2019 03:05, Jython wrote:
> STM32:
>     112KB at 2000 
>     16KB at 2001 C000
> 
> external sram : 1MB at 0x6800
> 
>  does MEMORY layout support RAM2?

Hello Jython,

you can distribute the regions to the two RAMs. For example this BSP
does that:

https://git.rtems.org/rtems/tree/bsps/arm/lpc32xx/start/linkcmds.lpc32xx_phycore

Please note that you have to take a detailed look at what is used till
your external RAM initialization run and what not. But if you put your
external RAM initialization in an early enough step, you shouldn't get
problems with that.

Best regards

Christian

> 
> On Fri, Jun 14, 2019 at 10:13 PM Christian Mauderer
>  <mailto:christian.maude...@embedded-brains.de>> wrote:
> 
> If you have already added the chip and it is initialized during startup,
> you most likely have to add a section for it in your linker command
> file. Depending on where your internal RAM is located and where the
> external one is: If they are continuous that can be enough.
> 
> Best regards
> 
> Christian
> 
> On 14/06/2019 04:42, Jython wrote:
> > we have added 1M ram by FSMC,  and want to manage it by system malloc
> > controler
> >
> > On Fri, Jun 14, 2019 at 10:26 AM Mr. Andrei Chichak
> mailto:gro...@chichak.ca>
> > <mailto:gro...@chichak.ca <mailto:gro...@chichak.ca>>> wrote:
> >
> >     A 407 doesn’t normally have external RAM.
> >
> >     ARMs have flash at 0 and the 407 has RAM at 0x2000  as you
> >     discussed earlier.
> >
> >     If you want to work with external flash or RAM, you have to set up
> >     the FSMC or FMC to support it, but that isn’t a part of the dev
> >     board that Sebastian used for the BSP port.
> >
> >     The external memory is going to be very specific to your board.
> >     Which board are you working with?
> >
> >     A
> >
> >     > On 2019-June-13, at 06:23, Christian Mauderer
> >      <mailto:christian.maude...@embedded-brains.de>
> >     <mailto:christian.maude...@embedded-brains.de
> <mailto:christian.maude...@embedded-brains.de>>> wrote:
> >     >
> >     > On 05/06/2019 02:55, Jython wrote:
> >     >> Hello!
> >     >>
> >     >>     2. In the normal (non-debugging) case, the linker
> script still
> >     >>        places the
> >     >>
> >     >>    .text section near zero, but places the start of the
> .data and
> >     .bss
> >     >>    sections at the start location of the MPC555's internal
> RAM. The
> >     >>    system startup code then configures the external RAM just
> >     after the
> >     >>    internal RAM in memory, forming one large block from the
> two RAM
> >     >>    devices.
> >     >>
> >     >> from https://devel.rtems.org/wiki/TBR/BSP/Ss555
> >     >>
> >     >> but i dont know how to configure the external RAM just
> after the
> >     >> internal RAM in memory?
> >     >> hope you could give me some guide!
> >     >> 
> >     >>
> >     >
> >     > Hello Jython,
> >     >
> >     > the documentation you linked is for an MPC. But your subject
> line
> >     > mentions an STM32. What controller / BSP are you using?
> >     >
> >     > Best regards
> >     >
> >     > Christian Mauderer
> >     > --
> >     > 
> >     > embedded brains GmbH
> >     > Herr Christian Mauderer
> >     > Dornierstr. 4
> >     > D-82178 Puchheim
> >     > Germany
> >     > email: christian.maude...@embedded-brains.de
> <mailto:christian.maude...@embedded-brains.de>
> >     <mailto:christian.maude...@embedded-brains.de
> <mailto:christian.maude...@embedded-brains.de>>
> >     > Phone: +49-89-18 94 741 - 18
> >     > Fax:   +49-89-18 94 741 - 08
> >     > PGP: Public key available on request.
> >     >
> >     > Diese Nachricht ist keine geschäftliche Mitteilung im Sinne
> des EHUG.
> >     > ___
> >     > users mailing list
> >     &g

Re: stm32 external SRAM

2019-06-14 Thread Christian Mauderer

If you have already added the chip and it is initialized during startup,
you most likely have to add a section for it in your linker command
file. Depending on where your internal RAM is located and where the
external one is: If they are continuous that can be enough.

Best regards

Christian

On 14/06/2019 04:42, Jython wrote:
> we have added 1M ram by FSMC,  and want to manage it by system malloc
> controler
> 
> On Fri, Jun 14, 2019 at 10:26 AM Mr. Andrei Chichak  <mailto:gro...@chichak.ca>> wrote:
> 
> A 407 doesn’t normally have external RAM.
> 
> ARMs have flash at 0 and the 407 has RAM at 0x2000  as you
> discussed earlier.
> 
> If you want to work with external flash or RAM, you have to set up
> the FSMC or FMC to support it, but that isn’t a part of the dev
> board that Sebastian used for the BSP port.
> 
> The external memory is going to be very specific to your board.
> Which board are you working with?
> 
> A
> 
> > On 2019-June-13, at 06:23, Christian Mauderer
>  <mailto:christian.maude...@embedded-brains.de>> wrote:
> >
> > On 05/06/2019 02:55, Jython wrote:
> >> Hello!
> >>
> >>     2. In the normal (non-debugging) case, the linker script still
> >>        places the
> >>
> >>    .text section near zero, but places the start of the .data and
> .bss
> >>    sections at the start location of the MPC555's internal RAM. The
> >>    system startup code then configures the external RAM just
> after the
> >>    internal RAM in memory, forming one large block from the two RAM
> >>    devices.
> >>
> >> from https://devel.rtems.org/wiki/TBR/BSP/Ss555
> >>
> >> but i dont know how to configure the external RAM just after the
> >> internal RAM in memory?
> >> hope you could give me some guide!
> >> 
> >>
> >
> > Hello Jython,
> >
> > the documentation you linked is for an MPC. But your subject line
> > mentions an STM32. What controller / BSP are you using?
> >
> > Best regards
> >
> > Christian Mauderer
> > --
> > 
> > embedded brains GmbH
> > Herr Christian Mauderer
> > Dornierstr. 4
> > D-82178 Puchheim
> > Germany
> > email: christian.maude...@embedded-brains.de
> <mailto:christian.maude...@embedded-brains.de>
> > Phone: +49-89-18 94 741 - 18
> > Fax:   +49-89-18 94 741 - 08
> > PGP: Public key available on request.
> >
> > Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
> > ___
> > users mailing list
> > users@rtems.org <mailto:users@rtems.org>
> > http://lists.rtems.org/mailman/listinfo/users
> 
> 
> ___
> users mailing list
> users@rtems.org
> http://lists.rtems.org/mailman/listinfo/users
> 

-- 

embedded brains GmbH
Herr Christian Mauderer
Dornierstr. 4
D-82178 Puchheim
Germany
email: christian.maude...@embedded-brains.de
Phone: +49-89-18 94 741 - 18
Fax:   +49-89-18 94 741 - 08
PGP: Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users

Re: stm32 external SRAM

2019-06-13 Thread Christian Mauderer

On 05/06/2019 02:55, Jython wrote:
> Hello!
> 
>  2. In the normal (non-debugging) case, the linker script still
> places the 
> 
> .text section near zero, but places the start of the .data and .bss
> sections at the start location of the MPC555's internal RAM. The
> system startup code then configures the external RAM just after the
> internal RAM in memory, forming one large block from the two RAM
> devices.
> 
> from https://devel.rtems.org/wiki/TBR/BSP/Ss555
> 
> but i dont know how to configure the external RAM just after the
> internal RAM in memory?
> hope you could give me some guide!
>  
> 

Hello Jython,

the documentation you linked is for an MPC. But your subject line
mentions an STM32. What controller / BSP are you using?

Best regards

Christian Mauderer
-- 
----
embedded brains GmbH
Herr Christian Mauderer
Dornierstr. 4
D-82178 Puchheim
Germany
email: christian.maude...@embedded-brains.de
Phone: +49-89-18 94 741 - 18
Fax:   +49-89-18 94 741 - 08
PGP: Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users

Re: BeagleBone Black Networking (wifi and/or wired)

2019-06-11 Thread Christian Mauderer

On 11/06/2019 01:27, Chris Johns wrote:
> On 9/6/19 6:00 pm, Christian Mauderer wrote:
>> On 09/06/2019 04:24, Chris Johns wrote:
>>> On 8/6/19 1:45 am, Christian Mauderer wrote:
>>>> Note that basically all device tree files that I have found yet are forked 
>>>> from the Linux ones.
>>>
>>> Yes, I understand this is the case.
>>>
>>>> They are all GPL.
>>>
>>> We need to work with these files and respect the license they are under. I 
>>> think
>>> GPL DTS is OK if these files are not linked into an executable. I am not 
>>> sure
>>> where you stand in relation to the GPL license if you link a GPL dtb into an
>>> executable. An overlay we create under a suitable license should be fine.
>>
>> Normally the DTB isn't linked in but loaded by some bootloader from a
>> file system so I agree that it shouldn't affect the license of the blob.
>>
>>>
>>>> I think it was Sichen Zhao during 2017 GSoC who wanted to add some to the 
>>>> RTEMS repository and it has been rejected due to the license.
>>>
>>> I remember and I still think the position discussed is fine.
>>>
>>>> I don't really object to adding them somewhere.
>>>
>>> What do we host and maintain? Do we need to host any of these files or 
>>> should we
>>> have a tool to collect and/or generate the blobs we need.
>>
>> Most likely for most device trees it would be best to just refer to some
>> external source. For example the Linux tree or the one in FreeBSD (which
>> is a fork of the one from Linux) or some extracted tree.
>>
>> We maybe have some exceptions with custom dts files or we can provide
>> some small overlays in case we need something special.
> 
> Yes I think this is the best approach.
> 
>>
>>>
>>>> But we should think exactly about where we want that stuff.
>>>
>>> Having a blob as a file in a system theoretically lets someone update it. 
>>> The
>>> `dtc` compiler can generate the dts source from a blob so a user can 
>>> recover the
>>> source, make a change, generate a blob, then return it back into a system if
>>> they wish too.
>>
>> Yes and if it is compiled with -@ option of the dtc it can even be
>> extended with overlays. But due to the GPL we should also provide a
>> matching source archive if we provide binaries.
> 
> Of course. If the RSB builds a DTB we will have downloaded and made available
> the source for the user to manage. They also know it is valid.
> 
>>>
>>> What about building the FDT blobs we need with the RSB? I know this will 
>>> work on
>>> FreeBSD and I suspect Linux, MacOS has some issues with clang's cpp.
>>
>> I think there are more and more BSPs that can use the FDT (especially
>> ones that use libbsd) so it would be a good thing if they can be build
>> by RSB.
> 
> I agree however we have some rough edges we need to document and/or clean up.
> 
> For example running libbsd with a beaglebone booted without a device tree
> crashes with a NULL pointer access when libbsd checks the magic value in the 
> DTB
> header (I could not quickly find how libbsd is passed the DTB pointer from the
> BSP). If you provide a DTB but use `mkimage` with the RTEMS output format (`-O
> rtems`) libbsd crashes because the RTEMS format image loading in u-boot does 
> not
> handle device trees. We need to use the Linux format which is not an obvious
> thing to do. As a result you need to have a very precise set up or you get a 
> low
> level crash.
> 

I'm not entirely sure but I think that the Linux format should be the
default now. I think the RTEMS format is more or less a legacy one. I
did a grep in the rtems-docs and all three mkimage calls show a "-O linux".

>> But please also note that we shouldn't see RSB as the only source for
>> DTBs.
> 
> Agreed, it is a way for us to capture and provide all the source in a board.
> 
>> It's not uncommon that there is already a DTB on a board that is
>> just used by our BSP. 
> 
> Yes and this is also a weakness because I fele not enough people build or 
> check
> the source is what they have as a binary image and it is being maintained.
> 
> For example with an upstream master u-boot a beaglebone built with the latest
> RTEMS compiler does not work, the SD card access is suspect so I wonder if
> something low level has been optimized differently. Using a gcc 6 something
> works. Building a Zynq gives you a warning that the board will be removed from
> u-

Re: [EXTERNAL] Re: BeagleBone Black Networking (wifi and/or wired)

2019-06-09 Thread Christian Mauderer

On 09/06/2019 08:59, Chris Johns wrote:
> On 9/6/19 4:29 pm, Vijay Kumar Banerjee wrote:
>> On Sun, Jun 9, 2019 at 6:22 AM Chris Johns > <mailto:chr...@rtems.org>> wrote:
>> On 8/6/19 5:58 pm, Christian Mauderer wrote:
>> > - Ursprüngliche Mail -
>> >> Von: "Oyake, Amalaye (386M)" > <mailto:amalaye.oy...@jpl.nasa.gov>>
>> >> An: "Chris Johns" mailto:chr...@rtems.org>>, "Vijay
>> Kumar Banerjee" > <mailto:vijaykumar9...@gmail.com>>, "Christian Mauderer"
>> >> > <mailto:christian.maude...@embedded-brains.de>>
>> >> CC: "RTEMS Users" mailto:users@rtems.org>>
>> >> Gesendet: Samstag, 8. Juni 2019 04:57:02
>> >> Betreff: Re: [EXTERNAL] Re: BeagleBone Black Networking (wifi and/or 
>> wired)
>> >
>> >> Device Tree overays are a method used to update the Device Tree. 
>> Given a
>> device
>> >> tree that describes all the devices, let's say you add a new SPI 
>> device, you
>> >> can update the device tree with a (blob) device tree overlay.
>> >>
>> >> I should ask (without Googling), What is the Device Tree Overlay 
>> mechanism in
>> >> RTEMS?
>> >
>> >
>> > Hello Amalaye,
>> >
>> > as far as I know, the device tree overlay mechanism in RTEMS is not
>> implemented. There is the prototype of fdt_overlay_apply() in libfdt.h 
>> but
>> there is no implementation. So there are two methods:
>> >
>> > 1. Applying the overlay on a build machine. Vijay did that during his 
>> tests.
>>
>> How do you do this?
>>
>> I used `fdtoverlay` from libfdt on linux host. 
> 
> Could cpukit/dtc/libfd in RTEMS be updated to support this code? I see 
> freebsd's
> kernel has the code.
> 

Theoretically that could be possible. If I understand it correctly, that
would mean that we could apply an overlay after boot. That would mean a
lot of additional stuff. For all changed parts the matching drivers
would have to be load or maybe some other ones have to be unload.
Basically we would need a dynamic device management for that. As long as
there is no concrete use case I don't think it's useful to do that work.

>>
>> > 2. Use the U-Boot mechanism to apply overlays before booting RTEMS. 
>> That
>> should most likely work too. But I didn't test it yet.
>>
>> OK
>>
>> >> On 6/7/19, 6:17 PM, "users on behalf of Chris Johns"
>> mailto:users-boun...@rtems.org> on
>> >> behalf of chr...@rtems.org <mailto:chr...@rtems.org>> wrote:
>> >>
>> >>    On 8/6/19 1:53 am, Vijay Kumar Banerjee wrote:
>> >>    >
>> >>    > I would like to add that in two projects of this year( I2C and
>> PRU-ICSS drivers)
>> >>    > we
>> >>    > are using our own device tree overlays that make our drivers 
>> work.
>> Where to add
>> >>    > the device
>> >>    > tree related stuff seems like an important question.
>> >>   
>> >>    What are device tree overlays?
>> >
>> > Like Oyake already said: They are some small pices of device trees that
>> are just added to the base tree in it's binary form. Linux (and most 
>> likely
>> FreeBSD too) supports that even after boot. If you add an overlay it
>> re-parses the device tree, updates GPIO settings and loads new drivers. 
>> The
>> alternative is to let the boot loader apply them during boot.
>>
>> What is needed to do this? Maybe I can add it to rtems-boot-image as a 
>> way to
>> handle this at the u-boot version.
>>
>> I have also tried to automate it by adding it in uEnv.txt as a script, it 
>> worked
>> nicely to apply
>> the overlay on the blob, I haven't tested it with any app though, but the
>> overlay applied
>> successfully. Here's what the test uEnv.txt looks like. 
>> ```
>> setenv bootdelay 5
>> uenvcmd=run overlay_cmd boot
>> overlay_cmd=fatload mmc 0 0x8080 rtems-app.img; fatload mmc 0 0x8800
>> am335x-boneblack.dtb; fatload mmc 0 0x8810 am335x-rtems.dtbo; fdt addr
>> 0x8800; fdt resize 0x1000; fdt apply 0x8810;
>> boot=bootm 0x8080 - 0x8800;
>> ```
>>
>> You can add s

Re: BeagleBone Black Networking (wifi and/or wired)

2019-06-09 Thread Christian Mauderer

On 09/06/2019 04:24, Chris Johns wrote:
> On 8/6/19 1:45 am, Christian Mauderer wrote:
>> Note that basically all device tree files that I have found yet are forked 
>> from the Linux ones.
> 
> Yes, I understand this is the case.
> 
>> They are all GPL.
> 
> We need to work with these files and respect the license they are under. I 
> think
> GPL DTS is OK if these files are not linked into an executable. I am not sure
> where you stand in relation to the GPL license if you link a GPL dtb into an
> executable. An overlay we create under a suitable license should be fine.

Normally the DTB isn't linked in but loaded by some bootloader from a
file system so I agree that it shouldn't affect the license of the blob.

> 
>> I think it was Sichen Zhao during 2017 GSoC who wanted to add some to the 
>> RTEMS repository and it has been rejected due to the license.
> 
> I remember and I still think the position discussed is fine.
> 
>> I don't really object to adding them somewhere.
> 
> What do we host and maintain? Do we need to host any of these files or should 
> we
> have a tool to collect and/or generate the blobs we need.

Most likely for most device trees it would be best to just refer to some
external source. For example the Linux tree or the one in FreeBSD (which
is a fork of the one from Linux) or some extracted tree.

We maybe have some exceptions with custom dts files or we can provide
some small overlays in case we need something special.

> 
>> But we should think exactly about where we want that stuff.
> 
> Having a blob as a file in a system theoretically lets someone update it. The
> `dtc` compiler can generate the dts source from a blob so a user can recover 
> the
> source, make a change, generate a blob, then return it back into a system if
> they wish too.

Yes and if it is compiled with -@ option of the dtc it can even be
extended with overlays. But due to the GPL we should also provide a
matching source archive if we provide binaries.

> 
> What about building the FDT blobs we need with the RSB? I know this will work 
> on
> FreeBSD and I suspect Linux, MacOS has some issues with clang's cpp.

I think there are more and more BSPs that can use the FDT (especially
ones that use libbsd) so it would be a good thing if they can be build
by RSB.

But please also note that we shouldn't see RSB as the only source for
DTBs. It's not uncommon that there is already a DTB on a board that is
just used by our BSP. Either because it's some evaluation board with a
matching one programmed somewhere and loaded by the original U-Boot or
for some FPGA based BSPs the DTB can be generated by the FPGA tools.

Best regards

Christian

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

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

Re: [EXTERNAL] Re: BeagleBone Black Networking (wifi and/or wired)

2019-06-08 Thread Christian Mauderer

- Ursprüngliche Mail -
> Von: "Oyake, Amalaye (386M)" 
> An: "Chris Johns" , "Vijay Kumar Banerjee" 
> , "Christian Mauderer"
> 
> CC: "RTEMS Users" 
> Gesendet: Samstag, 8. Juni 2019 04:57:02
> Betreff: Re: [EXTERNAL] Re: BeagleBone Black Networking (wifi and/or wired)

> Device Tree overays are a method used to update the Device Tree. Given a 
> device
> tree that describes all the devices, let's say you add a new SPI device, you
> can update the device tree with a (blob) device tree overlay.
> 
> I should ask (without Googling), What is the Device Tree Overlay mechanism in
> RTEMS?

Hello Amalaye,

as far as I know, the device tree overlay mechanism in RTEMS is not 
implemented. There is the prototype of fdt_overlay_apply() in libfdt.h but 
there is no implementation. So there are two methods:

1. Applying the overlay on a build machine. Vijay did that during his tests.

2. Use the U-Boot mechanism to apply overlays before booting RTEMS. That should 
most likely work too. But I didn't test it yet.

> 
> Regards,
> --
> * Amalaye Oyake, NASA / Jet Propulsion Laboratory.  */\  *
> * Jet Propulsion Laboratory, Pasadena   *||  *
> * CA/||\ *
> *^^***
> 
> 
>On 6/7/19, 6:17 PM, "users on behalf of Chris Johns" on
>behalf of chr...@rtems.org> wrote:
> 
>On 8/6/19 1:53 am, Vijay Kumar Banerjee wrote:
>> 
>> I would like to add that in two projects of this year( I2C and PRU-ICSS 
> drivers)
>> we
>> are using our own device tree overlays that make our drivers work. Where 
> to add
>> the device
>> tree related stuff seems like an important question.
>
>What are device tree overlays?

Like Oyake already said: They are some small pices of device trees that are 
just added to the base tree in it's binary form. Linux (and most likely FreeBSD 
too) supports that even after boot. If you add an overlay it re-parses the 
device tree, updates GPIO settings and loads new drivers. The alternative is to 
let the boot loader apply them during boot.

A practical example would be adding a I2C device like a DS1338 RTC to the 
extension connector of the Beagle: 
https://github.com/beagleboard/bb.org-overlays/blob/master/src/arm/BB-I2C2-RTC-DS1338.dts

I suggested them for Vijays GSoC project to be able to add an I2C adaption 
layer so that libbsd uses the RTEMS i2c drivers. That's necessary so that RTEMS 
applications can still use the RTEMS i2c interface but at the same time the 
FreeBSD drivers (in that case for some chip related to HDMI) can use the BSD 
interface.

Best regards

Christian

>
>Chris

-- 

embedded brains GmbH
Christian Mauderer
Dornierstr. 4
D-82178 Puchheim
Germany
email: christian.maude...@embedded-brains.de
Phone: +49-89-18 94 741 - 18
Fax:   +49-89-18 94 741 - 08
PGP: Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users

Re: BeagleBone Black Networking (wifi and/or wired)



- Ursprüngliche Mail -
> Von: "Chris Johns" 
> An: "Christian Mauderer" , "RTEMS 
> Users" 
> Gesendet: Freitag, 7. Juni 2019 14:23:51
> Betreff: Re: BeagleBone Black Networking (wifi and/or wired)

> On 7/6/19 7:41 pm, Christian Mauderer wrote:
>> On 07/06/2019 11:19, Chris Johns wrote:
>>> On 7/6/19 7:18 pm, Christian Mauderer wrote:
>>>
>>> Which FDT blob do I need to load?
>>>
>> 
>> I usually use the one from either the official Linux or the one from
>> FreeBSD. Alternatively you can build your own from
>> 
>>git://xenbits.xen.org/people/ianc/device-tree-rebasing.git
>> 
> 
> Thanks. I have found them and I can build the default one on FreeBSD. It does
> not build on MacOS, the `cpp` from clang does not like command line.
> 
> I wonder if we should include the dts source from FreeBSD in rtems-libbsp and
> maybe some blobs. This stuff is pretty nerdy and makes libbsd awkward to use.
> Crashing if not present is not friendly.
> 
> Chris

Note that basically all device tree files that I have found yet are forked from 
the Linux ones. They are all GPL. I think it was Sichen Zhao during 2017 GSoC 
who wanted to add some to the RTEMS repository and it has been rejected due to 
the license. I don't really object to adding them somewhere. But we should 
think exactly about where we want that stuff.

Regards

Christian
-- 

embedded brains GmbH
Christian Mauderer
Dornierstr. 4
D-82178 Puchheim
Germany
email: christian.maude...@embedded-brains.de
Phone: +49-89-18 94 741 - 18
Fax:   +49-89-18 94 741 - 08
PGP: Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users

Re: BeagleBone Black Networking (wifi and/or wired)

On 07/06/2019 11:19, Chris Johns wrote:
> On 7/6/19 7:18 pm, Christian Mauderer wrote:
>>
>> On 07/06/2019 11:16, Chris Johns wrote:
>>> On 7/6/19 6:34 pm, Christian Mauderer wrote:
>>>> On 07/06/2019 10:23, Chris Johns wrote:
>>>>> Hi,
>>>>>
>>>>> I am looking for some information on doing either but I cannot find out 
>>>>> what I
>>>>> need. I have run a few libbsd examples and some run and some crash. I am
>>>>> wondering if I need an device tree installed but I cannot find out which 
>>>>> one and
>>>>> from where.
>>>>>
>>>>> Any hints would be most welcome.
>>>>>
>>>>> Thanks
>>>>> Chris
>>>>
>>>> Hello Chris,
>>>>
>>>> for wired network, you should be able to add libbsd and start the
>>>> network similar like for all other boards.
>>>
>>> Nice. Do I need u-boot to load an FDT? I am not currently doing that.
>>
>> Yes. The libbsd drivers use the FDT.
>>
> 
> Which FDT blob do I need to load?
> 
> Chris
> 

I usually use the one from either the official Linux or the one from
FreeBSD. Alternatively you can build your own from

   git://xenbits.xen.org/people/ianc/device-tree-rebasing.git

-- 

embedded brains GmbH
Herr Christian Mauderer
Dornierstr. 4
D-82178 Puchheim
Germany
email: christian.maude...@embedded-brains.de
Phone: +49-89-18 94 741 - 18
Fax:   +49-89-18 94 741 - 08
PGP: Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users

Re: BeagleBone Black Networking (wifi and/or wired)


On 07/06/2019 11:16, Chris Johns wrote:
> On 7/6/19 6:34 pm, Christian Mauderer wrote:
>> On 07/06/2019 10:23, Chris Johns wrote:
>>> Hi,
>>>
>>> I am looking for some information on doing either but I cannot find out 
>>> what I
>>> need. I have run a few libbsd examples and some run and some crash. I am
>>> wondering if I need an device tree installed but I cannot find out which 
>>> one and
>>> from where.
>>>
>>> Any hints would be most welcome.
>>>
>>> Thanks
>>> Chris
>>
>> Hello Chris,
>>
>> for wired network, you should be able to add libbsd and start the
>> network similar like for all other boards.
> 
> Nice. Do I need u-boot to load an FDT? I am not currently doing that.

Yes. The libbsd drivers use the FDT.

> 
>>
>> Wireless is still some more effort. Note that you will need the
>> everything buildset of libbsd for that.
>>
>> If you want you can have a look at the example application that I used
>> during the last GSoC projects:
>>
>> https://gitlab.com/c-mauderer/rtems-bbb/tree/master/apps/wifi-sample
>>
>> That application starts a wpa_supplicant. It expects a RT8188EU based
>> WLAN dongle. There should be a wpa_supplicant.conf on the root of your
>> SD card. If I remember correctly it even routes between the networks. So
>> you could basically use the BBB as a Ethernet to WLAN adapter.
> 
> Nice.
> 
> Thanks
> Chris
> 

-- 

embedded brains GmbH
Herr Christian Mauderer
Dornierstr. 4
D-82178 Puchheim
Germany
email: christian.maude...@embedded-brains.de
Phone: +49-89-18 94 741 - 18
Fax:   +49-89-18 94 741 - 08
PGP: Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users

Re: BeagleBone Black Networking (wifi and/or wired)

On 07/06/2019 10:23, Chris Johns wrote:
> Hi,
> 
> I am looking for some information on doing either but I cannot find out what I
> need. I have run a few libbsd examples and some run and some crash. I am
> wondering if I need an device tree installed but I cannot find out which one 
> and
> from where.
> 
> Any hints would be most welcome.
> 
> Thanks
> Chris

Hello Chris,

for wired network, you should be able to add libbsd and start the
network similar like for all other boards.

Wireless is still some more effort. Note that you will need the
everything buildset of libbsd for that.

If you want you can have a look at the example application that I used
during the last GSoC projects:

https://gitlab.com/c-mauderer/rtems-bbb/tree/master/apps/wifi-sample

That application starts a wpa_supplicant. It expects a RT8188EU based
WLAN dongle. There should be a wpa_supplicant.conf on the root of your
SD card. If I remember correctly it even routes between the networks. So
you could basically use the BBB as a Ethernet to WLAN adapter.

Best regards

Christian
-- 
----
embedded brains GmbH
Herr Christian Mauderer
Dornierstr. 4
D-82178 Puchheim
Germany
email: christian.maude...@embedded-brains.de
Phone: +49-89-18 94 741 - 18
Fax:   +49-89-18 94 741 - 08
PGP: Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users

Re: RTEMS_FATAL_SOURCE_EXCEPTION in RTEMS

2019-05-03 Thread Christian Mauderer

- Ursprüngliche Mail -
> Von: "Amarnath MB" 
> An: "Christian Mauderer" 
> CC: "RTEMS Users" , "Ravi G Patil" 
> , "Shekhar Suman Singh"
> 
> Gesendet: Freitag, 3. Mai 2019 10:37:20
> Betreff: Re: RTEMS_FATAL_SOURCE_EXCEPTION in RTEMS

> Hi Christian,
> 
> Sorry for the formatting issue, from now onward i will follow like you
> suggested.
> 
>>Hello Amarnath,
>>
>>just a note in front: Could you try to keep the '>' signs (some mail
> programs show them as a solid line)
>>at the front of the lines intact and don't use ones on your newly written
> lines? Otherwise it's a little
>>hard to see the answers. There's normally no strong formatting
> requirements on this list (also we theoretically have a policy:
>>https://devel.rtems.org/wiki/RTEMSMailingLists#Policies) but please try to
> keep the mails readable.
>>
>>I tried to fix the indentation signs in my answer below. I hope that I
> caught all your remarks.
> 
> Thanks.
> 
>>- Ursprüngliche Mail -
>>> Von: "Amarnath MB" 
>>> An: "Christian Mauderer" 
>>> CC: "RTEMS Users" , "Ravi G Patil" <
> rav...@mistralsolutions.com>, "Shekhar Suman Singh"
>>> 
>>> Gesendet: Freitag, 3. Mai 2019 09:35:27
>>Then it would be best to find the reason for the exception and avoid the
> interrupt lock if possible.
> 
> We are discussing this issue with our FPGA team and hope to resolve it soon.
> 
>>>
>>>> > Flash controller is implemented using the AHB to external SRAM
> interface
>>>> in
>>>> > the Cortex-M System Design Kit and there are no pins shared between
> RAM
>>>> and
>>>> > NOR Flash.  We can't doubt that flash is blocking bus accesses for the
>>>> RAM,
>>>> > because the test executes fine in the uboot running from RAM.
>>>>
>>>> So it's a custom FPGA based design? Most likely your RAM and Flash
>>>> controller are both connected to the same system bus (AHB in that
> case). I
>>>> don't know the modules you mentioned but you might want to take a look
> at
>>>> the documentation whether they lock the AHB or not.
>>>>
>>>  Yes its a custom FPGA based design. Sure, I will go through the
>>> documentation.
>>
>>If the flash controller really blocks all other bus accesses (which would
> be an odd design),
>>you might can move the RAM and Flash to an independent bus or maybe add
> some kind of bus bridge
>>to separate the Flash. But I'm not that deep into the ARM blocks.
> 
> Our FPGA team has to see whether it is feasible.
> 
>>>
>>>> U-Boot most likely doesn't use interrupts. I assume you are waiting for
> a
>>>> flash operation to be finished in some busy wait loop there (polling a
> flag
>>>> or similar). That loop can be fully put into the processor cache (if you
>>>> have one which is quite likely). So in your U-Boot test case, the
> external
>>>> RAM most likely isn't accessed during the flash operations. If you have
> a
>>>> problem
>>>> with conflicting bus accesses you maybe only see them there if you
> disable
>>>> all caches.
>>>
>>> You are correct, we are waiting in a loop polling the busy status of NOR
>>> flash. Currently, the caches are enabled in both uboot and RTEMS.
>>>
>>
>>Maybe you can try to disable them in U-Boot and see whether your behavior
> changes?
>>It could be a bug in disguise if the U-Boot code only works due to caches.
> These are
>>quite nasty because they sometimes depend on the exact position of the
> code. In most
>>cases it works because the loop is in the cache but if for some reason the
> processor
>>has to load a new cache line for the loop it doesn't work. Really hard to
> find because
>>you can change something somewhere completely different and that moves
> your code and
>>triggers a bug.
> 
> Ya sure, I will test the same test code on uboot with caches disabled.
> 
>>>> In RTEMS on the other hand you are running with enabled interrupts and
>>>> task switches. So RAM access are more or less guaranteed during a longer
>>>> flash operation if you don't lock the interrupts.
>>>
>>> Okay, got it.
>>>
>>>> >
>>>> > You had mentioned there are a lot of possible reasons for a
>>>> > RTEMS_FATAL_SOURCE_EXCEPTION, is it somewhere documented what all
>

Re: RTEMS_FATAL_SOURCE_EXCEPTION in RTEMS

2019-05-03 Thread Christian Mauderer

Hello Amarnath,

just a note in front: Could you try to keep the '>' signs (some mail programs 
show them as a solid line) at the front of the lines intact and don't use ones 
on your newly written lines? Otherwise it's a little hard to see the answers. 
There's normally no strong formatting requirements on this list (also we 
theoretically have a policy: 
https://devel.rtems.org/wiki/RTEMSMailingLists#Policies) but please try to keep 
the mails readable.

I tried to fix the indentation signs in my answer below. I hope that I caught 
all your remarks.

- Ursprüngliche Mail -
> Von: "Amarnath MB" 
> An: "Christian Mauderer" 
> CC: "RTEMS Users" , "Ravi G Patil" 
> , "Shekhar Suman Singh"
> 
> Gesendet: Freitag, 3. Mai 2019 09:35:27
> Betreff: Re: RTEMS_FATAL_SOURCE_EXCEPTION in RTEMS

> On Thu, May 2, 2019 at 3:35 PM Christian Mauderer <
> christian.maude...@embedded-brains.de> wrote:
> 
>> - Ursprüngliche Mail -
>> > Von: "Amarnath MB" 
>> > An: "Christian Mauderer" 
>> > CC: "RTEMS Users" , "Ravi G Patil" <
>> rav...@mistralsolutions.com>, "Shekhar Suman Singh"
>> > 
>> > Gesendet: Donnerstag, 2. Mai 2019 11:18:48
>> > Betreff: Re: RTEMS_FATAL_SOURCE_EXCEPTION in RTEMS
>>
>> > Hi Christian,
>> >
>> > As per your suggestion, i tried disabling  global interrupt before my
>> erase
>> > call and enabling it afterwards. With this setup the test routine is
>> > passing without giving exception. So i think, interrupt was the issue
>> here.
>> >
>>
>> Hello Amarnath,
>>
>> good. Than you have at least a hint toward the problem. I wouldn't see it
>> as the solution. Like already discussed, depending on your application,
>> this can lead to missed interrupts. If you have a very specific case for
>> writing the flash that isn't during your normal operation (for example
>> firmware updates) you are most likely fine with that solution. But if you
>> write for example log files, you might get a quite unpredictable behavior
>> later.
>> Hi Christian,
>>
> Thank you for the detailed explanation. Even though we are using NOR
> flash for firmware storage, there is a chance that it may be used for log
> files later.
>

Then it would be best to find the reason for the exception and avoid the 
interrupt lock if possible.

> 
>> > Flash controller is implemented using the AHB to external SRAM interface
>> in
>> > the Cortex-M System Design Kit and there are no pins shared between RAM
>> and
>> > NOR Flash.  We can't doubt that flash is blocking bus accesses for the
>> RAM,
>> > because the test executes fine in the uboot running from RAM.
>>
>> So it's a custom FPGA based design? Most likely your RAM and Flash
>> controller are both connected to the same system bus (AHB in that case). I
>> don't know the modules you mentioned but you might want to take a look at
>> the documentation whether they lock the AHB or not.
>>
>  Yes its a custom FPGA based design. Sure, I will go through the
> documentation.

If the flash controller really blocks all other bus accesses (which would be an 
odd design), you might can move the RAM and Flash to an independent bus or 
maybe add some kind of bus bridge to separate the Flash. But I'm not that deep 
into the ARM blocks.

> 
>> U-Boot most likely doesn't use interrupts. I assume you are waiting for a
>> flash operation to be finished in some busy wait loop there (polling a flag
>> or similar). That loop can be fully put into the processor cache (if you
>> have one which is quite likely). So in your U-Boot test case, the external
>> RAM most likely isn't accessed during the flash operations. If you have a
>> problem
>> with conflicting bus accesses you maybe only see them there if you disable
>> all caches.
>
> You are correct, we are waiting in a loop polling the busy status of NOR
> flash. Currently, the caches are enabled in both uboot and RTEMS.
>

Maybe you can try to disable them in U-Boot and see whether your behavior 
changes? It could be a bug in disguise if the U-Boot code only works due to 
caches. These are quite nasty because they sometimes depend on the exact 
position of the code. In most cases it works because the loop is in the cache 
but if for some reason the processor has to load a new cache line for the loop 
it doesn't work. Really hard to find because you can change something somewhere 
completely different and that moves your code and triggers a bug.

>> In RTEMS on the other hand you are running with enabled interrupt

Re: RTEMS_FATAL_SOURCE_EXCEPTION in RTEMS

2019-05-01 Thread Christian Mauderer


- Ursprüngliche Mail -
> Von: "Amarnath MB" 
> An: "Christian Mauderer" 
> CC: "RTEMS Users" , "Ravi G Patil" 
> , "Shekhar Suman Singh"
> 
> Gesendet: Mittwoch, 1. Mai 2019 17:07:13
> Betreff: Re: RTEMS_FATAL_SOURCE_EXCEPTION in RTEMS

> Hi Christian,
> 
> Thanks for your quick response.
> Our boot process is like, first u-boot will be loaded from the NOR flash
> and then the uboot copies RTEMS application from NOR flash to the RAM.
> After that RTEMS executes entirely from RAM.
> 
> How can i issue a global interrupt disable? Is it using *
> rtems_interrupt_disable(0)*?
> One more doubt, if i issue a global interrupt disable then will there be
> chance that i can miss few clock ticks?
> 
> *Thank you & Regards,*
> *Amarnath MB*
> 

Hello Amarnath,

with a global interrupt lock, all kinds of events can be missed including clock 
ticks. Most should be processed just a little late but some interfaces might 
loose packets or data (depending on the data rate / flash access times). So if 
not necessary it's not a good solution.

The rtems_interrupt_disable() function should be called with a level argument. 
See the example at 
https://docs.rtems.org/branches/master/c-user/interrupt_manager.html#rtems-interrupt-disable.
 Note that for SMP configurations, you might have to use other functions.

But if your application runs entirely from RAM than the bus access shouldn't be 
the problem. So the interrupt might isn't the right guess.

Do you have any more information on the exception and where it happens? Some 
output or a stack trace from a debugger?

What kind of flash controller is used? Can it block bus accesses for the RAM? 
Does your RAM share pins with the flash?

With kind regards

Christian

> 
> 
> On Wed, May 1, 2019 at 8:16 PM Christian Mauderer <
> christian.maude...@embedded-brains.de> wrote:
> 
>> - Ursprüngliche Mail -
>> > Von: "Amarnath MB" 
>> > An: "RTEMS Users" 
>> > CC: "Ravi G Patil" , "Shekhar Suman Singh"
>> 
>> > Gesendet: Mittwoch, 1. Mai 2019 16:28:23
>> > Betreff: RTEMS_FATAL_SOURCE_EXCEPTION in RTEMS
>>
>> > Hi All,
>> >
>> > I'm developing RTEMS 5.00 BSP and device drivers for a custom ARM926EJ-S
>> > core. I was successful in porting and building BSP for the ARM core.
>> >
>> > We are facing a strange issue with the generic NOR flash driver we have
>> > developed. Our device drivers are designed such that it can be used with
>> > RTEMS as well as the bare metal programs.
>> > Our driver is working fine in bare metal program (erase, read, write
>> > everything), but when we use the driver with RTEMS application and issue
>> an
>> > erase call, then the application gives RTEMS_FATAL_SOURCE_EXCEPTION.
>> >
>> > For testing driver in RTEMS, we have added each test routine as a custom
>> > shell command using rtems_shell_add_cmd().
>> >
>> > For your info we also tested the same driver with u-boot and it works
>> > fines.
>> > Can anyone guide me on this issue?
>> >
>> > *Thank you & Regards,*
>> > *Amarnath MB*
>> >
>>
>> Hello Amarnath,
>>
>> it's a little hard with the given information to tell you a concrete
>> problem. There are a lot of possible reasons for a
>> RTEMS_FATAL_SOURCE_EXCEPTION.
>>
>> From your description, my guess would be some problem with an interrupt.
>> Most U-Boot code avoids interrupts. I don't know about your bare metal
>> application but maybe in some test application, you don't have too much
>> interrupts too. In RTEMS you have most likely at least a periodic tick
>> interrupt.
>>
>> Do you execute your code from the same flash or do you keep some data in
>> the flash? In that case it could be an access error during a flash erase or
>> write (for example caused by an interrupt). In that case you might have to
>> do a global interrupt disable before you enter certain routines.
>>
>> Best regards
>>
>> Christian

-- 

embedded brains GmbH
Christian Mauderer
Dornierstr. 4
D-82178 Puchheim
Germany
email: christian.maude...@embedded-brains.de
Phone: +49-89-18 94 741 - 18
Fax:   +49-89-18 94 741 - 08
PGP: Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users

Re: RTEMS_FATAL_SOURCE_EXCEPTION in RTEMS

2019-05-01 Thread Christian Mauderer

- Ursprüngliche Mail -
> Von: "Amarnath MB" 
> An: "RTEMS Users" 
> CC: "Ravi G Patil" , "Shekhar Suman Singh" 
> 
> Gesendet: Mittwoch, 1. Mai 2019 16:28:23
> Betreff: RTEMS_FATAL_SOURCE_EXCEPTION in RTEMS

> Hi All,
> 
> I'm developing RTEMS 5.00 BSP and device drivers for a custom ARM926EJ-S
> core. I was successful in porting and building BSP for the ARM core.
> 
> We are facing a strange issue with the generic NOR flash driver we have
> developed. Our device drivers are designed such that it can be used with
> RTEMS as well as the bare metal programs.
> Our driver is working fine in bare metal program (erase, read, write
> everything), but when we use the driver with RTEMS application and issue an
> erase call, then the application gives RTEMS_FATAL_SOURCE_EXCEPTION.
> 
> For testing driver in RTEMS, we have added each test routine as a custom
> shell command using rtems_shell_add_cmd().
> 
> For your info we also tested the same driver with u-boot and it works
> fines.
> Can anyone guide me on this issue?
> 
> *Thank you & Regards,*
> *Amarnath MB*
> 

Hello Amarnath,

it's a little hard with the given information to tell you a concrete problem. 
There are a lot of possible reasons for a RTEMS_FATAL_SOURCE_EXCEPTION.

>From your description, my guess would be some problem with an interrupt. Most 
>U-Boot code avoids interrupts. I don't know about your bare metal application 
>but maybe in some test application, you don't have too much interrupts too. In 
>RTEMS you have most likely at least a periodic tick interrupt.

Do you execute your code from the same flash or do you keep some data in the 
flash? In that case it could be an access error during a flash erase or write 
(for example caused by an interrupt). In that case you might have to do a 
global interrupt disable before you enter certain routines.

Best regards

Christian
-- 

embedded brains GmbH
Christian Mauderer
Dornierstr. 4
D-82178 Puchheim
Germany
email: christian.maude...@embedded-brains.de
Phone: +49-89-18 94 741 - 18
Fax:   +49-89-18 94 741 - 08
PGP: Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users

Re: stm32f4 wakeup interrupt

2019-04-29 Thread Christian Mauderer

Am 29.04.19 um 03:36 schrieb Jython:
> Thank you a lot ! maybe i was thinking make code more clear and then
> forget the right

No problem. Pointer bugs are most likely one of the most common ones for
C programmers. You know the 4 most common bugs:

- wrong parentheses
- pointer bugs
- off by one errors

Note: No real statistic behind that. But I liked the joke when I first
read it ;-)

Best regards

Christian

> 
> On Sun, Apr 28, 2019 at 3:27 PM Christian Mauderer  <mailto:l...@c-mauderer.de>> wrote:
> 
> Am 27.04.19 um 16:40 schrieb Christian Mauderer:
> > Am 24.04.19 um 10:00 schrieb Jython:
> >> HI, ALL!
> >> why the code stuck in wakeup handler while the RTC gets time work
> fine
> >> i have checked some days, but no register error found, i suspect that
> >> the handler function is the issue
> >>
> >>
> >> // code
> >> rtems_isr rtc_wakeup_handler(rtems_vector_number vector)
> >> {
> >>    
> >>     uint32_t STM32F4_RTC_ISR = (*(volatile uint32_t *)(0x4000280C));
> >>    
> >>     // clear 10bit
> >>     if(STM32F4_RTC_ISR & (1<<10))
> >>     {
> >>     //printk("wak\n");
> >>     STM32F4_RTC_ISR &= ~(1<<10);
> >>     STM32F4_RTC_ISR &= 0xfbff;
> >>     }
> >>    
> >>     volatile uint32_t EXIT_PR = *(volatile uint32_t*)0x40013C14;
> >>     printk("before clr %08x\n", EXIT_PR);
> >>     EXIT_PR |= 1<<22;
> >>    
> >>     int i;
> >>     for(i = 0; i < 1000; i++) i = i + 1 - 1;
> >>     printk(" %08x\n", EXIT_PR);
> >> }
> >>
> >>
> >> the printed log attached,  why the EXIT_PR bit22 not cleared
> >>
> >>
> >
> > Hello Jython,
> >
> > your EXIT_PR seems to be slightly odd. What you do:
> >
> >     volatile uint32_t EXIT_PR = *(volatile uint32_t*)0x40013C14;
> >
> > This means you read the content of 0x40013C14 and write it to a 32 bit
> > value.
> >
> > Later you do
> >
> >     EXIT_PR |= 1<<22;
> >
> > This changes the _copy_ of the value.
> >
> > What you most likely want to do is the following:
> >
> >     volatile uint32_t *EXIT_PR = (volatile uint32_t*)0x40013C14;
> >     *EXIT_PR |= 1<<22;
> >
> > This would change the value at 0x40013C14 and not only your copy.
> >
> > By the way: You tried to do a busy wait. That's not a good idea in an
> > interrupt. The way you implemented it, the compiler most likely even
> > just removes it:
> >
> >     int i;
> >     for(i = 0; i < 1000; i++) i = i + 1 - 1;
> >
> > The compiler most likely notices that this statement has no effect. If
> > you would like to implement a busy wait that way, you should use a
> > volatile int.
> >
> > Note that RTEMS has a rtems_counter_delay_nanoseconds() function. That
> > is a busy wait loop. It is based on the CPU counter and provides a
> > method for short busy waits for example during driver initialization.
> > But again: Please don't use busy waits in Interrupts. It's not a good
> > idea and will lead to problems sooner or later.
> >
> > Best regards
> >
> > Christian Mauderer
> 
> Oh, and I just noted: You are writing a one to the register but expect
> the bit to be cleared. So it is most likely a "write one to clear"
> register (which is quite common for interrupt flags). In that case you
> maybe don't want to use a
> 
>     *EXIT_PR |= 1<<22;
> 
> but a
> 
>     *EXIT_PR = 1<<22;
> 
> Otherwise you clear other flags in that register too. Please have a look
> at the reference manual of your chip to decide that.
> 
> Best regards
> 
> Christian
> 

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

Re: stm32f4 wakeup interrupt

2019-04-28 Thread Christian Mauderer

Am 27.04.19 um 16:40 schrieb Christian Mauderer:
> Am 24.04.19 um 10:00 schrieb Jython:
>> HI, ALL!
>> why the code stuck in wakeup handler while the RTC gets time work fine
>> i have checked some days, but no register error found, i suspect that
>> the handler function is the issue
>>
>>
>> // code
>> rtems_isr rtc_wakeup_handler(rtems_vector_number vector)
>> {
>>    
>>     uint32_t STM32F4_RTC_ISR = (*(volatile uint32_t *)(0x4000280C));
>>    
>>     // clear 10bit
>>     if(STM32F4_RTC_ISR & (1<<10))
>>     {
>>     //printk("wak\n");
>>     STM32F4_RTC_ISR &= ~(1<<10);
>>     STM32F4_RTC_ISR &= 0xfbff;
>>     }
>>    
>>     volatile uint32_t EXIT_PR = *(volatile uint32_t*)0x40013C14;
>>     printk("before clr %08x\n", EXIT_PR);
>>     EXIT_PR |= 1<<22;
>>    
>>     int i;
>>     for(i = 0; i < 1000; i++) i = i + 1 - 1;
>>     printk(" %08x\n", EXIT_PR);
>> }
>>
>>
>> the printed log attached,  why the EXIT_PR bit22 not cleared
>>
>>
> 
> Hello Jython,
> 
> your EXIT_PR seems to be slightly odd. What you do:
> 
> volatile uint32_t EXIT_PR = *(volatile uint32_t*)0x40013C14;
> 
> This means you read the content of 0x40013C14 and write it to a 32 bit
> value.
> 
> Later you do
> 
> EXIT_PR |= 1<<22;
> 
> This changes the _copy_ of the value.
> 
> What you most likely want to do is the following:
> 
> volatile uint32_t *EXIT_PR = (volatile uint32_t*)0x40013C14;
> *EXIT_PR |= 1<<22;
> 
> This would change the value at 0x40013C14 and not only your copy.
> 
> By the way: You tried to do a busy wait. That's not a good idea in an
> interrupt. The way you implemented it, the compiler most likely even
> just removes it:
> 
> int i;
> for(i = 0; i < 1000; i++) i = i + 1 - 1;
> 
> The compiler most likely notices that this statement has no effect. If
> you would like to implement a busy wait that way, you should use a
> volatile int.
> 
> Note that RTEMS has a rtems_counter_delay_nanoseconds() function. That
> is a busy wait loop. It is based on the CPU counter and provides a
> method for short busy waits for example during driver initialization.
> But again: Please don't use busy waits in Interrupts. It's not a good
> idea and will lead to problems sooner or later.
> 
> Best regards
> 
> Christian Mauderer

Oh, and I just noted: You are writing a one to the register but expect
the bit to be cleared. So it is most likely a "write one to clear"
register (which is quite common for interrupt flags). In that case you
maybe don't want to use a

*EXIT_PR |= 1<<22;

but a

*EXIT_PR = 1<<22;

Otherwise you clear other flags in that register too. Please have a look
at the reference manual of your chip to decide that.

Best regards

Christian
___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users

Re: stm32f4 __wfi

The system tick is responsible for everything timing relevant in RTEMS.
So if you want to use functions like sleep or rtems_task_wake_after, you
need a tick. If you don't want to use anything timing relevant, you can
disable that by (I think) using

CONFIGURE_APPLICATION_DOES_NOT_NEED_CLOCK_DRIVER

But please be aware that with that nothing which needs the system to
wait for a given time would work any more.

Am 24.04.19 um 11:04 schrieb Jython:
> Thanks for your quick reply!
> the system will wake up every tick, why? does it effect the RTC wakeup?
> i am also debugging the rtc wakeup, have posted a mail
> https://lists.rtems.org/pipermail/users/2019-April/033176.html
> 
> On Wed, Apr 24, 2019 at 4:48 PM Christian Mauderer
>  <mailto:christian.maude...@embedded-brains.de>> wrote:
> 
> There is the wfi in the Idle body. So as soon as all your tasks are
> sleeping (via sleep(), rtems_task_wake_after(), waiting for some signals
> or similar functions) wfi will be called.
> 
> Note that there most likely is a lot of potential in the drivers to save
> power. Also note that the system will wake up every tick. So depending
> on your configuration the power consumption will vary.
> 
> Am 24.04.19 um 10:44 schrieb Jython:
> > i searched it by add -i 
> >
> > 56794:d040 <_CPU_Thread_Idle_body>:
> > 56795-#ifdef ARM_MULTILIB_HAS_WFI
> > 56796-
> > 56797:void *_CPU_Thread_Idle_body( uintptr_t ignored )
> > 56798-{
> > 56799-  while ( true ) {
> > 56800-    __asm__ volatile ("wfi");
> > 56801-    d040:    bf30      wfi
> > 56802-  }
> > 56803:    d042:    e7fd      b.n    d040 <_CPU_Thread_Idle_body>
> > 56804-
> > 56805-d044 :
> > 56806-int rtems_filesystem_default_close(
> > 56807-  rtems_libio_t *iop
> > 56808-)
> > 56809-{
> > 56810-  return 0;
> > 56811-}
> > 56812-    d044:    2000      movs    r0, #0
> > 56813-    d046:    4770      bx    lr
>     >
> >
> > that's to say when i want to enter low power  i just need to call
> sleep
> > or rtems_task_wake_after or just while(1); ?
> >
> > On Wed, Apr 24, 2019 at 4:36 PM Christian Mauderer
> >  <mailto:christian.maude...@embedded-brains.de>
> > <mailto:christian.maude...@embedded-brains.de
> <mailto:christian.maude...@embedded-brains.de>>> wrote:
> >
> >     For some reason your grep hasn't found the
> _CPU_Thread_Idle_body. It's
> >     possible that the stm32f4 uses some other function for that
> also I don't
> >     know why.
> >
> >     For example for the xilinx_zynq_a9_qemu BSP the disassembled
> idle body
> >     looks like follows:
> >
> >     void *_CPU_Thread_Idle_body( uintptr_t ignored )
> >     {
> >        11d70:       b480            push    {r7}
> >        11d72:       b083            sub     sp, #12
> >        11d74:       af00            add     r7, sp, #0
> >        11d76:       6078            str     r0, [r7, #4]
> >       while ( true ) {
> >     #ifdef ARM_MULTILIB_HAS_WFI
> >         __asm__ volatile ("wfi");
> >        11d78:       bf30            wfi
> >        11d7a:       e7fd            b.n     11d78
> >     <_CPU_Thread_Idle_body+0x8>
> >
> >     Am 24.04.19 um 10:25 schrieb Jython:
> >     > arm-rtems4.11-objdump -dS hello.exe | grep idle --color=auto
> -n -B
> >     5 -A 12
> >     >
> >     > there is no idle function which calls wfi command
> >     > // log
> >     > 508-       
> >     > 509-       
> >     > 510-               
> >     > 511-    }
> >     > 512-   
> >     > 513:    if((*USART2_SR) & (1<<4))  // idle
> >     > 514- 3aa:    4b13      ldr    r3, [pc, #76]    ; (3f8
> >     > )
> >     > 515- 3ac:    681b      ldr    r3, [r3, #0]
> >     > 516- 3ae:    681b      ldr    r3, [r3, #0]
> >     > 517- 3b0:    f003 0310     and.w    r3, r3, #16
> >     > 518- 3b4:    2b00      cmp    r3, #0
> >     > 519- 3b6:    d00a      beq.n    3ce
> 
> >     > 520-    {
> >     > 521:        //printk("idle ");
> >     > 522-   
> >     > 523-    temp = (*

Re: stm32f4 __wfi

There is the wfi in the Idle body. So as soon as all your tasks are
sleeping (via sleep(), rtems_task_wake_after(), waiting for some signals
or similar functions) wfi will be called.

Note that there most likely is a lot of potential in the drivers to save
power. Also note that the system will wake up every tick. So depending
on your configuration the power consumption will vary.

Am 24.04.19 um 10:44 schrieb Jython:
> i searched it by add -i 
> 
> 56794:d040 <_CPU_Thread_Idle_body>:
> 56795-#ifdef ARM_MULTILIB_HAS_WFI
> 56796-
> 56797:void *_CPU_Thread_Idle_body( uintptr_t ignored )
> 56798-{
> 56799-  while ( true ) {
> 56800-    __asm__ volatile ("wfi");
> 56801-    d040:    bf30      wfi
> 56802-  }
> 56803:    d042:    e7fd      b.n    d040 <_CPU_Thread_Idle_body>
> 56804-
> 56805-d044 :
> 56806-int rtems_filesystem_default_close(
> 56807-  rtems_libio_t *iop
> 56808-)
> 56809-{
> 56810-  return 0;
> 56811-}
> 56812-    d044:    2000      movs    r0, #0
> 56813-    d046:    4770      bx    lr
> 
> 
> that's to say when i want to enter low power  i just need to call sleep
> or rtems_task_wake_after or just while(1); ?
> 
> On Wed, Apr 24, 2019 at 4:36 PM Christian Mauderer
>  <mailto:christian.maude...@embedded-brains.de>> wrote:
> 
> For some reason your grep hasn't found the _CPU_Thread_Idle_body. It's
> possible that the stm32f4 uses some other function for that also I don't
> know why.
> 
> For example for the xilinx_zynq_a9_qemu BSP the disassembled idle body
> looks like follows:
> 
> void *_CPU_Thread_Idle_body( uintptr_t ignored )
> {
>    11d70:       b480            push    {r7}
>    11d72:       b083            sub     sp, #12
>    11d74:       af00            add     r7, sp, #0
>    11d76:       6078            str     r0, [r7, #4]
>   while ( true ) {
> #ifdef ARM_MULTILIB_HAS_WFI
>     __asm__ volatile ("wfi");
>    11d78:       bf30            wfi
>    11d7a:       e7fd            b.n     11d78
> <_CPU_Thread_Idle_body+0x8>
> 
> Am 24.04.19 um 10:25 schrieb Jython:
> > arm-rtems4.11-objdump -dS hello.exe | grep idle --color=auto -n -B
> 5 -A 12
> >
> > there is no idle function which calls wfi command
> > // log
> > 508-       
> > 509-       
> > 510-               
> > 511-    }
> > 512-   
> > 513:    if((*USART2_SR) & (1<<4))  // idle
> > 514- 3aa:    4b13      ldr    r3, [pc, #76]    ; (3f8
> > )
> > 515- 3ac:    681b      ldr    r3, [r3, #0]
> > 516- 3ae:    681b      ldr    r3, [r3, #0]
> > 517- 3b0:    f003 0310     and.w    r3, r3, #16
> > 518- 3b4:    2b00      cmp    r3, #0
> > 519- 3b6:    d00a      beq.n    3ce 
> > 520-    {
> > 521:        //printk("idle ");
> > 522-   
> > 523-    temp = (*USART2_SR);
> > 524- 3b8:    4b0f      ldr    r3, [pc, #60]    ; (3f8
> > )
> > 525- 3ba:    681b      ldr    r3, [r3, #0]
> > 526- 3bc:    681b      ldr    r3, [r3, #0]
> > 527- 3be:    60fb      str    r3, [r7, #12]
> > 528-        temp = (*USART2_DR);
> > 529- 3c0:    4b0f      ldr    r3, [pc, #60]    ; (400
> > )
> > 530- 3c2:    681b      ldr    r3, [r3, #0]
> > 531- 3c4:    681b      ldr    r3, [r3, #0]
> > 532- 3c6:    60fb      str    r3, [r7, #12]
> > 533-    //temp = temp;
> > --
> > 627-       
> > 628-       
> > 629-               
> > 630-    }
> > 631-   
> > 632:    if((*USART3_SR) & (1<<4))  // idle
> > 633- 44c:    4b12      ldr    r3, [pc, #72]    ; (498
> > )
> > 634- 44e:    681b      ldr    r3, [r3, #0]
> > 635- 450:    681b      ldr    r3, [r3, #0]
> > 636- 452:    f003 0310     and.w    r3, r3, #16
> > 637- 456:    2b00      cmp    r3, #0
> > 638- 458:    d00a      beq.n    470 
> > 639-    {
> > 640:        //printk("idle ");
> > 641-   
> > 642-    temp = (*USART3_SR);
> > 643- 45a:    4b0f      ldr    r3, [pc, #60]    ; (498
> > )
> > 644- 45c:    681b      ldr    r3, [r3, #0]
> > 645- 45e:    681b      ldr    r3, [r3, #0]
> > 646- 460:    60fb      str    r3, [r7, #12]

Re: stm32f4 __wfi

775-    b9ae:    428b      cmp    r3, r1
> 49776-    b9b0:    bf38      it    cc
> 49777-    b9b2:    460b      movcc    r3, r1
> 49778-   *  fields not explicitly assigned were explicitly zeroed by
> 49779-   *  _Workspace_Initialization.
> 49780-   */
> 49781:  idle = _Thread_Internal_allocate();
> 49782-
> 49783-  _Thread_Initialize(
> 49784:    b9b4:    4a13      ldr    r2, [pc, #76]    ; (ba04
> <_Thread_Create_idle+0x6c>)
> 49785:static void _Thread_Create_idle_for_cpu( Per_CPU_Control *cpu )
> 49786-{
> 49787-  Objects_Name    name;
> 49788:  Thread_Control *idle;
> 49789-
> 49790-  name.name_u32 = _Objects_Build_name( 'I', 'D', 'L', 'E' );
> 49791:    b9b6:    f8df e058     ldr.w    lr, [pc, #88]    ; ba10
> <_Thread_Create_idle+0x78>
> 49792-   *  fields not explicitly assigned were explicitly zeroed by
> 49793-   *  _Workspace_Initialization.
> 49794-   */
> 49795:  idle = _Thread_Internal_allocate();
> 49796-
> 49797-  _Thread_Initialize(
> 49798-    b9ba:    7811      ldrb    r1, [r2, #0]
> 49799-    b9bc:    2400      movs    r4, #0
> 49800-    b9be:    2201      movs    r2, #1
> 49801-    b9c0:    9300      str    r3, [sp, #0]
> 49802-    b9c2:    9102      str    r1, [sp, #8]
> 49803-    b9c4:    f8cd e01c     str.w    lr, [sp, #28]
> 49804-    b9c8:    4629      mov    r1, r5
> 49805-    b9ca:    4623      mov    r3, r4
> 49806-    b9cc:    9203      str    r2, [sp, #12]
> 49807-    b9ce:    4638      mov    r0, r7
> 49808-    b9d0:    9401      str    r4, [sp, #4]
> 49809-    b9d2:    9404      str    r4, [sp, #16]
> 49810-    b9d4:    9405      str    r4, [sp, #20]
> 49811-    b9d6:    9406      str    r4, [sp, #24]
> 49812:    b9d8:    4a0b      ldr    r2, [pc, #44]    ; (ba08
> <_Thread_Create_idle+0x70>)
> 49813-    b9da:    f000 f96d     bl    bcb8 <_Thread_Initialize>
> 49814-   * MUST be done before _Thread_Start is invoked.
> 49815-   */
> 49816-  cpu->heir  =
> 49817:  cpu->executing = idle;
> 49818-
> 49819-  _Thread_Start(
> 49820-    b9de:    6a32      ldr    r2, [r6, #32]
> 49821-  /*
> 49822-   *  WARNING!!! This is necessary to "kick" start the system and
> 49823-   * MUST be done before _Thread_Start is invoked.
> 49824-   */
> 49825-  cpu->heir  =
> 49826:  cpu->executing = idle;
> 49827:    b9e0:    4e0a      ldr    r6, [pc, #40]    ; (ba0c
> <_Thread_Create_idle+0x74>)
> 49828-
> 49829-  _Thread_Start(
> 49830-    b9e2:    9400      str    r4, [sp, #0]
> 49831-    b9e4:    9601      str    r6, [sp, #4]
> 49832-    b9e6:    4628      mov    r0, r5
> 49833-    b9e8:    4621      mov    r1, r4
> 49834-    b9ea:    4623      mov    r3, r4
> 49835-  /*
> 49836-   *  WARNING!!! This is necessary to "kick" start the system and
> 49837-   * MUST be done before _Thread_Start is invoked.
> 49838-   */
> 49839-  cpu->heir  =
> 49840:  cpu->executing = idle;
> 49841-    b9ec:    60b5      str    r5, [r6, #8]
> 49842-
> 49843-  /*
> 49844-   *  WARNING!!! This is necessary to "kick" start the system and
> 49845-   * MUST be done before _Thread_Start is invoked.
> 49846-   */
> 49847-  cpu->heir  =
> 49848-    b9ee:    60f5      str    r5, [r6, #12]
> 49849:  cpu->executing = idle;
> 49850-
> 49851-  _Thread_Start(
> 49852-    b9f0:    f000 fee0     bl    c7b4 <_Thread_Start>
> 49853-
> 49854-    if ( _Per_CPU_Is_processor_started( cpu ) ) {
> 49855:  _Thread_Create_idle_for_cpu( cpu );
> 49856-    }
> 49857-  }
> 49858-}
> 49859-    b9f4:    b009      add    sp, #36    ; 0x24
> 49860-    b9f6:    bdf0      pop    {r4, r5, r6, r7, pc}
> 49861-    b9f8:    200042c0     .word    0x200042c0
> 49862-    b9fc:    000183c0     .word    0x000183c0
> 49863-    ba00:    200011c0     .word    0x200011c0
> 49864-    ba04:    200011bc     .word    0x200011bc
> 49865-    ba08:    0001847c     .word    0x0001847c
> 49866-    ba0c:    20004640     .word    0x20004640
> 49867-    ba10:    49444c45     .word    0x49444c45
> --
> 54093-  const Scheduler_Control *scheduler,
> 54094-  Thread_Control  *the_thread,
> 54095-  Per_CPU_Control *cpu
> 54096-)
> 54097-{
> 54098:  ( *scheduler->Operations.start_idle )( scheduler, the_thread, cpu );
> 54099-    c7de:    4809      ldr    r0, [pc, #36]    ; (c804
> <_Thread_Start+0x50>)
> 54100-  _Thread_Ready( the_thread );
> 54101-    } else {
> 54102-  const Scheduler_Control *scheduler = _Scheduler_Get_by_CPU(
> cpu );
> 54103-
> 54104-

Re: stm32f4 __wfi