Unable to use make command to build "Hello world" Program
Niteesh G. S.
niteesh.gs at gmail.com
Wed Feb 3 17:13:22 UTC 2021
Hello,
> Actually I followed this document
>
> https://docs.rtems.org/branches/master/user/start/bsp-build.html#quickstartbspbuild-manual
> to
> build bsp manually
> as mentioned in the "GSoc getting started" blog.
>
> Also yes when I run "./waf" command "Waf: Leaving directory
> `/home/rohan/devlopment/src/rtems/build/sparc/erc32'
> " this was the final output as you said.
>
> But I am actually stuck in running Hello world program
>
> https://docs.rtems.org/branches/master/user/start/gsoc.html#prove-you-can-work-on-rtems
> this
> document says to run "make" command but the folder "/build/b-erc32" is
> empty. So I was confused about how to run Hello world.
>
The document is incorrect. You have to run ./waf in the RTEMS source
directory
which should be
`/home/rohan/devlopment/src/rtems'
as per the output from waf.
Once that is done you should find your executable in
/home/rohan/devlopment/src/rtems/build/sparc/erc32/testsuites/samples
PS: I haven't tried these commands, maybe the directories differ but the
commands should be
same.
Thanks,
Niteesh.
On Wed, Feb 3, 2021 at 6:36 PM Joel Sherrill <joel at rtems.org> wrote:
>
> >
> >
> > On Wed, Feb 3, 2021, 6:43 AM Rohan kumar <krohan8870 at gmail.com> wrote:
> >
> >> Hello all,
> >> I am trying to run Hello World program but when run the command "make"
> to
> >> build, the error came "make: *** No targets specified and no makefile
> >> found. Stop". Actually there is nothing in the "/build/b-erc32" folder
> >> its just empty and
> >>
> >
> > I'm not sure what you did. The mention of b-erc32 hints at configure and
> > autotools but you mention waf. Waf leaves the results in rtems/build and
> > you run waf again.
> >
> > This seems to be mixing the old and new build infrastructure
> instructions.
> >
> > Is there something that needs more attention in the documentation as we
> > move to waf only?
> >
> >
> >
> > also there in the step "Test a BSP" I got two failures too.
> >>
> >
> > These results look pretty good. Minimum probably needs to be addressed
> > from a tester perspective and sometimes the DL tests fail as the tools
> > update.
> >
> >>
> >> "
> >> Passed: 557
> >> Failed: 2
> >> User Input: 6
> >> Expected Fail: 1
> >> Indeterminate: 0
> >> Benchmark: 3
> >> Timeout: 0
> >> Test too long: 0
> >> Invalid: 0
> >> Wrong Version: 0
> >> Wrong Build: 0
> >> Wrong Tools: 0
> >> ------------------
> >> Total: 569
> >> Failures:
> >> dl06.exe
> >> minimum.exe
> >> User Input:
> >> capture.exe
> >> dl10.exe
> >> top.exe
> >> fileio.exe
> >> termios.exe
> >> monitor.exe
> >> Expected Fail:
> >> psxfenv01.exe
> >> Benchmark:
> >> linpack.exe
> >> dhrystone.exe
> >> whetstone.exe
> >> Average test time: 0:00:00.283888
> >> Testing time : 0:02:41.532720
> >>
> >> "
> >>
> >> I am currently working on the master branch and trying to build
> >> sparc-erc32. Do I have to run the ./waf again I am not sure any
> direction
> >> will be very helpful.
> >>
> >> _______________________________________________
> >> 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/20210203/3c6c33e6/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 3
> Date: Wed, 3 Feb 2021 08:31:51 -0600
> From: Joel Sherrill <joel at rtems.org>
> To: Robin M?ller <robin.mueller.m at gmail.com>
> Cc: "rtems-devel at rtems.org" <devel at rtems.org>
> Subject: Re: [PATCH] Basic lwIP for STM32H7 BSP
> Message-ID:
> <
> CAF9ehCXZS14RXjjtYH1nUXCY3RNRYr4CSpaNctEGDagivVJgoQ at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> On Wed, Feb 3, 2021, 8:26 AM Robin M?ller <robin.mueller.m at gmail.com>
> wrote:
>
> > Also, Andrei Chichak provided a very good explanation:
> >
> > The STM32x7 ethernet controllers need their descriptors and data areas to
> >> be located on 32-byte boundaries with a combination of cache being
> turned
> >> off and buffering being turned off. This is a side effect of the STM32x7
> >> DMA and data caching.
> >>
> >> The examples that ST have for LWiP under FreeRTOS have some issues with
> >> the linker file having overlapping sections and the stack (above the ETH
> >> data areas) being left with no cache and no buffering. The space above
> the
> >> rx/tx buffers is also less than the stack space minimum specified in the
> >> linker file as well. Some rearranging of the ETH descriptors and data
> >> areas would be prudent. Like push them to the top of SRAM and locate the
> >> stack below.
> >>
> >> To get this all going, they set up the MPU for two overlapping sections,
> >> one being the top 16kB of SRAM and the other the 256B that contain the
> ETH
> >> descriptors. I believe the MPU regions can be set in increments of
> 32Bytes,
> >> so setting up the cache and buffering should be do-able without
> affecting
> >> the stack.
> >>
> >
> Just asking. Can this be a non-cacheable region and the variables not in
> special sections? I wonder if changing them to normal pointers to special
> memory would ripple. Do they just use the variables for initialization or
> reference them a lot?
>
> I think the standard linkcmds setup allows for nocache areas already.
>
> --joel
>
>
> > Kind Regards
> > Robin M?ller
> >
> > On Wed, 3 Feb 2021 at 14:50, Robin M?ller <robin.mueller.m at gmail.com>
> > wrote:
> >
> >> The following link contains more theoretical information about why these
> >> sections were placed at these addresses:
> >>
> https://community.st.com/s/article/FAQ-DMA-is-not-working-on-STM32H7-devices
> >>
> >> Kind Regards
> >> Robin
> >>
> >> On Wed, 3 Feb 2021 at 14:44, Robin M?ller <robin.mueller.m at gmail.com>
> >> wrote:
> >>
> >>> The DMA descriptors need to be placed at the start of the SRAM3 and
> need
> >>> to be aligned in a certain way. The RX buffer will take up the first
> >>> (slightly less than) 16 kB of SRAM3 but needs to be placed
> >>> behind the DMA descriptors. It also needs to be placed in a way that
> the
> >>> MPU configuration required for the DMA descriptors will not do
> something
> >>> with the RX buffers.
> >>> In the example provided by STM32, the first 256 bytes are configured by
> >>> MPU Config.
> >>>
> >>> Kind Regards
> >>> Robin
> >>>
> >>>
> >>>
> >>> On Wed, 3 Feb 2021 at 13:43, Sebastian Huber <
> >>> sebastian.huber at embedded-brains.de> wrote:
> >>>
> >>>> On 02/02/2021 20:10, Robin Mueller wrote:
> >>>>
> >>>> > + /* Not an ideal solution but required for lwIP on the STM32H7
> >>>> BSP.
> >>>> > + This places the DMA descriptors for lwIP at the start of
> SRAM3.
> >>>> > + The MPU still needs to be configured for the DMA descriptor
> >>>> regions to be
> >>>> > + bufferable, non-cacheable, non-shareable (first 256 bytes) */
> >>>> > + .lwip_sec_stm32h7 (NOLOAD) : ALIGN_WITH_INPUT {
> >>>> > + . = ABSOLUTE(0x30040000);
> >>>> > + *(.RxDecripSection)
> >>>> > + . = ABSOLUTE(0x30040060);
> >>>> > + *(.TxDecripSection)
> >>>> > + . = ABSOLUTE(0x30040200);
> >>>> > + *(.RxArraySection)
> >>>> > + } >SRAM_3 AT> REGION_TEXT_LOAD
> >>>> > +
> >>>>
> >>>> This is the wrong linker command file. This stuff should be in
> >>>>
> >>>> spec/build/bsps/arm/stm32h7/linkcmdsmemory.yml
> >>>>
> >>>> with an output section name like ".stm32h7_sram_3" and corresponding
> >>>> input section names. Why do you need absolute addresses here?
> >>>>
> >>>> --
> >>>> embedded brains GmbH
> >>>> Herr Sebastian HUBER
> >>>> Dornierstr. 4
> >>>> 82178 Puchheim
> >>>> Germany
> >>>> email: sebastian.huber at embedded-brains.de
> >>>> phone: +49-89-18 94 741 - 16
> >>>> fax: +49-89-18 94 741 - 08
> >>>>
> >>>> Registergericht: Amtsgericht M?nchen
> >>>> Registernummer: HRB 157899
> >>>> Vertretungsberechtigte Gesch?ftsf?hrer: Peter Rasmussen, Thomas
> D?rfler
> >>>> Unsere Datenschutzerkl?rung finden Sie hier:
> >>>> https://embedded-brains.de/datenschutzerklaerung/
> >>>>
> >>>> _______________________________________________
> > 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/20210203/776ec7b5/attachment.html
> >
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
>
> ------------------------------
>
> End of devel Digest, Vol 111, Issue 17
> **************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20210203/330b1105/attachment-0001.html>
More information about the devel
mailing list