Getting a little jumper-y

 This will be a short post. The tagline mentions jumper because this write-up is about reverse engineering the L2 cache jumpers on a 1990's Pentium (P54) motherboard. There are more jumpers that need some figuring out, and they will not appear until a future write-up.

While sorting through 'tech' I had stowed for future hobbies, I found myself unable to parrt with an AT (clone) case from what was once a 386DX/25 on which I first learned MS-DOS, Windows 3.1 and Microsoft Publisher.

That AT case no longer has anything from its "386" days except for the original two floppy drives and a power supply. At some point I had stashed a rescued Pentium motherboard in the case - Full Yes Incorporated SIS P5 PCI; the motherboard had 256K of 15ns cache  installed (eight chips) and a single cache chip with 25ns rating. The motherboard functioned only with cache disabled. 

With the cache disabled in BIOS, I uncovered another problem.  Since stashing the motherboard a decade ago, the Dallas CMOS RTC battery had faded. I was now greeted with a NMI error.  A site hinted that  bad CMOS can potentially interfere with being able to establish a healthy cache, resulting in memory errors and a dreaded NMI on boot. NMI errors are also reported as happening with bad disk blocks or a corrupted boot sector.

I ordered a new RTC from DigiKey, installed it, and my problems were not solved. 

Replacing the RTC allowed the CMOS to keep settings which meant the next challenge was to find out why I was getting the dreaded NMI.  The NMI ended up being a simple fix - either install parity SIMMs or disable the parity check in the BIOS.  I tried both ways, but I had yet another problem.  Upon getting to POST, the system hanged when the cache was enabled.

The motherboard uses a SIS 50x chipset. I read up on SIS chipsets and learned that most of the SIS motherboards supported 1MB to 2MB of cache.  This motherboard has 20 sockets for DIP32 cache chips.

I placed an order for 128Kx8's and upon receiving them, tested them in my Xgecu TL866ii to eliminate bad modules.

I installed the cache chips and the system would hang on POST with either a report of 0K or 64K of cache. I fussed with the jumpers in proximity to the cache sockets and found settings which claimed 2MB of alleged cache on POST; however, the system still hanged after POST or shortly after reaching a prompt in FreeDOS.

I read about how someone had managed to revise their system board - from the same era and same chipset - to accommodate 2MB of cache despite being manufactured with support for 1MB. That gave me incentive to pull out a multimeter and begin ohming connections on the system board.  I discovered that a block of jumpers positioned between the TAG RAM sockets and the CPU socket were not anything other than jumpers for specifying the TAG RAM configuration.  Up until this point I suspected they were settings for CPU or cache voltage.  Instead, neither.  Before filling all sockets, I double-checked that the TAG RAM sockets would accept 128Kx8's.  Other SIS system board manuals hinted that 1MB of cache with 128Kx8's requires a single 64Kx8 TAG SRAM.  Two banks of 1MB would follow to equal two 64Kx8's. 

Well, shoot; I only ordered 128Kx8's.

A 128Kx8 will address up to line A16, but what if the pin for A16 is neither connected to ground nor Vcc - in fact, not connected at all?  If that happened to be the case, I would need to short them ground; otherwise it might float between either of two 64K banks on the the 128Kx8 DIP32.  If they had been floating, that might explain the variance between 0K and 64K, or now with the jumpers configured to 2MB, wavering between 0K and 2MB.

A check with the multimeter showed line A16 of both TAG SRAM sockets was properly hooked to ground.  But the findings for the middle set of jumpers - JP7, JP8, JP9 and JP10 showed some measurements I did not immediately follow.  JP7, JP8 and JP10 all had been in a position to short to ground.  JP9 jumpered A13 to Vcc (+5V). The explanation for this became clear when I looked up the pin out for a DIP28 8Kx8.  The pin that feeds A13 on a 128Kx8 is actually the Vcc for an 8Kx8. From this I concluded that if I shifted JP7, JP8 and JP10 away from grounding, and JP9 away from Vcc, the configuration of twenty 128Kx8's would give me 2MB of fully functional cache.  Indeed it does.

I hope this helps someone else.

Here are the settings I established to configure a full 2MB cache using ISSI 61C1024-15Ns DIP32's

JP7  [32]1  means if 3-2-1 then [32] are jumpered and 1 is NC.  

JP8  [32]1  there are no markings for pin numbers so the order

JP9  [32]1  is purely based on JP4's position with respect to

JP10 [32]1  the other jumpers on the system board.

    [32]1 JP1

    [32]1 JP2

    [32]1 JP3

[54][32]1 JP4

That's all. Thanks for reading!

 

Over my dead eMMc...

You find yourself in an impossible situation.  Impossible in that, it's never going to happen to you.

Until it happens.

You have a Chromebook that will not boot.  You discover the internal eMMC is defunct.  Cracking it open, you discover the inevitable truth; the eMMC is soldered on.  

After removing the WP screw, you succeed in preparing a flash drive that includes MrChromebox's BIOS for the Chromebook and a few moments later, it reboots and splashes a welcoming running rabbit.

Your favorite Linux distro now boots from a USB drive and a SD-CARD. But, you now have a new problem. 

The ex-Chromebook will not suspend because the internal eMMC can't be communicated with in full, and inhibits ACPI suspend.  

What now?

You learn by trial and error that after a warm reboot from a successful initramfs prompt, the internal  eMMC is temporarily out of the way, and suspend works.  

You now face the challenge of how to make that eMMC disappear without physical intervention.

You fiddle around with the init ramfs and arrive at a solution.  You realize you're no expert, but it suffices.

You make the business portion of this bundle communicate a shutdown to plymouth, which disrupts any cryptsetup (decrypt password prompts) and follow with a call to systemctl to start the shutdown.target.  An older iteration tried using pkill ^plymouth and a reboot command, but after realizing calling binaries directly is a tad abrupt, you fall back on using modernized system administrator techniques.

You drop this in /usr/lib/systemd/system

#  SPDX-License-Identifier: LGPL-2.1-or-later

#

#  This file is part of systemd.

#

#  systemd is free software; you can redistribute it and/or modify it

#  under the terms of the GNU Lesser General Public License as published by

#  the Free Software Foundation; either version 2.1 of the License, or

#  (at your option) any later version.

[Unit]

Description=Reboot the system if a more than one mmc is found.

Documentation=man:man

DefaultDependencies=no

After=systemd-udev-settle.service

Conflicts=cryptsetup.target

Before=lvm2-activation-early.service cryptsetup.target local-fs-pre.target dmraid-activation.service

Wants=systemd-udev-settle.service

[Service]

Type=oneshot

RemainAfterExit=yes

ExecStart=/usr/lib/systemd/deadmmcreboot

[Install]

WantedBy=initrd.target

And you drop this in /usr/lib/systemd

#!/usr/bin/bash
# 2022-02-06 This ASUS C300 chromebook landing in my possession
# has a defunct internal eMMC. On cold boot, the eMMC can be
# read from the BIOS and even reaches a GRUB menu, and after
# the eMMC is enumerated by the Linux driver, a subsequent
# reboot appears to take the eMMC offline for future warm
# state reboots.  This helper attempts to detect if the eMMC
# is present and reboot at least once.
printMatch () {
    echo "Looks like this list qualifies for a reboot:"
    echo "  $(dmesg | grep mmcblk.:)"
  }
plymouthShutdown () {
    plymouth change-mode --shutdown
   }

for W in $(cat /proc/cmdline) 
  do
  IFS="="
  for X in ${W[@]}
    do 
    if [ ! -z $Y ]; then 
      if [ -e "/dev/${X}" ]; then
        printMatch
        plyouthShutdown
        systemctl start reboot.target
        fi
      unset Y
      fi
    if [ $X = "deadmmc" ]; then
      Y=1
      fi
    done
  done
# A crude way to determine if more than one mmc is detected.
# A fall-through in case the system is not configured with
# a kernel parameter.
# In the case of an ASUS C300 Chromebook with a defunct
# mmc, the kernel enumerates the internal eMMC as 
# mmcblk1
if [ ! -z "$(ls /dev/mmcblk0)" ] && [ ! -z "$(ls /dev/mmcblk1)" ]; then
  echo "Example: vmlinuz ... deadmmc=mmcblk1"
  printMatch
  plymouthShutdown
  systemctl start reboot.target
  fi

You create a directory 02deadmmcreboot under /usr/lib/dracut/modules.d.  Nearly done, you drop this in /usr/lib/dracut/modules.d/02deadmmcreboot

#!/usr/bin/bash

# called by dracut

check() {

    return 0

}

# called by dracut

depends() {

    return 0

}

# called by dracut

installkernel() {

    return 0

    local _arch=${DRACUT_ARCH:-$(uname -m)}

    instmods mmc_block sdhci_acpi sdhci_pci sdhci cqhci mmc_core

    hostonly="" instmods mmc_block mmc_core

    dracut_instmods -o -s ${_funcs} =drivers/mmc 

    return 0

}

# called by dracut

cmdline() {

    return 0

}

# called by dracut

install() {

    inst_simple "$systemdsystemunitdir"/deadmmcreboot.service

    inst_simple "$systemdutildir"/deadmmcreboot

    $SYSTEMCTL -q --root "$initdir" enable "deadmmcreboot.service"

}

Finally you run dracut.  

Because you weren't sure if this was going to work for all dead eMMCs, you remember that you could also try a boot parameter of deadmmc=mmcblk1 just in case, and add that to /etc/default/grub's default options.

Float this idea...

Since the early 1980's, it was known the floating bus in the Apple II would hold the value of a recently sampled value of memory displayed on screen.  When it comes to those who have taken advantage of the floating bus' availability, French Touch, deater (VMW), and John Brooks (VidHD) come to mind.  

One of the issues in using the floating bus is its availability across the various family of Apple II's.  On a //e, register $C022 will return a floating bus value, but on a IIGS it will not.  The IIGS and the //c use a number of the $C0xx IO addresses for newer purposes, and are otherwise unused in a II, II+ and //e.  

Mixed video modes are one of the neat things that can be made using the floating bus. I tested to see if I could reliably sync up the signal to provide any combination of mixed modes as seen in demos by French Touch and deater. I succeeded in making a program that reads the keyboard and based on user input, toggles the desired soft switch for the preferred mode while swapping every other scanline from page 1 and page 2.  Another program uses pages of 256-bytes to indicate any one of four IO registers to read, again, unique for page 1 and page 2.  Both work well enough for my exploration, but more ideas came to mind with regard to the floating bus.

I read that only if an expandable II series slots are not fully populated, it will reflect a recent video signal byte on the floating bus. If a slot is not populated, the address space for that card will be filled with floating bus values; but for the IIgs and some emulators, the floating bus is not exposed, rather just zeroes.  I have not tested if this also holds true for when the slot's expansion ROM space ($C800 - $CFFF).  For the sake of this exercise, slot 1 is vacant and on a //e, if the firmware is not enabled and the slot is vacant, $C100-$C1FF will take on the values of the floating bus.  This can be seen at a monitor prompt (CALL-151 from BASIC), and issuing C100L.

Slot ROM, either in the specific range, or in the expansion ROM address range, can it be used to invoke code? That question came to mind.

• Can the displayed video contents of the floating bus be executed as code?

The answer is yes. There is a one caveat.  This caveat could be used to confound a person debugging code.  Not all instructions have a linear cycle count ratio to the number of bytes the instruction and data consume.  For example, a LDA $C030 (AD 30 C0) takes four cycles; however, the video refresh will pass over four bytes even though the instruction only consumes three.  A new question comes to mind.

• What happens to the byte after the 2nd data byte of a LDA $absolute instruction?

At this time, I have not sought an answer to this question. I suspect the PC is now at the fifth byte and will direct the processor to that byte as the next opcode.

There is one another conditional caveat, and that is the hardware on which the scenario is applied.  On a physical enhanced Apple //e, the PC correctly fetches data for the instruction in at least some situations, such as a JMP (opcode $4C). In AppleWin 1.30, only zeroes are fetched for a JMP command. If at address $0000 a JMP $0300 (0: 4c 00 03), and if text page 2 is used for this example, and the text page contains all zeroes (800:0 m 801<800.bfem) except for address $800, and $800 has the JMP opcode (800: 4c), and the break vector is set to an address with a floating bus ($c030 on a //e), and text page 2 is actively displayed (can be lo-res but not hires), then if a BRK is executed (801g), the break vector redirects the PC to the value of $c030, which fetches the opcode (and data) from the floating bus.  If a BRK, the cycle continues. If not a BRK, the only other expected value is a JMP, which in AppleWin forms a JMP $0000, and in turn the JMP $0300 results.

On a physical //e, with slot 1 vacant, I filled text page 2 with a repeating pattern of AD 30 C0 EA EA EA EA EA except at $BF0 where I put in 4C 00 03.  I displayed text page 2 and invoked C100G.  In this exercise the BRK vector was set to an address that floats ($C050), which would not be used unless the invocation to C100G happened to land on the 00 in 4C 00 03 or some other value from the floating bus came up as 00 - say from the screen holes or during the blanking interval. The Apple //e ended up at the code at $300 every time.  This likely needs more in depth exploration as all the technical resources (Bishop's) describe that the blanking interval and RTZ can turn up some unexpected values.

That's all for now.