14_raspbooin64

[terenctbrobots]

I haven't been able to get to to work with either rasbootcom or usbimager -S. When I power up the pi-3 while the client is waiting to send the image I get:

Raspbootcom V1.0

Listening on /dev/ttyUSB0

RBIN64

sending kernel kernel8.img [13216 byte]

terminate called after throwing an instance of 'UnixError'
what(): sending kernel: Resource temporarily unavailable
Aborted (core dumped)

I've been using minicom to connect via /dev/ttyUSB0

I've tried it with sudo as well just in case ...

Do I need to update my RPI3 firmware? I haven't touched it since I got it ages ago?

[bztsrc]

Do I need to update my RPI3 firmware? I haven't touched it since I got it ages ago?

Well, I don't think so, however using the latest firmware is always recommended and it wouldn't hurt in this case for sure.

terminate called after throwing an instance of 'UnixError' what(): sending kernel: Resource temporarily unavailable
Aborted (core dumped)

This indicates an issue not with the RPi, but with the PC-side program. It should not throw an abort. What happens if you use USBImager -S? Can you see any relevant information in "dmesg" output after the problem happens? Can you give a try to my raspbootcom rewrite (just to rule out problems with raspbootcom, however this much more like a bug in your usb driver maybe)?

Cheers,
bzt

[terenctbrobots]

USBImager -S does the same thing with the same error.

I tried fiddling around with rasbootcom and changed opening the /dev/ttyUSB0 in blocking mode instead of blocking:

    while(keep_running) {
      // Open serial device
     if ((serial_fd = open(argv[1], O_RDWR | O_NOCTTY)) == -1) {
     // if ((serial_fd = open(argv[1], O_RDWR | O_NOCTTY | O_NONBLOCK)) == -1) {
        // udev takes a while to change ownership
        // so sometimes one gets EACCESS
        if (errno == ENOENT || errno == ENODEV || errno == EACCES) {
          fprintf(stderr, "\r### Waiting for %s...\r", argv[1]);
          sleep(1);
          continue;
        } else
          throw UnixError("open serial");
      }

I get a little further now but after the 'success' message, raspbootcom doesn't exit OR the kernel start on the PI.

Raspbootcom V1.0
### Listening on /dev/ttyUSB0     
RBIN64

### sending kernel kernel8.img [27144 byte]
### finished sending

I assume that the kernel should start right after the upload? I'm uploading the 09_framebuffer tutorial btw if that makes any difference...No Homer;(...... I will work on it some more this weekend by adding more debug code.

[terenctbrobots]

So besides the changes above, I had to send 8 extra bytes at the end. Not sure why...the size calculation seems ok. It works now....

Code added to end to send_kernel function...

  fprintf(stderr, "### finished sending\n\r");

  char end_buff[8] = {0};

  int val = write(fd,&end_buff,8);

  if (val == 0) {
    fprintf(stderr,"Error writing");
  }

  // close(fd);

  keep_running = false;

[dashiad]

I got the same problem (note: i was running raspbootcom in Windows linux subsystem). Can confirm the patches by @terenctbrobots fixed the issue.

[bztsrc]

It looks like raspbootcom is sending and incorrect size? Seems unlikely. My other guess would be that the serial device is opened in buffered mode for some reason (could be due to a driver issue)? I don't know.

However there might be a precedence related UB in the code. If it's evaluated as

char c = (size >> (8 * i)) & 0xFF;

then everything is fine, but if it's evaluated as

char c = ((size >> 8) * i) & 0xFF;

then wrong size will be sent. I'm not sure, this would mean a compiler bug, which is also very unlikely. I'll have to take a closer look and do some tests. However if it's not just raspbootcom, but USBImager -S fails too, that suggests there must be an issue on the RPi side. Since that code is extremely simple, I'm not sure what that could be. Further tests required.

You are both using WSL right? Could you please try the native Windows version of USBImager -S?

Cheers,
bzt