Blank VS1205g chips and rebuilding OS.

[martij]

Searching through the Forum, reading the manuals, and careful examination of VSOS source code and libraries has left me a unsure of understanding correctly.

1) The ROM functionality (entry points in rom1005g.txt, rom1005g.o) comes with the raw chips we buy? I assume this is why there are patches in VSOS and library code - it's just too hard to change. For raw chips do we need to do the connection of D0-D3 and JTAG to IOVDD trick to load things?
2) What does the 4k rescue image do? Where does it sit? In the 1MB SPI flash? In code ROM somewhere? Does this fix up the PROM code I may have destroyed.
3) Does extflash1005g.bin work for the internal flash system (distributed with the unbricking zip file)?
3) When you build VSOS, there appear to be 3 .img files. eeprom.img, eeprom_e.img, and eeprom_i.img. The prommer appears to use only eeprom.img. Should I be worried?
4) There's words about moving kernel.sym somewhere - I see only kernel_e.sym, kernel_i.sum. I don't see them in the either the devboard or BOB systems I have running.
5) If I have to trim out some VSOS stuff I'll never use (LCD/touchscreen and other random stuff since I need every instruction byte despite doing DLL's and all of your optimization tricks), do I need to adjust the VSOS I memory limits somewhere or does this happen automatically.
6) It seems a some file names have changed since the instructions for fixing bricked boards appeared. Are there some updated instructions in the works? Updated files?

Jed (from home).

[pasi]

A few answers to the ones I have answer for:

1) rom1005g.txt lists the addresses of variables in data RAM and constant arrays in data ROM, addresses of functions in the ROM, and addresses of function entry points in RAM. You don't need JTAG to load things. You may need to access a few pins to force an erase operation of the internal FLASH if things go very badly.

2) The rescue image is in the internal SPI FLASH. It performs some setup allowing more reliable boot from external boot media, such as the external SPI FLASH and possibly NAND FLASH.

3) extflash1005g.bin is apparently the program that performs programming to external SPI FLASH. (intflash1005g.bin would program the internal SPI FLASH.)
3) eeprom.img should be a copy of either the eeprom_e.img (kernel for external flash) or eeprom_i.img (kernel for internal flash).

5) Removed parts should be taken into account by the loader and dynamic memory allocation. Whatever you don't need to load -- or not include in the programs that are loaded -- are not taking space from memory.

Panu or Henrik needs to answer 4 and 6 (and double-check my answers).

[Panu]

Hi!

And thanks for your interest in the VS1005!

1) The ROM functionality (entry points in rom1005g.txt, rom1005g.o) comes with the raw chips we buy? I assume this is why there are patches in VSOS and library code - it's just too hard to change.

That's right. The ROM has functionality which the kernel uses. And your software uses the functionality provided by the kernel, not the ROM. Only in the final stage, when your application is already working, you can do a final optimization step of accessing some ROM symbols directly if it's needed. There are three different ways to do this: 1) to declare absolute address of a symbol with a LINK_ABS linker directive (this is the most beautiful solution because you know exactly which symbol comes from where), 2) to export the symbol from kernel (this is the cleanest solution) and 3) include the whole ROM symbol file in linking (this is the roughest solution)

For raw chips do we need to do the connection of D0-D3 and JTAG to IOVDD trick to load things?

It's needed for unbricking. But you need a lot of pins at correct states, please see the list at: viewtopic.php?f=13&t=1500

2) What does the 4k rescue image do? Where does it sit? In the 1MB SPI flash? In code ROM somewhere? Does this fix up the PROM code I may have destroyed.

It sits in the 1MB internal SPI flash, which is bonded into the same chip package with the VS1005g chip. It fixes boot reliability problems, allows unbricking of corrupted internal flash, and it's really useful.

3) Does extflash1005g.bin work for the internal flash system (distributed with the unbricking zip file)?

The unbricking zip places an old version of the rescue image into the NAND flash on the PCB instead of into the internal SPI flash. To have either or both is ok. (rescue img in internal flash or rescue img in nand flash, although the nand flash one is getting old).

3) When you build VSOS, there appear to be 3 .img files. eeprom.img, eeprom_e.img, and eeprom_i.img. The prommer appears to use only eeprom.img. Should I be worried?

Not really. We decided to automate the building of both internal and external flash versions of the kernel to include one critical property of the rescue image, and it differs by one bit in the external and the internal versions. Therefore there needs to be two different eeprom images. Eeprom.img is a copy of eeprom_e.img.

4) There's words about moving kernel.sym somewhere - I see only kernel_e.sym, kernel_i.sum. I don't see them in the either the devboard or BOB systems I have running.

That's right, and it follows naturally from automating the build for internal and external kernels. Rename the one which is relevant for you to kernel.sym and once you have programmed the kernel to your board and you get the [S1] button USB flash disk visible on the PC, copy the symbol file to the SYS subfolder. Kernel.sym file is only needed when the system crashes and you get a Stop trace. With the kernel.sym file present, you see real function names in the Stop trace dump instead of just addresses in hexadecimal.

