Hi, to clarify, I was not suggesting modifying the existing in-flash format. I was suggesting using a callback as a means of deciding whether to keep individual log entry not. This would allow you to change the policy regarding retaining entries very easily.
Alternatively, if you have some specific policy in mind, you could implement that inside an alternative to log_fcb.c. > On May 19, 2016, at 3:07 PM, Vipul Rahane <[email protected]> wrote: > > This does sound the way I was thinking about it. I do have a concern with > this approach though: since the log entry gets stored in the flash, we need a > way to mark an entry which increases the amount of space needed on the flash. > > As an alternative, I was thinking in the direction of keeping most recent N > number of entries. All this would need is a marker/flag in the log structure > and nothing on the flash. Of-course, there would still be a callback to do > that. > > Regards, > Vipul Rahane > >> On May 19, 2016, at 11:50 AM, marko kiiskila <[email protected]> wrote: >> >> For FCB option: >> >> You could add a callback to FCB backend for logging, which would call >> you when it’s ready to erase a sector. Maybe call it for every entry, >> and then in the end when it’s finished with erase. >> >> In this callback you could then decide whether you want to keep that >> log entry, or toss it. If you want to keep it, you’d write it back once >> erase has taken place (and there is more space available). >> >> Of course, you should toss some things away. >> >>> On May 18, 2016, at 12:39 PM, Vipul Rahane <[email protected]> wrote: >>> >>> Hello, >>> >>> I have a rough design of the reboot log ready along with the code. It >>> consists of logging the timestamp, reboot count, image version and reason. >>> >>> Possible reasons: >>> Soft reboot: Reboot issued by the developer/user >>> Hard reboot: Reboot caused by loss in battery power, pulling off the plug, >>> etc. Basically any reboot caused by an unknown reason. >>> Gen core: Reboot caused by core generated either by an assert or a core >>> generate command manually by a developer/user(Future use) >>> >>> Storage mechanism: >>> >>> Current: Flash using fcb backend >>> Advantages: >>> - Has an interface already, so easy to implement >>> >>> Disadvantages: >>> - The entire sector of the flash needs to be erased when it gets full which >>> would clear the reboot log. >>> - Different MCUs have different sector sizes which might/might not be >>> available for use. Eg: Depending on the availability reserving 64k in the >>> flash map for the system log itself sounds like a waste of flash space. >>> - We cannot break the flash space into smaller chunks to be used by the fcb. >>> - The flash sectors that would be used would have to be specified for each >>> BSP(Hard coded). >>> >>> Possible solutions: >>> >>> 1. Flash using config backend >>> Advantages: >>> - Has an interface as well, somewhat easy. >>> - Entire sector would not be needed for reserving for reboot/system log. >>> >>> Disadvantages or work needed: >>> - New functions supporting reading old config entries(15-20) and keeping >>> them around. >>> - A bit unusual to think about (hacky). >>> >>> 2. Fcb could somehow be more intelligent about underlying sectors. >>> Advantages: >>> - Not too hacky and could be used by anyone who uses fcb. >>> >>> Disadvantages: >>> - The way fcb is currently implemented, it takes care of very specific >>> functions at a sector level and hence supports read/write/erase at a sector >>> level. If we add this, it would do something more than just these basic >>> functions. >>> >>> I am open for both ideas. Any more ideas are welcome. >>> >>> Regards, >>> Vipul Rahane >> >
