Chromebook SMB circuit board replacement causes firmware Issue

[Michael]

Hi all,

Excuse me if this is not the correct forum for this post!

I am the technical support liaison at a middle school. I replaced the motherboards in a couple of out-of-warranty HP Chromebooks. When powered on, the devices default to the "Chrome OS is missing or damaged." screen with the error  gbb.flags is nonzero, etc screen. I have tried reinstalling the OS but it returns to this screen. 

I cannot access CROSH (or anything else). I used the recovery utility to try to reinstall the OS, but that did not work either. I think that the CB is is set somehow so that it cannot update its firmware and that is preventing it from moving forward. 

Any thoughts?

Michael

[Vincent Palatin]

Not sure where you found the replacement motherboards but they haven't been 'finalized' (that's the last step of the factory process where the parameters are written/verified and the write-protection enabled) but it is likely also badly signed? else I think it would boot the image once you have done the recovery process. (but it's the proper firmware version as far as I can tell)

with the flags 0x039, if you had a normal image on a USB stick(not a recovery one) for this machine,

- at this screen, pressing ctrl+U to boot this image

- go to the terminal (ctrl+alt+f2)

- flash a proper firmware: chromeos-firmwareupdate --mode=factory

- clear the gbb flags: /usr/share/vboot/bin/set_gbb_flags.sh 0

but as far as I know, we are not distributing those images.

[Bernie Thompson]

That GBB of 0x39 means the device is in an early factory state, this setting means it is effectively locked into developer mode. The system expects to go through a factory process that includes clearing of this flag, setting the serial number, and doing a variety of tests. Note that the process of preparing a device for normal use at this point is not trivial, and requires some command line work. 

I think you can get it into a better state by something like:

1. Check that the WP screw is removed, we need this out to rewrite the firmware.

2. Grab a recovery drive and plug it in, when you power on the device press ctrl+u to boot from it, this bypasses any signing checks (this requires dev mode). 

3. This recovery process should complete with success, and then it should boot into the OS correctly into developer mode, if not we need to debug why (may need to grab logs from the recovery drive). 

4. Now we may need to run a few commands, you can use ctrl+alt+F2 or ctrl+alt+t and then `shell` then `sudo bash` to get to a bash terminal, password should be test0000 if it asks, two things you may want to do here:

4.a. Set the serial number, you can check what it thinks the serial_number is with `vpd -l`, if this returns nothing then we need to set the expected serial number, if your devices need to be enterprise enrolled this is critical. You can set vpd values with `vpd -i RO_VPD -s "serial_number"="YOUR_SERIAL_NUMBER"`. 

4.b. Remove the GBB flags, this will allow the device to go back into normal mode. This involves reading the firmware, clearing the flags, and writing it back. The commands look like:
flashrom -p host -r /tmp/image.bin

gbb_utility --set --flags=0 /tmp/image.bin

flashrom -p host -w /tmp/image.bin 

5. With the serial number in place and the GBB flags cleared, you can reboot the device, convert it back to dev mode (spacebar) and then go ahead with enrollment.

-Bernie

On Tue, Mar 21, 2017 at 9:30 AM, Bernie Thompson <bhtho...@google.com> wrote:

That GBB of 0x39 means the device is in an early factory state, this setting means it is effectively locked into developer mode. The system expects to go through a factory process that includes clearing of this flag, setting the serial number, and doing a variety of tests. Note that the process of preparing a device for normal use at this point is not trivial, and requires some command line work, though as these are out of warranty there is not much to loose here.

I think you can get it into a better state by something like:

1. Check that the WP screw is removed, we need this out to rewrite the firmware.

2. Grab a recovery drive and plug it in, when you power on the device press ctrl+u to boot from it, this bypasses any signing checks (this requires dev mode). 

3. This recovery process should complete with success, and then it should boot into the OS correctly into developer mode, if not we need to debug why (may need to grab logs from the recovery drive). 

4. Now we may need to run a few commands, you can use ctrl+alt+F2 or ctrl+alt+t and then `shell` then `sudo bash` to get to a bash terminal, password should be test0000 if it asks, two things you may want to do here:

4.a. Set the serial number, you can check what it thinks the serial_number is with `vpd -l`, if this returns nothing then we need to set the expected serial number, if your devices need to be enterprise enrolled this is critical. You can set vpd values with `vpd -i RO_VPD -s "serial_number"="YOUR_SERIAL_NUMBER"`. 

4.b. Remove the GBB flags, this will allow the device to go back into normal mode. This involves reading the firmware, clearing the flags, and writing it back. The commands look like:
flashrom -p host -r /tmp/image.bin

gbb_utility --set --flags=0 /tmp/image.bin

flashrom -p host -w /tmp/image.bin 

5. With the serial number in place and the GBB flags cleared, you can reboot the device, convert it back to dev mode (spacebar) and then go ahead with enrollment.

-Bernie

--
--
Chromium OS Developers mailing list: chromiu...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-os-dev?hl=en

[Bernie Thompson]

Vincent brings up another good point about finalization, these might also be missing a valid HWID, without which they may not receive automated updates anymore, so we need to add a step to 4.b to set the HWID. In this case the HWID will not be perfectly accurate, but that is likely not to matter for normal use cases, it just needs to have a HWID that looks like it should, something like "FALCO ABC-123-465-XYZ", as these have checksums I would grab a Falco that is still working and reboot it into recovery mode (esc+refresh+power) and its should show a valid HWID, this HWID can be transplanted into the device being reworked, these values are not unique like serials but are a sort of 'hardware checksum' for the device, it encodes what components were used in the system (e.g. what memory, storage, display, etc), so transplanting from another system makes it inaccurate but that is probably fine. 

So once you have a valid looking HWID value you can write it in as part of step 4b, which we modify to look like:

4.b. Remove the GBB flags, this will allow the device to go back into normal mode, and set a valid HWID. This involves reading the firmware, clearing the flags, and writing it back. The commands look like:

flashrom -p host -r /tmp/image.bin

gbb_utility --set --hwid="FALCO SOME_STRING_FROM_ANOTHER_FALCO"

gbb_utility --set --flags=0 /tmp/image.bin

flashrom -p host -w /tmp/image.bin 

You probably also want to put back in the WP screw once you have confirmed the system boots up properly and can enroll.

-Bernie

[Michael]

Hey guys,

 thank you for all your feedback. I have two things to add before going forward:

1) Instead of using a new circuit board for the CB, I am using a working one from another  SMB Chromebook. I assumed they would pop in and out like the other parts do. I do have a new one, but I wanted to try with recycled parts first.

