Re: [U-Boot] Please pull u-boot-ti/next
Le 19/09/2011 01:39, s-paul...@ti.com a écrit : > Please pull u-boot-ti/next. > I checked all the patches for checkpatch errors. > Also all OMAP3 and OMAP4 built with no issues. > > Thanks, > Sandeep > > The following changes since commit 3522ad62864669b335b85f5abcd136a84bbb7519: >Ajay Bhargav (1): > Armada100: Enable 88E3015 PHY support for GplugD > > are available in the git repository at: > >git://git.denx.de/u-boot-ti.git next > > Philip Balister (2): >OMAP3: Overo: Update GPMC timing for ethernet chip >overo: Set IEN on GPMC_CLK to support synchronous clocking. > > Sandeep Paulraj (1): >devkit8000: Fix build break > > Simon Schwarz (9): >omap-common/omap4: relocate early UART clock setup >omap3: Configure RAM bank 0 if in SPL >omap-common: add nand spl support >spl: add NAND Library to new SPL >spl: Add POWER library to new spl >omap3: new SPL structure support >devkit8000: Add nand-spl support for new SPL >omap3: implement boot parameter saving >omap-common: reorganize spl.c Applied to u-boot-arm/next (and then rebased above current u-boot/master), thanks! (reminder: this causes a regression in orphan board smdk6400. If no new board maintainer steps in and fixes it before 2011-12 release, the board will be removed) Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] SMDK6400 regression (was: Please pull u-boot-ti/next)
Le 19/09/2011 16:21, Paulraj, Sandeep a écrit : > > >> >> Hi Wofgang, >> >> Le 19/09/2011 09:47, Wolfgang Denk a écrit : >>> Dear Albert ARIBAUD, >>> >>> In message<4e76ebfd.9060...@aribaud.net> you wrote: As this is your 'next' branch, there is an ambiguity: can you please indicate if you want me to pull this into my 'next' or 'master' branch? If on master, I assume you want me to also send out a pull request to Wolfgang, but I am not sure Wolfgang will allow it at this time. >>> >>> If I understand correctly this is mostly fixes, so I'd take it. >> >> Sandeep's 'next' branch is based on my 'next', not on my 'master', hence >> my question -- there would have to be a rebase if Sandeep expected me to >> pull into my master. >> >> Sandeep, can you confirm what you want exactly? Meanwhile, I am >> launching regression builds on u-boot-ti/next, just in case. >> > Albert, > > The pull request if for your next branch. Thanks a lot. There is a regression in u-boot-ti/next with respect to u-boot-arm/next, on board smdk6400, causing the following build failure: s3c64xx.c:80: error: static declaration of 'nand_read_buf' follows non-static declaration /home/uboot/src/u-boot-arm/include/nand.h:139: error: previous declaration of 'nand_read_buf' was here Git bisect finds commit 55f429bb39614a16b1bacc9a8bea9ac01a60bfc8 is the cause of the regression. Copying Simon as the author of the commit, in order to confirm that the issue is in smdk6400. If so, as MAINTAINERS has smdk marked orphaned and its former maintainer resigned, I take the ti/next branch in as it is, and if no one steps in as a maintainer for SMDK6400 before end of the 2011-12 releaése merge window, I will then apply a board removal patch for it. > Thanks, > Sandeep Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] start.S
From: Marek Vasut To: u-boot@lists.denx.de; maheen butt Cc: Christopher Harvey Sent: Tuesday, September 20, 2011 10:45 AM Subject: Re: [U-Boot] start.S On Tuesday, September 20, 2011 07:02:15 AM maheen butt wrote: > my target board is mips so > which part > of start.S jump to c code? and what is first function comes after start.S? 1) Please stop top-posting ... 2) board_init_f seems like it. > > what is it in case of ARM? board_init_f as well. They seem to be in arch/[family]/lib/ Thanks for your response! I searched board_init_f() it calls relocate_code() about which it has been commented that it does not return. my question is here that from relocate_code() control goes where? as I'm not able to find relocat_code() defined any where in C code its only declared in /u-boot/include/common.h( I found only its prototype) did it comes back in start.S? as I saw relocate_code assembly instruction in start.S.___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] armv7: only call save_boot_params for OMAP
Hi Simon, On Monday 19 September 2011 01:32 PM, Simon Schwarz wrote: > Hi Aneesh, > > I did this Patch because of an error with an SPL build of smdkv310. > > This board doesn't even build with the normal configuration but the SPL > patches add more errors (I did some BUILDALL testing). > > So the question: Should we care for an already broken board or just > leave the matter to the poor guy who will, in some distant future, fix > the other problems of this board? > I think we need to fix this issue anyway. There may be new SPLs that do not care about saving boot parameters. I can fix this in my next series. regards, Aneesh > Regards > Simon > > > On 09/16/2011 06:13 PM, Aneesh V wrote: >> Hi Simon, >> >> On Friday 16 September 2011 09:02 PM, Simon Schwarz wrote: >>> save_boot_params in start.S got called for all armv7 based cpus. >>> Since the >>> function relys on the OMAP specific bootloader this broke some boards >>> (or to be specific added more errors to already broken ones). This patch >>> wraps the call in #ifdef CONFIG_OMAP. >> >> There is a weakly linked default function implemented in armv7/cpu.c. >> So, there should not be any build break for u-boot builds. >> >> However armv7/cpu.c is not included in an SPL build, so may cause >> trouble for SPL build of non-OMAP boards. The solution for this problem >> is the following: >> >> --- a/arch/arm/cpu/armv7/Makefile >> +++ b/arch/arm/cpu/armv7/Makefile >> @@ -29,9 +29,9 @@ START := start.o >> >> ifndef CONFIG_SPL_BUILD >> COBJS += cache_v7.o >> -COBJS += cpu.o >> endif >> >> +COBJS += cpu.o >> COBJS += syslib.o >> >> SRCS := $(START:.o=.S) $(COBJS:.o=.c) >> >> Let me know if I am missing something. >> >> best regards, >> Aneesh >> >> >>> >>> Signed-off-by: Simon Schwarz >>> --- >>> arch/arm/cpu/armv7/start.S |2 ++ >>> 1 files changed, 2 insertions(+), 0 deletions(-) >>> >>> diff --git a/arch/arm/cpu/armv7/start.S b/arch/arm/cpu/armv7/start.S >>> index db8e9d2..7cb380c 100644 >>> --- a/arch/arm/cpu/armv7/start.S >>> +++ b/arch/arm/cpu/armv7/start.S >>> @@ -134,7 +134,9 @@ IRQ_STACK_START_IN: >>>*/ >>> >>> reset: >>> +#ifdef CONFIG_OMAP >>> blsave_boot_params >>> +#endif >>> /* >>>* set the cpu to SVC32 mode >>>*/ > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] start.S
hi, i am working on an arm board (smdk6410) the first function called in C code is "start_armboot" in file board.c(lib_arm) On Tue, Sep 20, 2011 at 1:02 PM, maheen butt wrote: > my target board is mips so > which part > of start.S jump to c code? and what is first function comes after start.S? > > what is it in case of ARM? > > > From: Christopher Harvey > To: u-boot@lists.denx.de > Sent: Monday, September 19, 2011 11:54 PM > Subject: Re: [U-Boot] start.S > > On 09/19/11 14:28, maheen butt wrote: > > Hi > > I'm newbie in the boot loader world. I'm trying to learning the > > source code for porting purpose. U-boot > > start execution from start.S.I want to know that which part > > of start.S jump to c code? and what is first function comes > > after start.S? > > > > Thanks > > Depends on the architecture you compiled U-boot for. What is your target > board? > Each architecture has it's own start.S > ___ > 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 > > -- Thanks and Regards Manoj Kumar *"One of the basic difference between God and Human is, God gives, gives and forgives. But Human gets, gets and forgets. Be thankful in life!"* ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] start.S
On Tuesday, September 20, 2011 07:02:15 AM maheen butt wrote: > my target board is mips so > which part > of start.S jump to c code? and what is first function comes after start.S? 1) Please stop top-posting ... 2) board_init_f seems like it. > > what is it in case of ARM? board_init_f as well. They seem to be in arch/[family]/lib/ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] serial ifdef mess
Hi Simon, On Tue, Sep 20, 2011 at 2:28 PM, Simon Glass wrote: > Hi Graeme & Mike, > > On Mon, Sep 19, 2011 at 6:07 PM, Graeme Russ wrote: >> Hi Mike, >> >> On Tue, Sep 20, 2011 at 10:52 AM, Mike Frysinger wrote: >>> On Monday, September 19, 2011 20:41:20 Graeme Russ wrote: Hi Mike, On Tue, Sep 20, 2011 at 6:57 AM, Mike Frysinger wrote: > On Sunday, September 18, 2011 09:08:35 Graeme Russ wrote: [snip] >> >> I can see two implementations that a board could decide to use >> >> a) Use a particular serial driver directly - perfect if you have only one >> serial port (or don't care about the others) > > Do we really want this? Is the code overhead of SERIAL_MULTI so bad > that people insist on not defining it? If so, can we reduce that code > overhead? It doesn't seem like it should be large. Perhaps non-MULTI > could be implemented by macros and inline functions in the header > file? Having a quick look via git web, no, SERIAL_MULTI does not look to add too much > >> b) Use the SERIAL_MULTI 'management layer' and 'register' each relavent >> serial port on the board. The board will need to define a (probably >> hard-coded) a default to handle I/O until the environment can be read >> and the hardware initialised to actually make the serial ports >> operational. > > Prior to relocation there is a single console UART. I wonder whether > it would be acceptable to buffer all output until after relocation? Nope - Some arches simply do not have the room for such a buffer. But for boards that can implement a pre-console buffer, you can buffer until environment is initialised and then output everything to the configured serial port > Serial init is the one peripheral still needed prior to reloc. At Timers are also needed pre-reloc > least this could be the default option, with something like > CONFIG_EARLY_UART defined to revert to current behavior for debugging > reasons. Yes, I like this idea. Even when using the pre-console buffer, pre- console output can still be sent to the 'early' UART so you get real-time output on the serial port as U-Boot is booting. You can then use your favourite serial terminal to look at the timing. > Slightly more radical: just move the U-Boot banner, etc. into > board_init_r. What could possible go wrong? Agree - I think there is some pre-reloc output which could be moved to post-reloc > But to truly deal with your point, I don't think the environment tells > the serial ports much. They get their registers address and settings The environment can specify which port is used for console and the baud rate. So environement needs to be up before redirecting output through SERIAL_MULTI > from other places (normally hard-coded in the driver, perhaps in > future through an fdt). It should be possible for any serial driver to > output things before the env is loaded. To implement an early UART we > simply need the serial layer to pass serial calls straight onto the > selected driver without going through the mux or anything else that > needs state. That bit already works... That can be done via putc() in console.c - That is where I redirect to the pre-console buffer prior to console init. It would be trivial to also add an #ifdef CONFIG_EARLY_UART to redirect to early_uart_putc() >> So in theory, we should be able to register an arbitrary number of serial >> ports, each with potentially different hardware and therefore different >> drivers. The board (or SoC) init function should be able to simply call >> serial_register() for each serial port with a name and info into how to >> talk to the hardware (hardware type, base address etc). The SERIAL_MULTI >> framework should then simply manage the list of serial devices and >> redirect I/O based on environment settings > > The main bugbear for me is that there is no handle passed to the > serial functions. All of the serial devices should have an extra > parameter at the start which is perhaps struct seral_device *, and > that structure should have a ->priv member, pointing to a > driver-specific structure which we can > use to store things like the port number / register address. So in > other words make it like most other driver layers in U-Boot. > > This would clean up the eserial macros for one thing. Yes, I hate them with a passion - I really dislike how all the serial port permutations are hard-coded. The extern mess in /include/serial.h really highlights the problem. And /drivers/serial/serial.c being so 16550 centric is so confusing when you also have /drivers/serial/ns16550.c And then you have /common/serial.c... So maybe we trash externs in /include/serial.h and move the implementation of serial_initialize() out of /common/serial.c and into board/SoC files by define a weak alias at SoC level so a board can still call it and register additional serial ports on top. I think the initcall method I put forward before can get around that more cleanly (YMMV) And tidy up /drivers/serial/serial.c
Re: [U-Boot] start.S
my target board is mips so which part of start.S jump to c code? and what is first function comes after start.S? what is it in case of ARM? From: Christopher Harvey To: u-boot@lists.denx.de Sent: Monday, September 19, 2011 11:54 PM Subject: Re: [U-Boot] start.S On 09/19/11 14:28, maheen butt wrote: > Hi > I'm newbie in the boot loader world. I'm trying to learning the > source code for porting purpose. U-boot > start execution from start.S.I want to know that which part > of start.S jump to c code? and what is first function comes > after start.S? > > Thanks Depends on the architecture you compiled U-boot for. What is your target board? Each architecture has it's own start.S ___ 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] serial ifdef mess
On Tuesday, September 20, 2011 00:28:30 Simon Glass wrote: > On Mon, Sep 19, 2011 at 6:07 PM, Graeme Russ wrote: > > a) Use a particular serial driver directly - perfect if you have only one > > serial port (or don't care about the others) > > Do we really want this? Is the code overhead of SERIAL_MULTI so bad > that people insist on not defining it? If so, can we reduce that code > overhead? It doesn't seem like it should be large. Perhaps non-MULTI > could be implemented by macros and inline functions in the header > file? MULTI: serial_puts looks up a struct in a linked list to find the device before calling the func pointer in that struct to the device-specific serial_puts !MULTI: serial_puts writes char to hardware register the latter sounds a lot more robust to me :). it might not be a recommended or default setting, but i think we should strive to keep that simplicity around. > > b) Use the SERIAL_MULTI 'management layer' and 'register' each relavent > > serial port on the board. The board will need to define a (probably > > hard-coded) a default to handle I/O until the environment can be read > > and the hardware initialised to actually make the serial ports > > operational. > > Prior to relocation there is a single console UART. I wonder whether > it would be acceptable to buffer all output until after relocation? > Serial init is the one peripheral still needed prior to reloc. At > least this could be the default option, with something like > CONFIG_EARLY_UART defined to revert to current behavior for debugging > reasons. as a debugging tool, any buffer is not interesting. after that, it might be. > But to truly deal with your point, I don't think the environment tells > the serial ports much. They get their registers address and settings > from other places (normally hard-coded in the driver, perhaps in > future through an fdt). It should be possible for any serial driver to > output things before the env is loaded. To implement an early UART we > simply need the serial layer to pass serial calls straight onto the > selected driver without going through the mux or anything else that > needs state. That bit already works... !MULTI gives us a working early UART now. i know because the Blackfin port can output info to the serial port at pretty much power on. > The main bugbear for me is that there is no handle passed to the > serial functions. All of the serial devices should have an extra > parameter at the start which is perhaps struct seral_device *, and > that structure should have a ->priv member, pointing to a > driver-specific structure which we can > use to store things like the port number / register address. So in > other words make it like most other driver layers in U-Boot. yes, this would be the first thing i'd fix -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] serial ifdef mess
On Monday, September 19, 2011 21:07:48 Graeme Russ wrote:
> a) Use a particular serial driver directly - perfect if you have only one
>serial port (or don't care about the others)
yes. this is what we have today with !SERIAL_MULTI. every serial driver
implements serial_{init,puts,putc,tstc,getc,setbrg,set_baud}. this code works
for exactly one device and is extremely thin. in the case of Blackfin UARTs,
serial_putc() does two things: wait for the hardware FIFO to free up, and then
writes the char to the hardware registers. serial_tstc() is a bit test of a
single hardware status register read. you really can't get any simpler than
this.
> b) Use the SERIAL_MULTI 'management layer' and 'register' each relavent
>serial port on the board. The board will need to define a (probably
>hard-coded) a default to handle I/O until the environment can be read
>and the hardware initialised to actually make the serial ports
>operational.
atm, SERIAL_MULTI provides support for "early" output by means of the
default_serial_console() function. but even this requires going through the
.data section in order to lookup the func pointer to the device pointers.
which means i dont think it works for the ports which do relocation on the
fly. but i dont know as i havent worked at that level with the relevant
arches before.
> So in theory, we should be able to register an arbitrary number of serial
> ports, each with potentially different hardware and therefore different
> drivers.
this works today
> The board (or SoC) init function should be able to simply call
> serial_register() for each serial port with a name and info into how to
> talk to the hardware (hardware type, base address etc).
this is doable today, but the standard is to add all devices to
common/serial.c:serial_initialize()
> The SERIAL_MULTI framework should then simply manage the list of serial
> devices and redirect I/O based on environment settings
which is what it does
one limitation of the current serial/stdio framework is that the serial multi
core can only have one active device at a time. the stdio core can have one
per channel: stdin, stderr, stdout. so this reminds me of the other goal:
merge serial framework into stdio framework.
-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] serial ifdef mess
Hi Graeme & Mike, On Mon, Sep 19, 2011 at 6:07 PM, Graeme Russ wrote: > Hi Mike, > > On Tue, Sep 20, 2011 at 10:52 AM, Mike Frysinger wrote: >> On Monday, September 19, 2011 20:41:20 Graeme Russ wrote: >>> Hi Mike, >>> >>> On Tue, Sep 20, 2011 at 6:57 AM, Mike Frysinger wrote: >>> > On Sunday, September 18, 2011 09:08:35 Graeme Russ wrote: >>> >> I mean, it irks me to no end that /common/serial.c, /drivers/serial.c >>> >> and /include/serial.h are such an ugly mess of #ifdef's - I'm working >>> >> on a new SoC at the moment, and it just plain weird that I have to >>> >> touch these :( >>> > >>> > well, there's two things there. the init mess which could get fixed in >>> > two diff ways: part of your larger init cleanup, or turn it into board >>> > callbacks like most of the other frameworks we have atm. >>> >>> I don't think the serial mess is related to the init sequence at all (but >>> I could be wrong) >> >> the only way to register a new serial device is to add a call to it in >> common/serial.c:serial_initialize(). and the only thing that func does is >> call all the various register funcs which are simply init calls. > > Ah, I see - I think I see an architectural thunk! about to happen ;) > >>> > the second thing is the CONFIG_SERIAL_MULTI hell. that mess i'd like to >>> > gut with a dull blade at some point. >>> >>> Or a sledgehammer! >>> >>> The big question I suppose is where we are at with the _MULTI interfaces. >>> From what I can gather, these should now be the only ones in use and we >>> should start to apply pressure on board maintainers (i.e. break their >>> boards) to fix any depricated usage. I think the same philosophy should >>> be applied to the various boards with 'flash.c' which should all be >>> using CFI by now. >> >> i dont have a problem with non-multi instances since it produces thinner code >> >> i dont think there is anyone driving the serial core atm though ... i dont >> recall seeing any patches there other than new device drivers since ive been >> watching the list ... > > Hmmm, so let me ponder (keep in mind I am not familiar with the serial code > and do not have it in front of me)... > > I can see two implementations that a board could decide to use > > a) Use a particular serial driver directly - perfect if you have only one > serial port (or don't care about the others) Do we really want this? Is the code overhead of SERIAL_MULTI so bad that people insist on not defining it? If so, can we reduce that code overhead? It doesn't seem like it should be large. Perhaps non-MULTI could be implemented by macros and inline functions in the header file? > b) Use the SERIAL_MULTI 'management layer' and 'register' each relavent > serial port on the board. The board will need to define a (probably > hard-coded) a default to handle I/O until the environment can be read > and the hardware initialised to actually make the serial ports > operational. Prior to relocation there is a single console UART. I wonder whether it would be acceptable to buffer all output until after relocation? Serial init is the one peripheral still needed prior to reloc. At least this could be the default option, with something like CONFIG_EARLY_UART defined to revert to current behavior for debugging reasons. Slightly more radical: just move the U-Boot banner, etc. into board_init_r. What could possible go wrong? ? But to truly deal with your point, I don't think the environment tells the serial ports much. They get their registers address and settings from other places (normally hard-coded in the driver, perhaps in future through an fdt). It should be possible for any serial driver to output things before the env is loaded. To implement an early UART we simply need the serial layer to pass serial calls straight onto the selected driver without going through the mux or anything else that needs state. That bit already works... > > So in theory, we should be able to register an arbitrary number of serial > ports, each with potentially different hardware and therefore different > drivers. The board (or SoC) init function should be able to simply call > serial_register() for each serial port with a name and info into how to > talk to the hardware (hardware type, base address etc). The SERIAL_MULTI > framework should then simply manage the list of serial devices and > redirect I/O based on environment settings The main bugbear for me is that there is no handle passed to the serial functions. All of the serial devices should have an extra parameter at the start which is perhaps struct seral_device *, and that structure should have a ->priv member, pointing to a driver-specific structure which we can use to store things like the port number / register address. So in other words make it like most other driver layers in U-Boot. This would clean up the eserial macros for one thing. I don't think this is a huge job. What is a huge job is managing the resulting centithread, laundry costs for th
Re: [U-Boot] [PATCH] MX31: Disable watchdog during low-power modes
On Monday, September 19, 2011 07:51:10 PM Fabio Estevam wrote:
> Turn on the watchdog WDZST bit so that watchdog timer does not count during
> low power modes.
>
> Prior to applying this patch mx31pdk board got watchdog resets because when
> it booted in the Linux prompt and there was no activity, the system
> entered into idle mode while watchdog timer was still active.
>
> Fix this by disabling watchdog timer during idle mode.
>
> Signed-off-by: Fabio Estevam
> ---
> arch/arm/cpu/arm1136/mx31/timer.c |4 ++--
> arch/arm/include/asm/arch-mx31/imx-regs.h |2 ++
> 2 files changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/cpu/arm1136/mx31/timer.c
> b/arch/arm/cpu/arm1136/mx31/timer.c index c05a39d..7197108 100644
> --- a/arch/arm/cpu/arm1136/mx31/timer.c
> +++ b/arch/arm/cpu/arm1136/mx31/timer.c
> @@ -173,8 +173,8 @@ void mxc_hw_watchdog_enable(void)
> #else
> secs = 64;
> #endif
> - writew(readw(&wdog->wcr) | (secs << WDOG_WT_SHIFT) | WDOG_ENABLE,
> - &wdog->wcr);
> + writew(readw(&wdog->wcr) | (secs << WDOG_WT_SHIFT) | WDOG_ENABLE
> + | WDOG_WDZST, &wdog->wcr);
Maybe
tmp = readw();
tmp |= ...
writel(tmp, ...);
?
> }
>
>
> diff --git a/arch/arm/include/asm/arch-mx31/imx-regs.h
> b/arch/arm/include/asm/arch-mx31/imx-regs.h index 2064870..338ba4d 100644
> --- a/arch/arm/include/asm/arch-mx31/imx-regs.h
> +++ b/arch/arm/include/asm/arch-mx31/imx-regs.h
> @@ -71,6 +71,8 @@ struct cspi_regs {
> /* Watchdog Timer (WDOG) registers */
> #define WDOG_ENABLE (1 << 2)
> #define WDOG_WT_SHIFT8
> +#define WDOG_WDZST 1
(1 << 0) ?
> +
> struct wdog_regs {
> u16 wcr;/* Control */
> u16 wsr;/* Service */
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 4/4 V4] I2C: mxc_i2c rework
Rewrite the mxc_i2c driver.
* This version is much closer to Linux implementation.
* Fixes IPG_PERCLK being incorrectly used as clock source
* Fixes behaviour of the driver on iMX51
* Clean up coding style a bit ;-)
Signed-off-by: Marek Vasut
Cc: Stefano Babic
Cc: Heiko Schocher
Cc: Jason Hui
---
drivers/i2c/mxc_i2c.c | 422 +
1 files changed, 289 insertions(+), 133 deletions(-)
V2: Use PERCLK as a source.
V3: Remove forgotten unused variables.
V4: Add missing Cc field to commit message
diff --git a/drivers/i2c/mxc_i2c.c b/drivers/i2c/mxc_i2c.c
index ebde3c5..75052e5 100644
--- a/drivers/i2c/mxc_i2c.c
+++ b/drivers/i2c/mxc_i2c.c
@@ -1,7 +1,15 @@
/*
- * i2c driver for Freescale mx31
+ * i2c driver for Freescale i.MX series
*
* (c) 2007 Pengutronix, Sascha Hauer
+ * (c) 2011 Marek Vasut
+ *
+ * Based on i2c-imx.c from linux kernel:
+ * Copyright (C) 2005 Torsten Koschorrek
+ * Copyright (C) 2005 Matthias Blaschke
+ * Copyright (C) 2007 RightHand Technologies, Inc.
+ * Copyright (C) 2008 Darius Augulis
+ *
*
* See file CREDITS for list of people who contributed to this
* project.
@@ -30,11 +38,13 @@
#include
#include
-#define IADR 0x00
-#define IFDR 0x04
-#define I2CR 0x08
-#define I2SR 0x0c
-#define I2DR 0x10
+struct mxc_i2c_regs {
+ uint32_tiadr;
+ uint32_tifdr;
+ uint32_ti2cr;
+ uint32_ti2sr;
+ uint32_ti2dr;
+};
#define I2CR_IEN (1 << 7)
#define I2CR_IIEN (1 << 6)
@@ -68,215 +78,361 @@
#endif
#define I2C_MAX_TIMEOUT1
-#define I2C_MAX_RETRIES3
-static u16 div[] = { 30, 32, 36, 42, 48, 52, 60, 72, 80, 88, 104, 128, 144,
-160, 192, 240, 288, 320, 384, 480, 576, 640, 768, 960,
-1152, 1280, 1536, 1920, 2304, 2560, 3072, 3840};
+static u16 i2c_clk_div[50][2] = {
+ { 22, 0x20 }, { 24, 0x21 }, { 26, 0x22 }, { 28, 0x23 },
+ { 30, 0x00 }, { 32, 0x24 }, { 36, 0x25 }, { 40, 0x26 },
+ { 42, 0x03 }, { 44, 0x27 }, { 48, 0x28 }, { 52, 0x05 },
+ { 56, 0x29 }, { 60, 0x06 }, { 64, 0x2A }, { 72, 0x2B },
+ { 80, 0x2C }, { 88, 0x09 }, { 96, 0x2D }, { 104, 0x0A },
+ { 112, 0x2E }, { 128, 0x2F }, { 144, 0x0C }, { 160, 0x30 },
+ { 192, 0x31 }, { 224, 0x32 }, { 240, 0x0F }, { 256, 0x33 },
+ { 288, 0x10 }, { 320, 0x34 }, { 384, 0x35 }, { 448, 0x36 },
+ { 480, 0x13 }, { 512, 0x37 }, { 576, 0x14 }, { 640, 0x38 },
+ { 768, 0x39 }, { 896, 0x3A }, { 960, 0x17 }, { 1024, 0x3B },
+ { 1152, 0x18 }, { 1280, 0x3C }, { 1536, 0x3D }, { 1792, 0x3E },
+ { 1920, 0x1B }, { 2048, 0x3F }, { 2304, 0x1C }, { 2560, 0x1D },
+ { 3072, 0x1E }, { 3840, 0x1F }
+};
+
+static u8 clk_idx;
-static inline void i2c_reset(void)
-{
- writew(0, I2C_BASE + I2CR); /* Reset module */
- writew(0, I2C_BASE + I2SR);
- writew(I2CR_IEN, I2C_BASE + I2CR);
-}
-
-void i2c_init(int speed, int unused)
+/*
+ * Calculate and set proper clock divider
+ */
+static void i2c_imx_set_clk(unsigned int rate)
{
- int freq;
+ struct mxc_i2c_regs *i2c_regs = (struct mxc_i2c_regs *)I2C_BASE;
+ unsigned int i2c_clk_rate;
+ unsigned int div;
int i;
#if defined(CONFIG_MX31)
struct clock_control_regs *sc_regs =
(struct clock_control_regs *)CCM_BASE;
+
/* start the required I2C clock */
writel(readl(&sc_regs->cgr0) | (3 << I2C_CLK_OFFSET),
&sc_regs->cgr0);
#endif
- freq = mxc_get_clock(MXC_IPG_PERCLK);
- for (i = 0; i < 0x1f; i++)
- if (freq / div[i] <= speed)
- break;
+ /* Divider value calculation */
+ i2c_clk_rate = mxc_get_clock(MXC_IPG_PERCLK);
+ div = (i2c_clk_rate + rate - 1) / rate;
+ if (div < i2c_clk_div[0][0])
+ i = 0;
+ else if (div > i2c_clk_div[ARRAY_SIZE(i2c_clk_div) - 1][0])
+ i = ARRAY_SIZE(i2c_clk_div) - 1;
+ else
+ for (i = 0; i2c_clk_div[i][0] < div; i++)
+ ;
+
+ /* Store divider value */
+ clk_idx = i2c_clk_div[i][1];
+ writeb(clk_idx, &i2c_regs->ifdr);
+}
- debug("%s: speed: %d\n", __func__, speed);
+/*
+ * Reset I2C Controller
+ */
+void i2c_reset(void)
+{
+ struct mxc_i2c_regs *i2c_regs = (struct mxc_i2c_regs *)I2C_BASE;
+
+ writeb(0, &i2c_regs->i2cr); /* Reset module */
+ writeb(0, &i2c_regs->i2sr);
+}
- writew(i, I2C_BASE + IFDR);
+/*
+ * Init I2C Bus
+ */
+void i2c_init(int speed, int unused)
+{
+ i2c_imx_set_clk(speed);
i2c_reset();
}
-static int wait_idle(void)
+/*
+ * Wait for bus to be busy (or free if for_busy = 0)
+ *
+ * for_busy = 1: Wait for IBB to be asserted
+ * for_busy = 0: Wait for IBB to be de-asserted
+ */
+int i2c_imx_bus_busy
[U-Boot] [PATCH 4/4 V3] I2C: mxc_i2c rework
Rewrite the mxc_i2c driver.
* This version is much closer to Linux implementation.
* Fixes IPG_PERCLK being incorrectly used as clock source
* Fixes behaviour of the driver on iMX51
* Clean up coding style a bit ;-)
Signed-off-by: Marek Vasut
---
drivers/i2c/mxc_i2c.c | 422 +
1 files changed, 289 insertions(+), 133 deletions(-)
V2: Use PERCLK as a source.
V3: Remove forgotten unused variables.
diff --git a/drivers/i2c/mxc_i2c.c b/drivers/i2c/mxc_i2c.c
index ebde3c5..75052e5 100644
--- a/drivers/i2c/mxc_i2c.c
+++ b/drivers/i2c/mxc_i2c.c
@@ -1,7 +1,15 @@
/*
- * i2c driver for Freescale mx31
+ * i2c driver for Freescale i.MX series
*
* (c) 2007 Pengutronix, Sascha Hauer
+ * (c) 2011 Marek Vasut
+ *
+ * Based on i2c-imx.c from linux kernel:
+ * Copyright (C) 2005 Torsten Koschorrek
+ * Copyright (C) 2005 Matthias Blaschke
+ * Copyright (C) 2007 RightHand Technologies, Inc.
+ * Copyright (C) 2008 Darius Augulis
+ *
*
* See file CREDITS for list of people who contributed to this
* project.
@@ -30,11 +38,13 @@
#include
#include
-#define IADR 0x00
-#define IFDR 0x04
-#define I2CR 0x08
-#define I2SR 0x0c
-#define I2DR 0x10
+struct mxc_i2c_regs {
+ uint32_tiadr;
+ uint32_tifdr;
+ uint32_ti2cr;
+ uint32_ti2sr;
+ uint32_ti2dr;
+};
#define I2CR_IEN (1 << 7)
#define I2CR_IIEN (1 << 6)
@@ -68,215 +78,361 @@
#endif
#define I2C_MAX_TIMEOUT1
-#define I2C_MAX_RETRIES3
-static u16 div[] = { 30, 32, 36, 42, 48, 52, 60, 72, 80, 88, 104, 128, 144,
-160, 192, 240, 288, 320, 384, 480, 576, 640, 768, 960,
-1152, 1280, 1536, 1920, 2304, 2560, 3072, 3840};
+static u16 i2c_clk_div[50][2] = {
+ { 22, 0x20 }, { 24, 0x21 }, { 26, 0x22 }, { 28, 0x23 },
+ { 30, 0x00 }, { 32, 0x24 }, { 36, 0x25 }, { 40, 0x26 },
+ { 42, 0x03 }, { 44, 0x27 }, { 48, 0x28 }, { 52, 0x05 },
+ { 56, 0x29 }, { 60, 0x06 }, { 64, 0x2A }, { 72, 0x2B },
+ { 80, 0x2C }, { 88, 0x09 }, { 96, 0x2D }, { 104, 0x0A },
+ { 112, 0x2E }, { 128, 0x2F }, { 144, 0x0C }, { 160, 0x30 },
+ { 192, 0x31 }, { 224, 0x32 }, { 240, 0x0F }, { 256, 0x33 },
+ { 288, 0x10 }, { 320, 0x34 }, { 384, 0x35 }, { 448, 0x36 },
+ { 480, 0x13 }, { 512, 0x37 }, { 576, 0x14 }, { 640, 0x38 },
+ { 768, 0x39 }, { 896, 0x3A }, { 960, 0x17 }, { 1024, 0x3B },
+ { 1152, 0x18 }, { 1280, 0x3C }, { 1536, 0x3D }, { 1792, 0x3E },
+ { 1920, 0x1B }, { 2048, 0x3F }, { 2304, 0x1C }, { 2560, 0x1D },
+ { 3072, 0x1E }, { 3840, 0x1F }
+};
+
+static u8 clk_idx;
-static inline void i2c_reset(void)
-{
- writew(0, I2C_BASE + I2CR); /* Reset module */
- writew(0, I2C_BASE + I2SR);
- writew(I2CR_IEN, I2C_BASE + I2CR);
-}
-
-void i2c_init(int speed, int unused)
+/*
+ * Calculate and set proper clock divider
+ */
+static void i2c_imx_set_clk(unsigned int rate)
{
- int freq;
+ struct mxc_i2c_regs *i2c_regs = (struct mxc_i2c_regs *)I2C_BASE;
+ unsigned int i2c_clk_rate;
+ unsigned int div;
int i;
#if defined(CONFIG_MX31)
struct clock_control_regs *sc_regs =
(struct clock_control_regs *)CCM_BASE;
+
/* start the required I2C clock */
writel(readl(&sc_regs->cgr0) | (3 << I2C_CLK_OFFSET),
&sc_regs->cgr0);
#endif
- freq = mxc_get_clock(MXC_IPG_PERCLK);
- for (i = 0; i < 0x1f; i++)
- if (freq / div[i] <= speed)
- break;
+ /* Divider value calculation */
+ i2c_clk_rate = mxc_get_clock(MXC_IPG_PERCLK);
+ div = (i2c_clk_rate + rate - 1) / rate;
+ if (div < i2c_clk_div[0][0])
+ i = 0;
+ else if (div > i2c_clk_div[ARRAY_SIZE(i2c_clk_div) - 1][0])
+ i = ARRAY_SIZE(i2c_clk_div) - 1;
+ else
+ for (i = 0; i2c_clk_div[i][0] < div; i++)
+ ;
+
+ /* Store divider value */
+ clk_idx = i2c_clk_div[i][1];
+ writeb(clk_idx, &i2c_regs->ifdr);
+}
- debug("%s: speed: %d\n", __func__, speed);
+/*
+ * Reset I2C Controller
+ */
+void i2c_reset(void)
+{
+ struct mxc_i2c_regs *i2c_regs = (struct mxc_i2c_regs *)I2C_BASE;
+
+ writeb(0, &i2c_regs->i2cr); /* Reset module */
+ writeb(0, &i2c_regs->i2sr);
+}
- writew(i, I2C_BASE + IFDR);
+/*
+ * Init I2C Bus
+ */
+void i2c_init(int speed, int unused)
+{
+ i2c_imx_set_clk(speed);
i2c_reset();
}
-static int wait_idle(void)
+/*
+ * Wait for bus to be busy (or free if for_busy = 0)
+ *
+ * for_busy = 1: Wait for IBB to be asserted
+ * for_busy = 0: Wait for IBB to be de-asserted
+ */
+int i2c_imx_bus_busy(int for_busy)
{
+ struct mxc_i2c_regs *i2c_regs = (struct mxc_i2c_regs *)I2C_BASE;
+
[U-Boot] [PATCH 13/15 V3] iMX28: Add support for DENX M28EVK board
This contains support for the following components:
- DUART
- MMC
- Both FEC interfaces
- NAND
- I2C (RTC, EEPROM)
- SPI (FLASH)
Signed-off-by: Marek Vasut
Cc: Stefano Babic
Cc: Wolfgang Denk
Cc: Detlev Zundel
Cc: Scott Wood
---
MAINTAINERS|1 +
board/denx/m28evk/Makefile | 49
board/denx/m28evk/m28evk.c | 195 ++
boards.cfg |1 +
include/configs/m28evk.h | 282
5 files changed, 528 insertions(+), 0 deletions(-)
create mode 100644 board/denx/m28evk/Makefile
create mode 100644 board/denx/m28evk/m28evk.c
create mode 100644 include/configs/m28evk.h
V2: Use scrub -y instead of scrub.quiet in the scripts.
V3: Use CONFIG_ENV_RANGE
diff --git a/MAINTAINERS b/MAINTAINERS
index 2f60a60..61a55a8 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -847,6 +847,7 @@ Marek Vasut
palmtc xscale/pxa
vpac270 xscale/pxa
zipitz2 xscale/pxa
+ m28evk i.MX28
efikamx i.MX51
Hugo Villeneuve
diff --git a/board/denx/m28evk/Makefile b/board/denx/m28evk/Makefile
new file mode 100644
index 000..4037199
--- /dev/null
+++ b/board/denx/m28evk/Makefile
@@ -0,0 +1,49 @@
+#
+# (C) Copyright 2000-2006
+# Wolfgang Denk, DENX Software Engineering, w...@denx.de.
+#
+# See file CREDITS for list of people who contributed to this
+# project.
+#
+# This program is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public License as
+# published by the Free Software Foundation; either version 2 of
+# the License, or (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+# MA 02111-1307 USA
+#
+
+include $(TOPDIR)/config.mk
+
+LIB= $(obj)lib$(BOARD).o
+
+COBJS := m28evk.o
+
+SRCS := $(COBJS:.o=.c)
+OBJS := $(addprefix $(obj),$(COBJS))
+
+$(LIB):$(obj).depend $(OBJS)
+ $(call cmd_link_o_target, $(OBJS))
+
+clean:
+ rm -f $(OBJS)
+
+distclean: clean
+ rm -f $(LIB) core *.bak .depend
+
+#
+
+# defines $(obj).depend target
+include $(SRCTREE)/rules.mk
+
+sinclude $(obj).depend
+
+#
diff --git a/board/denx/m28evk/m28evk.c b/board/denx/m28evk/m28evk.c
new file mode 100644
index 000..118e222
--- /dev/null
+++ b/board/denx/m28evk/m28evk.c
@@ -0,0 +1,195 @@
+/*
+ * DENX M28 module
+ *
+ * Copyright (C) 2011 Marek Vasut
+ * on behalf of DENX Software Engineering GmbH
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+DECLARE_GLOBAL_DATA_PTR;
+
+/*
+ * Functions
+ */
+int board_early_init_f(void)
+{
+ /* IO0 clock at 480MHz */
+ mx28_set_ioclk(MXC_IOCLK0, 48);
+ /* IO1 clock at 480MHz */
+ mx28_set_ioclk(MXC_IOCLK1, 48);
+
+ /* SSP0 clock at 96MHz */
+ mx28_set_sspclk(MXC_SSPCLK0, 96000, 0);
+ /* SSP2 clock at 96MHz */
+ mx28_set_sspclk(MXC_SSPCLK2, 96000, 0);
+
+ return 0;
+}
+
+int board_init(void)
+{
+ /* Adress of boot parameters */
+ gd->bd->bi_boot_params = PHYS_SDRAM_1 + 0x100;
+
+ return 0;
+}
+
+int dram_init(void)
+{
+ /* dram_init must store complete ramsize in gd->ram_size */
+ gd->ram_size = get_ram_size((long *)PHYS_SDRAM_1, PHYS_SDRAM_1_SIZE);
+ return 0;
+}
+
+#ifdef CONFIG_CMD_MMC
+static int m28_mmc_wp(int id)
+{
+ if (id != 0) {
+ printf("MXS MMC: Invalid card selected (card id = %d)\n", id);
+ return 1;
+ }
+
+ return gpio_get_value(MX28_PAD_AUART2_CTS__GPIO_3_10);
[U-Boot] Job Opportunities
Dear Applicant, This is to inform you that we have many Employment Opportunities openings in CHEVRON OIL COMPANY LIMITED UK, CLUK , UNITED KINGDOM the management has decided to fill up all the positions with foreign international reputable and experienced. These are the benefits: 1. Five Bedroom Flat Duplex 2. Free Medical & Travel Insurance 3. Ten Days Leave / break/ Vacation after every 90 working days 4. Flight Fares (Air Tickets) 5. Free Education Scheme to expatriates children/family 6. Free Toyota Camry Year 2008 Model (Company Car) Contact and send your complete updated CV/Resume and your passport number to this email: j...@chevol.co.uk, Contact person: Joe W. Laymon TEL: + (44)770-003-6982 Note: we will forward a copy of Practical Interview Letter online after filling the Job Application Form! And if you are among the successful candidate. You will do two week training before you resume on duties fully here in LONDON. Joe W. Laymon Vice President, Human Resources & Communication London, United Kingdom 1 Westferry Circus Canary Wharf London, E14 4HA ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] serial ifdef mess
Hi Mike, On Tue, Sep 20, 2011 at 10:52 AM, Mike Frysinger wrote: > On Monday, September 19, 2011 20:41:20 Graeme Russ wrote: >> Hi Mike, >> >> On Tue, Sep 20, 2011 at 6:57 AM, Mike Frysinger wrote: >> > On Sunday, September 18, 2011 09:08:35 Graeme Russ wrote: >> >> I mean, it irks me to no end that /common/serial.c, /drivers/serial.c >> >> and /include/serial.h are such an ugly mess of #ifdef's - I'm working >> >> on a new SoC at the moment, and it just plain weird that I have to >> >> touch these :( >> > >> > well, there's two things there. the init mess which could get fixed in >> > two diff ways: part of your larger init cleanup, or turn it into board >> > callbacks like most of the other frameworks we have atm. >> >> I don't think the serial mess is related to the init sequence at all (but >> I could be wrong) > > the only way to register a new serial device is to add a call to it in > common/serial.c:serial_initialize(). and the only thing that func does is > call all the various register funcs which are simply init calls. Ah, I see - I think I see an architectural thunk! about to happen ;) >> > the second thing is the CONFIG_SERIAL_MULTI hell. that mess i'd like to >> > gut with a dull blade at some point. >> >> Or a sledgehammer! >> >> The big question I suppose is where we are at with the _MULTI interfaces. >> From what I can gather, these should now be the only ones in use and we >> should start to apply pressure on board maintainers (i.e. break their >> boards) to fix any depricated usage. I think the same philosophy should >> be applied to the various boards with 'flash.c' which should all be >> using CFI by now. > > i dont have a problem with non-multi instances since it produces thinner code > > i dont think there is anyone driving the serial core atm though ... i dont > recall seeing any patches there other than new device drivers since ive been > watching the list ... Hmmm, so let me ponder (keep in mind I am not familiar with the serial code and do not have it in front of me)... I can see two implementations that a board could decide to use a) Use a particular serial driver directly - perfect if you have only one serial port (or don't care about the others) b) Use the SERIAL_MULTI 'management layer' and 'register' each relavent serial port on the board. The board will need to define a (probably hard-coded) a default to handle I/O until the environment can be read and the hardware initialised to actually make the serial ports operational. So in theory, we should be able to register an arbitrary number of serial ports, each with potentially different hardware and therefore different drivers. The board (or SoC) init function should be able to simply call serial_register() for each serial port with a name and info into how to talk to the hardware (hardware type, base address etc). The SERIAL_MULTI framework should then simply manage the list of serial devices and redirect I/O based on environment settings Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] serial ifdef mess
On Monday, September 19, 2011 20:41:20 Graeme Russ wrote: > Hi Mike, > > On Tue, Sep 20, 2011 at 6:57 AM, Mike Frysinger wrote: > > On Sunday, September 18, 2011 09:08:35 Graeme Russ wrote: > >> I mean, it irks me to no end that /common/serial.c, /drivers/serial.c > >> and /include/serial.h are such an ugly mess of #ifdef's - I'm working > >> on a new SoC at the moment, and it just plain weird that I have to > >> touch these :( > > > > well, there's two things there. the init mess which could get fixed in > > two diff ways: part of your larger init cleanup, or turn it into board > > callbacks like most of the other frameworks we have atm. > > I don't think the serial mess is related to the init sequence at all (but > I could be wrong) the only way to register a new serial device is to add a call to it in common/serial.c:serial_initialize(). and the only thing that func does is call all the various register funcs which are simply init calls. > > the second thing is the CONFIG_SERIAL_MULTI hell. that mess i'd like to > > gut with a dull blade at some point. > > Or a sledgehammer! > > The big question I suppose is where we are at with the _MULTI interfaces. > From what I can gather, these should now be the only ones in use and we > should start to apply pressure on board maintainers (i.e. break their > boards) to fix any depricated usage. I think the same philosophy should > be applied to the various boards with 'flash.c' which should all be > using CFI by now. i dont have a problem with non-multi instances since it produces thinner code i dont think there is anyone driving the serial core atm though ... i dont recall seeing any patches there other than new device drivers since ive been watching the list ... -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] serial ifdef mess
Hi Mike, On Tue, Sep 20, 2011 at 6:57 AM, Mike Frysinger wrote: > On Sunday, September 18, 2011 09:08:35 Graeme Russ wrote: >> I mean, it irks me to no end that /common/serial.c, /drivers/serial.c and >> /include/serial.h are such an ugly mess of #ifdef's - I'm working on a new >> SoC at the moment, and it just plain weird that I have to touch these :( > > well, there's two things there. the init mess which could get fixed in two > diff ways: part of your larger init cleanup, or turn it into board callbacks > like most of the other frameworks we have atm. I don't think the serial mess is related to the init sequence at all (but I could be wrong) > > the second thing is the CONFIG_SERIAL_MULTI hell. that mess i'd like to gut > with a dull blade at some point. Or a sledgehammer! The big question I suppose is where we are at with the _MULTI interfaces. >From what I can gather, these should now be the only ones in use and we should start to apply pressure on board maintainers (i.e. break their boards) to fix any depricated usage. I think the same philosophy should be applied to the various boards with 'flash.c' which should all be using CFI by now. I've got way to much on my plate to deal with it right now, otherwise I would give it a crack myself - Everyone should know by know that I'm not affraid to stir the pot with some pretty radical code changes ;) Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mx1: add mx1/l support for mxc_i2c
Hi Stefano, On 19 sept. 2011, at 09:26, Stefano Babic wrote: > On 09/19/2011 08:57 AM, Marek Vasut wrote: >> On Monday, August 22, 2011 10:56:43 PM Eric Jarrige wrote: >>> Signed-off-by: Eric Jarrige >>> Cc: Stefano Babic >>> Cc: Heiko Schocher >>> @@ -94,6 +98,8 @@ void i2c_init(int speed, int unused) >>> /* start the required I2C clock */ >>> writel(readl(&sc_regs->cgr0) | (3 << I2C_CLK_OFFSET), >>> &sc_regs->cgr0); >>> +#elif defined(CONFIG_IMX) >>> + freq = get_HCLK(); >>> #else >>> freq = mxc_get_clock(MXC_IPG_PERCLK); >>> #endif >> >> Please, no more ifdefs -- can't you actually modify your header files or add >> some which would define mxc_get_clock() ? That'd make this way much more >> clean. > > In principl, I agree completely with Marek, and we have tried to get rid > as much of possible of #ifdef in drivers. I know we have already > discussed about the opportunity to fix the whole IMX stuff, and I agreed > with you that this processor is obsolete and make no sense to invest a > lot of time for it. However, what about to define mxc_get_clock() as > simple macro ? Maybe in imx-regs.h, as exceptiion for this processor > (normally the imx-regs.h contains only defines and structures for the > internal registers) ? Something like: > > #define mxc_get_clock(a)(get_HCLK()) I agree with you to get rid of all these #ifdef and my current patch does not help at all. I can update the imx-regs.h with the change you propose but that won't help for the future iMX CPU. IMHO the problem comes from all the hard coded constants in the driver such as mxc_get_clock(MXC_IPG_PERCLK) and others I2C_BASE... Every chipset use a different root clock for its i2c controller. Why not changing the line freq = mxc_get_clock(MXC_IPG_PERCLK); by something more generic such as a macro: freq = MXC_GET_I2C_CLOCK(); /* or GET_MXC_I2C_CLOCK() */ that can be defined in clock.h with the correct definition for each chipset? Using a macro would clarify that is chipset dependent as each CPU use its own clock.h For the mx1, I can add a clock.h with the correct implementation of the macro: #define MXC_GET_I2C_CLOCK() get_HCLK() or any other solution that avoid any new ifdef. Does it makes sense? With all these constants moved to header files it would be easier and faster to support new CPU as the final hardware abstraction layer moved to header file specific for each CPU. Best regards, Eric ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2 RESEND] SPL: Allow user to disable CPU support library
On Monday, September 19, 2011 08:13:45 PM Scott Wood wrote: > On 09/16/2011 05:48 PM, Marek Vasut wrote: > > On Saturday, September 17, 2011 12:07:52 AM Scott Wood wrote: > >> You have no idea why I'd like to be extremely selective with what I > >> include in a 4K binary? > > > > That I do understand -- but that kind of selection is there. > > > >> It's not about avoiding particular files. It's about including > >> *nothing* but what is explicitly asked for through some SPL-specific > >> CONFIG symbol. Maybe that includes everything in arch/$(ARCH)/cpu. > >> Maybe it includes nothing in there. More likely, it includes just a > >> fraction of it. > > > > The stuff in arch/arm/cpu should be exactly what you need, nothing more ! > > This is "spl/", not "arch/arm/spl/", so let's not reason from one > architecture, much less the subset of that architecture that has already > been made to work with spl/ -- there are 14 different instances of > arch/arm/cpu/$(CPU). I don't think I follow you on this one really -- are we still discussing the inclusion/non-inclusion of the cpu-specific library in the SPL, right ? > > We will not want everything we normally pull from > arch/powerpc/cpu/mpc85xx to go into an 85xx NAND SPL, for example. But > we will want some small portion of it. Then you adjust the makefile there by ifdef CONFIG_SPL_BUILD > > My understanding of how spl/ is meant to work is that each directory's > makefiles will use special SPL config symbols to decide what individual > objects (if any) to include. It's not clear to me why we need a > directory-level control. Maybe it would be the most convenient way to > implement it for something that is well-encapsulated and arch-neutral > (thus only one instance to worry about), where the odds of a subset > being useful are slim, but it doesn't seem appropriate here. See above, you use CONFIG_SPL_BUILD to select that in the makefile. > > Whether it's file or directory based, everything should be off by > default. Boards should ask for what they want, not what they want to > exclude. Actually, this being a rare case where you want it excluded, it's better the way it is. > > -Scott Cheers ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] net/bootp.c: fix tftp load if autoload environment var isn't set
Dear Peter Korsgaard, In message <1316418886-13495-1-git-send-email-jac...@sunsite.dk> you wrote: > Commit 093498669 (Put common autoload code into auto_load() function) > broke handling of autoload environment variable not being set. > The bootp/dhcp code will just keep on requesting IP address forever > and never start TFTP download. > > Fix it by moving TftpStart() outside the conditional like it was before. > > Signed-off-by: Peter Korsgaard > --- > net/bootp.c |2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) Applied, thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Real computer scientists despise the idea of actual hardware. Hard- ware has limitations, software doesn't. It's a real shame that Turing machines are so poor at I/O. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-ppc4xx/master
Dear Stefan Roese, In message <201109191401.44473...@denx.de> you wrote: > Hi Wolfgang, > > please pull the following two ppc4xx fixes: > > The following changes since commit 56fa45d58116f86f343a9c45ce6d1110f50b8d70: > > DA830: Fix Build Warning (2011-09-13 22:24:24 +0200) > > are available in the git repository at: > git://www.denx.de/git/u-boot-ppc4xx.git master > > Stefan Roese (1): > ppc4xx: Flush dcache after DDR2 autocalibration with caches on > > Weirich, Bernhard (1): > Fix incorrect array size of phy settings for 405EX > > arch/powerpc/cpu/ppc4xx/44x_spd_ddr2.c |7 +++ > arch/powerpc/include/asm/u-boot.h |2 +- > 2 files changed, 8 insertions(+), 1 deletions(-) Applied, thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Star Trek Lives! ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Add support for IDS8313 boards
Dear sergej.stepa...@ids.de, In message <4206182445660643B9AEB8D4E55BBD0A15399F40A4@HERMES2> you wrote: > This patch adds support for IDS8313 boards based on MPC8313 > It contains the following components: > - both of TSEC's, NOR- and NAND flash, I2C, SPI > > Signed-off-by: Sergej Stepanov > Signed-off-by: Rolf Riehle > -- > board/ids/ids8313/Makefile | 52 > board/ids/ids8313/ids8313.c | 179 ++ > boards.cfg |1 + > include/configs/IDS8313.h | 575 > +++ > 4 files changed, 807 insertions(+), 0 deletions(-) Checkpatch says: [U-Boot] [PATCH] Add support for IDS8313 boards total: 136 errors, 218 warnings, 813 lines checked Please clean up and resubmit. 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 "It takes all sorts of in & out-door schooling to get adapted to my kind of fooling" - R. Frost ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mx1: add mx1/l support for mxc_i2c
Am 19/09/2011 22:34, schrieb Eric Jarrige: > Hi Stefano, > > On 19 sept. 2011, at 09:26, Stefano Babic wrote: > Hi Eric, >> On 09/19/2011 08:57 AM, Marek Vasut wrote: >>> On Monday, August 22, 2011 10:56:43 PM Eric Jarrige wrote: Signed-off-by: Eric Jarrige Cc: Stefano Babic Cc: Heiko Schocher @@ -94,6 +98,8 @@ void i2c_init(int speed, int unused) /* start the required I2C clock */ writel(readl(&sc_regs->cgr0) | (3 << I2C_CLK_OFFSET), &sc_regs->cgr0); +#elif defined(CONFIG_IMX) + freq = get_HCLK(); #else freq = mxc_get_clock(MXC_IPG_PERCLK); #endif >>> Please, no more ifdefs -- can't you actually modify your header files or >>> add >>> some which would define mxc_get_clock() ? That'd make this way much more >>> clean. >> In principl, I agree completely with Marek, and we have tried to get rid >> as much of possible of #ifdef in drivers. I know we have already >> discussed about the opportunity to fix the whole IMX stuff, and I agreed >> with you that this processor is obsolete and make no sense to invest a >> lot of time for it. However, what about to define mxc_get_clock() as >> simple macro ? Maybe in imx-regs.h, as exceptiion for this processor >> (normally the imx-regs.h contains only defines and structures for the >> internal registers) ? Something like: >> >> #define mxc_get_clock(a)(get_HCLK()) > I agree with you to get rid of all these #ifdef and my current patch does not > help at all. > I can update the imx-regs.h with the change you propose but that won't help > for the > future iMX CPU. > IMHO the problem comes from all the hard coded constants in the driver such as > mxc_get_clock(MXC_IPG_PERCLK) ...I see the clock name is not so generic, and it is not related to the interface.. > and others I2C_BASE... > Every chipset use a different root clock for its i2c controller. > > Why not changing the line > freq = mxc_get_clock(MXC_IPG_PERCLK); > > by something more generic such as a macro: > > freq = MXC_GET_I2C_CLOCK(); /* or GET_MXC_I2C_CLOCK() */ We have already this mechanism - this is the goal of the mxc_get_clock() function: a common way to get clocks for all i.MX processors. We have for example MXC_CSPI_CLK (SPI), MXC_UART_CLK, and so on. The line should become: freq = mxc_get_clock(MXC_I2C_CLK) and then each processor can return its own value. This already works for the other interfaces (FEC, UART, SPI,..) > > that can be defined in clock.h with the correct definition for each chipset? We need only to extend the mxc_clock enumeration type. The implementation of mxc_get_clock() is SOC specific. > Using a macro would clarify that is chipset dependent as each CPU use > its own clock.h > > For the mx1, I can add a clock.h with the correct implementation of the > macro: > #define MXC_GET_I2C_CLOCK() get_HCLK() > or any other solution that avoid any new ifdef. > > Does it makes sense? Yes, it makes sense to change, check my proposal Best regards, Stefano -- = DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] serial ifdef mess
On Sunday, September 18, 2011 09:08:35 Graeme Russ wrote: > I mean, it irks me to no end that /common/serial.c, /drivers/serial.c and > /include/serial.h are such an ugly mess of #ifdef's - I'm working on a new > SoC at the moment, and it just plain weird that I have to touch these :( well, there's two things there. the init mess which could get fixed in two diff ways: part of your larger init cleanup, or turn it into board callbacks like most of the other frameworks we have atm. the second thing is the CONFIG_SERIAL_MULTI hell. that mess i'd like to gut with a dull blade at some point. -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
[U-Boot] [PATCH] Add support for IDS8313 boards
This patch adds support for IDS8313 boards based on MPC8313
It contains the following components:
- both of TSEC's, NOR- and NAND flash, I2C, SPI
Signed-off-by: Sergej Stepanov
Signed-off-by: Rolf Riehle
--
board/ids/ids8313/Makefile | 52
board/ids/ids8313/ids8313.c | 179 ++
boards.cfg |1 +
include/configs/IDS8313.h | 575 +++
4 files changed, 807 insertions(+), 0 deletions(-)
diff --git a/board/ids/ids8313/Makefile b/board/ids/ids8313/Makefile
new file mode 100644
index 000..4bd325b
--- /dev/null
+++ b/board/ids/ids8313/Makefile
@@ -0,0 +1,52 @@
+#
+# Copyright (c) 2011 IDS GmbH, Germany
+#
+# Sergej Stepanov
+# Based on board/freescale/mpc8313erdb/Makefile
+#
+# See file CREDITS for list of people who contributed to this
+# project.
+#
+# This program is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public License as
+# published by the Free Software Foundation; either version 2 of
+# the License, or (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+# MA 02111-1307 USA
+#
+
+include $(TOPDIR)/config.mk
+
+LIB= $(obj)lib$(BOARD).o
+
+COBJS := $(BOARD).o
+
+SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c)
+OBJS := $(addprefix $(obj),$(COBJS))
+SOBJS := $(addprefix $(obj),$(SOBJS))
+
+$(LIB):$(obj).depend $(OBJS)
+ $(AR) $(ARFLAGS) $@ $(OBJS)
+
+clean:
+ rm -f $(SOBJS) $(OBJS)
+
+distclean: clean
+ rm -f $(LIB) core *.bak $(obj).depend
+
+#
+
+# defines $(obj).depend target
+include $(SRCTREE)/rules.mk
+
+sinclude $(obj).depend
+
+#
diff --git a/board/ids/ids8313/ids8313.c b/board/ids/ids8313/ids8313.c
new file mode 100644
index 000..0d587bb
--- /dev/null
+++ b/board/ids/ids8313/ids8313.c
@@ -0,0 +1,179 @@
+/*
+ * Copyright (c) 2011 IDS GmbH, Germany
+ * ids8313.c -- IDS ids8313 board support.
+ *
+ * Sergej Stepanov
+ * Based on board/freescale/mpc8313erdb/mpc8313erdb.c
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+extern void disable_addr_trans (void);
+extern void enable_addr_trans (void);
+int fixed_sdram(void);
+
+int checkboard (void)
+{
+ puts("Board: CX73X\n");
+ return 0;
+}
+
+phys_size_t initdram (int board_type)
+{
+ volatile immap_t *im = (immap_t *)CONFIG_SYS_IMMR;
+ volatile fsl_lbc_t *lbc = &im->im_lbc;
+ u32 msize = 0;
+
+ if ((im->sysconf.immrbar & IMMRBAR_BASE_ADDR) != (u32)im)
+ return -1;
+
+ /* DDR SDRAM - Main SODIMM */
+ msize = fixed_sdram();
+
+ /* nado */
+ out_be32(&lbc->lbcr, CONFIG_SYS_LBC_LBCR);
+ out_be32(&lbc->mrtpr, CONFIG_SYS_LBC_MRTPR);
+ sync();
+
+ /* return total bus SDRAM size(bytes) -- DDR */
+ return msize;
+}
+
+/*
+ * fixed sdram init -- doesn't use serial presence detect.
+ /
+int fixed_sdram(void)
+{
+ volatile immap_t *im = (volatile immap_t *)CONFIG_SYS_IMMR;
+ u32 msize = CONFIG_SYS_DDR_SIZE << 20;
+
+#if (CONFIG_SYS_DDR_SIZE != 128)
+#warning Currently any ddr size other than 256 is not supported
+#endif
+
+#ifndef CONFIG_SYS_RAMBOOT
+ u32 msize_log2 = __ilog2(msize);
+
+ out_be32(&im->sysconf.ddrlaw[0].bar,
+(CONFIG_SYS_DDR_SDRAM_BASE & 0xf000));
+ out_be32(&im->sysconf.ddrlaw[0].ar, LBLAWAR_EN | (msize_log2 - 1));
+ out_be32(&im->sysconf.ddrcdr, CONFIG_SYS_DDRCDR_VALUE);
+ sync();
+
+
[U-Boot] [PATCH 1/2 V2] EfikaMX: Add imximage config for Efika SB
Signed-off-by: Marek Vasut Cc: Stefano Babic --- MAINTAINERS |1 + board/efikamx/imximage.cfg| 122 - board/efikamx/imximage_mx.cfg | 122 + board/efikamx/imximage_sb.cfg | 122 + boards.cfg|3 +- 5 files changed, 247 insertions(+), 123 deletions(-) delete mode 100644 board/efikamx/imximage.cfg create mode 100644 board/efikamx/imximage_mx.cfg create mode 100644 board/efikamx/imximage_sb.cfg V2: Add missing MAINTAINERS entry diff --git a/MAINTAINERS b/MAINTAINERS index 2f60a60..86f581b 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -848,6 +848,7 @@ Marek Vasut vpac270 xscale/pxa zipitz2 xscale/pxa efikamx i.MX51 + efikasb i.MX51 Hugo Villeneuve diff --git a/board/efikamx/imximage.cfg b/board/efikamx/imximage.cfg deleted file mode 100644 index 6fe0ff9..000 --- a/board/efikamx/imximage.cfg +++ /dev/null @@ -1,122 +0,0 @@ -# -# Copyright (C) 2010 Marek Vasut -# -# BASED ON: imx51evk -# -# (C) Copyright 2009 -# Stefano Babic DENX Software Engineering sba...@denx.de. -# -# 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. 51 Franklin Street Fifth Floor Boston, -# MA 02110-1301 USA -# -# Refer docs/README.imxmage for more details about how-to configure -# and create imximage boot image -# -# The syntax is taken as close as possible with the kwbimage - -# Boot Device : one of -# spi, sd (the board has no nand neither onenand) -BOOT_FROM spi - -# Device Configuration Data (DCD) -# -# Each entry must have the format: -# Addr-type AddressValue -# -# where: -# Addr-type register length (1,2 or 4 bytes) -# Address absolute address of the register -# value value to be stored in the register - -# Setting IOMUXC -DATA 4 0x73fa88a0 0x000 -DATA 4 0x73fa850c 0x20c5 -DATA 4 0x73fa8510 0x20c5 -DATA 4 0x73fa883c 0x5 -DATA 4 0x73fa8848 0x5 -DATA 4 0x73fa84b8 0xe7 -DATA 4 0x73fa84bc 0x45 -DATA 4 0x73fa84c0 0x45 -DATA 4 0x73fa84c4 0x45 -DATA 4 0x73fa84c8 0x45 -DATA 4 0x73fa8820 0x0 -DATA 4 0x73fa84a4 0x5 -DATA 4 0x73fa84a8 0x5 -DATA 4 0x73fa84ac 0xe5 -DATA 4 0x73fa84b0 0xe5 -DATA 4 0x73fa84b4 0xe5 -DATA 4 0x73fa84cc 0xe5 -DATA 4 0x73fa84d0 0xe4 - -DATA 4 0x73fa882c 0x4 -DATA 4 0x73fa88a4 0x4 -DATA 4 0x73fa88ac 0x4 -DATA 4 0x73fa88b8 0x4 - -# Setting DDR for micron -# 13 Rows, 10 Cols, 32 bit, SREF=4 Micron Model -# CAS=3 BL=4 -# ESDCTL_ESDCTL0 -DATA 4 0x83fd9000 0x82a2 -# ESDCTL_ESDCTL1 -DATA 4 0x83fd9008 0x82a2 -# ESDCTL_ESDMISC -DATA 4 0x83fd9010 0xcaaaf6d0 -# ESDCTL_ESDCFG0 -DATA 4 0x83fd9004 0x3f3574aa -# ESDCTL_ESDCFG1 -DATA 4 0x83fd900c 0x3f3574aa - -# Init DRAM on CS0 -# ESDCTL_ESDSCR -DATA 4 0x83fd9014 0x04008008 -DATA 4 0x83fd9014 0x801a -DATA 4 0x83fd9014 0x801b -DATA 4 0x83fd9014 0x00448019 -DATA 4 0x83fd9014 0x07328018 -DATA 4 0x83fd9014 0x04008008 -DATA 4 0x83fd9014 0x8010 -DATA 4 0x83fd9014 0x8010 -DATA 4 0x83fd9014 0x06328018 -DATA 4 0x83fd9014 0x03808019 -DATA 4 0x83fd9014 0x00408019 -DATA 4 0x83fd9014 0x8000 - -# Init DRAM on CS1 -DATA 4 0x83fd9014 0x0400800c -DATA 4 0x83fd9014 0x801e -DATA 4 0x83fd9014 0x801f -DATA 4 0x83fd9014 0x801d -DATA 4 0x83fd9014 0x0732801c -DATA 4 0x83fd9014 0x0400800c -DATA 4 0x83fd9014 0x8014 -DATA 4 0x83fd9014 0x8014 -DATA 4 0x83fd9014 0x0632801c -DATA 4 0x83fd9014 0x0380801d -DATA 4 0x83fd9014 0x0040801d -DATA 4 0x83fd9014 0x8004 - -# Write to CTL0 -DATA 4 0x83fd9000 0xb2a2 -# Write to CTL1 -DATA 4 0x83fd9008 0xb2a2 -# ESDMISC -DATA 4 0x83fd9010 0x000ad6d0 -#ESDCTL_ESDCDLYGD -DATA 4 0x83fd9034 0x9000 -DATA 4 0x83fd9014 0x diff --git a/board/efikamx/imximage_mx.cfg b/board/efikamx/imximage_mx.cfg new file mode 100644 index 000..6fe0ff9 --- /dev/null +++ b/board/efikamx/imximage_mx.cfg @@ -0,0 +1,122 @@ +# +# Copyright (C) 2010 Marek Vasut +# +# BASED ON: imx51evk +# +# (C) Copyright 2009 +# Stefano Babic DENX Software Engineering sba...@denx.de. +# +# 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
Re: [U-Boot] [STATUS] [ARM] Status for last 13 unclean-building ARM boards
Am 09/17/2011 10:12 AM, schrieb Albert ARIBAUD: > (board maintainers in CC:) > > Hi all, > > There remains 13 boards listed as having warnings or errors at this > point in a ./MAKEALL arm: > > - SUMMARY > Boards compiled: 242 > Boards with warnings or errors: 13 ( omap3_beagle actux1_4_16 > actux1_8_16 actux1_4_32 actux1_8_32 actux2 actux3 actux4 dvlhost > ixdp425 ixdpg425 pdnb3 scpu ) > -- > > Of these, > > 1. omap3_beagle has a 'simple' warning "beagle.c:532: warning: > initialization from incompatible pointer type". Dirk, can you look > into it? > > 2. ixdp425 is marked "orphaned". Stefan, I am wild-guessing that > ixdp425 might be acquainted to the ixdpg425 that you maintain. Do you > want to take ixdp425? If not, we should drop it. I do have one of these @work, but rarely take it out of the closet. I can run tests if required. but I am not sure if it is worth the effort to keep it. OTOH, ixdgp425 seems to be an almost exact clone of the ixdp425, with different PCB layout, so ditching one and keeping the other makes not much sense IMHO. > > 3. All others have the same issue, namely "arm-linux-ld: stubs.o: > compiled for a big endian system and target is little endian". Seems > for this one, I am not using the right toolchain or at least the right > libs. Can one of the maintainers let me know how exactly they build > their boards? Just tried actux3 - I get only this one warning: /usr/local/pkg/x-tools/armeb-unknown-linux-gnu/bin/.armeb-unknown-linux-gnu-ld: warning: creating a DT_TEXTREL in object. AFAIK, that one has been there since relocation was added. I compile using > export CROSS_COMPILE=/opt/x-tools/armeb-unknown-linux-gnu/bin/armeb-unknown-linux-gnu- > make /opt/x-tools/armeb-unknown-linux-gnu/bin/armeb-unknown-linux-gnu-gcc -v shows Configured with: /export/cgcc/b-arm-linux-gcc/targets/src/gcc-4.3.4/configure --build=i486-build_pc-linux-gnu --host=i486-build_pc-linux-gnu --target=armeb-unknown-linux-gnu --prefix=/opt/x-tools/armeb-unknown-linux-gnu --with-sysroot=/opt/x-tools/armeb-unknown-linux-gnu/armeb-unknown-linux-gnu//sys-root --enable-languages=c,c++ --disable-multilib --with-arch=armv5te --with-cpu=xscale --with-tune=xscale --with-float=soft --with-pkgversion=crosstool-NG-hg_default@1471_4a88cb9bfe8f --enable-__cxa_atexit --with-gmp=/opt/x-tools/armeb-unknown-linux-gnu --with-mpfr=/opt/x-tools/armeb-unknown-linux-gnu --with-local-prefix=/opt/x-tools/armeb-unknown-linux-gnu/armeb-unknown-linux-gnu//sys-root --disable-nls --enable-threads=posix --enable-symvers=gnu --enable-c99 --enable-long-long --enable-target-optspace Thread model: posix gcc version 4.3.4 (crosstool-NG-hg_default@1471_4a88cb9bfe8f) cu Michael ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] start.S
On 09/19/11 14:28, maheen butt wrote: > Hi > I'm newbie in the boot loader world. I'm trying to learning the > source code for porting purpose. U-boot > start execution from start.S.I want to know that which part > of start.S jump to c code? and what is first function comes > after start.S? > > Thanks Depends on the architecture you compiled U-boot for. What is your target board? Each architecture has it's own start.S ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] start.S
Hi I'm newbie in the boot loader world. I'm trying to learning the source code for porting purpose. U-boot start execution from start.S.I want to know that which part of start.S jump to c code? and what is first function comes after start.S? Thanks ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] punt unused clean/distclean targets
On 09/19/2011 01:54 AM, Wolfgang Denk wrote: > Dear Mike Frysinger, > > In message <201109190059.55664.vap...@gentoo.org> you wrote: >> >> if it wasn't clear in my last e-mail, i want to move in the direction of .mk >> files that the top level would include them and thus all the specific cruft >> would be kept there > > Why should we do that? > > Having all build rules in a single, huge Makefile does not sound like > something that is desirable (and in this context it does not make any > difference if the file is actually a concatenation of all these build > rules, or if it's hidden in a set of [probably even nested] includes). > > I'm still a big friend of organizing complex stuff in small, > hierarchical structured pieces, so I have to u nderstand it only a > small bit at a time. > > Yes, running a number of nested makes may have some performance > penalty. But frankly: I care a ship about that when I can have the > sofware design simpler and easier to maintain. It's not just about build time. Recursive make adds complexity -- you not only need to know what you want to build, but which directory holds the makefile. See http://lists.denx.de/pipermail/u-boot/2011-September/101551.html You also get to play the game of which variables are passed on as variables, which are passed on as overrides, etc. While dealing with make is never pleasant, I've found dealing with non-recursive setups to be in general less unpleasant than dealing with recursive make. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2 RESEND] SPL: Allow user to disable CPU support library
On 09/16/2011 05:48 PM, Marek Vasut wrote: > On Saturday, September 17, 2011 12:07:52 AM Scott Wood wrote: >> You have no idea why I'd like to be extremely selective with what I >> include in a 4K binary? > > That I do understand -- but that kind of selection is there. >> >> It's not about avoiding particular files. It's about including >> *nothing* but what is explicitly asked for through some SPL-specific >> CONFIG symbol. Maybe that includes everything in arch/$(ARCH)/cpu. >> Maybe it includes nothing in there. More likely, it includes just a >> fraction of it. > > The stuff in arch/arm/cpu should be exactly what you need, nothing more ! This is "spl/", not "arch/arm/spl/", so let's not reason from one architecture, much less the subset of that architecture that has already been made to work with spl/ -- there are 14 different instances of arch/arm/cpu/$(CPU). We will not want everything we normally pull from arch/powerpc/cpu/mpc85xx to go into an 85xx NAND SPL, for example. But we will want some small portion of it. My understanding of how spl/ is meant to work is that each directory's makefiles will use special SPL config symbols to decide what individual objects (if any) to include. It's not clear to me why we need a directory-level control. Maybe it would be the most convenient way to implement it for something that is well-encapsulated and arch-neutral (thus only one instance to worry about), where the odds of a subset being useful are slim, but it doesn't seem appropriate here. Whether it's file or directory based, everything should be off by default. Boards should ask for what they want, not what they want to exclude. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 27/31] M28: Save environment in NAND
On 09/17/2011 03:20 AM, Marek Vasut wrote: > On Friday, September 16, 2011 09:15:12 PM Scott Wood wrote: >> Consider using CONFIG_ENV_RANGE to allow for bad blocks. > > How does this actually play with CONFIG_MTDPARTS ? I don't think there's any direct interaction between the environment code and mtdparts. > For you see -- I now have > CONFIG_MTDPARTS "...128k(environment), 128k(redundant-environment)..." > and CONFIG_ENV_SECT_SIZE (128 * 1024). > > So what exactly am I supposed to set into CONFIG_ENV_RANGE and do I have to > modify the CONFIG_MTDPARTS? You'd have to make the environment partitions larger -- the idea is to provide an extra block or two in case of bad blocks. CONFIG_ENV_RANGE would be set to the partition size. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] MX31: Disable watchdog during low-power modes
Turn on the watchdog WDZST bit so that watchdog timer does not count during low
power modes.
Prior to applying this patch mx31pdk board got watchdog resets because when it
booted in the Linux prompt
and there was no activity, the system entered into idle mode while watchdog
timer was still active.
Fix this by disabling watchdog timer during idle mode.
Signed-off-by: Fabio Estevam
---
arch/arm/cpu/arm1136/mx31/timer.c |4 ++--
arch/arm/include/asm/arch-mx31/imx-regs.h |2 ++
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/arm/cpu/arm1136/mx31/timer.c
b/arch/arm/cpu/arm1136/mx31/timer.c
index c05a39d..7197108 100644
--- a/arch/arm/cpu/arm1136/mx31/timer.c
+++ b/arch/arm/cpu/arm1136/mx31/timer.c
@@ -173,8 +173,8 @@ void mxc_hw_watchdog_enable(void)
#else
secs = 64;
#endif
- writew(readw(&wdog->wcr) | (secs << WDOG_WT_SHIFT) | WDOG_ENABLE,
- &wdog->wcr);
+ writew(readw(&wdog->wcr) | (secs << WDOG_WT_SHIFT) | WDOG_ENABLE
+ | WDOG_WDZST, &wdog->wcr);
}
diff --git a/arch/arm/include/asm/arch-mx31/imx-regs.h
b/arch/arm/include/asm/arch-mx31/imx-regs.h
index 2064870..338ba4d 100644
--- a/arch/arm/include/asm/arch-mx31/imx-regs.h
+++ b/arch/arm/include/asm/arch-mx31/imx-regs.h
@@ -71,6 +71,8 @@ struct cspi_regs {
/* Watchdog Timer (WDOG) registers */
#define WDOG_ENABLE(1 << 2)
#define WDOG_WT_SHIFT 8
+#define WDOG_WDZST 1
+
struct wdog_regs {
u16 wcr;/* Control */
u16 wsr;/* Service */
--
1.6.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] mx31pdk: Disable watchdog
Hi Stefano, On Mon, Sep 19, 2011 at 1:57 PM, Fabio Estevam wrote: > On Mon, Sep 19, 2011 at 1:24 PM, Stefano Babic wrote: > ... >> It works, the board does not get reset (of course, it is required to >> trigger at least once the watchdog under the kernel). I send my >> Tested-by to linux-arm. I managed to fix this and will submit a patch for U-boot shortly. Regards, Fabio Estevam ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] mx31pdk: Disable watchdog
On Mon, Sep 19, 2011 at 1:24 PM, Stefano Babic wrote: ... > It works, the board does not get reset (of course, it is required to > trigger at least once the watchdog under the kernel). I send my > Tested-by to linux-arm. Yes, looks like on my mx31pdk the kernel never services the watchdog. Will try to debug the kernel then. Thanks for testing it on qong board. Regards, Fabio Estevam ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] mx31pdk: Disable watchdog
On 09/19/2011 05:04 PM, Fabio Estevam wrote: > Hi Stefano, > > On Fri, Sep 16, 2011 at 4:46 AM, Stefano Babic wrote: >> On 09/16/2011 01:18 AM, Fabio Estevam wrote: >> >> Hi Fabio, >> >>> When booting a mainline kernel on a mx31pdk the system gets getting resets >>> from the watchdog. >>> >>> As the kernel has watchdog support, disable it from U-boot. >> >> But if the kernel has support for watchdog, why does the system reset ? >> I checked this board and the watchdog in u-boot is set to 64 seconds, >> that is the maximum value. It is surely enough for kernel to boot and to >> start triggering the watchdog. If the system still reboots, it seems to >> me that this is an issue to be fixed in kernel, not in u-boot. I am sure >> I have tested in the past (not recently) the QONG board with enabled >> watchdog, using also the imx2_wdt driver in kernel. > > I have sent a patch to the ARM kernel list to add watchdog support for > qong board: > http://lists.infradead.org/pipermail/linux-arm-kernel/2011-September/065698.html Ok, thanks. > > Can you please try it and let me know if you get resets when watchdog > is enabled in U-boot > and kernel? It works, the board does not get reset (of course, it is required to trigger at least once the watchdog under the kernel). I send my Tested-by to linux-arm. Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] net/bootp.c: fix tftp load if autoload environment var isn't set
Hi Peter, On Mon, Sep 19, 2011 at 8:29 AM, Peter Korsgaard wrote: >> "Simon" == Simon Glass writes: > > Hi, > > Simon> I think we just had this discussion at the end of August. It > Simon> would be good to get to the bottom of why this commit is > Simon> considered a change of behaviour - it is something subtle that I > Simon> cannot see. > > Because with that commit it no longer calls TftpStart() if the autoload > variable isn't set (it moved into the if (getenv..) conditional). OK I see thank you. > > Simon> But first: if autoload is not defined, it is supposed to default to > Simon> 'y'. If you want it to be 'n' then you need to set it. It that what > Simon> you expect? > > Yes, no autoload should behave like autoload=y, E.G. call TftpStart(). Acked-by: Simon Glass Regards, Simon > > -- > Bye, Peter Korsgaard > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] net/bootp.c: fix tftp load if autoload environment var isn't set
> "Simon" == Simon Glass writes: Hi, Simon> I think we just had this discussion at the end of August. It Simon> would be good to get to the bottom of why this commit is Simon> considered a change of behaviour - it is something subtle that I Simon> cannot see. Because with that commit it no longer calls TftpStart() if the autoload variable isn't set (it moved into the if (getenv..) conditional). Simon> But first: if autoload is not defined, it is supposed to default to Simon> 'y'. If you want it to be 'n' then you need to set it. It that what Simon> you expect? Yes, no autoload should behave like autoload=y, E.G. call TftpStart(). -- Bye, Peter Korsgaard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [RFC 2/2] misc:pmic:max8998: Support for max8998 pmic
This commit enables the max8998 PMIC to run with pmic_core.c generic
driver.
Signed-off-by: Lukasz Majewski
---
board/samsung/goni/goni.c | 18 +
include/configs/s5p_goni.h |3 ++
include/max8998_pmic.h | 84
3 files changed, 105 insertions(+), 0 deletions(-)
create mode 100644 include/max8998_pmic.h
diff --git a/board/samsung/goni/goni.c b/board/samsung/goni/goni.c
index e24cd29..3e0cb74 100644
--- a/board/samsung/goni/goni.c
+++ b/board/samsung/goni/goni.c
@@ -25,6 +25,8 @@
#include
#include
#include
+#include
+#include
DECLARE_GLOBAL_DATA_PTR;
@@ -59,6 +61,22 @@ void dram_init_banksize(void)
gd->bd->bi_dram[2].size = PHYS_SDRAM_3_SIZE;
}
+int board_pmic_init(struct pmic *p)
+{
+ static char name[] = "MAX8998_PMIC";
+
+ puts("Board PMIC init\n");
+
+ p->name = name;
+ p->interface = PMIC_I2C;
+ p->number_of_regs = PMIC_NUM_OF_REGS;
+ p->hw.i2c.addr = MAX8998_I2C_ADDR;
+ p->hw.i2c.tx_num = 1;
+ p->hw.i2c.bus_num = I2C_PMIC;
+
+ return 0;
+}
+
#ifdef CONFIG_DISPLAY_BOARDINFO
int checkboard(void)
{
diff --git a/include/configs/s5p_goni.h b/include/configs/s5p_goni.h
index 886c8be..e26dcb2 100644
--- a/include/configs/s5p_goni.h
+++ b/include/configs/s5p_goni.h
@@ -223,6 +223,9 @@
#define CONFIG_SYS_INIT_SP_ADDR(CONFIG_SYS_LOAD_ADDR - 0x100)
+#define CONFIG_PMIC
+#define CONFIG_PMIC_I2C
+
#include
/*
* I2C Settings
diff --git a/include/max8998_pmic.h b/include/max8998_pmic.h
new file mode 100644
index 000..bf28820
--- /dev/null
+++ b/include/max8998_pmic.h
@@ -0,0 +1,84 @@
+/*
+ * Copyright (C) 2011 Samsung Electronics
+ * Lukasz Majewski
+ *
+ * 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
+ */
+
+#ifndef __MAX8998_PMIC_H_
+#define __MAX8998_PMIC_H_
+
+/* MAX 8998 registers */
+enum {
+ MAX8998_REG_IRQ1,
+ MAX8998_REG_IRQ2,
+ MAX8998_REG_IRQ3,
+ MAX8998_REG_IRQ4,
+ MAX8998_REG_IRQM1,
+ MAX8998_REG_IRQM2,
+ MAX8998_REG_IRQM3,
+ MAX8998_REG_IRQM4,
+ MAX8998_REG_STATUS1,
+ MAX8998_REG_STATUS2,
+ MAX8998_REG_STATUSM1,
+ MAX8998_REG_STATUSM2,
+ MAX8998_REG_CHGR1,
+ MAX8998_REG_CHGR2,
+ MAX8998_REG_LDO_ACTIVE_DISCHARGE1,
+ MAX8998_REG_LDO_ACTIVE_DISCHARGE2,
+ MAX8998_REG_BUCK_ACTIVE_DISCHARGE3,
+ MAX8998_REG_ONOFF1,
+ MAX8998_REG_ONOFF2,
+ MAX8998_REG_ONOFF3,
+ MAX8998_REG_ONOFF4,
+ MAX8998_REG_BUCK1_VOLTAGE1,
+ MAX8998_REG_BUCK1_VOLTAGE2,
+ MAX8998_REG_BUCK1_VOLTAGE3,
+ MAX8998_REG_BUCK1_VOLTAGE4,
+ MAX8998_REG_BUCK2_VOLTAGE1,
+ MAX8998_REG_BUCK2_VOLTAGE2,
+ MAX8998_REG_BUCK3,
+ MAX8998_REG_BUCK4,
+ MAX8998_REG_LDO2_LDO3,
+ MAX8998_REG_LDO4,
+ MAX8998_REG_LDO5,
+ MAX8998_REG_LDO6,
+ MAX8998_REG_LDO7,
+ MAX8998_REG_LDO8_LDO9,
+ MAX8998_REG_LDO10_LDO11,
+ MAX8998_REG_LDO12,
+ MAX8998_REG_LDO13,
+ MAX8998_REG_LDO14,
+ MAX8998_REG_LDO15,
+ MAX8998_REG_LDO16,
+ MAX8998_REG_LDO17,
+ MAX8998_REG_BKCHR,
+ MAX8998_REG_LBCNFG1,
+ MAX8998_REG_LBCNFG2,
+ PMIC_NUM_OF_REGS,
+};
+
+#define MAX8998_LDO3 (1 << 2)
+#define MAX8998_LDO8 (1 << 5)
+
+#define MAX8998_I2C_ADDR(0xCC >> 1)
+
+enum { LDO_OFF, LDO_ON };
+
+#endif /* __MAX8998_PMIC_H_ */
--
1.7.2.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [RFC 1/2] misc:pmic New generic pmic driver
This commit adds new PMIC core driver
PMIC IC devices connected via I2C or SPI can be used.
Signed-off-by: Lukasz Majewski
---
arch/arm/lib/board.c |5 +
drivers/misc/Makefile|1 +
drivers/misc/pmic_core.c | 236 ++
include/pmic.h | 60
4 files changed, 302 insertions(+), 0 deletions(-)
create mode 100644 drivers/misc/pmic_core.c
create mode 100644 include/pmic.h
diff --git a/arch/arm/lib/board.c b/arch/arm/lib/board.c
index c899839..bd2c619 100644
--- a/arch/arm/lib/board.c
+++ b/arch/arm/lib/board.c
@@ -48,6 +48,7 @@
#include
#include
#include
+#include
#ifdef CONFIG_BITBANGMII
#include
@@ -580,6 +581,10 @@ void board_init_r(gd_t *id, ulong dest_addr)
copy_filename(BootFile, s, sizeof(BootFile));
#endif
+#if defined(CONFIG_PMIC)
+ pmic_init();
+#endif
+
#ifdef BOARD_LATE_INIT
board_late_init();
#endif
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index b152486..f710a29 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -35,6 +35,7 @@ COBJS-$(CONFIG_NS87308) += ns87308.o
COBJS-$(CONFIG_PDSP188x) += pdsp188x.o
COBJS-$(CONFIG_STATUS_LED) += status_led.o
COBJS-$(CONFIG_TWL4030_LED) += twl4030_led.o
+COBJS-$(CONFIG_PMIC) += pmic_core.o
COBJS := $(COBJS-y)
SRCS := $(COBJS:.o=.c)
diff --git a/drivers/misc/pmic_core.c b/drivers/misc/pmic_core.c
new file mode 100644
index 000..d96bb87
--- /dev/null
+++ b/drivers/misc/pmic_core.c
@@ -0,0 +1,236 @@
+/*
+ * Copyright (C) 2011 Samsung Electronics
+ * Lukasz Majewski
+ *
+ * (C) Copyright 2008-2009 Freescale Semiconductor, Inc.
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#include
+#include
+#include
+
+static struct pmic pmic;
+
+#ifdef CONFIG_PMIC_I2C
+#include
+#define pmic_set_reg(r) (p->hw.i2c.reg = r)
+#define pmic_set_addr(a) (p->hw.i2c.addr = a)
+#define pmic_i2c_addr (p->hw.i2c.addr)
+#define pmic_i2c_reg (p->hw.i2c.reg)
+#define pmic_tx_num (p->hw.i2c.tx_num)
+#define pmic_i2c_bus (p->hw.i2c.bus_num)
+
+int pmic_reg_write(struct pmic *p, u32 *val)
+{
+ unsigned char buf[4] = { 0 };
+
+ switch (pmic_tx_num) {
+ case 3:
+ buf[0] = (*val >> 16) & 0xff;
+ buf[1] = (*val >> 8) & 0xff;
+ buf[2] = (*val) & 0xff;
+ break;
+ case 1:
+ buf[0] = (*val) & 0xff;
+ break;
+ }
+
+ if (i2c_write(pmic_i2c_addr, pmic_i2c_reg, 1, buf, pmic_tx_num))
+ return -1;
+
+ return 0;
+}
+
+int pmic_reg_read(struct pmic *p, u32 *val)
+{
+ unsigned char buf[4] = { 0 };
+ u32 ret_val = 0;
+
+ if (i2c_read(pmic_i2c_addr, pmic_i2c_reg, 1, buf, pmic_tx_num))
+ return -1;
+
+ switch (pmic_tx_num) {
+ case 3:
+ ret_val = buf[0] << 16 | buf[1] << 8 | buf[2];
+ break;
+ case 1:
+ ret_val = buf[0];
+ break;
+ }
+ memcpy(val, &ret_val, sizeof(ret_val));
+ /* printf("val 0x%x:", *val); */
+
+ return 0;
+}
+
+int pmic_probe(struct pmic *p)
+{
+ i2c_set_bus_num(pmic_i2c_bus);
+ printf("PMIC:%s probed!\n", p->name);
+ if (i2c_probe(pmic_i2c_addr)) {
+ puts("Can't find max8998\n");
+ return -1;
+ }
+
+ return 0;
+}
+#else /* SPI interface */
+#include
+static struct spi_slave *slave;
+
+#define pmic_set_reg(r)
+#define pmic_set_addr(a)
+
+void pmic_spi_free(struct spi_slave *slave)
+{
+ if (slave)
+ spi_free_slave(slave);
+}
+
+
+int pmic_reg_write(struct pmic *p, u32 *val)
+{
+ return 0;
+}
+
+int pmic_reg_read(struct pmic *p, u32 *val)
+{
+ return 0;
+}
+#endif
+
+int __attribute__((weak)) board_pmic_init(struct pmic *p)
+{
+ puts("weak function");
+ return 0;
+}
+
+int pmic_set_output(struct pmic *p, int out, int on)
+{
+ u32 val;
+
+ if (pmic_reg_read(p, &val))
+ return -1;
+
+ if (on)
+ val |= out;
+ else
+ val &= ~out;
+
+ if (pmic_reg_write(p, &val))
+ return -1;
+
+ return 0;
+}
+
+static void pm
[U-Boot] [RFC 0/2] Generic PMIC driver
Dear all,
I'd like to propose a new approach for PMIC generic driver.
In my opinion following issues needs discussion:
1. In proposed
int pmic_reg_read(struct pmic *p, u32 *val) the val is returned by pointer.
Now at fsl_pmic.c read value is returned by return clause.
I think, that passing pointer is a better approach,since errors from
i2c_read/spi_read can be
caught in upper layers.
2. Since I haven't got a chance to test SPI part of the fsl_pmic.c driver, I've
focused
mainly on I2C and place stubs for SPI.
3. Suggestions for struct pmic's additional fields for SPI are more than
welcome :-)
4. Now the pmic_core.c file consist of
#ifdef PMIC_I2C
{Code for handling I2C}
#else
{Code for handling SPI}
#endif
The same approach is used at fsl_pmic.c
I'm wondering if this approach shouldn't be replaced with on-time checking if
SPI or I2C interface is available.
This check can be performed by:
struct pmic *p;
if (p->interface == PMIC_I2C) {
} else {
}
It would allow to remove obscure #ifdefs, but on the other hand it will reduce
execution speed of the driver.
Thanks in advance,
Lukasz
Lukasz Majewski (2):
misc:pmic New generic pmic driver
misc:pmic:max8998: Support for max8998 pmic
arch/arm/lib/board.c |5 +
board/samsung/goni/goni.c | 18
drivers/misc/Makefile |1 +
drivers/misc/pmic_core.c | 236
include/configs/s5p_goni.h |3 +
include/max8998_pmic.h | 84
include/pmic.h | 60 +++
7 files changed, 407 insertions(+), 0 deletions(-)
create mode 100644 drivers/misc/pmic_core.c
create mode 100644 include/max8998_pmic.h
create mode 100644 include/pmic.h
--
1.7.2.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] mx31pdk: Disable watchdog
Hi Stefano, On Fri, Sep 16, 2011 at 4:46 AM, Stefano Babic wrote: > On 09/16/2011 01:18 AM, Fabio Estevam wrote: > > Hi Fabio, > >> When booting a mainline kernel on a mx31pdk the system gets getting resets >> from the watchdog. >> >> As the kernel has watchdog support, disable it from U-boot. > > But if the kernel has support for watchdog, why does the system reset ? > I checked this board and the watchdog in u-boot is set to 64 seconds, > that is the maximum value. It is surely enough for kernel to boot and to > start triggering the watchdog. If the system still reboots, it seems to > me that this is an issue to be fixed in kernel, not in u-boot. I am sure > I have tested in the past (not recently) the QONG board with enabled > watchdog, using also the imx2_wdt driver in kernel. I have sent a patch to the ARM kernel list to add watchdog support for qong board: http://lists.infradead.org/pipermail/linux-arm-kernel/2011-September/065698.html Can you please try it and let me know if you get resets when watchdog is enabled in U-boot and kernel? Thanks, Fabio Estevam ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] net/bootp.c: fix tftp load if autoload environment var isn't set
Hi Peter, On Mon, Sep 19, 2011 at 6:47 AM, Fabio Estevam wrote: > On Mon, Sep 19, 2011 at 4:54 AM, Peter Korsgaard wrote: >> Commit 093498669 (Put common autoload code into auto_load() function) >> broke handling of autoload environment variable not being set. >> The bootp/dhcp code will just keep on requesting IP address forever >> and never start TFTP download. >> >> Fix it by moving TftpStart() outside the conditional like it was before. >> >> Signed-off-by: Peter Korsgaard > > This makes mx31pdk networking to work again at my company's network. > > Tested-by: Fabio Estevam I think we just had this discussion at the end of August. It would be good to get to the bottom of why this commit is considered a change of behaviour - it is something subtle that I cannot see. But first: if autoload is not defined, it is supposed to default to 'y'. If you want it to be 'n' then you need to set it. It that what you expect? Regards, Simon > > Thanks, > > Fabio Estevam > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] mkconfig: start deprecating Makefile config targets
On Monday, September 19, 2011 10:14:46 Wolfgang Denk wrote: > Mike Frysinger wrote: > > Now that we've got boards.cfg and most people have converted over, > > start warning people who have yet to so we can phase board configs > > completely out of the Makefile. > > > > Signed-off-by: Mike Frysinger > > --- > > v2 > > > > - fix typo in warning msg > > > > mkconfig |9 + > > 1 files changed, 9 insertions(+), 0 deletions(-) > > Please update doc/feature-removal-schedule.txt as well. i didnt have a schedule in mind ... just start scaring people :) any target you have in mind ? -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] punt unused clean/distclean targets
On Monday, September 19, 2011 02:54:35 Wolfgang Denk wrote: > Mike Frysinger wrote: > > if it wasn't clear in my last e-mail, i want to move in the direction of > > .mk files that the top level would include them and thus all the > > specific cruft would be kept there > > Why should we do that? > > Having all build rules in a single, huge Makefile does not sound like > something that is desirable (and in this context it does not make any > difference if the file is actually a concatenation of all these build > rules, or if it's hidden in a set of [probably even nested] includes). > > I'm still a big friend of organizing complex stuff in small, > hierarchical structured pieces, so I have to u nderstand it only a > small bit at a time. > > Yes, running a number of nested makes may have some performance > penalty. But frankly: I care a ship about that when I can have the > sofware design simpler and easier to maintain. i dont think my proposal will be more complex. however, i do think copying & pasting almost the same exact lines over and over across literally hundreds of Makefile's is a broken design. > > after all, the list of things to clean should be obvious once we have > > more kbuild style system: if it's listed as a file to build, then it > > should get cleaned. > > Keep in mind that you said yourslef we always want to remove _all_ > build results - this includes evne those not "listed as a file to > buil" for a specific configuration setting. as i mentioned in another e-mail, you do get access to the complete list regardless of config. COBJS-$(FOO) evaluates to one of two lists: $(COBJS-y) or $(COBJS-). -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/4] SPI: Add SPI driver support for Marvell Armada100
On Monday, September 19, 2011 06:47:07 Ajay Bhargav wrote:
> --- /dev/null
> +++ b/arch/arm/include/asm/arch-armada100/spi.h
>
> +struct armd_spi_slave {
> + struct spi_slave slave;
> + struct ssp_reg *spi_reg;
> + u32 cr0, cr1;
> + u32 int_cr1;
> + u32 clear_sr;
> + const void *tx;
> + void *rx;
> + int gpio_cs_inverted;
> +
> + void (*write)(struct armd_spi_slave *pss);
> + void (*read)(struct armd_spi_slave *pss);
> +};
> +
> +#define to_armd_spi_slave(s) container_of(s, struct armd_spi_slave, slave)
i dont think internal driver details should be in a header. these should be
moved to armada100_spi.c.
> --- /dev/null
> +++ b/drivers/spi/armada100_spi.c
>
> +static void null_writer(struct armd_spi_slave *pss)
> +static void null_reader(struct armd_spi_slave *pss)
> +static void u8_writer(struct armd_spi_slave *pss)
> +static void u8_reader(struct armd_spi_slave *pss)
> +static int flush(struct armd_spi_slave *pss)
please prefix these with something like "spi_armd_". generic names like this
are often hard to trace back when debugging.
-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] Please pull u-boot-ti/next
> > Hi Wofgang, > > Le 19/09/2011 09:47, Wolfgang Denk a écrit : > > Dear Albert ARIBAUD, > > > > In message<4e76ebfd.9060...@aribaud.net> you wrote: > >> > >> As this is your 'next' branch, there is an ambiguity: can you please > >> indicate if you want me to pull this into my 'next' or 'master' branch? > >> > >> If on master, I assume you want me to also send out a pull request to > >> Wolfgang, but I am not sure Wolfgang will allow it at this time. > > > > If I understand correctly this is mostly fixes, so I'd take it. > > Sandeep's 'next' branch is based on my 'next', not on my 'master', hence > my question -- there would have to be a rebase if Sandeep expected me to > pull into my master. > > Sandeep, can you confirm what you want exactly? Meanwhile, I am > launching regression builds on u-boot-ti/next, just in case. > Albert, The pull request if for your next branch. Thanks, Sandeep ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] mkconfig: start deprecating Makefile config targets
Dear Mike Frysinger, In message <1316441157-24823-1-git-send-email-vap...@gentoo.org> you wrote: > Now that we've got boards.cfg and most people have converted over, > start warning people who have yet to so we can phase board configs > completely out of the Makefile. > > Signed-off-by: Mike Frysinger > --- > v2 > - fix typo in warning msg > > mkconfig |9 + > 1 files changed, 9 insertions(+), 0 deletions(-) Please update doc/feature-removal-schedule.txt as well. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de "A little knowledge is a dangerous thing."- Doug Gwyn ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] mkconfig: start deprecating Makefile config targets
Now that we've got boards.cfg and most people have converted over,
start warning people who have yet to so we can phase board configs
completely out of the Makefile.
Signed-off-by: Mike Frysinger
---
v2
- fix typo in warning msg
mkconfig |9 +
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/mkconfig b/mkconfig
index ecb6d4e..438530b 100755
--- a/mkconfig
+++ b/mkconfig
@@ -29,6 +29,15 @@ if [ \( $# -eq 2 \) -a \( "$1" = "-A" \) ] ; then
set ${line}
# add default board name if needed
[ $# = 3 ] && set ${line} ${1}
+elif [ "${MAKEFLAGS+set}${MAKELEVEL+set}" = "setset" ] ; then
+ # only warn when using a config target in the Makefile
+ cat <<-EOF
+
+ warning: Please migrate to boards.cfg. Failure to do so will
+mean removal of your board in the next release.
+
+ EOF
+ sleep 5
fi
while [ $# -gt 0 ] ; do
--
1.7.6
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] net/bootp.c: fix tftp load if autoload environment var isn't set
On Mon, Sep 19, 2011 at 4:54 AM, Peter Korsgaard wrote: > Commit 093498669 (Put common autoload code into auto_load() function) > broke handling of autoload environment variable not being set. > The bootp/dhcp code will just keep on requesting IP address forever > and never start TFTP download. > > Fix it by moving TftpStart() outside the conditional like it was before. > > Signed-off-by: Peter Korsgaard This makes mx31pdk networking to work again at my company's network. Tested-by: Fabio Estevam Thanks, Fabio Estevam ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V3] arm: Add Prep subcommand support to bootm
Adds prep subcommand to bootm implementation of ARM. When bootm is called with
the subcommand prep the function stops right after ATAGS creation and before
announce_and_cleanup.
This is used in command "cmd_spl export"
Signed-off-by: Simon Schwarz
---
V2 changes:
nothing
V3 changes:
nothing
changes after slicing this from patch
http://article.gmane.org/gmane.comp.boot-loaders.u-boot/106422:
DEL Prototype declaration - not necessary if reordered
DEL Most #ifdefs - relying on -ffunction-sections and --gc-sections to handle
unused
CHG reorganized bootm. powerpc implementation was the model
ADD get_board_serial fake implementation - this is needed if setup_serial_tag
is compiled but the board doesn't support it - tradeoff for removing
#ifdefs
CHG changed back to former not checking for zero approach
V2 changes (after split):
CHG wrong comment using old savebp
DEL file-wide kernel-entry forward-defintion (moved to funciton using it)
DEL get_board_serial added #ifdef CONFIG_SERIAL_TAG to setup_serial_tag
instead
DEL boot_bd_t_linux and boot_cmdline_linux, do_bootm_linux returns -1 if
they are called
CHG boot_prep_linux: error text emitted
CHG some typos and style problems
CHG logic in do_bootm_linux to do it exactly like ppc no == 0
DEL extern from udc_disconnect - gc should do it
V3 changes:
ADD some #ifdefs to prevent compile errors and warnings
FIX build warnings regarding atags creation functions. Added #ifdefs
FIX compile warning implicit declaration of udc_disconnect. added bootm.h
REBASED on u-boot-ti
---
arch/arm/include/asm/bootm.h | 26
arch/arm/lib/bootm.c | 339 ++
2 files changed, 202 insertions(+), 163 deletions(-)
create mode 100644 arch/arm/include/asm/bootm.h
diff --git a/arch/arm/include/asm/bootm.h b/arch/arm/include/asm/bootm.h
new file mode 100644
index 000..db2ff94
--- /dev/null
+++ b/arch/arm/include/asm/bootm.h
@@ -0,0 +1,26 @@
+/* Copyright (C) 2011
+ * Corscience GmbH & Co. KG - Simon Schwarz
+ *
+ * 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
+ *
+ */
+#ifndef ARM_BOOTM_H
+#define ARM_BOOTM_H
+
+#ifdef CONFIG_USB_DEVICE
+extern void udc_disconnect(void);
+#endif
+
+#endif
diff --git a/arch/arm/lib/bootm.c b/arch/arm/lib/bootm.c
index 802e833..03c25e9 100644
--- a/arch/arm/lib/bootm.c
+++ b/arch/arm/lib/bootm.c
@@ -1,4 +1,8 @@
-/*
+/* Copyright (C) 2011
+ * Corscience GmbH & Co. KG - Simon Schwarz
+ * - Added prep subcommand support
+ * - Reorganized source - modeled after powerpc version
+ *
* (C) Copyright 2002
* Sysgo Real-Time Solutions, GmbH
* Marius Groeger
@@ -29,35 +33,26 @@
#include
#include
#include
+#include
DECLARE_GLOBAL_DATA_PTR;
-#if defined (CONFIG_SETUP_MEMORY_TAGS) || \
-defined (CONFIG_CMDLINE_TAG) || \
-defined (CONFIG_INITRD_TAG) || \
-defined (CONFIG_SERIAL_TAG) || \
-defined (CONFIG_REVISION_TAG)
-static void setup_start_tag (bd_t *bd);
-
-# ifdef CONFIG_SETUP_MEMORY_TAGS
-static void setup_memory_tags (bd_t *bd);
-# endif
-static void setup_commandline_tag (bd_t *bd, char *commandline);
-
-# ifdef CONFIG_INITRD_TAG
-static void setup_initrd_tag (bd_t *bd, ulong initrd_start,
- ulong initrd_end);
-# endif
-static void setup_end_tag (bd_t *bd);
-
+#if defined(CONFIG_SETUP_MEMORY_TAGS) || \
+ defined(CONFIG_CMDLINE_TAG) || \
+ defined(CONFIG_INITRD_TAG) || \
+ defined(CONFIG_SERIAL_TAG) || \
+ defined(CONFIG_REVISION_TAG)
static struct tag *params;
-#endif /* CONFIG_SETUP_MEMORY_TAGS || CONFIG_CMDLINE_TAG || CONFIG_INITRD_TAG
*/
-
-static ulong get_sp(void);
-#if defined(CONFIG_OF_LIBFDT)
-static int bootm_linux_fdt(int machid, bootm_headers_t *images);
#endif
+static ulong get_sp(void)
+{
+ ulong ret;
+
+ asm("mov %0, sp" : "=r"(ret) : );
+ return ret;
+}
+
void arch_lmb_reserve(struct lmb *lmb)
{
ulong sp;
@@ -80,85 +75,7 @@ void arch_lmb_reserve(struct lmb *lmb)
gd->bd->bi_dram[0].start + gd->bd->bi_dram[0].size - sp);
}
-static void announce_and_cleanup(void)
-{
- printf("\nStarting kernel ...\n\n");
-
-#ifdef CONFIG_USB_DEVICE
- {
- extern void udc_disconnect(void);
- udc_disconnect();
- }
-#endif
-
[U-Boot] [PATCH V5 6/6] omap-common: fixes BSS overwriting problem
spl_nand overwrote BSS section because it reads a whole block everytime. Now
loads the block to spare area and just copy the needed junk to destination.
Whole block read is necessary for ecc check!
Signed-off-by: Simon Schwarz
---
V2 changes:
nothing
V3 changes:
nothing
---
arch/arm/cpu/armv7/omap-common/spl_nand.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/arm/cpu/armv7/omap-common/spl_nand.c
b/arch/arm/cpu/armv7/omap-common/spl_nand.c
index 93f5183..ec56565 100644
--- a/arch/arm/cpu/armv7/omap-common/spl_nand.c
+++ b/arch/arm/cpu/armv7/omap-common/spl_nand.c
@@ -72,7 +72,8 @@ void spl_nand_load_image(void)
CONFIG_SYS_NAND_PAGE_SIZE, (void *)header);
spl_parse_image_header(header);
nand_spl_load_image(CONFIG_SYS_NAND_SPL_KERNEL_OFFS,
- spl_image.size, (void *)spl_image.load_addr);
+ spl_image.size,
+ (void *)spl_image.load_addr - sizeof(header));
} else
#endif
{
--
1.7.4.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V5 2/6] Add cmd_spl command
This adds a spl command to the u-boot.
Related config:
CONFIG_CMD_CPL
activate/deactivate the command
CONFIG_CMD_SPL_NAND_OFS
Offset in NAND to use
Signed-off-by: Simon Schwarz
---
V2 changes:
CHG corrected bootm call. Now bootm is called with five parameters including
Address of FDT in RAM. This fixes the hang on savebp fdt call.
ADD debug output of the actual bootm parameter call
CHG help message
V3 changes:
FIX added missing brackets
V4 changes:
CHG Corrected argument number in comments
CHG added check for CONFIG_OF_LIBFDT
CHG squashed the README to this commit
DEL define description from commit message - unused in this patch
CHG renamed to spl now with subcommand export, very different now
ADD New call style with subcommands.
CHG added printf where the image is located
CHG Patched README to reflect changes
CHG parameter count
CHG usage message
---
common/Makefile |1 +
common/cmd_spl.c | 214 ++
doc/README.commands.spl | 31 ++
include/cmd_spl.h| 30 ++
include/configs/devkit8000.h |7 ++
5 files changed, 283 insertions(+), 0 deletions(-)
create mode 100644 common/cmd_spl.c
create mode 100644 doc/README.commands.spl
create mode 100644 include/cmd_spl.h
diff --git a/common/Makefile b/common/Makefile
index 2edbd71..8b3321e 100644
--- a/common/Makefile
+++ b/common/Makefile
@@ -160,6 +160,7 @@ COBJS-$(CONFIG_USB_STORAGE) += usb_storage.o
endif
COBJS-$(CONFIG_CMD_XIMG) += cmd_ximg.o
COBJS-$(CONFIG_YAFFS2) += cmd_yaffs2.o
+COBJS-$(CONFIG_CMD_SPL) += cmd_spl.o
# others
COBJS-$(CONFIG_DDR_SPD) += ddr_spd.o
diff --git a/common/cmd_spl.c b/common/cmd_spl.c
new file mode 100644
index 000..51fc680
--- /dev/null
+++ b/common/cmd_spl.c
@@ -0,0 +1,214 @@
+/* Copyright (C) 2011
+ * Corscience GmbH & Co. KG - Simon Schwarz
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#include
+#include
+#include
+
+DECLARE_GLOBAL_DATA_PTR;
+
+/* Calls bootm with the parameters given */
+int call_bootm(int argc, char * const argv[], char *subcommand[])
+{
+ char *bootm_argv[5];
+ char command[] = "do_bootm";
+
+ int i = 0;
+ int ret = 0;
+
+ /* create paramter array */
+ bootm_argv[0] = command;
+ switch (argc) {
+ case 3:
+ bootm_argv[4] = argv[2]; /* fdt addr */
+ case 2:
+ bootm_argv[3] = argv[1]; /* initrd addr */
+ case 1:
+ bootm_argv[2] = argv[0]; /* kernel addr */
+ }
+
+
+ /* - do the work - */
+ /* exec subcommands of do_bootm to init the images
+* data structure */
+ while (subcommand[i] != '\0') {
+ bootm_argv[1] = subcommand[i];
+ debug("args: %s, %s, %s, %s, %s, %d\n", bootm_argv[0],
+ bootm_argv[1], bootm_argv[2], bootm_argv[3],
+ bootm_argv[4], argc);
+ ret = do_bootm(find_cmd("do_bootm"), 0, argc+2,
+ bootm_argv);
+ debug("Subcommand retcode: %d\n", ret);
+ i++;
+ }
+
+ if (ret) {
+ printf("ERROR prep subcommand failed!\n");
+ return -1;
+ }
+
+ return 0;
+}
+
+/* assemble the bootm paramteres for fdt creation */
+int spl_export_fdt(int argc, char * const argv[])
+{
+#ifdef CONFIG_OF_LIBFDT
+ /* Create subcommand string */
+ char *subcommand[] = {"start", "loados",
+#ifdef CONFIG_SYS_BOOT_RAMDISK_HIGH
+ "ramdisk",
+#endif
+ "fdt", "cmdline", "bdt", "prep", '\0'};
+
+ /* inspect paramters and execute bootm */
+ argc--;
+ argv++;
+ if (call_bootm(argc, argv, subcommand))
+ return -1;
+
+ printf("Argument image is now in RAM: 0x%p\n",
+ (void *)images.ft_addr);
+ return 0;
+#else
+ printf("Das U-Boot was build without fdt support - aborting\n");
+ return -1;
+#endif
+}
+
+/* assemble the bootm patameters for atags creation */
+int spl_export_atags(int argc, char * const argv[])
+{
+#if defined(CONFIG_SETUP_MEMORY_TAGS) || \
+ defined(CONFIG_CMDLINE_TAG) || \
+ defined(CONFIG_INITRD_TAG
[U-Boot] [PATCH V5 5/6] omap-common: Add NAND SPL linux booting
This implements booting of Linux from NAND in SPL
Related config parameters:
CONFIG_SYS_NAND_SPL_KERNEL_OFFS
Offset in NAND of direct boot kernel image to use in SPL
CONFIG_SYS_SPL_ARGS_ADDR
Address where the kernel boot arguments are expected - this is
normally RAM-start + 0x100 (on ARM)
Signed-off-by: Simon Schwarz
---
V2 changes:
nothing
V3 changes:
nothing
V4 changes:
ADD define description to commit message
CHG renaming some defines - renaming SAVEBP SPL
---
arch/arm/cpu/armv7/omap-common/spl_nand.c | 62 +---
1 files changed, 46 insertions(+), 16 deletions(-)
diff --git a/arch/arm/cpu/armv7/omap-common/spl_nand.c
b/arch/arm/cpu/armv7/omap-common/spl_nand.c
index af02a59..93f5183 100644
--- a/arch/arm/cpu/armv7/omap-common/spl_nand.c
+++ b/arch/arm/cpu/armv7/omap-common/spl_nand.c
@@ -24,6 +24,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -33,6 +34,7 @@
void spl_nand_load_image(void)
{
struct image_header *header;
+ int *src, *dst;
switch (omap_boot_mode()) {
case NAND_MODE_HW_ECC:
debug("spl: nand - using hw ecc\n");
@@ -46,26 +48,54 @@ void spl_nand_load_image(void)
/*use CONFIG_SYS_TEXT_BASE as temporary storage area */
header = (struct image_header *)(CONFIG_SYS_TEXT_BASE);
+#ifdef CONFIG_SPL_OS_BOOT
+ if (!spl_uboot_key()) {
+ /* load parameter image */
+ /* load to temp position since nand_spl_load_image reads
+* a whole block which is typically larger than
+* CONFIG_CMD_SAVEBP_WRITE_SIZE therefore may overwrite
+* following sections like BSS */
+ nand_spl_load_image(CONFIG_CMD_SPL_NAND_OFS,
+ CONFIG_CMD_SPL_WRITE_SIZE,
+ (void *)CONFIG_SYS_TEXT_BASE);
+ /* copy to destintion */
+ for (dst = (int *)CONFIG_SYS_SPL_ARGS_ADDR,
+ src = (int *)CONFIG_SYS_TEXT_BASE;
+ src < (int *)(CONFIG_SYS_TEXT_BASE +
+ CONFIG_CMD_SPL_WRITE_SIZE);
+ src++, dst++) {
+ writel(readl(src), dst);
+ }
+ /* load linux */
+ nand_spl_load_image(CONFIG_SYS_NAND_SPL_KERNEL_OFFS,
+ CONFIG_SYS_NAND_PAGE_SIZE, (void *)header);
+ spl_parse_image_header(header);
+ nand_spl_load_image(CONFIG_SYS_NAND_SPL_KERNEL_OFFS,
+ spl_image.size, (void *)spl_image.load_addr);
+ } else
+#endif
+ {
#ifdef CONFIG_NAND_ENV_DST
- nand_spl_load_image(CONFIG_ENV_OFFSET,
- CONFIG_SYS_NAND_PAGE_SIZE, (void *)header);
- spl_parse_image_header(header);
- nand_spl_load_image(CONFIG_ENV_OFFSET, spl_image.size,
- (void *)image_load_addr);
+ nand_spl_load_image(CONFIG_ENV_OFFSET,
+ CONFIG_SYS_NAND_PAGE_SIZE, (void *)header);
+ spl_parse_image_header(header);
+ nand_spl_load_image(CONFIG_ENV_OFFSET, spl_image.size,
+ (void *)spl_image.load_addr);
#ifdef CONFIG_ENV_OFFSET_REDUND
- nand_spl_load_image(CONFIG_ENV_OFFSET_REDUND,
- CONFIG_SYS_NAND_PAGE_SIZE, (void *)header);
- spl_parse_image_header(header);
- nand_spl_load_image(CONFIG_ENV_OFFSET_REDUND, spl_image.size,
- (void *)image_load_addr);
+ nand_spl_load_image(CONFIG_ENV_OFFSET_REDUND,
+ CONFIG_SYS_NAND_PAGE_SIZE, (void *)header);
+ spl_parse_image_header(header);
+ nand_spl_load_image(CONFIG_ENV_OFFSET_REDUND, spl_image.size,
+ (void *)spl_image.load_addr);
#endif
#endif
- /* Load u-boot */
- nand_spl_load_image(CONFIG_SYS_NAND_U_BOOT_OFFS,
- CONFIG_SYS_NAND_PAGE_SIZE, (void *)header);
- spl_parse_image_header(header);
- nand_spl_load_image(CONFIG_SYS_NAND_U_BOOT_OFFS,
- spl_image.size, (void *)spl_image.load_addr);
+ /* Load u-boot */
+ nand_spl_load_image(CONFIG_SYS_NAND_U_BOOT_OFFS,
+ CONFIG_SYS_NAND_PAGE_SIZE, (void *)header);
+ spl_parse_image_header(header);
+ nand_spl_load_image(CONFIG_SYS_NAND_U_BOOT_OFFS,
+ spl_image.size, (void *)spl_image.load_addr);
+ }
nand_deselect();
}
--
1.7.4.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V5 4/6] omap-common/spl: Add linux boot to SPL
This adds Linux booting to the SPL
This depends on CONFIG_MACH_TYPE patch by Igor Grinberg
(http://article.gmane.org/gmane.comp.boot-loaders.u-boot/105809)
Related CONFIGs:
CONFIG_SPL_OS_BOOT
Activates/Deactivates the OS booting feature
CONFIG_SPL_OS_BOOT_KEY
defines the IO-pin number u-boot switch - if pressed u-boot is booted
CONFIG_SYS_NAND_SPL_KERNEL_OFFS
Offset in NAND of direct boot kernel image to use in SPL
CONFIG_SYS_SPL_ARGS_ADDR
Address where the kernel boot arguments are expected - this is normaly
RAM-begin + 0x100
Signed-off-by: Simon Schwarz
---
V2 changes:
nothing
V3 changes:
nothing
V4 changes:
CHG Using CONFIG_MACH_TYPE now.
DEL CONFIG_SYS_SPL_MACHID
CHG Use CONFIG_MACH_TYPE for machine id config - This makes the patch
depending on the patch linked above
V5 changes:
FIX compile errors for OMAP4
REBASE u-boot-ti adapted new general gpio interface
---
arch/arm/cpu/armv7/omap-common/spl.c | 49 -
include/configs/devkit8000.h |9 +-
2 files changed, 54 insertions(+), 4 deletions(-)
diff --git a/arch/arm/cpu/armv7/omap-common/spl.c
b/arch/arm/cpu/armv7/omap-common/spl.c
index c76fea6..a7afd0a 100644
--- a/arch/arm/cpu/armv7/omap-common/spl.c
+++ b/arch/arm/cpu/armv7/omap-common/spl.c
@@ -35,6 +35,7 @@
#include
#include
#include
+#include
DECLARE_GLOBAL_DATA_PTR;
@@ -63,6 +64,25 @@ void board_init_f(ulong dummy)
relocate_code(CONFIG_SPL_STACK, &gdata, CONFIG_SPL_TEXT_BASE);
}
+/* Return the value of the U-boot key
+ *
+ * RETURN
+ * 0 if not pressed
+ * positiv if pressed
+ */
+#ifdef CONFIG_SPL_OS_BOOT
+int spl_uboot_key(void)
+{
+ int val = 0;
+ if (!gpio_request(CONFIG_SPL_OS_BOOT_KEY, "U-Boot key")) {
+ gpio_direction_input(CONFIG_SPL_OS_BOOT_KEY);
+ val = gpio_get_value(CONFIG_SPL_OS_BOOT_KEY);
+ gpio_free(CONFIG_SPL_OS_BOOT_KEY);
+ }
+ return !val;
+}
+#endif
+
void spl_parse_image_header(const struct image_header *header)
{
u32 header_size = sizeof(struct image_header);
@@ -90,7 +110,25 @@ void spl_parse_image_header(const struct image_header
*header)
}
}
-static void jump_to_image_no_args(void)
+/* This function jumps to an image with argument. Normally an FDT or ATAGS
+ * image.
+ * arg: Pointer to paramter image in RAM
+ */
+#ifdef CONFIG_SPL_OS_BOOT
+void jump_to_image_linux(void *arg)
+{
+ debug("Entering kernel arg pointer: 0x%X\n", arg);
+ typedef void (*image_entry_arg_t)(int, int, void *)
+ __attribute__ ((noreturn));
+ image_entry_arg_t image_entry =
+ (image_entry_arg_t) spl_image.entry_point;
+ /* cleanup_before_linux(); */ /*write SPL function for that*/
+ image_entry(0, CONFIG_MACH_TYPE, arg);
+}
+void jump_to_image_linux(void *) __attribute__ ((noreturn));
+#endif
+
+void jump_to_image_no_args(void)
{
typedef void (*image_entry_noargs_t)(void)__attribute__ ((noreturn));
image_entry_noargs_t image_entry =
@@ -99,8 +137,8 @@ static void jump_to_image_no_args(void)
debug("image entry point: 0x%X\n", spl_image.entry_point);
image_entry();
}
-
void jump_to_image_no_args(void) __attribute__ ((noreturn));
+
void board_init_r(gd_t *id, ulong dummy)
{
u32 boot_device;
@@ -134,6 +172,13 @@ void board_init_r(gd_t *id, ulong dummy)
debug("Jumping to U-Boot\n");
jump_to_image_no_args();
break;
+#ifdef CONFIG_SPL_OS_BOOT
+ case IH_OS_LINUX:
+ debug("Jumping to Linux\n");
+ spl_board_prepare_for_linux();
+ jump_to_image_linux((void *)CONFIG_SYS_SPL_ARGS_ADDR);
+ break;
+#endif
default:
puts("Unsupported OS image.. Jumping nevertheless..\n");
jump_to_image_no_args();
diff --git a/include/configs/devkit8000.h b/include/configs/devkit8000.h
index 629efb0..5d1014b 100644
--- a/include/configs/devkit8000.h
+++ b/include/configs/devkit8000.h
@@ -37,7 +37,9 @@
#define CONFIG_OMAP34301 /* which is in a 3430 */
#define CONFIG_OMAP3_DEVKIT80001 /* working with DevKit8000 */
-#defineCONFIG_SYS_TEXT_BASE0x80008000
+#define CONFIG_MACH_TYPE MACH_TYPE_DEVKIT8000
+
+#defineCONFIG_SYS_TEXT_BASE0x8010
#define CONFIG_SDRC/* The chip has SDRC controller */
@@ -329,7 +331,7 @@
#define CONFIG_SPL_MAX_SIZE0xB400 /* 45 K */
#define CONFIG_SPL_STACK LOW_LEVEL_SRAM_STACK
-#define CONFIG_SPL_BSS_START_ADDR 0x8000 /*CONFIG_SYS_SDRAM_BASE*/
+#define CONFIG_SPL_BSS_START_ADDR 0x8500 /* leave space for bootargs*/
#define CONFIG_SPL_BSS_MAX_SIZE0x8
/* NAND boot config */
@@ -359,6 +361,9 @@
#define CONFIG_CMD_SPL_WRITE_SIZE 0x400 /* 1024 byte */
#define CONFIG_CMD_SPL_NAND_OFS(CO
[U-Boot] [PATCH V5 3/6] devkit8000/spl: init GPMC for dm9000 in SPL
Linux crashes if the GPMC isn't configured for the dm9000.
Signed-off-by: Simon Schwarz
---
V2 changes:
nothing
V3 changes:
nothing
---
arch/arm/include/asm/omap_common.h |2 ++
board/timll/devkit8000/devkit8000.c | 31 +++
2 files changed, 25 insertions(+), 8 deletions(-)
diff --git a/arch/arm/include/asm/omap_common.h
b/arch/arm/include/asm/omap_common.h
index 015cede..0906f49 100644
--- a/arch/arm/include/asm/omap_common.h
+++ b/arch/arm/include/asm/omap_common.h
@@ -77,6 +77,8 @@ u32 omap_boot_mode(void);
/* SPL common function s*/
void spl_parse_image_header(const struct image_header *header);
+int spl_uboot_key(void);
+void spl_board_prepare_for_linux(void);
/* NAND SPL functions */
void spl_nand_load_image(void);
diff --git a/board/timll/devkit8000/devkit8000.c
b/board/timll/devkit8000/devkit8000.c
index f50d113..9124569 100644
--- a/board/timll/devkit8000/devkit8000.c
+++ b/board/timll/devkit8000/devkit8000.c
@@ -63,6 +63,18 @@ int board_init(void)
return 0;
}
+/* Configure GPMC registers for DM9000 */
+static void gpmc_dm9000_config(void)
+{
+ writel(NET_GPMC_CONFIG1, &gpmc_cfg->cs[6].config1);
+ writel(NET_GPMC_CONFIG2, &gpmc_cfg->cs[6].config2);
+ writel(NET_GPMC_CONFIG3, &gpmc_cfg->cs[6].config3);
+ writel(NET_GPMC_CONFIG4, &gpmc_cfg->cs[6].config4);
+ writel(NET_GPMC_CONFIG5, &gpmc_cfg->cs[6].config5);
+ writel(NET_GPMC_CONFIG6, &gpmc_cfg->cs[6].config6);
+ writel(NET_GPMC_CONFIG7, &gpmc_cfg->cs[6].config7);
+}
+
/*
* Routine: misc_init_r
* Description: Configure board specific parts
@@ -81,14 +93,7 @@ int misc_init_r(void)
#endif
#ifdef CONFIG_DRIVER_DM9000
- /* Configure GPMC registers for DM9000 */
- writel(NET_GPMC_CONFIG1, &gpmc_cfg->cs[6].config1);
- writel(NET_GPMC_CONFIG2, &gpmc_cfg->cs[6].config2);
- writel(NET_GPMC_CONFIG3, &gpmc_cfg->cs[6].config3);
- writel(NET_GPMC_CONFIG4, &gpmc_cfg->cs[6].config4);
- writel(NET_GPMC_CONFIG5, &gpmc_cfg->cs[6].config5);
- writel(NET_GPMC_CONFIG6, &gpmc_cfg->cs[6].config6);
- writel(NET_GPMC_CONFIG7, &gpmc_cfg->cs[6].config7);
+ gpmc_dm9000_config();
/* Use OMAP DIE_ID as MAC address */
if (!eth_getenv_enetaddr("ethaddr", enetaddr)) {
@@ -138,3 +143,13 @@ int board_eth_init(bd_t *bis)
return dm9000_initialize(bis);
}
#endif
+
+#ifdef CONFIG_SPL_OS_BOOT
+/* do board specific preperation before SPL
+ * Linux boot */
+void spl_board_prepare_for_linux(void)
+{
+ gpmc_dm9000_config();
+}
+
+#endif
--
1.7.4.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V5 1/6] removed static from images in cmd_bootm.c
This removes static modifier from cmd_bootm.c to make it public and usable
by savebp
Signed-off-by: Simon Schwarz
---
common/cmd_bootm.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/common/cmd_bootm.c b/common/cmd_bootm.c
index 8909ee7..cec6e7b 100644
--- a/common/cmd_bootm.c
+++ b/common/cmd_bootm.c
@@ -156,7 +156,7 @@ static boot_os_fn *boot_os[] = {
#endif
};
-static bootm_headers_t images; /* pointers to os/initrd/fdt images */
+bootm_headers_t images;/* pointers to os/initrd/fdt images */
/* Allow for arch specific config before we boot */
void __arch_preboot_os(void)
--
1.7.4.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V5 0/6] SPL Linux boot
Adds direct Linux boot to SPL. It implements a spl export command to save ATAGS or FDT to NAND flash. The kernel image has to be in place for this! Changes in V5: - Rebased on u-boot-ti - fixed MAKEALL warnings and errors - adapted to general gpio interface based on: - The new SPL layout - OMAP3 new SPL layout (http://article.gmane.org/gmane.comp.boot-loaders.u-boot/105260) - CONFIG_MACH_TYPE fix (http://article.gmane.org/gmane.comp.boot-loaders.u-boot/105809) - Prep subcommand patch for arm (http://article.gmane.org/gmane.comp.boot-loaders.u-boot/106725) Related to: - http://article.gmane.org/gmane.comp.boot-loaders.u-boot/102669 Simon Schwarz (6): removed static from images in cmd_bootm.c Add cmd_spl command devkit8000/spl: init GPMC for dm9000 in SPL omap-common/spl: Add linux boot to SPL omap-common: Add NAND SPL linux booting omap-common: fixes BSS overwriting problem arch/arm/cpu/armv7/omap-common/spl.c | 49 +++- arch/arm/cpu/armv7/omap-common/spl_nand.c | 63 +++-- arch/arm/include/asm/omap_common.h|2 + board/timll/devkit8000/devkit8000.c | 31 +++- common/Makefile |1 + common/cmd_bootm.c|2 +- common/cmd_spl.c | 214 + doc/README.commands.spl | 31 include/cmd_spl.h | 30 include/configs/devkit8000.h | 16 ++- 10 files changed, 410 insertions(+), 29 deletions(-) create mode 100644 common/cmd_spl.c create mode 100644 doc/README.commands.spl create mode 100644 include/cmd_spl.h -- 1.7.4.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] EfikaMX: Add imximage config for Efika SB
On 09/19/2011 12:42 PM, Marek Vasut wrote: > Signed-off-by: Marek Vasut > Cc: Stefano Babic > --- > board/efikamx/imximage.cfg| 122 > - > board/efikamx/imximage_mx.cfg | 122 > + > board/efikamx/imximage_sb.cfg | 122 > + > boards.cfg|3 +- > 4 files changed, 246 insertions(+), 123 deletions(-) > delete mode 100644 board/efikamx/imximage.cfg > create mode 100644 board/efikamx/imximage_mx.cfg > create mode 100644 board/efikamx/imximage_sb.cfg > MAINTAINER is not updated Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mkconfig: start deprecating Makefile config targets
> "Mike" == Mike Frysinger writes:
Mike> Now that we've got boards.cfg and most people have converted over,
Mike> start warning people who have yet to so we can phase board configs
Mike> completely out of the Makefile.
Mike> Signed-off-by: Mike Frysinger
Mike> ---
Mike> mkconfig |9 +
Mike> 1 files changed, 9 insertions(+), 0 deletions(-)
Mike> diff --git a/mkconfig b/mkconfig
Mike> index ecb6d4e..6a60849 100755
Mike> --- a/mkconfig
Mike> +++ b/mkconfig
Mike> @@ -29,6 +29,15 @@ if [ \( $# -eq 2 \) -a \( "$1" = "-A" \) ] ; then
Mike> set ${line}
Mike> # add default board name if needed
Mike> [ $# = 3 ] && set ${line} ${1}
Mike> +elif [ "${MAKEFLAGS+set}${MAKELEVEL+set}" = "setset" ] ; then
Mike> +# only warn when using a config target in the Makefile
Mike> +cat <<-EOF
Mike> +
Mike> +warning: Please migrate to boards.cfg. Failure to do so will
Mike> + mean removal of your board board in the next release.
s/board board/board/
--
Bye, Peter Korsgaard
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] smc911x not functional on top of tree
> "Helmut" == Helmut Raiger writes: Helmut> On 09/19/2011 11:20 AM, Helmut Raiger wrote: >> On >> I can confirm this issue, same with our i.MX31 board. Interestingly the >> tftpboot command works, so its probably a DHCP issue. >> >> Helmut Helmut> Bisecting the problem, got me: Helmut> 093498669e77597635a24f326f11efeab213d394 is the first bad commit Helmut> commit 093498669e77597635a24f326f11efeab213d394 Helmut> Author: Simon Glass Helmut> Date: Mon Jun 13 16:13:12 2011 -0700 Helmut> Put common autoload code into auto_load() function Helmut> This is a small clean-up patch. Helmut> Signed-off-by: Simon Glass Helmut> Tested-by: Eric Bénard Helmut> :04 04 cbc4fde5e7708a24f3e5ceb16946996e2b8048a5 Helmut> cc66136f66e0fb1e5e1f7e3aef0787f57072a4b1 Mnet Helmut> Still analyzing ... Yes, I sent a patch that earlier today: http://lists.denx.de/pipermail/u-boot/2011-September/101692.html -- Bye, Peter Korsgaard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] net: fix a regression in bootp.c
This fixes a bug introduced by 093498669e77597635a24f326f11efeab213d394. TftpStart() was not called unless the 'autoload' environment variable was set. Signed-off-by: Helmut Raiger --- net/bootp.c |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/net/bootp.c b/net/bootp.c index 3db08ea..3157548 100644 --- a/net/bootp.c +++ b/net/bootp.c @@ -164,8 +164,9 @@ static void auto_load(void) return; } #endif - TftpStart(); } + + TftpStart(); } #if !defined(CONFIG_CMD_DHCP) -- 1.7.4.4 -- Scanned by MailScanner. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-ti/next
Hi Wofgang, Le 19/09/2011 09:47, Wolfgang Denk a écrit : > Dear Albert ARIBAUD, > > In message<4e76ebfd.9060...@aribaud.net> you wrote: >> >> As this is your 'next' branch, there is an ambiguity: can you please >> indicate if you want me to pull this into my 'next' or 'master' branch? >> >> If on master, I assume you want me to also send out a pull request to >> Wolfgang, but I am not sure Wolfgang will allow it at this time. > > If I understand correctly this is mostly fixes, so I'd take it. Sandeep's 'next' branch is based on my 'next', not on my 'master', hence my question -- there would have to be a rebase if Sandeep expected me to pull into my master. Sandeep, can you confirm what you want exactly? Meanwhile, I am launching regression builds on u-boot-ti/next, just in case. > Best regards, > > Wolfgang Denk Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Please pull u-boot-ppc4xx/master
Hi Wolfgang, please pull the following two ppc4xx fixes: The following changes since commit 56fa45d58116f86f343a9c45ce6d1110f50b8d70: DA830: Fix Build Warning (2011-09-13 22:24:24 +0200) are available in the git repository at: git://www.denx.de/git/u-boot-ppc4xx.git master Stefan Roese (1): ppc4xx: Flush dcache after DDR2 autocalibration with caches on Weirich, Bernhard (1): Fix incorrect array size of phy settings for 405EX arch/powerpc/cpu/ppc4xx/44x_spd_ddr2.c |7 +++ arch/powerpc/include/asm/u-boot.h |2 +- 2 files changed, 8 insertions(+), 1 deletions(-) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ppc4xx: Flush dcache after DDR2 autocalibration with caches on
On Friday 16 September 2011 12:54:58 Stefan Roese wrote: > Flush the dcache before removing the TLB with caches enabled. > Otherwise this might lead to problems later on, e.g. while booting > Linux (as seen on ICON-440SPe). Applied to u-boot-ppc4xx/master. Best regards, Stefan -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-0 Fax: (+49)-8142-66989-80 Email: off...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Fix incorrect array size of phy settings for 405EX
Hi Bernhard, On Thursday 08 September 2011 18:27:38 Weirich, Bernhard wrote: > Hello, > > I just noticed that on 405EX the bd_t->bi_phy* arrays have just 1 member, > but should have two. So I propose this very simple patch. > > Best regards, > Bernhard Weirich > > Signed-off-by: Bernhard Weirich Applied, after manually fixing all the formal issues with this patch (commit message tweaked, line too long). Additionally the requested change from Wolfgang (list sorted) has been made. Thanks. Best regards, Stefan -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-0 Fax: (+49)-8142-66989-80 Email: off...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] smc911x not functional on top of tree
On 09/19/2011 11:20 AM, Helmut Raiger wrote: > On > I can confirm this issue, same with our i.MX31 board. Interestingly the > tftpboot command works, so its probably a DHCP issue. > > Helmut Bisecting the problem, got me: 093498669e77597635a24f326f11efeab213d394 is the first bad commit commit 093498669e77597635a24f326f11efeab213d394 Author: Simon Glass Date: Mon Jun 13 16:13:12 2011 -0700 Put common autoload code into auto_load() function This is a small clean-up patch. Signed-off-by: Simon Glass Tested-by: Eric Bénard :04 04 cbc4fde5e7708a24f3e5ceb16946996e2b8048a5 cc66136f66e0fb1e5e1f7e3aef0787f57072a4b1 Mnet Still analyzing ... Helmut -- Scanned by MailScanner. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] SPI: Add SPI driver support for Marvell Armada100
[..] > Hi Marek, > > I will fix that :) any more comments? Hi, Naw, looks good otherwise. Cheers > > Regards, > Ajay Bhargav ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] SPI: Add SPI driver support for Marvell Armada100
- "Marek Vasut" wrote:
> On Monday, September 19, 2011 12:47:07 PM Ajay Bhargav wrote:
> > This patch provides support for SPI emulated over SSP for Marvell
> > Armada100 SOC.
> >
> > Signed-off-by: Ajay Bhargav
> > ---
> > arch/arm/include/asm/arch-armada100/spi.h | 111
> > drivers/spi/Makefile |1 +
> > drivers/spi/armada100_spi.c | 205
> > + 3 files changed, 317 insertions(+), 0
> > deletions(-)
> > create mode 100644 arch/arm/include/asm/arch-armada100/spi.h
> > create mode 100644 drivers/spi/armada100_spi.c
> >
>
> [...]
>
> > +
> > +#define SSCR1_TXTRESH(x) ((x - 1) << 6) /* level [1..16] */
> > +#define SSCR1_RXTRESH(x) ((x - 1) << 10) /* level [1..16] */
>
> ((x) - 1), missing parenthesis, please fix globally.
>
> > +#define SSCR1_TINTE(1 << 19) /* Receiver Time-out
> > + Interrupt enable */
> > +
> > +#define SSCR0_DSS 0x0f/* Data Size Select (mask) */
> > +#define SSCR0_DATASIZE(x) (x - 1) /* Data Size Select [4..16] */
> > +#define SSCR0_FRF 0x30/* FRame Format (mask) */
> > +#define SSCR0_MOTO (0x0 << 4) /* Motorola's Serial
> > + Peripheral Interface */
> > +#define SSCR0_TI (0x1 << 4) /* TI's Synchronous
> > + Serial Protocol (SSP) */
> > +#define SSCR0_NATIONAL (0x2 << 4) /* National Microwire */
> > +#define SSCR0_ECS (1 << 6)/* External clock select */
> > +#define SSCR0_SSE (1 << 7)/* Synchronous Serial Port
> > + Enable */
> > +
> > +#define SSSR_TNF (1 << 2)/* Transmit FIFO Not Full */
> > +#define SSSR_RNE (1 << 3)/* Receive FIFO Not Empty */
> > +#define SSSR_BSY (1 << 4)/* SSP Busy */
> > +#define SSSR_TFS (1 << 5)/* Transmit FIFO Service Request */
> > +#define SSSR_RFS (1 << 6)/* Receive FIFO Service Request */
> > +#define SSSR_ROR (1 << 7)/* Receive FIFO Overrun */
> > +#define SSSR_TINT (1 << 19) /* Receiver Time-out Interrupt */
>
> [...]
>
> > +
> > +static void null_writer(struct armd_spi_slave *pss)
> > +{
> > + while (!(readl(&pss->spi_reg->sssr) & SSSR_TNF))
> > + ;
>
> Please avoid endless loops, please fix globally.
>
>
> Cheers
>
Hi Marek,
I will fix that :) any more comments?
Regards,
Ajay Bhargav
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] SPI: Add SPI driver support for Marvell Armada100
On Monday, September 19, 2011 12:47:07 PM Ajay Bhargav wrote:
> This patch provides support for SPI emulated over SSP for Marvell
> Armada100 SOC.
>
> Signed-off-by: Ajay Bhargav
> ---
> arch/arm/include/asm/arch-armada100/spi.h | 111
> drivers/spi/Makefile |1 +
> drivers/spi/armada100_spi.c | 205
> + 3 files changed, 317 insertions(+), 0
> deletions(-)
> create mode 100644 arch/arm/include/asm/arch-armada100/spi.h
> create mode 100644 drivers/spi/armada100_spi.c
>
[...]
> +
> +#define SSCR1_TXTRESH(x) ((x - 1) << 6) /* level [1..16] */
> +#define SSCR1_RXTRESH(x) ((x - 1) << 10) /* level [1..16] */
((x) - 1), missing parenthesis, please fix globally.
> +#define SSCR1_TINTE (1 << 19) /* Receiver Time-out
> +Interrupt enable */
> +
> +#define SSCR0_DSS0x0f/* Data Size Select (mask) */
> +#define SSCR0_DATASIZE(x)(x - 1) /* Data Size Select [4..16] */
> +#define SSCR0_FRF0x30/* FRame Format (mask) */
> +#define SSCR0_MOTO (0x0 << 4) /* Motorola's Serial
> +Peripheral Interface */
> +#define SSCR0_TI (0x1 << 4) /* TI's Synchronous
> +Serial Protocol (SSP) */
> +#define SSCR0_NATIONAL (0x2 << 4) /* National Microwire */
> +#define SSCR0_ECS(1 << 6)/* External clock select */
> +#define SSCR0_SSE(1 << 7)/* Synchronous Serial Port
> +Enable */
> +
> +#define SSSR_TNF (1 << 2)/* Transmit FIFO Not Full */
> +#define SSSR_RNE (1 << 3)/* Receive FIFO Not Empty */
> +#define SSSR_BSY (1 << 4)/* SSP Busy */
> +#define SSSR_TFS (1 << 5)/* Transmit FIFO Service Request */
> +#define SSSR_RFS (1 << 6)/* Receive FIFO Service Request */
> +#define SSSR_ROR (1 << 7)/* Receive FIFO Overrun */
> +#define SSSR_TINT(1 << 19) /* Receiver Time-out Interrupt */
[...]
> +
> +static void null_writer(struct armd_spi_slave *pss)
> +{
> + while (!(readl(&pss->spi_reg->sssr) & SSSR_TNF))
> + ;
Please avoid endless loops, please fix globally.
Cheers
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/4] Armada100: Add SPI support for Marvell gplugD
This patch add SPI driver support for Marvell gplugD.
Signed-off-by: Ajay Bhargav
---
arch/arm/include/asm/arch-armada100/armada100.h | 19 +++
arch/arm/include/asm/arch-armada100/mfp.h |6 ++
board/Marvell/gplugd/gplugd.c | 12
include/configs/gplugd.h|5 +
4 files changed, 42 insertions(+), 0 deletions(-)
diff --git a/arch/arm/include/asm/arch-armada100/armada100.h
b/arch/arm/include/asm/arch-armada100/armada100.h
index c449d4e..a8181b6 100644
--- a/arch/arm/include/asm/arch-armada100/armada100.h
+++ b/arch/arm/include/asm/arch-armada100/armada100.h
@@ -45,6 +45,10 @@
#define FE_CLK_RST 0x1
#define FE_CLK_ENA 0x8
+/* SSP2 Clock Control */
+#define SSP2_APBCLK0x01
+#define SSP2_FNCLK 0x02
+
/* Register Base Addresses */
#define ARMD1_DRAM_BASE0xB000
#define ARMD1_FEC_BASE 0xC080
@@ -175,5 +179,20 @@ struct armd1apb1_registers {
u32 ac97; /*0x084*/
};
+/*
+* APB2 Clock Reset/Control Registers
+* Refer Datasheet Appendix A.11
+*/
+struct armd1apb2_registers {
+ u32 pad1[0x01C - 0x000];
+ u32 ssp1_clkrst;/* 0x01C */
+ u32 ssp2_clkrst;/* 0x020 */
+ u32 pad2[0x04C - 0x020 - 4];
+ u32 ssp3_clkrst;/* 0x04C */
+ u32 pad3[0x058 - 0x04C - 4];
+ u32 ssp4_clkrst;/* 0x058 */
+ u32 ssp5_clkrst;/* 0x05C */
+};
+
#endif /* CONFIG_ARMADA100 */
#endif /* _ASM_ARCH_ARMADA100_H */
diff --git a/arch/arm/include/asm/arch-armada100/mfp.h
b/arch/arm/include/asm/arch-armada100/mfp.h
index da76b58..d48251a 100644
--- a/arch/arm/include/asm/arch-armada100/mfp.h
+++ b/arch/arm/include/asm/arch-armada100/mfp.h
@@ -83,6 +83,12 @@
#define MFP101_ETH_MDIO(MFP_REG(0x194) | MFP_AF5 |
MFP_DRIVE_MEDIUM)
#define MFP103_ETH_RXDV(MFP_REG(0x19C) | MFP_AF5 |
MFP_DRIVE_MEDIUM)
+/* SPI */
+#define MFP107_SSP2_RXD(MFP_REG(0x1AC) | MFP_AF4 |
MFP_DRIVE_MEDIUM)
+#define MFP108_SSP2_TXD(MFP_REG(0x1B0) | MFP_AF4 |
MFP_DRIVE_MEDIUM)
+#define MFP110_SSP2_CS (MFP_REG(0x1B8) | MFP_AF0 | MFP_DRIVE_MEDIUM)
+#define MFP111_SSP2_CLK(MFP_REG(0x1BC) | MFP_AF4 |
MFP_DRIVE_MEDIUM)
+
/* More macros can be defined here... */
#define MFP_PIN_MAX117
diff --git a/board/Marvell/gplugd/gplugd.c b/board/Marvell/gplugd/gplugd.c
index b4f7f81..42c8389 100644
--- a/board/Marvell/gplugd/gplugd.c
+++ b/board/Marvell/gplugd/gplugd.c
@@ -72,6 +72,12 @@ int board_early_init_f(void)
MFP101_ETH_MDIO,
MFP103_ETH_RXDV,
+ /* SSP2 */
+ MFP107_SSP2_RXD,
+ MFP108_SSP2_TXD,
+ MFP110_SSP2_CS,
+ MFP111_SSP2_CLK,
+
MFP_EOC /*End of configuration*/
};
/* configure MFP's */
@@ -81,6 +87,9 @@ int board_early_init_f(void)
int board_init(void)
{
+ struct armd1apb2_registers *apb2_regs =
+ (struct armd1apb2_registers *)ARMD1_APBC2_BASE;
+
/* arch number of Board */
gd->bd->bi_arch_number = MACH_TYPE_SHEEVAD;
/* adress of boot parameters */
@@ -90,6 +99,9 @@ int board_init(void)
udelay(10);
/* Deassert PHY_RST# */
gpio_set_value(CONFIG_SYS_GPIO_PHY_RST, GPIO_HIGH);
+
+ /* Enable SSP2 clock */
+ writel(SSP2_APBCLK | SSP2_FNCLK, &apb2_regs->ssp2_clkrst);
return 0;
}
diff --git a/include/configs/gplugd.h b/include/configs/gplugd.h
index 5f72163..527a0c8 100644
--- a/include/configs/gplugd.h
+++ b/include/configs/gplugd.h
@@ -91,6 +91,11 @@
/* GPIO Configuration for PHY */
#define CONFIG_SYS_GPIO_PHY_RST104 /* GPIO104 */
+/* SPI Support */
+#define CONFIG_ARMADA100_SPI
+#define CONFIG_ENV_SPI_CS 110
+#define CONFIG_SYS_SSP_PORT2
+
/*
* mv-common.h should be defined after CMD configs since it used them
* to enable certain macros
--
1.7.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 4/4] Armada100: Add env storage support for Marvell gplugD
This patch adds support for envrionment varaible storage in SPI flash for Marvell gplugD. Signed-off-by: Ajay Bhargav --- include/configs/gplugd.h | 10 -- 1 files changed, 8 insertions(+), 2 deletions(-) diff --git a/include/configs/gplugd.h b/include/configs/gplugd.h index 260a1dc..8905df8 100644 --- a/include/configs/gplugd.h +++ b/include/configs/gplugd.h @@ -116,7 +116,13 @@ /* * Environment variables configurations */ -#define CONFIG_ENV_IS_NOWHERE 1 /* if env in SDRAM */ -#define CONFIG_ENV_SIZE0x2 /* 64k */ +#define CONFIG_ENV_IS_IN_SPI_FLASH +#define CONFIG_ENV_SECT_SIZE 0x4000 +#define CONFIG_ENV_SIZE0x4000 +#define CONFIG_ENV_OFFSET 0x07C000 + +#define CONFIG_CMD_ASKENV +#define CONFIG_CMD_EDITENV +#define CONFIG_CMD_SAVEENV #endif /* __CONFIG_GPLUGD_H */ -- 1.7.0.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/4] SPI: Add SPI driver support for Marvell Armada100
This patch provides support for SPI emulated over SSP for Marvell
Armada100 SOC.
Signed-off-by: Ajay Bhargav
---
arch/arm/include/asm/arch-armada100/spi.h | 111
drivers/spi/Makefile |1 +
drivers/spi/armada100_spi.c | 205 +
3 files changed, 317 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/include/asm/arch-armada100/spi.h
create mode 100644 drivers/spi/armada100_spi.c
diff --git a/arch/arm/include/asm/arch-armada100/spi.h
b/arch/arm/include/asm/arch-armada100/spi.h
new file mode 100644
index 000..85c2ccf
--- /dev/null
+++ b/arch/arm/include/asm/arch-armada100/spi.h
@@ -0,0 +1,111 @@
+/*
+ * (C) Copyright 2011
+ * eInfochips Ltd.
+ * Written-by: Ajay Bhargav
+ *
+ * (C) Copyright 2010
+ * Marvell Semiconductor
+ *
+ * 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., 51 Franklin Street, Fifth Floor, Boston,
+ * MA 02110-1301 USA
+ */
+
+#ifndef __ARMADA100_SPI_H_
+#define __ARMADA100_SPI_H_
+
+#include
+
+#define CAT_BASE_ADDR(x) ARMD1_SSP ## x ## _BASE
+#define SSP_REG_BASE(x)CAT_BASE_ADDR(x)
+
+/*
+ * SSP Serial Port Registers
+ * refer Appendix A.26
+ */
+struct ssp_reg {
+ u32 sscr0; /* SSP Control Register 0 - 0x000 */
+ u32 sscr1; /* SSP Control Register 1 - 0x004 */
+ u32 sssr; /* SSP Status Register - 0x008 */
+ u32 ssitr; /* SSP Interrupt Test Register - 0x00C */
+ u32 ssdr; /* SSP Data Register - 0x010 */
+ u32 pad1[5];
+ u32 ssto; /* SSP Timeout Register - 0x028 */
+ u32 sspsp; /* SSP Programmable Serial Protocol Register - 0x02C */
+ u32 sstsa; /* SSP TX Timeslot Active Register - 0x030 */
+ u32 ssrsa; /* SSP RX Timeslot Active Register - 0x034 */
+ u32 sstss; /* SSP Timeslot Status Register - 0x038 */
+};
+
+struct armd_spi_slave {
+ struct spi_slave slave;
+ struct ssp_reg *spi_reg;
+ u32 cr0, cr1;
+ u32 int_cr1;
+ u32 clear_sr;
+ const void *tx;
+ void *rx;
+ int gpio_cs_inverted;
+
+ void (*write)(struct armd_spi_slave *pss);
+ void (*read)(struct armd_spi_slave *pss);
+};
+
+#define to_armd_spi_slave(s) container_of(s, struct armd_spi_slave, slave)
+
+#define DEFAULT_WORD_LEN 8
+#define SSP_FLUSH_NUM 0x2000
+#define RX_THRESH_DEF 8
+#define TX_THRESH_DEF 8
+#define TIMEOUT_DEF1000
+
+#define SSCR1_RIE (1 << 0)/* Receive FIFO Interrupt Enable */
+#define SSCR1_TIE (1 << 1)/* Transmit FIFO Interrupt Enable */
+#define SSCR1_LBM (1 << 2)/* Loop-Back Mode */
+#define SSCR1_SPO (1 << 3)/* Motorola SPI SSPSCLK polarity
+ setting */
+#define SSCR1_SPH (1 << 4)/* Motorola SPI SSPSCLK phase setting */
+#define SSCR1_MWDS (1 << 5)/* Microwire Transmit Data Size */
+#define SSCR1_TFT 0x03c0 /* Transmit FIFO Threshold (mask) */
+#define SSCR1_RFT 0x3c00 /* Receive FIFO Threshold (mask) */
+
+#define SSCR1_TXTRESH(x) ((x - 1) << 6) /* level [1..16] */
+#define SSCR1_RXTRESH(x) ((x - 1) << 10) /* level [1..16] */
+#define SSCR1_TINTE(1 << 19) /* Receiver Time-out
+ Interrupt enable */
+
+#define SSCR0_DSS 0x0f/* Data Size Select (mask) */
+#define SSCR0_DATASIZE(x) (x - 1) /* Data Size Select [4..16] */
+#define SSCR0_FRF 0x30/* FRame Format (mask) */
+#define SSCR0_MOTO (0x0 << 4) /* Motorola's Serial
+ Peripheral Interface */
+#define SSCR0_TI (0x1 << 4) /* TI's Synchronous
+ Serial Protocol (SSP) */
+#define SSCR0_NATIONAL (0x2 << 4) /* National Microwire */
+#define SSCR0_ECS (1 << 6)/* External clock select */
+#define SSCR0_SSE (1 << 7)/* Synchronous Serial Port
+ Enable */
+
+#define SSSR_TNF (1 << 2)/* Transmit FIFO Not Full */
[U-Boot] [PATCH 3/4] Armada100: Add SPI flash support for Marvell gplugD
This patch enables Atmel AT45 SPI flash support for Marvell gplugD Enables SF commands. Signed-off-by: Ajay Bhargav --- include/configs/gplugd.h |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/include/configs/gplugd.h b/include/configs/gplugd.h index 527a0c8..260a1dc 100644 --- a/include/configs/gplugd.h +++ b/include/configs/gplugd.h @@ -96,6 +96,10 @@ #define CONFIG_ENV_SPI_CS 110 #define CONFIG_SYS_SSP_PORT2 +/* Flash Support */ +#define CONFIG_CMD_SF +#define CONFIG_SPI_FLASH_ATMEL + /* * mv-common.h should be defined after CMD configs since it used them * to enable certain macros -- 1.7.0.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/2] EfikaSB: Add preliminary EfikaSB support
Signed-off-by: Marek Vasut
Cc: Stefano Babic
---
board/efikamx/efikamx.c | 57 +++---
1 files changed, 53 insertions(+), 4 deletions(-)
diff --git a/board/efikamx/efikamx.c b/board/efikamx/efikamx.c
index 0f84ae0..33fbc86 100644
--- a/board/efikamx/efikamx.c
+++ b/board/efikamx/efikamx.c
@@ -46,6 +46,19 @@ DECLARE_GLOBAL_DATA_PTR;
#error "CONFIG_MXC_SPI not set, this is essential for board's operation!"
#endif
+#if !defined(CONFIG_MACH_EFIKAMX) && !defined(CONFIG_MACH_EFIKASB)
+#error "Missing CONFIG_MACH_EFIKAMX or CONFIG_MACH_EFIKASB in config.h!"
+#endif
+
+/*
+ * Pin definition
+ */
+#ifdef CONFIG_MACH_EFIKAMX
+#defineEFIKA_SD1_CDMX51_PIN_GPIO1_0
+#else
+#defineEFIKA_SD1_CDMX51_PIN_EIM_CS2
+#endif
+
/*
* Shared variables / local defines
*/
@@ -65,6 +78,7 @@ void efikamx_toggle_led(uint32_t mask);
/*
* Board identification
*/
+#ifdef CONFIG_MACH_EFIKAMX
u32 get_efika_rev(void)
{
u32 rev = 0;
@@ -96,6 +110,12 @@ u32 get_efika_rev(void)
return (~rev & 0x7) + 1;
}
+#else
+inline u32 get_efika_rev(void)
+{
+ return 0;
+}
+#endif
u32 get_board_rev(void)
{
@@ -273,7 +293,7 @@ int board_mmc_getcd(u8 *absent, struct mmc *mmc)
struct fsl_esdhc_cfg *cfg = (struct fsl_esdhc_cfg *)mmc->priv;
if (cfg->esdhc_base == MMC_SDHC1_BASE_ADDR)
- *absent = gpio_get_value(IOMUX_TO_GPIO(MX51_PIN_GPIO1_0));
+ *absent = gpio_get_value(IOMUX_TO_GPIO(EFIKA_SD1_CD));
else
*absent = gpio_get_value(IOMUX_TO_GPIO(MX51_PIN_GPIO1_8));
@@ -284,9 +304,9 @@ int board_mmc_init(bd_t *bis)
int ret;
/* SDHC1 is used on all revisions, setup control pins first */
- mxc_request_iomux(MX51_PIN_GPIO1_0,
+ mxc_request_iomux(EFIKA_SD1_CD,
IOMUX_CONFIG_ALT0 | IOMUX_CONFIG_SION);
- mxc_iomux_set_pad(MX51_PIN_GPIO1_0,
+ mxc_iomux_set_pad(EFIKA_SD1_CD,
PAD_CTL_DRV_HIGH | PAD_CTL_HYS_ENABLE |
PAD_CTL_PUE_KEEPER | PAD_CTL_100K_PU |
PAD_CTL_ODE_OPENDRAIN_NONE |
@@ -298,11 +318,13 @@ int board_mmc_init(bd_t *bis)
PAD_CTL_100K_PU | PAD_CTL_ODE_OPENDRAIN_NONE |
PAD_CTL_SRE_FAST);
- gpio_direction_input(IOMUX_TO_GPIO(MX51_PIN_GPIO1_0));
+ gpio_direction_input(IOMUX_TO_GPIO(EFIKA_SD1_CD));
gpio_direction_input(IOMUX_TO_GPIO(MX51_PIN_GPIO1_1));
+#ifndefCONFIG_MACH_EFIKASB
/* Internal SDHC1 IOMUX + SDHC2 IOMUX on old boards */
if (get_efika_rev() < EFIKAMX_BOARD_REV_12) {
+#endif
/* SDHC1 IOMUX */
mxc_request_iomux(MX51_PIN_SD1_CMD,
IOMUX_CONFIG_ALT0 | IOMUX_CONFIG_SION);
@@ -384,6 +406,7 @@ int board_mmc_init(bd_t *bis)
ret = fsl_esdhc_initialize(bis, &esdhc_cfg[0]);
if (!ret)
ret = fsl_esdhc_initialize(bis, &esdhc_cfg[1]);
+#ifndefCONFIG_MACH_EFIKASB
} else {/* New boards use only SDHC1 */
/* SDHC1 IOMUX */
mxc_request_iomux(MX51_PIN_SD1_CMD,
@@ -414,6 +437,7 @@ int board_mmc_init(bd_t *bis)
ret = fsl_esdhc_initialize(bis, &esdhc_cfg[0]);
}
+#endif
return ret;
}
#endif
@@ -500,6 +524,7 @@ static inline void setup_iomux_usb(void) { }
/*
* LED configuration
*/
+#if defined(CONFIG_MACH_EFIKAMX)
void setup_iomux_led(void)
{
/* Blue LED */
@@ -524,6 +549,26 @@ void efikamx_toggle_led(uint32_t mask)
gpio_set_value(IOMUX_TO_GPIO(MX51_PIN_CSI1_HSYNC),
mask & EFIKAMX_LED_RED);
}
+#else
+void setup_iomux_led(void)
+{
+ /* CAPS-LOCK LED */
+ mxc_request_iomux(MX51_PIN_EIM_CS0, IOMUX_CONFIG_GPIO);
+ gpio_direction_output(IOMUX_TO_GPIO(MX51_PIN_EIM_CS0), 0);
+
+ /* ALARM-LED LED */
+ mxc_request_iomux(MX51_PIN_GPIO1_3, IOMUX_CONFIG_GPIO);
+ gpio_direction_output(IOMUX_TO_GPIO(MX51_PIN_GPIO1_3), 0);
+}
+
+void efikamx_toggle_led(uint32_t mask)
+{
+ gpio_set_value(IOMUX_TO_GPIO(MX51_PIN_EIM_CS0),
+ mask & EFIKAMX_LED_BLUE);
+ gpio_set_value(IOMUX_TO_GPIO(MX51_PIN_GPIO1_3),
+ !(mask & EFIKAMX_LED_GREEN));
+}
+#endif
/*
* Board initialization
@@ -616,7 +661,11 @@ int board_early_init_f(void)
int board_init(void)
{
+#ifdef CONFIG_MACH_EFIKAMX
gd->bd->bi_arch_number = MACH_TYPE_MX51_EFIKAMX;
+#else
+ gd->bd->bi_arch_number = MACH_TYPE_MX51_EFIKASB;
+#endif
gd->bd->bi_boot_params = PHYS_SDRAM_1 + 0x100;
return 0;
--
1.7.5.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/2] EfikaMX: Add imximage config for Efika SB
Signed-off-by: Marek Vasut Cc: Stefano Babic --- board/efikamx/imximage.cfg| 122 - board/efikamx/imximage_mx.cfg | 122 + board/efikamx/imximage_sb.cfg | 122 + boards.cfg|3 +- 4 files changed, 246 insertions(+), 123 deletions(-) delete mode 100644 board/efikamx/imximage.cfg create mode 100644 board/efikamx/imximage_mx.cfg create mode 100644 board/efikamx/imximage_sb.cfg diff --git a/board/efikamx/imximage.cfg b/board/efikamx/imximage.cfg deleted file mode 100644 index 6fe0ff9..000 --- a/board/efikamx/imximage.cfg +++ /dev/null @@ -1,122 +0,0 @@ -# -# Copyright (C) 2010 Marek Vasut -# -# BASED ON: imx51evk -# -# (C) Copyright 2009 -# Stefano Babic DENX Software Engineering sba...@denx.de. -# -# 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. 51 Franklin Street Fifth Floor Boston, -# MA 02110-1301 USA -# -# Refer docs/README.imxmage for more details about how-to configure -# and create imximage boot image -# -# The syntax is taken as close as possible with the kwbimage - -# Boot Device : one of -# spi, sd (the board has no nand neither onenand) -BOOT_FROM spi - -# Device Configuration Data (DCD) -# -# Each entry must have the format: -# Addr-type AddressValue -# -# where: -# Addr-type register length (1,2 or 4 bytes) -# Address absolute address of the register -# value value to be stored in the register - -# Setting IOMUXC -DATA 4 0x73fa88a0 0x000 -DATA 4 0x73fa850c 0x20c5 -DATA 4 0x73fa8510 0x20c5 -DATA 4 0x73fa883c 0x5 -DATA 4 0x73fa8848 0x5 -DATA 4 0x73fa84b8 0xe7 -DATA 4 0x73fa84bc 0x45 -DATA 4 0x73fa84c0 0x45 -DATA 4 0x73fa84c4 0x45 -DATA 4 0x73fa84c8 0x45 -DATA 4 0x73fa8820 0x0 -DATA 4 0x73fa84a4 0x5 -DATA 4 0x73fa84a8 0x5 -DATA 4 0x73fa84ac 0xe5 -DATA 4 0x73fa84b0 0xe5 -DATA 4 0x73fa84b4 0xe5 -DATA 4 0x73fa84cc 0xe5 -DATA 4 0x73fa84d0 0xe4 - -DATA 4 0x73fa882c 0x4 -DATA 4 0x73fa88a4 0x4 -DATA 4 0x73fa88ac 0x4 -DATA 4 0x73fa88b8 0x4 - -# Setting DDR for micron -# 13 Rows, 10 Cols, 32 bit, SREF=4 Micron Model -# CAS=3 BL=4 -# ESDCTL_ESDCTL0 -DATA 4 0x83fd9000 0x82a2 -# ESDCTL_ESDCTL1 -DATA 4 0x83fd9008 0x82a2 -# ESDCTL_ESDMISC -DATA 4 0x83fd9010 0xcaaaf6d0 -# ESDCTL_ESDCFG0 -DATA 4 0x83fd9004 0x3f3574aa -# ESDCTL_ESDCFG1 -DATA 4 0x83fd900c 0x3f3574aa - -# Init DRAM on CS0 -# ESDCTL_ESDSCR -DATA 4 0x83fd9014 0x04008008 -DATA 4 0x83fd9014 0x801a -DATA 4 0x83fd9014 0x801b -DATA 4 0x83fd9014 0x00448019 -DATA 4 0x83fd9014 0x07328018 -DATA 4 0x83fd9014 0x04008008 -DATA 4 0x83fd9014 0x8010 -DATA 4 0x83fd9014 0x8010 -DATA 4 0x83fd9014 0x06328018 -DATA 4 0x83fd9014 0x03808019 -DATA 4 0x83fd9014 0x00408019 -DATA 4 0x83fd9014 0x8000 - -# Init DRAM on CS1 -DATA 4 0x83fd9014 0x0400800c -DATA 4 0x83fd9014 0x801e -DATA 4 0x83fd9014 0x801f -DATA 4 0x83fd9014 0x801d -DATA 4 0x83fd9014 0x0732801c -DATA 4 0x83fd9014 0x0400800c -DATA 4 0x83fd9014 0x8014 -DATA 4 0x83fd9014 0x8014 -DATA 4 0x83fd9014 0x0632801c -DATA 4 0x83fd9014 0x0380801d -DATA 4 0x83fd9014 0x0040801d -DATA 4 0x83fd9014 0x8004 - -# Write to CTL0 -DATA 4 0x83fd9000 0xb2a2 -# Write to CTL1 -DATA 4 0x83fd9008 0xb2a2 -# ESDMISC -DATA 4 0x83fd9010 0x000ad6d0 -#ESDCTL_ESDCDLYGD -DATA 4 0x83fd9034 0x9000 -DATA 4 0x83fd9014 0x diff --git a/board/efikamx/imximage_mx.cfg b/board/efikamx/imximage_mx.cfg new file mode 100644 index 000..6fe0ff9 --- /dev/null +++ b/board/efikamx/imximage_mx.cfg @@ -0,0 +1,122 @@ +# +# Copyright (C) 2010 Marek Vasut +# +# BASED ON: imx51evk +# +# (C) Copyright 2009 +# Stefano Babic DENX Software Engineering sba...@denx.de. +# +# 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.
[U-Boot] [PATCH 0/2] Add EfikaSB support
This patchset extends the EfikaMX port by adding support for Efika Smartbook. Marek Vasut (2): EfikaMX: Add imximage config for Efika SB EfikaSB: Add preliminary EfikaSB support board/efikamx/efikamx.c | 57 ++- board/efikamx/imximage.cfg| 122 - board/efikamx/imximage_mx.cfg | 122 + board/efikamx/imximage_sb.cfg | 122 + boards.cfg|3 +- 5 files changed, 299 insertions(+), 127 deletions(-) delete mode 100644 board/efikamx/imximage.cfg create mode 100644 board/efikamx/imximage_mx.cfg create mode 100644 board/efikamx/imximage_sb.cfg -- 1.7.5.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/4] I2C: mxc_i2c rework
On Monday, September 19, 2011 12:11:55 PM Stefano Babic wrote: > On 09/15/2011 02:09 AM, Marek Vasut wrote: > > Rewrite the mxc_i2c driver. > > > > * This version is much closer to Linux implementation. > > * Fixes IPG_PERCLK being incorrectly used as clock source > > * Fixes behaviour of the driver on iMX51 > > * Clean up coding style a bit ;-) > > > > Signed-off-by: Marek Vasut > > --- > > Hi Marek, > > you miss to set the version number of your patchset. This can confuse > us, as confuses patchwork. Oh damn ... sorry. I'll do better next time ;-) > > Jason, do you have any issue with the last version of this patch (again, > without version number, sent by Marek last 15/9) ? I saw Heiko's ACK in > a previous version, but I won't push if some boards/SOC will be broken > by this patchset. Any comments ? I think this one was acked by Heiko today too. Cheers > > Best regards, > Stefano Babic ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] Add USB support for Efika
On Monday, September 19, 2011 10:43:14 AM Stefano Babic wrote: > On 09/18/2011 04:19 AM, Jana Rapava wrote: > > From: Marek Vasut > > > > This commit adds USB support for EfikaMX and EfikaSB. > > > > Signed-off-by: Marek Vasut > > Signed-off-by: Jana Rapava > > --- [...] > > + > > + > > +#ifdef CONFIG_MACH_EFIKASB > > Have I missed something ? In U-Boot I see only MACH_TYPE_MX51_EFIKAMX. > And I cannot find any patch on the ML for the EfikaSB board. > If you add support for a EfikaMX variant, you should add this variant in > your patchset, else this stuff is only dead code and must be removed. I'd prefer this to stay where it is. It's a code for another version of efika which I plan to add very soon (after I clean it up): http://git.denx.de/?p=u-boot/u-boot- pxa.git;a=commit;h=3d5f5c53819eeddf2088237e592c49bf97a5764c http://git.denx.de/?p=u-boot/u-boot- pxa.git;a=commit;h=d1298fdce8ff4ee3d6a485c935e231b9d0d6189e I might actually submit those on wednesday or so. [...] > > +u32 ulpi_read(u32 reg, struct usb_ehci *ehci) > > A ulpi_read() as ulpi_write() is not strictly related to the Efika board. We're missing generic ulpi infrastructure and adding it is way beyond scope of this patch. Cheers ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/4] I2C: mxc_i2c rework
On 09/15/2011 02:09 AM, Marek Vasut wrote: > Rewrite the mxc_i2c driver. > * This version is much closer to Linux implementation. > * Fixes IPG_PERCLK being incorrectly used as clock source > * Fixes behaviour of the driver on iMX51 > * Clean up coding style a bit ;-) > > Signed-off-by: Marek Vasut > --- Hi Marek, you miss to set the version number of your patchset. This can confuse us, as confuses patchwork. Jason, do you have any issue with the last version of this patch (again, without version number, sent by Marek last 15/9) ? I saw Heiko's ACK in a previous version, but I won't push if some boards/SOC will be broken by this patchset. Any comments ? Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/4] MX5: Clean up the output of "clocks" command
On 09/15/2011 02:09 AM, Marek Vasut wrote: > The new output looks like this: >> clocks > PLL1800 MHz > PLL2665 MHz > PLL3216 MHz > > AHB 133000 kHz > IPG 66500 kHz > IPG PERCLK 665000 kHz > > Signed-off-by: Marek Vasut > --- Thanks cleaning up ! Acked-by: Stefano Babic Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] mx31pdk: Change the prompt as per other i.MX boards
On 09/16/2011 01:18 AM, Fabio Estevam wrote: > Change the prompt as done in other i.MX boards. > > Signed-off-by: Fabio Estevam > --- Hi Fabio, > include/configs/mx31pdk.h |2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/include/configs/mx31pdk.h b/include/configs/mx31pdk.h > index e77805c..7f91f67 100644 > --- a/include/configs/mx31pdk.h > +++ b/include/configs/mx31pdk.h > @@ -123,7 +123,7 @@ > * Miscellaneous configurable options > */ > #define CONFIG_SYS_LONGHELP /* undef to save memory */ > -#define CONFIG_SYS_PROMPT"uboot> " > +#define CONFIG_SYS_PROMPT"MX31PDK U-Boot > " > #define CONFIG_SYS_CBSIZE256 /* Console I/O Buffer Size */ > /* Print Buffer Size */ > #define CONFIG_SYS_PBSIZE(CONFIG_SYS_CBSIZE + \ Applied to u-boot-imx, next branch, 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-0 Fax: +49-8142-66989-80 Email: off...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] smc911x not functional on top of tree
On 09/19/2011 11:20 AM, Helmut Raiger wrote: > On 09/15/2011 09:39 PM, Fabio Estevam wrote: >> Hi, >> >> When using U-boot from top of tree I am not able to get networking to >> work on a mx31pdk: >> >> uboot> dhcp >> smc911x: detected LAN9217 controller >> smc911x: phy initialized >> smc911x: MAC 00:04:9f:00:8d:6e >> BOOTP broadcast 1 >> BOOTP broadcast 2 >> DHCP client bound to address 10.29.244.21 >> BOOTP broadcast 3 >> DHCP client bound to address 10.29.244.21 >> BOOTP broadcast 4 >> DHCP client bound to address 10.29.244.21 >> BOOTP broadcast 5 >> DHCP client bound to address 10.29.244.21 >> >> Retry count exceeded; starting again >> > > I can confirm this issue, same with our i.MX31 board. Interestingly the > tftpboot command works, so its probably a DHCP issue. Without checking in code, it seems the timout for DHCP elapses before the answer arrives. This confirms Fabio's tests, that is something related to the network. Some boards have set CONFIG_ARP_TIMEOUT to a higher value as default (200 instead of 5 mSec). Maybe it is related, maybe not...you need to sniff your network ;-) Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] MX31: Improve readability for reset cause
On 09/16/2011 04:01 PM, Fabio Estevam wrote:
> Currently the reset cause is printed like:
> CPU: Freescale i.MX31 rev 2.0 at 531 MHz.Reset cause: POR
>
> Improve readability by adding a new line like it is done on other i.MX boards.
>
> Signed-off-by: Fabio Estevam
> ---
> arch/arm/cpu/arm1136/mx31/generic.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/arch/arm/cpu/arm1136/mx31/generic.c
> b/arch/arm/cpu/arm1136/mx31/generic.c
> index e3a4d1b..c6def5d 100644
> --- a/arch/arm/cpu/arm1136/mx31/generic.c
> +++ b/arch/arm/cpu/arm1136/mx31/generic.c
> @@ -180,7 +180,7 @@ int print_cpuinfo (void)
> {
> u32 srev = get_cpu_rev();
>
> - printf("CPU: Freescale i.MX31 rev %d.%d%s at %d MHz.",
> + printf("CPU: Freescale i.MX31 rev %d.%d%s at %d MHz.\n",
> (srev & 0xF0) >> 4, (srev & 0x0F),
> ((srev & 0x8000) ? " unknown" : ""),
> mx31_get_mcu_main_clk() / 100);
Applied to u-boot-imx, next branch, 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-0 Fax: +49-8142-66989-80 Email: off...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] smc911x not functional on top of tree
On 09/15/2011 09:39 PM, Fabio Estevam wrote: > Hi, > > When using U-boot from top of tree I am not able to get networking to > work on a mx31pdk: > > uboot> dhcp > smc911x: detected LAN9217 controller > smc911x: phy initialized > smc911x: MAC 00:04:9f:00:8d:6e > BOOTP broadcast 1 > BOOTP broadcast 2 > DHCP client bound to address 10.29.244.21 > BOOTP broadcast 3 > DHCP client bound to address 10.29.244.21 > BOOTP broadcast 4 > DHCP client bound to address 10.29.244.21 > BOOTP broadcast 5 > DHCP client bound to address 10.29.244.21 > > Retry count exceeded; starting again > I can confirm this issue, same with our i.MX31 board. Interestingly the tftpboot command works, so its probably a DHCP issue. Helmut -- Scanned by MailScanner. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] Devkit8000: Change console from ttyS2 to ttyO2
The omap serial names have changed from ttySx to ttyOx, so the console should be also changed to support this. Signed-off-by: Thomas Weber --- include/configs/devkit8000.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/include/configs/devkit8000.h b/include/configs/devkit8000.h index 710092d..3479740 100644 --- a/include/configs/devkit8000.h +++ b/include/configs/devkit8000.h @@ -181,7 +181,7 @@ #define CONFIG_EXTRA_ENV_SETTINGS \ "loadaddr=0x8200\0" \ - "console=ttyS2,115200n8\0" \ + "console=ttyO2,115200n8\0" \ "mmcdev=0\0" \ "vram=12M\0" \ "dvimode=1024x768MR-16@60\0" \ -- 1.7.6.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] Add USB support for Efika
On 09/18/2011 04:19 AM, Jana Rapava wrote:
> From: Marek Vasut
>
> This commit adds USB support for EfikaMX and EfikaSB.
>
> Signed-off-by: Marek Vasut
> Signed-off-by: Jana Rapava
> ---
> Changes for v2:
> - changed to proper patch
> Changes for v3:
> - merged other USB patches from u-boot-pxa/efikasb
> - offset-based access changed to struct-based access
> - use {clrset,clr,set}bits_le32() calls
> - CodingStyle and naming cleanup
Hi Jana,
you change several files, some of them in the general USB support. You
must then split your patch into a patchset, and each patch must address
a single issue. Really with your patch you do not only add USB support
to the EfikaMX board, but you want to add support for MX5 Soc and maybe
fix some issues. And if you change some general USB files, you should
add in CC the USB maintainer (Remy, I have already added him in my answer).
> diff --git a/board/efikamx/Makefile b/board/efikamx/Makefile
> index ee4a16e..860e4d2 100644
> --- a/board/efikamx/Makefile
> +++ b/board/efikamx/Makefile
> @@ -28,6 +28,9 @@ include $(TOPDIR)/config.mk
> LIB = $(obj)lib$(BOARD).o
>
> COBJS:= efikamx.o
> +ifdefCONFIG_CMD_USB
> +COBJS+= efikamx-usb.o
> +endif
>
> SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c)
> OBJS := $(addprefix $(obj),$(COBJS))
> diff --git a/board/efikamx/efikamx-usb.c b/board/efikamx/efikamx-usb.c
> new file mode 100644
> index 000..19227d4
> --- /dev/null
> +++ b/board/efikamx/efikamx-usb.c
> @@ -0,0 +1,349 @@
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include "../../drivers/usb/host/ehci.h"
> +#include "../../drivers/usb/host/ehci-core.h"
This seems to me pretty nasty - but it is not the only example in u-boot
including files from drivers/. Can we imagine to move these files into
the include directory ?
> +
> + /*
> + * Configure USBH1 control pads
> + */
> +
> + /* USB PHY reset */
> + mxc_request_iomux(MX51_PIN_EIM_D27, IOMUX_CONFIG_ALT1);
> + mxc_iomux_set_pad(MX51_PIN_EIM_D27, PAD_CTL_PKE_ENABLE |
> + PAD_CTL_SRE_FAST | PAD_CTL_DRV_HIGH);
> +
> + /* USB HUB reset */
> + mxc_request_iomux(MX51_PIN_GPIO1_5, IOMUX_CONFIG_ALT0);
> + mxc_iomux_set_pad(MX51_PIN_GPIO1_5, PAD_CTL_PKE_ENABLE |
> + PAD_CTL_SRE_FAST | PAD_CTL_DRV_HIGH);
> +
> +
> +#ifdef CONFIG_MACH_EFIKASB
Have I missed something ? In U-Boot I see only MACH_TYPE_MX51_EFIKAMX.
And I cannot find any patch on the ML for the EfikaSB board.
If you add support for a EfikaMX variant, you should add this variant in
your patchset, else this stuff is only dead code and must be removed.
> + /* WIFI EN (act low) */
> + mxc_request_iomux(MX51_PIN_EIM_A22, IOMUX_CONFIG_GPIO);
> + mxc_iomux_set_pad(MX51_PIN_EIM_A22, 0);
I think it is more readable if you exchange the fix "0" value with the
constants we have already defined, using maybe clrset* function for
PAD_CTL_PKE_ENABLE and PAD_CTL_PUE_KEEPER (the bits you want to clear).
> + /* WIFI RESET */
> + mxc_request_iomux(MX51_PIN_EIM_A16, IOMUX_CONFIG_GPIO);
> + mxc_iomux_set_pad(MX51_PIN_EIM_A16, 0);
Ditto, check globally.
> +/*
> + * Enable devices connected to USB BUSes
> + */
> +void efika_usb_enable_devices(void)
> +{
> + /* Enable Bluetooth */
> + gpio_direction_output(IOMUX_TO_GPIO(MX51_PIN_EIM_A17), 0);
> + udelay(1);
> + gpio_set_value(IOMUX_TO_GPIO(MX51_PIN_EIM_A17), 1);
> +
> + /* Enable WiFi */
> + gpio_direction_output(IOMUX_TO_GPIO(MX51_PIN_EIM_A22), 1);
> + udelay(1);
> +
> + /* Reset the WiFi chip */
> + gpio_direction_output(IOMUX_TO_GPIO(MX51_PIN_EIM_A16), 0);
> + udelay(1);
> + gpio_set_value(IOMUX_TO_GPIO(MX51_PIN_EIM_A16), 1);
> +}
Is it ok to wait in this function 30mSec or the value can be tuned ? It
seems to me quite high. In the rest of code you wait for 1mSec. Is it ok ?
> +
> +/*
> + * Reset USB PHY (or PHYs on EfikaSB)
As already said: I do not see support for EfikaSB. Please explain or add
support for this variant of the board.
> + */
> +void efika_usb_phy_reset(void)
> +{
> + /* SMSC 3317 PHY reset */
> + gpio_direction_output(IOMUX_TO_GPIO(MX51_PIN_EIM_D27), 0);
> + udelay(1000);
> + gpio_set_value(IOMUX_TO_GPIO(MX51_PIN_EIM_D27), 1);
> +}
Here you wait 1mSec...
> +
> +/*
> + * Configure control registers of the USB controller
> + */
> +void control_regs_setup(struct usb_control_regs *control)
> +{
> + clrsetbits_le32(&control->usbctrl,
> + (MXX1_OTG_WUE | MXX1_OTG_PM | MX51_H1_ULPI_IE |
> MX51_H1_WUE),
> + MX51_H1_PM);
Because these bits are valid for both MX5 and MX3, maybe you can call
them MXC_OTG_WUE, MXC_OTG_PM, and so on. MXX1_ let me think there is a
MXX1 Soc.
> +
> + clrsetbits_le32(&control->phyctrl0,
> + MX51_OTG_OVERCURD,
> +
[U-Boot] [PATCH 5/6 v2] integrator: make flash writeable on boot
This reconfigures the EBI (External Bus Interface) on the
integrator so that chip select 1, handling the flash memory, is
set to writeable. Without this it is not possible for U-Boot to
access flash memory and it crashes on startup since CFI won't
work properly.
Since this is the first time we use the EBI, we create a header
file for its registers.
Signed-off-by: Linus Walleij
---
ChangeLog v1->v2:
- Moved the arm-ebi.h file from the global include/ dir to the
board/armltd/integrator/ dir since it's only needed by
the Integrator.
---
board/armltd/integrator/arm-ebi.h| 62 ++
board/armltd/integrator/integrator.c | 15
2 files changed, 77 insertions(+), 0 deletions(-)
create mode 100644 board/armltd/integrator/arm-ebi.h
diff --git a/board/armltd/integrator/arm-ebi.h
b/board/armltd/integrator/arm-ebi.h
new file mode 100644
index 000..2d85e3f
--- /dev/null
+++ b/board/armltd/integrator/arm-ebi.h
@@ -0,0 +1,62 @@
+/*
+ * (C) Copyright 2011
+ * Linaro
+ * Linus Walleij
+ * Register definitions for the External Bus Interface (EBI)
+ * found in the ARM Integrator AP and CP reference designs
+ *
+ * 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
+ */
+
+#ifndef __ARM_EBI_H
+#define __ARM_EBI_H
+
+#define EBI_BASE 0x1200
+
+#define EBI_CSR0_REG 0x00 /* CS0 = Boot ROM */
+#define EBI_CSR1_REG 0x04 /* CS1 = Flash */
+#define EBI_CSR2_REG 0x08 /* CS2 = SSRAM */
+#define EBI_CSR3_REG 0x0C /* CS3 = Expansion memory */
+/*
+ * The four upper bits are the waitstates for each chip select
+ * 0x00 = 2 cycles, 0x10 = 3 cycles, ... 0xe0 = 16 cycles, 0xf0 = 16 cycles
+ */
+#define EBI_CSR_WAIT_MASK 0xF0
+/* Whether memory is synchronous or asynchronous */
+#define EBI_CSR_SYNC_MASK 0xF7
+#define EBI_CSR_ASYNC 0x00
+#define EBI_CSR_SYNC 0x08
+/* Whether memory is write enabled or not */
+#define EBI_CSR_WREN_MASK 0xFB
+#define EBI_CSR_WREN_DISABLE 0x00
+#define EBI_CSR_WREN_ENABLE0x04
+/* Memory bit width for each chip select */
+#define EBI_CSR_MEMSIZE_MASK 0xFC
+#define EBI_CSR_MEMSIZE_8BIT 0x00
+#define EBI_CSR_MEMSIZE_16BIT 0x01
+#define EBI_CSR_MEMSIZE_32BIT 0x02
+
+/*
+ * The lock register need to be written with 0xa05f before anything in the
+ * EBI can be changed.
+ */
+#define EBI_LOCK_REG 0x20
+#define EBI_UNLOCK_MAGIC 0xA05F
+
+#endif
diff --git a/board/armltd/integrator/integrator.c
b/board/armltd/integrator/integrator.c
index 780218c..dd83ca5 100644
--- a/board/armltd/integrator/integrator.c
+++ b/board/armltd/integrator/integrator.c
@@ -36,6 +36,7 @@
#include
#include
#include
+#include "arm-ebi.h"
DECLARE_GLOBAL_DATA_PTR;
@@ -56,6 +57,8 @@ void show_boot_progress(int progress)
int board_init (void)
{
+ u32 val;
+
/* arch number of Integrator Board */
#ifdef CONFIG_ARCH_CINTEGRATOR
gd->bd->bi_arch_number = MACH_TYPE_CINTEGRATOR;
@@ -73,6 +76,18 @@ extern void cm_remap(void);
cm_remap(); /* remaps writeable memory to 0x */
#endif
+ /*
+* The system comes up with the flash memory non-writable and
+* configuration locked. If we want U-Boot to be used for flash
+* access we cannot have the flash memory locked.
+*/
+ writel(EBI_UNLOCK_MAGIC, EBI_BASE + EBI_LOCK_REG);
+ val = readl(EBI_BASE + EBI_CSR1_REG);
+ val &= EBI_CSR_WREN_MASK;
+ val |= EBI_CSR_WREN_ENABLE;
+ writel(val, EBI_BASE + EBI_CSR1_REG);
+ writel(0, EBI_BASE + EBI_LOCK_REG);
+
icache_enable ();
return 0;
--
1.7.6
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] armv7: only call save_boot_params for OMAP
Hi Aneesh, I did this Patch because of an error with an SPL build of smdkv310. This board doesn't even build with the normal configuration but the SPL patches add more errors (I did some BUILDALL testing). So the question: Should we care for an already broken board or just leave the matter to the poor guy who will, in some distant future, fix the other problems of this board? Regards Simon On 09/16/2011 06:13 PM, Aneesh V wrote: > Hi Simon, > > On Friday 16 September 2011 09:02 PM, Simon Schwarz wrote: >> save_boot_params in start.S got called for all armv7 based cpus. Since the >> function relys on the OMAP specific bootloader this broke some boards >> (or to be specific added more errors to already broken ones). This patch >> wraps the call in #ifdef CONFIG_OMAP. > > There is a weakly linked default function implemented in armv7/cpu.c. > So, there should not be any build break for u-boot builds. > > However armv7/cpu.c is not included in an SPL build, so may cause > trouble for SPL build of non-OMAP boards. The solution for this problem > is the following: > > --- a/arch/arm/cpu/armv7/Makefile > +++ b/arch/arm/cpu/armv7/Makefile > @@ -29,9 +29,9 @@ START := start.o > > ifndef CONFIG_SPL_BUILD > COBJS += cache_v7.o > -COBJS += cpu.o > endif > > +COBJS += cpu.o > COBJS += syslib.o > > SRCS := $(START:.o=.S) $(COBJS:.o=.c) > > Let me know if I am missing something. > > best regards, > Aneesh > > >> >> Signed-off-by: Simon Schwarz >> --- >> arch/arm/cpu/armv7/start.S |2 ++ >> 1 files changed, 2 insertions(+), 0 deletions(-) >> >> diff --git a/arch/arm/cpu/armv7/start.S b/arch/arm/cpu/armv7/start.S >> index db8e9d2..7cb380c 100644 >> --- a/arch/arm/cpu/armv7/start.S >> +++ b/arch/arm/cpu/armv7/start.S >> @@ -134,7 +134,9 @@ IRQ_STACK_START_IN: >>*/ >> >> reset: >> +#ifdef CONFIG_OMAP >> bl save_boot_params >> +#endif >> /* >> * set the cpu to SVC32 mode >> */ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] net/bootp.c: fix tftp load if autoload environment var isn't set
Commit 093498669 (Put common autoload code into auto_load() function) broke handling of autoload environment variable not being set. The bootp/dhcp code will just keep on requesting IP address forever and never start TFTP download. Fix it by moving TftpStart() outside the conditional like it was before. Signed-off-by: Peter Korsgaard --- net/bootp.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/net/bootp.c b/net/bootp.c index 3db08ea..a003c42 100644 --- a/net/bootp.c +++ b/net/bootp.c @@ -164,8 +164,8 @@ static void auto_load(void) return; } #endif - TftpStart(); } + TftpStart(); } #if !defined(CONFIG_CMD_DHCP) -- 1.7.5.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 5/5 v1] integrator: make flash writeable on boot
On Sun, Sep 18, 2011 at 10:26 AM, Mike Frysinger wrote: > On Sunday, September 18, 2011 03:52:58 Linus Walleij wrote: >> board/armltd/integrator/integrator.c | 15 >> include/arm-ebi.h | 62 >> ++ 2 files changed, 77 insertions(+), 0 >> deletions(-) >> create mode 100644 include/arm-ebi.h > > if the integrator board is the only one that cares about this header, then > it's probably best to keep it in the board-specific dir rather than include/ Yes why not. I'll move it to the board dir, it indeed seems to be a board pecularity. Thanks, Linus Walleij ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 5/5 v1] integrator: make flash writeable on boot
On Sun, Sep 18, 2011 at 3:24 PM, Wolfgang Denk wrote: > I think this is a misunderstanding of terms. When we try to > identify the flash type and geomentry in the CFI driver, we do send > certain commands to the flash, and read the returned data. This > "sending commands" includes write cycles to the flash address space, > so it is necessary that the memory controller setup allows write > cycles on the bus. Yes that is exactly what happens. The integrator has some gate to disallow any write cycles to CFI unless it's unlocked through the EBI. Yours, Linus Walleij ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-ti/next
Dear Albert ARIBAUD, In message <4e76ebfd.9060...@aribaud.net> you wrote: > > As this is your 'next' branch, there is an ambiguity: can you please > indicate if you want me to pull this into my 'next' or 'master' branch? > > If on master, I assume you want me to also send out a pull request to > Wolfgang, but I am not sure Wolfgang will allow it at this time. If I understand correctly this is mostly fixes, so I'd take it. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de If it has syntax, it isn't user friendly. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH]: davinci: Replace CONFIG_PRELOADER with CONFIG_SPL_BUILD in board/davinci/common/misc.c
On Tue Sep 13, 2011 at 06:12:08PM +0530, Sughosh Ganu wrote: > Make the conditional compilation in misc.c based on > CONFIG_SPL_BUILD, replacing CONFIG_PRELOADER which was removed as part > of commit 401bb30b6d. > > Making this change, we no longer need to compile memsize.c for > hawkboard's nand_spl. > > Signed-off-by: Sughosh Ganu > --- > > Tested the changes on hawkboard. > Build tested on davinci boards with a 'MAKEALL -v davinci' > > > board/davinci/common/misc.c |2 +- > nand_spl/board/davinci/da8xxevm/Makefile |6 -- > 2 files changed, 1 insertions(+), 7 deletions(-) Will this not go through ti next branch. I don't see this patch included in the u-boot-ti/next pull request by Sandeep. -sughosh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mx1: add mx1/l support for mxc_i2c
On 09/19/2011 08:57 AM, Marek Vasut wrote: > On Monday, August 22, 2011 10:56:43 PM Eric Jarrige wrote: >> Signed-off-by: Eric Jarrige >> Cc: Stefano Babic >> Cc: Heiko Schocher >> @@ -94,6 +98,8 @@ void i2c_init(int speed, int unused) >> /* start the required I2C clock */ >> writel(readl(&sc_regs->cgr0) | (3 << I2C_CLK_OFFSET), >> &sc_regs->cgr0); >> +#elif defined(CONFIG_IMX) >> +freq = get_HCLK(); >> #else >> freq = mxc_get_clock(MXC_IPG_PERCLK); >> #endif > > Please, no more ifdefs -- can't you actually modify your header files or add > some which would define mxc_get_clock() ? That'd make this way much more > clean. In principl, I agree completely with Marek, and we have tried to get rid as much of possible of #ifdef in drivers. I know we have already discussed about the opportunity to fix the whole IMX stuff, and I agreed with you that this processor is obsolete and make no sense to invest a lot of time for it. However, what about to define mxc_get_clock() as simple macro ? Maybe in imx-regs.h, as exceptiion for this processor (normally the imx-regs.h contains only defines and structures for the internal registers) ? Something like: #define mxc_get_clock(a)(get_HCLK()) Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-ti/next
Hi Sandeep, Le 19/09/2011 01:39, s-paul...@ti.com a écrit : > Please pull u-boot-ti/next. > I checked all the patches for checkpatch errors. > Also all OMAP3 and OMAP4 built with no issues. > > Thanks, > Sandeep As this is your 'next' branch, there is an ambiguity: can you please indicate if you want me to pull this into my 'next' or 'master' branch? If on master, I assume you want me to also send out a pull request to Wolfgang, but I am not sure Wolfgang will allow it at this time. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
