[PATCH] Verify EEPROM integrity

This forum is dedicated to software development related to MultiWii.
It is not the right place to submit a setup problem.
Software download
Tommie
Posts: 438
Joined: Sun Apr 08, 2012 9:50 am

[PATCH] Verify EEPROM integrity

Post by Tommie »

With the latest changes, the EEPROM layout changes with the options enabled in config.h; if a copter does not use GPS, the configuration struct lacks the necessary fields for it. This creates a potential danger that fields might be misplaced if additional sensors are added or removed from the copter; in the worst case, the ARM boxitem might get activated during a configaration change and reflash.

This patch adds the configuration struct size to the struct itself, so changes will be noticed during load. It also adds two magic numbers to enclose the configuration parameters as well as a XOR checksum over the entire structure, preventing undesired effects or even damage.

The patch against the current _shared codebase is available on my github branch:
https://github.com/wertarbyte/multiwii- ... eeprom_chk

doughboy
Posts: 252
Joined: Tue Sep 04, 2012 7:20 am

Re: [PATCH] Verify EEPROM integrity

Post by doughboy »

thanks for the patch. I was wondering what was wrong with my setup until I figured out the eeprom layout changes everytime a feature is enabled/disabled. :0
I used to use ICSP programmer and that always wipe out the eeprom. then switched to ftdi and uploading via bootloader, which does not clear the eeprom and started seeing this problem.

User avatar
shikra
Posts: 783
Joined: Wed Mar 30, 2011 7:58 pm

Re: [PATCH] Verify EEPROM integrity

Post by shikra »

I enabled/disabled camstab tonight during some debugging.
And your fear confirmed - the arm button became enabled.

Of course I had the props off... ;) :shock:

Tommie
Posts: 438
Joined: Sun Apr 08, 2012 9:50 am

Re: [PATCH] Verify EEPROM integrity

Post by Tommie »

Are you actually using the ARM function via AUX switch? I once proposed a patch making it possible to disable that feature. It did not get included though.

fiendie
Posts: 151
Joined: Fri Apr 20, 2012 4:22 pm

Re: [PATCH] Verify EEPROM integrity

Post by fiendie »

shikra wrote:I enabled/disabled camstab tonight during some debugging.
And your fear confirmed - the arm button became enabled.

Of course I had the props off... ;) :shock:

Can someone PLEASE merge the patch that makes arming via AUX configurable? => https://github.com/wertarbyte/multiwii-firmware/compare/upstream_shared...disable_aux_arm
It's completely useless IMO and potentially dangerous, too, obviously.
And who would waste and AUX channel for that anyway?
Arming via Roll can be also be disabled in config.h already.

Tommie
Posts: 438
Joined: Sun Apr 08, 2012 9:50 am

Re: [PATCH] Verify EEPROM integrity

Post by Tommie »

fiendie wrote:
shikra wrote:I enabled/disabled camstab tonight during some debugging.
And your fear confirmed - the arm button became enabled.

Of course I had the props off... ;) :shock:

Can someone PLEASE merge the patch that makes arming via AUX configurable? => https://github.com/wertarbyte/multiwii-firmware/compare/upstream_shared...disable_aux_arm
It's completely useless IMO and potentially dangerous, too, obviously.
And who would waste and AUX channel for that anyway?
Arming via Roll can be also be disabled in config.h already.

I just re-did the patch so it can be applied to the current code base: viewtopic.php?f=8&t=2492

User avatar
jevermeister
Posts: 708
Joined: Wed Jul 20, 2011 8:56 am
Contact:

Re: [PATCH] Verify EEPROM integrity

Post by jevermeister »

why is arming via aux useless? I fly three different copter softwares and all use an arm switch.imho there is no alternative to that. I want control over armed status like in my car. you do not have to use it . just leave the boxes empty. and btw. you do not need an exclusive channel. i mixed it with acc mode and a three state switch.

additionally: one should be careful with merging untested intentional changes to the trunk. I did bad mistakes by acting to quickly in the recent past.

just sayong....

nils

fiendie
Posts: 151
Joined: Fri Apr 20, 2012 4:22 pm

