On Sat, Aug 18, 2012 at 5:56 PM, stefano babic sbabic@denx.de wrote:
Am 19/08/2012 00:29, schrieb Marek Vasut:
Dear Matt Sealey,
On Sat, Aug 18, 2012 at 10:34 AM, Stefano Babic sbabic@denx.de wrote:
On 17/08/2012 20:19, Matt Sealey wrote:
The i.MX Boot ROM lets us set up certain registers before U-Boot even gets executed. Rather than setting up DDR, putting U-Boot in place, and getting into pre-relocation init to set up DDR again, just do it once in the correct place. This also solves an issue where the Smarttop DDR pad settings were being applied on Smartbook.
While we're at it, configure PCBID0,1,2 and the LED GPIO since we've still got room in the DCD to do so.
Signed-off-by: Matt Sealey matt@genesi-usa.com
Hi Matt,
diff --git a/board/genesi/mx51_efikamx/imximage_mx.cfg b/board/genesi/mx51_efikamx/imximage_mx.cfg index 6fe0ff9..ac9aa9a 100644 --- a/board/genesi/mx51_efikamx/imximage_mx.cfg +++ b/board/genesi/mx51_efikamx/imximage_mx.cfg @@ -1,7 +1,7 @@
#
+# Copyright (C) 2009 Pegatron Corporation
^---Was this added for mistake ? I think you should add only yours.
The drive strength settings came from Pegatron a long, long time ago (2009 :) and our old config and the function is copyrighted to them. Just because Marek took them out and recopyrighted the file I derived them from in this case doesn't mean they lost their copyright..
This file was taken from mx51evk. It's written there. Please stop this nonsense, it's troubling me.
Then Pegatron has nothing to do with it. The original comes from Freescale, and the copyright was set.
Here is the pedigree of the code from initial table to current implementation, as it stands;
* 2009, Pegatron wrote their U-Boot port for the board * 2009, Pegatron gave us these drive strength settings based on some very expensive and laborious testing and calibration of the DDR implementation on the board. They did not update the settings in the DCD table, they just implemented this function which persisted in Marek's port to mainline * 2010, Marek took the mx51evk example and added the OLD DCD table to imximage.cfg and left the Pegatron drive strength code in there. Marek removed the Pegatron copyright, and Genesi's copyright, and Freescale's copyright but left the original code copyright he took from U-Boot. You cannot just remove the copyright pedigree from the chain just because you decided the "source" of the code was one guy when you copy paste it from some other place * 2012, we put the Pegatron copyrights back in, removed the drive strength function from the board file, re-integrated it into the imximage.cfg layout, and added our copyrights since we did the expensive and laborious testing of the values and cross-referencing of the manual.
The copyrights on every Efika MX file, since they were ALL ported from the original Pegatron reference code should be;
Copyright (C) 2009 Freescale Semiconductor Copyright (C) 2009 Pegatron Corporation Copyright (C) 2009-2012 Genesi USA, Inc. <name of the guy who you copied the mx51evk board file or imximage.cfg from> <your name here>
And that's that. We are looking to go about restoring the pedigree, that's all.
If this was a $5000 dog, you would be concerned if you found out someone had accidentally removed some history where it's grandmother bred with a mongrel and invalidated it's pure-bred status. I can assure you the money spent on coding this original code was more than the cost of a dog and the copyright chain should persist whether you think you "wrote" the code yourself or "copied" it from elsewhere in U-Boot.
The MX51EVK board files may have been where whoever originally committed them sourced it from, but this is not the true source of the code contained in the drive strength function we removed, the data contained in it, or the PCB ID table that's listed in the comments. The MX51EVK DDR settings in imximage.cfg are not the same as the ones in the old Efika MX file, so these have been ported from Pegatron's old DCD data. The new drive strength settings are sourced from the function and moved back into the DCD. All I did was verify they worked and we were not redundantly setting up the same register twice or pushing defaults information via the DCD to registers (since we only have 60 entries, doing every DDR pad control plus the required PCB ID setup overflows the maximum).