Re: problem when runing rpi sample on gdb simu

[Alan Cudmore]

Hi,
As far as I know, the raspberry Pi binaries will not run on the arm GDB
sim. There may be a suitable QEMU based Raspberry Pi simulator. That would
be a good option to try.

Alan


On Wed, Mar 11, 2015 at 9:42 PM, QIAO YANG  wrote:

> Hello ,
>
> I was wondering if the raspberry pi samples can run on arm-rtems4.11-gdb.
> I thought I had done the compilations correctly according to Mr Alan's
> blog, but it just stand still when running the sample in the simulator.
>
> I'm not sure if it's my problem or it can only run on a real rpi board.
> If it's my own problem I'll double check what I've done, if not I've got to
> wait until next week to post my hello demo when the cable arrives.
>
> here's the output of gdb:
>
> Reading symbols from
> ./arm-rtems4.11/c/raspberrypi/testsuites/samples/hello/hello.exe...done.
> (gdb) tar sim
> Connected to the simulator.
> (gdb) load
> Loading section .start, size 0x340 vma 0x8000
> Loading section .text, size 0x17920 vma 0x8340
> Loading section .init, size 0x18 vma 0x1fc60
> Loading section .fini, size 0x18 vma 0x1fc78
> Loading section .rodata, size 0xc30 vma 0x10
> Loading section .ARM.exidx, size 0x8 vma 0x100c30
> Loading section .eh_frame, size 0x48 vma 0x100c38
> Loading section .init_array, size 0x4 vma 0x100c80
> Loading section .fini_array, size 0x4 vma 0x100c84
> Loading section .jcr, size 0x4 vma 0x100c88
> Loading section .data, size 0x5e8 vma 0x100c90
> Start address 0x8040
> Transfer rate: 817184 bits in <1 sec.
> (gdb) r
> Starting program:
> /home/yangqiao/development/rtems/build-rtems-rpi/arm-rtems4.11/c/raspberrypi/testsuites/samples/hello/hello.exe
>
> Best regards,
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Hello demo on RPI

[Alan Cudmore]

Nice work Qiao!

Andre had submitted the patches for GPIO, SPI, and I2C including
recommended fixes. It was then recommended that we switch to the new Linux
based I2C API, and we ( or I ) got stuck there.
For the time I have available, it was not going to be a 1 or 2 day fix to
move Andre's I2C implementation to the new Linux based API. It was taking
me a while just to understand what needed to be done.

A little later today, I will try to come up with a proposal to split the Pi
work so it can be done by 3 participants.. But we need to decide if
re-doing the I2C implementation should be part of the work, or if we should
use Andre's initial implementation as a baseline for everyone.

Also, I will submit basic patches to create a raspberrypi2 BSP variant. I
have built both the raspberrypi and raspberrypi2 BSPs and tested ticker so
far.

Alan


On Sun, Mar 15, 2015 at 7:11 AM, Gedare Bloom  wrote:

>
>
> On Sun, Mar 15, 2015 at 5:50 AM, QIAO YANG  wrote:
>
>> Hi !
>>
>> I've managed to run a hello demo on RPI B/B+, including a demo for
>> loading an image by u-boot (I don't have an ethernet cable on my hand, but
>> I'm going to be able to load the image by tftp for dev).
>>
>> If I've got it right, to prepare my proposal I may choose part of the
>> TODO list , look into the implementation detail and schedule it. The work
>> list may be divided for 3 students to complete.
>>
>> I've checked out the André's branch with GPIO, I2C, SPI implementations.
>> Should we develop based on his branch or the upstream? Have we said that
>> the I2C, SPI API has changed? I wonder that if anyone is working on it and
>> if we will merge Andre's work to upstream at the begining of GSOC. If not,
>> maybe I can get start by trying to do this job.
>>
>> The obvious projects I see from
> https://devel.rtems.org/wiki/Developer/Projects/Open/ImproveRaspberryPiBSP
> are:
> 1) Get #1-3 mergeable. May not take much. Then do #4 SD-card support and
> refactor the i2c to use the newer cpukit/dev/i2c interface.
> 2) #5 Graphics Frame Buffer + #7 HDMI/Graphics console
> 3) #6 USB + #7 Networking
> 4) Raspberry Pi 2 support, but this probably isn't enough.
>
> -Gedare
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH] preliminary Raspberry Pi Model 2 support

[Alan Cudmore]

---
 c/src/lib/libbsp/arm/raspberrypi/configure.ac  |  8 +++
 .../libbsp/arm/raspberrypi/include/raspberrypi.h   | 26 +-
 .../arm/raspberrypi/make/custom/raspberrypi.cfg| 15 +
 .../arm/raspberrypi/make/custom/raspberrypi.inc| 18 +++
 .../arm/raspberrypi/make/custom/raspberrypi2.cfg   |  7 ++
 .../arm/raspberrypi/startup/mm_config_table.c  |  5 +++--
 6 files changed, 57 insertions(+), 22 deletions(-)
 create mode 100644 c/src/lib/libbsp/arm/raspberrypi/make/custom/raspberrypi.inc
 create mode 100644 
c/src/lib/libbsp/arm/raspberrypi/make/custom/raspberrypi2.cfg

diff --git a/c/src/lib/libbsp/arm/raspberrypi/configure.ac 
b/c/src/lib/libbsp/arm/raspberrypi/configure.ac
index 42be4e9..27abe6c 100644
--- a/c/src/lib/libbsp/arm/raspberrypi/configure.ac
+++ b/c/src/lib/libbsp/arm/raspberrypi/configure.ac
@@ -24,6 +24,14 @@ AM_CONDITIONAL(HAS_NETWORKING,test "$HAS_NETWORKING" = "yes")
 RTEMS_BSPOPTS_SET([BSP_START_RESET_VECTOR],[*],[])
 RTEMS_BSPOPTS_HELP([BSP_START_RESET_VECTOR],[reset vector address for BSP 
start])
 
+# Is this a Raspberry Pi 2?
+RTEMS_BSPOPTS_SET([BSP_IS_RPI2],[raspberrypi2],[1])
+RTEMS_BSPOPTS_SET([BSP_IS_RPI2],[*],[0])
+RTEMS_BSPOPTS_HELP([BSP_IS_RPI2],[Set if the BSP variant is Raspberry Pi 2.])
+AM_CONDITIONAL(RTEMS_RPI2,[test "$BSP_IS_RPI2" = "1"])
+
+
+
 RTEMS_BSP_CLEANUP_OPTIONS(0, 0)
 RTEMS_BSP_LINKCMDS
 
diff --git a/c/src/lib/libbsp/arm/raspberrypi/include/raspberrypi.h 
b/c/src/lib/libbsp/arm/raspberrypi/include/raspberrypi.h
index 4cc7eec..e3c4d76 100644
--- a/c/src/lib/libbsp/arm/raspberrypi/include/raspberrypi.h
+++ b/c/src/lib/libbsp/arm/raspberrypi/include/raspberrypi.h
@@ -45,6 +45,20 @@
 /** @} */
 
 /**
+ * @name Peripheral Base Register Address 
+ *
+ * @{
+ */
+
+#if (BSP_IS_RPI2 == 1)
+   #define RPI_PERIPHERAL_BASE  0x3F00
+#else
+   #define RPI_PERIPHERAL_BASE  0x2000 
+#endif
+
+#define RPI_PERIPHERAL_SIZE 0x0100
+
+/**
  * @name Internal ARM Timer Registers
  *
  * @{
@@ -52,7 +66,7 @@
 
 #define BCM2835_CLOCK_FREQ   25000
 
-#define BCM2835_TIMER_BASE   (0x2000B400)
+#define BCM2835_TIMER_BASE   (RPI_PERIPHERAL_BASE + 0xB400)
 
 #define BCM2835_TIMER_LOD(BCM2835_TIMER_BASE+0x00)
 #define BCM2835_TIMER_VAL(BCM2835_TIMER_BASE+0x04)
@@ -74,7 +88,7 @@
  * @{
  */
 
-#define BCM2835_GPIO_REGS_BASE   (0x2020)
+#define BCM2835_GPIO_REGS_BASE   (RPI_PERIPHERAL_BASE + 0x20)
 
 #define BCM2835_GPIO_GPFSEL1 (BCM2835_GPIO_REGS_BASE+0x04)
 #define BCM2835_GPIO_GPSET0  (BCM2835_GPIO_REGS_BASE+0x1C)
@@ -90,7 +104,7 @@
  * @{
  */
 
-#define BCM2835_AUX_BASE (0x20215000)
+#define BCM2835_AUX_BASE (RPI_PERIPHERAL_BASE + 0x215000)
 
 #define AUX_ENABLES  (BCM2835_AUX_BASE+0x04)
 #define AUX_MU_IO_REG(BCM2835_AUX_BASE+0x40)
@@ -115,7 +129,7 @@
  */
 
 
-#define BCM2835_UART0_BASE   (0x20201000)
+#define BCM2835_UART0_BASE   (RPI_PERIPHERAL_BASE + 0x201000)
 
 #define BCM2835_UART0_DR (BCM2835_UART0_BASE+0x00)
 #define BCM2835_UART0_RSRECR (BCM2835_UART0_BASE+0x04)
@@ -155,7 +169,7 @@
  * @{
  */
 
-#define BCM2835_BASE_INTC (0x2000B200)
+#define BCM2835_BASE_INTC (RPI_PERIPHERAL_BASE + 0xB200)
 
 #define BCM2835_IRQ_BASIC (BCM2835_BASE_INTC + 0x00)
 #define BCM2835_IRQ_PENDING1  (BCM2835_BASE_INTC + 0x04)
@@ -182,7 +196,7 @@
  *   it's own RTOS. 1 and 3 are available for use in
  *   RTEMS.
  */
-#define BCM2835_GPU_TIMER_BASE(0x20003000)
+#define BCM2835_GPU_TIMER_BASE(RPI_PERIPHERAL_BASE + 0x3000)
 
 #define BCM2835_GPU_TIMER_CS  (BCM2835_TIMER_BASE+0x00)
 #define BCM2835_GPU_TIMER_CLO (BCM2835_TIMER_BASE+0x04)
diff --git a/c/src/lib/libbsp/arm/raspberrypi/make/custom/raspberrypi.cfg 
b/c/src/lib/libbsp/arm/raspberrypi/make/custom/raspberrypi.cfg
index 48ac0f8..759b79d 100644
--- a/c/src/lib/libbsp/arm/raspberrypi/make/custom/raspberrypi.cfg
+++ b/c/src/lib/libbsp/arm/raspberrypi/make/custom/raspberrypi.cfg
@@ -1,20 +1,7 @@
 #
 #  Config file for RASPBERRYPI
 #
-
-include $(RTEMS_ROOT)/make/custom/default.cfg
-
-RTEMS_CPU = arm
+include $(RTEMS_ROOT)/make/custom/raspberrypi.inc
 
 CPU_CFLAGS = -mcpu=arm1176jzf-s
 
-CFLAGS_OPTIMIZE_V = -O2 -g
-
-# This defines the operations performed on the linked executable.
-# is currently required.
-define bsp-post-link
-$(OBJCOPY) -O binary --strip-all \
-$(basename $@)$(EXEEXT) $(basename $@)$(DOWNEXT)
-$(SIZE) $(basename $@)$(EXEEXT)
-endef
-
diff --git a/c/src/lib/libbsp/arm/raspberrypi/make/custom/raspberrypi.inc 
b/c/src/lib/libbsp/arm/raspberrypi/make/custom/raspberrypi.inc
new file mode 100644
index 000..8a756cd
--- /dev/null
+++ b/c/src/lib/libbsp/arm/raspberrypi/make/custom/raspberrypi.inc
@@ -0,0 +1,18 @@
+#
+#  Config file for Raspberry Pi variants.
+#
+
+include $(RTEMS_ROOT)/make/custom/default.cfg
+
+RTEMS_CPU = arm
+
+CFLAGS_OPTIMIZE_V ?= -O2 -g
+
+# This def

Re: [PATCH] preliminary Raspberry Pi Model 2 support

[Alan Cudmore]

This patch adds a BSP variant for the Raspberry Pi 2.
--enable-rtemsbsp="raspberrypi2 raspberrypi"

For the current BSP, the only change was the peripheral register base
address and the compiler options.
The raspberrypi/make/custom rules were re-factored:
raspberrypi.inc -- Common rules
raspberrypi.cfg - Raspberry Pi 1 specific rule/optons
raspberrypi2.cfg -- Raspberry Pi 2 specific rule/options

I tested hello, ticker, unlimited, and paranoia on both the Pi ( Model A+ )
and Pi 2.

Alan

On Sun, Mar 15, 2015 at 12:04 PM, Alan Cudmore 
wrote:

> ---
>  c/src/lib/libbsp/arm/raspberrypi/configure.ac  |  8 +++
>  .../libbsp/arm/raspberrypi/include/raspberrypi.h   | 26
> +-
>  .../arm/raspberrypi/make/custom/raspberrypi.cfg| 15 +
>  .../arm/raspberrypi/make/custom/raspberrypi.inc| 18 +++
>  .../arm/raspberrypi/make/custom/raspberrypi2.cfg   |  7 ++
>  .../arm/raspberrypi/startup/mm_config_table.c  |  5 +++--
>  6 files changed, 57 insertions(+), 22 deletions(-)
>  create mode 100644
> c/src/lib/libbsp/arm/raspberrypi/make/custom/raspberrypi.inc
>  create mode 100644
> c/src/lib/libbsp/arm/raspberrypi/make/custom/raspberrypi2.cfg
>
> diff --git a/c/src/lib/libbsp/arm/raspberrypi/configure.ac
> b/c/src/lib/libbsp/arm/raspberrypi/configure.ac
> index 42be4e9..27abe6c 100644
> --- a/c/src/lib/libbsp/arm/raspberrypi/configure.ac
> +++ b/c/src/lib/libbsp/arm/raspberrypi/configure.ac
> @@ -24,6 +24,14 @@ AM_CONDITIONAL(HAS_NETWORKING,test "$HAS_NETWORKING" =
> "yes")
>  RTEMS_BSPOPTS_SET([BSP_START_RESET_VECTOR],[*],[])
>  RTEMS_BSPOPTS_HELP([BSP_START_RESET_VECTOR],[reset vector address for BSP
> start])
>
> +# Is this a Raspberry Pi 2?
> +RTEMS_BSPOPTS_SET([BSP_IS_RPI2],[raspberrypi2],[1])
> +RTEMS_BSPOPTS_SET([BSP_IS_RPI2],[*],[0])
> +RTEMS_BSPOPTS_HELP([BSP_IS_RPI2],[Set if the BSP variant is Raspberry Pi
> 2.])
> +AM_CONDITIONAL(RTEMS_RPI2,[test "$BSP_IS_RPI2" = "1"])
> +
> +
> +
>  RTEMS_BSP_CLEANUP_OPTIONS(0, 0)
>  RTEMS_BSP_LINKCMDS
>
> diff --git a/c/src/lib/libbsp/arm/raspberrypi/include/raspberrypi.h
> b/c/src/lib/libbsp/arm/raspberrypi/include/raspberrypi.h
> index 4cc7eec..e3c4d76 100644
> --- a/c/src/lib/libbsp/arm/raspberrypi/include/raspberrypi.h
> +++ b/c/src/lib/libbsp/arm/raspberrypi/include/raspberrypi.h
> @@ -45,6 +45,20 @@
>  /** @} */
>
>  /**
> + * @name Peripheral Base Register Address
> + *
> + * @{
> + */
> +
> +#if (BSP_IS_RPI2 == 1)
> +   #define RPI_PERIPHERAL_BASE  0x3F00
> +#else
> +   #define RPI_PERIPHERAL_BASE  0x2000
> +#endif
> +
> +#define RPI_PERIPHERAL_SIZE 0x0100
> +
> +/**
>   * @name Internal ARM Timer Registers
>   *
>   * @{
> @@ -52,7 +66,7 @@
>
>  #define BCM2835_CLOCK_FREQ   25000
>
> -#define BCM2835_TIMER_BASE   (0x2000B400)
> +#define BCM2835_TIMER_BASE   (RPI_PERIPHERAL_BASE + 0xB400)
>
>  #define BCM2835_TIMER_LOD(BCM2835_TIMER_BASE+0x00)
>  #define BCM2835_TIMER_VAL(BCM2835_TIMER_BASE+0x04)
> @@ -74,7 +88,7 @@
>   * @{
>   */
>
> -#define BCM2835_GPIO_REGS_BASE   (0x2020)
> +#define BCM2835_GPIO_REGS_BASE   (RPI_PERIPHERAL_BASE + 0x20)
>
>  #define BCM2835_GPIO_GPFSEL1 (BCM2835_GPIO_REGS_BASE+0x04)
>  #define BCM2835_GPIO_GPSET0  (BCM2835_GPIO_REGS_BASE+0x1C)
> @@ -90,7 +104,7 @@
>   * @{
>   */
>
> -#define BCM2835_AUX_BASE (0x20215000)
> +#define BCM2835_AUX_BASE (RPI_PERIPHERAL_BASE + 0x215000)
>
>  #define AUX_ENABLES  (BCM2835_AUX_BASE+0x04)
>  #define AUX_MU_IO_REG(BCM2835_AUX_BASE+0x40)
> @@ -115,7 +129,7 @@
>   */
>
>
> -#define BCM2835_UART0_BASE   (0x20201000)
> +#define BCM2835_UART0_BASE   (RPI_PERIPHERAL_BASE + 0x201000)
>
>  #define BCM2835_UART0_DR (BCM2835_UART0_BASE+0x00)
>  #define BCM2835_UART0_RSRECR (BCM2835_UART0_BASE+0x04)
> @@ -155,7 +169,7 @@
>   * @{
>   */
>
> -#define BCM2835_BASE_INTC (0x2000B200)
> +#define BCM2835_BASE_INTC (RPI_PERIPHERAL_BASE + 0xB200)
>
>  #define BCM2835_IRQ_BASIC (BCM2835_BASE_INTC + 0x00)
>  #define BCM2835_IRQ_PENDING1  (BCM2835_BASE_INTC + 0x04)
> @@ -182,7 +196,7 @@
>   *   it's own RTOS. 1 and 3 are available for use in
>   *   RTEMS.
>   */
> -#define BCM2835_GPU_TIMER_BASE(0x20003000)
> +#define BCM2835_GPU_TIMER_BASE(RPI_PERIPHERAL_BASE + 0x3000)
>
>  #define BCM2835_GPU_TIMER_CS  (BCM2835_TIMER_BASE+0x00)
>  #define BCM2835_GPU_TIMER_CLO (BCM2835_TIMER_BASE+0x04)
> diff --git a/c/src/lib/libbsp/arm/raspberrypi/make/custom/raspberrypi.cfg
&

Re: Raspberry Pi 2 boot

[Alan Cudmore]

Jeff,
I have been running samples on the the RPI 2 by using the latest firmware:
https://github.com/raspberrypi/firmware/tree/master/boot

I just copied all of the files from the boot directory on my SD card.

I rename the sample ( ticker.ralf for example )  kernel7.img and it runs.

You can even copy a RPI 1 image to kernel.img and boot it using the same
card.

Alan


On Wed, Mar 18, 2015 at 2:41 PM, Jeff Mayes  wrote:

> Hi,
>
> I’ve built the Raspberry Pi 2 bsp and samples.  My SD card has Raspian for
> the moment, and I don’t see a kernel.img file like the previous Raspberry
> had.  So, how do I get “hello world” to run off the SD card?
>
>
>
> Thanks
> Jeff
>
>
>
>
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [RPI BSP] Framebuffer test

[Alan Cudmore]

Hi everyone,
A while back, I experimented with different graphics demos on the Pi. I
integrated some of this code into the RKI image and was able to draw simple
graphics under RTEMS:
https://www.cl.cam.ac.uk/projects/raspberrypi/tutorials/os/screen01.html

There are some other neat demos available too. This person ported the ugfx
library to the Pi using FreeRTOS:
http://macload1.frogcp.com/
I was able to run several of the ugfx graphics demos using this port (
under FreeRTOS, not RTEMS )

This person has some really nice demos using bare metal. He has support for
NEON and SMP on the Raspberry Pi 2 as well.
https://github.com/PeterLemon/RaspberryPi

Another bare metal Multi-core mandelbrot demo:
https://github.com/mrvn/test
http://www.raspberrypi.org/forums/viewtopic.php?f=72&t=98904&start=50

Of course, all of the usual License caveats apply.. This is all good for
fun and education, but the code cannot be copied into RTEMS because the
licenses are not compatible with the RTEMS license. But they all serve as
good references and examples of what can be done with graphics on the Pi. (
and some SMP Pi 2 hints in there ! )


Alan



On Mon, Apr 6, 2015 at 6:50 PM, Pavel Pisa  wrote:

> Hello Yang Qiao,
>
> On Tuesday 07 of April 2015 00:00:33 QIAO YANG wrote:
> > I've implemented a simple framebuffer, but I've got no idea how to test
> it.
> >
> > I've got Alan's rki and I made a sample to test the mailbox, the
> > framebuffer information seems to be successfully set and get (width,
> > height, pitch, buffer pointer, buffersize etc). In linux we open the
> > interface and map the pointer to set the pixels. If I try to access the
> > pointer and set the memory directly in the driver to draw something, the
> > program will stay still when I try to assign value to a certain address
> of
> > memory, or maybe it's only allowed to use memset/ memcpy to set the
> memory?
> >
> >  I've also tried to load the driver and open it ( /dev/fb0 ) with "open",
> > but it failed, while I can see the interface with "ls /dev ".
> >
> > In order to test the framebuffer, how can I use the fb interface to print
> > something, or maybe access the memory directly? Is there any existing
> > sample for fb testing? If not, is it necessary to create a common sample
> > for all to print something?
>
> I have not studied how it works on RPi. As I know from
> other reading, some part of physical memory is reserved for
> GPU/framebuffer by one of boot stages and configuration
> can be changed by "gpu_mem" in "config.txt"
>
>   http://elinux.org/RPiconfig
>
> It is great if you can setup display output mode.
> How is setup framebuffer start address? In the fact
> if you use same mode setup as is used in Linux then
> you should have same framebuffer starting physical address.
> RTEMS uses 1:1 CPU (virtual) to physical mapping.
> It is necessary to check that framebuffer physical address
> range is covered by 1:1 mapping initialization. This is in the
> fact equivalent to mmap() address space/VMA and page table manipulation
> on Linux. Check page table initialization at
>
>   rtems/c/src/lib/libbsp/arm/raspberrypi/startup/mm_config_table.c
>
> I am almost sure that you have to define additional rage
> to cover framebuffer address range. You should use uncached
> configuration
>
>   ARMV7_MMU_DATA_READ_WRITE
>
> at least for start. Some performance can be gained if read caching
> and write through + write combine is enabled for framebuffer area,
> but I am not sure if there is defined matching CP15 combination
> in
>
>   rtems/c/src/lib/libcpu/arm/shared/include/arm-cp15.h
>
> If this matches then you should be able to access framebuffer directly.
> I.e. from some BSP/framebuffer driver initialization code or some
> application
> linked to RTEMS system libraries some or you can modify some RTEMS
> test example to access given address directly.
>
> Which pixel format are you using - 16 bit RGB565, 24 bit RGB888
> or 32 bit RGBA? I would suggest to use 32 bit format RGB + 8 bit
> padding when there is enough memory for simplicity. It allows simple
> XY to address conversion and accesses to pixel are aligned.
>
> Then you should test something like
>
>   memset((char *)startaddress, 0, size_x * size_y * 4);
>   for (i = 0; i < 500; i++) {
>  ((uint32_t *)startaddress)[i] = 0xff;
>  ((uint32_t *)startaddress+1280)[i] = 0xff;
>  ((uint32_t *)startaddress+1280*2)[i] = 0x00ff00;
>  ((uint32_t *)startaddress+1280*3)[i] = 0xff;
>   }
>
> and you should see white, red, green and blue strips an the to of the
> display.
> If this goes well then you can check that physical address is passed right
> by /dev/fb0 appropriate IOCTL to the graphic libraries.
>
> You can access and modify physical addresses even from terminal by
> RTEMS shell medit command
>
>   rtems/cpukit/libmisc/shell/main_medit.c
>
> You need to have shell compiled and started in your application or you
> can compile and use RTEMS shell example for this testing.

[PATCH] Add hardware FPU flags for Raspberry Pi 2 BSP

[Alan Cudmore]

---
 c/src/lib/libbsp/arm/raspberrypi/make/custom/raspberrypi2.cfg | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/c/src/lib/libbsp/arm/raspberrypi/make/custom/raspberrypi2.cfg 
b/c/src/lib/libbsp/arm/raspberrypi/make/custom/raspberrypi2.cfg
index 08dda04..a233d34 100644
--- a/c/src/lib/libbsp/arm/raspberrypi/make/custom/raspberrypi2.cfg
+++ b/c/src/lib/libbsp/arm/raspberrypi/make/custom/raspberrypi2.cfg
@@ -3,4 +3,4 @@
 #
 include $(RTEMS_ROOT)/make/custom/raspberrypi.inc
 
-CPU_CFLAGS = -march=armv7-a -mtune=cortex-a7
+CPU_CFLAGS = -march=armv7-a -mthumb -mfpu=neon -mfloat-abi=hard 
-mtune=cortex-a7
-- 
1.9.1

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

Re: [PATCH] Add hardware FPU flags for Raspberry Pi 2 BSP

[Alan Cudmore]

This patch adds hardware FPU support for the RPI 2.
Builds and runs examples on the Pi2. My RKI image whetstone command is
significantly faster.

Alan


On Tue, Apr 7, 2015 at 4:06 PM, Alan Cudmore  wrote:

> ---
>  c/src/lib/libbsp/arm/raspberrypi/make/custom/raspberrypi2.cfg | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/c/src/lib/libbsp/arm/raspberrypi/make/custom/raspberrypi2.cfg
> b/c/src/lib/libbsp/arm/raspberrypi/make/custom/raspberrypi2.cfg
> index 08dda04..a233d34 100644
> --- a/c/src/lib/libbsp/arm/raspberrypi/make/custom/raspberrypi2.cfg
> +++ b/c/src/lib/libbsp/arm/raspberrypi/make/custom/raspberrypi2.cfg
> @@ -3,4 +3,4 @@
>  #
>  include $(RTEMS_ROOT)/make/custom/raspberrypi.inc
>
> -CPU_CFLAGS = -march=armv7-a -mtune=cortex-a7
> +CPU_CFLAGS = -march=armv7-a -mthumb -mfpu=neon -mfloat-abi=hard
> -mtune=cortex-a7
> --
> 1.9.1
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] [RPI BSP] mailbox

[Alan Cudmore]

Hi Qiao,
Functionally, this code looks good to me. It builds without warnings for the Pi 
and Pi2, and I was able to make the calls to init the frame buffer on the Pi 
B+. 

When you did the frame buffer test, what was your MMU table entry for the 
mailbox/framebuffer?

Thanks,
Alan


> On Apr 19, 2015, at 3:17 PM, QIAO YANG  wrote:
> 
> Here is a modified patch for mailbox.  If there's still anything against the 
> convention, please point it out and I'll correct it immediately. The mailbox 
> implementation might also be needed by other rpi bsp developpers.
> 
> --
> 
> diff --git a/c/src/lib/libbsp/arm/raspberrypi/Makefile.am 
> b/c/src/lib/libbsp/arm/raspberrypi/Makefile.am
> index c6133df..70bc01d 100644
> --- a/c/src/lib/libbsp/arm/raspberrypi/Makefile.am
> +++ b/c/src/lib/libbsp/arm/raspberrypi/Makefile.am
> @@ -43,6 +43,7 @@ include_bsp_HEADERS += ../shared/include/arm-release-id.h
>  include_bsp_HEADERS += include/irq.h
>  include_bsp_HEADERS += include/mmu.h
>  include_bsp_HEADERS += include/usart.h
> +include_bsp_HEADERS += include/mailbox.h
>  include_bsp_HEADERS += include/raspberrypi.h
>  
>  include_libcpu_HEADERS = ../../../libcpu/arm/shared/include/cache_.h \
> @@ -123,6 +124,9 @@ libbsp_a_SOURCES += misc/timer.c
>  
>  # I2C
>  
> +# Mailbox
> +libbsp_a_SOURCES += misc/mailbox.c
> +
>  # Cache
>  libbsp_a_SOURCES += ../../../libcpu/shared/src/cache_manager.c
>  libbsp_a_SOURCES += ../../../libcpu/arm/shared/include/cache_.h
> diff --git a/c/src/lib/libbsp/arm/raspberrypi/include/mailbox.h 
> b/c/src/lib/libbsp/arm/raspberrypi/include/mailbox.h
> new file mode 100644
> index 000..fa6a0c2
> --- /dev/null
> +++ b/c/src/lib/libbsp/arm/raspberrypi/include/mailbox.h
> @@ -0,0 +1,33 @@
> +/**
> + * @file
> + *
> + * @ingroup raspberrypi
> + *
> + * @brief mailbox support.
> + */
> +
> +/*
> + * Copyright (c) 2015 Yang Qiao
> + *
> + *  The license and distribution terms for this file may be
> + *  found in the file LICENSE in this distribution or at
> + *
> + *  http://www.rtems.org/license/LICENSE
> + *
> + */
> +
> +#ifndef LIBBSP_ARM_RASPBERRYPI_MAILBOX_H
> +#define LIBBSP_ARM_RASPBERRYPI_MAILBOX_H
> +
> +#ifdef __cplusplus
> +extern "C" {
> +#endif /* __cplusplus */
> +
> +extern unsigned int  raspberrypi_mailbox_read(unsigned int channel);
> +extern void raspberrypi_mailbox_write(unsigned int channel, unsigned int 
> data);
> +
> +#ifdef __cplusplus
> +}
> +#endif /* __cplusplus */
> +
> +#endif  /* LIBBSP_ARM_RASPBERRYPI_MAILBOX_H */
> diff --git a/c/src/lib/libbsp/arm/raspberrypi/include/raspberrypi.h 
> b/c/src/lib/libbsp/arm/raspberrypi/include/raspberrypi.h
> index c33e22a..3240404 100644
> --- a/c/src/lib/libbsp/arm/raspberrypi/include/raspberrypi.h
> +++ b/c/src/lib/libbsp/arm/raspberrypi/include/raspberrypi.h
> @@ -208,6 +208,55 @@
>  
>  /** @} */
>  
> + /**
> + * @name Mailbox Registers
> + *
> + * @{
> + */
> +
> +#define BCM2835_MBOX_BASE (RPI_PERIPHERAL_BASE+0xB880)
> +
> +#define BCM2835_MBOX_PEEK (BCM2835_MBOX_BASE+0x10)
> +#define BCM2835_MBOX_READ (BCM2835_MBOX_BASE+0x00)
> +#define BCM2835_MBOX_WRITE (BCM2835_MBOX_BASE+0x20)
> +#define BCM2835_MBOX_STATUS (BCM2835_MBOX_BASE+0x18)
> +#define BCM2835_MBOX_SENDER (BCM2835_MBOX_BASE+0x14)
> +#define BCM2835_MBOX_CONFIG (BCM2835_MBOX_BASE+0x1C)
> +
> +#define BCM2835_MBOX_SUCCESS (BCM2835_MBOX_BASE+0x8000)
> +#define BCM2835_MBOX_FULL (BCM2835_MBOX_BASE+0x8000)
> +#define BCM2835_MBOX_EMPTY (BCM2835_MBOX_BASE+0x4000)
> +
> +/**
> +* @name Mailbox Channels
> +*
> +* @{
> +*/
> +
> +/* Power Manager channel */
> +#define BCM2835_MBOX_CHANNEL_PM 0
> +/* Framebuffer channel */
> +#define BCM2835_MBOX_CHANNEL_FB 1
> + /* Virtual UART channel */
> +#define BCM2835_MBOX_CHANNEL_VUART  2
> + /* VCHIQ channel */
> +#define BCM2835_MBOX_CHANNEL_VCHIQ  3
> + /* LEDs channel */
> +#define BCM2835_MBOX_CHANNEL_LED4
> + /* Button channel */
> +#define BCM2835_MBOX_CHANNEL_BUTTON 5
> + /* Touch screen channel */
> +#define BCM2835_MBOX_CHANNEL_TOUCHS 6
> +/* Property tags (ARM <-> VC) channel */
> +#define BCM2835_MBOX_CHANNEL_PROP_AVC   8
> + /* Property tags (VC <-> ARM) channel */
> +#define BCM2835_MBOX_CHANNEL_PROP_VCA   9
> +
> +/** @} */
> +
> +
> +/** @} */
> +
>  
>  /** @} */
>  
> diff --git a/c/src/lib/libbsp/arm/raspberrypi/misc/mailbox.c 
> b/c/src/lib/libbsp/arm/raspberrypi/misc/mailbox.c
> new file mode 100644
> index 000..2a63a41
> --- /dev/null
> +++ b/c/src/lib/libbsp/arm/raspberrypi/misc/mailbox.c
> @@ -0,0 +1,44 @@
> +/**
> + * @file
> + *
> + * @ingroup raspberrypi
> + *
> + * @brief mailbox support.
> + */
> +
> +/*
> + * Copyright (c) 2015 Yang Qiao
> + *
> + *  The license and distribution terms for this file may be
> + *  found in the file LICENSE in this distribution or at
> + *
> + *  http://www.rtems.org/license/LICENSE
> + *
> + */
> +
> +#include 
> +#include 
> +#include 
> +
> +unsigned int raspberrypi_mailbox_read (unsigned int c

Re: [RPI BSP] resume, plan and questions for fb, fbcon gtk

[Alan Cudmore]

Hi YANG Qiao and fellow mentors,

> On May 4, 2015, at 7:08 PM, QIAO YANG  wrote:
> 
> Hello everyone,
> 
> Since I haven't yet received any respond of my last mail and I've now got the 
> names of mentors who would instruct me, I create a new thread for a simple 
> resume and post my questions .
> 
> First of all, I've managed to use mailbox channel to get a framebuffer 
> pointer and its informations. I can draw some simple images with the pointer 
> and also the pointer can be retrieved correctly by ioctrl from applications, 
> with the fb device interface. Painting works as well.
> I've already sent a patch with mailbox implementation, but I haven't yet 
> confirmed if it's ready to be merged or any modification should be done.

I applied this patch and have commented that it compiles for me. I think new 
patches might be held up right now while the 4.11 release is sorted out. 

I am also working on a fork of the RTEMS tree with your mailbox patch, and I 
have re-integrated Andre’s GPIO, SPI, and I2C code, just to have the latest of 
everything for the RPI to this date.


> 
> 
> 
> To complete fb implementation:
> 1.  Some more functions need to be added : connected monitor EDID read and 
> decoding for correct/optimal resolution selection. I don't know if we need a 
> full VESA driver like what we've done on i386. 

I’m not too familiar with the VESA standard, does anyone else have an opinion?

> 
> 2.   If we've enabled l2 cache, the memory mapping would be 0x4000, while 
> the mapping would be 0xC000 instead if l2 cache disabled. Normally it can 
> be configured in the config.txt file. 

I would think we want to have L2 cache enabled by default. Any reason to 
support the frame buffer without the cache?

> 
> The file 'config.txt' is read by GPU before the ARM core is initialized. It's 
> used as an BIOS configuration. It can be used to setup hdmi output mode, l2 
> cache, memory split etc. Such as memory split affect much the range of 
> framebuffer address which should be covered in the mmu configuration table. 
> What would be a better way to deal with it?  Should I enable the memory pages 
> that cover all possible range(This can vary depend on gpu_mem_split) ?

I’m not sure.. We probably need the MMU table before we start reading the 
configuration from the GPU mailbox, so it is hard to build the MMU table 
dynamically. Could we start with MMU disabled, query the mailbox API to 
determine the memory configuration, then setup the MMU?


> 
> 
> To plan for fbcon implementation:
> 1.  Find instructions for cursor. I've found that it's possible to get some 
> infos from mailbox property channel.
> 
> 2. Implementations refering to i386/pc386/console/outch.c
> 
> 3. Implementations refering to i386/pc386/console/vgacons
> 
> 
> For GTK porting
> 
> I tried to compile gtk for it. The libpng ...  etc can be installed and I'm 
> trying to make some samples for testing. Only the nxlib failed to build 
> because we haven't yet the keyboard support (mouse support can be switched 
> off, but I can't find out yet how to build the lib without keyboard).
> 
> That's all for a resume, plan, and questions report for my work.

By GTK, are you referring to the RTEMS Graphics tool kit? ( not the GTK/gnome 
libraries right? ) 

Thanks for the update, 
As soon as I get all of the latest Raspberry Pi code together in my repository, 
I’ll let everyone know. 

Alan



> 
> Best regards,
> 
> YANG Qiao

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

Re: Pre-branching Testing Request

[Alan Cudmore]

Hi Joel,
I cloned RSB, built a new copy of ARM and SPARC tools, cloned rtems.git, built 
for leon3, sis, raspberrypi, and raspberrypi2

I tried a hello and ticker on gdb/sis

I ran my RKI image, hello, ticker, paranoia, and unlimited on the Rasberry Pi 
2, Raspberry Pi B+, and Raspberry Pi A+

I need to try running a few tests on my old coldfire and Gameboy advance..

Alan


> On May 20, 2015, at 9:57 AM, Joel Sherrill  wrote:
> 
> Hi
> 
> Please test on your local hardware and report success or failures.
> 
> We are pushing clean up activities to be able to branch and make
> a 4.11.0 as soon as possible.
> 
> -- 
> Joel Sherrill, Ph.D. Director of Research & Development
> joel.sherr...@oarcorp.comOn-Line Applications Research
> Ask me about RTEMS: a free RTOS  Huntsville AL 35805
> Support Available(256) 722-9985
> 
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel

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

Re: GSoC 2015: Raspberry Pi 2 Support

[Alan Cudmore]

The caches are being enabled on the RPI 1 BSP. The same code is being executed 
by the RPI 2 BSP, but obviously it’s not sufficient for the cache setup.
I have been reading through this long thread, and it is very informative:
https://www.raspberrypi.org/forums/viewtopic.php?f=72&t=98904 


I am starting to understand the setup that is required to enable caches on the 
RPI 2. For example this message near the bottom of page 3 gives a good 
indication of the speedup available by configuring the MMU and caches correctly:
Quote from above thread
--
Enabling I/D caches and branch prediction, just like the julia demo uses, it 
takes ~12 seconds, or ~21 fps. It's just one core but also a much smaller loop 
than the julia demo has.

Enabling the MMU and mapping memory inner/outer write-back, write allocate and 
the framebuffer inner write-through, no write allocate + outer write-back, 
write-allocate it takes ~8 seconds, of 32 fps.

PS: 640x480x32 with MMU gets me ~256 fps. Must have a greater L2 cache effect.
-
End of quote

The person who posted the above comment (mrvn) posted the code here:
https://github.com/mrvn/test/blob/master/mmu.cc 



Also, it seems that when the Pi 2 starts up, cores 1-3 are put in a wait loop 
always accessing the bus. By putting this option in the config.txt file you can 
put the other cores to sleep, speeding up the code on core 1.  
 arm_control=0x1000
It would be worth trying that option to see if the benchmark speeds up.


Alan

> On Jun 2, 2015, at 8:05 AM, Hesham ALMatary  wrote:
> 
> On Tue, Jun 2, 2015 at 12:41 PM, Rohini Kulkarni  > wrote:
>> From what I saw, they have to be enabled separately. Cache/mmu are disabled
>> upon reset.
>> 
> For the existing Raspberry BSP [1] there's a code for MMU/Cache init,
> however I don't know about Pi2 and where its code is.
> 
> [1] 
> https://github.com/RTEMS/rtems/tree/master/c/src/lib/libbsp/arm/raspberrypi 
> 
>> On 2 Jun 2015 16:59, "Hesham ALMatary"  wrote:
>>> 
>>> Hi,
>>> 
>>> Aren't the MMU/Caches enabled by default for RPi [1]?
>>> 
>>> [1]
>>> https://github.com/RTEMS/rtems/blob/master/c/src/lib/libbsp/arm/shared/mminit.c
>>> 
>>> On Tue, Jun 2, 2015 at 12:18 PM, Joel Sherrill
>>>  wrote:
 
 
 On June 2, 2015 7:01:21 AM EDT, Rohini Kulkarni 
 wrote:
> Dr. Joel,
> 
> So we can't say something solely on the basis of this result?
 
 I don't think so. If Linux performs the same, then what you did is as
 good as it gets.
 
 However, if Linux is faster then some setting still isn't right.
 
 You need a reference measurement to have any confidence. It is possible
 you did something but didn't actually turn the cache (or all the cache) on.
 
> On 2 Jun 2015 16:28, "Rohini Kulkarni"  wrote:
> 
> I have not run it under linux on pi2 yet. Will have to run and check
> the result.
> 
> On 2 Jun 2015 16:16, "Joel Sherrill"  wrote:
> 
> 
> 
> On June 2, 2015 5:58:33 AM EDT, Rohini Kulkarni 
> wrote:
>> HI,
>> 
>> I tried running the dhrystone benchmark with some changes for
> cache/mmu
>> set up.
>> 
>> However, the output shows a reduction in performance.
>> The time to run through the dhrystone has increased from 12 to 13 and
>> dhrystones run per second decreased.
>> 
>> According to this result, things were better with caches disabled.
>> 
>> 
>> I have been working on this since two days and could not figure out an
>> improvement. Any pointers?
> 
> How did it do under Linux on the Pi2?
> 
> 
>> Thanks.
>> 
>> 
>> 
>> On Thu, May 28, 2015 at 8:41 PM, Rohini Kulkarni
>>  wrote:
>> 
>> Hi All,
>> 
>> I have to implement the cache coherency support for Cortex A7. But for
>> A7 MPCore, unlike for A9, I am not able to find any register
>> description for the Snoop Control Unit from the TRM.
>> 
>> I need help here on how to proceed.
>> 
>> Additionally for A9 there is a single bit for A9 in the Auxiliary
>> Control Register which enables cache broadcast operations. The
> register
>> format is different for A7 and again I am unable to find how to
> achieve
>> the same for A7.
>> 
>> Thanks!
>> 
>> 
>> 
>> 
>> 
>> On Tue, May 5, 2015 at 10:42 PM, Joel Sherrill
>>  wrote:
>> 
>> 
>> 
>> On 5/5/2015 11:11 AM, Rohini Kulkarni wrote:
>> 
>> Hi,
>> 
>> I am working with the code for bsp hooks. I am referring to existing
>> ARM multicore bsp codes, zync mainly.
>> 
>> 1. There are existing hooks for the raspberry pi. Where should the
> co

Re: GSoC 2015: Raspberry Pi 2 Support

[Alan Cudmore]

Hi,
Some of the code examples may give you some clues. Like this one:
https://github.com/mrvn/test/blob/master/smp.cc

Or this:
https://github.com/PeterLemon/RaspberryPi/tree/master/SMP/SMPINIT

If you still can't figure it out, you can always join the raspberrypi.org
forums and ask on this thread:
https://www.raspberrypi.org/forums/viewtopic.php?f=72&t=98904

When it comes to the Pi 2 and SMP, you are our RTEMS expert :)

Thanks,
Alan


On Sat, Jun 13, 2015 at 2:29 PM, Rohini Kulkarni 
wrote:

> Hi,
>
> This is regarding Pi 2 SMP support. After powering on, the secondary
> mailboxes read one of their four mailbox registers and wait for a non-zero
> content to be written. This content is to be the physical address of the
> location from where the cores are expected to start execution.
>
> I am stuck at figuring out this address. How should I go about
> understanding this?
>
> Thanks!
> On 3 Jun 2015 19:44, "Gedare Bloom"  wrote:
>
>> On Wed, Jun 3, 2015 at 2:39 AM, Rohini Kulkarni 
>> wrote:
>> > But, I can't say cache configurations have a role here.
>> >
>> > I'll push my code to my github project soon.
>> >
>> > P.S. The Pi2 board I possess seems to have broken down. It just isn't
>> > turning on. Unable to test further. Will order one immediately.
>> >
>> Ouch. Make sure you put it in a safe space for development, clear of
>> threats like moisture, static shock, and cats.
>>
>> > On 3 Jun 2015 09:03, "Rohini Kulkarni"  wrote:
>> >>
>> >> Hi,
>> >>
>> >> Alan, your suggestion has resulted in much improvement
>> >>
>> >> arm_control=0x1000
>> >>
>> >> This has simply worked! Looks like the other cores were taking up
>> plenty
>> >> of time.
>> >> I was aware from references that the other cores run a WFI, but ya, did
>> >> not get its impact.
>> >> Time for each dhrystone has reduced to 7 from 13 and the no of
>> dhrystones
>> >> per second also increased.
>> >>
>> >> But this is a change only in the config.txt not actually in the boot
>> code.
>> >>
>> >> Thanks
>> >>
>> >> Rohini
>> >>
>> >>
>> >>
>> >> On Wed, Jun 3, 2015 at 7:12 AM, Alan Cudmore 
>> >> wrote:
>> >>>
>> >>> The caches are being enabled on the RPI 1 BSP. The same code is being
>> >>> executed by the RPI 2 BSP, but obviously it’s not sufficient for the
>> cache
>> >>> setup.
>> >>> I have been reading through this long thread, and it is very
>> informative:
>> >>> https://www.raspberrypi.org/forums/viewtopic.php?f=72&t=98904
>> >>>
>> >>> I am starting to understand the setup that is required to enable
>> caches
>> >>> on the RPI 2. For example this message near the bottom of page 3
>> gives a
>> >>> good indication of the speedup available by configuring the MMU and
>> caches
>> >>> correctly:
>> >>> Quote from above thread
>> >>> --
>> >>> Enabling I/D caches and branch prediction, just like the julia demo
>> uses,
>> >>> it takes ~12 seconds, or ~21 fps. It's just one core but also a much
>> smaller
>> >>> loop than the julia demo has.
>> >>>
>> >>> Enabling the MMU and mapping memory inner/outer write-back, write
>> >>> allocate and the framebuffer inner write-through, no write allocate +
>> outer
>> >>> write-back, write-allocate it takes ~8 seconds, of 32 fps.
>> >>>
>> >>> PS: 640x480x32 with MMU gets me ~256 fps. Must have a greater L2 cache
>> >>> effect.
>> >>> -
>> >>> End of quote
>> >>>
>> >>> The person who posted the above comment (mrvn) posted the code here:
>> >>> https://github.com/mrvn/test/blob/master/mmu.cc
>> >>>
>> >>>
>> >>> Also, it seems that when the Pi 2 starts up, cores 1-3 are put in a
>> wait
>> >>> loop always accessing the bus. By putting this option in the
>> config.txt file
>> >>> you can put the other cores to sleep, speeding up the code on core 1.
>> >>>  arm_control=0x1000
>> >>> It would be worth trying that option to see if the benchmark speeds
>> up.
>> >>>
&g

Re: GSoC 2015: Raspberry Pi 2 Support

[Alan Cudmore]

Great news on the Pi 2 cache configuration!
I am looking forward to a patch to try.

Alan


On Sun, Jun 21, 2015 at 3:27 PM, Rohini Kulkarni 
wrote:

> :)
> There is very little code that had to be added.
> I need to clean the code and add conditional call for Pi 2. Then I would
> be ready to submit a patch.
>  On 22 Jun 2015 00:52, "Gedare Bloom"  wrote:
>
>> On Sun, Jun 21, 2015 at 3:04 PM, Rohini Kulkarni 
>> wrote:
>> > I missed mentioning the number of dhrystones in the previous mail.
>> >
>> > Originally it was 1 million.
>> > The new number of dhrystones I executed is 100 million.
>> >
>> The next thing to do is to figure out what changes are contributing to
>> the performance improvement, and then prepare patches. :) Great work
>>
>> > On Mon, Jun 22, 2015 at 12:29 AM, Rohini Kulkarni <
>> krohini1...@gmail.com>
>> > wrote:
>> >>
>> >> Hi all,
>> >>
>> >> I have managed to get a significant performance improvement with some
>> >> changes in configurations.
>> >>
>> >> The measured time was for dhrystones reduced from 12 to "too small to
>> be
>> >> measured "
>> >>
>> >> For dhrystones the time was 0.4.
>> >>
>> >> The number of dhrystones per second increased from approximately 8
>> to
>> >> 250 :)
>> >>
>> >> Thanks!
>> >>
>> >> On Sun, Jun 21, 2015 at 1:32 AM, Rohini Kulkarni <
>> krohini1...@gmail.com>
>> >> wrote:
>> >>>
>> >>> Hi,
>> >>>
>> >>> I have added an SMP related post to my blog to define where exactly in
>> >>> the code I need to work. Some feedback to indicate if I am
>> identifying the
>> >>> work area correctly would be very helpful!
>> >>>
>> >>> Thanks!
>> >>>
>> >>> On 18 Jun 2015 03:37, "Rohini Kulkarni" 
>> wrote:
>> >>>>
>> >>>> Hi all,
>> >>>>
>> >>>> I have updated my blog to reflect my understanding and attempts for
>> >>>> cache performance issue.
>> >>>>
>> >>>> Lately I have been trying around memory attributes for the
>> >>>> mm_config_table. One set of configurations for cacheable memory
>> (inner and
>> >>>> outer levels)ended up reducing performance further ( which I really
>> thought
>> >>>> would improve). So this table set up certainly controls performance.
>> >>>>
>> >>>> The results are not improving after turning on cache. So memory
>> sections
>> >>>> are perhaps not even getting cached.
>> >>>> I get a feeling it has got to do with this mm_config_table.
>> >>>>
>> >>>> Updates from the github code and blog might help in further
>> discussion.
>> >>>>
>> >>>> Link to github code:https://github.com/krohini1593/rtems/tree/rohini
>> >>>>
>> >>>> Link to Blog
>> >>>>
>> >>>> Thanks!
>> >>>>
>> >>>> On Mon, Jun 15, 2015 at 8:29 PM, Alan Cudmore <
>> alan.cudm...@gmail.com>
>> >>>> wrote:
>> >>>>>
>> >>>>> Hi,
>> >>>>> Some of the code examples may give you some clues. Like this one:
>> >>>>> https://github.com/mrvn/test/blob/master/smp.cc
>> >>>>>
>> >>>>> Or this:
>> >>>>> https://github.com/PeterLemon/RaspberryPi/tree/master/SMP/SMPINIT
>> >>>>>
>> >>>>> If you still can't figure it out, you can always join the
>> >>>>> raspberrypi.org forums and ask on this thread:
>> >>>>> https://www.raspberrypi.org/forums/viewtopic.php?f=72&t=98904
>> >>>>>
>> >>>>> When it comes to the Pi 2 and SMP, you are our RTEMS expert :)
>> >>>>>
>> >>>>> Thanks,
>> >>>>> Alan
>> >>>>>
>> >>>>>
>> >>>>> On Sat, Jun 13, 2015 at 2:29 PM, Rohini Kulkarni
>> >>>>>  wrote:
>> >>>>>>
>> >>>>>> Hi,
>> >>>>>>
>> >>>>>> This is regar

Re: [GSOC] Project update

[Alan Cudmore]

A question about the rtems_gpio_setup_UART functions;
Could it be implemented with rtems_gpio_set_mb(RPI_PORT,
RPI_GPIO_UART_MASK) , or would it do additional setup?

If BSP specific mask defines could be used, it would be easier to
implement, and it would not matter which GPIO peripherals each BSP
supported.

Alan





On Tue, Jun 17, 2014 at 10:52 AM, Andre Marques <
andre.lousa.marq...@gmail.com> wrote:

>  On 06/17/14 15:39, Alan Cudmore wrote:
>
> Hi Andre,
> I checked out the your GPIO_API branch and tried it out. I had do do a
> couple of things to get it to build:
> 1. On the configure, I had to use --disable-multiprocessing ( I think that
> is the option, I'm going from memory ). I wonder if this is now required
> for non SMP systems?
>
>
> I don't use that option.
>
>
>  2. I had to add the libgpio.h header install in the cpukit/preinstall.am
> file
>
>
> I forgot to push it. It is on github now.
>
>
>  I like the idea of setting up individual peripherals such as the UART,
> JTAG, or I2C with a single call. But, are all CPUs with GPIO configured
> this way? If this configuration is unique the the Pi/Broadcom CPU then it
> may not be applicable as a generic GPIO API.
>
>
> The point was if a certain CPU does not support one of the interfaces it
> would not implement that function, and return some rtems status code to
> signal that. I am also not sure if the right place for it is in the GPIO
> API, but I do like the idea of the API being able to track which pins are
> being used. Maybe a better approach would be to have the peripheral
> functions somewhere else and they would call a function on the GPIO API to
> request pins, so it could still track them.
>
>
>  I wonder if we should just make the GPIO library specific to the
> Raspberry Pi BSP for now, then try to take on the project of creating a
> generic GPIO API for all RTEMS BSPs later. I feel that we need more
> community input to make a generic GPIO API that will not change.
>
>
> Sure.
>
>
>  Thanks,
> Alan
>
>
> On Mon, Jun 16, 2014 at 6:39 PM, Andre Marques <
> andre.lousa.marq...@gmail.com> wrote:
>
>> Hello all,
>>
>> I have been very busy with my undergraduate thesis, but I expect to have
>> more free time by friday. In the meantime, i have added some code to github
>> which implement some of the features I have mentioned on the last blog post.
>>
>> First I added a function on the GPIO API that will alow a BSP that
>> support JTAG interfacing through GPIO to setup and use it. The advantage of
>> doing this through the API is that it tracks which pins are being used,
>> preventing the use of pins that were already setup for something else. It
>> also makes it very easy to the user to setup a JTAG interface (a test case
>> was also created to demonstrate that). This JTAG setup function can also be
>> seen as a proof of concept of the usefulness (or not) of having a function
>> for these sort of interfaces that may be available through GPIO.
>>
>> The JTAG libgpio function is based on alan's JTAG gpio setup program,
>> along with some changes both to that code and to the pin setup function on
>> the API, that can now setup pins to functions other than just input and
>> output (up to 6 alternate "generic" functions, which would be BSP specific).
>>
>> libgpio api ->
>> https://github.com/asuol/rtems/blob/GPIO_API/cpukit/libgpio/libgpio.h
>> libgpio raspberry implementation ->
>> https://github.com/asuol/rtems/blob/GPIO_API/c/src/lib/libbsp/arm/raspberrypi/gpio/libgpio.c
>>
>> libgpio jtag function test case ->
>> https://github.com/asuol/rtems/blob/GPIO_API/testsuites/samples/LIBGPIO_JTAG/init.c
>> alan's jtag program ->
>> https://github.com/alanc98/hello-rtems-jtag/blob/master/test.c
>>
>> Any feedback is well apreciated!
>>
>> Thanks for your time,
>> André Marques.
>>
>
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [GSOC] Project update

[Alan Cudmore]

I agree on (2). Having a generic function to setup an interface seems best.

I think that having a collection of specific interface setup functions such
as rtems_gpio_setup_UART might only be useful for a couple of BSPs.






On Wed, Jun 18, 2014 at 7:00 AM, Andre Marques <
andre.lousa.marq...@gmail.com> wrote:

>  Hello,
>
>
> On 06/18/14 02:21, Alan Cudmore wrote:
>
>  A question about the rtems_gpio_setup_UART functions;
> Could it be implemented with rtems_gpio_set_mb(RPI_PORT,
> RPI_GPIO_UART_MASK) , or would it do additional setup?
>
>   The set function is for digital output pins, which sets a pin value to
> 1. For the interface functions each pin would need to be setup with the
> corresponding funtion (as the JTAG setup does), and not a specific value.
>
> This setup may be done in two ways:
>
> 1 - Using the existing rtems_gpio_setup_pin, which would receive the pin
> number and its function, so if the interface needs to setup 5 pins it would
> call this function 5 times, one for each pin;
>
> 2 - A interface_setup function which would receive a struct with the pins
> and functions. Each BSP could define a structure for each interface it
> suports, so the user would still get a one call setup. In practice for each
> pin defined on the struct this function would call rtems_gpio_setup_pin, so
> this would be a wrapper function.
>
> To me the second options seems the best, as only one function call could
> setup any number of BSP specific GPIO configurations.
>
>
>   If BSP specific mask defines could be used, it would be easier to
> implement, and it would not matter which GPIO peripherals each BSP
> supported.
>
>  Alan
>
>
>
>
>
> On Tue, Jun 17, 2014 at 10:52 AM, Andre Marques <
> andre.lousa.marq...@gmail.com> wrote:
>
>>  On 06/17/14 15:39, Alan Cudmore wrote:
>>
>> Hi Andre,
>> I checked out the your GPIO_API branch and tried it out. I had do do a
>> couple of things to get it to build:
>> 1. On the configure, I had to use --disable-multiprocessing ( I think
>> that is the option, I'm going from memory ). I wonder if this is now
>> required for non SMP systems?
>>
>>
>>  I don't use that option.
>>
>>
>>  2. I had to add the libgpio.h header install in the cpukit/preinstall.am
>> file
>>
>>
>>  I forgot to push it. It is on github now.
>>
>>
>>  I like the idea of setting up individual peripherals such as the UART,
>> JTAG, or I2C with a single call. But, are all CPUs with GPIO configured
>> this way? If this configuration is unique the the Pi/Broadcom CPU then it
>> may not be applicable as a generic GPIO API.
>>
>>
>>  The point was if a certain CPU does not support one of the interfaces it
>> would not implement that function, and return some rtems status code to
>> signal that. I am also not sure if the right place for it is in the GPIO
>> API, but I do like the idea of the API being able to track which pins are
>> being used. Maybe a better approach would be to have the peripheral
>> functions somewhere else and they would call a function on the GPIO API to
>> request pins, so it could still track them.
>>
>>
>>  I wonder if we should just make the GPIO library specific to the
>> Raspberry Pi BSP for now, then try to take on the project of creating a
>> generic GPIO API for all RTEMS BSPs later. I feel that we need more
>> community input to make a generic GPIO API that will not change.
>>
>>
>>  Sure.
>>
>>
>>  Thanks,
>> Alan
>>
>>
>> On Mon, Jun 16, 2014 at 6:39 PM, Andre Marques <
>> andre.lousa.marq...@gmail.com> wrote:
>>
>>> Hello all,
>>>
>>> I have been very busy with my undergraduate thesis, but I expect to have
>>> more free time by friday. In the meantime, i have added some code to github
>>> which implement some of the features I have mentioned on the last blog post.
>>>
>>> First I added a function on the GPIO API that will alow a BSP that
>>> support JTAG interfacing through GPIO to setup and use it. The advantage of
>>> doing this through the API is that it tracks which pins are being used,
>>> preventing the use of pins that were already setup for something else. It
>>> also makes it very easy to the user to setup a JTAG interface (a test case
>>> was also created to demonstrate that). This JTAG setup function can also be
>>> seen as a proof of concept of the usefulness (or not) of having a function
>>> for these sort of interfaces that may be available through GPIO.
>>>
>>> T

Re: [GSOC] GPIO API

[Alan Cudmore]

This looks good to me.. But we welcome feedback from those with more
experience on different processors/BSPs.

Andre, I updated to your latest repository, rebuilt, and ran the GPIO test
with an LED and button. it worked just as described. I'm going to try this
with a couple of extra buttons and LEDs on my setup.  Great job!

Alan



On Sun, Jun 22, 2014 at 11:22 AM, Andre Marques <
andre.lousa.marq...@gmail.com> wrote:

> Hello,
>
> The GPIO API has been updated with doxygen documentation and code
> comments, along with a blog post that explains the current API work flow
> [1], and another blog post explaining how the API can be tested using the
> Raspberry Pi [2], both containing links to the actual code. Currently this
> API is only implemented for the RPi BSP, where it succeds at performing
> digital I/O.
>
> Changes to the API itself are:
>
> - It no longer stores memory addresses, as this is BSP specific;
>
> - Removed the interface setup functions (for UART, SPI, JTAG, ..) and
> replaced with a function that setups any GPIO pin configuration by using a
> struct. A BSP may define a number of specific GPIO interfaces/configuration
> on a header file, to be used by an application.
>
> The current way of using the API is to include the header file, initialize
> the API and call its directives to operate the GPIO pins, which can be used
> directly by an application or through a driver.
>
> Because the GPIO API itself only provides digital I/O directives (as any
> other type of I/O, such as SPI, is BSP specific), doing it directly using
> the API directives or using a digital I/O driver is almost the same, I am
> not sure if the said driver is useful at this point.
>
> For the API to become generic the implementation must go to cpukit too,
> and each BSP should provide low level functions to operate their specific
> hardware. Then a generic digital I/O driver can be created that should work
> with any BSP, as the high level functionality would be in cpukit. Comments
> to this idea are welcome.
>
> [1] - http://asuolgsoc2014.wordpress.com/2014/06/22/the-current-gpio-api/
> [2] - http://asuolgsoc2014.wordpress.com/2014/06/22/testing-the-gpio-api/
>
> --André Marques.
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [GSOC] GPIO status and I2C start

[Alan Cudmore]

Hi André,
I updated my Pi setup to add the second LED and switch, and your example
works for me. I did notice that when I power off the Rapberry Pi, then
power it back on, the second LED will remain lit and cause interrupts in
the RTEMS program. If I leave the Pi powered off for a little while, it
works as intended. I don't think this is an RTEMS problem. The good news is
that the RTEMS app continues to run and handle the interrupts, so it is
stable.

I will experiment with different button and LED combinations in the next
few days.

When you have an I2C driver to try, I have a number of I2C devices to
interface. I will have to find an SPI device to try out. Something like
this:
https://www.adafruit.com/product/1897
Or
https://www.adafruit.com/product/1900

A question about the examples ( maybe not for Andre ):
Can we keep Board/BSP specific tests in the testsuites/samples directory?

Alan


On Sat, Jul 5, 2014 at 6:58 PM, Andre Marques  wrote:

> Hello,
>
> The Raspberry Pi GPIO interrupts are already working, and a test case is
> available to test that [1]. A function is also provided to debounce a
> switch if needed. The test case requires two switches and two LEDS using
> the same setup described at [2] by only changing the pin numbers.
>
> The test works by setting interrupts on both edges of the switches, which
> handlers will turn on or off the corresponding LED. One of the LEDs also
> has a level interrupt which prints a message on the screen when the LED is
> on (high level).
>
> While I wait for some feedback on that, I will be looking at the next
> step: the I2C interface. To test both the I2C and the SPI interfaces I have
> here a simple display [3]. The idea is to create a low level driver for I2C
> to provide the needed directives for the libi2c API, so the driver for the
> display will actually use the libi2c API. Any thoughts here are welcome too!
>
> Thanks,
> André Marques.
>
> [1] - https://github.com/asuol/rtems/blob/GPIO_API/
> testsuites/samples/LIBGPIO_TEST_IQR/init.c
> [2] - http://asuolgsoc2014.wordpress.com/2014/06/22/testing-the-gpio-api/
> [3] - http://www.newhavendisplay.com/nhd0216k3zflgbwv3-p-5738.html
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [GSOC] GPIO status and I2C start

[Alan Cudmore]

On Mon, Jul 7, 2014 at 9:42 AM, Gedare Bloom  wrote:

> On Mon, Jul 7, 2014 at 9:37 AM, Alan Cudmore 
> wrote:
> > Hi André,
> > I updated my Pi setup to add the second LED and switch, and your example
> > works for me. I did notice that when I power off the Rapberry Pi, then
> power
> > it back on, the second LED will remain lit and cause interrupts in the
> RTEMS
> > program. If I leave the Pi powered off for a little while, it works as
> > intended. I don't think this is an RTEMS problem. The good news is that
> the
> > RTEMS app continues to run and handle the interrupts, so it is stable.
> >
> > I will experiment with different button and LED combinations in the next
> few
> > days.
> >
> > When you have an I2C driver to try, I have a number of I2C devices to
> > interface. I will have to find an SPI device to try out. Something like
> > this:
> > https://www.adafruit.com/product/1897
> > Or
> > https://www.adafruit.com/product/1900
> >
> > A question about the examples ( maybe not for Andre ):
> > Can we keep Board/BSP specific tests in the testsuites/samples directory?
> >
> We do not currently have a good location for BSP-specific tests in the
> RTEMS tree. However, we now have a way to specify in a BSP which tests
> it does not work for (test config file), so we could use that
> filtering mechanism to enforce BSP-specific tests. The question then
> is where to put those tests/examples so it is obvious to a user
> whether the code should work for them or not.
>
> -Gedare
>
>
We probably don't want to keep the examples in the RTEMS tree, since they
are so specific to the Raspberry Pi and the peripherals that we connect to
it. I think it will be good enough for the project to end up with a github
repository that has the code to exercise the various I/O interfaces.

Alan



> > Alan
> >
> >
> > On Sat, Jul 5, 2014 at 6:58 PM, Andre Marques
> >  wrote:
> >>
> >> Hello,
> >>
> >> The Raspberry Pi GPIO interrupts are already working, and a test case is
> >> available to test that [1]. A function is also provided to debounce a
> switch
> >> if needed. The test case requires two switches and two LEDS using the
> same
> >> setup described at [2] by only changing the pin numbers.
> >>
> >> The test works by setting interrupts on both edges of the switches,
> which
> >> handlers will turn on or off the corresponding LED. One of the LEDs
> also has
> >> a level interrupt which prints a message on the screen when the LED is
> on
> >> (high level).
> >>
> >> While I wait for some feedback on that, I will be looking at the next
> >> step: the I2C interface. To test both the I2C and the SPI interfaces I
> have
> >> here a simple display [3]. The idea is to create a low level driver for
> I2C
> >> to provide the needed directives for the libi2c API, so the driver for
> the
> >> display will actually use the libi2c API. Any thoughts here are welcome
> too!
> >>
> >> Thanks,
> >> André Marques.
> >>
> >> [1] -
> >>
> https://github.com/asuol/rtems/blob/GPIO_API/testsuites/samples/LIBGPIO_TEST_IQR/init.c
> >> [2] -
> http://asuolgsoc2014.wordpress.com/2014/06/22/testing-the-gpio-api/
> >> [3] - http://www.newhavendisplay.com/nhd0216k3zflgbwv3-p-5738.html
> >
> >
> >
> > ___
> > devel mailing list
> > devel@rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [GSOC] GPIO status and I2C start

[Alan Cudmore]

Hi André,
I have a couple of SPI devices to try now. I have the SPI FRAM chip:
https://www.adafruit.com/product/1897
and something that could be interesting, an SPI based LCD/touchscreen:
https://www.adafruit.com/products/1601

I can also verify that the RTEMS BSP works fine on the new Raspberry Pi
Model B+

Alan



On Sat, Jul 5, 2014 at 6:58 PM, Andre Marques  wrote:

> Hello,
>
> The Raspberry Pi GPIO interrupts are already working, and a test case is
> available to test that [1]. A function is also provided to debounce a
> switch if needed. The test case requires two switches and two LEDS using
> the same setup described at [2] by only changing the pin numbers.
>
> The test works by setting interrupts on both edges of the switches, which
> handlers will turn on or off the corresponding LED. One of the LEDs also
> has a level interrupt which prints a message on the screen when the LED is
> on (high level).
>
> While I wait for some feedback on that, I will be looking at the next
> step: the I2C interface. To test both the I2C and the SPI interfaces I have
> here a simple display [3]. The idea is to create a low level driver for I2C
> to provide the needed directives for the libi2c API, so the driver for the
> display will actually use the libi2c API. Any thoughts here are welcome too!
>
> Thanks,
> André Marques.
>
> [1] - https://github.com/asuol/rtems/blob/GPIO_API/
> testsuites/samples/LIBGPIO_TEST_IQR/init.c
> [2] - http://asuolgsoc2014.wordpress.com/2014/06/22/testing-the-gpio-api/
> [3] - http://www.newhavendisplay.com/nhd0216k3zflgbwv3-p-5738.html
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

RTEMS 5.1 pc686 BSP malloc_info problem?

[Alan Cudmore]

Hi,
I have a problem in RTEMS 5.1 where the pc686 running on QEMU seems to
block or spin when trying to acquire a lock for the malloc_info call.
The CPU utilization goes up to 100 (on the QEMU host) leading me to
think the calling task is spinning waiting on the lock. Tasks with
lower priority than the calling task stop running as well. I also get
this problem when running the "malloc info" shell command.
I don't see this problem with the leon3 BSP built from the same source
tree and executed on QEMU.

Is there an SMP related initialization or perhaps QEMU option I might
be missing? I can run the same code without problems on the RTEMS 4.11
release (same QEMU binary and QEMU options)

Thanks,
Alan
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: RTEMS 5.1 pc686 BSP malloc_info problem?

[Alan Cudmore]

I built the tools shortly after the announced 5.1 release. I'm using
the 5.1 branches for everything.
But some additional info..I built the full testsuite, and ran the
malloctest with no problems. It calls malloc_info a couple of times.

I also compiled my RTEMS Kernel Image (RKI) for this BSP and the
"malloc info" shell command works on that. This is the same way I
tested the sparc/leon3 BSP so at least that is consistent.

This has to come down to a configuration issue for the application
(core flight system pc-rtems test platform)
I'm going to check over the configuration options and compiler options
used. It will most likely be another case of user error, which I
prefer!

Thanks,
Alan

On Mon, Oct 5, 2020 at 11:58 AM Joel Sherrill  wrote:
>
>
>
> On Mon, Oct 5, 2020 at 10:34 AM Gedare Bloom  wrote:
>>
>> This is an SMP related bug?  Can you send the rtems configure command,
>> and the qemu run command?
>>
>> It might also help to know the number of tasks and their priorities.
>> The CONFIGURE* macros might also help.
>>
>> My first guess is that the lock primitive is somehow broken in the
>> pc686, maybe it gets caught in a buggy CAS/TAS loop? It would help if
>> you can narrow down the task spinning to a particular section of code
>> and send the disassembly (or file/line if it is in RTEMS)
>
>
> Hmmm.. When did you build your i386 tools? git says 9/19 for the last change
> but it was very much likely a few days after that when I pushed it.
>
> --joel
>>
>>
>> On Sun, Oct 4, 2020 at 2:06 PM Alan Cudmore  wrote:
>> >
>> > Hi,
>> > I have a problem in RTEMS 5.1 where the pc686 running on QEMU seems to
>> > block or spin when trying to acquire a lock for the malloc_info call.
>> > The CPU utilization goes up to 100 (on the QEMU host) leading me to
>> > think the calling task is spinning waiting on the lock. Tasks with
>> > lower priority than the calling task stop running as well. I also get
>> > this problem when running the "malloc info" shell command.
>> > I don't see this problem with the leon3 BSP built from the same source
>> > tree and executed on QEMU.
>> >
>> > Is there an SMP related initialization or perhaps QEMU option I might
>> > be missing? I can run the same code without problems on the RTEMS 4.11
>> > release (same QEMU binary and QEMU options)
>> >
>> > Thanks,
>> > Alan
>> > ___
>> > devel mailing list
>> > devel@rtems.org
>> > http://lists.rtems.org/mailman/listinfo/devel
>> ___
>> devel mailing list
>> devel@rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: RTEMS 5.1 pc686 BSP malloc_info problem?

[Alan Cudmore]

After doing a lot of tracing through my application, it looks like
malloc_info works fine before we start our cFS application, but it
blocks after the cFS is initialized. This suggests some sort of memory
corruption.
I started by instrumenting our code to call malloc info during various
stages of application initialization, and finally narrowed it down to
the code where we create a RAM Disk and format it with RFS.
(skipping a bunch of other malloc based troubleshooting.. )
After I followed the issue into the RFS init, I was able to narrow
down the place where malloc_info stopped working to here:
https://git.rtems.org/rtems/tree/cpukit/libfs/src/rfs/rtems-rfs-bitmaps.c?h=5#n637
During the RFS format process.
In this section of the code, the size variable is 0, meaning it will
exit the for loop and then return from the function, but it increments
the "search_map" variable and writes to memory through the pointer one
more time before exiting the loop and function. It's at this point
where malloc_info starts blocking.

It seems to me that this if block should be skipped when size == 0. I
tried that and the malloc_info issue seems to be fixed.

Is this an RFS bug writing into other memory, or is this last write
needed before the function updates?

If this looks like a bug, should I write a ticket and provide a patch?

Thanks,
Alan

On Mon, Oct 5, 2020 at 1:06 PM Joel Sherrill  wrote:
>
>
>
> On Mon, Oct 5, 2020 at 11:07 AM Alan Cudmore  wrote:
>>
>> I built the tools shortly after the announced 5.1 release. I'm using
>> the 5.1 branches for everything.
>> But some additional info..I built the full testsuite, and ran the
>> malloctest with no problems. It calls malloc_info a couple of times.
>>
>> I also compiled my RTEMS Kernel Image (RKI) for this BSP and the
>> "malloc info" shell command works on that. This is the same way I
>> tested the sparc/leon3 BSP so at least that is consistent.
>>
>> This has to come down to a configuration issue for the application
>> (core flight system pc-rtems test platform)
>> I'm going to check over the configuration options and compiler options
>> used. It will most likely be another case of user error, which I
>> prefer!
>
>
> This wouldn't be a user error. Just a case where the bug was found
> after the release. :)
>
> --joel
>>
>>
>> Thanks,
>> Alan
>>
>> On Mon, Oct 5, 2020 at 11:58 AM Joel Sherrill  wrote:
>> >
>> >
>> >
>> > On Mon, Oct 5, 2020 at 10:34 AM Gedare Bloom  wrote:
>> >>
>> >> This is an SMP related bug?  Can you send the rtems configure command,
>> >> and the qemu run command?
>> >>
>> >> It might also help to know the number of tasks and their priorities.
>> >> The CONFIGURE* macros might also help.
>> >>
>> >> My first guess is that the lock primitive is somehow broken in the
>> >> pc686, maybe it gets caught in a buggy CAS/TAS loop? It would help if
>> >> you can narrow down the task spinning to a particular section of code
>> >> and send the disassembly (or file/line if it is in RTEMS)
>> >
>> >
>> > Hmmm.. When did you build your i386 tools? git says 9/19 for the last 
>> > change
>> > but it was very much likely a few days after that when I pushed it.
>> >
>> > --joel
>> >>
>> >>
>> >> On Sun, Oct 4, 2020 at 2:06 PM Alan Cudmore  
>> >> wrote:
>> >> >
>> >> > Hi,
>> >> > I have a problem in RTEMS 5.1 where the pc686 running on QEMU seems to
>> >> > block or spin when trying to acquire a lock for the malloc_info call.
>> >> > The CPU utilization goes up to 100 (on the QEMU host) leading me to
>> >> > think the calling task is spinning waiting on the lock. Tasks with
>> >> > lower priority than the calling task stop running as well. I also get
>> >> > this problem when running the "malloc info" shell command.
>> >> > I don't see this problem with the leon3 BSP built from the same source
>> >> > tree and executed on QEMU.
>> >> >
>> >> > Is there an SMP related initialization or perhaps QEMU option I might
>> >> > be missing? I can run the same code without problems on the RTEMS 4.11
>> >> > release (same QEMU binary and QEMU options)
>> >> >
>> >> > Thanks,
>> >> > Alan
>> >> > ___
>> >> > devel mailing list
>> >> > devel@rtems.org
>> >> > http://lists.rtems.org/mailman/listinfo/devel
>> >> ___
>> >> devel mailing list
>> >> devel@rtems.org
>> >> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: RTEMS 5.1 pc686 BSP malloc_info problem?

[Alan Cudmore]

Hi Chris,
I'm not sure that I can easily create a test to show that this
condition exists. I think the rtems_rfs_bitmap_create_search function
works as it is intended to, but during the last iteration of the for
loop, if 'size' is zero and 'bit' is 31, the 'search_map' variable is
incremented once more, and the value of RTEMS_RFS_BITMAP_ELEMENT_CLEAR
(0x) is written to that location. This location is one address
beyond the memory that was allocated for the search_map in
rtems_rfs_bitmap_open.
I guess that most of the time this is a silent side effect, but my
application just happened to have memory lined up such that the extra
write causes the malloc Allocator mutex to fail, causing the
malloc_info call to block indefinitely. I would consider this a lucky
break!
The exact same example application does not fail on RTEMS 4.11. I
think the problem still exists, but in that case, the word that gets
written is different.

Here are some debug printfs from rtems_rfs_bitmap_open and
rtems_rfs_bitmap_create_search:

>From rtems_rfs_bitmap_open:
RFS - rtems_rfs_bitmap_open - search_bits malloced size = 16 bytes
RFS - rtems_rfs_bitmap_open - addr of search_bits = 0x00C03814
RFS -> size of search_map = 4
RFS -> control->size = 4095

>From the subsequent call to rtems_rfs_bitmap_create_search:
These printfs are in the if clause where bit == 31 (line 633)
RFS --> search_map before increment addr 00C03814, size = 3071
RFS --> search_map after increment -> writing
RTEMS_RFS_BITMAP_ELEMENT_CLEAR (-1) to addr 00C03818
RFS --> search_map before increment addr 00C03818, size = 2047
RFS --> search_map after increment -> writing
RTEMS_RFS_BITMAP_ELEMENT_CLEAR (-1) to addr 00C0381C
RFS --> search_map before increment addr 00C0381C, size = 1023
RFS --> search_map after increment -> writing
RTEMS_RFS_BITMAP_ELEMENT_CLEAR (-1) to addr 00C03820
RFS --> search_map before increment addr 00C03820, size = 0
RFS --> search_map after increment -> writing
RTEMS_RFS_BITMAP_ELEMENT_CLEAR (-1) to addr 00C03824

It's this last write to 00C03824 that causes the problem. I think the
fix just involves checking to see if size == 0 before executing the if
clause. I wanted to be sure that this extra write was not needed.

If you have an idea for a test case, I can work on it, but if you
think that this is good enough, I can propose a patch.

Also, thanks for the idea of using RTEMS_DEBUG Sebastian, I need to
upgrade my RTEMS toolbox with the latest techniques.

Alan


On Sun, Oct 11, 2020 at 6:20 PM Chris Johns  wrote:
>
> On 10/10/20 7:35 am, Alan Cudmore wrote:
> > After doing a lot of tracing through my application, it looks like
> > malloc_info works fine before we start our cFS application, but it
> > blocks after the cFS is initialized. This suggests some sort of memory
> > corruption.
> > I started by instrumenting our code to call malloc info during various
> > stages of application initialization, and finally narrowed it down to
> > the code where we create a RAM Disk and format it with RFS.
> > (skipping a bunch of other malloc based troubleshooting.. )
> > After I followed the issue into the RFS init, I was able to narrow
> > down the place where malloc_info stopped working to here:
> > https://git.rtems.org/rtems/tree/cpukit/libfs/src/rfs/rtems-rfs-bitmaps.c?h=5#n637
> > During the RFS format process.
> > In this section of the code, the size variable is 0, meaning it will
> > exit the for loop and then return from the function, but it increments
> > the "search_map" variable and writes to memory through the pointer one
> > more time before exiting the loop and function. It's at this point
> > where malloc_info starts blocking.
> >
> > It seems to me that this if block should be skipped when size == 0. I
> > tried that and the malloc_info issue seems to be fixed.
>
> Would you be able to create a test case for this? The test is ..
>
> https://git.rtems.org/rtems/tree/testsuites/fstests/fsrfsbitmap01/test.c
>
> Or if you could please provide the values in `control` I can add the test.
>
> > Is this an RFS bug writing into other memory, or is this last write
> > needed before the function updates?
>
> It would seem so.
>
> > If this looks like a bug, should I write a ticket and provide a patch?
>
> Yes please. It would be nice to have a test case that fails so we can isolate
> the cause.
>
> Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: RTEMS 5.1 pc686 BSP malloc_info problem?

[Alan Cudmore]

Thanks for all of the help, and thanks for the patch Chris! I was
hoping to submit a patch this weekend, so you just gave me back some
time :)
Alan

On Thu, Oct 15, 2020 at 2:08 AM Chris Johns  wrote:
>
> On 13/10/20 4:13 am, Joel Sherrill wrote:
> > On Mon, Oct 12, 2020 at 11:15 AM Alan Cudmore  > <mailto:alan.cudm...@gmail.com>> wrote:
> >
> > Hi Chris,
> > I'm not sure that I can easily create a test to show that this
> > condition exists. I think the rtems_rfs_bitmap_create_search function
> > works as it is intended to, but during the last iteration of the for
> > loop, if 'size' is zero and 'bit' is 31, the 'search_map' variable is
> > incremented once more, and the value of RTEMS_RFS_BITMAP_ELEMENT_CLEAR
> > (0x) is written to that location. This location is one address
> > beyond the memory that was allocated for the search_map in
> > rtems_rfs_bitmap_open.
> > I guess that most of the time this is a silent side effect, but my
> > application just happened to have memory lined up such that the extra
> > write causes the malloc Allocator mutex to fail, causing the
> > malloc_info call to block indefinitely. I would consider this a lucky
> > break!
> > The exact same example application does not fail on RTEMS 4.11. I
> > think the problem still exists, but in that case, the word that gets
> > written is different.
> >
> > Here are some debug printfs from rtems_rfs_bitmap_open and
> > rtems_rfs_bitmap_create_search:
> >
> > From rtems_rfs_bitmap_open:
> > RFS - rtems_rfs_bitmap_open - search_bits malloced size = 16 bytes
> > RFS - rtems_rfs_bitmap_open - addr of search_bits = 0x00C03814
> > RFS -> size of search_map = 4
> > RFS -> control->size = 4095
> >
> > From the subsequent call to rtems_rfs_bitmap_create_search:
> > These printfs are in the if clause where bit == 31 (line 633)
> > RFS --> search_map before increment addr 00C03814, size = 3071
> > RFS --> search_map after increment -> writing
> > RTEMS_RFS_BITMAP_ELEMENT_CLEAR (-1) to addr 00C03818
> > RFS --> search_map before increment addr 00C03818, size = 2047
> > RFS --> search_map after increment -> writing
> > RTEMS_RFS_BITMAP_ELEMENT_CLEAR (-1) to addr 00C0381C
> > RFS --> search_map before increment addr 00C0381C, size = 1023
> > RFS --> search_map after increment -> writing
> > RTEMS_RFS_BITMAP_ELEMENT_CLEAR (-1) to addr 00C03820
> > RFS --> search_map before increment addr 00C03820, size = 0
> > RFS --> search_map after increment -> writing
> > RTEMS_RFS_BITMAP_ELEMENT_CLEAR (-1) to addr 00C03824
> >
> > It's this last write to 00C03824 that causes the problem. I think the
> > fix just involves checking to see if size == 0 before executing the if
> > clause. I wanted to be sure that this extra write was not needed.
> >
> > If you have an idea for a test case, I can work on it, but if you
> > think that this is good enough, I can propose a patch.
> >
> > Also, thanks for the idea of using RTEMS_DEBUG Sebastian, I need to
> > upgrade my RTEMS toolbox with the latest techniques.
> >
> >
> > If, while analysing this issues, you came up with any consistency checks
> > or assertions that can be added to the code when debug is enabled,
> > those would be welcomed. It is hard to go back and add them without
> > the analysis like you did hunting this bug.
>
> I have added an _Assert (thanks Sebastian) and I now see:
>
> *** BEGIN OF TEST FSRFSBITMAP 1 ***
>
> *** TEST VERSION: 6.0.0.df9cc1aee87da6c6ba41d52454fa5f45fba74501
>
> *** TEST STATE: EXPECTED_PASS
>
> *** TEST BUILD: RTEMS_DEBUG
>
> *** TEST TOOLS: 10.2.1 20200918 (RTEMS 6, RSB
> ed5030bc24dbfdfac52074ed78cf4231bf1f353d, Newlib 749cbcc)
> Initializing filesystem RFS
>
> assertion "search_map >= control->search_bits && search_map <
> (control->search_bits +
> rtems_rfs_bitmap_elements(rtems_rfs_bitmap_elements(control->size)))" failed:
> file "../../../cpukit/libfs/src/rfs/rtems-rfs-bitmaps.c", line 648, function:
> rtems_rfs_bitmap_create_search
>
>
>
> I have a patch to fix this I will post.
>
> Thank you Alan for the report and the analysis. It made my job nice and 
> simple.
>
> Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: RTEMS 5.1 pc686 BSP malloc_info problem?

[Alan Cudmore]

On Thu, Oct 15, 2020 at 11:19 AM Gedare Bloom  wrote:
>
> On Thu, Oct 15, 2020 at 6:35 AM Joel Sherrill  wrote:
> >
> >
> >
> > On Thu, Oct 15, 2020, 7:15 AM Alan Cudmore  wrote:
> >>
> >> Thanks for all of the help, and thanks for the patch Chris! I was
> >> hoping to submit a patch this weekend, so you just gave me back some
> >> time :)
> >
> >
> > Glad you found this!
> >
> > The RFS was new in 4.10 as I recall. You guys have missions using this. Do 
> > you need to locally fix this?

We have one active mission that uses it. I will be worth trying to
determine what word of memory is affected before trying to fix it,
since it has been operating normally for 5.5 years with the issue.

> >
> > It also needs to be fixed in 4.11.
> >
> > For posterity, if a fix is needed for 4.10, should we push it even though 
> > we have no plans for a future release from that branch? Just asking since a 
> > small number of other patches have been pushed to that branch.
> >
> Yes.
>
> >
> >
> >> Alan
> >>
> >> On Thu, Oct 15, 2020 at 2:08 AM Chris Johns  wrote:
> >> >
> >> > On 13/10/20 4:13 am, Joel Sherrill wrote:
> >> > > On Mon, Oct 12, 2020 at 11:15 AM Alan Cudmore  >> > > <mailto:alan.cudm...@gmail.com>> wrote:
> >> > >
> >> > > Hi Chris,
> >> > > I'm not sure that I can easily create a test to show that this
> >> > > condition exists. I think the rtems_rfs_bitmap_create_search 
> >> > > function
> >> > > works as it is intended to, but during the last iteration of the 
> >> > > for
> >> > > loop, if 'size' is zero and 'bit' is 31, the 'search_map' variable 
> >> > > is
> >> > > incremented once more, and the value of 
> >> > > RTEMS_RFS_BITMAP_ELEMENT_CLEAR
> >> > > (0x) is written to that location. This location is one 
> >> > > address
> >> > > beyond the memory that was allocated for the search_map in
> >> > > rtems_rfs_bitmap_open.
> >> > > I guess that most of the time this is a silent side effect, but my
> >> > > application just happened to have memory lined up such that the 
> >> > > extra
> >> > > write causes the malloc Allocator mutex to fail, causing the
> >> > > malloc_info call to block indefinitely. I would consider this a 
> >> > > lucky
> >> > > break!
> >> > > The exact same example application does not fail on RTEMS 4.11. I
> >> > > think the problem still exists, but in that case, the word that 
> >> > > gets
> >> > > written is different.
> >> > >
> >> > > Here are some debug printfs from rtems_rfs_bitmap_open and
> >> > > rtems_rfs_bitmap_create_search:
> >> > >
> >> > > From rtems_rfs_bitmap_open:
> >> > > RFS - rtems_rfs_bitmap_open - search_bits malloced size = 16 bytes
> >> > > RFS - rtems_rfs_bitmap_open - addr of search_bits = 0x00C03814
> >> > > RFS -> size of search_map = 4
> >> > > RFS -> control->size = 4095
> >> > >
> >> > > From the subsequent call to rtems_rfs_bitmap_create_search:
> >> > > These printfs are in the if clause where bit == 31 (line 633)
> >> > > RFS --> search_map before increment addr 00C03814, size = 3071
> >> > > RFS --> search_map after increment -> writing
> >> > > RTEMS_RFS_BITMAP_ELEMENT_CLEAR (-1) to addr 00C03818
> >> > > RFS --> search_map before increment addr 00C03818, size = 2047
> >> > > RFS --> search_map after increment -> writing
> >> > > RTEMS_RFS_BITMAP_ELEMENT_CLEAR (-1) to addr 00C0381C
> >> > > RFS --> search_map before increment addr 00C0381C, size = 1023
> >> > > RFS --> search_map after increment -> writing
> >> > > RTEMS_RFS_BITMAP_ELEMENT_CLEAR (-1) to addr 00C03820
> >> > > RFS --> search_map before increment addr 00C03820, size = 0
> >> > > RFS --> search_map after increment -> writing
> >> > > RTEMS_RFS_BITMAP_ELEMENT_CLEAR (-1) to addr 00C03824
> >> > >
> >> > > It's this l

Re: RTEMS 5.1 pc686 BSP malloc_info problem?

[Alan Cudmore]

On Thu, Oct 15, 2020 at 3:03 PM Chris Johns  wrote:
>
> On 16/10/20 5:22 am, Alan Cudmore wrote:
> > On Thu, Oct 15, 2020 at 11:19 AM Gedare Bloom  wrote:
> >>
> >> On Thu, Oct 15, 2020 at 6:35 AM Joel Sherrill  wrote:
> >>>
> >>>
> >>>
> >>> On Thu, Oct 15, 2020, 7:15 AM Alan Cudmore  wrote:
> >>>>
> >>>> Thanks for all of the help, and thanks for the patch Chris! I was
> >>>> hoping to submit a patch this weekend, so you just gave me back some
> >>>> time :)
> >>>
> >>>
> >>> Glad you found this!
> >>>
> >>> The RFS was new in 4.10 as I recall. You guys have missions using this. 
> >>> Do you need to locally fix this?
> >
> > We have one active mission that uses it. I will be worth trying to
> > determine what word of memory is affected before trying to fix it,
> > since it has been operating normally for 5.5 years with the issue.
> >
>
> The number of bits needs to align to a value that fits the whole 32 bit mask 
> so
> the last is used to trigger the bug.

How can I calculate this? It would be great if I could tell known
users that they don't need to worry about it.
For example, in the open source cFS bundle where I encountered the
issue, it creates an RFS formatted RAM disk that is 0x20 bytes in
size (2 Mbytes). I would imagine that is a nice round number of bitmap
elements.

Thanks,
Alan

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

Re: GSoC'21 Raspberry Pi BSP project

[Alan Cudmore]

Hi,
I can try to give you some background, hopefully others will correct
me if I don't get everything right.

You are correct that the BSP just covers the original Pi1 and Pi Zero
(not Pi Zero W) models + the Pi 2. I don't think the I2C and GPIO
interfaces were ported to the Pi2. At some point, I think SMP was
working on the Pi2, but it did not work the last time I tried it.

In addition, the Pi 2 that I have is a BCM2386 (Quad A7) but the
current ones (if you can find one) have a BCM2387 (Quad A53, similar
to the Pi 3). Is the BCM2386 the same as the BCM2387? I did not think
they were.

I looked over the ticket, and much of the 2017 items still apply.. but
maybe this would be the place for the community to help prioritize
what should be done. Here are my thoughts:

1. What Pi Models should we support?

The Pi Zero continues to be a good choice, because it works, the base
model is still available, and is only $5 USD. The Pi Zero W (Bluetooth
and Wifi model) could be supported, but it requires a different
console UART, since the one used by the existing RTEMS BSP is used for
the Bluetooth module. (same applies to the Pi3). The original Pi B/B+,
A+, etc models with the single core BCM2835 should continue to work as
long as the Pi Zero does.

Pi 2: It probably would not take too much to revive this BSP and get
SMP working. But we have the problem of two different SoCs. If you buy
a new Pi 2, it will have a lower clocked BCM2837 like the Pi3 (but
without the extra Bluetooth/Wifi module). It may be hard to locate one
with the older BCM2836 Quad A7. We would have to be careful to specify
what revision of the Pi 2. I would deprecate it in favor of adding Pi
3 support.

Pi 3: This would be a nice model to support. It may not take too much
to get the generic 32 bit ARM build working on it ( like we originally
did with the Pi 2), but like the Pi Zero W, we would have to
reconfigure the RTEMS console to use the secondary UART. AArch64 SMP
support on the Pi 3 would be great in my opinion.

Pi 4: I have not even thought of this one yet. It's a different SoC
(BCM2711, Quad A72). It is the current model, and it looks like the
RPI foundation is targeting industrial use with the Compute Modules.

All models will be in production until at least 2026, the Pi 4 compute
modules until at least 2028.

My vote: keep Pi 0/1 support, add Pi Zero W support by fixing the
console UART. Drop the Pi 2 support, and put the effort into making
the Pi 3 work instead. Pi 2 users, please let me know if I'm wrong
here!

2. What peripherals should we support?
The basics are always a good place to start. Make sure we have
consistent SPI, I2C, GPIO, and support for both UARTs (important for
the Pi Zero W and PI3)
For the SD card, Ethernet, Wifi and Bluetooth, we should probably
follow the Beaglebone and Zynq path by using Libbsd.
The BeagleBone Black has become the more useful low cost RTEMS board
to me because of it's libbsd support for ethernet, USB, and the SD
card.

3. Are graphics important to users? For me, it's not that important, I
would rather have good SPI, I2C, and network support.

I have a couple of use cases that would be covered by this work:
- Pi Zero - this is one of the lowest cost boards available that can
run RTEMS ($5 USD). Although it does not have networking, with good
I2C, GPIO, and SPI support it can support a lot of applications.
- Pi 3 - A low cost SMP system with libbsd networking support would be
a replacement for the BeagleBone Black for my cFS development.

Here is what I think would make a good plan for the Raspberry Pi BSPs:
- Make sure the BSP works on the Pi Zero, fixing SPI, I2C, and GPIO if
necessary.
- Fix the RTEMS console/uart driver for the Pi Zero W, so the same BSP
will work on the Zero with proper configuration
- Deprecate the RPI 2 BSP (unless the community has a case to keep it,
I only have one of these, and it has not been used in years)
- Add RPI 3 32 bit support (needs same console fix as the RPI Zero 0
and most likely different interrupt and I2C, SPI, GPI support)
Bonus work
- Libbsd support for RPI 3, especially the ethernet
- Aarch64 support for RPI 3
Longer term work
RPI 4 and RPI 4 compute module support.

Sorry for the long post, and I hope this helps!
Alan






On Mon, Apr 5, 2021 at 4:00 PM Pranav Dangi  wrote:
>
> I've been going through the RTEMS raspberry pi repository, And i'm having 
> trouble understanding a couple of things there. the Pi1 (and Pi Zero) had the 
> BCM2835 SoC while the pi2 had the BCM2836 SoC, now, in the bsp directory 
> where the raspberry pi header is defined, the header file has register 
> definitions for both BCM2835 (for GPIO, I2C, etc.) and BCM2836 (for the 4 
> cores).
> However, the corresponding i2c.c or gpio.c files for the bsp only have code 
> for the BCM2835_REG registers and not their BCM2836 i.e. the raspberry pi2 
> counterparts.
> So, is the support for pi2 same as that of pi1 (selecting the particular bsp 
> doesn't make sense then) or am I missin

RE: [PATCH] bsps/raspberrypi/console: Fix default console device

[Alan Cudmore]

Hi Niteesh,I was hoping to try this out as soon as I get some time. No later than weekend. So if nobody else is able to check it out, I will be able to provide some feedback soon.I should be able to bring up the console on a RPi Zero W and RPi3, correct? Thanks,Alan From: Niteesh G. S.Sent: Thursday, May 6, 2021 4:29 AMTo: Joel Sherrill; Christian MaudererCc: rtems-de...@rtems.orgSubject: Re: [PATCH] bsps/raspberrypi/console: Fix default console device ping. On Sat, May 1, 2021 at 9:47 PM Niteesh G. S.  wrote:On Sat, May 1, 2021 at 8:31 PM Joel Sherrill  wrote: On Sat, May 1, 2021, 8:53 AM Niteesh G. S.  wrote:Just to provide more context,When the CONFIGURE_APPLICATION_NEEDS_CONSOLE_DRIVER option is usedand no --console option is provided, the console driver defaults to PL011.In raspberry pi 3 and other models whose primary UART is not PL011, we get no output.This patch fixes that by linking the primary UART to the console device. Thanks,Niteesh On Sat, May 1, 2021 at 7:05 PM G S Niteesh Babu  wrote:When no console argument is given, the driver defaults to pl011this results in no output in case of Rpi3 whose primary uart isminiuart.This patch fixes that by defaulting to the primary uart when noconsole option is provided. Does the default need to vary by model?Yes, the primary UART is different across models. Rpi's have two UARTs PL011 and miniuart, on models which have Bluetooththe PL011 is used to talk to the Bluetooth and miniuart acts as the primary UART.Now we can change this by adding miniuart-bt to config.txt but the miniuart isbased on the VPU core and requires to add another option which sets the core toa fixed freq. --- bsps/arm/raspberrypi/console/console-config.c | 12 +--- 1 file changed, 9 insertions(+), 3 deletions(-)diff --git a/bsps/arm/raspberrypi/console/console-config.c b/bsps/arm/raspberrypi/console/console-config.cindex 6b8eb80aa4..bd3a8d34c2 100644--- a/bsps/arm/raspberrypi/console/console-config.c+++ b/bsps/arm/raspberrypi/console/console-config.c@@ -165,10 +165,16 @@ static void console_select( void )     }   }else {     /**-     * If no command line option was given, default to PL011.+     * If no console option was given we default to the primary uarts.+     * The initialization of the uart's and BSP_output_char is already done+     * in the uart_probe function called before this. So now we can safely+     * compare BSP_output_char.      */-    BSP_output_char = output_char_pl011;-    link(PL011, CONSOLE_DEVICE_NAME);+    if (BSP_output_char == output_char_pl011) {+      link(PL011, CONSOLE_DEVICE_NAME);+    }else {+      link(MINIUART, CONSOLE_DEVICE_NAME);+    }   } }-- 2.17.1___devel mailing listdevel@rtems.orghttp://lists.rtems.org/mailman/listinfo/devel 
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] bsps/raspberrypi/console: Fix default console device

[Alan Cudmore]

Hi Niteesh,
I was able to build the current RTEMS master (raspberrypi BSP) and I
was also able to successfully apply your patch and rebuild.
However, I am having trouble getting RTEMS running on the Raspberry Pis I have.
I tried it with and without the patch and I cannot get it to work. I
tried a Raspberry Pi Zero, B+, and Zero W ( with the patch).
I used these instructions for the firmware on SD card:
https://docs.rtems.org/branches/master/user/bsps/bsps-arm.html#raspberrypi

I tried:
- RTEMS master "arm/raspberrypi" BSP with and without the patch
- RTEMS 5 branch "arm/raspberrypi" BSP
- latest version of the RPI firmware files
- an older version of the RPI firmware (from June 2016)
I used the config.txt file that is recommended, but I did not have any
command line options. I did not have my raspberry Pis connected to
HDMI, only serial.

Can you describe your setup?
I know I have been through this before.

Thanks,
Alan

On Thu, May 6, 2021 at 10:48 AM Niteesh G. S.  wrote:
>
> Hi Alan,
>
> On Thu, May 6, 2021 at 6:12 PM Alan Cudmore  wrote:
>>
>> Hi Niteesh,
>>
>> I was hoping to try this out as soon as I get some time. No later than 
>> weekend. So if nobody else is able to check it out, I will be able to 
>> provide some feedback soon.
>>
>> I should be able to bring up the console on a RPi Zero W and RPi3, correct?
>
> the consoles should work on Zero W and Pi3 by default. They only fail to work 
> when  CONFIGURE_APPLICATION_NEEDS_CONSOLE_DRIVER
> this option is used. This is because when that option is used it calls 
> console_initialize which checks if any boot options were present if none were
> given it defaults to pl011 which is the secondary UART in Zero w and Pi3 so 
> we get no output. This patch defaults to the primary UART instead of
> pl011 depending on the board.
> Also, this patch should be applied on RTEMS 5 since we started supporting Pi3 
> and Zero w from RTEMS 5.
>
> Thanks,
> Niteesh.
>
>
>>
>> Thanks,
>>
>> Alan
>>
>>
>>
>> From: Niteesh G. S.
>> Sent: Thursday, May 6, 2021 4:29 AM
>> To: Joel Sherrill; Christian Mauderer
>> Cc: rtems-de...@rtems.org
>> Subject: Re: [PATCH] bsps/raspberrypi/console: Fix default console device
>>
>>
>>
>> ping.
>>
>>
>>
>> On Sat, May 1, 2021 at 9:47 PM Niteesh G. S.  wrote:
>>
>> On Sat, May 1, 2021 at 8:31 PM Joel Sherrill  wrote:
>>
>>
>>
>> On Sat, May 1, 2021, 8:53 AM Niteesh G. S.  wrote:
>>
>> Just to provide more context,
>>
>> When the CONFIGURE_APPLICATION_NEEDS_CONSOLE_DRIVER option is used
>>
>> and no --console option is provided, the console driver defaults to PL011.
>>
>> In raspberry pi 3 and other models whose primary UART is not PL011, we get 
>> no output.
>>
>> This patch fixes that by linking the primary UART to the console device.
>>
>>
>>
>> Thanks,
>>
>> Niteesh
>>
>>
>>
>> On Sat, May 1, 2021 at 7:05 PM G S Niteesh Babu  wrote:
>>
>> When no console argument is given, the driver defaults to pl011
>> this results in no output in case of Rpi3 whose primary uart is
>> miniuart.
>> This patch fixes that by defaulting to the primary uart when no
>> console option is provided.
>>
>>
>>
>> Does the default need to vary by model?
>>
>> Yes, the primary UART is different across models.
>>
>>
>>
>> Rpi's have two UARTs PL011 and miniuart, on models which have Bluetooth
>>
>> the PL011 is used to talk to the Bluetooth and miniuart acts as the primary 
>> UART.
>>
>> Now we can change this by adding miniuart-bt to config.txt but the miniuart 
>> is
>>
>> based on the VPU core and requires to add another option which sets the core 
>> to
>>
>> a fixed freq.
>>
>>
>>
>> ---
>>  bsps/arm/raspberrypi/console/console-config.c | 12 +---
>>  1 file changed, 9 insertions(+), 3 deletions(-)
>>
>> diff --git a/bsps/arm/raspberrypi/console/console-config.c 
>> b/bsps/arm/raspberrypi/console/console-config.c
>> index 6b8eb80aa4..bd3a8d34c2 100644
>> --- a/bsps/arm/raspberrypi/console/console-config.c
>> +++ b/bsps/arm/raspberrypi/console/console-config.c
>> @@ -165,10 +165,16 @@ static void console_select( void )
>>  }
>>}else {
>>  /**
>> - * If no command line option was given, default to PL011.
>> + * If no console option was given we default to the primary uarts.
>> + * The initialization of the uart's and BSP_output_char is

Re: [PATCH] bsps/raspberrypi/console: Fix default console device

[Alan Cudmore]

Hi Niteesh,
I tried your firmware, booting directly instead of using u-boot. I was
able to get the RTEMS 5 branch to run on the Raspberry Pi Zero, but I
still cannot get the master/6 branch to run. I need some time to do
additional tests. I was also going to re-try your patch and see if I
can run the master branch and your firmware with the Pi 3.

Our GSOC student just started a RPi improvement project, so I think
the first step should be to sort all of this out.
I'm pretty busy right now, but I'll see if I can continue testing in
the next few days. I want to try loading from u-boot next.

Alan


On Thu, May 20, 2021 at 12:52 AM Niteesh G. S.  wrote:
>
> ping.
>
> On Tue, May 11, 2021 at 1:09 AM Niteesh G. S.  wrote:
>>
>> Hello Gedare,
>>
>> On Mon, May 10, 2021 at 8:57 PM Gedare Bloom  wrote:
>>>
>>> On Thu, May 6, 2021 at 8:49 AM Niteesh G. S.  wrote:
>>> >
>>> > Hi Alan,
>>> >
>>> > On Thu, May 6, 2021 at 6:12 PM Alan Cudmore  
>>> > wrote:
>>> >>
>>> >> Hi Niteesh,
>>> >>
>>> >> I was hoping to try this out as soon as I get some time. No later than 
>>> >> weekend. So if nobody else is able to check it out, I will be able to 
>>> >> provide some feedback soon.
>>> >>
>>> >> I should be able to bring up the console on a RPi Zero W and RPi3, 
>>> >> correct?
>>> >
>>> > the consoles should work on Zero W and Pi3 by default. They only fail to 
>>> > work when  CONFIGURE_APPLICATION_NEEDS_CONSOLE_DRIVER
>>> > this option is used. This is because when that option is used it calls 
>>> > console_initialize which checks if any boot options were present if none 
>>> > were
>>> > given it defaults to pl011 which is the secondary UART in Zero w and Pi3 
>>> > so we get no output. This patch defaults to the primary UART instead of
>>> > pl011 depending on the board.
>>> > Also, this patch should be applied on RTEMS 5 since we started supporting 
>>> > Pi3 and Zero w from RTEMS 5.
>>> >
>>> You'll need to provide a separate patch with a ticket to close on 5
>>> for a backport. Wait until you get the approval for the master branch
>>> though.
>>
>> OK. I'll create a ticket and request for a backport once this is pushed on
>> to the current master
>>
>> Thanks,
>> Niteesh.
>>>
>>>
>>> > Thanks,
>>> > Niteesh.
>>> >
>>> >
>>> >>
>>> >> Thanks,
>>> >>
>>> >> Alan
>>> >>
>>> >>
>>> >>
>>> >> From: Niteesh G. S.
>>> >> Sent: Thursday, May 6, 2021 4:29 AM
>>> >> To: Joel Sherrill; Christian Mauderer
>>> >> Cc: rtems-de...@rtems.org
>>> >> Subject: Re: [PATCH] bsps/raspberrypi/console: Fix default console device
>>> >>
>>> >>
>>> >>
>>> >> ping.
>>> >>
>>> >>
>>> >>
>>> >> On Sat, May 1, 2021 at 9:47 PM Niteesh G. S.  
>>> >> wrote:
>>> >>
>>> >> On Sat, May 1, 2021 at 8:31 PM Joel Sherrill  wrote:
>>> >>
>>> >>
>>> >>
>>> >> On Sat, May 1, 2021, 8:53 AM Niteesh G. S.  wrote:
>>> >>
>>> >> Just to provide more context,
>>> >>
>>> >> When the CONFIGURE_APPLICATION_NEEDS_CONSOLE_DRIVER option is used
>>> >>
>>> >> and no --console option is provided, the console driver defaults to 
>>> >> PL011.
>>> >>
>>> >> In raspberry pi 3 and other models whose primary UART is not PL011, we 
>>> >> get no output.
>>> >>
>>> >> This patch fixes that by linking the primary UART to the console device.
>>> >>
>>> >>
>>> >>
>>> >> Thanks,
>>> >>
>>> >> Niteesh
>>> >>
>>> >>
>>> >>
>>> >> On Sat, May 1, 2021 at 7:05 PM G S Niteesh Babu  
>>> >> wrote:
>>> >>
>>> >> When no console argument is given, the driver defaults to pl011
>>> >> this results in no output in case of Rpi3 whose primary uart is
>>> >> miniuart.
>>> >> This patch fixes that by defaulting to the primary uart when no
>>> 

Re: [PATCH] bsps/raspberrypi/console: Fix default console device

[Alan Cudmore]

Hi Niteesh,
Here are my latest tests:
- Using your firmware and the rtems.img in your firmware repo, I can
see that it runs on my Raspberry Pi 3. The hello example reports RTEMS
5.1. Was this from the 5 branch?
- The same image does not seem to boot on the Raspberry Pi 1 modules,
but I think that's because I need to add the command line option. What
file should I add that in, and what command line option I should use?

With the code I build:
- I can get your patch to apply on the master/6 branch, and it builds
OK, but I cannot get the raspberrypi BSP to run on any of my boards
yet (with or without your patch and firmware)
-  I can run the unmodified RTEMS 5 branch raspberry pi BSP on all of
the single core models I have (using your firmware). Interestingly,
the samples run on the Raspberry Pi Zero W (with wireless and
bluetooth) without a patch. I thought the Zero W would have the same
console problem as the RPI 3.
- I applied your patch to my RTEMS 5 branch (had to change the include
path for arm-pl011.h). It runs the same on the single core models
without the patch, and the console does not come up on the Pi 3 like
it does with your rtems.img. Is there something else that needs to be
done in RTEMS 5 to default to the pl011 uart?

All of my tests are not using u-boot.

What should be next?
- I can try the rest of my Raspberry Pi single core models with your
firmware and rtems.img, once I know the command line option I need.
- After that, maybe we should figure out how to configure the console
with your patch on the RTEMS 5 branch.
- Finally, we need to figure out how to get the master/6 branch working again.

Thanks!
Alan

On Thu, May 20, 2021 at 7:41 AM Alan Cudmore  wrote:
>
> Hi Niteesh,
> I tried your firmware, booting directly instead of using u-boot. I was
> able to get the RTEMS 5 branch to run on the Raspberry Pi Zero, but I
> still cannot get the master/6 branch to run. I need some time to do
> additional tests. I was also going to re-try your patch and see if I
> can run the master branch and your firmware with the Pi 3.
>
> Our GSOC student just started a RPi improvement project, so I think
> the first step should be to sort all of this out.
> I'm pretty busy right now, but I'll see if I can continue testing in
> the next few days. I want to try loading from u-boot next.
>
> Alan
>
>
> On Thu, May 20, 2021 at 12:52 AM Niteesh G. S.  wrote:
> >
> > ping.
> >
> > On Tue, May 11, 2021 at 1:09 AM Niteesh G. S.  wrote:
> >>
> >> Hello Gedare,
> >>
> >> On Mon, May 10, 2021 at 8:57 PM Gedare Bloom  wrote:
> >>>
> >>> On Thu, May 6, 2021 at 8:49 AM Niteesh G. S.  wrote:
> >>> >
> >>> > Hi Alan,
> >>> >
> >>> > On Thu, May 6, 2021 at 6:12 PM Alan Cudmore  
> >>> > wrote:
> >>> >>
> >>> >> Hi Niteesh,
> >>> >>
> >>> >> I was hoping to try this out as soon as I get some time. No later than 
> >>> >> weekend. So if nobody else is able to check it out, I will be able to 
> >>> >> provide some feedback soon.
> >>> >>
> >>> >> I should be able to bring up the console on a RPi Zero W and RPi3, 
> >>> >> correct?
> >>> >
> >>> > the consoles should work on Zero W and Pi3 by default. They only fail 
> >>> > to work when  CONFIGURE_APPLICATION_NEEDS_CONSOLE_DRIVER
> >>> > this option is used. This is because when that option is used it calls 
> >>> > console_initialize which checks if any boot options were present if 
> >>> > none were
> >>> > given it defaults to pl011 which is the secondary UART in Zero w and 
> >>> > Pi3 so we get no output. This patch defaults to the primary UART 
> >>> > instead of
> >>> > pl011 depending on the board.
> >>> > Also, this patch should be applied on RTEMS 5 since we started 
> >>> > supporting Pi3 and Zero w from RTEMS 5.
> >>> >
> >>> You'll need to provide a separate patch with a ticket to close on 5
> >>> for a backport. Wait until you get the approval for the master branch
> >>> though.
> >>
> >> OK. I'll create a ticket and request for a backport once this is pushed on
> >> to the current master
> >>
> >> Thanks,
> >> Niteesh.
> >>>
> >>>
> >>> > Thanks,
> >>> > Niteesh.
> >>> >
> >>> >
> >>> >>
> >>> >> Thanks,
> >>> >>
> >>> >> Alan
> >>

Re: [PATCH] bsps/raspberrypi: Add FDT defines to build options

[Alan Cudmore]

Hi,
This patch works for me. I can build and run the latest rtems master
branch samples on the RPI 2 and 3.
The samples do not run on the single core models, but it is not
related to this patch. I have a patch for the single core models, and
when combined with this patch I can get the samples to run on RPI
Zero, Zero W, Pi A+, Original Pi Model B+, Pi 2, and Pi 3.

Thanks,
Alan

On Fri, Jun 25, 2021 at 12:18 PM pranav  wrote:
>
> ---
>  spec/build/bsps/arm/raspberrypi/grp.yml |  8 
>  spec/build/bsps/arm/raspberrypi/optfdtcpyro.yml | 15 +++
>  spec/build/bsps/arm/raspberrypi/optfdtmxsz.yml  | 16 
>  spec/build/bsps/arm/raspberrypi/optfdtro.yml| 15 +++
>  spec/build/bsps/arm/raspberrypi/optfdtuboot.yml | 15 +++
>  5 files changed, 69 insertions(+)
>  create mode 100644 spec/build/bsps/arm/raspberrypi/optfdtcpyro.yml
>  create mode 100644 spec/build/bsps/arm/raspberrypi/optfdtmxsz.yml
>  create mode 100644 spec/build/bsps/arm/raspberrypi/optfdtro.yml
>  create mode 100644 spec/build/bsps/arm/raspberrypi/optfdtuboot.yml
>
> diff --git a/spec/build/bsps/arm/raspberrypi/grp.yml 
> b/spec/build/bsps/arm/raspberrypi/grp.yml
> index 7291e8b178..a810fdd529 100644
> --- a/spec/build/bsps/arm/raspberrypi/grp.yml
> +++ b/spec/build/bsps/arm/raspberrypi/grp.yml
> @@ -31,6 +31,14 @@ links:
>uid: optrpi2
>  - role: build-dependency
>uid: optspiiomode
> +- role: build-dependency
> +  uid: optfdtuboot
> +- role: build-dependency
> +  uid: optfdtcpyro
> +- role: build-dependency
> +  uid: optfdtmxsz
> +- role: build-dependency
> +  uid: optfdtro
>  - role: build-dependency
>uid: ../start
>  - role: build-dependency
> diff --git a/spec/build/bsps/arm/raspberrypi/optfdtcpyro.yml 
> b/spec/build/bsps/arm/raspberrypi/optfdtcpyro.yml
> new file mode 100644
> index 00..c26b1ae051
> --- /dev/null
> +++ b/spec/build/bsps/arm/raspberrypi/optfdtcpyro.yml
> @@ -0,0 +1,15 @@
> +SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
> +actions:
> +- get-boolean: null
> +- define-condition: null
> +build-type: option
> +copyrights:
> +- Copyright (C) 2020 embedded brains GmbH (http://www.embedded-brains.de)
> +default: true
> +default-by-variant: []
> +description: |
> +  copy the FDT blob into the read-only load area via bsp_fdt_copy()
> +enabled-by: true
> +links: []
> +name: BSP_FDT_BLOB_COPY_TO_READ_ONLY_LOAD_AREA
> +type: build
> diff --git a/spec/build/bsps/arm/raspberrypi/optfdtmxsz.yml 
> b/spec/build/bsps/arm/raspberrypi/optfdtmxsz.yml
> new file mode 100644
> index 00..14af766230
> --- /dev/null
> +++ b/spec/build/bsps/arm/raspberrypi/optfdtmxsz.yml
> @@ -0,0 +1,16 @@
> +SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
> +actions:
> +- get-integer: null
> +- define: null
> +build-type: option
> +copyrights:
> +- Copyright (C) 2020 embedded brains GmbH (http://www.embedded-brains.de)
> +default: 262144
> +default-by-variant: []
> +description: |
> +  maximum size of the FDT blob in bytes
> +enabled-by: true
> +format: '{}'
> +links: []
> +name: BSP_FDT_BLOB_SIZE_MAX
> +type: build
> diff --git a/spec/build/bsps/arm/raspberrypi/optfdtro.yml 
> b/spec/build/bsps/arm/raspberrypi/optfdtro.yml
> new file mode 100644
> index 00..a61bb2924b
> --- /dev/null
> +++ b/spec/build/bsps/arm/raspberrypi/optfdtro.yml
> @@ -0,0 +1,15 @@
> +SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
> +actions:
> +- get-boolean: null
> +- define-condition: null
> +build-type: option
> +copyrights:
> +- Copyright (C) 2020 embedded brains GmbH (http://www.embedded-brains.de)
> +default: true
> +default-by-variant: []
> +description: |
> +  place the FDT blob into the read-only data area
> +enabled-by: true
> +links: []
> +name: BSP_FDT_BLOB_READ_ONLY
> +type: build
> diff --git a/spec/build/bsps/arm/raspberrypi/optfdtuboot.yml 
> b/spec/build/bsps/arm/raspberrypi/optfdtuboot.yml
> new file mode 100644
> index 00..5805e912ff
> --- /dev/null
> +++ b/spec/build/bsps/arm/raspberrypi/optfdtuboot.yml
> @@ -0,0 +1,15 @@
> +SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
> +actions:
> +- get-boolean: null
> +- define-condition: null
> +build-type: option
> +copyrights:
> +- Copyright (C) 2020 embedded brains GmbH (http://www.embedded-brains.de)
> +default: true
> +default-by-variant: []
> +description: |
> +  copy the U-Boot provided FDT to an internal storage
> +enabled-by: true
> +links: []
> +name: BSP_START_COPY_FDT_FROM_U_BOOT
> +type: build
> --
> 2.27.0
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Question about Raspberry Pi bspstarthooks.c - potential patch

[Alan Cudmore]

Hi,
The current RTEMS 6/master branch does not seem to work on the
Raspberry Pi single core models, while the 5 branch does.

I was able to track it down to a commit where it stopped working:
272534eb725f2486b7a32b39d998202a101bd36e

In that commit, the call:
 /* Clear Secure or Non-secure Vector Base Address Register */
  arm_cp15_set_vector_base_address(bsp_vector_table_begin);

Was moved from bsp_start_hook_0 to rpi_start_rtems_on_secondary_processor.

If I add it back to bsp_start_hook_0, the single core models work again.

I added it here to make it work:
https://git.rtems.org/rtems/tree/bsps/arm/raspberrypi/start/bspstarthooks.c#n72
It seems like it would be called for both the primary and secondary CPUs.

Before Pranav submits a patch, I thought it would be worth seeing if
there was a reason it was moved in the first place.. No need to keep
moving it back and forth.

Also, it's worth mentioning that we still have to troubleshoot SMP on
the Pi 2 and Pi 3. The samples like ticker, hello, unlimited work on
the Pi 2 and Pi 3, but when I try SMP tests, I don't get console
output.

Thanks,
Alan
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Question about Raspberry Pi bspstarthooks.c - potential patch

[Alan Cudmore]

Hi Sebastian,
I understand the move in that commit now.
Maybe it's not working on the single core models because the code is
conditional for ARMV7 + A or ARMV8?
https://git.rtems.org/rtems/tree/bsps/arm/shared/start/start.S#n485
I think the single core RPIs are ARM1176JZF-S (ARMv6Z).
Do the conditional defines come from the compiler?

Thanks,
Alan

On Tue, Jun 29, 2021 at 1:42 AM Sebastian Huber
 wrote:
>
> Hello Alan,
>
> On 29/06/2021 03:13, Alan Cudmore wrote:
> > The current RTEMS 6/master branch does not seem to work on the
> > Raspberry Pi single core models, while the 5 branch does.
> >
> > I was able to track it down to a commit where it stopped working:
> > 272534eb725f2486b7a32b39d998202a101bd36e
> >
> > In that commit, the call:
> >   /* Clear Secure or Non-secure Vector Base Address Register */
> >arm_cp15_set_vector_base_address(bsp_vector_table_begin);
> >
> > Was moved from bsp_start_hook_0 to rpi_start_rtems_on_secondary_processor.
> >
> > If I add it back to bsp_start_hook_0, the single core models work again.
>
> I moved the VBAR setting to start.S. Maybe the problem is that TTBCR is
> no longer set to zero before the VBAR is set. The Raspberry Pi BSP is
> the only BSP which did this.
>
> --
> embedded brains GmbH
> Herr Sebastian HUBER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: sebastian.hu...@embedded-brains.de
> phone: +49-89-18 94 741 - 16
> 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/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Question about Raspberry Pi bspstarthooks.c - potential patch

[Alan Cudmore]

On Tue, Jun 29, 2021 at 3:01 PM Sebastian Huber
 wrote:
>
> On 29/06/2021 20:56, Alan Cudmore wrote:
> > I understand the move in that commit now.
> > Maybe it's not working on the single core models because the code is
> > conditional for ARMV7 + A or ARMV8?
> > https://git.rtems.org/rtems/tree/bsps/arm/shared/start/start.S#n485
> > I think the single core RPIs are ARM1176JZF-S (ARMv6Z).
>
> Oh, yes, this is probably the problem. I wasn't aware that we have a BSP
> which uses Armv6. I will try to figure out the right options.

Thanks! As soon as you have something that would work, we can test it.
The CPU architecture is old, but it looks like these models will be in
production until at least 2026.

>
> > Do the conditional defines come from the compiler?
>
> Yes, these are compiler built-in defines.
>
> --
> embedded brains GmbH
> Herr Sebastian HUBER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: sebastian.hu...@embedded-brains.de
> phone: +49-89-18 94 741 - 16
> 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/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Question about Raspberry Pi bspstarthooks.c - potential patch

[Alan Cudmore]

Also, if you do not have time, we could research a solution ( guidance
is welcome! )
Alan

On Tue, Jun 29, 2021 at 3:09 PM Alan Cudmore  wrote:
>
> On Tue, Jun 29, 2021 at 3:01 PM Sebastian Huber
>  wrote:
> >
> > On 29/06/2021 20:56, Alan Cudmore wrote:
> > > I understand the move in that commit now.
> > > Maybe it's not working on the single core models because the code is
> > > conditional for ARMV7 + A or ARMV8?
> > > https://git.rtems.org/rtems/tree/bsps/arm/shared/start/start.S#n485
> > > I think the single core RPIs are ARM1176JZF-S (ARMv6Z).
> >
> > Oh, yes, this is probably the problem. I wasn't aware that we have a BSP
> > which uses Armv6. I will try to figure out the right options.
>
> Thanks! As soon as you have something that would work, we can test it.
> The CPU architecture is old, but it looks like these models will be in
> production until at least 2026.
>
> >
> > > Do the conditional defines come from the compiler?
> >
> > Yes, these are compiler built-in defines.
> >
> > --
> > embedded brains GmbH
> > Herr Sebastian HUBER
> > Dornierstr. 4
> > 82178 Puchheim
> > Germany
> > email: sebastian.hu...@embedded-brains.de
> > phone: +49-89-18 94 741 - 16
> > 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/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Question about Raspberry Pi bspstarthooks.c - potential patch

[Alan Cudmore]

On Thu, Jul 1, 2021 at 8:20 AM Sebastian Huber
 wrote:
>
> On 29/06/2021 21:09, Alan Cudmore wrote:
> >> On 29/06/2021 20:56, Alan Cudmore wrote:
> >>> I understand the move in that commit now.
> >>> Maybe it's not working on the single core models because the code is
> >>> conditional for ARMV7 + A or ARMV8?
> >>> https://git.rtems.org/rtems/tree/bsps/arm/shared/start/start.S#n485
> >>> I think the single core RPIs are ARM1176JZF-S (ARMv6Z).
> >> Oh, yes, this is probably the problem. I wasn't aware that we have a BSP
> >> which uses Armv6. I will try to figure out the right options.
> > Thanks! As soon as you have something that would work, we can test it.
> > The CPU architecture is old, but it looks like these models will be in
> > production until at least 2026.
>
> I didn't find an Armv6 Reference Manual, so I have no idea if this works
> for all Armv6 systems (the only one in RTEMS is probably the Raspberry Pi)
>
> diff --git a/bsps/arm/shared/start/start.S b/bsps/arm/shared/start/start.S
> index 698495d32e..028bef6d2d 100644
> --- a/bsps/arm/shared/start/start.S
> +++ b/bsps/arm/shared/start/start.S
> @@ -482,7 +482,8 @@ bsp_start_hook_0_done:
>
>   .Lvector_table_copy_done:
>
> -#if (__ARM_ARCH >= 7 && __ARM_ARCH_PROFILE == 'A') || __ARM_ARCH >= 8
> +#if __ARM_ARCH == 6 || (__ARM_ARCH >= 7 && __ARM_ARCH_PROFILE == 'A') || \
> +  __ARM_ARCH >= 8
>  /*
>   * This code path is only executed by the primary processor.
> Set the
>   * VBAR to the normal vector table.  For secondary processors,
> this is
>
>
> --

The define works, but Armv6 does not implement dsb and isb.
I created a separate #if block for Armv6 without the dsb and isb
instructions and it seems to work on the Raspberry Pi Zero.
Do you think the equivalent synchronization operations are necessary
here? If so, I can research and test them. I found some references on
Raspberry Pi forums that I can follow (also had links to the ARM
manuals)

Also, for the #if blocks, would you prefer this style:
#if (7A or 8)
..
#else if (6)
..
#endif

or two separate #if blocks?

Thanks,
Alan

> embedded brains GmbH
> Herr Sebastian HUBER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: sebastian.hu...@embedded-brains.de
> phone: +49-89-18 94 741 - 16
> 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/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Question about Raspberry Pi bspstarthooks.c - potential patch

[Alan Cudmore]

I tried to implement the deprecated cp15 ARMv6 data sync and
instruction sync barriers in the code below. I'm not sure if I got it
right.
The samples run on the single core models, but they also run without
the sync instructions (the commented out code).

For the conditional code, I chose the __ARM_ARCH_6KZ__ define, since
it is set by the arch switch the Pi 1 BSP uses. Not all ARMv6 models
have the CP15 VBAR, so in the unlikely event we added an even older
ARMv6 it would break. I can change it to __ARM_ARCH == 6 if that is
preferred.

At this point, my questions are:
1. Is the define OK?
2. Include the sync barriers for ARMv6 or not?
3. If we keep the sync barriers, are they good enough, or do they need
more work?

Thanks,
Alan

Patch:

diff --git a/bsps/arm/shared/start/start.S b/bsps/arm/shared/start/start.S
index 698495d32e..bb8ad24e96 100644
--- a/bsps/arm/shared/start/start.S
+++ b/bsps/arm/shared/start/start.S
@@ -482,16 +482,26 @@ bsp_start_hook_0_done:

 .Lvector_table_copy_done:

-#if (__ARM_ARCH >= 7 && __ARM_ARCH_PROFILE == 'A') || __ARM_ARCH >= 8
/*
 * This code path is only executed by the primary processor.  Set the
 * VBAR to the normal vector table.  For secondary processors, this is
 * done by bsp_start_hook_0().
 */
+#if (__ARM_ARCH >= 7 && __ARM_ARCH_PROFILE == 'A') || __ARM_ARCH >= 8
ldr r0, =bsp_vector_table_begin
dsb
mcr p15, 0, r0, c12, c0, 0
isb
+#elif defined __ARM_ARCH_6KZ__
+/*
+** ldr r0, =bsp_vector_table_begin
+** mcr p15, 0, r0, c12, c0, 0
+*/
+mov r1, #0
+ldr r0, =bsp_vector_table_begin
+mcr p15, 0, r1, c7, c10, 4  /* DataSync */
+mcr p15, 0, r0, c12, c0, 0  /* Load VBAR */
+mcr p15, 0, r1, c7, c5, 4   /* Flush Prefetch */
 #endif

SWITCH_FROM_ARM_TO_THUMBr3

On Thu, Jul 1, 2021 at 10:02 AM Sebastian Huber
 wrote:
>
> On 01/07/2021 15:43, Alan Cudmore wrote:
> > The define works, but Armv6 does not implement dsb and isb.
>
> Ok, I think there are some (now deprecated) CP15 registers for dsb and isb.
>
> > I created a separate #if block for Armv6 without the dsb and isb
> > instructions and it seems to work on the Raspberry Pi Zero.
> > Do you think the equivalent synchronization operations are necessary
> > here? If so, I can research and test them. I found some references on
> > Raspberry Pi forums that I can follow (also had links to the ARM
> > manuals)
> >
> > Also, for the #if blocks, would you prefer this style:
> > #if (7A or 8)
> > ..
> > #else if (6)
> > ..
> > #endif
>
> Yes, this would be good.
>
> --
> embedded brains GmbH
> Herr Sebastian HUBER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: sebastian.hu...@embedded-brains.de
> phone: +49-89-18 94 741 - 16
> 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/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: m2006-2 Linux Build Sweep Feedback

[Alan Cudmore]

For the Pi2 SMP:
I started looking at this a while ago. If I remember correctly, Pi2
SMP worked on QEMU. I have an original Pi2 that it fails on (using
smp01.exe). I dont have a really good way to debug on the hardware, so
I was going down the path of using printk statements to figure out
where it was hanging. The console log below shows how far I was able
to get.
It looks like it's in _CPU_SMP_Processor_event_receive waiting for the
2nd CPU to change state.
If anyone has clues of where to look next, I can try a few changes out.

Alan


RTEMS RPi 2B 1.1 (1GB) [00a21041]
in _SMP_Handler_initialize
in _SMP_Handler_initialize, max processors = 4
in _SMP_Handler_initialize - calling _CPU_SMP_Initialize
in _CPU_SMP_Initialize
in _SMP_Handler_initialize - _SMP_Processor_maximum = 4
in _SMP_Handler_initialize - calling _SMP_Start_processors
In _SMP_Start_processors
In _SMP_Start_processors - index = 0
In _SMP_Start_processors - cpu_index = self, so started already
In _SMP_Start_processors - index = 1
In _SMP_Start_processors - calling _CPU_SMP_Start_processor
in _CPU_SMP_Start_processor : cpu_index = 1
in _CPU_SMP_Start_processor - call
_Per_CPU_State_wait_for_non_initial_state - bool started = 0
in Per_CPU_State_wait_for_non_initial_state index = 1, timeout = 0
 CPU state before = 0
in Per_CPU_State_wait_for_non_initial_state - about to call
_CPU_SMP_Processor_event_receive in while loop
in Per_CPU_State_wait_for_non_initial_state - after
_CPU_SMP_Processor_event_receive in while loop
 CPU state  after = 0
in Per_CPU_State_wait_for_non_initial_state - about to call
_CPU_SMP_Processor_event_receive in while loop

On Sun, Jun 21, 2020 at 7:09 AM Chris Johns  wrote:
>
>
> On 21 Jun 2020, at 12:48 am, Joel Sherrill  wrote:
>
> Hi
>
> The m2006-2 candidate passed more of the build sweep steps than any of the 
> other candidates.
>
>
> Great. I will branch the repos tomorrow.
>
> Thank you for all your testing and reports. They are really helpful and 
> important.
>
> The bsp builder sweep of all BSPs and many (1700+) configurations has the 
> normal 6 GCC induced epiphany failures. All but one of the BSP bsets built. 
> atsamv failed:
>
> https://lists.rtems.org/pipermail/build/2020-June/015864.html
>
> Looks like libbsd failed to build for that BSP with this:
>
> ===
> [1875/1925] Linking build/arm-rtems5-atsamv-default/epoch01.exe
> /home/joel/rtems-cron-5.0.0-m2006-2/rtems-source-builder-5.0.0-m2006-2/rtems/build/tmp/sb-1001-staging/bin/../lib/gcc/arm-rtems5/7.5.0/../../../../arm-rtems5/bin/ld:linkcmds.base:326
>  cannot move location counter backwards (from 2047ab60 to 
> 2045f000)
> collect2: error: ld returned 1 exit status
>
> /home/joel/rtems-cron-5.0.0-m2006-2/rtems-source-builder-5.0.0-m2006-2/rtems/build/tmp/sb-1001-staging/bin/../lib/gcc/arm-rtems5/7.5.0/../../../../arm-rtems5/bin/ld:linkcmds.base:326
>  cannot move location counter backwards (from 2053f9a0 to 
> 2045f000)
> collect2: error: ld returned 1 exit status
>
> /home/joel/rtems-cron-5.0.0-m2006-2/rtems-source-builder-5.0.0-m2006-2/rtems/build/tmp/sb-1001-staging/bin/../lib/gcc/arm-rtems5/7.5.0/../../../../arm-rtems5/bin/ld:linkcmds.base:326
>  cannot move location counter backwards (from 2053f9a0 to 
> 2045f000)
> collect2: error: ld returned 1 exit status
>
> Waf: Leaving directory 
> `/home/joel/rtems-cron-5.0.0-m2006-2/rtems-source-builder-5.0.0-m2006-2/rtems/build/rtems-libbsd-d38dbbe18e5315bf69a7c3916d71ef3838d4c20d-x86_64-linux-gnu-1/rtems-libbsd-5.0.0-m2006-2/build/arm-rtems5-atsamv-default'
> Build failed
> ===
>
> No one may read this far but this failure and Jan's Pi2 testing failure 
> appear to be the hurdles now.
>
>
> That is a shame. Fixes are welcome.
>
> Chris
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Raspberry Pi test report

[Alan Cudmore]

I finally found the time to try the latest RTEMS head on my collection of
Raspberry Pi models.
The last time I tried to run RTEMS on a Pi, I had trouble with the current
version of the Raspberry Pi Firmware, so I had to go back to a specific tag
on the Rasberry Pi firmware repository to get RTEMS to work. This time, the
head of the firmware repository seems to work (at least on the single core
models)

To keep things simple, I'm just going address the single core models here,
I can follow up after I finish testing the Raspberry Pi 2.

Test Setup:
I used the git.rtems.org rtems master from Jan 03 2020.
I used the Raspberry Pi firmware from the same date.
The firmware can be found here:
https://github.com/raspberrypi/firmware/tree/master/boot
To boot an RTEMS image, you can copy all files from the above "boot"
directory on a DOS formatted SD/MicroSD card along with the RTEMS image
(more about that in a minute).
On the SD card, I deleted the "dtb" files, as well as the overlay
directory. I dont think these are necessary to boot an RTEMS image.

I built a new arm-rtems5 toolchain using the RSB tool (head from the same
date) and built the "raspberrypi" BSP. After a quick test failed, I
reviewed the latest mailing list posts, and ended up applying the linker
script patch:
https://lists.rtems.org/pipermail/devel/2019-December/056551.html

After applying this patch and rebuilding, a few RTEMS samples seemed to
work fine on the Raspberry Pi Zero Models 1.2 and 1.3 (no wireless). I ran
hello.exe, ticker.exe, and unlimited.exe

The above images must be prepared using the following command:
$ arm-rtems5-objcopy -Obinary ticker.exe kernel.img
Then I copied kernel.img over the linux kernel on the SD card.

For all of these tests, I found this serial to USB board to be very useful
in my tests:
https://www.adafruit.com/product/3589
It can power the pi through the USB cable and has a power switch as well.

After the Pi Zero models, I tried my remaining older single core models:
1. Raspberry Pi Model B ( Original single core model with 512MB of RAM and
26 pin GPIO header)
2. Raspberry Pi Model B+ (Updated Single core model with 512MB of RAM and
40 pin GPIO header)
3. Raspberry Pi Model A+ (Smaller form factor single core model with 256MB
of RAM and 40 pin GPIO header)
   (Note this model has been updated to now have 512MB of RAM)

All three of the above models had the same exception that has been
discussed on the mailing list:
https://lists.rtems.org/pipermail/devel/2019-December/056556.html

All of these single core models are supposed to be compatible, and should
run the same RTEMS image given the same memory configuration.
Since the previous message was discussing the bspgetworkarea.c changes, I
made a couple of changes:
- Reverted to the generic bspgetworkarea.c file, and changed the memory
size from 256MB to 128MB ( same as the 4.11 release ).
With these changes, the same RTEMS images worked on all single core models:
- RPi Zero 1.2 and 1.3
- RPi Model B
- RPi Model B+
- RPi Model A+

Findings:
1. The code that identifies the models in bspstart.c does not account for
the older models:
https://git.rtems.org/rtems/tree/bsps/arm/raspberrypi/start/bspstart.c
The RPi Model B, B+, and A+ that I have all use the older revision which is
not in the table in bspstart.c. I think we can fix this by adding the older
revision codes in the table, but I think this code is mostly cosmetic.
https://www.raspberrypi.org/documentation/hardware/raspberrypi/revision-codes/README.md

2. I think the code that determines the memory size in bspgetworkarea.c is
not correct:
https://git.rtems.org/rtems/tree/bsps/arm/raspberrypi/start/bspgetworkarea.c
a) The mask for the memory size field should probably be 0x7 rather
than 0xf. The 0xF picks up the "new revision" field of the word.

https://git.rtems.org/rtems/tree/bsps/arm/raspberrypi/start/bspgetworkarea.c#n70
b) I'm not sure if the rpi_mem array is correct. The values are used in
address size calculations, but the values seem to be in Kilobytes, not
Megabytes. Maybe I'm not catching a shift that is done on these values.

https://git.rtems.org/rtems/tree/bsps/arm/raspberrypi/start/bspgetworkarea.c#n73
c) I'm not sure that the numbers all add up. Line 80 computes the
ram_end value by adding the Work Area start to the total size of the RAM. I
think this will overrun the end of the RAM.

https://git.rtems.org/rtems/tree/bsps/arm/raspberrypi/start/bspgetworkarea.c#n80
d) I would like to look at the relationship between the ram_end
calculation and the ram_size given in the autoconfigure setting ( currently
at 256MiB). Are the MMU settings done based on the hard coded linker script
value that may conflict with the sizes set here?
e) the code may not work for the older models that do not have the
updated revision fields.

If the intent is to cover the different raspberry pi memory sizes
automatically, then we can probably rework this code to work for all models.
We may be able to use

Re: Raspberry Pi test report

[Alan Cudmore]

The Debian Linux variant for the Raspberry Pi (Raspbian) is still 32 bit
for both the Pi 3 and 4, so I would think 32 bit ports would run on both.
The Raspberry Pi 4 has a Quad Core A72, 1 to 4 Gigabytes of LPDDR4 SDRAM,
Gigabit ethernet, USB 3, Wi-fi and bluetooth. I have not looked into it
enough to see what UARTs it uses.

On Wed, Jan 8, 2020 at 1:18 AM Christian Mauderer <
christian.maude...@embedded-brains.de> wrote:

> On 08/01/2020 00:24, Joel Sherrill wrote:
> >
> >
> > On Tue, Jan 7, 2020 at 12:42 PM Christian Mauderer  > <mailto:l...@c-mauderer.de>> wrote:
> >
> > Hello Alan,
> >
> > I pushed the patches mentioned further below. So the raspberry BSP
> > should now work again for all raspberry 1 and 2 on the official
> master
> > branch. Note that the
> >
> > kernel_address=0x20
> >
> > is still necessary.
> >
> >
> > This is awesome work. What about the Pi 3 and and Pi 4?  I think Niteesh
> > has the Pi 3 working so that leaves the 4. Any idea?
> >
> > --joel
> >
>
> As far as I followed his work Niteesh had some minimal version working
> with the mini UART and thought about trying the existing NS16550 (after
> I suggested that one). But I haven't seen a patch yet. So currently even
> if some basic stuff runs there will be no console.
>
> Beneath that: Pi 3 and Pi 4 are both 64Bit cores. I don't have any
> experience with aarch64. Therefore I'm not sure whether we can safely
> use them with 32Bit fallback. It seems to work to some extend but
> according to
>
> https://en.wikipedia.org/wiki/ARM_architecture#AArch64
>
> "ARMv8-A allows 32-bit applications to be executed in
>  a 64-bit OS, and a 32-bit OS to be under the control
>  of a 64-bit hypervisor."
>
> So I'm not sure in which situations we will run into problems. Maybe on
> interrupts?
>
> Best regards
>
> Christian
>
> >
> > Best regards
> >
> > Christian
> >
> > On 06/01/2020 11:10, Christian Mauderer wrote:
> > > Hello Alan,
> > >
> > > thanks for your very detailed tests.
> > >
> > > On 05/01/2020 23:42, Alan Cudmore wrote:
> > >> I finally found the time to try the latest RTEMS head on my
> > collection
> > >> of Raspberry Pi models.
> > >> The last time I tried to run RTEMS on a Pi, I had trouble with the
> > >> current version of the Raspberry Pi Firmware, so I had to go back
> > to a
> > >> specific tag on the Rasberry Pi firmware repository to get RTEMS
> to
> > >> work. This time, the head of the firmware repository seems to
> > work (at
> > >> least on the single core models)
> > >>
> > >> To keep things simple, I'm just going address the single core
> models
> > >> here, I can follow up after I finish testing the Raspberry Pi 2.
> > >>
> > >> Test Setup:
> > >> I used the git.rtems.org <http://git.rtems.org>
> > <http://git.rtems.org> rtems master from Jan 03
> > >> 2020.
> > >> I used the Raspberry Pi firmware from the same date.
> > >> The firmware can be found here:
> > >> https://github.com/raspberrypi/firmware/tree/master/boot
> > >> To boot an RTEMS image, you can copy all files from the above
> "boot"
> > >> directory on a DOS formatted SD/MicroSD card along with the RTEMS
> > image
> > >> (more about that in a minute).
> > >> On the SD card, I deleted the "dtb" files, as well as the overlay
> > >> directory. I dont think these are necessary to boot an RTEMS
> image.
> > >>
> > >> I built a new arm-rtems5 toolchain using the RSB tool (head from
> the
> > >> same date) and built the "raspberrypi" BSP. After a quick test
> > failed, I
> > >> reviewed the latest mailing list posts, and ended up applying the
> > linker
> > >> script patch:
> > >> https://lists.rtems.org/pipermail/devel/2019-December/056551.html
> > >
> > > I don't think that we will apply that patch. It moves code in an
> area
> > > that is protected against access to catch null pointer accesses
> later.
> > > This increases the image size.
> > >
> > > The alternative is to add the line
> > &g

Re: Pi Zero Automated Testing/TFTP/Uboot

[Alan Cudmore]

Unfortunately, The Raspberry Pi Zero (1.3) does not have a network
interface, it just has the MicroSD card and the interfaces exposed on the
40 Pin GPIO header. (SPI, I2C, GPIO, UART, etc)
The Raspberry Pi Zero W adds the Wi-Fi/bluetooth module that the RPi 3 has,
but I'm guessing that won't work with u-boot?

The Raspberry Pi Model B+ looks like it will be made until at least January
2022. It should be the same as the Pi Zero with the addition of the USB hub
that adds additional USB ports and the ethernet.
I think we are at the point where the "raspberrypi" BSP will run on all
single core models, so it may make sense for the reference system for the
"raspberrypi" BSP to continue to be the Model B+ so it can be used with
u-boot and TFTP.

https://www.raspberrypi.org/blog/product_categories/raspberry-pi-boards/



On Wed, Jan 8, 2020 at 10:37 AM Joel Sherrill  wrote:

> Hi
>
> Can the Pi Zero boot with TFTP like the wired versions? We are wondering
> as this is how the automated testing for the Pi's is done.
>
> We are hoping to setup at least one Pi from each basic generation (1, 2,
> 3, 4, and Zero) for automated testing.
>
> Thanks.
>
> --joel
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Cheap Small PC for RTEMS testing

[Alan Cudmore]

I wonder if any of these boards would be compatible:
https://up-board.org/

The Up Board that has the same form factor as a raspberry Pi looks like it
is $100 US:
 https://up-shop.org/up-boards/272-up-board.html

A google shows this x86 32 bit processor, which is interesting:
http://www.86duino.com/?page_id=11

The 86duino "zero" is $39 US and has a 32 bit 300mhz x86 compatible CPU.
Says:
 The 86Duino is a high performance and fully static 32-bit x86 processor
board compatible with Windows OS, Linux and most popular 32-bit RTOS
http://shop.dmp.com.tw/INT/products/23

Is RTEMS popular ? :)


On Mon, Jan 13, 2020 at 5:41 PM Joel Sherrill  wrote:

> Hi
>
> I was looking for a recommendation as a cheap test PC option.
>
> I was considering the Minnowboard but it looks like minnowboard.org is
> dead which makes me a bit vervois. It has 64-bit BIOS. Did we ever get far
> enough where this might work?
>
> https://store.netgate.com/Turbot4.aspx
>
> Does anyone have any recommendation? Doesn't have to be fancy. Just a UART
> for console and no development required to make the PC work with RTEMS. :)
>
> Thanks.
>
> --joel
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Raspberry Pi test report

[Alan Cudmore]

I tried the latest RTEMS master on my collection of single core RPis and
they all worked. I used the kernel_address=0x20 option in the
config.txt file.
The BSP did not identify the RPi Model B (26 pin GPIO header) or the RPi
Model A+ (1.1) since they use the older device ID register format. It's
probably a simple patch to identify these older models. Is it worth it,
given that they are not sold anymore?

I also tried some simple tests on the RPi 2 (v 1.1) and they worked.
However the SMP tests seem to crash on the RPi 2.
Does anyone know if the RPi 2 SMP works on the latest master? I know it has
worked in the past.
I wouldn't mind dropping the Pi 2 once the Pi 3 is working.. The model is
being phased out anyway.

It looks like there is progress being made on the RPi 3. The mini uart
support may also work on the RPi Zero W, since it has the same
wireless/bluetooth model as the 3. I can try the Pi 3 out whenever it is
ready.
Thanks for all of the recent RPI updates!
Alan



On Wed, Jan 8, 2020 at 10:26 AM Alan Cudmore  wrote:

> The Debian Linux variant for the Raspberry Pi (Raspbian) is still 32 bit
> for both the Pi 3 and 4, so I would think 32 bit ports would run on both.
> The Raspberry Pi 4 has a Quad Core A72, 1 to 4 Gigabytes of LPDDR4 SDRAM,
> Gigabit ethernet, USB 3, Wi-fi and bluetooth. I have not looked into it
> enough to see what UARTs it uses.
>
> On Wed, Jan 8, 2020 at 1:18 AM Christian Mauderer <
> christian.maude...@embedded-brains.de> wrote:
>
>> On 08/01/2020 00:24, Joel Sherrill wrote:
>> >
>> >
>> > On Tue, Jan 7, 2020 at 12:42 PM Christian Mauderer > > <mailto:l...@c-mauderer.de>> wrote:
>> >
>> > Hello Alan,
>> >
>> > I pushed the patches mentioned further below. So the raspberry BSP
>> > should now work again for all raspberry 1 and 2 on the official
>> master
>> > branch. Note that the
>> >
>> > kernel_address=0x20
>> >
>> > is still necessary.
>> >
>> >
>> > This is awesome work. What about the Pi 3 and and Pi 4?  I think Niteesh
>> > has the Pi 3 working so that leaves the 4. Any idea?
>> >
>> > --joel
>> >
>>
>> As far as I followed his work Niteesh had some minimal version working
>> with the mini UART and thought about trying the existing NS16550 (after
>> I suggested that one). But I haven't seen a patch yet. So currently even
>> if some basic stuff runs there will be no console.
>>
>> Beneath that: Pi 3 and Pi 4 are both 64Bit cores. I don't have any
>> experience with aarch64. Therefore I'm not sure whether we can safely
>> use them with 32Bit fallback. It seems to work to some extend but
>> according to
>>
>> https://en.wikipedia.org/wiki/ARM_architecture#AArch64
>>
>> "ARMv8-A allows 32-bit applications to be executed in
>>  a 64-bit OS, and a 32-bit OS to be under the control
>>  of a 64-bit hypervisor."
>>
>> So I'm not sure in which situations we will run into problems. Maybe on
>> interrupts?
>>
>> Best regards
>>
>> Christian
>>
>> >
>> > Best regards
>> >
>> > Christian
>> >
>> > On 06/01/2020 11:10, Christian Mauderer wrote:
>> > > Hello Alan,
>> > >
>> > > thanks for your very detailed tests.
>> > >
>> > > On 05/01/2020 23:42, Alan Cudmore wrote:
>> > >> I finally found the time to try the latest RTEMS head on my
>> > collection
>> > >> of Raspberry Pi models.
>> > >> The last time I tried to run RTEMS on a Pi, I had trouble with
>> the
>> > >> current version of the Raspberry Pi Firmware, so I had to go back
>> > to a
>> > >> specific tag on the Rasberry Pi firmware repository to get RTEMS
>> to
>> > >> work. This time, the head of the firmware repository seems to
>> > work (at
>> > >> least on the single core models)
>> > >>
>> > >> To keep things simple, I'm just going address the single core
>> models
>> > >> here, I can follow up after I finish testing the Raspberry Pi 2.
>> > >>
>> > >> Test Setup:
>> > >> I used the git.rtems.org <http://git.rtems.org>
>> > <http://git.rtems.org> rtems master from Jan 03
>> > >> 2020.
>> > >> I used the Raspberry Pi firmware from the s

RE: Re: Raspberry Pi test report

[Alan Cudmore]

  From: Christian MaudererSent: Sunday, January 19, 2020 2:49 PMTo: Alan Cudmore; Christian Mauderer; gsnb...@gmail.comCc: rtems-de...@rtems.orgSubject: Re: Raspberry Pi test report On 19/01/2020 20:42, Alan Cudmore wrote:> I tried the latest RTEMS master on my collection of single core RPis and> they all worked. I used the kernel_address=0x20 option in the> config.txt file.> The BSP did not identify the RPi Model B (26 pin GPIO header) or the RPi> Model A+ (1.1) since they use the older device ID register format. It's> probably a simple patch to identify these older models. Is it worth it,> given that they are not sold anymore? It's most likely only a wrong output. The memory size should be correctnow. But nonetheless it's a bug and we currently mainly support the 1and 2. Therefore I would say it's worth a fix. Do you want to add one? I can work on a fix for the model identification for the older models. > > I also tried some simple tests on the RPi 2 (v 1.1) and they worked.> However the SMP tests seem to crash on the RPi 2. > Does anyone know if the RPi 2 SMP works on the latest master? I know it> has worked in the past. I didn't test it. Do you have some details? I’m just starting to troubleshoot, but I build the raspberrypi2 BSP with –enable-smp.A few of the samples like ticker.exe and unlimited.exe work.But when I try smp01.exe, I don’t see any output past the model Identification that is printed by the BSP:RTEMS RPi 2B 1.1 (1GB) [00a21041] I commented out much of the code in smp01/init.c just to see if I could get the “test begin” banner, but did not see anything. (here is where the debugger would help!) Is the ticker.exe demo built differently than smp01.exe? These are both under the same build with the same configure options.I will try to continue my troubleshooting a little later. > I wouldn't mind dropping the Pi 2 once the Pi 3 is working.. The model> is being phased out anyway. Again: Still a lot of boards around. And quite possible that the olderones that are phased out of some Linux applications are used now forRTEMS stuff. So I'm not a fan of removing the support. That is fine with me. I read that there have been 30 million Raspberry Pis sold so far. I was trying to find a breakdown of that figure by model number. > > It looks like there is progress being made on the RPi 3. The mini uart> support may also work on the RPi Zero W, since it has the same> wireless/bluetooth model as the 3. I can try the Pi 3 out whenever it is> ready.> Thanks for all of the recent RPI updates!  Please give a special thanks to Niteesh. He does most of the currentraspberry work. And thank you for the repeated testing. Absolutely! Niteesh’s work to allow RTEMS to work on the Raspberry Pi 3 is very much appreciated! Thanks,Alan Best regards Christian > Alan> > > > On Wed, Jan 8, 2020 at 10:26 AM Alan Cudmore > > wrote:> > The Debian Linux variant for the Raspberry Pi (Raspbian) is still 32> bit for both the Pi 3 and 4, so I would think 32 bit ports would run> on both.> The Raspberry Pi 4 has a Quad Core A72, 1 to 4 Gigabytes of LPDDR4> SDRAM, Gigabit ethernet, USB 3, Wi-fi and bluetooth. I have not> looked into it enough to see what UARTs it uses.> > On Wed, Jan 8, 2020 at 1:18 AM Christian Mauderer> > > wrote:> > On 08/01/2020 00:24, Joel Sherrill wrote:> >> >> > On Tue, Jan 7, 2020 at 12:42 PM Christian Mauderer> > > >> wrote:> >> >     Hello Alan,> >> >     I pushed the patches mentioned further below. So the> raspberry BSP> >     should now work again for all raspberry 1 and 2 on the> official master> >     branch. Note that the> >> >         kernel_address=0x20> >> >     is still necessary.> >> >> > This is awesome work. What about the Pi 3 and and Pi 4?  I> think Niteesh> > has the Pi 3 working so that leaves the 4. Any idea?> >> > --joel> >> > As far as I followed his work Niteesh had some minimal version> working> with the mini UART and thought about trying the existing NS16550> (after> I suggested that one). But I haven't seen a patch yet. So> currently even> if some basic stuff runs there will be no console.> >     Beneath that: Pi 3 and Pi 4 are both 64Bit cores. I don't have any> experience with aarch64. Therefore I'm not sure whether we can> safely> use them with 32Bit fallback. It seems to work to some extend but>

RE: Re: Raspberry Pi test report

[Alan Cudmore]

Sorry for duplicate or incorrectly formatted messages. I need to setup an e-mail client to just send plain text. . See my replies below: From: Christian MaudererSent: Sunday, January 19, 2020 2:49 PMTo: Alan Cudmore; Christian Mauderer; gsnb...@gmail.comCc: rtems-de...@rtems.orgSubject: Re: Raspberry Pi test report On 19/01/2020 20:42, Alan Cudmore wrote:> I tried the latest RTEMS master on my collection of single core RPis and> they all worked. I used the kernel_address=0x20 option in the> config.txt file.> The BSP did not identify the RPi Model B (26 pin GPIO header) or the RPi> Model A+ (1.1) since they use the older device ID register format. It's> probably a simple patch to identify these older models. Is it worth it,> given that they are not sold anymore? It's most likely only a wrong output. The memory size should be correctnow. But nonetheless it's a bug and we currently mainly support the 1and 2. Therefore I would say it's worth a fix. Do you want to add one? I can work on a fix to identify the older models. > > I also tried some simple tests on the RPi 2 (v 1.1) and they worked.> However the SMP tests seem to crash on the RPi 2. > Does anyone know if the RPi 2 SMP works on the latest master? I know it> has worked in the past. I didn't test it. Do you have some details? I’m just starting to troubleshoot, but I build the raspberrypi2 BSP with –enable-smp.A few of the samples like ticker.exe and unlimited.exe work.But when I try smp01.exe, I don’t see any output past the model Identification that is printed by the BSP:RTEMS RPi 2B 1.1 (1GB) [00a21041] I commented out much of the code in smp01/init.c just to see if I could get the “test begin” banner, but did not see anything. (here is where the debugger would help!) Is the ticker.exe demo built differently than smp01.exe? These are both under the same build with the same configure options.I will try to continue my troubleshooting a little later.  > I wouldn't mind dropping the Pi 2 once the Pi 3 is working.. The model> is being phased out anyway. Again: Still a lot of boards around. And quite possible that the olderones that are phased out of some Linux applications are used now forRTEMS stuff. So I'm not a fan of removing the support. That is fine with me. I read that there have been 30 million Raspberry Pis sold so far. I am trying to find a breakdown of that figure by model number. > > It looks like there is progress being made on the RPi 3. The mini uart> support may also work on the RPi Zero W, since it has the same> wireless/bluetooth model as the 3. I can try the Pi 3 out whenever it is> ready.> Thanks for all of the recent RPI updates!  Please give a special thanks to Niteesh. He does most of the currentraspberry work. And thank you for the repeated testing. Absolutely! Niteesh’s work to allow RTEMS to work on the Raspberry Pi 3 is very much appreciated! Thanks,Alan Best regards Christian > Alan> > > > On Wed, Jan 8, 2020 at 10:26 AM Alan Cudmore > > wrote:> > The Debian Linux variant for the Raspberry Pi (Raspbian) is still 32> bit for both the Pi 3 and 4, so I would think 32 bit ports would run> on both.> The Raspberry Pi 4 has a Quad Core A72, 1 to 4 Gigabytes of LPDDR4> SDRAM, Gigabit ethernet, USB 3, Wi-fi and bluetooth. I have not> looked into it enough to see what UARTs it uses.> > On Wed, Jan 8, 2020 at 1:18 AM Christian Mauderer> > > wrote:> > On 08/01/2020 00:24, Joel Sherrill wrote:> >> >> > On Tue, Jan 7, 2020 at 12:42 PM Christian Mauderer> > > >> wrote:> >> >     Hello Alan,> >> >     I pushed the patches mentioned further below. So the> raspberry BSP> >     should now work again for all raspberry 1 and 2 on the> official master> >     branch. Note that the> >> >         kernel_address=0x20> >> >     is still necessary.> >> >> > This is awesome work. What about the Pi 3 and and Pi 4?  I> think Niteesh> > has the Pi 3 working so that leaves the 4. Any idea?> >> > --joel> >> > As far as I followed his work Niteesh had some minimal version> working> with the mini UART and thought about trying the existing NS16550> (after> I suggested that one). But I haven't seen a patch yet. So> currently even> if some basic stuff runs there will be no console.> >     Beneath that: Pi 3 and Pi 4 are both 64Bit cores. I don't have any> experience with aarch64. Therefore I'm not sure wheth

Re: Re: Raspberry Pi test report

[Alan Cudmore]

One clue for the Raspberry Pi 2 SMP problem:

The regular samples work (hello.exe, ticker.exe, unlimited.exe)
If I add #define CONFIGURE_MAXIMUM_PROCESSORS 4
to the init.c for hello, it does not work.



On Mon, Jan 20, 2020 at 11:52 AM Alan Cudmore 
wrote:

> Sorry for duplicate or incorrectly formatted messages. I need to setup an
> e-mail client to just send plain text. . See my replies below:
>
>
>
> *From: *Christian Mauderer 
> *Sent: *Sunday, January 19, 2020 2:49 PM
> *To: *Alan Cudmore ; Christian Mauderer
> ; gsnb...@gmail.com
> *Cc: *rtems-de...@rtems.org 
> *Subject: *Re: Raspberry Pi test report
>
>
>
> On 19/01/2020 20:42, Alan Cudmore wrote:
>
> > I tried the latest RTEMS master on my collection of single core RPis and
>
> > they all worked. I used the kernel_address=0x20 option in the
>
> > config.txt file.
>
> > The BSP did not identify the RPi Model B (26 pin GPIO header) or the RPi
>
> > Model A+ (1.1) since they use the older device ID register format. It's
>
> > probably a simple patch to identify these older models. Is it worth it,
>
> > given that they are not sold anymore?
>
>
>
> It's most likely only a wrong output. The memory size should be correct
>
> now. But nonetheless it's a bug and we currently mainly support the 1
>
> and 2. Therefore I would say it's worth a fix. Do you want to add one?
>
>
>
> I can work on a fix to identify the older models.
>
>
>
> >
>
> > I also tried some simple tests on the RPi 2 (v 1.1) and they worked.
>
> > However the SMP tests seem to crash on the RPi 2.
>
> > Does anyone know if the RPi 2 SMP works on the latest master? I know it
>
> > has worked in the past.
>
>
>
> I didn't test it. Do you have some details?
>
>
>
> I’m just starting to troubleshoot, but I build the raspberrypi2 BSP with
> –enable-smp.
>
> A few of the samples like ticker.exe and unlimited.exe work.
>
> But when I try smp01.exe, I don’t see any output past the model
> Identification that is printed by the BSP:
>
> RTEMS RPi 2B 1.1 (1GB) [00a21041]
>
>
>
> I commented out much of the code in smp01/init.c just to see if I could
> get the “test begin” banner, but did not see anything. (here is where the
> debugger would help!)
>
>
>
> Is the ticker.exe demo built differently than smp01.exe? These are both
> under the same build with the same configure options.
>
> I will try to continue my troubleshooting a little later.
>
>
>
>
>
> > I wouldn't mind dropping the Pi 2 once the Pi 3 is working.. The model
>
> > is being phased out anyway.
>
>
>
> Again: Still a lot of boards around. And quite possible that the older
>
> ones that are phased out of some Linux applications are used now for
>
> RTEMS stuff. So I'm not a fan of removing the support.
>
>
>
> That is fine with me. I read that there have been 30 million Raspberry Pis
> sold so far. I am trying to find a breakdown of that figure by model number.
>
>
>
> >
>
> > It looks like there is progress being made on the RPi 3. The mini uart
>
> > support may also work on the RPi Zero W, since it has the same
>
> > wireless/bluetooth model as the 3. I can try the Pi 3 out whenever it is
>
> > ready.
>
> > Thanks for all of the recent RPI updates!
>
>
>
> Please give a special thanks to Niteesh. He does most of the current
>
> raspberry work. And thank you for the repeated testing.
>
>
>
> Absolutely! Niteesh’s work to allow RTEMS to work on the Raspberry Pi 3 is
> very much appreciated!
>
>
>
> Thanks,
>
> Alan
>
>
>
> Best regards
>
>
>
> Christian
>
>
>
> > Alan
>
> >
>
> >
>
> >
>
> > On Wed, Jan 8, 2020 at 10:26 AM Alan Cudmore 
> > <mailto:alan.cudm...@gmail.com>> wrote:
>
> >
>
> > The Debian Linux variant for the Raspberry Pi (Raspbian) is still 32
>
> > bit for both the Pi 3 and 4, so I would think 32 bit ports would run
>
> > on both.
>
> > The Raspberry Pi 4 has a Quad Core A72, 1 to 4 Gigabytes of LPDDR4
>
> > SDRAM, Gigabit ethernet, USB 3, Wi-fi and bluetooth. I have not
>
> > looked into it enough to see what UARTs it uses.
>
> >
>
> > On Wed, Jan 8, 2020 at 1:18 AM Christian Mauderer
>
> > 
> > <mailto:christian.maude...@embedded-brains.de>> wrote:
>
> >
>
> > On 08/01/2020 00:24, Joel Sherrill wrote:
>
> > >
>
> > >
>
> >

Re: Raspberry Pi test report

[Alan Cudmore]

As it turns out the latest RTEMS master may need some of the dtb
and/or overlay files in the raspberry pi SD card. But the updated
instructions that Niteesh submitted for the raspberrypi BSP should
still be valid.

Either way, we should be able to automate it. A firmware release on
Github is ~180 megabytes. If you clone the whole repository, it's 10+
Gigabytes, probably because you get every binary release.

I'm trying to troubleshoot the RPi 2 SMP a little bit now. Non SMP
code seems to work on the Pi 2, but when you have an example with
#define CONFIGURE_MAXIMUM_PROCESSORS 4
it crashes during initialization.


On Mon, Jan 20, 2020 at 5:06 PM Chris Johns  wrote:
>
> On 6/1/20 9:42 am, Alan Cudmore wrote:
> > I finally found the time to try the latest RTEMS head on my collection of
> > Raspberry Pi models.
> > The last time I tried to run RTEMS on a Pi, I had trouble with the current
> > version of the Raspberry Pi Firmware, so I had to go back to a specific tag 
> > on
> > the Rasberry Pi firmware repository to get RTEMS to work. This time, the 
> > head of
> > the firmware repository seems to work (at least on the single core models)
> >
> > To keep things simple, I'm just going address the single core models here, 
> > I can
> > follow up after I finish testing the Raspberry Pi 2.
> >
> > Test Setup:
> > I used the git.rtems.org <http://git.rtems.org> rtems master from Jan 03 
> > 2020.
> > I used the Raspberry Pi firmware from the same date.
> > The firmware can be found here:
> > https://github.com/raspberrypi/firmware/tree/master/boot
> > To boot an RTEMS image, you can copy all files from the above "boot" 
> > directory
> > on a DOS formatted SD/MicroSD card along with the RTEMS image (more about 
> > that
> > in a minute).
> > On the SD card, I deleted the "dtb" files, as well as the overlay 
> > directory. I
> > dont think these are necessary to boot an RTEMS image.
>
> Interesting. Do you think support for this could be added to the RTEMS boot
> image tool?
>
> https://docs.rtems.org/branches/master/user/tools/boot-image.html
>
> It would be nice if we can automate the creation of an SD card image and
> abstract the low level host things needed to manage an SD card.
>
> I wonder if an option could be added to download and cache the boot files then
> that are copied to the SD card with the kernel image and a suitable config.
>
> Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Raspberry Pi test report

[Alan Cudmore]

A little more information on my Raspberry Pi 2 SMP tests:

The BSP startup is getting to this loop:
https://git.rtems.org/rtems/tree/cpukit/score/src/percpustatewait.c#n49
(In the function _Per_CPU_State_wait_for_non_initial_state)
In the while loop on line 49, the CPU state is PER_CPU_STATE_INITIAL (0).
The while loop calls _CPU_SMP_Processor_event_receive() and returns,
but the state is still 0
It calls _CPU_SMP_Processor_event_receive() again and does not return.

I'm reading up on the defines in percpu.h (comments for the defines
are very helpful by the way)
Based on what I can tell in the comments, the boot CPU will wait in
PER_CPU_STATE_INITIAL
until the secondary processors complete their primary initialization
and transition to
PER_CPU_STATE_READY_TO_START_MULTITASKING.

Next is to figure out why the secondary processors are not
transitioning or possibly why events are not occurring?

Alan

On Mon, Jan 20, 2020 at 6:25 PM Chris Johns  wrote:
>
> On 21/1/20 10:20 am, Alan Cudmore wrote:
> > As it turns out the latest RTEMS master may need some of the dtb
> > and/or overlay files in the raspberry pi SD card. But the updated
> > instructions that Niteesh submitted for the raspberrypi BSP should
> > still be valid.
>
> Great.
>
> > Either way, we should be able to automate it. A firmware release on
> > Github is ~180 megabytes. If you clone the whole repository, it's 10+
> > Gigabytes, probably because you get every binary release.
>
> Ouch. If we list the needed files, even if there is a few, I can fetch them 
> from
> github and avoid a full clone. We would need to settle on a specific hash or
> version but that is not a bad thing.
>
> > I'm trying to troubleshoot the RPi 2 SMP a little bit now. Non SMP
> > code seems to work on the Pi 2, but when you have an example with
> > #define CONFIGURE_MAXIMUM_PROCESSORS 4
> > it crashes during initialization.
>
> Awesome and all the best. I am sure you will figure it out.
>
> Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Raspberry Pi test report

[Alan Cudmore]

I don't really have a debug setup.. I'm just using printk for now. But
I have a pretty efficient setup where I can add a few printk
statements, rebuild and copy the smp01.exe sample over to the SD card.
I use this board:
https://www.adafruit.com/product/3589
It lets me connect the serial port using a USB cable, and it also
supplies power and provides a switch. I can pop the SD card in, flip
the switch and watch the UART output.
(Edit, make, objcopy, move card to pi, and flip the power switch).
The board provides plenty of power for the single core models through
the host USB port. I should double check that it's providing enough
power for the Pi2 before I spend too much time!

Here is an example of my latest output where the SMP initialization is
not completing:
RTEMS RPi 2B 1.1 (1GB) [00a21041]
in _SMP_Handler_initialize
in _SMP_Handler_initialize, max processors = 4
in _SMP_Handler_initialize - calling _CPU_SMP_Initialize
in _CPU_SMP_Initialize
in _SMP_Handler_initialize - _SMP_Processor_maximum = 4
in _SMP_Handler_initialize - calling _SMP_Start_processors
In _SMP_Start_processors
In _SMP_Start_processors - index = 0
In _SMP_Start_processors - index = 1
In _SMP_Start_processors - calling _CPU_SMP_Start_processor
in _CPU_SMP_Start_processor
in _CPU_SMP_Start_processor - wait for secondary processor to complete
in Per_CPU_State_wait_for_non_initial_state
 CPU state = 0
in Per_CPU_State_wait_for_non_initial_state - about to call
_CPU_SMP_Processor_event_receive in while loop
in Per_CPU_State_wait_for_non_initial_state - after
_CPU_SMP_Processor_event_receive in while loop
 CPU state  after = 0
in Per_CPU_State_wait_for_non_initial_state - about to call
_CPU_SMP_Processor_event_receive in while loop


Alan

On Mon, Jan 20, 2020 at 9:03 PM Niteesh  wrote:
>
> What is your debugging setup? It would be really helpful for my future works 
> on Rpi3.
>
> Thanks,
> Niteesh
>
> On Tue, 21 Jan, 2020, 7:23 AM Alan Cudmore,  wrote:
>>
>> A little more information on my Raspberry Pi 2 SMP tests:
>>
>> The BSP startup is getting to this loop:
>> https://git.rtems.org/rtems/tree/cpukit/score/src/percpustatewait.c#n49
>> (In the function _Per_CPU_State_wait_for_non_initial_state)
>> In the while loop on line 49, the CPU state is PER_CPU_STATE_INITIAL (0).
>> The while loop calls _CPU_SMP_Processor_event_receive() and returns,
>> but the state is still 0
>> It calls _CPU_SMP_Processor_event_receive() again and does not return.
>>
>> I'm reading up on the defines in percpu.h (comments for the defines
>> are very helpful by the way)
>> Based on what I can tell in the comments, the boot CPU will wait in
>> PER_CPU_STATE_INITIAL
>> until the secondary processors complete their primary initialization
>> and transition to
>> PER_CPU_STATE_READY_TO_START_MULTITASKING.
>>
>> Next is to figure out why the secondary processors are not
>> transitioning or possibly why events are not occurring?
>>
>> Alan
>>
>> On Mon, Jan 20, 2020 at 6:25 PM Chris Johns  wrote:
>> >
>> > On 21/1/20 10:20 am, Alan Cudmore wrote:
>> > > As it turns out the latest RTEMS master may need some of the dtb
>> > > and/or overlay files in the raspberry pi SD card. But the updated
>> > > instructions that Niteesh submitted for the raspberrypi BSP should
>> > > still be valid.
>> >
>> > Great.
>> >
>> > > Either way, we should be able to automate it. A firmware release on
>> > > Github is ~180 megabytes. If you clone the whole repository, it's 10+
>> > > Gigabytes, probably because you get every binary release.
>> >
>> > Ouch. If we list the needed files, even if there is a few, I can fetch 
>> > them from
>> > github and avoid a full clone. We would need to settle on a specific hash 
>> > or
>> > version but that is not a bad thing.
>> >
>> > > I'm trying to troubleshoot the RPi 2 SMP a little bit now. Non SMP
>> > > code seems to work on the Pi 2, but when you have an example with
>> > > #define CONFIGURE_MAXIMUM_PROCESSORS 4
>> > > it crashes during initialization.
>> >
>> > Awesome and all the best. I am sure you will figure it out.
>> >
>> > Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Raspberry Pi test report

[Alan Cudmore]

I can try QEMU. Is there a quick pointer to the QEMU parameters needed
to run a Pi2 image?
Alan

On Tue, Jan 21, 2020 at 3:22 PM Christian Mauderer  wrote:
>
> Does the same error occur on the Pi2 Qemu? In that case you could use it
> for proper debugging.
>
> On 21/01/2020 03:35, Alan Cudmore wrote:
> > I don't really have a debug setup.. I'm just using printk for now. But
> > I have a pretty efficient setup where I can add a few printk
> > statements, rebuild and copy the smp01.exe sample over to the SD card.
> > I use this board:
> > https://www.adafruit.com/product/3589
> > It lets me connect the serial port using a USB cable, and it also
> > supplies power and provides a switch. I can pop the SD card in, flip
> > the switch and watch the UART output.
> > (Edit, make, objcopy, move card to pi, and flip the power switch).
> > The board provides plenty of power for the single core models through
> > the host USB port. I should double check that it's providing enough
> > power for the Pi2 before I spend too much time!
> >
> > Here is an example of my latest output where the SMP initialization is
> > not completing:
> > RTEMS RPi 2B 1.1 (1GB) [00a21041]
> > in _SMP_Handler_initialize
> > in _SMP_Handler_initialize, max processors = 4
> > in _SMP_Handler_initialize - calling _CPU_SMP_Initialize
> > in _CPU_SMP_Initialize
> > in _SMP_Handler_initialize - _SMP_Processor_maximum = 4
> > in _SMP_Handler_initialize - calling _SMP_Start_processors
> > In _SMP_Start_processors
> > In _SMP_Start_processors - index = 0
> > In _SMP_Start_processors - index = 1
> > In _SMP_Start_processors - calling _CPU_SMP_Start_processor
> > in _CPU_SMP_Start_processor
> > in _CPU_SMP_Start_processor - wait for secondary processor to complete
> > in Per_CPU_State_wait_for_non_initial_state
> >  CPU state = 0
> > in Per_CPU_State_wait_for_non_initial_state - about to call
> > _CPU_SMP_Processor_event_receive in while loop
> > in Per_CPU_State_wait_for_non_initial_state - after
> > _CPU_SMP_Processor_event_receive in while loop
> >  CPU state  after = 0
> > in Per_CPU_State_wait_for_non_initial_state - about to call
> > _CPU_SMP_Processor_event_receive in while loop
> >
> >
> > Alan
> >
> > On Mon, Jan 20, 2020 at 9:03 PM Niteesh  wrote:
> >>
> >> What is your debugging setup? It would be really helpful for my future 
> >> works on Rpi3.
> >>
> >> Thanks,
> >> Niteesh
> >>
> >> On Tue, 21 Jan, 2020, 7:23 AM Alan Cudmore,  wrote:
> >>>
> >>> A little more information on my Raspberry Pi 2 SMP tests:
> >>>
> >>> The BSP startup is getting to this loop:
> >>> https://git.rtems.org/rtems/tree/cpukit/score/src/percpustatewait.c#n49
> >>> (In the function _Per_CPU_State_wait_for_non_initial_state)
> >>> In the while loop on line 49, the CPU state is PER_CPU_STATE_INITIAL (0).
> >>> The while loop calls _CPU_SMP_Processor_event_receive() and returns,
> >>> but the state is still 0
> >>> It calls _CPU_SMP_Processor_event_receive() again and does not return.
> >>>
> >>> I'm reading up on the defines in percpu.h (comments for the defines
> >>> are very helpful by the way)
> >>> Based on what I can tell in the comments, the boot CPU will wait in
> >>> PER_CPU_STATE_INITIAL
> >>> until the secondary processors complete their primary initialization
> >>> and transition to
> >>> PER_CPU_STATE_READY_TO_START_MULTITASKING.
> >>>
> >>> Next is to figure out why the secondary processors are not
> >>> transitioning or possibly why events are not occurring?
> >>>
> >>> Alan
> >>>
> >>> On Mon, Jan 20, 2020 at 6:25 PM Chris Johns  wrote:
> >>>>
> >>>> On 21/1/20 10:20 am, Alan Cudmore wrote:
> >>>>> As it turns out the latest RTEMS master may need some of the dtb
> >>>>> and/or overlay files in the raspberry pi SD card. But the updated
> >>>>> instructions that Niteesh submitted for the raspberrypi BSP should
> >>>>> still be valid.
> >>>>
> >>>> Great.
> >>>>
> >>>>> Either way, we should be able to automate it. A firmware release on
> >>>>> Github is ~180 megabytes. If you clone the whole repository, it's 10+
> >>>>> Gigabytes, probably because you get every binary release.
> >>>>
> >>>> Ouch. If we list the needed files, even if there is a few, I can fetch 
> >>>> them from
> >>>> github and avoid a full clone. We would need to settle on a specific 
> >>>> hash or
> >>>> version but that is not a bad thing.
> >>>>
> >>>>> I'm trying to troubleshoot the RPi 2 SMP a little bit now. Non SMP
> >>>>> code seems to work on the Pi 2, but when you have an example with
> >>>>> #define CONFIGURE_MAXIMUM_PROCESSORS 4
> >>>>> it crashes during initialization.
> >>>>
> >>>> Awesome and all the best. I am sure you will figure it out.
> >>>>
> >>>> Chris
> >
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] bsp/raspberrypi: Fix linker command file

[Alan Cudmore]

I believe we can discard this. I am running all of my recent tests
with the 0x20 RAM origin.
Thanks,
Alan

On Tue, Feb 11, 2020 at 2:06 AM Sebastian Huber
 wrote:
>
> Hello,
>
> I guess that after all the Raspberry Pi changes this patch can be discarded?
>
> On 20/12/2019 07:32, Sebastian Huber wrote:
> > The RTEMS entry point must be at 0x8000.
> >
> > Update #3774.
> > ---
> >   bsps/arm/raspberrypi/start/linkcmds.in | 13 ++---
> >   1 file changed, 6 insertions(+), 7 deletions(-)
> >
> > diff --git a/bsps/arm/raspberrypi/start/linkcmds.in 
> > b/bsps/arm/raspberrypi/start/linkcmds.in
> > index d99b4fe23e..fde75877e7 100644
> > --- a/bsps/arm/raspberrypi/start/linkcmds.in
> > +++ b/bsps/arm/raspberrypi/start/linkcmds.in
> > @@ -15,11 +15,12 @@
> >*/
> >
> >   MEMORY {
> > -  RAM_MMU (AIW) : ORIGIN = 0x0010, LENGTH = @RPI_RAM_MMU_LENGTH@
> > -  RAM (AIW) : ORIGIN = 0x0020, LENGTH = @RPI_RAM_LENGTH_AVAILABLE@ 
> > - @RPI_RAM_NOCACHE_LENGTH@
> > +  START (AIW) : ORIGIN = 0x8000, LENGTH = 0xf8000
> > +  MMU   (AIW) : ORIGIN = 0x0010, LENGTH = @RPI_RAM_MMU_LENGTH@
> > +  RAM   (AIW) : ORIGIN = 0x0020, LENGTH = @RPI_RAM_LENGTH_AVAILABLE@ - 
> > @RPI_RAM_NOCACHE_LENGTH@
> >   }
> >
> > -REGION_ALIAS ("REGION_START",  RAM);
> > +REGION_ALIAS ("REGION_START",  START);
> >   REGION_ALIAS ("REGION_VECTOR", RAM);
> >   REGION_ALIAS ("REGION_TEXT",   RAM);
> >   REGION_ALIAS ("REGION_TEXT_LOAD",  RAM);
> > @@ -41,9 +42,7 @@ bsp_stack_abt_size = DEFINED (bsp_stack_abt_size) ? 
> > bsp_stack_abt_size : 1024;
> >
> >   bsp_section_rwbarrier_align = DEFINED (bsp_section_rwbarrier_align) ? 
> > bsp_section_rwbarrier_align : 1M;
> >
> > -bsp_vector_table_in_start_section = 1;
> > -
> > -bsp_translation_table_base = ORIGIN (RAM_MMU);
> > -bsp_translation_table_end = ORIGIN (RAM_MMU) + LENGTH (RAM_MMU);
> > +bsp_translation_table_base = ORIGIN (MMU);
> > +bsp_translation_table_end = ORIGIN (MMU) + LENGTH (MMU);
> >
> >   INCLUDE linkcmds.armv4
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH v4] doc/raspberrypi: Added instructions for raspberrypi

[Alan Cudmore]

Hi Niteesh,
I have followed your instructions for getting RTEMS running on the Pi
1 and 2. SMP currently is not working on the 2 for me, but that is not
a problem with these instructions.
I started to try running on QEMU following your instructions but have
not been able to get time to complete my tests.

But this is a vast improvement over "TODO", so I recommend accepting
this change.

Thanks for creating this,
Alan

On Thu, Feb 13, 2020 at 1:49 AM G. S. Niteesh  wrote:
>
> Can someone take a look at this, It has been unnoticed for quite a while.
>
> Thank you,
> Niteesh
>
> On Sat, Jan 25, 2020 at 10:49 PM G S Niteesh  wrote:
>>
>> Added instructions to run examples on raspberrypi.
>> ---
>>  user/bsps/arm/raspberrypi.rst | 111 +-
>>  1 file changed, 110 insertions(+), 1 deletion(-)
>>
>> diff --git a/user/bsps/arm/raspberrypi.rst b/user/bsps/arm/raspberrypi.rst
>> index 4ef75bd..72889a5 100644
>> --- a/user/bsps/arm/raspberrypi.rst
>> +++ b/user/bsps/arm/raspberrypi.rst
>> @@ -5,4 +5,113 @@
>>  raspberrypi
>>  ===
>>
>> -TODO.
>> +This BSP supports `Raspberry Pi 1` and `Raspberry Pi 2` currently.
>> +The support for `Raspberry Pi 3` is work under progress.
>> +The default bootloader on the Raspberry Pi which is used to boot Raspbian
>> +or other OS can be also used to boot RTEMS. U-boot can also be used.
>> +
>> +Setup SD card
>> +
>> +
>> +The Raspberry Pis have an unconventional booting mechanism. The GPU
>> +boots first, initializes itself, runs the bootloader and starts the CPU.
>> +The bootloader looks for a kernel image, by default the kernel images must
>> +have a name of the form ``kernel*.img`` but this can be changed by adding
>> +`kernel=` to ``config.txt``.
>> +
>> +You must provide the required files for the GPU to proceed. These files
>> +can be downloaded from
>> +`the Raspberry Pi Firmware Repository 
>> `_.
>> +You can remove the ``kernel*.img`` files if you want too, but don't touch
>> +the other files.
>> +
>> +Copy these files in to a SD card with FAT filesystem.
>> +
>> +Kernel image
>> +
>> +
>> +The following steps show how to run ``hello.exe`` on a Raspberry Pi 2.
>> +The same instructions can be applied to Raspberry Pi 1 also.
>> +Other executables can be processed in a similar way.
>> +
>> +To create the kernel image:
>> +
>> +.. code-block:: none
>> +
>> + $ arm-rtems5-objcopy -Obinary hello.exe kernel.img
>> +
>> +Copy the kernel image to the SD card.
>> +
>> +Make sure you have these lines below, in your ``config.txt``.
>> +
>> +.. code-block:: none
>> +
>> + enable-uart=1
>> + kernel_address=0x20
>> + kernel=kernel.img
>> +
>> +Testing using QEMU
>> +--
>> +
>> +QEMU can be built using RSB. Navigate to ``/rtems``
>> +and run this command.
>> +
>> +.. code-block:: none
>> +
>> + $ ../source-builder/sb-set-builder --prefix= 
>> devel/qemu4.bset
>> +
>> +**Note**: Replace  and  with the
>> +correct path of the directories. For example, if you used quick-start 
>> section
>> +as your reference, these two will be ``$HOME/quick-start/src/rsb`` and
>> +``$HOME/quick-start/rtems/5`` respectively,
>> +
>> +QEMU along with GDB can be used for debugging, but it only supports
>> +Raspberry Pi 2 and the emulation is also incomplete. So some of the
>> +features might not work as expected.
>> +
>> +Make sure your version of QEMU is newer than v2.6, because older ones don't
>> +support Raspberry Pis.
>> +
>> +.. code-block:: none
>> +
>> + $ qemu-system-arm -M raspi2 -m 1G -kernel hello.exe -serial mon:stdio 
>> -nographic -S -s
>> +
>> +This starts QEMU and creates a socket at port ``localhost:1234`` for GDB to
>> +connect.
>> +
>> +The Device Tree Blob (DTB) is needed to load the device tree while starting 
>> up
>> +the kernel. The BSP uses information from this file to initialize the 
>> drivers.
>> +
>> +Make sure you pass in the correct DTB file. There are currently two version 
>> of
>> +DTB for the Raspberry Pi 2 ``bcm2709-rpi-2-b.dtb`` and 
>> ``bcm2710-rpi-2-b.dtb``.
>> +The ``bcm2709-rpi-2-b.dtb`` is for Raspberry Pi 2 Model B and
>> +``bcm2710-rpi-2-b.dtb`` is for Raspberry Pi 2 Model B v1.2
>> +
>> +We need to pass in the DTB file to GDB before running the example.
>> +
>> +In a new terminal, run GDB using
>> +
>> +.. code-block:: none
>> +
>> + $ arm-rtems5-gdb hello.exe
>> +
>> +This will open GDB and will load the symbol table from hello.exe. Issue the
>> +following commands in the GDB prompt.
>> +
>> +.. code-block:: none
>> +
>> + (gdb) tar remote:1234
>> + (gdb) load
>> + (gdb) restore bcm2709-rpi-2-b.dtb binary 0x2ef0
>> + (gdb) set $r2 = 0x2ef0
>> +
>> +This will connect GDB to QEMU and will load the DTB file and the 
>> application.
>> +
>> +.. code-block:: none
>> +
>> + (gdb) continue
>> +
>> +The ``continue`` command will run the executable.
>> +
>> +**Note**

Re: [PATCH v4] doc/raspberrypi: Added instructions for raspberrypi

[Alan Cudmore]

I get exceptions when trying to run hello.exe.
I'm using qemu-system-arm v 2.11.1 from ubuntu. Should I try using the
one built by RSB?
I was trying to get this setup to try RPI 2 SMP in QEMU. I may want to
get the latest repo and do a clean build to try this again.
Thanks,
Alan

On Thu, Feb 13, 2020 at 12:12 PM G. S. Niteesh  wrote:
>
> On Thu, Feb 13, 2020 at 10:40 PM Alan Cudmore  wrote:
>>
>> Hi Niteesh,
>> I have followed your instructions for getting RTEMS running on the Pi
>> 1 and 2. SMP currently is not working on the 2 for me, but that is not
>> a problem with these instructions.
>> I started to try running on QEMU following your instructions but have
>> not been able to get time to complete my tests.
>
> What problem are you exactly facing?
>>
>>
>>
>> But this is a vast improvement over "TODO", so I recommend accepting
>> this change.
>>
>> Thanks for creating this,
>> Alan
>>
>> On Thu, Feb 13, 2020 at 1:49 AM G. S. Niteesh  wrote:
>> >
>> > Can someone take a look at this, It has been unnoticed for quite a while.
>> >
>> > Thank you,
>> > Niteesh
>> >
>> > On Sat, Jan 25, 2020 at 10:49 PM G S Niteesh  wrote:
>> >>
>> >> Added instructions to run examples on raspberrypi.
>> >> ---
>> >>  user/bsps/arm/raspberrypi.rst | 111 +-
>> >>  1 file changed, 110 insertions(+), 1 deletion(-)
>> >>
>> >> diff --git a/user/bsps/arm/raspberrypi.rst b/user/bsps/arm/raspberrypi.rst
>> >> index 4ef75bd..72889a5 100644
>> >> --- a/user/bsps/arm/raspberrypi.rst
>> >> +++ b/user/bsps/arm/raspberrypi.rst
>> >> @@ -5,4 +5,113 @@
>> >>  raspberrypi
>> >>  ===
>> >>
>> >> -TODO.
>> >> +This BSP supports `Raspberry Pi 1` and `Raspberry Pi 2` currently.
>> >> +The support for `Raspberry Pi 3` is work under progress.
>> >> +The default bootloader on the Raspberry Pi which is used to boot Raspbian
>> >> +or other OS can be also used to boot RTEMS. U-boot can also be used.
>> >> +
>> >> +Setup SD card
>> >> +
>> >> +
>> >> +The Raspberry Pis have an unconventional booting mechanism. The GPU
>> >> +boots first, initializes itself, runs the bootloader and starts the CPU.
>> >> +The bootloader looks for a kernel image, by default the kernel images 
>> >> must
>> >> +have a name of the form ``kernel*.img`` but this can be changed by adding
>> >> +`kernel=` to ``config.txt``.
>> >> +
>> >> +You must provide the required files for the GPU to proceed. These files
>> >> +can be downloaded from
>> >> +`the Raspberry Pi Firmware Repository 
>> >> <https://github.com/raspberrypi/firmware/tree/master/boot>`_.
>> >> +You can remove the ``kernel*.img`` files if you want too, but don't touch
>> >> +the other files.
>> >> +
>> >> +Copy these files in to a SD card with FAT filesystem.
>> >> +
>> >> +Kernel image
>> >> +
>> >> +
>> >> +The following steps show how to run ``hello.exe`` on a Raspberry Pi 2.
>> >> +The same instructions can be applied to Raspberry Pi 1 also.
>> >> +Other executables can be processed in a similar way.
>> >> +
>> >> +To create the kernel image:
>> >> +
>> >> +.. code-block:: none
>> >> +
>> >> + $ arm-rtems5-objcopy -Obinary hello.exe kernel.img
>> >> +
>> >> +Copy the kernel image to the SD card.
>> >> +
>> >> +Make sure you have these lines below, in your ``config.txt``.
>> >> +
>> >> +.. code-block:: none
>> >> +
>> >> + enable-uart=1
>> >> + kernel_address=0x20
>> >> + kernel=kernel.img
>> >> +
>> >> +Testing using QEMU
>> >> +--
>> >> +
>> >> +QEMU can be built using RSB. Navigate to ``/rtems``
>> >> +and run this command.
>> >> +
>> >> +.. code-block:: none
>> >> +
>> >> + $ ../source-builder/sb-set-builder --prefix= 
>> >> devel/qemu4.bset
>> >> +
>> >> +**Note**: Replace  and  with 
>> >> the
>> >> +correct path of the directories. For example, if you used quick-start 
>> >> sec

Re: [PATCH v4] doc/raspberrypi: Added instructions for raspberrypi

[Alan Cudmore]

"set scheduler-locking on" in GDB works! I was able to run RPI2 hello.exe

So I consider your instructions ready to go in the repo.
More Pi 2 SMP debugging when I get the time..
Thanks!
Alan

On Thu, Feb 13, 2020 at 12:30 PM G. S. Niteesh  wrote:
>
> On Thu, Feb 13, 2020 at 10:57 PM Alan Cudmore  wrote:
>>
>> I get exceptions when trying to run hello.exe.
>> I'm using qemu-system-arm v 2.11.1 from ubuntu. Should I try using the
>> one built by RSB?
>
> No this should be fine. Can you post a screenshot of the output?
>>
>> I was trying to get this setup to try RPI 2 SMP in QEMU. I may want to
>> get the latest repo and do a clean build to try this again.
>
> SMP doesn't work well with QEMU. Did you try set scheduler-locking on in GDB?
> Running the executables directly in QEMU doesn't work.
>>
>> Thanks,
>> Alan
>>
>> On Thu, Feb 13, 2020 at 12:12 PM G. S. Niteesh  wrote:
>> >
>> > On Thu, Feb 13, 2020 at 10:40 PM Alan Cudmore  
>> > wrote:
>> >>
>> >> Hi Niteesh,
>> >> I have followed your instructions for getting RTEMS running on the Pi
>> >> 1 and 2. SMP currently is not working on the 2 for me, but that is not
>> >> a problem with these instructions.
>> >> I started to try running on QEMU following your instructions but have
>> >> not been able to get time to complete my tests.
>> >
>> > What problem are you exactly facing?
>> >>
>> >>
>> >>
>> >> But this is a vast improvement over "TODO", so I recommend accepting
>> >> this change.
>> >>
>> >> Thanks for creating this,
>> >> Alan
>> >>
>> >> On Thu, Feb 13, 2020 at 1:49 AM G. S. Niteesh  wrote:
>> >> >
>> >> > Can someone take a look at this, It has been unnoticed for quite a 
>> >> > while.
>> >> >
>> >> > Thank you,
>> >> > Niteesh
>> >> >
>> >> > On Sat, Jan 25, 2020 at 10:49 PM G S Niteesh  wrote:
>> >> >>
>> >> >> Added instructions to run examples on raspberrypi.
>> >> >> ---
>> >> >>  user/bsps/arm/raspberrypi.rst | 111 +-
>> >> >>  1 file changed, 110 insertions(+), 1 deletion(-)
>> >> >>
>> >> >> diff --git a/user/bsps/arm/raspberrypi.rst 
>> >> >> b/user/bsps/arm/raspberrypi.rst
>> >> >> index 4ef75bd..72889a5 100644
>> >> >> --- a/user/bsps/arm/raspberrypi.rst
>> >> >> +++ b/user/bsps/arm/raspberrypi.rst
>> >> >> @@ -5,4 +5,113 @@
>> >> >>  raspberrypi
>> >> >>  ===
>> >> >>
>> >> >> -TODO.
>> >> >> +This BSP supports `Raspberry Pi 1` and `Raspberry Pi 2` currently.
>> >> >> +The support for `Raspberry Pi 3` is work under progress.
>> >> >> +The default bootloader on the Raspberry Pi which is used to boot 
>> >> >> Raspbian
>> >> >> +or other OS can be also used to boot RTEMS. U-boot can also be used.
>> >> >> +
>> >> >> +Setup SD card
>> >> >> +
>> >> >> +
>> >> >> +The Raspberry Pis have an unconventional booting mechanism. The GPU
>> >> >> +boots first, initializes itself, runs the bootloader and starts the 
>> >> >> CPU.
>> >> >> +The bootloader looks for a kernel image, by default the kernel images 
>> >> >> must
>> >> >> +have a name of the form ``kernel*.img`` but this can be changed by 
>> >> >> adding
>> >> >> +`kernel=` to ``config.txt``.
>> >> >> +
>> >> >> +You must provide the required files for the GPU to proceed. These 
>> >> >> files
>> >> >> +can be downloaded from
>> >> >> +`the Raspberry Pi Firmware Repository 
>> >> >> <https://github.com/raspberrypi/firmware/tree/master/boot>`_.
>> >> >> +You can remove the ``kernel*.img`` files if you want too, but don't 
>> >> >> touch
>> >> >> +the other files.
>> >> >> +
>> >> >> +Copy these files in to a SD card with FAT filesystem.
>> >> >> +
>> >> >> +Kernel image
>> >> >> +
>> 

Re: [PATCH v3 2/2] bsp/raspberrypi: Mini UART driver

[Alan Cudmore]

Hi Niteesh,
I can try this patch on my Pi 3. Which BSP should I use? Is there any
special setup or BSP configuration needed?
Thanks,
Alan

On Sun, Feb 16, 2020 at 2:35 AM G. S. Niteesh  wrote:
>
> Hii,
> This is a reminder message since this patch has been unnoticed for a while.
> I have tested it on Raspberry Pi 3 and it works fine. There is also another 
> patch
> https://lists.rtems.org/pipermail/devel/2020-February/057194.html, please
> do have a look at these.
>
> Thank you.
> Niteesh
> On Mon, Feb 10, 2020 at 12:52 AM G S Niteesh  wrote:
>>
>> This patch adds driver for Mini UART present in Raspberry Pi 3
>> and above, this UART is currently used as the primary UART in
>> these models.
>> The Mini UART is similar to ns16550, this driver is built
>> upon libchip/ns16550.
>> ---
>>  bsps/arm/raspberrypi/console/console-config.c | 118 --
>>  bsps/arm/raspberrypi/include/bsp/usart.h  |   1 +
>>  2 files changed, 110 insertions(+), 9 deletions(-)
>>
>> diff --git a/bsps/arm/raspberrypi/console/console-config.c 
>> b/bsps/arm/raspberrypi/console/console-config.c
>> index 48c4c6a3ec..62196786dd 100644
>> --- a/bsps/arm/raspberrypi/console/console-config.c
>> +++ b/bsps/arm/raspberrypi/console/console-config.c
>> @@ -24,6 +24,7 @@
>>
>>  #include 
>>  #include 
>> +#include 
>>
>>  #include 
>>  #include 
>> @@ -34,35 +35,103 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>> +#include 
>>
>> -
>> -#define UART0 "/dev/ttyS0"
>> +/**
>> + * UART0 - PL011
>> + * UART1 - Mini UART
>> + */
>> +#define PL011 "/dev/ttyAMA0"
>> +#define MINIUART  "/dev/ttyS0"
>>  #define FBCONS"/dev/fbcons"
>>
>>  arm_pl011_context pl011_context;
>> +ns16550_context mini_uart_context;
>>
>>  rpi_fb_context fb_context;
>>
>> -static void output_char_serial(char c)
>> +static void output_char_pl011(char c)
>>  {
>>arm_pl011_write_polled(&pl011_context.base, c);
>>  }
>>
>> +static void output_char_mini_uart(char c)
>> +{
>> +  ns16550_polled_putchar(&mini_uart_context.base, c);
>> +}
>> +
>>  void output_char_fb(char c)
>>  {
>>fbcons_write_polled(&fb_context.base, c);
>>  }
>>
>> +static uint8_t mini_uart_get_reg(uintptr_t port, uint8_t index)
>> +{
>> +  volatile uint32_t *val = (volatile uint32_t *)port + index;
>> +  return (uint8_t) *val;
>> +}
>> +
>> +static void mini_uart_set_reg(uintptr_t port, uint8_t index, uint8_t val)
>> +{
>> +  volatile uint32_t *reg = (volatile uint32_t *)port + index;
>> +  *reg = val;
>> +}
>> +
>>  static void init_ctx_arm_pl011(
>>const void *fdt,
>>int node
>>  )
>>  {
>>arm_pl011_context *ctx = &pl011_context;
>> -  rtems_termios_device_context_initialize(&ctx->base, "UART");
>> +  rtems_termios_device_context_initialize(&ctx->base, "PL011UART");
>>ctx->regs = raspberrypi_get_reg_of_node(fdt, node);
>>  }
>>
>> +static uint32_t calculate_baud_divisor(
>> +  ns16550_context *ctx,
>> +  uint32_t baud
>> +)
>> +{
>> +  uint32_t baudDivisor = (ctx->clock / (8 * baud)) - 1;
>> +  return baudDivisor;
>> +}
>> +
>> +static void init_ctx_mini_uart(
>> +  const void *fdt,
>> +  int node
>> +)
>> +{
>> +  const char *status;
>> +  int len;
>> +  ns16550_context *ctx;
>> +
>> +  memset(&mini_uart_context, 0, sizeof(mini_uart_context));
>> +  ctx = &mini_uart_context;
>> +
>> +  rtems_termios_device_context_initialize(&ctx->base, "MiniUART");
>> +
>> +  status = fdt_getprop(fdt, node, "status", &len);
>> +  if ( status == NULL || strcmp(status, "disabled" ) == 0){
>> +return ;
>> +  }
>> +
>> +  ctx->port = (uintptr_t) raspberrypi_get_reg_of_node(fdt, node);
>> +  ctx->initial_baud = MINI_UART_DEFAULT_BAUD;
>> +  ctx->clock = BCM2835_CLOCK_FREQ;
>> +  ctx->calculate_baud_divisor = calculate_baud_divisor;
>> +  ctx->get_reg = mini_uart_get_reg;
>> +  ctx->set_reg = mini_uart_set_reg;
>> +
>> +  rtems_gpio_bsp_select_specific_io(0, 14, RPI_ALT_FUNC_5, NULL);
>> +  rtems_gpio_bsp_select_specific_io(0, 15, RPI_ALT_FUNC_5, NULL);
>> +  rtems_gpio_bsp_set_resistor_mode(0, 14, NO_PULL_RESISTOR);
>> +  rtems_gpio_bsp_set_resistor_mode(0, 15, NO_PULL_RESISTOR);
>> +
>> +  BCM2835_REG(AUX_ENABLES) |= 0x1;
>> +  ns16550_probe(&ctx->base);
>> +}
>> +
>>  static void register_fb( void )
>>  {
>>if (fbcons_probe(&fb_context.base) == true) {
>> @@ -87,16 +156,28 @@ static void console_select( void )
>>  link(FBCONS, CONSOLE_DEVICE_NAME);
>>  return ;
>>}
>> +} else if ( strncmp( opt, MINIUART, sizeof(MINIUART) - 1 ) == 0) {
>> +  BSP_output_char = output_char_mini_uart;
>> +  link(MINIUART, CONSOLE_DEVICE_NAME);
>> +} else if ( strncmp( opt, PL011, sizeof(PL011) - 1 ) == 0) {
>> +  BSP_output_char = output_char_pl011;
>> +  link(PL011, CONSOLE_DEVICE_NAME);
>>  }
>> +  }else {
>> +/**
>> + * If no command line option was given, default to PL011.
>> + */
>> +BSP_output_char = output_char_pl011;
>> +link(PL011, CONSOLE_DEVICE_NAME);
>>}
>> -  BSP_output_char = output_char_ser

Re: [PATCH v3 2/2] bsp/raspberrypi: Mini UART driver

[Alan Cudmore]

I tried running my raspberrypi BSP image that worked on the Pi Zero
and W, but it did not work on the Pi 3.

I built the raspberrypi2 BSP, used objcopy to copy the binary to my sd
card as kernel7.img, and it works on my Pi 3 and Pi3 A+ ( without
ethernet) . Note that my config.txt file does not specify the kernel
image, so the firmware defaults to kernel.img for the single core
models and kernel7.img for the 2 and 3.

I probably wont get a chance to try u-boot until later today or tomorrow.

But these patches are great for enabling the Pi Zero W and Pi 3 models!
Thanks,
Alan

On Sun, Feb 16, 2020 at 10:58 AM G. S. Niteesh  wrote:
>
> On Sun, Feb 16, 2020 at 8:37 PM Alan Cudmore  wrote:
>>
>> Hi Niteesh,
>> I can try this patch on my Pi 3. Which BSP should I use? Is there any
>> special setup or BSP configuration needed?
>> Thanks,
>> Alan
>
> Hi Alan,
> First of all, thank you for taking this initiative.
> I have tried using the default bootloader in Pi3 to load RTEMS but it doesn't 
> work,
> Can you try it?
> The currently use U-Boot in 32bit mode as the bootloader.
> You can use the below instructions to build U-Boot in 32bit mode
>
> git clone https://github.com/u-boot/u-boot.git u-boot
> cd u-boot
> git revert 995eab8b5b580b67394312b1621c60a71042cd18
> make CROSS_COMPILE=arm-linux-gnueabi- rpi_3_32b_defconfig
> make CROSS_COMPILE=arm-linux-gnueabi-
>
> This one uses an old version of U-Boot and I don't know if there is
> a new way to build in 32bit mode.
>
> To build the U-Boot image of RTEMS you can use the below instructions
>
> arm-rtems5-objcopy -Obinary hello.exe kernel.img
> mkimage -A arm -O linux -T kernel -a 0x20 -e 0x200080 -d kernel.img -C 
> none rtems.img
>
> To load and run in U-Boot
>
> fatload mmc 0 0x20 rtems.img
> fatload mmc 0 0x1000 bcm2710-rpi-3-b.dtb
> bootm 0x20 - 0x1000
>
> And to make your U-Boot build process simpler I have uploaded my u-boot.bin
> to my github, please use it :)
> https://github.com/gs-niteesh/rpi3_RTEMS
>
> And sorry for the delay, I tested all these instructions again before sending 
> them.
>
> Thanks
> Niteesh.
>
>   On Sun, Feb 16, 2020 at 2:35 AM G. S. Niteesh  wrote:
>>
>> >
>> > Hii,
>> > This is a reminder message since this patch has been unnoticed for a while.
>> > I have tested it on Raspberry Pi 3 and it works fine. There is also 
>> > another patch
>> > https://lists.rtems.org/pipermail/devel/2020-February/057194.html, please
>> > do have a look at these.
>> >
>> > Thank you.
>> > Niteesh
>> > On Mon, Feb 10, 2020 at 12:52 AM G S Niteesh  wrote:
>> >>
>> >> This patch adds driver for Mini UART present in Raspberry Pi 3
>> >> and above, this UART is currently used as the primary UART in
>> >> these models.
>> >> The Mini UART is similar to ns16550, this driver is built
>> >> upon libchip/ns16550.
>> >> ---
>> >>  bsps/arm/raspberrypi/console/console-config.c | 118 --
>> >>  bsps/arm/raspberrypi/include/bsp/usart.h  |   1 +
>> >>  2 files changed, 110 insertions(+), 9 deletions(-)
>> >>
>> >> diff --git a/bsps/arm/raspberrypi/console/console-config.c 
>> >> b/bsps/arm/raspberrypi/console/console-config.c
>> >> index 48c4c6a3ec..62196786dd 100644
>> >> --- a/bsps/arm/raspberrypi/console/console-config.c
>> >> +++ b/bsps/arm/raspberrypi/console/console-config.c
>> >> @@ -24,6 +24,7 @@
>> >>
>> >>  #include 
>> >>  #include 
>> >> +#include 
>> >>
>> >>  #include 
>> >>  #include 
>> >> @@ -34,35 +35,103 @@
>> >>  #include 
>> >>  #include 
>> >>  #include 
>> >> +#include 
>> >> +#include 
>> >>
>> >> -
>> >> -#define UART0 "/dev/ttyS0"
>> >> +/**
>> >> + * UART0 - PL011
>> >> + * UART1 - Mini UART
>> >> + */
>> >> +#define PL011 "/dev/ttyAMA0"
>> >> +#define MINIUART  "/dev/ttyS0"
>> >>  #define FBCONS"/dev/fbcons"
>> >>
>> >>  arm_pl011_context pl011_context;
>> >> +ns16550_context mini_uart_context;
>> >>
>> >>  rpi_fb_context fb_context;
>> >>
>> >> -static void output_char_serial(char c)
>> >> +static void output_char_pl011(char c)
>> >>  {
>> >>a

Re: [PATCH v3 2/2] bsp/raspberrypi: Mini UART driver

[Alan Cudmore]

I'm definitely using the kernel_address, but letting the firmware
decide what image to boot. For me kernel.img is the single core ARM
images. kernel7.img is used for the raspberry pi 2 and 3. With these
names, I can have both images on the same SD card to test in all of my
Pis.


my config.txt:
enable_uart=1
kernel_address=0x20


On Sun, Feb 16, 2020 at 11:44 AM Christian Mauderer  wrote:
>
> On 16/02/2020 17:31, G. S. Niteesh wrote:
> > Can you please share your config.txt for Pi3.
>
> +1
>
> It's interesting that it seems to work without an adapted config.txt. It
> should be at least necessary to define the start address.
>
> >
> > Thanks,
> > Niteesh
> >
> > On Sun, Feb 16, 2020 at 9:58 PM Alan Cudmore  > <mailto:alan.cudm...@gmail.com>> wrote:
> >
> > I tried running my raspberrypi BSP image that worked on the Pi Zero
> > and W, but it did not work on the Pi 3.
> >
> > I built the raspberrypi2 BSP, used objcopy to copy the binary to my sd
> > card as kernel7.img, and it works on my Pi 3 and Pi3 A+ ( without
> > ethernet) . Note that my config.txt file does not specify the kernel
> > image, so the firmware defaults to kernel.img for the single core
> > models and kernel7.img for the 2 and 3.
> >
> > I probably wont get a chance to try u-boot until later today or
> > tomorrow.
> >
> > But these patches are great for enabling the Pi Zero W and Pi 3 models!
> > Thanks,
> > Alan
> >
> > On Sun, Feb 16, 2020 at 10:58 AM G. S. Niteesh  > <mailto:gsnb...@gmail.com>> wrote:
> > >
> > > On Sun, Feb 16, 2020 at 8:37 PM Alan Cudmore
> > mailto:alan.cudm...@gmail.com>> wrote:
> > >>
> > >> Hi Niteesh,
> > >> I can try this patch on my Pi 3. Which BSP should I use? Is there any
> > >> special setup or BSP configuration needed?
> > >> Thanks,
> > >> Alan
> > >
> > > Hi Alan,
> > > First of all, thank you for taking this initiative.
> > > I have tried using the default bootloader in Pi3 to load RTEMS but
> > it doesn't work,
> > > Can you try it?
> > > The currently use U-Boot in 32bit mode as the bootloader.
> > > You can use the below instructions to build U-Boot in 32bit mode
> > >
> > > git clone https://github.com/u-boot/u-boot.git u-boot
> > > cd u-boot
> > > git revert 995eab8b5b580b67394312b1621c60a71042cd18
> > > make CROSS_COMPILE=arm-linux-gnueabi- rpi_3_32b_defconfig
> > > make CROSS_COMPILE=arm-linux-gnueabi-
> > >
> > > This one uses an old version of U-Boot and I don't know if there is
> > > a new way to build in 32bit mode.
> > >
> > > To build the U-Boot image of RTEMS you can use the below instructions
> > >
> > > arm-rtems5-objcopy -Obinary hello.exe kernel.img
> > > mkimage -A arm -O linux -T kernel -a 0x20 -e 0x200080 -d
> > kernel.img -C none rtems.img
> > >
> > > To load and run in U-Boot
> > >
> > > fatload mmc 0 0x20 rtems.img
> > > fatload mmc 0 0x1000 bcm2710-rpi-3-b.dtb
> > > bootm 0x20 - 0x1000
> > >
> > > And to make your U-Boot build process simpler I have uploaded my
> > u-boot.bin
> > > to my github, please use it :)
> > > https://github.com/gs-niteesh/rpi3_RTEMS
> > >
> > > And sorry for the delay, I tested all these instructions again
> > before sending them.
> > >
> > > Thanks
> > > Niteesh.
> > >
> > >   On Sun, Feb 16, 2020 at 2:35 AM G. S. Niteesh  > <mailto:gsnb...@gmail.com>> wrote:
> > >>
> > >> >
> > >> > Hii,
> > >> > This is a reminder message since this patch has been unnoticed
> > for a while.
> > >> > I have tested it on Raspberry Pi 3 and it works fine. There is
> > also another patch
> > >> >
> > https://lists.rtems.org/pipermail/devel/2020-February/057194.html,
> > please
> > >> > do have a look at these.
> > >> >
> > >> > Thank you.
> > >> > Niteesh
> > >> > On Mon, Feb 10, 2020 at 12:52 AM G S Niteesh  > <mailto:gsnb...@gmail.com>> wrote:
> >

Re: [PATCH v3 2/2] bsp/raspberrypi: Mini UART driver

[Alan Cudmore]

Awesome! The Pi Zero W is a bonus too! I think we can run RTEMS on all
models except the Pi 4 now.

On Sun, Feb 16, 2020 at 12:30 PM G. S. Niteesh  wrote:
>
> Hii Alan,
>
> I tested it on my Raspberry Pi 3 model b v1.2 and it works.
> U-Boot is not required anymore :)
>
> Thanks,
> Niteesh.
>
> On Sun, Feb 16, 2020 at 10:51 PM Alan Cudmore  wrote:
>>
>> I'm definitely using the kernel_address, but letting the firmware
>> decide what image to boot. For me kernel.img is the single core ARM
>> images. kernel7.img is used for the raspberry pi 2 and 3. With these
>> names, I can have both images on the same SD card to test in all of my
>> Pis.
>>
>>
>> my config.txt:
>> enable_uart=1
>> kernel_address=0x20
>>
>>
>> On Sun, Feb 16, 2020 at 11:44 AM Christian Mauderer  
>> wrote:
>> >
>> > On 16/02/2020 17:31, G. S. Niteesh wrote:
>> > > Can you please share your config.txt for Pi3.
>> >
>> > +1
>> >
>> > It's interesting that it seems to work without an adapted config.txt. It
>> > should be at least necessary to define the start address.
>> >
>> > >
>> > > Thanks,
>> > > Niteesh
>> > >
>> > > On Sun, Feb 16, 2020 at 9:58 PM Alan Cudmore > > > <mailto:alan.cudm...@gmail.com>> wrote:
>> > >
>> > > I tried running my raspberrypi BSP image that worked on the Pi Zero
>> > > and W, but it did not work on the Pi 3.
>> > >
>> > > I built the raspberrypi2 BSP, used objcopy to copy the binary to my 
>> > > sd
>> > > card as kernel7.img, and it works on my Pi 3 and Pi3 A+ ( without
>> > > ethernet) . Note that my config.txt file does not specify the kernel
>> > > image, so the firmware defaults to kernel.img for the single core
>> > > models and kernel7.img for the 2 and 3.
>> > >
>> > > I probably wont get a chance to try u-boot until later today or
>> > > tomorrow.
>> > >
>> > > But these patches are great for enabling the Pi Zero W and Pi 3 
>> > > models!
>> > > Thanks,
>> > > Alan
>> > >
>> > > On Sun, Feb 16, 2020 at 10:58 AM G. S. Niteesh > > > <mailto:gsnb...@gmail.com>> wrote:
>> > > >
>> > > > On Sun, Feb 16, 2020 at 8:37 PM Alan Cudmore
>> > > mailto:alan.cudm...@gmail.com>> wrote:
>> > > >>
>> > > >> Hi Niteesh,
>> > > >> I can try this patch on my Pi 3. Which BSP should I use? Is there 
>> > > any
>> > > >> special setup or BSP configuration needed?
>> > > >> Thanks,
>> > > >> Alan
>> > > >
>> > > > Hi Alan,
>> > > > First of all, thank you for taking this initiative.
>> > > > I have tried using the default bootloader in Pi3 to load RTEMS but
>> > > it doesn't work,
>> > > > Can you try it?
>> > > > The currently use U-Boot in 32bit mode as the bootloader.
>> > > > You can use the below instructions to build U-Boot in 32bit mode
>> > > >
>> > > > git clone https://github.com/u-boot/u-boot.git u-boot
>> > > > cd u-boot
>> > > > git revert 995eab8b5b580b67394312b1621c60a71042cd18
>> > > > make CROSS_COMPILE=arm-linux-gnueabi- rpi_3_32b_defconfig
>> > > > make CROSS_COMPILE=arm-linux-gnueabi-
>> > > >
>> > > > This one uses an old version of U-Boot and I don't know if there is
>> > > > a new way to build in 32bit mode.
>> > > >
>> > > > To build the U-Boot image of RTEMS you can use the below 
>> > > instructions
>> > > >
>> > > > arm-rtems5-objcopy -Obinary hello.exe kernel.img
>> > > > mkimage -A arm -O linux -T kernel -a 0x20 -e 0x200080 -d
>> > > kernel.img -C none rtems.img
>> > > >
>> > > > To load and run in U-Boot
>> > > >
>> > > > fatload mmc 0 0x20 rtems.img
>> > > > fatload mmc 0 0x1000 bcm2710-rpi-3-b.dtb
>> > > > bootm 0x20 - 0x1000
>> > > >
>> > > > And to make your U-Boot build process simpler

Device Tree Blob for Beaglebone Black?

[Alan Cudmore]

I have been trying to bring up RTEMS with rtems-libbsd on the
beaglebone black (latest master).

I can run the regular RTEMS samples on the board, and a couple of the
rtems-libbsd testsuite examples run as well.

The samples such as ping01 and usb01 get a fatal exception in the
function fdt_ro_probe_ , leading me to believe that maybe I am not
using the correct device tree blob.

I'm using the instructions here:
https://git.rtems.org/rtems-docs/tree/user/bsps/arm/beagle.rst

And I have am loading am335x-boneblack.dtb that I copied from a linux
u-boot build. The instructions talk about getting the one from the
FreeBSD repository, but there are many other files included in that
dts source.

What dtb is normally used for the Beaglebone black RTEMS libbsd testing?

Is the dtb needed for the non-libbsd BSP?

Also, is the ethernet supported on the RTEMS beagle BSP, or do I need
libbsd to get ethernet?

Thanks,
Alan
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Device Tree Blob for Beaglebone Black?

[Alan Cudmore]

Hi Christian,
Thanks for the quick response. I followed the instructions in the
docs.rtems.org manual and generated the dtb from the FreeBSD commit
that Vijay suggested. It still resulted in an exception in the same
function.

Do you know if a specific commit of rtems-libbsd is required to work
with that dtb?
I tried master, and then the "5-freebsd-12" branch.

Thanks,
Alan

On Sun, Feb 23, 2020 at 11:32 AM Christian Mauderer  wrote:
>
> On 23/02/2020 17:07, Alan Cudmore wrote:
> > I have been trying to bring up RTEMS with rtems-libbsd on the
> > beaglebone black (latest master).
> >
> > I can run the regular RTEMS samples on the board, and a couple of the
> > rtems-libbsd testsuite examples run as well.
> >
> > The samples such as ping01 and usb01 get a fatal exception in the
> > function fdt_ro_probe_ , leading me to believe that maybe I am not
> > using the correct device tree blob.
> >
> > I'm using the instructions here:
> > https://git.rtems.org/rtems-docs/tree/user/bsps/arm/beagle.rst
> >
> > And I have am loading am335x-boneblack.dtb that I copied from a linux
> > u-boot build. The instructions talk about getting the one from the
> > FreeBSD repository, but there are many other files included in that
> > dts source.
> >
> > What dtb is normally used for the Beaglebone black RTEMS libbsd testing?
> >
> > Is the dtb needed for the non-libbsd BSP?
> >
> > Also, is the ethernet supported on the RTEMS beagle BSP, or do I need
> > libbsd to get ethernet?
> >
> > Thanks,
> > Alan
>
> Hello Alan,
>
> I recommend to use the FreeBSD device trees. libbsd is FreeBSD based and
> therefore works best with them. Normally I would suggest to use the
> version matching the FreeBSD commit used in libbsd. But unfortunately in
> the last commit that doesn't seem to work. Vijay had some problems with
> it and noted that the version from FreeBSD commit
> 19a6ceb89dbacf74697d493e48c388767126d418 works fine.
>
> Regarding Ethernet support: As far as I know there is no support for the
> legacy stack. But the one in libbsd worked fine the last time I tested
> it (which was when I ported it). If you really want to use the legacy
> stack please note that it is still an IPv4 only one and therefore it is
> quite limited nowadays.
>
> Best regards
>
> Christian
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Device Tree Blob for Beaglebone Black?

[Alan Cudmore]

Hi Vijay,
My uEnv.txt was very similar, but I did not have the "fdt addr
0x8800" command. But that did not seem to help. I still get a
fatal exception when trying to run the usb01 and ping01 programs.

Do you think the u-boot version matters?
I am using the following:
- MLO and u-boot.img from a buildroot linux build. ( u-boot 2018.1)
- RTEMS kernel master from about a week ago ( samples like unlimited
and ticker work )
- rtems-libbsd 5-freebsd-12 branch
- The am335x-boneblack.dtb compiled from the suggested commit from the
FreeBSD github repository.

I don't have a debugger, so I looked up the PC address from the register dump.
For the ping01 sample the PC indicates that it is in the fdt_ro_probe_ function.
For the usb01, it seems to crash in an termios program.

## Transferring control to RTEMS (at address 8000) ...

RTEMS Beagleboard: am335x-based
ARM Debug: 0x4b141000
*** LIBBSD PING 1 TEST ***

*** FATAL ***
fatal source: 9 (RTEMS_FATAL_SOURCE_EXCEPTION)

R0   = 0x R8  = 0x
R1   = 0xfeed R9  = 0x
R2   = 0x0007 R10 = 0x0064
R3   = 0x006e6573 R11 = 0x802520a0
R4   = 0x0007 R12 = 0x01010101
R5   = 0xfff7 SP  = 0x8027589c
R6   = 0x80150dac LR  = 0x8011b1d0
R7   = 0x PC  = 0x8011a11c
CPSR = 0x0113 VEC = 0x0004
RTEMS version: 5.0.0.588646279951ff696f3893a4c2e79aa1ba67fccf
RTEMS tools: 7.5.0 20191114 (RTEMS 5, RSB 5 (57011908b007), Newlib d14714c69)
executing thread ID: 0x08a010001
executing thread name: UI1

One more question:
I am converting the images using the following commands:
arm-rtems5-objcopy $1.exe -O binary $1.bin
gzip -9 $1.bin
mkimage -A arm -O rtems -T kernel -a 0x8000 -e 0x8000 -n RTEMS
-d $1.bin.gz $1-app.img

Are the 0x8000. addresses correct in the mkimage command? It seems
that the RTEMS executable considers the start of RAM to be 0x8000.

It might be good to have an image I can try.

Thanks for the help!
Alan

On Mon, Feb 24, 2020 at 12:57 AM Vijay Kumar Banerjee
 wrote:
>
>
>
> On Sun, Feb 23, 2020 at 11:46 PM Alan Cudmore  wrote:
>>
>> Hi Christian,
>> Thanks for the quick response. I followed the instructions in the
>> docs.rtems.org manual and generated the dtb from the FreeBSD commit
>> that Vijay suggested. It still resulted in an exception in the same
>> function.
>>
>> Do you know if a specific commit of rtems-libbsd is required to work
>> with that dtb?
>> I tried master, and then the "5-freebsd-12" branch.
>>
>> Thanks,
>> Alan
>>
> Hi Alan,
>
> I checked with the usb01 and ping01 tests running on libbsd master
> and the dtb from the commit mentioned by Christian. I can't reproduce
> the error and it seems to run as expected. I'm not sure where the
> error might be coming from. Below I'm pasting the contents of my uEnv.txt
> If the error isn't in the uEnv, I can send you my sd card image(offlist) so 
> that you
> can try that on your board and that might give some hint on what was going
> wrong.
>
> ```
> setenv bootdelay 5
> uenvcmd=run boot
> boot=fatload mmc 0 0x8080 rtems-app.img ; fatload mmc 0 0x8800 
> am335x-boneblack.dtb ; fdt addr 0x8800; bootm 0x8080 - 0x8800
> ```
>
> Best regards,
> Vijay
>>
>> On Sun, Feb 23, 2020 at 11:32 AM Christian Mauderer  
>> wrote:
>> >
>> > On 23/02/2020 17:07, Alan Cudmore wrote:
>> > > I have been trying to bring up RTEMS with rtems-libbsd on the
>> > > beaglebone black (latest master).
>> > >
>> > > I can run the regular RTEMS samples on the board, and a couple of the
>> > > rtems-libbsd testsuite examples run as well.
>> > >
>> > > The samples such as ping01 and usb01 get a fatal exception in the
>> > > function fdt_ro_probe_ , leading me to believe that maybe I am not
>> > > using the correct device tree blob.
>> > >
>> > > I'm using the instructions here:
>> > > https://git.rtems.org/rtems-docs/tree/user/bsps/arm/beagle.rst
>> > >
>> > > And I have am loading am335x-boneblack.dtb that I copied from a linux
>> > > u-boot build. The instructions talk about getting the one from the
>> > > FreeBSD repository, but there are many other files included in that
>> > > dts source.
>> > >
>> > > What dtb is normally used for the Beaglebone black RTEMS libbsd testing?
>> > >
>> > > Is the dtb needed for the non-libbsd BSP?
>> > >
>> > > Also, is the ethernet supported on the RTEMS beagle BSP, or do I need
>> > > libbsd to get ethernet?
>> > >
>> > > Thanks,
>> > > Alan
>

Re: Device Tree Blob for Beaglebone Black?

[Alan Cudmore]

It looks like the mkimage command difference fixed the crash.

The original BSP README:
https://git.rtems.org/rtems/tree/bsps/arm/beagle/README
$ mkimage -A arm -O rtems -T kernel -a 0x8000 -e 0x8000 -n
RTEMS -d $exe.bin.gz rtems-app.img

The docs.rtems.org beagle BSP readme:
https://git.rtems.org/rtems-docs/tree/user/bsps/arm/beagle.rst
mkimage -A arm -O linux -T kernel -a 0x8000 -e 0x8000 -n RTEMS
-d app.bin.gz rtems-app.img

Thanks for the help! Next is trying to get the ethernet to communicate
with a host!

Alan

On Mon, Feb 24, 2020 at 12:08 PM Vijay Kumar Banerjee
 wrote:
>
>
>
>
> On Mon, Feb 24, 2020 at 8:16 PM Alan Cudmore  wrote:
>>
>> Hi Vijay,
>> My uEnv.txt was very similar, but I did not have the "fdt addr
>> 0x8800" command. But that did not seem to help. I still get a
>> fatal exception when trying to run the usb01 and ping01 programs.
>>
>> Do you think the u-boot version matters?
>> I am using the following:
>> - MLO and u-boot.img from a buildroot linux build. ( u-boot 2018.1)
>
> I don't think it's making much difference. I'm currently running u-boot 
> 2018.11
>>
>> - RTEMS kernel master from about a week ago ( samples like unlimited
>> and ticker work )
>> - rtems-libbsd 5-freebsd-12 branch
>
> I haven't tested with 5-freebsd-12 branch but it runs fine on master branch.
>>
>> - The am335x-boneblack.dtb compiled from the suggested commit from the
>> FreeBSD github repository.
>>
> This one is fine.
>>
>> I don't have a debugger, so I looked up the PC address from the register 
>> dump.
>> For the ping01 sample the PC indicates that it is in the fdt_ro_probe_ 
>> function.
>> For the usb01, it seems to crash in an termios program.
>>
>> ## Transferring control to RTEMS (at address 8000) ...
>>
>> RTEMS Beagleboard: am335x-based
>> ARM Debug: 0x4b141000
>> *** LIBBSD PING 1 TEST ***
>>
>> *** FATAL ***
>> fatal source: 9 (RTEMS_FATAL_SOURCE_EXCEPTION)
>>
>> R0   = 0x R8  = 0x
>> R1   = 0xfeed R9  = 0x
>> R2   = 0x0007 R10 = 0x0064
>> R3   = 0x006e6573 R11 = 0x802520a0
>> R4   = 0x0007 R12 = 0x01010101
>> R5   = 0xfff7 SP  = 0x8027589c
>> R6   = 0x80150dac LR  = 0x8011b1d0
>> R7   = 0x PC  = 0x8011a11c
>> CPSR = 0x0113 VEC = 0x0004
>> RTEMS version: 5.0.0.588646279951ff696f3893a4c2e79aa1ba67fccf
>> RTEMS tools: 7.5.0 20191114 (RTEMS 5, RSB 5 (57011908b007), Newlib d14714c69)
>> executing thread ID: 0x08a010001
>> executing thread name: UI1
>>
>> One more question:
>> I am converting the images using the following commands:
>> arm-rtems5-objcopy $1.exe -O binary $1.bin
>> gzip -9 $1.bin
>> mkimage -A arm -O rtems -T kernel -a 0x8000 -e 0x8000 -n RTEMS
>> -d $1.bin.gz $1-app.img
>>
> Mine is similar with a slight change in OS option:
>
> arm-rtems5-objcopy $executable -O binary $TMPDIR/${base}.bin
> gzip -9 $TMPDIR/${base}.bin
> mkimage -A arm -O linux -T kernel -a 0x8000 -e 0x8000 -n RTEMS -d 
> $TMPDIR/${base}.bin.gz $TMPDIR/$app
>
>> Are the 0x8000. addresses correct in the mkimage command? It seems
>> that the RTEMS executable considers the start of RAM to be 0x8000.
>>
> Yes, the start address is correct.
>>
>> It might be good to have an image I can try.
>>
> I'll send that to you offlist shortly :)
>>
>> Thanks for the help!
>> Alan
>>
>> On Mon, Feb 24, 2020 at 12:57 AM Vijay Kumar Banerjee
>>  wrote:
>> >
>> >
>> >
>> > On Sun, Feb 23, 2020 at 11:46 PM Alan Cudmore  
>> > wrote:
>> >>
>> >> Hi Christian,
>> >> Thanks for the quick response. I followed the instructions in the
>> >> docs.rtems.org manual and generated the dtb from the FreeBSD commit
>> >> that Vijay suggested. It still resulted in an exception in the same
>> >> function.
>> >>
>> >> Do you know if a specific commit of rtems-libbsd is required to work
>> >> with that dtb?
>> >> I tried master, and then the "5-freebsd-12" branch.
>> >>
>> >> Thanks,
>> >> Alan
>> >>
>> > Hi Alan,
>> >
>> > I checked with the usb01 and ping01 tests running on libbsd master
>> > and the dtb from the commit mentioned by Christian. I can't reproduce
>> > the error and it seems to run as expected. I'm not sure where the
>> > error might be coming from. Belo

Re: Device Tree Blob for Beaglebone Black?

[Alan Cudmore]

I noticed that the Zephyr RTOS (https://www.zephyrproject.org) uses a
device tree based initialization for all of its BSPs.
For example, here is the top level device tree source for the Adafruit
Trinket M0, which is a very small Atmel Cortex M0 based board:
https://github.com/zephyrproject-rtos/zephyr/blob/master/boards/arm/adafruit_trinket_m0/adafruit_trinket_m0.dts

The rest of the device tree source for common processors and devices are here:
https://github.com/zephyrproject-rtos/zephyr/tree/master/dts

To me, it looks like they have to develop (or port) and maintain
device trees for each board and device that is supported.

Does that look like a model that RTEMS could use? I'm not sure I
understand everything that deploying such a model implies, or if it
just makes more sense to use the existing FreeBSD or linux device
trees.

Just a thought.. I'm still catching up!
Thanks,
Alan

On Thu, Feb 27, 2020 at 2:44 PM Amar Takhar  wrote:
>
> On 2020-02-27 20:06 +0100, Christian Mauderer wrote:
>
> > > The only good way to handle this is to have it all in 1 giant repository 
> > > we work
> > > with.  Every other solution is a pain no matter how well thought out it 
> > > is.  I
> > > personally lean more on the service side of things that it should be *our*
> > > problem to maintain this and for users it should just work.>
> > > The easiest way to handle this is to have the minimum version required in 
> > > the
> > > commit message.  Eg, when pushing to libbsd have:
> > >
> > >   Minimum RTEMS: 
> > >
> > > After that it's up to the user to ensure to keep up-to-date.  The first 
> > > thing
> > > most developers do is check the log.
> >
> > Sounds like a nice suggestion. But it needs quite a lot of discipline
> > for the developers. So most likely a lot of errors will happen. Beneath
> > that it's not far from what we do now: Suggest to use commits from the
> > same date.
>
> There are two ways to look at it -- requiring discipline or simply doing
> something we should already be doing.  Because right now there is no way to 
> tell
> other than updating to the latest and if you are trying to bisect an issue 
> this
> because huge because you could feasibly jump into a comment that skips a
> version.  How would a user know which version of the library *or* RTEMS to 
> use?
>
>
> > But maybe we should move that discussion. It's not FDT related anymore
> > so no one will find it in this toppic. And I think for Chris the
> > pressing matter is FDT just now because it blocks the release.
>
> Yes that's true.
>
> > The BSP groups that use bsps/shared/start/bsp-fdt.c are:
> >
> > - riscv/riscv
> > - arm/imx
> > - arm/beagle
> > - arm/raspberrypi
> > - arm/altera-cyclone-v
> > - powerpc/qoriq
> >
> > For beagle and raspberry it should be definitely the FreeBSD FDT.
> >
> > For imx: I'm currently working on imx6 support in the imx BSP and that
> > one will use a FreeBSD derived one too. Not sure about the original imx7
> > support in that BSP.
> >
> > For the other BSPs I don't have any idea which FDT has been used during
> > development.
>
>
> Okay that list is already compelling enough to have the split model of having
> source based files in-tree and binary outside.  I think it makes sense to have
> it 'just work' for opensource boards like the beagle and rpi even if that's 
> the
> only two that require it.
>
>
> Amar.
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Link issue on xilinx_zynq_a9_qemu BSP on rtems-libbsd head

[Alan Cudmore]

Hi Lou,
Did you ever solve this problem?
I just tried linking an out of tree program for the beaglebone black
BSP and have the same undefined symbols. The testsuite links correctly
and the symbols are in the testsuite binaries, but not in libbsd.a

doing a grep of the rtems-libbsd source there is a PHYS_TO_VM_PAGE in
rtemsbsd/powerpc/include/linux/page.h
When I grep the directory where I installed the bsd library and
headers, this file is not present.

Any ideas?

Thanks,
Alan

On Wed, Jan 15, 2020 at 1:59 PM Lou Woods  wrote:
>
> Hello all,
>
> I just pulled from the master of both rtems 
> (362cf319d44e7e64987f12aa36ea030e6298c586) and rtems-libbsd 
> (d892051f37c2c4ad7f345f6a817ea3d38e56a431) trees and ran into an couple 
> undefined references when linking an application outside of the tree.  The 
> application doesn't directly use either symbol and has worked unmodified on 
> older trees.  This build issue is not present when using the 5-freebsd-12 
> branch of rtems-libbsd on the same application code.  I can move forward with 
> the 5-freebsd-12 branch so this isn't a show stopper for me.
>
> $ make
> arm-rtems5-gcc --pipe -march=armv7-a -mthumb -mfpu=neon -mfloat-abi=hard 
> -mtune=cortex-a9 -O0 -g -ffunction-sections -fdata-sections -Wall 
> -Wmissing-prototypes -Wimplicit-function-declaration -Wstrict-prototypes 
> -Wnested-externs -B 
> /home/woods/zynq-quickstart-trial/bsp-install/arm-rtems5/xilinx_zynq_a9_qemu/lib/
>  -specs bsp_specs -qrtems init.c  -o init.exe -lbsd -lm -ltelnetd
> /data/home/woods/zynq-quickstart-trial/tools/bin/../lib/gcc/arm-rtems5/7.5.0/../../../../arm-rtems5/bin/ld:
>  
> /home/woods/zynq-quickstart-trial/bsp-install/arm-rtems5/xilinx_zynq_a9_qemu/lib/libbsd.a(uipc_mbuf.c.18.o):
>  in function `m_unmappedtouio':
> /data/home/woods/zynq-quickstart-trial/rtems-libbsd/build/arm-rtems5-xilinx_zynq_a9_qemu-default/../../freebsd/sys/kern/uipc_mbuf.c:1813:
>  undefined reference to `PHYS_TO_VM_PAGE'
> /data/home/woods/zynq-quickstart-trial/tools/bin/../lib/gcc/arm-rtems5/7.5.0/../../../../arm-rtems5/bin/ld:
>  
> /data/home/woods/zynq-quickstart-trial/rtems-libbsd/build/arm-rtems5-xilinx_zynq_a9_qemu-default/../../freebsd/sys/kern/uipc_mbuf.c:1814:
>  undefined reference to `uiomove_fromphys'
> collect2: error: ld returned 1 exit status
> make: *** [init.exe] Error 1
>
> RTEMS was configured like this:
> ../rtems/configure --prefix=${rw}/bsp-install --target=arm-rtems5 \
>  --enable-rtemsbsp=xilinx_zynq_a9_qemu --disable-networking
>
> libbsd was configured like this:
> $ git clone git://git.rtems.org/rtems-libbsd.git
> $ cd ./rtems-libbsd
> $ git submodule init
> $ git submodule update rtems_waf
> $ python3 ./waf configure --rtems-tools=${rw}/tools --rtems=${rw}/bsp-install 
> \
>  --prefix=${rw}/bsp-install --rtems-bsps=arm/xilinx_zynq_a9_qemu
> $ python3 ./waf
> $ python3 ./waf install
>
> Makefile
>
> include $(RTEMS_MAKEFILE_PATH)/Makefile.inc
> include $(RTEMS_MAKEFILE_PATH)/make/target.cfg
> include $(RTEMS_CUSTOM)
>
> all: init.exe
>
> CFLAGS += -B ${RTEMS_MAKEFILE_PATH}/lib/ -specs bsp_specs -qrtems
>
> init.exe: init.c
> $(CC) $(CFLAGS) init.c  -o $@ -lbsd -lm -ltelnetd
>
>  clean:
>  init.exe
>
> If any other information can be useful, please let me know.
>
> Thanks,
> Lou Woods
> On-Line Applications Research
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Link issue on xilinx_zynq_a9_qemu BSP on rtems-libbsd head

[Alan Cudmore]

I had logged the verbose output from waf building the testsuite, but I
missed a couple of linker options in my makefile. It links now.
Is there a standalone rtems-libbsd example with a waf script or makefile?
Thank your for your quick response,
Alan

On Fri, Feb 28, 2020 at 1:25 AM Sebastian Huber
 wrote:
>
> On 28/02/2020 04:40, Alan Cudmore wrote:
> > Hi Lou,
> > Did you ever solve this problem?
> > I just tried linking an out of tree program for the beaglebone black
> > BSP and have the same undefined symbols. The testsuite links correctly
> > and the symbols are in the testsuite binaries, but not in libbsd.a
>
> For libbsd it is required that you link with the section garbage
> collection enabled: -Wl,--gc-sections
>
> This is how the tests are linked. If you omit the -Wl,--gc-sections in
> your application you do something which is not tested.
>
> --
> Sebastian Huber, embedded brains GmbH
>
> Address : Dornierstr. 4, D-82178 Puchheim, Germany
> Phone   : +49 89 189 47 41-16
> Fax : +49 89 189 47 41-09
> E-Mail  : sebastian.hu...@embedded-brains.de
> PGP : Public key available on request.
>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

RE: Re: Improve the Raspberry Pi BSP

[Alan Cudmore]

This is probably not a comprehensive list, but currently all models except the Pi 4 are working thanks to Niteesh’s work on the uart for the Pi 3 and Zero W. I believe there is some support for GPIO, and I2C.I’m not sure about the state of SPI.There is also support for the graphics console, but I don’t know that state of that with the various Pi models as well. Finally, there was an effort to port libbsd to the Pi, but I don’t think it was completed. From what I know the Pi 4 is not supported at all yet. So there is still a lot of work to do, maybe too much for a single GSoC project.Maybe try to narrow the focus on something like:Libbsd and SMP support for the Raspberry Pi 3?I have been learning how to use RTEMS and rtems-libbsd on the beaglebone black lately. Having that capability along with SMP on the Pi 3 would be great.  Alan   From: Joel SherrillSent: Tuesday, March 17, 2020 11:19 PMTo: Denil VergheseCc: rtems-de...@rtems.orgSubject: Re: Improve the Raspberry Pi BSP  On Sun, Mar 15, 2020, 10:20 PM Denil Verghese  wrote:Hi,    I would like to know whether the projects shown in this https://devel.rtems.org/ticket/2899 ticket is completed or not. If the ideas are yet to implement I could work on it. I think there is plenty left. I am not authoritative on this though. I think getting Pi3/4 support still has work. I think USB plus Ethernet. I recall the graphics work was done on the Beagle. I am not even sure that Pi2 qemu support has been worked through completely.   It will more interesting to work those projects rather than my currently selected project which is Release Note Generator. Meanwhile I have uploaded my draft proposal which is ongoing self revision. Thank youDenil C Verghese ___devel mailing listdevel@rtems.orghttp://lists.rtems.org/mailman/listinfo/devel 
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Improve the Raspberry Pi BSP

[Alan Cudmore]

While, I would like to see additional improvement to the Raspberry Pi
BSPs, I don't think I have the time to serve as a mentor this year. I
am sure I could not keep up with the daily communication that is
required for a successful GSoC project.
Alan

On Wed, Mar 18, 2020 at 1:12 PM Denil Verghese  wrote:
>
>
>
> On Wed, 18 Mar, 2020, 9:03 PM Gedare Bloom,  wrote:
>>
>> On Wed, Mar 18, 2020 at 8:41 AM Denil Verghese  wrote:
>> >
>> >
>> >
>> > On Wed, 18 Mar, 2020, 7:43 PM Alan Cudmore,  wrote:
>> >>
>> >> This is probably not a comprehensive list, but currently all models 
>> >> except the Pi 4 are working thanks to Niteesh’s work on the uart for the 
>> >> Pi 3 and Zero W.
>> >>
>> >>
>> >>
>> >> I believe there is some support for GPIO, and I2C.
>> >>
>> >> I’m not sure about the state of SPI.
>> >>
>> >> There is also support for the graphics console, but I don’t know that 
>> >> state of that with the various Pi models as well.
>> >>
>> >>
>> >>
>> >> Finally, there was an effort to port libbsd to the Pi, but I don’t think 
>> >> it was completed.
>> >>
>> >>
>> >>
>> >> From what I know the Pi 4 is not supported at all yet.
>> >>
>> >>
>> >>
>> >> So there is still a lot of work to do, maybe too much for a single GSoC 
>> >> project.
>> >>
>> >> Maybe try to narrow the focus on something like:
>> >>
>> >> Libbsd and SMP support for the Raspberry Pi 3?
>> >
>> > That is a great idea. Thanks for the suggestion.
>> >
>> > Will this will be more useful than my current proposal?( Which is based on 
>> > Release note generator and code formatter.).
>> >
>>
>> They are two very different projects. You can continue to flesh out
>> both of them if you like, although we prefer a student to focus on one
>> proposal if you are not certain then it will be fine
>
>
> I can't focus on two proposals at the same time. My intention was to change 
> my proposal if this makes a great contribution and will be interesting for 
> mentors.
>>
>>
>> As before, to do the RPi projects you must have and demonstrate that
>> you can run RPi at least with baremetal if not with RTEMS.
>>
>> I don't know if we'll have the bandwidth for multiple projects
>> involving libbsd, while the release note generator/formatter may be
>> somewhat easier to mentor. I haven't heard too much enthusiasm yet,
>> but if you write a strong proposal you may convince a mentor :)
>
>
> If that's the case, I will focus on my current proposal and will make it 
> strong as I can:). I need some clarification on how can I do formatting part. 
> Maybe start a new thread??
>>
>>
>> >> I have been learning how to use RTEMS and rtems-libbsd on the beaglebone 
>> >> black lately. Having that capability along with SMP on the Pi 3 would be 
>> >> great.
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> Alan
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> From: Joel Sherrill
>> >> Sent: Tuesday, March 17, 2020 11:19 PM
>> >> To: Denil Verghese
>> >> Cc: rtems-de...@rtems.org
>> >> Subject: Re: Improve the Raspberry Pi BSP
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> On Sun, Mar 15, 2020, 10:20 PM Denil Verghese  wrote:
>> >>
>> >> Hi,
>> >>
>> >>I would like to know whether the projects shown in this 
>> >> https://devel.rtems.org/ticket/2899 ticket is completed or not. If the 
>> >> ideas are yet to implement I could work on it.
>> >>
>> >>
>> >>
>> >> I think there is plenty left. I am not authoritative on this though.
>> >>
>> >>
>> >>
>> >> I think getting Pi3/4 support still has work.
>> >>
>> >>
>> >>
>> >> I think USB plus Ethernet.
>> >>
>> >>
>> >>
>> >> I recall the graphics work was done on the Beagle.
>> >>
>> >>
>> >>
>> >> I am not even sure that Pi2 qemu support has been worked through 
>> >> completely.
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> It will more interesting to work those projects rather than my currently 
>> >> selected project which is Release Note Generator.
>> >>
>> >> Meanwhile I have uploaded my draft proposal which is ongoing self 
>> >> revision.
>> >>
>> >>
>> >>
>> >> Thank you
>> >>
>> >> Denil C Verghese
>> >>
>> >>
>> >>
>> >> ___
>> >> devel mailing list
>> >> devel@rtems.org
>> >> http://lists.rtems.org/mailman/listinfo/devel
>> >>
>> >>
>> >
>> > ___
>> > devel mailing list
>> > devel@rtems.org
>> > http://lists.rtems.org/mailman/listinfo/devel
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: RTEMS Release Snapshot: 5.0.0-m2004 (02 Apr 2020)

[Alan Cudmore]

Chris,
I tested this release on the Raspberry Pi (Zero), Raspberry Pi 2,
Beaglebone Black with LibBSD, xilinx_zynq_a9_qemu, and partially on
the leon3. ( samples all work on Leon3 QEMU, but I'm still configuring
my application )

To help generate tools and BSPs for releases like this, I created a
series of Dockerfiles to generate a base system, Add tools, then build
BSPs. I was learning docker, and I thought generating release
candidate images might be a good exercise :)

Here are the Dockerfiles in case anyone is interested:
https://github.com/alanc98/rtems-release-docker

To use these, create the "rtems5-m2004-base" image first, then for the
ARM tools, the "rtems5-m2004-arm-tools" image. Finally, you can create
an image like "rtems5-m2004-arm-bbb" to build the RTEMS BSP and
rtems-libbsd for the Beaglebone Black.

The resulting Docker image will allow you to build RTEMS applications
that are shared through the "/host" directory in the container.

With these, I hope to be able to crank out a series of builds for the
targets I'm interested in for future releases.

I'm also working on integration of my RTEMS Kernel Image (RKI) with
rtems-libbsd. I have it working on the Beaglebone black and the
zynq_a9_qemu target. That is a work in progress here:
https://github.com/alanc98/rki2
All of the above targets work except for the leon3 right now. (
Raspberry Pi targets are not libbsd)

Alan

On Thu, Apr 2, 2020 at 6:13 AM  wrote:
>
> RTEMS Release Build - 5.0.0-m2004
>
> RTEMS 5 Release snapshot m2004 is avaliable for testing.
> It can be found at:
>
>  https://ftp.rtems.org/pub/rtems/releases/5/5.0.0/5.0.0-m2004
>
> Please test and report any issues to the u...@rtems.org or devel@rtems.org
> mailing lists or please raise a ticket.
>
> If you are part of the RTEMS testing program please build on your preferred
> host posting build and BSP test results to bu...@rtems.org.
>
> This is a development release and may have errors and be unstable.
>
> Thanks
> Chris
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: RTEMS Release Snapshot: 5.0.0-m2004 (02 Apr 2020)

[Alan Cudmore]

Hi Chris,
I definitely plan on creating a readme for the repository to help
anyone that is interested.

Regarding the LEON3: I am noticing something with the release that I
don't understand yet.

I am able to build and run a number of ARM BSPs including raspberrypi,
raspberrypi2, beagleboneblack, and xlinx_zynq_a9_qemu
When I build my application for the leon3, most of it appears to work,
but I have a task demo that crashes when I try to print a variable
that is on the task stack. ( task ID, similar to what ticker does )
I went back and ran a number of the testsuite programs on both my
patched QEMU and sparc-rtems5-sis with no problems.
I then cloned the latest rtems-examples git repository and built the
ticker examples using the (obsolete) Makefile. When built this way,
the ticker program crashes as well on both QEMU and SIS.

I'm trying to narrow down the differences by comparing the flags used
to build the testsuite in the build tree vs. my applications and the
rtems-examples repository.

Should I try building the examples with waf?

Thanks,
Alan

On Tue, Apr 7, 2020 at 2:35 AM Chris Johns  wrote:
>
> Hi Alan,
>
> This is awesome. I welcome deployment stories and support for them. I
> wonder if we need a way to assist capturing this for our users.
>
> You may need to add something to the site's README to provide beginner
> steps.
>
> Chris
>
> On 2020-04-07 11:44, Alan Cudmore wrote:
> > Chris,
> > I tested this release on the Raspberry Pi (Zero), Raspberry Pi 2,
> > Beaglebone Black with LibBSD, xilinx_zynq_a9_qemu, and partially on
> > the leon3. ( samples all work on Leon3 QEMU, but I'm still configuring
> > my application )
> >
> > To help generate tools and BSPs for releases like this, I created a
> > series of Dockerfiles to generate a base system, Add tools, then build
> > BSPs. I was learning docker, and I thought generating release
> > candidate images might be a good exercise :)
> >
> > Here are the Dockerfiles in case anyone is interested:
> > https://github.com/alanc98/rtems-release-docker
> >
> > To use these, create the "rtems5-m2004-base" image first, then for the
> > ARM tools, the "rtems5-m2004-arm-tools" image. Finally, you can create
> > an image like "rtems5-m2004-arm-bbb" to build the RTEMS BSP and
> > rtems-libbsd for the Beaglebone Black.
> >
> > The resulting Docker image will allow you to build RTEMS applications
> > that are shared through the "/host" directory in the container.
> >
> > With these, I hope to be able to crank out a series of builds for the
> > targets I'm interested in for future releases.
> >
> > I'm also working on integration of my RTEMS Kernel Image (RKI) with
> > rtems-libbsd. I have it working on the Beaglebone black and the
> > zynq_a9_qemu target. That is a work in progress here:
> > https://github.com/alanc98/rki2
> > All of the above targets work except for the leon3 right now. (
> > Raspberry Pi targets are not libbsd)
> >
> > Alan
> >
> > On Thu, Apr 2, 2020 at 6:13 AM  wrote:
> >>
> >> RTEMS Release Build - 5.0.0-m2004
> >>
> >> RTEMS 5 Release snapshot m2004 is avaliable for testing.
> >> It can be found at:
> >>
> >>   https://ftp.rtems.org/pub/rtems/releases/5/5.0.0/5.0.0-m2004
> >>
> >> Please test and report any issues to the u...@rtems.org or devel@rtems.org
> >> mailing lists or please raise a ticket.
> >>
> >> If you are part of the RTEMS testing program please build on your preferred
> >> host posting build and BSP test results to bu...@rtems.org.
> >>
> >> This is a development release and may have errors and be unstable.
> >>
> >> Thanks
> >> Chris
> >> ___
> >> devel mailing list
> >> devel@rtems.org
> >> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: RTEMS Release Snapshot: 5.0.0-m2004 (02 Apr 2020)

[Alan Cudmore]

Hi Sebastian,
Thank you for reproducing this. I added the floating point attribute
to my demo tasks and it works as expected.
I was just about to try Chris' suggestion of using GDB when I saw this message.

I encountered the same problem building the examples with waf.

Regards,
Alan

On Thu, Apr 9, 2020 at 7:51 AM Sebastian Huber
 wrote:
>
> Hello Alan,
>
> On 08/04/2020 17:48, Alan Cudmore wrote:
> > Regarding the LEON3: I am noticing something with the release that I
> > don't understand yet.
> >
> > I am able to build and run a number of ARM BSPs including raspberrypi,
> > raspberrypi2, beagleboneblack, and xlinx_zynq_a9_qemu
> > When I build my application for the leon3, most of it appears to work,
> > but I have a task demo that crashes when I try to print a variable
> > that is on the task stack. ( task ID, similar to what ticker does )
> > I went back and ran a number of the testsuite programs on both my
> > patched QEMU and sparc-rtems5-sis with no problems.
> > I then cloned the latest rtems-examples git repository and built the
> > ticker examples using the (obsolete) Makefile. When built this way,
> > the ticker program crashes as well on both QEMU and SIS.
> >
> > I'm trying to narrow down the differences by comparing the flags used
> > to build the testsuite in the build tree vs. my applications and the
> > rtems-examples repository.
> >
> > Should I try building the examples with waf?
>
> I was able to reproduce this issue. It seems to be a problem with the
> use of the FPU in a non-FP task:
>
> Program received signal SIGTERM, Terminated.
> syscall () at
> /home/EB/sebastian_h/src/rtems/c/src/../../cpukit/score/cpu/sparc/syscall.S:44
> 44  ta  0   ! syscall 1, halt with
> %g1,%g2,%g3 info
> (gdb) bt
> #0  syscall () at
> /home/EB/sebastian_h/src/rtems/c/src/../../cpukit/score/cpu/sparc/syscall.S:44
> #1  0x4000f888 in _User_extensions_Fatal_visitor (executing=0x0,
> arg=0x26, callouts=0x40020ca8 <_User_extensions_List+4>) at
> /home/EB/sebastian_h/src/rtems/c/src/../../cpukit/score/src/userextiterate.c:131
> #2  0x4001cdc4 in _CPU_Fatal_halt (source=10, source@entry=0, error=0,
> error@entry=38) at
> /home/EB/sebastian_h/src/rtems/c/src/lib/libbsp/sparc/leon3/../../../../../../bsps/sparc/leon3/start/bsp_fatal_halt.c:33
> #3  0x4000fb68 in _Terminate
> (the_source=the_source@entry=INTERNAL_ERROR_CORE, the_error=38,
> the_error@entry=0) at
> /home/EB/sebastian_h/src/rtems/c/src/../../cpukit/score/src/interr.c:44
> #4  0x4000fb7c in _Internal_error (core_error=0,
> core_error@entry=INTERNAL_ERROR_ILLEGAL_USE_OF_FLOATING_POINT_UNIT) at
> /home/EB/sebastian_h/src/rtems/c/src/../../cpukit/score/src/interr.c:52
> #5  0x40001664 in bsp_spurious_handler (trap=260, isf=0x40028518) at
> /home/EB/sebastian_h/src/rtems/c/src/lib/libbsp/sparc/leon3/../../../../../../bsps/sparc/leon3/start/spurious.c:124
> #6  0x40012390 in pil_fixed () at
> /home/EB/sebastian_h/src/rtems/c/src/../../cpukit/score/cpu/sparc/cpu_asm.S:592
>
> It would be good to add support for the RTEMS Tester to the examples.
>
> I was not able to build the examples with waf:
>
> Waf: Entering directory
> `/home/EB/sebastian_h/src/rtems-examples/build/sparc-rtems5-leon3'
> [ 1/14] Compiling hello/hello_world_c/test.c
> [ 2/14] Compiling hello/posix_hello_world/test.c
> [ 3/14] Compiling hello/both_hello/test.c
> [ 4/14] Compiling hello/both_hello/test.c
> [ 5/14] Compiling hello/both_hello/test.c
> [ 6/14] Linking
> build/sparc-rtems5-leon3/hello/posix_hello_world/posix_hello.exe
> [ 7/14] Linking build/sparc-rtems5-leon3/hello/hello_world_c/hello.exe
> [ 8/14] Compiling build/sparc-rtems5-leon3/hello/both_hello/test.c.2.o
> [ 9/14] Compiling build/sparc-rtems5-leon3/hello/both_hello/test.c.1.o
> [10/14] Linking build/sparc-rtems5-leon3/hello/both_hello/both_hello.exe
> [11/14] Compiling gdb/overwrite/rtems_init.c
> [12/14] Compiling gdb/overwrite/overwrite.c
> [13/14] Compiling filesystem/fat_ramdisk/rootfs/shell-init
> [14/14] Linking build/sparc-rtems5-leon3/gdb/overwrite/overwrite.exe
> [15/15] Compiling
> build/sparc-rtems5-leon3/filesystem/fat_ramdisk/rootfs/shell-init
> [16/16] Compiling
> build/sparc-rtems5-leon3/filesystem/fat_ramdisk/fs-root.tar
> [17/29] Compiling
> build/sparc-rtems5-leon3/filesystem/fat_ramdisk/fs-root-tar.c
> [18/29] Compiling filesystem/fat_ramdisk/init.c
> [19/29] Compiling
> build/sparc-rtems5-leon3/filesystem/fat_ramdisk/fs-root-tar.c
> [20/29] Compiling filesystem/fat_ramdisk/init.c
> [21/29] Compiling classic_api/classic_signal/test.c
> [22/29] Compiling classic_api/triple_period/tasks.c
> Waf: Leaving directory
> `/ho

Re: [PATCH v4] bsps: Move optfdt* files to shared parent directory

[Alan Cudmore]

The master branch works for me. I tried the raspberrypi and
raspberrypi2 BSPS and they work fine. I built the beagleboneblack BSP
but did not run it.

When this one line patch is installed, SMP works too:
https://lists.rtems.org/pipermail/devel/2021-August/068832.html
Alan

On Mon, Aug 9, 2021 at 1:37 PM Joel Sherrill  wrote:
>
>
>
> On Mon, Aug 9, 2021, 10:14 AM Pranav Dangi  wrote:
>>
>> Hi joel,
>> I had sent you a rebased patch as a direct attachment, I will ping that 
>> thread once again. Did that fail too?
>
>
> I just pushed a patch you sent me directly. Is it ok on master now?
>
> --joel
>>
>>
>> Thanks,
>> pranav
>>
>> On Mon, 9 Aug 2021, 20:40 Joel Sherrill,  wrote:
>>>
>>> On Mon, Aug 9, 2021 at 10:00 AM Gedare Bloom  wrote:
>>> >
>>> > Hi Joel,
>>> >
>>> > On Fri, Jul 16, 2021 at 10:40 AM Joel Sherrill  wrote:
>>> > >
>>> > > I'm doing a build sweep of all BSPs. When that completes, I plan to
>>> > > push this unless there are comments.
>>> > >
>>> > Did/can you push this?
>>>
>>> It doesn't apply for me. Could be a rebase is needed or it didn't survive
>>> the email client. If it's just an email issue, just send it to me directly 
>>> as an
>>> attachment possibly compressed to avoid any chance of email clients
>>> getting smart.
>>>
>>> Applying: bsps: Move optfdt* files to shared parent directory
>>> error: patch failed: spec/build/bsps/arm/beagle/optfdtcpyro.yml:1
>>> error: spec/build/bsps/arm/beagle/optfdtcpyro.yml: patch does not apply
>>> error: patch failed: spec/build/bsps/arm/beagle/optfdtmxsz.yml:1
>>> error: spec/build/bsps/arm/beagle/optfdtmxsz.yml: patch does not apply
>>> error: patch failed: spec/build/bsps/arm/beagle/optfdtro.yml:1
>>> error: spec/build/bsps/arm/beagle/optfdtro.yml: patch does not apply
>>> error: patch failed: spec/build/bsps/arm/beagle/optfdtuboot.yml:1
>>> error: spec/build/bsps/arm/beagle/optfdtuboot.yml: patch does not apply
>>> error: patch failed: spec/build/bsps/arm/imx/optfdtcpyro.yml:1
>>> error: spec/build/bsps/arm/imx/optfdtcpyro.yml: patch does not apply
>>> error: patch failed: spec/build/bsps/arm/imx/optfdtmxsz.yml:1
>>> error: spec/build/bsps/arm/imx/optfdtmxsz.yml: patch does not apply
>>> error: patch failed: spec/build/bsps/arm/imx/optfdtro.yml:1
>>> error: spec/build/bsps/arm/imx/optfdtro.yml: patch does not apply
>>> error: patch failed: spec/build/bsps/arm/imx/optfdtuboot.yml:1
>>> error: spec/build/bsps/arm/imx/optfdtuboot.yml: patch does not apply
>>> error: patch failed: spec/build/bsps/powerpc/qoriq/optfdtmxsz.yml:1
>>> error: spec/build/bsps/powerpc/qoriq/optfdtmxsz.yml: patch does not apply
>>> error: patch failed: spec/build/bsps/powerpc/qoriq/optfdtro.yml:1
>>> error: spec/build/bsps/powerpc/qoriq/optfdtro.yml: patch does not apply
>>> error: patch failed: spec/build/bsps/riscv/riscv/optfdtcpyro.yml:1
>>> error: spec/build/bsps/riscv/riscv/optfdtcpyro.yml: patch does not apply
>>> error: patch failed: spec/build/bsps/riscv/riscv/optfdtmxsz.yml:1
>>> error: spec/build/bsps/riscv/riscv/optfdtmxsz.yml: patch does not apply
>>> error: patch failed: spec/build/bsps/riscv/riscv/optfdtro.yml:1
>>> error: spec/build/bsps/riscv/riscv/optfdtro.yml: patch does not apply
>>> error: patch failed: spec/build/bsps/riscv/riscv/optfdtuboot.yml:1
>>> error: spec/build/bsps/riscv/riscv/optfdtuboot.yml: patch does not apply
>>> Patch failed at 0001 bsps: Move optfdt* files to shared parent directory
>>> The copy of the patch that failed is found in:
>>>/home/joel/rtems-work/rtems/.git/rebase-apply/patch
>>>
>>>
>>> >
>>> > > On Fri, Jul 16, 2021 at 9:51 AM pranav  wrote:
>>> > > >
>>> > > > ---
>>> > > >  .../arm/altera-cyclone-v/bspalteracyclonev.yml  |  8 
>>> > > >  spec/build/bsps/arm/beagle/grp.yml  |  8 
>>> > > >  spec/build/bsps/arm/beagle/optfdtcpyro.yml  | 16 
>>> > > >  spec/build/bsps/arm/beagle/optfdtmxsz.yml   | 17 
>>> > > > -
>>> > > >  spec/build/bsps/arm/beagle/optfdtro.yml | 16 
>>> > > >  spec/build/bsps/arm/beagle/optfdtuboot.yml  | 16 
>>> > > >  spec/build/bsps/arm/imx/bspimx.yml  |  8 
>>> > > >  spec/build/bsps/arm/imx/optfdtcpyro.yml | 16 
>>> > > >  spec/build/bsps/arm/imx/optfdtmxsz.yml  | 17 
>>> > > > -
>>> > > >  spec/build/bsps/arm/imx/optfdtro.yml| 16 
>>> > > >  spec/build/bsps/arm/imx/optfdtuboot.yml | 16 
>>> > > >  spec/build/bsps/arm/raspberrypi/grp.yml |  8 
>>> > > >  .../{arm/altera-cyclone-v => }/optfdtcpyro.yml  |  0
>>> > > >  .../{arm/altera-cyclone-v => }/optfdtmxsz.yml   |  0
>>> > > >  .../{arm/altera-cyclone-v => }/optfdtro.yml |  0
>>> > > >  .../{arm/altera-cyclone-v => }/optfdtuboot.yml  |  0
>>> > > >  spec/build/bsps/powerpc/qoriq/grp.yml   |  4 ++--
>>> > > >  spec/build/bsps/powerpc/qoriq/optfdtmxsz.yml| 17 
>>> > > > -

Building RTEMS toolchain on Aarch64 fails on expat

[Alan Cudmore]

Hi,
I tried to use the RSB master branch to build an RTEMS 6 toolchain on
a Raspberry Pi 4 running Ubuntu 20.04 64 bit (Aarch64).
It fails on expat-2.1.0, with the log saying that expat does not
recognize Aarch64.
The expat package on the Ubuntu distribution is 2.2.10.
Would this be as simple as upgrading the expat version in RSB?

I know that building a toolchain on a Raspberry Pi is not the most
common use case, but with the M1 Macs I think this will start to
become a more widely used development platform.

Thanks,
Alan
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Building RTEMS toolchain on Aarch64 fails on expat

[Alan Cudmore]

On Thu, Oct 14, 2021 at 11:39 AM Joel Sherrill  wrote:
>
> On Thu, Oct 14, 2021 at 10:18 AM Alan Cudmore  wrote:
> >
> > Hi,
> > I tried to use the RSB master branch to build an RTEMS 6 toolchain on
> > a Raspberry Pi 4 running Ubuntu 20.04 64 bit (Aarch64).
> > It fails on expat-2.1.0, with the log saying that expat does not
> > recognize Aarch64.
> > The expat package on the Ubuntu distribution is 2.2.10.
> > Would this be as simple as upgrading the expat version in RSB?
>
> It should be unless Ubuntu has patches to add aarch64 as recognized.
>
> Change the version and the hash and give it a spin.

Doing that now - It's past the expat build, but it will take a while
to build the entire toolchain on an SD card :)

>
> FYI rtems-tools needs updating to bump the has to something recent
> enough to get the aarch64 kcu105_qemu tester configuration and a
> number of Coverity fixes. It's in Alex's queue.
>
> >
> > I know that building a toolchain on a Raspberry Pi is not the most
> > common use case, but with the M1 Macs I think this will start to
> > become a more widely used development platform.
>
> No reason it shouldn't work. You are right that it will start to
> become more used. I saw some graphic that Apple will sell
> 80% of ARM based laptops. My first thought was "what are the
> other 20%?" :)

Probably refers to Chromebooks and Windows ARM devices like the
Microsoft SQ1 processor. We have a Mac with a M1 CPU.. Eventually I'll
have to try to generate an RTEMS toolchain on it.

Alan

>
> --joel
> >
> > Thanks,
> > Alan
> > ___
> > devel mailing list
> > devel@rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH] rtems-docs: add example booting aarch64 image on Xilinx ZCU102

[Alan Cudmore]

This patch is for the rtems-docs repo. I added details on the procedure I
used to boot RTEMS images on the Xilinx ZCU102 board. I applied this patch,
and  generated the HTML docs, and everything looks ok to me.
Thanks,
Alan

---
 user/bsps/aarch64/xilinx-zynqmp.rst | 138 
 1 file changed, 138 insertions(+)

diff --git a/user/bsps/aarch64/xilinx-zynqmp.rst
b/user/bsps/aarch64/xilinx-zynqmp.rst
index ca232de..3d55c4c 100644
--- a/user/bsps/aarch64/xilinx-zynqmp.rst
+++ b/user/bsps/aarch64/xilinx-zynqmp.rst
@@ -44,6 +44,144 @@ When booting via u-boot, RTEMS must be packaged into a
u-boot image or booted
 as a raw binary since u-boot does not currently support ELF64 which is
required
 for AArch64 ELF binaries.

+
+Example: Booting a RTEMS image on the ZCU102 ZynqMP board
+-
+
+This example will walk through the steps needed for booting RTEMS from a
SD card on the
+`ZCU102 ZynqMP board. <
https://www.xilinx.com/products/boards-and-kits/ek-u1-zcu102-g.html>`_ The
reference for setting up a SD card and obtaining pre-built boot images is
`here. <
https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18841858/Board+bring+up+using+pre-built+images
>`_
+
+Hardware Setup
+^^
+
+Set the dip switch SW6 according to the table below. This will allow the
board to boot from the SD card. Connect a Micro-USB cable to the USB UART
interface J83. This is a quad USB UART interface which will show up on the
development host computer as four different serial or tty devices. Use the
first channel for the console UART. It should be set to 115k baud.
+
++---+
+| Dip Switch JW6|
++--+--+--+--+
+|  ON  |  OFF |  OFF |  OFF |
++--+--+--+--+
+
+Prepare a SD card with a bootable partition
+
+
+The goal is to have a bootable SD card with a partition that is formatted
with the FAT file system. The file system will contain the boot artifacts
including BOOT.bin and the u-boot image. The RTEMS image will be placed on
this volume. To create the bootable SD card, follow the directions `here. <
https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18842385/How+to+format+SD+card+for+SD+boot
>`_
+
+Once you have the card formatted correctly, you need to place the files
from `this archive <
https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/2202763266/2021.2+Release#Downloads>`_
on the FAT partition. The following file was used for this example:
`xilinx-vck190-v2021.2-final.bsp <
https://www.xilinx.com/member/forms/download/xef.html?filename=xilinx-vck190-v2021.2-final.bsp
>`_
+
+In order to download these files, you need to have a Xilinx account login.
As an alternative, you can download a bootable image for Ubuntu 20.04 and
write it to an SD card using a utility such as `Balena Etcher <
https://www.balena.io/etcher>`_  or dd. The Ubuntu image is available
`here. `_ Download the image for the
Zynq Ultrascale+ MPSoC Development boards, uncompress it and write it to
the SD card. This image creates multiple partitions, but we only need to
use the FAT partition with the boot artifacts on it.
+
+Verify that the board can boot from the SD card
+^^^
+
+It is worth booting the board from the SD card before trying to boot
RTEMS. Insert the card and power on the board. You should see the messages
on the first console indicating the various boot loader stages and
eventually the Linux kernel. The goal is to interrupt u-boot when given the
chance to access the u-boot command prompt.
+
+Build RTEMS with examples
+^
+
+Build the RTEMS `xilinx-zynqmp-lp64-zu3eg` BSP. Use the ticker.exe sample
which can be found in the directory:
+
+.. code-block:: shell
+
+  build/aarch64/xilinx-zynqmp-lp64-zu3eg/testsuites/samples
+
+Prepare the RTEMS image
+^^^
+
+Prepare your RTEMS image to boot from u-boot with the following commands:
+
+.. code-block:: shell
+
+  $ aarch64-rtems6-objcopy -Obinary ticker.exe ticker.bin
+  $ gzip -9 ticker.bin
+  $ mkimage -A arm64 -O rtems -T kernel -a 0x1000 -e 0x1000 -n
RTEMS -d ticker.bin.gz rtems.img
+
+Boot the RTEMS image
+
+Copy the prepared RTEMS image to the SD card and insert the SD crd in the
ZCU102 board. Power on the board.
+When you see the prompt on the console to interupt u-boot, hit a key to
bring up the u-boot command prompt. On the u-boot command prompt you can
boot your RTEMS image:
+
+.. code-block:: shell
+
+  Zynq-MP> fatload mmc 0:1 0x1000 rtems.img
+  Zynq-MP> bootm 0x1000
+
+This is the entire boot sequence:
+
+.. code-block:: shell
+
+  Pre-FSBL boot Started
+  Xilinx Zynq MP First Stage Boot Loader
+  Release 2020.2   Nov 18 2020  -  11:46:01
+  NOTICE:  ATF running on XCZU9EG/silicon v1/RTL5.1 at 0xfffea000
+  NOTICE:  BL31: v2.2(release):xilinx_rebase_v2.2_2

Re: Info regarding development activity in RTEMS for ARM bsps/Raspberry pi

[Alan Cudmore]

Hi Ritesh,
For the Raspberry Pi, Andre Marques added GPIO, SPI, and I2C support for
his Google Summer of Code project. When this code is merged, it will allow
many other devices to work on the Pi. There is still plenty of other work
to do on the Raspberry Pi BSP including:
- JTAG debugging - I have not had the time to continue my work with the
MiniMod/OpenOCD JTAG debugger. It currently does not work reliably for me.
Another user is using a second Raspberry Pi as a JTAG interface.
- SD card driver - Some work has been done by Andre towards this.
- USB/Network - The ethernet device goes through the USB interface, which
means that a USB stack has to be in place to access the ethernet chip.
- Console & Framebuffer graphics
- Sound?

As you can see, there is plenty to work on with the Raspberry Pi BSP. There
are also plenty of other boards/BSPs to work on, but I am biased. There are
over 2.5 million Pi's out there, and I believe that having first class
RTEMS support will help to expand the RTEMS user base.

Links to Andre's GSOC work:
http://www.rtems.org/wiki/index.php/Raspberry_Pi_BSP_Peripherals

and the blog
http://asuolgsoc2014.wordpress.com/2014/08/18/testing-the-project/

Alan


On Wed, Aug 20, 2014 at 5:40 AM, Hesham Moustafa 
wrote:

> Hi Ritesh,
>
> On Wed, Aug 20, 2014 at 11:28 AM, Ritesh Harjani
>  wrote:
> > Hi All,
> >
> > I have been following RTEMS from quite some time rather I would say my
> > questions have been on & off from this community (although I haven't
> > contributed anything yet). So, this mail is mainly regarding some help
> from
> > the community members so that I can pitch in to contribute something to
> this
> > community.
> >
> > Based on my knowledge I would like to start from ARM bsps/raspberry pi
> as I
> > am seeing quite lot of development activity going on in these areas.
> >
> > If someone can guide me with the following activities it would be great:
> >
> > 1. I need to just start something, may be with a small patch (which
> should
> > be related to the above mentioned area):
> > Earlier I thought of starting with some driver development but without
> > having basic knowledge of RTEMS file structure/other areas, I wasn't
> able to
> > complete it.
> >
> > 2. Need to understand the boot flow and the code initialization routine
> > which can give me an idea as to where all and what all drivers are
> present
> > etc etc..
> >
> >
> > Later may be I can think of porting/developing some driver for any ARM
> bsp.
> >
> >
> > Background activity done till now:
> >
> > 1. Followed all the steps in Alan's Blog
> > (
> http://alanstechnotes.blogspot.in/2013/03/running-your-first-rtems-program-on.html
> ):
> > I was able to run ticker.exe sample test on Raspberry pi. Although there
> are
> > some doubts which I have asked below.
> >
> > 2. Ordered OpenOCD based JTAG board. Once this comes I will make this
> JTAG
> > board start working.
> >
> >
> > Queries:
> > 1. Is by default raspberry pi MMU enabled and all the page table are
> setup
> > ?(from HEAD of git://git.rtems.org/rtems.git)
> >
> > 2. I cannot see any libmmu tests which I think Hesham developed during
> GSOC
> > 2013 ?
> > Do we keep this into different git ?
> >
> Some of my project code has been merged (mainly low-level parts of
> libmm implemented for Raspberry Pi). The other code is held in my old
> github repo here https://github.com/heshamelmatary/rtems-gsoc2013
> > 3. With OpenOCD and gdb is it possible to see all the CP15 coprocessor
> > registers on ARM ?
> >
> > 4. How was Hesham able to debug and see the MMU register settings(like
> > SCTLR.MMU) during his work on GSoc 2013 libmmu development for raspberry
> pi
> > ? Was it QEMU ?
> >
> I was using QEMU for debugging Xilinx Zynq BSP, as well as Realview.
> For Raspberry Pi (worked on the HW board, no simulators), I just used
> printf to print out the values of registers which I need to peek into.
> >
> >
> > Please feel free to guide me through the work plan if anyone have in
> his/her
> > mind for ARM bsps.
> >
> >
> >
> > Thanks
> > Ritesh Harjani
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [GSOC] GPIO status and I2C start

[Alan Cudmore]

Hi Pavel,
Thanks for the feedback, we will definitely get the parameter change in
when the code is submitted.

Alan



On Thu, Aug 21, 2014 at 8:20 AM, Pavel Pisa  wrote:

> Hello everybody,
>
> I am happy that the common GPIO API for RTEMS is developed
> but I have some concerns about IRQ handlers registration.
>
> On Sunday 06 of July 2014 00:58:23 Andre Marques wrote:
> > Hello,
> >
> > The Raspberry Pi GPIO interrupts are already working, and a test case is
> > available to test that [1]. A function is also provided to debounce a
> > switch if needed. The test case requires two switches and two LEDS using
> > the same setup described at [2] by only changing the pin numbers.
>
>
> https://github.com/asuol/rtems/blob/GPIO_API/testsuites/samples/LIBGPIO_TEST_IRQ/init.c
>
> http://wiki.rtems.org/wiki/index.php/Raspberry_Pi_BSP_Peripherals
>
> The registered handler has no context parameter.This is unfortunate
> because there is often need to do same or similar processing
> for more interrupt sources and this way it means to write
> individual handler or trampoline for each pin.
>
> Please change registered handler prototype to same type
> as rtems_interrupt_handler used in rtems_interrupt_handler_install
>
>   typedef void (*rtems_interrupt_handler)(void *);
>
> then function prototype of gpio_enable_interrupt() should add
> void *arg and its value should be stored together with handler
> pointer and pass to the handler when called.
>
> In the fact, Linux kernel goes even more further where it
> statically or runtime allocates numbers for individual
> IO pins interrupt sources in the main interrupt table.
> Then GPIO provides only function to map GPIO number
> to IRQ source number and standard registration
> of interrupt handler is used to register to individual
> pin interrupt. That has advantage, that drivers of peripherals
> do not need to distinguish if their peripheral is connected
> to direct external IRQ source or to the GPIO pin which needs
> cascade IRQ event processing. In RTEMS that would lead to
> use of rtems_interrupt_handler_install even for GPIO IRQs.
>
> But that would require more changes. But passing of context
> to the handler is very important and fortunately RTEMS
> has switched from other handler prototypes to this standard
> years ago already.
>
> Best wishes,
>
> Pavel
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

TOD/RTC questions

[Alan Cudmore]

I am testing out the Raspberry Pi I2C interface by implementing a DS1307
RTC driver.

I started with the libchip/rtc/ds1375.c driver, since it is very close to
the 1307.

In the Raspberry Pi BSP, I added code to i2c_init.c to create a raw device
node for the RTC device, then I added the tod/todcfg.h similar to the
powerpc/mvme3100 BSP.

Using the test functions I can read and write the device, but is there
anything else I need to do in order to tie it to the RTEMS time functions?

For example:
In the shell ( main_date.c ) , the time() function just returns the 1998
epoch. Also, the shell rtc command ( main_rtc.c ) calls
rtems_clock_get_tod, but returns a error. If I use the RTC command and set
the time, it does try to write to my device and subsequent calls to
rtems_clock_tod do not return an error.

Am I missing any setup here?

Finally, is RTC the same as TOD for RTEMS?

Thanks,
Alan
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: TOD/RTC questions

[Alan Cudmore]

I was able to get the ds1307 i2c part working on the Pi. The tod.c 
driver shell was calling setRealTimeToRTEMS() but it was failing in 
rtems_clock_set because my driver was not returning the correct 
rtems_tod format.

Now when I boot the Pi, the rtems time is synced to the battery backed RTC.

Thanks,
Alan

On 8/28/2014 1:26 PM, Joel Sherrill wrote:

On 8/28/2014 12:16 PM, Alan Cudmore wrote:

I am testing out the Raspberry Pi I2C interface by implementing a
DS1307 RTC driver.

I started with the libchip/rtc/ds1375.c driver, since it is very close
to the 1307.

In the Raspberry Pi BSP, I added code to i2c_init.c to create a raw
device node for the RTC device, then I added the tod/todcfg.h similar
to the powerpc/mvme3100 BSP.

Using the test functions I can read and write the device, but is there
anything else I need to do in order to tie it to the RTEMS time functions?

For example:
In the shell ( main_date.c ) , the time() function just returns the
1998 epoch. Also, the shell rtc command ( main_rtc.c ) calls
rtems_clock_get_tod, but returns a error. If I use the RTC command and
set the time, it does try to write to my device and subsequent calls
to rtems_clock_tod do not return an error.

Am I missing any setup here?

Finally, is RTC the same as TOD for RTEMS?


It is a source to set the TOD from. There are some ugly APIs provided
by the RTC driver shell code. They really need new names but I haven't
had any good ideas. :(

See libbsp/shared/tod.c.

setRealTimeFromRTEMS() is probably the missing call you are looking
for.

Thanks,
Alan


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

Re: [PATCH] Add GPIO, I2C and SPI support for the RPi BSP

[Alan Cudmore]

I'm going to try to look at the Pi BSP warnings soon. I can try to help
address some of the issues with this patch as well.

What is the desired cut off date for 4.11?

Alan

On Fri, Oct 31, 2014 at 11:41 AM, Pavel Pisa  wrote:

> Hello Andre,
>
> On Friday 31 of October 2014 12:56:40 Andre Marques wrote:
>
> > +/**
> > + * @brief Generic ISR that clears the event register on the Raspberry Pi
> > and calls + *an user defined ISR.
> > + *
> > + * @param[in] arg Void pointer to a handler_arguments structure.
> > + */
> > +static void generic_handler(void* arg)
> > +{
> > +  handler_arguments* handler_args;
> > +  int rv = 0;
> > +  int pin = 0;
> > +
> > +  handler_args = (handler_arguments*) arg;
> > +
> > +  pin = handler_args->pin_number;
> > +
> > +  /*  If the interrupt was generated by the pin attached to this ISR
> > clears it. */ +  if ( BCM2835_REG(BCM2835_GPIO_GPEDS0) & (1 << pin) )
> > +BCM2835_REG(BCM2835_GPIO_GPEDS0) &= (1 << pin);
> > +
> > +  /* If not lets the next ISR process the interrupt. */
> > +  else
> > +return;
> > +
> > +  /* If this pin has the deboucing function attached, call it. */
> > +  if ( handler_args->debouncing_tick_count > 0 ) {
> > +rv = debounce_switch(pin);
> > +
> > +if ( rv < 0 )
> > +  return;
> > +  }
> > +
> > +  /* Call the user's ISR. */
> > +  (handler_args->handler) (handler_args->handler_arg);
> > +}
>
> There has to be mechanism (array of pointers) for registering args
> for each pin handler routine.
>
> > +/**
> > + * @brief Enables interrupts to be generated on a given GPIO pin.
> > + *When fired that interrupt will call the given handler.
> > + *
> > + * @param[in] dev_pin Raspberry Pi GPIO pin label number (not its
> position
> > + *on the header).
> > + * @param[in] interrupt Type of interrupt to enable for the pin.
> > + * @param[in] handler Pointer to a function that will be called every
> time
> > + *@var interrupt is generated. This function must
> have
> > + *no receiving parameters and return void.
>   @param[in] arg or context
>
> > + *
> > + * @retval 0 Interrupt successfully enabled for this pin.
> > + * @retval -1 Could not replace the currently active interrupt on this
> > pin, or + *unknown @var interrupt.
> > + */
> > +int gpio_enable_interrupt(int dev_pin, gpio_interrupt interrupt, void
> > (*handler)(void)) +{
>
>
> int gpio_enable_interrupt(int dev_pin, gpio_interrupt interrupt, void
>(*handler)(void *arg), void *arg)
>
> It would worth to be able to register mutiple handlers for single
> pin for case o emulating shared IRQ line - i.e. ISA bus, then information
> about IRQ handled/unhandled state has to be returned by handler - but that
> is not critical. Argument is critical as I have already stated.
>
> The handler function prototype should be same as for RTEMS ISR registration
>
> typedef void (*rtems_interrupt_handler)(void *);
>
> This allows to use drivers for some generic chips to be connected
> to some external bus same way on different CPU and boards architectures
> with same ISR handler when directly connected to some external interrupt
> input and use same driver+handler when interrupt is connected
> to GPIO ISR multiplexor.
>
> I have already raised this concern for previous patch version
> - see mail thread
>
> http://article.gmane.org/gmane.os.rtems.user/13211
>
> > +  rtems_status_code sc;
> > +  rpi_gpio_pin *pin;
> > +
> > +  /* Only consider GPIO pins up to 31. */
> > +  if ( dev_pin > 31 )
> > +return -1;
> > +
> > +  pin = &gpio_pin[dev_pin-1];
> > +
> > +  /* If the pin already has an enabled interrupt removes it first,
> > +   * as well as its handler. */
> > +  if ( pin->enabled_interrupt != NONE ) {
> > +sc = gpio_disable_interrupt(dev_pin);
> > +
> > +if ( sc != RTEMS_SUCCESSFUL )
> > +  return -1;
> > +  }
> > +
> > +  pin->h_args.pin_number = dev_pin;
> > +  pin->h_args.handler = handler;
>
>   +  pin->h_args.handler_arg = arg;
>
>
> > +
> > +  pin->h_args.last_isr_tick = rtems_clock_get_ticks_since_boot();
> > +
> > +  /* Installs the generic_handler, which will call the user handler
> > received +   * a parameter. */
> > +  sc = rtems_interrupt_handler_install(BCM2835_IRQ_ID_GPIO_0,
> > +   NULL,
> > +   RTEMS_INTERRUPT_SHARED,
> > +   (rtems_interrupt_handler)
> > generic_handler, +   &(pin->h_args));
>
> The use of RTEMS_INTERRUPT_SHARED and registering multiple handlers
> for single pin group is significant overhead. It would be much faster
> to register only one handler (when gpio_enable_interrupt is called first
> time).
> Then read interrupt status register (if before HW masking, apply mask)
> and use ffs (find first bit set) in loop to process all pending events.
> Each time ffs gives the bit, clear the bit in the local copy,
> retrieve pi

ARM bsp warnings ( shared/abort.c vs. shared/simple_abort.c )

[Alan Cudmore]

There are two warnings in the raspberry pi BSP due to the lack of
prototypes in simple_abort.c
the rtl22xx BSP has the same warnings because it also uses simple_abort.c.

Many of the other ARM BSPs use abort.c, which has prototypes for the two
functions.

The two functions in simple_abort.c and abort.c are nearly the same.

Does anyone know why there is a simple_abort.c ?

The potential fixes include:
1. removing simple_abort.c and have the Raspberry Pi and rtl22xx BSPs use
abort.c or
2. simply putting the prototypes in simple_abort.c to take care of the
warnings.

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

Re: ARM bsp warnings ( shared/abort.c vs. shared/simple_abort.c )

[Alan Cudmore]

On 11/1/2014 1:38 PM, Gedare Bloom wrote:

On Sat, Nov 1, 2014 at 1:12 PM, Alan Cudmore  wrote:

There are two warnings in the raspberry pi BSP due to the lack of prototypes
in simple_abort.c
the rtl22xx BSP has the same warnings because it also uses simple_abort.c.

Many of the other ARM BSPs use abort.c, which has prototypes for the two
functions.

The two functions in simple_abort.c and abort.c are nearly the same.

Does anyone know why there is a simple_abort.c ?

The potential fixes include:
1. removing simple_abort.c and have the Raspberry Pi and rtl22xx BSPs use
abort.c or
2. simply putting the prototypes in simple_abort.c to take care of the
warnings.


I prefer #1. I also would like to see the prototypes in abort.c go away.


OK.
It looks like the difference is that simple_abort.c uses less memory for 
the ARM CPUs that are very limited. I must have based the original Pi 
BSP on a BSP that used simple_abort.c instead of abort.c


I can keep simple_abort.c if we feel that the savings are still needed. 
At this point only the rtl22xx BSP would use it.


As for the prototypes, I can create a header. Should it go in 
libbsp/arm/shared/include or just in libbsp/arm/shared/abort?

For example, I see that libbsp/arm/shared/uart has a uart.h.

Also, if we keep simple_abort.c, it looks like both files could use the 
same header, since the defines and prototypes are the same.






Alan


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


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

[PATCH] libbsp ARM: create abort.h to eliminate warnings Created libbsp/arm/shared/abort/abort.h Edited abort.c and simple_abort.c to include abort.h Changed Raspberry Pi BSP to use abort.c instead of

[Alan Cudmore]

Signed-off-by: Alan Cudmore 
---
 c/src/lib/libbsp/arm/raspberrypi/Makefile.am |  2 +-
 c/src/lib/libbsp/arm/shared/abort/abort.c| 28 +---
 c/src/lib/libbsp/arm/shared/abort/abort.h| 57 
 c/src/lib/libbsp/arm/shared/abort/simple_abort.c | 22 +
 4 files changed, 60 insertions(+), 49 deletions(-)
 create mode 100644 c/src/lib/libbsp/arm/shared/abort/abort.h

diff --git a/c/src/lib/libbsp/arm/raspberrypi/Makefile.am 
b/c/src/lib/libbsp/arm/raspberrypi/Makefile.am
index 839c8de..a606d9d 100644
--- a/c/src/lib/libbsp/arm/raspberrypi/Makefile.am
+++ b/c/src/lib/libbsp/arm/raspberrypi/Makefile.am
@@ -86,7 +86,7 @@ libbsp_a_SOURCES += ../../shared/cpucounterdiff.c
 libbsp_a_SOURCES += ../../shared/gnatinstallhandler.c
 libbsp_a_SOURCES += ../../shared/sbrk.c
 libbsp_a_SOURCES += ../../shared/src/stackalloc.c
-libbsp_a_SOURCES += ../shared/abort/simple_abort.c
+libbsp_a_SOURCES += ../shared/abort/abort.c
 libbsp_a_SOURCES += ../shared/startup/bsp-start-memcpy.S
 libbsp_a_SOURCES += ../shared/arm-cp15-set-ttb-entries.c
 
diff --git a/c/src/lib/libbsp/arm/shared/abort/abort.c 
b/c/src/lib/libbsp/arm/shared/abort/abort.c
index d509a2a..8dc70d7 100644
--- a/c/src/lib/libbsp/arm/shared/abort/abort.c
+++ b/c/src/lib/libbsp/arm/shared/abort/abort.c
@@ -24,33 +24,7 @@
 #include 
 #include 
 
-#define INSN_MASK 0xc5
-
-#define INSN_STM1 0x80
-#define INSN_STM2 0x84
-#define INSN_STR  0x40
-#define INSN_STRB 0x44
-
-#define INSN_LDM1 0x81
-#define INSN_LDM230x85
-#define INSN_LDR  0x41
-#define INSN_LDRB 0x45
-
-#define GET_RD(x) ((x & 0xf000) >> 12)
-#define GET_RN(x) ((x & 0x000f) >> 16)
-
-#define GET_U(x)  ((x & 0x0080) >> 23)
-#define GET_I(x)  ((x & 0x0200) >> 25)
-
-#define GET_REG(r, ctx)  (((uint32_t   *)ctx)[r])
-#define SET_REG(r, ctx, v)   (((uint32_t   *)ctx)[r] = v)
-#define GET_OFFSET(insn) (insn & 0xfff)
-
-/*
- * Prototypes
- */
-void _print_full_context(uint32_t);
-void do_data_abort(uint32_t, uint32_t, Context_Control *);
+#include "abort.h"
 
 uint32_t g_data_abort_cnt = 0;
 /*this is a big overhead for MCU only got 16K RAM*/
diff --git a/c/src/lib/libbsp/arm/shared/abort/abort.h 
b/c/src/lib/libbsp/arm/shared/abort/abort.h
new file mode 100644
index 000..14feac3
--- /dev/null
+++ b/c/src/lib/libbsp/arm/shared/abort/abort.h
@@ -0,0 +1,57 @@
+/**
+ *  @file
+ *
+ *  @ingroup arm_abort
+ *
+ *  @brief ARM abort support
+ */
+
+/*
+ *  COPYRIGHT (c) 2007 Ray Xu.
+ *  mailto: Rayx at gmail dot com
+ *
+ *  COPYRIGHT (c) 2000 Canon Research Centre France SA.
+ *  Emmanuel Raguet, mailto:rag...@crf.canon.fr
+ *
+ *  Copyright (c) 2002 Advent Networks, Inc
+ *  Jay Monkman 
+ *
+ *  The license and distribution terms for this file may be
+ *  found in the file LICENSE in this distribution or at
+ *  http://www.rtems.org/license/LICENSE.
+ *
+ */
+
+#ifndef _BSPABORT_H
+#define _BSPABORT_H
+
+#define INSN_MASK 0xc5
+
+#define INSN_STM1 0x80
+#define INSN_STM2 0x84
+#define INSN_STR  0x40
+#define INSN_STRB 0x44
+
+#define INSN_LDM1 0x81
+#define INSN_LDM230x85
+#define INSN_LDR  0x41
+#define INSN_LDRB 0x45
+
+#define GET_RD(x) ((x & 0xf000) >> 12)
+#define GET_RN(x) ((x & 0x000f) >> 16)
+
+#define GET_U(x)  ((x & 0x0080) >> 23)
+#define GET_I(x)  ((x & 0x0200) >> 25)
+
+#define GET_REG(r, ctx)  (((uint32_t   *)ctx)[r])
+#define SET_REG(r, ctx, v)   (((uint32_t   *)ctx)[r] = v)
+#define GET_OFFSET(insn) (insn & 0xfff)
+
+/*
+ * Prototypes
+ */
+void _print_full_context(uint32_t);
+void do_data_abort(uint32_t, uint32_t, Context_Control *);
+
+#endif  /* _BSPABORT_H_ */
+
diff --git a/c/src/lib/libbsp/arm/shared/abort/simple_abort.c 
b/c/src/lib/libbsp/arm/shared/abort/simple_abort.c
index 51854bd..57f9a02 100644
--- a/c/src/lib/libbsp/arm/shared/abort/simple_abort.c
+++ b/c/src/lib/libbsp/arm/shared/abort/simple_abort.c
@@ -21,27 +21,7 @@
 #include 
 #include 
 
-#define INSN_MASK 0xc5
-
-#define INSN_STM1 0x80
-#define INSN_STM2 0x84
-#define INSN_STR  0x40
-#define INSN_STRB 0x44
-
-#define INSN_LDM1 0x81
-#define INSN_LDM230x85
-#define INSN_LDR  0x41
-#define INSN_LDRB 0x45
-
-#define GET_RD(x) ((x & 0xf000) >> 12)
-#define GET_RN(x) ((x & 0x000f) >> 16)
-
-#define GET_U(x)  ((x & 0x0080) >> 23)
-#define GET_I(x)  ((x & 0x0200) >> 25)
-
-#define GET_REG(r, ctx)  (((uint32_t   *)ctx)[r])
-#define SET_REG(r, ctx, v)   (((uint32_t   *)ctx)[r] = v)
-#define GET_OFFSET(insn) (insn & 0xfff)
+#include "abort.h&q

Re: [PATCH] libbsp ARM: create abort.h to eliminate warnings Created libbsp/arm/shared/abort/abort.h Edited abort.c and simple_abort.c to include abort.h Changed Raspberry Pi BSP to use abort.c instea

[Alan Cudmore]

OK, that makes sense. I'll fix it and resubmit the patch. Any other ARM
BSPs?
Alan
On Nov 3, 2014 2:03 AM, "Sebastian Huber" <
sebastian.hu...@embedded-brains.de> wrote:

> On 03/11/14 02:59, Alan Cudmore wrote:
>
>> -libbsp_a_SOURCES += ../shared/abort/simple_abort.c
>> +libbsp_a_SOURCES += ../shared/abort/abort.c
>>
>
> Since this BSP uses the shared start.S file, I would prefer to remove
> simple_abort.c and abort.c from the Makefile.am.  These files should go
> away in the long run.
>
> The default abort handler is now in:
>
> http://git.rtems.org/rtems/tree/cpukit/score/cpu/arm/
> armv4-exception-default.S
>
> --
> Sebastian Huber, embedded brains GmbH
>
> Address : Dornierstr. 4, D-82178 Puchheim, Germany
> Phone   : +49 89 189 47 41-16
> Fax : +49 89 189 47 41-09
> E-Mail  : sebastian.hu...@embedded-brains.de
> PGP : Public key available on request.
>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] libbsp ARM: create abort.h to eliminate warnings Created libbsp/arm/shared/abort/abort.h Edited abort.c and simple_abort.c to include abort.h Changed Raspberry Pi BSP to use abort.c instea

[Alan Cudmore]

I'm not sure any of the ARM BSPs use the abort.c or simple_abort.c, even if
they have the code included.
I don't have access to the code right now, but I will take a look at the
ARM BSPs and remove it from the ones that use the shared start.S.

If the ARM BSPs that do not use the shared start.S include the code, but
never call it, I can remove it, if that is what is best. We could even
remove abort.c and simple_abort.c completely. Just let me know.

Alan


On Mon, Nov 3, 2014 at 3:08 PM, Joel Sherrill 
wrote:

>
> On 11/3/2014 5:22 AM, Alan Cudmore wrote:
>
> OK, that makes sense. I'll fix it and resubmit the patch. Any other ARM
> BSPs?
>
>
> The warning only shows up in these:
>
> $ grep abort.c warnings-20141030a.txt
>   2 c/src/lib/libbsp/arm/rtl22xx/../shared/abort/simple_abort.c:56:6:
> warning: no previous prototype for '_print_full_context'
> [-Wmissing-prototypes]
>   2 c/src/lib/libbsp/arm/rtl22xx/../shared/abort/simple_abort.c:108:6:
> warning: no previous prototype for 'do_data_abort' [-Wmissing-prototypes]
>   1
> c/src/lib/libbsp/arm/raspberrypi/../shared/abort/simple_abort.c:56:6:
> warning: no previous prototype for '_print_full_context'
> [-Wmissing-prototypes]
>   1
> c/src/lib/libbsp/arm/raspberrypi/../shared/abort/simple_abort.c:108:6:
> warning: no previous prototype for 'do_data_abort' [-Wmissing-prototypes]
>
> which matches a grep:
>
> $ grep simple_abort.c */M*am
> raspberrypi/Makefile.am:libbsp_a_SOURCES += ../shared/abort/simple_abort.c
> rtl22xx/Makefile.am:libbsp_a_SOURCES += ../shared/abort/simple_abort.c
>
> When I "grep start.S */M*.am" from libbsp/arm, most BSPs use
> shared/start/start.S
> but a few have their own start.S. Not sure what the impact of that is.
>
> --joel
>
>
>  Alan
> On Nov 3, 2014 2:03 AM, "Sebastian Huber" <
> sebastian.hu...@embedded-brains.de> wrote:
>
>> On 03/11/14 02:59, Alan Cudmore wrote:
>>
>>> -libbsp_a_SOURCES += ../shared/abort/simple_abort.c
>>> +libbsp_a_SOURCES += ../shared/abort/abort.c
>>>
>>
>> Since this BSP uses the shared start.S file, I would prefer to remove
>> simple_abort.c and abort.c from the Makefile.am.  These files should go
>> away in the long run.
>>
>> The default abort handler is now in:
>>
>>
>> http://git.rtems.org/rtems/tree/cpukit/score/cpu/arm/armv4-exception-default.S
>>
>> --
>> Sebastian Huber, embedded brains GmbH
>>
>> Address : Dornierstr. 4, D-82178 Puchheim, Germany
>> Phone   : +49 89 189 47 41-16
>> Fax : +49 89 189 47 41-09
>> E-Mail  : sebastian.hu...@embedded-brains.de
>> PGP : Public key available on request.
>>
>> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>>
>
> --
> Joel Sherrill, Ph.D. Director of Research & 
> developmentjoel.sherr...@oarcorp.comOn-Line Applications Research
> Ask me about RTEMS: a free RTOS  Huntsville AL 35805
> Support Available(256) 722-9985
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] Add GPIO, I2C and SPI support for the RPi BSP

[Alan Cudmore]

This is a tough problem. We have plenty of inexpensive SPI and I2C devices
to mix and match with low cost boards such as the Pi and Beaglebone, but it
could all become obsolete quickly.
If we put a bunch of SPI and I2C drivers in the RTEMS repo, then how do we
test and maintain them without duplicating a custom breadboard setup?

Even an examples repo will have to come with a schematic to build the setup
necessary to run a program.

I have RTEMS drivers for some of the devices I have connected to my Pi,
such as the DS1302 RTC, an I2C GPIO expansion port, and an LCD display. I
was going to expand my RKI application to have a driver framework, so these
type of drivers could be integrated and tested without having to integrate
them into the RTEMS tree and BSP.

Alan

On Wed, Nov 5, 2014 at 9:32 AM, Gedare Bloom  wrote:

> I'm in support of putting bsp-specific examples in examples-v2. And
> renaming the repository...
>
> Reducing repo sprawl is good.
>
> -Gedare
>
> On Wed, Nov 5, 2014 at 12:32 AM, Chris Johns  wrote:
> > On 5/11/2014 2:40 pm, Gedare Bloom wrote:
> >>
> >> These are ideal for BSP-specific testing framework, which we presently
> >> lack. I'm not certain where they should go.
> >
> >
> > What about examples-v2 ? You could add a boards directory and the code
> under
> > arch/bsp. The waf build system lets you know when a specific arch/bsp is
> > being built.
> >
> >> Maybe a repo for BSP-specific examples is a useful idea.
> >
> >
> > I am attempting to lower the number of repos we have. Every repo needs
> > testing.
> >
> > Chris
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] libbsp ARM: create abort.h to eliminate warnings Created libbsp/arm/shared/abort/abort.h Edited abort.c and simple_abort.c to include abort.h Changed Raspberry Pi BSP to use abort.c instea

[Alan Cudmore]

On 11/5/2014 9:39 AM, Sebastian Huber wrote:

On 05/11/14 15:35, Alan Cudmore wrote:
If the ARM BSPs that do not use the shared start.S include the code, 
but never
call it, I can remove it, if that is what is best. We could even 
remove abort.c

and simple_abort.c completely. Just let me know.


It would be best to get rid of these files.

I did some investigation, and it is not going to be as easy as I thought 
to remove libbsp/arm/shared/abort/*.c


The following ARM BSPs use score: arm_exc_handler_high.c, 
arm_exc_handler_low.S, which in turn use shared abort.c ( or 
simple_abort.c ):

 csb336,
 csb337,
 edb7312,
 gp32,
 gumstix,
 rtx22xx

I think these will eventually have to be converted to use the ARM shared 
start.S.


The raspberrypi, beagle, and gdbarmsim BSPs compile the shared/abort 
files but do not use them.


So for now I can do the following:
1. remove the use of shared/abort/abort*.c from raspberrypi, beagle, and 
gdbarmsim ( in Makefile.am )
2. include a header file in shared/abort to eliminate future warnings 
for BSPs that use abort.c simple_abort.c


Alan


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

[PATCH] ARM removed shared/abort from several ARM BSPs

[Alan Cudmore]

---
 c/src/lib/libbsp/arm/beagle/Makefile.am  |  1 -
 c/src/lib/libbsp/arm/gdbarmsim/Makefile.am   |  2 -
 c/src/lib/libbsp/arm/raspberrypi/Makefile.am |  1 -
 c/src/lib/libbsp/arm/shared/abort/abort.c| 29 +
 c/src/lib/libbsp/arm/shared/abort/abort.h| 52 
 c/src/lib/libbsp/arm/shared/abort/simple_abort.c | 24 +--
 6 files changed, 55 insertions(+), 54 deletions(-)
 create mode 100644 c/src/lib/libbsp/arm/shared/abort/abort.h

diff --git a/c/src/lib/libbsp/arm/beagle/Makefile.am 
b/c/src/lib/libbsp/arm/beagle/Makefile.am
index c6cf9e79..abef8ba 100644
--- a/c/src/lib/libbsp/arm/beagle/Makefile.am
+++ b/c/src/lib/libbsp/arm/beagle/Makefile.am
@@ -85,7 +85,6 @@ libbsp_a_SOURCES += ../../shared/src/stackalloc.c
 libbsp_a_SOURCES += ../../shared/cpucounterdiff.c
 libbsp_a_SOURCES += ../../shared/timerstub.c
 libbsp_a_SOURCES += ../../shared/cpucounterread.c
-libbsp_a_SOURCES += ../shared/abort/simple_abort.c
 libbsp_a_SOURCES += ../shared/startup/bsp-start-memcpy.S
 libbsp_a_SOURCES += ../shared/arm-cp15-set-exception-handler.c
 
diff --git a/c/src/lib/libbsp/arm/gdbarmsim/Makefile.am 
b/c/src/lib/libbsp/arm/gdbarmsim/Makefile.am
index f13ad7d..3265494 100644
--- a/c/src/lib/libbsp/arm/gdbarmsim/Makefile.am
+++ b/c/src/lib/libbsp/arm/gdbarmsim/Makefile.am
@@ -45,8 +45,6 @@ libbsp_a_SOURCES += ../../shared/console-polled.c 
console/console-io.c
 libbsp_a_SOURCES += ../../shared/clock_driver_simidle.c
 # timer
 libbsp_a_SOURCES += ../../shared/timerstub.c
-# above
-libbsp_a_SOURCES += ../shared/abort/abort.c
 # start hooks
 libbsp_a_SOURCES += startup/bspstarthooks.c
 libbsp_a_SOURCES += ../shared/startup/bsp-start-memcpy.S
diff --git a/c/src/lib/libbsp/arm/raspberrypi/Makefile.am 
b/c/src/lib/libbsp/arm/raspberrypi/Makefile.am
index 839c8de..ed134fa 100644
--- a/c/src/lib/libbsp/arm/raspberrypi/Makefile.am
+++ b/c/src/lib/libbsp/arm/raspberrypi/Makefile.am
@@ -86,7 +86,6 @@ libbsp_a_SOURCES += ../../shared/cpucounterdiff.c
 libbsp_a_SOURCES += ../../shared/gnatinstallhandler.c
 libbsp_a_SOURCES += ../../shared/sbrk.c
 libbsp_a_SOURCES += ../../shared/src/stackalloc.c
-libbsp_a_SOURCES += ../shared/abort/simple_abort.c
 libbsp_a_SOURCES += ../shared/startup/bsp-start-memcpy.S
 libbsp_a_SOURCES += ../shared/arm-cp15-set-ttb-entries.c
 
diff --git a/c/src/lib/libbsp/arm/shared/abort/abort.c 
b/c/src/lib/libbsp/arm/shared/abort/abort.c
index d509a2a..657b2f4 100644
--- a/c/src/lib/libbsp/arm/shared/abort/abort.c
+++ b/c/src/lib/libbsp/arm/shared/abort/abort.c
@@ -23,34 +23,7 @@
 #include 
 #include 
 #include 
-
-#define INSN_MASK 0xc5
-
-#define INSN_STM1 0x80
-#define INSN_STM2 0x84
-#define INSN_STR  0x40
-#define INSN_STRB 0x44
-
-#define INSN_LDM1 0x81
-#define INSN_LDM230x85
-#define INSN_LDR  0x41
-#define INSN_LDRB 0x45
-
-#define GET_RD(x) ((x & 0xf000) >> 12)
-#define GET_RN(x) ((x & 0x000f) >> 16)
-
-#define GET_U(x)  ((x & 0x0080) >> 23)
-#define GET_I(x)  ((x & 0x0200) >> 25)
-
-#define GET_REG(r, ctx)  (((uint32_t   *)ctx)[r])
-#define SET_REG(r, ctx, v)   (((uint32_t   *)ctx)[r] = v)
-#define GET_OFFSET(insn) (insn & 0xfff)
-
-/*
- * Prototypes
- */
-void _print_full_context(uint32_t);
-void do_data_abort(uint32_t, uint32_t, Context_Control *);
+#include "abort.h"
 
 uint32_t g_data_abort_cnt = 0;
 /*this is a big overhead for MCU only got 16K RAM*/
diff --git a/c/src/lib/libbsp/arm/shared/abort/abort.h 
b/c/src/lib/libbsp/arm/shared/abort/abort.h
new file mode 100644
index 000..6d8704f
--- /dev/null
+++ b/c/src/lib/libbsp/arm/shared/abort/abort.h
@@ -0,0 +1,52 @@
+/*
+ *  COPYRIGHT (c) 2007 Ray Xu.
+ *  mailto: Rayx at gmail dot com
+ *
+ *  COPYRIGHT (c) 2000 Canon Research Centre France SA.
+ *  Emmanuel Raguet, mailto:rag...@crf.canon.fr
+ *
+ *  Copyright (c) 2002 Advent Networks, Inc
+ *  Jay Monkman 
+ *
+ *  The license and distribution terms for this file may be
+ *  found in the file LICENSE in this distribution or at
+ *  http://www.rtems.org/license/LICENSE.
+ *
+ */
+
+#ifndef _BSPABORT_H
+#define _BSPABORT_H
+
+#include 
+#include 
+#include 
+
+#define INSN_MASK 0xc5
+
+#define INSN_STM1 0x80
+#define INSN_STM2 0x84
+#define INSN_STR  0x40
+#define INSN_STRB 0x44
+
+#define INSN_LDM1 0x81
+#define INSN_LDM230x85
+#define INSN_LDR  0x41
+#define INSN_LDRB 0x45
+
+#define GET_RD(x) ((x & 0xf000) >> 12)
+#define GET_RN(x) ((x & 0x000f) >> 16)
+
+#define GET_U(x)  ((x & 0x0080) >> 23)
+#define GET_I(x)  ((x & 0x0200) >> 25)
+
+#define GET_REG(r, ctx)  (((uint32_t   *)ctx)[r])
+#define SET_REG(r, ctx, v)   (((uint32_t   *)ctx)[r] = v)
+#define GET_OFFSET(insn) (insn & 0xfff)
+
+/*
+ * Prototypes
+ */
+void _print_full_context(uint32_t);
+void do_data

Re: [PATCH 2/9] Add I2C driver framework

[Alan Cudmore]

Hi Sebastian,
This sounds like a nice improvement.  Is this intended to be a replacement
for the RTEMS libi2c?
Are any updates to existing i2c drivers or code required?

Alan

On Thu, Nov 13, 2014 at 4:30 AM, Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> This I2C driver framework has some major differences compared to libi2c.
>
> * It is compatible to the Linux I2C user-space API.
>
> * It uses generic IMFS nodes and thus reduces the levels of indirection.
>
> * The drivers don't have to mess around with minor numbers to get their
>   state information.
>
> * No arbitrary bus controller model is assumed.  The main task of a I2C
>   bus controller driver is to process I2C messages.  How this is done is
>   private to the driver.
>
> * Scatter/gather operations are supported.
> ---
>  cpukit/dev/Makefile.am|  11 +
>  cpukit/dev/i2c/i2c-bus.c  | 337 ++
>  cpukit/dev/i2c/i2c-dev.c  | 291 +++
>  cpukit/dev/include/dev/i2c/i2c.h  | 430
> ++
>  cpukit/dev/preinstall.am  |   9 +
>  cpukit/wrapup/Makefile.am |   1 +
>  testsuites/libtests/Makefile.am   |   1 +
>  testsuites/libtests/configure.ac  |   1 +
>  testsuites/libtests/i2c01/Makefile.am |  19 ++
>  testsuites/libtests/i2c01/i2c01.doc   |  11 +
>  testsuites/libtests/i2c01/i2c01.scn   |   2 +
>  testsuites/libtests/i2c01/init.c  | 286 ++
>  12 files changed, 1399 insertions(+)
>  create mode 100644 cpukit/dev/i2c/i2c-bus.c
>  create mode 100644 cpukit/dev/i2c/i2c-dev.c
>  create mode 100644 cpukit/dev/include/dev/i2c/i2c.h
>  create mode 100644 testsuites/libtests/i2c01/Makefile.am
>  create mode 100644 testsuites/libtests/i2c01/i2c01.doc
>  create mode 100644 testsuites/libtests/i2c01/i2c01.scn
>  create mode 100644 testsuites/libtests/i2c01/init.c
>
> diff --git a/cpukit/dev/Makefile.am b/cpukit/dev/Makefile.am
> index 5f8fee6..c2913a6 100644
> --- a/cpukit/dev/Makefile.am
> +++ b/cpukit/dev/Makefile.am
> @@ -1,12 +1,23 @@
>  include $(top_srcdir)/automake/compile.am
> +include $(top_srcdir)/automake/multilib.am
>
>  include_devdir = $(includedir)/dev
>  include_dev_HEADERS =
>
> +include_dev_i2cdir = $(includedir)/dev/i2c
> +include_dev_i2c_HEADERS =
> +include_dev_i2c_HEADERS += include/dev/i2c/i2c.h
> +
>  include_linuxdir = $(includedir)/linux
>  include_linux_HEADERS =
>  include_linux_HEADERS += include/linux/i2c.h
>  include_linux_HEADERS += include/linux/i2c-dev.h
>
> +noinst_LIBRARIES = libdev.a
> +
> +libdev_a_SOURCES =
> +libdev_a_SOURCES += i2c/i2c-bus.c
> +libdev_a_SOURCES += i2c/i2c-dev.c
> +
>  include $(srcdir)/preinstall.am
>  include $(top_srcdir)/automake/local.am
> diff --git a/cpukit/dev/i2c/i2c-bus.c b/cpukit/dev/i2c/i2c-bus.c
> new file mode 100644
> index 000..5ab185d
> --- /dev/null
> +++ b/cpukit/dev/i2c/i2c-bus.c
> @@ -0,0 +1,337 @@
> +/**
> + * @file
> + *
> + * @brief Inter-Integrated Circuit (I2C) Bus Implementation
> + *
> + * @ingroup I2CBus
> + */
> +
> +/*
> + * Copyright (c) 2014 embedded brains GmbH.  All rights reserved.
> + *
> + *  embedded brains GmbH
> + *  Dornierstr. 4
> + *  82178 Puchheim
> + *  Germany
> + *  
> + *
> + * The license and distribution terms for this file may be
> + * found in the file LICENSE in this distribution or at
> + * http://www.rtems.org/license/LICENSE.
> + */
> +
> +#if HAVE_CONFIG_H
> +  #include "config.h"
> +#endif
> +
> +#include 
> +
> +#include 
> +
> +#include 
> +#include 
> +
> +void i2c_bus_obtain(i2c_bus *bus)
> +{
> +  rtems_status_code sc;
> +
> +  sc = rtems_semaphore_obtain(bus->mutex, RTEMS_WAIT, RTEMS_NO_TIMEOUT);
> +  _Assert(sc == RTEMS_SUCCESSFUL);
> +  (void) sc;
> +}
> +
> +void i2c_bus_release(i2c_bus *bus)
> +{
> +  rtems_status_code sc;
> +
> +  sc = rtems_semaphore_release(bus->mutex);
> +  _Assert(sc == RTEMS_SUCCESSFUL);
> +  (void) sc;
> +}
> +
> +int i2c_bus_transfer(i2c_bus *bus, i2c_msg *msgs, uint32_t msg_count)
> +{
> +  int err;
> +
> +  _Assert(msg_count > 0);
> +
> +  i2c_bus_obtain(bus);
> +  err = (*bus->transfer)(bus, msgs, msg_count);
> +  i2c_bus_release(bus);
> +
> +  return err;
> +}
> +
> +static ssize_t i2c_bus_read(
> +  rtems_libio_t *iop,
> +  void *buffer,
> +  size_t count
> +)
> +{
> +  i2c_bus *bus = IMFS_generic_get_context_by_iop(iop);
> +  i2c_msg msg = {
> +.addr = bus->default_address,
> +.flags = I2C_M_RD,
> +.len = (uint16_t) count,
> +.buf = buffer
> +  };
> +  int err;
> +
> +  if (bus->ten_bit_address) {
> +msg.flags |= I2C_M_TEN;
> +  }
> +
> +  err = i2c_bus_transfer(bus, &msg, 1);
> +  if (err == 0) {
> +return msg.len;
> +  } else {
> +rtems_set_errno_and_return_minus_one(-err);
> +  }
> +}
> +
> +static ssize_t i2c_bus_write(
> +  rtems_libio_t *iop,
> +  const void *buffer,
> +  size_t count
> +)
> +{
> +  i2c_bus *bus = IMFS_generic_get_context_by_iop(iop);
> +  i2c_msg msg = {
> +.addr = bu

Re: [PATCH] Add GPIO, I2C and SPI support for the RPi BSP

[Alan Cudmore]

Is the ARM Zync BSP using the new i2c API?
I was looking through the BSP and did not see how it is initialized.

Also, the current libi2c supports SPI. Does anyone see a problem with using
libi2c for SPI and the new i2c API for i2c?

Finally, will new i2c drivers go in libchip, or in cpukit/dev ?

Thanks,
Alan

On Wed, Dec 10, 2014 at 7:41 PM, Andre Marques <
andre.lousa.marq...@gmail.com> wrote:
>
> On 12/10/14 22:36, Chris Johns wrote:
>
>> On 11/12/2014 5:27 am, Alan Cudmore wrote:
>>
>>> Andre,
>>> Thanks for submitting this. I think we need one minor change:
>>> Could you remove the include and the call to init the mcp23008 driver?
>>>
>>> After your code is in the tree, I will propose a patch to allow
>>> execution of application specific driver init functions that can be
>>> called from the BSP i2c and SPI driver init functions.
>>>
>>
>> Is the I2C code for the new I2C API or the old one ?
>>
>> Chris
>>
>
> It still uses the old API (libi2c) for both i2c and spi.
>
> --André Marques
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] Add GPIO, I2C and SPI support for the RPi BSP

[Alan Cudmore]

Thanks Sebastian and Chris ,
I will look at converting the Pi I2C code to this new interface.

What Zync boards does RTEMS run on? Will it run on the Micro Zed?

Finally, do we have a target for 4.11?  I probably will not get any 
serious development time for another week or so.


Thanks,
Alan

On 12/16/2014 4:38 AM, Sebastian Huber wrote:

Hello Alan,

On 15/12/14 21:19, Alan Cudmore wrote:

Is the ARM Zync BSP using the new i2c API?


yes, see file cadence-i2c.c and the functions mentioned by Chris.


I was looking through the BSP and did not see how it is initialized.

Also, the current libi2c supports SPI. Does anyone see a problem with 
using libi2c for SPI and the new i2c API for i2c?


I think we need also something similar for SPI which is also message 
based, e.g.


struct spi_msg {
uint16_t chip_select;
uint16_t len;
uint32_t bit_rate;
uint32_t flags;
const uint8_t *out;
uint8_t *in;
};

This makes it easier to support sophisticated SPI modules like the 
Freescale DSPI.




Finally, will new i2c drivers go in libchip, or in cpukit/dev ?


The I2C device drivers (devices connected via the I2C bus) should go 
into cpukit/dev and should have a test case in testsuites/libtests/i2c01.


The I2C bud drivers should be as general as possible. Unfortunately we 
don't have a bus space abstraction yet, so I still placed the first 
I2C bus driver into the BSP.  This is not the right location in the 
long run.




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

Re: [PATCH] Add GPIO, I2C and SPI support for the RPi BSP

[Alan Cudmore]

I have been looking at the new I2C API to see what needs to be ported over
on the i2c.

Why was the Linux API chosen over FreeBSD? Wouldn't we want to keep going
down the *BSD path to provide drivers and libraries?

Alan


On Tue, Dec 16, 2014 at 7:02 PM, Chris Johns  wrote:

> On 17/12/2014 8:43 am, Alan Cudmore wrote:
>
>> Thanks Sebastian and Chris ,
>> I will look at converting the Pi I2C code to this new interface.
>>
>> What Zync boards does RTEMS run on? Will it run on the Micro Zed?
>>
>>
> I have it running on custom hardware. The I2C module is hard IP in the PS
> so it should run on any Zynq. All you need to do is get the MIO configured
> correctly which normally is via the ps7_init files the design tool
> generates.
>
>  Finally, do we have a target for 4.11?  I probably will not get any
>> serious development time for another week or so.
>>
>
> We are working towards 4.11. The tools and newlib are stable with some
> outstanding patches being released soon. The web site has migrated and we
> have a 4.11 milestone set up in Trac and tickets assigned. If you click on
> the Roadmap link in Trac you will see the status. There has been progress
> made in moving the documentation to the ReST format from texinfo. We hope
> these changes will break the back of us making releases and we can get back
> to making them more often.
>
> Chris
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] Add GPIO, I2C and SPI support for the RPi BSP

[Alan Cudmore]

Sebastian,
Makes sense. I think I understand the idea a little better now, we are
using the linux uapi i2c API, but not the actual i2c bus and device driver
implementations from linux, right?

For the Pi ( and others like the Beagleboard ) we need to come up with an
i2c BSP bus driver ( similar to cadence-i2c.c/h ) then a set of i2c device
drivers to go in cpukit/dev/i2c.

Do the individual device drivers, such as cpukit/dev/i2c/gpi-nxp-pca9535.c,
resemble the equivalent linux driver?

Thanks,
Alan


On Tue, Dec 23, 2014 at 1:01 AM, Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

>
> On 22/12/14 22:17, Alan Cudmore wrote:
>
>>
>> Why was the Linux API chosen over FreeBSD? Wouldn't we want to keep going
>> down the *BSD path to provide drivers and libraries?
>>
>
> We also looked at the FreeBSD, OpenBSD and NetBSD I2C stuff, but the Linux
> I2C API appeared to be the best and most widely used.
>
>
> --
> Sebastian Huber, embedded brains GmbH
>
> Address : Dornierstr. 4, D-82178 Puchheim, Germany
> Phone   : +49 89 189 47 41-16
> Fax : +49 89 189 47 41-09
> E-Mail  : sebastian.hu...@embedded-brains.de
> PGP : Public key available on request.
>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: BSP requests.

[Alan Cudmore]

Thanks for getting the BSPs in.

I wanted to try to compare the old and new build systems on the raspberry
Pi 2, but I'm still working on getting the tools to build. Chris may have a
clue about this:
The compiler build finishes ( much faster than the RPI 1 ) but the rtems
tools build fails. This can be reproduced with just the rtems tools repo
without trying a complete RSB toolchain build.
I suspect that something is not getting defined for the ARM host in the
configure step:
pi@raspberrypi ~/rtems-tools.git $ ./waf build
Waf: Entering directory `/home/pi/rtems-tools.git/build'
[  1/142] libelf_convert.c:
rtemstoolkit/elftoolchain/libelf/libelf_convert.m4 ->
build/rtemstoolkit/libelf_convert.c
[  3/142] libelf_fsize.c: rtemstoolkit/elftoolchain/libelf/libelf_fsize.m4
-> build/rtemstoolkit/libelf_fsize.c
[  3/142] libelf_msize.c: rtemstoolkit/elftoolchain/libelf/libelf_msize.m4
-> build/rtemstoolkit/libelf_msize.c
[  4/142] native-elf-format:
rtemstoolkit/elftoolchain/common/native-elf-format ->
build/rtemstoolkit/elftoolchain/common/native-elf-format.h
[  5/142] c: rtemstoolkit/elftoolchain/libelf/elf.c ->
build/rtemstoolkit/elftoolchain/libelf/elf.c.5.o
[  6/142] c: rtemstoolkit/elftoolchain/libelf/elf_begin.c ->
build/rtemstoolkit/elftoolchain/libelf/elf_begin.c.5.o
[  7/142] c: rtemstoolkit/elftoolchain/libelf/elf_cntl.c ->
build/rtemstoolkit/elftoolchain/libelf/elf_cntl.c.5.o
[  8/142] c: rtemstoolkit/elftoolchain/libelf/elf_end.c ->
build/rtemstoolkit/elftoolchain/libelf/elf_end.c.5.o
../rtemstoolkit/elftoolchain/libelf/elf.c:34:18: error: ‘unknown’
undeclared here (not in a function)
Waf: Leaving directory `/home/pi/rtems-tools.git/build'
Build failed
 -> task in 'elf' failed (exit status 1):
 {task 38575952: c elf.c -> elf.c.5.o}
['/usr/bin/gcc', '-pipe', '-g', '-O2', '-I/home/pi/rtems-tools.git/build',
'-I/home/pi/rtems-tools.git/build/rtemstoolkit/elftoolchain/libelf', '-
I/home/pi/rtems-tools.git/rtemstoolkit/elftoolchain/libelf',
'-I/home/pi/rtems-tools.git/build/rtemstoolkit/elftoolchain/common',
'-I/home/pi/rtem
s-tools.git/rtemstoolkit/elftoolchain/common',
'-DPYTHONDIR="/media/Projects/rtems/4.11/lib/python2.7/site-packages"',
'-DPYTHONARCHDIR="/media/Pr
ojects/rtems/4.11/lib/python2.7/site-packages"',
'../rtemstoolkit/elftoolchain/libelf/elf.c', '-c', '-o',
'rtemstoolkit/elftoolchain/libelf/elf.c.
5.o']
pi@raspberrypi ~/rtems-tools.git $

Thanks,
Alan

On Mon, Feb 9, 2015 at 8:58 PM, Amar Takhar  wrote:

> On 2015-02-09 17:32 +, Cudmore, Alan P. (GSFC-5820) wrote:
> >
> > I would like to request Raspberry Pi, LEON3, and m68k/mcf5235.
>
> m68k/mcf5235 is now working.
>
> I will work on rpi after I get the Beagle BSPs working.
>
>
> Amar.
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: BSP requests.

[Alan Cudmore]

Chris,
It looks like _libelf_config.h has the defines for an ARM host on FreeBSD,
but for linux it includes "native-elf-format.h". It looks like this file is
produced with the native-elf-format binary, which produces this output:
pi@raspberrypi ~/rtems-tools.git/rtemstoolkit/elftoolchain/common $
./native-elf-format
/* Generated by native-elf-format on Tue Feb 10 03:33:38 UTC 2015 */
#define ELFTC_CLASS ELFCLASS32
#define ELFTC_ARCH unknown
#define ELFTC_BYTEORDER ELFDATA2LSB
pi@raspberrypi ~/rtems-tools.git/rtemstoolkit/elftoolchain/common $


So the #define ELFTC_ARCH unknown statement causes the compile error.

I can dig into this later, it's not a big deal, I just want to make my RPI
2 serve as a development host for my RPI 1 :)

As for the Linux on RPI 2, I think they are using the same Raspbian distro,
so this probably happens on the RPI 1 as well.

Thanks,
Alan


On Mon, Feb 9, 2015 at 10:24 PM, Chris Johns  wrote:

> On 10/02/2015 2:16 pm, Alan Cudmore wrote:
>
>> Thanks for getting the BSPs in.
>>
>> I wanted to try to compare the old and new build systems on the
>> raspberry Pi 2, but I'm still working on getting the tools to build.
>> Chris may have a clue about this:
>> The compiler build finishes ( much faster than the RPI 1 ) but the rtems
>> tools build fails. This can be reproduced with just the rtems tools repo
>> without trying a complete RSB toolchain build.
>> I suspect that something is not getting defined for the ARM host in the
>> configure step:
>> pi@raspberrypi ~/rtems-tools.git $ ./waf build
>> Waf: Entering directory `/home/pi/rtems-tools.git/build'
>> [  1/142] libelf_convert.c:
>> rtemstoolkit/elftoolchain/libelf/libelf_convert.m4 ->
>> build/rtemstoolkit/libelf_convert.c
>> [  3/142] libelf_fsize.c:
>> rtemstoolkit/elftoolchain/libelf/libelf_fsize.m4 ->
>> build/rtemstoolkit/libelf_fsize.c
>> [  3/142] libelf_msize.c:
>> rtemstoolkit/elftoolchain/libelf/libelf_msize.m4 ->
>> build/rtemstoolkit/libelf_msize.c
>> [  4/142] native-elf-format:
>> rtemstoolkit/elftoolchain/common/native-elf-format ->
>> build/rtemstoolkit/elftoolchain/common/native-elf-format.h
>> [  5/142] c: rtemstoolkit/elftoolchain/libelf/elf.c ->
>> build/rtemstoolkit/elftoolchain/libelf/elf.c.5.o
>> [  6/142] c: rtemstoolkit/elftoolchain/libelf/elf_begin.c ->
>> build/rtemstoolkit/elftoolchain/libelf/elf_begin.c.5.o
>> [  7/142] c: rtemstoolkit/elftoolchain/libelf/elf_cntl.c ->
>> build/rtemstoolkit/elftoolchain/libelf/elf_cntl.c.5.o
>> [  8/142] c: rtemstoolkit/elftoolchain/libelf/elf_end.c ->
>> build/rtemstoolkit/elftoolchain/libelf/elf_end.c.5.o
>> ../rtemstoolkit/elftoolchain/libelf/elf.c:34:18: error: ‘unknown’
>> undeclared here (not in a function)
>>
>
> This looks to me like the elftoolchain we have does not know how to handle
> the ARM you are on. Have a look at _libelf_config.h.
>
> Are you able to have a look at this for me ?
>
> I do not have a Rpi2 yet.
>
> Thanks
> Chris
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: BSP requests.

[Alan Cudmore]

Raspberry Pi times on my PC ( 6 core AMD, 8GB RAM, SSD , Ubuntu 14.04 ) :

Standard build system:
   Bootstrap : 7m4s
   Configure step: 8s
   Build: 3m15s

   Size of RTEMS Tree after bootstrap: 308Mbytes

Waf build:
   configure: ~4s
   build with tests: 29s

   Size of RTEMS tree : 188Mbytes

Nice improvement! ( although I did not run the standard build with the -j
14 flags, would that speed up the bootstrap? )

Will this waf system work on windows hosts?

Thanks,
Alan


On Tue, Feb 10, 2015 at 12:12 AM, Amar Takhar  wrote:

> On 2015-02-09 17:32 +, Cudmore, Alan P. (GSFC-5820) wrote:
> > I would like to request Raspberry Pi, LEON3, and m68k/mcf5235.
>
> arm/raspberrypi has been added.
>
> From scratch it took me exactly 4m10s to add this including the time to
> build
> RTEMS + all tests:
>
>
> http://git.rtems.org/amar/waf.git/commit/?id=a238716ffddeb74410f6795547129beecc7cfde7
>
>
> Amar.
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: RTEMS for ARM Cortex-M1 ?

[Alan Cudmore]

Thanks for the info.. so it sounds like a new BSP and some changes to the
ARMV7-M code in score.

The project will also look at some other fpga based cpus. I'm glad to see
the openrisc and microblaze work going on.
Alan
On Feb 14, 2015 8:29 AM, "Sebastian Huber" <
sebastian.hu...@embedded-brains.de> wrote:

> On 14/02/15 14:27, Sebastian Huber wrote:
>
>> On 14/02/15 12:48, Daniel Gutson wrote:
>>
>>> We're developing support for the
>>> cortex M 4 so we can let you know once we commit the patches so you can
>>> have a starting point in case an emulator is also needed.
>>>
>>
>> The Cortex-M4 is already supported including the FPU (e.g. LPC4088).
>>
>>
> Hm, I should read more carefully.  You added a Cortex-M4 support for Qemu
> including the FPU?
>
> --
> Sebastian Huber, embedded brains GmbH
>
> Address : Dornierstr. 4, D-82178 Puchheim, Germany
> Phone   : +49 89 189 47 41-16
> Fax : +49 89 189 47 41-09
> E-Mail  : sebastian.hu...@embedded-brains.de
> PGP : Public key available on request.
>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSOC2015 idea Raspberry Pi BSP

[Alan Cudmore]

The list below is still pretty good.
Items 1 - 3 were done by Andre last summer, but we still don't have them 
in the git repository. The RTEMS I2C API has changed and we were going 
to try to move the I2C implementation to the new Linux based API.


I still think that having complete Raspberry Pi support would be great 
for RTEMS, and RTOS education in general.  The Pi has worldwide 
availability, and is probably the least expensive target board that can 
run RTEMS.
Having a non-simulated RTEMS board that has network, file system, and 
now even SMP support for $35 USD would be amazing.


Now the new Pi2 with a Quad Core ARM7 and the HAT add on board standard, 
the Pi is even better for real applications such as this Navigation board:

http://www.emlid.com/


Alan

On 3/5/2015 9:28 AM, Gedare Bloom wrote:

Hello Yang Qiao,

There is the future work listed in that page, and there are some other
project ideas for raspberry pi. There also could be the opportunity to
support the raspberry pi 2.

The original list of open Raspberry Pi projects were:
Peripherals we need to support (in order of increasing difficulty):
1. GPIO (This has been done by one user, but is not integrated)
2. I2C Bus
3. SPI Bus
4. Secure Digital card read and write support (using the SPI bus)
5. Graphics / RTEMS Framebuffer Support (I have a graphics demo
working in an RTEMS task)
6. USB Device support
7. HDMI/Graphics console (Requires framebuffer support and USB or GPIO
connected keyboard device)
8. Ethernet network support (Requires USB support)

Finally, in order to do some of this coding, it may be necessary to
come up with a more efficient way to load and debug code on the
Raspberry Pi. Options include using U-boot or connecting a JTAG debug
device to load code.

I don't know the status of all of the above, but I think there is
still a lot to do in #5-8.

Gedare

On Thu, Mar 5, 2015 at 4:28 AM, QIAO YANG  wrote:

Hello ,

I' a 3rd year chinese student studying software engineering (real-time
system and embedded system) in France.  I've found the GSOC2015 idea
'Raspberry Pi BSP ' very attractive and I would like to know more about it
to prepare my proposal.

Since the wiki page hasn't a concrete introduction yet, I would like to know
a bit more about it in order to make my first step to try out the existing
codes and prepare the proposal.

After having read the wiki of the same project in GSOC2013,  I guess the BSP
is a library which contains the apis of communication protocols to
manipulate the peripherals. So maybe our goal is completing the "futur
works" described on GSOC 2013's wiki
https://devel.rtems.org/wiki/GSoC/2013/Raspberry_Pi_BSP_Peripherals,
that :  add support to different model of RPI  etc... or something else?

Any references or instructions would be greatly helpful.

Looking forward to hearing from you soon :)

Best regards

---
YANG Qiao

Université de Tchnologie de Compiègne

Génie Informatique


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


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

Re: GSOC2015 idea Raspberry Pi BSP

[Alan Cudmore]

On 3/5/2015 11:46 AM, Joel Sherrill wrote:


On 3/5/2015 10:40 AM, Alan Cudmore wrote:

The list below is still pretty good.
Items 1 - 3 were done by Andre last summer, but we still don't have them
in the git repository. The RTEMS I2C API has changed and we were going
to try to move the I2C implementation to the new Linux based API.

So the API needs to change on I2C. What else remains to do to merge Andre's
work? Is this the first step of a 2015 project?

I am guessing that USB and then the NIC are high on the list. Does FreeBSD
support the Pi? That would make it easier. This assumes the new TCP/IP
stack.
FreeBSD does support the Pi. I was thinking that the FreeBSD USB and 
network stack may be the way to accomplish this.




FWIW we need to make sure Andre's final write up is linked to from GSOC 2014
and the next Pi activities get their own project page for 2015.

I still think that having complete Raspberry Pi support would be great
for RTEMS, and RTOS education in general.  The Pi has worldwide
availability, and is probably the least expensive target board that can
run RTEMS.
Having a non-simulated RTEMS board that has network, file system, and
now even SMP support for $35 USD would be amazing.

+1

I haven't looked much. Does it have JTAG support even via soldering?
It is possible to get JTAG support through the GPIO pins. I started down 
this path, but did not have the time to complete it.



Now the new Pi2 with a Quad Core ARM7 and the HAT add on board standard,
the Pi is even better for real applications such as this Navigation board:
http://www.emlid.com/


Is the SoC documentation available?


I don't think the SoC documentation is available yet. From what I 
understand, some people are getting bare metal code running on the Pi2 
by changing the base address of the peripheral registers.
It may be as simple as the new peripheral register address and 
optimization flags for the ARM7.




Would it be better to complete the Pi or start a Pi v2 BSP? The last I
knew the
Pi V2 SoC documentation wasn't public yet so it isn't an option yet.

On general principle, I like the idea of finishing the Pi V1 BSP. If info is
available and we can support it, a project to complete V1 and start V2
BSP is a good one.


I think finishing the Pi 1 BSP is a good idea as well. They will 
continue to sell the Pi 1 ( Model B+ and A+ ) as long as there is 
demand. But hopefully, the Pi2 will just be a BSP configuration variant.


Alan


Alan

On 3/5/2015 9:28 AM, Gedare Bloom wrote:

Hello Yang Qiao,

There is the future work listed in that page, and there are some other
project ideas for raspberry pi. There also could be the opportunity to
support the raspberry pi 2.

The original list of open Raspberry Pi projects were:
Peripherals we need to support (in order of increasing difficulty):
1. GPIO (This has been done by one user, but is not integrated)
2. I2C Bus
3. SPI Bus
4. Secure Digital card read and write support (using the SPI bus)
5. Graphics / RTEMS Framebuffer Support (I have a graphics demo
working in an RTEMS task)
6. USB Device support
7. HDMI/Graphics console (Requires framebuffer support and USB or GPIO
connected keyboard device)
8. Ethernet network support (Requires USB support)

Finally, in order to do some of this coding, it may be necessary to
come up with a more efficient way to load and debug code on the
Raspberry Pi. Options include using U-boot or connecting a JTAG debug
device to load code.

I don't know the status of all of the above, but I think there is
still a lot to do in #5-8.

Gedare

On Thu, Mar 5, 2015 at 4:28 AM, QIAO YANG  wrote:

Hello ,

I' a 3rd year chinese student studying software engineering (real-time
system and embedded system) in France.  I've found the GSOC2015 idea
'Raspberry Pi BSP ' very attractive and I would like to know more about it
to prepare my proposal.

Since the wiki page hasn't a concrete introduction yet, I would like to know
a bit more about it in order to make my first step to try out the existing
codes and prepare the proposal.

After having read the wiki of the same project in GSOC2013,  I guess the BSP
is a library which contains the apis of communication protocols to
manipulate the peripherals. So maybe our goal is completing the "futur
works" described on GSOC 2013's wiki
https://devel.rtems.org/wiki/GSoC/2013/Raspberry_Pi_BSP_Peripherals,
that :  add support to different model of RPI  etc... or something else?

Any references or instructions would be greatly helpful.

Looking forward to hearing from you soon :)

Best regards

---
YANG Qiao

Université de Tchnologie de Compiègne

Génie Informatique


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

___