Re: [PATCH] Verify EEPROM integrity

Post by fiendie »

jevermeister wrote:why is arming via aux useless? I fly three different copter softwares and all use an arm switch.imho there is no alternative to that. I want control over armed status like in my car. you do not have to use it . just leave the boxes empty. and btw. you do not need an exclusive channel. i mixed it with acc mode and a three state switch.

So you can't fly without ACC?
Look, you can arm your copters anyway you want. As long as I can disable it.
IMO arming should be as deliberate as possible. I think arming via AUX is misguided because it's so easy to mess up the Box Items and the bug clearly shows that it can be dangerous.

additionally: one should be careful with merging untested intentional changes to the trunk. I did bad mistakes by acting to quickly in the recent past.

just sayong....

nils

That's why I always thought the debate about tommie breaking _shared for 2 hours was incredibly disingenuous. Stuff breaks all the time, sometimes for days or weeks, like the thing with LED_FLASHER not working when you don't have a BUZZER.

doughboy
Posts: 252
Joined: Tue Sep 04, 2012 7:20 am

[PATCH] Verify EEPROM integrity

Post by doughboy »

I won't say it's useless, but it is definitely redundant. I think it is used in in flight acc calibration right? Which I think you wrote?

I think if space (resources) is considered a premium, I would not mind if the arm option is just completely removed. You can still do in flight acc calibration via passthru switch.

doughboy
Posts: 252
Joined: Tue Sep 04, 2012 7:20 am

[PATCH] Verify EEPROM integrity

Post by doughboy »

fiendie wrote:Look, you can arm your copters anyway you want. As long as I can disable it.


I have to say personal preferences should be kept out of the main code. After all, this is open source and anyone can check out and customize the heck out of the code to suit one's preference.

User avatar
jevermeister
Posts: 708
Joined: Wed Jul 20, 2011 8:56 am
Contact:

Re: [PATCH] Verify EEPROM integrity

Post by jevermeister »

Aux1: Off/Armed/Armed+ACC
Either by 3 way switch or mixer.

imho it is fruitless to circumvent this by introducing a turn off method for a function that is turned on/off in gui. people will wonder why it does not work. fix the stry bit problem. it is ridiculous to fix the symptom but leave the root of problem alone and live with a bug.

nils

User avatar
jevermeister
Posts: 708
Joined: Wed Jul 20, 2011 8:56 am
Contact:

Re: [PATCH] Verify EEPROM integrity

Post by jevermeister »

I almost foegot:
kudos for finding this effect of the stray bit.
not an easy catch i think.

nils

fiendie
Posts: 151
Joined: Fri Apr 20, 2012 4:22 pm

Re: [PATCH] Verify EEPROM integrity

Post by fiendie »

doughboy wrote:
fiendie wrote:Look, you can arm your copters anyway you want. As long as I can disable it.


I have to say personal preferences should be kept out of the main code. After all, this is open source and anyone can check out and customize the heck out of the code to suit one's preference.

But we can already disable arming via Roll or Yaw? What's the big deal? And yes, I already have it completely disabled here. My point was that it's easy to tick the wrong tiny box in the GUI...

fiendie
Posts: 151
Joined: Fri Apr 20, 2012 4:22 pm

Re: [PATCH] Verify EEPROM integrity

Post by fiendie »

jevermeister wrote:Aux1: Off/Armed/Armed+ACC
Either by 3 way switch or mixer.

imho it is fruitless to circumvent this by introducing a turn off method for a function that is turned on/off in gui. people will wonder why it does not work. fix the stry bit problem. it is ridiculous to fix the symptom but leave the root of problem alone and live with a bug.

nils

Oh, you mean like it was the whole time before the firmware started telling GUI what capabilities the copter had?
You might have missed it, but that is the case now. The ARM Boxitem wouldn't even be there, so what's your point?

Tommie
Posts: 438
Joined: Sun Apr 08, 2012 9:50 am

Re: [PATCH] Verify EEPROM integrity

Post by Tommie »

