Raspberry Pi Zero W


 
Yeah I tried that 8GB, a 16GB Sandisk class 4, a 16GB Sandisk UHC, a 32GB Samsung EVO, and a 4GB Sandisk class 4 and they all worked on both devices, so I don't think it is an SD card problem. At least I hope we're not still having SD compatibility issues still.
 
Tried with a 2GB sd card and still no luck.

Decided to boot up a linux VM to look at the sd card and everything looks fine.

Code: 
Disk /dev/sdb: 1977 MB, 1977614336 bytes
61 heads, 62 sectors/track, 1021 cylinders, total 3862528 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x5452574f

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1   *        8192       47103       19456    c  W95 FAT32 (LBA)
/dev/sdb2           49152      180223       65536   83  Linux
 
Well this is just great, I got the Zero W from Adafruit tonight. Date of manufacture was Week 14 of 2017 and both say Zero W v1.1. Flashed the standard image to a microsd card and it booted right up, no problem whatsoever.

Between this and the original I have, the components look identical. There is just some additional silkscreen on the back by the FCC/CE marks. I'm not sure where to go from here. Do non-working units have an Elpida RAM chip over the CPU like both of mine do?

Apart from that, does anyone with a non-working unit want to sell it to me or lend it to me so I can take a look? I'd want the Zero W and the microsd in case it is one or the other. I'd pay shipping obviously if I was just borrowing it which would be ideal, else I can buy your unit or ship this working one out to you as a swap.
 
Can you post the exact image you're using.

Here's a pic of my Zero W.

14Z35qi.jpg

383b5wE.jpg
 
Last edited:
Steve_M said:
Can you post the exact image you're using.
Click to expand...
Yeah good idea. The one on the left is my original and the right is the new one I received yesterday. Looks like my original hardware matches yours. I am leaning toward thinking this isn't a Pi hardware problem which is baffling that the software fails so spectacularly.

(click for bigger)

 
Looks like we have the same units from 2016.

I assume you've confirmed that things boot up with an image downloaded from your heatermeter.com server?

What software or process are you using to write the image to the card? Can you post the md5 hashes of all the boot files on the sd card?

It feels like there's 1 step missing in the process for it to work consistently for you, but not for others.

Here's what I show:

Code: 
MD5 (COPYING.linux) = d7810fab7487fb0aad327b76f1be7cd7
MD5 (LICENCE.broadcom) = 4a4d169737c0786fb9482bb6d30401d1
MD5 (bcm2708-rpi-0-w.dtb) = 82c3830bb939eb01cfb837b97f9dd86b
MD5 (bcm2708-rpi-b-plus.dtb) = 32b4ae79519f797eed192e7922966abf
MD5 (bcm2708-rpi-b.dtb) = 560bd6c7181fbc070b374a9e7009af71
MD5 (bcm2708-rpi-cm.dtb) = c1e6c06bd3504722dee9fe30b640ca58
MD5 (bootcode.bin) = 90f09cba99869fd2d4eda0b533546ffe
MD5 (cmdline.txt) = 9b31b9a706e4d31698eff3fe9a779e45
MD5 (config.txt) = 350b0af4e6c7d84e9b0e875f93d94ae6
MD5 (fixup.dat) = 796c3ab1bf712e1ea10f02ce9e78da5a
MD5 (fixup_cd.dat) = 61b424d7509b565ffd682ad2e914ab53
MD5 (kernel.img) = 9c995511800ef513800e0f9024d2e861
MD5 (start.elf) = 9df32a895275394f28c71231bca2c21b
MD5 (start_cd.elf) = f17ada2b681c2ba9722d7a9c53bdb725
 
Last edited:
I've got the exact same thing, apart from config.txt which has my wifi info in it. I've also tried with an unconfigured image and it also has no problem.
Code: 
root@LEDE:~# md5sum /boot/*
d7810fab7487fb0aad327b76f1be7cd7  /boot/COPYING.linux
4a4d169737c0786fb9482bb6d30401d1  /boot/LICENCE.broadcom
md5sum: can't read '/boot/System Volume Information': Is a directory
82c3830bb939eb01cfb837b97f9dd86b  /boot/bcm2708-rpi-0-w.dtb
32b4ae79519f797eed192e7922966abf  /boot/bcm2708-rpi-b-plus.dtb
560bd6c7181fbc070b374a9e7009af71  /boot/bcm2708-rpi-b.dtb
c1e6c06bd3504722dee9fe30b640ca58  /boot/bcm2708-rpi-cm.dtb
90f09cba99869fd2d4eda0b533546ffe  /boot/bootcode.bin
9b31b9a706e4d31698eff3fe9a779e45  /boot/cmdline.txt
d6484974214750005819966f5cdaeb1b  /boot/config.txt
796c3ab1bf712e1ea10f02ce9e78da5a  /boot/fixup.dat
61b424d7509b565ffd682ad2e914ab53  /boot/fixup_cd.dat
9c995511800ef513800e0f9024d2e861  /boot/kernel.img
md5sum: can't read '/boot/overlays': Is a directory
9df32a895275394f28c71231bca2c21b  /boot/start.elf
f17ada2b681c2ba9722d7a9c53bdb725  /boot/start_cd.elf

I just download the pre-configured image from https://heatermeter.com/dl/ (snapshot, Pi A / B / Zero /etc). Open the img with Win32DiskImager 1.0, select the lowest drive letter for the microsd (it shows up as E: and F: on my Windows 10 Pro installation), and write. Pull it out of the computer and pop it into the Pi and away it goes.

