Re: [U-Boot] [PATCH 3/4][v2] powerpc/85xx:Make debug exception vector accessible
Hi Scott, Please find my reply in-lined On Thursday 22 March 2012 01:22 AM, Scott Wood wrote: On 03/20/2012 11:43 PM, Prabhakar Kushwaha wrote: Debugging of e500 and e500v1 processer requires debug exception vecter (IVPR + IVOR15) to have valid and fetchable OP code. While executing in translated space (AS=1), whenever a debug exception is generated, the MSR[DS/IS] gets cleared i.e. AS=0 and the processor tries to fetch an instruction from the debug exception vector (IVPR + IVOR15); since now we are in AS=0, the application needs to ensure the proper TLB configuration to have (IVOR + IVOR15) accessible from AS=0 also. Create a temporary TLB in AS0 to make sure debug exception verctor is accessible on debug exception. Signed-off-by: Radu Lazarescu Signed-off-by: Marius Grigoras Signed-off-by: Prabhakar Kushwaha Can you document the flow of exactly what TLB entries are present at various points of the boot flow, for all the various configurations (NOR boot, NAND SPL, RAMBOOT, IFC versus non-IFC, etc). Sure. May be separate patch will be send. diff --git a/arch/powerpc/cpu/mpc85xx/start.S b/arch/powerpc/cpu/mpc85xx/start.S index 597151b..cef00ba 100644 --- a/arch/powerpc/cpu/mpc85xx/start.S +++ b/arch/powerpc/cpu/mpc85xx/start.S @@ -182,6 +182,66 @@ l2_disabled: andi. r1,r3,L1CSR0_DCE@l beq 2b +#if defined(CONFIG_E500)&& defined(CONFIG_SYS_PPC_E500_DEBUG_TLB) +/* + * TLB for debuggging in AS1 + * Create temporary TLB in AS0 to handle debug exception + * As on debug exception MSR is cleared i.e. Address space is changed + * to 0. A TLB (in AS0) is required to handle debug exception generated + * in AS1. + */ s/TLB/TLB entry/g Sure, i will update. + + lis r6,FSL_BOOKE_MAS0(1, + CONFIG_SYS_PPC_E500_DEBUG_TLB, 0)@h + ori r6,r6,FSL_BOOKE_MAS0(1, + CONFIG_SYS_PPC_E500_DEBUG_TLB, 0)@l + +#if !defined(CONFIG_SYS_RAMBOOT) +/* + * TLB is created for IVPR + IVOR15 to map on valid OP code address + * bacause flash's virtual address maps to 0xff80 - 0x. + * and this window is outside of 4K boot window. + */ + lis r7,FSL_BOOKE_MAS1(1, 1, 0, 0, BOOKE_PAGESZ_4M)@h + ori r7,r7,FSL_BOOKE_MAS1(1, 1, 0, 0, BOOKE_PAGESZ_4M)@l + + lis r8,FSL_BOOKE_MAS2(CONFIG_SYS_MONITOR_BASE& 0xffc0, + (MAS2_I|MAS2_G))@h + ori r8,r8,FSL_BOOKE_MAS2(CONFIG_SYS_MONITOR_BASE& 0xffc0, + (MAS2_I|MAS2_G))@l + + /* The 85xx has the default boot window 0xff80 - 0x */ + lis r9,FSL_BOOKE_MAS3(0xffc0, 0, (MAS3_SX|MAS3_SW|MAS3_SR))@h + ori r9,r9,FSL_BOOKE_MAS3(0xffc0, 0, (MAS3_SX|MAS3_SW|MAS3_SR))@l +#else +/* + * TLB is created for IVPR + IVOR15 to map on valid OP code address + * because "nexti" will resize TLB to 4K + */ + lis r7,FSL_BOOKE_MAS1(1, 1, 0, 0, BOOKE_PAGESZ_256K)@h + ori r7,r7,FSL_BOOKE_MAS1(1, 1, 0, 0, BOOKE_PAGESZ_256K)@l + + lis r8,FSL_BOOKE_MAS2(CONFIG_SYS_MONITOR_BASE, (MAS2_I|MAS2_G))@h + ori r8,r8,FSL_BOOKE_MAS2(CONFIG_SYS_MONITOR_BASE, + (MAS2_I|MAS2_G))@l + lis r9,FSL_BOOKE_MAS3(CONFIG_SYS_MONITOR_BASE, 0, + (MAS3_SX|MAS3_SW|MAS3_SR))@h + ori r9,r9,FSL_BOOKE_MAS3(CONFIG_SYS_MONITOR_BASE, 0, + (MAS3_SX|MAS3_SW|MAS3_SR))@l +#endif In the ramboot case is this really supposed to be I+G? I am not sure. But same is done under label "create_init_ram_area" for TLB entry 15. what you suggest. Which path will NAND SPL go through (not the payload, but the SPL itself)? That will be only a 4K window mapped, and guarded doesn't stop speculative instruction fetches, so we don't want to map more than is backed up by something. NAND SPL go via !defined(CONFIG_SYS_RAMBOOT) path. i think NAND_SPL does not require temporary TLB as NAND SPL even does not have any interrupt vector. I will check this point + lis r10,0xffc0@h + ori r10,r10,0xffc0@l Don't waste instructions -- this could be in an SPL. That ori is a no-op. Please refer above response. May be this piece of code is not required for NAND SPL + + mtspr MAS0,r6 + mtspr MAS1,r7 + mtspr MAS2,r8 + mtspr MAS3,r9 + mtspr MAS7,r10 Why are you writing 0xffc0 into MAS7? Access to MAS7 needs to be conditional on CONFIG_ENABLE_36BIT_PHYS (misnamed, should be something like CONFIG_SYS_PPC_HAS_MAS7). i will put this code under #define CONFIG_ENABLE_36BIT_PHYS For your kind information : in start.S, label label "create_ccsr_new_tlb", "create_ccsr_old_tlb" uses MAS7 without CONFIG_ENABLE_36BIT_PHYS #define. It should be fixed ?? + isync + msync + tlbwe +#endif Nee
[U-Boot] Patchwork housekeeping
Hello Custodians and Mailing List Aficionados, I don't know if anyone has noticed, but patchwork is starting to collect a rather large amount of cruft. I occasionally jump onto patchwork and do a little housekeeping by marking updated patches as 'Superceeded' and anything applied by Wolfgang as 'Accepted' (There may be a few patches that have been applied to custodian tress that I marked as 'Accepted' when really they should have been marked as 'Awaiting Upstream') I really don't mind doing this housekeeping, but I would like to make a few suggestions that will make the work a little easier: - If you are a custodian: o When you apply a patch to your repo, can you please assign it to yourself in patchwork and set it to 'Awaiting Upstream' o Reply to the ML with 'Applied to /' o When you send a pull request, create a bundle with all the patches that are to be pulled (you can create the bundle early and add patches as you apply them) o When Wolfgang pulls your repo, go to the bundle and mark all the patches 'Accepted' - If you are a patch submitter: o Visit http://patchwork.ozlabs.org/project/uboot/list/ o Search for your patches by following the 'Filters'link and entering your name o Send and email (with 'patchwork' somewhere in the subject) to the ML with a list of patches that you submitted say more than one month ago. For each patch, please indicate if the patch is: * Superseded - By another patch (either by you or someone else) * Not Applicable - The patch can be ignored (was an RFC, was due to a misunderstanding, another patch did the same thing, etc) * Applied - Has been applied (state the repo and branch) * Rejected - Patch has been officially rejected * Waiting - You believe the patch is still valid but has not been applied (send a ping as a reply to the patch on the mailing list as well * Other - Please describe what state you feel the patch is in Once I get the raw list down to a manageable level, I'll start to look at the leftovers... Regards, "Your friendly Patchwork janitor" Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] sh: Fix building ecovec board
Hi,
2012/3/21 :
> Hi Nobuhiro,
>
>
>
>> I cannot reproduce this problem. I am using gcc-4.6 and gcc-4.4.
> I used the CodeSourcery G++ Lite 4.4-200 toolchain.
>
>
>> And I think that this problem is not revised with your patch.
>> I think that the contents of the patch are right.
> My change makes the ecovec Makefile the same structure as the other SH
> boards.
>
> I checked and found that the build error only occurs with out-of-tree
> builds.
OK, I confirmed this with out-of-tree build.
Applied.
Thanks.
Nobuhiro
>
>
>> 2012/3/17 Phil Edworthy :
>> > Build error was with board/renesas/ecovec/lowlevel_init.S
>> > include/version.h: Assembler messages:
>> > include/version.h:41: Error: unknown opcode
>> > lowlevel_init.S:48: Error: unknown opcode
>> > lowlevel_init.S:51: Error: unknown opcode
>> > etc
>> >
>> > Signed-off-by: Phil Edworthy
>> > ---
>> > board/renesas/ecovec/Makefile | 8 ++--
>> > 1 files changed, 6 insertions(+), 2 deletions(-)
>> >
>> > diff --git a/board/renesas/ecovec/Makefile
>> > b/board/renesas/ecovec/Makefile
>> > index 8fdc0c9..b592a9c 100644
>> > --- a/board/renesas/ecovec/Makefile
>> > +++ b/board/renesas/ecovec/Makefile
>> > @@ -25,8 +25,12 @@ LIB = $(obj)lib$(BOARD).o
>> > COBJS := ecovec.o
>> > SOBJS := lowlevel_init.o
>> >
>> > -$(LIB): $(obj).depend $(COBJS) $(SOBJS)
>> > - $(call cmd_link_o_target, $(COBJS) $(SOBJS))
>> > +SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c)
>> > +OBJS := $(addprefix $(obj),$(COBJS))
>> > +SOBJS := $(addprefix $(obj),$(SOBJS))
>> > +
>> > +$(LIB): $(OBJS) $(SOBJS)
>> > + $(call cmd_link_o_target, $(OBJS) $(SOBJS))
>> >
>> >
>> > #
>> >
>> > --
>> > 1.7.0.4
>> >
>
> Best regards,
> Phil
--
Nobuhiro Iwamatsu
iwamatsu at {nigauri.org / debian.org}
GPG ID: 40AD1FA6
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4][resend?] kirkwood: add support for Cloud Engines Pogoplug E02
Hi Prafulla, I wasn't sure if you had seen this and you are just snowed under w/ work now, or perhaps it slipped past you unnoticed... Wolfgang had provided some feedback for the v3, so this is v4 now. ==>http://lists.denx.de/pipermail/u-boot/2012-March/120447.html Shall I resend, or do you still have access to it? Thank you, regards, Dave -- Forwarded message -- From: Dave Purdy Date: Sat, Mar 17, 2012 at 1:25 PM Subject: [PATCH v4] kirkwood: add support for Cloud Engines Pogoplug E02 To: u-boot@lists.denx.de Cc: David Purdy , prafu...@marvell.com, albert.u.b...@aribaud.net From: David Purdy This patch adds support for Cloud Engines Pogoplug E02 Information regarding the CE Pogoplug E02 board can be found at: http://archlinuxarm.org/platforms/armv5/pogoplug-v2-pinkgray Signed-off-by: David Purdy Cc: prafu...@marvell.com Cc: albert.u.b...@aribaud.net --- Changes for v4: - remove parentheses from simple args - remove erroneous comment and redundant code in config - remove line wrap Changes for v3: - fix ordering mistake in boards.cfg Changes for v2: - added MAINTAINERS info for pogoplug_e02 - fixed format to ensure capture of all files in path . ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] tegra: Specify debugging serial port at boot.
Hi Wolfgang, On Wed, Mar 21, 2012 at 4:07 PM, Wolfgang Denk wrote: > Dear Simon Glass, > > In message > you > wrote: >> >> > No. I do not want to see any PRE_CONSOLE_UART or pre_console_putc() >> > stuff, because this is bogus. If you do output to a serial UART port, >> > this _is_ your console. Just use it in the standard war. >> > >> > I made my mind up: I want to get rid of all this "pre_console" UART >> > stuff. >> >> OK, so revert that commit? > > It hasn't hit mainline yet, or has it? Yes, it is there, sorry. > >> In that case I have a question. How can we get console output in the >> event of a panic before console_ready() is called? > > You cannot, by definition. You cannot output anything to the console > without initializing it before. > > This is why initializing the serial console has always been one of the > very, very first initialization steps in U-Boot. So if actually you want a pre-console panic() to be silent then that's fine. It's a little unfriendly though - so would you be interested in keeping board_pre_console_putc() around if we could solve this entirely with code in there? It turns out that Tegra has a setting for console UART in the hardware parameters that we can access.( I won't ask you about how to handle a panic() in SPL yet). Regards, Simon > > 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 > There are three ways to get something done: do it yourself, hire > someone, or forbid your kids to do it. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] tegra: Specify debugging serial port at boot.
Dear Simon Glass, In message you wrote: > > > No. I do not want to see any PRE_CONSOLE_UART or pre_console_putc() > > stuff, because this is bogus. If you do output to a serial UART port, > > this _is_ your console. Just use it in the standard war. > > > > I made my mind up: I want to get rid of all this "pre_console" UART > > stuff. > > OK, so revert that commit? It hasn't hit mainline yet, or has it? > In that case I have a question. How can we get console output in the > event of a panic before console_ready() is called? You cannot, by definition. You cannot output anything to the console without initializing it before. This is why initializing the serial console has always been one of the very, very first initialization steps in U-Boot. 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 There are three ways to get something done: do it yourself, hire someone, or forbid your kids to do it. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/5] Add board_panic_no_console() to deal with early critical errors
Dear Simon, In message <20120321224801.2c000202...@gemini.denx.de> I wrote: > > > So the existing pre-console putc() can be used, if we can sort out how > > to make UART init work. Graeme suggested an approach here - I will see > > if I can make that work. > > I don't think I will accept any "pre-console putc()". This is such a > dirty hack. Either you can initialize and use putc, then use the > normal console mechanism for it, or you cannot. And "cannot" means > "cannot" here. Sorry, this was not what I meant. My fingers were faster than my brain. The existing code around CONFIG_PRE_CONSOLE_BUFFER (i. e. storage in a temporary buffer until console bcomes available) is of course OK with me. What I meant was: I do not want to have any "pre console UART output" code. 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 \|/ \|/ \|/ \|/ @~/ ,. \~@ @~/ ,. \~@ /_( \__/ )_\ /_( \__/ )_\ \__U_/ \__U_/ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] tegra: Specify debugging serial port at boot.
Hi Wolfgang, On Wed, Mar 21, 2012 at 3:56 PM, Wolfgang Denk wrote: > Dear Simon, > > In message > you > wrote: >> >> 3. What you propose is actually very easy to implement - it just >> requires a new config like CONFIG_DEFAULT_UART or >> CONFIG_PRE_CONSOLE_UART to be defined, and used in the >> board_pre_console_putc() code. > > No. I do not want to see any PRE_CONSOLE_UART or pre_console_putc() > stuff, because this is bogus. If you do output to a serial UART port, > this _is_ your console. Just use it in the standard war. > > I made my mind up: I want to get rid of all this "pre_console" UART > stuff. OK, so revert that commit? In that case I have a question. How can we get console output in the event of a panic before console_ready() is called? Regards, Simon > > Best regards, > > Wolfgang Denk > > -- > DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel > HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany > Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de > "The first rule of magic is simple. Don't waste your time waving your > hands and hoping when a rock or a club will do." > - McCloctnik the Lucid ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] tegra: Specify debugging serial port at boot.
Dear Stephen, In message <4f6a1d1e.2090...@wwwdotorg.org> you wrote: > > But the last few messages in this thread have all been about the > following as far as I'm concerned: > > * The U-Boot configuration defines which single UART to use for the > initial console. > > * This initial console is registered early enough that almost all > failures can be reported. In particular, something as non-critical as > locating and parsing the DT should happen after this initial console is > registered, so that DT existence/parsing problems can be reported to > this initial console. > > By non-critical here, I mean that there should be no reason to require > the DT to be parsed in order for the CPU to boot, and the initial > UART-based console to be registered. DT parsing shouldn't be attempted > until this basic level of operation is achieved; it should be be > required that the DT be parsed for any of that to work. > > * When the DT is parsed later, the console specification from DT > replaces the initial console. > > With this scheme in place, there surely isn't any need for any kind of > special-case early putc/puts/printf - wasn't this exactly Wolfgang's point? Correct, that's what I have in mind. Actually we already do the same in other situations - for example on systems with console on LCD, whih becomes available pretty late in the boot sequence. 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 They weren't that important. They were merely at the top. The people who really run organizations are usually found several levels down, where it's still possible to get things done. - Terry Pratchett, _Small Gods_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 05/14] cfb_console: Fix function console_scrollup
On Wed, 21 Mar 2012 19:50:34 +0100 Pali Rohár wrote: ... > Hi, can you show me how to fix this? How to correctly use > framebuffer? Hi, Not really. This would be a new project to rewrite U-Boot driver for OMAP3 DSS. There is a driver under drivers/video/omap3_dss.c, but it doesn't do what we need here. You can try to set gdev.frameAdrs to point to another address range in RAM which is not used by U-Boot. Then get OMAP3430 TRM and read DSS documentation how to configure the display controller so that is displays frame buffer data from this address range. Currently I do not have time nor resources to rewrite the existing omap3_dss driver. Thanks, Anatolij ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] tegra: Specify debugging serial port at boot.
Dear Simon, In message you wrote: > > 3. What you propose is actually very easy to implement - it just > requires a new config like CONFIG_DEFAULT_UART or > CONFIG_PRE_CONSOLE_UART to be defined, and used in the > board_pre_console_putc() code. No. I do not want to see any PRE_CONSOLE_UART or pre_console_putc() stuff, because this is bogus. If you do output to a serial UART port, this _is_ your console. Just use it in the standard war. I made my mind up: I want to get rid of all this "pre_console" UART stuff. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de "The first rule of magic is simple. Don't waste your time waving your hands and hoping when a rock or a club will do." - McCloctnik the Lucid ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] tegra: Specify debugging serial port at boot.
Dear Stephen Warren, In message <4f6a01d3.3020...@wwwdotorg.org> you wrote: > > > It appears that all you are trying here is an annoying, but somewhat > > unlikely error situation. As marked above (see *), it might make > > sense to think of alternative ways to find out what the console port > > might be. One possibility to do this is to use the environment. > > You need access to the environment anyway to initialize the console > > port (for reading the "baudrate" setting). So why not encoding the > > console UART port for example as part of a "hwconfig" setting? This > > setting could be auto-initialized when you load a DT on this board > > (eventually after verifying that it works). ... > I'd prefer to just have a different U-Boot (build) config for each HW > configuration, and define the console UART as part of that configuration > using the existing defines that are for that purpose. This is another option - at the cost of maintaining separate binary images. > If we put the UART ID into the environment, then we either need to: > > a) Have a different U-Boot configuration anyway, in order to define the > different environment during the U-Boot build process. > > b) Post-process the U-Boot binary after building it, in order to modify > the environment that's contained in that binary. Not true. In the normal course of events, the board would boot with a working device tree provided, which provides correct console information. This could be used to auto-initialize the correct environment settings. You just have to make sure that board boots a single time with a working DT image - I don't know how production tests and/or software commissioning on these boards is organized, but this seems to be a possible route to me. [Been there, done that before. About 12 years before, IIRC.] You probably also need to program MAC addresses etc. ? 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 "Pardon me for breathing, which I never do anyway so I don't know why I bother to say it, oh God, I'm so depressed. Here's another of those self-satisfied doors. Life! Don't talk to me about life." - Marvin the Paranoid Android ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/5] Add board_panic_no_console() to deal with early critical errors
Dear Simon, In message you wrote: > > > Please make up your mind: either you CAN initialize the console, then > > you can use it to output messages in a regular way, or you CANNOT > > initialize it, in which case you cannot print anything. There is no > > third option. > > Well that is very clear - we cannot. We hit panic() before > console_ready() is called. OK - but this means that no output to a serial console port can be done, no matter what you try. > > If you have "available UARTs", you could use this as console, right? > > Yes, if we knew which it was. This is a design issue. If there are several similar boards that shall be handled with the same binary, then you must agree on some common sub-set of features, like on UART port that is available on all of these, and use this as (early) console port. > We know we won't get to console init in this case - there is a panic() > that happens first. So the existing pre-console putc() becomes our > route to displaying a message. The problem with that is only that the No. When you cannot initialize the console, you cannot output anything to the console. Period. If there is a way to do some initialization and output charatcers, than make this your regular console init code, and use it always, without any special warts. > board init hasn't happened yet, so either the pre-console putc() must > init the UARTs or we need a separate init function. This makes no sense to me. > So the existing pre-console putc() can be used, if we can sort out how > to make UART init work. Graeme suggested an approach here - I will see > if I can make that work. I don't think I will accept any "pre-console putc()". This is such a dirty hack. Either you can initialize and use putc, then use the normal console mechanism for it, or you cannot. And "cannot" means "cannot" here. 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 I have the simplest tastes. I am always satisfied with the best. -- Oscar Wilde ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Targets in the Makefile, SPL and .img
On Wed, Mar 21, 2012 at 5:54 PM, Tom Rini wrote: > On Wed, Mar 21, 2012 at 05:46:38PM -0400, jonsm...@gmail.com wrote: >> On Wed, Mar 21, 2012 at 5:38 PM, Tom Rini wrote: >> > On Wed, Mar 21, 2012 at 10:32:39AM -0400, jonsm...@gmail.com wrote: >> > >> >> If you make u-boot.img it doesn't also make in the SPL directory. Can >> >> this get fixed before the next release? >> > >> > Can you elaborate? ?This is working fine for folks as far as we can >> > tell. ?If doing a brand new (sub)arch you may need things similar to >> > arch/arm/cpu/armv7/omap3/config.mk >> >> Nothing is broken, it is just inconvenient. >> >> Do 'make' >> it builds u-boot.bin and spl/u-boot-spl.bin >> >> Do 'make u-boot.img' >> it builds u-boot.bin and u-boot.img, but not spl/u-boot-spl.bin >> >> In our case we are concatenating spl/u-boot-spl.bin and u-boot.img and >> we need the img header to know the length of the attached u-boot. >> >> Maybe just add u-boot.img to the default make targets? Otherwise I >> need to teach people to do 'make u-boot.img spl/u-boot-spl.bin'. > > That is not the behavior I see right now with omap3_beagle, for example. > It gives me u-boot.img and MLO (along with u-boot.bin and > spl/u-boot-spl.bin), both with and without O=. That's why I suggested > looking at the file I said because that's what controls making > u-boot.img be an always built target, for omap3 boards with SPL. I get it now. I added this to my config.mk. Thanks for the tip. ifndef CONFIG_SPL_BUILD ALL-y += $(obj)u-boot.img endif -- Jon Smirl jonsm...@gmail.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Targets in the Makefile, SPL and .img
On Wed, Mar 21, 2012 at 05:46:38PM -0400, jonsm...@gmail.com wrote: > On Wed, Mar 21, 2012 at 5:38 PM, Tom Rini wrote: > > On Wed, Mar 21, 2012 at 10:32:39AM -0400, jonsm...@gmail.com wrote: > > > >> If you make u-boot.img it doesn't also make in the SPL directory. Can > >> this get fixed before the next release? > > > > Can you elaborate? ?This is working fine for folks as far as we can > > tell. ?If doing a brand new (sub)arch you may need things similar to > > arch/arm/cpu/armv7/omap3/config.mk > > Nothing is broken, it is just inconvenient. > > Do 'make' > it builds u-boot.bin and spl/u-boot-spl.bin > > Do 'make u-boot.img' > it builds u-boot.bin and u-boot.img, but not spl/u-boot-spl.bin > > In our case we are concatenating spl/u-boot-spl.bin and u-boot.img and > we need the img header to know the length of the attached u-boot. > > Maybe just add u-boot.img to the default make targets? Otherwise I > need to teach people to do 'make u-boot.img spl/u-boot-spl.bin'. That is not the behavior I see right now with omap3_beagle, for example. It gives me u-boot.img and MLO (along with u-boot.bin and spl/u-boot-spl.bin), both with and without O=. That's why I suggested looking at the file I said because that's what controls making u-boot.img be an always built target, for omap3 boards with SPL. -- Tom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Targets in the Makefile, SPL and .img
On Wed, Mar 21, 2012 at 5:38 PM, Tom Rini wrote: > On Wed, Mar 21, 2012 at 10:32:39AM -0400, jonsm...@gmail.com wrote: > >> If you make u-boot.img it doesn't also make in the SPL directory. Can >> this get fixed before the next release? > > Can you elaborate? This is working fine for folks as far as we can > tell. If doing a brand new (sub)arch you may need things similar to > arch/arm/cpu/armv7/omap3/config.mk Nothing is broken, it is just inconvenient. Do 'make' it builds u-boot.bin and spl/u-boot-spl.bin Do 'make u-boot.img' it builds u-boot.bin and u-boot.img, but not spl/u-boot-spl.bin In our case we are concatenating spl/u-boot-spl.bin and u-boot.img and we need the img header to know the length of the attached u-boot. Maybe just add u-boot.img to the default make targets? Otherwise I need to teach people to do 'make u-boot.img spl/u-boot-spl.bin'. -- Jon Smirl jonsm...@gmail.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Targets in the Makefile, SPL and .img
On Wed, Mar 21, 2012 at 10:32:39AM -0400, jonsm...@gmail.com wrote: > If you make u-boot.img it doesn't also make in the SPL directory. Can > this get fixed before the next release? Can you elaborate? This is working fine for folks as far as we can tell. If doing a brand new (sub)arch you may need things similar to arch/arm/cpu/armv7/omap3/config.mk -- Tom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mmc: omap: handle controller errors properly
On Wednesday 21 March 2012 20:11:08 Pali Rohár wrote: > On Monday 19 March 2012 15:14:39 Tom Rini wrote: > > On 03/19/2012 03:12 PM, Grazvydas Ignotas wrote: > > > According to OMAP3 TRM, when the controller reports certain > > > errors, driver must perform a software reset. This is done by > > > setting a bit in SYSCTL and waiting it to clear: > > > - SRC on command timeout (CTO) > > > - SRD on data errors (DTO, DCRC and DEB) > > > > > > This fixes a problem seen on OMAP3 pandora board with some > > > cards > > > > > > that won't work with a message printed multiple times: > > >timedout waiting on cmd inhibit to clear > > > > > > Code loosely based on Linux omap_hsmmc driver. > > > > > > Signed-off-by: Grazvydas Ignotas > > > > Most excellent! Pali, can you try this on N900 and see if that > > helps out the problem you were having as well? > > > > Andy, I'll give this a spin through the boards I've got here but > > I'd like this to go, via your tree, into u-boot/master assuming > > all goes well. > > Hi! > > I tried this patch and it > really fixed problem on Nokia N900. Tested-by: Pali Rohár -- Pali Rohár pali.ro...@gmail.com 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 3/4][v2] powerpc/85xx:Make debug exception vector accessible
On 03/20/2012 11:43 PM, Prabhakar Kushwaha wrote: > Debugging of e500 and e500v1 processer requires debug exception vecter (IVPR + > IVOR15) to have valid and fetchable OP code. > > While executing in translated space (AS=1), whenever a debug exception is > generated, the MSR[DS/IS] gets cleared i.e. AS=0 and the processor tries to > fetch an instruction from the debug exception vector (IVPR + IVOR15); since > now > we are in AS=0, the application needs to ensure the proper TLB configuration > to > have (IVOR + IVOR15) accessible from AS=0 also. > > Create a temporary TLB in AS0 to make sure debug exception verctor is > accessible on debug exception. > > Signed-off-by: Radu Lazarescu > Signed-off-by: Marius Grigoras > Signed-off-by: Prabhakar Kushwaha Can you document the flow of exactly what TLB entries are present at various points of the boot flow, for all the various configurations (NOR boot, NAND SPL, RAMBOOT, IFC versus non-IFC, etc). > diff --git a/arch/powerpc/cpu/mpc85xx/start.S > b/arch/powerpc/cpu/mpc85xx/start.S > index 597151b..cef00ba 100644 > --- a/arch/powerpc/cpu/mpc85xx/start.S > +++ b/arch/powerpc/cpu/mpc85xx/start.S > @@ -182,6 +182,66 @@ l2_disabled: > andi. r1,r3,L1CSR0_DCE@l > beq 2b > > +#if defined(CONFIG_E500) && defined(CONFIG_SYS_PPC_E500_DEBUG_TLB) > +/* > + * TLB for debuggging in AS1 > + * Create temporary TLB in AS0 to handle debug exception > + * As on debug exception MSR is cleared i.e. Address space is changed > + * to 0. A TLB (in AS0) is required to handle debug exception generated > + * in AS1. > + */ s/TLB/TLB entry/g > + > + lis r6,FSL_BOOKE_MAS0(1, > + CONFIG_SYS_PPC_E500_DEBUG_TLB, 0)@h > + ori r6,r6,FSL_BOOKE_MAS0(1, > + CONFIG_SYS_PPC_E500_DEBUG_TLB, 0)@l > + > +#if !defined(CONFIG_SYS_RAMBOOT) > +/* > + * TLB is created for IVPR + IVOR15 to map on valid OP code address > + * bacause flash's virtual address maps to 0xff80 - 0x. > + * and this window is outside of 4K boot window. > + */ > + lis r7,FSL_BOOKE_MAS1(1, 1, 0, 0, BOOKE_PAGESZ_4M)@h > + ori r7,r7,FSL_BOOKE_MAS1(1, 1, 0, 0, BOOKE_PAGESZ_4M)@l > + > + lis r8,FSL_BOOKE_MAS2(CONFIG_SYS_MONITOR_BASE & 0xffc0, > + (MAS2_I|MAS2_G))@h > + ori r8,r8,FSL_BOOKE_MAS2(CONFIG_SYS_MONITOR_BASE & 0xffc0, > + (MAS2_I|MAS2_G))@l > + > + /* The 85xx has the default boot window 0xff80 - 0x */ > + lis r9,FSL_BOOKE_MAS3(0xffc0, 0, (MAS3_SX|MAS3_SW|MAS3_SR))@h > + ori r9,r9,FSL_BOOKE_MAS3(0xffc0, 0, (MAS3_SX|MAS3_SW|MAS3_SR))@l > +#else > +/* > + * TLB is created for IVPR + IVOR15 to map on valid OP code address > + * because "nexti" will resize TLB to 4K > + */ > + lis r7,FSL_BOOKE_MAS1(1, 1, 0, 0, BOOKE_PAGESZ_256K)@h > + ori r7,r7,FSL_BOOKE_MAS1(1, 1, 0, 0, BOOKE_PAGESZ_256K)@l > + > + lis r8,FSL_BOOKE_MAS2(CONFIG_SYS_MONITOR_BASE, (MAS2_I|MAS2_G))@h > + ori r8,r8,FSL_BOOKE_MAS2(CONFIG_SYS_MONITOR_BASE, > + (MAS2_I|MAS2_G))@l > + lis r9,FSL_BOOKE_MAS3(CONFIG_SYS_MONITOR_BASE, 0, > + (MAS3_SX|MAS3_SW|MAS3_SR))@h > + ori r9,r9,FSL_BOOKE_MAS3(CONFIG_SYS_MONITOR_BASE, 0, > + (MAS3_SX|MAS3_SW|MAS3_SR))@l > +#endif In the ramboot case is this really supposed to be I+G? Which path will NAND SPL go through (not the payload, but the SPL itself)? That will be only a 4K window mapped, and guarded doesn't stop speculative instruction fetches, so we don't want to map more than is backed up by something. > + lis r10,0xffc0@h > + ori r10,r10,0xffc0@l Don't waste instructions -- this could be in an SPL. That ori is a no-op. > + > + mtspr MAS0,r6 > + mtspr MAS1,r7 > + mtspr MAS2,r8 > + mtspr MAS3,r9 > + mtspr MAS7,r10 Why are you writing 0xffc0 into MAS7? Access to MAS7 needs to be conditional on CONFIG_ENABLE_36BIT_PHYS (misnamed, should be something like CONFIG_SYS_PPC_HAS_MAS7). > + isync > + msync > + tlbwe > +#endif Need isync after the tlbwe. I don't think we need the msync before it. > diff --git a/arch/powerpc/include/asm/config_mpc85xx.h > b/arch/powerpc/include/asm/config_mpc85xx.h > index 8654625..268c56e 100644 > --- a/arch/powerpc/include/asm/config_mpc85xx.h > +++ b/arch/powerpc/include/asm/config_mpc85xx.h > @@ -1,5 +1,5 @@ > /* > - * Copyright 2011 Freescale Semiconductor, Inc. > + * Copyright 2011-2012 Freescale Semiconductor, Inc. > * > * This program is free software; you can redistribute it and/or > * modify it under the terms of the GNU General Public License as > @@ -107,6 +107,7 @@ > #define CONFIG_MAX_CPUS 1 > #define CONFIG_FSL_SDHC_V2_3 >
Re: [U-Boot] [PATCH v3] README.mx28evk: add
On Wed, Mar 21, 2012 at 16:26, Marek Vasut wrote: >> This is mainline a copy of README.m28 changing the references to the >> mx28evk counterpart and removing NAND instructions as it is not >> supported by the board. > > All of this seems like a copy-paste to me, sorry if I'm just being annoyed > right > now and dumbified by it. Please clear this to me as I'm uncertain about my > reading skills now. We share a lot of information among the two boards (mx28evk and m28evk) and this ends duplicating some information, however I don't think both are similar enough that end user won't be confused about them. As you can see comparing both the mx28evk: * adds pins settings; * boards test revision; * drop NAND information; * fix references to the board; Splitting it in two, or three files, will make harder for user to find the need information; thus it seems better to have a small duplication of this and easy end user finding. I do think many boards has common stuff but splitting those details too much ends up making hard to find the needed information. -- Otavio Salvador O.S. Systems E-mail: ota...@ossystems.com.br http://www.ossystems.com.br Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] README.mx28: add
Dear Otavio Salvador, > On Wed, Mar 21, 2012 at 16:21, Marek Vasut wrote: > > This is copy-paste schizzle, can you please separate the CPU specific > > parts into one file and put only the different parts into their > > particular readmes? > > If you compare the v3 against the m28 one it is not a copy-paste > anymore; it does has specific information and remove the > not-applicable one. The v3 seems fine to me as is and makes easier to > new users to find the desired information. See my response, also next time please bother to Cc me, your chances of review of the patch rise a lot by doing so ... thanks ;-) Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] README.mx28evk: add
Dear Otavio Salvador,
> This is mainline a copy of README.m28 changing the references to the
> mx28evk counterpart and removing NAND instructions as it is not
> supported by the board.
>
> Signed-off-by: Otavio Salvador
> Acked-by: Fabio Estevam
> ---
> doc/README.mx28evk | 153
> 1 files changed, 153
> insertions(+), 0 deletions(-)
> create mode 100644 doc/README.mx28evk
>
> diff --git a/doc/README.mx28evk b/doc/README.mx28evk
> new file mode 100644
> index 000..ddca310
> --- /dev/null
> +++ b/doc/README.mx28evk
> @@ -0,0 +1,153 @@
> +Freescale MX28EVK
> +=
> +
> +This document describes the Freescale MX28EVK U-Boot port. This document
> mostly +covers topics related to making the board bootable. Only the
> MX28EVK revision D +has been tested.
> +
> +Terminology
> +---
> +
> +The dollar symbol ($) introduces a snipped of shell code. This shall be
> typed +into the unix command prompt in U-Boot source code root directory.
> +
> +The (=>) introduces a snipped of code that should by typed into U-Boot
> command +prompt.
> +
> +Contents
> +
> +
> +0) Files of the MX28EVK port
> +1) Prerequisites
> +2) Compiling U-Boot for MX28EVK
> +3) Installation of U-Boot for MX28EVK to SD card
> +
> +0) Files of the MX28EVK port
> +
> +
> +arch/arm/cpu/arm926ejs/mx28/ - The CPU support code for the Freescale
> i.MX28 +arch/arm/include/asm/arch-mx28/ - Header files for the Freescale
> i.MX28 +board/denx/mx28evk/ - MX28EVK board specific files
> +include/configs/mx28evk.h- MX28EVK configuration file
> +
> +1) Prerequisites
> +
> +
> +To make the MX28EVK board bootable, some tools are necessary. The first
> one is +the "elftosb" tool distributed by Freescale Semiconductor. The
> other tool is the +"mxsboot" tool found in U-Boot source tree.
> +
> +Firstly, obtain the elftosb archive from the following location:
> +
> + http://foss.doredevelopment.dk/mirrors/imx/elftosb-10.12.01.tar.gz
> +
> +We use a $VER variable here to denote the current version. At the time of
> +writing of this document, that is "10.12.01". To obtain the file from
> command +line, use:
> +
> + $ VER="10.12.01"
> + $ wget http://foss.doredevelopment.dk/mirrors/imx/elftosb-${VER}.tar.gz
> +
> +Extract the file:
> +
> + $ tar xzf elftosb-${VER}.tar.gz
> +
> +Compile the file. We need to manually tell the linker to use also libm:
> +
> + $ cd elftosb-${VER}/
> + $ make LIBS="-lstdc++ -lm" elftosb
> +
> +Optionally, remove debugging symbols from elftosb:
> +
> + $ strip bld/linux/elftosb
> +
> +Finally, install the "elftosb" binary. The "install" target is missing, so
> just +copy the binary by hand:
> +
> + $ sudo cp bld/linux/elftosb /usr/local/bin/
> +
> +Make sure the "elftosb" binary can be found in your $PATH, in this case
> this +means "/usr/local/bin/" has to be in your $PATH.
This is copy-paste
> +
> +2) Compiling U-Boot for MX28
> +
> +
> +Compiling the U-Boot for MX28 is straightforward and done as compiling
> U-Boot +for any other ARM device. For cross-compiler setup, please refer
> to ELDK5.0 +documentation. First, clean up the source code:
> +
> + $ make mrproper
> +
> +Next, configure U-Boot for MX28EVK:
> +
> + $ make mx28evk_config
> +
> +Lastly, compile U-Boot and prepare a "BootStream". The "BootStream" is a
> special +type of file, which the i.MX28 CPU can boot. This is handled by
> the following +command:
> +
> + $ make u-boot.sb
> +
> +HINT: To speed-up the build process, you can add -j, where N is number
> of + compiler instances that'll run in parallel.
> +
> +The code produces "u-boot.sb" file. This file needs to be augmented with a
> +proper header to allow successful boot from SD or NAND. Adding the header
> is +discussed in the following chapters.
> +
Copy-paste
> +3) Installation of U-Boot for MX28EVK to SD card
> +
> +
> +To boot an MX28 from SD, set the boot mode DIP switches as:
> +
> + * Boot Mode Select: 1 0 0 1 (Boot from SD card Slot 0 - U42)
> + * JTAG PSWITCH RESET: To the left (reset enabled)
> + * Battery Source: Down
> + * Wall 5V: Up
> + * VDD 5V: To the left (off)
> + * Hold Button: Down (off)
> +
> +Full reference at i.MX28 manual chapter 12.2.1 (Table 12-2).
> +
> +An SD card that can be used to boot U-Boot on a i.MX28 CPU must contain a
> DOS +partition table, which in turn carries a partition of special type
> and which +contains a special header. The rest of partitions in the DOS
> partition table can +be used by the user.
> +
> +To prepare such partition, use your favourite partitioning tool. The
> partition +must have the following parameters:
> +
> + * Start sector .. sector 2048
> + * Partition size at least 1024 kb
> + * Partition type 0x53 (sometimes "OnTrack DM6 Aux3")
> +
Re: [U-Boot] [RESEND] ca9x4_ct_vxp build error
Dear Matt Waddel, > Hi Marek, > > Your message wasn't ignored, you must have missed my response. > > There have been 2 patches submitted to fix this problem. They are > virtually identical: > > http://lists.denx.de/pipermail/u-boot/2012-March/119558.html > http://lists.denx.de/pipermail/u-boot/2012-February/118511.html > > Either one will work, I Acked the 2nd one since it was submitted > first: > > http://lists.denx.de/pipermail/u-boot/2012-March/119997.html Accept my apology for missing your response! CCing Albert, add my: Acked-by: Marek Vasut to the second patch please. > > Best regards, > Matt > > On 03/20/2012 03:11 PM, Marek Vasut wrote: > > As my previous remark about this board not building was ignored, I'm > > resending it one more time. I'll do one more resend of this note and if > > noone fixes this I'll submit a removal patch. > > > > $ CROSS_COMPILE=arm-linux-gnueabi- ARCH=arm ./MAKEALL ca9x4_ct_vxp > > Configuring for ca9x4_ct_vxp board... > > common/libcommon.o: In function `cread_line': > > /home/marex/U-Boot/u-boot-marex/common/main.c:695: undefined reference to > > `get_ticks' > > /home/marex/U-Boot/u-boot-marex/common/main.c:695: undefined reference to > > `get_tbclk' > > /home/marex/U-Boot/u-boot-marex/common/main.c:698: undefined reference to > > `get_ticks' > > arm-linux-gnueabi-ld: BFD (GNU Binutils for Debian) 2.22 assertion fail > > ../../bfd/elf32-arm.c:7498 > > arm-linux-gnueabi-ld: BFD (GNU Binutils for Debian) 2.22 assertion fail > > ../../bfd/elf32-arm.c:7498 > > arm-linux-gnueabi-ld: BFD (GNU Binutils for Debian) 2.22 assertion fail > > ../../bfd/elf32-arm.c:13830 > > /bin/sh: line 1: 11250 Segmentation fault arm-linux-gnueabi-ld -pie > > -T u- boot.lds -Bstatic -Ttext 0x6080 $UNDEF_SYM > > arch/arm/cpu/armv7/start.o -- start-group api/libapi.o > > arch/arm/cpu/armv7/libarmv7.o arch/arm/lib/libarm.o common/libcommon.o > > disk/libdisk.o drivers/bios_emulator/libatibiosemu.o > > drivers/block/libblock.o drivers/dma/libdma.o drivers/fpga/libfpga.o > > drivers/gpio/libgpio.o drivers/hwmon/libhwmon.o drivers/i2c/libi2c.o > > drivers/input/libinput.o drivers/misc/libmisc.o drivers/mmc/libmmc.o > > drivers/mtd/libmtd.o drivers/mtd/nand/libnand.o > > drivers/mtd/onenand/libonenand.o drivers/mtd/spi/libspi_flash.o > > drivers/mtd/ubi/libubi.o drivers/net/libnet.o drivers/net/phy/libphy.o > > drivers/pci/libpci.o drivers/pcmcia/libpcmcia.o drivers/power/libpower.o > > drivers/rtc/librtc.o drivers/serial/libserial.o drivers/spi/libspi.o > > drivers/twserial/libtws.o drivers/usb/eth/libusb_eth.o > > drivers/usb/gadget/libusb_gadget.o drivers/usb/host/libusb_host.o > > drivers/usb/musb/libusb_musb.o drivers/usb/phy/libusb_phy.o > > drivers/usb/ulpi/libusb_ulpi.o drivers/video/libvideo.o > > drivers/watchdog/libwatchdog.o fs/cramfs/libcramfs.o fs/ext2/libext2fs.o > > fs/fat/libfat.o fs/fdos/libfdos.o fs/jffs2/libjffs2.o > > fs/reiserfs/libreiserfs.o fs/ubifs/libubifs.o fs/yaffs2/libyaffs2.o > > lib/libfdt/libfdt.o lib/libgeneric.o lib/lzma/liblzma.o lib/lzo/liblzo.o > > lib/zlib/libz.o net/libnet.o post/libpost.o > > board/armltd/vexpress/libvexpress.o --end-group > > /home/marex/U-Boot/u-boot- marex/arch/arm/lib/eabi_compat.o -L > > /usr/lib/gcc/arm-linux-gnueabi/4.4.6 -lgcc - Map u-boot.map -o u-boot > > make: *** [u-boot] Error 139 > > arm-linux-gnueabi-size: ./u-boot: File format not recognized > > > > - SUMMARY > > Boards compiled: 1 > > Boards with warnings or errors: 1 ( ca9x4_ct_vxp ) > > -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] README.mx28: add
On Wed, Mar 21, 2012 at 16:21, Marek Vasut wrote: > This is copy-paste schizzle, can you please separate the CPU specific parts > into > one file and put only the different parts into their particular readmes? If you compare the v3 against the m28 one it is not a copy-paste anymore; it does has specific information and remove the not-applicable one. The v3 seems fine to me as is and makes easier to new users to find the desired information. -- Otavio Salvador O.S. Systems E-mail: ota...@ossystems.com.br http://www.ossystems.com.br Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] README.mx28: add
Dear Otavio Salvador, > This is mainline a copy of README.m28 changing the references to the > mx28 counterpart but it makes easy for people looking for information > about mx28 based boards. > > Signed-off-by: Otavio Salvador > Cc: Fabio Estevam This is copy-paste schizzle, can you please separate the CPU specific parts into one file and put only the different parts into their particular readmes? Thanks! Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mmc: omap: handle controller errors properly
On Monday 19 March 2012 15:14:39 Tom Rini wrote: > On 03/19/2012 03:12 PM, Grazvydas Ignotas wrote: > > According to OMAP3 TRM, when the controller reports certain > > errors, driver must perform a software reset. This is done by > > setting a bit in SYSCTL and waiting it to clear: > > - SRC on command timeout (CTO) > > - SRD on data errors (DTO, DCRC and DEB) > > > > This fixes a problem seen on OMAP3 pandora board with some cards > > > > that won't work with a message printed multiple times: > >timedout waiting on cmd inhibit to clear > > > > Code loosely based on Linux omap_hsmmc driver. > > > > Signed-off-by: Grazvydas Ignotas > > Most excellent! Pali, can you try this on N900 and see if that > helps out the problem you were having as well? > > Andy, I'll give this a spin through the boards I've got here but > I'd like this to go, via your tree, into u-boot/master assuming > all goes well. Hi! I tried this patch and it really fixed problem on Nokia N900. -- Pali Rohár pali.ro...@gmail.com 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 05/14] cfb_console: Fix function console_scrollup
On Wednesday 21 March 2012 12:32:16 Anatolij Gustschin wrote: > Hi Marek, > > On Wed, 21 Mar 2012 11:20:38 +0100 > > Marek Vasut wrote: > > Dear Anatolij Gustschin, > > > > > Hi, > > > > > > On Tue, 24 Jan 2012 15:28:02 +0100 > > > > > > Pali Rohár wrote: > > > > * Use correct buffer size, do not damage screen output > > > > > > > > Signed-off-by: Pali Rohár > > > > --- > > > > > > > > Changes since original version: > > > >- Fixed commit message > > > > > > > > drivers/video/cfb_console.c |2 +- > > > > 1 files changed, 1 insertions(+), 1 deletions(-) > > > > > > > > diff --git a/drivers/video/cfb_console.c > > > > b/drivers/video/cfb_console.c index 904caf7..9092399 100644 > > > > --- a/drivers/video/cfb_console.c > > > > +++ b/drivers/video/cfb_console.c > > > > @@ -701,7 +701,7 @@ static void console_scrollup(void) > > > > > > > > ); > > > > > > > > #else > > > > > > > > memcpyl(CONSOLE_ROW_FIRST, CONSOLE_ROW_SECOND, > > > > > > > > - CONSOLE_SCROLL_SIZE >> 2); > > > > + CONSOLE_SCROLL_SIZE); > > > > > > NAK. This change is wrong. CONSOLE_SCROLL_SIZE is the size of > > > the > > > visible frame buffer - size of one row in bytes. We are using > > > memcpyl() here, so the division by 4 (size >> 2) is correct. > > > With your change we end up copying 4 times more data then > > > needed. > > > > What kind of a problem are we fixing here? And what are the > > symptoms of it? > Actually I'm not aware of any problem in current > console_scrollup(). At least on two test setups with different > framebuffer drivers and in one setup with HW accelerated scrolling > I didn't see any problems with current code. > > The description in the commit log of this patch: > "Use correct buffer size, do not damage screen output" > doesn't say much about the problem. If the GraphicDevice structure > returned by video_hw_init() is setup correctly, the scrolling > should be working fine. From the other patch [1] I can see that > the structure is setup as follows: > > /* fill in Graphic Device */ > gdev.frameAdrs = 0x8f9c; > gdev.winSizeX = 800; > gdev.winSizeY = 480; > gdev.gdfBytesPP = 2; > gdev.gdfIndex = GDF_16BIT_565RGB; > memset((void *)gdev.frameAdrs, 0, 0xbb800); > return (void *) &gdev; > > Most likely using 0x8f9c as framebuffer address is the first > _big_ problem. The framebuffer address range is not allocated > properly and could be used by malloc area. The board has 256 MB of > RAM starting at 0x8000, if U-Boot relocated itself to the > upper RAM, the problems should be expected. > > AFAIK the N900 port doesn't use a framebuffer driver but probably > uses pre-initialized display controller configuration. This should > be fixed first. > > Thanks, > Anatolij Hi, can you show me how to fix this? How to correctly use framebuffer? -- Pali Rohár pali.ro...@gmail.com 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] NAND: TI: fix warnings in omap_gpmc.c
On 03/21/2012 06:33 AM, Stefano Babic wrote: > The following warnings are reported for boards using SOFT ECC. > > omap_gpmc.c:33:30: warning: 'hw_nand_oob' defined but not used > omap_gpmc.c:78:13: warning: 'omap_hwecc_init' defined but not used > omap_gpmc.c:116:12: warning: 'omap_correct_data' defined but not used > omap_gpmc.c:182:12: warning: 'omap_calculate_ecc' defined but not used > omap_gpmc.c:208:13: warning: 'omap_enable_hwecc' defined but not used > > Signed-off-by: Stefano Babic > Cc: Tom Rini > Cc: Scott Wood > --- > drivers/mtd/nand/omap_gpmc.c |6 ++ > 1 files changed, 6 insertions(+), 0 deletions(-) > > diff --git a/drivers/mtd/nand/omap_gpmc.c b/drivers/mtd/nand/omap_gpmc.c > index 1dfe074..3a9baff 100644 > --- a/drivers/mtd/nand/omap_gpmc.c > +++ b/drivers/mtd/nand/omap_gpmc.c > @@ -30,7 +30,10 @@ > #include > > static uint8_t cs; > +#if !defined(CONFIG_SPL_BUILD) || \ > + (defined(CONFIG_SPL_BUILD) && !defined(CONFIG_SPL_NAND_SOFTECC)) > static struct nand_ecclayout hw_nand_oob = GPMC_NAND_HW_ECC_LAYOUT; > +#endif > > /* > * omap_nand_hwcontrol - Set the address pointers corretly for the > @@ -69,6 +72,8 @@ int omap_spl_dev_ready(struct mtd_info *mtd) > } > #endif > > +#if !defined(CONFIG_SPL_BUILD) || \ > + (defined(CONFIG_SPL_BUILD) && !defined(CONFIG_SPL_NAND_SOFTECC)) > /* > * omap_hwecc_init - Initialize the Hardware ECC for NAND flash in > * GPMC controller > @@ -231,6 +236,7 @@ static void omap_enable_hwecc(struct mtd_info *mtd, > int32_t mode) > break; > } > } > +#endif > > #ifndef CONFIG_SPL_BUILD > /* Maybe just use __attribute__((unused))? Or provide this ifdeffery once at the top of the file, to produce a single symbol that indicates whether you're using hwecc in this file. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] tegra: Specify debugging serial port at boot.
On 03/21/2012 11:50 AM, Simon Glass wrote: > Hi Stephen, > > On Wed, Mar 21, 2012 at 10:38 AM, Stephen Warren > wrote: >> On 03/21/2012 11:13 AM, Simon Glass wrote: >>> Hi Stephen, >>> >>> On Wed, Mar 21, 2012 at 10:09 AM, Stephen Warren >>> wrote: On 03/21/2012 10:59 AM, Simon Glass wrote: > 3. What you propose is actually very easy to implement - it just > requires a new config like CONFIG_DEFAULT_UART or > CONFIG_PRE_CONSOLE_UART to be defined, and used in the > board_pre_console_putc() code. One question here: We already have CONFIG_TEGRA2_ENABLE_UART* and CONFIG_SYS_NS16550_COM* to select which UART to use. Surely one of those is appropriate for this, rather than inventing yet another config option? >>> >>> These will only exist when CONFIG_OF_CONTROL is not defined. It might >>> confusing to use the same CONFIGs for the pre-console panic() case, >>> knowing that they will in fact be ignored in a normal boot. I would >>> suggest a new option, at least in the CONFIG_OF_CONTROL case where the >>> two options you mention will not be used. >> >> Oh. >> >> But in u-boot-tegra/master, both Seaboard and Ventana still set those >> options even though they have CONFIG_OF_CONTROL turned on. And it looks >> like board_init_uart_f() both uses those defines irrespective of >> CONFIG_OF_CONTROL /and/ is called solely based on >> CONFIG_BOARD_EARLY_INIT_F (not CONFIG_OF_CONTROL), which is also defined >> for Seaboard and Ventana. > > Yes that's true. I have not yet prepared an upstream patch to fix > this. I will get to this one we have USB/I2C in, but in the meantime, > this series will probably nearly apply. The third patch is the main > event. > > https://gerrit.chromium.org/gerrit/#change,18256 > https://gerrit.chromium.org/gerrit/#change,18255 > https://gerrit.chromium.org/gerrit/#change,18257 > https://gerrit.chromium.org/gerrit/#change,18259 > >> >> I thought the upshot of this discussion was that there wasn't any need >> for any kind of pre-console stuff, either putc, puts/printf or whatever; >> instead, the console should simply be registered as early as possible >> based on the board/config's UART selection? > > Not quite - going back to your previous message, if there is a panic > before the console is ready (and in the event of there being no fdt) I > would like to offer a message on a UART selected by a CONFIG. > >> >> (and of course the DT parsed after that console was registered; no need >> for it before) > > The DT must be parsed before the console is registered - after all the > DT tells us which is the console. Yes, we can't know what console the DT says to use until the DT is located and parsed. That much is blatantly obvious. But the last few messages in this thread have all been about the following as far as I'm concerned: * The U-Boot configuration defines which single UART to use for the initial console. * This initial console is registered early enough that almost all failures can be reported. In particular, something as non-critical as locating and parsing the DT should happen after this initial console is registered, so that DT existence/parsing problems can be reported to this initial console. By non-critical here, I mean that there should be no reason to require the DT to be parsed in order for the CPU to boot, and the initial UART-based console to be registered. DT parsing shouldn't be attempted until this basic level of operation is achieved; it should be be required that the DT be parsed for any of that to work. * When the DT is parsed later, the console specification from DT replaces the initial console. With this scheme in place, there surely isn't any need for any kind of special-case early putc/puts/printf - wasn't this exactly Wolfgang's point? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] tegra: Specify debugging serial port at boot.
Hi Stephen, On Wed, Mar 21, 2012 at 10:38 AM, Stephen Warren wrote: > On 03/21/2012 11:13 AM, Simon Glass wrote: >> Hi Stephen, >> >> On Wed, Mar 21, 2012 at 10:09 AM, Stephen Warren >> wrote: >>> On 03/21/2012 10:59 AM, Simon Glass wrote: 3. What you propose is actually very easy to implement - it just requires a new config like CONFIG_DEFAULT_UART or CONFIG_PRE_CONSOLE_UART to be defined, and used in the board_pre_console_putc() code. >>> >>> One question here: We already have CONFIG_TEGRA2_ENABLE_UART* and >>> CONFIG_SYS_NS16550_COM* to select which UART to use. Surely one of those >>> is appropriate for this, rather than inventing yet another config option? >> >> These will only exist when CONFIG_OF_CONTROL is not defined. It might >> confusing to use the same CONFIGs for the pre-console panic() case, >> knowing that they will in fact be ignored in a normal boot. I would >> suggest a new option, at least in the CONFIG_OF_CONTROL case where the >> two options you mention will not be used. > > Oh. > > But in u-boot-tegra/master, both Seaboard and Ventana still set those > options even though they have CONFIG_OF_CONTROL turned on. And it looks > like board_init_uart_f() both uses those defines irrespective of > CONFIG_OF_CONTROL /and/ is called solely based on > CONFIG_BOARD_EARLY_INIT_F (not CONFIG_OF_CONTROL), which is also defined > for Seaboard and Ventana. Yes that's true. I have not yet prepared an upstream patch to fix this. I will get to this one we have USB/I2C in, but in the meantime, this series will probably nearly apply. The third patch is the main event. https://gerrit.chromium.org/gerrit/#change,18256 https://gerrit.chromium.org/gerrit/#change,18255 https://gerrit.chromium.org/gerrit/#change,18257 https://gerrit.chromium.org/gerrit/#change,18259 > > I thought the upshot of this discussion was that there wasn't any need > for any kind of pre-console stuff, either putc, puts/printf or whatever; > instead, the console should simply be registered as early as possible > based on the board/config's UART selection? Not quite - going back to your previous message, if there is a panic before the console is ready (and in the event of there being no fdt) I would like to offer a message on a UART selected by a CONFIG. > > (and of course the DT parsed after that console was registered; no need > for it before) The DT must be parsed before the console is registered - after all the DT tells us which is the console. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] tegra: Specify debugging serial port at boot.
On 03/21/2012 11:13 AM, Simon Glass wrote: > Hi Stephen, > > On Wed, Mar 21, 2012 at 10:09 AM, Stephen Warren > wrote: >> On 03/21/2012 10:59 AM, Simon Glass wrote: >>> 3. What you propose is actually very easy to implement - it just >>> requires a new config like CONFIG_DEFAULT_UART or >>> CONFIG_PRE_CONSOLE_UART to be defined, and used in the >>> board_pre_console_putc() code. >> >> One question here: We already have CONFIG_TEGRA2_ENABLE_UART* and >> CONFIG_SYS_NS16550_COM* to select which UART to use. Surely one of those >> is appropriate for this, rather than inventing yet another config option? > > These will only exist when CONFIG_OF_CONTROL is not defined. It might > confusing to use the same CONFIGs for the pre-console panic() case, > knowing that they will in fact be ignored in a normal boot. I would > suggest a new option, at least in the CONFIG_OF_CONTROL case where the > two options you mention will not be used. Oh. But in u-boot-tegra/master, both Seaboard and Ventana still set those options even though they have CONFIG_OF_CONTROL turned on. And it looks like board_init_uart_f() both uses those defines irrespective of CONFIG_OF_CONTROL /and/ is called solely based on CONFIG_BOARD_EARLY_INIT_F (not CONFIG_OF_CONTROL), which is also defined for Seaboard and Ventana. I thought the upshot of this discussion was that there wasn't any need for any kind of pre-console stuff, either putc, puts/printf or whatever; instead, the console should simply be registered as early as possible based on the board/config's UART selection? (and of course the DT parsed after that console was registered; no need for it before) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RESEND] ca9x4_ct_vxp build error
Hi Marek, Your message wasn't ignored, you must have missed my response. There have been 2 patches submitted to fix this problem. They are virtually identical: http://lists.denx.de/pipermail/u-boot/2012-March/119558.html http://lists.denx.de/pipermail/u-boot/2012-February/118511.html Either one will work, I Acked the 2nd one since it was submitted first: http://lists.denx.de/pipermail/u-boot/2012-March/119997.html Best regards, Matt On 03/20/2012 03:11 PM, Marek Vasut wrote: > As my previous remark about this board not building was ignored, I'm > resending > it one more time. I'll do one more resend of this note and if noone fixes > this > I'll submit a removal patch. > > $ CROSS_COMPILE=arm-linux-gnueabi- ARCH=arm ./MAKEALL ca9x4_ct_vxp > Configuring for ca9x4_ct_vxp board... > common/libcommon.o: In function `cread_line': > /home/marex/U-Boot/u-boot-marex/common/main.c:695: undefined reference to > `get_ticks' > /home/marex/U-Boot/u-boot-marex/common/main.c:695: undefined reference to > `get_tbclk' > /home/marex/U-Boot/u-boot-marex/common/main.c:698: undefined reference to > `get_ticks' > arm-linux-gnueabi-ld: BFD (GNU Binutils for Debian) 2.22 assertion fail > ../../bfd/elf32-arm.c:7498 > arm-linux-gnueabi-ld: BFD (GNU Binutils for Debian) 2.22 assertion fail > ../../bfd/elf32-arm.c:7498 > arm-linux-gnueabi-ld: BFD (GNU Binutils for Debian) 2.22 assertion fail > ../../bfd/elf32-arm.c:13830 > /bin/sh: line 1: 11250 Segmentation fault arm-linux-gnueabi-ld -pie -T u- > boot.lds -Bstatic -Ttext 0x6080 $UNDEF_SYM arch/arm/cpu/armv7/start.o -- > start-group api/libapi.o arch/arm/cpu/armv7/libarmv7.o arch/arm/lib/libarm.o > common/libcommon.o disk/libdisk.o drivers/bios_emulator/libatibiosemu.o > drivers/block/libblock.o drivers/dma/libdma.o drivers/fpga/libfpga.o > drivers/gpio/libgpio.o drivers/hwmon/libhwmon.o drivers/i2c/libi2c.o > drivers/input/libinput.o drivers/misc/libmisc.o drivers/mmc/libmmc.o > drivers/mtd/libmtd.o drivers/mtd/nand/libnand.o > drivers/mtd/onenand/libonenand.o > drivers/mtd/spi/libspi_flash.o drivers/mtd/ubi/libubi.o drivers/net/libnet.o > drivers/net/phy/libphy.o drivers/pci/libpci.o drivers/pcmcia/libpcmcia.o > drivers/power/libpower.o drivers/rtc/librtc.o drivers/serial/libserial.o > drivers/spi/libspi.o drivers/twserial/libtws.o drivers/usb/eth/libusb_eth.o > drivers/usb/gadget/libusb_gadget.o drivers/usb/host/libusb_host.o > drivers/usb/musb/libusb_musb.o drivers/usb/phy/libusb_phy.o > drivers/usb/ulpi/libusb_ulpi.o drivers/video/libvideo.o > drivers/watchdog/libwatchdog.o fs/cramfs/libcramfs.o fs/ext2/libext2fs.o > fs/fat/libfat.o fs/fdos/libfdos.o fs/jffs2/libjffs2.o > fs/reiserfs/libreiserfs.o > fs/ubifs/libubifs.o fs/yaffs2/libyaffs2.o lib/libfdt/libfdt.o > lib/libgeneric.o > lib/lzma/liblzma.o lib/lzo/liblzo.o lib/zlib/libz.o net/libnet.o > post/libpost.o > board/armltd/vexpress/libvexpress.o --end-group /home/marex/U-Boot/u-boot- > marex/arch/arm/lib/eabi_compat.o -L /usr/lib/gcc/arm-linux-gnueabi/4.4.6 > -lgcc - > Map u-boot.map -o u-boot > make: *** [u-boot] Error 139 > arm-linux-gnueabi-size: ./u-boot: File format not recognized > > - SUMMARY > Boards compiled: 1 > Boards with warnings or errors: 1 ( ca9x4_ct_vxp ) > -- -- Linaro.org │ Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro/155974581091106 http://twitter.com/#!/linaroorg http://www.linaro.org/linaro-blog/ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mx53: Make PLL2 to be the parent of UART clock
On Wed, Mar 21, 2012 at 12:42, Fabio Estevam wrote: ... > On a 2.6.35 kernel the serial console is messed up after IPU driver is loaded > and this patch fixes this problem. ... I tested it on my imx53qsb and it does fix the issue. Acked-by: Otavio Salvador -- Otavio Salvador O.S. Systems E-mail: ota...@ossystems.com.br http://www.ossystems.com.br Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] tegra: Specify debugging serial port at boot.
Hi Stephen, On Wed, Mar 21, 2012 at 10:09 AM, Stephen Warren wrote: > On 03/21/2012 10:59 AM, Simon Glass wrote: >> 3. What you propose is actually very easy to implement - it just >> requires a new config like CONFIG_DEFAULT_UART or >> CONFIG_PRE_CONSOLE_UART to be defined, and used in the >> board_pre_console_putc() code. > > One question here: We already have CONFIG_TEGRA2_ENABLE_UART* and > CONFIG_SYS_NS16550_COM* to select which UART to use. Surely one of those > is appropriate for this, rather than inventing yet another config option? These will only exist when CONFIG_OF_CONTROL is not defined. It might confusing to use the same CONFIGs for the pre-console panic() case, knowing that they will in fact be ignored in a normal boot. I would suggest a new option, at least in the CONFIG_OF_CONTROL case where the two options you mention will not be used. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] tegra: Specify debugging serial port at boot.
On 03/21/2012 10:59 AM, Simon Glass wrote: > 3. What you propose is actually very easy to implement - it just > requires a new config like CONFIG_DEFAULT_UART or > CONFIG_PRE_CONSOLE_UART to be defined, and used in the > board_pre_console_putc() code. One question here: We already have CONFIG_TEGRA2_ENABLE_UART* and CONFIG_SYS_NS16550_COM* to select which UART to use. Surely one of those is appropriate for this, rather than inventing yet another config option? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/4][v2] powerpc/85xx:Make debug exception vector accessible
On 03/21/2012 12:04 PM, Prabhakar Kushwaha wrote: > Hi Scott, > > On Wednesday 21 March 2012 10:04 PM, Scott Wood wrote: >> I don't see anywhere in this patchset where you set >> CONFIG_SYS_PPC_E500_DEBUG_TLB on any actual board. > > This CONFIG_SYS_PPC_E500_DEBUG_TLB is defined in > arch/powerpc/include/asm/config_mpc85xx.h. > i defined for P1010 (in this patch). For rest of e500 v1, v2 processor > family new patch-set will be sent once this base patch is accepted. Ah sorry, missed that. :-P -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/4][v2] powerpc/85xx:Make debug exception vector accessible
Hi Scott,
On Wednesday 21 March 2012 10:04 PM, Scott Wood wrote:
On 03/20/2012 11:43 PM, Prabhakar Kushwaha wrote:
diff --git a/arch/powerpc/cpu/mpc85xx/cpu_init_early.c
b/arch/powerpc/cpu/mpc85xx/cpu_init_early.c
index 091af7c..d0b15a4 100644
--- a/arch/powerpc/cpu/mpc85xx/cpu_init_early.c
+++ b/arch/powerpc/cpu/mpc85xx/cpu_init_early.c
@@ -1,5 +1,5 @@
/*
- * Copyright 2009-2011 Freescale Semiconductor, Inc
+ * Copyright 2009-2012 Freescale Semiconductor, Inc
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License as
@@ -53,6 +53,36 @@ void setup_ifc(void)
asm volatile("isync;msync;tlbwe;isync");
+#if defined(CONFIG_E500)&& defined(CONFIG_SYS_PPC_E500_DEBUG_TLB)
There is no need to check for CONFIG_E500 anywhere in
arch/powerpc/cpu/mpc85xx. mpc85xx implies CONFIG_E500.
Ok. I will re-spin all the patches without CONFIG_E500 condition check.
I don't see anywhere in this patchset where you set
CONFIG_SYS_PPC_E500_DEBUG_TLB on any actual board.
This CONFIG_SYS_PPC_E500_DEBUG_TLB is defined in
arch/powerpc/include/asm/config_mpc85xx.h.
i defined for P1010 (in this patch). For rest of e500 v1, v2 processor
family new patch-set will be sent once this base patch is accepted.
It should be set for
all e500v1/v2, not just so that debug works but so that this code
remains tested.
Yes. I agree with you.
It will be automatically enabled when CONFIG_SYS_PPC_E500_DEBUG_TLB is
defined per SoC(e500 v1/v2). As of now only for P1010 it is enabled.
--Prabhakar
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] tegra: Specify debugging serial port at boot.
Hi Stephen, On Wed, Mar 21, 2012 at 9:49 AM, Stephen Warren wrote: > On 03/21/2012 04:35 AM, Graeme Russ wrote: >> Hi Stephen, Wolfgang, >> >> On 03/21/2012 08:38 PM, Wolfgang Denk wrote: >>> Dear Simon Glass, >>> >>> In message >>> you >>> wrote: >> >>> We have standard ways of telling the Linux kernel what the console >>> port is - the "console=" boot argument has been working fine for many, >>> many years and many, many boards and systems. But Tegra needs to >>> invent it's own hackinsh implementation of putting special data in >>> some special registers. What a crap. >> >> This made me look into the x86 code - There is a command line option >> 'earlyprintk' which is available stupidly early (even the real-mode code >> and de-compressor have access to it) >> >> So I do now wonder why Tegra needs to do anything differently > > I was under the impression that earlyprintk was a boolean option, and > didn't take any arguments. But, a quick grep shows that some archs do > allow it to take an argument. The ARM code that handles the option > doesn't process the argument at present as far as I can tell, although > many ARM defconfigs do provide one. I'll see if it's possible to rework > the Tegra kernel code to use any earlyprintk argument. > > I doubt it will be possible to do this in the ARM zImage decompressor > though. > > Perhaps the kernel should follow these rules: > > If the kernel .config specifies a UART to output the early messages to, > then we use that by default (both for the zImage decompressor and > earlyprintk if enabled). This option can already include "none" which > would be safe across arbitary boards as a default. > > The zImage decompressor will always use that UART. If there are issues > in the decompressor, rebuild the kernel for the specific UART for the > board being tested to see the error spew. > > The kernel proper will parse any earlyprintk argument, and override the > UART specified in .config if an earlyprintk argument is present. > > This makes debugging zImage decmopressor issues slightly more annoying, > but (a) we'll probably have to do something like this for multi-SoC > kernel images anyway, and (b) zImage decompressor issues are quite rate. > > I suppose we could apply the same approach to U-Boot too: Have the > U-Boot configuration specify a UART to use for the console, which would > have to be "none" by default for maximum safety in a multi-board U-Boot > (build) config, but could be the single correct one for a single-board > U-Boot config. Then, replace this console with the one from DT once DT > is parsed. > > This would again make debugging a multi-board U-Boot config's boot hang > more annoying, since you'd have to rebuild in order to set a specific > "early" UART for the console, but at least it'd be possible. > > Then, we just have to make sure that this "early" console is always > available before any panic due to missing DT, so that problem would at > least be discoverable after setting the UART to use. Hopefully this > "early" console would be registered early enough that there are very > very few things that can fail before it... > > Tom/Simon: Does the U-Boot side of this sound acceptable to you? 1. I think we have agreed that we cannot and will not (at least for now) solve the problem of trying to get a message to the user during a panic() when we don't even know the console UART. 2. Given (1), it seems reasonable to allow the board config to select an 'early console UART' (which may be NONE) for use for very early panics in U-Boot. If this is not set, or set incorrectly, then no output will be visible. 3. What you propose is actually very easy to implement - it just requires a new config like CONFIG_DEFAULT_UART or CONFIG_PRE_CONSOLE_UART to be defined, and used in the board_pre_console_putc() code. So yes, I think it is acceptable. [[[ If I may comment on the Linux side, I think it is worth at least checking whether it is possible to find the UART in the zImage decompressor using the earlyprintk=... setting. It would solve the problem of this patch at least. Even if we need to just look at the number at the end of the setting and use that UART number :-( ]]] Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4][v2] doc:Add documentation for e500 external debugger support
Hi Scott, Thanks for reviewing it. Please find my reply in-lined. On Wednesday 21 March 2012 10:01 PM, Scott Wood wrote: On 03/20/2012 11:42 PM, Prabhakar Kushwaha wrote: diff --git a/README b/README index 8964672..48e50ed 100644 --- a/README +++ b/README @@ -3347,6 +3347,20 @@ Low Level (hardware related) configuration options: be used if available. These functions may be faster under some conditions but may increase the binary size. +E500 (MPC85xx) External Debug Support +- +-CONFIG_E500 + Enables BOOKE e500 family.It includes e500, e500v2 e500mc, + e5500 processor etc. This is not a debug-specific option. What's wrong with putting both of these options under the existing "85xx CPU Options" section? Yes. Both CONFIG_E500 and CONFIG_SYS_PPC_E500_DEBUG_TLB can be put under "85xx CPU Options". I made separate section thinking of CONFIG_SYS_PPC_E500_DEBUG_TLB as it required for overcoming e500 v1/v2 debugging restriction. i will send the updated patch. --Prabhakar ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] tegra: Specify debugging serial port at boot.
On 03/21/2012 04:35 AM, Graeme Russ wrote: > Hi Stephen, Wolfgang, > > On 03/21/2012 08:38 PM, Wolfgang Denk wrote: >> Dear Simon Glass, >> >> In message >> you >> wrote: > >> We have standard ways of telling the Linux kernel what the console >> port is - the "console=" boot argument has been working fine for many, >> many years and many, many boards and systems. But Tegra needs to >> invent it's own hackinsh implementation of putting special data in >> some special registers. What a crap. > > This made me look into the x86 code - There is a command line option > 'earlyprintk' which is available stupidly early (even the real-mode code > and de-compressor have access to it) > > So I do now wonder why Tegra needs to do anything differently I was under the impression that earlyprintk was a boolean option, and didn't take any arguments. But, a quick grep shows that some archs do allow it to take an argument. The ARM code that handles the option doesn't process the argument at present as far as I can tell, although many ARM defconfigs do provide one. I'll see if it's possible to rework the Tegra kernel code to use any earlyprintk argument. I doubt it will be possible to do this in the ARM zImage decompressor though. Perhaps the kernel should follow these rules: If the kernel .config specifies a UART to output the early messages to, then we use that by default (both for the zImage decompressor and earlyprintk if enabled). This option can already include "none" which would be safe across arbitary boards as a default. The zImage decompressor will always use that UART. If there are issues in the decompressor, rebuild the kernel for the specific UART for the board being tested to see the error spew. The kernel proper will parse any earlyprintk argument, and override the UART specified in .config if an earlyprintk argument is present. This makes debugging zImage decmopressor issues slightly more annoying, but (a) we'll probably have to do something like this for multi-SoC kernel images anyway, and (b) zImage decompressor issues are quite rate. I suppose we could apply the same approach to U-Boot too: Have the U-Boot configuration specify a UART to use for the console, which would have to be "none" by default for maximum safety in a multi-board U-Boot (build) config, but could be the single correct one for a single-board U-Boot config. Then, replace this console with the one from DT once DT is parsed. This would again make debugging a multi-board U-Boot config's boot hang more annoying, since you'd have to rebuild in order to set a specific "early" UART for the console, but at least it'd be possible. Then, we just have to make sure that this "early" console is always available before any panic due to missing DT, so that problem would at least be discoverable after setting the UART to use. Hopefully this "early" console would be registered early enough that there are very very few things that can fail before it... Tom/Simon: Does the U-Boot side of this sound acceptable to you? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/4][v2] powerpc/85xx:Make debug exception vector accessible
On 03/20/2012 11:43 PM, Prabhakar Kushwaha wrote:
> diff --git a/arch/powerpc/cpu/mpc85xx/cpu_init_early.c
> b/arch/powerpc/cpu/mpc85xx/cpu_init_early.c
> index 091af7c..d0b15a4 100644
> --- a/arch/powerpc/cpu/mpc85xx/cpu_init_early.c
> +++ b/arch/powerpc/cpu/mpc85xx/cpu_init_early.c
> @@ -1,5 +1,5 @@
> /*
> - * Copyright 2009-2011 Freescale Semiconductor, Inc
> + * Copyright 2009-2012 Freescale Semiconductor, Inc
> *
> * This program is free software; you can redistribute it and/or
> * modify it under the terms of the GNU General Public License as
> @@ -53,6 +53,36 @@ void setup_ifc(void)
>
> asm volatile("isync;msync;tlbwe;isync");
>
> +#if defined(CONFIG_E500) && defined(CONFIG_SYS_PPC_E500_DEBUG_TLB)
There is no need to check for CONFIG_E500 anywhere in
arch/powerpc/cpu/mpc85xx. mpc85xx implies CONFIG_E500.
I don't see anywhere in this patchset where you set
CONFIG_SYS_PPC_E500_DEBUG_TLB on any actual board. It should be set for
all e500v1/v2, not just so that debug works but so that this code
remains tested.
-Scott
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/5] Revert "Add board_pre_console_putc to deal with early console output"
Hi Wolfgang, On Wed, Mar 21, 2012 at 2:13 AM, Wolfgang Denk wrote: > Dear Simon Glass, > > In message <1332219558-9143-1-git-send-email-...@chromium.org> you wrote: >> This reverts commit 295d3942b806552503243f5cfb36aec6f1b5a9bf. >> >> It turns that this really doesn't work very nicely. Instead we should >> have a pre-console panic function so that we know that further execution >> is impossible and we don't need to worry about trampling on UARTs, etc. >> >> Signed-off-by: Simon Glass > > You failed to provide thw mandatory change log - it is impossible to > know what you changend in this V2 of the patches compared to the > previous verison. > > I assume that no changes were made and all review comments still apply > (at least the ones I made about design and concept do). > > Please stick to http://www.denx.de/wiki/U-Boot/Patches and especially > to > http://www.denx.de/wiki/view/U-Boot/Patches#Sending_updated_patch_versions There was no cover letter with this, which might have helped. However your assumption is correct - the only changes to the series were in the final patch (where there is a change log) and the addition of the new 'tegra_pre_console_panic' patch (which should have had 'new patch' in the change log). > > Patches ignored. Fair enough, you provided the comments I was looking for anyway, Regards, Simon > > 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 > "Do we define evil as the absence of goodness? It seems only logical > that shit happens--we discover this by the process of elimination." > -- Larry Wall ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 10/21] spi/kirkwood: add weak functions board_spi_bus_claim/release
> -Original Message-
> From: Holger Brunck [mailto:holger.bru...@keymile.com]
> Sent: 21 March 2012 21:19
> To: u-boot@lists.denx.de
> Cc: Valentin Longchamp; Gerlando Falauto; Prafulla Wadaskar; Holger
> Brunck
> Subject: [PATCH 10/21] spi/kirkwood: add weak functions
> board_spi_bus_claim/release
>
> From: Valentin Longchamp
>
> Some kirkwood based boards may need to implement such function due to
> some HW designs.
>
> Signed-off-by: Valentin Longchamp
> cc: Gerlando Falauto
> cc: Prafulla Wadaskar
> cc: Holger Brunck
> ---
> drivers/spi/kirkwood_spi.c | 12 +++-
> 1 files changed, 11 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/spi/kirkwood_spi.c b/drivers/spi/kirkwood_spi.c
> index db8ba8b..058dae2 100644
> --- a/drivers/spi/kirkwood_spi.c
> +++ b/drivers/spi/kirkwood_spi.c
> @@ -86,13 +86,23 @@ void spi_free_slave(struct spi_slave *slave)
> free(slave);
> }
>
> -int spi_claim_bus(struct spi_slave *slave)
> +__attribute__((weak)) int board_spi_claim_bus(struct spi_slave
> *slave)
> {
> return 0;
> }
>
> +int spi_claim_bus(struct spi_slave *slave)
> +{
> + return board_spi_claim_bus(slave);
> +}
> +
> +__attribute__((weak)) void board_spi_release_bus(struct spi_slave
> *slave)
> +{
> +}
> +
> void spi_release_bus(struct spi_slave *slave)
> {
> + board_spi_release_bus(slave);
> }
>
> #ifndef CONFIG_SPI_CS_IS_VALID
> --
> 1.7.1
Pls post this as standalone patch, does not have any dependency.
Exclude from this patch series.
Regards..
Prafulla . . .
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4][v2] doc:Add documentation for e500 external debugger support
On 03/20/2012 11:42 PM, Prabhakar Kushwaha wrote: > diff --git a/README b/README > index 8964672..48e50ed 100644 > --- a/README > +++ b/README > @@ -3347,6 +3347,20 @@ Low Level (hardware related) configuration options: > be used if available. These functions may be faster under some > conditions but may increase the binary size. > > +E500 (MPC85xx) External Debug Support > +- > +-CONFIG_E500 > + Enables BOOKE e500 family.It includes e500, e500v2 e500mc, > + e5500 processor etc. This is not a debug-specific option. What's wrong with putting both of these options under the existing "85xx CPU Options" section? -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 14/21] mvgbe: remove warning for unused methods
> -Original Message- > From: Holger Brunck [mailto:holger.bru...@keymile.com] > Sent: 21 March 2012 21:20 > To: u-boot@lists.denx.de > Cc: Stefan Bigler; Valentin Longchamp; Gerlando Falauto; Prafulla > Wadaskar; Holger Brunck > Subject: [PATCH 14/21] mvgbe: remove warning for unused methods > > From: Stefan Bigler > > Some baords may use the GBE interface but they have no > phy connected to the interface and a direct MAC/MAC interface. > For them we need to get rid of compiler warnings. > > Signed-off-by: Stefan Bigler > cc: Valentin Longchamp > cc: Gerlando Falauto > cc: Prafulla Wadaskar > cc: Holger Brunck > --- > drivers/net/mvgbe.c |2 ++ > 1 files changed, 2 insertions(+), 0 deletions(-) > > diff --git a/drivers/net/mvgbe.c b/drivers/net/mvgbe.c > index 477bf5c..dcc1547 100644 > --- a/drivers/net/mvgbe.c > +++ b/drivers/net/mvgbe.c > @@ -52,6 +52,7 @@ DECLARE_GLOBAL_DATA_PTR; > #define MV_PHY_ADR_REQUEST 0xee > #define MVGBE_SMI_REG (((struct mvgbe_registers *)MVGBE0_BASE)->smi) > > +#if defined(CONFIG_MII) || defined(CONFIG_CMD_MII) > /* > * smi_reg_read - miiphy_read callback function. > * > @@ -181,6 +182,7 @@ static int smi_reg_write(const char *devname, u8 > phy_adr, u8 reg_ofs, u16 data) > > return 0; > } > +#endif > > /* Stop and checks all queues */ > static void stop_queue(u32 * qreg) > -- Pls post this as standalone patch, does not have any dependency. Regards.. Prafulla . . . > 1.7.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] tegra: Specify debugging serial port at boot.
On 03/21/2012 03:38 AM, Wolfgang Denk wrote: ... > To bring this to a constructive end: > > It appears that all you are trying here is an annoying, but somewhat > unlikely error situation. As marked above (see *), it might make > sense to think of alternative ways to find out what the console port > might be. One possibility to do this is to use the environment. > You need access to the environment anyway to initialize the console > port (for reading the "baudrate" setting). So why not encoding the > console UART port for example as part of a "hwconfig" setting? This > setting could be auto-initialized when you load a DT on this board > (eventually after verifying that it works). > > OK, there is still a chance that the environment settings are missing > or incorrect _and_ the DT cannot be loaded, but the probability for > such a double-fault is much, much smaller. > > Could this be an acceptable solution for you? I'd prefer to just have a different U-Boot (build) config for each HW configuration, and define the console UART as part of that configuration using the existing defines that are for that purpose. If we put the UART ID into the environment, then we either need to: a) Have a different U-Boot configuration anyway, in order to define the different environment during the U-Boot build process. b) Post-process the U-Boot binary after building it, in order to modify the environment that's contained in that binary. Neither of those seem better to me that simply putting the UART ID into the U-Boot config directly in the first place. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/5] Add board_panic_no_console() to deal with early critical errors
Hi Wolfgang, On Wed, Mar 21, 2012 at 2:02 AM, Wolfgang Denk wrote: > Dear Simon Glass, > > In message <1332188824-5447-2-git-send-email-...@chromium.org> you wrote: >> This patch adds support for console output in the event of a panic() before >> the console is inited. The main purpose of this is to deal with a very early >> panic() which would otherwise cause a silent hang. >> >> A new board_pre_console_panic() function is added to the board API. If >> provided by the board it will be called in the event of a panic before the >> console is ready. This function should turn on all available UARTs and >> output the string (plus a newline) if it possibly can. > > In addition to the more constructive comments made already by Grame, I > object against this patch because I dislike the whole concept. Well I don't disagree :-) > >> +- Pre-console panic(): >> + Prior to the console being initialised, console output is >> + normally silently discarded. This can be annoying if a >> + panic() happens in this time. One reason for this might be > > True. This is the reason why it has always been an important design > rule for U-Boot to initialize the console port as soon as possible. > >> + that you have CONFIG_OF_CONTROL defined but have not >> + provided a valid device tree for U-Boot. In general U-Boot's >> + console code cannot resolve this problem, since the console >> + has not been set up, and it may not be known which UART is >> + the console anyway (for example if this information is in >> + the device tree). > > Please make up your mind: either you CAN initialize the console, then > you can use it to output messages in a regular way, or you CANNOT > initialize it, in which case you cannot print anything. There is no > third option. Well that is very clear - we cannot. We hit panic() before console_ready() is called. > >> + The solution is to define a function called >> + board_pre_console_panic() for your board, which alerts the >> + user however it can. Hopefuly this will involve displaying >> + a message on available UARTs, or perhaps at least flashing > > If you have "available UARTs", you could use this as console, right? Yes, if we knew which it was. > > In the previous discussion you explained the situation differently - > you were talking about _any_ UARTs that might be present on the > hardware, without caring about twhat these might actually be used for. Yes, basically the only difference with this series is that the board file can control what UARTs are used. > > I explained that such an approach is highly dangerous. I do not want > you toi set a precedent for such stle and code. OK > >> + an LED. The function should be very careful to only output >> + to UARTs that are known to be unused for peripheral >> + interfaces, and change GPIOs that will have no ill effect >> + on the board. That said, it is fine to do something >> + destructive that will prevent the board from continuing to >> + boot, since it isn't going to... > > Sorry, but this is bogus. Either you know the console port, or you > don't. If there is a free UART, it might be attached to custome > hardware you have no idea about. Ditto for GPIOs. Please do not > meddle with device state in arbitrary ways. If there are LED ports on > that board that are intended to signalize status information then it > makes sense to use these - but do not use any other ports that might > be present on the hardware. Yes that is true. The board file should know what is safe, but when we share board files among different hardware variants, we have exactly this problem. > >> + The function will need to output serial data directly, >> + since the console code is not functional yet. Note that if > > This is broken design. If you can initialize the UART as console, > then doi so and use it in the regular way. > >> + the panic happens early enough, then it is possible that >> + board_init_f() (or even arch_cpu_init() on ARM) has not >> + been called yet. You should init all clocks, GPIOs, etc. >> + that are needed to get the string out. Baud rates will need >> + to default to something sensible. > > Again, this is broken design. We cannot try to catch errors sooner > and sooner and soner, and if needed initialization steps have not been > executed yet, provide additional code for emergency initialization. > We have regular console code, and now we have pre_console_*() stuff, > and soon we will have pre_pre_pre_pre_pre_pre_pre_pre_console_*() > stuff ? NAK. > > Just stick to the design principles, and make sure there is as few > stuff that could possibly go wrong before console initialization as > possible. Than all this crap (excuse
[U-Boot] [PATCH 21/21] arm/km: cleanup km_kirkwood boards
Remove config options from boards.cfg and simply add one switch per board and differ afterwards in km_kirkwood.h between the features. More boards are upcoming and therefore it's easier to have this at one place. Signed-off-by: Holger Brunck cc: Valentin Longchamp cc: Gerlando Falauto cc: Prafulla Wadaskar --- boards.cfg|4 ++-- include/configs/km_kirkwood.h |7 ++- 2 files changed, 8 insertions(+), 3 deletions(-) diff --git a/boards.cfg b/boards.cfg index a0ec17b..c8b82d1 100644 --- a/boards.cfg +++ b/boards.cfg @@ -137,8 +137,8 @@ hawkboard_uart arm arm926ejs da8xxevmdavinci enbw_cmc arm arm926ejs enbw_cmcenbw davinci calimain arm arm926ejs calimain omicrondavinci dns325 arm arm926ejs - d-link kirkwood -km_kirkwood arm arm926ejs km_arm keymilekirkwoodkm_kirkwood:KM_KIRKWOOD,KM_DISABLE_PCI -km_kirkwood_pci arm arm926ejs km_arm keymilekirkwoodkm_kirkwood:KM_KIRKWOOD_PCI,KM_FPGA_CONFIG +km_kirkwood arm arm926ejs km_arm keymilekirkwoodkm_kirkwood:KM_KIRKWOOD +km_kirkwood_pci arm arm926ejs km_arm keymilekirkwoodkm_kirkwood:KM_KIRKWOOD_PCI kmnusa arm arm926ejs km_arm keymilekirkwoodkm_kirkwood:KM_NUSA mgcoge3unarm arm926ejs km_arm keymilekirkwoodkm_kirkwood:KM_MGCOGE3UN kmcoge5unarm arm926ejs km_arm keymilekirkwoodkm_kirkwood:KMCOGE5UN diff --git a/include/configs/km_kirkwood.h b/include/configs/km_kirkwood.h index 7d38413..549122b 100644 --- a/include/configs/km_kirkwood.h +++ b/include/configs/km_kirkwood.h @@ -37,15 +37,20 @@ #ifndef _CONFIG_KM_KIRKWOOD_H #define _CONFIG_KM_KIRKWOOD_H +/* KM_KIRKWOOD */ #if defined(CONFIG_KM_KIRKWOOD) #define CONFIG_IDENT_STRING"\nKeymile Kirkwood" #define CONFIG_HOSTNAMEkm_kirkwood -#undef CONFIG_KIRKWOOD_PCIE_INIT +#define CONFIG_KM_DISABLE_PCIE #define KM_IVM_BUS "pca9544a:70:9" /* I2C2 (Mux-Port 1)*/ + +/* KM_KIRKWOOD_PCI */ #elif defined(CONFIG_KM_KIRKWOOD_PCI) #define CONFIG_IDENT_STRING"\nKeymile Kirkwood PCI" #define CONFIG_HOSTNAMEkm_kirkwood_pci #define KM_IVM_BUS "pca9544a:70:9" /* I2C2 (Mux-Port 1)*/ +#define CONFIG_KM_FPGA_CONFIG + /* KM_NUSA */ #elif defined(CONFIG_KM_NUSA) #define KM_IVM_BUS "pca9547:70:9" /* I2C2 (Mux-Port 1)*/ -- 1.7.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 18/21] arm/km: remove portl2.h and use km_kirkwood instead
The additional headerfile is unneeded here, we can use the generic
km_kirkwood.h instead. And we can use the better config option
KM_PIGGY4_88E6061 for the specific features for boards with this
design in km_arm.c.
Signed-off-by: Holger Brunck
Acked-by: Valentin Longchamp
cc: Gerlando Falauto
cc: Prafulla Wadaskar
---
board/keymile/km_arm/km_arm.c |2 +-
boards.cfg|2 +-
include/configs/km_kirkwood.h |8
include/configs/portl2.h | 85 -
4 files changed, 10 insertions(+), 87 deletions(-)
delete mode 100644 include/configs/portl2.h
diff --git a/board/keymile/km_arm/km_arm.c b/board/keymile/km_arm/km_arm.c
index c948b13..4b83439 100644
--- a/board/keymile/km_arm/km_arm.c
+++ b/board/keymile/km_arm/km_arm.c
@@ -333,7 +333,7 @@ void dram_init_banksize(void)
}
}
-#if (defined(CONFIG_KM_MGCOGE3UN)|defined(CONFIG_PORTL2))
+#if (defined(CONFIG_KM_PIGGY4_88E6061))
#definePHY_LED_SEL 0x18
#define PHY_LED0_LINK (0x5)
diff --git a/boards.cfg b/boards.cfg
index 1af8e65..4094494 100644
--- a/boards.cfg
+++ b/boards.cfg
@@ -142,7 +142,7 @@ km_kirkwood_pci arm arm926ejs km_arm
keymile
kmnusa arm arm926ejs km_arm
keymilekirkwoodkm_kirkwood:KM_NUSA
mgcoge3unarm arm926ejs km_arm
keymilekirkwoodkm_kirkwood:KM_MGCOGE3UN
kmcoge5unarm arm926ejs km_arm
keymilekirkwoodkm_kirkwood:KMCOGE5UN
-portl2 arm arm926ejs km_arm
keymilekirkwood
+portl2 arm arm926ejs km_arm
keymilekirkwoodkm_kirkwood:KM_PORTL2
inetspace_v2 arm arm926ejs netspace_v2 LaCie
kirkwood lacie_kw:INETSPACE_V2
net2big_v2 arm arm926ejs net2big_v2 LaCie
kirkwood lacie_kw:NET2BIG_V2
netspace_max_v2 arm arm926ejs netspace_v2 LaCie
kirkwood lacie_kw:NETSPACE_MAX_V2
diff --git a/include/configs/km_kirkwood.h b/include/configs/km_kirkwood.h
index d1f3351..fbe714b 100644
--- a/include/configs/km_kirkwood.h
+++ b/include/configs/km_kirkwood.h
@@ -83,6 +83,14 @@
#define CONFIG_HOSTNAMEkmcoge5un
#define CONFIG_KM_DISABLE_PCIE
#define CONFIG_KM_PIGGY4_88E6352
+
+/* KM_PORTL2 */
+#elif defined(CONFIG_KM_PORTL2)
+#define CONFIG_IDENT_STRING"\nKeymile Port-L2"
+#define CONFIG_HOSTNAMEportl2
+#define KM_IVM_BUS "pca9544a:70:9" /* I2C2 (Mux-Port 1)*/
+#define CONFIG_KM_PIGGY4_88E6061
+
#else
#error ("Board unsupported")
#endif
diff --git a/include/configs/portl2.h b/include/configs/portl2.h
deleted file mode 100644
index e436cfe..000
--- a/include/configs/portl2.h
+++ /dev/null
@@ -1,85 +0,0 @@
-/*
- * (C) Copyright 2009
- * Marvell Semiconductor
- * Prafulla Wadaskar
- *
- * (C) Copyright 2009
- * Stefan Roese, DENX Software Engineering, s...@denx.de.
- *
- * (C) Copyright 2010-2011
- * Holger Brunck, Keymile GmbH Hannover, holger.bru...@keymile.com.
- * Valentin Longchamp, Keymile AG Bern, valentin.longch...@keymile.com
- *
- * 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
- */
-
-/* for linking errors see
- * http://lists.denx.de/pipermail/u-boot/2009-July/057350.html */
-
-#ifndef _CONFIG_PORTL2_H
-#define _CONFIG_PORTL2_H
-
-/* include common defines/options for all arm based Keymile boards */
-#include "km/km_arm.h"
-
-/*
- * Version number information
- */
-#define CONFIG_IDENT_STRING"\nKeymile Port-L2"
-#define CONFIG_HOSTNAMEportl2
-#define CONFIG_PORTL2
-
-#define KM_IVM_BUS "pca9544a:70:9" /* I2C2 (Mux-Port 1)*/
-/*
- * Note: This is only valid for HW > P1A if you got an outdated P1A
- * use KM_ENV_BUS "pca9544a:70:a"
- */
-#define KM_ENV_BUS "pca9544a:70:d" /* I2C2 (Mux-Port 5)*/
-
-/*
- * portl2 has a fixed link to the XMPP backplane
- * with 100MB full duplex and autoneg off, for this
- * reason we h
[U-Boot] [PATCH 15/21] arm/km: add kmnusa board support
This board is similar to portl2, but it has the u-boot environment in a SPI NOR flash and not in an i2c eeprom like portl2 have. Some other details: - IVM EEPROM is at adress: pca9547:70:9 - PCI is enabled - PIGGY4 is connected via MV88E6352 simple switch. There is no phy between the simple switch and the kirkwood. Signed-off-by: Holger Brunck Signed-off-by: Valentin Longchamp cc: Gerlando Falauto cc: Prafulla Wadaskar --- MAINTAINERS |1 + board/keymile/km_arm/128M16-1.cfg | 290 + board/keymile/km_arm/km_arm.c |9 +- boards.cfg|1 + include/configs/km/km_arm.h | 44 +- include/configs/km_kirkwood.h | 67 +++-- 6 files changed, 388 insertions(+), 24 deletions(-) create mode 100644 board/keymile/km_arm/128M16-1.cfg diff --git a/MAINTAINERS b/MAINTAINERS index 652113f..ddf9613 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -743,6 +743,7 @@ Sergey Lapin Valentin Longchamp km_kirkwood ARM926EJS (Kirkwood SoC) + kmnusa ARM926EJS (Kirkwood SoC) mgcoge3un ARM926EJS (Kirkwood SoC) portl2 ARM926EJS (Kirkwood SoC) diff --git a/board/keymile/km_arm/128M16-1.cfg b/board/keymile/km_arm/128M16-1.cfg new file mode 100644 index 000..cef8ea6 --- /dev/null +++ b/board/keymile/km_arm/128M16-1.cfg @@ -0,0 +1,290 @@ +# +# (C) Copyright 2010 +# Heiko Schocher, DENX Software Engineering, h...@denx.de. +# +# (C) Copyright 2012 +# Valentin Longchamp, Keymile AG, valentin.longch...@keymile.com +# Stefan Bigler, Keymile AG, stefan.big...@keymile.com +# +# (C) Copyright 2012 +# 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.kwimage for more details about how-to configure +# and create kirkwood boot image +# + +# Boot Media configurations +BOOT_FROM spi # Boot from SPI flash + +DATA 0xFFD1 0x0111 # MPP Control 0 Register +# bit 3-0: 2, MPPSel0 SPI_CSn (1=NF_IO[2]) +# bit 7-4: 2, MPPSel1 SPI_SI (1=NF_IO[3]) +# bit 12-8: 2, MPPSel2 SPI_SCK (1=NF_IO[4]) +# bit 15-12: 2, MPPSel3 SPI_SO (1=NF_IO[5]) +# bit 19-16: 1, MPPSel4 NF_IO[6] +# bit 23-20: 1, MPPSel5 NF_IO[7] +# bit 27-24: 1, MPPSel6 SYSRST_O +# bit 31-28: 0, MPPSel7 GPO[7] + +DATA 0xFFD10004 0x03303300 # MPP Control 1 Register +# bit 3-0: 0, MPPSel8 GPIO[8] +# bit 7-4: 0, MPPSel9 GPIO[9] +# bit 12-8: 3, MPPSel10 UA0_TXD +# bit 15-12: 3, MPPSel11 UA0_RXD +# bit 19-16: 0, MPPSel12 not connected +# bit 23-20: 3, MPPSel13 UA1_TXD +# bit 27-24: 3, MPPSel14 UA1_RXD +# bit 31-28: 0, MPPSel15 GPIO[15] + +DATA 0xFFD10008 0x1100 # MPP Control 2 Register +# bit 3-0: 0, MPPSel16 GPIO[16] +# bit 7-4: 0, MPPSel17 not connected +# bit 12-8: 1, MPPSel18 NF_IO[0] +# bit 15-12: 1, MPPSel19 NF_IO[1] +# bit 19-16: 0, MPPSel20 GPIO[20] +# bit 23-20: 0, MPPSel21 GPIO[21] +# bit 27-24: 0, MPPSel22 GPIO[22] +# bit 31-28: 0, MPPSel23 GPIO[23] + +# MPP Control 3-6 Register untouched (MPP24-49) + +DATA 0xFFD100E0 0x1B1B1B1B # IO Configuration 0 Register +# bit 2-0: 3, Reserved +# bit 5-3: 3, Reserved +# bit 6: 0, Reserved +# bit 7: 0, RGMII-pads voltage = 3.3V +# bit 10-8: 3, Reserved +# bit 13-11: 3, Reserved +# bit 14:0, Reserved +# bit 15:0, MPP RGMII-pads voltage = 3.3V +# bit 31-16 0x1B1B, Reserved + +DATA 0xFFD20134 0x # L2 RAM Timing 0 Register +# bit 0-1: 2, Tag RAM RTC RAM0 +# bit 3-2: 1, Tag RAM WTC RAM0 +# bit 7-4: 6, Reserve +# bit 9-8: 2, Valid RAM RTC RAM +# bit 11-10: 1, Valid RAM WTC RAM +# bit 13-12: 2, Dirty RAM RTC RAM +# bit 15-14: 1, Dirty RAM WTC RAM +# bit 17-16: 2, Data RAM RTC RAM0 +# bit 19-18: 1, Data RAM WTC RAM0 +# bit 21-20: 2, Data RAM RTC RAM1 +# bit 23-22: 1, Data RAM WTC RAM1 +# bit 25-24: 2, Data RAM RTC RAM2 +# bit 27-26: 1, Data RAM WTC RAM2 +# bit 29-28: 2, Data RAM RTC RAM3 +# bit 31-30: 1, Data RAM WTC RAM4 + +DATA 0xFFD20138 0x # L2 RAM Timing 1 Register +# bit 15-0: ???, Reserve +# bit 17-16: 2, ECC RAM RTC RAM0 +# bit 19-18: 1, ECC RAM WTC RAM0 +# bit 31-20: ???,Reserve + +DATA 0xFFD20154 0x0200 # CPU RAM Management Control3 Register +# bit 23-0: 0x000200, Addr Config tuni
[U-Boot] [PATCH 19/21] arm/km: correct init of 88e6352 switch in the reset_phy function
From: Valentin Longchamp
This is achieved thanks to the support read/write regs for the external
88e6352 switch. The functions for this are added into an own file
managed_switch.c. This is compiled if the define CONFIG_KM_MANAGED_SW_ADDR
was set in the board setup. This define specifies the phy address.
Signed-off-by: Valentin Longchamp
cc: Gerlando Falauto
cc: Prafulla Wadaskar
cc: Holger Brunck
---
board/keymile/common/common.h |6 +
board/keymile/km_arm/Makefile |4 +
board/keymile/km_arm/km_arm.c | 26 +-
board/keymile/km_arm/managed_switch.c | 166 +
include/configs/km_kirkwood.h | 13 +++
5 files changed, 214 insertions(+), 1 deletions(-)
create mode 100644 board/keymile/km_arm/managed_switch.c
diff --git a/board/keymile/common/common.h b/board/keymile/common/common.h
index 6c1f640..49225b8 100644
--- a/board/keymile/common/common.h
+++ b/board/keymile/common/common.h
@@ -125,6 +125,12 @@ struct bfticu_iomap {
int ethernet_present(void);
int ivm_read_eeprom(void);
+
+int ext_switch_reg_write(const char *devname, u8 phy_addr, u8 port,
+ u8 reg, u16 data);
+int ext_switch_reg_read(const char *devname, u8 phy_addr, u8 port,
+ u8 reg, u16 *data);
+
int set_km_env(void);
int fdt_set_node_and_value(void *blob,
char *nodename,
diff --git a/board/keymile/km_arm/Makefile b/board/keymile/km_arm/Makefile
index aa51255..06079e9 100644
--- a/board/keymile/km_arm/Makefile
+++ b/board/keymile/km_arm/Makefile
@@ -31,6 +31,10 @@ LIB = $(obj)lib$(BOARD).o
COBJS := $(BOARD).o ../common/common.o ../common/ivm.o
+ifdef CONFIG_KM_MANAGED_SW_ADDR
+COBJS += managed_switch.o
+endif
+
SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c)
OBJS := $(addprefix $(obj),$(COBJS))
SOBJS := $(addprefix $(obj),$(SOBJS))
diff --git a/board/keymile/km_arm/km_arm.c b/board/keymile/km_arm/km_arm.c
index 4b83439..f4be40f 100644
--- a/board/keymile/km_arm/km_arm.c
+++ b/board/keymile/km_arm/km_arm.c
@@ -9,6 +9,9 @@
* (C) Copyright 2010
* Heiko Schocher, DENX Software Engineering, h...@denx.de.
*
+ * (C) Copyright 2011, 2012
+ * Valentin Lontgchamp, Keymile AG, valentin.longch...@keymile.com
+ *
* See file CREDITS for list of people who contributed to this
* project.
*
@@ -36,6 +39,7 @@
#include
#include
#include
+#include
#include
#include
@@ -367,7 +371,27 @@ void reset_phy(void)
/* reset the phy */
miiphy_reset(name, CONFIG_PHY_BASE_ADR);
}
-#elif !defined(CONFIG_KM_PIGGY4_88E6352)
+#elif defined(CONFIG_KM_PIGGY4_88E6352)
+
+#if defined(CONFIG_KM_MANAGED_SW_ADDR)
+void reset_phy(void)
+{
+ char *name = "egiga0";
+
+ if (miiphy_set_current_dev(name))
+ return;
+
+ /* enable autoneg on port 0 phy */
+ ext_switch_reg_write(name, CONFIG_KM_MANAGED_SW_ADDR, 0, 0, 0x3300);
+
+ /* egress broadcast franes on all macs, with forwarding */
+ ext_switch_reg_write(name, CONFIG_KM_MANAGED_SW_ADDR, 16, 4, 0x000f);
+ ext_switch_reg_write(name, CONFIG_KM_MANAGED_SW_ADDR, 20, 4, 0x000f);
+ ext_switch_reg_write(name, CONFIG_KM_MANAGED_SW_ADDR, 21, 4, 0x000f);
+}
+#endif
+
+#else
/* Configure and enable MV88E1118 PHY on the piggy*/
void reset_phy(void)
{
diff --git a/board/keymile/km_arm/managed_switch.c
b/board/keymile/km_arm/managed_switch.c
new file mode 100644
index 000..482c18d
--- /dev/null
+++ b/board/keymile/km_arm/managed_switch.c
@@ -0,0 +1,166 @@
+/*
+ * (C) Copyright 2012
+ * Valentin Lontgchamp, Keymile AG, valentin.longch...@keymile.com
+ *
+ * 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
+ */
+
+#include
+#include
+#include
+
+#define SMI_HDR((0x8 | 0x1) << 12)
+#define SMI_BUSY_MASK (0x8000)
+#define SMIRD_OP (0x2 << 10)
+#define SMIWR_OP (0x1 << 10)
+#define SMI_MASK 0x1f
+#define PORT_SHIFT 5
+
+#define COMMAND_REG0
+#define DATA_REG 1
+
+static int ext_switch_wait_rdy(const char *devname, u8 phy_addr)
+{
+ u16 command;
+ u32 timeout = 100;
+ int ret;
+
+ /* wait till the SMI is not busy */
+ do {
+ /* read command register */
+ ret =
[U-Boot] [PATCH 20/21] arm/km: enable BOCO2 FPGA download support
From: Valentin Longchamp
This adds a first support of the FPGA download for a PCIe FPGA based
on the BOCO2 CPLD.
This takes place in 3 steps, all done accessing the SPICTRL reg of the
BOCO2:
1) start the FPGA config with an access to the FPGA_PROG bit
2) later in the boot sequence, wait for the FPGA_DONE bit to toggle to 1
for the end of the FPGA configuration (with a timeout)
3) reset the FPGA
4) finally remove the access to its config EEPROM from the FPGA so that
the CPU can update the FPGA configuration when the kernel is running
The boards with a PCIe FPGA but without BOCO2 still are supported.
The config option name is CONFIG_KM_FPGA_CONFIG
Signed-off-by: Valentin Longchamp
cc: Gerlando Falauto
cc: Prafulla Wadaskar
cc: Holger Brunck
---
board/keymile/common/common.h |6 +
board/keymile/km_arm/Makefile |4 +
board/keymile/km_arm/fpga_config.c | 212
board/keymile/km_arm/km_arm.c | 21 +++-
boards.cfg |2 +-
include/configs/km/km_arm.h|3 +
include/configs/km_kirkwood.h |8 +-
7 files changed, 246 insertions(+), 10 deletions(-)
create mode 100644 board/keymile/km_arm/fpga_config.c
diff --git a/board/keymile/common/common.h b/board/keymile/common/common.h
index 49225b8..c58e565 100644
--- a/board/keymile/common/common.h
+++ b/board/keymile/common/common.h
@@ -131,6 +131,12 @@ int ext_switch_reg_write(const char *devname, u8 phy_addr,
u8 port,
int ext_switch_reg_read(const char *devname, u8 phy_addr, u8 port,
u8 reg, u16 *data);
+
+int trigger_fpga_config(void);
+int wait_for_fpga_config(void);
+int fpga_reset(void);
+int toggle_eeprom_spi_bus(void);
+
int set_km_env(void);
int fdt_set_node_and_value(void *blob,
char *nodename,
diff --git a/board/keymile/km_arm/Makefile b/board/keymile/km_arm/Makefile
index 06079e9..bd824e2 100644
--- a/board/keymile/km_arm/Makefile
+++ b/board/keymile/km_arm/Makefile
@@ -31,6 +31,10 @@ LIB = $(obj)lib$(BOARD).o
COBJS := $(BOARD).o ../common/common.o ../common/ivm.o
+ifdef CONFIG_KM_FPGA_CONFIG
+COBJS += fpga_config.o
+endif
+
ifdef CONFIG_KM_MANAGED_SW_ADDR
COBJS += managed_switch.o
endif
diff --git a/board/keymile/km_arm/fpga_config.c
b/board/keymile/km_arm/fpga_config.c
new file mode 100644
index 000..4356b9a
--- /dev/null
+++ b/board/keymile/km_arm/fpga_config.c
@@ -0,0 +1,212 @@
+/*
+ * (C) Copyright 2012
+ * Valentin Lontgchamp, Keymile AG, valentin.longch...@keymile.com
+ *
+ * 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
+ */
+
+#include
+#include
+#include
+
+/* GPIO Pin from kirkwood connected to PROGRAM_B pin of the xilinx FPGA */
+#define KM_XLX_PROGRAM_B_PIN39
+
+#define BOCO_ADDR 0x10
+
+#define ID_REG 0x00
+#define BOCO2_ID 0x5b
+
+static int check_boco2(void)
+{
+ int ret;
+ u8 id;
+
+ ret = i2c_read(BOCO_ADDR, ID_REG, 1, &id, 1);
+ if (ret) {
+ printf("%s: error reading the BOCO id !!\n", __func__);
+ return ret;
+ }
+
+ return (id == BOCO2_ID);
+}
+
+static int boco_clear_bits(u8 reg, u8 flags)
+{
+ int ret;
+ u8 regval;
+
+ /* give access to the EEPROM from FPGA */
+ ret = i2c_read(BOCO_ADDR, reg, 1, ®val, 1);
+ if (ret) {
+ printf("%s: error reading the BOCO @%#x !!\n",
+ __func__, reg);
+ return ret;
+ }
+ regval &= ~flags;
+ ret = i2c_write(BOCO_ADDR, reg, 1, ®val, 1);
+ if (ret) {
+ printf("%s: error writing the BOCO @%#x !!\n",
+ __func__, reg);
+ return ret;
+ }
+
+ return 0;
+}
+
+static int boco_set_bits(u8 reg, u8 flags)
+{
+ int ret;
+ u8 regval;
+
+ /* give access to the EEPROM from FPGA */
+ ret = i2c_read(BOCO_ADDR, reg, 1, ®val, 1);
+ if (ret) {
+ printf("%s: error reading the BOCO @%#x !!\n",
+ __func__, reg);
+ return ret;
+ }
+ regval |= flags;
+ ret = i2c_write(BOCO_ADDR, reg, 1, ®val, 1);
+ if (ret) {
+ printf("%s: error writin
[U-Boot] [PATCH 17/21] arm/km: convert mgcoge3un target to km_kirkwood
Use the generic header km_kirkwood.h and get rid of the
board specific header.
Signed-off-by: Holger Brunck
Acked-by: Valentin Longchamp
cc: Gerlando Falauto
cc: Prafulla Wadaskar
---
board/keymile/km_arm/km_arm.c |9 ++--
boards.cfg|2 +-
include/configs/km_kirkwood.h | 46 +
include/configs/mgcoge3un.h | 87 -
4 files changed, 51 insertions(+), 93 deletions(-)
delete mode 100644 include/configs/mgcoge3un.h
diff --git a/board/keymile/km_arm/km_arm.c b/board/keymile/km_arm/km_arm.c
index ff57e60..c948b13 100644
--- a/board/keymile/km_arm/km_arm.c
+++ b/board/keymile/km_arm/km_arm.c
@@ -114,7 +114,7 @@ u32 kwmpp_config[] = {
0
};
-#if defined(CONFIG_MGCOGE3UN)
+#if defined(CONFIG_KM_MGCOGE3UN)
/*
* Wait for startup OK from mgcoge3ne
*/
@@ -134,8 +134,7 @@ int startup_allowed(void)
}
#endif
-#if (defined(CONFIG_MGCOGE3UN)|defined(CONFIG_PORTL2)| \
- defined(CONFIG_KM_PIGGY4_88E6352))
+#if (defined(CONFIG_KM_PIGGY4_88E6061)|defined(CONFIG_KM_PIGGY4_88E6352))
/*
* All boards with PIGGY4 connected via a simple switch have ethernet always
* present.
@@ -203,7 +202,7 @@ int misc_init_r(void)
printf("Overwriting MACH_TYPE with %d!!!\n", mach_type);
gd->bd->bi_arch_number = mach_type;
}
-#if defined(CONFIG_MGCOGE3UN)
+#if defined(CONFIG_KM_MGCOGE3UN)
char *wait_for_ne;
wait_for_ne = getenv("waitforne");
if (wait_for_ne != NULL) {
@@ -334,7 +333,7 @@ void dram_init_banksize(void)
}
}
-#if (defined(CONFIG_MGCOGE3UN)|defined(CONFIG_PORTL2))
+#if (defined(CONFIG_KM_MGCOGE3UN)|defined(CONFIG_PORTL2))
#definePHY_LED_SEL 0x18
#define PHY_LED0_LINK (0x5)
diff --git a/boards.cfg b/boards.cfg
index 38181ad..1af8e65 100644
--- a/boards.cfg
+++ b/boards.cfg
@@ -140,7 +140,7 @@ dns325 arm arm926ejs -
d-link
km_kirkwood arm arm926ejs km_arm
keymilekirkwoodkm_kirkwood:KM_KIRKWOOD,KM_DISABLE_PCI
km_kirkwood_pci arm arm926ejs km_arm
keymilekirkwoodkm_kirkwood:KM_KIRKWOOD_PCI,KM_RECONFIG_XLX
kmnusa arm arm926ejs km_arm
keymilekirkwoodkm_kirkwood:KM_NUSA
-mgcoge3unarm arm926ejs km_arm
keymilekirkwood
+mgcoge3unarm arm926ejs km_arm
keymilekirkwoodkm_kirkwood:KM_MGCOGE3UN
kmcoge5unarm arm926ejs km_arm
keymilekirkwoodkm_kirkwood:KMCOGE5UN
portl2 arm arm926ejs km_arm
keymilekirkwood
inetspace_v2 arm arm926ejs netspace_v2 LaCie
kirkwood lacie_kw:INETSPACE_V2
diff --git a/include/configs/km_kirkwood.h b/include/configs/km_kirkwood.h
index e6f0e36..d1f3351 100644
--- a/include/configs/km_kirkwood.h
+++ b/include/configs/km_kirkwood.h
@@ -58,6 +58,20 @@
#define CONFIG_KM_FPGA_CONFIG
#define CONFIG_KM_PIGGY4_88E6352
+/* KM_MGCOGE3UN */
+#elif defined(CONFIG_KM_MGCOGE3UN)
+#define CONFIG_IDENT_STRING"\nKeymile COGE3UN"
+#define CONFIG_HOSTNAMEmgcoge3un
+#define KM_IVM_BUS "pca9547:70:9" /* I2C2 (Mux-Port 1)*/
+#undef CONFIG_SYS_KWD_CONFIG
+#define CONFIG_SYS_KWD_CONFIG \
+ $(SRCTREE)/$(CONFIG_BOARDDIR)/kwbimage-memphis.cfg
+#define CONFIG_KM_BOARD_EXTRA_ENV "waitforne=true\0"
+#define CONFIG_PIGGY_MAC_ADRESS_OFFSET 3
+#define CONFIG_KM_DISABLE_PCIE
+#define CONFIG_KM_PIGGY4_88E6061
+
+/* KMCOGE5UN */
#elif defined(CONFIG_KMCOGE5UN)
#define CONFIG_IDENT_STRING"\nKeymile COGE5UN"
#define KM_IVM_BUS "pca9547:70:9" /* I2C2 (Mux-Port 1)*/
@@ -111,7 +125,39 @@
#endif
+#ifdef CONFIG_KM_PIGGY4_88E6061
+/*
+ * Some keymile boards like mgcoge3un have their PIGGY4 connected via
+ * an Marvell 88E6061 simple switch.
+ * In this case we have to change the default settings for the
+ * ethernet phy connected to the kirkwood.
+ * In this case 100MB full duplex and autoneg off
+ */
+#define PORT_SERIAL_CONTROL_VALUE ( \
+ MVGBE_FORCE_LINK_PASS | \
+ MVGBE_DIS_AUTO_NEG_FOR_DUPLX| \
+ MVGBE_DIS_AUTO_NEG_FOR_FLOW_CTRL| \
+ MVGBE_ADV_NO_FLOW_CTRL | \
+ MVGBE_FORCE_FC_MODE_NO_PAUSE_DIS_TX | \
+ MVGBE_FORCE_BP_MODE_NO_JAM | \
+ (1 << 9) /* Reserved bit has to be 1 */ | \
+ MVGBE_DO_NOT_FORCE_LINK_FAIL| \
+ MVGBE_DIS_AUTO_NEG_SPEED_GMII | \
+ MVGBE_DTE_ADV_0 | \
+ MVGBE_MIIPHY_MAC_MODE | \
+ MVGBE_AUTO_NEG_NO_CHANGE| \
[U-Boot] [PATCH 16/21] arm/km: add kmcoge5un board support
For u-boot this board is similar to mgcoge3un. But some differences are present. We have a different SDRAM on it and therefore a new SDRAM config file. Additionaly this board has a direct MAC/MAC connection from the kirkwood to a marvell simple switch without a phy inbetween, this needs a new configuration for the mvgbe driver. Signed-off-by: Holger Brunck Signed-off-by: Valentin Longchamp cc: Gerlando Falauto cc: Prafulla Wadaskar --- MAINTAINERS |1 + board/keymile/km_arm/256M8-1.cfg | 292 ++ boards.cfg |1 + include/configs/km_kirkwood.h| 16 ++- 4 files changed, 308 insertions(+), 2 deletions(-) create mode 100644 board/keymile/km_arm/256M8-1.cfg diff --git a/MAINTAINERS b/MAINTAINERS index ddf9613..78a2fe1 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -745,6 +745,7 @@ Valentin Longchamp km_kirkwood ARM926EJS (Kirkwood SoC) kmnusa ARM926EJS (Kirkwood SoC) mgcoge3un ARM926EJS (Kirkwood SoC) + kmcoge5un ARM926EJS (Kirkwood SoC) portl2 ARM926EJS (Kirkwood SoC) Nishanth Menon diff --git a/board/keymile/km_arm/256M8-1.cfg b/board/keymile/km_arm/256M8-1.cfg new file mode 100644 index 000..0b19832 --- /dev/null +++ b/board/keymile/km_arm/256M8-1.cfg @@ -0,0 +1,292 @@ +# +# (C) Copyright 2012 +# Stefan Bigler, Keymile AG, stefan.big...@keymile.com +# Norbert Mayer, Keymile AG, norbert.ma...@keymile.com +# Deepak Patel, XENTECH Limited, deepak.pa...@xentech.co.uk +# +# 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.kwimage for more details about how-to configure +# and create kirkwood boot image +# +# This configuration applies to COGE5 design (ARM-part) +# Two 8-Bit devices are connected on the 16-Bit bus on the same +# chip-select. The supported devices are +# MT47H256M8EB-3IT:C +# MT47H256M8EB-25EIT:C + +# Boot Media configurations +BOOT_FROM spi # Boot from SPI flash + +DATA 0xFFD1 0x0111 # MPP Control 0 Register +# bit 3-0: 2, MPPSel0 SPI_CSn (1=NF_IO[2]) +# bit 7-4: 2, MPPSel1 SPI_MOSI (1=NF_IO[3]) +# bit 12-8: 2, MPPSel2 SPI_SCK (1=NF_IO[4]) +# bit 15-12: 2, MPPSel3 SPI_MISO (1=NF_IO[5]) +# bit 19-16: 1, MPPSel4 NF_IO[6] +# bit 23-20: 1, MPPSel5 NF_IO[7] +# bit 27-24: 1, MPPSel6 SYSRST_O +# bit 31-28: 0, MPPSel7 GPO[7] + +DATA 0xFFD10004 0x03303300 # MPP Control 1 Register +# bit 3-0: 0, MPPSel8 GPIO[8] CPU_SDA bitbanged +# bit 7-4: 0, MPPSel9 GPIO[9] CPU_SCL bitbanged +# bit 12-8: 3, MPPSel10 UA0_TXD +# bit 15-12: 3, MPPSel11 UA0_RXD +# bit 19-16: 0, MPPSel12 not connected +# bit 23-20: 3, MPPSel13 GPIO[14] +# bit 27-24: 3, MPPSel14 GPIO[15] +# bit 31-28: 0, MPPSel15 GPIO[16] BOOT_FL_SEL (SPI-MUX Signal) + +DATA 0xFFD10008 0x1100 # MPP Control 2 Register +# bit 3-0: 0, MPPSel16 GPIO[16] +# bit 7-4: 0, MPPSel17 not connected +# bit 11-8: 1, MPPSel18 NF_IO[0] +# bit 15-12: 1, MPPSel19 NF_IO[1] +# bit 19-16: 0, MPPSel20 GPIO[20] +# bit 23-20: 0, MPPSel21 GPIO[21] +# bit 27-24: 0, MPPSel22 GPIO[22] +# bit 31-28: 0, MPPSel23 GPIO[23] + +# MPP Control 3-6 Register untouched (MPP24-49) + +DATA 0xFFD100E0 0x1B1B1B1B # IO Configuration 0 Register +# bit 2-0: 3, Reserved +# bit 5-3: 3, Reserved +# bit 6: 0, Reserved +# bit 7: 0, RGMII-pads voltage = 3.3V +# bit 10-8: 3, Reserved +# bit 13-11: 3, Reserved +# bit 14:0, Reserved +# bit 15:0, MPP RGMII-pads voltage = 3.3V +# bit 31-16 0x1B1B, Reserved + +DATA 0xFFD20134 0x # L2 RAM Timing 0 Register +# bit 0-1: 2, Tag RAM RTC RAM0 +# bit 3-2: 1, Tag RAM WTC RAM0 +# bit 7-4: 6, Reserved +# bit 9-8: 2, Valid RAM RTC RAM +# bit 11-10: 1, Valid RAM WTC RAM +# bit 13-12: 2, Dirty RAM RTC RAM +# bit 15-14: 1, Dirty RAM WTC RAM +# bit 17-16: 2, Data RAM RTC RAM0 +# bit 19-18: 1, Data RAM WTC RAM0 +# bit 21-20: 2, Data RAM RTC RAM1 +# bit 23-22: 1, Data RAM WTC RAM1 +# bit 25-24: 2, Data RAM RTC RAM2 +# bit 27-26: 1, Data RAM WTC RAM2 +# bit 29-28: 2, Data RAM RTC RAM3 +# bit 31-30: 1, Data RAM WTC RAM4 + +DATA 0xFFD20138 0x # L2 RAM Timing 1 Register +# bit 15-0: ?, Reserved +# bit 17-16: 2, ECC RAM RTC RAM0 +#
[U-Boot] [PATCH 08/21] arm/km: enable mii cmd
From: Valentin Longchamp
This is useful to debug the switch initialization
Signed-off-by: Valentin Longchamp
cc: Gerlando Falauto
cc: Prafulla Wadaskar
cc: Holger Brunck
---
include/configs/km/km_arm.h |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/include/configs/km/km_arm.h b/include/configs/km/km_arm.h
index 7ef..36eb765 100644
--- a/include/configs/km/km_arm.h
+++ b/include/configs/km/km_arm.h
@@ -159,6 +159,7 @@
*/
#define CONFIG_NETCONSOLE /* include NetConsole support */
#define CONFIG_MII /* expose smi ove miiphy interface */
+#define CONFIG_CMD_MII /* to debug mdio phy config */
#define CONFIG_MVGBE /* Enable Marvell Gbe Controller Driver */
#define CONFIG_SYS_FAULT_ECHO_LINK_DOWN/* detect link using phy */
#define CONFIG_MVGBE_PORTS {1, 0} /* enable port 0 only */
--
1.7.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 03/21] arm/km: rename CONFIG option CONFIG_KM_DEF_ENV_UPDATE
This config option sounds like the it is responsible for the
update of the environment, but it is the u-boot update handling.
Therefore we adapt it to a more apropriate naming.
Signed-off-by: Holger Brunck
cc: Valentin Longchamp
cc: Gerlando Falauto
cc: Prafulla Wadaskar
---
include/configs/km/km_arm.h |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/configs/km/km_arm.h b/include/configs/km/km_arm.h
index c73a10c..e46b510 100644
--- a/include/configs/km/km_arm.h
+++ b/include/configs/km/km_arm.h
@@ -81,7 +81,7 @@
"boot=bootm ${load_addr_r} - -\0" \
"cramfsloadfdt=true\0" \
"u-boot="xstr(CONFIG_HOSTNAME) "/u-boot.kwb\0" \
- CONFIG_KM_DEF_ENV_UPDATE\
+ CONFIG_KM_UPDATE_UBOOT \
""
#define CONFIG_SKIP_LOWLEVEL_INIT /* disable board lowlevel_init */
@@ -235,7 +235,7 @@ int get_scl(void);
"orion_nand:" \
"-(" CONFIG_KM_UBI_PARTITION_NAME ")"
-#defineCONFIG_KM_DEF_ENV_UPDATE
\
+#defineCONFIG_KM_UPDATE_UBOOT
\
"update=" \
"spi on;sf probe 0;sf erase 0 5;" \
"sf write ${load_addr_r} 0 ${filesize};"\
--
1.7.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 06/21] arm/km: change maintainer for mgcoge3un
Signed-off-by: Holger Brunck cc: Valentin Longchamp cc: Heiko Schocher cc: Prafulla Wadaskar cc: Gerlando Falauto --- MAINTAINERS |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 46f63a0..652113f 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -743,6 +743,7 @@ Sergey Lapin Valentin Longchamp km_kirkwood ARM926EJS (Kirkwood SoC) + mgcoge3un ARM926EJS (Kirkwood SoC) portl2 ARM926EJS (Kirkwood SoC) Nishanth Menon @@ -839,7 +840,6 @@ Heiko Schocher enbw_cmcARM926EJS (AM1808 SoC) magnesium i.MX27 - mgcoge3un ARM926EJS (Kirkwood SoC) Michael Schwingen -- 1.7.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 13/21] km/arm: remove spi toggle command
Now we toggle between SPI and NAND flash automatically if
we claim the SPI bus. So we can get rid of this command.
Signed-off-by: Holger Brunck
Signed-off-by: Valentin Longchamp
cc: Gerlando Falauto
cc: Prafulla Wadaskar
---
board/keymile/km_arm/km_arm.c | 26 --
include/configs/km/km_arm.h |5 ++---
2 files changed, 2 insertions(+), 29 deletions(-)
diff --git a/board/keymile/km_arm/km_arm.c b/board/keymile/km_arm/km_arm.c
index dcecf83..10c9a5f 100644
--- a/board/keymile/km_arm/km_arm.c
+++ b/board/keymile/km_arm/km_arm.c
@@ -313,32 +313,6 @@ void board_spi_release_bus(struct spi_slave *slave)
km_hw_spi_bus_claim(0);
}
-#if defined(CONFIG_CMD_SF)
-int do_spi_toggle(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
-{
- if (argc < 2)
- return cmd_usage(cmdtp);
-
- if ((strcmp(argv[1], "off") == 0)) {
- printf("SPI FLASH disabled, NAND enabled\n");
- km_hw_spi_bus_claim(0);
- } else if ((strcmp(argv[1], "on") == 0)) {
- printf("SPI FLASH enabled, NAND disabled\n");
- km_hw_spi_bus_claim(1);
- } else {
- return cmd_usage(cmdtp);
- }
-
- return 0;
-}
-
-U_BOOT_CMD(
- spitoggle, 2, 0, do_spi_toggle,
- "En-/disable SPI FLASH access",
- " - Enable (on) or disable (off) SPI FLASH access\n"
- );
-#endif
-
int dram_init(void)
{
/* dram_init must store complete ramsize in gd->ram_size */
diff --git a/include/configs/km/km_arm.h b/include/configs/km/km_arm.h
index e2e8793..edb8f4e 100644
--- a/include/configs/km/km_arm.h
+++ b/include/configs/km/km_arm.h
@@ -237,9 +237,8 @@ int get_scl(void);
#defineCONFIG_KM_UPDATE_UBOOT
\
"update=" \
- "spi on;sf probe 0;sf erase 0 5;" \
- "sf write ${load_addr_r} 0 ${filesize};"\
- "spi off\0"
+ "sf probe 0;sf erase 0 5;" \
+ "sf write ${load_addr_r} 0 ${filesize};\0"
/*
* Default environment variables
--
1.7.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 10/21] spi/kirkwood: add weak functions board_spi_bus_claim/release
From: Valentin Longchamp
Some kirkwood based boards may need to implement such function due to
some HW designs.
Signed-off-by: Valentin Longchamp
cc: Gerlando Falauto
cc: Prafulla Wadaskar
cc: Holger Brunck
---
drivers/spi/kirkwood_spi.c | 12 +++-
1 files changed, 11 insertions(+), 1 deletions(-)
diff --git a/drivers/spi/kirkwood_spi.c b/drivers/spi/kirkwood_spi.c
index db8ba8b..058dae2 100644
--- a/drivers/spi/kirkwood_spi.c
+++ b/drivers/spi/kirkwood_spi.c
@@ -86,13 +86,23 @@ void spi_free_slave(struct spi_slave *slave)
free(slave);
}
-int spi_claim_bus(struct spi_slave *slave)
+__attribute__((weak)) int board_spi_claim_bus(struct spi_slave *slave)
{
return 0;
}
+int spi_claim_bus(struct spi_slave *slave)
+{
+ return board_spi_claim_bus(slave);
+}
+
+__attribute__((weak)) void board_spi_release_bus(struct spi_slave *slave)
+{
+}
+
void spi_release_bus(struct spi_slave *slave)
{
+ board_spi_release_bus(slave);
}
#ifndef CONFIG_SPI_CS_IS_VALID
--
1.7.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 14/21] mvgbe: remove warning for unused methods
From: Stefan Bigler Some baords may use the GBE interface but they have no phy connected to the interface and a direct MAC/MAC interface. For them we need to get rid of compiler warnings. Signed-off-by: Stefan Bigler cc: Valentin Longchamp cc: Gerlando Falauto cc: Prafulla Wadaskar cc: Holger Brunck --- drivers/net/mvgbe.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/net/mvgbe.c b/drivers/net/mvgbe.c index 477bf5c..dcc1547 100644 --- a/drivers/net/mvgbe.c +++ b/drivers/net/mvgbe.c @@ -52,6 +52,7 @@ DECLARE_GLOBAL_DATA_PTR; #define MV_PHY_ADR_REQUEST 0xee #define MVGBE_SMI_REG (((struct mvgbe_registers *)MVGBE0_BASE)->smi) +#if defined(CONFIG_MII) || defined(CONFIG_CMD_MII) /* * smi_reg_read - miiphy_read callback function. * @@ -181,6 +182,7 @@ static int smi_reg_write(const char *devname, u8 phy_adr, u8 reg_ofs, u16 data) return 0; } +#endif /* Stop and checks all queues */ static void stop_queue(u32 * qreg) -- 1.7.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 11/21] arm/km: implement weak function board_spi_clam_bus/release
From: Valentin Longchamp
They are needed on all km_arm boards where we have the environement
variables in the NOR Flash. This is #ifdefed by
CONFIG_KM_ENV_IS_IN_SPI_NOR. First boards using this feature are
the upcoming boards kmcoge5un and kmnusa.
Signed-off-by: Valentin Longchamp
Signed-off-by: Holger Brunck
cc: Gerlando Falauto
cc: Prafulla Wadaskar
---
board/keymile/km_arm/km_arm.c | 11 +++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/board/keymile/km_arm/km_arm.c b/board/keymile/km_arm/km_arm.c
index 2507734..dcecf83 100644
--- a/board/keymile/km_arm/km_arm.c
+++ b/board/keymile/km_arm/km_arm.c
@@ -33,6 +33,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -302,6 +303,16 @@ int km_hw_spi_bus_claim(int on)
return 0;
}
+int board_spi_claim_bus(struct spi_slave *slave)
+{
+ return km_hw_spi_bus_claim(1);
+}
+
+void board_spi_release_bus(struct spi_slave *slave)
+{
+ km_hw_spi_bus_claim(0);
+}
+
#if defined(CONFIG_CMD_SF)
int do_spi_toggle(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
{
--
1.7.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 05/21] arm/km: fix wrong comment in SDRAM config for mgcoge3un
Signed-off-by: Holger Brunck Signed-off-by: Valentin Longchamp cc: Gerlando Falauto cc: Prafulla Wadaskar --- board/keymile/km_arm/kwbimage-memphis.cfg |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/board/keymile/km_arm/kwbimage-memphis.cfg b/board/keymile/km_arm/kwbimage-memphis.cfg index 2faaf2b..6df2ad7 100644 --- a/board/keymile/km_arm/kwbimage-memphis.cfg +++ b/board/keymile/km_arm/kwbimage-memphis.cfg @@ -149,7 +149,7 @@ DATA 0xFFD01424 0xF17F # DDR Controller Control High DATA 0xFFD01428 0x00084520 # DDR2 SDRAM Timing Low # bit3-0 : , required # bit7-4 : 0010, M_ODT assertion 2 cycles after read -# bit11-8 : 1001, M_ODT de-assertion 5 cycles after read +# bit11-8 : 0101, M_ODT de-assertion 5 cycles after read # bit15-12: 0100, internal ODT assertion 4 cycles after read # bit19-16: 1000, internal ODT de-assertion 8 cycles after read # bit31-20: 0 , required -- 1.7.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 12/21] arm/kirkwood: protect the ENV_SPI #defines
From: Valentin Longchamp So that they can be redefined by some boards specific values. Signed-off-by: Valentin Longchamp Signed-off-by: Holger Brunck cc: Gerlando Falauto cc: Prafulla Wadaskar --- arch/arm/include/asm/arch-kirkwood/config.h | 12 +--- 1 files changed, 9 insertions(+), 3 deletions(-) diff --git a/arch/arm/include/asm/arch-kirkwood/config.h b/arch/arm/include/asm/arch-kirkwood/config.h index 91164eb..a9499b7 100644 --- a/arch/arm/include/asm/arch-kirkwood/config.h +++ b/arch/arm/include/asm/arch-kirkwood/config.h @@ -82,9 +82,15 @@ #ifdef CONFIG_CMD_SF #define CONFIG_HARD_SPI1 #define CONFIG_KIRKWOOD_SPI1 -#define CONFIG_ENV_SPI_BUS 0 -#define CONFIG_ENV_SPI_CS 0 -#define CONFIG_ENV_SPI_MAX_HZ 5000/*50Mhz */ +#ifndef CONFIG_ENV_SPI_BUS +# define CONFIG_ENV_SPI_BUS0 +#endif +#ifndef CONFIG_ENV_SPI_CS +# define CONFIG_ENV_SPI_CS 0 +#endif +#ifndef CONFIG_ENV_SPI_MAX_HZ +# define CONFIG_ENV_SPI_MAX_HZ 5000 +#endif #endif /* -- 1.7.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 09/21] arm/km: use correct kw_gpio function for NAND/SPI switching
From: Valentin Longchamp
This used to be done with registers direct access, which is not clear
and optimal.
Signed-off-by: Valentin Longchamp
Signed-off-by: Holger Brunck
cc: Gerlando Falauto
cc: Prafulla Wadaskar
---
board/keymile/km_arm/km_arm.c | 55 +
include/configs/km/km_arm.h |2 +-
2 files changed, 29 insertions(+), 28 deletions(-)
diff --git a/board/keymile/km_arm/km_arm.c b/board/keymile/km_arm/km_arm.c
index c6c9a71..2507734 100644
--- a/board/keymile/km_arm/km_arm.c
+++ b/board/keymile/km_arm/km_arm.c
@@ -242,20 +242,15 @@ int misc_init_r(void)
int board_early_init_f(void)
{
- u32 tmp;
-
kirkwood_mpp_conf(kwmpp_config);
/*
-* The FLASH_GPIO_PIN switches between using a
+* The KM_FLASH_GPIO_PIN switches between using a
* NAND or a SPI FLASH. Set this pin on start
* to NAND mode.
*/
- tmp = readl(KW_GPIO0_BASE);
- writel(tmp | FLASH_GPIO_PIN , KW_GPIO0_BASE);
- tmp = readl(KW_GPIO0_BASE + 4);
- writel(tmp & (~FLASH_GPIO_PIN) , KW_GPIO0_BASE + 4);
-
+ kw_gpio_set_valid(KM_FLASH_GPIO_PIN, 1);
+ kw_gpio_direction_output(KM_FLASH_GPIO_PIN, 1);
#if defined(CONFIG_SOFT_I2C)
/* init the GPIO for I2C Bitbang driver */
kw_gpio_set_valid(KM_KIRKWOOD_SDA_PIN, 1);
@@ -284,35 +279,41 @@ int board_init(void)
return 0;
}
+int km_hw_spi_bus_claim(int on)
+{
+ int gpio_value = !on;
+
+ if (on) {
+ kwmpp_config[0] = MPP0_SPI_SCn;
+ kwmpp_config[1] = MPP1_SPI_MOSI;
+ kwmpp_config[2] = MPP2_SPI_SCK;
+ kwmpp_config[3] = MPP3_SPI_MISO;
+ } else {
+ kwmpp_config[0] = MPP0_NF_IO2;
+ kwmpp_config[1] = MPP1_NF_IO3;
+ kwmpp_config[2] = MPP2_NF_IO4;
+ kwmpp_config[3] = MPP3_NF_IO5;
+ }
+
+ /* Multi-Purpose Pins Functionality configuration */
+ kirkwood_mpp_conf(kwmpp_config);
+ kw_gpio_set_value(KM_FLASH_GPIO_PIN, gpio_value);
+
+ return 0;
+}
+
#if defined(CONFIG_CMD_SF)
int do_spi_toggle(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
{
- u32 tmp;
if (argc < 2)
return cmd_usage(cmdtp);
if ((strcmp(argv[1], "off") == 0)) {
printf("SPI FLASH disabled, NAND enabled\n");
- /* Multi-Purpose Pins Functionality configuration */
- kwmpp_config[0] = MPP0_NF_IO2;
- kwmpp_config[1] = MPP1_NF_IO3;
- kwmpp_config[2] = MPP2_NF_IO4;
- kwmpp_config[3] = MPP3_NF_IO5;
-
- kirkwood_mpp_conf(kwmpp_config);
- tmp = readl(KW_GPIO0_BASE);
- writel(tmp | FLASH_GPIO_PIN , KW_GPIO0_BASE);
+ km_hw_spi_bus_claim(0);
} else if ((strcmp(argv[1], "on") == 0)) {
printf("SPI FLASH enabled, NAND disabled\n");
- /* Multi-Purpose Pins Functionality configuration */
- kwmpp_config[0] = MPP0_SPI_SCn;
- kwmpp_config[1] = MPP1_SPI_MOSI;
- kwmpp_config[2] = MPP2_SPI_SCK;
- kwmpp_config[3] = MPP3_SPI_MISO;
-
- kirkwood_mpp_conf(kwmpp_config);
- tmp = readl(KW_GPIO0_BASE);
- writel(tmp & (~FLASH_GPIO_PIN) , KW_GPIO0_BASE);
+ km_hw_spi_bus_claim(1);
} else {
return cmd_usage(cmdtp);
}
diff --git a/include/configs/km/km_arm.h b/include/configs/km/km_arm.h
index 36eb765..e2e8793 100644
--- a/include/configs/km/km_arm.h
+++ b/include/configs/km/km_arm.h
@@ -227,7 +227,7 @@ int get_scl(void);
#define CONFIG_SPI_FLASH
#define CONFIG_SPI_FLASH_STMICRO
-#define FLASH_GPIO_PIN 0x0001
+#define KM_FLASH_GPIO_PIN 16
#define MTDIDS_DEFAULT "nand0=orion_nand"
/* test-only: partitioning needs some tuning, this is just for tests */
--
1.7.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 04/21] arm/km: use ARRAY_SIZE macro
Signed-off-by: Holger Brunck
cc: Valentin Longchamp
cc: Gerlando Falauto
cc: Prafulla Wadaskar
---
board/keymile/km_arm/km_arm.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/board/keymile/km_arm/km_arm.c b/board/keymile/km_arm/km_arm.c
index 9e9940c..c6c9a71 100644
--- a/board/keymile/km_arm/km_arm.c
+++ b/board/keymile/km_arm/km_arm.c
@@ -410,7 +410,7 @@ const ulong patterns[] = { 0x,
0xFF00FF00,
0x0F0F0F0F,
0xF0F0F0F0};
-const ulong NBR_OF_PATTERNS = sizeof(patterns)/sizeof(*patterns);
+const ulong NBR_OF_PATTERNS = ARRAY_SIZE(patterns);
const ulong OFFS_PATTERN= 3;
const ulong REPEAT_PATTERN = 1000;
--
1.7.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 07/21] arm/km: remove CONFIG_RESET_PHY_R
This is already defined in the generic kirkwood header.
Signed-off-by: Holger Brunck
cc: Valentin Longchamp
cc: Gerlando Falauto
cc: Prafulla Wadaskar
---
include/configs/km/km_arm.h |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/include/configs/km/km_arm.h b/include/configs/km/km_arm.h
index e46b510..7ef 100644
--- a/include/configs/km/km_arm.h
+++ b/include/configs/km/km_arm.h
@@ -164,7 +164,6 @@
#define CONFIG_MVGBE_PORTS {1, 0} /* enable port 0 only */
#define CONFIG_PHY_BASE_ADR0
#define CONFIG_ENV_OVERWRITE /* ethaddr can be reprogrammed */
-#define CONFIG_RESET_PHY_R /* use reset_phy() to init 88E1118 PHY */
/*
* UBI related stuff
--
1.7.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 01/21] arm/km: add board type to boards.cfg
Some other kirkwood boards from keymile will follow. They will have some small differences, but we want to use the km_kirkwood.h for all to distinguish them. This patch a preparation for this. Signed-off-by: Holger Brunck cc: Valentin Longchamp cc: Gerlando Falauto cc: Prafulla Wadaskar --- boards.cfg|4 ++-- include/configs/km_kirkwood.h |4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/boards.cfg b/boards.cfg index 28cc345..08ac582 100644 --- a/boards.cfg +++ b/boards.cfg @@ -137,8 +137,8 @@ hawkboard_uart arm arm926ejs da8xxevmdavinci enbw_cmc arm arm926ejs enbw_cmcenbw davinci calimain arm arm926ejs calimain omicrondavinci dns325 arm arm926ejs - d-link kirkwood -km_kirkwood arm arm926ejs km_arm keymilekirkwood km_kirkwood:KM_DISABLE_PCI -km_kirkwood_pci arm arm926ejs km_arm keymilekirkwood km_kirkwood:KM_RECONFIG_XLX +km_kirkwood arm arm926ejs km_arm keymilekirkwoodkm_kirkwood:KM_KIRKWOOD,KM_DISABLE_PCI +km_kirkwood_pci arm arm926ejs km_arm keymilekirkwoodkm_kirkwood:KM_KIRKWOOD_PCI,KM_RECONFIG_XLX mgcoge3unarm arm926ejs km_arm keymilekirkwood portl2 arm arm926ejs km_arm keymilekirkwood inetspace_v2 arm arm926ejs netspace_v2 LaCie kirkwood lacie_kw:INETSPACE_V2 diff --git a/include/configs/km_kirkwood.h b/include/configs/km_kirkwood.h index ed36124..f639edc 100644 --- a/include/configs/km_kirkwood.h +++ b/include/configs/km_kirkwood.h @@ -42,10 +42,10 @@ /* * Version number information */ -#ifdef CONFIG_KM_DISABLE_PCI +#if defined(CONFIG_KM_KIRKWOOD) #define CONFIG_IDENT_STRING"\nKeymile Kirkwood" #undef CONFIG_KIRKWOOD_PCIE_INIT -#else +#elif defined(CONFIG_KM_KIRKWOOD_PCI) #define CONFIG_IDENT_STRING"\nKeymile Kirkwood PCI" #endif -- 1.7.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 00/21] updates for keymile arm boards
This patch series updates keymile boards with Kirkwood CPU and adds two new boards. This new boards are kmnusa and kmcoge5un. Also the existing boards with own config files were migrated to the common header km_kirkwood.h. Some small adaption in generic kirkwood code was needed due to two new features on the new board. First one is that the u-boot environment is in the SPI NOR flash and the second one is the direct MAC/MAC connection from the mvgbe interface to an simple switch. Holger Brunck (13): arm/km: add board type to boards.cfg arm/km: add piggy mac adress offset for mgcoge3un arm/km: rename CONFIG option CONFIG_KM_DEF_ENV_UPDATE arm/km: use ARRAY_SIZE macro arm/km: fix wrong comment in SDRAM config for mgcoge3un arm/km: change maintainer for mgcoge3un arm/km: remove CONFIG_RESET_PHY_R km/arm: remove spi toggle command arm/km: add kmnusa board support arm/km: add kmcoge5un board support arm/km: convert mgcoge3un target to km_kirkwood arm/km: remove portl2.h and use km_kirkwood instead arm/km: cleanup km_kirkwood boards Stefan Bigler (1): mvgbe: remove warning for unused methods Valentin Longchamp (7): arm/km: enable mii cmd arm/km: use correct kw_gpio function for NAND/SPI switching spi/kirkwood: add weak functions board_spi_bus_claim/release arm/km: implement weak function board_spi_clam_bus/release arm/kirkwood: protect the ENV_SPI #defines arm/km: correct init of 88e6352 switch in the reset_phy function arm/km: enable BOCO2 FPGA download support MAINTAINERS |4 +- arch/arm/include/asm/arch-kirkwood/config.h | 12 +- board/keymile/common/common.h | 12 + board/keymile/km_arm/128M16-1.cfg | 290 ++ board/keymile/km_arm/256M8-1.cfg| 292 +++ board/keymile/km_arm/Makefile |8 + board/keymile/km_arm/fpga_config.c | 212 +++ board/keymile/km_arm/km_arm.c | 119 +++- board/keymile/km_arm/kwbimage-memphis.cfg |2 +- board/keymile/km_arm/managed_switch.c | 166 +++ boards.cfg | 10 +- drivers/net/mvgbe.c |2 + drivers/spi/kirkwood_spi.c | 12 +- include/configs/km/km_arm.h | 60 -- include/configs/km_kirkwood.h | 157 +-- include/configs/mgcoge3un.h | 86 include/configs/portl2.h| 85 17 files changed, 1269 insertions(+), 260 deletions(-) create mode 100644 board/keymile/km_arm/128M16-1.cfg create mode 100644 board/keymile/km_arm/256M8-1.cfg create mode 100644 board/keymile/km_arm/fpga_config.c create mode 100644 board/keymile/km_arm/managed_switch.c delete mode 100644 include/configs/mgcoge3un.h delete mode 100644 include/configs/portl2.h cc: Valentin Longchamp cc: Gerlando Falauto cc: Prafulla Wadaskar ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 02/21] arm/km: add piggy mac adress offset for mgcoge3un
On mgcoge3un the piggy mac adress is at offset 3. Signed-off-by: Holger Brunck cc: Valentin Longchamp cc: Gerlando Falauto cc: Prafulla Wadaskar --- include/configs/mgcoge3un.h |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/include/configs/mgcoge3un.h b/include/configs/mgcoge3un.h index 797b0df..156821c 100644 --- a/include/configs/mgcoge3un.h +++ b/include/configs/mgcoge3un.h @@ -77,6 +77,7 @@ MVGBE_SET_MII_SPEED_TO_100) #define CONFIG_KM_BOARD_EXTRA_ENV "waitforne=true\0" +#define CONFIG_PIGGY_MAC_ADRESS_OFFSET 3 /* * PCIe port not used on mgcoge3un -- 1.7.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] mx53: Make PLL2 to be the parent of UART clock
Change the parent UART clock to be PLL2, so that U-boot can also boot a Freescale 2.6.35 kernel for mx53. FSL kernel and U-boot changed the UART parent from PLL3 to PLL2 to avoid conflicts with IPU clocks, so that the video resolution can be changed without affecting the UART clock. On a 2.6.35 kernel the serial console is messed up after IPU driver is loaded and this patch fixes this problem. Tested on a mx53loco board booting a FSL kernel and also a mainline kernel. Reported-by: Otavio Salvador Signed-off-by: Fabio Estevam --- arch/arm/cpu/armv7/mx5/lowlevel_init.S | 20 +--- 1 files changed, 17 insertions(+), 3 deletions(-) diff --git a/arch/arm/cpu/armv7/mx5/lowlevel_init.S b/arch/arm/cpu/armv7/mx5/lowlevel_init.S index 01f6d75..90c6ec1 100644 --- a/arch/arm/cpu/armv7/mx5/lowlevel_init.S +++ b/arch/arm/cpu/armv7/mx5/lowlevel_init.S @@ -284,10 +284,24 @@ ldr r1, =0x00C30321 str r1, [r0, #CLKCTL_CSCDR1] #elif defined(CONFIG_MX53) + /* Switch peripheral to PLL2 */ + ldr r0, =CCM_BASE_ADDR + ldr r1, =0x00808145 + orr r1, r1, #(2 << 10) + orr r1, r1, #(0 << 16) + orr r1, r1, #(1 << 19) + str r1, [r0, #CLKCTL_CBCDR] + + ldr r1, =0x00016154 + str r1, [r0, #CLKCTL_CBCMR] + /* Change uart clk parent to pll2*/ + ldr r1, [r0, #CLKCTL_CSCMR1] + and r1, r1, #0xfcff + orr r1, r1, #0x0100 + str r1, [r0, #CLKCTL_CSCMR1] ldr r1, [r0, #CLKCTL_CSCDR1] - orr r1, r1, #0x3f - eor r1, r1, #0x3f - orr r1, r1, #0x21 + and r1, r1, #0xffc0 + orr r1, r1, #0x0a str r1, [r0, #CLKCTL_CSCDR1] #endif /* make sure divider effective */ -- 1.7.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] README.mx28: add
Dear Otavio Salvador, In message <1332295831-19224-1-git-send-email-ota...@ossystems.com.br> you wrote: > This is mainline a copy of README.m28 changing the references to the s/mainline/mainly/ ? > mx28 counterpart but it makes easy for people looking for information > about mx28 based boards. I don't like that we copy all this stuff around for each and every board that uses the i.MX28; there may be a lot of such boards one day, and we will have a maintenenace nightmare because nobody will keep all tehse READMEs in sync. Can we please split this document in a generic and board specific part? For now, while there are only very few boards, this can probably be done in a single document. 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 is easier to change the specification to fit the program than vice versa. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Please pull u-boot-cfi-flash/master
Hi Wolfgang, please pull the following fix: The following changes since commit dbb87bbd8eff11cf974caa2b5cc397aea444bc5a: Armada100: gplugD: Add FAT & EXT2 command support (2012-03-19 00:08:26 +0100) are available in the git repository at: git://www.denx.de/git/u-boot-cfi-flash.git master for you to fetch changes up to 85c344e5f98408c0bcf988a6c6fca68c1f3c2015: cfi: fix the incomplete erased status check in buffer write (2012-03-21 16:25:33 +0100) Tao Hou (1): cfi: fix the incomplete erased status check in buffer write drivers/mtd/cfi_flash.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3] README.mx28evk: add
This is mainline a copy of README.m28 changing the references to the
mx28evk counterpart and removing NAND instructions as it is not
supported by the board.
Signed-off-by: Otavio Salvador
Acked-by: Fabio Estevam
---
doc/README.mx28evk | 153
1 files changed, 153 insertions(+), 0 deletions(-)
create mode 100644 doc/README.mx28evk
diff --git a/doc/README.mx28evk b/doc/README.mx28evk
new file mode 100644
index 000..ddca310
--- /dev/null
+++ b/doc/README.mx28evk
@@ -0,0 +1,153 @@
+Freescale MX28EVK
+=
+
+This document describes the Freescale MX28EVK U-Boot port. This document mostly
+covers topics related to making the board bootable. Only the MX28EVK revision D
+has been tested.
+
+Terminology
+---
+
+The dollar symbol ($) introduces a snipped of shell code. This shall be typed
+into the unix command prompt in U-Boot source code root directory.
+
+The (=>) introduces a snipped of code that should by typed into U-Boot command
+prompt.
+
+Contents
+
+
+0) Files of the MX28EVK port
+1) Prerequisites
+2) Compiling U-Boot for MX28EVK
+3) Installation of U-Boot for MX28EVK to SD card
+
+0) Files of the MX28EVK port
+
+
+arch/arm/cpu/arm926ejs/mx28/ - The CPU support code for the Freescale i.MX28
+arch/arm/include/asm/arch-mx28/- Header files for the Freescale i.MX28
+board/denx/mx28evk/- MX28EVK board specific files
+include/configs/mx28evk.h - MX28EVK configuration file
+
+1) Prerequisites
+
+
+To make the MX28EVK board bootable, some tools are necessary. The first one is
+the "elftosb" tool distributed by Freescale Semiconductor. The other tool is
the
+"mxsboot" tool found in U-Boot source tree.
+
+Firstly, obtain the elftosb archive from the following location:
+
+ http://foss.doredevelopment.dk/mirrors/imx/elftosb-10.12.01.tar.gz
+
+We use a $VER variable here to denote the current version. At the time of
+writing of this document, that is "10.12.01". To obtain the file from command
+line, use:
+
+ $ VER="10.12.01"
+ $ wget http://foss.doredevelopment.dk/mirrors/imx/elftosb-${VER}.tar.gz
+
+Extract the file:
+
+ $ tar xzf elftosb-${VER}.tar.gz
+
+Compile the file. We need to manually tell the linker to use also libm:
+
+ $ cd elftosb-${VER}/
+ $ make LIBS="-lstdc++ -lm" elftosb
+
+Optionally, remove debugging symbols from elftosb:
+
+ $ strip bld/linux/elftosb
+
+Finally, install the "elftosb" binary. The "install" target is missing, so just
+copy the binary by hand:
+
+ $ sudo cp bld/linux/elftosb /usr/local/bin/
+
+Make sure the "elftosb" binary can be found in your $PATH, in this case this
+means "/usr/local/bin/" has to be in your $PATH.
+
+2) Compiling U-Boot for MX28
+
+
+Compiling the U-Boot for MX28 is straightforward and done as compiling U-Boot
+for any other ARM device. For cross-compiler setup, please refer to ELDK5.0
+documentation. First, clean up the source code:
+
+ $ make mrproper
+
+Next, configure U-Boot for MX28EVK:
+
+ $ make mx28evk_config
+
+Lastly, compile U-Boot and prepare a "BootStream". The "BootStream" is a
special
+type of file, which the i.MX28 CPU can boot. This is handled by the following
+command:
+
+ $ make u-boot.sb
+
+HINT: To speed-up the build process, you can add -j, where N is number of
+ compiler instances that'll run in parallel.
+
+The code produces "u-boot.sb" file. This file needs to be augmented with a
+proper header to allow successful boot from SD or NAND. Adding the header is
+discussed in the following chapters.
+
+3) Installation of U-Boot for MX28EVK to SD card
+
+
+To boot an MX28 from SD, set the boot mode DIP switches as:
+
+ * Boot Mode Select: 1 0 0 1 (Boot from SD card Slot 0 - U42)
+ * JTAG PSWITCH RESET: To the left (reset enabled)
+ * Battery Source: Down
+ * Wall 5V: Up
+ * VDD 5V: To the left (off)
+ * Hold Button: Down (off)
+
+Full reference at i.MX28 manual chapter 12.2.1 (Table 12-2).
+
+An SD card that can be used to boot U-Boot on a i.MX28 CPU must contain a DOS
+partition table, which in turn carries a partition of special type and which
+contains a special header. The rest of partitions in the DOS partition table
can
+be used by the user.
+
+To prepare such partition, use your favourite partitioning tool. The partition
+must have the following parameters:
+
+ * Start sector .. sector 2048
+ * Partition size at least 1024 kb
+ * Partition type 0x53 (sometimes "OnTrack DM6 Aux3")
+
+For example in Linux fdisk, the sequence for a clear card follows. Be sure to
+run fdisk with the option "-u=sectors" to set units to sectors:
+
+ * o . create a clear partition table
+ * n . create new partition
+ * p .
Re: [U-Boot] [PATCH v2] README.mx28: add
On Wed, Mar 21, 2012 at 12:03, Stefano Babic wrote: > only a couple of small issues. You have already changed inside the file > all occurencies of mx28 to mx28evk. You should also rename this file to > make sure it is specific to the mx28evk and not, for example, to the > m28evk or generally for the SOC. So please rename it to README.mx28evk. Will send v3 in a minute. :) -- Otavio Salvador O.S. Systems E-mail: ota...@ossystems.com.br http://www.ossystems.com.br Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] README.mx28: add
On Tue, Mar 20, 2012 at 11:10 PM, Otavio Salvador wrote: > This is mainline a copy of README.m28 changing the references to the > mx28 counterpart but it makes easy for people looking for information > about mx28 based boards. > > Signed-off-by: Otavio Salvador > Cc: Fabio Estevam > --- > doc/README.mx28 | 152 > +++ > 1 files changed, 152 insertions(+), 0 deletions(-) > create mode 100644 doc/README.mx28 > > diff --git a/doc/README.mx28 b/doc/README.mx28 > new file mode 100644 > index 000..a68ad72 > --- /dev/null > +++ b/doc/README.mx28 > @@ -0,0 +1,152 @@ > +Freescale MX28EVK > += > + > +This document describes the Freescale MX28EVK U-Boot port. This document > mostly > +covers topics related to making the module/board bootable. As you will have to respin it, please remove "module" and also include "Only the latest revision of MX28EVK has been tested (rev. D)". ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] README.mx28: add
On 21/03/2012 03:10, Otavio Salvador wrote: > This is mainline a copy of README.m28 changing the references to the > mx28 counterpart but it makes easy for people looking for information > about mx28 based boards. > Hi Otavio, only a couple of small issues. You have already changed inside the file all occurencies of mx28 to mx28evk. You should also rename this file to make sure it is specific to the mx28evk and not, for example, to the m28evk or generally for the SOC. So please rename it to README.mx28evk. Can you also rename the subject in a form like: mx28evk: Add README.mx28evk Fabio has alrady sent his ACK, I will merge this patch in the forthcoming release. 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
[U-Boot] Targets in the Makefile, SPL and .img
If you make u-boot.img it doesn't also make in the SPL directory. Can this get fixed before the next release? -- Jon Smirl jonsm...@gmail.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [BUG] cfi_flash can't work correctly on latest uboot
Hi Bob,
sorry for the late reply.
On Wednesday 02 November 2011 08:20:03 Bob Liu wrote:
> Hi, folks
>
> I think this patch make cfi_flash can't work correctly.
> http://git.denx.de/?p=u-boot.git;a=commitdiff;h=df4e813b72bf07d9026b00455f5
> e7dffd694ae48
>
> --- a/drivers/mtd/cfi_flash.c
> +++ b/drivers/mtd/cfi_flash.c
> @@ -1426,6 +1426,11 @@ int flash_real_protect (flash_info_t * info,
> long sector, int prot)
> #endif
> };
>
> + /*
> +* Flash needs to be in status register read mode for
> +* flash_full_status_check() to work correctly
> +*/
> + flash_write_cmd(info, sector, 0, FLASH_CMD_READ_STATUS);
>
> --
> without this line, flash can't be recognized. So it's correct here.
>
> U-Boot 2011.09-svn2735 (ADI-2012R1-pre) (Nov 02 2011 - 15:05:23)
> --
>
> if ((retcode =
> flash_full_status_check (info, sector, info->erase_blk_tout,
> prot ? "protect" : "unprotect")) ==
> 0) { @@ -1975,6 +1980,13 @@ ulong flash_get_size (phys_addr_t base, int
> banknum)
> case CFI_CMDSET_INTEL_PROG_REGIONS:
> case CFI_CMDSET_INTEL_EXTENDED:
> case CFI_CMDSET_INTEL_STANDARD:
> + /*
> +* Set flash to read-id mode.
> Otherwise
> +* reading protected status is not
> +* guaranteed.
> +*/
> + flash_write_cmd(info, sect_cnt, 0,
> + FLASH_CMD_READ_ID);
> ---
> - But with this two lines. flash ops are not correct.
>
> I used old uboot version to read out data from flash.
> Then tftpboot and run with latest uboot version, you can see that the read
> out data from flash is different.
> And without set flash to read-id mode here, it works fine.
>
> U-Boot 2010.06 (ADI-2010R1-RC2) (Oct 20 2010 - 04:37:34)
>
> CPU: ADSP bf526-0.0 (Detected Rev: 0.2) (parallel flash boot)
> Board: ADI BF526 EZ-Board board
>Support: http://blackfin.uclinux.org/
> Clock: VCO: 400 MHz, Core: 400 MHz, System: 80 MHz
> RAM: 64 MiB
> Flash: 4 MiB
> In:serial
> Out: serial
> Err: serial
> KGDB: [on serial] ready
> Net: bfin_mac
> Hit any key to stop autoboot: 0
> bfin>
> bfin> md 0x2010
> 2010: 56190527 0b223987 d60baf4e 2e871c00'..V.9".N...
> 20100010: 0010 c42c1c00 a86adb94 01021005..,...j.
> 20100020: 32356662 2e302d36 2e332d30 2d382e30bf526-0.0-3.0.8-
> 20100030: 2d494441 31313032 702d3152 732d6572ADI-2011R1-pre-s
> 20100040: 00088b1f fdc40302 4514780b.x.E
> 20100050: 570e38d6 3d33264f 24f48743 0649d303.8.WO&3=C..$..I.
> 20100060: 93080932 834e9970 0931141a 648443a02...p.N...1..C.d
> 20100070: e0804212 12048762 56501a34 086bb2f1.B..b...4.PV..k.
> 20100080: 66e0888a d9782808 d165049d 75049945...f.(x...e.E..u
> 20100090: 31415041 ba02cba2 aebbb2ae 8093d34bAPA1K...
> 201000a0: 682f1a8a 9cffceb8 105ceeea 7f7df77d../h..\.}.}.
> 201000b0: 3c7cf3df 3aea984f 9d554ea7 4e753aaa..| 201000c0: b1a94e5d b13ae91e cc436dbe 749b42c2]N:..mC..B.t
> 201000d0: fa449283 2aa2ec29 a82e0846 b7089ae5..D.)..*F...
> 201000e0: cc1f9dc4 a9920651 113e5122 b1122213Q..."Q>.."..
> 201000f0: 308f15a9 b6496a6a 12562598 49a8c8af...0jjI..%VI
>
> bfin> tftpboot 0x1000 u-boot.bin
> Using bfin_mac device
> TFTP from server 10.100.4.174; our IP address is 10.100.4.50
> Filename 'u-boot.bin'.
> Load address: 0x1000
> Loading: ###
> done
> Bytes transferred = 213828 (34344 hex)
> bfin> go 0x1000
> ## Starting application at 0x1000 ...
>
>
> U-Boot 2011.09-svn2735 (ADI-2012R1-pre) (Nov 02 2011 - 15:15:05)
>
> CPU: ADSP bf526-0.0 (Detected Rev: 0.2) (parallel flash boot)
> Board: ADI BF526 EZ-Board board
>Support: http://blackfin.uclinux.org/
> Clock: VCO: 400 MHz, Core: 400 MHz, System: 80 MHz
> RAM: 64 MiB
> Flash: 4 MiB
> In:serial
> Out: serial
> Err: serial
> KGDB: [on serial] ready
> Net: bfin_mac
> Hit any key to stop autoboot: 0
> bfin> md 0x2010
> 2010: 88150020 0001 bfcf ...
> 20100010:
> 20100020: 00520051 00030059 0039 Q.R.Y.9.
Hmmm. Strange. Your flash still seems to be in read-id mode after
initial detection. But from looking at flash_get_size(),
the following flash reset command should bring it back to read-array
mode:
flash_write_cmd (info, 0, 0, info->cmd_reset);
Did you check that cmd_reset is set correctly on your hard
[U-Boot] How to specify the TEXT_BASE
Hi All, I am working on the porting of uboot at freescale MPC8360, now stuck on the address TEXT_BASE. in our board, the address of Nor Flash is 0xfc00_-0x_, the high 1MB from 0xfff0_ is used for boot rom. could you instruct me how to specify the TEXT_BASE? is the same to the 0xfc00_ ? in addition, the region of SDRAM is 0x_ to 0x0fff_. Besd regards, -Peter___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 4/6] km/common: add support for second flash
From: Andreas Huber
Add support for a second flash.
By default, a single flash chip is set up:
- called 'boot'
- mtd name for ubi 'ubi0'
MTDIDS and MTDPARTS may be overwritten to add a second flash.
The 'ubiattach' command is featured in two versions:
- if CONFIG_KM_UBI_PARTITION_NAME_APP is not defined:
this is the version as up to now
- if CONFIG_KM_UBI_PARTITION_NAME_APP is defined:
a check on 'actual_bank' will be done to determine the flash to boot
from.
Use CONFIG_KM_UBI_PARTITION_NAME_BOOT and
CONFIG_KM_UBI_PARTITION_NAME_APP to define where to put the bootloader
and the applications.
Example:
In the board config do:
... snip ...
"boot:" \
"768k(u-boot)," \
"128k(env),"\
"128k(envred)," \
"-(" CONFIG_KM_UBI_PARTITION_NAME_BOOT ");" \
"app:" \
"-(" CONFIG_KM_UBI_PARTITION_NAME_APP ");"
... snap ...
You may also need to enable the second flash:
... snip ...
/* additional featured for COGE5 */
... snap ...
Signed-off-by: Andreas Huber
cc: Kim Phillips
cc: Valentin Longchamp
cc: Gerlando Falauto
Signed-off-by: Holger Brunck
---
include/configs/km/keymile-common.h | 34 +-
include/configs/km/km83xx-common.h | 11 ---
include/configs/km/km_arm.h | 15 +--
3 files changed, 42 insertions(+), 18 deletions(-)
diff --git a/include/configs/km/keymile-common.h
b/include/configs/km/keymile-common.h
index 7a01705..4f606a0 100644
--- a/include/configs/km/keymile-common.h
+++ b/include/configs/km/keymile-common.h
@@ -126,12 +126,29 @@
"netdev=eth0\0"
#endif
-#ifndef CONFIG_KM_UBI_PARTITION_NAME
-#define CONFIG_KM_UBI_PARTITION_NAME "ubi0"
-#endif
-#ifndef CONFIG_KM_UBI_LINUX_MTD_NAME
-#define CONFIG_KM_UBI_LINUX_MTD_NAME "ubi0"
-#endif
+#ifndef CONFIG_KM_UBI_PARTITION_NAME_BOOT
+#define CONFIG_KM_UBI_PARTITION_NAME_BOOT "ubi0"
+#endif /* CONFIG_KM_UBI_PARTITION_NAME_BOOT */
+
+#ifndef CONFIG_KM_UBI_PARTITION_NAME_APP
+/* one flash chip only called boot */
+/* boot: CONFIG_KM_UBI_PARTITION_NAME_BOOT */
+# define CONFIG_KM_UBI_LINUX_MTD \
+ "ubi.mtd=" CONFIG_KM_UBI_PARTITION_NAME_BOOT
+# define CONFIG_KM_DEV_ENV_FLASH_BOOT_UBI \
+ "ubiattach=ubi part " CONFIG_KM_UBI_PARTITION_NAME_BOOT "\0"
+#else /* CONFIG_KM_UBI_PARTITION_NAME_APP */
+/* two flash chips called boot and app */
+/* boot: CONFIG_KM_UBI_PARTITION_NAME_BOOT */
+/* app: CONFIG_KM_UBI_PARTITION_NAME_APP */
+# define CONFIG_KM_UBI_LINUX_MTD \
+ "ubi.mtd=" CONFIG_KM_UBI_PARTITION_NAME_BOOT " "\
+ "ubi.mtd=" CONFIG_KM_UBI_PARTITION_NAME_APP
+# define CONFIG_KM_DEV_ENV_FLASH_BOOT_UBI \
+ "ubiattach=if test ${boot_bank} -eq 0; then; " \
+ "ubi part " CONFIG_KM_UBI_PARTITION_NAME_BOOT "; else; "\
+ "ubi part " CONFIG_KM_UBI_PARTITION_NAME_APP "; fi\0"
+#endif /* CONFIG_KM_UBI_PARTITION_NAME_APP */
#define xstr(s)str(s)
#define str(s) #s
@@ -173,7 +190,7 @@
" console=" CONFIG_KM_CONSOLE_TTY ",${baudrate}"\
" mem=${kernelmem} init=${init}"\
" phram.phram=phvar,${varaddr}," xstr(CONFIG_KM_PHRAM) \
- " ubi.mtd=" CONFIG_KM_UBI_LINUX_MTD_NAME " "\
+ " " CONFIG_KM_UBI_LINUX_MTD " " \
CONFIG_KM_DEF_BOOT_ARGS_CPU \
"\0"\
"addpanic=" \
@@ -199,10 +216,9 @@
#define CONFIG_KM_DEF_ENV_FLASH_BOOT \
"cramfsaddr=" xstr(CONFIG_KM_CRAMFS_ADDR) "\0" \
"cramfsloadkernel=cramfsload ${load_addr_r} uImage\0" \
- "ubiattach=ubi part " CONFIG_KM_UBI_PARTITION_NAME "\0" \
"ubicopy=ubi read "xstr(CONFIG_KM_CRAMFS_ADDR) \
" bootfs${boot_bank}\0" \
- ""
+ CONFIG_KM_DEV_ENV_FLASH_BOOT_UBI
/*
* constants
diff --git a/include/configs/km/km83xx-common.h
b/include/configs/km/km83xx-common.h
index 06ecb8a..2c266fa 100644
--- a/include/configs/km/km83xx-common.h
+++ b/include/configs/km/km83xx-common.h
@@ -15,13 +15,18 @@
#include "keymile-common.h"
#include "km-powerpc.h"
-#define MTDIDS_DEFAULT "nor0=boot"
-#define MTDPARTS_DEFAULT "mtdparts=" \
+#ifndef MTDIDS_DEFAULT
+# define MTDIDS_DEFAULT"nor0=boot"
+#endif /* MTDIDS_DEFAULT */
+
+#ifndef
[U-Boot] [PATCH 5/6] powerpc/83xx: add kmcoge5ne board support
This board is a MPC8360 board. Two flashes are present
a NOR flash were u-boot and the u-boot environment is stored
and a NAND flash for the application code. This board has 512MB
SDRAM.
Additionaly we introduce a common km8360.h file and convert kmeter1 to
use this.
Signed-off-by: Holger Brunck
Signed-off-by: Christian Herzig
cc: Kim Phillips
cc: Valentin Longchamp
cc: Gerlando Falauto
cc: Heiko Schocher
---
MAINTAINERS|4 +
board/keymile/km83xx/km83xx.c |2 +-
boards.cfg |3 +-
include/configs/km/km83xx-common.h |2 +
include/configs/km8360.h | 281
include/configs/kmeter1.h | 172 --
6 files changed, 290 insertions(+), 174 deletions(-)
create mode 100644 include/configs/km8360.h
delete mode 100644 include/configs/kmeter1.h
diff --git a/MAINTAINERS b/MAINTAINERS
index 46f63a0..4ccb5d1 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -66,6 +66,10 @@ Oliver Brown
gw8260 MPC8260
+Holger Brunck
+
+ kmcoge5ne MPC8360
+
Cyril Chemparathy
tnetv107x_evm tnetv107x
diff --git a/board/keymile/km83xx/km83xx.c b/board/keymile/km83xx/km83xx.c
index c3a05e6..1043ccd 100644
--- a/board/keymile/km83xx/km83xx.c
+++ b/board/keymile/km83xx/km83xx.c
@@ -32,7 +32,7 @@
const qe_iop_conf_t qe_iop_conf_tab[] = {
/* port pin dir open_drain assign */
-#if defined(CONFIG_KMETER1)
+#if defined(CONFIG_MPC8360)
/* MDIO */
{0, 1, 3, 0, 2}, /* MDIO */
{0, 2, 1, 0, 1}, /* MDC */
diff --git a/boards.cfg b/boards.cfg
index f7ec9a3..bb44120 100644
--- a/boards.cfg
+++ b/boards.cfg
@@ -607,7 +607,8 @@ MPC8360ERDK_66 powerpc mpc83xx
mpc8360erdk freesca
MPC837XEMDS powerpc mpc83xx mpc837xemds
freescale - MPC837XEMDS
MPC837XEMDS_HOST powerpc mpc83xx mpc837xemds
freescale - MPC837XEMDS:PCI
MPC837XERDB powerpc mpc83xx mpc837xerdb
freescale
-kmeter1 powerpc mpc83xx km83xx
keymile
+kmcoge5nepowerpc mpc83xx km83xx
keymile- km8360:KMCOGE5NE
+kmeter1 powerpc mpc83xx km83xx
keymile- km8360:KMETER1
MERGERBOXpowerpc mpc83xx mergerbox
matrix_vision
MVBLM7 powerpc mpc83xx mvblm7
matrix_vision
SIMPC8313_LP powerpc mpc83xx simpc8313
sheldon- SIMPC8313:NAND_LP
diff --git a/include/configs/km/km83xx-common.h
b/include/configs/km/km83xx-common.h
index 2c266fa..877d841 100644
--- a/include/configs/km/km83xx-common.h
+++ b/include/configs/km/km83xx-common.h
@@ -54,6 +54,8 @@
*/
#define CONFIG_SYS_DDR_BASE0x /* DDR is system memory */
#define CONFIG_SYS_SDRAM_BASE CONFIG_SYS_DDR_BASE
+#define CONFIG_SYS_SDRAM_BASE2 (CONFIG_SYS_SDRAM_BASE + 0x1000) /* +256M */
+
#define CONFIG_SYS_DDR_SDRAM_BASE CONFIG_SYS_DDR_BASE
#define CONFIG_SYS_DDR_SDRAM_CLK_CNTL (DDR_SDRAM_CLK_CNTL_SS_EN | \
DDR_SDRAM_CLK_CNTL_CLK_ADJUST_05)
diff --git a/include/configs/km8360.h b/include/configs/km8360.h
new file mode 100644
index 000..230b054
--- /dev/null
+++ b/include/configs/km8360.h
@@ -0,0 +1,281 @@
+/*
+ * (C) Copyright 2012
+ * Holger Brunck, Keymile GmbH Hannover,
+ * Christian Herzig, Keymile AG Switzerland,
+ *
+ * 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.
+ */
+
+#ifndef __CONFIG_H
+#define __CONFIG_H
+
+/* KMBEC FPGA (PRIO) */
+#define CONFIG_SYS_KMBEC_FPGA_BASE 0xE800
+#define CONFIG_SYS_KMBEC_FPGA_SIZE 64
+
+#if defined CONFIG_KMETER1
+#define CONFIG_HOSTNAMEkmeter1
+#define CONFIG_KM_BOARD_NAME "kmeter1"
+#define CONFIG_KM_DEF_NETDEV "netdev=eth2\0"
+#elif defined CONFIG_KMCOGE5NE
+#define CONFIG_HOSTNAMEkmcoge5ne
+#define CONFIG_KM_BOARD_NAME "kmcoge5ne"
+#define CONFIG_KM_DEF_NETDEV "netdev=eth1\0"
+#define CONFIG_CMD_NAND
+#define CONFIG_NAND_KMETER1
+#define CONFIG_SYS_MAX_NAND_DEVICE 1
+#define NAND_MAX_CHIPS 1
+#define CONFIG_SYS_NAND_BASE CONFIG_SYS_KMBEC_FPGA_BASE /* PRIO_BASE_ADDRESS */
+
+#define CONFIG_KM_UBI_PARTITION_NAME_BOOT "ubi0"
+#define CONFIG_KM_UBI_PARTITION_NAME_APP "ubi1"
+#define MTDIDS_DEFAULT "nor0=boot,nand0=app"
+
+#define MTDPARTS_DEFAULT "mtdparts=" \
+ "boot:"
[U-Boot] [PATCH 2/6] powerpc83xx/km: lock the window size to 2GiB befor fixing sdram size
From: Christian Herzig If the ram size isn't locked to 2GiB, the get_ram_size() may hang up. Signed-off-by: Christian Herzig cc: Kim Phillips cc: Valentin Longchamp cc: Gerlando Falauto Signed-off-by: Holger Brunck --- board/keymile/km83xx/km83xx.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/board/keymile/km83xx/km83xx.c b/board/keymile/km83xx/km83xx.c index 16ae2e4..c3a05e6 100644 --- a/board/keymile/km83xx/km83xx.c +++ b/board/keymile/km83xx/km83xx.c @@ -204,7 +204,7 @@ int fixed_sdram(void) u32 ddr_size_log2; out_be32(&im->sysconf.ddrlaw[0].ar, (LAWAR_EN | 0x1e)); - out_be32(&im->ddr.csbnds[0].csbnds, CONFIG_SYS_DDR_CS0_BNDS); + out_be32(&im->ddr.csbnds[0].csbnds, (CONFIG_SYS_DDR_CS0_BNDS) | 0x7f); out_be32(&im->ddr.cs_config[0], CONFIG_SYS_DDR_CS0_CONFIG); out_be32(&im->ddr.timing_cfg_0, CONFIG_SYS_DDR_TIMING_0); out_be32(&im->ddr.timing_cfg_1, CONFIG_SYS_DDR_TIMING_1); -- 1.7.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 6/6] MAINTAINERS: cleanup for keymile boards
Signed-off-by: Holger Brunck cc: Kim Phillips cc: Valentin Longchamp cc: Gerlando Falauto cc: Heiko Schocher --- MAINTAINERS |8 +++- 1 files changed, 3 insertions(+), 5 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 4ccb5d1..28244f6 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -68,7 +68,10 @@ Oliver Brown Holger Brunck + kmeter1 MPC8360 kmcoge5ne MPC8360 + tuge1 MPC8321 + tuxx1 MPC8321 Cyril Chemparathy @@ -435,7 +438,6 @@ Heiko Schocher charon MPC5200 ids8247 MPC8247 jupiter MPC5200 - kmeter1 MPC8360 kmsupx5 MPC8321 mgcoge MPC8247 mgcoge3ne MPC8247 @@ -447,10 +449,6 @@ Heiko Schocher uc101 MPC5200 ve8313 MPC8313 -Holger Brunck - tuge1 MPC8321 - tuxx1 MPC8321 - Peter De Schrijver ML2 PPC4xx -- 1.7.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/6] powerpc/83xx/km: use tuxx1.h for kmsupx5 target
This additional header is unneeded, we can use the tuxx1.h for this target. Signed-off-by: Holger Brunck cc: Kim Phillips cc: Valentin Longchamp cc: Gerlando Falauto cc: Heiko Schocher --- boards.cfg|8 ++-- include/configs/kmsupx5.h | 91 - include/configs/tuxx1.h | 22 ++ 3 files changed, 17 insertions(+), 104 deletions(-) delete mode 100644 include/configs/kmsupx5.h diff --git a/boards.cfg b/boards.cfg index 28cc345..f7ec9a3 100644 --- a/boards.cfg +++ b/boards.cfg @@ -608,15 +608,15 @@ MPC837XEMDS powerpc mpc83xx mpc837xemds freesca MPC837XEMDS_HOST powerpc mpc83xx mpc837xemds freescale - MPC837XEMDS:PCI MPC837XERDB powerpc mpc83xx mpc837xerdb freescale kmeter1 powerpc mpc83xx km83xx keymile -kmsupx5 powerpc mpc83xx km83xx keymile -suvd3powerpc mpc83xx km83xx keymile -tuge1powerpc mpc83xx km83xx keymile- tuxx1:KM_DISABLE_APP2 -tuxx1powerpc mpc83xx km83xx keymile MERGERBOXpowerpc mpc83xx mergerbox matrix_vision MVBLM7 powerpc mpc83xx mvblm7 matrix_vision SIMPC8313_LP powerpc mpc83xx simpc8313 sheldon- SIMPC8313:NAND_LP SIMPC8313_SP powerpc mpc83xx simpc8313 sheldon- SIMPC8313:NAND_SP TQM834x powerpc mpc83xx tqm834x tqc +suvd3powerpc mpc83xx km83xx keymile +tuge1powerpc mpc83xx km83xx keymile- tuxx1:KM_DISABLE_APP2,TUGE1 +tuxx1powerpc mpc83xx km83xx keymile +kmsupx5 powerpc mpc83xx km83xx keymile- tuxx1:KM_DISABLE_APP2,KMSUPX5 sbc8540 powerpc mpc85xx sbc8560 - - SBC8540 sbc8540_33 powerpc mpc85xx sbc8560 - - SBC8540 sbc8540_66 powerpc mpc85xx sbc8560 - - SBC8540 diff --git a/include/configs/kmsupx5.h b/include/configs/kmsupx5.h deleted file mode 100644 index b0dd88c..000 --- a/include/configs/kmsupx5.h +++ /dev/null @@ -1,91 +0,0 @@ -/* - * Copyright (C) 2006 Freescale Semiconductor, Inc. - *Dave Liu - * - * Copyright (C) 2007 Logic Product Development, Inc. - *Peter Barada - * - * Copyright (C) 2007 MontaVista Software, Inc. - *Anton Vorontsov - * - * (C) Copyright 2008 - * Heiko Schocher, DENX Software Engineering, h...@denx.de. - * - * (C) Copyright 2010 - * Lukas Roggli, KEYMILE Ltd, lukas.rog...@keymile.com - * - * (C) Copyright 2010-2011 - * Thomas Reufer, KEYMILE Ltd, thomas.reu...@keymile.com - * - * 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. - */ - -#ifndef __CONFIG_H -#define __CONFIG_H - -/* - * High Level Configuration Options - */ -#define CONFIG_KMSUPX5 1 /* Keymile PBEC8321 board specific */ -#define CONFIG_HOSTNAMEsupx5 -#define CONFIG_KM_BOARD_NAME "supx5" - -#defineCONFIG_SYS_TEXT_BASE0xF000 - -/* include common defines/options for all 8321 Keymile boards */ -#include "km/km8321-common.h" - -/* - * Init Local Bus Memory Controller: - * - * Bank Bus Machine PortSz Size Device - * --- --- -- - -- - * 2 Local GPCM8 bit 256MB LPXF - * 3 Local not used - * - */ - -/* - * LPXF on the local bus CS2 - * Window base at flash base - * Window size: 256 MB - */ - -#defineCONFIG_SYS_LPXF_BASE0xA000/* LPXF */ -#defineCONFIG_SYS_LPXF_SIZE256 /* Megabytes */ - -#define CONFIG_SYS_LBLAWBAR2_PRELIMCONFIG_SYS_LPXF_BASE -#define CONFIG_SYS_LBLAWAR2_PRELIM (LBLAWAR_EN | LBLAWAR_256MB) - -#define CONFIG_SYS_BR2_PRELIM (CONFIG_SYS_LPXF_BASE | \ -BR_PS_8 | \ -BR_MS_GPCM | \ -BR_V) - -#define CONFIG_SYS_OR2_PRELIM (MEG_TO_AM(CONFIG_SYS_LPXF_SIZE) | \ -OR_GPCM_CSNT | \ -OR_GPCM_ACS_DIV4 | \ -OR_GPCM_SCY_2 | \ -
[U-Boot] [PATCH 3/6] powerpc83xx/km: remove unneeded CONFIG_PCI for kmeter1
We don't use PCI on kmeter1 and never will be, so remove some unneeded code. Signed-off-by: Holger Brunck cc: Kim Phillips cc: Valentin Longchamp cc: Gerlando Falauto cc: Heiko Schocher --- include/configs/kmeter1.h | 15 --- 1 files changed, 0 insertions(+), 15 deletions(-) diff --git a/include/configs/kmeter1.h b/include/configs/kmeter1.h index 6b5a6fe..f816da2 100644 --- a/include/configs/kmeter1.h +++ b/include/configs/kmeter1.h @@ -160,20 +160,6 @@ #define CONFIG_SYS_DBAT5L (CONFIG_SYS_PAXE_BASE | BATL_PP_RW | \ BATL_CACHEINHIBIT | BATL_GUARDEDSTORAGE) #define CONFIG_SYS_DBAT5U CONFIG_SYS_IBAT5U - -#ifdef CONFIG_PCI -/* PCI MEM space: cacheable */ -#define CFG_IBAT6L (CFG_PCI1_MEM_PHYS | BATL_PP_RW | BATL_MEMCOHERENCE) -#define CFG_IBAT6U (CFG_PCI1_MEM_PHYS | BATU_BL_256M | BATU_VS | BATU_VP) -#define CFG_DBAT6L CFG_IBAT6L -#define CFG_DBAT6U CFG_IBAT6U -/* PCI MMIO space: cache-inhibit and guarded */ -#define CFG_IBAT7L (CFG_PCI1_MMIO_PHYS | BATL_PP_RW | \ -BATL_CACHEINHIBIT | BATL_GUARDEDSTORAGE) -#define CFG_IBAT7U (CFG_PCI1_MMIO_PHYS | BATU_BL_256M | BATU_VS | BATU_VP) -#define CFG_DBAT7L CFG_IBAT7L -#define CFG_DBAT7U CFG_IBAT7U -#else /* CONFIG_PCI */ #define CONFIG_SYS_IBAT6L (0) #define CONFIG_SYS_IBAT6U (0) #define CONFIG_SYS_IBAT7L (0) @@ -182,6 +168,5 @@ #define CONFIG_SYS_DBAT6U CONFIG_SYS_IBAT6U #define CONFIG_SYS_DBAT7L CONFIG_SYS_IBAT7L #define CONFIG_SYS_DBAT7U CONFIG_SYS_IBAT7U -#endif /* CONFIG_PCI */ #endif /* __CONFIG_H */ -- 1.7.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/6] updates for keymile powerpc83xx boards
- board support for the new kmcoge5ne board was added - other headerfiles are reworked and simplified - new feature for boards with two different flashtypes are added to km common code The patch for km/common changes also some lines in km_arm.h but because of some interdependencies it should go through the powepc83xx tree if possible. Andreas Huber (1): km/common: add support for second flash Christian Herzig (1): powerpc83xx/km: lock the window size to 2GiB befor fixing sdram size Holger Brunck (4): powerpc/83xx/km: use tuxx1.h for kmsupx5 target powerpc83xx/km: remove unneeded CONFIG_PCI for kmeter1 powerpc/83xx: add kmcoge5ne board support MAINTAINERS: cleanup for keymile boards MAINTAINERS | 12 +- board/keymile/km83xx/km83xx.c |4 +- boards.cfg | 11 +- include/configs/km/keymile-common.h | 34 +++- include/configs/km/km83xx-common.h | 13 ++- include/configs/km/km_arm.h | 15 +- include/configs/km8360.h| 281 +++ include/configs/kmeter1.h | 187 --- include/configs/kmsupx5.h | 91 --- include/configs/tuxx1.h | 22 ++- 10 files changed, 353 insertions(+), 317 deletions(-) create mode 100644 include/configs/km8360.h delete mode 100644 include/configs/kmeter1.h delete mode 100644 include/configs/kmsupx5.h ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Bug in cfb_console driver
On Wed, 21 Mar 2012 02:54:02 -0700 (PDT) Pali Rohár wrote: > On Saturday 10 March 2012 14:06:23 Pali Rohár wrote: > > On Tuesday 06 March 2012 10:25:57 Anatolij Gustschin wrote: > > > Hi, > > > > > > On Mon, 05 Mar 2012 11:42:13 +0100 > > > Pali Rohár wrote: > > > ... > > > > > > > Hi, thanks. If you need some more info write me. > > > > > > Can you please test with attached patch? Does it help to solve > > > your problem on N900? > > > > > > Thanks, > > > Anatolij > > > > Hi! This patch solving problem on my N900. > > Hi, I found a problem why code (without) this patch garbage display > output. I played with code in function video_draw_cursor and every > time when I tried to only read what is stored in *dest, on n900 > dispaly was show some random white or blue pixel. This code not > working on n900: > > static u8 foo; > ... > for (yfor (x u8 *destfoo *dest > } > } > > But if I commented assign foo > So I think that reading memory of framebuffer on n900 does not working > (it also write something somewhere...) What do you think, where can be > problem? I have a suspicion that your framebuffer area configured for the display controller is not exclusively used. In another email [1] to Marek I explained where the problem could be. Thanks, Anatolij [1] http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/123527/focus=127720 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] add new board nas62x0
> -Original Message- > From: Marek Vasut [mailto:ma...@denx.de] > Sent: 21 March 2012 16:27 > To: Prafulla Wadaskar > Cc: Luka Perkov; u-boot@lists.denx.de; drea...@doukki.net; Wolfgang > Denk > Subject: Re: [U-Boot] [PATCH v2] add new board nas62x0 > > Dear Prafulla Wadaskar, > > > > -Original Message- > > > From: Marek Vasut [mailto:ma...@denx.de] > > > Sent: 21 March 2012 15:33 > > > To: Prafulla Wadaskar > > > Cc: Luka Perkov; u-boot@lists.denx.de; drea...@doukki.net; > Wolfgang > > > Denk > > > Subject: Re: [U-Boot] [PATCH v2] add new board nas62x0 > > > > > > Dear Prafulla Wadaskar, > > > > ...snip... > > > > > > Hi Luka > > > > > > > > #1: Defining these values as 0x, indicates that all > GPIOs > > > > > > are > > > > > > > configured high by default. so this configuration solely depends > > > > > > upon your > > > > > > > board requirement. > > > > > > > > #2: on kirkwood, you should define CONFIG_SKIP_LOWLEVEL_INIT > since > > > > lowlevel_init is not needed on Kirkwood platforms. (ref: > > > > doc/README.kwbimage) > > > > > > Prafulla, you're then missing the fiddling with CPSR bits, which > might > > > be quite > > > necessary. > > > > Hi Marek. > > May be, may you please explain these bits? Or any pointers? Can't > these be > > addressed in kwimage.cfg? > > I have no idea, I'm no kirkwood expert. And about these bits, check > start.S, > what it does with them. Hi Marek, I have checked arc/arm/cpu/arm926ejs/start.S, and I didn't find any issue, lowlevel_init will be called from cpu_init_crit which should be okay, there is cache init related code in it, if that can be a problem then it should be kept out. And on Kirkwood, internal bootloader does the job of lowlevel_init prior to start uboot execution. Regards.. Prafulla . . . ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 05/14] cfb_console: Fix function console_scrollup
On Wed, 21 Mar 2012 12:32:16 +0100 Anatolij Gustschin wrote: ... > doesn't say much about the problem. If the GraphicDevice structure > returned by video_hw_init() is setup correctly, the scrolling should be > working fine. From the other patch [1] I can see that the structure I forgot to include a link [1] to the mentioned patch, sorry. Here it is: [1] http://patchwork.ozlabs.org/patch/137567/ Thanks, Anatolij ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] NAND: TI: fix warnings in omap_gpmc.c
The following warnings are reported for boards using SOFT ECC. omap_gpmc.c:33:30: warning: 'hw_nand_oob' defined but not used omap_gpmc.c:78:13: warning: 'omap_hwecc_init' defined but not used omap_gpmc.c:116:12: warning: 'omap_correct_data' defined but not used omap_gpmc.c:182:12: warning: 'omap_calculate_ecc' defined but not used omap_gpmc.c:208:13: warning: 'omap_enable_hwecc' defined but not used Signed-off-by: Stefano Babic Cc: Tom Rini Cc: Scott Wood --- drivers/mtd/nand/omap_gpmc.c |6 ++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/drivers/mtd/nand/omap_gpmc.c b/drivers/mtd/nand/omap_gpmc.c index 1dfe074..3a9baff 100644 --- a/drivers/mtd/nand/omap_gpmc.c +++ b/drivers/mtd/nand/omap_gpmc.c @@ -30,7 +30,10 @@ #include static uint8_t cs; +#if !defined(CONFIG_SPL_BUILD) || \ + (defined(CONFIG_SPL_BUILD) && !defined(CONFIG_SPL_NAND_SOFTECC)) static struct nand_ecclayout hw_nand_oob = GPMC_NAND_HW_ECC_LAYOUT; +#endif /* * omap_nand_hwcontrol - Set the address pointers corretly for the @@ -69,6 +72,8 @@ int omap_spl_dev_ready(struct mtd_info *mtd) } #endif +#if !defined(CONFIG_SPL_BUILD) || \ + (defined(CONFIG_SPL_BUILD) && !defined(CONFIG_SPL_NAND_SOFTECC)) /* * omap_hwecc_init - Initialize the Hardware ECC for NAND flash in * GPMC controller @@ -231,6 +236,7 @@ static void omap_enable_hwecc(struct mtd_info *mtd, int32_t mode) break; } } +#endif #ifndef CONFIG_SPL_BUILD /* -- 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 05/14] cfb_console: Fix function console_scrollup
Hi Marek, On Wed, 21 Mar 2012 11:20:38 +0100 Marek Vasut wrote: > Dear Anatolij Gustschin, > > > Hi, > > > > On Tue, 24 Jan 2012 15:28:02 +0100 > > > > Pali Rohár wrote: > > > * Use correct buffer size, do not damage screen output > > > > > > Signed-off-by: Pali Rohár > > > --- > > > > > > Changes since original version: > > >- Fixed commit message > > > > > > drivers/video/cfb_console.c |2 +- > > > 1 files changed, 1 insertions(+), 1 deletions(-) > > > > > > diff --git a/drivers/video/cfb_console.c b/drivers/video/cfb_console.c > > > index 904caf7..9092399 100644 > > > --- a/drivers/video/cfb_console.c > > > +++ b/drivers/video/cfb_console.c > > > @@ -701,7 +701,7 @@ static void console_scrollup(void) > > > > > > ); > > > > > > #else > > > > > > memcpyl(CONSOLE_ROW_FIRST, CONSOLE_ROW_SECOND, > > > > > > - CONSOLE_SCROLL_SIZE >> 2); > > > + CONSOLE_SCROLL_SIZE); > > > > NAK. This change is wrong. CONSOLE_SCROLL_SIZE is the size of the > > visible frame buffer - size of one row in bytes. We are using memcpyl() > > here, so the division by 4 (size >> 2) is correct. With your change > > we end up copying 4 times more data then needed. > > What kind of a problem are we fixing here? And what are the symptoms of it? Actually I'm not aware of any problem in current console_scrollup(). At least on two test setups with different framebuffer drivers and in one setup with HW accelerated scrolling I didn't see any problems with current code. The description in the commit log of this patch: "Use correct buffer size, do not damage screen output" doesn't say much about the problem. If the GraphicDevice structure returned by video_hw_init() is setup correctly, the scrolling should be working fine. From the other patch [1] I can see that the structure is setup as follows: /* fill in Graphic Device */ gdev.frameAdrs = 0x8f9c; gdev.winSizeX = 800; gdev.winSizeY = 480; gdev.gdfBytesPP = 2; gdev.gdfIndex = GDF_16BIT_565RGB; memset((void *)gdev.frameAdrs, 0, 0xbb800); return (void *) &gdev; Most likely using 0x8f9c as framebuffer address is the first _big_ problem. The framebuffer address range is not allocated properly and could be used by malloc area. The board has 256 MB of RAM starting at 0x8000, if U-Boot relocated itself to the upper RAM, the problems should be expected. AFAIK the N900 port doesn't use a framebuffer driver but probably uses pre-initialized display controller configuration. This should be fixed first. Thanks, Anatolij ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] README.mx28: add
On Tue, Mar 20, 2012 at 11:10 PM, Otavio Salvador wrote: > This is mainline a copy of README.m28 changing the references to the > mx28 counterpart but it makes easy for people looking for information > about mx28 based boards. > > Signed-off-by: Otavio Salvador > Cc: Fabio Estevam Acked-by: Fabio Estevam ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] add new board nas62x0
Dear Prafulla Wadaskar, > > -Original Message- > > From: Marek Vasut [mailto:ma...@denx.de] > > Sent: 21 March 2012 15:33 > > To: Prafulla Wadaskar > > Cc: Luka Perkov; u-boot@lists.denx.de; drea...@doukki.net; Wolfgang > > Denk > > Subject: Re: [U-Boot] [PATCH v2] add new board nas62x0 > > > > Dear Prafulla Wadaskar, > > ...snip... > > > > Hi Luka > > > > > > #1: Defining these values as 0x, indicates that all GPIOs > > > > are > > > > > configured high by default. so this configuration solely depends > > > > upon your > > > > > board requirement. > > > > > > #2: on kirkwood, you should define CONFIG_SKIP_LOWLEVEL_INIT since > > > lowlevel_init is not needed on Kirkwood platforms. (ref: > > > doc/README.kwbimage) > > > > Prafulla, you're then missing the fiddling with CPSR bits, which might > > be quite > > necessary. > > Hi Marek. > May be, may you please explain these bits? Or any pointers? Can't these be > addressed in kwimage.cfg? I have no idea, I'm no kirkwood expert. And about these bits, check start.S, what it does with them. > > Regards.. > Prafulla . . . Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] tegra: Specify debugging serial port at boot.
Hi Stephen, Wolfgang, On 03/21/2012 08:38 PM, Wolfgang Denk wrote: > Dear Simon Glass, > > In message > you > wrote: > We have standard ways of telling the Linux kernel what the console > port is - the "console=" boot argument has been working fine for many, > many years and many, many boards and systems. But Tegra needs to > invent it's own hackinsh implementation of putting special data in > some special registers. What a crap. This made me look into the x86 code - There is a command line option 'earlyprintk' which is available stupidly early (even the real-mode code and de-compressor have access to it) So I do now wonder why Tegra needs to do anything differently Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] add new board nas62x0
> -Original Message- > From: Marek Vasut [mailto:ma...@denx.de] > Sent: 21 March 2012 15:33 > To: Prafulla Wadaskar > Cc: Luka Perkov; u-boot@lists.denx.de; drea...@doukki.net; Wolfgang > Denk > Subject: Re: [U-Boot] [PATCH v2] add new board nas62x0 > > Dear Prafulla Wadaskar, ...snip... > > > > Hi Luka > > > > #1: Defining these values as 0x, indicates that all GPIOs > are > > configured high by default. so this configuration solely depends > upon your > > board requirement. > > > > #2: on kirkwood, you should define CONFIG_SKIP_LOWLEVEL_INIT since > > lowlevel_init is not needed on Kirkwood platforms. (ref: > > doc/README.kwbimage) > > Prafulla, you're then missing the fiddling with CPSR bits, which might > be quite > necessary. Hi Marek. May be, may you please explain these bits? Or any pointers? Can't these be addressed in kwimage.cfg? Regards.. Prafulla . . . ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 05/14] cfb_console: Fix function console_scrollup
Dear Anatolij Gustschin, > Hi, > > On Tue, 24 Jan 2012 15:28:02 +0100 > > Pali Rohár wrote: > > * Use correct buffer size, do not damage screen output > > > > Signed-off-by: Pali Rohár > > --- > > > > Changes since original version: > >- Fixed commit message > > > > drivers/video/cfb_console.c |2 +- > > 1 files changed, 1 insertions(+), 1 deletions(-) > > > > diff --git a/drivers/video/cfb_console.c b/drivers/video/cfb_console.c > > index 904caf7..9092399 100644 > > --- a/drivers/video/cfb_console.c > > +++ b/drivers/video/cfb_console.c > > @@ -701,7 +701,7 @@ static void console_scrollup(void) > > > > ); > > > > #else > > > > memcpyl(CONSOLE_ROW_FIRST, CONSOLE_ROW_SECOND, > > > > - CONSOLE_SCROLL_SIZE >> 2); > > + CONSOLE_SCROLL_SIZE); > > NAK. This change is wrong. CONSOLE_SCROLL_SIZE is the size of the > visible frame buffer - size of one row in bytes. We are using memcpyl() > here, so the division by 4 (size >> 2) is correct. With your change > we end up copying 4 times more data then needed. What kind of a problem are we fixing here? And what are the symptoms of it? > > Thanks, > Anatolij Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/2] OMAP3: mt_ventoux: sets its own mtdparts
Signed-off-by: Stefano Babic Cc: Tom Rini --- include/configs/mt_ventoux.h | 10 ++ 1 files changed, 10 insertions(+), 0 deletions(-) diff --git a/include/configs/mt_ventoux.h b/include/configs/mt_ventoux.h index 2034b59..5db6d57 100644 --- a/include/configs/mt_ventoux.h +++ b/include/configs/mt_ventoux.h @@ -40,6 +40,16 @@ #define CONFIG_SYS_PROMPT V_PROMPT /* + * Set its own mtdparts, different from common + */ +#undef MTDIDS_DEFAULT +#undef MTDPARTS_DEFAULT +#define MTDIDS_DEFAULT "nand0=omap2-nand.0" +#define MTDPARTS_DEFAULT "mtdparts=omap2-nand.0:512k(MLO)," \ + "1m(u-boot),256k(env1)," \ + "256k(env2),8m(ubisystem),-(rootfs)" + +/* * FPGA */ #define CONFIG_CMD_FPGA -- 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] OMAP3: mt_ventoux: updated timing for FPGA
Fix chipselect timing for FPGA
Signed-off-by: Stefano Babic
Cc: Tom Rini
---
board/teejet/mt_ventoux/mt_ventoux.h | 11 +--
1 files changed, 5 insertions(+), 6 deletions(-)
diff --git a/board/teejet/mt_ventoux/mt_ventoux.h
b/board/teejet/mt_ventoux/mt_ventoux.h
index 34c1ec5..9b2e43e 100644
--- a/board/teejet/mt_ventoux/mt_ventoux.h
+++ b/board/teejet/mt_ventoux/mt_ventoux.h
@@ -31,12 +31,11 @@ const omap3_sysinfo sysinfo = {
/* FPGA CS1 configuration */
#define FPGA_GPMC_CONFIG1 0x1200
-#define FPGA_GPMC_CONFIG2 0x00111a00
-#define FPGA_GPMC_CONFIG3 0x00010100
-#define FPGA_GPMC_CONFIG4 0x06041a04
-#define FPGA_GPMC_CONFIG5 0x0019101a
-#define FPGA_GPMC_CONFIG6 0x890503c0
-#define FPGA_GPMC_CONFIG7 0x0860
+#define FPGA_GPMC_CONFIG2 0x00161f00
+#define FPGA_GPMC_CONFIG3 0x00040400
+#define FPGA_GPMC_CONFIG4 0x120c1f08
+#define FPGA_GPMC_CONFIG5 0x001e161f
+#define FPGA_GPMC_CONFIG6 0x96080fcf
#define FPGA_BASE_ADDR 0x2000
--
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 v4] add new board nas62x0
> -Original Message-
> From: u-boot-boun...@lists.denx.de [mailto:u-boot-
> boun...@lists.denx.de] On Behalf Of Luka Perkov
> Sent: 21 March 2012 06:23
> To: u-boot@lists.denx.de
> Cc: drea...@doukki.net; gmbno...@gmail.com
> Subject: [U-Boot] [PATCH v4] add new board nas62x0
Please specify the patch header as Kirkwood: add NAS62x0 board support
This reflects on patch subject as patch for Kirkwood.
>
> Add support for new boards RaidSonic ICY BOX NAS6210 and NAS6220.
Add few links about board being supported here for quick reference
>
> Only difference between boards is number of SATA ports.
>
> Signed-off-by: Luka Perkov
> Signed-off-by: Gerald Kerma
> ---
>
V1, v2 change log missing ???
> Changes from version v3:
>
> * don't use utf8 for Geralds name
> * don't mix upper/lower case in kwbimage.cfg
> * fix prompt
>
> Found problems that should be looked at (this is not related with
> adding
> support for this board):
>
> * IB62x0_OE_LOW and IB62x0_OE_HIGH issue
> * CONFIG_SKIP_LOWLEVEL_INIT issue
>
> In separate patch I'll resend fix for CONFIG_SKIP_LOWLEVEL_INIT.
>
>
> MAINTAINERS |4 +
> board/Marvell/ib62x0/Makefile | 51 +++
This board does not belongs to Marvell it should be added to boards/
> board/Marvell/ib62x0/ib62x0.c | 114
> board/Marvell/ib62x0/ib62x0.h | 41 +
> board/Marvell/ib62x0/kwbimage.cfg | 167
Is this exactly copy paste from other available kwbimage.cfg, if yes then you
can reuse it, if no then what are the key changes w.r.to referred board?
> +++
> boards.cfg|2 +
> include/configs/ib62x0.h | 176
> +
> 7 files changed, 555 insertions(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 46f63a0..11d023e 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -782,6 +782,10 @@ Linus Walleij
> integratorapvarious
> integratorcpvarious
>
> +Luka Perkov
> +
> + ib62x0 ARM926EJS
It's better to add both boards being supported
> +
> Dave Peverley
>
> omap730p2 ARM926EJS
...snip...
> diff --git a/board/Marvell/ib62x0/ib62x0.c
> b/board/Marvell/ib62x0/ib62x0.c
> new file mode 100644
> index 000..e6853e7
> --- /dev/null
> +++ b/board/Marvell/ib62x0/ib62x0.c
> @@ -0,0 +1,114 @@
> +/*
> + * Copyright (C) 2011 Gerald Kerma
> + *
> + * Written-by: Gerald Kerma
> + *
> + * 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
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include "ib62x0.h"
> +
> +DECLARE_GLOBAL_DATA_PTR;
> +
> +int board_early_init_f(void)
> +{
> + /*
> + * default gpio configuration
> + * There are maximum 64 gpios controlled through 2 sets of
> registers
> + * the below configuration configures mainly initial LED status
> + */
> + kw_config_gpio(IB62x0_OE_VAL_LOW,
> + IB62x0_OE_VAL_HIGH,
> + IB62x0_OE_LOW, IB62x0_OE_HIGH);
> +
> + /* Multi-Purpose Pins Functionality configuration */
> + u32 kwmpp_config[] = {
> + MPP0_NF_IO2,
> + MPP1_NF_IO3,
> + MPP2_NF_IO4,
> + MPP3_NF_IO5,
> + MPP4_NF_IO6,
> + MPP5_NF_IO7,
> + MPP6_SYSRST_OUTn,
> + MPP7_GPO,
> + MPP8_UART0_RTS,
> + MPP9_UART0_CTS,
> + MPP10_UART0_TXD,
> + MPP11_UART0_RXD,
> + MPP12_SD_CLK,
> + MPP13_SD_CMD,
> + MPP14_SD_D0,
> + MPP15_SD_D1,
> + MPP16_SD_D2,
> + MPP17_SD_D3,
> + MPP18_NF_IO0,
> + MPP19_NF_IO1,
> + MPP20_GPIO,
> + MPP21_GPIO,
> + MPP22_GPIO, /* Power LED red */
> + MPP23_GPIO,
> + MPP24_GPIO,
> + MPP25_GPIO, /* Power LED green */
> + MPP26_GPIO,
> + MPP27_GPIO, /* USB transfer LED */
> + MPP28_GPIO, /* Reset button */
> + MPP29_TSMP9,/* USB Copy button */
> + MPP30
Re: [U-Boot] [PATCH v2] add new board nas62x0
Dear Prafulla Wadaskar, > > -Original Message- > > From: Marek Vasut [mailto:ma...@denx.de] > > Sent: 21 March 2012 12:52 > > To: Luka Perkov > > Cc: u-boot@lists.denx.de; drea...@doukki.net; Wolfgang Denk; Prafulla > > Wadaskar > > Subject: Re: [U-Boot] [PATCH v2] add new board nas62x0 > > > > Dear Luka Perkov, > > > > > Hi Marek, > > ...snip... > > > > > > This is my proposal - I'll resend v4 and it should be ok to > > > > commit > > > > > > > without fixes for: > > > > > 1) IB62x0_OE_LOW and IB62x0_OE_HIGH > > > > > 2) CONFIG_SKIP_LOWLEVEL_INIT > > > > > 3) ifdef indentation > > > > > > > > > > Because fixing the 1) and 2) is more than adding support for > > > > this new > > > > > > > board, and if it was in the same patch I would need to separate > > > > it. > > > > > > > That is a different issue. > > > > > > > > You can wait for Prafulla with #1 and #2, also for #2 check my > > > > comment. > > > > > > But we have two bugs going on for granted here at least and > > > > they're not > > > > > > your boards fault. On the other hand, it'd be cool if you could > > > > fix them > > > > > > prior to adding your board ;-) > > Hi Luka > > #1: Defining these values as 0x, indicates that all GPIOs are > configured high by default. so this configuration solely depends upon your > board requirement. > > #2: on kirkwood, you should define CONFIG_SKIP_LOWLEVEL_INIT since > lowlevel_init is not needed on Kirkwood platforms. (ref: > doc/README.kwbimage) Prafulla, you're then missing the fiddling with CPSR bits, which might be quite necessary. > > Regards.. > Prafulla . . . Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
