Thread: Help with fatsave function

Okay, I have zero experience with C, and programming in general. So thank you in advance for your patience...

I am modifying a u-boot file and have run into a problem. The program is already written, I am simply trying to add a function to the code. I have pulled a function from the file and simply modified it, hoping to get the results I need, so if you see things that you think don't belong in this function, you are probably right.

I am attempting to have a function that overwrites an existing file and makes it a specific size (1088 bytes) and contain only zeroes.

This is the function as defined in the top of the program

Code:

int clear_recovery_instructions_file(const char* file, char value) {
    lcd_is_enabled = 0;
    ("mmcinit 0; fatsave mmc 1:2 0x%08x %s 1088", &value, file);
    lcd_is_enabled = 1;
    return value;

And here I am calling it below

Code:

if ((key & HOME_KEY) && (cursor == CLEAR_RECOVERY_INSTRUCTIONS)) {  //clear boot count and reset BCB
            const char* file = "BCB";
            {clear_recovery_instructions_file (file, '0x400');}
            udelay(RESET_TICK);
            highlight_boot_line(cursor, HIGHLIGHT_GREEN);
            do {udelay(RESET_TICK);} while (tps65921_keypad_keys_pressed(&key));  //wait for release
        }

As you can see, I merely want the overwrite to occur if the user selects the Clear Recovery Instructions option in the bootloader menu.

As it stands, if I manually change the file size in the device terminal, after selecting the option in the bootloader, the file size stays at whatever I manually put it to instead of 1088.

Any help would be appreciated. I am sure there is garbage in the above code, as some of it I understand and some of it I don't. If I didn't understand what it was in the existing overwrite function I lifted the code from, I left it in. For instance, I believe the %s option indicates a string, and so may be useless or harmful as is. I left it in in case it referenced the 0's I woud like the file filled with.

Thanks!

Looks like you have a great thread on this already.

Also, no idea what you're doing with this code, it's invalid C. Line 3 of block 1 seems to be missing a function call, and line 3 of block 2 isn't a character.

Code:

const char* file = "BCB";
{clear_recovery_instructions_file (file, '0');}

If you're just going to hardcode "BCB", and it's not used elsewhere, there's no reason you can't just do:

Code:

clear_recovery_instructions_file("BCB", '0');

The

Code:

{}

s around that call, while not incorrect, have no added value there.

Your sprintf() in the function, now what are you trying to do there on the whole? Maybe issue a system command? sprintf takes as its first argument an array of characters into which to copy the string, with the replacements.

That thread is at an end-user device forum, where most people, if they use programming at all, tend to have some linux and maybe some java. (like me)

That thread appears to me to be on a developers forum, not an end-user forum?

Originally Posted by rags_to_riches

Your sprintf() in the function, now what are you trying to do there on the whole? Maybe issue a system command? sprintf takes as its first argument an array of characters into which to copy the string, with the replacements.

I have done the corrections you offered, although they look like general clean-up, not really substantive changes. Although I guess clean code is better.

I used the sprintf function because it was used in an earlier overwrite function in the file, not because I was sure it was the correct tool.

I am trying to overwrite the BCB file to be 512 bytes (or 1088. either way), consisting of only 0's. That's really it.

That thread appears to me to be on a developers forum, not an end-user forum?

The devs there tend to use the board to release software and offer support for it. I was the one poster who was willing and able to work on it. My C programming skill is obviously lacking. The fellow poster who was giving the majority of the advice was posting repeated snippets of unix commands.

I didn't start that thread and it is not devoted to code generally or this project period.

When I needed to learn how to diff and patch, I went to a linux forum and got help. If I needed to learn how to flash the bootloader, then I would certainly take it to the device board. I had a problem with C, so I went to a forum devoted to the topic.

Here is where I am. Any and all comment is appreciated.
Function

Code:

int clear_recovery_instructions_file(const char* file, char value) {
    lcd_is_enabled = 0;
    sprintf("fatsave mmc 1:2 0x81c00000 BCB 0x200", &value, file);
    sprintf("fatsave mmc ${mmcromdev}:2 0x81c00000 devconf/BootCnt 4", &value, file);
    lcd_is_enabled = 1;
}

call

Code:

if ((key & HOME_KEY) && (cursor == CLEAR_RECOVERY_INSTRUCTIONS)) {  //clear boot count and reset BCB
            clear_recovery_instructions_file ("BCB", '0');  
            udelay(RESET_TICK);
            highlight_boot_line(cursor, HIGHLIGHT_GREEN);
            do {udelay(RESET_TICK);} while (tps65921_keypad_keys_pressed(&key));  //wait for release
        }

It compiles just fine, but won't resize the file. I know that it can be resized, because one early version resized it to 73 bytes. I have since found (I think) the area where the bytes are defined (0x200 in the top code block) but can no longer get the thing to change.

I cannot shake the feeling I am somewhat close, yet am doing something impossibly noobish to screw it up.

I am going to try that first thing tomorrow morning. I originally had some buf parameters, but clipped them out when trying to separate out things I didn't think applied.

I don't know if fatsave will work on the command line, though. I know it is particular to the bootloader, and don't know much about it. It is used in the omap config file, which is partially where I sourced it from.

Thanks, you have given me some ideas to try!

Okay, I am back to a point where the function, when called through the hardware, actually mods the BCB file again. It was something I had accomplished early in this project, but had somehow broken, and couldn't, no matter what I seemed to do, get back. Honestly, the fact that I had blundered into it accidentally was the only thing that had me convinced it was possible.


Of course, it has been over 100 u-boot builds later...

I was originally going to post a copy of the fatsave function (finally tracked down with cscope) but I figured I would just keep on experimenting until I had a specific question.

Really, the advice that memcpy gave me in passing was helpful, as I knew I was close after that.

But the key was Salem suggested the buffer, I remembered taking a buffer out when I was originally modifying the function to no longer write a string of boot data. Maybe that is simple and SOP, but I just didn't know what it was.

I would have been back to report some modest success earlier, except an errant deleted space key, after the buf call, had the whole thing screwy for the last several days.

Anyway, I think I have the info to finally put this thing to bed. I am going to try and finish it tomorrow, and assuming I don't come across another issue I think you can help with, I will mark the issue as solved.

Thanks.

Originally Posted by QuantumPete

Does this forum look like a ticketing system to you?

Wow. okay, man.

You are sure are a friendly lot.

I read the sticky posts and tried to follow the rules. Trust me when I say that I took the responses and tried to use them to create my own solution, not just try and get someone to fix/write it for me. As you can see, I was able to do that.

I just came back to report as a courtesy and a thank you to those who responded.

I didn't know your conventions, which I guess are different than some other sites. I always thought that was done to let help future readers know if a solution could be found, and let the people who volunteered their time know it helped find a resolution.

Now I know different.

I was just someone trying to learn something new, not here to mess up your sandbox.

I'll leave the thread as it is.

Thanks to the initial responders.