2) How do I re-enable developer mode? I contacted our IT department and all they could do was move the CB to a group where dev mode is enabled. This doesn't help me with my local machine, since I cannot even get it on the network.

Oh, and one more thing, how do you guys know so much about Chromebooks? My school is now one-to-one and I have had to learn everything I know by searching.

Thanks again for your help.

[Bernie Thompson]

On Tue, Mar 21, 2017 at 10:45 AM, Michael <mhwil...@bullochschools.org> wrote:

Hey guys,

 thank you for all your feedback. I have two things to add before going forward:

1) Instead of using a new circuit board for the CB, I am using a working one from another  SMB Chromebook. I assumed they would pop in and out like the other parts do. I do have a new one, but I wanted to try with recycled parts first.

Physically they may pop in, but some of the state of the device is baked into that motherboard, so it is unfortunately a bit complex as shown in this thread. OTOH if the motherboard was pulled from a system that was working fine, it would probably still work fine in the new one (it should not have had gbb 0x39 and such then, this implies a factory fresh/RMA board). 

 

2) How do I re-enable developer mode? I contacted our IT department and all they could do was move the CB to a group where dev mode is enabled. This doesn't help me with my local machine, since I cannot even get it on the network.

Go to recovery with esc+refresh+power, then press ctrl+d at the white dev mode screen and it should start a conversion.

 

Oh, and one more thing, how do you guys know so much about Chromebooks? My school is now one-to-one and I have had to learn everything I know by searching.

This list is for developers, many of the folks on here have authored portions of the OS itself or have been otherwise involved deeply with Chrome OS development. I am familiar with these particular steps as I have fixed up systems that came from the factory in a bad state in the past, which is common with very early builds of new systems. 

 

Thanks again for your help.

On Tuesday, March 21, 2017 at 11:32:41 AM UTC-4, Michael wrote:

Hi all,

Excuse me if this is not the correct forum for this post!

I am the technical support liaison at a middle school. I replaced the motherboards in a couple of out-of-warranty HP Chromebooks. When powered on, the devices default to the "Chrome OS is missing or damaged." screen with the error  gbb.flags is nonzero, etc screen. I have tried reinstalling the OS but it returns to this screen. 

I cannot access CROSH (or anything else). I used the recovery utility to try to reinstall the OS, but that did not work either. I think that the CB is is set somehow so that it cannot update its firmware and that is preventing it from moving forward. 

Any thoughts?

Michael

--

[Michael]

I have tried the ESVC + Refresh+ Power, CTRL + D method and it still brings me back to the "Owner has disabled dev mode" screen. 

Anyway, I know a lot more than I did this time yesterday. Thanks for helping me out. I think put this one aside for now. 

On Tuesday, March 21, 2017 at 11:32:41 AM UTC-4, Michael wrote:

[Bernie Thompson]

If it was blocked from dev mode by the owner (IT department of a school) and it has not been able to connect to the network to remove the dev mode blocking after the school removed the dev mode blocking on the console (e.g. it is not booting), I think it may be effectively bricked :(. Recovery at that point may require more advanced physical tools (e.g. a Dediprog or a Servo) to directly rewrite the firmware to force it into dev mode (this is by design). The cost and complexity of these generally limit their use to only if you have a large number of such systems, or are really into firmware development.

You might get it to boot if you have multiple of these systems by performing a SSD swap (IIRC Falcos have discrete SSD cards, but some in this generation had them soldered down so this may be a no go), a valid OS on a SSD from another Falco may still boot on this one and allow it to get to a point that the dev mode blocking can get disabled, but that is a bit of a long shot.

-Bernie

--