jevermeister wrote:why is arming via aux useless? I fly three different copter softwares and all use an arm switch.imho there is no alternative to that. I want control over armed status like in my car. you do not have to use it . just leave the boxes empty.

Leaving the boxes empty does not help if an undetected EEPROM layout change fills them.
That's why I consider both patches a viable safety bonus: https://github.com/wertarbyte/multiwii- ... le_aux_arm https://github.com/wertarbyte/multiwii- ... eeprom_chk

User avatar
shikra
Posts: 783
Joined: Wed Mar 30, 2011 7:58 pm

Re: [PATCH] Verify EEPROM integrity

Post by shikra »

Tommie wrote:Are you actually using the ARM function via AUX switch? I once proposed a patch making it possible to disable that feature. It did not get included though.

No I don't use arm function.
I think it is worthwhile - I just don't do acro stuff which will put the sticks in motor off scenario....
Definitely should stay - I think its really usefull.

Personally I'm not really worried if there is an option to disable in the code, but I am a little concerned that maybe a newb would not appreciate its role - and accidentally set it.

That said I think both your patches (or some variation) should be included
And keep to the same standard as others - camstab/gps etc. Enable arm if you want. My concern is the newbs -
Disabled by defalut -enable if you want the feature

It caught me out without realising - was working disabled camstab and made a couple of changes, uploaded and as soon as it reset 6 motors come to life. The dog shit itself. quickly followed by me...

copterrichie
Posts: 2261
Joined: Sat Feb 19, 2011 8:30 pm

Re: [PATCH] Verify EEPROM integrity

Post by copterrichie »

jevermeister wrote:why is arming via aux useless? I fly three different copter softwares and all use an arm switch.imho there is no alternative to that. I want control over armed status like in my car. you do not have to use it . just leave the boxes empty. and btw. you do not need an exclusive channel. i mixed it with acc mode and a three state switch.

additionally: one should be careful with merging untested intentional changes to the trunk. I did bad mistakes by acting to quickly in the recent past.

just sayong....

nils


I also tried the Arming via an AUX and felt it was too dangerous, I prefer the normal arming procedures.

Sebbi
Posts: 478
Joined: Sun Jul 08, 2012 1:08 am
Location: Germany
Contact:

Re: [PATCH] Verify EEPROM integrity

Post by Sebbi »

The arm box/switch is useful on airplanes where you don't want to disarm it while gliding (motor off). However, airplanes could just be always armed ...

Tommie
Posts: 438
Joined: Sun Apr 08, 2012 9:50 am

Re: [PATCH] Verify EEPROM integrity

Post by Tommie »

Well, no one advocates removing the ARM box for everyone, I just find it convinient to remove it through my personal configuration choice.
Please look at patches being discussed before crying about how stuff is taken away from you.
Last edited by Tommie on Fri Sep 21, 2012 1:53 pm, edited 1 time in total.

timecop
Posts: 1880
Joined: Fri Sep 02, 2011 4:48 pm

Re: [PATCH] Verify EEPROM integrity

Post by timecop »

So like, this patch simply makes aux arming a compile time decision to include or not.
you can simple apply the patch, make the function included by default, and there is no difference for end users.
Why is this discussion 2 pages long already.

Tommie
Posts: 438
Joined: Sun Apr 08, 2012 9:50 am

Re: [PATCH] Verify EEPROM integrity

Post by Tommie »

timecop wrote:So like, this patch simply makes aux arming a compile time decision to include or not.
you can simple apply the patch, make the function included by default, and there is no difference for end users.
Why is this discussion 2 pages long already.

Well, especially since this is the wrong thread about it - this one should be about checksumming the eeprom content and sprinkling it with magic numbers :-)

Having BOXARM is just an impressive way of demonstrating the issue with current EEPROM handling.

frogstarb
Posts: 59
Joined: Wed Jul 25, 2012 10:52 pm

Re: [PATCH] Verify EEPROM integrity

Post by frogstarb »

timecop wrote:Why is this discussion 2 pages long already.


My first reaction was "another one without any exposure to open source development" but then I realized it was timecop :)

Best example of perfect usage of the irony and sarcasm combo I've seen in a while! Congrats

