Re: RTEMS | Complete the u-boot support for qoriq BSP (!1046)
Sebastian Huber commented on a discussion on bsps/powerpc/qoriq/start/uboot_support.c: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1046#note_144118 > + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR > PURPOSE > + * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE > + * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR > + * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF > + * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS > + * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN > + * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) > + * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF > THE > + * POSSIBILITY OF SUCH DAMAGE. > + */ > + > +#include > + > +#include > + > +#if defined(HAS_UBOOT) The HAS_UBOOT option itself is fine, but I think using it in uboot_getenv.c() is unnecessary. You can always provide this implementation for the BSPs using it. If the environment size is zero (defined by some new BSP option), the bsp_uboot_getenv() should simply always return NULL. -- View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1046#note_144118 You're receiving this email because of your account on gitlab.rtems.org. ___ bugs mailing list [email protected] http://lists.rtems.org/mailman/listinfo/bugs
Re: RTEMS | Complete the u-boot support for qoriq BSP (!1046)
Gedare Bloom pushed new commits to merge request !1046 Merge request URL: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1046 * fd017c46...d62d6b65 - 2 commits from branch `main` * 99041bd6 - bsps/powerpc/qoriq: Add the u-boot support for powerpc/qoriq. -- View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1046 You're receiving this email because of your account on gitlab.rtems.org. ___ bugs mailing list [email protected] http://lists.rtems.org/mailman/listinfo/bugs
Re: RTEMS | Complete the u-boot support for qoriq BSP (!1046)
Ran Hong commented on a discussion on bsps/powerpc/qoriq/start/uboot_support.c: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1046#note_143556 > + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR > PURPOSE > + * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE > + * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR > + * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF > + * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS > + * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN > + * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) > + * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF > THE > + * POSSIBILITY OF SUCH DAMAGE. > + */ > + > +#include > + > +#include > + > +#if defined(HAS_UBOOT) @sebhub Yes, we do have a compiled device tree blob. I found it in our tftp server but I have no idea who got it there first. Is it OK that I keep the HAS_UBOOT define and configure uboot_environment and uboot_environment_size in BSP options? I need the HAS_UBOOT in my application code. -- View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1046#note_143556 You're receiving this email because of your account on gitlab.rtems.org. ___ bugs mailing list [email protected] http://lists.rtems.org/mailman/listinfo/bugs
Re: RTEMS | Complete the u-boot support for qoriq BSP (!1046)
Sebastian Huber commented on a discussion on bsps/powerpc/qoriq/start/uboot_support.c: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1046#note_143514 > + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR > PURPOSE > + * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE > + * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR > + * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF > + * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS > + * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN > + * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) > + * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF > THE > + * POSSIBILITY OF SUCH DAMAGE. > + */ > + > +#include > + > +#include > + > +#if defined(HAS_UBOOT) The QorIQ BSPs assume that they are booted from U-Boot (or a boot loader with the application start interface) with a proper device tree. This is also required for the libbsd network support. This is clearly documented here: https://docs.rtems.org/docs/main/user/bsps/bsps-powerpc.html#qoriq-qoriq -- View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1046#note_143514 You're receiving this email because of your account on gitlab.rtems.org. ___ bugs mailing list [email protected] http://lists.rtems.org/mailman/listinfo/bugs
Re: RTEMS | Complete the u-boot support for qoriq BSP (!1046)
Andrew Johnson commented on a discussion on bsps/powerpc/qoriq/start/uboot_support.c: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1046#note_143513 > + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR > PURPOSE > + * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE > + * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR > + * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF > + * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS > + * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN > + * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) > + * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF > THE > + * POSSIBILITY OF SUCH DAMAGE. > + */ > + > +#include > + > +#include > + > +#if defined(HAS_UBOOT) @sebhub Would you expect U-Boot on our MVME2500 boards to be providing a device tree to RTEMS? Can the QORIQ BSP look for and make use of a device tree if one is provided? Is there any RTEMS documentation on how that all works? I would much prefer that we make use of a device tree if U-Boot can provide one and RTEMS can use it, but we didn't know anything about that when we started work on the BSP. Reading its environment variables was a solution we came up with to pass device configuration from U-Boot into the RTEMS image it loads from the network. If you have better suggestions we would sincerely appreciate your advice. We want RTEMS to be able to reuse some of the configuration parameters that we have to set for U-Boot to load the OS image — mainly network settings, but passing a boot-line to our application would be useful too. -- View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1046#note_143513 You're receiving this email because of your account on gitlab.rtems.org. ___ bugs mailing list [email protected] http://lists.rtems.org/mailman/listinfo/bugs
Re: RTEMS | Complete the u-boot support for qoriq BSP (!1046)
Sebastian Huber commented on a discussion on bsps/powerpc/qoriq/start/uboot_support.c: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1046#note_143509 > + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR > PURPOSE > + * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE > + * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR > + * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF > + * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS > + * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN > + * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) > + * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF > THE > + * POSSIBILITY OF SUCH DAMAGE. > + */ > + > +#include > + > +#include > + > +#if defined(HAS_UBOOT) The uboot_getenv.c is currently only used by two BSP families: gen5200 and gen83xx. Both BSPs are maintained by us. I will review and test the changes. The usage of the U-Boot environment is not that common. The usual way is using the device tree provided by U-Boot. -- View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1046#note_143509 You're receiving this email because of your account on gitlab.rtems.org. ___ bugs mailing list [email protected] http://lists.rtems.org/mailman/listinfo/bugs
Re: RTEMS | Complete the u-boot support for qoriq BSP (!1046)
Ran Hong commented on a discussion on bsps/powerpc/qoriq/start/uboot_support.c: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1046#note_143492 > + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR > PURPOSE > + * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE > + * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR > + * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF > + * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS > + * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN > + * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) > + * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF > THE > + * POSSIBILITY OF SUCH DAMAGE. > + */ > + > +#include > + > +#include > + > +#if defined(HAS_UBOOT) Removing HAS_UBOOT sounds dangerous to me. Many application developers may use it in their application codes to decide how to obtain the environment variables. I did it in my application code. Making changes to other BSPs is also beyond the scope of this merge request I made for. I don't have other boards to test if the new way of getting uboot_environment and uboot_environment_size works, and whether it is compatible with other users' existing code. -- View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1046#note_143492 You're receiving this email because of your account on gitlab.rtems.org. ___ bugs mailing list [email protected] http://lists.rtems.org/mailman/listinfo/bugs
Re: RTEMS | Complete the u-boot support for qoriq BSP (!1046)
Sebastian Huber started a new discussion on bsps/powerpc/qoriq/start/uboot_support.c: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1046#note_143481 > + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR > PURPOSE > + * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE > + * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR > + * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF > + * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS > + * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN > + * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) > + * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF > THE > + * POSSIBILITY OF SUCH DAMAGE. > + */ > + > +#include > + > +#include > + > +#if defined(HAS_UBOOT) I would do it like this: The usage HAVE_UBOOT define should be removed from uboot_getenv.c. The uboot_support.c should be removed for all BSPs. Definitions of uboot_environment and uboot_environment_size should move to uboot_getenv.c with values provided by two new BSP options shared by the powerpc BSPs. If these options are not defined, then both should be 0 initialized, so that bsp_uboot_getenv() always returns NULL. -- View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1046#note_143481 You're receiving this email because of your account on gitlab.rtems.org. ___ bugs mailing list [email protected] http://lists.rtems.org/mailman/listinfo/bugs
Re: RTEMS | Complete the u-boot support for qoriq BSP (!1046)
Ran Hong commented on a discussion: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1046#note_143437 I think the flash is on the SPI bus. -- View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1046#note_143437 You're receiving this email because of your account on gitlab.rtems.org. ___ bugs mailing list [email protected] http://lists.rtems.org/mailman/listinfo/bugs
Re: RTEMS | Complete the u-boot support for qoriq BSP (!1046)
Andrew Johnson commented on a discussion: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1046#note_143436 IIRC the U-boot environment values are stored on a Flash device, not in main memory or on the boot flash, but I forget whether it was on an I2C bus or somewhere else. When I was working on our VxWorks BSP for the MVME2500 I remember reading that out and seeing the variable names and values. I think it held a checksum of some kind at the beginning, maybe in the first 2 bytes. -- View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1046#note_143436 You're receiving this email because of your account on gitlab.rtems.org. ___ bugs mailing list [email protected] http://lists.rtems.org/mailman/listinfo/bugs
Re: RTEMS | Complete the u-boot support for qoriq BSP (!1046)
Gedare Bloom pushed new commits to merge request !1046 Merge request URL: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1046 * 5e9f94de...e4a02bc2 - 2 commits from branch `main` * 1cc16a98 - bsps/powerpc/qoriq: Add the u-boot support for powerpc/qoriq. -- View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1046 You're receiving this email because of your account on gitlab.rtems.org. ___ bugs mailing list [email protected] http://lists.rtems.org/mailman/listinfo/bugs
Re: RTEMS | Complete the u-boot support for qoriq BSP (!1046)
Ran Hong commented on a discussion: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1046#note_143418 Yes. I unprotect the main branch, and I also rebased the branch. -- View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1046#note_143418 You're receiving this email because of your account on gitlab.rtems.org. ___ bugs mailing list [email protected] http://lists.rtems.org/mailman/listinfo/bugs
Re: RTEMS | Complete the u-boot support for qoriq BSP (!1046)
Ran Hong commented on a discussion: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1046#note_143414 Hi Sebastian, I just checked the dts file I have for mvme2500, and it does not have the u-boot environment address. -- View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1046#note_143414 You're receiving this email because of your account on gitlab.rtems.org. ___ bugs mailing list [email protected] http://lists.rtems.org/mailman/listinfo/bugs
Re: RTEMS | Complete the u-boot support for qoriq BSP (!1046)
Ran Hong pushed new commits to merge request !1046 Merge request URL: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1046 * 03a2e44c...01f88b05 - 2 commits from branch `main` * b34c2eba - bsps/powerpc/qoriq: Add the u-boot support for powerpc/qoriq. -- View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1046 You're receiving this email because of your account on gitlab.rtems.org. ___ bugs mailing list [email protected] http://lists.rtems.org/mailman/listinfo/bugs
Re: RTEMS | Complete the u-boot support for qoriq BSP (!1046)
Merge request https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1046 was reviewed by Sebastian Huber -- Sebastian Huber commented on a discussion: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1046#note_143386 Thanks for the information. How is this related to the device tree provided by U-Boot? Is the presence and location of the U-Boot environment provided by the device tree? -- View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1046 You're receiving this email because of your account on gitlab.rtems.org. ___ bugs mailing list [email protected] http://lists.rtems.org/mailman/listinfo/bugs
Re: RTEMS | Complete the u-boot support for qoriq BSP (!1046)
Andrew Johnson commented: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1046#note_143385 The MVME2500 VME CPU board is a QORIQ (e500) that has a U-Boot ROM for booting. There are 2 models, with a P2010 and P2020 CPU. We have about 25 of the P2010 model that we currently run VxWorks on. -- View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1046#note_143385 You're receiving this email because of your account on gitlab.rtems.org. ___ bugs mailing list [email protected] http://lists.rtems.org/mailman/listinfo/bugs
Re: RTEMS | Complete the u-boot support for qoriq BSP (!1046)
Sebastian Huber commented: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1046#note_143383 I worked a bit with the QorIQ BSPs and never used the U-Boot environment. For what is this used? -- View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1046#note_143383 You're receiving this email because of your account on gitlab.rtems.org. ___ bugs mailing list [email protected] http://lists.rtems.org/mailman/listinfo/bugs
Re: RTEMS | Complete the u-boot support for qoriq BSP (!1046)
Gedare Bloom started a new discussion: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1046#note_143362 Because you opened this from your `main` branch, we cannot rebase it. You should either "unprotect" your `main` branch, or recreate this MR on a different branch in your fork. -- View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1046#note_143362 You're receiving this email because of your account on gitlab.rtems.org. ___ bugs mailing list [email protected] http://lists.rtems.org/mailman/listinfo/bugs
Re: RTEMS | Complete the u-boot support for qoriq BSP (!1046)
Ran Hong commented on a discussion: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1046#note_142648 Just did it. -- View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1046#note_142648 You're receiving this email because of your account on gitlab.rtems.org. ___ bugs mailing list [email protected] http://lists.rtems.org/mailman/listinfo/bugs
Re: RTEMS | Complete the u-boot support for qoriq BSP (!1046)
Ran Hong pushed new commits to merge request !1046 Merge request URL: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1046 * 0b724e3b - bsps/powerpc/qoriq: Add the u-boot support for powerpc/qoriq. -- View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1046 You're receiving this email because of your account on gitlab.rtems.org. ___ bugs mailing list [email protected] http://lists.rtems.org/mailman/listinfo/bugs
Re: RTEMS | Complete the u-boot support for qoriq BSP (!1046)
Ran Hong pushed new commits to merge request !1046 Merge request URL: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1046 * 6238a211...9ff62c34 - 2 commits from branch `main` * 3259a1b2 - Merge branch rtems:main into main -- View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1046 You're receiving this email because of your account on gitlab.rtems.org. ___ bugs mailing list [email protected] http://lists.rtems.org/mailman/listinfo/bugs
Re: RTEMS | Complete the u-boot support for qoriq BSP (!1046)
Ran Hong commented on a discussion: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1046#note_142632 In the u-boot command line interface, I export the environment to the MRAM. For mvme2500, the u-boot environment is stored in the SPI-flash and it is loaded to the SDRAM after powering up. I don't know if it always save the environment at the same SDRAM address every time. I will document this for APS: when saving the environment in the u-boot commandline (to SPI Flash), also export it to MRAM. -- View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1046#note_142632 You're receiving this email because of your account on gitlab.rtems.org. ___ bugs mailing list [email protected] http://lists.rtems.org/mailman/listinfo/bugs
Re: RTEMS | Complete the u-boot support for qoriq BSP (!1046)
Ran Hong commented on a discussion on bsps/powerpc/qoriq/start/uboot_support.c: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1046#note_142631 > + > +#include > + > +#include > + > +#if defined(HAS_UBOOT) > +/* Base address of U-Boot environment variables > + * The default base address 0xfff0 is the starting address of the MRAM > + * of board mvme2500 according to its manual. MRAM is a type of nonvolatile > + * memory. > + * > + * For other qoriq boards, users should update the base address accordingly. > + * User should export the U-Boot environment to this base address in U-Boot > + * terminal before accessing it in RTEMS. > + */ > +const uint8_t *uboot_environment = (const uint8_t *) 0xfff0; Does it need more link flag changes or other changes in the build configuration? If so, I worry that it may confuse new users. -- View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1046#note_142631 You're receiving this email because of your account on gitlab.rtems.org. ___ bugs mailing list [email protected] http://lists.rtems.org/mailman/listinfo/bugs
Re: RTEMS | Complete the u-boot support for qoriq BSP (!1046)
Andrew Johnson commented: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1046#note_142596 @hongran86 How did you configure U-Boot on the MVME2500 to copy its environment to the MRAM? IIRC there is no in-memory copy of the environment variable values while U-Boot is running, and U-Boot doesn't store them in the MRAM by default. I remember finding them in an i2c Flash EPROM when working with this board a few years back. If you added commands to move or copy them to the MRAM as part of the boot process that should be documented somewhere. -- View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1046#note_142596 You're receiving this email because of your account on gitlab.rtems.org. ___ bugs mailing list [email protected] http://lists.rtems.org/mailman/listinfo/bugs
Re: RTEMS | Complete the u-boot support for qoriq BSP (!1046)
Gedare Bloom started a new discussion on bsps/powerpc/qoriq/start/uboot_support.c: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1046#note_142513 > + > +#include > + > +#include > + > +#if defined(HAS_UBOOT) > +/* Base address of U-Boot environment variables > + * The default base address 0xfff0 is the starting address of the MRAM > + * of board mvme2500 according to its manual. MRAM is a type of nonvolatile > + * memory. > + * > + * For other qoriq boards, users should update the base address accordingly. > + * User should export the U-Boot environment to this base address in U-Boot > + * terminal before accessing it in RTEMS. > + */ > +const uint8_t *uboot_environment = (const uint8_t *) 0xfff0; Can we get this from a linkcmds variable, or add a linkcmds variable for it? -- View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1046#note_142513 You're receiving this email because of your account on gitlab.rtems.org. ___ bugs mailing list [email protected] http://lists.rtems.org/mailman/listinfo/bugs
Re: RTEMS | Complete the u-boot support for qoriq BSP (!1046)
Gedare Bloom commented on a discussion: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1046#note_142494 Add "Closes #5439" to your commit message and re-push it. -- View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1046#note_142494 You're receiving this email because of your account on gitlab.rtems.org. ___ bugs mailing list [email protected] http://lists.rtems.org/mailman/listinfo/bugs
Re: RTEMS | Complete the u-boot support for qoriq BSP (!1046)
Ran Hong commented: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1046#note_141917 The related issue is #5439 (https://gitlab.rtems.org/rtems/rtos/rtems/-/issues/5439). I am not sure how to link them together. -- View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1046#note_141917 You're receiving this email because of your account on gitlab.rtems.org. ___ bugs mailing list [email protected] http://lists.rtems.org/mailman/listinfo/bugs
