Problem flashing on a Miracelbox MBtwin

[original-birdman]

I'm trying to (couch) flash a build of the Python3 build of OpenVix. The image build has completed OK and I have this:

[mbtwin]: unzip -l openvix-5.5.015.005.developer-mbtwin_usb.zip
Archive:  openvix-5.5.015.005.developer-mbtwin_usb.zip
  Length      Date    Time    Name
---------  ---------- -----   ----
       33  09-27-2021 19:47   miraclebox/twin/imageversion
  4304784  09-27-2021 19:47   miraclebox/twin/kernel.bin
       66  09-27-2021 19:47   miraclebox/twin/noforce
102105088  09-27-2021 19:47   miraclebox/twin/rootfs.bin
  1244214  09-27-2021 19:47   miraclebox/twin/splash.bin
 --------                     -------
107654185                     5 files

but when I try to couch flash this ofgwrite starts up, then the screen goes blank and nothing further happens.

The syslog is reporting (lots of) this error:

Sep 27 23:59:43 mbtwin user.warn kernel: !!!Error BERR_OS_ERROR(0x6) at /home/peteru/Source/T3/inihdx/device/refsw_release_97405_20110228/nexus/../magnum/basemodules/kni/linuxkernel/bkni.c:622

If I reboot the box at this point it boots back to the previous image (indicating that no flashing took place at all?)

If I take a full image backup of the current (Python2-based) system and couch flash that all is OK. That image is:

[mbtwin]: unzip -l myimage-developer-5.4.015.006-20210927_234440.zip
Archive:  myimage-developer-5.4.015.006-20210927_234440.zip
  Length      Date    Time    Name
---------  ---------- -----   ----
        0  09-27-2021 23:44   miraclebox/
        0  09-27-2021 23:52   miraclebox/twin/
  6291456  09-27-2021 23:44   miraclebox/twin/kernel.bin
119537664  09-27-2021 23:52   miraclebox/twin/rootfs.bin
       55  09-27-2021 23:52   miraclebox/twin/imageversion
       67  09-27-2021 23:52   miraclebox/twin/noforce
 --------                     -------
125829242                     6 files

so it doesn't look as though it's an image size issue (as this one is larger)

Any ideas as to what the problem actually is?

[original-birdman]

Hmmmmm.....I can (now) see an oddity in the Py3 image build.

The kernel.bin is not a multiple of 512. Could this be an issue???

[betacentauri]

Is the ofgwrite “GUI” visible on the TV screen?

You could try doing this:

1. Login via telnet. Execute this: tail -f /var/log/messages Then start flashing via ofgwrite. Post log from Telnet window.
2. Try to flash the image via USB. Does this work?

[Huevos]

Sep 27 23:59:43 mbtwin user.warn kernel: !!!Error BERR_OS_ERROR(0x6) at /home/peteru/Source/T3/inihdx/device/refsw_release_97405_20110228/nexus/../magnum/basemodules/kni/linuxkernel/bkni.c:622

What is that?Looks like it belongs to a Beyonwiz T3.

[original-birdman]

The GUI starts up, the first "block" is filled in on the top progress bar - then the screen goes blank.

At this point it is looping and filling the messages log with that error message.

The command being run is:

root      1245     1 10 Sep27 ?        00:00:18 /newroot/ofgwrite_bin -r -k /media/usb/imagebackups/imagerestore/miraclebox/twin

[original-birdman]

What is that?Looks like it belongs to a Beyonwiz T3.

It's a Miraclebox MBTwin. Which, IIRC, is very similar.

[betacentauri]

Can you please execute this in Telnet: ofgwrite -n -r -k /media/usb/imagebackups/imagerestore/miraclebox/twin (Edit: This is one line)

This won’t flash your box (because of -n switch), but it maybe shows the problem. Please post the output.

[original-birdman]

That finds nothing wrong...

[mbtwin]: ofgwrite -n -r -k /media/usb/imagebackups/imagerestore/miraclebox/twin 

ofgwrite Utility v4.5.6
Author: Betacentauri
Based upon: mtd-utils-native-1.5.1 and busybox 1.24.1
Use at your own risk! Make always a backup before use!
Don't use it if you use multiple ubi volumes in ubi layer!

Flashing rootfs
Flashing kernel
Searching image files in /media/usb/imagebackups/imagerestore/miraclebox/twin resolved to /media/usb/imagebackups/imagerestore/miraclebox/twin
Found kernel file: /media/usb/imagebackups/imagerestore/miraclebox/twin/kernel.bin
Found rootfs file: /media/usb/imagebackups/imagerestore/miraclebox/twin/rootfs.bin
Found UBIFS rootfs
Found mounted /newroot
Found mountpoint for rootfs file: /media/usb

Found /proc/mtd entries:
Device:   Size:     Erasesize:  Name:                   Image:
mtd0:     1ff00000  00020000    "complete"        
mtd1:     00600000  00020000    "kernel"            ->  /media/usb/imagebackups/imagerestore/miraclebox/twin/kernel.bin
mtd2:     1f900000  00020000    "rootfs"            ->  /media/usb/imagebackups/imagerestore/miraclebox/twin/rootfs.bin
mtd3:     00080000  00010000    "cfe"             
mtd4:     00200000  00010000    "splash"          
mtd5:     00080000  00010000    "macadr"          
mtd6:     00080000  00010000    "nvram"           
mtd7:     00040000  00010000    "bootconfig"      
mtd8:     00040000  00010000    "facconfig"       
Using kernel mtd device: /dev/mtd1
Using rootfs mtd device: /dev/mtd2

Syncing filesystem
Flashing kernel ...
Found NAND flash
Erasing kernel: flash_erase /dev/mtd1 0 0
Flashing kernel: nandwrite -pm /dev/mtd1 /media/usb/imagebackups/imagerestore/miraclebox/twin/kernel.bin
Successfully flashed kernel!
Found NAND flash
Flashing rootfs: ubiformat /dev/mtd2 -f /media/usb/imagebackups/imagerestore/miraclebox/twin/rootfs.bin
Successfully flashed rootfs! Rebooting in 3 seconds...

[Huevos]

What is that? Looks like it belongs to a Beyonwiz T3.

It's a Miraclebox MBTwin. Which, IIRC, is very similar.

"peteru" is a Beyonwiz developer and "T3" is a Beyonwiz model so no clue what that is doing in mbtwin build.

[original-birdman]

Similar paths are mentioned through the dvb.ko file. Possibly he was involved in compiling it (10 years ago)?

Anyway, it's the same file that gets used when successfully flashing my Py2-Vix made backup.

[betacentauri]

Please flash the image via USB to confirm that it works.

Do you have a serial cable for the box?

[original-birdman]

Please flash the image via USB to confirm that it works.

It does. Slow, but it gets there and then I can boot into the Py3 version of OpenVix.

Do you have a serial cable for the box?

No.

[betacentauri]

And if you first stop e2 and then flash from telnet? So first: init 4 And then same command like above, but this time without the -n.

[original-birdman]

I actually tried a reflash of the image (from my now-running Py3 Vix) and that also failed (screen blanked shortly after the "start"). When I manually reran the command it produced:

[mbtwin]: /newroot/ofgwrite_bin -r -k /media/usb/imagebackups/imagerestore/miraclebox/twin

ofgwrite Utility v4.5.6
Author: Betacentauri
Based upon: mtd-utils-native-1.5.1 and busybox 1.24.1
Use at your own risk! Make always a backup before use!
Don't use it if you use multiple ubi volumes in ubi layer!

Flashing rootfs
Flashing kernel
Searching image files in /media/usb/imagebackups/imagerestore/miraclebox/twin resolved to /media/usb/imagebackups/imagerestore/miraclebox/twin
Found kernel file: /media/usb/imagebackups/imagerestore/miraclebox/twin/kernel.bin
Found rootfs file: /media/usb/imagebackups/imagerestore/miraclebox/twin/rootfs.bin
Found UBIFS rootfs
Found mounted /newroot
Found mountpoint for rootfs file: /media/usb

Found /proc/mtd entries:
Device:   Size:     Erasesize:  Name:                   Image:
mtd0:     1ff00000  00020000    "complete"        
mtd1:     00600000  00020000    "kernel"            ->  /media/usb/imagebackups/imagerestore/miraclebox/twin/kernel.bin
mtd2:     1f900000  00020000    "rootfs"            ->  /media/usb/imagebackups/imagerestore/miraclebox/twin/rootfs.bin
mtd3:     00080000  00010000    "cfe"             
mtd4:     00200000  00010000    "splash"          
mtd5:     00080000  00010000    "macadr"          
mtd6:     00080000  00010000    "nvram"           
mtd7:     00040000  00010000    "bootconfig"      
mtd8:     00040000  00010000    "facconfig"       
Using kernel mtd device: /dev/mtd1
Using rootfs mtd device: /dev/mtd2

^C^C^C

That ^C^C^C is me trying to get out of it, but it's hung (looping in the kernel).

Again, it hadn't actually flashed anything, as a power off/on brought back my Py3 Vix.

However, one further wrinkle. I created an image backup of my Vix Py3 installation. This one couch flashes fine (and takes me back to where I was...).

So it seems to be something specific to that one image file(?).

[original-birdman]

So, a quick recap.

openvix-5.5.015.005.developer-mbtwin_usb.zip An image file produced by the Vix build process. This can be USB flashed, but cannot be flashed using ofgwrite in either 5.4.014.006 (Py2) or 5.5.015.005 (Py3)

myimage-developer-5.5.015.005-20210929_192243.zip An image file created by the ImageManager on the running 5.5.015.005 (Py3) system. This can be flashed by ofgwrite on my running 5.5.015.005 (Py3). EDIT: But has since FAILED on a bare install of 5.5.015.005 (Py3) after a USB flash an no restore of my settings/plugins.

[original-birdman]

And I've found out what the problem is!!!

The build process produces an image file that contains splash.bin, but the backup process does not. And if I unpack the build image, remove splash.bin and rezip it, then ofgwrite is happy with it.

So the problem is related to the splash.bin.

Now, I do remember some time (years?) ago that the original OpenVix start-up splash banner went away and was replaced by a plain miraclebox one. Perhaps there is something wrong with the box that means the splash "location" is now non-writable?

[betacentauri]

Ofgwrite don’t use splash.bin. And it don’t unzip the image zip. That does e2.

I still don’t understand how this can cause problems…

[betacentauri]

According to the log it might hang while opening the framebuffer. Is not 100% sure but this is one of the steps after the last log message. In the other open issue here from technic he also has problems with the framebuffer. I don’t understand why this happens. These kind of errors were not present in the last months/years…

[original-birdman]

OK. Having got the system to flash without the splash.bin I was left with a bare system. So I tried couch flashing my Py3 backup (which had worked earlier this evening). That failed this time. So there seems to be something odd and random going on?