Re: [U-Boot] [PATCH] km/common: add toolchain variable
Hi Wolfgang, On 12/17/2011 09:49 PM, Wolfgang Denk wrote: > In message <1323879110-8404-1-git-send-email-holger.bru...@keymile.com> you > wrote: >> Add a variable "toolchain" and configure the rootpath >> for the nfsargs with this variable. >> >> Signed-off-by: Holger Brunck >> cc: Wolfgang Denk >> --- >> board/keymile/scripts/README |2 +- >> board/keymile/scripts/develop-common.txt |3 ++- >> 2 files changed, 3 insertions(+), 2 deletions(-) >> >> diff --git a/board/keymile/scripts/README b/board/keymile/scripts/README >> index 7fbcf74..dd935b2 100644 >> --- a/board/keymile/scripts/README >> +++ b/board/keymile/scripts/README >> @@ -7,7 +7,7 @@ default environment must be parsed: >> run develop : setup environment to configure for rootfs via nfs >> run ramfs : setup environment to configure for rootfs in ram >> >> -Last change: 20.05.2011 >> +Last change: 24.11.2011 > > Does this really make any sense? Which date are you recording here/ > When you (think) you last edited the file? When you applied the patch > to your local tree? When you submitted it for mainline? When it > actually got applied? > What I want to record is to track the version of the scripts and this makes sense for me. In the end the scripts are copied into /tftpboot on each developers machine and is therefore not under git control. It is an easy indication wether the scripts are uptodate or not, without starting a diff tool and compare them with the latest git tree. Inside the git tree the information is useless, I agree. > I recommend to get rid of this, and rather use git revision > information instead. > I would like to keep this, because git does not easily help here. Best regards Holger ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] Exynos: Fix ARM Clock frequency calculation
Dear Wolfgang Denk, On 19 December 2011 13:27, Wolfgang Denk wrote: > Dear Chander Kashyap, > > In message <1324275424-29468-3-git-send-email-chander.kash...@linaro.org> > you wrote: > > Earliar ARM clock frequency was calculated by: > > MOUTAPLL/(DIVAPLL + 1) which is actually returning SCLKAPLL. > > It is fixed by calcuating it as follows: > > Um Comment and code disagree: > > > ARMCLK=MOUTCORE/(DIVCORE + 1)/DIVCORE2 + 1) > > ...or is this just missing a paren? > > > + dout_apll = get_pll_clk(APLL) / (core_ratio + 1); > > + dout_apll /= (core2_ratio + 1); > > This gives > > ARMCLK=MOUTCORE/(DIVCORE + 1)/ (DIVCORE2 + 1) > > Please check if this is correct. > Below is the scenario of selection. MOUTAPLL --->| MUX_CORE |>MOUTCORE MOUTMPLL --->|| Here MOUTAPLL is selected as input. So Parent is correct. Best regards, > > Wolfgang Denk > > -- > DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel > HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany > Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de > Bus error -- driver executed. > -- with warm regards, Chander Kashyap ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 0/9] Add support for the OpenRISC architecture
Hi Wolfgang, On Sun, Nov 27, 2011 at 07:04:48AM +0200, Stefan Kristiansson wrote: > This patch series adds support for the OpenRISC 1000 architecture. > > The OpenRISC architecture has been around for about a decade and > has experienced a revival in the last couple of years from the > efforts of a small, but dedicated community compound of both > commercial and independent contributors. > > Most of the development takes place on opencores.org/or1k and openrisc.net. > > The patches included in this series are also available in the > 'for-upstream' branch in the following git repository: > > git://openrisc.net/stefan/u-boot > > which is also browsable here: > > http://git.openrisc.net/cgit.cgi/stefan/u-boot/?h=for-upstream > > NOTE: The openrisc-generic board depends on this pending > patch to build properly: > net/ethoc: use flush_dcache_range instead of flush_dcache > (http://patchwork.ozlabs.org/patch/123622/) I have not received any comments (or complaints, depending how you look at it) on the v2 of those patches. I saw your message about the next branch, so would you please consider applying those to that, if nobody has any further comments or objections? Thanks Stefan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] Exynos: Fix ARM Clock frequency calculation
On 19 December 2011 16:57, Wolfgang Denk wrote: > Dear Chander Kashyap, > > In message <1324275424-29468-3-git-send-email-chander.kash...@linaro.org> you > wrote: >> Earliar ARM clock frequency was calculated by: >> MOUTAPLL/(DIVAPLL + 1) which is actually returning SCLKAPLL. >> It is fixed by calcuating it as follows: > > Um Comment and code disagree: > >> ARMCLK=MOUTCORE/(DIVCORE + 1)/DIVCORE2 + 1) > > ...or is this just missing a paren? > >> + dout_apll = get_pll_clk(APLL) / (core_ratio + 1); >> + dout_apll /= (core2_ratio + 1); > > This gives > > ARMCLK=MOUTCORE/(DIVCORE + 1)/ (DIVCORE2 + 1) > > Please check if this is correct. Wolfgang, you are right. ARMCLK=MOUTCORE / (DIVCORE + 1) / (DIVCORE2 + 1) is right. Dear Chander Kashyap, > /* APLL_RATIO: [26:24] */ Please fix this comment also. > - apll_ratio = (div >> 24) & 0x7; > + core_ratio = (div >> 0) & 0x7; > + core2_ratio = (div >> 28) & 0x7; > > - dout_apll = get_pll_clk(APLL) / (apll_ratio + 1); > + dout_apll = get_pll_clk(APLL) / (core_ratio + 1); This output is not dout_apll. Please fix it. > + dout_apll /= (core2_ratio + 1); > > return dout_apll; Thanks Minkyu Kang -- from. prom. www.promsoft.net ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] Exynos: Fix ARM Clock frequency calculation
Dear Wolfgang Denk, On 19 December 2011 13:50, Chander Kashyap wrote: > Dear Wolfgang Denk, > > > On 19 December 2011 13:27, Wolfgang Denk wrote: > >> Dear Chander Kashyap, >> >> In message <1324275424-29468-3-git-send-email-chander.kash...@linaro.org> >> you wrote: >> > Earliar ARM clock frequency was calculated by: >> > MOUTAPLL/(DIVAPLL + 1) which is actually returning SCLKAPLL. >> > It is fixed by calcuating it as follows: >> >> Um Comment and code disagree: >> >> > ARMCLK=MOUTCORE/(DIVCORE + 1)/DIVCORE2 + 1) >> > Yes comment need to be modified. > >> ...or is this just missing a paren? >> >> > + dout_apll = get_pll_clk(APLL) / (core_ratio + 1); >> > + dout_apll /= (core2_ratio + 1); >> >> This gives >> >> ARMCLK=MOUTCORE/(DIVCORE + 1)/ (DIVCORE2 + 1) >> >> Please check if this is correct. >> > > Below is the scenario of selection. > > MOUTAPLL --->| MUX_CORE |>MOUTCORE > MOUTMPLL --->|| > > Here MOUTAPLL is selected as input. So Parent is correct. > > Best regards, >> >> Wolfgang Denk >> >> -- >> DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel >> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany >> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de >> Bus error -- driver executed. >> > > > > -- > with warm regards, > Chander Kashyap > -- with warm regards, Chander Kashyap ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [GIT PULL] Pull request: u-boot-imx
Hi Stefano, Le 19/12/2011 08:45, Stefano Babic a écrit : Hi Albert, please pull from u-boot-imx (a couple of fixes): The following changes since commit a7b39185338c333a052728a7952b5f1cba4fc22a: tools/setlocalversion: Update from the Linux Kernel (2011-12-17 20:58:48 +0100) are available in the git repository at: git://www.denx.de/git/u-boot-imx.git master Anatolij Gustschin (1): Fix building for mx51evk board Marek Vasut (1): M28: Fix tab indent in u-boot.bd board/denx/m28evk/u-boot.bd |8 board/freescale/mx51evk/mx51evk.c |3 ++- board/freescale/mx53loco/mx53loco.c |3 ++- 3 files changed, 8 insertions(+), 6 deletions(-) Applied tu u-boot-arm/master, thanks. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] Exynos: Fix ARM Clock frequency calculation
On 19 December 2011 13:56, Minkyu Kang wrote: > On 19 December 2011 16:57, Wolfgang Denk wrote: > > Dear Chander Kashyap, > > > > In message <1324275424-29468-3-git-send-email-chander.kash...@linaro.org> > you wrote: > >> Earliar ARM clock frequency was calculated by: > >> MOUTAPLL/(DIVAPLL + 1) which is actually returning SCLKAPLL. > >> It is fixed by calcuating it as follows: > > > > Um Comment and code disagree: > > > >> ARMCLK=MOUTCORE/(DIVCORE + 1)/DIVCORE2 + 1) > > > > ...or is this just missing a paren? > > > >> + dout_apll = get_pll_clk(APLL) / (core_ratio + 1); > >> + dout_apll /= (core2_ratio + 1); > > > > This gives > > > > ARMCLK=MOUTCORE/(DIVCORE + 1)/ (DIVCORE2 + 1) > > > > Please check if this is correct. > > Wolfgang, you are right. > ARMCLK=MOUTCORE / (DIVCORE + 1) / (DIVCORE2 + 1) is right. > I will fix the comment. > > > Dear Chander Kashyap, > > >/* APLL_RATIO: [26:24] */ > > Please fix this comment also. > Yes > > > - apll_ratio = (div >> 24) & 0x7; > > + core_ratio = (div >> 0) & 0x7; > > + core2_ratio = (div >> 28) & 0x7; > > > > - dout_apll = get_pll_clk(APLL) / (apll_ratio + 1); > > + dout_apll = get_pll_clk(APLL) / (core_ratio + 1); > > This output is not dout_apll. > Please fix it. > I will rename the output. > > > + dout_apll /= (core2_ratio + 1); > > > >return dout_apll; > > Thanks > Minkyu Kang > -- > from. prom. > www.promsoft.net > -- with warm regards, Chander Kashyap ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] U-Boot on Nokia RX-51 (aka N900)
Hi Pali, On 19/12/11 18:17, Pali Rohár wrote: > On Monday 19 December 2011 00:57:27 Wolfgang Denk wrote: >> Dear Pali =?ISO-8859-1?Q?Roh=E1r?=, >> >> In message <1778406.ezGto4lKnu@pali-elitebook> you wrote: >>> I'm sending third version of rx51 patches for u-boot. All patches was >>> checked by checkpatch.pl and no error or warning was appeared. Last 2 >>> patches (0014 and 0015) adding ANSI terminal bootmenu support for rx51 >>> and can be reviewed separatly (patches 0001-0013 adding nokia rx51 >>> board support and working without that last two). >> >> It seems you did not bother to read >> http://www.denx.de/wiki/view/U-Boot/Patches#Sending_updated_patch_versions >> >> I do not have the time to try to find out what you might have changed >> compared top your previous submission, and others are in the same >> situation. >> >> Why did you not provide any change logs? >> >> >> >> Best regards, >> >> Wolfgang Denk > > Here is changelog v2:v3 > > * fixed all problems detected by checkpatch.pl > * wrapped long commit messages > * in arch/arm/lib/bootm.c added local define CONFIG_SETUP_ANY_TAG > * Patch "cfb_console.c: Add function console_swap_colors" squashed into > "cfb_console.c: Add support for ANSI terminal" > * renamed command clr to clear; use puts instead printf; move cursor to pos1,1 > * removed check #ifdef CONFIG_PREMONITOR in main.c > * rx51 board code: removed Makefile targets: clean and distclean > * ansi bootmenu command: use puts instead printf So which patches have changed? What changes apply to which patch? Before posting any more updates, please read: http://www.denx.de/wiki/view/U-Boot/Patches _completely_ In particular: - Set the in-reply-to email header of the new version of _each_ _individual_ patch the the message-id: of the previous version of that _individual_ patch - Add v1/v2/v3 to the subject line of the updated version of _each_ _individual_ patch (i.e. [PATCH v2 06/15] ..) - You do not need to post an new version of any patches which have no changes (you can if you want to keep the version numbers the same across the whole series, but make sure you put 'no changes' in the changelog) - Include the changelog for all previous version of _each_ _individual_ patch on the new version of _each_ _individual_ patch - DO NOT put the changelog in patch 0 - Use git format-patch and git send-email - git format-patch creates a ready-to-send email - All you need to do is add the 'in-reply-to' email header and chagelog and then do a git-send-email We are fairly tolerant of honest mistakes (thankfully, because I've made my fair share) but we tend to draw the line at mistakes that could have been avoided with a little prior reading (particularly if said reading was explicitly pointed out) I suggest you create a 'v4' patchset after reading up on exactly how to submit revised patches Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] SPL Linux Boot
On 16/12/2011 16:45, Tom Rini wrote: > On Fri, Dec 16, 2011 at 8:37 AM, Stefano Babic wrote: >> Hi, >> Hi Tom, > I'm going to mark this series as RFC in patchwork as I see you did > +#ifneq... in some Makefiles and I know you know better :) That said, > can you confirm MAKEALL -s omap3 -s omap4 -s omap5 works? there is a missing include in this patchset (fixed in next version), but I can compile all. > omap4/5 has > smaller size requirements than omap3(ish) stuff and I don't have 100% > faith in linker magic to make sure the cache stuff added to SPL in > arch/arm/lib/ isn't going to bloat up the omap4/5 stuff slightly. Checking MLO without and with this patchset for an OMAP4 board (panda), I get: without patchset (u-boot-ti): 33012 bytes with the patchset (SPL_OS not enabled): 33424 I cannot test it, but is seems still in order, right ? Stefano -- = DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-ti/master (updated!)
Hi Tom, Le 16/12/2011 23:20, Tom Rini a écrit : On Wed, Dec 14, 2011 at 9:06 AM, Tom Rini wrote: On Tue, Dec 13, 2011 at 11:58 AM, Tom Rini wrote: The following changes since commit 953209bf5ef0889a1baa02aa0ed5324f53ff8fda: Wolfgang Grandegger (1): arm: add __aeabi_unwind_cpp_pr1() function to avoid linker complaints are available in the git repository at: git://git.denx.de/u-boot-ti.git master Ilya Yanok (1): arm926ejs: remove noop flush_dcache_all function arch/arm/cpu/arm926ejs/cache.c |5 - 1 files changed, 0 insertions(+), 5 deletions(-) This is a bugfix to the cache changes that were pushed before and without them some boards get stuck in an infinite loop. This is now: The following changes since commit 953209bf5ef0889a1baa02aa0ed5324f53ff8fda: Wolfgang Grandegger (1): arm: add __aeabi_unwind_cpp_pr1() function to avoid linker complaints are available in the git repository at: git://git.denx.de/u-boot-ti.git master Ilya Yanok (1): arm926ejs: remove noop flush_dcache_all function Manfred Rudigier (1): davinci: Fixed wrong timebase clock frequency. arch/arm/cpu/arm926ejs/cache.c |5 - arch/arm/cpu/arm926ejs/davinci/timer.c |2 +- 2 files changed, 1 insertions(+), 6 deletions(-) The change from Manfred corrects get_tbclk() to return the right value (CONFIG_SYS_HZ_TIMER, basically) rather than CONFIG_SYS_HZ which is not at all the same. And now: The following changes since commit 953209bf5ef0889a1baa02aa0ed5324f53ff8fda: Wolfgang Grandegger (1): arm: add __aeabi_unwind_cpp_pr1() function to avoid linker complaints are available in the git repository at: git://git.denx.de/u-boot-ti.git master Chris Lalancette (1): omap4_panda: Initialize the USB phy Ilya Yanok (1): arm926ejs: remove noop flush_dcache_all function Manfred Rudigier (1): davinci: Fixed wrong timebase clock frequency. arch/arm/cpu/arm926ejs/cache.c |5 -- arch/arm/cpu/arm926ejs/davinci/timer.c |2 +- arch/arm/include/asm/arch-omap4/clocks.h | 63 ++ board/ti/panda/panda.c | 59 4 files changed, 123 insertions(+), 6 deletions(-) This adds Chris' patch for the USB clocks on Pandaboard. While USB continues to not be supported in U-Boot, without this patch we have a regression in Linux wherein USB stops working. Applied to u-boot-arm/master, thanks. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2] ARM: fix s3c24x0 timer code
Hi Andreas,
Le 08/12/2011 13:58, Andreas Bießmann a écrit :
Dear David Müller,
Am 08.12.2011 13:23, schrieb David Müller:
This patch fixes the s3c24x0 timer code to work with the ARM
relocation feature.
Signed-off-by: David Mueller
---
arch/arm/cpu/arm920t/s3c24x0/timer.c | 40 +++--
arch/arm/include/asm/global_data.h |7 ++
2 files changed, 25 insertions(+), 22 deletions(-)
Changes for V2:
- rebase to master
diff --git a/arch/arm/include/asm/global_data.h
b/arch/arm/include/asm/global_data.h
index c3ff789..02420d8 100644
--- a/arch/arm/include/asm/global_data.h
+++ b/arch/arm/include/asm/global_data.h
@@ -67,6 +67,13 @@ typedef struct global_data {
#ifdef CONFIG_IXP425
unsigned long timestamp;
#endif
+#ifdef CONFIG_S3C24X0
+ /* "static data" needed by s3c24x0 timer.c */
+ unsigned long timer_load_val;
+ unsigned long timer_clk;
+ unsigned long timestamp;
+ unsigned long lastdec;
+#endif
I tend to NAK this. There are currently values defined ('#ifdef
CONFIG_ARM') which should work out for s3c24x0 timer too.
E.g. your 'lastdec' corresponds to the 'lastinc' there, timestamp could
be timer_reset_value (but maybe we should include the 'timestamp'
defined by CONFIG_IXP425 into the CONFIG_ARM?), timer_clk could be
timer_rate_hz ...
I guess the arm920t/at91 timer is not that much different to yours (by
means of logic), maybe have a look for that driver?
Albert, how do you think about this?
Sorry for being late.
Yes, I would tend to favor as common a timer code as possible.
best regards
Andreas Bießmann
Amicalement,
--
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V2 0/2] Exynos Related fixes
Chander Kashyap (2): Exynos: PWM: Add TCMPB3 field in pwm structure Exynos: Fix ARM Clock frequency calculation arch/arm/cpu/armv7/exynos/clock.c | 15 +-- arch/arm/include/asm/arch-exynos/pwm.h |2 +- 2 files changed, 10 insertions(+), 7 deletions(-) -- 1.7.5.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V2 1/2] Exynos: PWM: Add TCMPB3 field in pwm structure
Add TCMPB3 field in pwm structure, earliar this was res1.
Signed-off-by: Chander Kashyap
---
arch/arm/include/asm/arch-exynos/pwm.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/include/asm/arch-exynos/pwm.h
b/arch/arm/include/asm/arch-exynos/pwm.h
index d0cf3cb..3e95160 100644
--- a/arch/arm/include/asm/arch-exynos/pwm.h
+++ b/arch/arm/include/asm/arch-exynos/pwm.h
@@ -57,7 +57,7 @@ struct s5p_timer {
unsigned inttcmpb2;
unsigned inttcnto2;
unsigned inttcntb3;
- unsigned intres1;
+ unsigned inttcmpb3;
unsigned inttcnto3;
unsigned inttcntb4;
unsigned inttcnto4;
--
1.7.5.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V2 2/2] Exynos: Fix ARM Clock frequency calculation
Earliar ARM clock frequency was calculated by: MOUTAPLL/(DIVAPLL + 1) which is actually returning SCLKAPLL. It is fixed by calculating it as follows: ARMCLK=MOUTCORE / (DIVCORE + 1) / (DIVCORE2 + 1) Signed-off-by: Chander Kashyap --- Changes for V2: - Fixed commit comment - Fixed comment in clock.c "exynos4_get_arm_clk ()" - Renamed dout_apll to armclk in clock.c "exynos4_get_arm_clk ()" arch/arm/cpu/armv7/exynos/clock.c | 15 +-- 1 files changed, 9 insertions(+), 6 deletions(-) diff --git a/arch/arm/cpu/armv7/exynos/clock.c b/arch/arm/cpu/armv7/exynos/clock.c index 64de262..0c199cd 100644 --- a/arch/arm/cpu/armv7/exynos/clock.c +++ b/arch/arm/cpu/armv7/exynos/clock.c @@ -102,17 +102,20 @@ static unsigned long exynos4_get_arm_clk(void) struct exynos4_clock *clk = (struct exynos4_clock *)samsung_get_base_clock(); unsigned long div; - unsigned long dout_apll; - unsigned int apll_ratio; + unsigned long armclk; + unsigned int core_ratio; + unsigned int core2_ratio; div = readl(&clk->div_cpu0); - /* APLL_RATIO: [26:24] */ - apll_ratio = (div >> 24) & 0x7; + /* CORE_RATIO: [2:0], CORE2_RATIO: [30:28] */ + core_ratio = (div >> 0) & 0x7; + core2_ratio = (div >> 28) & 0x7; - dout_apll = get_pll_clk(APLL) / (apll_ratio + 1); + armclk = get_pll_clk(APLL) / (core_ratio + 1); + armclk /= (core2_ratio + 1); - return dout_apll; + return armclk; } /* exynos4: return pwm clock frequency */ -- 1.7.5.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] km/common: add toolchain variable
Dear Holger Brunck, In message <4eeef0d3.5040...@keymile.com> you wrote: > > >> +Last change: 24.11.2011 > > > > Does this really make any sense? Which date are you recording here/ > > When you (think) you last edited the file? When you applied the patch > > to your local tree? When you submitted it for mainline? When it > > actually got applied? > > What I want to record is to track the version of the scripts and this makes > sense for me. In the end the scripts are copied into /tftpboot on each > developers machine and is therefore not under git control. It is an easy > indication wether the scripts are uptodate or not, without starting a diff > tool > and compare them with the latest git tree. Inside the git tree the information > is useless, I agree. You can insert such information when you export the files from git, say by adding a line like: Last commit date: $Format:%H %cD$ That would IMO make much more sense. See what we do with "snapshot.commit" in U-Boot [see also the entry in .git/info/attributes]. > > I recommend to get rid of this, and rather use git revision > > information instead. > > > > I would like to keep this, because git does not easily help here. Maybe it does - see above. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Committee, n.: A group of men who individually can do nothing but as a group decide that nothing can be done. - Fred Allen ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] Exynos: Fix ARM Clock frequency calculation
Dear Chander Kashyap, In message you wrote: > > > In message <1324275424-29468-3-git-send-email-chander.kash...@linaro.org> > > you wrote: > > > Earliar ARM clock frequency was calculated by: > > > MOUTAPLL/(DIVAPLL + 1) which is actually returning SCLKAPLL. > > > It is fixed by calcuating it as follows: > > > > Um Comment and code disagree: > > > > > ARMCLK=MOUTCORE/(DIVCORE + 1)/DIVCORE2 + 1) > > > > ...or is this just missing a paren? > > > > > + dout_apll = get_pll_clk(APLL) / (core_ratio + 1); > > > + dout_apll /= (core2_ratio + 1); > > > > This gives > > > > ARMCLK=MOUTCORE/(DIVCORE + 1)/ (DIVCORE2 + 1) > > > > Please check if this is correct. > > > > Below is the scenario of selection. > > MOUTAPLL --->| MUX_CORE |>MOUTCORE > MOUTMPLL --->|| > > Here MOUTAPLL is selected as input. So Parent is correct. You miss the point. Your comment: ARMCLK=MOUTCORE/(DIVCORE + 1)/DIVCORE2 + 1) is missing one opening brace. Depending on where you insert it, the code may or may not match. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de "A little knowledge is a dangerous thing."- Doug Gwyn ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] add print_cpuinfo to s3c24x0
Hi David,
Le 03/12/2010 16:12, David Müller a écrit :
Hello
This patch adds support for "print_cpuinfo" on Samsung s3c24x0
based targets. If activated by "#define CONFIG_DISPLAY_CPUINFO", the
chip ID and the 3 main cpu frequencies will be displayed.
Dave
Signed-off-by: David Müller
diff --git a/arch/arm/cpu/arm920t/s3c24x0/Makefile
b/arch/arm/cpu/arm920t/s3c24x0/Makefile
index bd53724..0029700 100644
--- a/arch/arm/cpu/arm920t/s3c24x0/Makefile
+++ b/arch/arm/cpu/arm920t/s3c24x0/Makefile
@@ -26,6 +26,7 @@ include $(TOPDIR)/config.mk
LIB = $(obj)lib$(SOC).o
COBJS-$(CONFIG_USE_IRQ) += interrupts.o
+COBJS-$(CONFIG_DISPLAY_CPUINFO)+= cpu_info.o
COBJS-y += speed.o
COBJS-y += timer.o
COBJS-y += usb.o
diff --git a/arch/arm/cpu/arm920t/s3c24x0/cpu_info.c
b/arch/arm/cpu/arm920t/s3c24x0/cpu_info.c
new file mode 100644
index 000..14c5c6a
--- /dev/null
+++ b/arch/arm/cpu/arm920t/s3c24x0/cpu_info.c
@@ -0,0 +1,54 @@
+/*
+ * (C) Copyright 2010
+ * David Mueller
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#include
+#include
+#include
+
+typedef ulong (*getfreq)(void);
+
+static const getfreq freq_f[] = {
+ get_FCLK,
+ get_HCLK,
+ get_PCLK,
+};
+
+static const char freq_c[] = { 'F', 'H', 'P' };
+
+int print_cpuinfo(void)
+{
+ int i;
+ char buf[32];
+/* the S3C2400 seems to be lacking a CHIP ID register */
+#ifndef CONFIG_S3C2400
+ ulong cpuid;
+ struct s3c24x0_gpio * const gpio = s3c24x0_get_base_gpio();
+
+ cpuid = readl(&gpio->gstatus1);
+ printf("CPUID: %8lX\n", cpuid);
+#endif
+ for (i = 0; i< ARRAY_SIZE(freq_f); i++)
+ printf("%cCLK: %8s MHz\n", freq_c[i], strmhz(buf, freq_f[i]()));
+
+ return 0;
+}
For some reason and despite David's pings, I'd missed this roughly
one-year-old patch. Applied to u-boot-arm/master, with apologies for the
delay. :(
Note:
include/configs/VCMA9.h:/* to be activated as soon as s3c24x0 has
print_cpuinfo
include/configs/smdk2410.h:/* may be activated as soon as s3c24x0 has
print_cpuinfo
Amicalement,
--
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] Exynos: Fix ARM Clock frequency calculation
Dear Wolfgang Denk, On 19 December 2011 14:29, Wolfgang Denk wrote: > Dear Chander Kashyap, > > In message < > canuqghhq_+az6z100agouaumeuyxwh-hl6anpgrtowbadeq...@mail.gmail.com> you > wrote: > > > > > In message < > 1324275424-29468-3-git-send-email-chander.kash...@linaro.org> > > > you wrote: > > > > Earliar ARM clock frequency was calculated by: > > > > MOUTAPLL/(DIVAPLL + 1) which is actually returning SCLKAPLL. > > > > It is fixed by calcuating it as follows: > > > > > > Um Comment and code disagree: > > > > > > > ARMCLK=MOUTCORE/(DIVCORE + 1)/DIVCORE2 + 1) > > > > > > ...or is this just missing a paren? > > > > > > > + dout_apll = get_pll_clk(APLL) / (core_ratio + 1); > > > > + dout_apll /= (core2_ratio + 1); > > > > > > This gives > > > > > > ARMCLK=MOUTCORE/(DIVCORE + 1)/ (DIVCORE2 + 1) > > > > > > Please check if this is correct. > > > > > > > Below is the scenario of selection. > > > > MOUTAPLL --->| MUX_CORE |>MOUTCORE > > MOUTMPLL --->|| > > > > Here MOUTAPLL is selected as input. So Parent is correct. > > You miss the point. > > Your comment: > >ARMCLK=MOUTCORE/(DIVCORE + 1)/DIVCORE2 + 1) > > is missing one opening brace. Depending on where you insert it, the > code may or may not match. > Thanks, I got it. Resend it again. > > Best regards, > > Wolfgang Denk > > -- > DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel > HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany > Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de > "A little knowledge is a dangerous thing."- Doug Gwyn > -- with warm regards, Chander Kashyap ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 1/2] Exynos: PWM: Add TCMPB3 field in pwm structure
Dear Chander Kashyap, In message <1324285004-32354-2-git-send-email-chander.kash...@linaro.org> you wrote: > Add TCMPB3 field in pwm structure, earliar this was res1. > > Signed-off-by: Chander Kashyap > --- > arch/arm/include/asm/arch-exynos/pwm.h |2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/arch/arm/include/asm/arch-exynos/pwm.h > b/arch/arm/include/asm/arch-exynos/pwm.h > index d0cf3cb..3e95160 100644 You submit a V2 patch, but without any indication what was changed ??? Where is the _mandatory_ change log? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Always try to do things in chronological order; it's less confusing that way. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] OMAP3: Remove unused define CONFIG_OMAP3_*_DDR
Thomas Weber wrote: This patch removes the unused definitions: CONFIG_OMAP3_MICRON_DDR CONFIG_OMAP3_NUMONYX_DDR CONFIG_OMAP3_INFINEON_DDR Signed-off-by: Thomas Weber Acked-by: Luca Ceresoli Luca ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 1/2] Exynos: PWM: Add TCMPB3 field in pwm structure
Hi Wolfgsng Denk, On 19 December 2011 14:33, Wolfgang Denk wrote: > Dear Chander Kashyap, > > In message <1324285004-32354-2-git-send-email-chander.kash...@linaro.org> > you wrote: > > Add TCMPB3 field in pwm structure, earliar this was res1. > > > > Signed-off-by: Chander Kashyap > > --- > > arch/arm/include/asm/arch-exynos/pwm.h |2 +- > > 1 files changed, 1 insertions(+), 1 deletions(-) > > > > diff --git a/arch/arm/include/asm/arch-exynos/pwm.h > b/arch/arm/include/asm/arch-exynos/pwm.h > > index d0cf3cb..3e95160 100644 > > You submit a V2 patch, but without any indication what was changed ??? > Changes are in Patch2/2. I have mentioned them in Patch2/2. > > Where is the _mandatory_ change log? > > Best regards, > > Wolfgang Denk > > -- > DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel > HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany > Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de > Always try to do things in chronological order; it's less confusing > that way. > -- with warm regards, Chander Kashyap ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] common/cmd_nvedit.c: Fix size calculation in do_env_import()
Dear KRONSTORFER Horst, In message <024fe3275ef7814d9b07390f28c0832c63a20...@vie196nt.frequentis.frq> you wrote: > > > Can you please describe a test case that shows this bug? > > host: > echo foo=bar > env.txt > mkenvimage -b -s 13 -o env.bin env.txt > > be target: > tftp 20 env.bin > env import -c $fileaddr > ## Info: input data size = 12 = 0xC > ## Error: bad CRC, import failed Thanks. [Note: it would have been even more helpful if you had also provided a hex dump of "env.bin" - as is, it's difficult for me to see if there is a bug with cmd_nvedit or with your version of the mkenvimage tool.] Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Q: Why do PCs have a reset button on the front? A: Because they are expected to run Microsoft operating systems. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] common/cmd_nvedit.c: Fix size calculation in do_env_import()
Dear Horst Kronstorfer, In message <1324114390-27290-1-git-send-email-hkron...@frequentis.com> you wrote: > do_env_import() missed the final '\0' terminator when calculating the > size of an environment data block. This led to an erroneous 'bad CRC, > import failed' message for a checksum protected environment (-c.) > > Signed-off-by: Horst Kronstorfer > --- > common/cmd_nvedit.c |2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) Applied, thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de You don't have to stay up nights to succeed; you have to stay awake days. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [STATUS] "next" branch started
Hi all, On Sun, 18 Dec 2011 00:19:34 +0100 Wolfgang Denk wrote: ... > as you may have seen from some of my confirmation messages, I have > started a "next" branch. > > Please feel free to send pull-requests for next, or to point me to > patches that should go into next (or even into the upcoming release). These two patches http://patchwork.ozlabs.org/patch/126542/ http://patchwork.ozlabs.org/patch/126546/ fix broken building for 6 boards/configurations: sbc35_a9g20_eeprom sbc35_a9g20_nandflash tny_a9260_eeprom tny_a9260_nandflash tny_a9g20_eeprom tny_a9g20_nandflash Albert, can you queue these patches for v2011.12 release? Thanks, Anatolij ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] common/cmd_pxe.c: Fix GCC 4.6 build warnings
Hi Heiko, On Tue, 13 Dec 2011 07:37:17 +0100 Heiko Schocher wrote: > Fix: > cmd_pxe.c: In function 'parse_pxefile_top': > cmd_pxe.c:941:5: warning: 'err' may be used uninitialized in this > function [-Wuninitialized] > cmd_pxe.c:921:6: note: 'err' was declared here > > Signed-off-by: Heiko Schocher > Cc: Jason Hobbs > --- > common/cmd_pxe.c |2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) Applied to u-boot-staging/ag...@denx.de. Thanks! Anatolij ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 0/2] Add i2c TPM driver
This patchset adds an i2c bus based TPM driver.
Changes in v1:
- Update s-o-b Peter Huewe's email address
- Squash patch #3 into patch #2
Changes in v2:
- Style improvements
Che-Liang Chiou (2):
tpm: Rename generic_lpc_tpm to tpm_tis_lpc
tpm: Add i2c TPM driver
Makefile |2 +-
README | 18 +-
drivers/tpm/Makefile |5 +-
drivers/tpm/tpm.c| 466 +
drivers/tpm/tpm_private.h| 134 +
drivers/tpm/tpm_tis_i2c.c| 587 ++
drivers/tpm/{generic_lpc_tpm.c => tpm_tis_lpc.c} |0
7 files changed, 1209 insertions(+), 3 deletions(-)
create mode 100644 drivers/tpm/tpm.c
create mode 100644 drivers/tpm/tpm_private.h
create mode 100644 drivers/tpm/tpm_tis_i2c.c
rename drivers/tpm/{generic_lpc_tpm.c => tpm_tis_lpc.c} (100%)
--
1.7.3.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 1/2] tpm: Rename generic_lpc_tpm to tpm_tis_lpc
The new name is more aligned with Linux kernel's naming of TPM driver.
Signed-off-by: Peter Huewe
Signed-off-by: Che-Liang Chiou
Acked-by: Mike Frysinger
---
Changes in v1:
- Update s-o-b Peter Huewe's email address
Makefile |2 +-
README |5 -
drivers/tpm/Makefile |2 +-
drivers/tpm/{generic_lpc_tpm.c => tpm_tis_lpc.c} |0
4 files changed, 6 insertions(+), 3 deletions(-)
rename drivers/tpm/{generic_lpc_tpm.c => tpm_tis_lpc.c} (100%)
diff --git a/Makefile b/Makefile
index de65a17..abeafd7 100644
--- a/Makefile
+++ b/Makefile
@@ -277,7 +277,7 @@ LIBS += arch/powerpc/cpu/mpc8xxx/lib8xxx.o
endif
LIBS += drivers/rtc/librtc.o
LIBS += drivers/serial/libserial.o
-ifeq ($(CONFIG_GENERIC_LPC_TPM),y)
+ifeq ($(CONFIG_TPM),y)
LIBS += drivers/tpm/libtpm.o
endif
LIBS += drivers/twserial/libtws.o
diff --git a/README b/README
index e9d1891..434384c 100644
--- a/README
+++ b/README
@@ -1073,7 +1073,10 @@ The following options need to be configured:
If this option is set, the driver enables cache flush.
- TPM Support:
- CONFIG_GENERIC_LPC_TPM
+ CONFIG_TPM
+ Support TPM devices.
+
+ CONFIG_TPM_TIS_LPC
Support for generic parallel port TPM devices. Only one device
per system is supported at this time.
diff --git a/drivers/tpm/Makefile b/drivers/tpm/Makefile
index be11c8b..47d09de 100644
--- a/drivers/tpm/Makefile
+++ b/drivers/tpm/Makefile
@@ -23,7 +23,7 @@ include $(TOPDIR)/config.mk
LIB := $(obj)libtpm.o
-COBJS-$(CONFIG_GENERIC_LPC_TPM) = generic_lpc_tpm.o
+COBJS-$(CONFIG_TPM_TIS_LPC) = tpm_tis_lpc.o
COBJS := $(COBJS-y)
SRCS := $(COBJS:.o=.c)
diff --git a/drivers/tpm/generic_lpc_tpm.c b/drivers/tpm/tpm_tis_lpc.c
similarity index 100%
rename from drivers/tpm/generic_lpc_tpm.c
rename to drivers/tpm/tpm_tis_lpc.c
--
1.7.3.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 2/2] tpm: Add i2c TPM driver
Peter Huewe implemented the original driver; this patch only reorganizes
the code structure of the driver, and does not make logical changes.
tpm.c implements the interface defined in tpm.h based on underlying
LPC or i2C TPM driver. tpm.c and the underlying driver communicate
throught tpm_private.h.
This patch is tested on a tegra2-based machine, where the i2c driver is
not upstreamed yet.
Note: Merging the LPC driver with tpm.c is left to future patches.
Signed-off-by: Peter Huewe
Signed-off-by: Che-Liang Chiou
---
Changes in v1:
- Squash patch #3 into patch #2
Changes in v2:
- Style improvements
README| 13 +
drivers/tpm/Makefile |5 +-
drivers/tpm/tpm.c | 466 +++
drivers/tpm/tpm_private.h | 134 ++
drivers/tpm/tpm_tis_i2c.c | 587 +
5 files changed, 1204 insertions(+), 1 deletions(-)
create mode 100644 drivers/tpm/tpm.c
create mode 100644 drivers/tpm/tpm_private.h
create mode 100644 drivers/tpm/tpm_tis_i2c.c
diff --git a/README b/README
index 434384c..badb834 100644
--- a/README
+++ b/README
@@ -1076,6 +1076,19 @@ The following options need to be configured:
CONFIG_TPM
Support TPM devices.
+ CONFIG_TPM_TIS_I2C
+ Support for i2c bus TPM devices. Only one device
+ per system is supported at this time.
+
+ CONFIG_TPM_TIS_I2C_BUS_NUMBER
+ Define the the i2c bus number for the TPM device
+
+ CONFIG_TPM_TIS_I2C_SLAVE_ADDRESS
+ Define the TPM's address on the i2c bus
+
+ CONFIG_TPM_TIS_I2C_BURST_LIMITATION
+ Define the burst count bytes upper limit
+
CONFIG_TPM_TIS_LPC
Support for generic parallel port TPM devices. Only one device
per system is supported at this time.
diff --git a/drivers/tpm/Makefile b/drivers/tpm/Makefile
index 47d09de..cb29bab 100644
--- a/drivers/tpm/Makefile
+++ b/drivers/tpm/Makefile
@@ -23,7 +23,10 @@ include $(TOPDIR)/config.mk
LIB := $(obj)libtpm.o
-COBJS-$(CONFIG_TPM_TIS_LPC) = tpm_tis_lpc.o
+# TODO(clchiou): Merge tpm_tis_lpc.c with tpm.c
+COBJS-$(CONFIG_TPM_TIS_I2C) += tpm.o
+COBJS-$(CONFIG_TPM_TIS_I2C) += tpm_tis_i2c.o
+COBJS-$(CONFIG_TPM_TIS_LPC) += tpm_tis_lpc.o
COBJS := $(COBJS-y)
SRCS := $(COBJS:.o=.c)
diff --git a/drivers/tpm/tpm.c b/drivers/tpm/tpm.c
new file mode 100644
index 000..785ed01
--- /dev/null
+++ b/drivers/tpm/tpm.c
@@ -0,0 +1,466 @@
+/*
+ * Copyright (C) 2011 Infineon Technologies
+ *
+ * Authors:
+ * Peter Huewe
+ *
+ * Description:
+ * Device driver for TCG/TCPA TPM (trusted platform module).
+ * Specifications at www.trustedcomputinggroup.org
+ *
+ * It is based on the Linux kernel driver tpm.c from Leendert van
+ * Dorn, Dave Safford, Reiner Sailer, and Kyleen Hall.
+ *
+ * Version: 2.1.1
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation, version 2 of the
+ * License.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "tpm_private.h"
+
+/* Global structure for tpm chip data */
+static struct tpm_chip tpm_chip;
+
+enum tpm_duration {
+ TPM_SHORT = 0,
+ TPM_MEDIUM = 1,
+ TPM_LONG = 2,
+ TPM_UNDEFINED,
+};
+
+/* Extended error numbers from linux (see errno.h) */
+#defineECANCELED 125 /* Operation Canceled */
+
+/* Timer frequency. Corresponds to msec timer resolution*/
+#define HZ 1000
+
+#define TPM_MAX_ORDINAL243
+#define TPM_MAX_PROTECTED_ORDINAL 12
+#define TPM_PROTECTED_ORDINAL_MASK 0xFF
+
+#define TPM_CMD_COUNT_BYTE 2
+#define TPM_CMD_ORDINAL_BYTE 6
+
+/*
+ * Array with one entry per ordinal defining the maximum amount
+ * of time the chip could take to return the result. The ordinal
+ * designation of short, medium or long is defined in a table in
+ * TCG Specification TPM Main Part 2 TPM Structures Section 17. The
+ * values of the SHORT, MEDIUM, and LONG durations are retrieved
+ * from the chip during initialization with a call to tpm_get_timeouts.
+ */
+static const u8 tpm_protected_ordinal_duration[TPM_MAX_PROTECTED_ORDINAL] = {
+ TPM_UNDEFI
Re: [U-Boot] [PATCH v1 2/2] tpm: Add i2c TPM driver
On Sat, Dec 17, 2011 at 1:21 AM, Mike Frysinger wrote:
> On Wednesday 14 December 2011 03:48:24 Che-Liang Chiou wrote:
>> --- /dev/null
>> +++ b/drivers/tpm/tpm.c
>>
>> +int tis_sendrecv(const uint8_t *sendbuf, size_t send_size, uint8_t
>> *recvbuf, + size_t *recv_len)
>> +{
>> + error("%s: invalid send_size %zx\n", __func__, send_size);
>
> using __func__ with error() makes no sense as error() already includes that
Done.
>> --- /dev/null
>> +++ b/drivers/tpm/tpm_private.h
>
> this should probably include linux/types.h and linux/compiler.h since it uses
> __be32 and __packed
Done.
>> --- /dev/null
>> +++ b/drivers/tpm/tpm_tis_i2c.c
>>
>> + if (burstcnt > (len-1-count))
>> + burstcnt = len-1-count;
>
> add some spaces around those "-"
Done.
> -mike
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v1 2/2] tpm: Add i2c TPM driver
On Sun, Dec 18, 2011 at 4:33 AM, Wolfgang Denk wrote:
> Dear Che-Liang Chiou,
>
> In message <1323852504-19954-3-git-send-email-clch...@chromium.org> you wrote:
>> Peter Huewe implemented the original driver; this patch only reorganizes
>> the code structure of the driver, and does not make logical changes.
>>
>> tpm.c implements the interface defined in tpm.h based on underlying
>> LPC or i2C TPM driver. tpm.c and the underlying driver communicate
>> throught tpm_private.h.
>>
>> This patch is tested on a tegra2-based machine, where the i2c driver is
>> not upstreamed yet.
>>
>> Note: Merging the LPC driver with tpm.c is left to future patches.
>>
>> Signed-off-by: Peter Huewe
>> Signed-off-by: Che-Liang Chiou
>
> ...
>> + if (ordinal < TPM_MAX_ORDINAL)
>> + duration_idx = tpm_ordinal_duration[ordinal];
>> + else if ((ordinal & TPM_PROTECTED_ORDINAL_MASK) <
>> + TPM_MAX_PROTECTED_ORDINAL)
>> + duration_idx = tpm_protected_ordinal_duration[ordinal &
>> + TPM_PROTECTED_ORDINAL_MASK];
>
> Braces needed around multiline statement.
Done.
>> + if (duration_idx != TPM_UNDEFINED)
>> + duration = chip->vendor.duration[duration_idx];
>> + if (duration <= 0)
>
> Readability could be improved by inserting a blank line before this
> one.
Done.
> ...
>> + debug("%s: waiting for status...\n", __func__);
>> + u8 status = tpm_chip.vendor.status(&tpm_chip);
>> + if ((status & tpm_chip.vendor.req_complete_mask) ==
>
> Please always seaprate declarations and code by one blank line.
> Please fix globally.
Done. I found as many cases as possible, and inserted a few more blank
lines. I hope that would increase readability.
>
> Best regards,
>
> Wolfgang Denk
>
> --
> DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
> Yes, it's a technical challenge, and you have to kind of admire
> people who go to the lengths of actually implementing it, but at the
> same time you wonder about their IQ...
> -- Linus Torvalds in <5phda5$ml6$1...@palladium.transmeta.com>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm, fdt: update ethernet mac address before booting Linux
Hi Heiko, Le 15/09/2011 07:16, Heiko Schocher a écrit : Signed-off-by: Heiko Schocher Cc: Albert ARIBAUD Cc: Gerald van Baren --- arch/arm/lib/bootm.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/arch/arm/lib/bootm.c b/arch/arm/lib/bootm.c index 802e833..afa0093 100644 --- a/arch/arm/lib/bootm.c +++ b/arch/arm/lib/bootm.c @@ -206,6 +206,8 @@ static int bootm_linux_fdt(int machid, bootm_headers_t *images) fixup_memory_node(*of_flat_tree); + fdt_fixup_ethernet(*of_flat_tree); + fdt_initrd(*of_flat_tree, *initrd_start, *initrd_end, 1); announce_and_cleanup(); Applied to u-boot-arm/master, thanks! Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: Tidy up of PRAM init to use getenv_f()
Hi Simon,
Le 10/10/2011 22:24, Simon Glass a écrit :
It seems that few people use CONFIG_PRAM on ARM. The getenv_r() function has
been renamed to getenv_f().
Please correct the commit message: it does not rename the function, it
switches from callong the _r version to calling the _f version.
Signed-off-by: Simon Glass
---
arch/arm/lib/board.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/lib/board.c b/arch/arm/lib/board.c
index 1fe3751..653345f 100644
--- a/arch/arm/lib/board.c
+++ b/arch/arm/lib/board.c
@@ -317,7 +317,7 @@ void board_init_f(ulong bootflag)
/*
* reserve protected RAM
*/
- i = getenv_r("pram", (char *)tmp, sizeof(tmp));
+ i = getenv_f("pram", (char *)tmp, sizeof(tmp));
reg = (i> 0) ? simple_strtoul((const char *)tmp, NULL, 10) :
CONFIG_PRAM;
addr -= (reg<< 10); /* size is in kB */
Amicalement,
--
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [STATUS] "next" branch started
Le 19/12/2011 10:23, Anatolij Gustschin a écrit : Hi all, On Sun, 18 Dec 2011 00:19:34 +0100 Wolfgang Denk wrote: ... as you may have seen from some of my confirmation messages, I have started a "next" branch. Please feel free to send pull-requests for next, or to point me to patches that should go into next (or even into the upcoming release). These two patches http://patchwork.ozlabs.org/patch/126542/ http://patchwork.ozlabs.org/patch/126546/ fix broken building for 6 boards/configurations: sbc35_a9g20_eeprom sbc35_a9g20_nandflash tny_a9260_eeprom tny_a9260_nandflash tny_a9g20_eeprom tny_a9g20_nandflash Albert, can you queue these patches for v2011.12 release? Thanks, Anatolij Hmm, so these are NOT for next, actually, right? Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [STATUS] "next" branch started
On Mon, 19 Dec 2011 11:27:51 +0100 Albert ARIBAUD wrote: ... > > These two patches > > http://patchwork.ozlabs.org/patch/126542/ > > http://patchwork.ozlabs.org/patch/126546/ > > > > fix broken building for 6 boards/configurations: > > > > sbc35_a9g20_eeprom > > sbc35_a9g20_nandflash > > tny_a9260_eeprom > > tny_a9260_nandflash > > tny_a9g20_eeprom > > tny_a9g20_nandflash > > > > Albert, can you queue these patches for v2011.12 release? > > > > Thanks, > > Anatolij > > Hmm, so these are NOT for next, actually, right? Right. Thanks, Anatolij ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] km/common: add toolchain variable
Hi Wolfgang, On 12/19/2011 09:57 AM, Wolfgang Denk wrote: > In message <4eeef0d3.5040...@keymile.com> you wrote: >> +Last change: 24.11.2011 >>> >>> Does this really make any sense? Which date are you recording here/ >>> When you (think) you last edited the file? When you applied the patch >>> to your local tree? When you submitted it for mainline? When it >>> actually got applied? >> >> What I want to record is to track the version of the scripts and this makes >> sense for me. In the end the scripts are copied into /tftpboot on each >> developers machine and is therefore not under git control. It is an easy >> indication wether the scripts are uptodate or not, without starting a diff >> tool >> and compare them with the latest git tree. Inside the git tree the >> information >> is useless, I agree. > > You can insert such information when you export the files from git, > say by adding a line like: > > Last commit date: $Format:%H %cD$ > > That would IMO make much more sense. > > See what we do with "snapshot.commit" in U-Boot [see also the entry > in .git/info/attributes]. > After reading the doc I don't know how it could be used in my usecase. Please correct me if I am wrong, but this does only work in combination with the "git archive" command. And I don't want to do an archive, I want to export/copy some files out of the git tree into /tftpboot. Best regards Holger ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 6/9] ARM: tny_a9260: re-add MACH_TYPE_TNY_A9G20 and MACH_TYPE_TNY_A9260
Hi Anatolij, Le 19/11/2011 12:59, Anatolij Gustschin a écrit : MACH_TYPE_TNY_A9G20 and MACH_TYPE_TNY_A9260 were removed from mach-types.h. Add them to the board config file. Signed-off-by: Anatolij Gustschin --- board/calao/tny_a9260/tny_a9260.c |5 - include/configs/tny_a9260.h |4 2 files changed, 4 insertions(+), 5 deletions(-) diff --git a/board/calao/tny_a9260/tny_a9260.c b/board/calao/tny_a9260/tny_a9260.c index ab51a33..a472b91 100644 --- a/board/calao/tny_a9260/tny_a9260.c +++ b/board/calao/tny_a9260/tny_a9260.c @@ -86,11 +86,6 @@ int board_init(void) /* Enable Ctrlc */ console_init_f(); -#if defined(CONFIG_TNY_A9260) - gd->bd->bi_arch_number = MACH_TYPE_TNY_A9260; -#elif defined(CONFIG_TNY_A9G20) - gd->bd->bi_arch_number = MACH_TYPE_TNY_A9G20; -#endif /* adress of boot parameters */ gd->bd->bi_boot_params = CONFIG_SYS_SDRAM_BASE + 0x100; diff --git a/include/configs/tny_a9260.h b/include/configs/tny_a9260.h index 986aeba..c632de6 100644 --- a/include/configs/tny_a9260.h +++ b/include/configs/tny_a9260.h @@ -45,8 +45,12 @@ /* Define actual evaluation board type from used processor type */ #ifdef CONFIG_AT91SAM9G20 # define CONFIG_TNY_A9G20 +# define MACH_TYPE_TNY_A9G20 2059 +# define CONFIG_MACH_TYPE MACH_TYPE_TNY_A9G20 #else # define CONFIG_TNY_A9260 +# define MACH_TYPE_TNY_A9260 2058 +# define CONFIG_MACH_TYPE MACH_TYPE_TNY_A9260 #endif /* ARM asynchronous clock */ Applied to u-boot-arm/master, thanks! Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 5/9] ARM: sbc35_a9g20: re-add MACH_TYPE_SBC35_A9G20
Hi Anatolij, Le 19/11/2011 12:59, Anatolij Gustschin a écrit : MACH_TYPE_SBC35_A9G20 was removed from mach-types.h. Add it to the board config file. Signed-off-by: Anatolij Gustschin --- board/calao/sbc35_a9g20/sbc35_a9g20.c |1 - include/configs/sbc35_a9g20.h |3 +++ 2 files changed, 3 insertions(+), 1 deletions(-) diff --git a/board/calao/sbc35_a9g20/sbc35_a9g20.c b/board/calao/sbc35_a9g20/sbc35_a9g20.c index 5f448d9..446afb2 100644 --- a/board/calao/sbc35_a9g20/sbc35_a9g20.c +++ b/board/calao/sbc35_a9g20/sbc35_a9g20.c @@ -152,7 +152,6 @@ int board_init(void) /* Enable Ctrlc */ console_init_f(); - gd->bd->bi_arch_number = MACH_TYPE_SBC35_A9G20; /* adress of boot parameters */ gd->bd->bi_boot_params = CONFIG_SYS_SDRAM_BASE + 0x100; diff --git a/include/configs/sbc35_a9g20.h b/include/configs/sbc35_a9g20.h index 1e355a8..cdf8659 100644 --- a/include/configs/sbc35_a9g20.h +++ b/include/configs/sbc35_a9g20.h @@ -36,6 +36,9 @@ #define CONFIG_ENV_IS_IN_EEPROM #endif +#define MACH_TYPE_SBC35_A9G20 1848 +#define CONFIG_MACH_TYPE MACH_TYPE_SBC35_A9G20 + /* ARM asynchronous clock */ #define CONFIG_SYS_AT91_SLOW_CLOCK32768 /* slow clock xtal */ #define CONFIG_SYS_AT91_MAIN_CLOCK1200/* 12.000 MHz crystal */ Applied to u-boot-arm/master, thanks! Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v1 1/2] tpm: Rename generic_lpc_tpm to tpm_tis_lpc
On Sun, Dec 18, 2011 at 4:35 AM, Wolfgang Denk wrote:
> Dear Che-Liang Chiou,
>
> In message <1323852504-19954-2-git-send-email-clch...@chromium.org> you wrote:
>> The new name is more aligned with Linux kernel's naming of TPM driver.
>>
>> Signed-off-by: Peter Huewe
>> Signed-off-by: Che-Liang Chiou
>> Acked-by: Mike Frysinger
>> ---
>> Changes in v1:
>> - Update s-o-b Peter Huewe's email address
>>
>> Makefile | 2 +-
>> README | 5 -
>> drivers/tpm/Makefile | 2 +-
>> drivers/tpm/{generic_lpc_tpm.c => tpm_tis_lpc.c} | 0
>> 4 files changed, 6 insertions(+), 3 deletions(-)
>> rename drivers/tpm/{generic_lpc_tpm.c => tpm_tis_lpc.c} (100%)
>
> Does such a change actually make sense?
>
> Should we not rather remove all this dead code again?
>
> Until today there are no users for this code in mainline, and no
> patches have been submitted that intend to use it.
Chrome/Chromium OS uses TPM for its secure boot. So I would say it is
quite a lot of usage on the critical path of booting.
The code that uses TPM did not send to the mainline because the
mainline did not have a TPM driver until very recently.
And, I am still figuring out how to submit the TPM user code. I guess
it would be better to organize it in a command-line toolkit so that it
can be interleaved in between other commands. What do you think?
> I think we should scrap this in the next release.
>
> Best regards,
>
> Wolfgang Denk
>
> --
> DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
> Drawing on my fine command of language, I said nothing.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] drivers/usb/gadget/pxa27x_udc.c: Coding Style cleanup
Commit bdbcdc89 "pxa: convert pxa27x_udc to use read and write
functions" added a number of C++ comments. Fix these.
Signed-off-by: Wolfgang Denk
---
drivers/usb/gadget/pxa27x_udc.c |5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/gadget/pxa27x_udc.c b/drivers/usb/gadget/pxa27x_udc.c
index 0d3a988..4c00081 100644
--- a/drivers/usb/gadget/pxa27x_udc.c
+++ b/drivers/usb/gadget/pxa27x_udc.c
@@ -195,12 +195,12 @@ static int udc_read_urb_ep0(void)
for (i = 0; i < w; i++) {
data32[ep0_urb->actual_length / 4 + i] = readl(UDCDN(0));
-// ep0_urb->actual_length += 4;
+ /* ep0_urb->actual_length += 4; */
}
for (i = 0; i < b; i++) {
data8[ep0_urb->actual_length + w * 4 + i] = readb(UDCDN(0));
-// ep0_urb->actual_length++;
+ /* ep0_urb->actual_length++; */
}
ep0_urb->actual_length += n;
@@ -599,7 +599,6 @@ void udc_setup_ep(struct usb_device_instance *device,
unsigned int id,
writel(tmp, UDCCN(ep_num));
- //usbdbg
usbdbg("UDCCR%c = %x", 'A' + ep_num-1, readl(UDCCN(ep_num)));
usbdbg("UDCCSR%c = %x", 'A' + ep_num-1, readl(UDCCSN(ep_num)));
}
--
1.7.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] Coding Style cleanup
Fix trailing white space, indentation by spaces instead of TABs,
excessive blank lines, trailing blank lines.
Signed-off-by: Wolfgang Denk
---
arch/arm/include/asm/arch-davinci/da8xx-fb.h |1 -
arch/sh/lib/ashrsi3.S|2 +-
doc/README.menu |2 +-
doc/README.p3060qds |3 +-
doc/README.pxe | 54 +-
doc/README.sh7757lcr |7 +--
drivers/net/sh_eth.h |1 -
drivers/usb/host/ehci-mx5.c |2 -
include/configs/P2020COME.h |8 +---
9 files changed, 34 insertions(+), 46 deletions(-)
diff --git a/arch/arm/include/asm/arch-davinci/da8xx-fb.h
b/arch/arm/include/asm/arch-davinci/da8xx-fb.h
index 6d2327c..a9181d8 100644
--- a/arch/arm/include/asm/arch-davinci/da8xx-fb.h
+++ b/arch/arm/include/asm/arch-davinci/da8xx-fb.h
@@ -123,4 +123,3 @@ struct lcd_sync_arg {
void da8xx_video_init(const struct da8xx_panel *panel, int bits_pixel);
#endif /* ifndef DA8XX_FB_H */
-
diff --git a/arch/sh/lib/ashrsi3.S b/arch/sh/lib/ashrsi3.S
index 6f3cf46..2d68b27 100644
--- a/arch/sh/lib/ashrsi3.S
+++ b/arch/sh/lib/ashrsi3.S
@@ -56,7 +56,7 @@ Boston, MA 02110-1301, USA. */
!
.global __ashrsi3
-
+
.align 2
__ashrsi3:
mov #31,r0
diff --git a/doc/README.menu b/doc/README.menu
index 1259c6a..0dad6a2 100644
--- a/doc/README.menu
+++ b/doc/README.menu
@@ -97,7 +97,7 @@ char *pick_a_tool(void)
printf("failed to add item!");
menu_destroy(m);
return NULL;
-}
+ }
}
if (menu_get_choice(m, (void **)&tool) != 1)
diff --git a/doc/README.p3060qds b/doc/README.p3060qds
index 2ed49ca..ec62798 100644
--- a/doc/README.p3060qds
+++ b/doc/README.p3060qds
@@ -43,7 +43,7 @@ I2C:
* I2C1_CH0: EEPROM AT24C64(0x50) RCW, AT24C02(0x51) DDR SPD,
AT24C02(0x53) DDR SPD, AT24C02(0x57) SystemID, RTC DS3232(0x68)
* I2C1_CH1: 1588 RiserCard(0x55), HSLB Testport, TempMon
- ADT7461(0x4C), SerDesMux DS64MB201(0x51/59/5C/5D)
+ADT7461(0x4C), SerDesMux DS64MB201(0x51/59/5C/5D)
* I2C1_CH2: VDD/GVDD/GIDD ZL6100 (0x21/0x22/0x23/0x24/0x40)
* I2C1_CH3: OCM CFG AT24C02(0x55), OCM IPL AT24C64(0x56)
* I2C1_CH4: PCIe SLOT1
@@ -108,4 +108,3 @@ Place a linux uImage in the TFTP disk area.
tftp 200 rootfs.ext2.gz.uboot
tftp 300 p3060rdb.dtb
bootm 100 200 300
-
diff --git a/doc/README.pxe b/doc/README.pxe
index 9026d9c..95cd9b9 100644
--- a/doc/README.pxe
+++ b/doc/README.pxe
@@ -115,50 +115,50 @@ Supported global commands
-
Unrecognized commands are ignored.
-default - the label named here is treated as the default and is
- the first label 'pxe boot' attempts to boot.
+default - the label named here is treated as the default
and is
+ the first label 'pxe boot' attempts to boot.
menu title - sets a title for the menu of labels being displayed.
menu include - use tftp to retrieve the pxe file at , which
- is then immediately parsed as if the start of its
- contents were the next line in the current file. nesting
- of include up to 16 files deep is supported.
+ is then immediately parsed as if the start of its
+ contents were the next line in the current file. nesting
+ of include up to 16 files deep is supported.
-prompt- if 1, always prompt the user to enter a label to boot
- from. if 0, only prompt the user if timeout expires.
+prompt - if 1, always prompt the user to enter a label to boot
+ from. if 0, only prompt the user if timeout expires.
timeout - wait for user input for /10 seconds before
- auto-booting a node.
+ auto-booting a node.
-label - begin a label definition. labels continue until
- a command not recognized as a label command is seen,
- or EOF is reached.
+label- begin a label definition. labels continue until
+ a command not recognized as a label command is seen,
+ or EOF is reached.
Supported label commands
labels end when a command not recognized as a label command is reached, or EOF.
-menu default- set this label as the default label to boot; this is
- the same behavior as the global default command but
- specified in a different way
+menu default - set this label as the default label to boot; this is
+ the same behavior as the global default command but
[U-Boot] [STATUS] v2011.12-rc2 is out - finish for release...
Hi everybody, I've just released v2011.12-rc2; please help testing. Please respond quickly if you find anything missing for the final release, I want to get this out on Friday at latest. Thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de "Obviously, a major malfunction has occurred." -- Steve Nesbitt, voice of Mission Control, January 28, 1986, as the shuttle Challenger exploded within view of the grandstands. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 0/2] Add i2c TPM driver
Dear Che-Liang Chiou, In message <1324288224-5075-1-git-send-email-clch...@chromium.org> you wrote: > > This patchset adds an i2c bus based TPM driver. Are there any users of this driver? I see we are adding TPM code, but so far this is all dead code as there are no users for it. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de History is only a confused heap of facts. -- Philip Earl of Chesterfield ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] km/common: add toolchain variable
Dear Holger Brunck, In message <4eef13d4.5020...@keymile.com> you wrote: > > > You can insert such information when you export the files from git, > > say by adding a line like: > > > > Last commit date: $Format:%H %cD$ ... > After reading the doc I don't know how it could be used in my usecase. Please > correct me if I am wrong, but this does only work in combination with the "git > archive" command. And I don't want to do an archive, I want to export/copy > some > files out of the git tree into /tftpboot. You could for example use the following command to copy this file into /tftpboot: $ cd board/keymile/scripts $ git archive --format=tar HEAD README | \ ( cd /tftpboot ; tar -xpvf - ) Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de In general, they do what you want, unless you want consistency. - Larry Wall in the perl man page ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] drivers/usb/gadget/pxa27x_udc.c: Coding Style cleanup
Dear Wolfgang Denk, In message <1324292417-23817-1-git-send-email...@denx.de> you wrote: > Commit bdbcdc89 "pxa: convert pxa27x_udc to use read and write > functions" added a number of C++ comments. Fix these. > > Signed-off-by: Wolfgang Denk > --- > drivers/usb/gadget/pxa27x_udc.c |5 ++--- > 1 files changed, 2 insertions(+), 3 deletions(-) Applied, thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Let's say the docs present a simplified view of reality...:-) - Larry Wall in <6...@jpl-devvax.jpl.nasa.gov> ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v1 1/2] tpm: Rename generic_lpc_tpm to tpm_tis_lpc
Dear Che-liang Chiou, In message you wrote: > > > Should we not rather remove all this dead code again? > > > > Until today there are no users for this code in mainline, and no > > patches have been submitted that intend to use it. > > Chrome/Chromium OS uses TPM for its secure boot. So I would say it is > quite a lot of usage on the critical path of booting. I do not see any such code in mainline. So for mainline, this is just dead code, i. e. it adds maintenance efforts without benefit for any mainline users. > The code that uses TPM did not send to the mainline because the > mainline did not have a TPM driver until very recently. Well, the patche shave been submitted long time ago, so I would have expected to see such code soon after. But so far, nothign happened. Now you are trying to add even more code, with still no users in sight. > And, I am still figuring out how to submit the TPM user code. I guess > it would be better to organize it in a command-line toolkit so that it > can be interleaved in between other commands. What do you think? I don't understand what you mean. Didn't you just write there was code ready to be submitted? So that code is not ready and not intended for mainline? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Never ascribe to malice that which can adequately be explained by stupidity. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [STATUS] v2011.12-rc2 is out - finish for release...
On 19/12/2011 12:23, Wolfgang Denk wrote: > Hi everybody, > > I've just released v2011.12-rc2; please help testing. > > Please respond quickly if you find anything missing for the final > release, I want to get this out on Friday at latest. mx51evk is broken - fix merged, Albert has already merged my pull request into u-boot-arm. The fix must flow into mainline. Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ehci: speed up initialization
On 12/10/2011 05:29 PM, Remy Bohmer wrote: > Hi, > > 2011/12/5 Vincent Palatin : >> According to EHCI specification v1.0, the controller should stabilize >> the power on a port at most 20 ms after the port power bit transition. >> So, we put this setting in the virtual descriptor corresponding field, >> (bPwrOn2PwrGood = 10 => 10 x 2ms = 20ms), this saves about 500ms at each >> controller initialization/enumeration. >> >> Signed-off-by: Vincent Palatin >> --- >> drivers/usb/host/ehci-hcd.c |2 +- >> 1 files changed, 1 insertions(+), 1 deletions(-) > > Applied to u-boot-usb. I just realized that this patch breaks "usb start" on my mx53loco board: MX53LOCO U-Boot > usb start (Re)start USB... USB: Register 10011 NbrPorts 1 USB EHCI 1.00 scanning bus for devices... 1 USB Device(s) found scanning bus for storage devices... 0 Storage Device(s) found scanning bus for ethernet devices... 0 Ethernet Device(s) found MX53LOCO U-Boot > usb start (Re)start USB... USB: Register 10011 NbrPorts 1 USB EHCI 1.00 scanning bus for devices... 2 USB Device(s) found scanning bus for storage devices... 0 Storage Device(s) found scanning bus for ethernet devices... 1 Ethernet Device(s) found The device is not found at the first attempt. Obviously, a value of 10 for bPwrOn2PwrGood seems too short but 20 works fine. Would that be a resonable compromise? If yes, I could send a patch. Wolfgang. Wolfgang. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [STATUS] v2011.12-rc2 is out - finish for release...
Dear Wolfgang, On 19.12.2011 12:23, Wolfgang Denk wrote: > Hi everybody, > > I've just released v2011.12-rc2; please help testing. > > Please respond quickly if you find anything missing for the final > release, I want to get this out on Friday at latest. avr32 is still broken. Anatolij has taken the required patch cause Reinhard is not responding. Please merge this patch into final release. Anatolij can you please send a pull request for http://git.denx.de/?p=u-boot/u-boot-staging.git;a=commitdiff;h=c230649a1da6701b081105a43beef163ae5e2820 best regards Andreas Bießmann ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [STATUS] v2011.12-rc2 is out - finish for release...
Hello Andreas, On Mon, 19 Dec 2011 13:21:51 +0100 "Andreas Bießmann" wrote: > Dear Wolfgang, > > On 19.12.2011 12:23, Wolfgang Denk wrote: > > Hi everybody, > > > > I've just released v2011.12-rc2; please help testing. > > > > Please respond quickly if you find anything missing for the final > > release, I want to get this out on Friday at latest. > > avr32 is still broken. Anatolij has taken the required patch cause > Reinhard is not responding. Please merge this patch into final release. > Anatolij can you please send a pull request for > http://git.denx.de/?p=u-boot/u-boot-staging.git;a=commitdiff;h=c230649a1da6701b081105a43beef163ae5e2820 Yes. I've another patch in my staging branch and maybe will add some more fixes, and then I'll send a pull request. Thanks, Anatolij ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] i.mx6:imx6q: allign MAC address with burned-in ordering
For the i.mx6q, the burned-in MAC address will be the following odering,
fuse: 0x620[7:0] MAC_ADDR[7:0] ---> mac[5]
fuse: 0x620[15:8] MAC_ADDR[15:8]---> mac[4]
fuse: 0x620[23:16] MAC_ADDR[23:16] ---> mac[3]
fuse: 0x620[31:24] MAC_ADDR[31:24] ---> mac[2]
fuse: 0x630[7:0] MAC_ADDR[39:32] ---> mac[1]
fuse: 0x630[15:8] MAC_ADDR[47:40] ---> mac[0]
This patch also fix the error caculation for the fuse bank[0] address
Signed-off-by: Jason Liu
Cc: Stefano Babic
---
arch/arm/cpu/armv7/mx6/soc.c | 14 --
arch/arm/include/asm/arch-mx6/imx-regs.h |2 +-
2 files changed, 9 insertions(+), 7 deletions(-)
diff --git a/arch/arm/cpu/armv7/mx6/soc.c b/arch/arm/cpu/armv7/mx6/soc.c
index dff5e4e..bd59cf5 100644
--- a/arch/arm/cpu/armv7/mx6/soc.c
+++ b/arch/arm/cpu/armv7/mx6/soc.c
@@ -70,13 +70,15 @@ void imx_get_mac_from_fuse(unsigned char *mac)
struct fuse_bank4_regs *fuse =
(struct fuse_bank4_regs *)bank->fuse_regs;
- u32 mac_lo = readl(&fuse->mac_addr_low);
- u32 mac_hi = readl(&fuse->mac_addr_high);
+ u32 value = readl(&fuse->mac_addr_high);
+ mac[0] = (value >> 8);
+ mac[1] = value ;
- *(u32 *)mac = mac_lo;
-
- mac[4] = mac_hi & 0xff;
- mac[5] = (mac_hi >> 8) & 0xff;
+ value = readl(&fuse->mac_addr_low);
+ mac[2] = value >> 24 ;
+ mac[3] = value >> 16 ;
+ mac[4] = value >> 8 ;
+ mac[5] = value ;
}
#endif
diff --git a/arch/arm/include/asm/arch-mx6/imx-regs.h
b/arch/arm/include/asm/arch-mx6/imx-regs.h
index 85d55b7..5fe9748 100644
--- a/arch/arm/include/asm/arch-mx6/imx-regs.h
+++ b/arch/arm/include/asm/arch-mx6/imx-regs.h
@@ -214,7 +214,7 @@ struct iim_regs {
u32 crc_value;
u32 rsvd6[3];
u32 version;
- u32 rsvd7[0xd8];
+ u32 rsvd7[0xdb];
struct fuse_bank {
u32 fuse_regs[0x20];
--
1.7.4.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [STATUS] v2011.12-rc2 is out - finish for release...
Hi all, Le 19/12/2011 13:07, Stefano Babic a écrit : On 19/12/2011 12:23, Wolfgang Denk wrote: Hi everybody, I've just released v2011.12-rc2; please help testing. Please respond quickly if you find anything missing for the final release, I want to get this out on Friday at latest. mx51evk is broken - fix merged, Albert has already merged my pull request into u-boot-arm. The fix must flow into mainline. Best regards, Stefano Babic Pull request for ARM coming later today. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] km/common: add toolchain variable
Hi Wolfgang, On 12/19/2011 12:33 PM, Wolfgang Denk wrote: > In message <4eef13d4.5020...@keymile.com> you wrote: >> >>> You can insert such information when you export the files from git, >>> say by adding a line like: >>> >>> Last commit date: $Format:%H %cD$ > ... >> After reading the doc I don't know how it could be used in my usecase. Please >> correct me if I am wrong, but this does only work in combination with the >> "git >> archive" command. And I don't want to do an archive, I want to export/copy >> some >> files out of the git tree into /tftpboot. > > You could for example use the following command to copy this file into > /tftpboot: > > $ cd board/keymile/scripts > $ git archive --format=tar HEAD README | \ > ( cd /tftpboot ; tar -xpvf - ) > hm together with the needed git configuration IMO a bit to complicated for my needs. To be honest I would like to keep this date information as it is. If this is not acceptable then I will remove this string completely from the u-boot tree and force the users to add a VERSION file to /tftpboot/scripts with: $ git describe > /tftpboot/scripts/VERSION or I keep it as a OOT patch. Just let me know. Best regards Holger ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ehci: speed up initialization
On 12/19/2011 01:51 PM, Vincent Palatin wrote: > On Mon, Dec 19, 2011 at 04:07, Wolfgang Grandegger > wrote: >> I just realized that this patch breaks "usb start" on my mx53loco board: >> >> MX53LOCO U-Boot > usb start >> (Re)start USB... >> USB: Register 10011 NbrPorts 1 >> USB EHCI 1.00 >> scanning bus for devices... 1 USB Device(s) found >> scanning bus for storage devices... 0 Storage Device(s) found >> scanning bus for ethernet devices... 0 Ethernet Device(s) found >> >> MX53LOCO U-Boot > usb start >> (Re)start USB... >> USB: Register 10011 NbrPorts 1 >> USB EHCI 1.00 >> scanning bus for devices... 2 USB Device(s) found >> scanning bus for storage devices... 0 Storage Device(s) found >> scanning bus for ethernet devices... 1 Ethernet Device(s) found >> >> The device is not found at the first attempt. Obviously, a value of 10 >> for bPwrOn2PwrGood seems too short but 20 works fine. Would that be a >> resonable compromise? If yes, I could send a patch. > > This doesn't match the EHCI standard which explicity states that the > power should be good after 20ms (paragraph 2.3.9 in EHCI 1.0), so we > should probably find whether we are missing another delay somewhere in > the generic EHCI code (which used to be hidden and should be fixed) or > if i.MX53 is not compliant with the standard and need a special quirk. I'm not an USB expert but if I look into the hub_power_on() function of the Linux kernel it waits at least 100ms (and only once). See: http://lxr.linux.no/#linux+v3.1.5/drivers/usb/core/hub.c#L567 Wolfgang. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 3/3] mx28evk: Add initial support for MX28EVK board
Dear Marek Vasut, On 12/17/2011 05:17 AM, Marek Vasut wrote: Hi Fabio, On 12/16/2011 12:07 AM, Fabio Estevam wrote: Tested boot via SD card and by loading a kernel via TFTP through the FEC interface. Have you any idea why this works from SD card but not by USB recovery using exactly same sb file? By quick look it seems that control is not passed back to the ROM properly after SPL or ROM is unable to load/run U-Boot after SPL. What do you mean? The SPL only inits the hardware and then lets the bootrom do whatever it wants again with the next file in u-boot.bd. U-Boot doesn't start up after SPL, that is what I see. I don't have tools or knowledge to investigate this further but here are steps to replicate the issue: 1) make mx28evk_config 2) make u-boot.sb 3) set dip switches to usb0 bootmode 4) connect micro-USB cable 5) try to load u-boot.sb using mfgtool (Windows) or imx_hid_recovery (Linux) [1] I tested USB powered mode and 5V wall adapter without difference. -- Veli-Pekka Peltola [1] http://git.pengutronix.de/?p=mxs-utils.git;a=commit;h=87692449099ae85922842f7f01acc0ab71e382d7 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] board/samsung/universal_c210/universal.c: Fix build warning
Fix:
universal.c: In function 's5pc210_phy_control':
universal.c:273:7: warning: 'ret' may be used uninitialized
in this function [-Wuninitialized]
Signed-off-by: Anatolij Gustschin
Cc: Lukasz Majewski
Cc: Minkyu Kang
---
board/samsung/universal_c210/universal.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/board/samsung/universal_c210/universal.c
b/board/samsung/universal_c210/universal.c
index 8393e4f..d0ff834 100644
--- a/board/samsung/universal_c210/universal.c
+++ b/board/samsung/universal_c210/universal.c
@@ -260,7 +260,7 @@ int board_mmc_init(bd_t *bis)
#ifdef CONFIG_USB_GADGET
static int s5pc210_phy_control(int on)
{
- int ret;
+ int ret = 0;
struct pmic *p = get_pmic();
if (pmic_probe(p))
--
1.7.5.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] usb: s3c_udc_otg: fix GCC 4.6 build warnings
Fix:
In file included from s3c_udc_otg.c:216:0:
s3c_udc_otg_xfer_dma.c: In function 'complete_tx':
s3c_udc_otg_xfer_dma.c:280:33: warning: variable 'is_short' set but not used
s3c_udc_otg_xfer_dma.c:280:6: warning: variable 'ep_tsr' set but not used
s3c_udc_otg_xfer_dma.c: In function 's3c_udc_irq':
s3c_udc_otg_xfer_dma.c:469:16: warning: variable 'flags' set but not used
s3c_udc_otg_xfer_dma.c:468:18: warning: variable 'gintmsk' set but not used
s3c_udc_otg_xfer_dma.c: In function 's3c_queue':
s3c_udc_otg_xfer_dma.c:582:14: warning: variable 'gintsts' set but not used
s3c_udc_otg_xfer_dma.c:581:16: warning: variable 'flags' set but not used
s3c_udc_otg_xfer_dma.c: In function 's3c_ep0_read':
s3c_udc_otg_xfer_dma.c:778:6: warning: variable 'ret' set but not used
s3c_udc_otg_xfer_dma.c: In function 's3c_udc_set_halt':
s3c_udc_otg_xfer_dma.c:1020:16: warning: variable 'flags' set but not used
s3c_udc_otg_xfer_dma.c: In function 's3c_ep0_setup':
s3c_udc_otg_xfer_dma.c:1258:13: warning: initialization from incompatible
pointer type [enabled by default]
s3c_udc_otg_xfer_dma.c:1239:16: warning: variable 'is_in' set but not used
s3c_udc_otg_xfer_dma.c:1239:9: warning: variable 'bytes' set but not used
s3c_udc_otg.c: In function 'usb_gadget_register_driver':
s3c_udc_otg.c:292:16: warning: variable 'flags' set but not used
s3c_udc_otg.c: In function 'usb_gadget_unregister_driver':
s3c_udc_otg.c:338:16: warning: variable 'flags' set but not used
s3c_udc_otg.c: In function 's3c_ep_enable':
s3c_udc_otg.c:582:16: warning: variable 'flags' set but not used
s3c_udc_otg.c: In function 's3c_ep_disable':
s3c_udc_otg.c:646:16: warning: variable 'flags' set but not used
s3c_udc_otg.c: In function 's3c_dequeue':
s3c_udc_otg.c:704:16: warning: variable 'flags' set but not used
Signed-off-by: Anatolij Gustschin
Cc: Lukasz Majewski
Cc: Remy Bohmer
---
drivers/usb/gadget/s3c_udc_otg.c | 52 -
drivers/usb/gadget/s3c_udc_otg_xfer_dma.c | 166 -
include/usb/lin_gadget_compat.h |2 +-
include/usb/s3c_udc.h | 20 ++--
4 files changed, 125 insertions(+), 115 deletions(-)
diff --git a/drivers/usb/gadget/s3c_udc_otg.c b/drivers/usb/gadget/s3c_udc_otg.c
index 901fac9..1050a98 100644
--- a/drivers/usb/gadget/s3c_udc_otg.c
+++ b/drivers/usb/gadget/s3c_udc_otg.c
@@ -47,7 +47,6 @@
#include
#include "regs-otg.h"
-#include
#include
/***/
@@ -73,8 +72,6 @@
#define EP0_CON0
#define EP_MASK0xF
-#if defined(DEBUG_S3C_UDC_SETUP) || defined(DEBUG_S3C_UDC_ISR) \
- || defined(DEBUG_S3C_UDC_OUT_EP)
static char *state_names[] = {
"WAIT_FOR_SETUP",
"DATA_STATE_XMIT",
@@ -86,7 +83,6 @@ static char *state_names[] = {
"WAIT_FOR_IN_COMPLETE",
"WAIT_FOR_NULL_COMPLETE",
};
-#endif
#define DRIVER_DESC "S3C HS USB OTG Device Driver, (c) Samsung Electronics"
#define DRIVER_VERSION "15 March 2009"
@@ -362,7 +358,7 @@ static void done(struct s3c_ep *ep, struct s3c_request
*req, int status)
{
unsigned int stopped = ep->stopped;
- DEBUG("%s: %s %p, req = %p, stopped = %d\n",
+ debug("%s: %s %p, req = %p, stopped = %d\n",
__func__, ep->ep.name, ep, &req->req, stopped);
list_del_init(&req->queue);
@@ -373,7 +369,7 @@ static void done(struct s3c_ep *ep, struct s3c_request
*req, int status)
status = req->req.status;
if (status && status != -ESHUTDOWN) {
- DEBUG("complete %s req %p stat %d len %u/%u\n",
+ debug("complete %s req %p stat %d len %u/%u\n",
ep->ep.name, &req->req, status,
req->req.actual, req->req.length);
}
@@ -401,7 +397,7 @@ static void done(struct s3c_ep *ep, struct s3c_request
*req, int status)
req->req.complete(&ep->ep, &req->req);
spin_lock(&ep->dev->lock);
- DEBUG("callback completed\n");
+ debug("callback completed\n");
ep->stopped = stopped;
}
@@ -413,7 +409,7 @@ static void nuke(struct s3c_ep *ep, int status)
{
struct s3c_request *req;
- DEBUG("%s: %s %p\n", __func__, ep->ep.name, ep);
+ debug("%s: %s %p\n", __func__, ep->ep.name, ep);
/* called with irqs blocked */
while (!list_empty(&ep->queue)) {
@@ -456,7 +452,7 @@ static void reconfig_usbd(void)
int i;
unsigned int uTemp = writel(CORE_SOFT_RESET, ®->grstctl);
- DEBUG(2, "Reseting OTG controller\n");
+ debug("Reseting OTG controller\n");
writel(0<<15/* PHY Low Power Clock sel*/
|1<<14 /* Non-Periodic TxFIFO Rewind Enable*/
@@ -526,13 +522,13 @@ static void reconfig_usbd(void)
/* Flush the RX FIFO */
writel(RX_FIFO_FLUSH, ®->grstctl);
while (readl(®->grstctl) & RX_FIFO_FLUSH)
- DEBUG("%s: waiting for S3C_UDC_OTG_GRSTC
Re: [U-Boot] [PATCH] MXS-NAND: Backport ecc.size from linux kernel
Hi Marek, On 12/18/2011 07:50 PM, Marek Vasut wrote: The ecc.size for mxs NAND driver is set to 1 in Linux kernel and to 512 in U-Boot, which causes "ubi part" command malfunction due to wrong subpage size. [snip] Subpage size is now reported correctly and ubifs works fine. Thanks! Tested-by: Veli-Pekka Peltola -- Veli-Pekka Peltola ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ehci: speed up initialization
On Mon, Dec 19, 2011 at 04:07, Wolfgang Grandegger wrote: > I just realized that this patch breaks "usb start" on my mx53loco board: > > MX53LOCO U-Boot > usb start > (Re)start USB... > USB: Register 10011 NbrPorts 1 > USB EHCI 1.00 > scanning bus for devices... 1 USB Device(s) found > scanning bus for storage devices... 0 Storage Device(s) found > scanning bus for ethernet devices... 0 Ethernet Device(s) found > > MX53LOCO U-Boot > usb start > (Re)start USB... > USB: Register 10011 NbrPorts 1 > USB EHCI 1.00 > scanning bus for devices... 2 USB Device(s) found > scanning bus for storage devices... 0 Storage Device(s) found > scanning bus for ethernet devices... 1 Ethernet Device(s) found > > The device is not found at the first attempt. Obviously, a value of 10 > for bPwrOn2PwrGood seems too short but 20 works fine. Would that be a > resonable compromise? If yes, I could send a patch. This doesn't match the EHCI standard which explicity states that the power should be good after 20ms (paragraph 2.3.9 in EHCI 1.0), so we should probably find whether we are missing another delay somewhere in the generic EHCI code (which used to be hidden and should be fixed) or if i.MX53 is not compliant with the standard and need a special quirk. -- Vincent ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] board/samsung/universal_c210/universal.c: Fix build warning
> Fix:
> universal.c: In function 's5pc210_phy_control':
> universal.c:273:7: warning: 'ret' may be used uninitialized
> in this function [-Wuninitialized]
>
> Signed-off-by: Anatolij Gustschin
> Cc: Lukasz Majewski
> Cc: Minkyu Kang
> ---
> board/samsung/universal_c210/universal.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/board/samsung/universal_c210/universal.c
> b/board/samsung/universal_c210/universal.c index 8393e4f..d0ff834
> 100644 --- a/board/samsung/universal_c210/universal.c
> +++ b/board/samsung/universal_c210/universal.c
> @@ -260,7 +260,7 @@ int board_mmc_init(bd_t *bis)
> #ifdef CONFIG_USB_GADGET
> static int s5pc210_phy_control(int on)
> {
> - int ret;
> + int ret = 0;
> struct pmic *p = get_pmic();
>
> if (pmic_probe(p))
Hi Anatolij,
Thank you for pointing me out about the new compiler version.
I've just realized, that I'm still using:
gcc version 4.4.1 (Sourcery G++ Lite 2009q3-68)
My question is about the GCC 4.6 version.
Is it a Codesourcery (Mentor Graphisc), ptxdist Oselas Toolchain,
buildroot (uClibc), linaro, ELDK or a vanilla GCC 4.6 build from source
with custom paramters?
--
Best regards,
Lukasz Majewski
Samsung Poland R&D Center
Platform Group
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] MXS-NAND: Backport ecc.size from linux kernel
> Hi Marek, > > On 12/18/2011 07:50 PM, Marek Vasut wrote: > > The ecc.size for mxs NAND driver is set to 1 in Linux kernel and to 512 > > in U-Boot, which causes "ubi part" command malfunction due to wrong > > subpage size. > > [snip] > > Subpage size is now reported correctly and ubifs works fine. Thanks! > > Tested-by: Veli-Pekka Peltola You're the guy doing the bluegiga mx28 board ? I think I noticed in linux kernel, are you for example working on mx28/device tree support too? M ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Coding Style cleanup
> -Original Message- > From: u-boot-boun...@lists.denx.de > [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Wolfgang Denk > Sent: Monday, December 19, 2011 4:41 PM > To: u-boot@lists.denx.de > Subject: [U-Boot] [PATCH] Coding Style cleanup > > Fix trailing white space, indentation by spaces instead of TABs, > excessive blank lines, trailing blank lines. > > Signed-off-by: Wolfgang Denk [snip]...[snip] > @@ -563,6 +556,7 @@ extern unsigned long > get_board_sys_clk(unsigned long dummy); > "tftp $fdtaddr $tftppath/$fdtfile;" > \ > "bootm $loadaddr - $fdtaddr" > > + > #define CONFIG_RAMBOOTCOMMAND This appears to be a stray addition. ~sanjeev [snip]...[snip] ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] board/samsung/universal_c210/universal.c: Fix build warning
Hi all,
On Mon, 19 Dec 2011 16:00:21 +0100
Lukasz Majewski wrote:
...
> > diff --git a/board/samsung/universal_c210/universal.c
> > b/board/samsung/universal_c210/universal.c index 8393e4f..d0ff834
> > 100644 --- a/board/samsung/universal_c210/universal.c
> > +++ b/board/samsung/universal_c210/universal.c
> > @@ -260,7 +260,7 @@ int board_mmc_init(bd_t *bis)
> > #ifdef CONFIG_USB_GADGET
> > static int s5pc210_phy_control(int on)
> > {
> > - int ret;
> > + int ret = 0;
> > struct pmic *p = get_pmic();
> >
> > if (pmic_probe(p))
>
> Hi Anatolij,
>
> Thank you for pointing me out about the new compiler version.
>
> I've just realized, that I'm still using:
> gcc version 4.4.1 (Sourcery G++ Lite 2009q3-68)
>
> My question is about the GCC 4.6 version.
> Is it a Codesourcery (Mentor Graphisc), ptxdist Oselas Toolchain,
> buildroot (uClibc), linaro, ELDK or a vanilla GCC 4.6 build from source
> with custom paramters?
I used GCC version 4.2.2 from ELDK 4.2 and GCC version 4.6.1 20110627
from ELDK 5.1 and see this warning with both.
For another patch fixing warnings for s3c_udc_otg driver I
also used same GCC versions, but I see the warnings only
with GCC 4.6.1 from ELDK 5.1. GCC 4.2.2 from ELDK 4.2 didn't
generate any warning when building s3c_udc_otg driver.
Thanks,
Anatolij
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] km/common: add toolchain variable
Dear Holger Brunck, In message <4eef350c.4040...@keymile.com> you wrote: > > hm together with the needed git configuration IMO a bit to complicated for my > needs. To be honest I would like to keep this date information as it is. OK, as you like it. > If this is not acceptable then I will remove this string completely from the > u-boot tree and force the users to add a VERSION file to /tftpboot/scripts > with: I don't like it, that's all. But then I don't have to. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Alliance: In international politics, the union of two thieves who have their hands so deeply inserted in each other's pocket that they cannot separately plunder a third. - Ambrose Bierce ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] MXS-NAND: Backport ecc.size from linux kernel
On 12/19/2011 05:05 PM, Marek Vasut wrote: You're the guy doing the bluegiga mx28 board ? I think I noticed in linux kernel, are you for example working on mx28/device tree support too? Yes, I have done something but most of kernel stuff related to our board is done by my colleague Lauri Hintsala. Currently device tree support is not in our task list. I don't know if someone is working on it. Shawn Guo (kernel maintainer for MX28) might know. -- Veli-Pekka Peltola ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ehci: speed up initialization
Dear Wolfgang Grandegger, In message <4eef290b.9060...@grandegger.com> you wrote: > > The device is not found at the first attempt. Obviously, a value of 10 > for bPwrOn2PwrGood seems too short but 20 works fine. Would that be a > resonable compromise? If yes, I could send a patch. If 10 doesn't work, but 20 does, then we should use at least 25 or even 30. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de The inappropriate cannot be beautiful. - Frank Lloyd Wright _The Future of Architecture_ (1953) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Coding Style cleanup
Dear "Premi, Sanjeev", In message you wrote: > > > @@ -563,6 +556,7 @@ extern unsigned long=20 > > get_board_sys_clk(unsigned long dummy); > > "tftp $fdtaddr $tftppath/$fdtfile;" =09 > > \ > > "bootm $loadaddr - $fdtaddr" > > =20 > > + > > #define CONFIG_RAMBOOTCOMMAND =09 > > This appears to be a stray addition. ...which appears to be added by your mailer. I don;t see it in the patch. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de When the ax entered the forest, the trees said, "The handle is one of us!" -- Turkish proverb ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4] ARMV7: Add support For Logic OMAP35x/DM37x modules
On 12/19/2011 02:37 AM, Igor Grinberg wrote: > Hi Peter, > > Thanks for fixing all the issues pointed. > I have one last question (sorry for not seeing it earlier) and one neat below. > > On 12/18/11 19:25, Peter Barada wrote: >> This patch adds basic support for OMAP35x/DM37x SOM LV/Torpedo >> reference boards. It assumes U-boot is loaded to SDRAM with the >> help of another small bootloader (x-load) running from SRAM. >> >> Signed-off-by: Peter Barada >> Cc: Tom Rini >> Cc: Igor Grinberg >> Cc: Wolfgang Denk >> --- [ ... ] > > > The TRM says that the initial state of pins is the safe mode (M7). > Also not every pin has this state by definition. > So the question is, wouldn't it be better to remove those lines > that setup the safe mode, or is there a purpose, which I don't see? > Removing those lines will make the file/patch much shorter. Back when we first started with u-boot on these boards, it was loaded from another bootloader that did its own pinmux setup and this was how I put all the pins back to a known state. Moving to SPL/u-boot will preclude having to tweak all the pins. I'll trim the pinmux setup back to only those pins that are different than their reset values (or those that need PTD/EN pulldowns to minimise power consumption when the kernel goes into suspend). >> +/* DDR - I use Micron DDR */ >> +#define CONFIG_OMAP3_MICRON_DDR > You forgot to remove that one - it is not used anymore... Done... > [...] > > -- > Regards, > Igor. -- Peter Barada peter.bar...@logicpd.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] board/samsung/universal_c210/universal.c: Fix build warning
Dear Lukasz, In message <20111219161828.7495c109@wker> Anatolij Gustschin wrote: > > I used GCC version 4.2.2 from ELDK 4.2 and GCC version 4.6.1 20110627 > from ELDK 5.1 and see this warning with both. Note: ELDK 5.1 is based on Yocto 1.1 (edison-6.0 release tag), plus some fixes for ARM related GCC issues. See http://www.denx.de/wiki/ELDK-5 Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de All he had was nothing, but that was something, and now it had been taken away. - Terry Pratchett, _Sourcery_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] PXA: Kill last remnants of set_GPIO_mode function
Hi Marek, Albert, On Mon, 12 Dec 2011 16:34:03 +0100 Marek Vasut wrote: > GPIO configuration shall never be done inside a driver, never. > > Signed-off-by: Marek Vasut > Cc: Anatolij Gustschin > Cc: Albert ARIBAUD > --- > board/lubbock/lubbock.c |6 ++ > drivers/mmc/pxa_mmc.c |5 - > 2 files changed, 6 insertions(+), 5 deletions(-) This patch should go into v2011.12 release. Who is going to apply it? Or should I push it via my staging branch? Thanks, Anatolij ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] PXA: Kill last remnants of set_GPIO_mode function
Le 19/12/2011 16:57, Anatolij Gustschin a écrit : Hi Marek, Albert, On Mon, 12 Dec 2011 16:34:03 +0100 Marek Vasut wrote: GPIO configuration shall never be done inside a driver, never. Signed-off-by: Marek Vasut Cc: Anatolij Gustschin Cc: Albert ARIBAUD --- board/lubbock/lubbock.c |6 ++ drivers/mmc/pxa_mmc.c |5 - 2 files changed, 6 insertions(+), 5 deletions(-) This patch should go into v2011.12 release. Who is going to apply it? Or should I push it via my staging branch? Thanks, Anatolij How was this patch tested? Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] PXA: Kill last remnants of set_GPIO_mode function
On Mon, 19 Dec 2011 17:15:03 +0100 Albert ARIBAUD wrote: > Le 19/12/2011 16:57, Anatolij Gustschin a écrit : > > Hi Marek, Albert, > > > > On Mon, 12 Dec 2011 16:34:03 +0100 > > Marek Vasut wrote: > > > >> GPIO configuration shall never be done inside a driver, never. > >> > >> Signed-off-by: Marek Vasut > >> Cc: Anatolij Gustschin > >> Cc: Albert ARIBAUD > >> --- > >> board/lubbock/lubbock.c |6 ++ > >> drivers/mmc/pxa_mmc.c |5 - > >> 2 files changed, 6 insertions(+), 5 deletions(-) > > > > This patch should go into v2011.12 release. Who is going > > to apply it? Or should I push it via my staging branch? > > > > Thanks, > > Anatolij > > How was this patch tested? I only compile-tested it. Marek, do you have this board? Did you test this patch on real hardware? Anatolij ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] PXA: Kill last remnants of set_GPIO_mode function
> Le 19/12/2011 16:57, Anatolij Gustschin a écrit : > > Hi Marek, Albert, > > > > On Mon, 12 Dec 2011 16:34:03 +0100 > > > > Marek Vasut wrote: > >> GPIO configuration shall never be done inside a driver, never. > >> > >> Signed-off-by: Marek Vasut > >> Cc: Anatolij Gustschin > >> Cc: Albert ARIBAUD > >> --- > >> > >> board/lubbock/lubbock.c |6 ++ > >> drivers/mmc/pxa_mmc.c |5 - > >> 2 files changed, 6 insertions(+), 5 deletions(-) > > > > This patch should go into v2011.12 release. Who is going > > to apply it? Or should I push it via my staging branch? > > > > Thanks, > > Anatolij > > How was this patch tested? > > Amicalement, It wasn't ... only compile-tested. Does someone have a lubbock? M ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] PXA: Kill last remnants of set_GPIO_mode function
Dear Marek Vasut, In message <201112191725.00963.marek.va...@gmail.com> you wrote: > > It wasn't ... only compile-tested. Does someone have a lubbock? Lubbock is orphaned, no testers are known. If it's compile clean, that should be good enough. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Only in our dreams we are free. The rest of the time we need wages. - Terry Pratchett, _Wyrd Sisters_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] PXA: Kill last remnants of set_GPIO_mode function
Hi Wolfgang, Le 19/12/2011 17:33, Wolfgang Denk a écrit : Dear Marek Vasut, In message<201112191725.00963.marek.va...@gmail.com> you wrote: It wasn't ... only compile-tested. Does someone have a lubbock? Lubbock is orphaned, no testers are known. If it's compile clean, that should be good enough. Best regards, Wolfgang Denk Ok, I'll pull it in then; but if Lubbock is orphaned, then maybe we should throw a call for a new maintainer to step forward during next release cycle, and if none shows, then remove the board rather and try and keep it alive. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] New Oxford Semiconductor board with assertion fail in linker
Hi, I am trying to port support for a board from Oxford Semiconductor to the current head of the git repository. Medion released GPL Sources of their P89626 NAS [1]. In these sources there are using an old version 1.1.2 of U-Boot with some modification a board from Oxford Semiconductor. The board is called ox820. I made a clone of the git repo [2] and modified the source to get the compiliation working. The modifications I made, can be viewed here [3]. When I am trying to build, I get this error from the linker (I also tried the toolchain which is included in the download from Medion): /home/michael/x-tools/arm-unknown-eabi/bin/arm-unknown-eabi-ld: BFD (crosstool-NG 1.13.2) 2.21.1 assertion fail /home/michael/tmp/x/.build/src/binutils-2.21.1a/bfd/elf32-arm.c:12478 /bin/bash: line 1: 5991 Segmentation fault /home/michael/x-tools/arm-unknown-eabi/bin/arm-unknown-eabi-ld -pie -T u-boot.lds -Bstatic -Ttext "-1" $UNDEF_SYM arch/arm/cpu/arm1136/start.o --start-group api/libapi.o arch/arm/cpu/arm1136/libarm1136.o arch/arm/lib/libarm.o common/libcommon.o disk/libdisk.o drivers/bios_emulator/libatibiosemu.o drivers/block/libblock.o drivers/dma/libdma.o drivers/fpga/libfpga.o drivers/gpio/libgpio.o drivers/hwmon/libhwmon.o drivers/i2c/libi2c.o drivers/input/libinput.o drivers/misc/libmisc.o drivers/mmc/libmmc.o drivers/mtd/libmtd.o drivers/mtd/nand/libnand.o drivers/mtd/onenand/libonenand.o drivers/mtd/spi/libspi_flash.o drivers/mtd/ubi/libubi.o drivers/net/libnet.o drivers/net/phy/libphy.o drivers/pci/libpci.o drivers/pcmcia/libpcmcia.o drivers/power/libpower.o drivers/rtc/librtc.o drivers/serial/libserial.o drivers/spi/libspi.o drivers/twserial/libtws.o drivers/usb/eth/libusb_eth.o drivers/usb/gadget/libusb_gadget.o drivers/usb/host/libusb_host.o drivers/usb/musb/libusb_musb.o drivers/usb/phy/libusb_phy.o drivers/usb/ulpi/libusb_ulpi.o drivers/video/libvideo.o drivers/watchdog/libwatchdog.o fs/cramfs/libcramfs.o fs/ext2/libext2fs.o fs/fat/libfat.o fs/fdos/libfdos.o fs/jffs2/libjffs2.o fs/reiserfs/libreiserfs.o fs/ubifs/libubifs.o fs/yaffs2/libyaffs2.o lib/libfdt/libfdt.o lib/libgeneric.o lib/lzma/liblzma.o lib/lzo/liblzo.o lib/zlib/libz.o net/libnet.o post/libpost.o board/ox820/libox820.o --end-group /home/michael/medion/u-boot-medion-p89626/arch/arm/lib/eabi_compat.o -L /home/michael/x-tools/arm-unknown-eabi/lib/gcc/arm-unknown-eabi/4.4.6 -lgcc -Map u-boot.map -o u-boot make: *** [u-boot] Error 139 Here is the code from binutils. The assertion fails in the line with the BFD_ASSERT case DT_PLTRELSZ: s = bfd_get_section_by_name (output_bfd, RELOC_SECTION (htab, ".plt")); BFD_ASSERT (s != NULL); dyn.d_un.d_val = s->size; bfd_elf32_swap_dyn_out (output_bfd, &dyn, dyncon); break; What I am doing wrong? What is missing? Where should I look know? Is this a bug in binutils? Michael [1] http://www1.medion.de/downloads/download.pl?lang=de&filename=gpl_source_md86407.exe&id=10636&type=software [2] http://git.denx.de/u-boot.git/ [3] https://github.com/michaelkebe/u-boot-medion-p89626 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] sspi command creates chip select at wrong time
When I use the sspi command 'sspi 1 24 0301ff' it causes the chip select line to toggle between each byte. It would be low for the 03, then a quick low->high->low transition between the next byte '01.' This is causing me all kinds of grief with the part. Is there a setting to fix this or do I need to just hack the code? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Pull request: u-boot-arm/master
Hi Wolfgang, The following changes since commit 901de79a3792c81aefcbf207a34049e63f21362b: Prepare v2011.12-rc2 (2011-12-19 12:12:54 +0100) are available in the git repository at: git://git.denx.de/u-boot-arm.git master Anatolij Gustschin (3): Fix building for mx51evk board ARM: sbc35_a9g20: re-add MACH_TYPE_SBC35_A9G20 ARM: tny_a9260: re-add MACH_TYPE_TNY_A9G20 and MACH_TYPE_TNY_A9260 Chris Lalancette (1): omap4_panda: Initialize the USB phy David Müller (ELSOFT AG) (1): add print_cpuinfo to s3c24x0 Heiko Schocher (1): arm, fdt: update ethernet mac address before booting Linux Ilya Yanok (1): arm926ejs: remove noop flush_dcache_all function Manfred Rudigier (1): davinci: Fixed wrong timebase clock frequency. Marek Vasut (2): M28: Fix tab indent in u-boot.bd PXA: Kill last remnants of set_GPIO_mode function arch/arm/cpu/arm920t/s3c24x0/Makefile|1 + arch/arm/cpu/arm920t/s3c24x0/cpu_info.c | 54 + arch/arm/cpu/arm926ejs/cache.c |5 -- arch/arm/cpu/arm926ejs/davinci/timer.c |2 +- arch/arm/include/asm/arch-omap4/clocks.h | 63 ++ arch/arm/lib/bootm.c |2 + board/calao/sbc35_a9g20/sbc35_a9g20.c|1 - board/calao/tny_a9260/tny_a9260.c|5 -- board/denx/m28evk/u-boot.bd |8 ++-- board/freescale/mx51evk/mx51evk.c|3 +- board/freescale/mx53loco/mx53loco.c |3 +- board/lubbock/lubbock.c |6 +++ board/ti/panda/panda.c | 59 drivers/mmc/pxa_mmc.c|5 -- include/configs/sbc35_a9g20.h|3 + include/configs/tny_a9260.h |4 ++ 16 files changed, 201 insertions(+), 23 deletions(-) create mode 100644 arch/arm/cpu/arm920t/s3c24x0/cpu_info.c Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ehci: speed up initialization
Hi Wolfgang, 2011/12/19 Wolfgang Grandegger : > On 12/19/2011 01:51 PM, Vincent Palatin wrote: >> On Mon, Dec 19, 2011 at 04:07, Wolfgang Grandegger >> wrote: >>> I just realized that this patch breaks "usb start" on my mx53loco board: >>> >>> The device is not found at the first attempt. Obviously, a value of 10 >>> for bPwrOn2PwrGood seems too short but 20 works fine. Would that be a >>> resonable compromise? If yes, I could send a patch. >> >> This doesn't match the EHCI standard which explicity states that the >> power should be good after 20ms (paragraph 2.3.9 in EHCI 1.0), so we >> should probably find whether we are missing another delay somewhere in >> the generic EHCI code (which used to be hidden and should be fixed) or >> if i.MX53 is not compliant with the standard and need a special quirk. > > I'm not an USB expert but if I look into the hub_power_on() function of > the Linux kernel it waits at least 100ms (and only once). See: > > http://lxr.linux.no/#linux+v3.1.5/drivers/usb/core/hub.c#L567 I would prefer a solution in line with the specification, but what is the reason why Linux takes 100 msec here? Is that just chosen randomly , or was there a good reason for it? If there is a good reason (which I assume) I would prefer to follow Linux here and go for the 100 msec. Can you please provide a patch? Kind regards, Remy ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] PXA: Kill last remnants of set_GPIO_mode function
> Hi Wolfgang, > > Le 19/12/2011 17:33, Wolfgang Denk a écrit : > > Dear Marek Vasut, > > > > In message<201112191725.00963.marek.va...@gmail.com> you wrote: > >> It wasn't ... only compile-tested. Does someone have a lubbock? > > > > Lubbock is orphaned, no testers are known. > > > > If it's compile clean, that should be good enough. > > > > Best regards, > > > > Wolfgang Denk > > Ok, I'll pull it in then; but if Lubbock is orphaned, then maybe we > should throw a call for a new maintainer to step forward during next > release cycle, and if none shows, then remove the board rather and try > and keep it alive. > > Amicalement, That's indeed the plan. M ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] net/eth: Don't issue warnings for offboard ethernet chips
On Dec 17, 2011, at 15:16, Wolfgang Denk wrote: > Dear Kyle Moffett, > In message <1324001821-15337-1-git-send-email-kyle.d.moff...@boeing.com> you > wrote: >> When using an offboard ethernet chip such as e1000, it is highly likely >> that the driver has already read a valid MAC address from the onboard >> EEPROM. In that case, U-Boot should not issue a warning about the >> absence of an "eth*addr" value in the environment. > > Yes, it should. The rule is that then environment settings always > have precedence, and if they are missing or contain different data > than other sources for this information, a waning shall be printed. That is a problem for devices which are typically add-in PCI cards. In that case U-Boot can't be expected to have knowledge of what the MAC addresses should be, and it should just use the ROM attached to the card instead. In our use case the e1000 chips are on a separate board attached via CompactPCI. U-Boot should not spontaneously start throwing errors just because the board was stuck into a different slot or replaced due to hardware failure. I was careful to maintain the behavior that U-Boot will issue a warning if there is no usable MAC address or if the environment has a MAC address that does not match the board. However, in the case that the board itself has a valid external MAC address and U-Boot does not even have an environment variable, it should not cause extra messages. Think about hot-pluggable USB net adapters where the detection order is nondeterministic. >> A properly configured HWW-1U-1A board is fixed from this output: >> >> Net: e1000: 00:50:93:81:ff:8a >> e1000: 00:50:93:81:ff:8b >> owt0, owt1, peer, e1000#0 >> Warning: failed to set MAC address >> , e1000#1 >> Warning: failed to set MAC address >> >> To this: >> >> Net: e1000: 00:50:93:81:ff:8a >> e1000: 00:50:93:81:ff:8b >> owt0, owt1, peer, e1000#0, e1000#1 > > This is also not correct. There should never be any printing of the > MAC addresses here. > > The messages should be: > > Net: owt0, owt1, peer, e1000#0, e1000#1 The "e1000" driver has always done that. I can submit a separate patch to fix that if you would like. >> Furthermore, the log messages should avoid screwing up the "Net:" output >> formatting provided by the calling code, EG: >> >> Net: eth0, eth1 [could not set MAC: 00:50:93:81:ff:8a], eth2 > > No. "could not set" is an error message, and deserves a separate > line. Ok, I will respin the patch so that errors show up like this: Net: eth0, eth1, ERROR: Could not set MAC address: 00:50:93:81:ff:8a eth2 Is that OK? Cheers, Kyle Moffett ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] net/eth: Don't issue warnings for offboard ethernet chips
Dear "Moffett, Kyle D", In message <58a08f2d-4743-4634-a909-466eb8535...@boeing.com> you wrote: > > > Yes, it should. The rule is that then environment settings always > > have precedence, and if they are missing or contain different data > > than other sources for this information, a waning shall be printed. > > That is a problem for devices which are typically add-in PCI cards. > In that case U-Boot can't be expected to have knowledge of what the > MAC addresses should be, and it should just use the ROM attached to > the card instead. The user can be expected to read the boot messages and adjust the environment if he wants to use the card's settinge. In any case, the user shall have the authority to overwrite the card's settings by defining any settings in the environment he wants. > In our use case the e1000 chips are on a separate board attached via > CompactPCI. U-Boot should not spontaneously start throwing errors > just because the board was stuck into a different slot or replaced > due to hardware failure. U-Boot does not throw errors if you have appropriate settings in the environment. The worst to happen is a warning thatt he MAC settings in U-Boot and on the card don't match. > However, in the case that the board itself has a valid external MAC > address and U-Boot does not even have an environment variable, it > should not cause extra messages. Think about hot-pluggable USB net > adapters where the detection order is nondeterministic. Yes, it should, because a mandatory environment variable is not set correctly. > The "e1000" driver has always done that. I can submit a separate > patch to fix that if you would like. Thats would be welcome, thanks. > Ok, I will respin the patch so that errors show up like this: > > Net: eth0, eth1, > ERROR: Could not set MAC address: 00:50:93:81:ff:8a > eth2 > > Is that OK? Yes, thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Two wrongs don't make a right, but three rights make a left. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Intent of CONFIG_NAND_ENV_DST?
Hey all, I'm attempting to use CONFIG_NAND_ENV_DST work, and I'm wondering it what I see as the intent of the option is the real intent as it's not working without patches, but perhaps I'm just using it wrong. What I'm trying to have done is that if the above is set, SPL will read the environment from NAND into CONFIG_NAND_ENV_DST (nand_spl/ code does this, today) and once U-Boot itself is fired up, env_init will see we've been given a real environment and go. But what happens now is that there's no special case of env_relocate_spec that knows our current pointer is fine and just needs to populate the table. When I asked Wolfgang on IRC, he mentioned the embedded into the U-Boot image trick, but I don't want to go down that path as it bloats the image size (and in this case, U-Boot supports both a NAND-sporting EVM and the NAND-less BeagleBone, and we don't want to add all that padding and extra space to the Bone image). Thanks! -- Tom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] New Oxford Semiconductor board with assertion fail in linker
Dear Michael Kebe, In message you wrote: > > When I am trying to build, I get this error from the linker (I also > tried the toolchain which is included in the download from Medion): ... > /home/michael/x-tools/arm-unknown-eabi/bin/arm-unknown-eabi-ld: BFD > (crosstool-NG 1.13.2) 2.21.1 assertion fail ... > What I am doing wrong? What is missing? Where should I look know? Is > this a bug in binutils? Try a known to be working (with current code) tool chain? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de The human mind ordinarily operates at only ten percent of its capaci- ty - the rest is overhead for the operating system. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ehci: speed up initialization
On Mon, Dec 19, 2011 at 08:59, Remy Bohmer wrote: > Hi Wolfgang, > > 2011/12/19 Wolfgang Grandegger : >> On 12/19/2011 01:51 PM, Vincent Palatin wrote: >>> On Mon, Dec 19, 2011 at 04:07, Wolfgang Grandegger >>> wrote: I just realized that this patch breaks "usb start" on my mx53loco board: The device is not found at the first attempt. Obviously, a value of 10 for bPwrOn2PwrGood seems too short but 20 works fine. Would that be a resonable compromise? If yes, I could send a patch. >>> >>> This doesn't match the EHCI standard which explicity states that the >>> power should be good after 20ms (paragraph 2.3.9 in EHCI 1.0), so we >>> should probably find whether we are missing another delay somewhere in >>> the generic EHCI code (which used to be hidden and should be fixed) or >>> if i.MX53 is not compliant with the standard and need a special quirk. >> >> I'm not an USB expert but if I look into the hub_power_on() function of >> the Linux kernel it waits at least 100ms (and only once). See: >> >> http://lxr.linux.no/#linux+v3.1.5/drivers/usb/core/hub.c#L567 > > I would prefer a solution in line with the specification, but what is > the reason why Linux takes 100 msec here? The patch adding this delay was the following one : commit b789696af8b4102b7cc26dec30c2c51ce51ee18b Author: David Brownell Date: Wed Aug 31 10:41:44 2005 -0700 [PATCH] USB: relax usbcore reset timings This appears to help some folk, please merge. This patch relaxes reset timings. There are some reports that it helps make enumeration work better on some high speed devices. Signed-off-by: David Brownell Signed-off-by: Greg Kroah-Hartman > Is that just chosen randomly , or was there a good reason for it? So random timings based on user inputs. -- Vincent Palatin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Intent of CONFIG_NAND_ENV_DST?
On 12/19/2011 11:58 AM, Tom Rini wrote: > Hey all, > > I'm attempting to use CONFIG_NAND_ENV_DST work, and I'm wondering it > what I see as the intent of the option is the real intent as it's not > working without patches, but perhaps I'm just using it wrong. What > I'm trying to have done is that if the above is set, SPL will read the > environment from NAND into CONFIG_NAND_ENV_DST (nand_spl/ code does > this, today) and once U-Boot itself is fired up, env_init will see > we've been given a real environment and go. But what happens now is > that there's no special case of env_relocate_spec that knows our > current pointer is fine and just needs to populate the table. Hmm... so it will unnecessarily reread the environment, discarding any variables that have been modified before then. That should be fixed (I think we just need to add CONFIG_NAND_ENV_DST to the ENV_IS_EMBEDDED ifdef in env_relocate_spec, as was done in env_init), though the primary intent was simply to get early read access to variables such as serial baud -- for that, it should already work, right? -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Intent of CONFIG_NAND_ENV_DST?
On Mon, Dec 19, 2011 at 11:57 AM, Scott Wood wrote: > On 12/19/2011 11:58 AM, Tom Rini wrote: >> Hey all, >> >> I'm attempting to use CONFIG_NAND_ENV_DST work, and I'm wondering it >> what I see as the intent of the option is the real intent as it's not >> working without patches, but perhaps I'm just using it wrong. What >> I'm trying to have done is that if the above is set, SPL will read the >> environment from NAND into CONFIG_NAND_ENV_DST (nand_spl/ code does >> this, today) and once U-Boot itself is fired up, env_init will see >> we've been given a real environment and go. But what happens now is >> that there's no special case of env_relocate_spec that knows our >> current pointer is fine and just needs to populate the table. > > Hmm... so it will unnecessarily reread the environment, discarding any > variables that have been modified before then. That should be fixed (I > think we just need to add CONFIG_NAND_ENV_DST to the ENV_IS_EMBEDDED > ifdef in env_relocate_spec, as was done in env_init), though the primary > intent was simply to get early read access to variables such as serial > baud -- for that, it should already work, right? It should be working for that use case, yes. I'll give things a shot with just or'ing in on the existing ENV_IS_EMBEDDED case and report back. -- Tom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] New Oxford Semiconductor board with assertion fail in linker
On Mon, Dec 19, 2011 at 18:58, Wolfgang Denk wrote: > > Try a known to be working (with current code) tool chain? > Dear Wolfgang, I can built other boards with the same toolchain. I think I know what I did wrong: #define CONFIG_SYS_UBOOT_BASE -1 #define CONFIG_SYS_TEXT_BASE -1 To get the preprocessor working I defined these two just with -1. These are used in the start.S of the arm1176 CPU. I have found the CONFIG_SYS_UBOOT_BASE address in the Medion source, but the CONFIG_SYS_TEXT_BASE is still missing. There is no documentation on this. Any hints? Michael ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] New Oxford Semiconductor board with assertion fail in linker
Dear Michael Kebe, In message you wrote: > > CONFIG_SYS_TEXT_BASE is still missing. There is no documentation on > this. Any hints? Check the old sources for a board specific config.mk file ... Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de In an infinite universe all things are possible, including the possi- bility that the universe does not exist. - Terry Pratchett, _The Dark Side of the Sun_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] MXS-NAND: Backport ecc.size from linux kernel
On 12/18/2011 11:50 AM, Marek Vasut wrote: > The ecc.size for mxs NAND driver is set to 1 in Linux kernel and to 512 in > U-Boot, which causes "ubi part" command malfunction due to wrong subpage size. > > Signed-off-by: Marek Vasut > Cc: Wolfgang Denk > Cc: Detlev Zundel > Cc: Stefan Roese > Cc: Scott Wood > Cc: Veli-Pekka Peltola > --- > drivers/mtd/nand/mxs_nand.c |2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/drivers/mtd/nand/mxs_nand.c b/drivers/mtd/nand/mxs_nand.c > index ce2a326..26778ac 100644 > --- a/drivers/mtd/nand/mxs_nand.c > +++ b/drivers/mtd/nand/mxs_nand.c > @@ -1105,7 +1105,7 @@ int board_nand_init(struct nand_chip *nand) > nand->ecc.layout= &fake_ecc_layout; > nand->ecc.mode = NAND_ECC_HW; > nand->ecc.bytes = 9; > - nand->ecc.size = 512; > + nand->ecc.size = 1; > > return 0; > ecc.size = 1 doesn't make sense -- this is the block size over which ecc is calculated. Where is this Linux driver? I don't see mxs_nand.c in Linux. What specifically is happening in "ubi part" with ecc.size = 512? -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Cannot access a FAT filesystem in an El-Torito partition
The U-Boot FAT driver appears to manually check for the existence of an MS-DOS partition table, even when CONFIG_DOS_PARTITION is present and working. As a result, it is not possible to use the FAT driver on an ISO9660 El-Torito boot volume, because it does not have a DOS MBR and does not pass the magic number check. It looks like the code in the FAT driver to check DOS MBRs is just legacy code from before libpart existed, and I would like to remove it, except several board configs seem to set CONFIG_CMD_FAT but do not set CONFIG_DOS_PARTITION: include/configs/dbau1x00.h include/configs/mv88f6281gtw_ge.h include/configs/hymod.h include/configs/LANTEC.h include/configs/gth2.h include/configs/dreamplug.h include/configs/lacie_kw.h include/configs/dockstar.h include/configs/omap3_evm_common.h include/configs/guruplug.h include/configs/rd6281a.h include/configs/ep8260.h include/configs/sheevaplug.h Can I just modify those board configs to set CONFIG_DOS_PARTITION and remove the duplicated FAT-specific partition-table probing code or is there something else I should do? Cheers, Kyle Moffett -- Curious about my work on the Debian powerpcspe port? I'm keeping a blog here: http://pureperl.blogspot.com/ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] MXS-NAND: Backport ecc.size from linux kernel
> On 12/18/2011 11:50 AM, Marek Vasut wrote: > > The ecc.size for mxs NAND driver is set to 1 in Linux kernel and to 512 > > in U-Boot, which causes "ubi part" command malfunction due to wrong > > subpage size. > > > > Signed-off-by: Marek Vasut > > Cc: Wolfgang Denk > > Cc: Detlev Zundel > > Cc: Stefan Roese > > Cc: Scott Wood > > Cc: Veli-Pekka Peltola > > --- > > > > drivers/mtd/nand/mxs_nand.c |2 +- > > 1 files changed, 1 insertions(+), 1 deletions(-) > > > > diff --git a/drivers/mtd/nand/mxs_nand.c b/drivers/mtd/nand/mxs_nand.c > > index ce2a326..26778ac 100644 > > --- a/drivers/mtd/nand/mxs_nand.c > > +++ b/drivers/mtd/nand/mxs_nand.c > > @@ -1105,7 +1105,7 @@ int board_nand_init(struct nand_chip *nand) > > > > nand->ecc.layout= &fake_ecc_layout; > > nand->ecc.mode = NAND_ECC_HW; > > nand->ecc.bytes = 9; > > > > - nand->ecc.size = 512; > > + nand->ecc.size = 1; > > > > return 0; > > ecc.size = 1 doesn't make sense -- this is the block size over which ecc > is calculated. And in a way it forces the subpage shift to be 0 ... we need to fix it in both later, but for this release, let's make it this way (in sync with linux). > > Where is this Linux driver? I don't see mxs_nand.c in Linux. drivers/mtd/nand/gpmi-nand/* > > What specifically is happening in "ubi part" with ecc.size = 512? The driver doesn\t support subpage writes. > > -Scott M ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Cannot access a FAT filesystem in an El-Torito partition
On Dec 19, 2011, at 15:21, Kyle Moffett wrote: > The U-Boot FAT driver appears to manually check for the existence of > an MS-DOS partition table, even when CONFIG_DOS_PARTITION is present > and working. > > As a result, it is not possible to use the FAT driver on an ISO9660 > El-Torito boot volume, because it does not have a DOS MBR and does > not pass the magic number check. > > It looks like the code in the FAT driver to check DOS MBRs is just > legacy code from before libpart existed, and I would like to remove > it, except several board configs seem to set CONFIG_CMD_FAT but do > not set CONFIG_DOS_PARTITION: > include/configs/dbau1x00.h > include/configs/mv88f6281gtw_ge.h > include/configs/hymod.h > include/configs/LANTEC.h > include/configs/gth2.h > include/configs/dreamplug.h > include/configs/lacie_kw.h > include/configs/dockstar.h > include/configs/omap3_evm_common.h > include/configs/guruplug.h > include/configs/rd6281a.h > include/configs/ep8260.h > include/configs/sheevaplug.h Nevermind, I just checked all of these and they do indirectly set CONFIG_DOS_PARTITION where necessary. > Can I just modify those board configs to set CONFIG_DOS_PARTITION > and remove the duplicated FAT-specific partition-table probing > code or is there something else I should do? I will be submitting a patch shortly. Cheers, Kyle Moffett -- Curious about my work on the Debian powerpcspe port? I'm keeping a blog here: http://pureperl.blogspot.com/ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] New Oxford Semiconductor board with assertion fail in linker
On Mon, Dec 19, 2011 at 21:01, Wolfgang Denk wrote: > Check the old sources for a board specific config.mk file ... There is this in the old include/configs/ox820.h: #define STATIC_CS0_BASE_PA 0x4100 #define CFG_NAND_BASE STATIC_CS0_BASE_PA Do you think that's the correct one? Michael ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] MXS-NAND: Backport ecc.size from linux kernel
On 12/19/2011 02:23 PM, Marek Vasut wrote: >> On 12/18/2011 11:50 AM, Marek Vasut wrote: >> What specifically is happening in "ubi part" with ecc.size = 512? > > The driver doesn\t support subpage writes. Is this meant to be a workaround for the NAND layer ignoring a driver setting NAND_NO_SUBPAGE_WRITE? I'd rather just fix that... -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] MXS-NAND: Backport ecc.size from linux kernel
> On 12/19/2011 02:23 PM, Marek Vasut wrote: > >> On 12/18/2011 11:50 AM, Marek Vasut wrote: > >> What specifically is happening in "ubi part" with ecc.size = 512? > > > > The driver doesn\t support subpage writes. > > Is this meant to be a workaround for the NAND layer ignoring a driver > setting NAND_NO_SUBPAGE_WRITE? I'd rather just fix that... Well it's like this in linux, it took me some time to find this out. I backported it, so probably. M ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Please pull u-boot-ti/next
Hello, The following changes since commit a69c1beefe8d1afb34c79a324a87a8951a793a59: Fabio Estevam (1): vision2: Fix checkpatch warning are available in the git repository at: git://git.denx.de/u-boot-ti.git next Christian Riesch (7): spl: display_options.o is required for SPI flash support in SPL sf: Add spi_boot() to allow booting from SPI flash in an SPL arm, davinci: Add SPL support for DA850 SoCs arm, da850evm: Add an SPL for SPI boot mkimage: Fix variable length header support arm, davinci: Add support for generating AIS images to the Makefile arm, davinci: Fix build warnings for cam_enc_4xx Stefano Babic (2): ARM: omap3: added common configuration for Technexion TAM3517 ARM: omap3: add support to Technexion twister board Thomas Weber (1): Devkit8000: Switch over to enable_gpmc_cs_config .gitignore |1 + MAINTAINERS |1 + Makefile| 13 + arch/arm/cpu/arm926ejs/davinci/Makefile |3 +- arch/arm/cpu/arm926ejs/davinci/spl.c| 35 +++- board/davinci/da8xxevm/da850evm.c |4 +- board/davinci/da8xxevm/u-boot-spl.lds | 73 ++ board/technexion/twister/Makefile | 38 +++ board/technexion/twister/twister.c | 116 + board/technexion/twister/twister.h | 411 +++ board/timll/devkit8000/devkit8000.c | 19 +- boards.cfg |1 + doc/README.SPL |1 + doc/README.davinci |9 + drivers/mtd/spi/Makefile|4 + drivers/mtd/spi/spi_spl_load.c | 58 + include/configs/da850evm.h | 87 +++ include/configs/tam3517-common.h| 361 +++ include/configs/twister.h | 54 include/spi_flash.h |3 + lib/Makefile|2 + tools/mkimage.c | 97 22 files changed, 1333 insertions(+), 58 deletions(-) create mode 100644 board/davinci/da8xxevm/u-boot-spl.lds create mode 100644 board/technexion/twister/Makefile create mode 100644 board/technexion/twister/twister.c create mode 100644 board/technexion/twister/twister.h create mode 100644 drivers/mtd/spi/spi_spl_load.c create mode 100644 include/configs/tam3517-common.h create mode 100644 include/configs/twister.h Thanks! -- Tom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-ti/next
Hi Tom, Le 19/12/2011 22:20, Tom Rini a écrit : Hello, The following changes since commit a69c1beefe8d1afb34c79a324a87a8951a793a59: Fabio Estevam (1): vision2: Fix checkpatch warning are available in the git repository at: git://git.denx.de/u-boot-ti.git next Christian Riesch (7): spl: display_options.o is required for SPI flash support in SPL sf: Add spi_boot() to allow booting from SPI flash in an SPL arm, davinci: Add SPL support for DA850 SoCs arm, da850evm: Add an SPL for SPI boot mkimage: Fix variable length header support arm, davinci: Add support for generating AIS images to the Makefile arm, davinci: Fix build warnings for cam_enc_4xx Stefano Babic (2): ARM: omap3: added common configuration for Technexion TAM3517 ARM: omap3: add support to Technexion twister board Thomas Weber (1): Devkit8000: Switch over to enable_gpmc_cs_config .gitignore |1 + MAINTAINERS |1 + Makefile| 13 + arch/arm/cpu/arm926ejs/davinci/Makefile |3 +- arch/arm/cpu/arm926ejs/davinci/spl.c| 35 +++- board/davinci/da8xxevm/da850evm.c |4 +- board/davinci/da8xxevm/u-boot-spl.lds | 73 ++ board/technexion/twister/Makefile | 38 +++ board/technexion/twister/twister.c | 116 + board/technexion/twister/twister.h | 411 +++ board/timll/devkit8000/devkit8000.c | 19 +- boards.cfg |1 + doc/README.SPL |1 + doc/README.davinci |9 + drivers/mtd/spi/Makefile|4 + drivers/mtd/spi/spi_spl_load.c | 58 + include/configs/da850evm.h | 87 +++ include/configs/tam3517-common.h| 361 +++ include/configs/twister.h | 54 include/spi_flash.h |3 + lib/Makefile|2 + tools/mkimage.c | 97 22 files changed, 1333 insertions(+), 58 deletions(-) create mode 100644 board/davinci/da8xxevm/u-boot-spl.lds create mode 100644 board/technexion/twister/Makefile create mode 100644 board/technexion/twister/twister.c create mode 100644 board/technexion/twister/twister.h create mode 100644 drivers/mtd/spi/spi_spl_load.c create mode 100644 include/configs/tam3517-common.h create mode 100644 include/configs/twister.h Thanks! Applied to u-boot-arm/next (to move onto master after 2011.12 is out), thanks! Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] sata_sil Driver on a PowerPC
I am using the 405EX "Kilauea" Evaluation Board from Applied Micro, and am trying to get a Silicon Image 3124 PCIe to SATA adaptor working on it. I have modified the Kilauea configuration to include the sata_sil driver with the following in the configuration file: #define CONFIG_CMD_SATA #define CONFIG_FSL_SATA 1 #define CONFIG_LIBATA 1 #define CONFIG_LBA481 #define CONFIG_SYS_SATA_MAX_DEVICE 2 #define CONFIG_MAC_PARTITION1 #define CONFIG_DOS_PARTITION1 #define CONFIG_ISO_PARTITION1 The PCIe identifies SI 3124, => pci 1.0.0 Scanning PCI devices on bus 1 BusDevFun VendorId DeviceId Device Class Sub-Class _ 01.00.00 0x1095 0x3132 Mass storage controller 0x80 but the driver won't initialize, => sata init pci_hose_phys_to_bus: invalid physical address SATA0 (No RDY) SATA1 (No RDY) When I boot to Linux and have full access to the drive, so it doesn't look like a hardware issue. I have been searching the net for a working configuration, but no luck so far. Has anyone successfully used this driver? BTW, I am using the v2011.12-rc1 build. John. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Cannot access a FAT filesystem in an El-Torito partition
Dear Kyle, In message <4edc0b2f-3d26-48a6-9cd9-0b40d6a01...@boeing.com> you wrote: > The U-Boot FAT driver appears to manually check for the existence of > an MS-DOS partition table, even when CONFIG_DOS_PARTITION is present > and working. > > As a result, it is not possible to use the FAT driver on an ISO9660 > El-Torito boot volume, because it does not have a DOS MBR and does > not pass the magic number check. > > It looks like the code in the FAT driver to check DOS MBRs is just > legacy code from before libpart existed, and I would like to remove > it, except several board configs seem to set CONFIG_CMD_FAT but do > not set CONFIG_DOS_PARTITION: > include/configs/dbau1x00.h > include/configs/mv88f6281gtw_ge.h > include/configs/hymod.h > include/configs/LANTEC.h > include/configs/gth2.h > include/configs/dreamplug.h > include/configs/lacie_kw.h > include/configs/dockstar.h > include/configs/omap3_evm_common.h > include/configs/guruplug.h > include/configs/rd6281a.h > include/configs/ep8260.h > include/configs/sheevaplug.h Some of these devices are well maintained, others are more or less dead and have long reached their (commercial, at least) EOL. It will probably be impossible to test on all of them. > Can I just modify those board configs to set CONFIG_DOS_PARTITION > and remove the duplicated FAT-specific partition-table probing > code or is there something else I should do? The best you can do is probbaly 1) provide an easy to reproduce test case for the problem (for example including an image that can be put on a USB stick or an SDCard), and 2) submit a patch that implements your fix. Then at least the boards that are still alive can be tested. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Speculation is always more interesting than facts. - Terry Pratchett, _Making_Money_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] New Oxford Semiconductor board with assertion fail in linker
Dear Michael Kebe, In message you wrote: > On Mon, Dec 19, 2011 at 21:01, Wolfgang Denk wrote: > > Check the old sources for a board specific config.mk file ... > > There is this in the old include/configs/ox820.h: > > #define STATIC_CS0_BASE_PA 0x4100 > #define CFG_NAND_BASE STATIC_CS0_BASE_PA > > Do you think that's the correct one? No. As I mentioned, look for a config.mk file in the board directory, i. e. probably board/ox820/config.mk or similar. This should contain the definition of TEXT_BASE. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de For every complex problem, there is a solution that is simple, neat, and wrong. -- H. L. Mencken ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
