Hello

Certainly it is much better to only be doing ECC in one place otherwise the ECC mechanisms can end up "fighting" over spare bytes etc used to store the ECC data.

Regards

Charles


On Fri, Oct 25, 2019 at 3:19 AM Schneeberger, Eric <eric.schneeberger@gtt.com> wrote:

Charles,

 

Any other thoughts?

 

I noticed yesterday that the ECC was turn on in the NAND and our code also had YAFFS doing ECC.

I assume this is a bad thing. (Not sure what this would do?)

 

I will change this and see if this makes a difference.

 

Currently I’m looking at our drivers for the chip to make sure we are doing the correct thing.

 

Regards,

Eric Schneeberger

 

 

From: Schneeberger, Eric
Sent: Monday, October 14, 2019 9:29 AM
To: Charles Manning <cdhmanning@gmail.com>
Cc: yaffs@stoneboat.aleph1.co.uk
Subject: RE: [EXTERNAL] Re: [Yaffs] file doesn't exist

 

Hello Charles,

 

Thanks for taking the time to help me out.

I appreciate it.

 

We use an yaffs_open for the first portion (high codes) of the data then do a yaffs_seek to get to the end of that portion and write the second portion (low codes).  (code below)

 

We don’t typically do a seek, only on some of our files.

 

The ffs_open is just a wrapper around the yaffs call. We use it to get diagnostics of when things get written etc..

 

static bool SecurityCodesCfg_WriteDefault(char* filesystemname, PS_MODEL model)

{

    bool success = false;

    int file;

    uint8_t num_retries = 0;

 

    os_itv_set(OS_WAIT_50_MSEC);

 

    if ( model != MODEL_UNKNOWN ) //should we even bother??

    {

        while(( num_retries < NUM_WRITE_RETRIES ) && ( !success ))

        {

            num_retries++;

 

            // Write the default Security Codes Configuration.

            if ( (file = ffs_open(filesystemname, O_CREAT|O_RDWR|O_TRUNC, S_IREAD|S_IWRITE)) != -1)

            {

                os_itv_wait();

 

                // Default high priority codes.

                if ( ffs_write(file, (void *)&HighSecurityConfig, sizeof(security_config_t)) != -1)

                {

                    os_itv_wait();

 

                    // Next default low priority codes.

                    if(yaffs_lseek(file, sizeof(security_config_t), SEEK_SET) != -1)

                   {

                        os_itv_wait();

 

                        if ( ffs_write(file, (void *)&LowSecurityConfig, sizeof(security_config_t)) != -1)

                        {

                            success = true;

                        }

                    }

                }

 

                os_itv_wait();

                ffs_close(file);

            }

        }

    }

 

    return success;

}//end SecurityCodesCfg_WriteDefault()

 

 

Thanks,

Eric

 

 

 

From: Charles Manning <cdhmanning@gmail.com>
Sent: Sunday, October 13, 2019 10:40 PM
To: Schneeberger, Eric <eric.schneeberger@gtt.com>
Cc: yaffs@stoneboat.aleph1.co.uk
Subject: Re: [EXTERNAL] Re: [Yaffs] file doesn't exist

 

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.

 

Hello Eric

 

How are you writing the data?

 

If you are writing files via the yaffs open/read/write interface, then writing too much data should just result in a partially written file.

 

But ultimately it won't work stuffing 40blocks of data into 32 blocks of space.

 

On Sat, Oct 12, 2019 at 10:08 AM Schneeberger, Eric <eric.schneeberger@gtt.com> wrote:

Hello Charles,

 

Looking at our setup.

 

The SecurityCodes looks to be 40 blocks of data, however we only allocate 32 blocks for the partition.

 

I assume this is not good. 

What could happen in this case? I assume funky things could happen to the file system. Like what we are seeing?

 

~Eric

 

 

