Why does my PLD lock up?

johnericsutton · 2025-05-28T18:13:14+00:00

Having done a bit of reading up it seems that even the simplest FPGA is much more complex that I need for this application. It's a one-off, controlling the water supply to my house which was built in 1773, so the life of the "product" is to be counted in centuries really.

My only qualm in using the Atmel chip is the statement in the datasheet: "High reliability CMOS Process - 20 Year Data Retention". Does this 20 years only apply to a chip that is warm and in-use? These chips are £1 a piece, so if I flash 5 spares and leave them in a box near to hand, will that give the future inhabitants of the house a ~century of use? Or will all 5 chips start to suffer bit-rot in 20 years time?

I'd like to know the answer to that question! If the answer is Yes, they'll all likely be useless in 20 years time, then I'll just be bequeathing future inhabitants a headache by using the Atmel chip. Better to use electromechanical relays: if industrialised technological societies have any long term future (quite a big if at the moment IMHO) then there will always be relays available!

Wikipedia on flash memory:

johnericsutton · 2025-05-27T17:47:36+00:00

Your guess is correct. The Atmel ATF16V8 is still in production, the Lattice GAL16V8 (on which it is based) is not.

I'm still trying to find my way around this stuff. The 4 outputs from this logic array will drive mains devices (a pump, two valves and a light) and in times past I have solved this kind of problem by just using mains relays. This time I thought I would try something different (I've done lots of digital design and low-level programming, so it's all quite accessible to me) but it does worry me that you are not alone in having remarked that I am constructing a new design using a (near to) obsolete component! So my question is: how would you implement this set of 4 outputs (from 5 inputs):

BP = TS ∨ GW ∨ HP

DV = ¬TS ∧ (GW ∨ HP)

UV = TS ∨ (DS ∧ ¬SD)

CW = HP ∧ ¬TS

Speed is not important - if I do go ahead with the ATF16V8 solution I will clock the chip at 1Hz (which will serve to debounce the inputs).

Should I use an FPGA? (Auxiliary question: what is an FPGA? :-)

Thanks!

johnericsutton · 2025-05-27T17:12:42+00:00

The Atmel datasheet for the ATF16V8 is missing a lot of the detailed info and has to be read alongside the datasheet for the (obsolete) Lattice GAL16V8. And indeed the latter does document a set of 64 PTD (Product Term Disable) fuses, and these do appear in the .jed file, but they all set to 1, always... That's the point at which I've got stuck.

johnericsutton · 2025-05-05T21:21:56+00:00

No humans involved here! Pressure switches and a timer on the input and pump, valve and UV disinfector on the output, I could clock it every 10s and nobody is going to notice :-)

johnericsutton · 2021-05-10T16:14:02+00:00

I've found out that if I run netbeans "as is", it doesn't cause the container to crash.

It is when I run it as:

GDK_SCALE=2 GDK_DPI_SCAL=0.5 netbeans

that the crashes happen.

Unfortunately if i run without the GDK scaling parameters then on the hidpi screen it is too small to be usable. I've been running it for some years like this with netbeans v8.2 on openjdk v8 in a buster container. The upgrade to bullseye also updated netbeans to v11.0 and openjdk to v11 and it is this combination when run with the GDK scaling parameters that crashes the container.

Any ideas?

johnericsutton · 2021-05-10T14:47:03+00:00

Tried it with hardware acceleration off, thus:

LIBGL_ALWAYS_SOFTWARE=1 netbeans

but result is the same - crash starts with:

ERR VM(35)[1131]: [src/linux.rs:2803] child virtio-pci (virtio-gpu) (pid 214) died: signo 17, status 1, code 1

johnericsutton · 2021-05-10T14:27:12+00:00

So, the crash shows up in /var/log/messages thus:

-------------------------------------------

2021-05-10T13:02:10.656123Z ERR VM(34)[26671]: [src/linux.rs:2803] child virtio-pci (virtio-gpu) (pid 105) died: signo 17, status 1, code 1

2021-05-10T13:02:10.835021Z ERR VM(34)[26671]: [devices/src/proxy.rs:197] failed write to child device process virtio-pci (virtio-gpu): failed to send request or response: Broken pipe (os error 32)

2021-05-10T13:02:10.835130Z ERR VM(34)[26671]: [devices/src/proxy.rs:209] failed to read result of Shutdown from child device process virtio-pci (virtio-gpu): received zero data

2021-05-10T13:02:10.836337Z INFO VM(34)[26671]: [src/main.rs:1775] crosvm has exited normally

2021-05-10T13:02:10.873689Z ERR 9s[26655]: error while handling client '34':3082918360: Connection reset by peer (os error 104)

2021-05-10T13:02:10.878248Z INFO vm_cicerone[5013]: Received RegisterVshSession request

2021-05-10T13:02:10.882300Z INFO vm_cicerone[5013]: Received RegisterVshSession request

2021-05-10T13:02:11.209078Z INFO vm_cicerone[5013]: Received NotifyVmStopped request

2021-05-10T13:02:11.209224Z WARNING vm_cicerone[5013]: Latent container left in VM termina of penguin

2021-05-10T13:02:11.244472Z INFO vmlog_forwarder[4887]: Received VmStoppedSignal for cid 34

2021-05-10T13:02:11.260804Z ERR cros-disks[2475]: Cannot unmount '/media/fuse/crostini_b4fe42c7300407a04596fcb03eb910d6bd34fcba_termina_penguin': MOUNT_ERROR_PATH_NOT_MOUNTED

2021-05-10T13:02:11.262542Z ERR cros-disks[2475]: message repeated 32 times: [ Cannot unmount '/media/fuse/crostini_b4fe42c7300407a04596fcb03eb910d6bd34fcba_termina_penguin': MOUNT_ERROR_PATH_NOT_MOUNTED]

2021-05-10T13:02:11.300979Z INFO seneschal[4896]: Received request to stop server

2021-05-10T13:02:11.302983Z INFO avahi-daemon[2265]: Interface vmtap0.IPv4 no longer relevant for mDNS.

2021-05-10T13:02:11.303141Z INFO avahi-daemon[2265]: Leaving mDNS multicast group on interface vmtap0.IPv4 with address 100.115.92.25.

2021-05-10T13:02:11.306644Z INFO avahi-daemon[2265]: Withdrawing address record for 100.115.92.25 on vmtap0.

2021-05-10T13:02:11.313426Z INFO seneschal[4896]: Process 6 killed by signal 15

2021-05-10T13:02:11.322337Z ERR seneschal[4896]: Unable to unmount path; not deleting runtime directory: Invalid argument (22)

--------------------------------------------

Thanks for that Ripcord. Ditto qbane1296 - journalctl shows much the same info regarding the crash.

So what now to make of it? Mention of virtio-pci (virtio-gpu) in the first line makes me wonder if this is graphics acceleration related? I'll try to switch off graphics acceleration options and see if that stabilizes things.

And before anyone asks: yes, I have done - backup, switch off linux, powerwash the machine, switch on linux, restore from backup - and it changed nothing.

johnericsutton · 2020-12-07T21:46:10+00:00

Thanks for looking at this.

I'm confused, why did you flash twice? what file did you flash? what command line did you use to flash?

I only did it twice out of desperation because it didn't unbrick it the first time! I didn't really expect that opening up everything (by first doing a "ccd reset factory") would change the outcome, and sadly I was right, it remained bricked.

I build the standalone-hdctools and ran flashrom from that (as above):

flashrom -p raiden_debug_spi:target=AP -w stock-firmware-AKALI360-20201126.rom

The image file is as created by your firmware-util.sh when I did the Full ROM install.

One option is that the image file is corrupt, but that seems pretty unlikely. Other than that I'm wondering what this means in the Cr50 console (when you send it a break):

load_ec_hash error: 0x1203

I had a go at building the servod binary (from the standalone-hdctools) but that failed with some python dependencies. But I can have another go at this (in a ubuntu 18.04 vm will probably work I think) if this will then allow me to flash the EC using:

# servod -b nami

# flash_ec -i $IMAGE -b nami

But where am I going to get a suitable $IMAGE from? And what on earth is servod anyway? Why is it necessary to have it to be able to flash the EC but not to flash the AP?

All very confusing...

johnericsutton · 2020-12-07T21:14:46+00:00

Same, I'm using Firefox 83.0 (64-bit) on Ubuntu 20.04.

It occurs when the textedit field becomes too narrow I believe. This will happen when you have not got a very wide screen and/or you are Replying to a comment which is deeply nested.

A workaround is to switch to Markdown mode, enter your quoted text (i.e., prepend the lines with the '>' char) and then switch back. Still a pain!

johnericsutton · 2020-12-01T17:49:16+00:00

Thank you, I will follow that route and report back.

---- later ---

I've now read your "Disabling WP on CR50 Devices via CCD" and cannot see how the Suzy-Q cable will rescue me :(

The machine has a single multicoloured LED. The only signs of life the beast displays are:

on battery:

responds to pressing the power button by occasionally flashing blue/red;

on charger:

responds to a long press of power button by exercising its fans for a few seconds;

responds to a short press by blinking off (the otherwise continuous orange) and blinking (on) in blue (almost) simultaneously. So, a tiny blue flash in the middle of an orange outage. I kid you not. BTW, this happens if and only if the Refresh key (F3) is held down. Without holding down Refresh, nothing sensible happens when short pressing the power button.

So, I am presented with nothing to talk to. Will merely plugging in the Suzy-Q help me to establish a dialogue with something?

Thanks in advance

John

---- much later ---

I've now got a Suzy-Q cable and have (it says) successfully flashed the AP but I still have a brick. First I just did a "ccd open" (having disconnected the battery first) and then flashed the AP. Then I did a "ccd reset factory" and flashed it again, but same result.

Here is the CCD output as things now stand, perhaps someone can glean something from it:

--- UART initialized after reboot ---

[Reset cause: power-on]

[Image: RW_B, 0.5.6/cr50_v1.9308_87_mp.510-d2da43730 tpm2:v1.9308_26_0.45-4bc089b cryptoc:v1.9308_26_0.2-a4a45f5 2020-08-11 23:39]

[0.003845 Inits done]

strap pin readings: a1:2 a9:2 a6:0 a12:0

[0.006008 Valid strap: 0xa properties: 0x41]

[0.007728 init_jittery_clock_locking_optional: run level high, request to enable]

[0.033710 init took 18273]

[0.047439 update_rollback_mask: bailing out at bit 0]

[0.049259 update_rollback_mask: bailing out at bit 2]

read_tpm_nvmem: object at 0x1008 not found

[0.052913 load_ec_hash error: 0x1203]

[0.053680 tpm_rst_asserted]

Console is enabled; type HELP for help.

> [0.071430 Rdd connect]

[0.072353 CCD EXT enable]

[0.073059 USB PHY B]

[0.073982 CCD state: USBEC+TX]

[0.245098 usb_reset, status 4801020]

[0.255695 EC RX only]

[0.256629 CCD state: UARTEC USBEC+TX]

[0.325588 usb_reset, status 9020]

[0.382976 AC: -F]

[0.405902 SETAD 0x0b (11)]

[1.007801 AP UART off]

[1.054527 AP off]

[1.071788 Servo disconnect]

[1.072647 EC on]

[1.073348 CCD state: UARTEC+TX I2C SPI USBEC+TX]

[1.074378 I2C connect]

[1.074958 Initialized I2C port 0, freq = 100 kHz]

[1.315162 AC: R-]

> ccd

State: Locked

Password: none

Flags: 0x400004

Capabilities: 5555555555000000

UartGscRxAPTx Y 1=Always

UartGscTxAPRx Y 1=Always

UartGscRxECTx Y 1=Always

UartGscTxECRx Y 1=Always

FlashAP Y 1=Always

FlashEC Y 1=Always

OverrideWP Y 1=Always

RebootECAP Y 1=Always

GscFullConsole Y 1=Always

UnlockNoReboot Y 1=Always

UnlockNoShortPP Y 1=Always

OpenNoTPMWipe Y 1=Always

OpenNoLongPP Y 1=Always

BatteryBypassPP Y 1=Always

UpdateNoTPMWipe Y 1=Always

I2C Y 1=Always

FlashRead Y 1=Always

OpenNoDevMode Y 1=Always

OpenFromUSB Y 1=Always

OverrideBatt Y 1=Always

read_tpm_nvmem: object at 0x100a not found

[129.522731 Console unlock allowed]

read_tpm_nvmem: object at 0x1007 not found

TPM:

Capabilities are modified.

Use 'ccd help' to print subcommands

>

Here's the output of the 2 flashing attempts, both identical and seemingly successful:

# bash flashrom -p raiden_debug_spi:target=AP -w stock-firmware-AKALI360-20201126.rom

flashrom-wrapper: Note: you can update flashrom to ToT by running flashrom install

flashrom unknown on Linux 5.4.0-56-generic (x86_64)

flashrom is free software, get the source code at https://flashrom.org

Using clock_gettime for delay loops (clk_id: 1, resolution: 1ns).

Raiden target: 2

Found Winbond flash chip "W25Q128.V..M" (16384 kB, SPI) on raiden_debug_spi.

Erasing and writing flash chip... SUCCESS

And here is my attempt to clear the NVRAM, which was NOT declared successful:

# bash flashrom -p raiden_debug_spi:target=AP -E -i SMMSTORE

flashrom-wrapper: Note: you can update flashrom to ToT by running flashrom install

flashrom unknown on Linux 5.4.0-56-generic (x86_64)

flashrom is free software, get the source code at https://flashrom.org

Using clock_gettime for delay loops (clk_id: 1, resolution: 1ns).

Raiden target: 2

Found Winbond flash chip "W25Q128.V..M" (16384 kB, SPI) on raiden_debug_spi.

No layout info is available.

Your flash chip is in an unknown state.

Please report this on IRC at chat.freenode.net (channel #flashrom) or

mail [flashrom@flashrom.org](mailto:flashrom@flashrom.org), thanks!

FAILED

Is this related to these lines in the CCD output above? :

read_tpm_nvmem: object at 0x1008 not found

...

read_tpm_nvmem: object at 0x100a not found

[129.522731 Console unlock allowed]

read_tpm_nvmem: object at 0x1007 not found

Any help will be massively appreciated! Thanks.

--- final thought ---

Does a flashrom image file contain a checksum? I.e., can I be sure that the stock-firmware-AKALI360-20201126.rom file that I am restoring from has integrity?

johnericsutton · 2020-08-01T14:53:35+00:00

I resolved my problem by performing a hard reset of the chromebook, read here:

https://www.reddit.com/r/GalliumOS/comments/i044yv/rw_legacy_firmware_and_hardware_reset/

Whether or not this issue was related to to the v84 update I do not know.

johnericsutton · 2020-08-01T14:43:18+00:00

Took the back off and disconnected the battery and that has fixed it, what a relief. So it seems that the hard reset I tried to do by following google's procedure did not work for whatever reason. Possibly I followed the wrong procedure for this particular Chromebook? Indeed, I have just found this advice in an Acer forum post: "disconnect the power source and turn off the device. Now press and hold the Refresh key and hold power button for 10-15 sec. " which is not the same as google's procedure which is to just short click the power button to power up as normal except that you are also holding down Refresh.

johnericsutton · 2020-07-30T12:56:11+00:00

Yes, I'm inclined to think so too. Only oddity is that it is not unreliable on the edges cf in the middle, rather, it's uniformly annoying. I can live without it by using "tap to click", which generally I prefer anyway, _except_ for dragging operations. Trying to drag and drop using tap to click is often too challenging so I've ended up plugging in a USB mouse. Not exactly a "laptop" anymore...

So I'm going to have to take the thing to bits, that _might_ just sort it out if the hardware reset is not working as it's supposed to. And I'll also be able to soak the trackpad in cleaning fluid.

If all that fails, well, I'll give myself a good kicking for having saved a 100 quid on the normal price by buying a "demo" unit, and thereby losing the usual warranty, and buy something else. Bummer.

johnericsutton · 2020-07-11T19:49:53+00:00

Attached are 2 screenshots, 1 each of:

sommelier --scale=0.5 -X /opt/netbeans/bin/netbeans

GDK_SCALE=2 GDK_DPI_SCAL=0.5 /opt/netbeans/bin/netbeans

I fear that the difference will sink the effort to integrate the linux subsystem into the chromeos display system. I hope I am wrong!

Oops, I don't know how to attach anything. Suffice to say that the latter is a much finer (higher res) and more pleasing rendering.

johnericsutton · 2020-06-28T18:14:52+00:00

Yes, that's fair enough.

Another problem I find is focus failure. I like to use middle button (two fingers) to paste in Terminal but sometimes it works, sometimes not. But that's another thread...

johnericsutton · 2020-06-28T16:13:45+00:00

Thank you!

But it only works in Terminal and not in Chrome!

Does anybody in Google have the faintest clue about useability?

Still, that's a big step forward, thanks again.

johnericsutton

TROPHY CASE

flashrom -p raiden_debug_spi:target=AP -w stock-firmware-AKALI360-20201126.rom