VSOS UART Shell

[Mark]

Panu,

Thank you for the assistance.

Have you removed all the other files from the flash before copying small_root? The small_root should be well below 800 KB in size so it should fit the internal flash.

Capture1.PNG (3.37 KiB) Viewed 12818 times

Capture2.PNG (37.64 KiB) Viewed 12818 times

Small-root states ~638KB, so I am a little confused as to why Windows states that it cannot copy. Maybe it is possible that Windows consumes a large overhead when copying? This is baffling!

If you like, it would be possible to set up a minimal root filesystem in the internal flash and then run USBHOST S from the config.txt. This would replace the USB flash disk as the S: filesystem BUT the system would almost immediately crash when you remove that USB flash.

So maybe I will need to do this and not remove the USB device (since it is internal to the board). Of course, in retrospect I should have added a NAND device to the design to possibly help with this issue. Could you provide some guidance on how to setup this up?

This should be well documented in the documentation. Basically just CD to that disk and use PLAYDIR or PLAYFILE etc.

[/quote]

Yes, I do seem to recall this now that you stated. I will look through the documentation, but as I recall it is simply a change that gets entered into the CONFIG.TXT.

SDSDMONO D ==> USBHOST D

Thanks,
Mark

[Panu]

Small-root states ~638KB, so I am a little confused as to why Windows states that it cannot copy. Maybe it is possible that Windows consumes a large overhead when copying? This is baffling!

It makes no sense to me... Hmm... can you do some disk check... check the disk for errors in case it's corrupted somehow... also maybe configure Explorer to show hidden and system files also to see if Windows has stored some hidden files there.... ... .. ?

You can also format the disk again, that should clear all problems.

Also, there's a lot of software even in small_root that you don't need in your final product. Eliminating that is a possibility.

in retrospect I should have added a NAND device to the design to possibly help with this issue.

Or perhaps an external SPI flash. But the BEST option is to use SD card since we have hardware SD card controller in VS1005 and the SD card is very well behaving under VSOS (whereas the nand is very difficult).

The best option is to hide a microsd connector inside the unit (you can even hide it with black epoxy for production) or use eMMC flash or perhaps even solder a microSD card directly to the PCB.

One more final possibility to note is that if you have ANY four GPIO pins available on your PCB (in a pin header, perhaps), it is possible to load a software SPI driver configured to use those 4 pins as MISO, MOSI, SCK, SCLK and then use a SD-SPI driver (SD card in SPI mode) to use that software SPI. That way you can connect an SD card to any four IO pins on the VS1005 and use it as a (not very fast) disk. At VLSI we've used this method quite a few times to assist with software development even if the final unit does not have an SD card. I've simply soldered 6 female pin wires (VCC, GND, MISO, MOSI, XCS, SCLK) to a plastic microSD adapter and plugged the wires to any debug pin headers on the PCB.
-Panu

[Mark]

Panu,

Thank you for the reply and good ideas on how to move forward. I believe that I have determined the issue with copying the files to the vs1005 from the pc, I believe that the pc has a minimum cluster size that it uses for its file system and when dealing with such small file sizes this creates issues. I did perform a drive check with no findings, I will also attemp to perform a format.

I believe that at this immediate point the best path forward will be to minimize the vs1005 file system. Could you provide some guidance on how the best accomplish this given that we absolutely require the serial comms/control. Also, any guidance on how to put everything (operating system and audio playback/record files) on the SD would be helpful; we do have SD currently on the board (it does have a wiring error but can be used with some mods). I will look into the gpio option.

Thank You,
Mark

[Henrik]

Hello Mark,

Watch for this space, as I'll provide an even smaller version of small_root in a few hours.

Kind regards,
- Henrik

[Henrik]

Hello again,

I've made a smaller root file that I hope fits into your internal Flash.

If you still have trouble, some things you might want to remove:

• hello.mp3 (needed by some test programs but not as the system itself)
• SYS/dec* (any audio playback formats that you won't need, e.g. decwma.dl3 if you don't need WMA playback)
• SYS/enc* + SYS/Rec.dl3 + SYS/FILEBUF.dl3 if you don't need to record to a file. Or, if you only need e.g. Vorbis recording and not MP3 recording, you can remove only SYS/encmp3.dl3.
• SYS/usbhost.dl3 if you don't need USB Host functionality
• SYS/auoi2sma.dl3 if you don't need I2S output
• SYS/auospda.dl3 if you don't need S/PDIF output

Kind regards,
- Henrik

[Mark]

Henrik,

Thank you again for your quick support on this issue. I am currently on travel and do not have access to the development system, as soon as I return I will attempt to load this up into the BOB (Friday or this weekend). I will report back ASAP.

Mark

[Mark]

Henrick,

Thank you for making the smaller root file; let me update you on my status.

1. As is, the smaller root would not fit onto the VS1005 BOB. Now, for the next couple of steps keep in mind that I am on a Window (10) development environment.

2. When I dropped a 7K file on the BOB, Windows stated that 12K was consumed. I found this confusing, I figured that 8K would be consumed given either a 4K (4096 byte) or an 8K (8192 byte) allocation unit size was being used. Heck, the next larger allocation unit size in Windows FAT system is 16K, so this was not being used. I believe that Windows was adding some additional overhead to the BOB file system, but I was not able to observe this directly.

3. I reformatted the VS1005 BOB using the FAT file system and a 4K (4096 byte) allocation unit size, this gave me 856KB free of the 868KB stated by Windows on the BOB.

4. I again tried to move over the smaller root and BANG - everything copied over with 160K free.

5. So I could not simply stop with this bit of success so I erased the smaller root and tried to move over the 3.27 small root file system and BANG - everything copied over with 108K free.

I believe that the point here is that in order to do anything with the VS1005 file system using the Windows (10) OS, the VS1005 file system must first be formatted and forced to a 4096 byte allocation unit size. Maybe if you have some time this may be a good thing to experiment with; hopefully this little headache can be elevated to others (maybe in the manuals). Now I can finally move forward with the turn-up of our design.

Thank You,
Mark

[Mark]

Hello,

Quick question, here is the output of the VS1005 BOB boot-up with the 3.27 small root file system. There are some errors that I do not recall seeing in the past, could you possibly help decipher these?

Capture.PNG (26.88 KiB) Viewed 12771 times

Thank You,
Mark

[Panu]

Hmm, 3.10 is quite old kernel, I think the error is that AUODAC needs function InitMutexN which is not exported by such an old kernel.

Have you updated the kernel on the board?

-Panu

PS. The console output seems interesting. What am I actually looking at?

[Panu]

I believe that the point here is that in order to do anything with the VS1005 file system using the Windows (10) OS, the VS1005 file system must first be formatted and forced to a 4096 byte allocation unit size. Maybe if you have some time this may be a good thing to experiment with; hopefully this little headache can be elevated to others (maybe in the manuals). Now I can finally move forward with the turn-up of our design.

My SPI flash driver implementation forces a 4K physical sectors size. A larger cluster size is technically possible, but why would any OS want to use such? The FAT fits inside one sector as is; it should be difficult format it to anything else than to 4K allocation size.

When I dropped a 7K file on the BOB, Windows stated that 12K was consumed. I found this confusing, I figured that 8K would be consumed given either a 4K (4096 byte) or an 8K (8192 byte) allocation unit size was being used.

I also. This is baffling, I wonder why it happens. I'd sure like to know.

I've been avoiding Win10 (and even Win8) so far. Low level stuff works so much better in Win7 (and even better in Windows 2000 if you ask me). Nonetheless, this might be the root cause of the problem and must be examined.

-Panu