bios(UP-CHT01 R1.7) bug? boot loop...

iohzrd
iohzrd New Member Posts: 2 ✭
edited October 2019 in UP board BIOS

I work for a company where we use a ton(hundreds...) of up boards, generally the 16GB storage, 2GB RAM variant. We use arch Linux and generally I just flash our new boards with a .img from another board. I do this because it's a lot faster than re-installing from scratch every time, in spite of having the whole process scripted.

The problem arose when trying to flash a board which is apparently from a newer batch than our previous orders, and has a nand chip which is 55MB smaller than expected.

After truncating the image and flashing it to the new board, the board doesn't boot, it just loops at the bios splash forever, not even allowing me to F7 into the menu. So far I've bricked two boards doing this so I'm trying to figure out what's wrong and what the solution is...

I don't know if this bug is related to me having truncated the image or if it's because my arch configuration is using the non-EFI Systemd-boot bootloader instead of GRUB-EFI, but I never had this issue with previous batches(UP-CHT01 R1.1) and needless to say, this is a big issue. Currently, my plan is to copy the bios from an older board and flash it onto one of the newer ones to see if this resolves the issue.

Any thoughts or ideas would be greatly appreciated...

· Share on FacebookShare on Twitter

Comments

  • DCleri
    DCleri Administrator, AAEON Posts: 1,213 admin

    You cannot use the old BIOS with the new boards, you must use R1.7 or newer which supports both old and new revisions.

    non-efi boot is not supported by the new BIOS and the only BIOS which supported legacy mode (non-EFI) was probably only the first revision, but it cannot be used.

    Also the boards cannot be bricked while flashing the eMMC, you can always reinstall the system from a USB stick.

    You have 2 options regarding the OS:
    1. from a working board, reduce the root partition using a live USB and then save the new image to be used with the new batch.
    2. install and configure the system from scratch on one of the board from the new batch and then save the new image.

    · Share on FacebookShare on Twitter
  • iohzrd
    iohzrd New Member Posts: 2 ✭

    Good to know that I can't flash back to the old BIOS, and that the new revision is EFI only, guess I'll have to come up with a plan B.

    As a test, I built an EFI arch installation on a new board to eliminate the resize/truncate step potentially being part of the problem. I imaged it and flashed it onto a brand new board and I'm still getting the behavior I described previously. The board hangs on the UP splash and then reboots after about a minute, looping endlessly and not allowing me to get into the BIOS or boot menu.

    I guess plan B for now is to just install from scratch each time and run my scripts, which isn't optimal in terms of time, but will work just fine until I get into the boot menu after flashing.

    · Share on FacebookShare on Twitter
  • DCleri
    DCleri Administrator, AAEON Posts: 1,213 admin

    we normally create system images with Clonezilla and we don't experience such problems when we restore the system, even if we use different eMMC size (of course image has to be smaller than the eMMC size).

    · Share on FacebookShare on Twitter
  • adamziek
    adamziek New Member Posts: 2 ✭

    I have exactly the same issue after trying to write an image from another board. Stuck in a boot loop , cannot enter the UEFI menu or boot from USB with F7. Did you have an resoultion? Surely the board can't have been bricked this way!

    · Share on FacebookShare on Twitter
  • Aling
    Aling Guest Posts: 561 admin

    @adamziek We suggest following wiki to clone the image.
    We have escalated the issue to Intel that cloning image from different eMMC brand might cause bricking.

    Is the board are the same PCB version? From the PCB, you will see version A0.3 or A1.1. If they are different version PCB, we don't suggest you clone the image from each other. While we change PCB version, we also change eMMC, and we notice the different eMMC could cause a brick issue.

    You may raise RMA at UP SHOP and see how our team can help you.

    · Share on FacebookShare on Twitter
  • adamziek
    adamziek New Member Posts: 2 ✭

    Thanks @Aling . Although I wish I'd seen that wiki first time around, in looking at it, I don't see what I did differently. The UpBoards themselves are identical as far as I know having ordered them as a batch. I set up one, imaged it then tried to clone to another. All are A1.1.

    I'm not an expert, but why would it be that corrupting data on the eMMC prevents being able to access the UEFI menu or boot from an alternative device in order to re-partition the eMMC. Or is the UEFI data stored on the same memory?

    Please can you provide more details on how to raise an RMA?

    Kind regards

    Adam

    · Share on FacebookShare on Twitter

Categories

Privacy Policy