Re: [U-Boot] I apply to maintain S3C6400 board for u-boot
Dear Hongbo, In message <5007fbbf.7040...@gmail.com> you wrote: > > I get some information from MAINTAINERS file. I know The board of > S3C6400 is a orphaned board. Also I have not the board, But I have a > S3C6410 board in my hand. In my development u-boot for my board, I know > the S3C6410 replace the s3c6400, and they use the same arm1176 > architecture. So I think that I can help do a little thing for S3C6400's > u-boot. Thanks for volunteering. If you want to take over responsbility for a board (even an orphaned one) then please send a patch that adds you to the MAINTAINERS file. > In the recently, I send the patch serial of S3C6400. This patch > is very important for S3C64XX. It clear the old method to operate the > I/O port, and adopt the new SPL boot to reduce the code number. I expect > get the advice for this patch. But I wait for a long time, I do not know > who can help me to review this patch? who can merge this patch? Please don't be discouraged by missing comments - in general the rule is "No news is Good News", i. e. receiving no comments is often better than receiving a large number of deep-going change requests ;-) These boards use Samsung SoCs, so the Samsung custodian (Minkyu Kang, on cc:) is supposed to process these, but please note that the merge window is currently closed, which might explain for lack of comments. > If anyone believe me, I will continue to maintain the board, Maybe I > have some limitation, Such as I have a poor english. But I believe I > can keep the board can work normal in u-boot mainline, and I will reply > the email about S3C64xx CPU in time. Thanks you very much in advance. Your efforts are highly appreciated. 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 right is not what someone gives you; it's what no one can take from you. - Ramsey Clark ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Pull request: u-boot-net.git next
Dear Joe Hershberger, In message you wrote: > The following changes since commit 0878222fed3fafbfd0b1f2e5a6b2da90a81e910d: > Wolfgang Denk (1): > Merge branch 'next' of git://git.denx.de/u-boot-net into next > > are available in the git repository at: > > git://git.denx.de/u-boot-net.git next > > Tetsuyuki Kobayashi (1): > net: nfs: make NFS_TIMEOUT configurable > > benoit.thebaudeau@advans (2): > net: fec_mxc: Fix setting of RCR for xMII > net: fec_mxc: Fix MDC for xMII > > README|7 +++ > drivers/net/fec_mxc.c | 10 -- > net/nfs.c |6 +- > 3 files changed, 16 insertions(+), 7 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 The one who says it cannot be done should never interrupt the one who is doing it. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: armv7: add compile option -mno-unaligned-access if available
Hi Mike, On Thu, 19 Jul 2012 10:27:07 -0400, Mike Frysinger wrote: > On Thursday 19 July 2012 02:28:05 Albert ARIBAUD wrote: > > On Thu, 19 Jul 2012 00:29:23 -0400, Mike Frysinger wrote: > > > On Monday 02 July 2012 12:14:40 Måns Rullgård wrote: > > > > It's slightly more complicated than that. Data can be misaligned for a > > > > variety of reasons: > > > > > > > > 1. Errors in software. > > > > 2. Specified by a file format or communication protocol. > > > > 3. Deliberately misaligned by the compiler. > > > > > > > > Misaligned data of type 1 should of course be fixed properly, not > > > > worked around in any way. > > > > > > it's also a reliability aspect. people don't write bug free software, > > > not bug free protocols, nor bug free compilers. when misalignment does > > > happen in the field, it's a hell of a lot better if the software > > > continued to execute correctly rather than randomly triggered an > > > exception. > > > > Nitpick: this is robustness, not reliability. > > useless pedantry: by increasing robustness, the system is more reliable Your description confirms that robustness and reliability are not equivalent, thereby goes against your statement about pedantry... :) > > That being said, yes, this robustness is desirable when you do not control > > all of the SW running on the product; Linux, for instance, will have to > > execute processes which were built with any old (or new) compiler > > settings, thus the Linux folks have to make sure the kernel won't fail > > running those. > > > > But the only uncontrolled SW U-Boot runs is its payload -- typically the > > kernel image -- which are usually very cautious in what they assume they > > can do, thus are unlikely to perform unaligned accesses. > > it isn't just that. there is no way you can guarantee both the linux kernel > and u-boot code bases themselves are perfect. in fact, it's even worse when > these are the ones that get tripped up because it means your system > resets/hardlocks/kills a kitten. when doing driver development under the > linux kernel, we would come across parts of core stacks that lacked alignment > checking and would panic the system. sometimes it would always panic, other > times it depended on factors that made life worse: the compiler version > (newer > ones always like to pack/optimize better), the actual data stream, or the > execution paths. Correct; here I was considering the requirements / operating conditions for both projects, I was not considering development issues -- bugs during development happen (morethan they do in the field, hopefully). Do you mean you'd like to catch misalignments as early as possible, and would like to have both -munaligned-access and A=1 during dev? > > > simply search the kernel for get_unaligned then. there are plenty of > > > examples in there. granted, many apply to stacks that don't show up in > > > u-boot (yet?) such as bluetooth, wireless, and irda, but i'm pretty sure > > > TCP/IPv4 has a few edge cases too. > > > > I'll have a look, if only to lament that protocol are not what they used to > > be in the old days. :) > > > > Anyway: as I said: performing *controlled* unaligned accesses for external > > reasons other than bugs is fine with me. Having our own get_unaligned() in > > such places would be fine with me. > > i have no problem adding put/get_unaligned() to all the right places. that > makes perfect sense. but, as an orthogonal issue wrt ARMv7, i don't see any > problem enabling hardware functionality: it increases robustness (:P), > shrinks > the code base (all the get/put unaligned macros expand into a single memory > access as they no longer have to do alignment fixups in software), and speeds > up the runtime (a single unaligned memory access is always faster than > address > masking/multiple loads/bit shifting/etc... -- obviously this ignores > multimedia type code that does alignment adjustment at the start, then lets > of > memory accesses, then another adjustment at the end, but that's not what > we're > talking about here). I wouldn't care about the ARMv7 implementing explicit unaligned accesses with native instructions if it didn't mean it won't catch unwanted unaligned accesses any more, and thus such unalignments will be found in another context and will take some more time to trace back. > if you want to tell people that if they found an unaligned access in code > they > must fix that, then great. make them fix it. then once that bug has been > fixed, > let's merge the purely optimization patch that allows the hardware to do > unaligned accesses. My problem is that as long as people start configuring their HW and compiler to not care about unaligned accesses, they *won't* find such accesses when accidental, because nothing will tell them. Here's my suggestion: when building U-Boot as usual, strict aligment policy is enforced, i.e. -mno-unaligned-access and A=1, and for platforms th
Re: [U-Boot] [PULL] u-boot-usb/master
Dear Marek,
In message <201207191452.53818.ma...@denx.de> you wrote:
>
> please apply this into the current release. I'm hereby commiting seppuku.
PLEASE send such pull reqeusts to the mailing list, so everybody can
see it.
> The following changes since commit 66714b1a6df0a5a9f1656a6d4e6eea3c7ecdf7ae:
>
> Merge branch 'next' of git://git.denx.de/u-boot-video (2012-07-18 10:47:03
> +0200)
>
> are available in the git repository at:
>
>
> git://git.denx.de/u-boot-usb.git master
>
> for you to fetch changes up to 1b4bd0e66cd3b5124669c78bc968510b1040e9d9:
>
> usb_storage: fix ehci driver max transfer size (2012-07-18 14:46:19 +0200)
>
>
> Ilya Yanok (6):
> ehci-hcd: program asynclistaddr before every transfer
> ehci-hcd: fix external buffer cache handling
> usb: pass cache-aligned buffer to usb_get_descriptor()
> usb: check return value of submit_{control, bulk}_msg
> ehci-hcd: change debug() to printf() in case of errors
> smsc95xx: align buffers to cache line size
>
> Marek Vasut (1):
> common.h: Introduce DEFINE_CACHE_ALIGN_BUFFER
>
> Stefan Herbrechtsmeier (1):
> usb_storage: fix ehci driver max transfer size
>
> Tom Rini (2):
> ehci-omap: Do not call dcache_off from omap_ehci_hcd_init
> ehci-hcd.c, musb_core, usb.h: Add USB_DMA_MINALIGN define for cache
> alignment
>
> common/usb.c | 12
> common/usb_storage.c | 37 +++
> drivers/usb/eth/smsc95xx.c | 13 +
> drivers/usb/host/ehci-hcd.c | 96
> ---
> drivers/usb/host/ehci-omap.c |1 -
> drivers/usb/musb/musb_core.h |2 +-
> include/common.h | 21 +---
> include/usb.h| 10 ++
> 8 files changed, 117 insertions(+), 75 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
Substitute "damn" every time you're inclined to write "very"; your
editor will delete it and the writing will be just as it should be.
- Mark Twain
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] nds32: split common cache access from cpu into lib
Hi Marek and Mike, > sounds like we should rip all this cache stuff out of common.h and into > > like cache.h so we can document the API expectations. i think Wolfgang > > was against this before, but maybe that was just creating a header for > one > > specific cache macro and not all cache stuff ? > > Certainly this sounds good. We'd also be able to add some nice > instrumentation > while at that, to detect problematic cases with DEBUG enabled or so. The > cache > stuff is starting to get really crazy. > > Best regards, > Marek Vasut > Since this discussion hasn't been finished, and we haven't decide the final action about the new policy about cache.h and common.h. I'd like to pick this patch v2 for the coming release for fixing build error for board adp-ag102. What do you think? :-) -- Best regards, Macpaul Lin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] video: support exynos fimd driver for various exynos series
Hi, On Thu, 19 Jul 2012 10:30:44 +0900 Donghwa Lee wrote: > This patch support exynos fimd driver for various exynos series different from > existing it supports only exynos4 chip. > > Signed-off-by: Donghwa Lee > Signed-off-by: Kyungmin Park > --- > Changes for v1: > - moves exynos_fimd_get_base_offset() to exynos_fb.h Why? This function is used in exynos_fimd.c file only. Moving it to the header file will result in a warning when compiling files including exynos_fb.h. This function should be in exynos_fimd.c. Thanks, Anatolij ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] kirkwood: add support for Iomega iConnect board
Hi Prafulla,
On Thu, Jul 19, 2012 at 11:02:58PM -0700, Prafulla Wadaskar wrote:
> > board/iomega/iconnect/kwbimage.cfg | 165
> >
>
> Is this file (kwbimage.cfg) 100% clone from any existing file already
> mainlined?
No, but I did not check with all .cfg files. Should I?
> > + /* Multi-Purpose Pins Functionality configuration */
> > + u32 kwmpp_config[] = {
> > + MPP0_NF_IO2,
> > + MPP1_NF_IO3,
> > + MPP2_NF_IO4,
> > + MPP3_NF_IO5,
> > + MPP4_NF_IO6,
> > + MPP5_NF_IO7,
> > + MPP6_SYSRST_OUTn,
> > + MPP7_GPO,
> > + MPP8_TW_SDA,
> > + MPP9_TW_SCK,
> > + MPP10_UART0_TXD,
> > + MPP11_UART0_RXD,
> > + MPP12_GPO,
> > + MPP13_SD_CMD,
> > + MPP14_SD_D0,
> > + MPP15_SD_D1,
> > + MPP16_SD_D2,
> > + MPP17_SD_D3,
> > + MPP18_NF_IO0,
> > + MPP19_NF_IO1,
> > + MPP20_GE1_0,
> > + MPP21_GE1_1,
> > + MPP22_GE1_2,
> > + MPP23_GE1_3,
> > + MPP24_GE1_4,
> > + MPP25_GE1_5,
> > + MPP26_GE1_6,
> > + MPP27_GE1_7,
> > + MPP28_GPIO,
> > + MPP29_GPIO,
> > + MPP30_GE1_10,
> > + MPP31_GE1_11,
> > + MPP32_GE1_12,
> > + MPP33_GE1_13,
> > + MPP34_GE1_14,
> > + MPP35_GPIO,
> > + MPP36_AUDIO_SPDIFI,
> > + MPP37_AUDIO_SPDIFO,
> > + MPP38_GPIO,
> > + MPP39_TDM_SPI_CS0,
> > + MPP40_TDM_SPI_SCK,
> > + MPP41_GPIO,
> > + MPP42_GPIO,
> > + MPP43_GPIO,
> > + MPP44_GPIO,
> > + MPP45_GPIO,
> > + MPP46_GPIO,
> > + MPP47_GPIO,
> > + MPP48_GPIO,
> > + MPP49_GPIO,
> > + 0
> > + };
>
> As per your schematics, please document possible MPPs being used for what
> purpose.
I dont have schematics, but this values are proven to work. This patch
has been in OpenWrt for quite some time, this is updated and cleaner
version...
> > +#define CONFIG_IDENT_STRING" Iomega iConnect Wireless"
>
> The strings looks to be too long, is it possible to shorten it?
Would this be ok:
#define CONFIG_IDENT_STRING " Iomega iConnect"
> Reset other thinks looks okay to me.
Great.
Regards,
Luka
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2] i.MX: fsl_esdhc: allow use with cache enabled.
On 20/07/2012 07:35, Dirk Behme wrote: > Then > > http://lists.denx.de/pipermail/u-boot/2012-June/126097.html > > mentions "WD applied the cache stub patch already". > > So do we have this "cache stub patch" somewhere which fixes the issue > mentioned above? I'm not sure I've seen it ... It is done, but I see it is compiled only if USB is activated. We need a fix like: diff --git a/arch/powerpc/cpu/mpc85xx/Makefile b/arch/powerpc/cpu/mpc85xx/Makefile index 7d65aa7..34f6c54 100644 --- a/arch/powerpc/cpu/mpc85xx/Makefile +++ b/arch/powerpc/cpu/mpc85xx/Makefile @@ -131,7 +131,7 @@ COBJS += tlb.o COBJS += traps.o # Stub implementations of cache management functions for USB -COBJS-$(CONFIG_USB_EHCI) += cache.o +COBJS += cache.o SRCS := $(START:.o=.S) $(SOBJS:.o=.S) $(COBJS:.o=.c) OBJS := $(addprefix $(obj),$(SOBJS) $(COBJS)) I send a proper patch. Stefano -- = DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] MPC85XX: compile stub cache function
An empty flush_dcache_range() was added into MPC85xx to work with drivers shared with other architecture. However, it is compiled only if USB is set, but it is required for other drivers (FSL_ESDHC), too. Signed-off-by: Stefano Babic CC: Andy Fleming CC: Dirk Behme CC: Marek Vasut CC: Wolfgang Denk --- arch/powerpc/cpu/mpc85xx/Makefile |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/powerpc/cpu/mpc85xx/Makefile b/arch/powerpc/cpu/mpc85xx/Makefile index 7d65aa7..34f6c54 100644 --- a/arch/powerpc/cpu/mpc85xx/Makefile +++ b/arch/powerpc/cpu/mpc85xx/Makefile @@ -131,7 +131,7 @@ COBJS += tlb.o COBJS += traps.o # Stub implementations of cache management functions for USB -COBJS-$(CONFIG_USB_EHCI) += cache.o +COBJS += cache.o SRCS := $(START:.o=.S) $(SOBJS:.o=.S) $(COBJS:.o=.c) OBJS := $(addprefix $(obj),$(SOBJS) $(COBJS)) -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/2] powerpc: Stack Pointer must be 16 aligned
The PowerPC ABI mandates the SP to be 16 bytes aligned, make is so.
Signed-off-by: Joakim Tjernlund
---
arch/powerpc/lib/board.c |5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff --git arch/powerpc/lib/board.c arch/powerpc/lib/board.c
index d5b75e5..dc7cc40 100644
--- arch/powerpc/lib/board.c
+++ arch/powerpc/lib/board.c
@@ -521,9 +521,8 @@ void board_init_f(ulong bootflag)
addr_sp -= 16;
addr_sp &= ~0xF;
s = (ulong *) addr_sp;
- *s-- = 0;
- *s-- = 0;
- addr_sp = (ulong) s;
+ *s = 0; /* NULL Back Chain */
+ *--s = 0; /* NULL LR */
debug("Stack Pointer at: %08lx\n", addr_sp);
/*
--
1.7.3.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/2] mpc85xx: Initial SP alignment is wrong.
PowerPC mandates SP to be 16 bytes aligned. Furthermore, a stack frame is added, pointing to the reset vector which is just get in the way when gdb is walking the stack because the reset vector may not accessible depending on emulator settings. Also use a temp register so gdb doesn't pick up intermediate values. Signed-off-by: Joakim Tjernlund --- arch/powerpc/cpu/mpc85xx/start.S | 16 +--- 1 files changed, 5 insertions(+), 11 deletions(-) diff --git arch/powerpc/cpu/mpc85xx/start.S arch/powerpc/cpu/mpc85xx/start.S index 8d66cf1..8c75af9 100644 --- arch/powerpc/cpu/mpc85xx/start.S +++ arch/powerpc/cpu/mpc85xx/start.S @@ -848,18 +848,12 @@ version_string: .globl _start_cont _start_cont: /* Setup the stack in initial RAM,could be L2-as-SRAM or L1 dcache*/ - lis r1,CONFIG_SYS_INIT_RAM_ADDR@h - ori r1,r1,CONFIG_SYS_INIT_SP_OFFSET@l - + lis r2,(CONFIG_SYS_INIT_RAM_ADDR)@h + ori r2,r2,((CONFIG_SYS_INIT_SP_OFFSET-16)&~0xf)@l /* Align to 16 */ li r0,0 - stwur0,-4(r1) - stwur0,-4(r1) /* Terminate call chain */ - - stwur1,-8(r1) /* Save back chain and move SP */ - lis r0,RESET_VECTOR@h /* Address of reset vector */ - ori r0,r0,RESET_VECTOR@l - stwur1,-8(r1) /* Save back chain and move SP */ - stw r0,+12(r1) /* Save return addr (underflow vect) */ + stw r0,-4(r2) /* Store a NULL LR */ + stw r0,0(r2)/* Store a NULL Back Chain */ + mr r1,r2 /* Transfer to SP(r1) */ GET_GOT bl cpu_init_early_f -- 1.7.3.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v5] arm: rmobile: kzm9g: Add dummy member to struct sh73a0_rwdt
From: Tetsuyuki Kobayashi
Add dummy member to struct sh73a0_rwdt in sh73a0.h.
Without this, initializing watch dog timer goes wrong.
Signed-off-by: Tetsuyuki Kobayashi
---
Changes for v2:
- New
Changes for v3:
- No change
Changes for v4:
- No change
Changes for v5:
- remove volatile
arch/arm/include/asm/arch-rmobile/sh73a0.h |2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/include/asm/arch-rmobile/sh73a0.h
b/arch/arm/include/asm/arch-rmobile/sh73a0.h
index 2c0c8c6..39ed2c3 100644
--- a/arch/arm/include/asm/arch-rmobile/sh73a0.h
+++ b/arch/arm/include/asm/arch-rmobile/sh73a0.h
@@ -64,7 +64,9 @@
/* RWDT */
struct sh73a0_rwdt {
u16 rwtcnt0;/* 0x00 */
+ u16 dummy0; /* 0x02 */
u16 rwtcsra0; /* 0x04 */
+ u16 dummy1; /* 0x06 */
u16 rwtcsrb0; /* 0x08 */
};
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] i.MX28: bug fixes in PMU configuration code
On 19/07/2012 19:14, Marek Vasut wrote: > Dear Stathis Voukelatos, > >> Fixed some typos in the i.MX28 PMU code that sets up the VDDD >> and VDDIO power rails. In addition the VDDD and VDDIO brownout >> offset values should be divided by a step size before being >> programmed to the corresponding registers. >> >> Signed-off-by: Stathis Voukelatos >> Cc: Stefano Babic >> Cc: Marek Vasut > > Stefano, I think this should be applied. There are checkpatch errors that should be fixed before applying. Stathis, can you check them and resubmit ? Thanks. 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-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] kirkwood: add support for Iomega iConnect board
> -Original Message-
> From: Wojciech Dubowik [mailto:wojciech.dubo...@neratec.com]
> Sent: 20 July 2012 15:39
> To: Luka Perkov
> Cc: Prafulla Wadaskar; u-boot@lists.denx.de; t...@night-shade.org.uk
> Subject: Re: [PATCH v2] kirkwood: add support for Iomega iConnect
> board
>
> I have looked at original linux source from Mapower and added
> some description.
>
> I also don't have schematics...
>
> Br,
> Wojtek
>
> On 07/20/2012 10:53 AM, Luka Perkov wrote:
> > Hi Prafulla,
> >
> > On Thu, Jul 19, 2012 at 11:02:58PM -0700, Prafulla Wadaskar wrote:
> >>> board/iomega/iconnect/kwbimage.cfg | 165
> >>>
> >> Is this file (kwbimage.cfg) 100% clone from any existing file
> already mainlined?
> > No, but I did not check with all .cfg files. Should I?
Yes, if you can, it would be good since we can avoid one complete file in this
patch.
> >
> >>> + /* Multi-Purpose Pins Functionality configuration */
> >>> + u32 kwmpp_config[] = {
> >>> + MPP0_NF_IO2,
> >>> + MPP1_NF_IO3,
> >>> + MPP2_NF_IO4,
> >>> + MPP3_NF_IO5,
> >>> + MPP4_NF_IO6,
> >>> + MPP5_NF_IO7,
> I think these are used for NAND
> >>> + MPP6_SYSRST_OUTn,
> Reset signal
> >> + MPP7_GPO,
> >> + MPP8_TW_SDA,
> >> + MPP9_TW_SCK,
> MPP8-9 I2C
> >>> + MPP10_UART0_TXD,
> >>> + MPP11_UART0_RXD,
> Serial
> >>> + MPP12_GPO,
> This should be MPP12_GPIO as it's a reset button
> >>> + MPP13_SD_CMD,
> >>> + MPP14_SD_D0,
> >>> + MPP15_SD_D1,
> >>> + MPP16_SD_D2,
> >>> + MPP17_SD_D3,
> >>> + MPP18_NF_IO0,
> >>> + MPP19_NF_IO1,
> >>> + MPP20_GE1_0,
> >>> + MPP21_GE1_1,
> >>> + MPP22_GE1_2,
> >>> + MPP23_GE1_3,
> >>> + MPP24_GE1_4,
> >>> + MPP25_GE1_5,
> >>> + MPP26_GE1_6,
> >>> + MPP27_GE1_7,
> >>> + MPP28_GPIO,
> >>> + MPP29_GPIO,
> >>> + MPP30_GE1_10,
> >>> + MPP31_GE1_11,
> >>> + MPP32_GE1_12,
> >>> + MPP33_GE1_13,
> >>> + MPP34_GE1_14,
> >>> + MPP35_GPIO,
> This is OTB button
> >>> + MPP36_AUDIO_SPDIFI,
> >>> + MPP37_AUDIO_SPDIFO,
> >>> + MPP38_GPIO,
> >>> + MPP39_TDM_SPI_CS0,
> >>> + MPP40_TDM_SPI_SCK,
> >>> + MPP41_GPIO,
> >>> + MPP42_GPIO,
> >>> + MPP43_GPIO,
> >>> + MPP44_GPIO,
> >>> + MPP45_GPIO,
> >>> + MPP46_GPIO,
> >>> + MPP47_GPIO,
> >>> + MPP48_GPIO,
> >>> + MPP49_GPIO,
> MPP41 => led brightness (default on)
> MPP42 => Blue power led
> MPP43 => Red power led
> MPP44-47 => USB Leds 1-4
> MPP48 => OTB Led
> MPP49 not used
Please leave those GPIO usage as comments for respective line
Leave the MPPs for standard peripheral.
> >>> + 0
> >>> + };
> >> As per your schematics, please document possible MPPs being used
> for what purpose.
> > I dont have schematics, but this values are proven to work. This
> patch
> > has been in OpenWrt for quite some time, this is updated and cleaner
> > version...
> >
> >>> +#define CONFIG_IDENT_STRING " Iomega iConnect Wireless"
> >> The strings looks to be too long, is it possible to shorten it?
> > Would this be ok:
> >
> > #define CONFIG_IDENT_STRING " Iomega iConnect"
That looks better (shorter) :-)
Regards...
Prafulla . . .
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] video: support exynos fimd driver for various exynos series
On 20 July 2012 17:28, Anatolij Gustschin wrote: > Hi, > > On Thu, 19 Jul 2012 10:30:44 +0900 > Donghwa Lee wrote: > >> This patch support exynos fimd driver for various exynos series different >> from >> existing it supports only exynos4 chip. >> >> Signed-off-by: Donghwa Lee >> Signed-off-by: Kyungmin Park >> --- >> Changes for v1: >> - moves exynos_fimd_get_base_offset() to exynos_fb.h > > Why? This function is used in exynos_fimd.c file only. Moving it > to the header file will result in a warning when compiling files > including exynos_fb.h. This function should be in exynos_fimd.c. > Good point : ) Donghwa misunderstood my opinion, maybe. I want to move this function to arch/arm/include/asm/arch-exynos/fb.h. not drivers/video/exynos_fb.h. Because define values and accessor function should be in same header file. 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
[U-Boot] [PATCH v2 2/5] ehci-hcd: Boost transfer speed
This patch takes advantage of the hardware EHCI qTD queuing mechanism to avoid
software overhead and to make transfers as fast as possible.
The only drawback is a call to memalign. However, this is fast compared to the
transfer timings, and the heap size to allocate is small, e.g. a little bit more
than 100 kB for a transfer length of 65535 packets of 512 bytes.
Tested on i.MX25 and i.MX35. In my test conditions, the speedup was about 15x
using page-aligned buffers, which is really appreciable when accessing large
files.
Signed-off-by: Benoît Thébaudeau
Cc: Marek Vasut
Cc: Ilya Yanok
Cc: Stefan Herbrechtsmeier
---
Changes for v2:
- Use DIV_ROUND_UP to make code more readable.
.../drivers/usb/host/ehci-hcd.c| 92 ++--
1 file changed, 63 insertions(+), 29 deletions(-)
diff --git u-boot-usb-1b4bd0e.orig/drivers/usb/host/ehci-hcd.c
u-boot-usb-1b4bd0e/drivers/usb/host/ehci-hcd.c
index 5b3b906..cf9ab92 100644
--- u-boot-usb-1b4bd0e.orig/drivers/usb/host/ehci-hcd.c
+++ u-boot-usb-1b4bd0e/drivers/usb/host/ehci-hcd.c
@@ -208,7 +208,8 @@ ehci_submit_async(struct usb_device *dev, unsigned long
pipe, void *buffer,
int length, struct devrequest *req)
{
ALLOC_ALIGN_BUFFER(struct QH, qh, 1, USB_DMA_MINALIGN);
- ALLOC_ALIGN_BUFFER(struct qTD, qtd, 3, USB_DMA_MINALIGN);
+ struct qTD *qtd;
+ int qtd_count = 0;
int qtd_counter = 0;
volatile struct qTD *vtd;
@@ -229,8 +230,23 @@ ehci_submit_async(struct usb_device *dev, unsigned long
pipe, void *buffer,
le16_to_cpu(req->value), le16_to_cpu(req->value),
le16_to_cpu(req->index));
+ if (req != NULL)/* SETUP + ACK */
+ qtd_count += 1 + 1;
+ if (length > 0 || req == NULL) {/* buffer */
+ if ((uint32_t)buffer & 4095)/* page-unaligned */
+ qtd_count += DIV_ROUND_UP(((uint32_t)buffer & 4095) +
+ length, (QT_BUFFER_CNT - 1) * 4096);
+ else/* page-aligned */
+ qtd_count += DIV_ROUND_UP(length, QT_BUFFER_CNT * 4096);
+ }
+ qtd = memalign(USB_DMA_MINALIGN, qtd_count * sizeof(struct qTD));
+ if (qtd == NULL) {
+ printf("unable to allocate TDs\n");
+ return -1;
+ }
+
memset(qh, 0, sizeof(struct QH));
- memset(qtd, 0, 3 * sizeof(*qtd));
+ memset(qtd, 0, qtd_count * sizeof(*qtd));
toggle = usb_gettoggle(dev, usb_pipeendpoint(pipe), usb_pipeout(pipe));
@@ -291,31 +307,46 @@ ehci_submit_async(struct usb_device *dev, unsigned long
pipe, void *buffer,
}
if (length > 0 || req == NULL) {
- /*
-* Setup request qTD (3.5 in ehci-r10.pdf)
-*
-* qt_next 03-00 H
-* qt_altnext . 07-04 H
-* qt_token ... 0B-08 H
-*
-* [ buffer, buffer_hi ] loaded with "buffer".
-*/
- qtd[qtd_counter].qt_next = cpu_to_hc32(QT_NEXT_TERMINATE);
- qtd[qtd_counter].qt_altnext = cpu_to_hc32(QT_NEXT_TERMINATE);
- token = (toggle << 31) |
- (length << 16) |
- ((req == NULL ? 1 : 0) << 15) |
- (0 << 12) |
- (3 << 10) |
- ((usb_pipein(pipe) ? 1 : 0) << 8) | (0x80 << 0);
- qtd[qtd_counter].qt_token = cpu_to_hc32(token);
- if (ehci_td_buffer(&qtd[qtd_counter], buffer, length) != 0) {
- printf("unable construct DATA td\n");
- goto fail;
- }
- /* Update previous qTD! */
- *tdp = cpu_to_hc32((uint32_t)&qtd[qtd_counter]);
- tdp = &qtd[qtd_counter++].qt_next;
+ uint8_t *buf_ptr = buffer;
+ int left_length = length;
+
+ do {
+ int xfr_bytes = min(left_length,
+ (QT_BUFFER_CNT * 4096 -
+((uint32_t)buf_ptr & 4095)) &
+ ~4095);
+
+ /*
+* Setup request qTD (3.5 in ehci-r10.pdf)
+*
+* qt_next 03-00 H
+* qt_altnext . 07-04 H
+* qt_token ... 0B-08 H
+*
+* [ buffer, buffer_hi ] loaded with "buffer".
+*/
+ qtd[qtd_counter].qt_next =
+ cpu_to_hc32(QT_NEXT_TERMINATE);
+ qtd[qtd_counter].qt_altnext =
+
Re: [U-Boot] [PATCH 1/2] common.h: Introduce DEFINE_CACHE_ALIGN_BUFFER
Dear Mike Frysinger, > On Saturday 07 July 2012 23:08:14 Marek Vasut wrote: > > +/* > > + * DEFINE_CACHE_ALIGN_BUFFER() is similar to ALLOC_CACHE_ALIGN_BUFFER, > > but it's + * purpose is to allow allocating aligned buffers outside of > > function scope. + * Usage of this macro shall be avoided or used with > > extreme care! + */ > > +#define DEFINE_CACHE_ALIGN_BUFFER(type, name, size) \ > > + static char __##name[roundup(size * sizeof(type), ARCH_DMA_MINALIGN)] \ > > + __aligned(ARCH_DMA_MINALIGN); \ > > + \ > > + static type *name = (type *)__##name; > > how is this any different from doing: > static __u8 foo[1234] __aligned(ARCH_DMA_MINALIGN); > -mike Does __aligned() align both start of the buffer downwards and end of it upwards ? Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 5/7] dfu:cmd: Support for DFU u-boot command
Dear Mike Frysinger, > On Wednesday 04 July 2012 10:39:20 Marek Vasut wrote: > > > Putting there the __func__ name would improve structure and speed up > > > finding right place. > > > > And if you want to use even __LINE__, look up __stringify patch in the ML > > archives ;-) > > ugh, no, let's not use __LINE__ anywhere other than debug(). it has no > business in code we ship as it is pointless bloated noise. Helps find out the problematic place in code ... > -mike Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 5/7] dfu:cmd: Support for DFU u-boot command
Dear Mike Frysinger,
> On Tuesday 03 July 2012 17:32:54 Marek Vasut wrote:
> > > +int do_dfu(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
> > > +{
> > > + char *str_env = NULL, *env_bkp = NULL;
> > > + static char *s = "dfu";
> > > + int ret = 0;
> > > +
> > > + if (argc < 3)
> > > + return CMD_RET_USAGE;
> > > +
> > > + str_env = getenv("dfu_alt_info");
> > > + if (str_env == NULL) {
> > > + printf("%s: \"dfu_alt_info\" env variable not defined!\n",
> > > +__func__);
> >
> > I was always curious if it's not possible to do something like
> >
> > puts(__func__ "rest of string");
> >
> > Maybe it'd help the overhead a bit? Certainly, it's beyond the scope of
> > this patchset, I'm just curious :)
>
> not anymore -- gcc disabled support for that sometime ago. and it's good
> they did as it causes more bloat than good. as soon as you do more than
> one statement, you get duplication. the string table will have:
> "some_func: rest of string"
> "some_func: boo"
> "some_func: another message"
> which takes up more space than:
> "some_func"
> "%s: rest of string"
> "%s: boo"
> "%s: another message"
Good knowing this. I'd expect gcc would build some trie in there to optimize
the
size.
> -mike
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/5] ehci-hcd: Boost transfer speed
Am 20.07.2012 13:26, schrieb Benoît Thébaudeau:
This patch takes advantage of the hardware EHCI qTD queuing mechanism to avoid
software overhead and to make transfers as fast as possible.
The only drawback is a call to memalign. However, this is fast compared to the
transfer timings, and the heap size to allocate is small, e.g. a little bit more
than 100 kB for a transfer length of 65535 packets of 512 bytes.
Tested on i.MX25 and i.MX35. In my test conditions, the speedup was about 15x
using page-aligned buffers, which is really appreciable when accessing large
files.
Signed-off-by: Benoît Thébaudeau
Cc: Marek Vasut
Cc: Ilya Yanok
Cc: Stefan Herbrechtsmeier
---
Changes for v2:
- Use DIV_ROUND_UP to make code more readable.
.../drivers/usb/host/ehci-hcd.c| 92 ++--
1 file changed, 63 insertions(+), 29 deletions(-)
diff --git u-boot-usb-1b4bd0e.orig/drivers/usb/host/ehci-hcd.c
u-boot-usb-1b4bd0e/drivers/usb/host/ehci-hcd.c
index 5b3b906..cf9ab92 100644
--- u-boot-usb-1b4bd0e.orig/drivers/usb/host/ehci-hcd.c
+++ u-boot-usb-1b4bd0e/drivers/usb/host/ehci-hcd.c
@@ -208,7 +208,8 @@ ehci_submit_async(struct usb_device *dev, unsigned long
pipe, void *buffer,
int length, struct devrequest *req)
{
ALLOC_ALIGN_BUFFER(struct QH, qh, 1, USB_DMA_MINALIGN);
- ALLOC_ALIGN_BUFFER(struct qTD, qtd, 3, USB_DMA_MINALIGN);
+ struct qTD *qtd;
+ int qtd_count = 0;
int qtd_counter = 0;
volatile struct qTD *vtd;
@@ -229,8 +230,23 @@ ehci_submit_async(struct usb_device *dev, unsigned long
pipe, void *buffer,
le16_to_cpu(req->value), le16_to_cpu(req->value),
le16_to_cpu(req->index));
+ if (req != NULL) /* SETUP + ACK */
+ qtd_count += 1 + 1;
+ if (length > 0 || req == NULL) { /* buffer */
+ if ((uint32_t)buffer & 4095)/* page-unaligned */
+ qtd_count += DIV_ROUND_UP(((uint32_t)buffer & 4095) +
+ length, (QT_BUFFER_CNT - 1) * 4096);
+ else/* page-aligned */
+ qtd_count += DIV_ROUND_UP(length, QT_BUFFER_CNT * 4096);
+ }
+ qtd = memalign(USB_DMA_MINALIGN, qtd_count * sizeof(struct qTD));
+ if (qtd == NULL) {
+ printf("unable to allocate TDs\n");
+ return -1;
+ }
+
memset(qh, 0, sizeof(struct QH));
- memset(qtd, 0, 3 * sizeof(*qtd));
+ memset(qtd, 0, qtd_count * sizeof(*qtd));
toggle = usb_gettoggle(dev, usb_pipeendpoint(pipe), usb_pipeout(pipe));
@@ -291,31 +307,46 @@ ehci_submit_async(struct usb_device *dev, unsigned long pipe, void *buffer,
}
if (length > 0 || req == NULL) {
- /*
-* Setup request qTD (3.5 in ehci-r10.pdf)
-*
-* qt_next 03-00 H
-* qt_altnext . 07-04 H
-* qt_token ... 0B-08 H
-*
-* [ buffer, buffer_hi ] loaded with "buffer".
-*/
- qtd[qtd_counter].qt_next = cpu_to_hc32(QT_NEXT_TERMINATE);
- qtd[qtd_counter].qt_altnext = cpu_to_hc32(QT_NEXT_TERMINATE);
- token = (toggle << 31) |
- (length << 16) |
- ((req == NULL ? 1 : 0) << 15) |
- (0 << 12) |
- (3 << 10) |
- ((usb_pipein(pipe) ? 1 : 0) << 8) | (0x80 << 0);
- qtd[qtd_counter].qt_token = cpu_to_hc32(token);
- if (ehci_td_buffer(&qtd[qtd_counter], buffer, length) != 0) {
- printf("unable construct DATA td\n");
- goto fail;
- }
- /* Update previous qTD! */
- *tdp = cpu_to_hc32((uint32_t)&qtd[qtd_counter]);
- tdp = &qtd[qtd_counter++].qt_next;
+ uint8_t *buf_ptr = buffer;
+ int left_length = length;
+
+ do {
+ int xfr_bytes = min(left_length,
+ (QT_BUFFER_CNT * 4096 -
+((uint32_t)buf_ptr & 4095)) &
+ ~4095);
Why you align the length to 4096?
+
+ /*
+* Setup request qTD (3.5 in ehci-r10.pdf)
+*
+* qt_next 03-00 H
+* qt_altnext . 07-04 H
+* qt_token ... 0B-08 H
+*
+* [ buffer, buffer_hi ] loaded with "buffer".
+*/
+ qtd[qtd_counter].qt_next =
+ cpu_to_hc32(QT_NEXT_TERMINATE);
+
Re: [U-Boot] [PATCH v2 1/2] kirkwood: implement kw_sdram_bs_set()
Dear Prafulla Wadaskar, [...] > > diff --git a/arch/arm/cpu/arm926ejs/kirkwood/dram.c > > b/arch/arm/cpu/arm926ejs/kirkwood/dram.c > > index 181b3e7..d938578 100644 > > --- a/arch/arm/cpu/arm926ejs/kirkwood/dram.c > > +++ b/arch/arm/cpu/arm926ejs/kirkwood/dram.c > > @@ -32,6 +32,12 @@ DECLARE_GLOBAL_DATA_PTR; > > > > #define KW_REG_CPUCS_WIN_BAR(x)(KW_REGISTER(0x1500) + (x * > > > > 0x08)) > > > > #define KW_REG_CPUCS_WIN_SZ(x) (KW_REGISTER(0x1504) + (x * > > > > 0x08)) > > Hi Gerlando > I have a full ack for this patch. > But I would like to ask you- > Since dram.c is going through this change and macros are being used in > stead of c-struct for DRAM register variables. This is being one of the > todo item pending from long time. > > Would you like to convert macros to c-struct definition in this file? Certainly, but let's get this applied first. [...] > > diff --git a/arch/arm/include/asm/arch-kirkwood/cpu.h > > b/arch/arm/include/asm/arch-kirkwood/cpu.h > > index d28c51a..807154e 100644 > > --- a/arch/arm/include/asm/arch-kirkwood/cpu.h > > +++ b/arch/arm/include/asm/arch-kirkwood/cpu.h > > @@ -159,6 +159,8 @@ void reset_cpu(unsigned long ignored); > > > > unsigned char get_random_hex(void); > > unsigned int kw_sdram_bar(enum memory_bank bank); > > unsigned int kw_sdram_bs(enum memory_bank bank); > > > > +void kw_sdram_bs_set(enum memory_bank bank, u32 size); > > + > > Please remove this additional line Well, maybe you can remove it in the application process since it's really one small thing? > > int kw_config_adr_windows(void); > > void kw_config_gpio(unsigned int gpp0_oe_val, unsigned int > > > > gpp1_oe_val, > > > > unsigned int gpp0_oe, unsigned int gpp1_oe); > > > > -- > > Regards... > Prafulla . . . > > > 1.7.1 Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] i.MX28: bug fixes in PMU configuration code
Dear Stefano Babic, > On 19/07/2012 19:14, Marek Vasut wrote: > > Dear Stathis Voukelatos, > > > >> Fixed some typos in the i.MX28 PMU code that sets up the VDDD > >> and VDDIO power rails. In addition the VDDD and VDDIO brownout > >> offset values should be divided by a step size before being > >> programmed to the corresponding registers. > >> > >> Signed-off-by: Stathis Voukelatos > >> Cc: Stefano Babic > >> Cc: Marek Vasut > > > > Stefano, I think this should be applied. > > There are checkpatch errors that should be fixed before applying. > Stathis, can you check them and resubmit ? Thanks. I can eventually resubmit if Stathis grew unhappy about the slow response time :-( Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] I apply to maintain S3C6400 board for u-boot
Hi Wolfgang Denk, On 07/20/2012 03:11 PM, Wolfgang Denk wrote: > Dear Hongbo, > > In message <5007fbbf.7040...@gmail.com> you wrote: >> >> I get some information from MAINTAINERS file. I know The board of >> S3C6400 is a orphaned board. Also I have not the board, But I have a >> S3C6410 board in my hand. In my development u-boot for my board, I know >> the S3C6410 replace the s3c6400, and they use the same arm1176 >> architecture. So I think that I can help do a little thing for S3C6400's >> u-boot. > > Thanks for volunteering. If you want to take over responsbility for a > board (even an orphaned one) then please send a patch that adds you to > the MAINTAINERS file. OK > >> In the recently, I send the patch serial of S3C6400. This patch >> is very important for S3C64XX. It clear the old method to operate the >> I/O port, and adopt the new SPL boot to reduce the code number. I expect >> get the advice for this patch. But I wait for a long time, I do not know >> who can help me to review this patch? who can merge this patch? > > Please don't be discouraged by missing comments - in general the rule > is "No news is Good News", i. e. receiving no comments is often better > than receiving a large number of deep-going change requests ;-) Good to know. > > These boards use Samsung SoCs, so the Samsung custodian (Minkyu Kang, > on cc:) is supposed to process these, but please note that the merge > window is currently closed, which might explain for lack of comments. Thanks for your explanation. Thanks, hongbo > >> If anyone believe me, I will continue to maintain the board, Maybe I >> have some limitation, Such as I have a poor english. But I believe I >> can keep the board can work normal in u-boot mainline, and I will reply >> the email about S3C64xx CPU in time. > > Thanks you very much in advance. Your efforts are highly appreciated. > > Best regards, > > Wolfgang Denk > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] kirkwood: add support for Iomega iConnect board
I have looked at original linux source from Mapower and added
some description.
I also don't have schematics...
Br,
Wojtek
On 07/20/2012 10:53 AM, Luka Perkov wrote:
Hi Prafulla,
On Thu, Jul 19, 2012 at 11:02:58PM -0700, Prafulla Wadaskar wrote:
board/iomega/iconnect/kwbimage.cfg | 165
Is this file (kwbimage.cfg) 100% clone from any existing file already mainlined?
No, but I did not check with all .cfg files. Should I?
+ /* Multi-Purpose Pins Functionality configuration */
+ u32 kwmpp_config[] = {
+ MPP0_NF_IO2,
+ MPP1_NF_IO3,
+ MPP2_NF_IO4,
+ MPP3_NF_IO5,
+ MPP4_NF_IO6,
+ MPP5_NF_IO7,
I think these are used for NAND
+ MPP6_SYSRST_OUTn,
Reset signal
+ MPP7_GPO,
+ MPP8_TW_SDA,
+ MPP9_TW_SCK,
MPP8-9 I2C
+ MPP10_UART0_TXD,
+ MPP11_UART0_RXD,
Serial
+ MPP12_GPO,
This should be MPP12_GPIO as it's a reset button
+ MPP13_SD_CMD,
+ MPP14_SD_D0,
+ MPP15_SD_D1,
+ MPP16_SD_D2,
+ MPP17_SD_D3,
+ MPP18_NF_IO0,
+ MPP19_NF_IO1,
+ MPP20_GE1_0,
+ MPP21_GE1_1,
+ MPP22_GE1_2,
+ MPP23_GE1_3,
+ MPP24_GE1_4,
+ MPP25_GE1_5,
+ MPP26_GE1_6,
+ MPP27_GE1_7,
+ MPP28_GPIO,
+ MPP29_GPIO,
+ MPP30_GE1_10,
+ MPP31_GE1_11,
+ MPP32_GE1_12,
+ MPP33_GE1_13,
+ MPP34_GE1_14,
+ MPP35_GPIO,
This is OTB button
+ MPP36_AUDIO_SPDIFI,
+ MPP37_AUDIO_SPDIFO,
+ MPP38_GPIO,
+ MPP39_TDM_SPI_CS0,
+ MPP40_TDM_SPI_SCK,
+ MPP41_GPIO,
+ MPP42_GPIO,
+ MPP43_GPIO,
+ MPP44_GPIO,
+ MPP45_GPIO,
+ MPP46_GPIO,
+ MPP47_GPIO,
+ MPP48_GPIO,
+ MPP49_GPIO,
MPP41 => led brightness (default on)
MPP42 => Blue power led
MPP43 => Red power led
MPP44-47 => USB Leds 1-4
MPP48 => OTB Led
MPP49 not used
+ 0
+ };
As per your schematics, please document possible MPPs being used for what
purpose.
I dont have schematics, but this values are proven to work. This patch
has been in OpenWrt for quite some time, this is updated and cleaner
version...
+#define CONFIG_IDENT_STRING" Iomega iConnect Wireless"
The strings looks to be too long, is it possible to shorten it?
Would this be ok:
#define CONFIG_IDENT_STRING " Iomega iConnect"
Reset other thinks looks okay to me.
Great.
Regards,
Luka
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] SMDK6400: Add MAINTAINERS entry
From: Zhong Hongbo Signed-off-by: Zhong Hongbo --- MAINTAINERS |5 - 1 files changed, 4 insertions(+), 1 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index fd0c65c..84413de 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -959,6 +959,10 @@ Vladimir Zapolskiy devkit3250 lpc32xx +Zhong Hongbo + + SMDK6400ARM1176 (S3C6400 SoC) + - Unknown / orphaned boards: @@ -971,7 +975,6 @@ Unknown / orphaned boards: imx31_phycore_eet i.MX31 Guennadi Liakhovetski / resigned mx31ads i.MX31 Guennadi Liakhovetski / resigned - SMDK6400 S3C6400 Guennadi Liakhovetski / resigned # # x86 Systems: # -- 1.7.5.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Pull request: ub-oot-arm/master
Hi Wolfgang, The following changes since commit 3ec81d758c09d6887a77a1b1259d044a2905bc8e: Merge branch 'master' of git://git.denx.de/u-boot-usb (2012-07-20 09:12:43 +0200) are available in the git repository at: git://git.denx.de/u-boot-arm master for you to fetch changes up to a21c65115bd95572cc80092a31b0e9ecb8710e9f: ARM: lib: Remove CONFIG_ARCH_CPU_INIT dependency (2012-07-20 14:24:08 +0200) Fabio Estevam (1): ARM: lib: Remove CONFIG_ARCH_CPU_INIT dependency SRICHARAN R (1): ARM: OMAP4: PANDA: Add rest of the USB module pads to essentials Tetsuyuki Kobayashi (1): arm: armv7: add compile option -mno-unaligned-access if available Zhong Hongbo (1): arm: Fix to mistake clean the memory space arch/arm/cpu/arm1136/start.S|8 --- arch/arm/cpu/arm1176/start.S|9 arch/arm/cpu/arm720t/start.S|8 --- arch/arm/cpu/arm920t/start.S|8 --- arch/arm/cpu/arm925t/start.S|8 --- arch/arm/cpu/arm946es/start.S |8 --- arch/arm/cpu/arm_intcm/start.S |8 --- arch/arm/cpu/armv7/config.mk|2 ++ arch/arm/cpu/armv7/start.S |8 --- arch/arm/cpu/ixp/start.S|8 --- arch/arm/cpu/lh7a40x/start.S|8 --- arch/arm/cpu/pxa/start.S|8 --- arch/arm/cpu/s3c44b0/start.S|8 --- arch/arm/cpu/sa1100/start.S |8 --- arch/arm/lib/board.c| 10 +++-- board/ti/panda/panda_mux_data.h | 44 +++ 16 files changed, 97 insertions(+), 64 deletions(-) Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/2] kirkwood: implement kw_sdram_bs_set()
Hi Marek, hi Prafulla, On 07/20/2012 01:40 PM, Marek Vasut wrote: > Dear Prafulla Wadaskar, > > [...] > >>> diff --git a/arch/arm/cpu/arm926ejs/kirkwood/dram.c >>> b/arch/arm/cpu/arm926ejs/kirkwood/dram.c >>> index 181b3e7..d938578 100644 >>> --- a/arch/arm/cpu/arm926ejs/kirkwood/dram.c >>> +++ b/arch/arm/cpu/arm926ejs/kirkwood/dram.c >>> @@ -32,6 +32,12 @@ DECLARE_GLOBAL_DATA_PTR; >>> >>> #define KW_REG_CPUCS_WIN_BAR(x)(KW_REGISTER(0x1500) + (x * >>> >>> 0x08)) >>> >>> #define KW_REG_CPUCS_WIN_SZ(x) (KW_REGISTER(0x1504) + (x * >>> >>> 0x08)) >> >> Hi Gerlando >> I have a full ack for this patch. >> But I would like to ask you- >> Since dram.c is going through this change and macros are being used in >> stead of c-struct for DRAM register variables. This is being one of the >> todo item pending from long time. >> >> Would you like to convert macros to c-struct definition in this file? > > Certainly, but let's get this applied first. > > [...] > I have done a v3 version of this patchserie with Prafullas inputs. Gerlando is not in these days. I'll send the updates soon... I have already tested them on km_kirkwood. Regards Holger ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 1/4] kirkwood: use c-struct for access to SDRAM addr decode registers
Remove the defines and do this with a C-struct.
Signed-off-by: Holger Brunck
cc: Prafulla Wadaskar
cc: Valentin Longchamp
cc: Gerlando Falauto
cc: Marek Vasut
---
changes for v3:
- new patch as requested on the ML
arch/arm/cpu/arm926ejs/kirkwood/dram.c | 23 +--
1 files changed, 17 insertions(+), 6 deletions(-)
diff --git a/arch/arm/cpu/arm926ejs/kirkwood/dram.c
b/arch/arm/cpu/arm926ejs/kirkwood/dram.c
index 181b3e7..1c5faab 100644
--- a/arch/arm/cpu/arm926ejs/kirkwood/dram.c
+++ b/arch/arm/cpu/arm926ejs/kirkwood/dram.c
@@ -30,20 +30,29 @@
DECLARE_GLOBAL_DATA_PTR;
-#define KW_REG_CPUCS_WIN_BAR(x)(KW_REGISTER(0x1500) + (x *
0x08))
-#define KW_REG_CPUCS_WIN_SZ(x) (KW_REGISTER(0x1504) + (x * 0x08))
+struct kw_sdram_bank {
+ u32 win_bar;
+ u32 win_sz;
+};
+
+struct kw_sdram_addr_dec {
+ struct kw_sdram_banksdram_bank[4];
+};
+
/*
* kw_sdram_bar - reads SDRAM Base Address Register
*/
u32 kw_sdram_bar(enum memory_bank bank)
{
+ struct kw_sdram_addr_dec *base =
+ (struct kw_sdram_addr_dec *)KW_REGISTER(0x1500);
u32 result = 0;
- u32 enable = 0x01 & readl(KW_REG_CPUCS_WIN_SZ(bank));
+ u32 enable = 0x01 & readl(&base->sdram_bank[bank].win_sz);
if ((!enable) || (bank > BANK3))
return 0;
- result = readl(KW_REG_CPUCS_WIN_BAR(bank));
+ result = readl(&base->sdram_bank[bank].win_bar);
return result;
}
@@ -52,12 +61,14 @@ u32 kw_sdram_bar(enum memory_bank bank)
*/
u32 kw_sdram_bs(enum memory_bank bank)
{
+ struct kw_sdram_addr_dec *base =
+ (struct kw_sdram_addr_dec *)KW_REGISTER(0x1500);
u32 result = 0;
- u32 enable = 0x01 & readl(KW_REG_CPUCS_WIN_SZ(bank));
+ u32 enable = 0x01 & readl(&base->sdram_bank[bank].win_sz);
if ((!enable) || (bank > BANK3))
return 0;
- result = 0xff00 & readl(KW_REG_CPUCS_WIN_SZ(bank));
+ result = 0xff00 & readl(&base->sdram_bank[bank].win_sz);
result += 0x0100;
return result;
}
--
1.7.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 3/4] kirkwood: implement kw_sdram_size_adjust
From: Gerlando Falauto
Size of the SDRAM chips might differ between any two (otherwise
identical) instances of the same board. So add a function which reads
out the current ram size and set them in the SDRAM size register of
kirkwood.
Signed-off-by: Gerlando Falauto
Signed-off-by: Holger Brunck
cc: Prafulla Wadaskar
cc: Valentin Longchamp
cc: Marek Vasut
---
chages for v3:
- rename dram_size_fixup to kw_sdramsize_adjust and move them to
kirkwood/dram.c
changes for v2:
- rebase to current u-boot-marvell.git master branch
arch/arm/cpu/arm926ejs/kirkwood/dram.c | 11 +++
arch/arm/include/asm/arch-kirkwood/cpu.h |1 +
2 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/arch/arm/cpu/arm926ejs/kirkwood/dram.c
b/arch/arm/cpu/arm926ejs/kirkwood/dram.c
index 5e2f9d8..9f97964 100644
--- a/arch/arm/cpu/arm926ejs/kirkwood/dram.c
+++ b/arch/arm/cpu/arm926ejs/kirkwood/dram.c
@@ -97,6 +97,17 @@ u32 kw_sdram_bs(enum memory_bank bank)
return result;
}
+void kw_sdram_size_adjust(void)
+{
+ u32 size;
+
+ /* probe currently equipped RAM size */
+ size = get_ram_size((void *)kw_sdram_bar(0), kw_sdram_bs(0));
+
+ /* adjust SDRAM window size accordingly */
+ kw_sdram_bs_set(0, size);
+}
+
#ifndef CONFIG_SYS_BOARD_DRAM_INIT
int dram_init(void)
{
diff --git a/arch/arm/include/asm/arch-kirkwood/cpu.h
b/arch/arm/include/asm/arch-kirkwood/cpu.h
index d28c51a..128393c 100644
--- a/arch/arm/include/asm/arch-kirkwood/cpu.h
+++ b/arch/arm/include/asm/arch-kirkwood/cpu.h
@@ -159,6 +159,7 @@ void reset_cpu(unsigned long ignored);
unsigned char get_random_hex(void);
unsigned int kw_sdram_bar(enum memory_bank bank);
unsigned int kw_sdram_bs(enum memory_bank bank);
+void kw_sdram_size_adjust(void);
int kw_config_adr_windows(void);
void kw_config_gpio(unsigned int gpp0_oe_val, unsigned int gpp1_oe_val,
unsigned int gpp0_oe, unsigned int gpp1_oe);
--
1.7.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 4/4] arm/km: use kw_sdram_size_adjust to adjust SDRAM size
Some boards may differ only in the SDRAM size. This function allows to fix the size accordingly and we can use the same u-boot binary for both boards. Signed-off-by: Holger Brunck Signed-off-by: Gerlando Falauto cc: Prafulla Wadaskar cc: Valentin Longchamp cc: Marek Vasut --- chages for v3: - new patch board/keymile/km_arm/km_arm.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/board/keymile/km_arm/km_arm.c b/board/keymile/km_arm/km_arm.c index 2b2ca39..9a616fc 100644 --- a/board/keymile/km_arm/km_arm.c +++ b/board/keymile/km_arm/km_arm.c @@ -250,7 +250,7 @@ int board_early_init_f(void) tmp = readl(KW_GPIO0_BASE + 4); writel(tmp & (~KM_KIRKWOOD_SOFT_I2C_GPIOS) , KW_GPIO0_BASE + 4); #endif - + kw_sdram_size_adjust(); kirkwood_mpp_conf(kwmpp_config, NULL); return 0; } -- 1.7.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 2/4] kirkwood: implement kw_sdram_bs_set()
From: Gerlando Falauto
Some boards might be equipped with different SDRAM configurations.
When that is the case, CPU CS Window Size Register (CS[0]n Size)
should be set to the biggest value through board.cfg file; then its
value can be fixed at runtime according to the detected SDRAM size.
Therefore, implement kw_sdram_bs_set().
Signed-off-by: Gerlando Falauto
Signed-off-by: Holger Brunck
cc: Prafulla Wadaskar
cc: Valentin Longchamp
cc: Marek Vasut
---
changes for v3:
- remove reviewed by, because there are some chages in
- use c-struct instead of defines
- make kw_sdram_bs_set static
changes for v2:
- added Reviewed-by: Marek Vasut
arch/arm/cpu/arm926ejs/kirkwood/dram.c | 24
1 files changed, 24 insertions(+), 0 deletions(-)
diff --git a/arch/arm/cpu/arm926ejs/kirkwood/dram.c
b/arch/arm/cpu/arm926ejs/kirkwood/dram.c
index 1c5faab..5e2f9d8 100644
--- a/arch/arm/cpu/arm926ejs/kirkwood/dram.c
+++ b/arch/arm/cpu/arm926ejs/kirkwood/dram.c
@@ -39,6 +39,11 @@ struct kw_sdram_addr_dec {
struct kw_sdram_banksdram_bank[4];
};
+#define KW_REG_CPUCS_WIN_ENABLE(1 << 0)
+#define KW_REG_CPUCS_WIN_WR_PROTECT(1 << 1)
+#define KW_REG_CPUCS_WIN_WIN0_CS(x)(((x) & 0x3) << 2)
+#define KW_REG_CPUCS_WIN_SIZE(x) (((x) & 0xff) << 24)
+
/*
* kw_sdram_bar - reads SDRAM Base Address Register
*/
@@ -57,6 +62,25 @@ u32 kw_sdram_bar(enum memory_bank bank)
}
/*
+ * kw_sdram_bs_set - writes SDRAM Bank size
+ */
+static void kw_sdram_bs_set(enum memory_bank bank, u32 size)
+{
+ struct kw_sdram_addr_dec *base =
+ (struct kw_sdram_addr_dec *)KW_REGISTER(0x1500);
+ /* Read current register value */
+ u32 reg = readl(&base->sdram_bank[bank].win_sz);
+
+ /* Clear window size */
+ reg &= ~KW_REG_CPUCS_WIN_SIZE(0xFF);
+
+ /* Set new window size */
+ reg |= KW_REG_CPUCS_WIN_SIZE((size - 1) >> 24);
+
+ writel(reg, &base->sdram_bank[bank].win_sz);
+}
+
+/*
* kw_sdram_bs - reads SDRAM Bank size
*/
u32 kw_sdram_bs(enum memory_bank bank)
--
1.7.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Unable to power the USB Keyboard on u-boot
Dear All, I am trying to use "usb keyboard" on u-boot. I am using the u-boot stack which was shared by you. Can you help me to know where problem is going. I am sending some of debug prints which i found on my "Beagle board xM". I have connected usb mouse and usb keyboard on same side of port, here usb mouse lights up but the keyboard does not powers on. Both keyboard and Mouse are from logitech. Please help me to make this up as i have scheduled demo. /* usb reset */ OMAP3 beagleboard.org # usb reset (Re)start USB... USB: Initializing OMAP EHCI OMAP UHH_REVISION 0x10 OMAP EHCI init done Register 1313 NbrPorts 3 USB EHCI 1.00 scanning bus for devices... New Device 0 New Device 1 New Device 2 New Device 3 New Device 4 5 USB Device(s) found USB KBD: found set protocol... USB KBD: found set idle... USB KBD: enable interrupt pipe... USB KBD: found set up device. USB KBD: register. usb_kbd_dev.name- usbkbd before stdio register clone _dev->name-usbkbd,dev->name-usbkbd clone _dev->flag- 8003 in stdio register,usb_kbd_dev.name- usbkbd After stdio register before strcmp stdin name- serial After strcmp stdin name- serial before over write before console assign before error test scan end scanning bus for storage devices... 0 Storage Device(s) found scanning bus for ethernet devices... Warning: failed to set MAC address 1 Ethernet Device(s) found OMAP3 beagleboard.org # /*/ /*** coninfo **/ OMAP3 beagleboard.org # coninfo List of available devices: serial 8003 SIO stdout stderr usbtty 0003 .IO usbkbd 8003 SIO stdin OMAP3 beagleboard.org # ---> here i am able to switch the console using "setenv stdin usbkbd" but No power on keyboard does not help. /**/ / usb info ***/ OMAP3 beagleboard.org# usb info 1: Hub, USB Revision 2.0 - u-boot EHCI Host Controller - Class: Hub - PacketSize: 64 Configurations: 1 - Vendor: 0x Product 0x Version 1.0 Configuration: 1 - Interfaces: 1 Self Powered 0mA Interface: 0 - Alternate Setting 0, Endpoints: 1 - Class Hub - Endpoint 1 In Interrupt MaxPacket 8 Interval 255ms 2: Hub, USB Revision 2.0 - Class: Hub - PacketSize: 64 Configurations: 1 - Vendor: 0x0424 Product 0x9514 Version 2.0 Configuration: 1 - Interfaces: 1 Self Powered Remote Wakeup 2mA Interface: 0 - Alternate Setting 0, Endpoints: 1 - Class Hub - Endpoint 1 In Interrupt MaxPacket 1 Interval 12ms - Endpoint 1 In Interrupt MaxPacket 1 Interval 12ms 3: Vendor specific, USB Revision 2.0 - Class: Vendor specific - PacketSize: 64 Configurations: 1 - Vendor: 0x0424 Product 0xec00 Version 2.0 Configuration: 1 - Interfaces: 1 Self Powered Remote Wakeup 2mA Interface: 0 - Alternate Setting 0, Endpoints: 3 - Class Vendor specific - Endpoint 1 In Bulk MaxPacket 512 - Endpoint 2 Out Bulk MaxPacket 512 - Endpoint 3 In Interrupt MaxPacket 16 Interval 4ms 4: Human Interface, USB Revision 1.10 - LITEON Technology USB Multimedia Keyboard - Class: (from Interface) Human Interface - PacketSize: 8 Configurations: 1 - Vendor: 0x046d Product 0xc312 Version 1.1 Configuration: 1 - Interfaces: 1 Bus Powered Remote Wakeup 70mA Interface: 0 - Alternate Setting 0, Endpoints: 1 - Class Human Interface, Subclass: Boot Keyboard - Endpoint 1 In Interrupt MaxPacket 8 Interval 24ms 5: Human Interface, USB Revision 2.0 - Logitech USB Optical Mouse - Class: (from Interface) Human Interface - PacketSize: 8 Configurations: 1 - Vendor: 0x046d Product 0xc018 Version 67.1 Configuration: 1 - Interfaces: 1 Bus Powered Remote Wakeup 100mA Interface: 0 - Alternate Setting 0, Endpoints: 1 - Class Human Interface, Subclass: Boot Mouse - Endpoint 1 In Interrupt MaxPacket 5 Interval 10ms OMAP3 beagleboard.org # // Thanks & Regards Atul Kumar ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] SMDK6400: Add MAINTAINERS entry
From: Zhong Hongbo Signed-off-by: Zhong Hongbo --- MAINTAINERS |5 - 1 files changed, 4 insertions(+), 1 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index fd0c65c..84413de 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -959,6 +959,10 @@ Vladimir Zapolskiy devkit3250 lpc32xx +Zhong Hongbo + + SMDK6400ARM1176 (S3C6400 SoC) + - Unknown / orphaned boards: @@ -971,7 +975,6 @@ Unknown / orphaned boards: imx31_phycore_eet i.MX31 Guennadi Liakhovetski / resigned mx31ads i.MX31 Guennadi Liakhovetski / resigned - SMDK6400 S3C6400 Guennadi Liakhovetski / resigned # # x86 Systems: # -- 1.7.5.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Need help to get u-boot running on the taskit stamp9g20
On Wed, Jul 18, 2012 at 03:21:00PM +0200, Markus Hubig wrote: > Hmm OK I disabled the watchdog and enabled debugging and now this > is what I get at the first boot after flashing: > > | RomBOOT > | > | > | U-Boot 2012.04.01-3-gab465ef-dirty (Jul 18 2012 - 15:08:22) > | > | U-Boot code: 23F0 -> 23F30130 BSS: -> 23F71E28 > | CPU: AT91SAM9G20 > | Crystal frequency: 18.432 MHz > | CPU clock: 396.288 MHz > | Master clock : 132.096 MHz > | Starting dram_init! > | dram_init finished! > | monitor len: 00071E28 > | ramsize: 0400 > | Top of RAM usable for U-Boot at: 2400 > | Reserving 455k for U-Boot at: 23f8e000 > | Reserving 640k for malloc() at: 23eee000 > | Reserving 36 Bytes for Board Info at: 23eedfdc > | Reserving 144 Bytes for Global Data at: 23eedf4c > | New Stack Pointer is: 23eedf40 > | RAM Configuration: > | Bank #0: 2000 64 MiB > | relocation Offset is: 0008e000 > | WARNING: Caches not enabled > | monitor flash len: 00035750 > | Starting board_init! > | Starting stamp9G20_nand_hw_init! > | stamp9G20_nand_hw_init finished! > | Starting stamp9G20_macb_hw_init! > | stamp9G20_macb_hw_init finished! > | board_init finished! > | Now running in RAM - U-Boot at: 23f8e000 > > The red LED is on and I can't input anything. OK now I managed to plug a JTAG Adapter with OpenOCD to the PortuxG20. But what now? How can I find out where I stuck? Cheers, Markus ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/5] ehci-hcd: Boost transfer speed
On Friday 20 July 2012 13:37:37 Stefan Herbrechtsmeier wrote: > Am 20.07.2012 13:26, schrieb Benoît Thébaudeau: > > + int xfr_bytes = min(left_length, > > + (QT_BUFFER_CNT * 4096 - > > +((uint32_t)buf_ptr & 4095)) & > > + ~4095); > Why you align the length to 4096? It's to guarantee that each transfer length is a multiple of the max packet length. Otherwise, early short packets are issued, which breaks the transfer and results in time-out error messages. Regards, Benoît ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 1/9] FAT: cosmetic: Remove extra spaces
Remove spaces before opening parentheses in function calls.
Signed-off-by: Benoît Thébaudeau
Cc: Wolfgang Denk
---
Changes for v2:
- New patch for this version of the series.
.../fs/fat/fat.c | 44 ++--
1 file changed, 21 insertions(+), 23 deletions(-)
diff --git u-boot-66714b1.orig/fs/fat/fat.c u-boot-66714b1/fs/fat/fat.c
index bc46cc5..9f83572 100644
--- u-boot-66714b1.orig/fs/fat/fat.c
+++ u-boot-66714b1/fs/fat/fat.c
@@ -37,7 +37,7 @@
/*
* Convert a string to lowercase.
*/
-static void downcase (char *str)
+static void downcase(char *str)
{
while (*str != '\0') {
TOLOWER(*str);
@@ -62,7 +62,7 @@ static int disk_read(__u32 block, __u32 nr_blocks, void *buf)
cur_part_info.start + block, nr_blocks, buf);
}
-int fat_register_device (block_dev_desc_t * dev_desc, int part_no)
+int fat_register_device(block_dev_desc_t * dev_desc, int part_no)
{
ALLOC_CACHE_ALIGN_BUFFER(unsigned char, buffer, dev_desc->blksz);
@@ -127,7 +127,7 @@ int fat_register_device (block_dev_desc_t * dev_desc, int
part_no)
* Get the first occurence of a directory delimiter ('/' or '\') in a string.
* Return index into string if found, -1 otherwise.
*/
-static int dirdelim (char *str)
+static int dirdelim(char *str)
{
char *start = str;
@@ -142,7 +142,7 @@ static int dirdelim (char *str)
/*
* Extract zero terminated short name from a directory entry.
*/
-static void get_name (dir_entry *dirent, char *s_name)
+static void get_name(dir_entry *dirent, char *s_name)
{
char *ptr;
@@ -171,7 +171,7 @@ static void get_name (dir_entry *dirent, char *s_name)
* Get the entry at index 'entry' in a FAT (12/16/32) table.
* On failure 0x00 is returned.
*/
-static __u32 get_fatent (fsdata *mydata, __u32 entry)
+static __u32 get_fatent(fsdata *mydata, __u32 entry)
{
__u32 bufnum;
__u32 off16, offset;
@@ -270,8 +270,7 @@ static __u32 get_fatent (fsdata *mydata, __u32 entry)
* Return 0 on success, -1 otherwise.
*/
static int
-get_cluster (fsdata *mydata, __u32 clustnum, __u8 *buffer,
-unsigned long size)
+get_cluster(fsdata *mydata, __u32 clustnum, __u8 *buffer, unsigned long size)
{
__u32 idx = 0;
__u32 startsect;
@@ -317,8 +316,8 @@ get_cluster (fsdata *mydata, __u32 clustnum, __u8 *buffer,
* Return the number of bytes read or -1 on fatal errors.
*/
static long
-get_contents (fsdata *mydata, dir_entry *dentptr, __u8 *buffer,
- unsigned long maxsize)
+get_contents(fsdata *mydata, dir_entry *dentptr, __u8 *buffer,
+unsigned long maxsize)
{
unsigned long filesize = FAT2CPU32(dentptr->size), gotsize = 0;
unsigned int bytesperclust = mydata->clust_size * mydata->sect_size;
@@ -397,7 +396,7 @@ getit:
* starting at l_name[*idx].
* Return 1 if terminator (zero byte) is found, 0 otherwise.
*/
-static int slot2str (dir_slot *slotptr, char *l_name, int *idx)
+static int slot2str(dir_slot *slotptr, char *l_name, int *idx)
{
int j;
@@ -433,8 +432,8 @@ __u8 get_vfatname_block[MAX_CLUSTSIZE]
__aligned(ARCH_DMA_MINALIGN);
static int
-get_vfatname (fsdata *mydata, int curclust, __u8 *cluster,
- dir_entry *retdent, char *l_name)
+get_vfatname(fsdata *mydata, int curclust, __u8 *cluster,
+dir_entry *retdent, char *l_name)
{
dir_entry *realdent;
dir_slot *slotptr = (dir_slot *)retdent;
@@ -516,7 +515,7 @@ get_vfatname (fsdata *mydata, int curclust, __u8 *cluster,
}
/* Calculate short name checksum */
-static __u8 mkcksum (const char *str)
+static __u8 mkcksum(const char *str)
{
int i;
@@ -537,9 +536,9 @@ static __u8 mkcksum (const char *str)
__u8 get_dentfromdir_block[MAX_CLUSTSIZE]
__aligned(ARCH_DMA_MINALIGN);
-static dir_entry *get_dentfromdir (fsdata *mydata, int startsect,
- char *filename, dir_entry *retdent,
- int dols)
+static dir_entry *get_dentfromdir(fsdata *mydata, int startsect,
+ char *filename, dir_entry *retdent,
+ int dols)
{
__u16 prevcksum = 0x;
__u32 curclust = START(retdent);
@@ -699,7 +698,7 @@ static dir_entry *get_dentfromdir (fsdata *mydata, int
startsect,
* Read boot sector and volume info from a FAT filesystem
*/
static int
-read_bootsectandvi (boot_sector *bs, volume_info *volinfo, int *fatsize)
+read_bootsectandvi(boot_sector *bs, volume_info *volinfo, int *fatsize)
{
__u8 *block;
volume_info *vistart;
@@ -716,7 +715,7 @@ read_bootsectandvi (boot_sector *bs, volume_info *volinfo,
int *fatsize)
return -1;
}
- if (disk_read (0, 1, block) < 0) {
+ if (disk_read(0, 1, block) < 0) {
debug("Error: reading block\n");
goto fail;
}
@@ -770,8 +769,7 @@ __u8
[U-Boot] [PATCH v2 2/8] FAT: get_fatent: Fix FAT boundary check
startblock must be taken into account in order not to read past the end of the FAT. Signed-off-by: Benoît Thébaudeau Cc: Wolfgang Denk --- Changes for v2: - Patch renumbering because of the new v2 1/8. - Possible code style changes due to the new v2 1/8. .../fs/fat/fat.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git u-boot-66714b1.orig/fs/fat/fat.c u-boot-66714b1/fs/fat/fat.c index 9f83572..87a1623 100644 --- u-boot-66714b1.orig/fs/fat/fat.c +++ u-boot-66714b1/fs/fat/fat.c @@ -207,8 +207,8 @@ static __u32 get_fatent(fsdata *mydata, __u32 entry) __u32 fatlength = mydata->fatlength; __u32 startblock = bufnum * FATBUFBLOCKS; - if (getsize > fatlength) - getsize = fatlength; + if (startblock + getsize > fatlength) + getsize = fatlength - startblock; fatlength *= mydata->sect_size; /* We want it in bytes now */ startblock += mydata->fat_sect; /* Offset from start of disk */ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 3/8] FAT: cosmetic: Remove useless assignment
fatlength is not used after this assignment, so it is useless and can be
removed.
Signed-off-by: Benoît Thébaudeau
Cc: Wolfgang Denk
---
Changes for v2:
- Patch renumbering because of the new v2 1/8.
- Possible code style changes due to the new v2 1/8.
.../fs/fat/fat.c |1 -
1 file changed, 1 deletion(-)
diff --git u-boot-66714b1.orig/fs/fat/fat.c u-boot-66714b1/fs/fat/fat.c
index 87a1623..48c8844 100644
--- u-boot-66714b1.orig/fs/fat/fat.c
+++ u-boot-66714b1/fs/fat/fat.c
@@ -210,7 +210,6 @@ static __u32 get_fatent(fsdata *mydata, __u32 entry)
if (startblock + getsize > fatlength)
getsize = fatlength - startblock;
- fatlength *= mydata->sect_size; /* We want it in bytes now */
startblock += mydata->fat_sect; /* Offset from start of disk */
if (disk_read(startblock, getsize, bufptr) < 0) {
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 4/8] FAT: Fix redundant sector read
With the previous code, the remaining prefetched sectors were read again after
each sector. With this patch, each sector is read only once, thus making the
prefetch useful.
Signed-off-by: Benoît Thébaudeau
Cc: Wolfgang Denk
---
Changes for v2:
- Patch renumbering because of the new v2 1/8.
- Possible code style changes due to the new v2 1/8.
.../fs/fat/fat.c | 59 +++-
1 file changed, 33 insertions(+), 26 deletions(-)
diff --git u-boot-66714b1.orig/fs/fat/fat.c u-boot-66714b1/fs/fat/fat.c
index 48c8844..fbc2d7d 100644
--- u-boot-66714b1.orig/fs/fat/fat.c
+++ u-boot-66714b1/fs/fat/fat.c
@@ -775,7 +775,7 @@ do_fat_read(const char *filename, void *buffer, unsigned
long maxsize, int dols)
volume_info volinfo;
fsdata datablock;
fsdata *mydata = &datablock;
- dir_entry *dentptr;
+ dir_entry *dentptr = NULL;
__u16 prevcksum = 0x;
char *subname = "";
__u32 cursect;
@@ -874,19 +874,21 @@ do_fat_read(const char *filename, void *buffer, unsigned
long maxsize, int dols)
while (1) {
int i;
- debug("FAT read sect=%d, clust_size=%d, DIRENTSPERBLOCK=%zd\n",
- cursect, mydata->clust_size, DIRENTSPERBLOCK);
+ if (j == 0) {
+ debug("FAT read sect=%d, clust_size=%d,
DIRENTSPERBLOCK=%zd\n",
+ cursect, mydata->clust_size, DIRENTSPERBLOCK);
- if (disk_read(cursect,
- (mydata->fatsize == 32) ?
- (mydata->clust_size) :
- PREFETCH_BLOCKS,
- do_fat_read_block) < 0) {
- debug("Error: reading rootdir block\n");
- goto exit;
- }
+ if (disk_read(cursect,
+ (mydata->fatsize == 32) ?
+ (mydata->clust_size) :
+ PREFETCH_BLOCKS,
+ do_fat_read_block) < 0) {
+ debug("Error: reading rootdir block\n");
+ goto exit;
+ }
- dentptr = (dir_entry *) do_fat_read_block;
+ dentptr = (dir_entry *) do_fat_read_block;
+ }
for (i = 0; i < DIRENTSPERBLOCK; i++) {
char s_name[14], l_name[VFAT_MAXLEN_BYTES];
@@ -1028,28 +1030,33 @@ do_fat_read(const char *filename, void *buffer,
unsigned long maxsize, int dols)
* completely processed.
*/
++j;
- int fat32_end = 0;
- if ((mydata->fatsize == 32) && (j == mydata->clust_size)) {
- int nxtsect = 0;
- int nxt_clust = 0;
+ int rootdir_end = 0;
+ if (mydata->fatsize == 32) {
+ if (j == mydata->clust_size) {
+ int nxtsect = 0;
+ int nxt_clust = 0;
- nxt_clust = get_fatent(mydata, root_cluster);
- fat32_end = CHECK_CLUST(nxt_clust, 32);
+ nxt_clust = get_fatent(mydata, root_cluster);
+ rootdir_end = CHECK_CLUST(nxt_clust, 32);
- nxtsect = mydata->data_begin +
- (nxt_clust * mydata->clust_size);
+ nxtsect = mydata->data_begin +
+ (nxt_clust * mydata->clust_size);
- root_cluster = nxt_clust;
+ root_cluster = nxt_clust;
- cursect = nxtsect;
- j = 0;
+ cursect = nxtsect;
+ j = 0;
+ }
} else {
- cursect++;
+ if (j == PREFETCH_BLOCKS)
+ j = 0;
+
+ rootdir_end = (++cursect - mydata->rootdir_sect >=
+ rootdir_size);
}
/* If end of rootdir reached */
- if ((mydata->fatsize == 32 && fat32_end) ||
- (mydata->fatsize != 32 && j == rootdir_size)) {
+ if (rootdir_end) {
if (dols == LS_ROOT) {
printf("\n%d file(s), %d dir(s)\n\n",
files, dirs);
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 5/8] FAT: Fix file contents listed as directory
With:
fatls mmc 0 /dir/file
dir: regular directory
file: regular file
The previous code read the contents of file as if it were directory entries to
list. This patch refuses to list file contents as if it were a folder.
Signed-off-by: Benoît Thébaudeau
Cc: Wolfgang Denk
---
Changes for v2:
- Patch renumbering because of the new v2 1/8.
- Possible code style changes due to the new v2 1/8.
.../fs/fat/fat.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git u-boot-66714b1.orig/fs/fat/fat.c u-boot-66714b1/fs/fat/fat.c
index fbc2d7d..5d08948 100644
--- u-boot-66714b1.orig/fs/fat/fat.c
+++ u-boot-66714b1/fs/fat/fat.c
@@ -1103,11 +1103,11 @@ rootdir_done:
goto exit;
}
- if (idx >= 0) {
- if (!(dentptr->attr & ATTR_DIR))
- goto exit;
+ if (isdir && !(dentptr->attr & ATTR_DIR))
+ goto exit;
+
+ if (idx >= 0)
subname = nextname;
- }
}
ret = get_contents(mydata, dentptr, buffer, maxsize);
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 6/8] FAT: get_cluster: Add buffer bouncing
Add a buffer bouncing mechanism to get_cluster. This can be useful for
misaligned applicative buffers passed through get_contents. This is required for
the following patches in the case of data aligned differently relatively to
buffers and clusters.
Signed-off-by: Benoît Thébaudeau
Cc: Wolfgang Denk
---
Changes for v2:
- Patch renumbering because of the new v2 1/8.
- Possible code style changes due to the new v2 1/8.
- Use printf instead of debug for the misalignment message.
.../fs/fat/fat.c | 42 ++--
1 file changed, 30 insertions(+), 12 deletions(-)
diff --git u-boot-66714b1.orig/fs/fat/fat.c u-boot-66714b1/fs/fat/fat.c
index 5d08948..101eb3a 100644
--- u-boot-66714b1.orig/fs/fat/fat.c
+++ u-boot-66714b1/fs/fat/fat.c
@@ -273,7 +273,6 @@ get_cluster(fsdata *mydata, __u32 clustnum, __u8 *buffer,
unsigned long size)
{
__u32 idx = 0;
__u32 startsect;
- __u32 nr_sect;
int ret;
if (clustnum > 0) {
@@ -285,25 +284,44 @@ get_cluster(fsdata *mydata, __u32 clustnum, __u8 *buffer,
unsigned long size)
debug("gc - clustnum: %d, startsect: %d\n", clustnum, startsect);
- nr_sect = size / mydata->sect_size;
- ret = disk_read(startsect, nr_sect, buffer);
- if (ret != nr_sect) {
- debug("Error reading data (got %d)\n", ret);
- return -1;
- }
- if (size % mydata->sect_size) {
+ if ((unsigned long)buffer & (ARCH_DMA_MINALIGN - 1)) {
ALLOC_CACHE_ALIGN_BUFFER(__u8, tmpbuf, mydata->sect_size);
+ printf("FAT: Misaligned buffer address (%p)\n", buffer);
+
+ while (size >= mydata->sect_size) {
+ ret = disk_read(startsect++, 1, tmpbuf);
+ if (ret != 1) {
+ debug("Error reading data (got %d)\n", ret);
+ return -1;
+ }
+
+ memcpy(buffer, tmpbuf, mydata->sect_size);
+ buffer += mydata->sect_size;
+ size -= mydata->sect_size;
+ }
+ } else {
idx = size / mydata->sect_size;
- ret = disk_read(startsect + idx, 1, tmpbuf);
+ ret = disk_read(startsect, idx, buffer);
+ if (ret != idx) {
+ debug("Error reading data (got %d)\n", ret);
+ return -1;
+ }
+ startsect += idx;
+ idx *= mydata->sect_size;
+ buffer += idx;
+ size -= idx;
+ }
+ if (size) {
+ ALLOC_CACHE_ALIGN_BUFFER(__u8, tmpbuf, mydata->sect_size);
+
+ ret = disk_read(startsect, 1, tmpbuf);
if (ret != 1) {
debug("Error reading data (got %d)\n", ret);
return -1;
}
- buffer += idx * mydata->sect_size;
- memcpy(buffer, tmpbuf, size % mydata->sect_size);
- return 0;
+ memcpy(buffer, tmpbuf, size);
}
return 0;
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 7/8] FAT: Simplify get_contents
One call to get_cluster can be factorized with another, so avoid duplicating
code.
Signed-off-by: Benoît Thébaudeau
Cc: Wolfgang Denk
---
Changes for v2:
- Patch renumbering because of the new v2 1/8.
- Possible code style changes due to the new v2 1/8.
.../fs/fat/fat.c | 14 +-
1 file changed, 1 insertion(+), 13 deletions(-)
diff --git u-boot-66714b1.orig/fs/fat/fat.c u-boot-66714b1/fs/fat/fat.c
index 101eb3a..19f6a8c 100644
--- u-boot-66714b1.orig/fs/fat/fat.c
+++ u-boot-66714b1/fs/fat/fat.c
@@ -367,21 +367,9 @@ get_contents(fsdata *mydata, dir_entry *dentptr, __u8
*buffer,
actsize += bytesperclust;
}
- /* actsize >= file size */
- actsize -= bytesperclust;
-
- /* get remaining clusters */
- if (get_cluster(mydata, curclust, buffer, (int)actsize) != 0) {
- printf("Error reading cluster\n");
- return -1;
- }
-
/* get remaining bytes */
- gotsize += (int)actsize;
- filesize -= actsize;
- buffer += actsize;
actsize = filesize;
- if (get_cluster(mydata, endclust, buffer, (int)actsize) != 0) {
+ if (get_cluster(mydata, curclust, buffer, (int)actsize) != 0) {
printf("Error reading cluster\n");
return -1;
}
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 8/8] FAT: Make it possible to read from any file position
When storage devices contain files larger than the embedded RAM, it is useful to
be able to read these files by chunks, e.g. for a software update to the
embedded NAND Flash from an external storage device (USB stick, SD card, etc.).
Hence, this patch makes it possible by adding a new FAT API to read files from a
given position.
Signed-off-by: Benoît Thébaudeau
Cc: Wolfgang Denk
---
Changes for v2:
- Patch renumbering because of the new v2 1/8.
- Possible code style changes due to the new v2 1/8.
- Add missing vairable renaming to fat_write.c.
.../fs/fat/fat.c | 88
.../fs/fat/fat_write.c | 18 ++--
2 files changed, 80 insertions(+), 26 deletions(-)
diff --git u-boot-66714b1.orig/fs/fat/fat.c u-boot-66714b1/fs/fat/fat.c
index 19f6a8c..8c94b28 100644
--- u-boot-66714b1.orig/fs/fat/fat.c
+++ u-boot-66714b1/fs/fat/fat.c
@@ -328,13 +328,16 @@ get_cluster(fsdata *mydata, __u32 clustnum, __u8 *buffer,
unsigned long size)
}
/*
- * Read at most 'maxsize' bytes from the file associated with 'dentptr'
+ * Read at most 'maxsize' bytes from 'pos' in the file associated with
'dentptr'
* into 'buffer'.
* Return the number of bytes read or -1 on fatal errors.
*/
+__u8 get_contents_vfatname_block[MAX_CLUSTSIZE]
+ __aligned(ARCH_DMA_MINALIGN);
+
static long
-get_contents(fsdata *mydata, dir_entry *dentptr, __u8 *buffer,
-unsigned long maxsize)
+get_contents(fsdata *mydata, dir_entry *dentptr, unsigned long pos,
+__u8 *buffer, unsigned long maxsize)
{
unsigned long filesize = FAT2CPU32(dentptr->size), gotsize = 0;
unsigned int bytesperclust = mydata->clust_size * mydata->sect_size;
@@ -344,12 +347,59 @@ get_contents(fsdata *mydata, dir_entry *dentptr, __u8
*buffer,
debug("Filesize: %ld bytes\n", filesize);
- if (maxsize > 0 && filesize > maxsize)
- filesize = maxsize;
+ if (pos >= filesize) {
+ debug("Read position past EOF: %lu\n", pos);
+ return gotsize;
+ }
+
+ if (maxsize > 0 && filesize > pos + maxsize)
+ filesize = pos + maxsize;
debug("%ld bytes\n", filesize);
actsize = bytesperclust;
+
+ /* go to cluster at pos */
+ while (actsize <= pos) {
+ curclust = get_fatent(mydata, curclust);
+ if (CHECK_CLUST(curclust, mydata->fatsize)) {
+ debug("curclust: 0x%x\n", curclust);
+ debug("Invalid FAT entry\n");
+ return gotsize;
+ }
+ actsize += bytesperclust;
+ }
+
+ /* actsize > pos */
+ actsize -= bytesperclust;
+ filesize -= actsize;
+ pos -= actsize;
+
+ /* align to beginning of next cluster if any */
+ if (pos) {
+ actsize = min(filesize, bytesperclust);
+ if (get_cluster(mydata, curclust, get_contents_vfatname_block,
+ (int)actsize) != 0) {
+ printf("Error reading cluster\n");
+ return -1;
+ }
+ filesize -= actsize;
+ actsize -= pos;
+ memcpy(buffer, get_contents_vfatname_block + pos, actsize);
+ gotsize += actsize;
+ if (!filesize)
+ return gotsize;
+ buffer += actsize;
+
+ curclust = get_fatent(mydata, curclust);
+ if (CHECK_CLUST(curclust, mydata->fatsize)) {
+ debug("curclust: 0x%x\n", curclust);
+ debug("Invalid FAT entry\n");
+ return gotsize;
+ }
+ }
+
+ actsize = bytesperclust;
endclust = curclust;
do {
@@ -433,9 +483,6 @@ static int slot2str(dir_slot *slotptr, char *l_name, int
*idx)
* into 'retdent'
* Return 0 on success, -1 otherwise.
*/
-__u8 get_vfatname_block[MAX_CLUSTSIZE]
- __aligned(ARCH_DMA_MINALIGN);
-
static int
get_vfatname(fsdata *mydata, int curclust, __u8 *cluster,
dir_entry *retdent, char *l_name)
@@ -474,13 +521,13 @@ get_vfatname(fsdata *mydata, int curclust, __u8 *cluster,
return -1;
}
- if (get_cluster(mydata, curclust, get_vfatname_block,
+ if (get_cluster(mydata, curclust, get_contents_vfatname_block,
mydata->clust_size * mydata->sect_size) != 0) {
debug("Error: reading directory block\n");
return -1;
}
- slotptr2 = (dir_slot *)get_vfatname_block;
+ slotptr2 = (dir_slot *)get_contents_vfatname_block;
while (counter > 0) {
if (((slotptr2->id & ~LAST_LONG_ENTRY_MASK)
& 0xff) != counter)
@@ -491,7 +538,7 @@ get_vfatn
Re: [U-Boot] [PATCH v2 1/9] FAT: cosmetic: Remove extra spaces
Argh, it was 1/8 actually, not 1/9...
- Original Message -
> From: "Benoît Thébaudeau"
> To: u-boot@lists.denx.de
> Cc: "Wolfgang Denk" , "Mike Frysinger"
> Sent: Friday, July 20, 2012 3:18:44 PM
> Subject: [PATCH v2 1/9] FAT: cosmetic: Remove extra spaces
>
> Remove spaces before opening parentheses in function calls.
>
> Signed-off-by: Benoît Thébaudeau
> Cc: Wolfgang Denk
> ---
> Changes for v2:
> - New patch for this version of the series.
>
> .../fs/fat/fat.c | 44
> ++--
> 1 file changed, 21 insertions(+), 23 deletions(-)
>
> diff --git u-boot-66714b1.orig/fs/fat/fat.c
> u-boot-66714b1/fs/fat/fat.c
> index bc46cc5..9f83572 100644
> --- u-boot-66714b1.orig/fs/fat/fat.c
> +++ u-boot-66714b1/fs/fat/fat.c
> @@ -37,7 +37,7 @@
> /*
> * Convert a string to lowercase.
> */
> -static void downcase (char *str)
> +static void downcase(char *str)
> {
> while (*str != '\0') {
> TOLOWER(*str);
> @@ -62,7 +62,7 @@ static int disk_read(__u32 block, __u32 nr_blocks,
> void *buf)
> cur_part_info.start + block, nr_blocks, buf);
> }
>
> -int fat_register_device (block_dev_desc_t * dev_desc, int part_no)
> +int fat_register_device(block_dev_desc_t * dev_desc, int part_no)
> {
> ALLOC_CACHE_ALIGN_BUFFER(unsigned char, buffer, dev_desc->blksz);
>
> @@ -127,7 +127,7 @@ int fat_register_device (block_dev_desc_t *
> dev_desc, int part_no)
> * Get the first occurence of a directory delimiter ('/' or '\') in
> a string.
> * Return index into string if found, -1 otherwise.
> */
> -static int dirdelim (char *str)
> +static int dirdelim(char *str)
> {
> char *start = str;
>
> @@ -142,7 +142,7 @@ static int dirdelim (char *str)
> /*
> * Extract zero terminated short name from a directory entry.
> */
> -static void get_name (dir_entry *dirent, char *s_name)
> +static void get_name(dir_entry *dirent, char *s_name)
> {
> char *ptr;
>
> @@ -171,7 +171,7 @@ static void get_name (dir_entry *dirent, char
> *s_name)
> * Get the entry at index 'entry' in a FAT (12/16/32) table.
> * On failure 0x00 is returned.
> */
> -static __u32 get_fatent (fsdata *mydata, __u32 entry)
> +static __u32 get_fatent(fsdata *mydata, __u32 entry)
> {
> __u32 bufnum;
> __u32 off16, offset;
> @@ -270,8 +270,7 @@ static __u32 get_fatent (fsdata *mydata, __u32
> entry)
> * Return 0 on success, -1 otherwise.
> */
> static int
> -get_cluster (fsdata *mydata, __u32 clustnum, __u8 *buffer,
> - unsigned long size)
> +get_cluster(fsdata *mydata, __u32 clustnum, __u8 *buffer, unsigned
> long size)
> {
> __u32 idx = 0;
> __u32 startsect;
> @@ -317,8 +316,8 @@ get_cluster (fsdata *mydata, __u32 clustnum, __u8
> *buffer,
> * Return the number of bytes read or -1 on fatal errors.
> */
> static long
> -get_contents (fsdata *mydata, dir_entry *dentptr, __u8 *buffer,
> - unsigned long maxsize)
> +get_contents(fsdata *mydata, dir_entry *dentptr, __u8 *buffer,
> + unsigned long maxsize)
> {
> unsigned long filesize = FAT2CPU32(dentptr->size), gotsize = 0;
> unsigned int bytesperclust = mydata->clust_size *
> mydata->sect_size;
> @@ -397,7 +396,7 @@ getit:
> * starting at l_name[*idx].
> * Return 1 if terminator (zero byte) is found, 0 otherwise.
> */
> -static int slot2str (dir_slot *slotptr, char *l_name, int *idx)
> +static int slot2str(dir_slot *slotptr, char *l_name, int *idx)
> {
> int j;
>
> @@ -433,8 +432,8 @@ __u8 get_vfatname_block[MAX_CLUSTSIZE]
> __aligned(ARCH_DMA_MINALIGN);
>
> static int
> -get_vfatname (fsdata *mydata, int curclust, __u8 *cluster,
> - dir_entry *retdent, char *l_name)
> +get_vfatname(fsdata *mydata, int curclust, __u8 *cluster,
> + dir_entry *retdent, char *l_name)
> {
> dir_entry *realdent;
> dir_slot *slotptr = (dir_slot *)retdent;
> @@ -516,7 +515,7 @@ get_vfatname (fsdata *mydata, int curclust, __u8
> *cluster,
> }
>
> /* Calculate short name checksum */
> -static __u8 mkcksum (const char *str)
> +static __u8 mkcksum(const char *str)
> {
> int i;
>
> @@ -537,9 +536,9 @@ static __u8 mkcksum (const char *str)
> __u8 get_dentfromdir_block[MAX_CLUSTSIZE]
> __aligned(ARCH_DMA_MINALIGN);
>
> -static dir_entry *get_dentfromdir (fsdata *mydata, int startsect,
> -char *filename, dir_entry *retdent,
> -int dols)
> +static dir_entry *get_dentfromdir(fsdata *mydata, int startsect,
> + char *filename, dir_entry *retdent,
> + int dols)
> {
> __u16 prevcksum = 0x;
> __u32 curclust = START(retdent);
> @@ -699,7 +698,7 @@ static dir_entry *get_dentfromdir (fsdata
> *mydata, int startsect,
> * Read boot sector and volume info from a FAT filesystem
> */
> static int
> -read_bootsectandvi (boot_sec
[U-Boot] [PATCH] md5: Export step-by-step API
Export the MD5 step-by-step API so that it is possible for the lib users to
digest files by chunks. This is especially useful for very large files that
would not fit into the embedded RAM.
Signed-off-by: Benoît Thébaudeau
Cc: Wolfgang Denk
---
.../include/u-boot/md5.h |4
{u-boot-66714b1.orig => u-boot-66714b1}/lib/md5.c |6 +++---
2 files changed, 7 insertions(+), 3 deletions(-)
diff --git u-boot-66714b1.orig/include/u-boot/md5.h
u-boot-66714b1/include/u-boot/md5.h
index e09c16a..e5cb923 100644
--- u-boot-66714b1.orig/include/u-boot/md5.h
+++ u-boot-66714b1/include/u-boot/md5.h
@@ -17,6 +17,10 @@ struct MD5Context {
};
};
+void MD5Init(struct MD5Context *ctx);
+void MD5Update(struct MD5Context *ctx, unsigned char const *buf, unsigned len);
+void MD5Final(unsigned char digest[16], struct MD5Context *ctx);
+
/*
* Calculate and store in 'output' the MD5 digest of 'len' bytes at
* 'input'. 'output' must have enough space to hold 16 bytes.
diff --git u-boot-66714b1.orig/lib/md5.c u-boot-66714b1/lib/md5.c
index 2ae4a06..688b725 100644
--- u-boot-66714b1.orig/lib/md5.c
+++ u-boot-66714b1/lib/md5.c
@@ -55,7 +55,7 @@ byteReverse(unsigned char *buf, unsigned longs)
* Start MD5 accumulation. Set bit count to 0 and buffer to mysterious
* initialization constants.
*/
-static void
+void
MD5Init(struct MD5Context *ctx)
{
ctx->buf[0] = 0x67452301;
@@ -71,7 +71,7 @@ MD5Init(struct MD5Context *ctx)
* Update context to reflect the concatenation of another buffer full
* of bytes.
*/
-static void
+void
MD5Update(struct MD5Context *ctx, unsigned char const *buf, unsigned len)
{
register __u32 t;
@@ -120,7 +120,7 @@ MD5Update(struct MD5Context *ctx, unsigned char const *buf,
unsigned len)
* Final wrapup - pad to 64-byte boundary with the bit pattern
* 1 0* (64-bit count of bits processed, MSB-first)
*/
-static void
+void
MD5Final(unsigned char digest[16], struct MD5Context *ctx)
{
unsigned int count;
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Unable to power the USB Keyboard on u-boot
Dear Atul Kumar, > Dear All, > >I am trying to use "usb keyboard" on u-boot. I am using the > u-boot stack which was shared by you. Can you help me to know where problem > is going. I am sending some of debug prints which i found on my "Beagle > board xM". > > I have connected usb mouse and usb keyboard on same side of port, here usb > mouse lights up but the keyboard does not powers on. Both keyboard and > Mouse are from logitech. > > Please help me to make this up as i have scheduled demo. [...] What version of uboot is that? Try with latest u-boot git head, it should have the beagleboard/usb patches in there. Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/5] ehci-hcd: Boost transfer speed
Dear Benoît Thébaudeau, > On Friday 20 July 2012 13:37:37 Stefan Herbrechtsmeier wrote: > > Am 20.07.2012 13:26, schrieb Benoît Thébaudeau: > > > + int xfr_bytes = min(left_length, > > > + (QT_BUFFER_CNT * 4096 - > > > + ((uint32_t)buf_ptr & 4095)) & > > > + ~4095); > > > > Why you align the length to 4096? > > It's to guarantee that each transfer length is a multiple of the max packet > length. Otherwise, early short packets are issued, which breaks the > transfer and results in time-out error messages. Early short packets ? What do you mean? > Regards, > Benoît Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 1/4] kirkwood: use c-struct for access to SDRAM addr decode registers
> -Original Message-
> From: Holger Brunck [mailto:holger.bru...@keymile.com]
> Sent: 20 July 2012 18:04
> To: u-boot@lists.denx.de
> Cc: Holger Brunck; Prafulla Wadaskar; Valentin Longchamp; Gerlando
> Falauto; Marek Vasut
> Subject: [PATCH v3 1/4] kirkwood: use c-struct for access to SDRAM
> addr decode registers
>
> Remove the defines and do this with a C-struct.
>
> Signed-off-by: Holger Brunck
> cc: Prafulla Wadaskar
> cc: Valentin Longchamp
> cc: Gerlando Falauto
> cc: Marek Vasut
> ---
> changes for v3:
> - new patch as requested on the ML
>
> arch/arm/cpu/arm926ejs/kirkwood/dram.c | 23 +--
> 1 files changed, 17 insertions(+), 6 deletions(-)
>
> diff --git a/arch/arm/cpu/arm926ejs/kirkwood/dram.c
> b/arch/arm/cpu/arm926ejs/kirkwood/dram.c
> index 181b3e7..1c5faab 100644
> --- a/arch/arm/cpu/arm926ejs/kirkwood/dram.c
> +++ b/arch/arm/cpu/arm926ejs/kirkwood/dram.c
> @@ -30,20 +30,29 @@
>
> DECLARE_GLOBAL_DATA_PTR;
>
> -#define KW_REG_CPUCS_WIN_BAR(x) (KW_REGISTER(0x1500) + (x *
> 0x08))
> -#define KW_REG_CPUCS_WIN_SZ(x) (KW_REGISTER(0x1504) + (x *
> 0x08))
> +struct kw_sdram_bank {
> + u32 win_bar;
> + u32 win_sz;
> +};
> +
> +struct kw_sdram_addr_dec {
> + struct kw_sdram_banksdram_bank[4];
> +};
> +
> /*
> * kw_sdram_bar - reads SDRAM Base Address Register
> */
> u32 kw_sdram_bar(enum memory_bank bank)
> {
> + struct kw_sdram_addr_dec *base =
> + (struct kw_sdram_addr_dec *)KW_REGISTER(0x1500);
> u32 result = 0;
> - u32 enable = 0x01 & readl(KW_REG_CPUCS_WIN_SZ(bank));
> + u32 enable = 0x01 & readl(&base->sdram_bank[bank].win_sz);
>
> if ((!enable) || (bank > BANK3))
> return 0;
>
> - result = readl(KW_REG_CPUCS_WIN_BAR(bank));
> + result = readl(&base->sdram_bank[bank].win_bar);
> return result;
> }
>
> @@ -52,12 +61,14 @@ u32 kw_sdram_bar(enum memory_bank bank)
> */
> u32 kw_sdram_bs(enum memory_bank bank)
> {
> + struct kw_sdram_addr_dec *base =
> + (struct kw_sdram_addr_dec *)KW_REGISTER(0x1500);
> u32 result = 0;
> - u32 enable = 0x01 & readl(KW_REG_CPUCS_WIN_SZ(bank));
> + u32 enable = 0x01 & readl(&base->sdram_bank[bank].win_sz);
>
> if ((!enable) || (bank > BANK3))
> return 0;
> - result = 0xff00 & readl(KW_REG_CPUCS_WIN_SZ(bank));
> + result = 0xff00 & readl(&base->sdram_bank[bank].win_sz);
> result += 0x0100;
> return result;
> }
Hi Holger
First of all, many thanks for this initiative.
Acked-By: Prafulla Wadaskar
Regards...
Prafulla . . .
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/5] ehci-hcd: Boost transfer speed
Dear Marek Vasut, On Friday 20 July 2012 15:44:01 Marek Vasut wrote: > > On Friday 20 July 2012 13:37:37 Stefan Herbrechtsmeier wrote: > > > Am 20.07.2012 13:26, schrieb Benoît Thébaudeau: > > > > + int xfr_bytes = min(left_length, > > > > + (QT_BUFFER_CNT * 4096 - > > > > +((uint32_t)buf_ptr & > > > > 4095)) & > > > > + ~4095); > > > > > > Why you align the length to 4096? > > > > It's to guarantee that each transfer length is a multiple of the > > max packet > > length. Otherwise, early short packets are issued, which breaks the > > transfer and results in time-out error messages. > > Early short packets ? What do you mean? During a USB transfer, all packets must have a length of max packet length for the pipe/endpoint, except the final one that can be a short packet. Without the alignment I make for xfr_bytes, short packets can occur within a transfer, because the hardware starts a new packet for each new queued qTD it handles. Best regards, Benoît ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] rtc: pcf8563: Make century compatible with Linux
This driver uses the century bit of this RTC in the opposite way Linux does. From Linux's rtc-pcf8563.c: /* * The meaning of MO_C bit varies by the chip type. * From PCF8563 datasheet: this bit is toggled when the years * register overflows from 99 to 00 * 0 indicates the century is 20xx * 1 indicates the century is 19xx * From RTC8564 datasheet: this bit indicates change of * century. When the year digit data overflows from 99 to 00, * this bit is set. By presetting it to 0 while still in the * 20th century, it will be set in year 2000, ... * There seems no reliable way to know how the system use this * bit. So let's do it heuristically, assuming we are live in * 1970...2069. */ As U-Boot's PCF8563 driver does not say it is supposed to support the RTC8564, make this driver compatible with Linux's by giving the opposite meaning to the century bit. Signed-off-by: Benoît Thébaudeau Cc: Wolfgang Denk --- .../drivers/rtc/pcf8563.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git u-boot-66714b1.orig/drivers/rtc/pcf8563.c u-boot-66714b1/drivers/rtc/pcf8563.c index 339e5f6..a028533 100644 --- u-boot-66714b1.orig/drivers/rtc/pcf8563.c +++ u-boot-66714b1/drivers/rtc/pcf8563.c @@ -72,7 +72,7 @@ int rtc_get (struct rtc_time *tmp) tmp->tm_hour = bcd2bin (hour & 0x3F); tmp->tm_mday = bcd2bin (mday & 0x3F); tmp->tm_mon = bcd2bin (mon_cent & 0x1F); - tmp->tm_year = bcd2bin (year) + ((mon_cent & 0x80) ? 2000 : 1900); + tmp->tm_year = bcd2bin (year) + ((mon_cent & 0x80) ? 1900 : 2000); tmp->tm_wday = bcd2bin (wday & 0x07); tmp->tm_yday = 0; tmp->tm_isdst= 0; @@ -94,7 +94,7 @@ int rtc_set (struct rtc_time *tmp) rtc_write (0x08, bin2bcd(tmp->tm_year % 100)); - century = (tmp->tm_year >= 2000) ? 0x80 : 0; + century = (tmp->tm_year >= 2000) ? 0 : 0x80; rtc_write (0x07, bin2bcd(tmp->tm_mon) | century); rtc_write (0x06, bin2bcd(tmp->tm_wday)); ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] rtc: imxdi: Initial support
Add support for Freescale's i.MX DryIce RTC, present on i.MX25.
Signed-off-by: Benoît Thébaudeau
Cc: Wolfgang Denk
Cc: Stefano Babic
---
.../drivers/rtc/Makefile |1 +
/dev/null => u-boot-66714b1/drivers/rtc/imxdi.c| 224
2 files changed, 225 insertions(+)
create mode 100644 u-boot-66714b1/drivers/rtc/imxdi.c
diff --git u-boot-66714b1.orig/drivers/rtc/Makefile
u-boot-66714b1/drivers/rtc/Makefile
index faf4fcd..aeeea37 100644
--- u-boot-66714b1.orig/drivers/rtc/Makefile
+++ u-boot-66714b1/drivers/rtc/Makefile
@@ -43,6 +43,7 @@ COBJS-$(CONFIG_RTC_DS164x) += ds164x.o
COBJS-$(CONFIG_RTC_DS174x) += ds174x.o
COBJS-$(CONFIG_RTC_DS3231) += ds3231.o
COBJS-$(CONFIG_RTC_FTRTC010) += ftrtc010.o
+COBJS-$(CONFIG_RTC_IMXDI) += imxdi.o
COBJS-$(CONFIG_RTC_ISL1208) += isl1208.o
COBJS-$(CONFIG_RTC_M41T11) += m41t11.o
COBJS-$(CONFIG_RTC_M41T60) += m41t60.o
diff --git u-boot-66714b1/drivers/rtc/imxdi.c u-boot-66714b1/drivers/rtc/imxdi.c
new file mode 100644
index 000..c2be842
--- /dev/null
+++ u-boot-66714b1/drivers/rtc/imxdi.c
@@ -0,0 +1,224 @@
+/*
+ * (C) Copyright 2009-2012 ADVANSEE
+ * Benoît Thébaudeau
+ *
+ * Based on the Linux rtc-imxdi.c driver, which is:
+ * Copyright 2008-2009 Freescale Semiconductor, Inc. All Rights Reserved.
+ * Copyright 2010 Orex Computed Radiography
+ *
+ * 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
+ */
+
+/*
+ * Date & Time support for Freescale i.MX DryIce RTC
+ */
+
+#include
+#include
+#include
+
+#if defined(CONFIG_CMD_DATE)
+
+#include
+#include
+
+/* DryIce Register Definitions */
+
+#define DTCMR 0x00 /* Time Counter MSB Reg */
+#define DTCLR 0x04 /* Time Counter LSB Reg */
+
+#define DCAMR 0x08 /* Clock Alarm MSB Reg */
+#define DCALR 0x0c /* Clock Alarm LSB Reg */
+#define DCAMR_UNSET 0x /* doomsday - 1 sec */
+
+#define DCR 0x10 /* Control Reg */
+#define DCR_TCE (1 << 3) /* Time Counter Enable */
+
+#define DSR 0x14 /* Status Reg */
+#define DSR_WBF (1 << 10) /* Write Busy Flag */
+#define DSR_WNF (1 << 9) /* Write Next Flag */
+#define DSR_WCF (1 << 8) /* Write Complete Flag */
+#define DSR_WEF (1 << 7) /* Write Error Flag */
+#define DSR_CAF (1 << 4) /* Clock Alarm Flag */
+#define DSR_NVF (1 << 1) /* Non-Valid Flag */
+#define DSR_SVF (1 << 0) /* Security Violation Flag */
+
+#define DIER 0x18 /* Interrupt Enable Reg */
+#define DIER_WNIE (1 << 9) /* Write Next Interrupt Enable */
+#define DIER_WCIE (1 << 8) /* Write Complete Interrupt Enable */
+#define DIER_WEIE (1 << 7) /* Write Error Interrupt Enable */
+#define DIER_CAIE (1 << 4) /* Clock Alarm Interrupt Enable */
+
+/*
+ * This function attempts to clear the dryice write-error flag.
+ *
+ * A dryice write error is similar to a bus fault and should not occur in
+ * normal operation. Clearing the flag requires another write, so the root
+ * cause of the problem may need to be fixed before the flag can be cleared.
+ */
+static void clear_write_error(void)
+{
+ int cnt;
+
+ puts("### Warning: RTC - Register write error!\n");
+
+ /* clear the write error flag */
+ __raw_writel(DSR_WEF, IMX_DRYICE_BASE + DSR);
+
+ /* wait for it to take effect */
+ for (cnt = 0; cnt < 1000; cnt++) {
+ if ((__raw_readl(IMX_DRYICE_BASE + DSR) & DSR_WEF) == 0)
+ return;
+ udelay(10);
+ }
+ puts("### Error: RTC - Cannot clear write-error flag!\n");
+}
+
+/*
+ * Write a dryice register and wait until it completes.
+ *
+ * This function uses interrupt flags to determine when the
+ * write has completed.
+ */
+static int di_write_wait(u32 val, int reg)
+{
+ int cnt;
+ int ret = 0;
+ int rc = 0;
+
+ /* do the register write */
+ __raw_writel(val, IMX_DRYICE_BASE + reg);
+
+ /* wait for the write to finish */
+ for (cnt = 0; cnt < 100; cnt++) {
+ if ((__raw_readl(IMX_DRYICE_BASE + DSR) &
+ (DSR_WCF | DSR_WEF)) != 0) {
+ ret = 1;
+
Re: [U-Boot] Need help to get u-boot running on the taskit stamp9g20
On Fri, Jul 20, 2012 at 03:08:51PM +0200, Markus Hubig wrote:
> On Wed, Jul 18, 2012 at 03:21:00PM +0200, Markus Hubig wrote:
> > Hmm OK I disabled the watchdog and enabled debugging and now this
> > is what I get at the first boot after flashing:
> >
> > | RomBOOT
> > |
> > |
> > | U-Boot 2012.04.01-3-gab465ef-dirty (Jul 18 2012 - 15:08:22)
> > |
> > | U-Boot code: 23F0 -> 23F30130 BSS: -> 23F71E28
> > | CPU: AT91SAM9G20
> > | Crystal frequency: 18.432 MHz
> > | CPU clock: 396.288 MHz
> > | Master clock : 132.096 MHz
> > | Starting dram_init!
> > | dram_init finished!
> > | monitor len: 00071E28
> > | ramsize: 0400
> > | Top of RAM usable for U-Boot at: 2400
> > | Reserving 455k for U-Boot at: 23f8e000
> > | Reserving 640k for malloc() at: 23eee000
> > | Reserving 36 Bytes for Board Info at: 23eedfdc
> > | Reserving 144 Bytes for Global Data at: 23eedf4c
> > | New Stack Pointer is: 23eedf40
> > | RAM Configuration:
> > | Bank #0: 2000 64 MiB
> > | relocation Offset is: 0008e000
> > | WARNING: Caches not enabled
> > | monitor flash len: 00035750
> > | Starting board_init!
> > | Starting stamp9G20_nand_hw_init!
> > | stamp9G20_nand_hw_init finished!
> > | Starting stamp9G20_macb_hw_init!
> > | stamp9G20_macb_hw_init finished!
> > | board_init finished!
> > | Now running in RAM - U-Boot at: 23f8e000
> >
> > The red LED is on and I can't input anything.
>
> OK now I managed to plug a JTAG Adapter with OpenOCD to the
> PortuxG20. But what now? How can I find out where I stuck?
Hmm ok .. JTAG & GDB is kind of a future wappon for me, don't know
how to handle. But using the old'n'good "trace code" debugging, I
managed to find out where my u-boot stops. It's in
arch/arm/lib/board.c:
=
| debug("malloc stuff start\n");
| /* The Malloc area is immediately below the monitor copy in DRAM */
| malloc_start = dest_addr - TOTAL_MALLOC_LEN;
| mem_malloc_init (malloc_start, TOTAL_MALLOC_LEN);
| debug("malloc stuff finished\n");
It never reaches the second debug output. Digin a bit deeper I found in
common/dlmalloc.c
=
| void mem_malloc_init(ulong start, ulong size)
| {
| mem_malloc_start = start;
| mem_malloc_end = start + size;
| mem_malloc_brk = start;
| debug("bevor memset");
| memset((void *)mem_malloc_start, 0, size);
| debug("after memset\n");
| }
here it also never reaches the second debug output.
And the only setting I found in my board support code (stamp9g20.h)
that is obviously realated to this "malloc-thing" is:
| #define CONFIG_SYS_MALLOC_LEN ROUND(3 * CONFIG_ENV_SIZE \
| + 128*1024, 0x1000)
| #define CONFIG_SYS_GBL_DATA_SIZE 128
| #define CONFIG_STACKSIZE (32*1024)
but this values are all copied from the original (and once working)
patch from taskit ...
Any thoughts?
Cheers, Markus
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] nds32: split common cache access from cpu into lib
On Friday 20 July 2012 04:24:55 Macpaul Lin wrote: > Since this discussion hasn't been finished, > and we haven't decide the final action about the new policy about cache.h > and common.h. > I'd like to pick this patch v2 for the coming release for fixing build > error for board adp-ag102. > What do you think? :-) i don't think the topic of cleaning up common code impedes you merging your nds32 cache clean ups at all. they're orthogonal issues. -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 5/7] dfu:cmd: Support for DFU u-boot command
On Friday 20 July 2012 07:33:49 Marek Vasut wrote: > Dear Mike Frysinger, > > On Wednesday 04 July 2012 10:39:20 Marek Vasut wrote: > > > > Putting there the __func__ name would improve structure and speed up > > > > finding right place. > > > > > > And if you want to use even __LINE__, look up __stringify patch in the > > > ML archives ;-) > > > > ugh, no, let's not use __LINE__ anywhere other than debug(). it has no > > business in code we ship as it is pointless bloated noise. > > Helps find out the problematic place in code ... except the code changes thus invalidating the line numbers, and how often are you putting the same string in multiple places that you can't easily coordinate where it came from ? if people are using the same exact string in multiple places, that sounds like a different problem. -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] md5: Export step-by-step API
Acked-by: Mike Frysinger -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/5] ehci-hcd: Boost transfer speed
Am 20.07.2012 15:56, schrieb Benoît Thébaudeau: Dear Marek Vasut, On Friday 20 July 2012 15:44:01 Marek Vasut wrote: On Friday 20 July 2012 13:37:37 Stefan Herbrechtsmeier wrote: Am 20.07.2012 13:26, schrieb Benoît Thébaudeau: + int xfr_bytes = min(left_length, + (QT_BUFFER_CNT * 4096 - +((uint32_t)buf_ptr & 4095)) & + ~4095); Why you align the length to 4096? It's to guarantee that each transfer length is a multiple of the max packet length. Otherwise, early short packets are issued, which breaks the transfer and results in time-out error messages. Early short packets ? What do you mean? During a USB transfer, all packets must have a length of max packet length for the pipe/endpoint, except the final one that can be a short packet. Without the alignment I make for xfr_bytes, short packets can occur within a transfer, because the hardware starts a new packet for each new queued qTD it handles. But if I am right, the max packet length is 512 for bulk and 1024 for Interrupt transfer. Regards, Stefan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] global_data: unify global flag defines
On Sunday 18 March 2012 20:31:24 Mike Frysinger wrote: > All the global flag defines are the same across all arches. So unify them > in one place, and add a simple way for arches to extend for their needs. this one seems to still apply with `git am -3` to mainline ... -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/5] ehci-hcd: Boost transfer speed
On Friday 20 July 2012 16:51:33 Stefan Herbrechtsmeier wrote: > Am 20.07.2012 15:56, schrieb Benoît Thébaudeau: > > Dear Marek Vasut, > > > > On Friday 20 July 2012 15:44:01 Marek Vasut wrote: > >>> On Friday 20 July 2012 13:37:37 Stefan Herbrechtsmeier wrote: > Am 20.07.2012 13:26, schrieb Benoît Thébaudeau: > > + int xfr_bytes = min(left_length, > > + (QT_BUFFER_CNT * 4096 - > > +((uint32_t)buf_ptr & > > 4095)) & > > + ~4095); > Why you align the length to 4096? > >>> It's to guarantee that each transfer length is a multiple of the > >>> max packet > >>> length. Otherwise, early short packets are issued, which breaks > >>> the > >>> transfer and results in time-out error messages. > >> Early short packets ? What do you mean? > > During a USB transfer, all packets must have a length of max packet > > length for > > the pipe/endpoint, except the final one that can be a short packet. > > Without the > > alignment I make for xfr_bytes, short packets can occur within a > > transfer, > > because the hardware starts a new packet for each new queued qTD it > > handles. > But if I am right, the max packet length is 512 for bulk and 1024 for > Interrupt transfer. There are indeed different max packet lengths for different transfer types, but it does not matter since the chosen alignment guarantees a multiple of all these possible max packet lengths. Best regards, Benoît ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/5] ehci-hcd: Boost transfer speed
Am 20.07.2012 17:03, schrieb Benoît Thébaudeau: On Friday 20 July 2012 16:51:33 Stefan Herbrechtsmeier wrote: Am 20.07.2012 15:56, schrieb Benoît Thébaudeau: Dear Marek Vasut, On Friday 20 July 2012 15:44:01 Marek Vasut wrote: On Friday 20 July 2012 13:37:37 Stefan Herbrechtsmeier wrote: Am 20.07.2012 13:26, schrieb Benoît Thébaudeau: + int xfr_bytes = min(left_length, + (QT_BUFFER_CNT * 4096 - +((uint32_t)buf_ptr & 4095)) & + ~4095); Why you align the length to 4096? It's to guarantee that each transfer length is a multiple of the max packet length. Otherwise, early short packets are issued, which breaks the transfer and results in time-out error messages. Early short packets ? What do you mean? During a USB transfer, all packets must have a length of max packet length for the pipe/endpoint, except the final one that can be a short packet. Without the alignment I make for xfr_bytes, short packets can occur within a transfer, because the hardware starts a new packet for each new queued qTD it handles. But if I am right, the max packet length is 512 for bulk and 1024 for Interrupt transfer. There are indeed different max packet lengths for different transfer types, but it does not matter since the chosen alignment guarantees a multiple of all these possible max packet lengths. But thereby you limit the transfer to 4 qT buffers for unaligned transfers. Best regards, Stefan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/5] ehci-hcd: Boost transfer speed
On Friday 20 July 2012 17:15:13 Stefan Herbrechtsmeier wrote: > Am 20.07.2012 17:03, schrieb Benoît Thébaudeau: > > On Friday 20 July 2012 16:51:33 Stefan Herbrechtsmeier wrote: > >> Am 20.07.2012 15:56, schrieb Benoît Thébaudeau: > >>> Dear Marek Vasut, > >>> > >>> On Friday 20 July 2012 15:44:01 Marek Vasut wrote: > > On Friday 20 July 2012 13:37:37 Stefan Herbrechtsmeier wrote: > >> Am 20.07.2012 13:26, schrieb Benoît Thébaudeau: > >>> + int xfr_bytes = min(left_length, > >>> + (QT_BUFFER_CNT * 4096 - > >>> + ((uint32_t)buf_ptr & > >>> 4095)) & > >>> + ~4095); > >> Why you align the length to 4096? > > It's to guarantee that each transfer length is a multiple of > > the > > max packet > > length. Otherwise, early short packets are issued, which breaks > > the > > transfer and results in time-out error messages. > Early short packets ? What do you mean? > >>> During a USB transfer, all packets must have a length of max > >>> packet > >>> length for > >>> the pipe/endpoint, except the final one that can be a short > >>> packet. > >>> Without the > >>> alignment I make for xfr_bytes, short packets can occur within a > >>> transfer, > >>> because the hardware starts a new packet for each new queued qTD > >>> it > >>> handles. > >> But if I am right, the max packet length is 512 for bulk and 1024 > >> for > >> Interrupt transfer. > > There are indeed different max packet lengths for different > > transfer types, but > > it does not matter since the chosen alignment guarantees a multiple > > of all these > > possible max packet lengths. > But thereby you limit the transfer to 4 qT buffers for unaligned > transfers. Not exactly. The 5 qt_buffers are used for page-unaligned buffers, but that results in only 4 full pages of unaligned data, requiring 5 aligned pages. For page-aligned buffers, the 5 qt_buffers result in 5 full pages of aligned data. The unaligned case could be a little bit improved to always use as many packets as possible per qTD, but that would over-complicate things for a very negligible speed and memory gain. Best regards, Benoît ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] nds32: split common cache access from cpu into lib
Hi Macpaul, 2012/7/17 Macpaul Lin > This commit does the following updates. > 1. Split the common cache access from cpu.c into lib folder. > 2. Rename the following cache api to adapt common.h > - dcache_flush_rang -> flush_dcache_rang > - icache_inval_range -> invalidate_icache_range > 3. Add invalidate_dcache_range > > Signed-off-by: Macpaul Lin > --- > Changes for v2: > - flush_dcache_range: merge two asm calls into a single >asm volatile() block. > - Replace __asm__ __volatile__ block into asm volatile() > This commit has been applied into u-boot-nds32/master Thanks! ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Pull request: u-boot-nds32
Dear Wolfgang, Please pull the following 1 patch from u-boot-nds32 into your tree. Thanks! Macpaul Lin. The following changes since commit 3ec81d758c09d6887a77a1b1259d044a2905bc8e: Merge branch 'master' of git://git.denx.de/u-boot-usb (2012-07-20 09:12:43 +0200) are available in the git repository at: git://git.denx.de/u-boot-nds32.git master for you to fetch changes up to 8d732840ba1cd4d41c12242ba07f1cf58b6429bf: nds32: split common cache access from cpu into lib (2012-07-20 23:55:52 +0800) Macpaul Lin (1): nds32: split common cache access from cpu into lib arch/nds32/cpu/n1213/ag101/cpu.c | 112 arch/nds32/cpu/n1213/ag102/cpu.c | 112 arch/nds32/lib/Makefile | 2 +- arch/nds32/lib/cache.c | 157 +++ 4 files changed, 158 insertions(+), 225 deletions(-) create mode 100644 arch/nds32/lib/cache.c ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Notes from the U-Boot BOF Meeting in Geneva 2012/07/12
On Mon, 16 Jul 2012 23:30:49 +0200 Detlev Zundel wrote: > as promised, here are my expanded notes from the BoF meeting at LSM2012 > last week. It was a pleasure to get some core developers into one room Any word on Kconfig support? Kim ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PULL] u-boot-usb/master
On Fri, Jul 20, 2012 at 2:19 AM, Wolfgang Denk wrote:
> Dear Marek,
>
> In message <201207191452.53818.ma...@denx.de> you wrote:
>>
>> please apply this into the current release. I'm hereby commiting seppuku.
>
>
> PLEASE send such pull reqeusts to the mailing list, so everybody can
> see it.
>
>
>> The following changes since commit 66714b1a6df0a5a9f1656a6d4e6eea3c7ecdf7ae:
>>
>> Merge branch 'next' of git://git.denx.de/u-boot-video (2012-07-18 10:47:03
>> +0200)
>>
>> are available in the git repository at:
>>
>>
>> git://git.denx.de/u-boot-usb.git master
>>
>> for you to fetch changes up to 1b4bd0e66cd3b5124669c78bc968510b1040e9d9:
>>
>> usb_storage: fix ehci driver max transfer size (2012-07-18 14:46:19 +0200)
>>
>>
>> Ilya Yanok (6):
>> ehci-hcd: program asynclistaddr before every transfer
>> ehci-hcd: fix external buffer cache handling
>> usb: pass cache-aligned buffer to usb_get_descriptor()
>> usb: check return value of submit_{control, bulk}_msg
>> ehci-hcd: change debug() to printf() in case of errors
>> smsc95xx: align buffers to cache line size
>>
>> Marek Vasut (1):
>> common.h: Introduce DEFINE_CACHE_ALIGN_BUFFER
>>
>> Stefan Herbrechtsmeier (1):
>> usb_storage: fix ehci driver max transfer size
>>
>> Tom Rini (2):
>> ehci-omap: Do not call dcache_off from omap_ehci_hcd_init
>> ehci-hcd.c, musb_core, usb.h: Add USB_DMA_MINALIGN define for cache
>> alignment
>>
>> common/usb.c | 12
>> common/usb_storage.c | 37 +++
>> drivers/usb/eth/smsc95xx.c | 13 +
>> drivers/usb/host/ehci-hcd.c | 96
>> ---
>> drivers/usb/host/ehci-omap.c |1 -
>> drivers/usb/musb/musb_core.h |2 +-
>> include/common.h | 21 +---
>> include/usb.h| 10 ++
>> 8 files changed, 117 insertions(+), 75 deletions(-)
>
> Applied, thanks.
I think this merge is causing issues. Resetting to the previous merge
(ad8439d Merge branch 'sf' of git://git.denx.de/u-boot-blackfin) and
the issues go away.
-M
Generating include/generated/asm-offsets.h
bootm.c:329:16: error: expected ')' before '__attribute__'
bootm.c:329:25: error: expected identifier or '(' before ')' token
bootm.c:59:13: warning: 'boot_jump_linux' defined but not used
bootm.c:177:13: warning: 'boot_prep_linux' defined but not used
bootm.c:249:12: warning: 'boot_body_linux' defined but not used
make[2]: *** [bootm.o] Error 1
make[2]: *** Waiting for unfinished jobs
fm.c: In function 'fm_init_common':
/local/home/mattsm/git/u-boot/include/common.h:344:12: sorry,
unimplemented: inlining failed in call to 'setenv': function body not
available
fm.c:420:8: sorry, unimplemented: called from here
make[2]: *** [fm.o] Error 1
make[2]: *** Waiting for unfinished jobs
make[1]: *** [arch/powerpc/lib/libpowerpc.o] Error 2
make[1]: *** Waiting for unfinished jobs
make[1]: *** [drivers/net/fm/libfm.o] Error 2
bootp.c: In function 'DhcpHandler':
/local/home/mattsm/git/u-boot/include/common.h:344:12: sorry,
unimplemented: inlining failed in call to 'setenv': function body not
available
bootp.c:119:9: sorry, unimplemented: called from here
make[2]: *** [bootp.o] Error 1
make[2]: *** Waiting for unfinished jobs
net.c: In function 'NetLoop':
/local/home/mattsm/git/u-boot/include/common.h:344:12: sorry,
unimplemented: inlining failed in call to 'setenv': function body not
available
net.c:516:11: sorry, unimplemented: called from here
/local/home/mattsm/git/u-boot/include/common.h:344:12: sorry,
unimplemented: inlining failed in call to 'setenv': function body not
available
net.c:519:11: sorry, unimplemented: called from here
make[2]: *** [net.o] Error 1
make[1]: *** [net/libnet.o] Error 2
cmd_net.c: In function 'netboot_common':
/local/home/mattsm/git/u-boot/include/common.h:344:12: sorry,
unimplemented: inlining failed in call to 'setenv': function body not
available
cmd_net.c:138:10: sorry, unimplemented: called from here
-M
>
> 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
> Substitute "damn" every time you're inclined to write "very"; your
> editor will delete it and the writing will be just as it should be.
> - Mark Twain
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PULL] u-boot-usb/master
Dear McClintock Matthew-B29882,
[...]
> I think this merge is causing issues. Resetting to the previous merge
> (ad8439d Merge branch 'sf' of git://git.denx.de/u-boot-blackfin) and
> the issues go away.
>
> -M
>
> Generating include/generated/asm-offsets.h
> bootm.c:329:16: error: expected ')' before '__attribute__'
> bootm.c:329:25: error: expected identifier or '(' before ')' token
> bootm.c:59:13: warning: 'boot_jump_linux' defined but not used
> bootm.c:177:13: warning: 'boot_prep_linux' defined but not used
> bootm.c:249:12: warning: 'boot_body_linux' defined but not used
> make[2]: *** [bootm.o] Error 1
> make[2]: *** Waiting for unfinished jobs
> fm.c: In function 'fm_init_common':
> /local/home/mattsm/git/u-boot/include/common.h:344:12: sorry,
> unimplemented: inlining failed in call to 'setenv': function body not
> available
> fm.c:420:8: sorry, unimplemented: called from here
> make[2]: *** [fm.o] Error 1
> make[2]: *** Waiting for unfinished jobs
> make[1]: *** [arch/powerpc/lib/libpowerpc.o] Error 2
> make[1]: *** Waiting for unfinished jobs
> make[1]: *** [drivers/net/fm/libfm.o] Error 2
> bootp.c: In function 'DhcpHandler':
> /local/home/mattsm/git/u-boot/include/common.h:344:12: sorry,
> unimplemented: inlining failed in call to 'setenv': function body not
> available
> bootp.c:119:9: sorry, unimplemented: called from here
> make[2]: *** [bootp.o] Error 1
> make[2]: *** Waiting for unfinished jobs
> net.c: In function 'NetLoop':
> /local/home/mattsm/git/u-boot/include/common.h:344:12: sorry,
> unimplemented: inlining failed in call to 'setenv': function body not
> available
> net.c:516:11: sorry, unimplemented: called from here
> /local/home/mattsm/git/u-boot/include/common.h:344:12: sorry,
> unimplemented: inlining failed in call to 'setenv': function body not
> available
> net.c:519:11: sorry, unimplemented: called from here
> make[2]: *** [net.o] Error 1
> make[1]: *** [net/libnet.o] Error 2
> cmd_net.c: In function 'netboot_common':
> /local/home/mattsm/git/u-boot/include/common.h:344:12: sorry,
> unimplemented: inlining failed in call to 'setenv': function body not
> available
> cmd_net.c:138:10: sorry, unimplemented: called from here
[...]
What compiler and what board did you test this with?
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 2/4] kirkwood: implement kw_sdram_bs_set()
> -Original Message-
> From: Holger Brunck [mailto:holger.bru...@keymile.com]
> Sent: 20 July 2012 18:04
> To: u-boot@lists.denx.de
> Cc: Gerlando Falauto; Holger Brunck; Prafulla Wadaskar; Valentin
> Longchamp; Marek Vasut
> Subject: [PATCH v3 2/4] kirkwood: implement kw_sdram_bs_set()
>
> From: Gerlando Falauto
>
> Some boards might be equipped with different SDRAM configurations.
> When that is the case, CPU CS Window Size Register (CS[0]n Size)
> should be set to the biggest value through board.cfg file; then its
> value can be fixed at runtime according to the detected SDRAM size.
>
> Therefore, implement kw_sdram_bs_set().
>
> Signed-off-by: Gerlando Falauto
> Signed-off-by: Holger Brunck
> cc: Prafulla Wadaskar
> cc: Valentin Longchamp
> cc: Marek Vasut
> ---
> changes for v3:
> - remove reviewed by, because there are some chages in
> - use c-struct instead of defines
> - make kw_sdram_bs_set static
> changes for v2:
> - added Reviewed-by: Marek Vasut
>
> arch/arm/cpu/arm926ejs/kirkwood/dram.c | 24
>
> 1 files changed, 24 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/cpu/arm926ejs/kirkwood/dram.c
> b/arch/arm/cpu/arm926ejs/kirkwood/dram.c
> index 1c5faab..5e2f9d8 100644
> --- a/arch/arm/cpu/arm926ejs/kirkwood/dram.c
> +++ b/arch/arm/cpu/arm926ejs/kirkwood/dram.c
> @@ -39,6 +39,11 @@ struct kw_sdram_addr_dec {
> struct kw_sdram_banksdram_bank[4];
> };
>
> +#define KW_REG_CPUCS_WIN_ENABLE (1 << 0)
> +#define KW_REG_CPUCS_WIN_WR_PROTECT (1 << 1)
> +#define KW_REG_CPUCS_WIN_WIN0_CS(x) (((x) & 0x3) << 2)
> +#define KW_REG_CPUCS_WIN_SIZE(x) (((x) & 0xff) << 24)
> +
> /*
> * kw_sdram_bar - reads SDRAM Base Address Register
> */
> @@ -57,6 +62,25 @@ u32 kw_sdram_bar(enum memory_bank bank)
> }
>
> /*
> + * kw_sdram_bs_set - writes SDRAM Bank size
> + */
> +static void kw_sdram_bs_set(enum memory_bank bank, u32 size)
> +{
> + struct kw_sdram_addr_dec *base =
> + (struct kw_sdram_addr_dec *)KW_REGISTER(0x1500);
> + /* Read current register value */
> + u32 reg = readl(&base->sdram_bank[bank].win_sz);
> +
> + /* Clear window size */
> + reg &= ~KW_REG_CPUCS_WIN_SIZE(0xFF);
> +
> + /* Set new window size */
> + reg |= KW_REG_CPUCS_WIN_SIZE((size - 1) >> 24);
> +
> + writel(reg, &base->sdram_bank[bank].win_sz);
> +}
> +
> +/*
> * kw_sdram_bs - reads SDRAM Bank size
> */
> u32 kw_sdram_bs(enum memory_bank bank)
> --
Acked-by: Prafulla Wadaskar
Regards...
Prafulla . . .
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 3/4] kirkwood: implement kw_sdram_size_adjust
> -Original Message-
> From: Holger Brunck [mailto:holger.bru...@keymile.com]
> Sent: 20 July 2012 18:04
> To: u-boot@lists.denx.de
> Cc: Gerlando Falauto; Holger Brunck; Prafulla Wadaskar; Valentin
> Longchamp; Marek Vasut
> Subject: [PATCH v3 3/4] kirkwood: implement kw_sdram_size_adjust
>
> From: Gerlando Falauto
>
> Size of the SDRAM chips might differ between any two (otherwise
> identical) instances of the same board. So add a function which reads
> out the current ram size and set them in the SDRAM size register of
> kirkwood.
>
> Signed-off-by: Gerlando Falauto
> Signed-off-by: Holger Brunck
> cc: Prafulla Wadaskar
> cc: Valentin Longchamp
> cc: Marek Vasut
> ---
> chages for v3:
> - rename dram_size_fixup to kw_sdramsize_adjust and move them to
> kirkwood/dram.c
>
> changes for v2:
> - rebase to current u-boot-marvell.git master branch
>
> arch/arm/cpu/arm926ejs/kirkwood/dram.c | 11 +++
> arch/arm/include/asm/arch-kirkwood/cpu.h |1 +
> 2 files changed, 12 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/cpu/arm926ejs/kirkwood/dram.c
> b/arch/arm/cpu/arm926ejs/kirkwood/dram.c
> index 5e2f9d8..9f97964 100644
> --- a/arch/arm/cpu/arm926ejs/kirkwood/dram.c
> +++ b/arch/arm/cpu/arm926ejs/kirkwood/dram.c
> @@ -97,6 +97,17 @@ u32 kw_sdram_bs(enum memory_bank bank)
> return result;
> }
>
> +void kw_sdram_size_adjust(void)
I think you must pass bank_id to this function so that one can tune any/all of
the four available DRAM banks.
Regards..
Prafulla . . .
> +{
> + u32 size;
> +
> + /* probe currently equipped RAM size */
> + size = get_ram_size((void *)kw_sdram_bar(0), kw_sdram_bs(0));
> +
> + /* adjust SDRAM window size accordingly */
> + kw_sdram_bs_set(0, size);
> +}
> +
> #ifndef CONFIG_SYS_BOARD_DRAM_INIT
> int dram_init(void)
> {
> diff --git a/arch/arm/include/asm/arch-kirkwood/cpu.h
> b/arch/arm/include/asm/arch-kirkwood/cpu.h
> index d28c51a..128393c 100644
> --- a/arch/arm/include/asm/arch-kirkwood/cpu.h
> +++ b/arch/arm/include/asm/arch-kirkwood/cpu.h
> @@ -159,6 +159,7 @@ void reset_cpu(unsigned long ignored);
> unsigned char get_random_hex(void);
> unsigned int kw_sdram_bar(enum memory_bank bank);
> unsigned int kw_sdram_bs(enum memory_bank bank);
> +void kw_sdram_size_adjust(void);
> int kw_config_adr_windows(void);
> void kw_config_gpio(unsigned int gpp0_oe_val, unsigned int
> gpp1_oe_val,
> unsigned int gpp0_oe, unsigned int gpp1_oe);
> --
> 1.7.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 4/4] arm/km: use kw_sdram_size_adjust to adjust SDRAM size
> -Original Message- > From: Holger Brunck [mailto:holger.bru...@keymile.com] > Sent: 20 July 2012 18:04 > To: u-boot@lists.denx.de > Cc: Holger Brunck; Gerlando Falauto; Prafulla Wadaskar; Valentin > Longchamp; Marek Vasut > Subject: [PATCH v3 4/4] arm/km: use kw_sdram_size_adjust to adjust > SDRAM size > > Some boards may differ only in the SDRAM size. This function allows to > fix the size accordingly and we can use the same u-boot binary for > both > boards. > > Signed-off-by: Holger Brunck > Signed-off-by: Gerlando Falauto > cc: Prafulla Wadaskar > cc: Valentin Longchamp > cc: Marek Vasut > --- > chages for v3: > - new patch > > board/keymile/km_arm/km_arm.c |2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/board/keymile/km_arm/km_arm.c > b/board/keymile/km_arm/km_arm.c > index 2b2ca39..9a616fc 100644 > --- a/board/keymile/km_arm/km_arm.c > +++ b/board/keymile/km_arm/km_arm.c > @@ -250,7 +250,7 @@ int board_early_init_f(void) > tmp = readl(KW_GPIO0_BASE + 4); > writel(tmp & (~KM_KIRKWOOD_SOFT_I2C_GPIOS) , KW_GPIO0_BASE + 4); > #endif > - > + kw_sdram_size_adjust(); If bank_id is considered then this call will change. Regards... Prafulla . . . ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PULL] u-boot-usb/master
On Fri, Jul 20, 2012 at 1:56 PM, Marek Vasut wrote:
> Dear McClintock Matthew-B29882,
>
> [...]
>
>> I think this merge is causing issues. Resetting to the previous merge
>> (ad8439d Merge branch 'sf' of git://git.denx.de/u-boot-blackfin) and
>> the issues go away.
>>
>> -M
>>
>> Generating include/generated/asm-offsets.h
>> bootm.c:329:16: error: expected ')' before '__attribute__'
>> bootm.c:329:25: error: expected identifier or '(' before ')' token
>> bootm.c:59:13: warning: 'boot_jump_linux' defined but not used
>> bootm.c:177:13: warning: 'boot_prep_linux' defined but not used
>> bootm.c:249:12: warning: 'boot_body_linux' defined but not used
>> make[2]: *** [bootm.o] Error 1
>> make[2]: *** Waiting for unfinished jobs
>> fm.c: In function 'fm_init_common':
>> /local/home/mattsm/git/u-boot/include/common.h:344:12: sorry,
>> unimplemented: inlining failed in call to 'setenv': function body not
>> available
>> fm.c:420:8: sorry, unimplemented: called from here
>> make[2]: *** [fm.o] Error 1
>> make[2]: *** Waiting for unfinished jobs
>> make[1]: *** [arch/powerpc/lib/libpowerpc.o] Error 2
>> make[1]: *** Waiting for unfinished jobs
>> make[1]: *** [drivers/net/fm/libfm.o] Error 2
>> bootp.c: In function 'DhcpHandler':
>> /local/home/mattsm/git/u-boot/include/common.h:344:12: sorry,
>> unimplemented: inlining failed in call to 'setenv': function body not
>> available
>> bootp.c:119:9: sorry, unimplemented: called from here
>> make[2]: *** [bootp.o] Error 1
>> make[2]: *** Waiting for unfinished jobs
>> net.c: In function 'NetLoop':
>> /local/home/mattsm/git/u-boot/include/common.h:344:12: sorry,
>> unimplemented: inlining failed in call to 'setenv': function body not
>> available
>> net.c:516:11: sorry, unimplemented: called from here
>> /local/home/mattsm/git/u-boot/include/common.h:344:12: sorry,
>> unimplemented: inlining failed in call to 'setenv': function body not
>> available
>> net.c:519:11: sorry, unimplemented: called from here
>> make[2]: *** [net.o] Error 1
>> make[1]: *** [net/libnet.o] Error 2
>> cmd_net.c: In function 'netboot_common':
>> /local/home/mattsm/git/u-boot/include/common.h:344:12: sorry,
>> unimplemented: inlining failed in call to 'setenv': function body not
>> available
>> cmd_net.c:138:10: sorry, unimplemented: called from here
> [...]
>
> What compiler and what board did you test this with?
P4080DS with:
gcc version 4.5.1 (Sourcery G++ Lite 2010.09-55)
-M
> Best regards,
> Marek Vasut
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/2] kirkwood: ib62x0: Invert SATA activity LEDs
The hardware design of the IB-NAS62x0 causes the SATA activity
LEDs to be on when idle by default. Reverse the polarity of the
activity LEDs in early init.
Signed-off-by: Simon Baatz
Cc: Luka Perkov
Cc: Prafulla Wadaskar
---
board/raidsonic/ib62x0/ib62x0.c |3 +++
board/raidsonic/ib62x0/ib62x0.h |4
2 files changed, 7 insertions(+)
diff --git a/board/raidsonic/ib62x0/ib62x0.c b/board/raidsonic/ib62x0/ib62x0.c
index 1164d6b..b7e6e41 100644
--- a/board/raidsonic/ib62x0/ib62x0.c
+++ b/board/raidsonic/ib62x0/ib62x0.c
@@ -23,6 +23,7 @@
#include
#include
+#include
#include
#include
#include
@@ -41,6 +42,8 @@ int board_early_init_f(void)
IB62x0_OE_VAL_HIGH,
IB62x0_OE_LOW, IB62x0_OE_HIGH);
+ /* Set SATA activity LEDs to default off */
+ writel(MVSATAHC_LED_POLARITY_CTRL, MVSATAHC_LED_CONF_REG);
/* Multi-Purpose Pins Functionality configuration */
u32 kwmpp_config[] = {
MPP0_NF_IO2,
diff --git a/board/raidsonic/ib62x0/ib62x0.h b/board/raidsonic/ib62x0/ib62x0.h
index 0c30690..0118c2b 100644
--- a/board/raidsonic/ib62x0/ib62x0.h
+++ b/board/raidsonic/ib62x0/ib62x0.h
@@ -37,4 +37,8 @@
#define MV88E1116_RGMII_TXTM_CTRL (1 << 4)
#define MV88E1116_RGMII_RXTM_CTRL (1 << 5)
+/* SATAHC related */
+#define MVSATAHC_LED_CONF_REG (MV_SATA_BASE + 0x2C)
+#define MVSATAHC_LED_POLARITY_CTRL (1 << 3)
+
#endif /* __IB62x0_H */
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/2] kirkwood: ib62x0: Support flattened devicetree
Support for the IB-NAS62x0 was added to the Linux mainline kernel as of 3.5-rc1 using flattened devicetree. Change the config for this board accordingly. Signed-off-by: Simon Baatz Cc: Luka Perkov Cc: Prafulla Wadaskar --- include/configs/ib62x0.h |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/include/configs/ib62x0.h b/include/configs/ib62x0.h index 85856f2..34c83a4 100644 --- a/include/configs/ib62x0.h +++ b/include/configs/ib62x0.h @@ -37,9 +37,9 @@ #define CONFIG_SKIP_LOWLEVEL_INIT /* disable board lowlevel_init */ /* - * Machine type + * Enable device tree support */ -#define CONFIG_MACH_TYPE MACH_TYPE_NAS6210 +#define CONFIG_OF_LIBFDT /* * Compression configuration -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] common.h: Remove include compiler.h
Remove this as including it on global scale breaks a lot of things. This was reported by: Matthew McClintock Fix found by: Tom Rini Signed-off-by: Marek Vasut Cc: Wolfgang Denk Cc: Tom Rini --- include/common.h |3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/include/common.h b/include/common.h index be9c278..39859d3 100644 --- a/include/common.h +++ b/include/common.h @@ -39,7 +39,6 @@ typedef volatile unsigned charvu_char; #include #include #include -#include #include #include #if defined(CONFIG_PCI) && (defined(CONFIG_4xx) && !defined(CONFIG_AP1000)) @@ -959,7 +958,7 @@ int cpu_release(int nr, int argc, char * const argv[]); */ #define DEFINE_ALIGN_BUFFER(type, name, size, align) \ static char __##name[roundup(size * sizeof(type), align)] \ - __aligned(align); \ + __attribute__((aligned(align))); \ \ static type *name = (type *)__##name #define DEFINE_CACHE_ALIGN_BUFFER(type, name, size)\ -- 1.7.10.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PULL] u-boot-usb/master
Hi, On Fri, Jul 20, 2012 at 10:59 PM, McClintock Matthew-B29882 < b29...@freescale.com> wrote: > On Fri, Jul 20, 2012 at 1:56 PM, Marek Vasut wrote: > > Dear McClintock Matthew-B29882, > > > > [...] > > > >> I think this merge is causing issues. Resetting to the previous merge > >> (ad8439d Merge branch 'sf' of git://git.denx.de/u-boot-blackfin) and > >> the issues go away. > >> > >> -M > >> > >> Generating include/generated/asm-offsets.h > >> bootm.c:329:16: error: expected ')' before '__attribute__' > including breaks __attribute__((noinline)) (has to be changed to noinline). I believe it's enough to fix this file and remove #define noinline from lib/vsprintf.c Regards, Ilya. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PULL] u-boot-usb/master
Dear Ilya Yanok, > Hi, > > On Fri, Jul 20, 2012 at 10:59 PM, McClintock Matthew-B29882 < > > b29...@freescale.com> wrote: > > On Fri, Jul 20, 2012 at 1:56 PM, Marek Vasut wrote: > > > Dear McClintock Matthew-B29882, > > > > > > [...] > > > > > >> I think this merge is causing issues. Resetting to the previous merge > > >> (ad8439d Merge branch 'sf' of git://git.denx.de/u-boot-blackfin) and > > >> the issues go away. > > >> > > >> -M > > >> > > >> Generating include/generated/asm-offsets.h > > >> bootm.c:329:16: error: expected ')' before '__attribute__' > > including breaks __attribute__((noinline)) (has to be > changed to noinline). I believe it's enough to fix this file and remove > #define noinline from lib/vsprintf.c It isn't, but there's a patch that changes __aligned to __attribute__((aligned(...))); and removes compiler.h > Regards, Ilya. Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] common.h: Remove include compiler.h
Dear Marek Vasut, In message <1342815178-32546-1-git-send-email-ma...@denx.de> you wrote: > Remove this as including it on global scale breaks a lot of things. > This was reported by: > Matthew McClintock > > Fix found by: > Tom Rini > > Signed-off-by: Marek Vasut > Cc: Wolfgang Denk > Cc: Tom Rini > --- > include/common.h |3 +-- > 1 file changed, 1 insertion(+), 2 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 Parkinson's Law: Work expands to fill the time alloted it. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Pull request: u-boot-nds32
Dear Macpaul Lin, In message you wrote: > > The following changes since commit 3ec81d758c09d6887a77a1b1259d044a2905bc8e: > > Merge branch 'master' of git://git.denx.de/u-boot-usb (2012-07-20 > 09:12:43 +0200) > > are available in the git repository at: > > > git://git.denx.de/u-boot-nds32.git master > > for you to fetch changes up to 8d732840ba1cd4d41c12242ba07f1cf58b6429bf: > > nds32: split common cache access from cpu into lib (2012-07-20 23:55:52 > +0800) > > > Macpaul Lin (1): > nds32: split common cache access from cpu into lib > > arch/nds32/cpu/n1213/ag101/cpu.c | 112 > arch/nds32/cpu/n1213/ag102/cpu.c | 112 > arch/nds32/lib/Makefile | 2 +- > arch/nds32/lib/cache.c | 157 > +++ > 4 files changed, 158 insertions(+), 225 deletions(-) > create mode 100644 arch/nds32/lib/cache.c Applied, thanks. > --bcaec554de605b34b304c5450bb9 > Content-Type: text/html; charset=ISO-8859-1 > Content-Transfer-Encoding: quoted-printable Please, do NOT send HTML!!! 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 Gewöhnlich glaubt der Mensch, wenn er nur Worte hört, es müsse sich dabei doch auch was denken lassen. -- Goethe, Faust I ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Pull request: ub-oot-arm/master
Dear Albert ARIBAUD, In message <20120720142924.5b4c8b4e@aari01-12> you wrote: > > git://git.denx.de/u-boot-arm master > > for you to fetch changes up to a21c65115bd95572cc80092a31b0e9ecb8710e9f: > > ARM: lib: Remove CONFIG_ARCH_CPU_INIT dependency (2012-07-20 14:24:08 > +0200) > > > Fabio Estevam (1): > ARM: lib: Remove CONFIG_ARCH_CPU_INIT dependency > > SRICHARAN R (1): > ARM: OMAP4: PANDA: Add rest of the USB module pads to essentials > > Tetsuyuki Kobayashi (1): > arm: armv7: add compile option -mno-unaligned-access if available > > Zhong Hongbo (1): > arm: Fix to mistake clean the memory space > > arch/arm/cpu/arm1136/start.S|8 --- > arch/arm/cpu/arm1176/start.S|9 > arch/arm/cpu/arm720t/start.S|8 --- > arch/arm/cpu/arm920t/start.S|8 --- > arch/arm/cpu/arm925t/start.S|8 --- > arch/arm/cpu/arm946es/start.S |8 --- > arch/arm/cpu/arm_intcm/start.S |8 --- > arch/arm/cpu/armv7/config.mk|2 ++ > arch/arm/cpu/armv7/start.S |8 --- > arch/arm/cpu/ixp/start.S|8 --- > arch/arm/cpu/lh7a40x/start.S|8 --- > arch/arm/cpu/pxa/start.S|8 --- > arch/arm/cpu/s3c44b0/start.S|8 --- > arch/arm/cpu/sa1100/start.S |8 --- > arch/arm/lib/board.c| 10 +++-- > board/ti/panda/panda_mux_data.h | 44 > +++ 16 files changed, 97 > insertions(+), 64 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 The software required `Windows 95 or better', so I installed Linux. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/2] powerpc/mpc85xx: Enable workaround for erratum CPU_A011 for P3041
P3041 was left out in previous commit 5e23ab0a. Erratum NMG_CPU_A011 applies to P4080 rev 1.0, 2.0, fixed in rev 3.0. It also applies to P3041 rev 1.0, 1.1, P2041 rev 1.0, 1.1. Signed-off-by: York Sun --- arch/powerpc/include/asm/config_mpc85xx.h |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/arch/powerpc/include/asm/config_mpc85xx.h b/arch/powerpc/include/asm/config_mpc85xx.h index 1d21ee8..8154df0 100644 --- a/arch/powerpc/include/asm/config_mpc85xx.h +++ b/arch/powerpc/include/asm/config_mpc85xx.h @@ -385,6 +385,7 @@ #define CONFIG_SYS_FSL_USB_INTERNAL_UTMI_PHY #define CONFIG_SYS_FSL_ERRATUM_ESDHC111 #define CONFIG_SYS_FSL_ERRATUM_USB138 +#define CONFIG_SYS_FSL_ERRATUM_NMG_CPU_A011 #define CONFIG_SYS_FSL_ERRATUM_CPU_A003999 #define CONFIG_SYS_FSL_ERRATUM_DDR_A003474 #define CONFIG_SYS_FSL_SRIO_MAX_PORTS 2 -- 1.7.0.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-imx for v2012.07
Hi Stefano, On Thu, 19 Jul 2012 09:15:58 +0200, Stefano Babic wrote: > Hi Albert, > > please pull from u-boot-imx, thanks. > > The following changes since commit 444def73695103c4aca06a70e9f4de9a5e6df28a: > > ARM: OMAP4: PANDA: Add rest of the USB module pads to essentials > (2012-07-19 00:03:34 +0200) > > are available in the git repository at: > > git://www.denx.de/git/u-boot-imx.git master > > for you to fetch changes up to 7c5f5118c70fd463df2fc131bd48e9769097e92f: > > mx6: Make pad name macro consistent with the datasheet (2012-07-19 > 09:11:04 +0200) > > > Anatolij Gustschin (1): > mx28: Fix elftosb source link in README.mx28_common > > Ashok (1): > mx6: Make pad name macro consistent with the datasheet > > Fabio Estevam (1): > doc: README.mx28_common: Add missing entry into Contents > > arch/arm/include/asm/arch-mx6/mx6x_pins.h |4 ++-- > doc/README.mx28_common|9 + > 2 files changed, 7 insertions(+), 6 deletions(-) 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
[U-Boot] Pull request #2: u-boot-arm/master
Hi Wolfgang, The following changes since commit a21c65115bd95572cc80092a31b0e9ecb8710e9f: ARM: lib: Remove CONFIG_ARCH_CPU_INIT dependency (2012-07-20 14:24:08 +0200) are available in the git repository at: git://git.denx.de/u-boot-arm master for you to fetch changes up to 6b8ac524e7bcfd4853bb4f494e539a63d894a46f: mx6: Make pad name macro consistent with the datasheet (2012-07-20 23:03:28 +0200) Anatolij Gustschin (1): mx28: Fix elftosb source link in README.mx28_common Ashok (1): mx6: Make pad name macro consistent with the datasheet Fabio Estevam (1): doc: README.mx28_common: Add missing entry into Contents arch/arm/include/asm/arch-mx6/mx6x_pins.h |4 ++-- doc/README.mx28_common|9 + 2 files changed, 7 insertions(+), 6 deletions(-) Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Notes from the U-Boot BOF Meeting in Geneva 2012/07/12
Dear Kim Phillips, > On Mon, 16 Jul 2012 23:30:49 +0200 > > Detlev Zundel wrote: > > as promised, here are my expanded notes from the BoF meeting at LSM2012 > > last week. It was a pleasure to get some core developers into one room > > Any word on Kconfig support? > > Kim I was digging in it for a bit, but then Graeme took over. Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 5/7] dfu:cmd: Support for DFU u-boot command
Dear Mike Frysinger, > On Friday 20 July 2012 07:33:49 Marek Vasut wrote: > > Dear Mike Frysinger, > > > > > On Wednesday 04 July 2012 10:39:20 Marek Vasut wrote: > > > > > Putting there the __func__ name would improve structure and speed > > > > > up finding right place. > > > > > > > > And if you want to use even __LINE__, look up __stringify patch in > > > > the ML archives ;-) > > > > > > ugh, no, let's not use __LINE__ anywhere other than debug(). it has no > > > business in code we ship as it is pointless bloated noise. > > > > Helps find out the problematic place in code ... > > except the code changes thus invalidating the line numbers, and how often > are you putting the same string in multiple places that you can't easily > coordinate where it came from ? if people are using the same exact string > in multiple places, that sounds like a different problem. You can always replace the function names with macros, which expand in place. And then simply add __func__ __LINE__ __FILE__ etc. > -mike Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] mpc85xx: Initial SP alignment is wrong.
On 07/20/2012 04:20 AM, Joakim Tjernlund wrote: > PowerPC mandates SP to be 16 bytes aligned. > Furthermore, a stack frame is added, pointing to the reset vector > which is just get in the way when gdb is walking the stack because > the reset vector may not accessible depending on emulator settings. > Also use a temp register so gdb doesn't pick up intermediate values. > > Signed-off-by: Joakim Tjernlund > --- > arch/powerpc/cpu/mpc85xx/start.S | 16 +--- > 1 files changed, 5 insertions(+), 11 deletions(-) > > diff --git arch/powerpc/cpu/mpc85xx/start.S arch/powerpc/cpu/mpc85xx/start.S > index 8d66cf1..8c75af9 100644 > --- arch/powerpc/cpu/mpc85xx/start.S > +++ arch/powerpc/cpu/mpc85xx/start.S > @@ -848,18 +848,12 @@ version_string: > .globl _start_cont > _start_cont: > /* Setup the stack in initial RAM,could be L2-as-SRAM or L1 dcache*/ > - lis r1,CONFIG_SYS_INIT_RAM_ADDR@h > - ori r1,r1,CONFIG_SYS_INIT_SP_OFFSET@l > - > + lis r2,(CONFIG_SYS_INIT_RAM_ADDR)@h > + ori r2,r2,((CONFIG_SYS_INIT_SP_OFFSET-16)&~0xf)@l /* Align to 16 */ Please don't use r2 as a general purpose register -- even if it's early enough that we haven't started using it for its fixed purpose yet. > + stw r0,-4(r2) /* Store a NULL LR */ > + stw r0,0(r2)/* Store a NULL Back Chain */ > + mr r1,r2 /* Transfer to SP(r1) */ Why are you storing anything below the stack pointer? LR goes above the backchain, not below -- and it's not valid anyway for the current stack frame. If you want to have a terminating stack frame with a NULL LR, you need to create a second stack frame, like the code currently does. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] powerpc: Stack Pointer must be 16 aligned
On 07/20/2012 04:20 AM, Joakim Tjernlund wrote: > The PowerPC ABI mandates the SP to be 16 bytes aligned, make is so. > > Signed-off-by: Joakim Tjernlund > --- > arch/powerpc/lib/board.c |5 ++--- > 1 files changed, 2 insertions(+), 3 deletions(-) > > diff --git arch/powerpc/lib/board.c arch/powerpc/lib/board.c > index d5b75e5..dc7cc40 100644 > --- arch/powerpc/lib/board.c > +++ arch/powerpc/lib/board.c > @@ -521,9 +521,8 @@ void board_init_f(ulong bootflag) > addr_sp -= 16; > addr_sp &= ~0xF; > s = (ulong *) addr_sp; > - *s-- = 0; > - *s-- = 0; > - addr_sp = (ulong) s; > + *s = 0; /* NULL Back Chain */ > + *--s = 0; /* NULL LR */ Same problems as in patch 2/2. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/2] powerpc/mpc85xx: Ignore E bit for BSC9130/1
Commit 48f6a5c34 removed E bit. BSC9130/1 were left out due to patch apply timing. Remove them now. Signed-off-by: York Sun --- arch/powerpc/include/asm/processor.h |2 -- 1 files changed, 0 insertions(+), 2 deletions(-) diff --git a/arch/powerpc/include/asm/processor.h b/arch/powerpc/include/asm/processor.h index 489dd61..7bd3789 100644 --- a/arch/powerpc/include/asm/processor.h +++ b/arch/powerpc/include/asm/processor.h @@ -1104,9 +1104,7 @@ #define SVR_8641D 0x809001 #define SVR_9130 0x860001 -#define SVR_9130_E 0x860801 #define SVR_9131 0x86 -#define SVR_9131_E 0x860800 #define SVR_Unknown0xFF -- 1.7.0.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Notes from the U-Boot BOF Meeting in Geneva 2012/07/12
Hi Kim & Marek, On 07/21/2012 07:09 AM, Marek Vasut wrote: > Dear Kim Phillips, > >> On Mon, 16 Jul 2012 23:30:49 +0200 >> >> Detlev Zundel wrote: >>> as promised, here are my expanded notes from the BoF meeting at LSM2012 >>> last week. It was a pleasure to get some core developers into one room >> >> Any word on Kconfig support? >> >> Kim > > I was digging in it for a bit, but then Graeme took over. I have started on it - I've ported over the Kbuild infrastructure into a dedicated 'kbuild' makefile which is called from the main makefile. This make modifications to the existing makefile very minimal Now it's just a case of building all the Kconfig files which is, to say the least, a massive task. I have a lot of other things going on, so unfortunately progress is slow Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Notes from the U-Boot BOF Meeting in Geneva 2012/07/12
On 07/20/2012 04:34 PM, Graeme Russ wrote: > Hi Kim & Marek, > > On 07/21/2012 07:09 AM, Marek Vasut wrote: >> Dear Kim Phillips, >> >>> On Mon, 16 Jul 2012 23:30:49 +0200 >>> >>> Detlev Zundel wrote: as promised, here are my expanded notes from the BoF meeting at LSM2012 last week. It was a pleasure to get some core developers into one room >>> >>> Any word on Kconfig support? >>> >>> Kim >> >> I was digging in it for a bit, but then Graeme took over. > > I have started on it - I've ported over the Kbuild infrastructure into a > dedicated 'kbuild' makefile which is called from the main makefile. This > make modifications to the existing makefile very minimal > > Now it's just a case of building all the Kconfig files which is, to say the > least, a massive task. I have a lot of other things going on, so > unfortunately progress is slow How about a transitional phase, where a symbol can either be a kconfig symbol or handled the old way via the board config file? That way, custodians/maintainers could handle the conversion of their own symbols (with the expectation that this be done within a reasonable timeframe). -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] common.h: Introduce DEFINE_CACHE_ALIGN_BUFFER
On Friday 20 July 2012 07:31:47 Marek Vasut wrote: > Dear Mike Frysinger, > > On Saturday 07 July 2012 23:08:14 Marek Vasut wrote: > > > +/* > > > DEFINE_CACHE_ALIGN_BUFFER() is similar to ALLOC_CACHE_ALIGN_BUFFER, > > > but it's purpose is to allow allocating aligned buffers outside of > > > function scope. Usage of this macro shall be avoided or used with > > > extreme care! */ > > > +#define DEFINE_CACHE_ALIGN_BUFFER(type, name, size) > > > + static char __##name[roundup(size * sizeof(type), ARCH_DMA_MINALIGN)] > > > + __aligned(ARCH_DMA_MINALIGN); > > > + static type *name = (type *)__##name; > > > > how is this any different from doing: > > static __u8 foo[1234] __aligned(ARCH_DMA_MINALIGN); > > Does __aligned() align both start of the buffer downwards and end of it > upwards ? it guarantees the start is aligned. i don't believe it does any tail padding. that said, you've added just 1 consumer, but it uses in function scope, so i don't see why you had to define a new helper in the first place. the existing one would work fine shouldn't it ? you should probably add a const to the 2nd part so gcc is more likely to optimize away the storage: static type * const name = (type *)__##name; otherwise older gcc versions will create a pointer to go through rather than having things directly access the buffer. w/out const: $ readelf -s a.out | grep foo 11: 004005d0 8 OBJECT LOCAL DEFAULT 13 foo.1592 12: 0040208096 OBJECT LOCAL DEFAULT 25 __foo.1591 w/const: $ readelf -s a.out | grep foo 11: 0040208096 OBJECT LOCAL DEFAULT 25 __foo.1591 -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] common.h: Introduce DEFINE_CACHE_ALIGN_BUFFER
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/20/2012 02:47 PM, Mike Frysinger wrote: > On Friday 20 July 2012 07:31:47 Marek Vasut wrote: >> Dear Mike Frysinger, >>> On Saturday 07 July 2012 23:08:14 Marek Vasut wrote: +/* DEFINE_CACHE_ALIGN_BUFFER() is similar to ALLOC_CACHE_ALIGN_BUFFER, but it's purpose is to allow allocating aligned buffers outside of function scope. Usage of this macro shall be avoided or used with extreme care! */ +#define DEFINE_CACHE_ALIGN_BUFFER(type, name, size) + static char __##name[roundup(size * sizeof(type), ARCH_DMA_MINALIGN)] + __aligned(ARCH_DMA_MINALIGN); + static type *name = (type *)__##name; >>> >>> how is this any different from doing: static __u8 foo[1234] >>> __aligned(ARCH_DMA_MINALIGN); >> >> Does __aligned() align both start of the buffer downwards and end >> of it upwards ? > > it guarantees the start is aligned. i don't believe it does any > tail padding. > > that said, you've added just 1 consumer, but it uses in function > scope, so i don't see why you had to define a new helper in the > first place. the existing one would work fine shouldn't it ? The rough outline of the problems are: - - We need to have buffers that are multiple of cache size, for clearing. - - Today we know ehci-hcd had a problem. We also know other drivers / layers have problems, but they aren't as readily breakable. That's why we put the macro in rather than a USB header. - -- Tom -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJQCdKoAAoJENk4IS6UOR1WuzUP/0ndUzaq6U2/8X8E7VIhLqAV AQ+5rmJy5seJAhhvzRLbNgYv7KrLJRayMd4bj4DT8WAmAyUDo1BPvIcKNuQ8Il3M un3Kjo9+qXusfyvbs1V2wOaXL1pmwcOSQe4n+/8xKlmJ3Jh9v1AIBoXIJQqXPrcL zhaN0ilxTcLeblFWVzXSOWPAWo4ufJZ1cd43lGXxtjW890GEUCRTNXod9Bpivi2P ShycGvEcvo80mR7xGKMjZYl9Zf5OQ5QP0Xcvul7X4rjGepEuOsn941wE0zrP1I+s zXfruOklqWBckiP+aBprX2lzsaBUE33hHZidfPtvuB9rTFk735snaDcrZsL/5K25 17Bczpqqb6RXP1yb/tpc1hWkzpfCZ+eqpg2pN8bIp0P8XZ5apMTvq7L9IMG90lN2 FPwOC2VH9gnOK34Est/iTkp6QnW15r/ZayD9DMBUoxelhx38VJHR8OVyu56QXk2K 10zb6lwKQ3dE8u24ki2TybycVgPVoOq35vUjMw7TWZwiwXSBwgcfHMRukpTSdHA6 wNzw+VsurehKdkqRBeG5tOeOf0tcFrKfg1tfyDQqlBJUn9E6Usj43IXfF23DOQ11 VMcMeizuHP6oTmBk571XrgOKczCaUej1UIrLhnfpXNmFsQ7YsIi9PlQcndFiMBLC yo+rfRjqLqrPxJdrP5h4 =alD6 -END PGP SIGNATURE- ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Notes from the U-Boot BOF Meeting in Geneva 2012/07/12
Hi Scott, On 07/21/2012 07:40 AM, Scott Wood wrote: > On 07/20/2012 04:34 PM, Graeme Russ wrote: >> Hi Kim & Marek, >> >> On 07/21/2012 07:09 AM, Marek Vasut wrote: >>> Dear Kim Phillips, >>> On Mon, 16 Jul 2012 23:30:49 +0200 Detlev Zundel wrote: > as promised, here are my expanded notes from the BoF meeting at LSM2012 > last week. It was a pleasure to get some core developers into one room Any word on Kconfig support? Kim >>> >>> I was digging in it for a bit, but then Graeme took over. >> >> I have started on it - I've ported over the Kbuild infrastructure into a >> dedicated 'kbuild' makefile which is called from the main makefile. This >> make modifications to the existing makefile very minimal >> >> Now it's just a case of building all the Kconfig files which is, to say the >> least, a massive task. I have a lot of other things going on, so >> unfortunately progress is slow > > How about a transitional phase, where a symbol can either be a kconfig > symbol or handled the old way via the board config file? That way, > custodians/maintainers could handle the conversion of their own symbols > (with the expectation that this be done within a reasonable timeframe). Well the plan in to have 'make xyz_config' produce the equivalent .config file (which it pretty much does anyway) - You can then use Kconfig to tweak the board config Or use Kconfig to create a config from scratch Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Notes from the U-Boot BOF Meeting in Geneva 2012/07/12
On Wed, Jul 18, 2012 at 09:21:40AM +0200, Wolfgang Denk wrote: [snip] > And Jenkins... well, we have been using this for some time internally > to run test builds for U-Boot. I can tell you a thing or two about > it, and Marek has his own story to tell about his experiences when he > added to the build matrix. > > As is, we try hard to get rid of Jenkins, because it does not scale > well to the type of builds we want to be able to do. Marek even > started setting up his own test build framework... I told Marek on IRC that I don't understand this, given a lot of the things I've made Jenkins do before and that at the end of the day it's $whatever-pass/fail-logic on top of a bash script to do the building and testing. -- Tom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Notes from the U-Boot BOF Meeting in Geneva 2012/07/12
Dear Tom Rini, > On Wed, Jul 18, 2012 at 09:21:40AM +0200, Wolfgang Denk wrote: > > [snip] > > > And Jenkins... well, we have been using this for some time internally > > to run test builds for U-Boot. I can tell you a thing or two about > > it, and Marek has his own story to tell about his experiences when he > > added to the build matrix. > > > > As is, we try hard to get rid of Jenkins, because it does not scale > > well to the type of builds we want to be able to do. Marek even > > started setting up his own test build framework... > > I told Marek on IRC that I don't understand this, given a lot of the > things I've made Jenkins do before and that at the end of the day it's > $whatever-pass/fail-logic Not really, what about the warning-logic ? Aka. I actually need jenkins to do tristate results. How, I didn't figure out. > on top of a bash script to do the building and > testing. So in the end, jenkins is just an executor, bringing in pile of java overhead and possible random breakage. I use MAKEALL in my script, which does exactly what I need ... and even tests MAKEALL ;-) Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Notes from the U-Boot BOF Meeting in Geneva 2012/07/12
Hi All, On 07/21/2012 11:27 AM, Marek Vasut wrote: > Dear Tom Rini, > >> On Wed, Jul 18, 2012 at 09:21:40AM +0200, Wolfgang Denk wrote: >> >> [snip] >> >>> And Jenkins... well, we have been using this for some time internally >>> to run test builds for U-Boot. I can tell you a thing or two about >>> it, and Marek has his own story to tell about his experiences when he >>> added to the build matrix. >>> >>> As is, we try hard to get rid of Jenkins, because it does not scale >>> well to the type of builds we want to be able to do. Marek even >>> started setting up his own test build framework... >> >> I told Marek on IRC that I don't understand this, given a lot of the >> things I've made Jenkins do before and that at the end of the day it's >> $whatever-pass/fail-logic > > Not really, what about the warning-logic ? Aka. I actually need jenkins to do > tristate results. How, I didn't figure out. > >> on top of a bash script to do the building and >> testing. > > So in the end, jenkins is just an executor, bringing in pile of java overhead > and possible random breakage. I use MAKEALL in my script, which does exactly > what I need ... and even tests MAKEALL ;-) I don't think a protracted 'tool x' doesn't do this and 'tool y' doesn't do that is going to get us anywhere. What we need to do is define exactly what we want out of the patch management, automated build, etc. tools. We can then see if there are any tools which already exist which fit our needs. If no existing tools fit, look at the ones that come closest and investigate what would be required to get them to a state that they would. We already know that git is a perfect fit for source code management, and the mailing list is how we will continue to submit, review and discuss patches. So that gives a good starting point. Patch Management: - Integrate with existing email work flow. It must pick up patches from the mailing list, and any output it generates must get posted to the mailing list - Reliably track revisions of patches (mark superseded version as such) - Automatically run sanity checks (checkpatch, test apply, etc.) - Track which repo patches below to - Rerun sanity checks on unapplied patches when new patches are applied to the associated repo - Track patch pre-requisite requirements (need to specify such requirments in the patch itself) - Track ack'd, nack'd, tested, etc, posted to the mailing list - Group multi-patch sets and retain the 0/x patch as it usually contains relevant information Automatic Build: - Nightly MAKEALL with output sent to mailing list (only need to run if a new patch has been applied) - MAKEALL against each repo - Automatic build test of patches which pass through the sanity checks of the patch management tool. This one is really tricky as a MAKEALL for each patch posted to the ML is going to require too many CPU cycles. We need a way to determine what configurations a particular patch is going to impact and only test against them Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
