Announcement

Collapse
No announcement yet.

Restoring OpenRex U-Boot problem

Collapse
X
Collapse
 
  • Page of 1
  • Time
  • Show
Clear All
new posts
Previous template Next
  • #1

    Restoring OpenRex U-Boot problem

    Hello forum.

    I have received the OpenRex board from Voipac and enjoyed the 10hrs course from Robert.

    The TFTP and MFGTOOL methods are verified as well as the cross-compile of u-boot and Linux in both make and Yocto environment.
    At first, I did not update the SPI FLASH u-boot, but used the "undocumented feature" to force booting of the SD-Card.

    While studying the differences between the lectured u-boot v2015.10 at Fedevel and the one from Voipac I finally decided to flash the u-boot 2015.10 version.
    The first updates went well.
    However, as I was changing the upd_uboot environmental several times, the OpenRex serial terminal suddenly became unresponsive.
    Reset/repower, terminal loop-back test finally confirmed that the OpenRex u-boot was corrupted.

    I then reloaded the u-boot by means of MFGTOOLS as described here:

    How to uBoot - Compile, Flash, Update, Boot - iMX6 Rex Projects
    http://www.imx6rex.com/open-rex/software/how-to-uboot-compile-flash-update-boot/#run_u_boot_empty_board
    Content Get and compile the latest uBoot Run uBoot on an empty board Flash uBoot for the very first time into a fresh board Programming eFuses on very fresh


    The u-boot started, but when I loaded the environmentals for my site and tried to re-flash the U-Boot, I had no success.
    Of some reason I can't use the update_spi_boot as the set_ethernet overrides the ipaddr:
    OpenRex U-Boot> printenv ipaddr
    ipaddr=192.168.1.150
    OpenRex U-Boot> printenv serverip
    serverip=192.168.1.50
    OpenRex U-Boot> run set_ethernet
    OpenRex U-Boot> printenv ipaddr
    ipaddr=192.168.0.150
    OpenRex U-Boot> printenv serverip
    serverip=192.168.1.50
    OpenRex U-Boot>

    Running the manual u-boot upgrade as shown below fails with a SPI timeout message.
    Something seem corrupted, but i can't figure out what.
    The problem is shown below and I cannot find a corresponding problem (with relevant situation) described on the web.

    Please advice.

    Best regards
    Terje

    u-boot scenario, failing to update SPI-FLASH:

    setenv netdev eth0
    setenv ethprime FEC
    setenv ethact FEC
    setenv ethaddr 00:0D:15:001:75
    setenv fec_addr 00:0D:15:001:75
    setenv ipaddr 192.168.1.150
    setenv serverip 192.168.1.50
    setenv gatewayip 192.168.1.1

    OpenRex U-Boot> mw.b 0x10800000 0xFF 0x80000;tftp 0x10800000 imx6/u-boot-imx6q-openrex.imx;sf probe 3:2;sf erase 0x0 0x80000;sf write 0x10800000 0x0 0x80000
    Using FEC device
    TFTP from server 192.168.1.50; our IP address is 192.168.1.150
    Filename 'imx6/u-boot-imx6q-openrex.imx'.
    Load address: 0x10800000
    Loading: #T ####################T #####T ########################################
    ######T #######T ##
    13.7 KiB/s
    done
    Bytes transferred = 400384 (61c00 hex)
    spi_xchg_single: Timeout!
    SF: Failed to get idcodes
    Failed to initialize SPI flash at 3:2
    No SPI flash selected. Please run `sf probe'
    No SPI flash selected. Please run `sf probe'
    OpenRex U-Boot>
    OpenRex U-Boot> sf probe
    SF: Detected SST26VF032B with page size 256 Bytes, erase size 4 KiB, total 4 MiB
    OpenRex U-Boot> sf probe 1
    SF: Detected SST26VF032B with page size 256 Bytes, erase size 4 KiB, total 4 MiB
    OpenRex U-Boot>
    Tags: None
    • #2
      As the last line of my previous post indicates, there is something strange about the sf probe.
      In the Fedevel OpenRex update recipe the command "sf probe 3:2" is used.
      Somehow, this doesn't work.
      When I change the line to "sf probe 2:2" (or just "sf probe") things start to happen:
      OpenRex U-Boot > setenv netdev eth0
      OpenRex U-Boot > setenv ethprime FEC
      OpenRex U-Boot > setenv ethact FEC
      OpenRex U-Boot > setenv ethaddr 00:0D:15:001:75
      OpenRex U-Boot > setenv fec_addr 00:0D:15:001:75
      OpenRex U-Boot > setenv ipaddr 192.168.1.150
      OpenRex U-Boot > setenv serverip 192.168.1.50
      OpenRex U-Boot > setenv gatewayip 192.168.1.1
      OpenRex U-Boot > mw.b 0x10800000 0xFF 0x80000;tftp 0x10800000 imx6/u-boot-imx6-openrexultra-2v4.imx;sf probe 2:2;sf erase 0x0 0x80000;sf write 0x10800000 0x0 0x80000
      Using FEC device
      TFTP from server 192.168.1.50; our IP address is 192.168.1.150
      Filename 'imx6/u-boot-imx6-openrexultra-2v4.imx'.
      Load address: 0x10800000
      Loading: ################################################## ###############
      ##
      217.8 KiB/s
      done
      Bytes transferred = 342064 (53830 hex)
      SF: Detected SST26VF032B with page size 256 Bytes, erase size 4 KiB, total 4 MiB
      SF: 524288 bytes @ 0x0 Erased: OK
      SF: 524288 bytes @ 0x0 Written: OK
      OpenRex U-Boot >

      Now it all seem OK.....
      But when I remove the MFGTOOLS and repower the board, u-boot does not start.

      Seems like the iMX6 doesn't read its SPI FLASH anymore.

      Please advice.

      Best regards
      Terje

        Comment

        • #3
          Hm..
          After the u-boot stopped working, the first time I tried the MFGTOOLS, I just forgot to insert the JP2.
          Although not touching the fuses, could this drop-of-the-mind destroy the fuse-settings for the boot?

          After all, the u-boot stopped working after an ordinary change of the upd_uboot environmental parameter.

          Best regards
          Terje

            Comment

            • #4
              After some digging, I found that the fuses can be read by the "fuse read" command, and not the missing (but lectured) imxotp (read) command.
              The fuses are not changed compared to the required settings: OpenRex U-Boot > fuse read 0 5
              Reading bank 0:
              Word 0x00000005: 2a000030
              OpenRex U-Boot > fuse read 0 6
              Reading bank 0:
              Word 0x00000006: 00000010

              Well, the board still doesn't boot.
              Is there any plausible reason for this problem?

              Best regards
              Terje

                Comment

                • #5
                  Inspecting the u-boot versions 2015.10 and 2015.4 I discovered differences in the "include/configs" files where the 2015.4 had a corrected test for presence of ipaddr.
                  Compiling, MFGTOOL upload and flashing did the trick!
                  Now I have a running u-boot again "despite a long and winding road".

                  T
                  here are inkonsistensenes between the Fedevl and Voipac recipes.
                  For two weeks I studied the Fedevel recipes and videos.
                  So, when finally receiving the OpenRex from Voipac, I consequently used the Fedevl recipes.
                  Differences Fedevel/Voipac:
                  "run bootmmc" is changed to "run mmcboot"
                  "run bootnet" is changed to "run netboot"
                  "sf probe 3:2" is changed to "sf probe 2:2", but preferably only "sf probe"

                  Think I can conclude with "case closed".

                  Best regards
                  Trrje

                    Comment

                    • #6
                      terje, there are many differences between uBoots - they may not be compatible, what works in one may not work in the other one (especially if you are using custom env definitions).

                      Also, if you are changing uBoots, you may need to reset the env variables which are stored in the SPI memory. I think it is done by "env default -a" command. This can be useful (search for Reflash uBoot): http://www.imx6rex.com/open-rex/soft...er/#edit_uboot

                        Comment

                        Previous template Next
                        Working...
                        X
                        😀
                        🥰
                        🤢
                        😎
                        😡
                        👍
                        👎