Changing ethernet port speed

[Hamid Amirrad]

Hi Zeb,

I found a default username/password (root:0penBmc). I can log in to my
newly installed image. The only thing that confuses me is that on the qemu
simulator, I have the following interface
ast#

When I type (?), it shows me all the available commands such as (version,
setenv, printenv, etc). Also no password is required to login.

With the new image that I compiled from the github and installed on my BMC
Module, I have the following interface:
root at evb-ast2500:~#

When I type (?), it doesn't work and I have a whole different available
commands (mostly from linux). Also need password to login.

Is this expected?

Thanks alot,
Hamid

On Wed, Dec 7, 2022 at 2:47 PM Hamid Amirrad <amirradh at gmail.com> wrote:

> Hi Zev,
>
> I might have installed it correctly this time (still have to confirm).
> However, I get the following, cant find any details about username
> password. where can I find it?
> evb-ast2500 login:
>
> Thanks,
> Hamid
>
> On Wed, Dec 7, 2022 at 12:53 PM Hamid Amirrad <amirradh at gmail.com> wrote:
>
>> Hi Zev,
>>
>> I am checking out the code from: https://github.com/openbmc/openbmc
>> Revision I am building from is 15231.
>>
>> sockflash.sh output is below for upgrading:
>>
>> ./socflash.sh image-bmc image-bmc
>> ASPEED SOC Flash Utility v.1.22.08
>> Warning:
>> SoCflash utility is only for engineers to update the firmware in lab,
>> it is not a commercialized software product,
>> ASPEED has not done compatibility/reliability stress test for SoCflash.
>> Please do not use this utility for any mass production purpose.
>> Press y to continue if you are agree ....
>> y
>> Find ASPEED Device 1a03:2000 on 7:0.0
>> MMIO Virtual Address: abb9000
>> Relocate IO Base: b000
>> Found ASPEED Device 1a03:2500 rev. 41
>> Static Memory Controller Information:
>> CS0 Flash Type is SPI
>> CS1 Flash Type is SPI
>> CS2 Flash Type is SPI
>> CS3 Flash Type is NOR
>> CS4 Flash Type is NOR
>> Boot CS is 0
>> Option Information:
>> CS: 0
>> Flash Type: SPI
>> [Warning] Don't AC OFF or Reboot System During BMC Firmware Update!!
>> Find Flash Chip #1: 64MB SPI Flash
>> Backup Flash Chip O.K.
>> Update Flash Chip #1 O.K.
>> Update Flash Chip O.K.
>>
>> On Tue, Dec 6, 2022 at 4:39 PM Zev Weiss <zweiss at equinix.com> wrote:
>>
>>> 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 part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20221208/3e4666a8/attachment-0001.htm>