Blank VS1205g chips and rebuilding OS.

Writing software that controls the system and peripherals such as displays, SD cards, Buttons, LEDs, Serial Ports etc.
martij
User
Posts: 3
Joined: Mon 2017-01-30 5:05

Blank VS1205g chips and rebuilding OS.

Postby martij » Mon 2017-01-30 5:26

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).

User avatar
pasi
VLSI Staff
Posts: 1329
Joined: Thu 2010-07-15 16:04

Re: Blank VS1205g chips and rebuilding OS.

Postby pasi » Mon 2017-02-06 15:10

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).
Visit https://www.facebook.com/VLSISolution VLSI Solution on Facebook

User avatar
Panu
VLSI Staff
Posts: 2328
Joined: Tue 2010-06-22 13:43

Re: Blank VS1205g chips and rebuilding OS.

Postby Panu » Thu 2017-02-09 14:33

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
Info: Line In and Line Out, VS1000 User interface, Overlay howto, Latest VSIDE, MCU Howto, Youtube
Panu-Kristian Poiksalo, VLSI Solution Oy

jedm@vpitech.com
Senior User
Posts: 39
Joined: Wed 2016-11-02 22:50

Re: Blank VS1205g chips and rebuilding OS.

Postby jedm@vpitech.com » Thu 2017-04-13 22:24

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

User avatar
Panu
VLSI Staff
Posts: 2328
Joined: Tue 2010-06-22 13:43

Re: Blank VS1205g chips and rebuilding OS.

Postby Panu » Fri 2017-04-14 13:22

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
Info: Line In and Line Out, VS1000 User interface, Overlay howto, Latest VSIDE, MCU Howto, Youtube
Panu-Kristian Poiksalo, VLSI Solution Oy


Return to “System Software”

Who is online

Users browsing this forum: No registered users