06:45 <SymbioticFemale> what does it mean when serial output is just "CCCCCCCCCCC" repeating?

07:57 <Arijit> Hi there!

11:12 <zmatt> SymbioticFemale: bootrom is attempting to perform xmodem boot over the uart

11:13 <zmatt> SymbioticFemale: this means it was not able to load the next stage (typ u-boot SPL) from eMMC or μSD

11:15 <zmatt> (the default boot device list for bootrom is { eMMC, μSD, uart-xmodem, usb-rndis } on the BBB, or { spi-flash, μSD, usb-rndis, uart-xmodem } if the S2 button was held down at the moment of power-on

11:15 <zmatt> )

11:30 <SymbioticFemale> weird that my microSD card wasn't being read because i flashed two different images on it during testing

11:31 <SymbioticFemale> no idea what is on my eMMC because it has been malfunctioning for over a year. some corrupt image is on there, for sure.

11:33 <zmatt> well dunno about "corrupt", bootrom performs no significant validation on the MLO it loads

11:33 <zmatt> it's more likely it can't find it at all

11:33 <SymbioticFemale> it should be finding my microSD image though after ignoring the emmc

11:34 <SymbioticFemale> but its not

11:34 <zmatt> yep, so the logical conclusion is that your microSD image is not bootable

11:34 <zmatt> not considered to be bootable by bootrom

11:35 <SymbioticFemale> shouldn't there at least be a message from uboot at boot?

11:35 <zmatt> bootrom != u-boot

11:35 <zmatt> u-boot is the thing loaded by bootrom

11:35 <SymbioticFemale> oh i see

11:36 <zmatt> there's a short description of how bootrom finds the MLO here: https://github.com/mvduin/bbb-asm-demo/#booting-%CE%BCsdemmc

11:37 <zmatt> (MLO is a raw binary prepended with an 8-byte header indicating the load address and the length, execution starts in ARM-mode at the start of the binary)

11:38 <SymbioticFemale> the images i tried flashing were the latest bone-* image from https://rcn-ee.net/rootfs/debian-armhf/ and the latest (but old) console image from beaglebone.org

11:38 <zmatt> how are you flashing it?

11:39 <SymbioticFemale> dd

11:39 <zmatt> after unxz'ing it?

11:39 <SymbioticFemale> unxz, then dd

11:39 <SymbioticFemale> of course

11:39 <zmatt> to the whole card, not a subpartition? :P

11:39 <SymbioticFemale> correct

11:40 <zmatt> that's curious indeed, that would suggest either a problem with the SD card itself or with the SD card slot of the BBB

11:41 <SymbioticFemale> i tried at least the console image on usb too. no change.

11:41 <zmatt> "on usb" ?

11:41 <SymbioticFemale> flashing to usb drive

11:41 <zmatt> bbb can't boot from an usb drive

11:41 <SymbioticFemale> :/ alright so i should find myself a different microsd

11:42 <SymbioticFemale> i'll give that a try. thanks zmatt.

11:42 <zmatt> maybe try flashing with Balena Etcher, which will also verify the sd card contents after writing it

12:19 <SymbioticFemale> changing flash cards worked

12:19 <SymbioticFemale> yay

12:19 <SymbioticFemale> i thought my BBB was borked

13:22 <zmatt> people sometimes confuse sd cards for being reliable media ;)

13:23 <SymbioticFemale> it lasted longer than my eMMC

13:23 <zmatt> what did you do to your poor eMMC to murder it?

13:24 <SymbioticFemale> unsure but its possible to write to it a little bit then it gets i/o error and everything falls apart

13:25 <zmatt> sounds like wear-out

13:26 <zmatt> we once introduced a "little" bug in one of our software components that accidently caused it to write about 16 GB/hr constantly

13:28 <zmatt> fortunately we discovered this before it was deployed widely

13:29 <SymbioticFemale> i think i've mostly ever used freebsd/openbsd images, and not extensively. this beaglebone is at least 6-7 years old though. most of that time in storage.

13:31 <zmatt> anyway, this is also why it's important to verify sd card contents after writing it... that would have imediately revealed it was bad. this is also important since sd card wear-out may not be immediately obvious, it can also just result in corrupting random chunks of data, causing mysterious problems when you try to use that system

13:35 <zmatt> long-term storage (especially at elevated temperatures) may degrade the *contents* of flash memory but afaik not the memory itself, that happens due to erase/write cycles

17:16 <vd> zmatt: from the bootloader level, do you need to access the RTC after clearing the PMIC OFF bit to trigger a power cycle? Or can you access a gpio or something directly instead of programming the ALARMs?

17:18 <zmatt> you need to access the rtc, which has exclusive control over a dedicated power-enable signal to the pmic

17:18 <zmatt> both the power-off and the subsequent power-on are triggered by alarms

17:19 <zmatt> for safety I'd recommend scheduling the power-on in the rtc *before* setting the OFF bit in the pmic

17:20 <vd> ok thank you, that is very clear

17:46 <vd> zmatt this is the simplest (linux userspace) fix you can do with your recommendations: http://ix.io/3y19

20:48 <zmatt> vd: one concern with that is that you can't be sure a clean shutdown takes only 10 seconds. might be better to use "poweroff --force" or even "poweroff --force --force"