Newbie here with newbie questions

[msat]

I've been reading various documents and forum posts about VSOS and the VS1005 and think I'm starting to finally wrap my head around some of the core concepts. I'm creating this thread to verify that my head is in the right place so far, and also that maybe these questions/statements will help others in the future. Presumably, these statements/questions are only applicable to projects that will utilize VSOS. Please let me know whether or not these are correct.

1) A potion of the internal or external flash (depending on device) is often formatted with a FAT filesystem. A device letter (basically a drive letter like in Windows) is given to this. Usually (always?) S: for 'system'.

a) This partition is where the user applications (.AP3 files for VSOS v3) and drivers/libraries that aren't part of the kernel (.DL3 files for VSOS v3) usually reside. CONFIG.TXT in the root directory contains commands that are executed depending the state values of certain pins upon boot. These commands are simply executed in sequence. If CONFIG.TXT is omitted, the kernel looks for a program named INIT.AP3 and runs that instead.

b) The VSOS kernel has a built-in FAT FS driver. File handling/operation functions can be called to manipulate the files on the system partition. It is therefore trivial to move files around between the system partition and other FAT partitions such as those on SD cards or USB memory sticks.

c) The contents of this partition can be made accessible to other devices such as computers by using something like the available USBMSC mass storage device class driver which can be pointed to the S: device when it is invoked. This driver can also be used to point to other device letters such as the one attributed to a mounted SD card (which also requires its own driver such as 'SDSD'), so that the card's contents are accessible via USB as a mass storage class device.

d) The kernel itself (and what else?) is not stored on the system device FAT partition, though it is in flash.

e) Because the boot kernel is not in the system partition, it cannot be modified with FAT FS functions/commands. However, there are low-level flash writing functions. Typically, if needed, the boot kernel is overwritten using promming software tools using hardware attached to the chip's UART port.

f) For convenient field-updatable kernels, there is also a minimal "Safe firmware update kernel" (viewtopic.php?f=13&t=1756) in the boot region of flash. This kernel is intended to not be overwritten with new kernels. Instead, it copies over a .BIN file containing the full kernel update from some media such as SD card or USB memory stick into a separate region of flash. Control is then handed over to the full kernel at some address offset in flash.


Question: In the case where the safe kernel is used in a product, does the generated backup .BIN file also contain the FAT partition and all it's contents? Or in other words, can I provide a monolithic .BIN file to be used in field updates that contains a kernel and a FAT partition with all the desired .AP3 and .DL3 files? Or does the .BIN file only contain the kernel?

[Hannu]

Hello,

You have done your homework very well. And the aswer is yes. sysbackup copies everything to image file.

I've been reading various documents and forum posts about VSOS and the VS1005 and think I'm starting to finally wrap my head around some of the core concepts. I'm creating this thread to verify that my head is in the right place so far, and also that maybe these questions/statements will help others in the future. Presumably, these statements/questions are only applicable to projects that will utilize VSOS. Please let me know whether or not these are correct.

1) A potion of the internal or external flash (depending on device) is often formatted with a FAT filesystem. A device letter (basically a drive letter like in Windows) is given to this. Usually (always?) S: for 'system'.

That is correct. The difference between S: and for example D: (SD card) is that programs are searched from S:sys directory. Nothing however prevents running d:progs/hello.dl3.

a) This partition is where the user applications (.AP3 files for VSOS v3) and drivers/libraries that aren't part of the kernel (.DL3 files for VSOS v3) usually reside. CONFIG.TXT in the root directory contains commands that are executed depending the state values of certain pins upon boot. These commands are simply executed in sequence. If CONFIG.TXT is omitted, the kernel looks for a program named INIT.AP3 and runs that instead.

Basically correct. There are usually aren't partition tables and partitions. Only kernel area and file system area. However partitions work also, but it consumes space from SPI flash which usually are quite small.

b) The VSOS kernel has a built-in FAT FS driver. File handling/operation functions can be called to manipulate the files on the system partition. It is therefore trivial to move files around between the system partition and other FAT partitions such as those on SD cards or USB memory sticks.

Correct. copy and delete programs exist.

c) The contents of this partition can be made accessible to other devices such as computers by using something like the available USBMSC mass storage device class driver which can be pointed to the S: device when it is invoked. This driver can also be used to point to other device letters such as the one attributed to a mounted SD card (which also requires its own driver such as 'SDSD'), so that the card's contents are accessible via USB as a mass storage class device.

Correct. Any device can be published as long it has a letter and BlockRead() and BlockWrite() and its flags are correct.

d) The kernel itself (and what else?) is not stored on the system device FAT partition, though it is in flash.

Correct. It is in the beginning of the flash before file system.

e) Because the boot kernel is not in the system partition, it cannot be modified with FAT FS functions/commands. However, there are low-level flash writing functions. Typically, if needed, the boot kernel is overwritten using promming software tools using hardware attached to the chip's UART port.

Correct. Most of the time that is how the update is done.

f) For convenient field-updatable kernels, there is also a minimal "Safe firmware update kernel" (viewtopic.php?f=13&t=1756) in the boot region of flash. This kernel is intended to not be overwritten with new kernels. Instead, it copies over a .BIN file containing the full kernel update from some media such as SD card or USB memory stick into a separate region of flash. Control is then handed over to the full kernel at some address offset in flash.