I also checked the microsd in a Linux machine and see the same partition layout you showed in your 2GB card, although my fdisk does not report geometry information. I find it interesting you have different CHS geometry than the partition table is created with which uses 4 heads, 63 sectors. I'm not sure if this makes much difference in the partition table because regardless of the simulated geometry, the sector numbers for the partitions match up. I've also got the rootfs partition aligned on both a 4MB and 8MB boundary (at the 24MB point) to match the most common erase size blocks of sdcards for performance reasons but it also eliminates the possibility that the squashfs straddling a boundary would be an issue.

I just wish I could reproduce this so I could at least start shotgunning a solution until I find something that boots and then work backward!
 
Can someone try this image I've created? https://heatermeter.com/devel/snapshots/bcm2708/
Code: 
lede-brcm2708-bcm2708-rpi-squashfs-sdcard.img 7ec32f1550ae625b1213f70d4dad063b (md5)

The squashfs inode table is stored at the end of the filesystem data, so I am wondering if the padding operation I do on the end (128kb) is causing the last erase block of the SD card to not be completely written which would corrupt the inode table? I'm kinda grasping at straws here but who knows what could be causing this, and causing it so consistently.

For what it is worth, I use a Transcend TS-RDF5K USB 3.0 SD / microsd card reader to flash the image.
 
The new image is now working for me. Where it wasn't working previously. I'm just using a Samsung 2GB microsd card. Let me know if I can provide any info.
 
The new image doesn't work for me.

It looks like the problem on my end is with the Apple Pi-Baker app that I've been using. I was on 1.9 so I upgraded to 1.9.4 and it's still problematic. The data is clearly being written to the sdcard and you can view and modify the files, but there's clearly something not being written correctly to the card.

If I drop down the command line and use dd, I'm able to boot off the smaller images without problem.

I can also reproduce it by zeroing out the sdcard and using Apple Pi-Baker and it will fail, and then use dd and it will work again.
 
Well all this is certainly interesting. I can't imagine there's some sort of bug that truncates the image when it is written to the SD card because that would also corrupt a larger image unless it happened to hit a multiple of some magic block size.

If I look at the image generation, the images created with the original script and without the "wipe out the user data" padding they are identical apart from one having 128kb of zeros at the end.
Code: 
Original (Broken)
01c2c1b0  00 01 59 5a 4c b9 42 00  00 00 00 00 5a c0 42 00  |..YZL.B.....Z.B.|
01c2c1c0  00 00 00 00 04 80 00 00  00 00 c4 c1 42 00 00 00  |............B...|
01c2c1d0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
01c4c1d2

Workingish?
01c2c1b0  00 01 59 5a 4c b9 42 00  00 00 00 00 5a c0 42 00  |..YZL.B.....Z.B.|
01c2c1c0  00 00 00 00 04 80 00 00  00 00 c4 c1 42 00 00 00  |............B...|
*
01c2c1d2

I'd hate to just keep adding more zeros to the end until everything just magically starts working. Also the image's size that seems to work better (29540818 bytes) isn't a multiple of even 1KB, much less 1MB or 4MB or 8MB.

EDIT: Although the "larger" old image (with the full sized live ext4 system) is exactly 36MB, a multiple of 4MB.
 
Last edited:
The "conv=sync" option in dd is what made the difference.

sync: Pad every input block to the input buffer size. Spaces are used for pad bytes if a block oriented conversion value is specified, otherwise NUL bytes are used.


When specifying a block size, which is normal to speed things up, I tried bs=4m, bs=2m and bs=1m and these all resulted in an SD card that wouldn't boot. When I used the conv=sync option, I was able to successfully boot the SD card each time. I could also get it to successfully boot without using conv=sync and not specifying a block size (bs=Xm) but the result is very long process to write the image to the SD card.

I also reported this to the author of the Apple Pi-Baker app and he added the conv=sync option and now it's working as well in v1.9.5 that he built for me to test.
 
Interestingly, I tried building the image yesterday with bs=128k conv=sync, thinking that my weird method piping the two image pieces together was what was causing the image to be broken. What I ended up with was the exact same image (byte-wise) except it was aligned to a 128k block size instead of the image size + 128k.

So is it that nothing was broken in the image to begin with, but there are bugs in the writer applications that cause problems? That would make sense why the exact same image with the exact same Pi with the exact same microsd would work for some but not others. It doesn't explain why the shorter image worked for some where the longer image did not though. The image does need to be the bigger size to wipe the user data in the overlay that follows the squashfs, as Ralph noted that his configuration remained intact after flashing (which it should not unless done through the webui).
 
This is driving me bonkers. I need to buy a mac now to run ApplePi-Baker and compare the actual image written to the microsd card to see where it breaks. I mean even without conv=sync, all the bytes in our image file should end up on the microsd, without a corrupted squashfs on it.

Steve, when you used dd with a block size but no conv=sync, did dd report the same number of bytes written and have the +1 to the number of records to indicate a partial record write too?
Code: 
bs=1M
28+1 records in
28+1 records out
29540818 bytes (30 MB, 28 MiB) copied, 0.058228 s, 507 MB/s

bs=2M
14+1 records in
14+1 records out
29540818 bytes (30 MB, 28 MiB) copied, 0.0178002 s, 1.7 GB/s

bs=4M
7+1 records in
7+1 records out
29540818 bytes (30 MB, 28 MiB) copied, 0.016848 s, 1.8 GB/s
 
You must log in or register to reply here.

 

Back
Top