laptop2pi

You remember an earlier log where I couldn't get the SD card making script working on Pixel_x86, and had to fall back to using another Pi? It turns out it was the fault of my Compaq craptop. The script works fine on a couple of other laptops, so I've changed the instructions and parts list.

This Compaq has given me grief in the past: it has several odd behaviors, including not being able to boot from the Zero. I think it's time to retire it.

I made several edits to the instructions to make them clearer. I also uploaded a couple of new scripts, and changed the setup script a bit. Now NAT works easily to allow the Zero to access the Internet. And remote X is easier to use.

I'm going to mark this project completed. That doesn't mean I won't be making changes in the future, just nothing major.

I've finished the write-up, and added some pictures. I hope my writing isn't too confusing.

Remote X is running, and I added instructions for it to the write-up.

I've been using the laptop (Frankentop?) on my daily commute, and it's working well. Now I can get all of the unfinished/unupdated bits of my projects taken care of!

Next is trying to get the SD setup script running under Pixel_x86. As I mentioned before, I can't completely copy the ISO image using the laptop. I think it's something having to do with udev and automounting. Wish me luck!

I've finished a preliminary write-up. After writing everything down it looks a lot more complicated than I remember when building mine. It probably shouldn't be someone's first project.

It desperately needs pictures! I've already taken a few but I haven't posted them. I didn't take any details of the USB wiring though. I should probably solder a cable to an old USB jack and take one. Maybe in the next few days.

I discovered something interesting: I thought this project was working on my Mini 510, but it turns out I hadn't tested it enough. It hangs during Xwindow load, and I haven't been able to figure out the reason why. I only testing the 510, I won't actually be using it, so it doesn't cause me a problem personally. Therefore you should test your own laptop to make sure this setup will work. As a workaround you can use a flash drive to boot your laptop.

I also had a problem which consumed a bit of time tracking down: an SD card set up with the script would work on a laptop for the first boot, but on the second it would hang. The card that was set up manually worked fine. What was different? After a couple of hours I tracked it down to this: when I wrote my setup script I decided not to put dwc2 in the modules load file. I assumed it wasn't necessary since I put the dwc2 overlay callout in the /boot/config.txt file. Turns out it WAS necessary. But why did it work at all as a mass storage gadget without dwc2 loaded? The only thing I can think of is that the normal USB driver already contains some gadget supporting code, but not quite enough. Maybe the foundation is slowly combining the two drivers. But working on first boot, where there isn't a second partition set up on the mass storage gadget, then failing when a second partition is present, is a bit of a puzzle. I'll have to remember to test all changes PRIOR to writing instruction/setup scripts in the future. It's the old "change one thing at a time" rule I should have learned a long time ago.

And here's another bit of weirdness: long or failed boots if the laptop SD card reader has something in it. Even if it's just an empty micro to full size SD adapter. This only happens during boot: the reader can be used after startup. I figured this out almost by accident: one of my laptops had a card adapter in it, the other didn't. It pays to strip things down to basics when testing.

It's something to watch out for on your own laptop.

I started writing down the steps I took to set things up. It got pretty long, so I decided to write a setup shell script to do all the work. It'll come in handy when a new version of Raspbian or Pixel_x86 comes out and I need to make a new SD card. And of course it'll make it easier for my dear readers to do this themselves. The setup script should be well-documented (doesn't everyone say that?), so have a look at what I did.

I learned a lot about scripting partitioning software. Did you know you can call parted with parameters to do simple tasks such as add or delete a partition? Not documented is the fact that you can't do negative sizes, such as -4000, which means "4000 meg from the end of the disk". Which I of course needed to do. Parted thinks it's a parameter since it starts with a dash. So I had to pipe the command into parted using echo. Kind of makes the scripting ability useless.

This workaround was necessary because I decided to use a partition instead of an image file as a backing store for the mass storage gadget. Why? it should be a bit faster. Or so I imagine.

I also had to do some funny things to try and find the drive designation of the SD card. I didn't want to have the user enter this if at all possible, since it takes a fair bit of Linux experience to find this out reliably. I personally have no problem using dmesg for this, but then I've been doing this for quite a while.

I also ran into a bit of a weird problem - Pixel on a laptop behaves quite differently than a Pi when it comes to disk mounting and copying. First, when you eject a disk on the Pi using the desktop control, the disk can still be manually mounted. But on the laptop, when you eject, the disk disappears. The kernel no longer sees it. You have to unplug and re-plug it to get it back.

But there's a more vexing problem - if I make a new partition and then copy the Pixel_x86 iso to it I can only copy part of it. It seems as soon as I copy the first few sectors. which contains the partition table, the kernel recognises it as a kind of extended disk. And since this disk is marked read-only (because it's a DVD image), the kernel suddenly halts copying. I tried copying from the beginning of the disk with an offset, but couldn't get this to work either.

