From: Zev Weiss <zweiss@equinix.com>
To: Hamid Amirrad <amirradh@gmail.com>
Cc: "openbmc@lists.ozlabs.org" <openbmc@lists.ozlabs.org>
Subject: Re: Changing ethernet port speed
Date: Tue, 6 Dec 2022 21:39:44 +0000 [thread overview]
Message-ID: <20221206213941.GH18848@packtop> (raw)
In-Reply-To: <CACFAz8CO7sm6TXCct35kOH-mWZOAj=UHuRisgw3rSpawRxr9jQ@mail.gmail.com>
On Tue, Dec 06, 2022 at 11:27:47AM PST, Hamid Amirrad wrote:
>Hi,
>
>I see that the u-boot has been recently upgraded to 2019.04.
>I created the image as follows:
>1. Checked out the code
>2. . setup evb-ast2500
>3. time bitbake obmc-phosphor-image
>
>Then I copied the created image (bmc-image)
>from /trunk/build/evb-ast2500/tmp/deploy/images/evb-ast2500/obmc-phosphor-image-evb-ast2500-20221122160306.static.mtd.all.tar
>to my LC having BMC module. I used ./socflash.sh to upgrade the BMC image
>to one just created. After upgrade is done, I still see the old u-boot
>version (below). Is this something else I need to do for the u-boot to be
>at revision 2019?
>
>ast# version
>
>U-Boot 2016.07 (Jun 10 2020 - 10:12:49 +0000)
>arm-openbmc-linux-gnueabi-gcc (GCC) 11.2.0
>GNU ld (GNU Binutils) 2.37.20210721
>
>I am using BMC simulator on another server and on that the u-boot revision
>is fine (below). Not sure why u-boot is not at 2019 when I compile the code
>directly.
>ast# version
>U-Boot 2019.04 (Nov 10 2022 - 00:12:58 +0000)
>
>arm-openbmc-linux-gnueabi-gcc (GCC) 12.2.0
>GNU ld (GNU Binutils) 2.39.0.20220819
>
>Any help would be greatly appreciated.
>
>Thanks,
>Hamid
>
What OpenBMC commit are you building from? It looks like evb-ast2500
got updated to the newer u-boot branch in February:
https://github.com/openbmc/openbmc/commit/7d75b9b68370374db00e9c99b5406ebb6b18512f
If the same image is showing the expected u-boot version in a simulator
(qemu?), then it sounds like maybe your installation procedure isn't
doing what you intended it to. I don't know what the 'socflash.sh' you
referred to above is; if you can boot into a reasonably healthy OpenBMC
environment, I'd suggest using the normal firmware-update mechanism. If
the existing firmware is something else or isn't working enough to boot
normally you might need to resort to a hardware flash programmer or
something (or if you can get your u-boot networking working at all, even
at a slow speed, you could TFTP in an OpenBMC kernel/initrd, boot into
that, and use flashcp to write the full OpenBMC image).
Zev
next prev parent reply other threads:[~2022-12-06 21:40 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-01 17:27 Changing ethernet port speed Hamid Amirrad
2022-12-04 6:21 ` Bruce Ferrell
2022-12-04 8:18 ` [Phishing Risk] [External] " Zhang Jian
2022-12-04 23:45 ` Zev Weiss
2022-12-06 19:27 ` Hamid Amirrad
2022-12-06 21:39 ` Zev Weiss [this message]
2022-12-07 17:53 ` Hamid Amirrad
2022-12-07 19:47 ` Hamid Amirrad
2022-12-08 14:46 ` Hamid Amirrad
2022-12-09 6:59 ` Zev Weiss
2022-12-13 17:48 ` Hamid Amirrad
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20221206213941.GH18848@packtop \
--to=zweiss@equinix.com \
--cc=amirradh@gmail.com \
--cc=openbmc@lists.ozlabs.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.