User avatar
Hamburger
Posts: 2578
Joined: Tue Mar 01, 2011 2:14 pm
Location: air
Contact:

Re: [PATCH] Verify EEPROM integrity

Post by Hamburger »

Sebbi wrote:The arm box/switch is useful on airplanes where you don't want to disarm it while gliding (motor off). However, airplanes could just be always armed ...

Wrong. Lots of MWii functionality depends on status 'unarmed'.

doughboy
Posts: 252
Joined: Tue Sep 04, 2012 7:20 am

[PATCH] Verify EEPROM integrity

Post by doughboy »

fiendie wrote:
doughboy wrote:
fiendie wrote:Look, you can arm your copters anyway you want. As long as I can disable it.


I have to say personal preferences should be kept out of the main code. After all, this is open source and anyone can check out and customize the heck out of the code to suit one's preference.

But we can already disable arming via Roll or Yaw? What's the big deal? And yes, I already have it completely disabled here. My point was that it's easy to tick the wrong tiny box in the GUI...


My post was meant to agree with what you said, I think you interpreted it as I am disagreeing with you. :)

Anyway, I really thing this EEPROM checksum fix should be in main code and provably with a corresponding GUI fix. The box arm issue is not the only issue caused by this design oversight. When hamburger added the fix to vbatmin, I ran into problems also due to the EEPROM layout not matching the new value he added. And do a search in the forum and see how many issues are due to incorrect EEPROM layout and resolved by doing an EEPROM reset in GUI.

Tommie
Posts: 438
Joined: Sun Apr 08, 2012 9:50 am

Re: [PATCH] Verify EEPROM integrity

Post by Tommie »

Feel free to merge, the patch set is there.

fiendie
Posts: 151
Joined: Fri Apr 20, 2012 4:22 pm

Re: [PATCH] Verify EEPROM integrity

Post by fiendie »

doughboy wrote:My post was meant to agree with what you said, I think you interpreted it as I am disagreeing with you. :)

OK, now I get it =)

Danal
Posts: 137
Joined: Tue Oct 18, 2011 5:15 pm

Re: [PATCH] Verify EEPROM integrity

Post by Danal »

fiendie wrote:
shikra wrote:I enabled/disabled camstab tonight during some debugging.
And your fear confirmed - the arm button became enabled.

Of course I had the props off... ;) :shock:

Can someone PLEASE merge the patch that makes arming via AUX configurable? => https://github.com/wertarbyte/multiwii-firmware/compare/upstream_shared...disable_aux_arm
It's completely useless IMO and potentially dangerous, too, obviously.
And who would waste and AUX channel for that anyway?
Arming via Roll can be also be disabled in config.h already.



People who already have the habit of hitting "throttle hold" switch just before a crash really like to have arm/disarm on a switch. And not to have "motor stop" at zero throttle.

So, configurable is a great idea.

Tommie
Posts: 438
Joined: Sun Apr 08, 2012 9:50 am

Re: [PATCH] Verify EEPROM integrity

Post by Tommie »

I have more a generic question:

Why take ideas from the forum, re-implement them in an inferior way, and not even give a single line of credit to the proposer in the commit message?
https://code.google.com/p/multiwii/source/detail?r=1144

While I appreciate the addition of a checksum to the conf struct, my changes address the issue far more thoroughly; a checksum alone might not detect configuration size changes (the default value of EEPROM data is 0xFF, so adding two bytes to the struct might not change the checksum). That's why my patchset includes the struct size and canary indicators. It also clarifies the reset procedures and does not rely on positioning of the checksum parameter.

So why try to reimplement the wheel, creating an octagon, while a round one is already there? If there are any issues regarding my patches, please step forward - this is a discussion board-, but simply walking over it does not feel like good style.

Alexinparis
Posts: 1630
Joined: Wed Jan 19, 2011 9:07 pm

Re: [PATCH] Verify EEPROM integrity

Post by Alexinparis »

magic_be and magic_ef seem to be an over protection

MIS code seems to be simpler, maybe not stronger but probably shorter, and in any case not copy paste based.

