[U-Boot] (no subject)
QUIT Received: from unknown (HELO vlm30043.net) (160.208.143.9) by with SMTP; 3 Feb 2009 07:58:21 - X-Originating-IP: [160.208.143.9] Date: Tue, 3 Feb 2009 15:58:20 +0800 From: "SEMG" To: "u-boot" Reply-To: Subject: =?GB2312?B?cGNiIGJ1c2luZXNz?= X-Mailer: VolleyMail 6.0[cn] Mime-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 RGVhciBTaXIsIA0KDQpJIGFtIChNaXNzLilBYmJ5IFpoYW5nLCB2ZXJ5IHBsZWFzZWQgdG8gY29u dGFjdCB5b3UgZm9yIGZyaWVuZHNoaXAgYXMgd2VsbCBhcyBidXNpbmVzcyByZWxhdGlvbnNoaXAu DQogIA0KUGxlYXNlIGFsbG93IG1lIHRvIGludHJvZHVjZSBvdXIgY29tcGFueSB0byB5b3UsIHdl IGFyZSBhIHByb2Zlc3Npb25hbCBwY2IgbWFudWZhY3R1cmVyIGluIENoaW5hIG1haW5sYW5kLA0K DQpzcGVjaWFsaXppbmcgaW4gdGhlIHBjYiBwcm90b3R5cGUgYW5kIHZvbHVtZSBwcm9kdWN0aW9u LiAgDQogDQpvdXIgUENCIGNhcGFiaWxpdHkgaXMgYXMgZm9sbG93OiANClByb2R1Y3Q6IGRvdWJs ZSBzaWRlLCBtdWx0aS1sYXllciAoNCB0byAyMCBsYXllcnMpIA0KQmFzZSBNYXRlcmlhbDogIEZS LTQsIEhpZ2ggVGcsIEFsdW1pbnVtIEJhc2UsIGV0Yy4gDQpDb3BwZXIgdGhpY2tuZXNzczogMC41 LTMuMCBPWiANCk1pbi4gQ29yZSBUaGlja25lc3MgMC4wMDI1IiAoMC4wNjQgbW0pIA0KVHlwZXMg b2YgU3VyZmFjZSBGaW5pc2g6IEhBU0wgTGVhZCBmcmVlLCBJbW0uR29sZCwgR29sZCBQbGF0aW5n LCBFbnRlaywgZXRjLiANCk1pbi4gSG9sZSBTaXplIChEcmlsbCkgMC4wMDgiICgwLjIwIG1tKSAN ClZpYSBIb2xlIFBUSCwgUGx1Z2dlZCBIb2xlIGJ5IHJlc2luIG9yIFNvbGRlciBtYXNrIA0KTWlu LiBMaW5lIFdpZHRoICYgU3BhY2luZyA0IG1pbCAvIDQgbWlsICgwLjEgbW0gLyAwLjEgbW0pIA0K U29sZGVyIE1hc2sgVVYgY3VyYWJsZSwgUGhvdG9pbWFnZWFibGUsIFBlZWxhYmxlIFR5cGUgDQpJ bXBlZGFuY2UgQ29udHJvbCArLy0gMTAlIA0KDQpUaGFuayB5b3UgZm9yIHlvdXIgc3Ryb25nIHN1 cHBvcnQuIA0KDQpGb3IgbW9yZSBpbmZvcm1hdGlvbiwgd2VsY29tZSB0byB2aXNpdCBodHRwOi8v d3d3LnNlbWdmYWIuY24sIHRoYW5rcyEgDQoNCkJlc3QgcmVnYXJkcywgDQoNCkFiYnkgWmhhbmcg U2FsZXMgU3VwZXJ2aXNvciANCg0KU2VhdHRsZSBFbGVjdHJvbmljcyBNZmcgR3JvdXAgTFRELg0K DQpodHRwOi8vd3d3LnNlbWdmYWIuY24NCg0KVEVMOiA4Ni03NTUtODExNjU5NzMgRkFYOiA4Ni03 NTUtMjU1MzA4MTcgU2t5cGUgSUQ6IHNlbWdwY2INCkFkZHJlc3M6IEJsZGcjMTU1LTUwMUEsIFNo dWliZWkgMm5kIFJkLCBMdW9odSBEaXN0cmljdCwgU2hlbnpoZW4sIENoaW5hDQoKoaqhqqGqoaqh qqGqoaqhqqGqoaqhqqGqoaqhqqGqoaqhqqGqoaqhqqGqoaqhqqGqoaqhqqGqoaqhqqGqCqG+16LS 4qG/yc/D5rXE08q8/sTayN3T69LUz8LOxNfWzt652KGjsb7I7bz+vfbP3tPaus+3qNPDzb4hCrjD 08q8/tPJobZWb2xsZXltYWls08q8/si6t6LXqLzSobfI7bz+t6LLzaO7sbvN+NPRxsDOqtfuwPe6 pgq1xNPKvP7IureiyO28/rb4tuC0ztKqx/PGxr3io6HP1sPit9HPwtTYo6zO3s/eyrG85Mq508Oh owrP6sfpx+u3w87KztLDx7XE1vfSs6O6aHR0cDovL3d3dy5jbnlzb2Z0LmNvbS8= ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] u-boot environment variable storage
twebb sez, > Does u-boot have support for storage of environment variables in > file form? For example, in a file on a FAT32 file system > residing on a MMC card? The only reason I can think you'd want to do that is to be able to set environment variables in linux user land. But then I have a small brain. If you do, take a look at fw_printenv under \tools\something_or_other Matt Harper --- ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] sh: use write{8,16,32} in ms7720se lowlevel_init
Signed-off-by: Nobuhiro Iwamatsu --- board/ms7720se/lowlevel_init.S | 156 +++- 1 files changed, 42 insertions(+), 114 deletions(-) diff --git a/board/ms7720se/lowlevel_init.S b/board/ms7720se/lowlevel_init.S index dcb77ef..7593811 100644 --- a/board/ms7720se/lowlevel_init.S +++ b/board/ms7720se/lowlevel_init.S @@ -18,6 +18,8 @@ * MA 02111-1307 USA */ +#include + .global lowlevel_init .text @@ -25,157 +27,83 @@ lowlevel_init: - mov.l WTCSR_A,r1 - mov.l WTCSR_D,r0 - mov.w r0,@r1 + write16 WTCSR_A, WTCSR_D + + write16 WTCNT_A, WTCNT_D - mov.l WTCNT_A,r1 - mov.l WTCNT_D,r0 - mov.w r0,@r1 + write16 FRQCR_A, FRQCR_D - mov.l FRQCR_A,r1 - mov.l FRQCR_D,r0 - mov.w r0,@r1 + write16 UCLKCR_A, UCLKCR_D - mov.l UCLKCR_A,r1 - mov.l UCLKCR_D,r0 - mov.w r0,@r1 + write32 CMNCR_A, CMNCR_D - mov.l CMNCR_A, r1 - mov.l CMNCR_D, r0 - mov.l r0, @r1 + write32 CMNCR_A, CMNCR_D - mov.l CS0BCR_A, r1 - mov.l CS0BCR_D, r0 - mov.l r0, @r1 + write32 CS0BCR_A, CS0BCR_D - mov.l CS2BCR_A, r1 - mov.l CS2BCR_D, r0 - mov.l r0, @r1 + write32 CS2BCR_A, CS2BCR_D - mov.l CS3BCR_A, r1 - mov.l CS3BCR_D, r0 - mov.l r0, @r1 + write32 CS3BCR_A, CS3BCR_D - mov.l CS4BCR_A, r1 - mov.l CS4BCR_D, r0 - mov.l r0, @r1 + write32 CS4BCR_A, CS4BCR_D - mov.l CS5ABCR_A, r1 - mov.l CS5ABCR_D, r0 - mov.l r0, @r1 + write32 CS5ABCR_A, CS5ABCR_D - mov.l CS5BBCR_A, r1 - mov.l CS5BBCR_D, r0 - mov.l r0, @r1 + write32 CS5BBCR_A, CS5BBCR_D - mov.l CS6ABCR_A, r1 - mov.l CS6ABCR_D, r0 - mov.l r0, @r1 + write32 CS6ABCR_A, CS6ABCR_D - mov.l CS6BBCR_A, r1 - mov.l CS6BBCR_D, r0 - mov.l r0, @r1 + write32 CS6BBCR_A, CS6BBCR_D - mov.l CS0WCR_A, r1 - mov.l CS0WCR_D, r0 - mov.l r0, @r1 + write32 CS0WCR_A, CS0WCR_D - mov.l CS2WCR_A, r1 - mov.l CS2WCR_D, r0 - mov.l r0, @r1 + write32 CS2WCR_A, CS2WCR_D - mov.l CS3WCR_A, r1 - mov.l CS3WCR_D, r0 - mov.l r0, @r1 + write32 CS3WCR_A, CS3WCR_D - mov.l CS4WCR_A, r1 - mov.l CS4WCR_D, r0 - mov.l r0, @r1 + write32 CS4WCR_A, CS4WCR_D - mov.l CS5AWCR_A, r1 - mov.l CS5AWCR_D, r0 - mov.l r0, @r1 + write32 CS5AWCR_A, CS5AWCR_D - mov.l CS5BWCR_A, r1 - mov.l CS5BWCR_D, r0 - mov.l r0, @r1 + write32 CS5BWCR_A, CS5BWCR_D - mov.l CS6AWCR_A, r1 - mov.l CS6AWCR_D, r0 - mov.l r0, @r1 + write32 CS6AWCR_A, CS6AWCR_D - mov.l CS6BWCR_A, r1 - mov.l CS6BWCR_D, r0 - mov.l r0, @r1 + write32 CS6BWCR_A, CS6BWCR_D - mov.l SDCR_A, r1 - mov.l SDCR_D1, r0 - mov.l r0, @r1 + write32 SDCR_A, SDCR_D1 - mov.l RTCSR_A, r1 - mov.l RTCSR_D, r0 - mov.l r0, @r1 + write32 RTCSR_A, RTCSR_D - mov.l RTCNT_A, r1 - mov.l RTCNT_D, r0 - mov.l r0, @r1 + write32 RTCNT_A RTCNT_D - mov.l RTCOR_A, r1 - mov.l RTCOR_D, r0 - mov.l r0, @r1 + write32 RTCOR_A, RTCOR_D - mov.l SDCR_A, r1 - mov.l SDCR_D2, r0 - mov.l r0, @r1 + write32 SDCR_A, SDCR_D2 - mov.l SDMR3_A, r1 - mov.l SDMR3_D, r0 - mov.w r0, @r1 + write16 SDMR3_A, SDMR3_D - mov.l PCCR_A, r1 - mov.l PCCR_D, r0 - mov.w r0, @r1 + write16 PCCR_A, PCCR_D - mov.l PDCR_A, r1 - mov.l PDCR_D, r0 - mov.w r0, @r1 + write16 PDCR_A, PDCR_D - mov.l PECR_A, r1 - mov.l PECR_D, r0 - mov.w r0, @r1 + write16 PECR_A, PECR_D - mov.l PGCR_A, r1 - mov.l PGCR_D, r0 - mov.w r0, @r1 + write16 PGCR_A, PGCR_D - mov.l PHCR_A, r1 - mov.l PHCR_D, r0 - mov.w r0, @r1 + write16 PHCR_A, PHCR_D - mov.l PPCR_A, r1 - mov.l PPCR_D, r0 - mov.w r0, @r1 + write16 PPCR_A, PPCR_D - mov.l PTCR_A, r1 - mov.l PTCR_D, r0 - mov.w r0, @r1 + write16 PTCR_A, PTCR_D - mov.l PVCR_A, r1 - mov.l PVCR_D, r0 - mov.w r0, @r1 + write16 PVCR_A, PVCR_D - mov.l PSELA_A, r1 - mov.l PSELA_D, r0 - mov.w r0, @r1 + write16 PSELA_A, PSELA_D - mov.l CCR_A, r1 - mov.l CCR_D, r0 - mov.l r0, @r1 + write32 CCR_A, CCR_D - mov.l LED_A, r1 - mov.l LED_D, r0 - mov.b r0, @r1 + write8 LED_A, LED_D rts nop -- 1.5.6.5 ___ U-Boot mailing
Re: [U-Boot] [PATCH] Fix Freescale link scripts for newer GCCs
On Sat, 31 Jan 2009, Wolfgang Denk wrote: > In message you wrote: > > > so, what's the status of this patch? I've seen this fail on 83xx. > > > Most of these types of patches that fix the newer gcc's behaviour have > > > been dropped, one of which even did sorting on name and alignment: > > > > > > http://www.mail-archive.com/u-boot@lists.denx.de/msg03193.html > > > > > > Do I need to make one for 83xx and apply it myself? > > > > Wolfgang rejected mine because he wanted a patch that fixed every single > > board in one shot. I didn't feel like patching a hundred other linker > > scripts I knew nothing about. > > Why not? If you know what you are doing (and I have strong resons to > believe that you do) then I think your fix should be applied to all > systems that are affected by the problem. But what systems are affected by the problem? For instance ms7750se only has ".rodata", not even ".rodata.str1.4". So should it get changed too? There are CPUs that have a special segment for byte aligned data. Does u-boot support any of these CPUs? I don't know. But changing ".rodata" to ".rodata*" could break a system if ".rodata1" was supposed to be picked up by a ".*data*1" somewhere else in the linker script. It seems like people who know the platform would be less likely to get caught by this. Or take something like mpc8220, which has this for a text segment: *(.text) *(.fixup) *(.got1) . = ALIGN(16); *(.rodata) *(.rodata1) *(.rodata.str1.4) *(.eh_frame) Why is the start of rodata aligned to 16 bytes? I'd guess some sort of I/D cache issue. Though aren't fixup and got1 data, not code? I can't find any docs on what the differences between fixup, got, got1, and got2 are. It seems like current gcc only uses got2. The mpc8220 ld script also lists fixup a second time, in the reloc section, a mistake that probably doesn't break anything since I think gcc hasn't used fixup in some time. Anyway, not knowing if it's ok to delete fixup and got1, I would change this to: *(.text) *(.fixup) *(.got1) . = ALIGN(16); *(.eh_frame) *(SORT_BY_ALIGNMENT(SORT_BY_NAME(.rodata*))) eh_frame should go before rodata* since it has has a larger alignment, but now rodata isn't 16 byte aligned like it was before. Does that matter? I doubt it, but I don't know for sure. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] ARM:OMAP3:Zoom1: Add nand unlock option
>From d391faf8ca68fcddc8569b03cf24d151d4d3b937 Mon Sep 17 00:00:00 2001 From: Nishanth Menon Date: Mon, 2 Feb 2009 18:20:12 -0600 Subject: [PATCH] ARM:OMAP3:Zoom1: Add nand unlock option Enable NAND_UNLOCK option for unlocking nand for erase/write operations Signed-off-by: Nishanth Menon --- include/configs/omap3_zoom1.h |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/include/configs/omap3_zoom1.h b/include/configs/omap3_zoom1.h index 54d2416..f8ae163 100644 --- a/include/configs/omap3_zoom1.h +++ b/include/configs/omap3_zoom1.h @@ -103,6 +103,7 @@ #define CONFIG_CMD_I2C /* I2C serial bus support */ #define CONFIG_CMD_MMC /* MMC support */ #define CONFIG_CMD_NAND/* NAND support */ +#define CONFIG_CMD_NAND_LOCK_UNLOCK /* Enable lock/unlock support */ #undef CONFIG_CMD_FLASH/* flinfo, erase, protect */ #undef CONFIG_CMD_FPGA /* FPGA configuration Support */ -- 1.5.4.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 01/27 v2] Blackfin: bfin_mac: force board_get_enetaddr() usage
On Monday 02 February 2009 16:04:34 Wolfgang Denk wrote:
> In message Mike Frysinger you wrote:
> > ---
> > Usage
> > ---
> >
> > During board init (like the board-specific misc_init_r() function),
> > boards should take care of locating the MAC address, initializing the
> > environment, and seeding the global data.
>
> Please change:
>
> If the hardware design mandates that the MAC address is stored
> in some special place, like EEPROM etc., then the board
> specific init code (like the board-specific misc_init_r()
> function) is responsible for locating the MAC address(es) and
> initialize the respective environment variable(s) from it.
>
> Note that this shall be done if, and only if, the environment
> does not already contain these environment variables, i. e.
> existing variable definitions must not be overwritten.
>
> The envrionment handling code (function setevn()) will update
> the global data accordingly.
it will update the global data, but nowhere will it initially seed it. i'm
thinking env_init() should be a unified entry point that first calls down to
the specific env storage (eeprom/flash/nand/etc...) and then initializes the
relevant bi_enetaddr members of the global data structure.
> > During runtime, the ethernet layer will use the environment variables to
> > sync the MAC addresses to the ethernet structures. All ethernet driver
> > code should then only use the enetaddr member of the eth_device
> > structure.
>
> Please change:
>
> During runtime, the ethernet layer will use the global data
> to sync ...
documenting it this way wont change the code ;). the ethernet code does not
use the global data in any way. look at eth_initialize() in net/eth.c. i
imagine part of the reason for this is that working with multiple ethernet
devices is pretty ugly atm. the static list of CONFIG_HAS_ETH{1,2,3,...}
makes working with more than one device very messy. the ethernet code today
though builds the string dynamically "eth%iaddr" and so can handle arbitrary
number of devices without needing any changes.
this also applies to the cascading of setenv() into the global data. that
code only handles bi_enetaddr and none of the bi_enetNaddr ... doing 'set
eth1addr ..." will not update bi_enet1addr ...
> > Any other common code that wishes to access the MAC address should then
> > query the global data directly. No one should be looking in the
> > environment for any addresses.
>
> Any code that wishes to access the MAC address should then query the
> global data or the environment, depending on whatever (binary or
> string representation) seems more appropriate.
relying on global data only means code can avoid having to handle unset
variables. global data will always have something in there. the
str_enetaddr() utility function makes this easy ...
> > * bool eth_getenv_enetaddr(char *name, uchar *enetaddr);
>
> Make this "int" - we don't use "bool" in U-Boot. This is C code.
bool is a C type ... not that i'll bitch enough to keep it :p
i've merged your other changes locally
-mike
signature.asc
Description: This is a digitally signed message part.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Preparing a patch for u-boot
Hi, After reading over the U-Boot patch submission guidelines, I want to ask the list before I go ahead and prepare a patch. I am working with a hardware vendor using the XBurst CPU SOC (system on chip). It's basically a MIPS32 compatible CPU with various integrated functions made by Ingenic Semiconductor. A number of low-cost tiny laptops are using the chipset, as well as some embedded systems. The vendor has done a reasonable job releasing all their work under GPL and getting the boards to run on Linux 2.4/2.6 series kernels. They also patched U-Boot to work with their specific chipset and boards. The patch is released here: ftp://ftp.ingenic.cn/3sw/01linux/01loader/u-boot/u-boot-1.1.6-jz-20080530.patch.gz After looking through the patch, it seems to do the following major things (against U-Boot 1.1.6): * Add board support for the various boards that use their XBurst chipset * Added LCD support for their boards * Add specific CPU code to the MIPS CPU for their XBurst chipset * Modified the NAND read/write/erase commands to enable bad block handling My question is essentially: besides updating the patch against the latest GIT version of U-Boot, what would you recommend I do with the code to assist in integrating it into the U-Boot mainline? I realize there are some stylistic changes, but overall, if you could briefly review the patch and give me some pointers it would be most helpful (i.e. would you like this split into several patches, does the patch make any changes that you would not consider for introduction into the mainline, etc)? Thank you very much in advance, Daniel -- Daniel Jabbour Software Engineer Laptouch, Inc. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [ARM] Environment variables not available during console initialisation?
Dear Guennadi Liakhovetski, In message you wrote: > > > Such an explanation belongs into the commit message. > > Sure, _if_ we decide, that this is the correct direction to fix this > problem. We're iterating here to make this a usable patch, right? Such description should be added to the next version. > > We have two situations only: > > > > 1) environment is on the same NAND chip as the U-Boot image; this is > >the case we can handle cleanly. But it does not play any role of > >the environment is embedded, or directly adjacent (either before > >or after) to the U-Boot image, or if it is on a completely > >different location on this NAND chip. > > Well, there is a difference. If the environment is embedded, it is loaded > by nand_spl automatically with the image with a single nand_load() (that's > how it worked until now, I think). If the environment is not embedded but > on the same chip, we still can handle it, but we need an additional > nand_load(). And the copy of the environment from NAND as loaded into RAM > will be at a different location. Maybe env_nand.c doesn't have to know > about this difference, but I haven't gone that far to unify these two > cases. Why not? The only thing env_nand.c needs to know is the address of the environment in memory - it does not care if it's embedded or elsewhere. I think we should not artifically split this into two cases when it's really one. There is two things that need to be done: (1) nand_spl must locate a valid copy of the environment and load it into RAM, and (2) the address must be passed to env_nand.c, but this is probably easy as it can be statically defined, I think. > > To me this means that 1) is the case we implement, without additional > > #ifdef'fery, and 2) is a configuration error for which we should add > > appropriate #error handling. > > Hm, as I briefly looked through other env_*.c, it looks like a few of them > resort to the default environment until env_relocate(). So, we can either Which ones? I think this is almost certainly broken, then. > accept that and say "on those media you can store environment, but it will > be only available late in boot process," or we can start fixing them all > by shifting hardware initialisation before env_init()... Or are you > suggesting to declare them all as broken? Not declare them as broken - just state what they are. But that wa snot what I suggested above. I wrote that we should bail out with an error message if somebody attempts to compile a configuration where the environment is on a different NAND chip than the U-Boot image - it's a non-supported configuration. > > > > > #define CFG_ENV_OFFSET 0x004 > > > > > +/* Leave enough space for bss, currently __bss_end == 0x57e74800 */ > > > > > +#define CFG_NAND_ENV_DST (CFG_UBOOT_BASE + 0x8) > > > > > > > > What's that? What has BSS to do with the environment storage ??? > > > > > > This is smdk6400 header, on this board I chose to place the environment > > > read in by nand_spl above bss, because, AFAIU, the area above __bss_end > > > is > > > > What has BSS to do with the environment storage ??? > > > > BSS does not take any space in the U-Boot image, so why leave a > > (eventually huge) gap unused? > > I need a location in RAM for nand_spl to put a copy of the environment > into. I know that bss doesn't take space in the u-boot image. But you > cannot put environment there, because it will be nullified by u-boot > proper. I think there is some problem with the memory map on this system. It's next to impossible to understand it's design from the config file. Maybe you should document this in the first place. No, please deleted the "maybe". Your patch refers to CFG_MAPPED_RAM_BASE which is not present in mainline. Then you define CFG_UBOOT_BASE. Using a fixed offset, i. e. probably without dynamic memory sizing? Grrrgh. Ah, right, that's ARM where this is broken anyway. Well, I think it is fundamentally important here that you take off the ARM goggles here. Please be aware that such code must run on PPC as well, i. e. it must be usable on systems that do proper auto-sizing etc. If you need space for the environment copy, you must not just use some area somewhere "behind" U-Boot, where it will most likely collide with protected ram, shared log buffer, frame buffer memory etc. Instead, you must design a place for it in the memory map. Thus please start by documenting the intended memory map. > > What has the location in RAM to do with the image structure on NAND? > > We don't need to allocate any space for BSS on the NAND device, right? > > 1. nand_spl copies u-boot proper at a location in RAM > > 2. nand_spl copies environment at another location in RAM > > 3. nand_spl jumps to u-boot proper > > 4. u-boot nullifies bss > > 5. u-boot looks for environment - either embedded, or default, or copied > by nand_spl in 2. Agreed. I
[U-Boot] [PATCH 6/8 v2] Add support for the Freescale eSDHC found on 8379 and 8536 SoCs
This uses the new MMC framework
Some contributions by Dave Liu
Signed-off-by: Andy Fleming
---
Changed how we got eSDHC address, and used clrsetbits_be32, where appropriate.
drivers/mmc/Makefile|1 +
drivers/mmc/fsl_esdhc.c | 348 +++
include/fsl_esdhc.h | 145
3 files changed, 494 insertions(+), 0 deletions(-)
create mode 100644 drivers/mmc/fsl_esdhc.c
create mode 100644 include/fsl_esdhc.h
diff --git a/drivers/mmc/Makefile b/drivers/mmc/Makefile
index d5a969c..040be8d 100644
--- a/drivers/mmc/Makefile
+++ b/drivers/mmc/Makefile
@@ -27,6 +27,7 @@ LIB := $(obj)libmmc.a
COBJS-$(CONFIG_GENERIC_MMC) += mmc.o
COBJS-$(CONFIG_ATMEL_MCI) += atmel_mci.o
+COBJS-$(CONFIG_FSL_ESDHC) += fsl_esdhc.o
COBJS := $(COBJS-y)
SRCS := $(COBJS:.o=.c)
diff --git a/drivers/mmc/fsl_esdhc.c b/drivers/mmc/fsl_esdhc.c
new file mode 100644
index 000..0ba45cd
--- /dev/null
+++ b/drivers/mmc/fsl_esdhc.c
@@ -0,0 +1,348 @@
+/*
+ * Copyright 2007, Freescale Semiconductor, Inc
+ * Andy Fleming
+ *
+ * Based vaguely on the pxa mmc code:
+ * (C) Copyright 2003
+ * Kyle Harris, Nexus Technologies, Inc. khar...@nexus-tech.net
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+
+DECLARE_GLOBAL_DATA_PTR;
+
+struct fsl_esdhc {
+ uintdsaddr;
+ uintblkattr;
+ uintcmdarg;
+ uintxfertyp;
+ uintcmdrsp0;
+ uintcmdrsp1;
+ uintcmdrsp2;
+ uintcmdrsp3;
+ uintdatport;
+ uintprsstat;
+ uintproctl;
+ uintsysctl;
+ uintirqstat;
+ uintirqstaten;
+ uintirqsigen;
+ uintautoc12err;
+ uinthostcapblt;
+ uintwml;
+ charreserved1[8];
+ uintfevt;
+ charreserved2[168];
+ uinthostver;
+ charreserved3[780];
+ uintscr;
+};
+
+/* Return the XFERTYP flags for a given command and data packet */
+uint esdhc_xfertyp(struct mmc_cmd *cmd, struct mmc_data *data)
+{
+ uint xfertyp = 0;
+
+ if (data) {
+ xfertyp |= XFERTYP_DPSEL | XFERTYP_DMAEN;
+
+ if (data->blocks > 1) {
+ xfertyp |= XFERTYP_MSBSEL;
+ xfertyp |= XFERTYP_BCEN;
+ }
+
+ if (data->flags & MMC_DATA_READ)
+ xfertyp |= XFERTYP_DTDSEL;
+ }
+
+ if (cmd->resp_type & MMC_RSP_CRC)
+ xfertyp |= XFERTYP_CCCEN;
+ if (cmd->resp_type & MMC_RSP_OPCODE)
+ xfertyp |= XFERTYP_CICEN;
+ if (cmd->resp_type & MMC_RSP_136)
+ xfertyp |= XFERTYP_RSPTYP_136;
+ else if (cmd->resp_type & MMC_RSP_BUSY)
+ xfertyp |= XFERTYP_RSPTYP_48_BUSY;
+ else if (cmd->resp_type & MMC_RSP_PRESENT)
+ xfertyp |= XFERTYP_RSPTYP_48;
+
+ return XFERTYP_CMD(cmd->cmdidx) | xfertyp;
+}
+
+static int esdhc_setup_data(struct mmc *mmc, struct mmc_data *data)
+{
+ uint wml_value;
+ int timeout;
+ struct fsl_esdhc *regs = mmc->priv;
+
+ wml_value = data->blocksize/4;
+
+ if (data->flags & MMC_DATA_READ) {
+ if (wml_value > 0x10)
+ wml_value = 0x10;
+
+ wml_value = 0x10 | wml_value;
+
+ out_be32(®s->dsaddr, (u32)data->dest);
+ } else {
+ if (wml_value > 0x80)
+ wml_value = 0x80;
+ if ((in_be32(®s->prsstat) & PRSSTAT_WPSPL) == 0) {
+ printf("\nThe SD card is locked. Can not write to a
locked card.\n\n");
+ return TIMEOUT;
+ }
+ wml_value = wml_value << 16 | 0x10;
+ out_be32(®s->dsaddr, (u32)data->src);
+ }
+
+ out_be32(®s->wml, wml_value);
+
+ out_be32(®s->blkattr, data->blocks << 16 | data->blocksize);
+
+ /* Calculate the timeout period for data transactions */
+ timeout = __ilog2(mmc->tran_speed/10);
+ timeout -= 13;
+
+ if (timeout > 14)
+ timeou
[U-Boot] [PATCH 8/8 v2] 83xx: Add eSDHC support on 8379 EMDS board
Signed-off-by: Andy Fleming
---
Addressed Kim's comments
board/freescale/mpc837xemds/mpc837xemds.c | 23 ++-
cpu/mpc83xx/cpu.c | 14 ++
include/asm-ppc/immap_83xx.h |2 ++
include/configs/MPC837XEMDS.h | 15 +++
include/mpc83xx.h |3 +++
5 files changed, 52 insertions(+), 5 deletions(-)
diff --git a/board/freescale/mpc837xemds/mpc837xemds.c
b/board/freescale/mpc837xemds/mpc837xemds.c
index 156d808..062d762 100644
--- a/board/freescale/mpc837xemds/mpc837xemds.c
+++ b/board/freescale/mpc837xemds/mpc837xemds.c
@@ -23,6 +23,7 @@
int board_early_init_f(void)
{
+ struct immap __iomem *im = (struct immap __iomem *)CONFIG_SYS_IMMR;
u8 *bcsr = (u8 *)CONFIG_SYS_BCSR;
/* Enable flash write */
@@ -30,6 +31,18 @@ int board_early_init_f(void)
/* Clear all of the interrupt of BCSR */
bcsr[0xe] = 0xff;
+#ifdef CONFIG_MMC
+ /* Set SPI_SD, SER_SD, and IRQ4_WP so that SD signals go through */
+ bcsr[0xc] |= 0x4c;
+
+ /* Set proper bits in SICR to allow SD signals through */
+ clrsetbits_be32(&im->sysconf.sicrl, SICRL_USB_B, SICRL_USB_B_SD);
+
+ clrsetbits_be32(&im->sysconf.sicrh, (SICRH_GPIO2_E | SICRH_SPI),
+ (SICRH_GPIO2_E_SD | SICRH_SPI_SD));
+
+#endif
+
#ifdef CONFIG_FSL_SERDES
immap_t *immr = (immap_t *)CONFIG_SYS_IMMR;
u32 spridr = in_be32(&immr->sysconf.spridr);
@@ -38,21 +51,21 @@ int board_early_init_f(void)
switch (PARTID_NO_E(spridr)) {
case SPR_8377:
fsl_setup_serdes(CONFIG_FSL_SERDES1, FSL_SERDES_PROTO_SATA,
-FSL_SERDES_CLK_100, FSL_SERDES_VDD_1V);
+ FSL_SERDES_CLK_100, FSL_SERDES_VDD_1V);
break;
case SPR_8378:
fsl_setup_serdes(CONFIG_FSL_SERDES1, FSL_SERDES_PROTO_SGMII,
-FSL_SERDES_CLK_125, FSL_SERDES_VDD_1V);
+ FSL_SERDES_CLK_125, FSL_SERDES_VDD_1V);
break;
case SPR_8379:
fsl_setup_serdes(CONFIG_FSL_SERDES1, FSL_SERDES_PROTO_SATA,
-FSL_SERDES_CLK_100, FSL_SERDES_VDD_1V);
+ FSL_SERDES_CLK_100, FSL_SERDES_VDD_1V);
fsl_setup_serdes(CONFIG_FSL_SERDES2, FSL_SERDES_PROTO_SATA,
-FSL_SERDES_CLK_100, FSL_SERDES_VDD_1V);
+ FSL_SERDES_CLK_100, FSL_SERDES_VDD_1V);
break;
default:
printf("serdes not configured: unknown CPU part number: "
- "%04x\n", spridr >> 16);
+ "%04x\n", spridr >> 16);
break;
}
#endif /* CONFIG_FSL_SERDES */
diff --git a/cpu/mpc83xx/cpu.c b/cpu/mpc83xx/cpu.c
index 587fca3..9e0a05d 100644
--- a/cpu/mpc83xx/cpu.c
+++ b/cpu/mpc83xx/cpu.c
@@ -34,6 +34,7 @@
#include
#include
#include
+#include
DECLARE_GLOBAL_DATA_PTR;
@@ -385,3 +386,16 @@ int cpu_eth_init(bd_t *bis)
#endif
return 0;
}
+
+/*
+ * Initializes on-chip MMC controllers.
+ * to override, implement board_mmc_init()
+ */
+int cpu_mmc_init(bd_t *bis)
+{
+#ifdef CONFIG_FSL_ESDHC
+ return fsl_esdhc_mmc_init(bis);
+#else
+ return 0;
+#endif
+}
diff --git a/include/asm-ppc/immap_83xx.h b/include/asm-ppc/immap_83xx.h
index 77c09db..7b847f8 100644
--- a/include/asm-ppc/immap_83xx.h
+++ b/include/asm-ppc/immap_83xx.h
@@ -895,4 +895,6 @@ typedef struct immap {
} immap_t;
#endif
+#define CONFIG_SYS_MPC83xx_ESDHC_OFFSET(0x2e000)
+#define CONFIG_SYS_MPC83xx_ESDHC_ADDR (CONFIG_SYS_IMMR +
CONFIG_SYS_MPC83xx_ESDHC_OFFSET)
#endif /* __IMMAP_83xx__ */
diff --git a/include/configs/MPC837XEMDS.h b/include/configs/MPC837XEMDS.h
index 0dd6ef5..75b67b4 100644
--- a/include/configs/MPC837XEMDS.h
+++ b/include/configs/MPC837XEMDS.h
@@ -319,6 +319,9 @@
#define CONFIG_OF_BOARD_SETUP 1
#define CONFIG_OF_STDOUT_VIA_ALIAS 1
+#define CONFIG_SYS_64BIT_STRTOUL 1
+#define CONFIG_SYS_64BIT_VSPRINTF 1
+
/* I2C */
#define CONFIG_HARD_I2C/* I2C with hardware support */
#undef CONFIG_SOFT_I2C /* I2C bit-banged */
@@ -502,6 +505,18 @@ extern int board_pci_host_broken(void);
#undef CONFIG_WATCHDOG /* watchdog disabled */
+#define CONFIG_MMC 1
+
+#ifdef CONFIG_MMC
+#define CONFIG_FSL_ESDHC
+#define CONFIG_SYS_FSL_ESDHC_ADDR CONFIG_SYS_MPC83xx_ESDHC_ADDR
+#define CONFIG_CMD_MMC
+#define CONFIG_GENERIC_MMC
+#define CONFIG_CMD_EXT2
+#define CONFIG_CMD_FAT
+#define CONFIG_DOS_PARTITION
+#endif
+
/*
* Miscellaneous configurable options
*/
diff --git a/include/mpc83xx.h b/include/mpc83xx.h
index 191488a..3554fdd 100644
--- a/include/mpc83xx.h
+++ b/include/mpc83xx.h
@@ -266,6 +266,7 @@
/* SICRL bits - MPC
[U-Boot] [PATCH 7/8 v2] 85xx: Add eSDHC support for 8536 DS
Signed-off-by: Andy Fleming
---
Changed how we got the pmuxcr address, and used setbits_be32 for writing it
Also shifted some #defines around to better places, and switched to using
CONFIG_SYS_FSL_ESDHC_ADDR for the eSDHC address
board/freescale/mpc8536ds/mpc8536ds.c | 14 ++
cpu/mpc85xx/cpu.c | 15 +++
include/asm-ppc/immap_85xx.h |3 +++
include/configs/MPC8536DS.h | 14 ++
4 files changed, 46 insertions(+), 0 deletions(-)
diff --git a/board/freescale/mpc8536ds/mpc8536ds.c
b/board/freescale/mpc8536ds/mpc8536ds.c
index eb80500..62c247e 100644
--- a/board/freescale/mpc8536ds/mpc8536ds.c
+++ b/board/freescale/mpc8536ds/mpc8536ds.c
@@ -44,6 +44,20 @@
phys_size_t fixed_sdram(void);
+int board_early_init_f (void)
+{
+#ifdef CONFIG_MMC
+ volatile ccsr_gur_t *gur = (void *)(CONFIG_SYS_MPC85xx_GUTS_ADDR);
+
+ setbits_be32(&gur->pmuxcr,
+ (MPC85xx_PMUXCR_SD_DATA |
+MPC85xx_PMUXCR_SDHC_CD |
+MPC85xx_PMUXCR_SDHC_WP));
+
+#endif
+ return 0;
+}
+
int checkboard (void)
{
printf ("Board: MPC8536DS, System ID: 0x%02x, "
diff --git a/cpu/mpc85xx/cpu.c b/cpu/mpc85xx/cpu.c
index bbea50f..fa1c0e1 100644
--- a/cpu/mpc85xx/cpu.c
+++ b/cpu/mpc85xx/cpu.c
@@ -31,6 +31,7 @@
#include
#include
#include
+#include
#include
#include
@@ -392,5 +393,19 @@ int cpu_eth_init(bd_t *bis)
#if defined(CONFIG_TSEC_ENET) || defined(CONFIG_MPC85XX_FEC)
tsec_standard_init(bis);
#endif
+
return 0;
}
+
+/*
+ * Initializes on-chip MMC controllers.
+ * to override, implement board_mmc_init()
+ */
+int cpu_mmc_init(bd_t *bis)
+{
+#ifdef CONFIG_FSL_ESDHC
+ return fsl_esdhc_mmc_init(bis);
+#else
+ return 0;
+#endif
+}
diff --git a/include/asm-ppc/immap_85xx.h b/include/asm-ppc/immap_85xx.h
index ed8dded..7b97fe0 100644
--- a/include/asm-ppc/immap_85xx.h
+++ b/include/asm-ppc/immap_85xx.h
@@ -1614,6 +1614,9 @@ typedef struct ccsr_gur {
uintgpindr; /* 0xe0050 - General-purpose input data
register */
charres5[12];
uintpmuxcr; /* 0xe0060 - Alternate function signal
multiplex control */
+#define MPC85xx_PMUXCR_SD_DATA 0x8000
+#define MPC85xx_PMUXCR_SDHC_CD 0x4000
+#define MPC85xx_PMUXCR_SDHC_WP 0x2000
charres6[12];
uintdevdisr;/* 0xe0070 - Device disable control */
#define MPC85xx_DEVDISR_PCI1 0x8000
diff --git a/include/configs/MPC8536DS.h b/include/configs/MPC8536DS.h
index e379d53..bbb448d 100644
--- a/include/configs/MPC8536DS.h
+++ b/include/configs/MPC8536DS.h
@@ -72,6 +72,8 @@ extern unsigned long get_board_ddr_clk(unsigned long dummy);
#define CONFIG_L2_CACHE/* toggle L2 cache */
#define CONFIG_BTB /* toggle branch predition */
+#define CONFIG_BOARD_EARLY_INIT_F 1 /* Call board_pre_init */
+
#define CONFIG_ENABLE_36BIT_PHYS 1
#define CONFIG_SYS_MEMTEST_START 0x /* memtest works on */
@@ -528,6 +530,18 @@ extern unsigned long get_board_ddr_clk(unsigned long
dummy);
#undef CONFIG_WATCHDOG /* watchdog disabled */
+#define CONFIG_MMC 1
+
+#ifdef CONFIG_MMC
+#define CONFIG_FSL_ESDHC
+#define CONFIG_SYS_FSL_ESDHC_ADDR CONFIG_SYS_MPC85xx_ESDHC_ADDR
+#define CONFIG_CMD_MMC
+#define CONFIG_GENERIC_MMC
+#define CONFIG_CMD_EXT2
+#define CONFIG_CMD_FAT
+#define CONFIG_DOS_PARTITION
+#endif
+
/*
* Miscellaneous configurable options
*/
--
1.5.4.GIT
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [ARM] Environment variables not available during console initialisation?
On Mon, 2 Feb 2009, Wolfgang Denk wrote:
> Dear Guennadi Liakhovetski,
>
> In message you wrote:
> >
> > > > -#ifdef ENV_IS_EMBEDDED
> > > > +#if defined(ENV_IS_EMBEDDED)
> > > > extern uchar environment[];
> > > > env_t *env_ptr = (env_t *)(&environment[0]);
> > > > +#elif defined(CFG_ENV_IS_APPENDED)
> > >
> > > What makes you think an "appended" environment is so special that it
> > > is worth a separate #ifdef here? What about a prepended environment?
> > > Or one two sectors apart?
> >
> > Ok, agree, the name is badly chosen. The real restriction of this specific
> > implementation is that the environment must be on the same NAND chip as
> > the one we are booting from. Any location on that chip can be handled, I
> > think.
>
> Such an explanation belongs into the commit message.
Sure, _if_ we decide, that this is the correct direction to fix this
problem.
> And I'm not really sure why this file is affected, then.
This file provides the env_init() function, which now has to become aware
of the new possibility - proper (not default) environment already in RAM
(after being loaded by nand_spl).
> > > > +#if defined(ENV_IS_EMBEDDED) || defined(CFG_ENV_IS_APPENDED)
> > > > int crc1_ok = 0, crc2_ok = 0;
> > > > - env_t *tmp_env1, *tmp_env2;
> > > > + env_t *tmp_env1;
> > > >
> > >
> > > Note that there is a fundamental difference between embedded and
> > > non-embedded (in whatever which way) environments, but I can see no
> > > significant difference between an "appended" or a "prepended" or
> > > otherwise separate environment.
> >
> > The reason they share the same #if case here is that both get initialised
> > early, not as was only possible until now on NAND - after all initcalls.
>
> But why does this matter here, and why do we have to change this file
> for that?
I haven't found a better way to do this. Maybe there is one. I understood,
that the proper place to provide an early copy of the dynamic (not
default / static) environment is env_init(), a copy of which is present in
each of env_{flash,nand,nvram,onenand,dataflash,sf}.c.
> > 1. embedded, in this case the real environment is initialised at
> > env_init() time, otherwise first default environment is used
>
> First default environment? Do we have more than one default
> environment?
s/first/at first/ (in the beginning, before env_relocate()).
> > 2. other, env_init() initialises the default environment, the real (stored
> > in NAND) environment is first activated at env_relocate() time.
> >
> > With this patch we add one more case
> >
> > 3. environment, located on the same NAND chip as the boot NAND. in this
> > case we can also let the nand_spl code load it for is in RAM and then we
> > can use it in env_init().
>
> I don't see why we need a special case here.
>
> We have two situations only:
>
> 1) environment is on the same NAND chip as the U-Boot image; this is
>the case we can handle cleanly. But it does not play any role of
>the environment is embedded, or directly adjacent (either before
>or after) to the U-Boot image, or if it is on a completely
>different location on this NAND chip.
Well, there is a difference. If the environment is embedded, it is loaded
by nand_spl automatically with the image with a single nand_load() (that's
how it worked until now, I think). If the environment is not embedded but
on the same chip, we still can handle it, but we need an additional
nand_load(). And the copy of the environment from NAND as loaded into RAM
will be at a different location. Maybe env_nand.c doesn't have to know
about this difference, but I haven't gone that far to unify these two
cases.
> 2) environment is on a different NAND chip than the U-Boot image; in
>this case we cannot access the environment as early as needed,
>i.e. proper operation of U-Boot is not possible.
>
> To me this means that 1) is the case we implement, without additional
> #ifdef'fery, and 2) is a configuration error for which we should add
> appropriate #error handling.
Hm, as I briefly looked through other env_*.c, it looks like a few of them
resort to the default environment until env_relocate(). So, we can either
accept that and say "on those media you can store environment, but it will
be only available late in boot process," or we can start fixing them all
by shifting hardware initialisation before env_init()... Or are you
suggesting to declare them all as broken?
> > > > #define CFG_ENV_OFFSET 0x004
> > > > +/* Leave enough space for bss, currently __bss_end == 0x57e74800 */
> > > > +#define CFG_NAND_ENV_DST (CFG_UBOOT_BASE + 0x8)
> > >
> > > What's that? What has BSS to do with the environment storage ???
> >
> > This is smdk6400 header, on this board I chose to place the environment
> > read in by nand_spl above bss, because, AFAIU, the area above __bss_end is
>
> What has BSS to do with the environment storage ???
>
> BS
[U-Boot] [PATCH 1/2] flash/cfi_flash: Use virtual sector start address, not phys
include/flash.h was commented to say that the address in
flash_info->start was a physical address. However, from u-boot's
point of view, and looking at most flash code, it makes more
sense for this to be a virtual address. So I corrected the
comment to indicate that this was a virtual address.
The only flash driver that was actually treating the address
as physical was the mtd/cfi_flash driver. However, this code
was using it inconsistently as it actually directly dereferenced
the "start" element, while it used map_physmem to get a
virtual address in other places. I changed this driver so
that the code which initializes the info->start field calls
map_physmem to get a virtual address, eliminating the need for
further map_physmem calls. The code is now consistent.
The *only* place a physical address should be used is when defining the
flash banks list that is used to initialize the flash_info struct,
usually found in the board config file.
Signed-off-by: Becky Bruce
---
drivers/mtd/cfi_flash.c | 53 +-
include/flash.h |2 +-
2 files changed, 25 insertions(+), 30 deletions(-)
diff --git a/drivers/mtd/cfi_flash.c b/drivers/mtd/cfi_flash.c
index 84ff7e8..4cb5fb5 100644
--- a/drivers/mtd/cfi_flash.c
+++ b/drivers/mtd/cfi_flash.c
@@ -305,17 +305,12 @@ flash_map (flash_info_t * info, flash_sect_t sect, uint
offset)
{
unsigned int byte_offset = offset * info->portwidth;
- return map_physmem(info->start[sect] + byte_offset,
- flash_sector_size(info, sect) - byte_offset,
- MAP_NOCACHE);
+ return (void *)(info->start[sect] + byte_offset);
}
static inline void flash_unmap(flash_info_t *info, flash_sect_t sect,
unsigned int offset, void *addr)
{
- unsigned int byte_offset = offset * info->portwidth;
-
- unmap_physmem(addr, flash_sector_size(info, sect) - byte_offset);
}
/*---
@@ -802,13 +797,11 @@ static flash_sect_t find_sector (flash_info_t * info,
ulong addr)
static int flash_write_cfiword (flash_info_t * info, ulong dest,
cfiword_t cword)
{
- void *dstaddr;
+ void *dstaddr = (void *)dest;
int flag;
flash_sect_t sect = 0;
char sect_found = 0;
- dstaddr = map_physmem(dest, info->portwidth, MAP_NOCACHE);
-
/* Check if Flash is (sufficiently) erased */
switch (info->portwidth) {
case FLASH_CFI_8BIT:
@@ -827,10 +820,8 @@ static int flash_write_cfiword (flash_info_t * info, ulong
dest,
flag = 0;
break;
}
- if (!flag) {
- unmap_physmem(dstaddr, info->portwidth);
+ if (!flag)
return ERR_NOT_ERASED;
- }
/* Disable interrupts which might cause a timeout here */
flag = disable_interrupts ();
@@ -873,8 +864,6 @@ static int flash_write_cfiword (flash_info_t * info, ulong
dest,
if (flag)
enable_interrupts ();
- unmap_physmem(dstaddr, info->portwidth);
-
if (!sect_found)
sect = find_sector (info, dest);
@@ -890,7 +879,7 @@ static int flash_write_cfibuffer (flash_info_t * info,
ulong dest, uchar * cp,
int cnt;
int retcode;
void *src = cp;
- void *dst = map_physmem(dest, len, MAP_NOCACHE);
+ void *dst = dest;
void *dst2 = dst;
int flag = 0;
uint offset = 0;
@@ -1052,7 +1041,6 @@ static int flash_write_cfibuffer (flash_info_t * info,
ulong dest, uchar * cp,
}
out_unmap:
- unmap_physmem(dst, len);
return retcode;
}
#endif /* CONFIG_SYS_FLASH_USE_BUFFER_WRITE */
@@ -1301,7 +1289,7 @@ int write_buff (flash_info_t * info, uchar * src, ulong
addr, ulong cnt)
/* handle unaligned start */
if ((aln = addr - wp) != 0) {
cword.l = 0;
- p = map_physmem(wp, info->portwidth, MAP_NOCACHE);
+ p = (uchar *)wp;
for (i = 0; i < aln; ++i)
flash_add_byte (info, &cword, flash_read8(p + i));
@@ -1313,7 +1301,6 @@ int write_buff (flash_info_t * info, uchar * src, ulong
addr, ulong cnt)
flash_add_byte (info, &cword, flash_read8(p + i));
rc = flash_write_cfiword (info, wp, cword);
- unmap_physmem(p, info->portwidth);
if (rc != 0)
return rc;
@@ -1372,14 +1359,13 @@ int write_buff (flash_info_t * info, uchar * src, ulong
addr, ulong cnt)
* handle unaligned tail bytes
*/
cword.l = 0;
- p = map_physmem(wp, info->portwidth, MAP_NOCACHE);
+ p = (uchar *)wp;
for (i = 0; (i < info->portwidth) && (cnt > 0); ++i) {
flash_add_byte (info, &cword, *src++);
--cnt;
}
for (; i < info->portwidt
[U-Boot] [PATCH 2/2] mpc8641hpcn: Use physical address in flash banks defintion
If the VA and PA of the flash aren't the same, the banks list
should be initialized to hold the physical address. Correct this.
Signed-off-by: Becky Bruce
---
include/configs/MPC8641HPCN.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/include/configs/MPC8641HPCN.h b/include/configs/MPC8641HPCN.h
index 5a83296..ceb8e54 100644
--- a/include/configs/MPC8641HPCN.h
+++ b/include/configs/MPC8641HPCN.h
@@ -186,7 +186,7 @@ extern unsigned long get_board_sys_clk(unsigned long dummy);
#define CONFIG_SYS_FLASH_BASE_PHYS (CONFIG_SYS_FLASH_BASE \
| CONFIG_SYS_PHYS_ADDR_HIGH)
-#define CONFIG_SYS_FLASH_BANKS_LIST {CONFIG_SYS_FLASH_BASE}
+#define CONFIG_SYS_FLASH_BANKS_LIST {CONFIG_SYS_FLASH_BASE_PHYS}
#define CONFIG_SYS_BR0_PRELIM (BR_PHYS_ADDR(CONFIG_SYS_FLASH_BASE_PHYS) \
| 0x1001) /* port size 16bit */
--
1.5.6.6
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [ARM] Environment variables not available during console initialisation?
Dear Guennadi Liakhovetski, In message you wrote: > > > > -#ifdef ENV_IS_EMBEDDED > > > +#if defined(ENV_IS_EMBEDDED) > > > extern uchar environment[]; > > > env_t *env_ptr = (env_t *)(&environment[0]); > > > +#elif defined(CFG_ENV_IS_APPENDED) > > > > What makes you think an "appended" environment is so special that it > > is worth a separate #ifdef here? What about a prepended environment? > > Or one two sectors apart? > > Ok, agree, the name is badly chosen. The real restriction of this specific > implementation is that the environment must be on the same NAND chip as > the one we are booting from. Any location on that chip can be handled, I > think. Such an explanation belongs into the commit message. And I'm not really sure why this file is affected, then. > > > +#if defined(ENV_IS_EMBEDDED) || defined(CFG_ENV_IS_APPENDED) > > > int crc1_ok = 0, crc2_ok = 0; > > > - env_t *tmp_env1, *tmp_env2; > > > + env_t *tmp_env1; > > > > > > > Note that there is a fundamental difference between embedded and > > non-embedded (in whatever which way) environments, but I can see no > > significant difference between an "appended" or a "prepended" or > > otherwise separate environment. > > The reason they share the same #if case here is that both get initialised > early, not as was only possible until now on NAND - after all initcalls. But why does this matter here, and why do we have to change this file for that? > 1. embedded, in this case the real environment is initialised at > env_init() time, otherwise first default environment is used First default environment? Do we have more than one default environment? > 2. other, env_init() initialises the default environment, the real (stored > in NAND) environment is first activated at env_relocate() time. > > With this patch we add one more case > > 3. environment, located on the same NAND chip as the boot NAND. in this > case we can also let the nand_spl code load it for is in RAM and then we > can use it in env_init(). I don't see why we need a special case here. We have two situations only: 1) environment is on the same NAND chip as the U-Boot image; this is the case we can handle cleanly. But it does not play any role of the environment is embedded, or directly adjacent (either before or after) to the U-Boot image, or if it is on a completely different location on this NAND chip. 2) environment is on a different NAND chip than the U-Boot image; in this case we cannot access the environment as early as needed, i.e. proper operation of U-Boot is not possible. To me this means that 1) is the case we implement, without additional #ifdef'fery, and 2) is a configuration error for which we should add appropriate #error handling. > > > #define CFG_ENV_OFFSET 0x004 > > > +/* Leave enough space for bss, currently __bss_end == 0x57e74800 */ > > > +#define CFG_NAND_ENV_DST (CFG_UBOOT_BASE + 0x8) > > > > What's that? What has BSS to do with the environment storage ??? > > This is smdk6400 header, on this board I chose to place the environment > read in by nand_spl above bss, because, AFAIU, the area above __bss_end is What has BSS to do with the environment storage ??? BSS does not take any space in the U-Boot image, so why leave a (eventually huge) gap unused? > unused by u-boot. But I didn't find an easy way to pass a calculated value > from u-boot proper to nand_spl or vice versa. As you know, these two > objects use saparate linker scripts and are linked absolutely > independently, and just cat'ed together in the end. So, I had to use a > macro to specify the location of the environment copy in RAM instead of > calculating it precisely. What has the location in RAM to do with the image structure on NAND? We don't need to allocate any space for BSS on the NAND device, right? 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 On a clear disk you can seek forever. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] u-boot environment variable storage
Dear twebb, In message you wrote: > Does u-boot have support for storage of environment variables in file > form? For example, in a file on a FAT32 file system residing on a MMC > card? We don't have any writable file systems, so this would render the envrionment read-only, which makes little sense. Short answer: no. 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 combination of a number of things to make existence worthwhile." "Yes, the philosophy of 'none,' meaning 'all.'" -- Spock and Lincoln, "The Savage Curtain", stardate 5906.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 01/27 v2] Blackfin: bfin_mac: force board_get_enetaddr() usage
Dear Mike Frysinger,
In message <200902021505.17476.vap...@gentoo.org> you wrote:
>
> how about this document at doc/README.enetaddr ...
Thanks!
> -
> Ethernet Address (MAC) Handling
> -
>
> There are a variety of places in U-Boot where the MAC address is used, parse,
parsed
> Here are the places where MAC addresses are stored:
...where MAC addresses may be stored.
> - board-specific location (eeprom, dedicated flash, ...)
Please add:
Note: only used when mandatory due to hardware ddesign etc.
> - environment ("ethaddr", "eth1addr", ...)
Please add:
Note: this is the preferred way to permanently store the MAC
addresses in U-Boot.
> - global data (bi_enetaddr, bi_enet1addr, ...)
> - ethernet data (struct eth_device -> enetaddr)
Please add:
Note: these two are just temporary copies of the MAC address,
which exist only after running the respective initialization
code.
> ---
> Usage
> ---
>
> During board init (like the board-specific misc_init_r() function), boards
> should take care of locating the MAC address, initializing the environment,
> and seeding the global data.
Please change:
If the hardware design mandates that the MAC address is stored
in some special place, like EEPROM etc., then the board
specific init code (like the board-specific misc_init_r()
function) is responsible for locating the MAC address(es) and
initialize the respective environment variable(s) from it.
Note that this shall be done if, and only if, the environment
does not already contain these environment variables, i. e.
existing variable definitions must not be overwritten.
The envrionment handling code (function setevn()) will update
the global data accordingly.
> During runtime, the ethernet layer will use the environment variables to sync
> the MAC addresses to the ethernet structures. All ethernet driver code should
> then only use the enetaddr member of the eth_device structure.
Please change:
During runtime, the ethernet layer will use the global data
to sync ...
> The common environment code will take care of passing environment changes to
> the global data and to the ethernet layer.
Maybe again refer to setenv(). Note that this updates only the global
data. The ethernet layer shall init any internal structures it needs
when it runs it's own init code, i. e. upon invocation of a network
related command.
> Any other common code that wishes to access the MAC address should then query
> the global data directly. No one should be looking in the environment for any
> addresses.
Any code that wishes to access the MAC address should then query the
global data or the environment, depending on whatever (binary or
string representation) seems more appropriate.
> * bool eth_getenv_enetaddr(char *name, uchar *enetaddr);
Make this "int" - we don't use "bool" in U-Boot. This is C code.
> Look up an environment variable and convert the stored address. If the env
> var
> is not set, then the function returns false. Otherwise, the conversion occurs
> and returns true.
s/false/-1/; s/true/0/;
> uchar enetaddr[6];
> if (eth_getenv_enetaddr("ethaddr", enetaddr))
> /* enetaddr is now set to the value stored in the ethaddr env var */
> else
> /* "ethaddr" is not set in the environment */
if (!eth_getenv_enetaddr("ethaddr", enetaddr)) {
/* "ethaddr" is not set in the environment */
...
}
/* enetaddr is now set to the value stored in the ethaddr env var */
Thanks again.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
How many seconds are there in a year? If I tell you there are 3.155 x
10^7, you won't even try to remember it. On the other hand, who could
forget that, to within half a percent, pi seconds is a nanocentury.
-- Tom Duff, Bell Labs
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [ARM] Environment variables not available during console initialisation?
On Mon, 2 Feb 2009, Wolfgang Denk wrote: > Dear Guennadi Liakhovetski, > > In message you wrote: > > > > -#ifdef ENV_IS_EMBEDDED > > +#if defined(ENV_IS_EMBEDDED) > > extern uchar environment[]; > > env_t *env_ptr = (env_t *)(&environment[0]); > > +#elif defined(CFG_ENV_IS_APPENDED) > > What makes you think an "appended" environment is so special that it > is worth a separate #ifdef here? What about a prepended environment? > Or one two sectors apart? Ok, agree, the name is badly chosen. The real restriction of this specific implementation is that the environment must be on the same NAND chip as the one we are booting from. Any location on that chip can be handled, I think. > > -#if defined(ENV_IS_EMBEDDED) > > - size_t total; > > +#if defined(ENV_IS_EMBEDDED) || defined(CFG_ENV_IS_APPENDED) > > int crc1_ok = 0, crc2_ok = 0; > > - env_t *tmp_env1, *tmp_env2; > > + env_t *tmp_env1; > > > > Note that there is a fundamental difference between embedded and > non-embedded (in whatever which way) environments, but I can see no > significant difference between an "appended" or a "prepended" or > otherwise separate environment. The reason they share the same #if case here is that both get initialised early, not as was only possible until now on NAND - after all initcalls. > Maybe you try to explain what you have in mind with this > special-casing here? > > And I don't understand the rest of your implementation either. Please > explain... Ok, currently environment in NAND has two cases: 1. embedded, in this case the real environment is initialised at env_init() time, otherwise first default environment is used 2. other, env_init() initialises the default environment, the real (stored in NAND) environment is first activated at env_relocate() time. With this patch we add one more case 3. environment, located on the same NAND chip as the boot NAND. in this case we can also let the nand_spl code load it for is in RAM and then we can use it in env_init(). > > diff --git a/include/configs/smdk6400.h b/include/configs/smdk6400.h > > index 1ee4191..3acf7cd 100644 > > --- a/include/configs/smdk6400.h > > +++ b/include/configs/smdk6400.h > > @@ -223,6 +224,8 @@ > > #define CFG_UBOOT_BASE (CFG_MAPPED_RAM_BASE + 0x07e0) > > > > #define CFG_ENV_OFFSET 0x004 > > +/* Leave enough space for bss, currently __bss_end == 0x57e74800 */ > > +#define CFG_NAND_ENV_DST (CFG_UBOOT_BASE + 0x8) > > What's that? What has BSS to do with the environment storage ??? This is smdk6400 header, on this board I chose to place the environment read in by nand_spl above bss, because, AFAIU, the area above __bss_end is unused by u-boot. But I didn't find an easy way to pass a calculated value from u-boot proper to nand_spl or vice versa. As you know, these two objects use saparate linker scripts and are linked absolutely independently, and just cat'ed together in the end. So, I had to use a macro to specify the location of the environment copy in RAM instead of calculating it precisely. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. 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] u-boot environment variable storage
Does u-boot have support for storage of environment variables in file form? For example, in a file on a FAT32 file system residing on a MMC card? Thanks. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] qong: support for Dave/DENX QongEVB-LITE board
Dear Ilya Yanok,
In message <1233589490-14293-4-git-send-email-ya...@emcraft.com> you wrote:
> This patch adds support for Dave/DENX QongEVB-LITE i.MX31-based board.
>
> Signed-off-by: Ilya Yanok
...
> board/dave/qong/Makefile| 51 +
> board/dave/qong/config.mk |1 +
> board/dave/qong/lowlevel_init.S | 170 +++
> board/dave/qong/qong.c | 167 ++
> board/dave/qong/qong_fpga.h | 41
> board/dave/qong/u-boot.lds | 59 +++
The vendor name should be "davedenx", thus the directory name should
be board/davedenx/qong/, please.
> diff --git a/board/dave/qong/qong.c b/board/dave/qong/qong.c
> new file mode 100644
> index 000..5d12a13
> --- /dev/null
> +++ b/board/dave/qong/qong.c
> @@ -0,0 +1,167 @@
...
> +int dram_init (void)
> +{
> + gd->bd->bi_dram[0].start = PHYS_SDRAM_1;
> + gd->bd->bi_dram[0].size = PHYS_SDRAM_1_SIZE;
> +
> + return 0;
> +}
Why do we not auto-size the RAM here like U-Boot is supposed to do?
> diff --git a/board/dave/qong/u-boot.lds b/board/dave/qong/u-boot.lds
> new file mode 100644
> index 000..1460adc
> --- /dev/null
> +++ b/board/dave/qong/u-boot.lds
> @@ -0,0 +1,59 @@
> +/*
> + * January 2004 - Changed to support H4 device
> + * Copyright (c) 2004 Texas Instruments
Are you sure this is an appropriate comment for this file?
> diff --git a/include/configs/qong.h b/include/configs/qong.h
> new file mode 100644
> index 000..8fae342
> --- /dev/null
> +++ b/include/configs/qong.h
...
> +/*
> + * Reducing the ARP timeout from default 5 seconds to 200ms we speed up the
> + * initial TFTP transfer, should the user wish one, significantly.
> + */
> +#define CONFIG_ARP_TIMEOUT 200UL
Is this really necessary on this hardware?
> +/* allow to overwrite serial and ethaddr */
> +#define CONFIG_ENV_OVERWRITE
Please don't.
> +/***
> + * Command definition
> + ***/
> +
> +#include
> +
> +#define CONFIG_CMD_PING
> +#define CONFIG_CMD_DHCP
> +#define CONFIG_CMD_NET
> +#define CONFIG_CMD_MII
> +
> +#define CONFIG_ETHADDR 00:50:c2:1e:af:e7
> +#define CONFIG_NETMASK 255.255.0.0
> +#define CONFIG_IPADDR192.168.0.81
> +#define CONFIG_SERVERIP 192.168.1.1
> +#define CONFIG_GATEWAYIP 192.168.1.1
Please never, never ever hardcode any network configuration into
U-Boot. Delete this, please.
And please add image timestamp support.
> +#define CONFIG_BOOTDELAY 3
Make this standard 5 seconds, please.
> +#define CONFIG_EXTRA_ENV_SETTINGS
> \
> + "netdev=eth0\0" \
> + "nfsargs=setenv bootargs root=/dev/nfs rw " \
> + "nfsroot=${serverip}:${rootpath}\0" \
> + "ramargs=setenv bootargs root=/dev/ram rw\0"\
> + "addip=setenv bootargs ${bootargs} "\
> + "ip=${ipaddr}:${serverip}:${gatewayip}:${netmask}" \
> + ":${hostname}:${netdev}:off panic=1\0" \
> + "addtty=setenv bootargs ${bootargs}"\
> + " console=ttymxc0,${baudrate}\0"\
> + "addmisc=setenv bootargs ${bootargs}\0" \
> + "uboot_addr=0xa000\0" \
^^
> + "uboot=qong/u-boot.bin\0" \
> + "kernel_addr_r=0x8080\0"\
---^^
No need for 0x prefix.
> + "hostname=qong\0" \
> + "bootfile=qong/uImage\0"\
> + "rootpath=/opt/eldk-4.2-arm/armVFP\0" \
> + "flash_self=run ramargs addip addtty addmisc;" \
> + "bootm ${kernel_addr} ${ramdisk_addr}\0"\
> + "flash_nfs=run nfsargs addip addtty addmisc;" \
> + "bootm ${kernel_addr}\0"\
> + "net_nfs=tftp ${kernel_addr_r} ${bootfile};"\
> + "run nfsargs addip addtty addmisc;" \
> + "bootm ${kernel_addr_r}\0" \
Pleain "bootm" would do as well.
> + "load=tftp ${loadaddr} ${uboot}\0" \
> + "update=protect off " xstr(CONFIG_SYS_MONITOR_BASE) " +"\
> + xstr(CONFIG_SYS_MONITOR_LEN)";" \
> + "era " xstr(CONFIG_SYS_MONITOR_BASE) " +" \
> + xstr(CONFIG_SYS_MONITOR_LEN)";" \
^
Re: [U-Boot] [PATCH 2/3] dnet: driver for Dave DNET ethernet controller
Dear Ilya Yanok,
In message <1233589490-14293-3-git-send-email-ya...@emcraft.com> you wrote:
> Driver for Dave DNET ethernet controller (used on Dave/DENX
> QongEVB-LITE board).
...
> --- a/drivers/net/Makefile
> +++ b/drivers/net/Makefile
> @@ -69,6 +69,7 @@ COBJS-$(CONFIG_VSC7385_ENET) += vsc7385.o
> COBJS-$(CONFIG_XILINX_EMAC) += xilinx_emac.o
> COBJS-$(CONFIG_XILINX_EMACLITE) += xilinx_emaclite.o
> COBJS-$(CONFIG_SH_ETHER) += sh_eth.o
> +COBJS-$(CONFIG_DRIVER_DNET) += dnet.o
Please omit the "DIVER_" part in the name.
> +struct dnet_device {
> + void*regs;
> +
> + const struct device *dev;
> + struct eth_device netdev;
> + unsigned short phy_addr;
> +};
Please no empty line in the struct declaration.
> +#define to_dnet(_nd) container_of(_nd, struct dnet_device, netdev)
Maybe a comment what this is good for?
> +static void dnet_mdio_write(struct dnet_device *dnet, u8 reg, u16 value)
> +{
> + u16 tmp;
> +
> + debug(DRIVERNAME "dnet_mdio_write %02x:%02x <- %04x\n",
> + dnet->phy_addr, reg, value);
> +
> + while (!(dnet_readw_mac(dnet, DNET_INTERNAL_GMII_MNG_CTL_REG) &
> + DNET_INTERNAL_GMII_MNG_CMD_FIN));
Please move the semicolon to a separate line.
> + while (!(dnet_readw_mac(dnet, DNET_INTERNAL_GMII_MNG_CTL_REG) &
> + DNET_INTERNAL_GMII_MNG_CMD_FIN));
Ditto.
> +static u16 dnet_mdio_read(struct dnet_device *dnet, u8 reg)
> +{
> + u16 value;
> +
> + while (!(dnet_readw_mac(dnet, DNET_INTERNAL_GMII_MNG_CTL_REG) &
> + DNET_INTERNAL_GMII_MNG_CMD_FIN));
> +
> + /* only 5 bits allowed for register offset*/
> + reg &= 0x1f;
> +
> + /* prepare reg_value for a read */
> + value = (dnet->phy_addr << 8);
> + value |= reg;
> +
> + /* write control word */
> + dnet_writew_mac(dnet, DNET_INTERNAL_GMII_MNG_CTL_REG, value);
> +
> + /* wait for end of transfer */
> + while (!(dnet_readw_mac(dnet, DNET_INTERNAL_GMII_MNG_CTL_REG) &
> + DNET_INTERNAL_GMII_MNG_CMD_FIN));
Ditto - and so on.
> +static int dnet_recv(struct eth_device *netdev)
> +{
> + struct dnet_device *dnet = to_dnet(netdev);
> + unsigned int * data_ptr;
> + int pkt_len, poll, i;
> + u32 cmd_word;
> +
> + debug("Waiting for pkt (polling)\n");
> + poll = 50;
> + while ((dnet_readl(dnet, RX_FIFO_WCNT) >> 16) == 0) {
> + udelay(10); // wait 10 usec
^^^
> + --poll;
> + if (poll == 0)
> + return 0; // no pkt available
---^^^
No C++ comments, please.
> +/* Register access macros */
> +#define dnet_writel(port, value, reg)\
> + writel((value), (port)->regs + DNET_##reg)
Please do not swap arguments.
> +#define dnet_readl(port, reg)readl((port)->regs + DNET_##reg)
Hmm... Why do we need this?
> +/* ALL DNET FIFO REGISTERS */
> +#define DNET_RX_LEN_FIFO (0x000) /* RX_LEN_FIFO */
> +#define DNET_RX_DATA_FIFO(0x004) /* RX_DATA_FIFO */
> +#define DNET_TX_LEN_FIFO (0x008) /* TX_LEN_FIFO */
> +#define DNET_TX_DATA_FIFO(0x00C) /* TX_DATA_FIFO */
> +
> +/* ALL DNET CONTROL/STATUS REGISTERS OFFSETS */
> +#define DNET_VERCAPS (0x100) /* VERCAPS */
> +#define DNET_INTR_SRC(0x104) /* INTR_SRC */
> +#define DNET_INTR_ENB(0x108) /* INTR_ENB */
> +#define DNET_RX_STATUS (0x10C) /* RX_STATUS */
> +#define DNET_TX_STATUS (0x110) /* TX_STATUS */
> +#define DNET_RX_FRAMES_CNT (0x114) /* RX_FRAMES_CNT */
> +#define DNET_TX_FRAMES_CNT (0x118) /* TX_FRAMES_CNT */
> +#define DNET_RX_FIFO_TH (0x11C) /* RX_FIFO_TH */
> +#define DNET_TX_FIFO_TH (0x120) /* TX_FIFO_TH */
> +#define DNET_SYS_CTL (0x124) /* SYS_CTL */
> +#define DNET_PAUSE_TMR (0x128) /* PAUSE_TMR */
> +#define DNET_RX_FIFO_WCNT(0x12C) /* RX_FIFO_WCNT */
> +#define DNET_TX_FIFO_WCNT(0x130) /* TX_FIFO_WCNT */
...
I see.
Please do not operate on base register plus magic offset - implement a
proper C structure instead to describe the controller hardware.
> +/*
> + * Capabilities. Used by the driver to know the capabilities that
> + * the ethernet controller inside the FPGA have.
> + */
> +
> +#define DNET_HAS_MDIO(1 << 0)
> +#define DNET_HAS_IRQ (1 << 1)
> +#define DNET_HAS_GIGABIT (1 << 2)
> +#define DNET_HAS_DMA (1 << 3)
> +
> +#define DNET_HAS_MII (1 << 4) // or GMII
> +#define DNET_HAS_RMII(1 << 5) /
Re: [U-Boot] [PATCH 1/3] mx31: add GPIO registers definitions
Dear Ilya Yanok, In message <1233589490-14293-2-git-send-email-ya...@emcraft.com> you wrote: > Added definitions for i.MX31 processor GPIO registers. > > Signed-off-by: Ilya Yanok > --- > include/asm-arm/arch-mx31/mx31-regs.h | 10 ++ > 1 files changed, 10 insertions(+), 0 deletions(-) > > diff --git a/include/asm-arm/arch-mx31/mx31-regs.h > b/include/asm-arm/arch-mx31/mx31-regs.h > index b04a718..939bdd3 100644 > --- a/include/asm-arm/arch-mx31/mx31-regs.h > +++ b/include/asm-arm/arch-mx31/mx31-regs.h > @@ -87,6 +87,16 @@ > #define WDOG_BASE0x53FDC000 > > /* > + * GPIO > + */ > +#define GPIO1_BASE (0x53FCC000) > +#define GPIO2_BASE (0x53FD) > +#define GPIO3_BASE (0x53FA4000) > +#define GPIO_DR (0x) > +#define GPIO_GDIR (0x0004) > +#define GPIO_PSR(0x0008) No need for parens around simple constants. But please add a few comments what all these mean/ 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 Every revolutionary idea - in science, politics, art, or whatever - evokes three stages of reaction in a hearer: 1. It is completely impossible - don't waste my time. 2. It is possible, but it is not worth doing. 3. I said it was a good idea all along. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [ARM] Environment variables not available during console initialisation?
Dear Guennadi Liakhovetski,
In message you wrote:
>
> -#ifdef ENV_IS_EMBEDDED
> +#if defined(ENV_IS_EMBEDDED)
> extern uchar environment[];
> env_t *env_ptr = (env_t *)(&environment[0]);
> +#elif defined(CFG_ENV_IS_APPENDED)
What makes you think an "appended" environment is so special that it
is worth a separate #ifdef here? What about a prepended environment?
Or one two sectors apart?
> -#if defined(ENV_IS_EMBEDDED)
> - size_t total;
> +#if defined(ENV_IS_EMBEDDED) || defined(CFG_ENV_IS_APPENDED)
> int crc1_ok = 0, crc2_ok = 0;
> - env_t *tmp_env1, *tmp_env2;
> + env_t *tmp_env1;
>
Note that there is a fundamental difference between embedded and
non-embedded (in whatever which way) environments, but I can see no
significant difference between an "appended" or a "prepended" or
otherwise separate environment.
Maybe you try to explain what you have in mind with this
special-casing here?
And I don't understand the rest of your implementation either. Please
explain...
> diff --git a/include/configs/smdk6400.h b/include/configs/smdk6400.h
> index 1ee4191..3acf7cd 100644
> --- a/include/configs/smdk6400.h
> +++ b/include/configs/smdk6400.h
> @@ -223,6 +224,8 @@
> #define CFG_UBOOT_BASE (CFG_MAPPED_RAM_BASE + 0x07e0)
>
> #define CFG_ENV_OFFSET 0x004
> +/* Leave enough space for bss, currently __bss_end == 0x57e74800 */
> +#define CFG_NAND_ENV_DST (CFG_UBOOT_BASE + 0x8)
What's that? What has BSS to do with the environment storage ???
> #if !defined(CONFIG_ENABLE_MMU)
> diff --git a/lib_arm/board.c b/lib_arm/board.c
> index a093860..2dadfce 100644
> --- a/lib_arm/board.c
> +++ b/lib_arm/board.c
> @@ -282,7 +282,7 @@ init_fnc_t *init_sequence[] = {
> board_init, /* basic board dependent setup */
> interrupt_init, /* set up exceptions */
> env_init, /* initialize environment */
> - init_baudrate, /* initialze baudrate settings */
> + init_baudrate, /* initialize baudrate settings */
> serial_init,/* serial communications setup */
> console_init_f, /* stage 1 init of console */
> display_banner, /* say that we are here */
Please never, never ever mix unrelated changes into one patch. Always
keep patches orthogonal.
> diff --git a/nand_spl/nand_boot.c b/nand_spl/nand_boot.c
> index 16d128f..1fe10d2 100644
> --- a/nand_spl/nand_boot.c
> +++ b/nand_spl/nand_boot.c
> @@ -248,6 +248,11 @@ void nand_boot(void)
> ret = nand_load(&nand_info, CFG_NAND_U_BOOT_OFFS, CFG_NAND_U_BOOT_SIZE,
> (uchar *)CFG_NAND_U_BOOT_DST);
>
> +#ifdef CFG_ENV_IS_APPENDED
> + nand_load(&nand_info, CFG_ENV_OFFSET, CFG_ENV_SIZE,
> + (uchar *)CFG_NAND_ENV_DST);
> +#endif
What is so special here with "appended" compared to any other location
of the environment in the NAND?
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
...though his invention worked superbly -- his theory was a crock of
sewage from beginning to end. - Vernor Vinge, "The Peace War"
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 01/27 v2] Blackfin: bfin_mac: force board_get_enetaddr() usage
On Thursday 29 January 2009 20:23:06 Mike Frysinger wrote:
> at any rate, i'm fine with having the driver assume bi_enetaddr is sane.
> so the series of patches i just posted starts unifying the things i whined
> about earlier and does what you suggested.
>
> unfortunately, with this small review i noticed another layer of confusion
> ;). every ethernet device is represented as struct eth_device, and that
> device has an enetaddr member. the board makes sure ethaddr is set in the
> environment during misc init. then when the network is actually used, the
> eth layer calls the board init which calls the driver init which registers
> a new eth_device. then the eth layer sets up dev->enetaddr based on the
> appropriate ethaddr env var. so imo, no eth driver should be touching the
> global data (and thus the bi_enetaddr's contained in there).
>
> going back a step, i dont think the board itself should be touching the
> global bi_enetaddr. when the board sets the ethaddr env var, the common
> code in cmd_nvedit.c syncs the value to the global data.
>
> if i were to document this mess, where would be the best place ? start a
> new doc/README.enetaddr as i dont see any document that covers the eth
> layer ? that way in the future we can all easily agree on how things should
> be done.
how about this document at doc/README.enetaddr ...
-mike
-
Ethernet Address (MAC) Handling
-
There are a variety of places in U-Boot where the MAC address is used, parse,
and stored. This document covers proper usage of each location and the moving
of data between them.
---
Locations
---
Here are the places where MAC addresses are stored:
- board-specific location (eeprom, dedicated flash, ...)
- environment ("ethaddr", "eth1addr", ...)
- global data (bi_enetaddr, bi_enet1addr, ...)
- ethernet data (struct eth_device -> enetaddr)
---
Usage
---
During board init (like the board-specific misc_init_r() function), boards
should take care of locating the MAC address, initializing the environment,
and seeding the global data.
During runtime, the ethernet layer will use the environment variables to sync
the MAC addresses to the ethernet structures. All ethernet driver code should
then only use the enetaddr member of the eth_device structure.
The common environment code will take care of passing environment changes to
the global data and to the ethernet layer.
Any other common code that wishes to access the MAC address should then query
the global data directly. No one should be looking in the environment for any
addresses.
-
Helpers
-
To assist in the management of these layers, a few helper functions exist. You
should use these rather than attempt to do any kind of parsing/manipulation
yourself as many common errors have arisen in the past.
* void eth_parse_enetaddr(char *addr, uchar *enetaddr);
Convert a string representation of a MAC address to the binary version.
char *addr = "00:11:22:33:44:55";
uchar enetaddr[6];
eth_parse_enetaddr(addr, enetaddr);
/* enetaddr now equals { 0x00, 0x11, 0x22, 0x33, 0x44, 0x55 } */
* bool eth_getenv_enetaddr(char *name, uchar *enetaddr);
Look up an environment variable and convert the stored address. If the env var
is not set, then the function returns false. Otherwise, the conversion occurs
and returns true.
uchar enetaddr[6];
if (eth_getenv_enetaddr("ethaddr", enetaddr))
/* enetaddr is now set to the value stored in the ethaddr env var */
else
/* "ethaddr" is not set in the environment */
* int eth_setenv_enetaddr(char *name, uchar *enetaddr);
Store the MAC address into the named environment variable. The return value is
the same as the setenv() function.
uchar enetaddr[6] = { 0x00, 0x11, 0x22, 0x33, 0x44, 0x55 };
eth_setenv_enetaddr("ethaddr", enetaddr);
/* the "ethaddr" env var should now be set to "00:11:22:33:44:55" */
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] [ARM] Environment variables not available during, console initialisation?
Is this a catch 22? If console is initialized after loading environment variables, this means NAND (or other memories) driver are loaded before console being available and there is no console output to debug NAND driver initialization. If console is initialized before loading NAND driver, environment variable is available after the console is configured? Derek ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Pull request u-boot-blackfin.git
(note that the on-going enetaddr patch has been dropped)
The following changes since commit 6c6e042ab3bbfb5428e4cdeb38fa27728c63afdd:
Wolfgang Denk (1):
Merge branch 'master' of git://git.denx.de/u-boot-arm
are available in the git repository at:
git://www.denx.de/git/u-boot-blackfin.git master
Cliff Cai (1):
Blackfin: add driver for on-chip MMC/SD controller
Mike Frysinger (24):
Blackfin: bfin_mac: set MDCDIV based on SCLK
Blackfin: bfin_mac: cleanup MII/PHY functions
Blackfin: bfin_mac: respect CONFIG_PHY_{ADDR,CLOCK_FREQ}
Blackfin: bfin_mac: use common debug()
Blackfin: bfin_mac: convert CONFIG_BFIN_MAC_RMII to CONFIG_RMII
Blackfin: bfin_mac: cleanup pointer/casts for aliasing issues
Blackfin: only build post code when CONFIG_POST
Blackfin: add driver for on-chip SPI controller
Blackfin: dont check baud if it wont actually get used
Blackfin: enable --gc-sections
Blackfin: cache core/system clock values
Blackfin: setup bi_enetaddr for single nets
Blackfin: rewrite cache handling functions
Blackfin: dma_memcpy(): fix random failures
Blackfin: only flag L1 instruction for DMA memcpy
Blackfin: use 8/16/32 bit transfer widths in dma_memcpy()
Blackfin: fix up EBIU defines
Blackfin: build with -mno-fdpic
Blackfin: add driver for on-chip NAND controller
Blackfin: add port I bits
Blackfin: update asm-blackfin/posix_types.h to latest Linux version
Blackfin: set default CONFIG_ENV_SPI_CS based on bootrom
Blackfin: output booting source when booting
Blackfin: add port muxing for BF51x SPI
Sonic Zhang (1):
Blackfin: add driver for on-chip ATAPI controller
blackfin_config.mk |5 +-
board/bf537-stamp/spi_flash.c| 20 +-
cpu/blackfin/Makefile|1 +
cpu/blackfin/cache.S | 118 ++-
cpu/blackfin/initcode.c |6 +-
drivers/block/Makefile |1 +
drivers/block/pata_bfin.c| 1201 ++
drivers/block/pata_bfin.h| 173
drivers/mmc/Makefile |1 +
drivers/mmc/bfin_sdh.c | 546
drivers/mmc/bfin_sdh.h | 59 ++
drivers/mtd/nand/Makefile|1 +
drivers/mtd/nand/bfin_nand.c | 385 +
drivers/net/bfin_mac.c | 380 -
drivers/net/bfin_mac.h | 31 +-
drivers/spi/Makefile |1 +
drivers/spi/bfin_spi.c | 343
include/asm-blackfin/blackfin-config-post.h |5 +
include/asm-blackfin/blackfin-config-pre.h | 22 +
include/asm-blackfin/blackfin_local.h| 20 +-
include/asm-blackfin/mach-bf548/ports.h | 20 +-
include/asm-blackfin/mach-common/bits/ebiu.h |4 +-
include/asm-blackfin/mach-common/bits/pata.h | 220 +
include/asm-blackfin/mach-common/bits/sdh.h | 122 +++
include/asm-blackfin/mmc.h |1 +
include/asm-blackfin/posix_types.h | 20 +-
lib_blackfin/Makefile|4 +-
lib_blackfin/board.c | 61 +-
lib_blackfin/cache.c | 18 +-
lib_blackfin/clocks.c| 77 ++
lib_blackfin/post.c |4 -
lib_blackfin/string.c| 38 +-
lib_blackfin/tests.c |3 -
33 files changed, 3528 insertions(+), 383 deletions(-)
create mode 100644 drivers/block/pata_bfin.c
create mode 100644 drivers/block/pata_bfin.h
create mode 100644 drivers/mmc/bfin_sdh.c
create mode 100644 drivers/mmc/bfin_sdh.h
create mode 100644 drivers/mtd/nand/bfin_nand.c
create mode 100644 drivers/spi/bfin_spi.c
create mode 100644 include/asm-blackfin/mach-common/bits/pata.h
create mode 100644 include/asm-blackfin/mach-common/bits/sdh.h
create mode 100644 include/asm-blackfin/mmc.h
create mode 100644 lib_blackfin/clocks.c
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/3] dnet: driver for Dave DNET ethernet controller
Hi Ben, Thanks a lot for your comments! I'll address them and repost the patch in a short time. Regards, Ilya. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/3] dnet: driver for Dave DNET ethernet controller
Hi Ilya,
Ilya Yanok wrote:
> Driver for Dave DNET ethernet controller (used on Dave/DENX
> QongEVB-LITE board).
>
> Signed-off-by: Ilya Yanok
> ---
> drivers/net/Makefile |1 +
> drivers/net/dnet.c | 405
> ++
> drivers/net/dnet.h | 169 +
> 3 files changed, 575 insertions(+), 0 deletions(-)
> create mode 100644 drivers/net/dnet.c
> create mode 100644 drivers/net/dnet.h
>
You need to add your initialize() function to include/netdev.h
> diff --git a/drivers/net/Makefile b/drivers/net/Makefile
> index 631336a..a1084a6 100644
> --- a/drivers/net/Makefile
> +++ b/drivers/net/Makefile
> @@ -69,6 +69,7 @@ COBJS-$(CONFIG_VSC7385_ENET) += vsc7385.o
> COBJS-$(CONFIG_XILINX_EMAC) += xilinx_emac.o
> COBJS-$(CONFIG_XILINX_EMACLITE) += xilinx_emaclite.o
> COBJS-$(CONFIG_SH_ETHER) += sh_eth.o
> +COBJS-$(CONFIG_DRIVER_DNET) += dnet.o
>
>
In alphabetical order, please. (ignore the other transgressions)
> COBJS:= $(COBJS-y)
> SRCS := $(COBJS:.o=.c)
> diff --git a/drivers/net/dnet.c b/drivers/net/dnet.c
> new file mode 100644
> index 000..4513707
> --- /dev/null
> +++ b/drivers/net/dnet.c
> @@ -0,0 +1,405 @@
> +/*
> + * Dave Ethernet Controller driver
> + *
> + * Copyright (C) 2008 Dave S.r.l.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#include
> +
> +#if defined(CONFIG_DRIVER_DNET) \
> + && (defined(CONFIG_CMD_NET) || defined(CONFIG_CMD_MII))
> +
>
Not needed, this is taken care of in the Makefile
> +#define CFG_DNET_AUTONEG_TIMEOUT 500
> +
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +
> +#include "dnet.h"
> +
> +struct dnet_device {
> + void*regs;
> +
>
Surely you know enough about this to define its type
> + const struct device *dev;
> + struct eth_device netdev;
> + unsigned short phy_addr;
> +};
> +
> +#define to_dnet(_nd) container_of(_nd, struct dnet_device, netdev)
> +
> +/* function for reading internal MAC register */
> +u16 dnet_readw_mac(struct dnet_device *dnet, u16 reg)
> +{
> + u16 data_read;
> +
> + /* issue a read */
> + dnet_writel(dnet, reg, MACREG_ADDR);
> +
> + /* since a read/write op to the MAC is very slow,
> + * we must wait before reading the data */
> + udelay(1);
> +
> + /* read data read from the MAC register */
> + data_read = dnet_readl(dnet, MACREG_DATA);
> +
> + /* all done */
> + return(data_read);
> +}
> +
> +/* function for writing internal MAC register */
> +void dnet_writew_mac(struct dnet_device *dnet, u16 reg, u16 val)
> +{
> + /* load data to write */
> + dnet_writel(dnet, val, MACREG_DATA);
> +
> + /* issue a write */
> + dnet_writel(dnet, reg | DNET_INTERNAL_WRITE, MACREG_ADDR);
> +
> + /* since a read/write op to the MAC is very slow,
> + * we must wait before exiting */
> + udelay(1);
> +
> + /* all done */
> + return;
>
Not necessary to return
> +}
> +
> +static void dnet_mdio_write(struct dnet_device *dnet, u8 reg, u16 value)
> +{
> + u16 tmp;
> +
> + debug(DRIVERNAME "dnet_mdio_write %02x:%02x <- %04x\n",
> + dnet->phy_addr, reg, value);
> +
> + while (!(dnet_readw_mac(dnet, DNET_INTERNAL_GMII_MNG_CTL_REG) &
> + DNET_INTERNAL_GMII_MNG_CMD_FIN));
> +
> + /* prepare for a write operation */
> + tmp = (1 << 13);
> +
> + /* only 5 bits allowed for register offset */
> + reg &= 0x1f;
> +
> + /* prepare reg_value for a write */
> + tmp |= (dnet->phy_addr << 8);
> + tmp |= reg;
> +
> + /* write data to write first */
> + dnet_writew_mac(dnet, DNET_INTERNAL_GMII_MNG_DAT_REG, value);
> +
> + /* write control word */
> + dnet_writew_mac(dnet, DNET_INTERNAL_GMII_MNG_CTL_REG, tmp);
> +
> + while (!(dnet_readw_mac(dnet, DNET_INTERNAL_GMII_MNG_CTL_REG) &
> + DNET_INTERNAL_GMII_MNG_CMD_FIN));
> +}
> +
> +static u16 dnet_mdio_read(struct dnet_device *dnet, u8 reg)
> +{
> + u16 value;
> +
> + while (!(dnet_readw_mac(dnet, DNET_INTERNAL_GMII_MNG_CTL_REG) &
> + DNET_INTERNAL_GMII_MNG_CMD_FIN));
> +
> + /* only 5 bits allowed for register offset*/
> + reg &= 0x1f;
> +
> + /* prepare reg_value for a read */
> + value = (dnet->phy_addr << 8);
> + value |= reg;
> +
> + /* write control word */
> + dnet_writew_mac(dnet, DNET_INTERNAL_GMII_MNG_CTL_REG, value);
> +
> + /* wait for end of transfer */
> + while (!(dnet_readw_mac(dnet, DNET_INTERNAL_GMII_MNG_CTL_REG) &
> + DNET_INTERNAL_GMII_MNG_CMD_FIN));
> +
> + value = dnet_readw_mac(dnet, DNET_INTERNAL_GMII_MNG_DAT_REG);
> +
> + debug(DRIVERNAME "dnet_mdi
Re: [U-Boot] [RFC] fdt expert advice needed
On Sun, Feb 01, 2009 at 10:30:20PM +0100, Matthias Fuchs wrote:
> - do_fixup_by_compat_u32(blob, "ns16550", "clock-frequency",
> gd->uart_clk, 1);
> + off = fdt_path_offset(blob, "/plb/opb");
> + while ((off = fdt_next_node(blob, off, &ndepth)) >= 0) {
> + /*
> + * process all sub nodes and stop when we are back
> + * at the starting depth
> + */
> + if (ndepth == 0)
> + break;
Should be ndepth <= 0; it can be negative if opb is the last node under
plb to be visited.
Looks OK otherwise.
-Scott
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] PATCH Fix 100Mbs ethernet operation on sh7763 based boards
On Mon, 2 Feb 2009 09:44:08 + Simon Munton wrote: > 100Mbs ethernet does not work on sh7763 chips due to the wrong value being > used in the GECMR register. Following diff fixes the problem > > Signed-off-by: Simon Munton Acked-by: Nobuhiro Iwamatsu -- Nobuhiro Iwamatsu ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [ARM] Environment variables not available during console initialisation?
Hi,
below is a patch / rfc that allows me to read the envorinment from NAND
early enough to be used in the console initialisation. It turns out this
is not only an ARM problem, rather it is common to all platforms storing
environment in NAND. Similarly, probably, env in SPI flash would have this
problem on all platforms too. The patch is not meant for mainline in its
present form because it only solves the problem for platforms, that not
only have their env in NAND, but also boot from NAND (using nand_spl).
OTOH, who would want to store environment in NAND if they didn't have to
boot from it? Anyway, it lacks generality. Also, it contains a couple of
clean ups, that actually would have to be submitted separately (removal
of unused "total" variable, and a typo fix in a comment).
So, this is mostly as an inspiration for someone to develop a proper
patch, or, if we do decide, that this approach is good enough, I'll split
it up and submit properly.
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
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
diff --git a/common/env_nand.c b/common/env_nand.c
index a8f0de7..1261dd2 100644
--- a/common/env_nand.c
+++ b/common/env_nand.c
@@ -71,9 +71,11 @@ extern int default_environment_size;
char * env_name_spec = "NAND";
-#ifdef ENV_IS_EMBEDDED
+#if defined(ENV_IS_EMBEDDED)
extern uchar environment[];
env_t *env_ptr = (env_t *)(&environment[0]);
+#elif defined(CFG_ENV_IS_APPENDED)
+env_t *env_ptr = (env_t *)CFG_NAND_ENV_DST;
#else /* ! ENV_IS_EMBEDDED */
env_t *env_ptr = 0;
#endif /* ENV_IS_EMBEDDED */
@@ -105,23 +107,28 @@ uchar env_get_char_spec (int index)
*/
int env_init(void)
{
-#if defined(ENV_IS_EMBEDDED)
- size_t total;
+#if defined(ENV_IS_EMBEDDED) || defined(CFG_ENV_IS_APPENDED)
int crc1_ok = 0, crc2_ok = 0;
- env_t *tmp_env1, *tmp_env2;
+ env_t *tmp_env1;
- total = CFG_ENV_SIZE;
+#ifdef CFG_REDUNDAND_ENVIRONMENT
+ env_t *tmp_env2;
- tmp_env1 = env_ptr;
tmp_env2 = (env_t *)((ulong)env_ptr + CFG_ENV_SIZE);
+ crc2_ok = (crc32(0, tmp_env2->data, ENV_SIZE) == tmp_env2->crc);
+#endif
+ tmp_env1 = env_ptr;
crc1_ok = (crc32(0, tmp_env1->data, ENV_SIZE) == tmp_env1->crc);
- crc2_ok = (crc32(0, tmp_env2->data, ENV_SIZE) == tmp_env2->crc);
- if (!crc1_ok && !crc2_ok)
+ gd->env_addr = (ulong)env_ptr->data;
+
+ if (!crc1_ok && !crc2_ok) {
+ gd->env_addr = 0;
gd->env_valid = 0;
- else if(crc1_ok && !crc2_ok)
+ } else if(crc1_ok && !crc2_ok)
gd->env_valid = 1;
+#ifdef CFG_REDUNDAND_ENVIRONMENT
else if(!crc1_ok && crc2_ok)
gd->env_valid = 2;
else {
@@ -138,10 +145,13 @@ int env_init(void)
gd->env_valid = 1;
}
+ if (gd->env_valid == 2)
+ env_ptr = tmp_env2;
+ else
+#endif
if (gd->env_valid == 1)
env_ptr = tmp_env1;
- else if (gd->env_valid == 2)
- env_ptr = tmp_env2;
+
#else /* ENV_IS_EMBEDDED */
gd->env_addr = (ulong)&default_environment[0];
gd->env_valid = 1;
@@ -186,12 +196,10 @@ int writeenv(size_t offset, u_char *buf)
#ifdef CFG_ENV_OFFSET_REDUND
int saveenv(void)
{
- size_t total;
int ret = 0;
nand_erase_options_t nand_erase_options;
env_ptr->flags++;
- total = CFG_ENV_SIZE;
nand_erase_options.length = CFG_ENV_RANGE;
nand_erase_options.quiet = 0;
@@ -229,7 +237,6 @@ int saveenv(void)
#else /* ! CFG_ENV_OFFSET_REDUND */
int saveenv(void)
{
- size_t total;
int ret = 0;
nand_erase_options_t nand_erase_options;
@@ -246,7 +253,6 @@ int saveenv(void)
return 1;
puts ("Writing to Nand... ");
- total = CFG_ENV_SIZE;
if (writeenv(CFG_ENV_OFFSET, (u_char *) env_ptr)) {
puts("FAILED!\n");
return 1;
@@ -290,12 +296,9 @@ int readenv (size_t offset, u_char * buf)
void env_relocate_spec (void)
{
#if !defined(ENV_IS_EMBEDDED)
- size_t total;
int crc1_ok = 0, crc2_ok = 0;
env_t *tmp_env1, *tmp_env2;
- total = CFG_ENV_SIZE;
-
tmp_env1 = (env_t *) malloc(CFG_ENV_SIZE);
tmp_env2 = (env_t *) malloc(CFG_ENV_SIZE);
diff --git a/include/configs/smdk6400.h b/include/configs/smdk6400.h
index 1ee4191..3acf7cd 100644
--- a/include/configs/smdk6400.h
+++ b/include/configs/smdk6400.h
@@ -223,6 +224,8 @@
#define CFG_UBOOT_BASE (CFG_MAPPED_RAM_BASE + 0x07e0)
#define CFG_ENV_OFFSET 0x004
+/* Leave enough space for bss, currently __bss_end == 0x57e74800 */
+#define CFG_NAND_ENV_DST (CFG_UBOOT_BASE + 0x8)
/* NAND configuration */
#define CFG_MAX_NAND_DEVICE1
@@
[U-Boot] [PATCH 3/3] qong: support for Dave/DENX QongEVB-LITE board
This patch adds support for Dave/DENX QongEVB-LITE i.MX31-based board. Signed-off-by: Ilya Yanok --- Makefile|4 + board/dave/qong/Makefile| 51 + board/dave/qong/config.mk |1 + board/dave/qong/lowlevel_init.S | 170 +++ board/dave/qong/qong.c | 167 ++ board/dave/qong/qong_fpga.h | 41 board/dave/qong/u-boot.lds | 59 +++ include/configs/qong.h | 213 +++ 8 files changed, 706 insertions(+), 0 deletions(-) create mode 100644 board/dave/qong/Makefile create mode 100644 board/dave/qong/config.mk create mode 100644 board/dave/qong/lowlevel_init.S create mode 100644 board/dave/qong/qong.c create mode 100644 board/dave/qong/qong_fpga.h create mode 100644 board/dave/qong/u-boot.lds create mode 100644 include/configs/qong.h diff --git a/Makefile b/Makefile index 9647bd2..9436107 100644 --- a/Makefile +++ b/Makefile @@ -2994,6 +2994,10 @@ mx31ads_config : unconfig omap2420h4_config : unconfig @$(MKCONFIG) $(@:_config=) arm arm1136 omap2420h4 NULL omap24xx +qong_config: unconfig + @$(MKCONFIG) $(@:_config=) arm arm1136 qong dave mx31 + + # ## ARM1176 Systems # diff --git a/board/dave/qong/Makefile b/board/dave/qong/Makefile new file mode 100644 index 000..b08bc72 --- /dev/null +++ b/board/dave/qong/Makefile @@ -0,0 +1,51 @@ +# +# (C) Copyright 2000-2006 +# Wolfgang Denk, DENX Software Engineering, w...@denx.de. +# +# See file CREDITS for list of people who contributed to this +# project. +# +# This program is free software; you can redistribute it and/or +# modify it under the terms of the GNU General Public License as +# published by the Free Software Foundation; either version 2 of +# the License, or (at your option) any later version. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program; if not, write to the Free Software +# Foundation, Inc., 59 Temple Place, Suite 330, Boston, +# MA 02111-1307 USA +# + +include $(TOPDIR)/config.mk + +LIB= $(obj)lib$(BOARD).a + +COBJS := qong.o +SOBJS := lowlevel_init.o + +SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c) +OBJS := $(addprefix $(obj),$(COBJS)) +SOBJS := $(addprefix $(obj),$(SOBJS)) + +$(LIB):$(obj).depend $(OBJS) $(SOBJS) + $(AR) $(ARFLAGS) $@ $(OBJS) $(SOBJS) + +clean: + rm -f $(SOBJS) $(OBJS) + +distclean: clean + rm -f $(LIB) core *.bak .depend + +# + +# defines $(obj).depend target +include $(SRCTREE)/rules.mk + +sinclude $(obj).depend + +# diff --git a/board/dave/qong/config.mk b/board/dave/qong/config.mk new file mode 100644 index 000..d34dc02 --- /dev/null +++ b/board/dave/qong/config.mk @@ -0,0 +1 @@ +TEXT_BASE = 0x87f0 diff --git a/board/dave/qong/lowlevel_init.S b/board/dave/qong/lowlevel_init.S new file mode 100644 index 000..92d5409 --- /dev/null +++ b/board/dave/qong/lowlevel_init.S @@ -0,0 +1,170 @@ +/* + * Copyright (C) 2009, Emcraft Systems, Ilya Yanok + * + * Based on board/freescale/mx31ads/lowlevel_init.S + * by Guennadi Liakhovetski. + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License as + * published by the Free Software Foundation; either version 2 of + * the License, or (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, + * MA 02111-1307 USA + */ + +#include + +.macro REG reg, val + ldr r2, =\reg + ldr r3, =\val + str r3, [r2] +.endm + +.macro REG8 reg, val + ldr r2, =\reg + ldr r3, =\val + strb r3, [r2] +.endm + +.macro DELAY loops + ldr r2, =\loops +1: + subsr2, r2, #1 + nop + bcs 1b +.endm + +/* RedBoot: To support 133MHz DDR */ +.macro init_drive_strength + /* +* Disable maximum drive strength SDRAM/DDR lines by clearing DSE1 bits +* in SW_PAD_CTL registers +*/ + +
[U-Boot] [PATCH 2/3] dnet: driver for Dave DNET ethernet controller
Driver for Dave DNET ethernet controller (used on Dave/DENX
QongEVB-LITE board).
Signed-off-by: Ilya Yanok
---
drivers/net/Makefile |1 +
drivers/net/dnet.c | 405 ++
drivers/net/dnet.h | 169 +
3 files changed, 575 insertions(+), 0 deletions(-)
create mode 100644 drivers/net/dnet.c
create mode 100644 drivers/net/dnet.h
diff --git a/drivers/net/Makefile b/drivers/net/Makefile
index 631336a..a1084a6 100644
--- a/drivers/net/Makefile
+++ b/drivers/net/Makefile
@@ -69,6 +69,7 @@ COBJS-$(CONFIG_VSC7385_ENET) += vsc7385.o
COBJS-$(CONFIG_XILINX_EMAC) += xilinx_emac.o
COBJS-$(CONFIG_XILINX_EMACLITE) += xilinx_emaclite.o
COBJS-$(CONFIG_SH_ETHER) += sh_eth.o
+COBJS-$(CONFIG_DRIVER_DNET) += dnet.o
COBJS := $(COBJS-y)
SRCS := $(COBJS:.o=.c)
diff --git a/drivers/net/dnet.c b/drivers/net/dnet.c
new file mode 100644
index 000..4513707
--- /dev/null
+++ b/drivers/net/dnet.c
@@ -0,0 +1,405 @@
+/*
+ * Dave Ethernet Controller driver
+ *
+ * Copyright (C) 2008 Dave S.r.l.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include
+
+#if defined(CONFIG_DRIVER_DNET) \
+ && (defined(CONFIG_CMD_NET) || defined(CONFIG_CMD_MII))
+
+#define CFG_DNET_AUTONEG_TIMEOUT 500
+
+#include
+#include
+#include
+
+#include
+#include
+
+#include "dnet.h"
+
+struct dnet_device {
+ void*regs;
+
+ const struct device *dev;
+ struct eth_device netdev;
+ unsigned short phy_addr;
+};
+
+#define to_dnet(_nd) container_of(_nd, struct dnet_device, netdev)
+
+/* function for reading internal MAC register */
+u16 dnet_readw_mac(struct dnet_device *dnet, u16 reg)
+{
+ u16 data_read;
+
+ /* issue a read */
+ dnet_writel(dnet, reg, MACREG_ADDR);
+
+ /* since a read/write op to the MAC is very slow,
+* we must wait before reading the data */
+ udelay(1);
+
+ /* read data read from the MAC register */
+ data_read = dnet_readl(dnet, MACREG_DATA);
+
+ /* all done */
+ return(data_read);
+}
+
+/* function for writing internal MAC register */
+void dnet_writew_mac(struct dnet_device *dnet, u16 reg, u16 val)
+{
+ /* load data to write */
+ dnet_writel(dnet, val, MACREG_DATA);
+
+ /* issue a write */
+ dnet_writel(dnet, reg | DNET_INTERNAL_WRITE, MACREG_ADDR);
+
+ /* since a read/write op to the MAC is very slow,
+* we must wait before exiting */
+ udelay(1);
+
+ /* all done */
+ return;
+}
+
+static void dnet_mdio_write(struct dnet_device *dnet, u8 reg, u16 value)
+{
+ u16 tmp;
+
+ debug(DRIVERNAME "dnet_mdio_write %02x:%02x <- %04x\n",
+ dnet->phy_addr, reg, value);
+
+ while (!(dnet_readw_mac(dnet, DNET_INTERNAL_GMII_MNG_CTL_REG) &
+ DNET_INTERNAL_GMII_MNG_CMD_FIN));
+
+ /* prepare for a write operation */
+ tmp = (1 << 13);
+
+ /* only 5 bits allowed for register offset */
+ reg &= 0x1f;
+
+ /* prepare reg_value for a write */
+ tmp |= (dnet->phy_addr << 8);
+ tmp |= reg;
+
+ /* write data to write first */
+ dnet_writew_mac(dnet, DNET_INTERNAL_GMII_MNG_DAT_REG, value);
+
+ /* write control word */
+ dnet_writew_mac(dnet, DNET_INTERNAL_GMII_MNG_CTL_REG, tmp);
+
+ while (!(dnet_readw_mac(dnet, DNET_INTERNAL_GMII_MNG_CTL_REG) &
+ DNET_INTERNAL_GMII_MNG_CMD_FIN));
+}
+
+static u16 dnet_mdio_read(struct dnet_device *dnet, u8 reg)
+{
+ u16 value;
+
+ while (!(dnet_readw_mac(dnet, DNET_INTERNAL_GMII_MNG_CTL_REG) &
+ DNET_INTERNAL_GMII_MNG_CMD_FIN));
+
+ /* only 5 bits allowed for register offset*/
+ reg &= 0x1f;
+
+ /* prepare reg_value for a read */
+ value = (dnet->phy_addr << 8);
+ value |= reg;
+
+ /* write control word */
+ dnet_writew_mac(dnet, DNET_INTERNAL_GMII_MNG_CTL_REG, value);
+
+ /* wait for end of transfer */
+ while (!(dnet_readw_mac(dnet, DNET_INTERNAL_GMII_MNG_CTL_REG) &
+ DNET_INTERNAL_GMII_MNG_CMD_FIN));
+
+ value = dnet_readw_mac(dnet, DNET_INTERNAL_GMII_MNG_DAT_REG);
+
+ debug(DRIVERNAME "dnet_mdio_read %02x:%02x <- %04x\n",
+ dnet->phy_addr, reg, value);
+
+ return value;
+}
+
+#if defined(CONFIG_CMD_NET)
+
+static int dnet_send(struct eth_device *netdev, volatile void *packet,
+int length)
+{
+ struct dnet_device *dnet = to_dnet(netdev);
+ int i, len, wrsz;
+ unsigned int * bufp;
+ unsigned int tx_cmd;
+
+ debug(DRIVERNAME "[%s] Sending %u bytes\n", __FUNCTION__, length);
+
+ /* frame size (words) */
+ len = (len
[U-Boot] [PATCH 0/3] qong: support for Dave/DENX QongEVB-LITE
These patches add support for Dave/DENX QongEVB-LITE i.MX31-based board. Signed-off-by: Ilya Yanok ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/3] mx31: add GPIO registers definitions
Added definitions for i.MX31 processor GPIO registers. Signed-off-by: Ilya Yanok --- include/asm-arm/arch-mx31/mx31-regs.h | 10 ++ 1 files changed, 10 insertions(+), 0 deletions(-) diff --git a/include/asm-arm/arch-mx31/mx31-regs.h b/include/asm-arm/arch-mx31/mx31-regs.h index b04a718..939bdd3 100644 --- a/include/asm-arm/arch-mx31/mx31-regs.h +++ b/include/asm-arm/arch-mx31/mx31-regs.h @@ -87,6 +87,16 @@ #define WDOG_BASE 0x53FDC000 /* + * GPIO + */ +#define GPIO1_BASE (0x53FCC000) +#define GPIO2_BASE (0x53FD) +#define GPIO3_BASE (0x53FA4000) +#define GPIO_DR (0x) +#define GPIO_GDIR (0x0004) +#define GPIO_PSR(0x0008) + +/* * Signal Multiplexing (IOMUX) */ -- 1.6.0.6 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] need help with flash in U-boot 2009
Hi all We recently ported a MPC8548 board from U-Boot 1.2 to U-Boot 2009.01. U-Boot seems to work fine except for Flash operations, and we can boot Linux 2.6.27 kernel using nfs. We are using CFI ( AMD nor flash). The problem presented it self as the inability to erase a sector of flash. With further investigation we became aware that we can not red the flash correctly. It seams like the 1st 16bits of the 32 bit value is read correctly, but instead of reading the second 16bits, the 1st 16 bits are repeated. as shown below ( comparing the output of U-Boot 2009 and U-Boot 1.2 U-Boot 2009: UBoot=> md f820 f820: 65716571 73007300 eqeqs.s. U-Boot 1.2 UBoot=> md f820 f820: 65717575 7300 equus... The CFI information is consistent between U-Boot 1.2 and U-Boot 2009. (flash vendor = 2, portwidth = 0x4 , buffer_size = 0x20, erase_blk_tout = 0x4000, cmd_reset = 0xf0, cfi_version = 0x3133) which results in FLASH_CFI_32 functions. The Flash And a CPLD is inside the same LAW and we are able to read teh values in the CPLD correctly with both U-Boot versions. Could this be a TLB problem or have we missed something concerning the CFI. My bootpromt is as follows : U-Boot 2009.01-00226-g6c6e042-dirty-svn1188 (Feb 02 2009 - 17:35:04) CPU: 8548E, Version: 1.1, (0x80390011) Core: E500, Version: 1.0, (0x80210010) Clock Configuration: CPU0:990 MHz, CCB:396 MHz, DDR:198 MHz (396 MT/s data rate), LBC:49.500 MHz L1:D-cache 32 kB enabled I-cache 32 kB enabled Board: Equus MPC8548 PCI1: 64 bit, 66 MHz, sync I2C: ready DRAM: Initializing fsl_ddr_sdram starting at step 1 (STEP_GET_SPD) DDR: DDR II rank density = 0x2000 Equus hacked RD_EN to 0 (mpc8xxx/ddr/ddr2_dimm_params Setting Equus custom ddr controll options DDR: 512 MB Top of RAM usable for U-Boot at: 1000 Reserving 301k for U-Boot at: 0ffb Reserving 136k for malloc() at: 0ff8e000 Reserving 72 Bytes for Board Info at: 0ff8dfb8 Reserving 68 Bytes for Global Data at: 0ff8df74 Stack Pointer at: 0ff8df58 New Stack Pointer is: 0ff8df58 Now running in RAM - U-Boot at: 0ffb
Re: [U-Boot] Support for both NAND and NOR flashes in one u-boot image
Dear Deven Balani, In message you wrote: > > I have a reference board design which allows user to select one of the NOR = > or NAND flash as onboard boot devices via a jumper setting. I have a regist= > er setting in the hardware which can be used to identify the boot device ty= > pe (NAND or NOR) during execution of bootloader. Please use shorter lines - accepted line length is some 70 characters or so. > I'm interested in using u-boot to automatically check the boot device type = > (NAND or NOR) during startup, load/store environment from the detected (NAN= > D or NOR) flash device and enable supported u-boot commands for that flash = > device. That's not needed. > I need some advice on, how this mechanism is supported in u-boot? > > In other words, Is it possible to support both NAND and NOR flash as boot d= > evices in one binary image of u-boot? No, this doesn't work. You need two different images. 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 Es gibt immer genug fuer die Beduerfnisse aller, aber niemals genug fuer die Gier einzelner.-- Ghandi ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] Add 16bpp BMP support
Haavard Skinnemoen wrote: > Mark Jackson wrote: >>> We do NOT want to do everything that is possible, but only what is >>> reasonable. >> Exactly ... otherwise where do you stop ? JPG, GIF, TIFF, PNG, etc ? >> We're *only* meant to be showing a simply boot up image (not view lots >> of different sized photos or movies !!), in a very controlled >> environment (i.e. no "user" options ... just what the designers want / >> require). > > Why not do it even simpler? Drop BMP and generate an image matching the > native format of the LCD controller at compile time :-) Not sure if you're serious, but that'd reduce some of the functionality I was expecting to use. My splashimage is stored in a particular, separate flash partition, and I'm intending to allow end-users to change the boot logo (via a userspace app ?) to customise / personalise the unit as they require (e.g. their own company logo). Hard-coding the image would render this impossible. Regards Mark ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Allow board specific overwriting of library code
Hello, recently there were some discussion how to support board specfic lowlevel_init code on the at91 plattform. For example in Nov 2008 there was a discussion about CONFIG_USER_LOWLEVEL_INIT or so and recently there was a patch proposal from Jean-Christophe to provide a cmd_link_o_target macro that creates a combinend object file instead an archive. The combined object file was needed because weak linking somehow doesn't work with archive files. Very annoying. I had large problems with weak linking regarding coloured LED support on my board, too. I came to the conclusion that weak linking across archives are somehow broken. However I was not able to create a small test case to trigger this behavior (bug?) in gcc/bintuils. Ok, so here my proposal that is generic and allows any library code to get overwritten by board specific functions without defining any weak symbols in the library code. It is based purely on sequence of object files presented to 'ld'. Please take a look and tell me your opinion. I have patches to support a new board in my queue but I need any possibility to provide a board specific lowlevel_init. Which solution is selected plays no role to me. Michael Roth ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/1] Allow board specific overwriting of library code
Enables to overwrite any library code by defining EXTRABOARDOBJS in the board specific config.mk. Those listed object files get linked directly into the u-boot binary right after the start objects and before any archives. Signed-off-by: Michael Roth --- Makefile | 12 ++-- 1 files changed, 10 insertions(+), 2 deletions(-) diff --git a/Makefile b/Makefile index 802a704..87975a1 100644 --- a/Makefile +++ b/Makefile @@ -273,6 +273,8 @@ LIBS := $(addprefix $(obj),$(LIBS)) LIBBOARD = board/$(BOARDDIR)/lib$(BOARD).a LIBBOARD := $(addprefix $(obj),$(LIBBOARD)) +EXTRABOARDOBJS := $(addprefix $(obj)board/$(BOARDDIR)/,$(EXTRABOARDOBJS)) + # Add GCC lib PLATFORM_LIBS += -L $(shell dirname `$(CC) $(CFLAGS) -print-libgcc-file-name`) -lgcc @@ -294,7 +296,7 @@ ONENAND_IPL = onenand_ipl U_BOOT_ONENAND = $(obj)u-boot-onenand.bin endif -__OBJS := $(subst $(obj),,$(OBJS)) +__OBJS := $(subst $(obj),,$(OBJS)) $(subst $(obj),,$(EXTRABOARDOBJS)) __LIBS := $(subst $(obj),,$(LIBS)) $(subst $(obj),,$(LIBBOARD)) # @@ -338,7 +340,8 @@ $(obj)u-boot.sha1: $(obj)u-boot.bin $(obj)u-boot.dis: $(obj)u-boot $(OBJDUMP) -d $< > $@ -$(obj)u-boot: depend $(SUBDIRS) $(OBJS) $(LIBBOARD) $(LIBS) $(LDSCRIPT) +$(obj)u-boot: depend $(SUBDIRS) $(OBJS) $(EXTRABOARDOBJS) \ + $(LIBBOARD) $(LIBS) $(LDSCRIPT) UNDEF_SYM=`$(OBJDUMP) -x $(LIBBOARD) $(LIBS) | \ sed -n -e 's/.*\($(SYM_PREFIX)__u_boot_cmd_.*\)/-u\1/p'|sort|uniq`;\ cd $(LNDIR) && $(LD) $(LDFLAGS) $$UNDEF_SYM $(__OBJS) \ @@ -348,6 +351,11 @@ $(obj)u-boot: depend $(SUBDIRS) $(OBJS) $(LIBBOARD) $(LIBS) $(LDSCRIPT) $(OBJS): depend $(obj)include/autoconf.mk $(MAKE) -C cpu/$(CPU) $(if $(REMOTE_BUILD),$@,$(notdir $@)) +$(EXTRABOARDOBJS): depend $(obj)include/autoconf.mk + $(MAKE) -C $(dir $(subst $(obj),,$@)) \ + $(if $(REMOTE_BUILD), \ + $(EXTRABOARDOBJS),$(notdir $(EXTRABOARDOBJS))) + $(LIBS): depend $(obj)include/autoconf.mk $(SUBDIRS) $(MAKE) -C $(dir $(subst $(obj),,$@)) -- 1.6.0.6 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Support for both NAND and NOR flashes in one u-boot image
Hello all, I have a reference board design which allows user to select one of the NOR or NAND flash as onboard boot devices via a jumper setting. I have a register setting in the hardware which can be used to identify the boot device type (NAND or NOR) during execution of bootloader. I'm interested in using u-boot to automatically check the boot device type (NAND or NOR) during startup, load/store environment from the detected (NAND or NOR) flash device and enable supported u-boot commands for that flash device. I need some advice on, how this mechanism is supported in u-boot? In other words, Is it possible to support both NAND and NOR flash as boot devices in one binary image of u-boot? Thanks, Deven ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] PATCH Fix 100Mbs ethernet operation on sh7763 based boards
100Mbs ethernet does not work on sh7763 chips due to the wrong value being
used in the GECMR register. Following diff fixes the problem
Signed-off-by: Simon Munton
--- ./drivers/net/sh_eth.h.orig 2008-11-10 13:49:30.0 +
+++ ./drivers/net/sh_eth.h 2009-01-30 16:21:11.0 +
@@ -166,7 +166,7 @@
/* GECMR */
enum GECMR_BIT {
- GECMR_1000B = 0x01, GECMR_100B = 0x40, GECMR_10B = 0x00,
+ GECMR_1000B = 0x01, GECMR_100B = 0x04, GECMR_10B = 0x00,
};
/* EDRRR*/
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] How to do a basic memory test test using BDI??
Dear Afzal Nadirshah, In message <174230991e95d743b0c91df471ef44e8434393f...@mtw02msg02.mindtree.com> you wrote: > > Can I write simple tests for the RAM on a PPC460 and execute it using= > the BDI debugger? If I don't have linux / u-boot up on my board, how can I= > test the RAM? Except for most basic tests like writing and reading single cells in memory which can be done using the "mm" and "md" commands, the most reasonable approach is a two-pass sort of solution: in the first pass, bring up U-Boot at least to the extent that it boots from flash and has the serial console running. 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 What can it profit a man to gain the whole world and to come to his property with a gastric ulcer, a blown prostate, and bifocals? -- John Steinbeck, _Cannery Row_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mflash u-boot support
Hello?
I fixed and added followings for your requests.
1. too long line length => fixed
2. not a linux coding style => fixed
3. add document (doc/README.mflash)
4. ARM only dependency and always init problem => fixed
5. msecs_to_hz function is changed.
In some ARM platform, CONFIG_SYS_HZ is not 1000 (samsung s3c24xx,
intel pxa25x, pxa27x)
and get_timer() just return elapsed tick of OS timer.
For the compatibility of these, I use #ifdef.
Any comments, advice will be appreciated.
Here is fixed patch.
unsik Kim
Signed-off-by: unsik Kim
---
common/Makefile |2 +
common/cmd_mgdisk.c | 76 ++
common/cmd_nvedit.c |8 +-
common/env_mgdisk.c | 90 ++
disk/part.c |8 +-
disk/part_amiga.c |5 +-
disk/part_dos.c |1 +
disk/part_efi.c |1 +
disk/part_iso.c |1 +
disk/part_mac.c |1 +
doc/README.mflash | 93 +++
drivers/block/Makefile |5 +-
drivers/block/mg_disk.c | 629 +++
drivers/block/mg_disk_prv.h | 140 ++
fs/fat/fat.c|2 +
include/config_cmd_all.h|1 +
include/environment.h | 12 +
include/mg_disk.h | 51
include/part.h |1 +
19 files changed, 1119 insertions(+), 8 deletions(-)
diff --git a/common/Makefile b/common/Makefile
index 93e3963..3a85c2a 100644
--- a/common/Makefile
+++ b/common/Makefile
@@ -53,6 +53,7 @@ COBJS-$(CONFIG_ENV_IS_IN_DATAFLASH) += env_dataflash.o
COBJS-$(CONFIG_ENV_IS_IN_EEPROM) += env_eeprom.o
COBJS-y += env_embedded.o
COBJS-$(CONFIG_ENV_IS_IN_FLASH) += env_flash.o
+COBJS-$(CONFIG_ENV_IS_IN_MG_DISK) += env_mgdisk.o
COBJS-$(CONFIG_ENV_IS_IN_NAND) += env_nand.o
COBJS-$(CONFIG_ENV_IS_IN_NVRAM) += env_nvram.o
COBJS-$(CONFIG_ENV_IS_IN_ONENAND) += env_onenand.o
@@ -104,6 +105,7 @@ COBJS-$(CONFIG_LOGBUFFER) += cmd_log.o
COBJS-$(CONFIG_ID_EEPROM) += cmd_mac.o
COBJS-$(CONFIG_CMD_MEMORY) += cmd_mem.o
COBJS-$(CONFIG_CMD_MFSL) += cmd_mfsl.o
+COBJS-$(CONFIG_CMD_MG_DISK) += cmd_mgdisk.o
COBJS-$(CONFIG_MII) += miiphyutil.o
COBJS-$(CONFIG_CMD_MII) += miiphyutil.o
COBJS-$(CONFIG_CMD_MII) += cmd_mii.o
diff --git a/common/cmd_mgdisk.c b/common/cmd_mgdisk.c
new file mode 100644
index 000..f2f5061
--- /dev/null
+++ b/common/cmd_mgdisk.c
@@ -0,0 +1,76 @@
+/*
+ * (C) Copyright 2009 mGine co.
+ * unsik Kim
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#include
+#include
+
+#if defined (CONFIG_CMD_MG_DISK)
+
+#include
+
+int do_mg_disk_cmd (cmd_tbl_t *cmdtp, int flag, int argc, char *argv[])
+{
+ u32 from, to, size;
+
+ switch (argc) {
+ case 2:
+ if (!strcmp(argv[1], "init"))
+ mg_disk_init();
+ else
+ return 1;
+ break;
+ case 4:
+ from = simple_strtoul(argv[2], NULL, 0);
+ to = simple_strtoul(argv[3], NULL, 0);
+ size = simple_strtoul(argv[4], NULL, 0);
+
+ if (!strcmp(argv[1], "read"))
+ mg_disk_read(from, (u8 *)to, size);
+ else if (!strcmp(argv[1], "write"))
+ mg_disk_write(to, (u8 *)from, size);
+ else if (!strcmp(argv[1], "readsec"))
+ mg_disk_read_sects((void *)to, from, size);
+ else if (!strcmp(argv[1], "writesec"))
+ mg_disk_write_sects((void *)from, to, size);
+ else
+ return 1;
+ break;
+ default:
+ printf("Usage:\n%s\n", cmdtp->usage);
+ return 1;
+ }
+ return 0;
+}
+
+U_BOOT_CMD(
+ mgd,5, 0, do_mg_disk_cmd,
+ "mgd - mgine m[g]flash command\n",
+ ": mgine mflash IO mode (disk) command\n"
+ "- initialize : mgd init\n"
+ "- random read : mgd read [from] [to] [size]\n"
+ "- random write : mgd write [from] [to] [size]\n"
+ "- sector read : mgd readsec [sector] [to] [counts]\n"
+ "- sector write : mgd writesec [from] [sector] [counts]\n"
+);
+
+#
Re: [U-Boot] [PATCH v3] Add 16bpp BMP support
Mark Jackson wrote: > > We do NOT want to do everything that is possible, but only what is > > reasonable. > > Exactly ... otherwise where do you stop ? JPG, GIF, TIFF, PNG, etc ? > We're *only* meant to be showing a simply boot up image (not view lots > of different sized photos or movies !!), in a very controlled > environment (i.e. no "user" options ... just what the designers want / > require). Why not do it even simpler? Drop BMP and generate an image matching the native format of the LCD controller at compile time :-) Haavard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
