CRAASNETO Not Consistently Offering Internal Disk as Boot Option

[Rampaging-Mongoose]

I'm not 100% confident that I know what triggers the problem but it seems that, in certain "first-boot" scenarios, the internal disk is visible to the BIOS. This consistently occurs after the device is initially powered on. The "solution" thus far has been to reboot the device via "refresh + power" until the system successfully reaches the linux bootloader.

Another scenario, possibly related, occurs after getting to the linux bootloader but before I am prompted for decryption password. When this occurs I choose the OS to boot but am followed up with an init error and am never prompted to decrypt. Rebooting after receiving this error generally resolves the problem.

CRAASNETO
Model:Acer Chromebook 314
Model No.: N23Q19
MFG Date: 2024/05/25
C936T-POTV

[caineblood]

The above comment asking you to download a file is malware to steal your account; do not under any circumstances download or run it. The post needs to be removed. If you have attempted to run it please have your system cleaned and your account secured immediately.

[Rampaging-Mongoose]

The above comment asking you to download a file is malware to steal your account; do not under any circumstances download or run it. The post needs to be removed. If you have attempted to run it please have your system cleaned and your account secured immediately.

Aww man, I really wanted to run a totally random, unexplained, executable today :(

Thank you for the heads-up!

[MrChromebox]

The above comment asking you to download a file is malware to steal your account; do not under any circumstances download or run it. The post needs to be removed. If you have attempted to run it please have your system cleaned and your account secured immediately.

removed

[MrChromebox]

@Rampaging-Mongoose does your device use eMMC, UFS, or NVMe for internal storage?

[Rampaging-Mongoose]

I'm not sure; linux sees the storage device as /dev/mmcblk0. Here's the output of an mmc command:

[rampaging-mongoose@nixos:~]$ mmc csd read /sys/block/mmcblk0/device
	SPEC_VERS: 0x4 (v4.0-v4.3)
	CCC: 0x8f5 (class: 11, 7, 6, 5, 4, 2, 0,   )

[MrChromebox]

then it's almost certainly eMMC

[Rampaging-Mongoose]

I thought so but the output differs substantially from another Chromebook I'm running your FW on so I wasn't absolutely sure.

[MrChromebox]

I thought so but the output differs substantially from another Chromebook I'm running your FW on so I wasn't absolutely sure.

not sure what you mean - different devices have different hardware

[Rampaging-Mongoose]

Do you need anything else to confirm the storage type and/or is there anything more that I can provide for you at this time?

[MrChromebox]

if you have a SuzyQ cable, I can have you flash a debug build and get a log to try and see what's going on. But that's about it

[Rampaging-Mongoose]

Yeah, I got a couple to deal with the newer Chromebooks that require CCD in order to disable WP. This model is actually one of those.

[MrChromebox]

here's a serial/debug enabled build. flash it (--fmap -i COREBOOTis sufficient), and have a minicom session open to /dev/ttyUSB1. Enable logging and save to file, then attach here. Do not copy the screen and save that way, it will not be accurate.

coreboot_edk2-craasneto_debug-mrchromebox_20240831.zip

[Rampaging-Mongoose]

I've included three different captures: two failed boots, one with a CRC error and another with a "device" error. A successfull boot is also included. The order these caps were generated was "minicom-crc_error" (reboot) "minicom-device_error" (reboot) "minicom_success"

minicom.zip

[MrChromebox]

I've included three different captures: two failed boots, one with a CRC error and another with a "device" error. A successfull boot is also included. The order these caps were generated was "minicom-crc_error" (reboot) "minicom-device_error" (reboot) "minicom_success"

minicom.zip

sadly there's no difference in the eMMC init, only the errors at the end when edk2 goes to boot the device