patch regarding 'RTEMS not booting with Qemu PREP larger than 256Mb'

Tue Mar 6 17:02:51 UTC 2018

On Mon, Mar 5, 2018 at 5:37 PM, Joel Sherrill <joel at rtems.org> 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.tremblay at 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): 300000000/100000000
>> Time Base Divisor: 1000
>> Memory Size: 18000000
>> Residual: 102afd4 (length 27148)
>>
>> PCI: Probing PCI hardware
>>
>> RTEMS 4.x/PPC load:
>> Uncompressing the kernel...
>> Kernel at 0x00000000, size=0x495b0
>> Initrd at 0x00000000, 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,0xf0000000 at 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 > 0x10000000)
>> +   {
>> +   /* 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 / 0x10000000);
>> +   const unsigned int BAT3Addr    = ((BSP_mem_size % 0x10000000)    ?
>> + (mem256Count     * 0x10000000) :
>> + ((mem256Count-1) * 0x10000000));
>> +      setdbat(3, BAT3Addr, BAT3Addr, 0x10000000, IO_PAGE);
>> +#ifdef SHOW_MORE_INIT_SETTINGS
>> +      printk("Setting up BAT3 for large memory support. (BAT3 -->
>> 0x%x)\n", BAT3Addr);
>> +#endif
>> +   }
>> +
>>    /* Allocate and set up the page table mappings
>>     * This is only available on >604 CPUs.
>>     *
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> devel mailing list
>> devel at rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
>
>
>
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel