June 2014 - U-Boot

[U-Boot] Some Driver Model Ponderings
by Jon Loeliger 03 Jun '14

03 Jun '14

Hi U-Booters, Over the past few days, I had an off-line conversation with Simon Glass on the topic of the Driver Model. At his request, I've edited that conversation into this piece of email for the U-Boot List in the hopes that others in the community might also benefit. Already, some documentation patches have been offered as a result. http://patchwork.ozlabs.org/patch/352165/ But try to follow along. This is a conversation that occured over several back-and-forth pieces of email. I've edited and spliced. Hopefully, all the important pieces and parts are present without offense or malice. I start with the plea: Hi Simon, I write to you directly in an effort to A) Get a new GPIO driver into U-Boot using the new Driver Model B) Hopefully answer many lingering questions rapidly the background: Backing up a half step now... I need a PL061 ARM GPIO driver. I have exactly one GPIO I need to drive. But I have 7 GPIO blocks of 8 bits each. Rather than just hacking in yet another GPIO hackery into the general U-Boot fray, I thought I'd try the new driver model approach. So I think I want, and have written, a simple PL061 driver that fits these standard operations: static const struct dm_gpio_ops gpio_pl061_ops = { .request = pl061_gpio_request, .free = pl061_gpio_free, .direction_input = pl061_gpio_direction_input, .direction_output = pl061_gpio_direction_output, .get_value = pl061_gpio_get_value, .set_value = pl061_gpio_set_value, .get_state = pl061_gpio_get_state, }; Each of those routines takes a struct device that is mapped into an instance of the struct pl061_priv like so: struct pl061_priv *priv = dev_get_priv(dev); My priv structure is this: struct pl061_priv { u32 regs; /* GPIO bit-masked I/O space, controller */ u32 pad_regs; /* Pad control */ u32 gpio_base; /* GPIO range implemented by this device. */ u32 gpio_count; }; Now, I want to build up 7 of these with different bases for the 'regs', and different segments of the global linear GPIO space, 8-bits apiece. I am resonably convinced that the UCLASS_GPIO is going to help me do this. And is supposed to. It is some combination of the probe, bind, setup that I am not quite understanding yet. At this point, Simon states that another reference implementation has been pushed: I just pushed us-gpioc to http://git.denx.de/u-boot-x86.git which includes another conversion - drivers/gpio/s5p_gpio.c. It might be a bit closer to what you need. So, my UCLASS related questions haven't all been answered yet, but I also had questions about the relationships between the various bits of data along the way: uc_priv, platdata, priv: I'm not quite understanding the relationship of my "pl061_priv" data to the so-called platdata. Simon clarifies that: priv is your device's private data, used while the device is running (i.e. it is set up when the device is probed, and deleted when the device is removed) platdata is like Linux platform data. It provides the information needed to start up the device - like its register addresses or configuration options. I make two observations about those two paragraphs that then go on to cause a new documentation patch to be submitted. My first observation is that nowhere in the as-yet-written documentation abou the Driver Model is there any statement about the lifetime of the data pieces. Until that first paragraph. So I ask for more complete data-lifetime documentation. Secondly, I also observe that there is no data-flow documented. What is the sequence of data as it transitions through the various bind, probe, use, and release phases? Simon offers to document some data-lifetime, but quotes some existing platdata documentation too: " platdata (data which tells the driver how to operate on a particular platform)" Which just sets me off: This is *exactly* the wording I am arguing against. :-) That uses the same word to define the word. We need *other* words to describe what is meant by "platform data" in this context. Something like what you wrote in the mail to me: Examples of platform data might include: - the base address of the IP blocks register space - configuration options - board-level physical switch settings - something else obvious - when using DTS, data parsed out of the device node And perhaps a description of why it is needed in the first place: The device driver needs instance data for about a device's running state but may not be able to determine it. The platform data convey's the specific device setup data to an instance of the private device driver data that it will not otherwise be able to determine on its own. Ultimately, all that crap ends up in a pretty good doc patch! Anyway, from my original piece of mail, I ramble on: And I'm not understanding how I get my uc_priv for GPIOs to do the glue layer for what I need. And then when I think I get it, I see that after the bind step, all the GPIOs get renumbered! Why? I think I wanted to manually set those up directly myself. And, furthermore, since I really only have *one* GPIO I need to manipulate, I don't really need to instantiate all 7 instance, but just the one instance that holds the one GPIO pin I need. (Which happens to be in Bank 3.) Simon replies: The renumbering is done by the uclass. Provided that you set up you devices correctly this should just work, and will give you the numbering you wanted anyway. I think this issue of renumbering lingers and needs to be addressed. I'm not happy with the renumbering, so I push back: I don't want a renumbering. I want to be able to declare *just* the one GPIO I need. It happens to be in bank 3 to handle the global GPIO space 24 through 31. I need GPIO 31. But if the renumbering happens, it will need 0 -7, 8-15, 16-23 in the uclist prior to bank 3 for GPIOs 24-31. I want one uclass list item to hold the one GPIO bank that I need for the range 24-31. But I *also* want the ability to allow a future GPIO bank addition to seemlessly fit into the list for bank 6 when I need to add a GPIO from that bank too. The uclass should happily handle a sparse representation of the list of banks and global GPIO ranges. The thing stopping that is willie-nillie renumbering that isn't even necessary in the first place. If something needs to renumber, or for that matter, renumber according to a *different* scheme, why not make an optional uclass call-out function for "post-processing" and identify where its lifetime and sequencing it takes place. Simon offers: Well that's the way it works at present. I'm not sure why you wouldn't just support all the GPIOs from the start - that way you can upstream the code! Also note that you can give GPIOs bank names A, B, C, D, etc. which might help you. Which again, just torques my nipples. So I rant: Wow. Seriously? I don't even know where to begin with that response. This isn't a matter of upstreaming. I get that. This isn't about upstreaming. And upstreaming should never be the justification for leaving bad code design in place. In fact, this is exactly the opposite reasoning at work here. That is, I'm trying to get this driver upstreamed (said that from the onset of this discussion), but the renumbering behind my back will get in the way. This is a problem with the code performing totally unexpected behavior in a non-obvious, behind your back and broken way. Let's try an analogy with the Linux Kernel IRQ scheme. You might think of this UCLASS GPIO scheme as being quite similar to the linear mapping space of the irqchips. I set up a series of small IRQ IP blocks that handle ranges of 32 IRQs, which in turn are mapped onto a larger, global space of IRQs maintained by the Linux Kernel. If I set up a series of IRQ blocks, mapping each one to IRQs: Bank 0 is IRQ 64-95 Bank 1 is IRQ 0-31 Bank 2 is IRQ 32-63 and as I finished the last registration of the irqchip the kernel came along and remapped them behind my back as this: Bank 0 is IRQ 0-31 Bank 1 is IRQ 32-63 Bank 2 is IRQ 64-95 there would be hell to pay! So what the kernel did was provide a non-static mapping for the IRQs and irqchips. They allocatge the IRQs on the fly and allow each irqchip to make its own mapping. That way they never have to worry about re-organizing the global IRQ space, and never have to worry about the individual irqchip space needing to be shuffled as well. I assume you can see where I am headed here now. The problem with our proposed DM for GPIOs is that the global space is a fixed linear space. You have to honor the original registration contract when the uc_privs were created and filled in. If you want to *sort* the uc_priv blocks into a nicely orderd list so that, say, lookup operations might be faster, that is fine. Maybe even good. But you can't renumber the regions and ranges behind my back. Unless I am completely missing something here, doing so breaks the association between the UC_GPIO class range mappings and the corresponding base register of the IP block. So blah. We still need to address the capricious renumbering in the UC_GPIO space. Simon explains: Fair enough, but the GPIO uclass does not support dis-contiguous ordering. The numbering is owned by the board not the driver. For example, another board with the same SoC as you are using might have an I2C expander with 16 GPIOs. It might want these GPIOs to go first or last. Neither driver can determine the ordering. Also the intent is that you should use names in your U-Boot scripts. I'm not sold here yet. Perhaps we are talking past each other here. The GPIO class *could* support both discontinguous and sparse sets. In fact it would if only they weren't renumbered capriciously. My original confusion continues with so many "So, ..." issues: So, I saw your patch for the tegra GPIO conversion. Well timed! But it leaves me a bit baffled due to your apparent two-layers of PORTs and BANKS, and plat data. Some of which I don't think I should need. (?) So, I read through your gpio_tegra_bind(), and I don't understand what the "parent" device is. Where'd that come from? Who called this with what arguemnt? All leading to what is really happening in that device_bind() call? Simon says(1): The parent device is empty - it has no actual GPIOs, but is just a parent for all the real GPIOs devices. Driver model supports child devices. I'm still baffled on the "artificial parent" issue: Yes, I get that. And an I2C bus might have a I2C MUX device in the mix as well, and etc. And a DMA controller might have N sub-channel devices, etc. I don't understand how you are creating and organizing what should be (perhaps only in my case) just a list of 7 UC_GPIO nodes. I think the UC_CLASS for GPIOs has 7 allocated uc_priv instances in a list, one for each of my 7 banks of GPIOs. There is no hierarchy needed anywhere here, right? It looks to me like you have an extra UC_GPIO node, with no actual {uc_priv->gpio_base, ->gpio_count} set on it, so that it just occupies an extra instance on the UC_CLASS UC_GPIO list. And, I think, the only reason for that node is to house a platdata structure that has a parent base register. (Which, in the case of the s5p GPIO code you pointed me toward, baffles me a bit: I expected to see the base reg for each block parsed out of the DTS node for that block. Instead it looks like they are formed by doing the "bank++" to step through large register block structures for each bank. Urg.) Simon confirms my interpretation and the "bank++" approach, but unfortunately doesn't explain either. Yes that's right - it is just a parent device, with no actual GPIOs in it. and: That's the way the hardware is implemented on Exynos (and Tegra BTW). Hrm. Meanwhile, another "So,..." issue from my original mail: So, where did I get multiple uc_priv structures? One for each of my needed 7 instances? Do I allocate them in a bind function? I thought I wanted something like this, but I need one uc_priv for each instance still: int gpio_pl061_bind(struct device *dev) { struct gpio_dev_priv *uc_priv = dev->uclass_priv; int bank; for (bank = 0; bank < RAPID_N_GPIO_BANKS; ++bank) { /* Is uc_priv allocated here? */ uc_priv->gpio_base = bank * PL061_GPIOS_PER_BANK; uc_priv->gpio_count = PL061_GPIOS_PER_BANK; } return 0; } Simon points out several flaws with my approach: dev->uclass_priv is allocated for you before probe() is called. bind just means that driver model knows about the device - it doesn't mean that it is ready for use yet. You mustn't touch uc_priv in the bind function since it doesn't exist yet. and notes that the two uc_priv-> assignments instead belong in the probe() function. I think I understand and write: OK, But then how does the probe code know what bank to operate on? And the answer to that now appears to be "via the platdata." Right? And who/where was platdata allocated and filled in? In the bind, right? So bind() first, get reg base and global GIO base. Fill those into plat data. Then probe() where plat-data is copied into both a newly allocated priv, and the uc_priv GPIO fields. I am not sure when or how the bind() function is called: Will this bind be called once, or somehow 7 times? And cryptically, Simon replies: Well if you call device_bind() you can create new devices, which is what the tegra/exynos drivers do. And I am now adding a bit of explanation about this comment that I think I have deduced after reading the as-yet-to-be-written new documentation patch that Simon will have submitted later.(2) Here's the unwritten thing: I think your driver bind() function is supposed to call the lower-layer device_bind(). Simon then adds: bind() creates the struct device. It puts in the platdata pointer if it has one (i.e. if there was a U_BOOT_DEVICE() declaration). For device tree, it doesn't do that - see ofdata_to_platdata. and offers a doc patch to clarify this some more. OK, so, on to compiling issues.... First off, it appears that I will need to define my new CONFIG_GPIO_PL061 to get my driver file. Good. Got that. And then also CONFIG_DM_GPIO so that I get the Driver Model GPIO uclass layer. Good. I want that generic mapping of global GPIO numbers into my specific device... Check. But then it wants me to also suddenly define CONFIG_SANDBOX_GPIO_COUNT. Whichi I think is broken. I should never have to define something for another configuration (sandbox). If I have to somehow accommodate some new unit testing scenario, that should be something *else* standalone. And somehow I am missing a bunch of symbols still too: uclass_get, uclass_first_device, dev_get_prand weirdly iv, all the sandbox GPIO functions too. Oh, right, I also, also need CONFIG_DM. Hrm. That causes list code to be compiled and it looks totally sloppy and has compilation errors all over it still. Still getting test/dm/gpio.o in the mix and likely shouldn't. And, about the time I sent that rambling series of issues, Simon was furiously developing this series of patches: Yes, this is a bug. You should apply the driver model patches from my tegra series v3, for example: http://patchwork.ozlabs.org/patch/347491/ And yes, applying the patch "dm: Allow driver model tests only for sandbox" was vastly helpful. Mid-conversation, I trump up a few new questions: - When in the overall U-Boot flow are the devices bound and subsequently probed to make them available? - The DTS file. I have a DTS that I am passing on to Linux *through* U-Boot on the bootz command line. Is the same DTS file that being used to setup and configure U-Boot now? Or does U-Boot have its *own* (perhaps different) DTS? Specifically, are the GPIO nodes in my Linux DTS file the *same* nodes that might now be probed by U-Boot? If so, then the compatibles have to agree. That is, I'll have to use "arm,pl061". This sort of note also needs to be present in the DM README. Simon responds: Yes you should use the same file. Perhaps README.fdt-control would be a good place for that. We want U-Boot to use the same bindings as Linux. But I think my point was missed. It shouldn't be "the same file" with "the same data". I think it should be the actual DTB as already stored in flash waiting to be handed off to Linux. I wrote: That's not what is happening, though. Yesterday I worked through the craziness that is CONFIG_OF_{EMBED,SEPARATE}. It caused me to create a duplicate DTS, totally different than the one that I pass to Linux already. My Linux DTB is over in my flash, in an area of memory that is perfectly accessible to U-Boot if it wanted to read it. But it thinks it can't. So I have an OF_EMBED or OF_SEPARATE choice. Either of those cause an entirely new copy of the DTS, located in the U-Boot source tree now, to be DTC'ed and glued to the u-boot image. I don't want that at all. And having now worked through the issues around CONFIG_OF_SEPARATE and CONFIG_OF_EMBED, I think there needs to be a third alternative that says something like CONFIG_OF_SHARED_IN_FLASH. Dunno. More work. I've also had some difficulty gettin the DTB to be parsed. Further investigation revealed that my DTB is being found and parsed, but that only the "top level" nodes are being used for "bind"operations. As my GPIO nodes are second-level, under an SOC node, they are not being found and bound. Again, more work there. I close with a plea: You know. :-) Any help for the weary? Thanks, jdl And so does Simon: It would be good to cc this to the list - please considering doing that so that everyone benefits. You are not missing anything obvious and I'm sure others will benefit from your efforts. Regards, Simon I offer to do the dirty work: Simon, thank you! This really helped me. I don't want to sign this address up on the U-Boot list, so I will cut-n-paste this onto my gmail address and post a *slightly* modified version to the list! And, with this mail, I have answered Simon's final plea: Let's move this discussion to the list, as the issues you raise above are much better discussed in public. Driver model is in the very early stages and others will have comments also. Regards, Simon Thanks, jdl (1) -- See what I did there? (2) -- Are you following my timeline still? :-)

2 1

Re: [U-Boot] (no subject)
by rajshekar_py＠yahoo.com 03 Jun '14

03 Jun '14

Hi! http://netreign.com/_redirect?wynymaq917558

1 0

[U-Boot] imx6 booting from NAND with bad block 0
by Andy Ng 03 Jun '14

03 Jun '14

I have an imx6 solo system and currently I am using the SD card to boot the u-boot. I would like to make it boot from NAND, but my first Block in NAND is a bad one. Do I need u-boot with NAND SPL support? Best regards Andy

2 1

[U-Boot] Standalone application on secondary cores
by Francesco Teodoro 02 Jun '14

02 Jun '14

I'm using a SABRE SD board (from Freescale) based on i.MX6 and the u-boot version is the 2014.04 one. What I've been trying to do is to activate the secondary cores so that I would be able to use them. First of all I've imported the commands cpu status/release/reset, then I checked if they were working in this way: U-boot > cpu 1 status (which gives as result: core1 disabled ...) U-boot > cpu 1 release 0x12000000 0 U-boot > cpu 1 status (which gives as result: core1 enabled ...) Next step was to run a standalone application on secondary cores. First I checked the hello_world application, but it seems that the serial debug for secondary cores is not set (but I'm not sure). So I wrote an application to check if I could get changes in memory. This is the simple application (I just modified the hello_world one): //standalone app #include <common.h> #include <exports.h> volatile int test[5]={1,2,3,4,5}; int hello_world () { int i; for (i=0; i<5; i++) { test[i] = -test[i]; } return (0); } First I used it on the boot core (core0) with the "go" command and with the "md" command I checked that the results were correct. Then I used the following command to run it on other cores (the application is at address 0x12000000): U-boot > cpu X release 0x12000000 0 But when I check with the "md" command, I can see that there are no changes in memory. What should I do to make it work? Am I missing something to set before running the application on other cores? I'm new to this subject so every suggestion would be appreciated. Thank you in advance.

