patch regarding 'RTEMS not booting with Qemu PREP larger than 256Mb'
Gedare Bloom
gedare at rtems.org
Tue Mar 6 18:39:08 UTC 2018
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
<e.tremblay at axis-canada.com> 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 <gedare at rtems.org> 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
>> <e.tremblay at axis-canada.com> 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 <gedare at rtems.org> wrote:
>> >>
>> >> 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
>> >
>> >
>
>
More information about the devel
mailing list