On Mon, May 3, 2021 at 5:36 PM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:
> On 03/05/2021 13:47, somesh deshmukh wrote:
>
> > I performed the following sequence of instruction:
> > ./waf clean
> > ./waf configure
> > ./waf
> >
> > Tried this couple of times but the same result al
On 03/05/2021 13:47, somesh deshmukh wrote:
I performed the following sequence of instruction:
./waf clean
./waf configure
./waf
Tried this couple of times but the same result always.
I will try this again with fresh sources from rsb and rtems master
branches.
Now it should work. I forgot to
On Mon, May 3, 2021 at 5:01 PM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:
> On 03/05/2021 13:25, somesh deshmukh wrote:
>
> >
> > I tried this patch with the master branch and the build is failing
> > after applying the patch.
> >
> > The error message includes:
> >
> >
> /home/s
On 03/05/2021 13:25, somesh deshmukh wrote:
I tried this patch with the master branch and the build is failing
after applying the patch.
The error message includes:
/home/somesh/Documents/rtems-temp/rtems/6/lib/gcc/riscv-rtems6/10.2.1/../../../../riscv-rtems6/bin/ld:
/home/somesh/work/rtem
Hi Sebastian,
I tried this patch with the master branch and the build is failing after
applying the patch.
The error message includes:
/home/somesh/Documents/rtems-temp/rtems/6/lib/gcc/riscv-rtems6/10.2.1/../../../../riscv-rtems6/bin/ld:
/home/somesh/work/rtems-master/rtems/build/riscv/rv64imafd
On 30/04/2021 15:34, Sebastian Huber wrote:
On 30/04/2021 15:32, Hesham Almatary wrote:
The noinit attributes is a bit broken in GCC:
I guess we can go for a separate custom section then? Or we can just
assign it a magic value so that it doesn’t go into BSS.
I propose to add something
On 30/04/2021 15:32, Hesham Almatary wrote:
The noinit attributes is a bit broken in GCC:
I guess we can go for a separate custom section then? Or we can just
assign it a magic value so that it doesn’t go into BSS.
I propose to add something like this:
+/* Generated from spec:/rtems/bas
On Fri, 30 Apr 2021 at 14:22, Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:
> On 29/04/2021 20:53, Sebastian Huber wrote:
>
> > On 29/04/2021 20:18, Hesham Almatary wrote:
> >
> I would place the device tree in a noinit section.
>
> >>> That is probably a better solution.
Hi Sebastian,
For testing, I had manually added the device tree blob address into the a1
register.
On Fri, Apr 30, 2021 at 6:52 PM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:
> On 29/04/2021 20:53, Sebastian Huber wrote:
>
> > On 29/04/2021 20:18, Hesham Almatary wrote:
> >
> >>
On 29/04/2021 20:53, Sebastian Huber wrote:
On 29/04/2021 20:18, Hesham Almatary wrote:
I would place the device tree in a noinit section.
That is probably a better solution.
It should also be documented in this start.S file what are the
assumptions about parameters coming from the bootload
On 29/04/2021 20:18, Hesham Almatary wrote:
I would place the device tree in a noinit section.
That is probably a better solution.
It should also be documented in this start.S file what are the
assumptions about parameters coming from the bootloader since it is
not obvious.
+1
The recent G
On Thu, 29 Apr 2021 at 20:07, Gedare Bloom wrote:
>
> On Thu, Apr 29, 2021 at 11:53 AM Sebastian Huber
> wrote:
> >
> >
> > On 28/04/2021 15:55, Somesh Deshmukh wrote:
> > > +/* Clear .bss */
> > > +LADDRa0, bsp_section_bss_begin
> > > +li a1, 0
> > > +LADDRa2, bsp_section_bss_s
On Thu, Apr 29, 2021 at 11:53 AM Sebastian Huber
wrote:
>
>
> On 28/04/2021 15:55, Somesh Deshmukh wrote:
> > +/* Clear .bss */
> > +LADDRa0, bsp_section_bss_begin
> > +li a1, 0
> > +LADDRa2, bsp_section_bss_size
> > +call memset
> > +
> > #ifdef BSP_START_COPY_FDT_FROM_U_BOOT
On 28/04/2021 15:55, Somesh Deshmukh wrote:
+/* Clear .bss */
+LADDR a0, bsp_section_bss_begin
+li a1, 0
+LADDR a2, bsp_section_bss_size
+call memset
+
#ifdef BSP_START_COPY_FDT_FROM_U_BOOT
mv a0, a1
callbsp_fdt_copy
#endif
How did you test this? The above
On Wed, 28 Apr 2021 at 15:55, Somesh Deshmukh
wrote:
>
> - The current startup sequence performs the call to the bsp_fdt_copy() and
> then
> performs memset to the BSS region. In bsp_fdt_copy(), RTEMS allocates
> memory for bsp_fdt_blob into BSS region which is yet to initialize. With
> cur
looks good. someone using riscv can build/test and push, any takers?
On Wed, Apr 28, 2021 at 7:55 AM Somesh Deshmukh
wrote:
>
> - The current startup sequence performs the call to the bsp_fdt_copy() and
> then
> performs memset to the BSS region. In bsp_fdt_copy(), RTEMS allocates
> memory f
- The current startup sequence performs the call to the bsp_fdt_copy() and then
performs memset to the BSS region. In bsp_fdt_copy(), RTEMS allocates
memory for bsp_fdt_blob into BSS region which is yet to initialize. With
current startup sequence, the bsp_fdt_blob is getting erased after mem
17 matches
Mail list logo