2 1

[U-Boot] [PATCH] PPC4xx: Remove quad100hd board
by Wolfgang Denk 02 Jun '14

02 Jun '14

The quad100hd has been unmaintained and dead ever since it's been added some 6 years ago. Remove it. Also update README.scrapyard and insert some commit IDs for removed boards. Signed-off-by: Wolfgang Denk <wd(a)denx.de> Cc: Stefan Roese <sr(a)denx.de> Cc: Gary Jennejohn <gljennjohn(a)googlemail.com> --- board/quad100hd/Makefile | 8 -- board/quad100hd/nand.c | 53 --------- board/quad100hd/quad100hd.c | 73 ------------ boards.cfg | 1 - doc/README.scrapyard | 21 ++-- include/configs/quad100hd.h | 281 -------------------------------------------- 6 files changed, 12 insertions(+), 425 deletions(-) delete mode 100644 board/quad100hd/Makefile delete mode 100644 board/quad100hd/nand.c delete mode 100644 board/quad100hd/quad100hd.c delete mode 100644 include/configs/quad100hd.h diff --git a/board/quad100hd/Makefile b/board/quad100hd/Makefile deleted file mode 100644 index b65e5ad..0000000 --- a/board/quad100hd/Makefile +++ /dev/null @@ -1,8 +0,0 @@ -# -# (C) Copyright 2007 -# Stefan Roese, DENX Software Engineering, sr(a)denx.de. -# -# SPDX-License-Identifier: GPL-2.0+ -# - -obj-y = quad100hd.o nand.o diff --git a/board/quad100hd/nand.c b/board/quad100hd/nand.c deleted file mode 100644 index 47bbb6b..0000000 --- a/board/quad100hd/nand.c +++ /dev/null @@ -1,53 +0,0 @@ -/* - * (C) Copyright 2008 - * Gary Jennejohn, DENX Software Engineering GmbH, garyj(a)denx.de - * - * SPDX-License-Identifier: GPL-2.0+ - */ - -#include <common.h> -#include <config.h> -#if defined(CONFIG_CMD_NAND) -#include <asm/ppc4xx-gpio.h> -#include <asm/io.h> -#include <nand.h> - -/* - * hardware specific access to control-lines - */ -static void quad100hd_hwcontrol(struct mtd_info *mtd, - int cmd, unsigned int ctrl) -{ - struct nand_chip *this = mtd->priv; - - if (ctrl & NAND_CTRL_CHANGE) { - gpio_write_bit(CONFIG_SYS_NAND_CLE, !!(ctrl & NAND_CLE)); - gpio_write_bit(CONFIG_SYS_NAND_ALE, !!(ctrl & NAND_ALE)); - gpio_write_bit(CONFIG_SYS_NAND_CE, !(ctrl & NAND_NCE)); - } - - if (cmd != NAND_CMD_NONE) - writeb(cmd, this->IO_ADDR_W); -} - -static int quad100hd_nand_ready(struct mtd_info *mtd) -{ - return gpio_read_in_bit(CONFIG_SYS_NAND_RDY); -} - -/* - * Main initialization routine - */ -int board_nand_init(struct nand_chip *nand) -{ - /* Set address of hardware control function */ - nand->cmd_ctrl = quad100hd_hwcontrol; - nand->dev_ready = quad100hd_nand_ready; - nand->ecc.mode = NAND_ECC_SOFT; - /* 15 us command delay time */ - nand->chip_delay = 20; - - /* Return happy */ - return 0; -} -#endif /* CONFIG_CMD_NAND */ diff --git a/board/quad100hd/quad100hd.c b/board/quad100hd/quad100hd.c deleted file mode 100644 index bb14ca7..0000000 --- a/board/quad100hd/quad100hd.c +++ /dev/null @@ -1,73 +0,0 @@ -/* - * (C) Copyright 2008 - * Gary Jennejohn, DENX Software Engineering GmbH, garyj(a)denx.de. - * - * Based in part on board/icecube/icecube.c from PPCBoot - * (C) Copyright 2003 Intrinsyc Software - * - * SPDX-License-Identifier: GPL-2.0+ - */ - -#include <common.h> -#include <command.h> -#include <malloc.h> -#include <environment.h> -#include <logbuff.h> -#include <post.h> - -#include <asm/processor.h> -#include <asm/io.h> -#include <asm/ppc4xx-gpio.h> - -DECLARE_GLOBAL_DATA_PTR; - -int board_early_init_f(void) -{ - /* taken from PPCBoot */ - mtdcr(UIC0SR, 0xFFFFFFFF); /* clear all ints */ - mtdcr(UIC0ER, 0x00000000); /* disable all ints */ - mtdcr(UIC0CR, 0x00000000); - mtdcr(UIC0PR, 0xFFFF7FFE); /* set int polarities */ - mtdcr(UIC0TR, 0x00000000); /* set int trigger levels */ - mtdcr(UIC0SR, 0xFFFFFFFF); /* clear all ints */ - mtdcr(UIC0VCR, 0x00000001); /* set vect base=0,INT0 highest priority */ - - mtdcr(CPC0_SRR, 0x00040000); /* Hold PCI bridge in reset */ - - return 0; -} - -/* - * Check Board Identity: - */ -int checkboard(void) -{ - char buf[64]; - int i = getenv_f("serial#", buf, sizeof(buf)); -#ifdef DISPLAY_BOARD_INFO - sys_info_t sysinfo; -#endif - - puts("Board: Quad100hd"); - - if (i > 0) { - puts(", serial# "); - puts(buf); - } - putc('\n'); - -#ifdef DISPLAY_BOARD_INFO - /* taken from ppcboot */ - get_sys_info(&sysinfo); - - printf("\tVCO: %lu MHz\n", sysinfo.freqVCOMhz); - printf("\tCPU: %lu MHz\n", sysinfo.freqProcessor / 1000000); - printf("\tPLB: %lu MHz\n", sysinfo.freqPLB / 1000000); - printf("\tOPB: %lu MHz\n", sysinfo.freqOPB / 1000000); - printf("\tEPB: %lu MHz\n", sysinfo.freqPLB / (sysinfo.pllExtBusDiv * - 1000000)); - printf("\tPCI: %lu MHz\n", sysinfo.freqPCI / 1000000); -#endif - - return 0; -} diff --git a/boards.cfg b/boards.cfg index 81e28ba..4297b98 100644 --- a/boards.cfg +++ b/boards.cfg @@ -1096,7 +1096,6 @@ Active powerpc ppc4xx - - - Active powerpc ppc4xx - - - korat - Larry Johnson <lrj(a)acm.org> Active powerpc ppc4xx - - - lwmon5 - Stefan Roese <sr(a)denx.de> Active powerpc ppc4xx - - - pcs440ep - Stefan Roese <sr(a)denx.de> -Active powerpc ppc4xx - - - quad100hd - Gary Jennejohn <garyj(a)denx.de> Active powerpc ppc4xx - - - sbc405 - - Active powerpc ppc4xx - - - sc3 - Heiko Schocher <hs(a)denx.de> Active powerpc ppc4xx - - - t3corp - Stefan Roese <sr(a)denx.de> diff --git a/doc/README.scrapyard b/doc/README.scrapyard index f9742e7..49cb4ca 100644 --- a/doc/README.scrapyard +++ b/doc/README.scrapyard @@ -11,15 +11,18 @@ easily if here is something they might want to dig for... Board Arch CPU Commit Removed Last known maintainer/contact ================================================================================================= -lubbock arm pxa - 2014-04-04 Kyle Harris <kharris(a)nexus-tech.net> -MOUSSE powerpc mpc824x - 2014-04-04 -rsdproto powerpc mpc8260 - 2014-04-04 -RPXsuper powerpc mpc8260 - 2014-04-04 -RPXClassic powerpc mpc8xx - 2014-04-04 -RPXlite powerpc mpc8xx - 2014-04-04 -genietv powerpc mpc8xx - 2014-04-04 -mbx8xx powerpc mpc8xx - 2014-04-04 -nx823 powerpc mpc8xx - 2014-04-04 +quad100hd powerpc ppc405ep - - Gary Jennejohn <gljennjohn(a)googlemail.com> +lubbock arm pxa 36bf57b 2014-04-18 Kyle Harris <kharris(a)nexus-tech.net> +EVB64260 powerpc mpc824x bb3aef9 2014-04-18 +MOUSSE powerpc mpc824x 03f2ecc 2014-04-18 +rsdproto powerpc mpc8260 8b043e6 2014-04-18 +RPXsuper powerpc mpc8260 0ebf5f5 2014-04-18 +RPXClassic powerpc mpc8xx 4fb3925 2014-04-18 +RPXlite powerpc mpc8xx 4fb3925 2014-04-18 +FADS powerpc mpc8xx aa6e1e4 2014-04-18 +genietv powerpc mpc8xx b8a49bd 2014-04-18 +mbx8xx powerpc mpc8xx d6b11fd 2014-04-18 +nx823 powerpc mpc8xx a146e8b 2014-04-18 idmr m68k mcf52x2 ba650e9b 2014-01-28 M5271EVB m68k mcf52x2 ba650e9b 2014-01-28 dvl_host arm ixp e317de6b 2014-01-28 Michael Schwingen <michael(a)schwingen.org> diff --git a/include/configs/quad100hd.h b/include/configs/quad100hd.h deleted file mode 100644 index e91e805..0000000 --- a/include/configs/quad100hd.h +++ /dev/null @@ -1,281 +0,0 @@ -/* - * (C) Copyright 2008 - * Gary Jennejohn, DENX Software Engineering GmbH, garyj(a)denx.de. - * - * SPDX-License-Identifier: GPL-2.0+ - */ - -/************************************************************************ - * quad100hd.h - configuration for Quad100hd board - ***********************************************************************/ -#ifndef __CONFIG_H -#define __CONFIG_H - -/*----------------------------------------------------------------------- - * High Level Configuration Options - *----------------------------------------------------------------------*/ -#define CONFIG_QUAD100HD 1 /* Board is Quad100hd */ -#define CONFIG_405EP 1 /* Specifc 405EP support*/ - -#define CONFIG_SYS_TEXT_BASE 0xFFFC0000 - -#define CONFIG_SYS_CLK_FREQ 33333333 /* external frequency to pll */ - -#define CONFIG_BOARD_EARLY_INIT_F 1 /* Call board_early_init_f */ - -#define PLLMR0_DEFAULT PLLMR0_266_133_66 /* no PCI */ -#define PLLMR1_DEFAULT PLLMR1_266_133_66 /* no PCI */ - -/* the environment is in the EEPROM by default */ -#define CONFIG_ENV_IS_IN_EEPROM -#undef CONFIG_ENV_IS_IN_FLASH - -#define CONFIG_PPC4xx_EMAC -#define CONFIG_HAS_ETH1 1 -#define CONFIG_MII 1 /* MII PHY management */ -#define CONFIG_PHY_ADDR 0x01 /* PHY address */ -#define CONFIG_SYS_RX_ETH_BUFFER 16 /* Number of ethernet rx buffers & descriptors */ -#define CONFIG_PHY_RESET 1 -#define CONFIG_PHY_RESET_DELAY 300 /* PHY RESET recovery delay */ - -/* - * Command line configuration. - */ -#include <config_cmd_default.h> - -#undef CONFIG_CMD_ASKENV -#undef CONFIG_CMD_CACHE -#define CONFIG_CMD_DHCP -#undef CONFIG_CMD_DIAG -#define CONFIG_CMD_EEPROM -#undef CONFIG_CMD_ELF -#define CONFIG_CMD_I2C -#undef CONFIG_CMD_IRQ -#define CONFIG_CMD_JFFS2 -#undef CONFIG_CMD_MII -#define CONFIG_CMD_NAND -#undef CONFIG_CMD_PING -#define CONFIG_CMD_REGINFO - -#undef CONFIG_WATCHDOG /* watchdog disabled */ - -/*----------------------------------------------------------------------- - * SDRAM - *----------------------------------------------------------------------*/ -/* - * SDRAM configuration (please see cpu/ppc/sdram.[ch]) - */ -#define CONFIG_SDRAM_BANK0 1 - -/* FIX! SDRAM timings used in datasheet */ -#define CONFIG_SYS_SDRAM_CL 3 /* CAS latency */ -#define CONFIG_SYS_SDRAM_tRP 20 /* PRECHARGE command period */ -#define CONFIG_SYS_SDRAM_tRC 66 /* ACTIVE-to-ACTIVE command period */ -#define CONFIG_SYS_SDRAM_tRCD 20 /* ACTIVE-to-READ delay */ -#define CONFIG_SYS_SDRAM_tRFC 66 /* Auto refresh period */ - -/* - * JFFS2 - */ -#define CONFIG_SYS_JFFS2_FIRST_BANK 0 -#ifdef CONFIG_SYS_KERNEL_IN_JFFS2 -#define CONFIG_SYS_JFFS2_FIRST_SECTOR 0 /* JFFS starts at block 0 */ -#else /* kernel not in JFFS */ -#define CONFIG_SYS_JFFS2_FIRST_SECTOR 8 /* block 0-7 is kernel (1MB = 8 sectors) */ -#endif -#define CONFIG_SYS_JFFS2_NUM_BANKS 1 - -/*----------------------------------------------------------------------- - * Serial Port - *----------------------------------------------------------------------*/ -#define CONFIG_CONS_INDEX 1 /* Use UART0 */ -#define CONFIG_SYS_NS16550 -#define CONFIG_SYS_NS16550_SERIAL -#define CONFIG_SYS_NS16550_REG_SIZE 1 -#define CONFIG_SYS_NS16550_CLK get_serial_clock() -#undef CONFIG_SYS_EXT_SERIAL_CLOCK /* external serial clock */ -#define CONFIG_SYS_BASE_BAUD 691200 -#define CONFIG_BAUDRATE 115200 - -/* The following table includes the supported baudrates */ -#define CONFIG_SYS_BAUDRATE_TABLE \ - {300, 600, 1200, 2400, 4800, 9600, 19200, 38400, 57600, 115200, 230400} - -/*----------------------------------------------------------------------- - * Miscellaneous configurable options - *----------------------------------------------------------------------*/ -#define CONFIG_SYS_LONGHELP /* undef to save memory */ -#if defined(CONFIG_CMD_KGDB) -#define CONFIG_SYS_CBSIZE 1024 /* Console I/O Buffer Size */ -#else -#define CONFIG_SYS_CBSIZE 256 /* Console I/O Buffer Size */ -#endif -#define CONFIG_SYS_PBSIZE (CONFIG_SYS_CBSIZE+sizeof(CONFIG_SYS_PROMPT)+16) /* Print Buffer Size */ -#define CONFIG_SYS_MAXARGS 16 /* max number of command args */ -#define CONFIG_SYS_BARGSIZE CONFIG_SYS_CBSIZE /* Boot Argument Buffer Size */ - -#define CONFIG_SYS_MEMTEST_START 0x0400000 /* memtest works on */ -#define CONFIG_SYS_MEMTEST_END 0x0C00000 /* 4 ... 12 MB in DRAM */ - -#define CONFIG_SYS_LOAD_ADDR 0x100000 /* default load address */ -#define CONFIG_SYS_EXTBDINFO 1 /* To use extended board_info (bd_t) */ - -#define CONFIG_LOADS_ECHO 1 /* echo on for serial download */ -#define CONFIG_SYS_LOADS_BAUD_CHANGE 1 /* allow baudrate change */ - -#define CONFIG_CMDLINE_EDITING 1 /* add command line history */ -#define CONFIG_LOOPW 1 /* enable loopw command */ -#define CONFIG_MX_CYCLIC 1 /* enable mdc/mwc commands */ -#define CONFIG_ZERO_BOOTDELAY_CHECK /* check for keypress on bootdelay==0 */ -#define CONFIG_VERSION_VARIABLE 1 /* include version env variable */ - -/*----------------------------------------------------------------------- - * I2C - *----------------------------------------------------------------------*/ -#define CONFIG_SYS_I2C -#define CONFIG_SYS_I2C_PPC4XX -#define CONFIG_SYS_I2C_PPC4XX_CH0 -#define CONFIG_SYS_I2C_PPC4XX_SPEED_0 400000 -#define CONFIG_SYS_I2C_PPC4XX_SLAVE_0 0x7F - -#define CONFIG_SYS_I2C_EEPROM_ADDR 0x50 /* base address */ -#define CONFIG_SYS_I2C_EEPROM_ADDR_LEN 2 /* bytes of address */ - -#define CONFIG_SYS_EEPROM_PAGE_WRITE_BITS 5 /* 8 byte write page size */ -#define CONFIG_SYS_EEPROM_PAGE_WRITE_DELAY_MS 10 /* and takes up to 10 msec */ -#define CONFIG_SYS_EEPROM_SIZE 0x2000 - -/*----------------------------------------------------------------------- - * Start addresses for the final memory configuration - * (Set up by the startup code) - * Please note that CONFIG_SYS_SDRAM_BASE _must_ start at 0 - */ -#define CONFIG_SYS_SDRAM_BASE 0x00000000 -#define CONFIG_SYS_FLASH_BASE 0xFFC00000 -#define CONFIG_SYS_MONITOR_LEN (256 * 1024) /* Reserve 256 kB for Monitor */ -#define CONFIG_SYS_MALLOC_LEN (128 * 1024) /* Reserve 128 kB for malloc() */ -#define CONFIG_SYS_MONITOR_BASE (CONFIG_SYS_TEXT_BASE) - -/* - * For booting Linux, the board info and command line data - * have to be in the first 8 MB of memory, since this is - * the maximum mapped by the Linux kernel during initialization. - */ -#define CONFIG_SYS_BOOTMAPSZ (8 << 20) /* Initial Memory map for Linux */ - -/*----------------------------------------------------------------------- - * FLASH organization - */ -#define CONFIG_SYS_FLASH_CFI /* The flash is CFI compatible */ -#define CONFIG_FLASH_CFI_DRIVER - -#define CONFIG_SYS_FLASH_BANKS_LIST { CONFIG_SYS_FLASH_BASE } - -#define CONFIG_SYS_MAX_FLASH_BANKS 1 /* max number of memory banks */ -#define CONFIG_SYS_MAX_FLASH_SECT 128 /* max number of sectors on one chip */ - -#define CONFIG_SYS_FLASH_ERASE_TOUT 120000 /* Timeout for Flash Erase (in ms) */ -#define CONFIG_SYS_FLASH_WRITE_TOUT 500 /* Timeout for Flash Write (in ms) */ - -#define CONFIG_SYS_FLASH_USE_BUFFER_WRITE 1 /* use buffered writes (20x faster) */ -#define CONFIG_SYS_FLASH_INCREMENT 0 /* there is only one bank */ - -#define CONFIG_SYS_FLASH_EMPTY_INFO /* print 'E' for empty sector on flinfo */ -#define CONFIG_SYS_FLASH_QUIET_TEST 1 /* don't warn upon unknown flash */ - -#ifdef CONFIG_ENV_IS_IN_FLASH -#define CONFIG_ENV_SECT_SIZE 0x10000 /* size of one complete sector */ -/* the environment is located before u-boot */ -#define CONFIG_ENV_ADDR (CONFIG_SYS_TEXT_BASE - CONFIG_ENV_SECT_SIZE) - -/* Address and size of Redundant Environment Sector */ -#define CONFIG_ENV_ADDR_REDUND (CONFIG_ENV_ADDR - CONFIG_ENV_SECT_SIZE) -#define CONFIG_ENV_SIZE_REDUND (CONFIG_ENV_SECT_SIZE) -#endif - -#ifdef CONFIG_ENV_IS_IN_EEPROM -#define CONFIG_ENV_SIZE 0x400 /* Size of Environment vars */ -#define CONFIG_ENV_OFFSET 0x00000000 -#define CONFIG_SYS_ENABLE_CRC_16 1 /* Intrinsyc formatting used crc16 */ -#endif - -/* partly from PPCBoot */ -/* NAND */ -#define CONFIG_NAND -#ifdef CONFIG_NAND -#define CONFIG_SYS_NAND_BASE 0x60000000 -#define CONFIG_SYS_NAND_CS 10 /* our CS is GPIO10 */ -#define CONFIG_SYS_NAND_RDY 23 /* our RDY is GPIO23 */ -#define CONFIG_SYS_NAND_CE 24 /* our CE is GPIO24 */ -#define CONFIG_SYS_NAND_CLE 31 /* our CLE is GPIO31 */ -#define CONFIG_SYS_NAND_ALE 30 /* our ALE is GPIO30 */ -#define CONFIG_SYS_MAX_NAND_DEVICE 1 - -#endif - -/*----------------------------------------------------------------------- - * Definitions for initial stack pointer and data area (in data cache) - */ -/* use on chip memory (OCM) for temperary stack until sdram is tested */ -/* see ./arch/powerpc/cpu/ppc4xx/start.S */ -#define CONFIG_SYS_TEMP_STACK_OCM 1 - -/* On Chip Memory location */ -#define CONFIG_SYS_OCM_DATA_ADDR 0xF8000000 -#define CONFIG_SYS_OCM_DATA_SIZE 0x1000 -#define CONFIG_SYS_INIT_RAM_ADDR CONFIG_SYS_OCM_DATA_ADDR /* inside of OCM */ -#define CONFIG_SYS_INIT_RAM_SIZE CONFIG_SYS_OCM_DATA_SIZE /* Size of used area in RAM */ - -#define CONFIG_SYS_GBL_DATA_OFFSET (CONFIG_SYS_INIT_RAM_SIZE - GENERATED_GBL_DATA_SIZE) -#define CONFIG_SYS_INIT_SP_OFFSET CONFIG_SYS_GBL_DATA_OFFSET - -/*----------------------------------------------------------------------- - * External Bus Controller (EBC) Setup - * Taken from PPCBoot board/icecube/icecube.h - */ - -/* see ./arch/powerpc/cpu/ppc4xx/cpu_init.c ./cpu/ppc4xx/ndfc.c */ -#define CONFIG_SYS_EBC_PB0AP 0x04002480 -/* AMD NOR flash - this corresponds to FLASH_BASE so may be correct */ -#define CONFIG_SYS_EBC_PB0CR 0xFFC5A000 -#define CONFIG_SYS_EBC_PB1AP 0x04005480 -#define CONFIG_SYS_EBC_PB1CR 0x60018000 -#define CONFIG_SYS_EBC_PB2AP 0x00000000 -#define CONFIG_SYS_EBC_PB2CR 0x00000000 -#define CONFIG_SYS_EBC_PB3AP 0x00000000 -#define CONFIG_SYS_EBC_PB3CR 0x00000000 -#define CONFIG_SYS_EBC_PB4AP 0x00000000 -#define CONFIG_SYS_EBC_PB4CR 0x00000000 - -/*----------------------------------------------------------------------- - * Definitions for GPIO setup (PPC405EP specific) - * - * Taken in part from PPCBoot board/icecube/icecube.h - */ -/* see ./arch/powerpc/cpu/ppc4xx/cpu_init.c ./cpu/ppc4xx/start.S */ -#define CONFIG_SYS_GPIO0_OSRL 0x55555550 -#define CONFIG_SYS_GPIO0_OSRH 0x00000110 -#define CONFIG_SYS_GPIO0_ISR1L 0x00000000 -#define CONFIG_SYS_GPIO0_ISR1H 0x15555445 -#define CONFIG_SYS_GPIO0_TSRL 0x00000000 -#define CONFIG_SYS_GPIO0_TSRH 0x00000000 -#define CONFIG_SYS_GPIO0_TCR 0xFFFF8097 -#define CONFIG_SYS_GPIO0_ODR 0x00000000 - -#if defined(CONFIG_CMD_KGDB) -#define CONFIG_KGDB_BAUDRATE 230400 /* speed to run kgdb serial port */ -#endif - -/* ENVIRONMENT VARS */ - -#define CONFIG_IPADDR 192.168.1.67 -#define CONFIG_SERVERIP 192.168.1.50 -#define CONFIG_GATEWAYIP 192.168.1.1 -#define CONFIG_NETMASK 255.255.255.0 -#define CONFIG_LOADADDR 300000 -#define CONFIG_BOOTDELAY 5 /* autoboot after 5 seconds */ - -/* pass open firmware flat tree */ -#define CONFIG_OF_LIBFDT 1 - -#endif /* __CONFIG_H */ -- 1.9.0

2 3

[U-Boot] [PATCH] mmc: add wrappers for MMC block_{read, write, erase}
by Steve Rae 02 Jun '14

02 Jun '14

Each wrapper function: - switches to the specified physical partition, then - performs the original function, and then - switches back to the original physical partition where the physical partition (aka HW partition) is 0=User, 1=Boot1, 2=Boot2, etc. Signed-off-by: Steve Rae <srae(a)broadcom.com> --- based on a discussion: http://lists.denx.de/pipermail/u-boot/2014-April/178171.html The original calling code is (for example): mmc->block_dev.block_read(dev_num, start, blkcnt, buffer) Therefore, these wrappers use the following naming convention: mmc_block_read_hwpart(dev_num, part_num, start, blkcnt, buffer) "hwpart" comes from: Stephen Warren <swarren(a)nvidia.com> drivers/mmc/Makefile | 1 + drivers/mmc/mmc_hwpart.c | 75 ++++++++++++++++++++++++++++++++++++++++++++++++ include/mmc.h | 10 +++++++ 3 files changed, 86 insertions(+) create mode 100644 drivers/mmc/mmc_hwpart.c diff --git a/drivers/mmc/Makefile b/drivers/mmc/Makefile index 4c6ab9e..04f87f9 100644 --- a/drivers/mmc/Makefile +++ b/drivers/mmc/Makefile @@ -11,6 +11,7 @@ obj-$(CONFIG_FSL_ESDHC) += fsl_esdhc.o obj-$(CONFIG_FTSDC010) += ftsdc010_mci.o obj-$(CONFIG_FTSDC021) += ftsdc021_sdhci.o obj-$(CONFIG_GENERIC_MMC) += mmc.o +obj-$(CONFIG_GENERIC_MMC) += mmc_hwpart.o obj-$(CONFIG_GENERIC_ATMEL_MCI) += gen_atmel_mci.o obj-$(CONFIG_MMC_SPI) += mmc_spi.o obj-$(CONFIG_ARM_PL180_MMCI) += arm_pl180_mmci.o diff --git a/drivers/mmc/mmc_hwpart.c b/drivers/mmc/mmc_hwpart.c new file mode 100644 index 0000000..1c29f8f --- /dev/null +++ b/drivers/mmc/mmc_hwpart.c @@ -0,0 +1,75 @@ +/* + * Copyright 2014 Broadcom Corporation. + * + * SPDX-License-Identifier: GPL-2.0+ + */ + +#include <mmc.h> + +static int switch_part(struct mmc *mmc, + int dev, + unsigned int chk_part_num, + unsigned int part_num) +{ + if (!mmc) + return -1; + + if (mmc->part_num != chk_part_num) { + if (mmc_switch_part(dev, part_num)) { + printf("MMC partition switch to %d failed [dev=%d]\n", + part_num, dev); + return -1; + } + } + return 0; +} + +unsigned long mmc_block_read_hwpart(int dev, + unsigned int part_num, + lbaint_t start, + lbaint_t blkcnt, + void *buffer) +{ + unsigned long rc = 0; + struct mmc *mmc = find_mmc_device(dev); + + if (switch_part(mmc, dev, part_num, part_num)) + return 0; + rc = mmc->block_dev.block_read(dev, start, blkcnt, buffer); + switch_part(mmc, dev, part_num, mmc->part_num); + + return rc; +} + +unsigned long mmc_block_write_hwpart(int dev, + unsigned int part_num, + lbaint_t start, + lbaint_t blkcnt, + const void *buffer) +{ + unsigned long rc = 0; + struct mmc *mmc = find_mmc_device(dev); + + if (switch_part(mmc, dev, part_num, part_num)) + return 0; + rc = mmc->block_dev.block_write(dev, start, blkcnt, buffer); + switch_part(mmc, dev, part_num, mmc->part_num); + + return rc; +} + +unsigned long mmc_block_erase_hwpart(int dev, + unsigned int part_num, + lbaint_t start, + lbaint_t blkcnt) +{ + unsigned long rc = -1; + struct mmc *mmc = find_mmc_device(dev); + + if (switch_part(mmc, dev, part_num, part_num)) + return -1; + rc = mmc->block_dev.block_erase(dev, start, blkcnt); + switch_part(mmc, dev, part_num, mmc->part_num); + + return rc; +} diff --git a/include/mmc.h b/include/mmc.h index a3a100b..4871c08 100644 --- a/include/mmc.h +++ b/include/mmc.h @@ -347,6 +347,16 @@ int mmc_rpmb_read(struct mmc *mmc, void *addr, unsigned short blk, unsigned short cnt, unsigned char *key); int mmc_rpmb_write(struct mmc *mmc, void *addr, unsigned short blk, unsigned short cnt, unsigned char *key); +/* Functions to read/write/erase from the specified HW partition */ +unsigned long mmc_block_read_hwpart(int dev, unsigned int part_num, + lbaint_t start, lbaint_t blkcnt, + void *buffer); +unsigned long mmc_block_write_hwpart(int dev, unsigned int part_num, + lbaint_t start, lbaint_t blkcnt, + const void *buffer); + +unsigned long mmc_block_erase_hwpart(int dev, unsigned int part_num, + lbaint_t start, lbaint_t blkcnt); /** * Start device initialization and return immediately; it does not block on * polling OCR (operation condition register) status. Then you should call -- 1.8.5

4 15

[U-Boot] [PATCH 0/9] Remove MPC82xx, MPC8xx Orphan boards
by Masahiro Yamada 02 Jun '14

02 Jun '14

The maintainers are no longer repsponding. These boards are so old that nobody would have motivation to maintain them. I built all the other boards. I confirmed there is no impact to the other boards. Apply Wolfgang's patch first: http://patchwork.ozlabs.org/patch/353935/ to avoid a conflict of doc/README.scrapyard. Masahiro Yamada (9): powerpc: adder: remove orphan board powerpc: mpc8260ads: remove orphan board powerpc: zpc1900: remove orphan board powerpc: rattler: remove orphan board powerpc: ispan: remove orphan board powerpc: ep8248: remove orphan board powerpc: kvme080: remove orphan board powerpc: debris: remove orphan board powerpc: hiddendragon: remove orphan board README | 8 - arch/powerpc/cpu/mpc8260/pci.c | 2 - arch/powerpc/cpu/mpc8260/start.S | 13 - arch/powerpc/include/asm/processor.h | 12 - board/adder/Makefile | 11 - board/adder/adder.c | 108 ----- board/adder/u-boot.lds | 79 ---- board/ep8248/Makefile | 8 - board/ep8248/ep8248.c | 254 ------------ board/etin/debris/Makefile | 8 - board/etin/debris/debris.c | 174 -------- board/etin/debris/flash.c | 705 -------------------------------- board/etin/debris/phantom.c | 301 -------------- board/etin/kvme080/Makefile | 8 - board/etin/kvme080/kvme080.c | 184 --------- board/etin/kvme080/multiverse.c | 184 --------- board/etin/kvme080/multiverse.h | 173 -------- board/freescale/mpc8260ads/Makefile | 8 - board/freescale/mpc8260ads/flash.c | 476 --------------------- board/freescale/mpc8260ads/mpc8260ads.c | 544 ------------------------ board/hidden_dragon/Makefile | 8 - board/hidden_dragon/README | 60 --- board/hidden_dragon/flash.c | 559 ------------------------- board/hidden_dragon/hidden_dragon.c | 85 ---- board/ispan/Makefile | 11 - board/ispan/ispan.c | 448 -------------------- board/rattler/Makefile | 8 - board/rattler/rattler.c | 215 ---------- board/zpc1900/Makefile | 8 - board/zpc1900/zpc1900.c | 288 ------------- boards.cfg | 27 -- doc/README.scrapyard | 9 + include/common.h | 2 - include/configs/Adder.h | 193 --------- include/configs/HIDDEN_DRAGON.h | 371 ----------------- include/configs/ISPAN.h | 330 --------------- include/configs/MPC8260ADS.h | 549 ------------------------- include/configs/Rattler.h | 279 ------------- include/configs/ZPC1900.h | 261 ------------ include/configs/debris.h | 443 -------------------- include/configs/ep8248.h | 253 ------------ include/configs/kvme080.h | 251 ------------ include/mpc8260.h | 4 - 43 files changed, 9 insertions(+), 7913 deletions(-) delete mode 100644 board/adder/Makefile delete mode 100644 board/adder/adder.c delete mode 100644 board/adder/u-boot.lds delete mode 100644 board/ep8248/Makefile delete mode 100644 board/ep8248/ep8248.c delete mode 100644 board/etin/debris/Makefile delete mode 100644 board/etin/debris/debris.c delete mode 100644 board/etin/debris/flash.c delete mode 100644 board/etin/debris/phantom.c delete mode 100644 board/etin/kvme080/Makefile delete mode 100644 board/etin/kvme080/kvme080.c delete mode 100644 board/etin/kvme080/multiverse.c delete mode 100644 board/etin/kvme080/multiverse.h delete mode 100644 board/freescale/mpc8260ads/Makefile delete mode 100644 board/freescale/mpc8260ads/flash.c delete mode 100644 board/freescale/mpc8260ads/mpc8260ads.c delete mode 100644 board/hidden_dragon/Makefile delete mode 100644 board/hidden_dragon/README delete mode 100644 board/hidden_dragon/flash.c delete mode 100644 board/hidden_dragon/hidden_dragon.c delete mode 100644 board/ispan/Makefile delete mode 100644 board/ispan/ispan.c delete mode 100644 board/rattler/Makefile delete mode 100644 board/rattler/rattler.c delete mode 100644 board/zpc1900/Makefile delete mode 100644 board/zpc1900/zpc1900.c delete mode 100644 include/configs/Adder.h delete mode 100644 include/configs/HIDDEN_DRAGON.h delete mode 100644 include/configs/ISPAN.h delete mode 100644 include/configs/MPC8260ADS.h delete mode 100644 include/configs/Rattler.h delete mode 100644 include/configs/ZPC1900.h delete mode 100644 include/configs/debris.h delete mode 100644 include/configs/ep8248.h delete mode 100644 include/configs/kvme080.h -- 1.9.1

3 11

Re: [U-Boot] [RFC PATCH 17/22] dm: Expand and improve the device lifecycle docs
by Simon Glass 02 Jun '14

02 Jun '14

+U-Boot list again Hi Jon, On 30 May 2014 09:55, Jon Loeliger <loeliger(a)gmail.com> wrote: >> > Why is the scan only on the "top level"? My GPIO nodes are, for example, >> > under an SOC node. >> >> Why? Do you have an SOC driver? > > Hi Simon, > > This gets to my earlier issue: I want to use the *exact* same DTS file > for both U-Boot and Linux. We definitely shouldn't have to copy them > into both the Kernel and U-Boot source repositories, and we shouldn't > have to have two in-memory (or flash) DTB blobs either. Here's something I wrote while fiddling with Beaglebone which may help. First a note that may to help avoid confusion. U-Boot and Linux both use device tree. They may use the same device tree source, but it is seldom useful for them to use the exact same binary from the same place. More typically, U-Boot has its device tree packaged wtih it, and the kernel's device tree is packaged with the kernel. In particular this is important with verified boot, since U-Boot's device tree must be immutable. If it can be changed then the public keys can be changed and verified boot is useless. An attacker can simply generate a new key and put his public key into U-Boot so that everything verifies. On the other hand the kernel's device tree typically changes when the kernel changes, so it is useful to package an updated device tree with the kernel binary. U-Boot supports the latter with its flexible FIT format (Flat Image Tree). Re the two source repositories, you can set up any sort of repo that you like for your .dts files, but they are in the U-Boot and kernel repos at present. > > And yes, all the GPIO nodes are under an SoC bus node. > > For example, here is the versatile express DTS from the kernel repository > with the same device (pl061) I am needing: > > $ less versatile-pb.dts > #include <versatile-ab.dts> > > / { > model = "ARM Versatile PB"; > compatible = "arm,versatile-pb"; > > amba { > gpio2: gpio@101e6000 { > compatible = "arm,pl061", "arm,primecell"; > reg = <0x101e6000 0x1000>; > interrupts = <8>; > gpio-controller; > #gpio-cells = <2>; > interrupt-controller; > #interrupt-cells = <2>; > }; > > gpio3: gpio@101e7000 { > compatible = "arm,pl061", "arm,primecell"; > reg = <0x101e7000 0x1000>; > interrupts = <9>; > gpio-controller; > #gpio-cells = <2>; > interrupt-controller; > #interrupt-cells = <2>; > }; > > fpga { > uart@9000 { > compatible = "arm,pl011", "arm,primecell"; > reg = <0x9000 0x1000>; > interrupt-parent = <&sic>; > interrupts = <6>; > }; > sci@a000 { > compatible = "arm,primecell"; > reg = <0xa000 0x1000>; > interrupt-parent = <&sic>; > interrupts = <5>; > }; > mmc@b000 { > compatible = "arm,primecell"; > reg = <0xb000 0x1000>; > interrupts-extended = <&vic 23 &sic 2>; > }; > }; > }; > }; > > #include <testcases.dtsi> > > So yes, I think we need more iterative structure in the DTS parsing for U-Boot. Here I expect you would have a driver for the amba bus, and then that driver would do the scan. The devices should have the amba bus as their parent. One reason for this is that the bus may have its own access mechanism which needs to be provided to devices in that bus (e.g. I2C, SPI, PCI, SCSI, etc.) I'm not saying we don't want to scan the tree more deeply, but until we have a use case for it we should hold off. Regards, Simon