A Raspberry Pi doesn't exhibit this behavior. So you'll need an operating Pi to set things up instead of just using the laptop running Pixel_x86 from a DVD or flash drive. I was trying to avoid this since folks might not have one available. I don't feel too bad though, a second Pi is a handy thing to have when working with Pi Zeros.

There's one problem with this setup: shutdowns.

The laptop needs to save state to the mass storage device when halted in persistent mode. After the laptop has halted the Pi Zero needs to shutdown properly. But you can't communicate with the Zero to shut it down because the laptop is halted. What to do?

I solved this with a watchdog shell script on the Zero. It first waits until the laptop responds to pings, then when the laptop no longer responds it shuts down the Zero. That way it gets a graceful shutdown after the laptop halts. I also built in a timeout: if the laptop doesn't initially respond for three minutes the Zero shuts down anyway. This handles the case of the laptop failing to boot up properly. You also shouldn't shut down the Zero from it's command line: I'll probably remove or rename the shutdown and poweroff commands to fix this.

Yes, I know a poweroff button on the Zero would be the best solution. There's even a device tree overlay to make this simple. But I'm trying to keep this a minimal project.

You also should never use the poweroff command on the laptop - it kills power to the Zero while it's still running. (That was a bit of a surprise the first time I did it - I hadn't thought things through.) That's bad for the SD card. So, I'll probably remove the poweroff binary, make a new shutdown replacement shellscript that can only do halts, and modify the shutdown command in the window manager. That should cover all cases.

I'll do the file munging later. For now I'll just have to be careful!

I finally figured out configfs and got everything working on my Mini 510. I had to read several how-tos and the kernel documentation to understand it.

It just goes to show you can solve almost any problem with software!

I was able to mount the Zero in the drive bay by modifying the original hard drive carrier. I could have just stuck it down with foam tape, but this way I can remove the Zero by undoing one screw. Kind of handy if you need to change the SD card. Running the USB cable required only a bit of plastic trimming. I broke off part of the shell of one of the USB ports, stripped the cable end, and soldered it to the port. A blob of hot glue protects the connections. After the laptop was re-assembled I could hardly tell it was modified.

And there's enough room in the drive bay for any (small) project I'm working on!

Using the composite gadget module the Zero is emulating a flash drive and an Ethernet device at the same time. Like usual, it was pretty easy because of other people's hard work documenting what they did.

The problem is it works and boots up Pixel_x86 on everything but my HP Mini 510. I think it's BIOS is somewhat broken - it's probably enumerating only the first function of the composite device (which isn't mass storage), then giving up.

That means I'm going to have to bite the bullet and learn how to use libcomposite and configfs. This should give me more control over enumeration order. I've been avoiding this since it looks complicated and easy to break. But I also need to learn it for some of my other projects, so off I go.

I have gadget mode working as an Ethernet adapter. There are lots of good how-tos available for this which helped greatly. That's one of the perks of using a Raspberry Pi I guess.

Then I realized something interesting - gadget mode can emulate more than one device. So the Zero could be both an Ethernet gadget and a mass storage gadget. That would allow me to boot the laptop from the Zero, no USB flash drive needed. That's a bit of a bummer - I no longer get to use that cute little flash drive I just bought.

So things just got even simpler. At least hardware wise: software configuration will be more difficult.

Well, that design didn't last long.

I bought a really tiny flash drive and loaded Pixel_x86 on it. It worked really well with the HP Mini. Pixel_x86 also has a persistent mode that stores changes to the USB drive if you boot from one, and works really well. So I decided the hard drive was redundant, and removed it to save weight. Thus, I was faced with a rather large cavity where the drive had been:

Then it hit me - why not put a Pi Zero there? I could run a cable inside the laptop from the Zero to one of the USB ports. I could then access the Pi via USB gadget mode, and everything would be internal and protected.

My objections (see previous log) to using gadget mode to access a Pi were nullified. So the portable WiFi Pi is no more. And the project just got a lot simpler and less expensive.