When I plug the Quad on my PC a new drive is created and I can use it.
But in upgrade mode (with the first button held down during power up) nothing appear.
When I make a lsusb there is no visible difference in the two cases.
Inthe first case :
Bus 002 Device 004: ID 0483:5720 SGS Thomson Microelectronics
In upgrade mode:
Bus 002 Device 005: ID 0483:5720 SGS Thomson Microelectronics
Same ID in both cases.
sorry that we have not considered it in linux. If you need to upgrade the firmware, computer with windows system maybe needed…
Ok, but what are the differences between the two modes? May be I can do something under Linux for the virtual drive in upgrade mode be recognized?
What suck me is that they seem to appear with the same ID so I don’t understand why the drive isn’t recognized and automatically mounted.
I am a little confused about this discussion. I always loaded the appropriate files with the Quad in normal mode. Then I would recycle the Quad power into upgrade mode to install the changes. I never had a reason to copy files to the Quad USB drive while in the upgrade mode. Why can’t you do the same? You didn’t specify if your PC was a Linux or not, so the assumption would be that it is Linux. Place the upgrade files onto the Quad USB drive while the Quad is in normal mode?
Thank you Lygra for the answer.
Your right my PC is a Linux.
I already try to copy in the USB drive and launch the upgrade mode after but nothing happen.
At the moment I’m not sure the different application release are stable so the only thing I tried to modify was the logo. And the only way that worked was switching to Windows.
I’am not sure we are using the same version of firmware that could perhaps explain that our Quads behave in a different maner.
My Quads says:
In normal mode
DS203 Mini DSO SYS Ver 1.31
DS203 Mini DSO APP Ver 2.30
In upgrade mode
Device Firmware Upgrade V3.10
From my experimentations what is happening is that the drive is being removed monetarily so that the ARM can check the files, about every other second or so. On the MAC this shows a drive coming and going. On window, it seems to tolerate it better, but there the drive is not all the way gone, just enough that windows rescans the disk when it comes back, but not enough that it closes the window. So in this case you copy in the file, flash the window refetches and the file has the changed name. A cute hack. Unfortunately Linux and Macos do not tolerate this hack. (I am guessing based on a quick view on some logs, but something like this is what the linux and mac host see.) To make this work there are a few easy ways to deal with it. The best would be to make a small change to require a button press to move to the next step in the process if a different host or button is detected during startup. That would allow non windows users to upgrade there system, but have to press a different key with each file.
On Linux (Ubuntu 10.04 in my case) when in upgrade mode the drive is never recognized, neither at boot time where the drive is present until you copy a file. That’s why I thought that this drive was seen by the OS not as a usual drive.
On mac os it is seen as a disk, but about as long as it takes to open a window to the device is as long as it stays there. At that point it throws an improperly removed drive while it is active error message up. It appears that every time it checks to see if files have changed it disconnects from the OS. I am assuming that it is appears a type of disk, since it sees a disk appear, but it drops the connection faster than you can mount and copy a file to it. Slowing the timing could help, but I would prefer a press a button before it goes away option which would work in both worlds. From reading the logs it appears that the OS sees it as a flakey disk connection, so it is doing a fsck every time it reappears. Thus decreasing the usable seconds to effectively nothing.
Mac OS is always trying to write hidden files to usb disks.
.Spotlight-V100
.Trashes
._.Trashes
.disk
.fseventsd
maybe disabling this feature using “BlueHarvest” or similar program would resolve issues on mac… but I haven’t tried it.
Yes you’re right, Linux behaves the same way. Some track to explore.
If that is issue than it would be best if dso quad could automatically send those files to NULL… much better than messing with Mac OS/Linux on every computer
This is unfortunate. I would have figured being an open source project we would have linux support. I don’t run windows on my machine.
I’ll try to see if I can find a copy of Windows and run it in a VM, but this is a massive inconvenience.
I also support modding the firmware (if possible) to have the user tell the device when to disconnect the disk. To those who are more knowledgeable: does this sound possible?
If you need test run I can test on both platforms, I can find a few other platforms as well.
Having an open tool chain is as important to me as having an open device.
From a programming perspective it is a simple change, but it sounds like they are using a bootloader they got from somewhere else to do this. Of course the upgrading of the bootloader is not something to be done lightly. I am surprised they went away from the dfuse bootloader that the previous projects used, as we had developed an open source version of that one. I can see how this one, if it worked right would be more accessible to noobs, but it is a real pain that it was not tested on other systems and as such blocks so many of us.
DO NOT TRY THIS.
I did and it does not work and causes the Mac to get quite upset. The number of disk shown in the Finder keeps growing, one keeps getting popups warning a drive was not correctly disconnected, and some of the bogus disks can not be unmounted.
For the curious it reports that an ever growing number of partitions have been mounted on the device, but the disk utility does not see any of them. BlueHarvest fights with this hack and leaves things damaged. It was a pain to recover from. The rate of creation is not constant. The first several happen at about 1 a second, but the later ones come in batches.
If upgrading the bootloader is dangerous, perhaps a better approach would be finding a way to make Linux/Mac more tolerant of the disk disconnecting (like it is in Windows). Not sure how we would go about this, anyone?
Here’s some data I gathered with: watch -n0.5 “dmesg | tail -n30” (from power on to power off in upgrade mode)
[554837.860066] usb 2-4.4: new full speed USB device using ohci_hcd and address 18
[554837.975360] usb 2-4.4: configuration #1 chosen from 1 choice
[554837.983578] scsi10 : SCSI emulation for USB Mass Storage devices
[554837.987174] usb-storage: device found at 18
[554837.987182] usb-storage: waiting for device to settle before scanning
[554842.989187] usb-storage: device scan complete
[554842.996163] scsi 10:0:0:0: Direct-Access Vertual DFU Disk PQ: 0 ANSI: 2
[554842.997490] sd 10:0:0:0: Attached scsi generic sg3 type 0
[554843.007113] sd 10:0:0:0: [sdc] 1024 512-byte logical blocks: (524 kB/512 KiB)
[554843.014171] sd 10:0:0:0: [sdc] Write Protect is off
[554843.014187] sd 10:0:0:0: [sdc] Mode Sense: 03 00 00 00
[554843.014193] sd 10:0:0:0: [sdc] Assuming drive cache: write through
[554843.040086] sd 10:0:0:0: [sdc] Assuming drive cache: write through
[554843.040103] sdc: unknown partition table
[554843.095511] sd 10:0:0:0: [sdc] Assuming drive cache: write through
[554843.095526] sd 10:0:0:0: [sdc] Attached SCSI removable disk
[554852.395053] usb 2-4.4: USB disconnect, address 18
The key lines seem to be:
...
[554842.996163] scsi 10:0:0:0: Direct-Access Vertual DFU Disk PQ: 0 ANSI: 2
...
[554843.040103] sdc: unknown partition table
...“Vertual” is a misspelling. When I plug in a normal USB storage device I get: (for comparison)
[555282.058217] scsi 11:0:0:0: Direct-Access Lexar JD FireFly 1100 PQ: 0 ANSI: 0 CCSSo the misspelling probably isn’t causing the problem.
As for the “unknown partition table”, how is the drive on the Quad formatted? FAT32? A quick fdisk shows:
[code]Disk /dev/sdd: 0 MB, 524288 bytes
1 heads, 1 sectors/track, 1024 cylinders, total 1024 sectors
Units = cylinders of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x2faff17d
Disk /dev/sdd doesn’t contain a valid partition table[/code]
I find it strange that Windows can see a valid partition table, but Linux can’t.
Rich, how did you go about diagnosing this issue?
I managed to copy a file to it once with: sudo mount -t vfat /dev/sde /mnt/quad && {copy command}
I could ls and see the file, the drive unmounted, and I forgot to try mounting it again before switching off.
Now I can’t seem to get the file copied again, and when I ls, dmesg shows a bunch of:
[556630.715754] FAT: Directory bread(block 25) failed
[556630.715772] FAT: Directory bread(block 26) failed
[556630.715790] FAT: Directory bread(block 27) failed
[556630.715808] FAT: Directory bread(block 28) failed
[556630.715825] FAT: Directory bread(block 29) failed
I also notice that when I initially mount the drive I get something like:
johnny@picard:/mnt/quad$ sudo fdisk -l | grep 524288 -A8
Disk /dev/sdg doesn't contain a valid partition table
Disk /dev/sdg: 0 MB, 524288 bytes
1 heads, 1 sectors/track, 1024 cylinders, total 1024 sectors
Units = cylinders of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x2feff97d
But after trying to read and write I get:
johnny@picard:/mnt/quad$ sudo fdisk -l | grep 524288 -A8
Disk /dev/sdg doesn't contain a valid partition table
Disk /dev/sdg: 0 MB, 524288 bytes
1 heads, 1 sectors/track, 1024 cylinders, total 1024 sectors
Units = cylinders 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
r/w operations seem to cause the disk identifier to change. Strange…
It seems to me that Bure going back to dfuse makes a lot more sense. Admit the mistake and move back to dfuse if possible (with the FPGA). If FPGA is a problem, why not load the FPGA code into the STM and then run the STM to stuff the FPGA. Then load the STM with what it needs. Dfuse v3.01 supports all operating systems and includes 64-bit machines.
No matter what they do going forward, they have devices now with this firmware – they’ll have to support them.
Let’s focus on getting it working.