1 0

[U-Boot] [PATCH 0/4] Fix SPI read and Enable required configs for Exynos5
by Akshay Saraswat 02 Jun '14

02 Jun '14

This patch set intends to - 1. Fix SPI flash reading. 2. Enable saving environment at the end of flash. 3. Increase SPL size. 4. Enable USB booting for all Exynos5 Socs. Akshay Saraswat (4): Exynos: SPI: Fix reading data from SPI flash Exynos5: Config: Place environment at the end of SPI Flash Exynos5: Config: Increase SPL footprint for Exynos5420 Exynos5: Config: Enable USB boot mode for all Exynos5 SoCs drivers/spi/exynos_spi.c | 3 +++ include/configs/exynos5-dt.h | 12 +++++++++--- include/configs/exynos5250-dt.h | 8 ++------ include/configs/exynos5420.h | 2 ++ 4 files changed, 16 insertions(+), 9 deletions(-) -- 1.7.12.4

2 8

[U-Boot] [Patch v3 1/4] Added 64-bit MMIO accessors for ARMv8
by York Sun 02 Jun '14

02 Jun '14

From: "J. German Rivera" <German.Rivera(a)freescale.com> This is needed for accessing peripherals with 64-bit MMIO registers, from ARMv8 processors. Signed-off-by: J. German Rivera <German.Rivera(a)freescale.com> --- Change log: v3: No change. The blank line mentioned in review is in the other patch. arch/arm/include/asm/io.h | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/arch/arm/include/asm/io.h b/arch/arm/include/asm/io.h index 6a1f05a..95528dd 100644 --- a/arch/arm/include/asm/io.h +++ b/arch/arm/include/asm/io.h @@ -70,10 +70,12 @@ static inline phys_addr_t virt_to_phys(void * vaddr) #define __arch_getb(a) (*(volatile unsigned char *)(a)) #define __arch_getw(a) (*(volatile unsigned short *)(a)) #define __arch_getl(a) (*(volatile unsigned int *)(a)) +#define __arch_getq(a) (*(volatile unsigned long long *)(a)) #define __arch_putb(v,a) (*(volatile unsigned char *)(a) = (v)) #define __arch_putw(v,a) (*(volatile unsigned short *)(a) = (v)) #define __arch_putl(v,a) (*(volatile unsigned int *)(a) = (v)) +#define __arch_putq(v,a) (*(volatile unsigned long long *)(a) = (v)) extern inline void __raw_writesb(unsigned long addr, const void *data, int bytelen) @@ -123,10 +125,12 @@ extern inline void __raw_readsl(unsigned long addr, void *data, int longlen) #define __raw_writeb(v,a) __arch_putb(v,a) #define __raw_writew(v,a) __arch_putw(v,a) #define __raw_writel(v,a) __arch_putl(v,a) +#define __raw_writeq(v,a) __arch_putq(v,a) #define __raw_readb(a) __arch_getb(a) #define __raw_readw(a) __arch_getw(a) #define __raw_readl(a) __arch_getl(a) +#define __raw_readq(a) __arch_getq(a) /* * TODO: The kernel offers some more advanced versions of barriers, it might @@ -139,10 +143,12 @@ extern inline void __raw_readsl(unsigned long addr, void *data, int longlen) #define writeb(v,c) ({ u8 __v = v; __iowmb(); __arch_putb(__v,c); __v; }) #define writew(v,c) ({ u16 __v = v; __iowmb(); __arch_putw(__v,c); __v; }) #define writel(v,c) ({ u32 __v = v; __iowmb(); __arch_putl(__v,c); __v; }) +#define writeq(v,c) ({ u64 __v = v; __iowmb(); __arch_putq(__v,c); __v; }) #define readb(c) ({ u8 __v = __arch_getb(c); __iormb(); __v; }) #define readw(c) ({ u16 __v = __arch_getw(c); __iormb(); __v; }) #define readl(c) ({ u32 __v = __arch_getl(c); __iormb(); __v; }) +#define readq(c) ({ u64 __v = __arch_getq(c); __iormb(); __v; }) /* * The compiler seems to be incapable of optimising constants @@ -168,9 +174,11 @@ extern inline void __raw_readsl(unsigned long addr, void *data, int longlen) #define out_arch(type,endian,a,v) __raw_write##type(cpu_to_##endian(v),a) #define in_arch(type,endian,a) endian##_to_cpu(__raw_read##type(a)) +#define out_le64(a,v) out_arch(q,le64,a,v) #define out_le32(a,v) out_arch(l,le32,a,v) #define out_le16(a,v) out_arch(w,le16,a,v) +#define in_le64(a) in_arch(q,le64,a) #define in_le32(a) in_arch(l,le32,a) #define in_le16(a) in_arch(w,le16,a) -- 1.7.9.5

3 8