@MIS:
readEEPROM(); // not needed and removed to avoid endless loop
It is needed to recalculate lookupPitchRollRC and so on.

Tommie
Posts: 438
Joined: Sun Apr 08, 2012 9:50 am

Re: [PATCH] Verify EEPROM integrity

Post by Tommie »

Alexinparis wrote:magic_be and magic_ef seem to be an over protection

No. Consider removing a boxitem, which results in the removal or addition of 2 byte from the conf struct: this will not alter the checksum value, and depending on the values will slip through unnoticed. That's why the canary members magic_be and magic_ef are included as well as the struct size: the provide plausibility, since even a completely wiped EEPROM will pass the checksum test fine (0xFF ^ 0xFF ^ 0xFF...).

Mis
Posts: 203
Joined: Fri Apr 01, 2011 12:23 am

Re: [PATCH] Verify EEPROM integrity

Post by Mis »

BUT removing a boxitem move the checksum byte to other position. No way for good checksum in this way.
Tomme, as far i know, your patch check only config data size, and don't checking data integrity.

Tommie
Posts: 438
Joined: Sun Apr 08, 2012 9:50 am

Re: [PATCH] Verify EEPROM integrity

Post by Tommie »

Please look again. My patchset performs several checks to ensure the validity of the configuration data:

1) is the version number identical?
2) is the configuration struct size identical?
3) are the magic canary numbers intact that frame the configuration data?
4) does the XOR checksum match?

2 and/or 3 are critical, since the size of the configuration struct may vary with changes in config.h. Not every change will be detected by a simple MDC, especially if no magic numbers are sprinkled into the mix (e.g. an erased EEPROM will pass a simple XOR test quite fine).

Even having the checksum at another position will not yield an error; imagine this EEPROM content, where [] marks the boundaries of the configuration struct:

[A B C D] E F

D is the checksum, so A^B^C=D, which is equivalent to A^B^C^D=0.

Now we are adding two bytes to the struct, so the new firmware now assumes that the checksum is located at F, this has to fail, right?

[A B C D E F]

Our XOR check now has to fullfill the condition A^B^C^D^E^F=0.
Since we have not changed the EEPROM content, (A^B^C^D) is still zero; E and F are uninitialized, so both have the value of 0xFF, so we actually have:

0 ^ 0xFF ^ 0xFF = 0

Voila, the checksum is verified!
There goes the copter, misinterpreting the EEPROM config he considers completly intact and valid.

Mis
Posts: 203
Joined: Fri Apr 01, 2011 12:23 am

Re: [PATCH] Verify EEPROM integrity

Post by Mis »

Where are you see XOR'ing of the checksum byte ? I use simple adding modulo 256.
I can use full CRC8 checking available in GCC ibutton library, good implementation, but the size... For Mega2560 - no problem, for Mega328 hmmm.

Tommie
Posts: 438
Joined: Sun Apr 08, 2012 9:50 am

Re: [PATCH] Verify EEPROM integrity

Post by Tommie »

Oh, I stand corrected, using a mod checksum of course lessens the risk of accidental misvalidation. I still would have appreciated some kind of technical discussion in this thread before making an existing and proposed patch obsolete by another implementation with the same goal.

Mis
Posts: 203
Joined: Fri Apr 01, 2011 12:23 am

Re: [PATCH] Verify EEPROM integrity

Post by Mis »

Ok, I'm sorry, I see this thread name, and don't even read it, but think "this is simple and not stupid" :D Afrer next 15 minutes i have my simple version ready, and tested. I do not care for entries in "credits" file. If you want, I add info about source of checksum idea in code.
But now, i think about two, three or even four different eeprom settings :)
But not have idea for stick combination for configuration selecting. BUT... maybe little similar to MikroKopter, position of the right stick can select new setting during gyro calibration (right stick down = no change, others position change current setting). Software implementation is pretty easy 8-)

fiendie
Posts: 151
Joined: Fri Apr 20, 2012 4:22 pm

Re: [PATCH] Verify EEPROM integrity

Post by fiendie »