From: Schneeberger, Eric
Sent: Friday, October 11, 2019 11:34 AM
To: Charles Manning <cdhmanning@gmail.com>
Cc: yaffs@stoneboat.aleph1.co.uk
Subject: RE: [EXTERNAL] Re: [Yaffs] file doesn't exist

 

Hello Charles,

 

Thanks for responding.

 

More info:

  1. 32 blocks is reasonably small for a Yaffs partition. Not too small, but still smaller than normal. That in itself should not be an issue. How many files are there? How much free space is there before modifying the files?
    1. Most of are partitions are 32 blocks

                                                               i.      I’m not sure why we designed it this way, I was not the original designer. In fact on our other device I got rid of all the config partitions and made them one, now we just have 3  (cfgs, activity_logs & call_playback ).

    1. Our first partition has 10 files not including the lost+found (See below in list)

                                                               i.      The rootCA, deviceKey, and deviceCert are not written be default only when we need them.

        1. So we have 7 of 32 blocks used (25 free blocks) (or did you want the number of bytes free?)
  1. Are the other partitions mounted at the same time or are they left unmounted?
    1. All the partitions are mounted at the power up. I thought maybe it was a mounting issue, but don’t see any mount failures.

 

 

Here is how our stuff is laid out:

 

Partitions:

yaffs_comm_configs_device                       start=1,                end =32               (32 blocks)

yaffs_config_profiles_device                       start=33,              end =64               (32 blocks)

yaffs_gps_configs_device                             start=65,              end =96               (32 blocks)

yaffs_misc_configs_device                           start=97,              end =128             (32 blocks)

yaffs_mode_configs_device                        start=129,            end =144             (16 blocks)

yaffs_security_codes_device                      start=145,            end =176             (32 blocks)

yaffs_time_configs_device                          start=177,            end =208             (32 blocks)

yaffs_activity_logs_device                           start=209,            end =848             (640 blocks)

yaffs_call_playback_device                          start=849,            end =1023           (175 blocks)

 

The number mean:

stat.st_ino, stat.st_mode, stat.st_nlink, stat.st_rdev, stat.st_size, stat.st_blksize, stat.st_blocks

 

/comm_cfgs:
515 100600 1 0 4097 2048 3 rootCA                        (doesn’t always exist)
514 100600 1 0 4097 2048 3 deviceKey                 (doesn’t always exist)
769 100600 1 0 4097 2048 3 deviceCert                (doesn’t always exist)
2263 100600 1 0 138 2048 1 Ntcip1211
262 100600 1 0 272 2048 1 ActiveCallCfg
261 100600 1 0 16 2048 1 NetworkUDPCfg
260 100600 1 0 4 2048 1 ServiceAdr
259 100600 1 0 10 2048 1 SerialCom
2 40666 1 0 2048 2048 1 lost+found/
258 100600 1 0 24 2048 1 Network
257 100600 1 0 401 2048 1 ModemInit

/cfg_profiles:
2 40666 1 0 2048 2048 1 lost+found/
258 100600 1 0 27200 2048 14 StdConfigProfiles
257 100600 1 0 27200 2048 14 SpcConfigProfiles

/gps_cfgs:
260 100600 1 0 2400 2048 2 MapGeoPts
259 100600 1 0 8 2048 1 GpsLocation
2 40666 1 0 2048 2048 1 lost+found/
258 100600 1 0 72 2048 1 GpsFilter
257 100600 1 0 2620 2048 2 ApproachMaps

/misc_cfgs:
514 100600 1 0 512 2048 1 IOTMQTTCredentialCfg
513 100600 1 0 268 2048 1 IOTMQTTCommCfg
262 100600 1 0 116 2048 1 Unit
261 100600 1 0 1 2048 1 RangeTimer
260 100600 1 0 976 2048 1 ChParams
259 100600 1 0 10 2048 1 BaseStation
2 40666 1 0 2048 2048 1 lost+found/
258 100600 1 0 5 2048 1 ActivityLogCfg
257 100600 1 0 5 2048 1 ConfirmLights