5) If I have to trim out some VSOS stuff I'll never use (LCD/touchscreen and other random stuff since I need every instruction byte despite doing DLL's and all of your optimization tricks), do I need to adjust the VSOS I memory limits somewhere or does this happen automatically.

All that stuff is already trimmed out from the VSOS kernel - all that is left for you to do is choose which drivers are loaded in CONFIG.TXT and how you separate your application into separately loadable DL3 files.

6) It seems a some file names have changed since the instructions for fixing bricked boards appeared. Are there some updated instructions in the works? Updated files?

The unbricking instructions are still valid, but a new prommer utility is being written to simplify the process in the future.

-Panu

[jedm@vpitech.com]

We now have our product boards with the VS1205's on them. We bought the chips from you and soldered them down. What came with those chips? We're not seeing the USB mass storage on boot up though the USB connection was recognized as a VS1005 when first plugged in as we saw on the BOB's. Should we be seeing the SCSI START on default boot or do we start with the unbricking sequence to load the OS? Of course, it could be a problem with our new hardware as well.
Jed

[Panu]

Hi!

You'll probably need to write the rescue image into the internal flash first, or at least it helps.

Can you see it in VSIDE's autodetect? That's the first step anyway.
If not, do you have IOVDD and IOVDD2 (FVDD) connected together? If not, connect them together and see if you can autodetect the chip then.

Whenever you can autodetect / connect with the chip with VSIDE and UART, program the rescue image into the internal flash. The chip will boot reliably then.

-Panu

[jedm@vpitech.com]

We'll give that a try. Is the date on your server set correctly? Messages are showing up as 2017 instead of 2018 so I don't get the notifications of a response. Perhaps this is a feature of the Windows 10 upgrade we were just subjected to.
Jed.

[jedm@vpitech.com]

Some experiments:
1) Apology: We have the VS1005GF chip.
2) Pins 6 and 7 are connected together and to IOVDD. Verified with scope, ohmmeter.
3) The only real difference we can tell between this board and previous is:
a) Different tri-color LED (which appears to work as advertised when connected to the battery charger)
b) Different lot numbers. Working version 6115620 3T0347 1630, new version 6298670 3T0347 1728
4) On old programmed versions, IOVDD starts around 3.2v and drops a bit after startup. On the new version,
it starts at around 3.2v then drops down to 2.2-2.4v with lots of noise .
5) The VSIDE prommer never connects because the device never shows up as a serial port. It's always a VS1005G Audio device,
Input device. This appears to be true on both Windows 10 and Windows 7 (we have one lucky hold out here). The
details say that it's HID compliant, Speakers (4-VS1005G), USB Composite Device, USB Input Device, VS1005G sound,
video and game controller.
6) We have a reset which works; the USB goes away but comes back as VS1005G when released.
7) We can also pull up GPIO0_0 with reset. This normally brings up the USB mass storage with the internal 1MB flash.
Same behavior as above.
8) The prommer never recognizes the device
9) GPIO0_8 is held high through 10k resistor to IOVDD (we tried it without as well).

Any other ideas?
Jed

[Hannu]

Just a quick idea which affects to IOVDD voltage.
How about GPIO0_7? There should be pull-up to IOVDD to set the IOVDD to 3.3V. when it's down during boot, you get 1.8V and that might be 2.4 after some other chip pulls it higher.
GPIO0_8 needs pull-up so that flash probe doesn't get stuck. And this pull-up you already have.

[Panu]

The VSIDE prommer never connects because the device never shows up as a serial port. It's always a VS1005G Audio device

VS1005 never shows up as a serial port, with ROM software anyway. Usually you connect a USB UART cable to RX, TX pins.

VS1005G Audio device,Input device. The details say that it's HID compliant, Speakers (4-VS1005G), USB Composite Device, USB Input Device, VS1005G sound, video and game controller.

That does look like the ancient USB profile set up in the VS1005 ROM. (I don't think that it actually works as a USB audio device)

We can also pull up GPIO0_0 with reset. This normally brings up the USB mass storage with the internal 1MB flash.
Same behavior as above.

You mean no mass storage? You only get mass storage if the flash is programmed to hold the VSOS kernel.


What you need, by some way or another, is to get RX and TX connected to a USB UART cable, and then use VSIDE to write a VSOS kernel to the internal flash. This also sets up a primary boot record ("RESCUE_IMG") which stabilizes the ic.

Is it something you can do? Do you have RX, TX pins? Do you have SD card?

-Panu

[jedm@vpitech.com]

Our fault - everything working fine. We forgot how to do this and were trying to program the wrong port.

As a side complement: I've been programming for almost 50 years and this is the first time I've ever encountered a new release of an operating system that was smaller than the previous. Well done!