WARP Project Forums - Wireless Open-Access Research Platform

welsh wrote:

If you add back the windows partition, are you still able to use the SD card?

I've tried that, but the card still doesn't work. I also checked the card, there is no bad sector.

yq@yq-LIFEBOOK-E751:~$ sudo fdisk -l

Disk /dev/sda: 640.1 GB, 640135028736 bytes
255 heads, 63 sectors/track, 77825 cylinders, total 1250263728 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: 0x000af71e

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *  1242187776  1250263039     4037632   82  Linux swap / Solaris
/dev/sda2            2046   656250879   328124417    5  Extended
/dev/sda5            2048   656250879   328124416   83  Linux

Partition table entries are not in disk order

Disk /dev/mmcblk0: 1977 MB, 1977614336 bytes
53 heads, 48 sectors/track, 1518 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: 0x956f0f9c

        Device Boot      Start         End      Blocks   Id  System
/dev/mmcblk0p1            2048       67583       32768    b  W95 FAT32
yq@yq-LIFEBOOK-E751:~$ sudo dd bs=512 seek=131072 if=w3_WARPLab_7.4.0.2RF.bin of=/dev/mmcblk0
18032+1 records in
18032+1 records out
9232444 bytes (9.2 MB) copied, 2.24311 s, 4.1 MB/s

Hi Welsh,

Thanks for your reply. I also notice that the partition of the SD card is different from the original one. Because I use fdisk to partition my SD card, and the default start sector is at least 2048, as show below.

How do you partition the SD card before shipping? fdisk doesn't allow me to start the partition with sector 2. I guess the problem maybe solved if I can revert the SD card to the original state when shipping.
-------------------------------------------------------------
Command (m for help): p

Disk /dev/mmcblk0: 1977 MB, 1977614336 bytes
4 heads, 16 sectors/track, 60352 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: 0xe32a7195

        Device Boot      Start         End      Blocks   Id  System

Command (m for help): n
Partition type:
   p   primary (0 primary, 0 extended, 4 free)
   e   extended
Select (default p): p
Partition number (1-4, default 1): 1
First sector (2048-3862527, default 2048): 2
Value out of range.
--------------------------------------------------------------
First sector (2048-3862527, default 2048):

welsh wrote:

Unfortunately, I'm not an SD expert. 

WARP v3 starts reading the SD card 64 MB from the beginning of the disk (ie Slot 0 is at 131072 * 512 bytes / block = 2^26, or 64 MB).  Then the next slot begins 16 MB (ie 32768 * 512 bytes / block = 2^24, or 16 MB) from the beginning of the previous slot.  See here for the behavior of the LEDs during SD programming.  When there is no data in a slot, then the LED will never fully illuminate. 

One thing I noticed is that the configuration of the SD card is different from what we ship:

Code:

Disk /dev/sdd: 1977 MB, 1977614336 bytes
255 heads, 63 sectors/track, 240 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: 0x00000000

   Device Boot      Start         End      Blocks   Id  System
/dev/sdd1               2       62505       31252    b  W95 FAT32

specifically, the heads, sectors/track, and cylinders are different.  However, I'm not sure if that makes a difference when using DD.

At this point, I'm not sure why it is failing (I assume you have checked the dip switch settings to make sure they are set to slot 0; and that you have seen other cards work on the same kit). 

The only other thing to try would be to get a hex / disk editor and try to view the contents of the card to see that dd is writing the bin file to the correct address (i.e. starting at 64MB offset from the beginning of the card for slot 0).

Glad it's working, and thank you for reporting back. We've never seen this issue, but it's very helpful knowing your result to share with future users.