patch regarding 'RTEMS not booting with Qemu PREP larger than 256Mb'
Éric Tremblay
e.tremblay at axis-canada.com
Tue Mar 6 18:03:39 UTC 2018
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
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20180306/21df4606/attachment-0001.html>
More information about the devel
mailing list