Re: ARM cp15 c1 control on the BBB at _start
On 6/3/18 6:40 pm, Sebastian Huber wrote: > On 05/03/18 23:12, Chris Johns wrote: >> Note, the Zynq does not clear the A flag in it's specific MMU set up call so >> does it assume the boot loader will clear it? >> >> Why not clear the A flag and remove any restrictions and try and make the >> BSPs >> consistent? > > A set SCTLR[A] bit after initialization (in thread/interrupt context) is a > bug. > The bit is left set by u-boot, well it is set while SPL is running. How do you define initialization? I am asking why not clear it as soon as possible after _start? Chris ps, SCTLR[A] is used in the Cortex-A9 docs and not in the Cortex-A8 :) ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] CONFIGURE_*_SIMPLE_TASK_CONSOLE_DRIVER
On 6/3/18 6:38 pm, Sebastian Huber wrote: > On 06/03/18 08:15, Chris Johns wrote: >> Should the documentation make mention of why would you select one of these >> console drivers? > > We could move the console driver options into an extra section, OK. > but I am quite > busy at the moment, so I would leave this currently as is. Sure. Could you please update the ticket to note this is something worth doing? Thanks Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: potential deadlock in _once
On 04/03/18 22:09, Passas, Stavros wrote: Hi, We have faced RTEMS threads getting locked up when using certain c++ functionality. Issue happens for example when std::future is combined with std::async. Investigating deeper, seems like this happens if std::async executes before std::future gets scheduled to run. Both of these create a pthread_once instance. _once uses a common semaphore for all calls, thus the first function (async.get usually) gets the lock, calls its “init” function (which blocks until the second function has completed, while std::future also uses pthread_once to create a new thread, but because the lock is already taken, it blocks, casing a deadlock between these two functions. Is this a known issue? No. If not, should I create a ticket about it? Yes, please open a ticket and provide a test case for the RTEMS test suite. Maybe we have to use dedicated mutexes for each pthread_once_t object. This is what Linux and FreeBSD do. This would require a Newlib update. -- 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: potential deadlock in _once
-Original Message- From: Sebastian Huber [mailto:sebastian.hu...@embedded-brains.de] Sent: Tuesday, March 6, 2018 10:19 AM To: Passas, Stavros ; rtems-de...@rtems.org Subject: Re: potential deadlock in _once > Yes, please open a ticket and provide a test case for the RTEMS test suite. > Maybe we have to use dedicated mutexes for each pthread_once_t object. This > is what Linux and FreeBSD do. This would require a Newlib update. Using one dedicated mutex for each pthread_once_t instance would be a longer term and elegant solution. On the other hand, I think we can get away with a much simpler change: The _once implementation uses a single mutex. Currently this mutex protects the whole function, while I believe we protect reads/writes to the once_state variable only. Concurrent tasks finding the state on RUNNING, could just yield until the state becomes ONCE_STATE_COMPLETE. One side problem I noticed is that the _once() returns EINVAL, if a thread finds the state in ONCE_STATE_RUNNING. This is not documented in RTEMS, neither in POSIX. The specs define: "The init_routine is guaranteed to have run to completion when this routine returns to the caller". Best Regards, Stavros -- Intel Research and Development Ireland Limited Registered in Ireland Registered Office: Collinstown Industrial Park, Leixlip, County Kildare Registered Number: 308263 This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] CONFIGURE_*_SIMPLE_TASK_CONSOLE_DRIVER
On 06/03/18 09:24, Chris Johns wrote: On 6/3/18 6:38 pm, Sebastian Huber wrote: On 06/03/18 08:15, Chris Johns wrote: Should the documentation make mention of why would you select one of these console drivers? We could move the console driver options into an extra section, OK. but I am quite busy at the moment, so I would leave this currently as is. Sure. Could you please update the ticket to note this is something worth doing? https://devel.rtems.org/ticket/3321 -- 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: potential deadlock in _once
On 06/03/18 12:12, Passas, Stavros wrote: -Original Message- From: Sebastian Huber [mailto:sebastian.hu...@embedded-brains.de] Sent: Tuesday, March 6, 2018 10:19 AM To: Passas, Stavros;rtems-de...@rtems.org Subject: Re: potential deadlock in _once Yes, please open a ticket and provide a test case for the RTEMS test suite. Maybe we have to use dedicated mutexes for each pthread_once_t object. This is what Linux and FreeBSD do. This would require a Newlib update. Using one dedicated mutex for each pthread_once_t instance would be a longer term and elegant solution. On the other hand, I think we can get away with a much simpler change: The _once implementation uses a single mutex. Currently this mutex protects the whole function, while I believe we protect reads/writes to the once_state variable only. Concurrent tasks finding the state on RUNNING, could just yield until the state becomes ONCE_STATE_COMPLETE. Ok, maybe we could use a condition variable for this. It might be preferable in terms of storage space. The pthread_once_t is currently only one byte. A mutex would increase this to 28 bytes or so. One side problem I noticed is that the _once() returns EINVAL, if a thread finds the state in ONCE_STATE_RUNNING. This is not documented in RTEMS, neither in POSIX. The specs define: "The init_routine is guaranteed to have run to completion when this routine returns to the caller". If this is important for you then I suggest to add tickets and implement and test it. -- 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: getentropy() implementation on BBB
Hi,
Here's the updated code(I have also attached the patch PFA):
>From 96e6e1bfd8cffeef5d309eb0a07fe2bfd086ef0a Mon Sep 17 00:00:00 2001
From: Udit agarwal
Date: Tue, 6 Mar 2018 20:07:44 +0530
Subject: [PATCH] Added getentropy support to BBB BSP
---
bsps/arm/beagle/headers.am | 1 +
bsps/arm/beagle/include/bsp/bbb_getentropy.h | 57 +++
bsps/arm/include/libcpu/am335x.h | 16 +
c/src/lib/libbsp/arm/beagle/Makefile.am| 4 ++
.../libbsp/arm/beagle/getentropy/bbb_getentropy.c | 80
++
5 files changed, 158 insertions(+)
create mode 100644 bsps/arm/beagle/include/bsp/bbb_getentropy.h
create mode 100644 c/src/lib/libbsp/arm/beagle/getentropy/bbb_getentropy.c
diff --git a/bsps/arm/beagle/headers.am b/bsps/arm/beagle/headers.am
index 6692d0b..ac4ff7c 100644
--- a/bsps/arm/beagle/headers.am
+++ b/bsps/arm/beagle/headers.am
@@ -12,3 +12,4 @@ include_bsp_HEADERS +=
../../../../../../bsps/arm/beagle/include/bsp/bbb-pwm.h
include_bsp_HEADERS +=
../../../../../../bsps/arm/beagle/include/bsp/beagleboneblack.h
include_bsp_HEADERS += ../../../../../../bsps/arm/beagle/include/bsp/i2c.h
include_bsp_HEADERS += ../../../../../../bsps/arm/beagle/include/bsp/irq.h
+include_bsp_HEADERS +=
../../../../../../bsps/arm/beagle/include/bsp/bbb_getentropy.h
diff --git a/bsps/arm/beagle/include/bsp/bbb_getentropy.h
b/bsps/arm/beagle/include/bsp/bbb_getentropy.h
new file mode 100644
index 000..5e46f89
--- /dev/null
+++ b/bsps/arm/beagle/include/bsp/bbb_getentropy.h
@@ -0,0 +1,57 @@
+/**
+ * @file
+ *
+ * @ingroup arm_beagle
+ *
+ * @brief TRNG Definations
+ */
+
+/*
+ * Copyright (c) 2018 Udit kumar agarwal
+ *
+ * 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 _TRNG_
+#define _TRNG_
+
+/*--
+ * Headers
+
**/
+
+#include
+
+
/*--
+ * Register structure
+
**/
+
+struct rng {
+uint64_t output; /*00*/
+uint32_t status; /*08*/
+uint32_t irq_en; /*0c*/
+uint32_t status_clr; /*10*/
+uint32_t control; /*14*/
+uint32_t config; /*18*/
+};
+
+typedef volatile struct rng *rng_ref_t;
+
+/**/
+/* Exported
functions */
+/**/
+
+/* configure and enable RNG module */
+static void am335x_rng_enable(rng_ref_t);
+/* enable module clock for random number generator */
+static void am335x_rng_clock_enable(void);
+/* outputs random data */
+static uint64_t trng_getranddata(rng_ref_t);
+/* Copy random data of a specified size to the pointer supplied */
+int getentropy(void *ptr, size_t);
+
+
+
+#endif /* #ifndef _TRNG_ */
\ No newline at end of file
diff --git a/bsps/arm/include/libcpu/am335x.h
b/bsps/arm/include/libcpu/am335x.h
index 367e97c..8b58f1a 100644
--- a/bsps/arm/include/libcpu/am335x.h
+++ b/bsps/arm/include/libcpu/am335x.h
@@ -14,6 +14,9 @@
* Modified by Ben Gras to add lots
* of beagleboard/beaglebone definitions, delete lpc32xx specific
* ones, and merge with some other header files.
+ *
+ * Modified by Udit agarwal to add random
+ * number generating module definations
*/
#if !defined(_AM335X_H_)
@@ -701,4 +704,17 @@
#define AM335X_CM_PER_OCPWP_L3_CLKSTCTRL_CLKACTIVITY_OCPWP_L4_GCLK
(0x0020u)
#define AM335X_I2C_INT_STOP_CONDITION AM335X_I2C_IRQSTATUS_BF
+/* TRNG Register */
+
+/* RNG base address */
+#define RNG_BASE0x4831
+/* RNG clock control */
+#define CM_PER_RNG_CLKCTRLAM335X_CM_PER_ADDR | 9<<4
+/* Offset from RNG base for output ready flag */
+#define RNG_STATUS_RDY(1u << 0)
+/* Offset from RNG base for FRO related error*/
+#define RNG_STATUS_ERR(1u << 1)
+/* Offset from RNG base for clock status */
+#define RNG_STATUS_CLK(1u << 31)
+
#endif
diff --git a/c/src/lib/libbsp/arm/beagle/Makefile.am
b/c/src/lib/libbsp/arm/beagle/Makefile.am
index 8251660..bf92081 100644
--- a/c/src/lib/libbsp/arm/beagle/Makefile.am
+++ b/c/src/lib/libbsp/arm/beagle/Makefile.am
@@ -88,9 +88,13 @@ libbsp_a_SOURCES += gpio/bbb-gpio.c
#pwm
libbsp_a_SOURCES += pwm/pwm.c
+#getentropy
+libbsp_a_SOURCES += getentropy/bbb_getentropy.c
+
#RTC
libbsp_a_SOURCES += rtc.c
libbsp_a_SOURCES += ../../shared/tod.c
+
# Clock
libbsp_a_SOURCES += clock.c
libbsp_a_SOURCES += ../../shared/clockdrv_shell.h
diff --git a/c/src/lib/libbsp/arm/beagle/getentropy/bbb_getentropy.c
b/c/src/lib/libbsp/arm/beagle/getentropy/bbb_getentropy.c
new file mode 100644
inde
Re: MMU was Re: Contribute to a project under GSOC 2018
On Sun, Mar 4, 2018 at 1:50 AM, Abhinav Jain wrote: > Sir, > > Thanks for your time and consideration. I was discussing this project with > Gedare Sir and he guided me, how to proceed. > I am studying various things before proceeding with the code part but for > now, I request you to please guide me what should be my next steps to work > on this project under GSOC'18. > > Thanks and Regards > Abhinav Jain > > On Sun, Mar 4, 2018 at 10:48 AM, Hesham Almatary > wrote: >> >> On Sun, Mar 4, 2018 at 10:20 AM, Joel Sherrill wrote: >> > >> > >> > On Mar 3, 2018 12:16 PM, "Abhinav Jain" wrote: >> > >> > Sir/Madam, >> > >> > I am Abhinav Jain, a second-year engineering student from Delhi, India. >> > I >> > have been working in Linux Kernel Development, I have been writing small >> > drivers and have a good knowledge of the operating system. >> > I have been studying about Memory Protection project(ticket #2904) for >> > around a month and found it really interesting. I studied about POSIX, >> > MMU >> > support in various other architecture and the memory protection APIs in >> > various operating systems.I have been discussing the same on the mailing >> > list. >> > I also solved an issue (#2522) around a week ago to gain some hands-on >> > code. >> > -ENOPATCH >> > >> > Welcome aboard. >> > >> > >> > I would like to work on the Memory Protection project under GSOC 2018, >> > so I >> > request you to please guide me regarding the steps to be followed. >> > >> > >> > Gedare conceived of what's there be so I cc'ed him. My recollection is >> > that >> > there were specific things he wanted to change and when that was >> > addressed, >> > providing support for arenas on multiple architecture is desirable >> > >> +1 >> >> There might be an opportunity to port RTEMS to RISC-V's Supervisor >> Mode which will need MMU support (currently it only runs on M-Mode >> which doesn't have MMU). Both QEMU and Spike simulators support >> S-Mode. >> Start to develop a draft proposal if you have not yet, starting with our template. A successful proposal must contain a sound design and good plan, which you will need a lot of time and feedback to develop. Don't read too much about 64-bit processor architectures and their needs, since we have limited support there. The first issue to resolve is what kind of BSP-level interface should we provide over MMU/MPU hardware, and then what can we do to use that BSP layer to provide upper-layer services such as managed memory regions, better mmap() support, "arena" allocators, etc. There are three views here: 1. no mmu/mpu is available or it is not desired by end users. 2. mmu/mpu are available, but should only be manipulated statically/boot-time. 3. mmu/mpu are available, and can be changed dynamically. Managing #3 is the hardest, but accommodating 1 and 2 in any system design is important. Another important concern is mmu/mpu with limited numbers of entries. Right now, we exist mainly in #1, and #2 is only used to setup a linear 1:1 memory map with all permissions enabled when the MMU/MPU can't be turned off. A few projects exist here and there to also restrict permissions to thread stacks with a hook in the context switch to change the mpu/mmu state. Since RTEMS has no multi-process model, the existing solutions in general-purpose commodity OS do not apply, but you should still be familiar with how they work for sure. It would also be good for you to review the solutions in the commodity RTOS domain, e.g. what does vxworks, safertos, threadx, etc., provides in this field. Some relevant citations to get more relevant background: https://highintegritysystems.com/downloads/white_papers/Using_an_MPU_to_Enforce_Spatial_Separation.pdf https://pdfs.semanticscholar.org/3c92/7ed6b426fccfb203dd96be9b7591b3744f1f.pdf https://www.researchgate.net/publication/221033285_A_New_Approach_to_Memory_Partitioning_in_On-Board_Spacecraft_Software >> > >> > >> > Thanks and Regards >> > Abhinav Jain >> > >> > ___ >> > 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 >> >> >> >> -- >> Hesham > > ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: patch regarding 'RTEMS not booting with Qemu PREP larger than 256Mb'
On Mon, Mar 5, 2018 at 5:37 PM, Joel Sherrill wrote:
> Can you file a ticket with the patch attached? We don't change things on a
> release
> branch without a ticket? devel.rtems.org
>
+1
> Are you able to test this on real hardware? It touches files in shared which
> will
> be used by multiple powerpc BSPs so it would be good to have feedback on
> real HW.
>
+2
This should be verified on hw before applying especially to a release.
If it affects hw, also change the comments to just say "greater than
256 MiB" without specifying qemu -m option.
> FWIW we are trying to wrap up a set of patches for a 4.11 release and it
> would
> be good to have this in the ticket queue for consideration.
>
> Thanks.
>
> --joel
>
>
> On Mon, Mar 5, 2018 at 2:31 PM, Éric Tremblay
> wrote:
>>
>> Hi,
>> I posted a question last week about a strange behavior I was getting using
>> RTEMS with qemu-system-ppc. Anytime I was specifying more than 256Mb of
>> memory using the -m option the RTEMS kernel was not booting. Here is an
>> example of command line I was using:
>>
>> qemu-system-ppc -M prep -kernel ./hello.ralf -bios
>> /home/qemu_fakerom/qemu_fakerom.bin -cpu 750cxe -nographic -no-reboot -m 384
>>
>> Model:
>> Serial:
>> Processor/Bus frequencies (Hz): 3/1
>> Time Base Divisor: 1000
>> Memory Size: 1800
>> Residual: 102afd4 (length 27148)
>>
>> PCI: Probing PCI hardware
>>
>> RTEMS 4.x/PPC load:
>> Uncompressing the kernel...
>> Kernel at 0x, size=0x495b0
>> Initrd at 0x, size=0x0
>> Residual data at 0x0004a000
>> Command line at 0x00051000
>> done
>> Now booting... execution
>> stuck here
>>
>>
>> I have spent quite some time debugging this issue and I traced it back to
>> two issues for which I am submitting a patch. Please understand this is my
>> first time using RTEMS and debugging a bootloader so my patch might not be
>> accurate but it does fix the behavior I mentioned above. With this patch I
>> can successfully launch a "Hello World" and specify more memory (-m 512 for
>> example).
>>
>> My patch is quite simple since it simply allows the system to access
>> section of memory. Please let me know if this is a suitable correction, if
>> this is totally wrong I would like to know how this could be fixed since our
>> application will use around 512Mb of memory and the current state of things
>> won't work.
>>
>> Thank you for your cooperation,
>> Eric
>>
>> PS: I am using RTEMS release 4.11.3.
>>I am using Qemu v 2.5.0
>>I am running in a Linux Ubuntu VM (intel 64 bits)
>>
>>
>>
>>
>> c/src/lib/libbsp/powerpc/shared/start/start.S | 18
>> ++
>> c/src/lib/libbsp/powerpc/shared/startup/bspstart.c | 18
>> ++
>> 2 files changed, 36 insertions(+)
>>
>> diff --git a/c/src/lib/libbsp/powerpc/shared/start/start.S
>> b/c/src/lib/libbsp/powerpc/shared/start/start.S
>> index 729c89c40b..532c1f9ee4 100644
>> --- a/c/src/lib/libbsp/powerpc/shared/start/start.S
>> +++ b/c/src/lib/libbsp/powerpc/shared/start/start.S
>> @@ -93,6 +93,24 @@ __rtems_entry_point:
>> mtspr IBAT0L,r8
>> mtspr IBAT0U,r11
>> isync
>> +/* Map section where residual is located if outside
>> + * the first 256Mb of RAM. This is to support cases
>> + * where the user supplies the -m option with Qemu
>> + * in order to have more memory available to the system.
>> + */
>> + mr r9, r1/* Get where residual was mapped */
>> + lis r12,0xf000@h
>> + and r9,r9,r12
>> + cmpi 0,1,r9, 0
>> + beq skip_BAT1_config
>> + isync
>> + ori r11,r9,0x1ffe
>> + mtspr DBAT1L,r8 /* N.B. 6xx (not 601) have valid */
>> + mtspr DBAT1U,r11 /* bit in upper BAT register */
>> + mtspr IBAT1L,r8
>> + mtspr IBAT1U,r11
>> + isync
>> +skip_BAT1_config:
>>
>> /*
>> * we now have the 1st 256M of ram mapped with the bats. We are still
>> diff --git a/c/src/lib/libbsp/powerpc/shared/startup/bspstart.c
>> b/c/src/lib/libbsp/powerpc/shared/startup/bspstart.c
>> index 5a97cc8531..f80835b117 100644
>> --- a/c/src/lib/libbsp/powerpc/shared/startup/bspstart.c
>> +++ b/c/src/lib/libbsp/powerpc/shared/startup/bspstart.c
>> @@ -300,6 +300,24 @@ void bsp_start( void )
>> */
>>_BSP_clear_hostbridge_errors(0 /* enableMCP */, 0/*quiet*/);
>>
>> + if (BSP_mem_size > 0x1000)
>> + {
>> + /* Support cases with qemu supplied -m option and mem size larger than
>> 256Mb.
>> +*
>> +* We use BAT3 in order to obtain access to the top section of the
>> RAM.
>> +* We also need to do this just before setting up the page table
>> because
>> +* this is where the page table will be located.
>> +*/
>> + const unsigned int mem256Count = (BSP_mem_size / 0x1000);
>> + const unsigned int BAT3Addr= ((BSP_mem_size % 0x1000)?
>> + (mem256Count * 0x1000) :
>> + ((mem256Count-1) * 0x1000));
>> + setdbat(3, BAT3Addr, BAT3Addr, 0x1000, IO_PAGE);
>> +#ifdef SHOW_MORE_INIT_SETTINGS
>> + pr
Re: patch regarding 'RTEMS not booting with Qemu PREP larger than 256Mb'
Hi Gedare, Joel,
Unfortunately I do not have access to hw so I cannot test in this
environment.
Do you want me to create the ticket or one of you will take care of it?
Thanks,
Eric
On Tue, Mar 6, 2018 at 12:02 PM, Gedare Bloom wrote:
> On Mon, Mar 5, 2018 at 5:37 PM, Joel Sherrill wrote:
> > Can you file a ticket with the patch attached? We don't change things on
> a
> > release
> > branch without a ticket? devel.rtems.org
> >
> +1
>
> > Are you able to test this on real hardware? It touches files in shared
> which
> > will
> > be used by multiple powerpc BSPs so it would be good to have feedback on
> > real HW.
> >
> +2
>
> This should be verified on hw before applying especially to a release.
>
> If it affects hw, also change the comments to just say "greater than
> 256 MiB" without specifying qemu -m option.
>
> > FWIW we are trying to wrap up a set of patches for a 4.11 release and it
> > would
> > be good to have this in the ticket queue for consideration.
> >
> > Thanks.
> >
> > --joel
> >
> >
> > On Mon, Mar 5, 2018 at 2:31 PM, Éric Tremblay <
> e.tremb...@axis-canada.com>
> > wrote:
> >>
> >> Hi,
> >> I posted a question last week about a strange behavior I was getting
> using
> >> RTEMS with qemu-system-ppc. Anytime I was specifying more than 256Mb of
> >> memory using the -m option the RTEMS kernel was not booting. Here is an
> >> example of command line I was using:
> >>
> >> qemu-system-ppc -M prep -kernel ./hello.ralf -bios
> >> /home/qemu_fakerom/qemu_fakerom.bin -cpu 750cxe -nographic -no-reboot
> -m 384
> >>
> >> Model:
> >> Serial:
> >> Processor/Bus frequencies (Hz): 3/1
> >> Time Base Divisor: 1000
> >> Memory Size: 1800
> >> Residual: 102afd4 (length 27148)
> >>
> >> PCI: Probing PCI hardware
> >>
> >> RTEMS 4.x/PPC load:
> >> Uncompressing the kernel...
> >> Kernel at 0x, size=0x495b0
> >> Initrd at 0x, size=0x0
> >> Residual data at 0x0004a000
> >> Command line at 0x00051000
> >> done
> >> Now booting...
> execution
> >> stuck here
> >>
> >>
> >> I have spent quite some time debugging this issue and I traced it back
> to
> >> two issues for which I am submitting a patch. Please understand this
> is my
> >> first time using RTEMS and debugging a bootloader so my patch might not
> be
> >> accurate but it does fix the behavior I mentioned above. With this
> patch I
> >> can successfully launch a "Hello World" and specify more memory (-m 512
> for
> >> example).
> >>
> >> My patch is quite simple since it simply allows the system to access
> >> section of memory. Please let me know if this is a suitable
> correction, if
> >> this is totally wrong I would like to know how this could be fixed
> since our
> >> application will use around 512Mb of memory and the current state of
> things
> >> won't work.
> >>
> >> Thank you for your cooperation,
> >> Eric
> >>
> >> PS: I am using RTEMS release 4.11.3.
> >>I am using Qemu v 2.5.0
> >>I am running in a Linux Ubuntu VM (intel 64 bits)
> >>
> >>
> >>
> >>
> >> c/src/lib/libbsp/powerpc/shared/start/start.S | 18
> >> ++
> >> c/src/lib/libbsp/powerpc/shared/startup/bspstart.c | 18
> >> ++
> >> 2 files changed, 36 insertions(+)
> >>
> >> diff --git a/c/src/lib/libbsp/powerpc/shared/start/start.S
> >> b/c/src/lib/libbsp/powerpc/shared/start/start.S
> >> index 729c89c40b..532c1f9ee4 100644
> >> --- a/c/src/lib/libbsp/powerpc/shared/start/start.S
> >> +++ b/c/src/lib/libbsp/powerpc/shared/start/start.S
> >> @@ -93,6 +93,24 @@ __rtems_entry_point:
> >> mtspr IBAT0L,r8
> >> mtspr IBAT0U,r11
> >> isync
> >> +/* Map section where residual is located if outside
> >> + * the first 256Mb of RAM. This is to support cases
> >> + * where the user supplies the -m option with Qemu
> >> + * in order to have more memory available to the system.
> >> + */
> >> + mr r9, r1/* Get where residual was mapped */
> >> + lis r12,0xf000@h
> >> + and r9,r9,r12
> >> + cmpi 0,1,r9, 0
> >> + beq skip_BAT1_config
> >> + isync
> >> + ori r11,r9,0x1ffe
> >> + mtspr DBAT1L,r8 /* N.B. 6xx (not 601) have valid */
> >> + mtspr DBAT1U,r11 /* bit in upper BAT register */
> >> + mtspr IBAT1L,r8
> >> + mtspr IBAT1U,r11
> >> + isync
> >> +skip_BAT1_config:
> >>
> >> /*
> >> * we now have the 1st 256M of ram mapped with the bats. We are still
> >> diff --git a/c/src/lib/libbsp/powerpc/shared/startup/bspstart.c
> >> b/c/src/lib/libbsp/powerpc/shared/startup/bspstart.c
> >> index 5a97cc8531..f80835b117 100644
> >> --- a/c/src/lib/libbsp/powerpc/shared/startup/bspstart.c
> >> +++ b/c/src/lib/libbsp/powerpc/shared/startup/bspstart.c
> >> @@ -300,6 +300,24 @@ void bsp_start( void )
> >> */
> >>_BSP_clear_hostbridge_errors(0 /* enableMCP */, 0/*quiet*/);
> >>
> >> + if (BSP_mem_size > 0x1000)
> >> + {
> >> + /* Support cases with qemu supplied -m option and mem size larger
> than
> >> 256Mb.
> >> +*
>
Re: patch regarding 'RTEMS not booting with Qemu PREP larger than 256Mb'
On Tue, Mar 6, 2018 at 11:02 AM, Gedare Bloom wrote: > On Mon, Mar 5, 2018 at 5:37 PM, Joel Sherrill wrote: > > Can you file a ticket with the patch attached? We don't change things on > a > > release > > branch without a ticket? devel.rtems.org > > > +1 > > > Are you able to test this on real hardware? It touches files in shared > which > > will > > be used by multiple powerpc BSPs so it would be good to have feedback on > > real HW. > > > +2 > > This should be verified on hw before applying especially to a release. > > If it affects hw, also change the comments to just say "greater than > 256 MiB" without specifying qemu -m option. > I would add that it would be nice to capture his invocation of qemu in both rtems-testing (https://git.rtems.org/rtems-testing/tree/sim-scripts) and the rtems-tools (https://git.rtems.org/rtems-tools/tree/tester/rtems). The second is critical for automated testing. The first is old but still useful for running singleton tests. Eric .. Please don't think we are discouraging you. We just are trying to make sure your patch is merged and we cover all the bases. We have to depend on users when it comes to specific BSPs and hardware configurations, so we are careful. > > > FWIW we are trying to wrap up a set of patches for a 4.11 release and it > > would > > be good to have this in the ticket queue for consideration. > > > > Thanks. > > > > --joel > > > > > > On Mon, Mar 5, 2018 at 2:31 PM, Éric Tremblay < > e.tremb...@axis-canada.com> > > wrote: > >> > >> Hi, > >> I posted a question last week about a strange behavior I was getting > using > >> RTEMS with qemu-system-ppc. Anytime I was specifying more than 256Mb of > >> memory using the -m option the RTEMS kernel was not booting. Here is an > >> example of command line I was using: > >> > >> qemu-system-ppc -M prep -kernel ./hello.ralf -bios > >> /home/qemu_fakerom/qemu_fakerom.bin -cpu 750cxe -nographic -no-reboot > -m 384 > >> > >> Model: > >> Serial: > >> Processor/Bus frequencies (Hz): 3/1 > >> Time Base Divisor: 1000 > >> Memory Size: 1800 > >> Residual: 102afd4 (length 27148) > >> > >> PCI: Probing PCI hardware > >> > >> RTEMS 4.x/PPC load: > >> Uncompressing the kernel... > >> Kernel at 0x, size=0x495b0 > >> Initrd at 0x, size=0x0 > >> Residual data at 0x0004a000 > >> Command line at 0x00051000 > >> done > >> Now booting... > execution > >> stuck here > >> > >> > >> I have spent quite some time debugging this issue and I traced it back > to > >> two issues for which I am submitting a patch. Please understand this > is my > >> first time using RTEMS and debugging a bootloader so my patch might not > be > >> accurate but it does fix the behavior I mentioned above. With this > patch I > >> can successfully launch a "Hello World" and specify more memory (-m 512 > for > >> example). > >> > >> My patch is quite simple since it simply allows the system to access > >> section of memory. Please let me know if this is a suitable > correction, if > >> this is totally wrong I would like to know how this could be fixed > since our > >> application will use around 512Mb of memory and the current state of > things > >> won't work. > >> > >> Thank you for your cooperation, > >> Eric > >> > >> PS: I am using RTEMS release 4.11.3. > >>I am using Qemu v 2.5.0 > >>I am running in a Linux Ubuntu VM (intel 64 bits) > >> > >> > >> > >> > >> c/src/lib/libbsp/powerpc/shared/start/start.S | 18 > >> ++ > >> c/src/lib/libbsp/powerpc/shared/startup/bspstart.c | 18 > >> ++ > >> 2 files changed, 36 insertions(+) > >> > >> diff --git a/c/src/lib/libbsp/powerpc/shared/start/start.S > >> b/c/src/lib/libbsp/powerpc/shared/start/start.S > >> index 729c89c40b..532c1f9ee4 100644 > >> --- a/c/src/lib/libbsp/powerpc/shared/start/start.S > >> +++ b/c/src/lib/libbsp/powerpc/shared/start/start.S > >> @@ -93,6 +93,24 @@ __rtems_entry_point: > >> mtspr IBAT0L,r8 > >> mtspr IBAT0U,r11 > >> isync > >> +/* Map section where residual is located if outside > >> + * the first 256Mb of RAM. This is to support cases > >> + * where the user supplies the -m option with Qemu > >> + * in order to have more memory available to the system. > >> + */ > >> + mr r9, r1/* Get where residual was mapped */ > >> + lis r12,0xf000@h > >> + and r9,r9,r12 > >> + cmpi 0,1,r9, 0 > >> + beq skip_BAT1_config > >> + isync > >> + ori r11,r9,0x1ffe > >> + mtspr DBAT1L,r8 /* N.B. 6xx (not 601) have valid */ > >> + mtspr DBAT1U,r11 /* bit in upper BAT register */ > >> + mtspr IBAT1L,r8 > >> + mtspr IBAT1U,r11 > >> + isync > >> +skip_BAT1_config: > >> > >> /* > >> * we now have the 1st 256M of ram mapped with the bats. We are still > >> diff --git a/c/src/lib/libbsp/powerpc/shared/startup/bspstart.c > >> b/c/src/lib/libbsp/powerpc/shared/startup/bspstart.c > >> index 5a97cc8531..f80835b117 100644 > >> --- a/c/src/lib/libb
Re: getentropy() implementation on BBB
On Tue, Mar 6, 2018 at 9:43 AM, Udit agarwal wrote:
> Hi,
> Here's the updated code(I have also attached the patch PFA):
>
> From 96e6e1bfd8cffeef5d309eb0a07fe2bfd086ef0a Mon Sep 17 00:00:00 2001
> From: Udit agarwal
> Date: Tue, 6 Mar 2018 20:07:44 +0530
> Subject: [PATCH] Added getentropy support to BBB BSP
>
> ---
> bsps/arm/beagle/headers.am | 1 +
> bsps/arm/beagle/include/bsp/bbb_getentropy.h | 57 +++
> bsps/arm/include/libcpu/am335x.h | 16 +
> c/src/lib/libbsp/arm/beagle/Makefile.am| 4 ++
> .../libbsp/arm/beagle/getentropy/bbb_getentropy.c | 80
> ++
> 5 files changed, 158 insertions(+)
> create mode 100644 bsps/arm/beagle/include/bsp/bbb_getentropy.h
> create mode 100644 c/src/lib/libbsp/arm/beagle/getentropy/bbb_getentropy.c
>
> diff --git a/bsps/arm/beagle/headers.am b/bsps/arm/beagle/headers.am
> index 6692d0b..ac4ff7c 100644
> --- a/bsps/arm/beagle/headers.am
> +++ b/bsps/arm/beagle/headers.am
> @@ -12,3 +12,4 @@ include_bsp_HEADERS +=
> ../../../../../../bsps/arm/beagle/include/bsp/bbb-pwm.h
> include_bsp_HEADERS +=
> ../../../../../../bsps/arm/beagle/include/bsp/beagleboneblack.h
> include_bsp_HEADERS += ../../../../../../bsps/arm/beagle/include/bsp/i2c.h
> include_bsp_HEADERS += ../../../../../../bsps/arm/beagle/include/bsp/irq.h
> +include_bsp_HEADERS +=
> ../../../../../../bsps/arm/beagle/include/bsp/bbb_getentropy.h
> diff --git a/bsps/arm/beagle/include/bsp/bbb_getentropy.h
> b/bsps/arm/beagle/include/bsp/bbb_getentropy.h
> new file mode 100644
> index 000..5e46f89
> --- /dev/null
> +++ b/bsps/arm/beagle/include/bsp/bbb_getentropy.h
> @@ -0,0 +1,57 @@
> +/**
> + * @file
> + *
> + * @ingroup arm_beagle
> + *
> + * @brief TRNG Definations
> + */
> +
> +/*
> + * Copyright (c) 2018 Udit kumar agarwal
> + *
> + * 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 _TRNG_
> +#define _TRNG_
> +
> +/*--
Please look at similar files in RTEMS for how to add comments.
We do not use this style /*
And we don't put this kind of comment about the file sections.
> + * Headers
> +
> **/
> +
> +#include
> +
> +
> /*--
> + * Register structure
> +
> **/
> +
> +struct rng {
> +uint64_t output; /*00*/
> +uint32_t status; /*08*/
> +uint32_t irq_en; /*0c*/
> +uint32_t status_clr; /*10*/
> +uint32_t control; /*14*/
> +uint32_t config; /*18*/
> +};
for an exported header, the struct namespace needs to be user
friendly. See similar files at this layer for how to name things.
Probably, this can be defined in the am335x.h header?
> +
> +typedef volatile struct rng *rng_ref_t;
I'm not such a big fan of using the typedef to hide things like
volatile or pointer notation. I don't see a need for this usually.
> +
> +/**/
> +/* Exported functions
> */
> +/**/
> +
> +/* configure and enable RNG module */
> +static void am335x_rng_enable(rng_ref_t);
> +/* enable module clock for random number generator */
> +static void am335x_rng_clock_enable(void);
> +/* outputs random data */
> +static uint64_t trng_getranddata(rng_ref_t);
static keyword implies these are not exported.
> +/* Copy random data of a specified size to the pointer supplied */
> +int getentropy(void *ptr, size_t);
I guess getentropy() is already exported by a different header file
(unistd.h) in libc? This doesn't belong here.
I suspect this header file is not actually necessary.
> +
> +
> +
Don't use multiple blank lines in a row. Only one empty line is ever
needed by RTEMS style.
> +#endif /* #ifndef _TRNG_ */
> \ No newline at end of file
> diff --git a/bsps/arm/include/libcpu/am335x.h
> b/bsps/arm/include/libcpu/am335x.h
> index 367e97c..8b58f1a 100644
> --- a/bsps/arm/include/libcpu/am335x.h
> +++ b/bsps/arm/include/libcpu/am335x.h
> @@ -14,6 +14,9 @@
> * Modified by Ben Gras to add lots
> * of beagleboard/beaglebone definitions, delete lpc32xx specific
> * ones, and merge with some other header files.
> + *
> + * Modified by Udit agarwal to add random
> + * number generating module definations
typo: definitions
add a period (full stop).
> */
>
> #if !defined(_AM335X_H_)
> @@ -701,4 +704,17 @@
> #define AM335X_CM_PER_OCPWP_L3_CLKSTCTRL_CLKACTIVITY_OCPWP_L4_GCLK
> (0x0020u)
> #define AM335X_I2C_INT_STOP_CONDITION AM335X_I2C_IRQSTATUS_BF
>
> +/* TRNG Register */
> +
> +/*
Re: patch regarding 'RTEMS not booting with Qemu PREP larger than 256Mb'
Éric It would be preferable if you could create the ticket, so we have the right "reporter" in mind later. Gedare On Tue, Mar 6, 2018 at 12:25 PM, Éric Tremblay wrote: > Hi Gedare, Joel, > Unfortunately I do not have access to hw so I cannot test in this > environment. > > Do you want me to create the ticket or one of you will take care of it? > > Thanks, > Eric > > On Tue, Mar 6, 2018 at 12:02 PM, Gedare Bloom wrote: >> >> On Mon, Mar 5, 2018 at 5:37 PM, Joel Sherrill wrote: >> > Can you file a ticket with the patch attached? We don't change things on >> > a >> > release >> > branch without a ticket? devel.rtems.org >> > >> +1 >> >> > Are you able to test this on real hardware? It touches files in shared >> > which >> > will >> > be used by multiple powerpc BSPs so it would be good to have feedback on >> > real HW. >> > >> +2 >> >> This should be verified on hw before applying especially to a release. >> >> If it affects hw, also change the comments to just say "greater than >> 256 MiB" without specifying qemu -m option. >> >> > FWIW we are trying to wrap up a set of patches for a 4.11 release and it >> > would >> > be good to have this in the ticket queue for consideration. >> > >> > Thanks. >> > >> > --joel >> > >> > >> > On Mon, Mar 5, 2018 at 2:31 PM, Éric Tremblay >> > >> > wrote: >> >> >> >> Hi, >> >> I posted a question last week about a strange behavior I was getting >> >> using >> >> RTEMS with qemu-system-ppc. Anytime I was specifying more than 256Mb >> >> of >> >> memory using the -m option the RTEMS kernel was not booting. Here is >> >> an >> >> example of command line I was using: >> >> >> >> qemu-system-ppc -M prep -kernel ./hello.ralf -bios >> >> /home/qemu_fakerom/qemu_fakerom.bin -cpu 750cxe -nographic -no-reboot >> >> -m 384 >> >> >> >> Model: >> >> Serial: >> >> Processor/Bus frequencies (Hz): 3/1 >> >> Time Base Divisor: 1000 >> >> Memory Size: 1800 >> >> Residual: 102afd4 (length 27148) >> >> >> >> PCI: Probing PCI hardware >> >> >> >> RTEMS 4.x/PPC load: >> >> Uncompressing the kernel... >> >> Kernel at 0x, size=0x495b0 >> >> Initrd at 0x, size=0x0 >> >> Residual data at 0x0004a000 >> >> Command line at 0x00051000 >> >> done >> >> Now booting... >> >> execution >> >> stuck here >> >> >> >> >> >> I have spent quite some time debugging this issue and I traced it back >> >> to >> >> two issues for which I am submitting a patch. Please understand this >> >> is my >> >> first time using RTEMS and debugging a bootloader so my patch might not >> >> be >> >> accurate but it does fix the behavior I mentioned above. With this >> >> patch I >> >> can successfully launch a "Hello World" and specify more memory (-m 512 >> >> for >> >> example). >> >> >> >> My patch is quite simple since it simply allows the system to access >> >> section of memory. Please let me know if this is a suitable >> >> correction, if >> >> this is totally wrong I would like to know how this could be fixed >> >> since our >> >> application will use around 512Mb of memory and the current state of >> >> things >> >> won't work. >> >> >> >> Thank you for your cooperation, >> >> Eric >> >> >> >> PS: I am using RTEMS release 4.11.3. >> >>I am using Qemu v 2.5.0 >> >>I am running in a Linux Ubuntu VM (intel 64 bits) >> >> >> >> >> >> >> >> >> >> c/src/lib/libbsp/powerpc/shared/start/start.S | 18 >> >> ++ >> >> c/src/lib/libbsp/powerpc/shared/startup/bspstart.c | 18 >> >> ++ >> >> 2 files changed, 36 insertions(+) >> >> >> >> diff --git a/c/src/lib/libbsp/powerpc/shared/start/start.S >> >> b/c/src/lib/libbsp/powerpc/shared/start/start.S >> >> index 729c89c40b..532c1f9ee4 100644 >> >> --- a/c/src/lib/libbsp/powerpc/shared/start/start.S >> >> +++ b/c/src/lib/libbsp/powerpc/shared/start/start.S >> >> @@ -93,6 +93,24 @@ __rtems_entry_point: >> >> mtspr IBAT0L,r8 >> >> mtspr IBAT0U,r11 >> >> isync >> >> +/* Map section where residual is located if outside >> >> + * the first 256Mb of RAM. This is to support cases >> >> + * where the user supplies the -m option with Qemu >> >> + * in order to have more memory available to the system. >> >> + */ >> >> + mr r9, r1/* Get where residual was mapped */ >> >> + lis r12,0xf000@h >> >> + and r9,r9,r12 >> >> + cmpi 0,1,r9, 0 >> >> + beq skip_BAT1_config >> >> + isync >> >> + ori r11,r9,0x1ffe >> >> + mtspr DBAT1L,r8 /* N.B. 6xx (not 601) have valid */ >> >> + mtspr DBAT1U,r11 /* bit in upper BAT register */ >> >> + mtspr IBAT1L,r8 >> >> + mtspr IBAT1U,r11 >> >> + isync >> >> +skip_BAT1_config: >> >> >> >> /* >> >> * we now have the 1st 256M of ram mapped with the bats. We are still >> >> diff --git a/c/src/lib/libbsp/powerpc/shared/startup/bspstart.c >> >> b/c/src/lib/libbsp/powerpc/shared/startup/bspstart.c >> >> index 5a97cc8531..f80835b117 100644 >> >> --- a/c/src/lib/libbsp/powerpc/shared/startup/bspstart.c >> >>
Re: patch regarding 'RTEMS not booting with Qemu PREP larger than 256Mb'
On Tue, Mar 6, 2018 at 11:25 AM, Éric Tremblay wrote: > Hi Gedare, Joel, > Unfortunately I do not have access to hw so I cannot test in this > environment. > Hmm... We will have to find someone with a board to test it. I have a few users in mind. > > Do you want me to create the ticket or one of you will take care of it? > It would be best if you do, because you have the issue and patch. > > Thanks, > Eric > > On Tue, Mar 6, 2018 at 12:02 PM, Gedare Bloom wrote: > >> On Mon, Mar 5, 2018 at 5:37 PM, Joel Sherrill wrote: >> > Can you file a ticket with the patch attached? We don't change things >> on a >> > release >> > branch without a ticket? devel.rtems.org >> > >> +1 >> >> > Are you able to test this on real hardware? It touches files in shared >> which >> > will >> > be used by multiple powerpc BSPs so it would be good to have feedback on >> > real HW. >> > >> +2 >> >> This should be verified on hw before applying especially to a release. >> >> If it affects hw, also change the comments to just say "greater than >> 256 MiB" without specifying qemu -m option. >> >> > FWIW we are trying to wrap up a set of patches for a 4.11 release and it >> > would >> > be good to have this in the ticket queue for consideration. >> > >> > Thanks. >> > >> > --joel >> > >> > >> > On Mon, Mar 5, 2018 at 2:31 PM, Éric Tremblay < >> e.tremb...@axis-canada.com> >> > wrote: >> >> >> >> Hi, >> >> I posted a question last week about a strange behavior I was getting >> using >> >> RTEMS with qemu-system-ppc. Anytime I was specifying more than 256Mb >> of >> >> memory using the -m option the RTEMS kernel was not booting. Here is >> an >> >> example of command line I was using: >> >> >> >> qemu-system-ppc -M prep -kernel ./hello.ralf -bios >> >> /home/qemu_fakerom/qemu_fakerom.bin -cpu 750cxe -nographic -no-reboot >> -m 384 >> >> >> >> Model: >> >> Serial: >> >> Processor/Bus frequencies (Hz): 3/1 >> >> Time Base Divisor: 1000 >> >> Memory Size: 1800 >> >> Residual: 102afd4 (length 27148) >> >> >> >> PCI: Probing PCI hardware >> >> >> >> RTEMS 4.x/PPC load: >> >> Uncompressing the kernel... >> >> Kernel at 0x, size=0x495b0 >> >> Initrd at 0x, size=0x0 >> >> Residual data at 0x0004a000 >> >> Command line at 0x00051000 >> >> done >> >> Now booting... >> execution >> >> stuck here >> >> >> >> >> >> I have spent quite some time debugging this issue and I traced it back >> to >> >> two issues for which I am submitting a patch. Please understand this >> is my >> >> first time using RTEMS and debugging a bootloader so my patch might >> not be >> >> accurate but it does fix the behavior I mentioned above. With this >> patch I >> >> can successfully launch a "Hello World" and specify more memory (-m >> 512 for >> >> example). >> >> >> >> My patch is quite simple since it simply allows the system to access >> >> section of memory. Please let me know if this is a suitable >> correction, if >> >> this is totally wrong I would like to know how this could be fixed >> since our >> >> application will use around 512Mb of memory and the current state of >> things >> >> won't work. >> >> >> >> Thank you for your cooperation, >> >> Eric >> >> >> >> PS: I am using RTEMS release 4.11.3. >> >>I am using Qemu v 2.5.0 >> >>I am running in a Linux Ubuntu VM (intel 64 bits) >> >> >> >> >> >> >> >> >> >> c/src/lib/libbsp/powerpc/shared/start/start.S | 18 >> >> ++ >> >> c/src/lib/libbsp/powerpc/shared/startup/bspstart.c | 18 >> >> ++ >> >> 2 files changed, 36 insertions(+) >> >> >> >> diff --git a/c/src/lib/libbsp/powerpc/shared/start/start.S >> >> b/c/src/lib/libbsp/powerpc/shared/start/start.S >> >> index 729c89c40b..532c1f9ee4 100644 >> >> --- a/c/src/lib/libbsp/powerpc/shared/start/start.S >> >> +++ b/c/src/lib/libbsp/powerpc/shared/start/start.S >> >> @@ -93,6 +93,24 @@ __rtems_entry_point: >> >> mtspr IBAT0L,r8 >> >> mtspr IBAT0U,r11 >> >> isync >> >> +/* Map section where residual is located if outside >> >> + * the first 256Mb of RAM. This is to support cases >> >> + * where the user supplies the -m option with Qemu >> >> + * in order to have more memory available to the system. >> >> + */ >> >> + mr r9, r1/* Get where residual was mapped */ >> >> + lis r12,0xf000@h >> >> + and r9,r9,r12 >> >> + cmpi 0,1,r9, 0 >> >> + beq skip_BAT1_config >> >> + isync >> >> + ori r11,r9,0x1ffe >> >> + mtspr DBAT1L,r8 /* N.B. 6xx (not 601) have valid */ >> >> + mtspr DBAT1U,r11 /* bit in upper BAT register */ >> >> + mtspr IBAT1L,r8 >> >> + mtspr IBAT1U,r11 >> >> + isync >> >> +skip_BAT1_config: >> >> >> >> /* >> >> * we now have the 1st 256M of ram mapped with the bats. We are still >> >> diff --git a/c/src/lib/libbsp/powerpc/shared/startup/bspstart.c >> >> b/c/src/lib/libbsp/powerpc/shared/startup/bspstart.c >> >> index 5a97cc8531..f80835b117 100644 >> >> --- a/c/src/lib/libbsp/powerpc
Re: patch regarding 'RTEMS not booting with Qemu PREP larger than 256Mb'
Hi, I just created the ticket (#3322) with the patch in attachment. Let's hope I filled the ticket with enough information. If there is anything else you need let me know. Eric On Tue, Mar 6, 2018 at 12:36 PM, Gedare Bloom wrote: > Éric > > It would be preferable if you could create the ticket, so we have the > right "reporter" in mind later. > > Gedare > > On Tue, Mar 6, 2018 at 12:25 PM, Éric Tremblay > wrote: > > Hi Gedare, Joel, > > Unfortunately I do not have access to hw so I cannot test in this > > environment. > > > > Do you want me to create the ticket or one of you will take care of it? > > > > Thanks, > > Eric > > > > On Tue, Mar 6, 2018 at 12:02 PM, Gedare Bloom wrote: > >> > >> On Mon, Mar 5, 2018 at 5:37 PM, Joel Sherrill wrote: > >> > Can you file a ticket with the patch attached? We don't change things > on > >> > a > >> > release > >> > branch without a ticket? devel.rtems.org > >> > > >> +1 > >> > >> > Are you able to test this on real hardware? It touches files in shared > >> > which > >> > will > >> > be used by multiple powerpc BSPs so it would be good to have feedback > on > >> > real HW. > >> > > >> +2 > >> > >> This should be verified on hw before applying especially to a release. > >> > >> If it affects hw, also change the comments to just say "greater than > >> 256 MiB" without specifying qemu -m option. > >> > >> > FWIW we are trying to wrap up a set of patches for a 4.11 release and > it > >> > would > >> > be good to have this in the ticket queue for consideration. > >> > > >> > Thanks. > >> > > >> > --joel > >> > > >> > > >> > On Mon, Mar 5, 2018 at 2:31 PM, Éric Tremblay > >> > > >> > wrote: > >> >> > >> >> Hi, > >> >> I posted a question last week about a strange behavior I was getting > >> >> using > >> >> RTEMS with qemu-system-ppc. Anytime I was specifying more than 256Mb > >> >> of > >> >> memory using the -m option the RTEMS kernel was not booting. Here is > >> >> an > >> >> example of command line I was using: > >> >> > >> >> qemu-system-ppc -M prep -kernel ./hello.ralf -bios > >> >> /home/qemu_fakerom/qemu_fakerom.bin -cpu 750cxe -nographic > -no-reboot > >> >> -m 384 > >> >> > >> >> Model: > >> >> Serial: > >> >> Processor/Bus frequencies (Hz): 3/1 > >> >> Time Base Divisor: 1000 > >> >> Memory Size: 1800 > >> >> Residual: 102afd4 (length 27148) > >> >> > >> >> PCI: Probing PCI hardware > >> >> > >> >> RTEMS 4.x/PPC load: > >> >> Uncompressing the kernel... > >> >> Kernel at 0x, size=0x495b0 > >> >> Initrd at 0x, size=0x0 > >> >> Residual data at 0x0004a000 > >> >> Command line at 0x00051000 > >> >> done > >> >> Now booting... > >> >> execution > >> >> stuck here > >> >> > >> >> > >> >> I have spent quite some time debugging this issue and I traced it > back > >> >> to > >> >> two issues for which I am submitting a patch. Please understand this > >> >> is my > >> >> first time using RTEMS and debugging a bootloader so my patch might > not > >> >> be > >> >> accurate but it does fix the behavior I mentioned above. With this > >> >> patch I > >> >> can successfully launch a "Hello World" and specify more memory (-m > 512 > >> >> for > >> >> example). > >> >> > >> >> My patch is quite simple since it simply allows the system to access > >> >> section of memory. Please let me know if this is a suitable > >> >> correction, if > >> >> this is totally wrong I would like to know how this could be fixed > >> >> since our > >> >> application will use around 512Mb of memory and the current state of > >> >> things > >> >> won't work. > >> >> > >> >> Thank you for your cooperation, > >> >> Eric > >> >> > >> >> PS: I am using RTEMS release 4.11.3. > >> >>I am using Qemu v 2.5.0 > >> >>I am running in a Linux Ubuntu VM (intel 64 bits) > >> >> > >> >> > >> >> > >> >> > >> >> c/src/lib/libbsp/powerpc/shared/start/start.S | 18 > >> >> ++ > >> >> c/src/lib/libbsp/powerpc/shared/startup/bspstart.c | 18 > >> >> ++ > >> >> 2 files changed, 36 insertions(+) > >> >> > >> >> diff --git a/c/src/lib/libbsp/powerpc/shared/start/start.S > >> >> b/c/src/lib/libbsp/powerpc/shared/start/start.S > >> >> index 729c89c40b..532c1f9ee4 100644 > >> >> --- a/c/src/lib/libbsp/powerpc/shared/start/start.S > >> >> +++ b/c/src/lib/libbsp/powerpc/shared/start/start.S > >> >> @@ -93,6 +93,24 @@ __rtems_entry_point: > >> >> mtspr IBAT0L,r8 > >> >> mtspr IBAT0U,r11 > >> >> isync > >> >> +/* Map section where residual is located if outside > >> >> + * the first 256Mb of RAM. This is to support cases > >> >> + * where the user supplies the -m option with Qemu > >> >> + * in order to have more memory available to the system. > >> >> + */ > >> >> + mr r9, r1/* Get where residual was mapped */ > >> >> + lis r12,0xf000@h > >> >> + and r9,r9,r12 > >> >> + cmpi 0,1,r9, 0 > >> >> + beq skip_BAT1_config > >> >> + isync > >> >> + ori r11,r9,0x1ff
Re: patch regarding 'RTEMS not booting with Qemu PREP larger than 256Mb'
Great, thanks. Regarding the patch, I didn't notice before, but we avoid use of tabs preferring instead space characters. If you wouldn't mind reformatting the patch, that would be helpful. Later, some expert in powerpc might give more feedback. :) On Tue, Mar 6, 2018 at 1:03 PM, Éric Tremblay wrote: > Hi, > I just created the ticket (#3322) with the patch in attachment. Let's hope > I filled the ticket with enough information. > > If there is anything else you need let me know. > > Eric > > On Tue, Mar 6, 2018 at 12:36 PM, Gedare Bloom wrote: >> >> Éric >> >> It would be preferable if you could create the ticket, so we have the >> right "reporter" in mind later. >> >> Gedare >> >> On Tue, Mar 6, 2018 at 12:25 PM, Éric Tremblay >> wrote: >> > Hi Gedare, Joel, >> > Unfortunately I do not have access to hw so I cannot test in this >> > environment. >> > >> > Do you want me to create the ticket or one of you will take care of it? >> > >> > Thanks, >> > Eric >> > >> > On Tue, Mar 6, 2018 at 12:02 PM, Gedare Bloom wrote: >> >> >> >> On Mon, Mar 5, 2018 at 5:37 PM, Joel Sherrill wrote: >> >> > Can you file a ticket with the patch attached? We don't change things >> >> > on >> >> > a >> >> > release >> >> > branch without a ticket? devel.rtems.org >> >> > >> >> +1 >> >> >> >> > Are you able to test this on real hardware? It touches files in >> >> > shared >> >> > which >> >> > will >> >> > be used by multiple powerpc BSPs so it would be good to have feedback >> >> > on >> >> > real HW. >> >> > >> >> +2 >> >> >> >> This should be verified on hw before applying especially to a release. >> >> >> >> If it affects hw, also change the comments to just say "greater than >> >> 256 MiB" without specifying qemu -m option. >> >> >> >> > FWIW we are trying to wrap up a set of patches for a 4.11 release and >> >> > it >> >> > would >> >> > be good to have this in the ticket queue for consideration. >> >> > >> >> > Thanks. >> >> > >> >> > --joel >> >> > >> >> > >> >> > On Mon, Mar 5, 2018 at 2:31 PM, Éric Tremblay >> >> > >> >> > wrote: >> >> >> >> >> >> Hi, >> >> >> I posted a question last week about a strange behavior I was getting >> >> >> using >> >> >> RTEMS with qemu-system-ppc. Anytime I was specifying more than >> >> >> 256Mb >> >> >> of >> >> >> memory using the -m option the RTEMS kernel was not booting. Here >> >> >> is >> >> >> an >> >> >> example of command line I was using: >> >> >> >> >> >> qemu-system-ppc -M prep -kernel ./hello.ralf -bios >> >> >> /home/qemu_fakerom/qemu_fakerom.bin -cpu 750cxe -nographic >> >> >> -no-reboot >> >> >> -m 384 >> >> >> >> >> >> Model: >> >> >> Serial: >> >> >> Processor/Bus frequencies (Hz): 3/1 >> >> >> Time Base Divisor: 1000 >> >> >> Memory Size: 1800 >> >> >> Residual: 102afd4 (length 27148) >> >> >> >> >> >> PCI: Probing PCI hardware >> >> >> >> >> >> RTEMS 4.x/PPC load: >> >> >> Uncompressing the kernel... >> >> >> Kernel at 0x, size=0x495b0 >> >> >> Initrd at 0x, size=0x0 >> >> >> Residual data at 0x0004a000 >> >> >> Command line at 0x00051000 >> >> >> done >> >> >> Now booting... >> >> >> execution >> >> >> stuck here >> >> >> >> >> >> >> >> >> I have spent quite some time debugging this issue and I traced it >> >> >> back >> >> >> to >> >> >> two issues for which I am submitting a patch. Please understand >> >> >> this >> >> >> is my >> >> >> first time using RTEMS and debugging a bootloader so my patch might >> >> >> not >> >> >> be >> >> >> accurate but it does fix the behavior I mentioned above. With this >> >> >> patch I >> >> >> can successfully launch a "Hello World" and specify more memory (-m >> >> >> 512 >> >> >> for >> >> >> example). >> >> >> >> >> >> My patch is quite simple since it simply allows the system to access >> >> >> section of memory. Please let me know if this is a suitable >> >> >> correction, if >> >> >> this is totally wrong I would like to know how this could be fixed >> >> >> since our >> >> >> application will use around 512Mb of memory and the current state of >> >> >> things >> >> >> won't work. >> >> >> >> >> >> Thank you for your cooperation, >> >> >> Eric >> >> >> >> >> >> PS: I am using RTEMS release 4.11.3. >> >> >>I am using Qemu v 2.5.0 >> >> >>I am running in a Linux Ubuntu VM (intel 64 bits) >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> c/src/lib/libbsp/powerpc/shared/start/start.S | 18 >> >> >> ++ >> >> >> c/src/lib/libbsp/powerpc/shared/startup/bspstart.c | 18 >> >> >> ++ >> >> >> 2 files changed, 36 insertions(+) >> >> >> >> >> >> diff --git a/c/src/lib/libbsp/powerpc/shared/start/start.S >> >> >> b/c/src/lib/libbsp/powerpc/shared/start/start.S >> >> >> index 729c89c40b..532c1f9ee4 100644 >> >> >> --- a/c/src/lib/libbsp/powerpc/shared/start/start.S >> >> >> +++ b/c/src/lib/libbsp/powerpc/shared/start/start.S >> >> >> @@ -93,6 +93,24 @@ __rtems_entry_point: >> >> >> mtspr
Re: MMU was Re: Contribute to a project under GSOC 2018
Sir, Thanks a lot for the guidance. I will study the documents provided by you and will try to find more about this to increase my knowledge about Memory support. I will start preparing a draft proposal as per the template provided on the RTEMS GSoC page. Thanks and Regards Abhinav Jain On Mar 6, 2018 10:25 PM, "Gedare Bloom" wrote: On Sun, Mar 4, 2018 at 1:50 AM, Abhinav Jain wrote: > Sir, > > Thanks for your time and consideration. I was discussing this project with > Gedare Sir and he guided me, how to proceed. > I am studying various things before proceeding with the code part but for > now, I request you to please guide me what should be my next steps to work > on this project under GSOC'18. > > Thanks and Regards > Abhinav Jain > > On Sun, Mar 4, 2018 at 10:48 AM, Hesham Almatary > wrote: >> >> On Sun, Mar 4, 2018 at 10:20 AM, Joel Sherrill wrote: >> > >> > >> > On Mar 3, 2018 12:16 PM, "Abhinav Jain" wrote: >> > >> > Sir/Madam, >> > >> > I am Abhinav Jain, a second-year engineering student from Delhi, India. >> > I >> > have been working in Linux Kernel Development, I have been writing small >> > drivers and have a good knowledge of the operating system. >> > I have been studying about Memory Protection project(ticket #2904) for >> > around a month and found it really interesting. I studied about POSIX, >> > MMU >> > support in various other architecture and the memory protection APIs in >> > various operating systems.I have been discussing the same on the mailing >> > list. >> > I also solved an issue (#2522) around a week ago to gain some hands-on >> > code. >> > -ENOPATCH >> > >> > Welcome aboard. >> > >> > >> > I would like to work on the Memory Protection project under GSOC 2018, >> > so I >> > request you to please guide me regarding the steps to be followed. >> > >> > >> > Gedare conceived of what's there be so I cc'ed him. My recollection is >> > that >> > there were specific things he wanted to change and when that was >> > addressed, >> > providing support for arenas on multiple architecture is desirable >> > >> +1 >> >> There might be an opportunity to port RTEMS to RISC-V's Supervisor >> Mode which will need MMU support (currently it only runs on M-Mode >> which doesn't have MMU). Both QEMU and Spike simulators support >> S-Mode. >> Start to develop a draft proposal if you have not yet, starting with our template. A successful proposal must contain a sound design and good plan, which you will need a lot of time and feedback to develop. Don't read too much about 64-bit processor architectures and their needs, since we have limited support there. The first issue to resolve is what kind of BSP-level interface should we provide over MMU/MPU hardware, and then what can we do to use that BSP layer to provide upper-layer services such as managed memory regions, better mmap() support, "arena" allocators, etc. There are three views here: 1. no mmu/mpu is available or it is not desired by end users. 2. mmu/mpu are available, but should only be manipulated statically/boot-time. 3. mmu/mpu are available, and can be changed dynamically. Managing #3 is the hardest, but accommodating 1 and 2 in any system design is important. Another important concern is mmu/mpu with limited numbers of entries. Right now, we exist mainly in #1, and #2 is only used to setup a linear 1:1 memory map with all permissions enabled when the MMU/MPU can't be turned off. A few projects exist here and there to also restrict permissions to thread stacks with a hook in the context switch to change the mpu/mmu state. Since RTEMS has no multi-process model, the existing solutions in general-purpose commodity OS do not apply, but you should still be familiar with how they work for sure. It would also be good for you to review the solutions in the commodity RTOS domain, e.g. what does vxworks, safertos, threadx, etc., provides in this field. Some relevant citations to get more relevant background: https://highintegritysystems.com/downloads/white_papers/ Using_an_MPU_to_Enforce_Spatial_Separation.pdf https://pdfs.semanticscholar.org/3c92/7ed6b426fccfb203dd96be9b7591b3 744f1f.pdf https://www.researchgate.net/publication/221033285_A_New_Approach_to_Memory_ Partitioning_in_On-Board_Spacecraft_Software >> > >> > >> > Thanks and Regards >> > Abhinav Jain >> > >> > ___ >> > 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 >> >> >> >> -- >> Hesham > > ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH] bsps: More verbose bsp_fatal_extension()
Close #3318.
---
c/src/lib/libbsp/shared/bspclean.c | 20
1 file changed, 20 insertions(+)
diff --git a/c/src/lib/libbsp/shared/bspclean.c
b/c/src/lib/libbsp/shared/bspclean.c
index e5fee78961..4ed6243b57 100644
--- a/c/src/lib/libbsp/shared/bspclean.c
+++ b/c/src/lib/libbsp/shared/bspclean.c
@@ -11,6 +11,8 @@
#include
#include
#include
+#include
+#include
void bsp_fatal_extension(
rtems_fatal_source source,
@@ -19,6 +21,8 @@ void bsp_fatal_extension(
)
{
#if BSP_VERBOSE_FATAL_EXTENSION
+Thread_Control *executing;
+
printk(
"\n"
"*** FATAL ***\n"
@@ -55,6 +59,22 @@ void bsp_fatal_extension(
rtems_version(),
__VERSION__
);
+
+executing = _Thread_Get_executing();
+
+if ( executing != NULL ) {
+ char name[ 32 ];
+
+ _Thread_Get_name( executing, name, sizeof( name ) );
+ printk(
+"executing thread ID: 0x08%" PRIx32 "\n"
+"executing thread name: %s\n",
+executing->Object.id,
+name
+ );
+} else {
+ printk( "executing thread is NULL\n" );
+}
#endif
#if (BSP_PRESS_KEY_FOR_RESET)
--
2.12.3
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
