Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fexc fixes #49

Merged
merged 5 commits into from
May 30, 2016
Merged

fexc fixes #49

merged 5 commits into from
May 30, 2016

Conversation

n1tehawk
Copy link
Collaborator

I'm currently experimenting with functional tests that do a "fex2bin + bin2fex cycle" on all FEX files from sunxi-boards. In doing that, two minor problems with the current code showed up. This pull request addresses those.

A test case for this is "fex2bin a-star_kv49l.fex".

This patch fixes an execution path in script_fex.c that would
allow script_parse_fex() to fail (i.e. return 0) without providing
any feedback to the user.

Signed-off-by: Bernhard Nortmann <[email protected]>
@@ -271,7 +271,7 @@ static int decompile_section(void *bin, size_t bin_size,
} else if (gpio->port < 1 || gpio->port > GPIO_BANK_MAX) {
pr_err("%s: %s.%s: unknown GPIO port bank %c (%u)\n",
filename, section->name, entry->name,
'A'+gpio->port, gpio->port);
'@'+gpio->port, gpio->port);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The '@' character looks a little bit odd here. Maybe it's better to have a cleaner error message variant for the cases when the bank number can't be mapped to a valid latin letter?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It looks odd, but the message also prints the decimal bank number - so it should be possible for the user to identify the problem even when gpio->port <= 0. There are other places where something like 'A' + gpio->port - 1 gets used - but it don't really consider that "cleaner".

@ssvb
Copy link
Contributor

ssvb commented May 19, 2016

The "fexc: Don't fail silently on parse error" patch looks good to me. BTW, what are we going to do with the discovered broken FEX files in the sunxi-boards repository?

@n1tehawk
Copy link
Collaborator Author

BTW, what are we going to do with the discovered broken FEX files in the sunxi-boards repository?

No idea. 😄 I have created corresponding issues, but it remains to be seen whether anybody cares... Who's "in charge" of the sunxi-boards repo? I noticed that there also seem to be several pull requests pending.

One of the reasons I'm aiming at some automated testing of the .fex files is to have a proper functional test of sunxi-fexc - and the other is to discover such bad configurations, and prevent "broken" files from going into the repo again in the future (or a least: discover and fix them early).

@n1tehawk
Copy link
Collaborator Author

If that was more of a "technical" question instead of an administrative one: For now I have simply resorted to using a set of patches to the .fex files for my testing - see n1tehawk@2876aff. With those applied (and the sunxi-fexc modifications from this PR), the .fex → .bin → .fex cycle can be completed successfully for all sys_config files in the repo.

@n1tehawk n1tehawk added the fexc label May 21, 2016
@ssvb
Copy link
Contributor

ssvb commented May 24, 2016

Who's "in charge" of the sunxi-boards repo?

Not sure about this, maybe @jwrdegoede knows something?

One of the reasons I'm aiming at some automated testing of the .fex files is to have a proper functional test of sunxi-fexc - and the other is to discover such bad configurations, and prevent "broken" files from going into the repo again in the future (or a least: discover and fix them early).

Yes, enabling continuous integration for sunxi-boards and doing at least some basic automatic validation for the contributed FEX files would make sense.

@jwrdegoede
Copy link
Contributor

Hi,

On 24-05-16 11:32, Siarhei Siamashka wrote:

Who's "in charge" of the sunxi-boards repo?

Not sure about this, maybe @jwrdegoede https://github.com/jwrdegoede knows something?

No one really is, a bunch of us has access and we all pull in patches posted to
the list every now and then. It is really just a collection of fex files
for easy reference.

Regards,

Hans

@n1tehawk
Copy link
Collaborator Author

Hi Hans!

It is really just a collection of fex files for easy reference.

Some of which are untested / broken, i.e. won't compile with our current sunxi-fexc...

@ssvb Siarhei - if I'm not mistaken, you have write access to the sunxi-boards repo, too.

Regards, NiteHawk

Both the error output in function decompile_section() and the
definition of GPIO_BANK_MAX in script.h suffered from an "off
by one" logic. The bank numbering in the .bin is based on 1,
so it should be added to ('A' - 1) for human-readable output,
and the maximum number corresponding to 'N' is 14.

This became apparent when trying to translate a fex2bin-compiled
a80_optimus_board.bin back to its original .fex equivalent.

Signed-off-by: Bernhard Nortmann <[email protected]>
@n1tehawk n1tehawk force-pushed the 20160518_fexc-fixes branch from 5bb213f to 6271d37 Compare May 25, 2016 09:23
@n1tehawk
Copy link
Collaborator Author

I have reworked the second commit not to output any 'invalid' bank letters any more (and just use the number instead). From my point of view, this should be good to merge now?

@ssvb
Copy link
Contributor

ssvb commented May 25, 2016

Thanks, looks good now.

@n1tehawk
Copy link
Collaborator Author

I'll probably add to this PR to address a quirk detected with decompiling (malformed) .bin files.
See linux-sunxi/sunxi-boards#50 (comment)

n1tehawk added 3 commits May 26, 2016 02:10
Recent original .bin files showed up with a version[0] of 49152
= 0xC000, which won't pass our current sanity checks. Restrict
version[0] check to lower 14 bits, to make it pass again.

(This might require further investigation in the future, as it's
possible that this particular header field actually isn't related
to version data at all.)

Fixes linux-sunxi#51.

Signed-off-by: Bernhard Nortmann <[email protected]>
script_bin.c decompiles section entries even if they have invalid
indentifiers. Thus malformed .bin files were observed to result in
a .fex that couldn't be processed successfully with the sunxi-fexc
compiler.

This patch makes bin2fex now issue a warning for this kind of keys,
so that they're easier to notice and correct.

Signed-off-by: Bernhard Nortmann <[email protected]>
Such lines do not conform to any known syntax rules.

With this patch, fexc will assume that they represent a special
case (where bin2fex extracted a malformed indentifier from a .bin
file - likely a remnant from a comment typo), issue a warning and
ignore the line.

Signed-off-by: Bernhard Nortmann <[email protected]>
@n1tehawk
Copy link
Collaborator Author

In the end I decided to follow a two-fold strategy here: 1. Have bin2fex issue a warning when encountering suspicious key names, but otherwise still decompile what's "in" the .bin file; and 2. make fex2bin warn on those ':' lines, but simply ignore them (assuming they were comments originally).

This should solve the problems that linux-sunxi/sunxi-boards#50 related to.

Siarhei, if you're okay with the three new commits above, I'd like to merge this - allowing me to move forward with another branch adding actual .fex ↔ .bin tests to Travis CI.

@ssvb
Copy link
Contributor

ssvb commented May 30, 2016

Thanks, this seems to be reasonable and Acked-by: Siarhei Siamashka <[email protected]>

@n1tehawk n1tehawk merged commit b416803 into linux-sunxi:master May 30, 2016
@n1tehawk
Copy link
Collaborator Author

Merged. Thanks for reviewing!

@n1tehawk n1tehawk deleted the 20160518_fexc-fixes branch May 31, 2016 09:34
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants