> 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
>
> [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
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__stoneboat.aleph1.co.uk_cgi-2Dbin_mailman_listinfo_yaffs&d=DwMFaQ&c=YEQWdgm3lcu5w_Y3fWOQZUGtAhl_lImuPlnxuD4zIqo&r=h8g7xIzdNG1y6gKi7Jnzf5ulB6HAufGtEYhC_2i4MgQ&m=iGSNNxT7WZ3JjdZ3WmQ3GR6Do55OPfn9N0LupbW4WnI&s=ysZ6B5IWccARBy2VAxSI_G21O6n21t-r29GUM2Pf314&e=>
>
>