/mode_cfgs:
261 100600 1 0 7 2048 1 TimeOutput
260 100600 1 0 4 2048 1 TimeInput
259 100600 1 0 2 2048 1 LowPriOutModeCfg
2 40666 1 0 2048 2048 1 lost+found/
258 100600 1 0 12 2048 1 EvacuationMode
257 100600 1 0 1 2048 1 DelawareModeCfg

/security_codes:
2 40666 1 0 2048 2048 1 lost+found/
257 100600 1 0 80000 2048 40 SecurityCodes

/time_cfgs:
260 100600 1 0 20 2048 1 WklyTimePlanCal
259 100600 1 0 258 2048 1 TimeLocal
2 40666 1 0 2048 2048 1 lost+found/
258 100600 1 0 1420 2048 1 StdDailyScheds
257 100600 1 0 1420 2048 1 SpcDailyScheds

/activity_logs:
2 40666 1 0 2048 2048 1 lost+found/
258 100600 1 0 0 2048 0 ActivityLog
257 100600 1 0 20 2048 1 ActivityLogsDir

/call_playback:
2 40666 1 0 2048 2048 1 lost+found/
258 100600 1 0 0 2048 0 CallPlaybackLogs
257 100600 1 0 1612 2048 1 CallPlaybackLogsDir

 

 

~Eric Schneeberger

 

 

 

From: Charles Manning <cdhmanning@gmail.com>
Sent: Thursday, October 10, 2019 8:37 PM
To: Schneeberger, Eric <eric.schneeberger@gtt.com>
Cc: yaffs@stoneboat.aleph1.co.uk
Subject: [EXTERNAL] Re: [Yaffs] file doesn't exist

 

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.

 

 

On Thu, Oct 10, 2019 at 9:04 PM Schneeberger, Eric <eric.schneeberger@gtt.com> wrote:

Hello, we are having a problem that only seems to appears with new devices from our factory.

 

yaffs_lstat will return -1, aka file doesn’t exist.

 

Steps:

  1. Initial power-up we default our configuration files.
    1. We have multiply mount points but it appears to happen only on the first mount point. Blocks 1-32
  1. Reboot and files all exist in fist mount point. (yaffs_lstat returns 0)
  2. Do a write to a file in first mount point
    1. Any file (from what I can tell)
  1. Reboot and all files don’t exist (yaffs_lstat returns -1)
  2. >From then on any write and reboot the files will exist.
    1. I haven’t been able to reproduce it after this.

 

FYI flash NAND is a micron MT29F1G08ABADA.

 

Has anyone seen such behavior?

 

Any help is appreciated.

 

Hello Eric

 

In all cases that I have seen something like this it has come down to either a driver or a configuration issue causing some overlap.

 

Can you give me some more info:

1) 32 blocks is reasonably small for a Yaffs partition. Not too small, but still smaller than normal. That in itself should not be an issue. How many files are there? How much free space is there before modifying the files?

 

2) Are the other partitions mounted at the same time or are they left unmounted?

 

Regards

 

Charles

 

 

 

Regards,

 

Eric Schneeberger

Senior Firmware Engineer

P 651.789.7315

Global Traffic Technologies, LLC • 7800 Third Street North • St. Paul, Minnesota 55128-5441

cid:image001.png@01D39C47.26EA0B80

 

Please be advised that this email may contain confidential information. If you are not the intended recipient, please notify us by email by replying to the sender and delete this message. The sender disclaims that the content of this email constitutes an offer to enter into, or the acceptance of, any agreement; provided that the foregoing does not invalidate the binding effect of any digital or other electronic reproduction of a manual signature that is included in any attachment.

_______________________________________________
yaffs mailing list
yaffs@stoneboat.aleph1.co.uk
http://stoneboat.aleph1.co.uk/cgi-bin/mailman/listinfo/yaffs