Question: In the case where the safe kernel is used in a product, does the generated backup .BIN file also contain the FAT partition and all it's contents? Or in other words, can I provide a monolithic .BIN file to be used in field updates that contains a kernel and a FAT partition with all the desired .AP3 and .DL3 files? Or does the .BIN file only contain the kernel?

sysbackup creates full flash image and it contains kernel, filesystem and even the last few sectors outside of the filesystem. It is image of the flash.
The update kernel then writes the image to its flash.

[msat]

Thank you for the quick response, Hannu! I'm glad that I've been heading in the right direction!

[msat]

I have another question. I apologize if this should have gone in it's own thread.

Looking at ParseFileParam.h I see a function prototype FileParamSeek as follow:

Code: Select all

auto const char *FileParamSeek(register const char *haystack,
			       register const char *needle,
			       register s_int16 *n);

The other prototypes have good comments but the one above has none. Can someone help me understand how it's used? I assume *haystack and *needle parameters are the same as in the other functions. What's not clear is what the *n parameter is, and what exactly is returned.

Thanks!

[Hannu]

Hi!

That is seeking function, which the FileParam* functions use internally. Those parsing functions are white space sensitive like the examples in the documentation. The source code is in roots and solutions package under libvsos.

I have used FileParamInt on VS1010 (same code) to parse file which is very readable containing lines like:

Code: Select all

#Don't boot if battery voltage is too low.
  batteryBootLimit   =  12345

To work with comments and white space I have some additional code. Not very memory conservative but that program comes to memory, does its job and exits. So it doesn't have to be memory optimized. struct systemConfig has only s_int16 members so it can be handled like array of s_int16s. So this is little bit special case, doesn't cover the string variant and is overcomplex but I hope this helps.

Code: Select all

typedef struct {
	/* Battery empty voltages */
	s_int16 batteryBootLimit;
	....
} systemConfig;

#define LINE_BUF_SIZE 256

char confBuf[LINE_BUF_SIZE];
char lineBuf[LINE_BUF_SIZE];

systemConfig k;
systemConfig __mem_y d;
....
void DefaultConfig() {

	/* Battery empty voltages */
	k.batteryBootLimit = (s_int16)"batteryBootLimit"; d.batteryBootLimit = 2000;
	...
}
void LoadValue(char *line, systemConfig *dest) {
	char **key = (char **)&k;
	s_int16 i, *val = (s_int16 *)dest; /* Handle like an array */
	if (*line == '\0')return; /* Early return for empty line */
	for (i = 0; i < sizeof (systemConfig); i++) {
		u_int32 tmp;
		tmp = FileParamInt(line, *key++, (u_int32)*val); /* <------ HERE IS THE BEEF */
		if (((s_int32)tmp) > INT_MAX && ((s_int32)tmp) < INT_MIN) {
			printf("Bad value range: %s\n", line);
		} else {
			*val = (s_int16)tmp;
		}
		val++;
	}
}
void RemoveWhiteSpace() {
	char *s = lineBuf, *dest = confBuf;
	memset(confBuf, 0, sizeof(confBuf));
	while (*s) {
		if (*s == '#') {
			return;
		}
		if (isspace(*s) == 0) {
			*dest++ = *s;
		}
		s++;
	}
}
...
	FILE *conf = fopen(SYSTEM_CONFIG, "rb");
	DefaultConfig(); /* Prepare default config */
	if (conf) {
		if (structDest == NULL) {
			fclose(conf);
			return S_ERROR;
		}
		*((systemConfig *)structDest) = d; /* Copy the default values */
		while(fgets(lineBuf,  LINE_BUF_SIZE - 1, conf)) {
			RemoveWhiteSpace();
			LoadValue(confBuf, (systemConfig *)structDest);
		}
....		

[msat]

Thanks for the whitespace agnostic routines, Hannu. This might come in handy!

I found the source code you were referring to. While I haven't wrapped my head around the n parameter in the FileParamSeek function, looking at the FileParamInt code, I think I know everything I need to know to use the FileParamSeek function to, for example, locate a value in something like a config.txt file via pointer and write a change to it.

[Hannu]

If you are parsing command line parameters there is a tool for that.

paramspl takes parameters, splits the string on whitespace. and returns number of pieces.

Have a look at for example solutions/AuControl/AuInput/main.c in roots and sources.

The essential pattern is below

Code: Select all

int nParam = RunProgram("ParamSpl", parameters);
char *p = parameters;
for (i=0; i<nParam; i++) {
  //Process the parameters
  p += strlen(p)+1;
}

And the additional benefit is that the paramspl code is loaded, executed and dropped so it doesn't take memory all the time. And paramspl isn't limited to parameter splitting. it can take other strings too. However it modifies the string.
if you call RunProgram("paramspl", "Hello <many spaces> there"); it will return 2 and the string will be after call hello\0there\0, So it can bite in interesting ways.

[msat]

Thanks for bringing paramspl to my attention. There is a ton of great utility code provided by VLSI which is significantly cutting down on my workload. The hardest part is finding out about all the goodies in there. I should write myself a cheatsheet of all the good stuff I find.

[Hannu]

If your cheatsheet gets good, please share it. At least I will review it and give a feedback. And it could be useful to other VSDSP coders to get started.

There are so many small and simple things we take for granted and don't even think about until someone asks.

[msat]

If I do end up writing such a list then I'll be happy to share it!