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

[Joel Sherrill]

Can you file a ticket with the patch attached? We don't change things on a
release
branch without a ticket? devel.rtems.org

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.

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20180305/6274c823/attachment-0002.html>