Hi to all,
I used flashrom to flash the BIOS on a AxiomTek SBC84500, which mounts a Winbond W29C020C. All is recognized fine, but the flashing fails.
# flashrom -v -w axiom.bin No LinuxBIOS table found. Enabling flash write on CS5530...OK W29C020C found at physical address: 0xfffc0000 Flash part is S29C51002T (256 KB) Flash image seems to be a legacy BIOS. Disabling checks. Programming Page: 2047 at address: 0x0003ff80 Verifying flash - FAILED.
Trying fo find out the cause of the failure I eventually found a grave error in jedec.c, at write_page_write_jedec(). The code:
if (*src == 0xFF) continue; *dst++ = *src++;
is, of course, wrong. It should be
if (*src != 0xFF ) *dst = *src; dst++; src++;
I include a patch which fixes this error. But this is not enough. Sector writes sometimes fail, so included a check/rewrite code similar to write_byte_program_jedec(). Maybe this is not the best way to do the task, but at least for me works :)
Furthermore, the patch adds support for the SyncMos S29C51002T 256K flash. Tested successfully on a Boser HS-2603. It is high probable that the same configuration would work with all the chips of the same family.
# flashrom -v -w boser.bin No LinuxBIOS table found. Enabling flash write on CS5530...OK S29C51002T found at physical address: 0xfffc0000 Flash part is S29C51002T (256 KB) Flash image seems to be a legacy BIOS. Disabling checks. Programming Page: 2047 at address: 0x0003ff80 Verifying flash - VERIFIED
That's all. Ciao.
Hi,
On Wed, Nov 15, 2006 at 09:37:36AM +0100, Giampiero Giancipoli wrote:
goto retry;
Um, do we really want to use GOTOs in userland code?
There are some GOTOs in the LinuxBIOS code already, but I'd rather remove those than introduce new ones... Is there a consensus about GOTO usage in LinuxBIOS? Do we allow that? If no, I'll update the development guidelines accordingly...
Uwe.
On Thu, Nov 16, 2006 at 09:45:02PM +0100, Uwe Hermann wrote:
On Wed, Nov 15, 2006 at 09:37:36AM +0100, Giampiero Giancipoli wrote:
goto retry;Um, do we really want to use GOTOs in userland code?
goto can be good. I was allergic to goto for many years but then I found my cluestick; I really like having fewer indent steps and to use goto for forward references and/or error handling. I think it makes code much simpler to read.
Of course the unexperienced programmer will not intuitively know when to avoid goto and when to use them, but I don't think very many work on this project and when they want to we'll just show them how to do it right. :)
//Peter
* Peter Stuge stuge-linuxbios@cdy.org [061117 01:41]:
Um, do we really want to use GOTOs in userland code?
goto can be good. I was allergic to goto for many years but then I found my cluestick; I really like having fewer indent steps and to use goto for forward references and/or error handling. I think it makes code much simpler to read.
Yes, goto is the C programmer's exception handling. Describing the exception scenario with additional scopes seems not only less elegant, but also wrong from a design perspective.
Of course the unexperienced programmer will not intuitively know when to avoid goto and when to use them, but I don't think very many work on this project and when they want to we'll just show them how to do it right. :)
Yes, I think the rule should be "use goto if you really think you mess up your code otherwise, and await the code review to rend your implementation"
Yes, I think the rule should be "use goto if you really think you mess up your code otherwise, and await the code review to rend your implementation"
OK then. This should be documented, though.
Uwe.
There are some GOTOs in the LinuxBIOS code already, but I'd rather remove those than introduce new ones... Is there a consensus about GOTO usage in LinuxBIOS? Do we allow that? If no, I'll update the development guidelines accordingly...
Our CodingStyle (borrowed from Linux) currently says that goto's to an error exit path are allowed (preferred to other solutions, actually).
Most other goto's are frowned upon of course.
Segher
On Fri, 2006-11-17 at 02:49 +0100, Segher Boessenkool wrote:
There are some GOTOs in the LinuxBIOS code already, but I'd rather remove those than introduce new ones... Is there a consensus about GOTO usage in LinuxBIOS? Do we allow that? If no, I'll update the development guidelines accordingly...
Our CodingStyle (borrowed from Linux) currently says that goto's to an error exit path are allowed (preferred to other solutions, actually).
Most other goto's are frowned upon of course.
Why exactly is this anyways? Pesonally, I agree with Peter that gotos make code much easier to follow, but I always learned that they were frowned upon, my C++ instructer in college refused to even teach about it (although he couldn't tell me why either). Also, you state "CodingStyle" as one word...is there a specific page/doc outlining what the preferred coding style is, or is it just a general consensus deal?
-Corey
On Thu, Nov 16, 2006 at 11:06:43PM -0500, Corey wrote:
Our CodingStyle (borrowed from Linux) currently says that goto's to an error exit path are allowed (preferred to other solutions, actually).
Most other goto's are frowned upon of course.
Why exactly is this anyways? Pesonally, I agree with Peter that gotos make code much easier to follow, but I always learned that they were frowned upon, my C++ instructer in college refused to even teach about it (although he couldn't tell me why either). Also, you state "CodingStyle" as one word...is there a specific page/doc outlining what the preferred coding style is, or is it just a general consensus deal?
I've documented it in the wiki now: http://www.linuxbios.org/Development_Guidelines#Coding_Guidelines
We just use the plain Linux coding style currently (or rather: in future; most code in svn doesn't follow the coding style, yet).
Uwe.
Why exactly is this anyways? Pesonally, I agree with Peter that gotos make code much easier to follow, but I always learned that they were frowned upon, my C++ instructer in college refused to even teach about it (although he couldn't tell me why either). Also, you state "CodingStyle" as one word...is there a specific page/doc outlining what the preferred coding style is, or is it just a general consensus deal?
At the Hamburg conference, it was decided to generally use the Linux coding style, which is mostly documented in a file called CodingStyle in the Linux source tree.
Segher
* Corey corey_osgood@verizon.net [061117 05:06]:
Why exactly is this anyways? Pesonally, I agree with Peter that gotos make code much easier to follow, but I always learned that they were frowned upon, my C++ instructer in college refused to even teach about it (although he couldn't tell me why either).
In C++ you are probably supposed to use exceptions to implement that behavior.
The initial idea is that the use of goto makes it hard for the compiler to do code flow optimization. In fact, in case of exceptions or errors, this is mostly irrelevant though.
Also, you state "CodingStyle" as one word...is there a specific page/doc outlining what the preferred coding style is, or is it just a general consensus deal?
We started writing up a cumulative document at http://www.linuxbios.org/Development_Guidelines
On Fri, Nov 17, 2006 at 01:12:55PM +0100, Stefan Reinauer wrote:
The initial idea is that the use of goto makes it hard for the compiler to do code flow optimization.
The initial idea why you should _not_ use GOTOs is that GOTOs suck ;-) There was a paper called "Go To Statement Considered Harmful" from Edsger W. Dijkstra (and that man probably knows what he's talking about) in 1968 (!). GOTOs usually produce unreadable, unmaintainable code and should generally not be used.
But yeah, in low-level programming it may make sense in certain situations, as the code sometimes gets very ugly otherwise...
Uwe.
The initial idea why you should _not_ use GOTOs is that GOTOs suck ;-) There was a paper called "Go To Statement Considered Harmful" from Edsger W. Dijkstra (and that man probably knows what he's talking about) in 1968 (!). GOTOs usually produce unreadable, unmaintainable code and should generally not be used.
Using gotos instead of higher-level control structures is evil. Using such control structures to simulate goto is just as evil.
Segher
Segher Boessenkool segher@kernel.crashing.org writes:
The initial idea why you should _not_ use GOTOs is that GOTOs suck ;-) There was a paper called "Go To Statement Considered Harmful" from Edsger W. Dijkstra (and that man probably knows what he's talking about) in 1968 (!). GOTOs usually produce unreadable, unmaintainable code and should generally not be used.
Using gotos instead of higher-level control structures is evil. Using such control structures to simulate goto is just as evil.
You mean you don't like people writing loops with function calls?
void loop(int n) { if (n > 0) loop(n); return; }
Sorry I couldn't resist. But you certainly have the gist of the Dijkstra's argument. Of course we was slightly biased having introduced several of the higher level constructs if I recall correctly. :)
Eric
You mean you don't like people writing loops with function calls?
Heh, that's a different point :-)
In C, you shouldn't ever do this. In some other languages, where you get guaranteed tail-recursion and whatnot, this actually is good style.
Well OT, back to work :-)
Segher
Uwe Hermann uwe@hermann-uwe.de writes:
On Fri, Nov 17, 2006 at 01:12:55PM +0100, Stefan Reinauer wrote:
The initial idea is that the use of goto makes it hard for the compiler to do code flow optimization.
The initial idea why you should _not_ use GOTOs is that GOTOs suck ;-) There was a paper called "Go To Statement Considered Harmful" from Edsger W. Dijkstra (and that man probably knows what he's talking about) in 1968 (!). GOTOs usually produce unreadable, unmaintainable code and should generally not be used.
But yeah, in low-level programming it may make sense in certain situations, as the code sometimes gets very ugly otherwise...
To a certain extent the title of that paper is unfortunate. What Dijkstra was arguing for was single points of entry and single points of exit. This makes proofs (and other kinds of understanding) of the code much easier.
So the argument was against multiple return statements, continue and break, every much as it was against goto. The core observation was that you can replace any control dependency and with a data dependency and get easier to follow code. (i.e. you can introduce a variable).
Stefan point with the compilers is also valid because they have to understand the code they like this style of programming.
So the ideal is a single point of entry and a single exit from every block of code. In general using gotos for exception handling improve this situation because they reduce the number of unique exit paths from a piece of code. In that context goto's also leave the code more readable because you don't get lots of extra unnecessary levels of indentation, and it easier to follow what the code is really trying to do. So if you are not doing a formal proof but a human inspection proof the goto certainly helps.
I actually suspect Dijkstra might argue against C++ exception handling due to the challenges it places on proving code is correct. The control flow can be completely non-obvious when exceptions are involved. I know there is a lot of C++ that is proof and compilation hostile which makes it a poor choice for low level systems programming.
Dijkstra's papers are available online and I challenge any one who wants to understand this better to dig them up and read them.
Eric
Hi,
On Wed, Nov 15, 2006 at 09:37:36AM +0100, Giampiero Giancipoli wrote:
Furthermore, the patch adds support for the SyncMos S29C51002T 256K flash. Tested successfully on a Boser HS-2603. It is high probable that the same configuration would work with all the chips of the same family.
Please provide separate patches for separate issues. And please sign-off your patches by adding Signed-off-by: Giampiero Giancipoli gianci@email.it in your email. See http://www.linuxbios.org/Development_Guidelines for details.
Index: flashchips.c
--- flashchips.c (revision 2497) +++ flashchips.c (working copy) @@ -114,6 +114,8 @@ #endif {"LHF00L04", SHARP_ID, SHARP_LHF00L04, NULL, 1024, 64 * 1024, probe_lhf00l04, erase_lhf00l04, write_lhf00l04, NULL},
- {"S29C51002T", SM_ID, S29C51002T, NULL, 256, 128,
probe_jedec, erase_chip_jedec, write_49f002, NULL},};
I cannot test the first part of your patch right now, but the second part does not compile. You're using SM_ID and S29C51002T which are not defined anywhere. You have to add them to flash.h, I think.
Cheers, Uwe.
-
Corey -
ebiederman＠lnxi.com -
Giampiero Giancipoli -
Peter Stuge -
Segher Boessenkool -
Stefan Reinauer -
Uwe Hermann