Alexinparis wrote:magic_be and magic_ef seem to be an over protection
MIS code seems to be simpler, maybe not stronger but probably shorter, and in any case not copy paste based.

So let me get this straight: Somebody finds a bug, proposes a readymade solution, someone else "simplifies" it (not even saying if the simplification makes sense at all) or reimplements it and the original submitter doesn't get any credit for it? This is just wrong. And this is not the first time something like this has happened. The point is not if the code is copypasted, the point IMO is that nobody would've even thought of a checksum were it not for the initial patch.

User avatar
shikra
Posts: 783
Joined: Wed Mar 30, 2011 7:58 pm

Re: [PATCH] Verify EEPROM integrity

Post by shikra »

for credits file... "Initial implementation by Tommie, adapted by MIS" sorted. Lets move on to something that will give benefit.

User avatar
shikra
Posts: 783
Joined: Wed Mar 30, 2011 7:58 pm

Re: [PATCH] Verify EEPROM integrity

Post by shikra »

Mis wrote:But not have idea for stick combination for configuration selecting. BUT... maybe little similar to MikroKopter, position of the right stick can select new setting during gyro calibration (right stick down = no change, others position change current setting). Software implementation is pretty easy 8-)


I always wanted this - or thought I did. I now realise what I really wanted was dual rates/expo more than anything. Same copter, but different mood of flying - acro fun or some steady AP/FPV.

copterrichie
Posts: 2261
Joined: Sat Feb 19, 2011 8:30 pm

Re: [PATCH] Verify EEPROM integrity

Post by copterrichie »

fiendie wrote:So let me get this straight: Somebody finds a bug, proposes a readymade solution, someone else "simplifies" it (not even saying if the simplification makes sense at all) or reimplements it and the original submitter doesn't get any credit for it? This is just wrong. And this is not the first time something like this has happened. The point is not if the code is copypasted, the point IMO is that nobody would've even thought of a checksum were it not for the initial patch.


It happens more often then people would like to believe. The End justify the means.

doughboy
Posts: 252
Joined: Tue Sep 04, 2012 7:20 am

Re: [PATCH] Verify EEPROM integrity

Post by doughboy »

I'd say it is the second developer's responsibility (and common courtesy) to credit where he copied the code/idea from, and not the repository owner. So don't blame Alexinparis

User avatar
Hamburger
Posts: 2578
Joined: Tue Mar 01, 2011 2:14 pm
Location: air
Contact:

Re: [PATCH] Verify EEPROM integrity

Post by Hamburger »

Tommie wrote:Why take ideas from the forum, re-implement them in an inferior way, and not even give a single line of credit to the proposer in the commit message?
https://code.google.com/p/multiwii/source/detail?r=1144


fiendie wrote:
Alexinparis wrote:magic_be and magic_ef seem to be an over protection
MIS code seems to be simpler, maybe not stronger but probably shorter, and in any case not copy paste based.

So let me get this straight: Somebody finds a bug, proposes a readymade solution, someone else "simplifies" it (not even saying if the simplification makes sense at all) or reimplements it and the original submitter doesn't get any credit for it? This is just wrong. And this is not the first time something like this has happened. The point is not if the code is copypasted, the point IMO is that nobody would've even thought of a checksum were it not for the initial patch.



ridiculous. Fuzzing over checksum and start/stop control characters?
Besides, use the search function, you are late yourselves, a lot of other people have discussed eeprom handling or even done such work for MWii before you (and you have joined such discussions in the past as well, so you cannot feign ignorance).

viewtopic.php?f=8&t=1482&hilit=eeprom
viewtopic.php?f=8&t=1720&hilit=eeprom

Tommie
Posts: 438
Joined: Sun Apr 08, 2012 9:50 am

Re: [PATCH] Verify EEPROM integrity

Post by Tommie »

Oh yes, I just checked your links - looks like someone already created a patch for Multiwii with checksum creation in april. Oh, I also just noticed that it was me.

nicog
Posts: 88
Joined: Tue Aug 21, 2012 2:21 pm

Re: [PATCH] Verify EEPROM integrity

Post by nicog »

JAJAJAJJAJAJA... well done Tommie.

ReadError
Posts: 70
Joined: Sun Sep 09, 2012 11:08 pm

Re: [PATCH] Verify EEPROM integrity

Post by ReadError »

viewtopic.php?f=8&t=1720&hilit=eeprom#p14501

Hamburger wrote:Tommie,
I am not going to stop you :)
I was looking for an easy fix. We could probably copy an alternate implementation from dongs stm32 port of MWii. I have not investigated any further yet - like i said 'looking for an easy fix'.
Cheers, Hamburger


Stops you.

Tommie
Posts: 438
Joined: Sun Apr 08, 2012 9:50 am

Re: [PATCH] Verify EEPROM integrity

Post by Tommie »

It's just something I pointed out several times before: people invest time to create patches and fix problems with their firmware, publish the patch in this forum - where it gets ignored and starts rotting due to the source code base moving further. Then after some time, somehow picks up the idea, rewrites the entire stuff from scratch and commits - basically saying "Screw you and your code, I'll not even look at it, I'll just reuse your idea, making your work completely obsolete and throwing you engagement into the waste bucket"

It's kind of annoying and really discourages participation.

User avatar
jevermeister
Posts: 708
Joined: Wed Jul 20, 2011 8:56 am
Contact:

Re: [PATCH] Verify EEPROM integrity

Post by jevermeister »

I wish I was an admin in this forum. I would close this ridicolous thread and kick ban all of you lousy trolls. Some people are behaving like children here.
Normally my agenda is not to feed the trolls but this discussion is so childish. I am happier than ever that I stopped contributing to this codebase when I see things like this.
Normally I lean back and watch the usual bullshit jibber jabber and wait for good contributes to be made but I am so fed up right now.

Guys:Do what is best for the code and keep the personalities out of it.

Boooooh
-1

copterrichie
Posts: 2261
Joined: Sat Feb 19, 2011 8:30 pm

Re: [PATCH] Verify EEPROM integrity

Post by copterrichie »

People have a right to express their views, rightly or wrong! What is important is, views/opinion are allowed to be freely expressed.

fiendie
Posts: 151
Joined: Fri Apr 20, 2012 4:22 pm

Re: [PATCH] Verify EEPROM integrity

Post by fiendie »

jevermeister wrote:I wish I was an admin in this forum. I would close this ridicolous thread and kick ban all of you lousy trolls. Some people are behaving like children here.
Normally my agenda is not to feed the trolls but this discussion is so childish. I am happier than ever that I stopped contributing to this codebase when I see things like this.
Normally I lean back and watch the usual bullshit jibber jabber and wait for good contributes to be made but I am so fed up right now.

Guys:Do what is best for the code and keep the personalities out of it.

Boooooh
-1

Dude, you're are just showboating.
I've read enough of your posts to know that you are just as confrontational and self-serving as anyone else. So stop the silly chest-thumping.
I hate to break it to you, but sometimes people argue on the internet.

I fully agree with copterrichie. If you have something to say on the issue, then go ahead. If not then how about not saying anything at all?
Because until Hamburger and you showed up the tone was perfectly civilized.

Mis
Posts: 203
Joined: Fri Apr 01, 2011 12:23 am

Re: [PATCH] Verify EEPROM integrity

Post by Mis »

Oh yes Tommie, eeprom checksum is great, unusual feature, and you first invented it.
From my side - EOT.

Tommie
Posts: 438
Joined: Sun Apr 08, 2012 9:50 am

Re: [PATCH] Verify EEPROM integrity

Post by Tommie »

I'm not claiming to be the first to come up with the idea; I am just complaining that submitting patches to this forum and project is obviously completely useless; they get completely ignored, there is no technical discussion about the reasons for that, but sdometimes, the same feature pops up later with a different implementation. You said it yourself: You saw the general idea in the thread title and reimplemented it yourself without even looking at the attached patchset. This translates loosely to: "Screw you with the work you put into your changeset, we can do it bettter anyway, I won't even bother looking at your stinking code."

It's not the first time this happened, and I think it says a lot about the attitude towards the contributions of people outside the core gang.

Post Reply