How to flash the new image

[pwariche]

Hello,

I acquire an Accton Wedge-100 and wanted to upgrade OpenBMC, the build process went fine I have the following artifacts:
./u-boot-wedge100-v2016.07-r0.bin
./wedge100-image-wedge100-20170725181816.rootfs.cpio.lzma
./flash-wedge100-20170725181816
./wedge100-image-wedge100-20170725181816.rootfs.tar.gz
./modules--4.1.15-r1-wedge100-20170725181816.tgz
./wedge100-image-wedge100-20170725181816.rootfs.cpio.lzma.u-boot
./uImage--4.1.15-r1-wedge100-20170725181816.bin
./wedge100-image-wedge100-20170725181816.rootfs.manifest
./README_-_DO_NOT_DELETE_FILES_IN_THIS_DIRECTORY.txt

My current mtd scheme is like this
root@bmc:/tmp# cat /proc/mtd
dev: size erasesize name
mtd0: 00060000 00010000 "u-boot"
mtd1: 00020000 00010000 "env"
mtd2: 00200000 00010000 "kernel"
mtd3: 00c00000 00010000 "rootfs"
mtd4: 01100000 00010000 "data0"

mtd2 is too small for the new kernel
root@bmc:/tmp# flashcp -v uImage--4.1.15-r1-wedge100-20170725181816.bin /dev/mtd2
flashcp: uImage--4.1.15-r1-wedge100-20170725181816.bin bigger than /dev/mtd2

How can I proceed to flash the complete mtd to the latest release ?

Thanks in advance

/Patrick

[covracer]

We have repartitioned (changed the offsets). To handle this, we set the mtdparts= kernel command line and reboot to create a "flash0" partition, mtd5, that covers the whole chip, and flashcp the flash-wedge100-20170725181816 file to it. We've written some scripts around this which are under code review at the moment.

[sonoble]

Hello,
Has the code review finished? I am working with a few boxes that I would like to put the latest OpenBMC on.

[covracer]

Yes, the code is at https://github.com/facebook/openbmc/tree/helium/common/recipes-utils/pypartition/files. I've been creating a tarball containing check_image.py virtualcat.py partition.py system.py improve_system.py and using the following commands to upgrade:

# set new_image old_image pypartition_url image_url
cd meta-openbmc/common/recipes-utils/pypartition/files
(for image in $old_image $new_image; do ./check_image.py --checksums <(echo {}) $image 2>&1; done) | sed -nr 's/.*u-boot\) md5sum ([0-9a-f]+) not.*/\1/p' | xargs | sed 's/^/{"/; s/ /": "", /; s/$/"}/' > checksums.json
cat checksums.json | sshpass -p$password ssh root@$1 "set -x &&
    wget -qO - $pypartition_url |
    tar -mxzC /tmp &&
    cat > /tmp/checksums.json &&
    /tmp/improve_system.py --checksums /tmp/checksums.json $image_url"

In the worst case you'll have to repeat the on-target steps three times: once to remediate low memory, once to to set mtdparts, and once to make the flash take effect. In the best case only the last run is needed.

If you don't happen to have an HTTP server handy for the pypartition.tar.gz and flash-image file, I intended for the --serve option to check_image.py to be able to play that role, but I haven't used it in a while.

[sonoble]

Edit: For clarity, I am doing this on the Wedge 40.

Originally I had issues with missing python modules, which I was able to work around by putting the necessary modules in the site-packages directory. I also needed to modify the is_openbmc routine to detect both "Open BMC" and "OpenBMC".

Original:
I think I need to dig a bit more into this. The version of OpenBMC I am running currently, 201412101451, does not appear to have the right python modules available.

root@bmc:/tmp# ./improve_system.py
Traceback (most recent call last):
File "./improve_system.py", line 25, in
import logging
ImportError: No module named logging

[covracer]

My quick workaround for the /etc/issue check was to run the following before improve_system.py: sed -i 1s/Open\ BMC/OpenBMC/ /etc/issue. If you'd like to submit your patch, I'd be happy to take it. The check is mostly there to prevent accidentally calling improve_system.py from the microserver or development host.

I don't recall encountering a version without the logging module. Another workaround could be to upgrade from the old Fido branch image to the most recent Fido branch image, and then from there upgrade to Helium branch.

[sonoble]

Hi Chris,

What image file are you using? If i use my flash-wedge-20171118221005 one, it fails the magic number test "Unrecognized magic 0x27051956 at offset 0x0".

If I use the wedge-image-wedge-20171118221005.rootfs.cpio.lzma.u-boot image, I can get it to pass the magic test (ERROR:Unrecognized magic 0x27051956 at offset 0x0.) but fails due to being unable to determine partition sizes. "WARNING:Size 0xbc1f6a of 0x???????@0x0080000(kernel) greater than possibilities [0x280000, 0x400000]."

[covracer]

I'm using the flash-wedge file, which has the following concatenated contents: raw U-Boot binary, (zeroed out) firmware environment variable storage, kernel wrapped in a "legacy" U-Boot header, and root filesystem wrapped in "legacy" U-Boot header. (Some platforms are using Flattened Image Tree [FIT] for kernel and rootfs, but not Wedge 40 yet.) The reason for using the combined or full flash image is that flashing it always works, even in corner cases like bootloader upgrades and re-partitioning, whereas component or single partition upgrades can be occasionally problematic.

Also, as of this evening, the older /etc/issue contents are supported (986e81b, a6594ae).

[pwariche]

Hello,

I manage to upgrade my wedge-100 using the bmc_pusher script together with improve_system.py
But upon reboot I can see the following in the log:

2018 Jan 24 05:00:03 bmc-oob kern.warning wedge100-baf26fe: kernel: jffs2: warning: (2577) jffs2_get_inode_nodes: Eep. No valid nodes for ino #4.
2018 Jan 24 05:00:03 bmc-oob kern.warning wedge100-baf26fe: kernel: jffs2: warning: (2577) jffs2_do_read_inode_internal: no data nodes found for ino #4
2018 Jan 24 05:00:03 bmc-oob kern.warning wedge100-baf26fe: kernel: jffs2: iget() failed for ino #4
2018 Jan 24 05:00:03 bmc-oob kern.notice wedge100-baf26fe: kernel: jffs2: notice: (2577) jffs2_get_inode_nodes: Wrong magic bitmask 0x0000 in node header at 0x3e2484.
2018 Jan 24 05:00:03 bmc-oob kern.warning wedge100-baf26fe: kernel: jffs2: Node totlen on flash (0x00000000) != totlen from node ref (0x00000048)

So I guess the filesystem is corrupted somehow but still functional. was there something I did wrong ? is there a way to resolve this ?

/Patrick

[covracer]

I've run into messages like that too, but don't have a solution yet. My first thought was that I should run fsck, but apparently there's isn't one implemented for jffs2. If you have any important logs or anything, try to get them off as soon as possible. It's been a while since I was staring at the specifics, but I think the jffs2 /mnt/data filesystem is completely omitted from the flash-$platform file. If you don't have any important files on that BMC you could maybe try flash_eraseall and mount, like in the common/recipes-utils/openbmc-utils/files/mount_data0.sh script.