Spontaneous numlock

[ab1jx]

Hmm, hacking away.  I thought the update process spewed out the number of the chip, I should have captured the output.  The writes are done I think in usb_keyboard.c in a function called write_kb_fw().  So I gutted it to disable the write for testing.

Code:

int write_kb_fw(const unsigned char *data, int data_length) {
// dummy function
  return 0;
}

int write_kb_fw0(const unsigned char *data, int data_length)  // renamed
{
  unsigned char hex_file[MAX_BINLEN];
  unsigned char read_hex_file[MAX_BINLEN];
  int hex_file_length;
  int rc;
  int try;

  hex_file_length = read_hexdata(data, data_length, hex_file);
  if (hex_file_length <= 0) {
    printf(">>> Failed to read: %d\n", data_length);
    return -1;
  }

  switch_to_boot_mode();

  printf("
[*] Opening in boot mode\n");
  for (try = 0; try < 20; try++) {
    rc = open_boot_mode();
    if (rc >= 0) {
      break;
    }
    usleep(100*1000);
  }

  if (try == 20) {
    printf(">>> Failed to open in boot mode\n");
    goto finish;
  }

  unsigned char reportData[6] = {
    0x5, 0x45, 0x45, 0x45, 0x45, 0x45
  };

  // flash erase
  printf("
[*]Erasing flash\n");
  rc = libusb_control_transfer(devh, 0x21, 0x09, 0x0305, 0,
    reportData, sizeof(reportData), 100);
  if (rc < 0) {
    printf("failed to erase flash\n");
    goto finish;
  }

  sleep(2);

  printf("
[*]Writing firmware...\n");
  // write FW
  for (try = 0; try < 5; try++) {
    rc = write_bulk(hex_file, hex_file_length);
    if (rc == 0) {
      break;
    }
  }

  if (try == 5) {
    printf("too many tries\n");
    rc = -1;
    goto finish;
  }

  printf("
[*]Reading back firmware...\n");
  // read FW
  for (try = 0; try < 5; try++) {
    rc = read_bulk(read_hex_file, hex_file_length);
    if (rc == 0) {
      break;
    }
  }

  if (try == 5) {
    printf("too many tries\n");
    rc = -1;
    goto finish;
  }

  printf("
[*]Comparing firmwares...\n");
  if (memcmp(hex_file, read_hex_file, 0x37fb)) {
    printf("FATAL ERROR FW does differ\n");
    for (int i = 0; i < hex_file_length; i++) {
      if (hex_file[i] == read_hex_file[i]) {
        continue;
      }
      printf(">>> 0x%04x] %02x != %02x\n", i, hex_file[i], read_hex_file[i]);
    }
    rc = -1;
    goto finish;
  }

#if 0
  printf("
[*]Writing serial number...\n");
  write_serial_number(1, 0x4100);
  if (rc < 0) {
    goto finish;
  }
#endif

  printf("
[*]Reseting device?\n");
  reset_device();

  printf("
[*]Finished succesfully!\n");
finish:
  close_usb();
  return rc;
}

But that disables too much, now when it runs I only see

Code:

Running STEP-1...

[*]Flashing keyboard updater firmware...
[*]Please reboot now, and run `step-2`.

Somewhere in there it reads some stuff from the flash and writes to the screen, maybe if I disable from "flash erase" to the end?

---

Well, no, it just shows a bunch of addresses. If there's a chip number it's not in the beginning of step 1. I thought I saw one somewhere in the process.

There's a step to unlock or whatever the USB, if you take that out the keyboard and touchpad are disabled. But I read it, and connected from a phone by ssh to do a screenshot and reboot.

[ab1jx]

It's apparently trying many times to open that USB device, those numbers are all the same.  And it's a vendor:model USB address.

https://imgur.com/gallery/FtUemId

[KC9UDX]

I think (not sure) that the only way to know which chip it is, is by physical inspection.

[ab1jx]

So where is this chip located?  Is it part of the keyboard or the touchpad?  Neither is all that expensive to replace, and maybe get a chip without the 8-write limit.  Seems like each was under $20 but I'm not sure they're still available.

I probably wouldn't spend $20 to fix it because the problem isn't that bad.  I've never used the numlock anyway, and now I know I can turn it off with Print Screen or Pause (which I've also never used) I'm not bothered by it.  Some other keys are affected but I'm not sure what they do anyway.

Off topic but I'd love to see a Raspberry Pi 3B in a laptop case with the same battery and display.  Much lower power drain I think but adequate CPU power, especially if you utilize the GPU.  I have 4 of them now and a few Zeros.  A ZeroW with an external USB sound card only draws 1/4 amp from 5 volts.  And seems to play music just fine despite the single core CPU.  It would run 40 hours on the PBP battery.  Headless but you can ssh to them, or run nginx.  And recording on batteries avoids all hum, I used my PBP that way last summer, but it would only run about 6 hours.

[KC9UDX]

I can hardly find any good information on this. I'm starting to think it's on the main board, but I can't find any high resolution images to look for the chip. I'm not able to take my PBP apart to lol for it right now.

[ab1jx]

Yeah, that chip's pretty tiny, it could be hiding anywhere.

But the board's blue, there might not be many of those.  And those 4 circles look like test points of some sort.

There's a disappointing lack of pictures of the inside of the PBP.  I need to open mine up to deal with a stuck hinge so maybe I'll take some.  Have Nikons will travel.  Lighting I'm trying to figure out still.  A copy stand would be ideal but I don't have one, I do have a good tripod though, and a real DSLR.

I think looking up the numbers on the back of the keyboard might get somewhere.  But I'm still typing on mine.  I do  have other computers.

[dsimic]

My apologies for the delayed response.  I went through all replies posted in the meantime, and here are a few comments from my side.

Probably everybody has localectl since it's command line, My Debian and Manjaro both have it without installing anything special.  In Debian I see:

Code:

System Locale: LANG=C.UTF-8
      VC Keymap: n/a
      X11 Layout: us
      X11 Model: pc105

I was just booted into Manjaro and I was seeing a UK keyboard layout.  " displayed as @ was the first thing I noticed about it.

On my PineBook Pro with ANSI keyboard, running Manjaro ARM, this is the output of localectl:

Code:

   System Locale: LANG=en_US.UTF-8
       VC Keymap: us
      X11 Layout: us
       X11 Model: pc105+inet
     X11 Options: terminate:ctrl_alt_bksp

If you want, I can find the Manjaro ARM setup script that configures the keyboard layout, although it should contain no "magic".

I was carefully pushing Fn, then a key, then letting up the key, then Fn because I was trying to see the Fn key.  And redirecting the output to a file so I wasn't actually seeing anything.  And I had rebooted and done this before I started X.

But I don't see a scancode for Fn.  There should be one hex number that's in all of them and there isn't..  I'm not sure what the pairings of scancodes are, maybe press and release.

The Fn key is also "invisible" on my PineBook Pro, and it should be that way because the Fn key is supposed to be handled entirely by the keyboard controller.  In other words, the Fn keys on laptop keyboards have been invented as a space-saver feature, and the effects of pressing an Fn key (i.e. changes to the generated scancodes) should be handled entirely by the keyboard itself.

What I can gather (barely) is that you get the same results on different operating systems, with different U-boots.  So the problem is in the keyboard itself.  It's either the keyboard firmware, or the keyboard switches.

I'm also inclined to think that something is wrong with the keyboard.  Updating the keyboard firmware again changed nothing, so there almost certainly must be something wrong with the keyboard.

I can hardly find any good information on this.  I'm starting to think it's on the main board, but I can't find any high resolution images to look for the chip.  I'm not able to take my PBP apart to lol for it right now.

According to page 20 of the PineBook Pro schematic, the SH68F83Q IC is located on the main board.  The schematic puts it behind the J6 connector (#7 in the picture), which receives the keyboard's ribbon cable.

[ab1jx]

Nah, I ditched Manjaro (again), went back to Debian Bullseye.  But yesterday I had my PBP booted into mrfixit Stretch, Debian Bullseye, and Manjaro.  The numlock key works exactly the same in all of them.  And I'm wondering if it started happening when I did the pinebook-pro-keyboard-updater 4 months ago.  Could it affect different machines differently?  Isn't there a way to put the old code back?  I guess you would have had to have saved it.  That's a cloned, repackaged 8051 I think, https://en.wikipedia.org/wiki/Intel_8051, I was never into them.

The UK layout was partly an experiment, but it didn't change the numlock.  The only problem I have with it was when the numlock came on and I hadn't figured out yet to use print screen or pause to turn it off.  So it's soldered into the main board, it can stay there then.

[slyecho]

For me the keyboard firmware updater that was in the stickied thread in this forum didn't work that well. It left a lot of the fn keys with bad mappings and there were some other things. I'm currently using the firmware fork by jackhumbert.

The positive was also the trackpad firmware being much improved.

One caveat though: I got my machine in January 2019, early 2019 I applied the update. I can't know what kind of changes the firmware hackers may have done in the mean time and how the hardware design could have changed in the factory since then. I'm not rushing to update it again especially since I've read on these forums some people having thouble with updates and I wouldn't suggest anyone else to do so unless they experience problems.

[ab1jx]

January 13, 2020 I got mine. I've already flashed it twice now, I won't do it again unless I open it and find it's not the chip with the 8-write limit. In the Redit thread https://old.reddit.com/r/PINE64official/...appointed/ somebody presents the hypothesis that the chip with limited writes also only has 14 K of space instead of 16 K, so some of what is being written gets lost. I'm not sure I believe that, but most of my top row keys don't do much on the Fn functions anyway. Insert works, Print Screen and Pause both toggle NumLk, beyond that nothing I think.

Replacing the mainboard at $100 seems the only sure fix. https://pine64.com/product-category/lapt...46c16e2e66 I'll just live with it.

sh61f83 datasheet https://datasheetspdf.com/pdf-file/12528.../SH61F83/1
sh6f83 datasheet https://datasheet4u.com/datasheet-pdf/Si...?id=932021

So yes, 14k vs 16k, 8x write limit vs none. Somebody bought the wrong parts.