On Mon, Mar 5, 2018 at 5:37 PM, Joel Sherrill <j...@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.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): 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@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@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
