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 > *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 > *Sent:* Sunday, October 13, 2019 10:40 PM > *To:* Schneeberger, Eric > *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 > *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 > *Sent:* Thursday, October 10, 2019 8:37 PM > *To:* Schneeberger, Eric > *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 > > [image: 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 > > >