Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Topics - hiryu

Pages: [1]
1
Firmware / Flashing corrupted BMC firmware
« on: November 16, 2023, 09:45:54 am »
Plugging in my Talos II board, I was only seeing this periodically over and over on the serial port:
Code: [Select]
DRAM Init-V12-DDR4
0abc1-4Gb-Done
Read margin-DL:0.3607/DH:0.3803 CK (min:0.30)

Only some of the numbers on the last line would change.

I decided to try this method:
https://wiki.raptorcs.com/wiki/Debricking_the_BMC#Flash_new_BMC_firmware_via_serial_port_.28Open_Source_Method.29

Running this all night (from my Blackbird), I am getting these messages:
Code: [Select]
./flashrom --verbose --programmer 'ast2400:serial=/dev/ttyUSB0,cpu=halt,spibus=0' -c MX25L25635F/MX25L25645E/MX25L25665E -w image-bmc
flashrom d8f8f68 on Linux 6.5.11 (ppc64le)
flashrom is free software, get the source code at https://flashrom.org

flashrom was built with libpci 3.7.0, GCC 11.4.0, little endian
Command line (7 args): flashrom --verbose --programmer ast2400:serial=/dev/ttyUSB0,cpu=halt,spibus=0 -c MX25L25635F/MX25L25645E/MX25L25665E -w image-bmc
Calibrating delay loop... OS timer resolution is 1 usecs, 1887M loops per second, 10 myus = 10 us, 100 myus = 100 us, 1000 myus = 997 us, 10000 myus = 9992 us, 4 myus = 4 us, OK.
Initializing ast2400 programmer
No password specified with aspeed_vendor_backdoor_password, falling back to default.
Sending vendor serial backdoor password... done.
Waiting for response... done.
Detected 115200 baud interface
Configuring P2A bridge for SCU access
Configuring P2A bridge for WDT access
Configuring P2A bridge for SMC access
Enabling CE0 write
Using CE0 offset 0x00000000
The following protocols are supported: SPI.
Probing for Macronix MX25L25635F/MX25L25645E/MX25L25665E, 32768 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2019
Found Macronix flash chip "MX25L25635F/MX25L25645E/MX25L25665E" (32768 kB, SPI) on ast2400.
Chip status register is 0x00.
Chip status register: Status Register Write Disable (SRWD, SRP, ...) is not set
Chip status register: Bit 6 is not set
Chip status register: Block Protect 3 (BP3) is not set
Chip status register: Block Protect 2 (BP2) is not set
Chip status register: Block Protect 1 (BP1) is not set
Chip status register: Block Protect 0 (BP0) is not set
Chip status register: Write Enable Latch (WEL) is not set
Chip status register: Write In Progress (WIP/BUSY) is not set
This chip may contain one-time programmable memory. flashrom cannot read
and may never be able to write it, hence it may not be able to completely
clone the contents of this chip (see man page for details).
Switched to 4-bytes addressing mode.
Reading old flash chip contents... done.
Erasing and writing flash chip... Trying erase function 0...  0%0x000000-0x000fff:EFAILED at 0x00000000! Expected=0xff, Found=0xf8, failed byte count from 0x00000000-0x00000fff: 0xf98
ERASE FAILED!
Reading current flash chip contents... 32%

That seems bad... Is there anything I can do different from my side or do I need to replace the flash ship?


2
Firmware / annoying missing sshd corner case with manually edited users
« on: February 21, 2020, 12:15:33 am »
After some back and forth on twitter, the notes have been updated:
https://twitter.com/RaptorCompSys/status/1230723235961917440

But I will give a run down on how this seemed to occur to me.
a. /etc/passwd- was giving me a random "stale file handle" issue... Which was preventing me from writing to /etc/passwd, as /etc/passwd could not be backed up to /etc/passwd-
b. Restarting the BMC fixed this so this "stale file handle" issue is intermittent?
c. Ultimately the issue here is that /etc/passwd is persistent and I had added a user. The new version of the file which can be found here: /run/initramfs/ro/etc/passwd, has the sshd user.

From here... it's clear that useradd is _really_ broken. It complains:
useradd: PAM: Permission denied

Probably needs to be built without PAM support?

adduser won't give you a list of options it accepts and it's the busybox version so who knows? Turns out it seems to _mostly_ have parity with Debian 10's adduser.

Here is how I ultimately was able to get this working:
1. addgroup --system sshd
2. adduser --system --home /var/run/sshd --shell /bin/false sshd (ignore the error about the sshd group)
3. usermod -g sshd sshd
4. chown root:root /var/run/sshd

Theoretically and ideally, the above steps should be performed BEFORE the upgrade to avoid having to hook up a serial cable.

My steps won't provide the same UID/GID as in the release notes, but will use the next available system UID/GID, which will work just as well. You could also modify the user or add some CLI switches to match Raptor's settings.

(edited to make minor fix to step 2 adduser command)

Pages: [1]