Re: [U-Boot] [ARM] Environment variables not available during console initialisation?
Morning Wolfgang
On Tue, 3 Feb 2009, Wolfgang Denk wrote:
> 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.
for (1) - "valid copy" - you're not suggesting to calculate crc32 in
nand_spl to decide upon env validity, are you? I think, we should add as
little as possible to nand_spl, remember, it has to fit in a very limited
size like 16, or 4, or even 2K. So, probably, just add one (or two for
redundant env) nand_load calls and let env_init() evaluate them? Or is
this what you meant?
> > > 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.
Correct me if I'm wrong, but I think code like
int env_init(void)
{
/* SPI flash isn't usable before relocation */
gd->env_addr = (ulong)&default_environment[0];
gd->env_valid = 1;
return 0;
}
does mean the specific environment limits itself to default until
env_relocate()? Then, this snippet os from env_sf.c, env_onenand.c does
exactly the same, env_nand.c if env is not embedded. The rest are actually
reading the medium.
> > 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.
Why? Maybe there are users out there ATM that have environment in NAND and
boot from another storage and are reasonably happy being only able to
affect late configuration dynamically (e.g., Linux boot procedure) and
having to recompile u-boot to change early configuration (console
baudrate, etc.)?
> > > > > > #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.
This all sounds good, but, as I see it, this memory map, and the location
of the env copies read out by nand_spl are platform-dependent, so, every
implementor will just have to take care of the specific configuration.
besides, this location only has to survive until env_relocate(), where it
anyway will be copied
Re: [U-Boot] [PATCH 01/27 v2] Blackfin: bfin_mac: force board_get_enetaddr() usage
Dear Mike Frysinger,
In message <200902021937.26246.vap...@gentoo.org> you wrote:
>
> > 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.
No, that would mix functions in a bad way as it creates new
dependencies on what can or must be done when. env_init() in sone
thing (initializes the environment data), but global data init is
another issue.
Maybe we should try and collect the global data initialization into
one place - but I have to admit that I don't know if or how easily
this can be done.
> > 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.
Well, I think we agree that the current state is a mess. Documenting
the mess makes it easier to add to it. But should we not try to clean
up instead? I.e. document what we think should be done, and fix the
implementation accordingly?
> 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 ...
Agreed - that needs to be fixed, too.
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
Vulcans do not approve of violence.
-- Spock, "Journey to Babel", stardate 3842.4
___
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:
>
> > 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.
>
> for (1) - "valid copy" - you're not suggesting to calculate crc32 in
> nand_spl to decide upon env validity, are you? I think, we should add as
> little as possible to nand_spl, remember, it has to fit in a very limited
> size like 16, or 4, or even 2K. So, probably, just add one (or two for
> redundant env) nand_load calls and let env_init() evaluate them? Or is
> this what you meant?
I enjoy the position of taking a higher level view without caring
about implementation details :-)
Technically, you have to check which of the possibly N copies of the
environment in NAND are valid, and which of them is the most current
copy. With NAND based storage this always means you have to load all
the data in RAM anyway, so it seems OK with me to do just the loading
in the NAND bootstrap loader and leave the rest of the work to the
full U-Boot initialization.
But as mentioned before: that's an implementation details.
> > > 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.
>
> Correct me if I'm wrong, but I think code like
>
> int env_init(void)
> {
> /* SPI flash isn't usable before relocation */
> gd->env_addr = (ulong)&default_environment[0];
> gd->env_valid = 1;
>
> return 0;
> }
>
> does mean the specific environment limits itself to default until
> env_relocate()? Then, this snippet os from env_sf.c, env_onenand.c does
> exactly the same, env_nand.c if env is not embedded. The rest are actually
> reading the medium.
You are right - all the examples you listed are basicly broken and
should be fixed.
> > 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.
>
> Why? Maybe there are users out there ATM that have environment in NAND and
> boot from another storage and are reasonably happy being only able to
> affect late configuration dynamically (e.g., Linux boot procedure) and
> having to recompile u-boot to change early configuration (console
> baudrate, etc.)?
Why should we add additional complexity to the code for a unknown
(but in any case tiny) number of systems with an exotic setup? So far
no such need is known, and nobody in a sane state of mind would do
this. If we clearly state that such a mode of operation is not
supported, we also have a clear position if somebody asks about such
a design.
However, if we allow for this now, and add all the complexity to the
implementation, you can be sure that soon somebody will pop up who is
stupid enough to actually use this, so we never can get rid of it
again, not even after realizing how stupid it actually was.
Let's do it right, especially when doing it right results in clean and
simple code that works as expected.
> > Thus please start by documenting the intended memory map.
>
> This all sounds good, but, as I see it, this memory map, and the location
> of the env copies read out by nand_spl are platform-dependent, so, every
> implementor will just have to take care of the specific configuration.
No. It is architecture dependent (unforatunately, becaus ethe initial
armboot port tried to "simplify" the design we had in place for PPC),
but it is in no way board dependent.
Yes, certain areas may or may not be present for a specific board
(there may or may not be pram or a shared log buffer or video memory
or ...), but the relative location of all these areas is exactly the
same for all boards of the same architecture.
> besides, this location only has to survive until env_relocate(), where it
> anyway will be copied to a malloc()ed buffer. Although, if we reuse the
> ENV_IS_EMBEDDED case then we can keep the buffers and avoid the extra
> malloc() / memcpy(). But documenting is always good, sure:-)
You don't want to keep all the buffers. See above - you will probably
read N sectors of redundant environment, and in the end you will use
just a part of one of these sectors.
> > > 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
Re: [U-Boot] [PATCH 1/2] flash/cfi_flash: Use virtual sector start address, not phys
Becky Bruce wrote:
> 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);
> }
Since "flash_unmap(flash_info_t *info, flash_sect_t sect,unsigned int offset,
void *addr)" function is empty after applying the patch, should all function
calls in the /drivers/mtd/cfi_flash.c file not also be removed?
cheers pieter
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Solved: need help with flash in U-boot 2009
Pieter wrote: > 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... > I found the problem and thought I'll post the solution in case someone down the line makes the same mistake. In porting to U-Boot 2009 I defined the port size in BR0 as 16bit, where it should have be 32 bit. cheers pieter ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] usbtty: Added additional usbtty_configured() checks to get around hang when usb is not connected but multi-io is set up.
This adds additional checks in usbtty_puts() and usbtty_putc() to get around a
hang when usb is not
connected but multi-io (setenv stdout serial,usbtty etc) is set up by the user.
We hang because the
buffers get full because usb isn't connected.
---
drivers/serial/usbtty.c |9 -
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/drivers/serial/usbtty.c b/drivers/serial/usbtty.c
index 7eba470..0e4e17d 100644
--- a/drivers/serial/usbtty.c
+++ b/drivers/serial/usbtty.c
@@ -433,6 +433,9 @@ int usbtty_getc (void)
*/
void usbtty_putc (const char c)
{
+ if (!usbtty_configured ())
+ return;
+
buf_push (&usbtty_output, &c, 1);
/* If \n, also do \r */
if (c == '\n')
@@ -486,8 +489,12 @@ static void __usbtty_puts (const char *str, int len)
void usbtty_puts (const char *str)
{
int n;
- int len = strlen (str);
+ int len;
+
+ if (!usbtty_configured ())
+ return;
+ len = strlen (str);
/* add '\r' for each '\n' */
while (len > 0) {
n = next_nl_pos (str);
--
1.5.6.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] arm: fix some arch_number definition
Sorry for a late reply, but it seems not to be upstream yet, so On Thu, 22 Jan 2009, Jean-Christophe PLAGNIOL-VILLARD wrote: > On 07:51 Thu 22 Jan , Jens Gehrlein wrote: > > Jean-Christophe PLAGNIOL-VILLARD schrieb: > > > >> diff --git a/board/imx31_phycore/imx31_phycore.c > >> b/board/imx31_phycore/imx31_phycore.c > >> index ae93444..4b72d57 100644 > >> --- a/board/imx31_phycore/imx31_phycore.c > >> +++ b/board/imx31_phycore/imx31_phycore.c > >> @@ -60,7 +60,7 @@ int board_init (void) > >>mx31_gpio_mux(MUX_CSPI2_MOSI__I2C2_SCL); > >>mx31_gpio_mux(MUX_CSPI2_MISO__I2C2_SDA); > >> - gd->bd->bi_arch_number = 447; /* board id for linux */ > >> + gd->bd->bi_arch_number = MACH_TYPE_MX31ADS; /* board id for linux */ > > > > Why ADS board ID for the Phycore? > the 447 is the MX31ADS There is a number already, could you please use MACH_TYPE_PCM037 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
Re: [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? > > 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 > Acutally, I have a system that only contains eMMC flash that is formatted to hold filesystems of one sort or another, so there is no spare "non-filesystem" flash available for the environment. There is also no other form of NVRAM on the device. These are the reasons I asked about whether the environment could be maintained in file form; I have no need to set/get environment variables from userland. Thanks, twebb ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] ppc4xx: Make PCIE support selectable
On some platforms PCIE support is not required, but would be included because the cpu supports it. To reduce fooprint it is now configurable via CONFIG_PCI_DISABLE_PCIE. Signed-off-by: Dirk Eibach --- cpu/ppc4xx/4xx_pci.c |5 +++-- cpu/ppc4xx/4xx_pcie.c |2 +- 2 files changed, 4 insertions(+), 3 deletions(-) diff --git a/cpu/ppc4xx/4xx_pci.c b/cpu/ppc4xx/4xx_pci.c index e8871fc..2e75886 100644 --- a/cpu/ppc4xx/4xx_pci.c +++ b/cpu/ppc4xx/4xx_pci.c @@ -588,8 +588,9 @@ void pci_init_board(void) int busno; busno = pci_440_init (&ppc440_hose); -#if defined(CONFIG_440SPE) || \ -defined(CONFIG_460EX) || defined(CONFIG_460GT) +#if (defined(CONFIG_440SPE) || \ +defined(CONFIG_460EX) || defined(CONFIG_460GT)) && \ +!defined(CONFIG_PCI_DISABLE_PCIE) pcie_setup_hoses(busno + 1); #endif } diff --git a/cpu/ppc4xx/4xx_pcie.c b/cpu/ppc4xx/4xx_pcie.c index fd40d8a..58d96bb 100644 --- a/cpu/ppc4xx/4xx_pcie.c +++ b/cpu/ppc4xx/4xx_pcie.c @@ -33,7 +33,7 @@ #if (defined(CONFIG_440SPE) || defined(CONFIG_405EX) ||\ defined(CONFIG_460EX) || defined(CONFIG_460GT)) && \ -defined(CONFIG_PCI) +defined(CONFIG_PCI) && !defined(CONFIG_PCI_DISABLE_PCIE) #include -- 1.5.6.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] flash/cfi_flash: Use virtual sector start address, not phys
On Feb 3, 2009, at 2:53 AM, Pieter wrote:
>>
>> 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);
>> }
>
>
> Since "flash_unmap(flash_info_t *info, flash_sect_t sect,unsigned
> int offset, void *addr)" function is empty after applying the patch,
> should all function calls in the /drivers/mtd/cfi_flash.c file not
> also be removed?
>
> cheers pieter
I think its best to leave them alone for now. If in the future we
really think flash_unmap isn't going to get called we can remove
them. Stefan?
- k
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Support Kilauea USB
Hello, I wanted to know if support for the Native USB 2.0 on the kilauea was in the works. I am currently looking to add support for the USB Boot on a kilauea derived board. Thanks, Lance ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] Add support for setting environment variable from RAM.
This is useful for allowing scripts to read environment variables from
file, among other things.
This is a slightly modified version of what Alessandro submitted to the
mailing list last July:
http://www.mail-archive.com/u-boot-us...@lists.sourceforge.net/msg07932.html
I changed the name from 'setenvram' to 'ramenv' to prevent breakage of scripts
that use the abbreviation 'set' (which my handss have the habit of doing).
Signed-off-by: Eric Nelson
---
common/cmd_nvedit.c | 46 ++
1 files changed, 46 insertions(+), 0 deletions(-)
diff --git a/common/cmd_nvedit.c b/common/cmd_nvedit.c
index 1fcb4c9..bcb6d9f 100644
--- a/common/cmd_nvedit.c
+++ b/common/cmd_nvedit.c
@@ -494,6 +494,44 @@ int do_askenv ( cmd_tbl_t *cmdtp, int flag, int argc, char
*argv[])
#endif
/
+ * Set a new environment variable from RAM.
+ * Requires three arguments: the variable name, a memory address and a length.
+ *
+ * Deletes the environment variable if the length is zero.
+ */
+int do_ramenv(cmd_tbl_t *cmdtp, int flag, int argc, char *argv[])
+{
+ unsigned long len, i;
+ char *addr;
+
+ if (argc != 4) {
+ cmd_usage(cmdtp);
+ return 1;
+ }
+ addr = (char *)simple_strtol(argv[2], NULL, 16);
+ len = simple_strtol(argv[3], NULL, 16);
+ if (!addr || !len) {
+ cmd_usage(cmdtp);
+ return 1;
+ }
+ addr[len] = '\0';
+ for (i = 0; i < len; i++) {
+ /* turn newlines into semicolon */
+ if (addr[i] == '\n')
+ addr[i] = ';'; /* ignore dos-style newlines */
+ if (addr[i] == '\r')
+ addr[i] = ' '; /* accept sh-comments and discard them */
+ if (addr[i] == '#') {
+ while (addr[i] && addr[i] != '\n')
+ addr[i++] = ' ';
+ i--;
+ }
+ }
+ setenv(argv[1], addr);
+ return 0;
+}
+
+/
* Look up variable from environment,
* return address of storage for that variable,
* or NULL if not found
@@ -605,6 +643,14 @@ U_BOOT_CMD(
"- delete environment variable 'name'\n"
);
+U_BOOT_CMD(
+ ramenv, 4, 0, do_ramenv,
+ "ramenv - get environment variable from ram\n",
+ "name addr maxlen\n"
+ "- set environment variable 'name' from addr 'addr'\n"
+ "- delete environment variable if maxlen is 0\n"
+);
+
#if defined(CONFIG_CMD_ASKENV)
U_BOOT_CMD(
--
1.5.5.1.382.g182fb
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Add support for setting environment variable from RAM.
Hi Eric,
On Tue, 2009-02-03 at 08:28 -0700, Eric Nelson (Boundary Devices) wrote:
> /
> + * Set a new environment variable from RAM.
> + * Requires three arguments: the variable name, a memory address and a
> length.
> + *
> + * Deletes the environment variable if the length is zero.
> + */
> +int do_ramenv(cmd_tbl_t *cmdtp, int flag, int argc, char *argv[])
> +{
> + unsigned long len, i;
> + char *addr;
> +
> + if (argc != 4) {
> + cmd_usage(cmdtp);
> + return 1;
> + }
> + addr = (char *)simple_strtol(argv[2], NULL, 16);
> + len = simple_strtol(argv[3], NULL, 16);
> + if (!addr || !len) {
> + cmd_usage(cmdtp);
> + return 1;
> + }
> + addr[len] = '\0';
> + for (i = 0; i < len; i++) {
> + /* turn newlines into semicolon */
> + if (addr[i] == '\n')
> + addr[i] = ';'; /* ignore dos-style newlines */
> + if (addr[i] == '\r')
> + addr[i] = ' '; /* accept sh-comments and discard them */
> + if (addr[i] == '#') {
> + while (addr[i] && addr[i] != '\n')
> + addr[i++] = ' ';
> + i--;
> + }
> + }
> + setenv(argv[1], addr);
> + return 0;
> +}
> +
> +/
> * Look up variable from environment,
> * return address of storage for that variable,
> * or NULL if not found
> @@ -605,6 +643,14 @@ U_BOOT_CMD(
> "- delete environment variable 'name'\n"
> );
>
> +U_BOOT_CMD(
> + ramenv, 4, 0, do_ramenv,
> + "ramenv - get environment variable from ram\n",
The "ramenv - " and "\n" are no longer used in the above line.
> + "name addr maxlen\n"
> + "- set environment variable 'name' from addr 'addr'\n"
> + "- delete environment variable if maxlen is 0\n"
> +);
> +
> #if defined(CONFIG_CMD_ASKENV)
>
> U_BOOT_CMD(
In the email thread you mentioned above, Detlev mentions 2 alternatives
to the "ramenv" command - loading a uImage script and running it via
autoscr, or modifying autoscr to be able to raw files (non-uImages).
Both of these methods seem cleaner and more flexible at a glance. Is
there a specific reason using autoscr wouldn't work for your setup?
For example, what is the process to load multiple environment variables
with the ramenv command? If I understand correctly, in order to load 10
environment variables you'd have to repeat the process of "load a file
to RAM, run ramenv" 10 times? That seems much more difficult than
loading 1 file with 10 environment variables and running autoscr once.
Best,
Peter
___
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?
Guennadi Liakhovetski wrote: > On Tue, 3 Feb 2009, Wolfgang Denk wrote: >> I don't see what nand(_spl) maintainers should comment here - their >> code is so far completley unaffected. We just agreed on needing >> another call to the load routine. > > We still have the other possibility - properly initialise NAND before > calling env_init() and then read out env? This would be a preferred > solution IMHO, because it leverages restrictions like "only the boot > NAND," simplifies the choice of a location in RAM, leaves nand_spl code > intact, thus avoiding even minimal size increment. NAND maintainer's > opinion as to how feasible / difficult this would be would be appreciated. > Or even better - a patch:-) I think, we could even move mem_malloc_init() > before the initcall loop and use a malloc()ed buffer just as > env_relocate() would do. Besides Wolfgang's comment that this would preclude serial output during NAND init, this won't work if you're booting from NOR flash and thus don't have RAM initialized yet. And even with NAND boot, this is prior to relocation to the top of RAM, which might complicate things. We could leave nand_spl code completely untouched if we pad the NAND image to a block boundary, and then append the environment. nand_spl would just see a larger image. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [GIT PULL] Please pull mpc5xxx tree
Wolfgang, The following changes since commit 92c20fbd3a7788c1a154f50a3f44f28a7763f99a: John Rigby (1): ADS5121 DIU Make inclusion of FSL logo optional are available in the git repository at: http://git.denx.de/u-boot-mpc5xxx.git master John Rigby (3): ADS5121 DIU Add diu_bmp_addr env ADS5121 Fix rev2 silicon pci iopad config ADS5121 Add IC Ident Module (IIM) support Ralph Kondziella (1): ADS5121 Add PATA support board/ads5121/ads5121.c | 120 +- board/ads5121/ads5121_diu.c | 28 +++- common/cmd_ide.c |4 + cpu/mpc512x/Makefile |3 + cpu/mpc512x/iim.c| 394 ++ include/asm-ppc/immap_512x.h | 49 +- include/configs/ads5121.h| 58 ++ include/mpc512x.h| 25 +++ 8 files changed, 676 insertions(+), 5 deletions(-) create mode 100644 cpu/mpc512x/iim.c ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-Boot Hanging
Hi Afzal: Sounds like an issue where the fixed DRAM init did not work as it should. Try to pull the latest version of U-Boot, see if that helps. You may want to pull The latest from Stefan's tree as well. Feng Kan AMCC Software -Original Message- From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Afzal Nadirshah Sent: Tuesday, February 03, 2009 2:02 AM To: u-boot@lists.denx.de Subject: [U-Boot] U-Boot Hanging Hi, I have compiled u-boot (for nand flash, using canyonlands_nand_config) for the canyonlands board having a PPC460Ex. I have flashed the u-boot-nand.bin to the NAND flash. When I boot from the NAND flash the u-boot starts giving outputs onto minicom, but it hangs after just a few statements. U-Boot 1.3.4-00380-g302e52e (Sep 8 2008 - 15:37:41) CPU: AMCC PowerPC 460EX Rev. A at 600 MHz (PLB=200, OPB=100, EBC=100 MHz) Security/Kasumi support Bootstrap Option H - Boot ROM Location I2C (Addr 0x52) Internal PCI arbiter disabled 32 kB I-Cache 32 kB D-Cache Board: Canyonlands - AMCC PPC460EX Evaluation Board, 2*PCIe, Rev. 16 I2C: ready DTT: 1 is 47 C DRAM: 512 MB Has anybody faced this issue? Regards, Afzal Nadirshah http://www.mindtree.com/email/disclaimer.html ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Add support for the digsy MTC board.
Wolfgang Denk wrote:
> Dear Grzegorz,
>
> In message <12331552753467-git-send-email-...@semihalf.com> you wrote:
>> This is the InterControl custom device based on the MPC5200B chip.
> ...
>
> General comment: there is a lot of code which could use a few comments
> so the reader has a chance to understand what exactly you are doing.
>
>> --- /dev/null
>> +++ b/board/digsymtc/digsymtc.c
> ...
>> +static void sdram_start(int hi_addr)
>> +{
>> +long hi_addr_bit = hi_addr ? 0x0100 : 0;
>> +long control = SDRAM_CONTROL | hi_addr_bit;
>> +
>> +/* unlock mode register */
>> +*(vu_long *)MPC5XXX_SDRAM_CTRL = control | 0x8000;
>> +__asm__ volatile ("sync");
>> +
>> +/* precharge all banks */
>> +*(vu_long *)MPC5XXX_SDRAM_CTRL = control | 0x8002;
>> +__asm__ volatile ("sync");
>> +
>> +/* auto refresh */
>> +*(vu_long *)MPC5XXX_SDRAM_CTRL = control | 0x8004;
>> +__asm__ volatile ("sync");
>> +
>> +/* set mode register */
>> +*(vu_long *)MPC5XXX_SDRAM_MODE = SDRAM_MODE;
>> +__asm__ volatile ("sync");
>> +
>> +/* normal operation */
>> +*(vu_long *)MPC5XXX_SDRAM_CTRL = control;
>> +__asm__ volatile ("sync");
>
> Please use proper I/O accessor functions instead of volatile pointer
> accesses, here and in all other similar places as well...
>
> You can then get rid of the "sync"s as well.
>
Ok, I changed it in whole file.
>> +phys_size_t initdram(int board_type)
>> +{
>> +ulong dramsize = 0;
>> +ulong dramsize2 = 0;
>> +uint svr, pvr;
>> +#ifndef CONFIG_SYS_RAMBOOT
>> +ulong test1, test2;
>> +
>> +/* setup SDRAM chip selects */
>> +*(vu_long *)MPC5XXX_SDRAM_CS0CFG = 0x001C; /* 512MB at 0x0 */
>> +*(vu_long *)MPC5XXX_SDRAM_CS1CFG = 0x8000; /* disabled */
>
> ... like here and below.
>
>> +if (s != NULL) { puts(", "); puts(s); }
>
> Please use proper indentation.
>
ok, done
>> +void set_ethaddr(void)
>
> Please add "static" here.
>
ok, done
>> +int last_stage_init (void)
>> +{
>> +set_ethaddr();
>> +return 0;
>
> You should do this only as long as "ethaddr" is not already set in the
> environment.
>
ok, done
>> --- /dev/null
>> +++ b/board/digsymtc/eeprom.h
> ...
>> +
>> +#define EEPROM_ADDR CONFIG_SYS_I2C_EEPROM_ADDR
>> +#define EEPROM_LEN 1024
>> +#define EEPROM_IDENT2408
>> +#define EEPROM_ADDR_IDENT 0x
>> +#define EEPROM_ADDR_LEN_SYS 0x0002
>> +#define EEPROM_ADDR_LEN_SYSCFG 0x0004
>> +#define EEPROM_OFF_ETHADDR 23
>
> You want to add some comments what all these magic defines mean...
>
comments added
>> diff --git a/cpu/mpc5xxx/ide.c b/cpu/mpc5xxx/ide.c
>> index df5b4ac..07d33e3 100644
>> --- a/cpu/mpc5xxx/ide.c
>> +++ b/cpu/mpc5xxx/ide.c
>> @@ -12,7 +12,7 @@
>> *
>> * 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
>> + * 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
>
> Please don't arbitrarily reformat the code.
>
ok, I restored original layout
>> --- /dev/null
>> +++ b/include/configs/digsymtc.h
> ...
>> +#define CONFIG_PSC_CONSOLE 4 /* console is on PSC4 */
> ...
>> +"console=ttyPSC1\0" \
>
> This looks fishy to me - is it PSC1 or PSC4 ?
>
Linux enumerates ttyPSC starting from zero, so PSC3 is ttyPSC0 and
ttyPSC4 is ttyPSC4. Some time ago ttyPSC number could be enforced
by setting port-number field in dts, but lately it was removed.
>
>> +#define OF_CPU "PowerPC,5...@0"
>> +#define OF_SOC "soc5...@f000"
>> +#define OF_TBCLK(bd->bi_busfreq / 4)
>> +#define OF_STDOUT_PATH "/soc5...@f000/ser...@2600"
>
> Do we really need this?
OF_CPU, OF_SOC and OF_TBCLK is used and I removed OF_STDOUT_PATH.
regards,
Grzesiek
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] Add support for the digsy MTC board.
This is the InterControl custom device based on the MPC5200B chip.
Signed-off-by: Grzegorz Bernacki
---
Version 2:
- use I/O accessor functions instead of volatile pointer
- set ethernet address only if not set in environment
- add some comments and some style cleanup
MAKEALL |1 +
Makefile | 16 ++
board/digsy_mtc/Makefile | 51 ++
board/digsy_mtc/config.mk| 43 +
board/digsy_mtc/digsy_mtc.c | 330
board/digsy_mtc/eeprom.h | 32
board/digsy_mtc/is42s16800a-7t.h | 28 +++
cpu/mpc5xxx/ide.c|2 +-
drivers/net/mpc5xxx_fec.c|1 +
include/configs/digsy_mtc.h | 345 ++
10 files changed, 848 insertions(+), 1 deletions(-)
create mode 100644 board/digsy_mtc/Makefile
create mode 100644 board/digsy_mtc/config.mk
create mode 100644 board/digsy_mtc/digsy_mtc.c
create mode 100644 board/digsy_mtc/eeprom.h
create mode 100644 board/digsy_mtc/is42s16800a-7t.h
create mode 100644 include/configs/digsy_mtc.h
diff --git a/MAKEALL b/MAKEALL
index 530fe82..71ce43a 100755
--- a/MAKEALL
+++ b/MAKEALL
@@ -47,6 +47,7 @@ LIST_5xxx=" \
BC3450 \
cm5200 \
cpci5200\
+ digsy_mtc \
EVAL5200\
fo300 \
icecube_5100\
diff --git a/Makefile b/Makefile
index 8c73586..fed942e 100644
--- a/Makefile
+++ b/Makefile
@@ -527,6 +527,22 @@ cm5200_config: unconfig
cpci5200_config: unconfig
@$(MKCONFIG) -a cpci5200 ppc mpc5xxx cpci5200 esd
+digsy_mtc_config \
+digsy_mtc_LOWBOOT_config \
+digsy_mtc_RAMBOOT_config: unconfig
+ @mkdir -p $(obj)include
+ @mkdir -p $(obj)board/digsy_mtc
+ @ >$(obj)include/config.h
+ @[ -z "$(findstring LOWBOOT_,$@)" ] || \
+ { echo "TEXT_BASE = 0xFF00"
>$(obj)board/digsy_mtc/config.tmp ; \
+ echo "... with LOWBOOT configuration" ; \
+ }
+ @[ -z "$(findstring RAMBOOT_,$@)" ] || \
+ { echo "TEXT_BASE = 0x0010"
>$(obj)board/digsy_mtc/config.tmp ; \
+ echo "... with RAMBOOT configuration" ; \
+ }
+ @$(MKCONFIG) -a digsy_mtc ppc mpc5xxx digsy_mtc
+
hmi1001_config:unconfig
@$(MKCONFIG) hmi1001 ppc mpc5xxx hmi1001
diff --git a/board/digsy_mtc/Makefile b/board/digsy_mtc/Makefile
new file mode 100644
index 000..4bcb233
--- /dev/null
+++ b/board/digsy_mtc/Makefile
@@ -0,0 +1,51 @@
+
+#
+# (C) Copyright 2003-2009
+# 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 := $(BOARD).o
+
+SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c)
+OBJS := $(addprefix $(obj),$(COBJS))
+SOBJS := $(addprefix $(obj),$(SOBJS))
+
+$(LIB):$(obj).depend $(OBJS)
+ $(AR) $(ARFLAGS) $@ $(OBJS)
+
+clean:
+ rm -f $(SOBJS) $(OBJS)
+
+distclean: clean
+ rm -f $(LIB) core *.bak .depend
+
+#
+
+# defines $(obj).depend target
+include $(SRCTREE)/rules.mk
+
+sinclude $(obj).depend
+
+#
diff --git a/board/digsy_mtc/config.mk b/board/digsy_mtc/config.mk
new file mode 100644
index 000..f160674
--- /dev/null
+++ b/board/digsy_mtc/config.mk
@@ -0,0 +1,43 @@
+#
+# (C) Copyright 2003-2009
+# 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 sh
[U-Boot] U-Boot Hanging
Hi, I have compiled u-boot (for nand flash, using canyonlands_nand_config) for the canyonlands board having a PPC460Ex. I have flashed the u-boot-nand.bin to the NAND flash. When I boot from the NAND flash the u-boot starts giving outputs onto minicom, but it hangs after just a few statements. U-Boot 1.3.4-00380-g302e52e (Sep 8 2008 - 15:37:41) CPU: AMCC PowerPC 460EX Rev. A at 600 MHz (PLB=200, OPB=100, EBC=100 MHz) Security/Kasumi support Bootstrap Option H - Boot ROM Location I2C (Addr 0x52) Internal PCI arbiter disabled 32 kB I-Cache 32 kB D-Cache Board: Canyonlands - AMCC PPC460EX Evaluation Board, 2*PCIe, Rev. 16 I2C: ready DTT: 1 is 47 C DRAM: 512 MB Has anybody faced this issue? Regards, Afzal Nadirshah http://www.mindtree.com/email/disclaimer.html ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] lcd_putc bug?
In the lcd_putc() of common/lcd.c, line 189 handles tab '\t'. And the following lines: console_col |= 8; console_col &= ~7; seems to have problems. If console_col is 9, it will become 8 after the above two lines, which means instead of tab of 8 spaces, it goes back 1. Is this intentional or a bug? I think it should be console_col += 8; instead of console_col |= 8; Derek ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] usbtty: Added usbtty_configured() checks. Fixed attribute(packed) warnings.
Added usb_configured() checks in usbtty_puts() and usbtty_putc() to
get around a hang
when usb is not connected and the user has set up multi-io (setenv
stdout serial,usbtty etc).
Got rid of redundant __attribute__((packed)) directives that were
causing warnings from gcc.
Signed-off-by: Atin Malaviya
---
This makes the previous v1 patch in
http://lists.denx.de/pipermail/u-boot/2009-February/046705.html
obsolete. This patch is against the mainline u-boot next branch.
drivers/serial/usbtty.c | 18 +++---
1 files changed, 11 insertions(+), 7 deletions(-)
diff --git a/drivers/serial/usbtty.c b/drivers/serial/usbtty.c
index 7eba470..2624e6f 100644
--- a/drivers/serial/usbtty.c
+++ b/drivers/serial/usbtty.c
@@ -150,8 +150,7 @@ struct acm_config_desc {
/* Slave Interface */
struct usb_interface_descriptor data_class_interface;
- struct usb_endpoint_descriptor
- data_endpoints[NUM_ENDPOINTS-1] __attribute__((packed));
+ struct usb_endpoint_descriptor data_endpoints[NUM_ENDPOINTS-1];
} __attribute__((packed));
static struct acm_config_desc
acm_configuration_descriptors[NUM_CONFIGS] = {
@@ -280,10 +279,8 @@ static struct rs232_emu rs232_desc={
struct gserial_config_desc {
struct usb_configuration_descriptor configuration_desc;
- struct usb_interface_descriptor
- interface_desc[NUM_GSERIAL_INTERFACES] __attribute__((packed));
- struct usb_endpoint_descriptor
- data_endpoints[NUM_ENDPOINTS] __attribute__((packed));
+ struct usb_interface_descriptor
interface_desc[NUM_GSERIAL_INTERFACES];
+ struct usb_endpoint_descriptor data_endpoints[NUM_ENDPOINTS];
} __attribute__((packed));
@@ -433,6 +430,9 @@ int usbtty_getc (void)
*/
void usbtty_putc (const char c)
{
+ if (!usbtty_configured ())
+ return;
+
buf_push (&usbtty_output, &c, 1);
/* If \n, also do \r */
if (c == '\n')
@@ -486,8 +486,12 @@ static void __usbtty_puts (const char *str, int
len)
void usbtty_puts (const char *str)
{
int n;
- int len = strlen (str);
+ int len;
+
+ if (!usbtty_configured ())
+ return;
+ len = strlen (str);
/* add '\r' for each '\n' */
while (len > 0) {
n = next_nl_pos (str);
--
1.5.6.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] lcd_putc bug?
Dear Derek Ou, In message <49889076.5010...@siconix.com> you wrote: > In the lcd_putc() of common/lcd.c, line 189 handles tab '\t'. And the > following lines: > console_col |= 8; > console_col &= ~7; > seems to have problems. If console_col is 9, it will become 8 after the > above two lines, which means instead of tab of 8 spaces, it goes back > 1. Is this intentional or a bug? > > I think it should be console_col += 8; instead of console_col |= 8; I think you are right - can you please submit a patch? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de A student of probability soon realizes that by its nature the billion-to-one chance crops up nine times out of ten, and that the greatest odds boil down to a double-sided statement: it will happen, or it will not. - Terry Pratchett, _The Dark Side of the Sun_ ___ 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 Tuesday 03 February 2009 03:16:27 Wolfgang Denk wrote:
> Dear Mike Frysinger,
>
> In message <200902021937.26246.vap...@gentoo.org> you wrote:
> > > 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.
>
> No, that would mix functions in a bad way as it creates new
> dependencies on what can or must be done when. env_init() in sone
> thing (initializes the environment data), but global data init is
> another issue.
>
> Maybe we should try and collect the global data initialization into
> one place - but I have to admit that I don't know if or how easily
> this can be done.
trying to do it in one go will probably be ugly and break crap, so i think
starting with a few pieces and expanding from there is fine. in this case,
we'll start with updating all the lib_*/board.c files to call global_init()
and that will in turn start with setting up bi_enetaddr.
> > > 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.
>
> Well, I think we agree that the current state is a mess. Documenting
> the mess makes it easier to add to it. But should we not try to clean
> up instead? I.e. document what we think should be done, and fix the
> implementation accordingly?
yes, but having the documentation say one thing and the actual implementation
do something completely different leads to confusion. people dont know
whether the documentation is out of date, plain wrong, or what. to both ends,
we can have the documentation read what *should* be happening and then add a
note about what *actually* is happening and how it needs to be changed.
> > 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 ...
>
> Agreed - that needs to be fixed, too.
so does it make sense for the env code to even be calling eth_set_enetaddr() ?
after all, any network operation will call the eth init code which will take
care of rereading the mac address from the env/global data.
also, are you saying that the current method of a static # of ethernet devices
is the way to go ? we'll have to maintain a hardcoded list of places like:
#ifdef CONFIG_HAS_ETH1
... work with bi_enet1addr ...
#endif
#ifdef CONFIG_HAS_ETH2
... do same thing but now with bi_enet2addr ...
#endif
#ifdef CONFIG_HAS_ETH3
... do same thing but now with bi_enet3addr ...
#endif
#ifdef CONFIG_HAS_ETH4
... do same thing but now with bi_enet4addr ...
#endif
i think we can agree that this does not scale at all. if, however, we change
the global data to something like:
typedef struct bd_info {
...
#ifdef CONFIG_NET_MULTI
uchar bi_enetXaddr[CONFIG_NET_MULTI_MAX][6];
# define bi_enetaddr bi_enetXaddr[0]
#else
uchar bi_enetaddr[6];
#endif
...
};
then we should be able to scale nicely ?
-mike
signature.asc
Description: This is a digitally signed message part.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] integratorap: fix PCI support
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD --- include/configs/integratorap.h |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/include/configs/integratorap.h b/include/configs/integratorap.h index 6ce3b4d..d7f617f 100644 --- a/include/configs/integratorap.h +++ b/include/configs/integratorap.h @@ -143,7 +143,7 @@ * PCI definitions */ -/*#define CONFIG_PCI /--* include pci support*/ +#ifdef CONFIG_PCI /* pci support */ #undef CONFIG_PCI_PNP #define CONFIG_PCI_SCAN_SHOW 1 /* show pci devices on startup */ #define DEBUG @@ -151,7 +151,6 @@ #define CONFIG_EEPRO100 #define CONFIG_SYS_RX_ETH_BUFFER 8 /* use 8 rx buffer on eepro100 */ - #define INTEGRATOR_BOOT_ROM_BASE 0x2000 #define INTEGRATOR_HDR0_SDRAM_BASE 0x8000 @@ -279,6 +278,7 @@ #define INTEGRATOR_SC_PCIENABLE \ (INTEGRATOR_SC_BASE + INTEGRATOR_SC_PCIENABLE_OFFSET) +#endif /* CONFIG_PCI */ /*--- * There are various dependencies on the core module (CM) fitted * Users should refer to their CM user guide -- 1.5.6.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3] Added usbtty_configured() check. Fixed attribute(packed) warnings.
V3: Fixed line-wrap problem due to user error in mail!
Added usb_configured() checks in usbtty_puts() and usbtty_putc() to get around
a hang
when usb is not connected and the user has set up multi-io (setenv stdout
serial,usbtty etc).
Got rid of redundant __attribute__((packed)) directives that were causing
warnings from gcc.
Signed-off-by: Atin Malaviya
---
This makes the previous v2 patch in
http://lists.denx.de/pipermail/u-boot/2009-February/046716.html obsolete. This
patch is
against the mainline u-boot next branch.
drivers/serial/usbtty.c | 18 +++---
1 files changed, 11 insertions(+), 7 deletions(-)
diff --git a/drivers/serial/usbtty.c b/drivers/serial/usbtty.c
index 7eba470..2624e6f 100644
--- a/drivers/serial/usbtty.c
+++ b/drivers/serial/usbtty.c
@@ -150,8 +150,7 @@ struct acm_config_desc {
/* Slave Interface */
struct usb_interface_descriptor data_class_interface;
- struct usb_endpoint_descriptor
- data_endpoints[NUM_ENDPOINTS-1] __attribute__((packed));
+ struct usb_endpoint_descriptor data_endpoints[NUM_ENDPOINTS-1];
} __attribute__((packed));
static struct acm_config_desc acm_configuration_descriptors[NUM_CONFIGS] = {
@@ -280,10 +279,8 @@ static struct rs232_emu rs232_desc={
struct gserial_config_desc {
struct usb_configuration_descriptor configuration_desc;
- struct usb_interface_descriptor
- interface_desc[NUM_GSERIAL_INTERFACES] __attribute__((packed));
- struct usb_endpoint_descriptor
- data_endpoints[NUM_ENDPOINTS] __attribute__((packed));
+ struct usb_interface_descriptor interface_desc[NUM_GSERIAL_INTERFACES];
+ struct usb_endpoint_descriptor data_endpoints[NUM_ENDPOINTS];
} __attribute__((packed));
@@ -433,6 +430,9 @@ int usbtty_getc (void)
*/
void usbtty_putc (const char c)
{
+ if (!usbtty_configured ())
+ return;
+
buf_push (&usbtty_output, &c, 1);
/* If \n, also do \r */
if (c == '\n')
@@ -486,8 +486,12 @@ static void __usbtty_puts (const char *str, int len)
void usbtty_puts (const char *str)
{
int n;
- int len = strlen (str);
+ int len;
+
+ if (!usbtty_configured ())
+ return;
+ len = strlen (str);
/* add '\r' for each '\n' */
while (len > 0) {
n = next_nl_pos (str);
--
1.5.6.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] flash/cfi_flash: Use virtual sector start address, not phys
On Feb 3, 2009, at 8:48 AM, Kumar Gala wrote:
>
> On Feb 3, 2009, at 2:53 AM, Pieter wrote:
>
>>>
>>> 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);
>>> }
>>
>>
>> Since "flash_unmap(flash_info_t *info, flash_sect_t sect,unsigned
>> int offset, void *addr)" function is empty after applying the
>> patch, should all function calls in the /drivers/mtd/cfi_flash.c
>> file not also be removed?
>>
>> cheers pieter
>
> I think its best to leave them alone for now. If in the future we
> really think flash_unmap isn't going to get called we can remove
> them. Stefan?
>
I left those in case there might later be something that needs to be
done there, so that flash_map/unmap remain symmetric. But I can
remove them if Stefan wants.
Cheers,
B
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Add support for setting environment variable from RAM.
Wolfgang Denk wrote: > Dear Eric, > > In message <4988936e.3070...@boundarydevices.com> you wrote: >>> In the email thread you mentioned above, Detlev mentions 2 alternatives >>> to the "ramenv" command - loading a uImage script and running it via >>> autoscr, or modifying autoscr to be able to raw files (non-uImages). >>> Both of these methods seem cleaner and more flexible at a glance. Is >>> there a specific reason using autoscr wouldn't work for your setup? >>> >> The customer requesting this feature operates in a regulated environment with >> pretty strict rules about separation of code and data. Autoscr is kind of >> a big stick for what we're trying to achieve: (configuring an LCD with >> settings from a file on SD card). > > Why is it a big stick? It has a couple of significant advantages over > your implementation: > No offense intended ;) Perhaps I should have said it was a much more powerful feature. > * It already exissts in mainline. > * It can set several environment variables at once (and also perform > any other commands you might need on your system). > * It is based on text files which are easy to edit without need for > new tools. > * It will verify that your file has been transmitted correctly. > Don't get me wrong, I'm a big fan of autoscr. As I mentioned, the customer requesting the feature has a regulatory requirement any time __code__ changes. They have interpreted boot loader scripts as being executable, so they have to write checks if the script changes, but not if "data" changes. They interpret a file containing a variable as data. Of course they'll need a code release to get there, ... >> Our particular need is just for a single environment variable, so the >> update works pretty well. I started by updating our 'lcdpanel' U-Boot >> command to read from file, but this is much more useful. > > I suggest you use autoscr instead. > > I think I will reject your patch. > That's reasonable. I don't mind carrying the patch around for this customer, and you're the one preventing U-Boot from becoming bloated over time. I appreciate all of your efforts. Regards, Eric ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] ppc4xx: Only fixup opb attached UARTs
This patch updates the fdt UART clock fixup code to
only touch CPU internal UARTs on 4xx systems.
Only these UARTs are definitely clocked by gd->uart_clk.
Signed-off-by: Matthias Fuchs
---
cpu/ppc4xx/fdt.c | 24 ++--
1 files changed, 22 insertions(+), 2 deletions(-)
diff --git a/cpu/ppc4xx/fdt.c b/cpu/ppc4xx/fdt.c
index c55e1cf..ba5c120 100644
--- a/cpu/ppc4xx/fdt.c
+++ b/cpu/ppc4xx/fdt.c
@@ -113,6 +113,7 @@ void fdt_pcie_setup(void *blob)
void ft_cpu_setup(void *blob, bd_t *bd)
{
sys_info_t sys_info;
+ int off, ndepth = 0;
get_sys_info(&sys_info);
@@ -133,9 +134,28 @@ void ft_cpu_setup(void *blob, bd_t *bd)
fdt_fixup_memory(blob, (u64)bd->bi_memstart, (u64)bd->bi_memsize);
/*
-* Setup all baudrates for the UARTs
+* Fixup all UART clocks for CPU internal UARTs
+* (only these UARTs are definitely clocked by gd->uart_clk)
+*
+* These UARTs are direct childs of /plb/opb. This code
+* does not touch any UARTs that are connected to the ebc.
*/
- 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;
+
+ /* only update direct childs */
+ if ((ndepth == 1) &&
+ (fdt_node_check_compatible(blob, off, "ns16550") == 0))
+ fdt_setprop(blob, off,
+ "clock-frequency",
+ (void*)&(gd->uart_clk), 4);
+ }
/*
* Fixup all ethernet nodes
--
1.5.6.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Add support for setting environment variable from RAM.
Dear Eric Nelson, In message <4988bbc0.4070...@boundarydevices.com> you wrote: > > As I mentioned, the customer requesting the feature has a regulatory > requirement any time __code__ changes. They have interpreted boot loader > scripts as being executable, so they have to write checks if the script > changes, but not if "data" changes. They interpret a file containing a > variable as data. Hm... If we think this to a logical end that would mean that you have to disable the setenv command completely, as any variable can in fact contain a sequence of commands that might get run, thus environment data should be treated as code ;-) > > I think I will reject your patch. > > > That's reasonable. I don't mind carrying the patch around for this customer, > and you're the one preventing U-Boot from becoming bloated over time. > > I appreciate all of your efforts. Thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de A person who is more than casually interested in computers should be well schooled in machine language, since it is a fundamental part of a computer. -- Donald Knuth ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Pull request u-boot-blackfin.git
Dear Mike Frysinger,
In message <1233596548-5716-1-git-send-email-vap...@gentoo.org> you wrote:
> (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
Applied, thanks.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
Nothing is easier than to denounce the evildoer; nothing is more
difficult than to understand him. - Fyodor Dostoevski
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boo
Re: [U-Boot] Pull request: u-boot-usb
Dear Remy Bohmer, In message <3efb10970902031137u55743e48j6384f205d3326...@mail.gmail.com> you wrote: > 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://git.denx.de/u-boot-usb.git master > > Remy Bohmer (1): > Compile warning fix in onenand_uboot.h > > Stefan Roese (1): > USB: Add EHCI support for VCT EHCI controller (really with driver now) > > drivers/usb/usb_ehci_vct.c | 58 > > include/onenand_uboot.h|2 + > 2 files changed, 60 insertions(+), 0 deletions(-) > create mode 100644 drivers/usb/usb_ehci_vct.c Applied, thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Gewöhnlich glaubt der Mensch, wenn er nur Worte hört, es müsse sich dabei doch auch was denken lassen. -- Goethe, Faust I ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/1] pxa: move mmc drivers to drivers/mmc
introduce new macro CONFIG_PXA_MMC to activate it
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD
---
cpu/pxa/Makefile |2 +-
drivers/mmc/Makefile |1 +
cpu/pxa/mmc.c => drivers/mmc/pxa_mmc.c |4
include/configs/delta.h|7 +--
include/configs/lubbock.h |7 +--
include/configs/pleb2.h|5 +
include/configs/pxa255_idp.h |5 -
include/configs/trizepsiv.h|5 -
include/configs/xsengine.h |8 ++--
include/configs/zylonite.h |8 ++--
10 files changed, 37 insertions(+), 15 deletions(-)
rename cpu/pxa/mmc.c => drivers/mmc/pxa_mmc.c (99%)
diff --git a/cpu/pxa/Makefile b/cpu/pxa/Makefile
index 8b4367e..42903b2 100644
--- a/cpu/pxa/Makefile
+++ b/cpu/pxa/Makefile
@@ -26,7 +26,7 @@ include $(TOPDIR)/config.mk
LIB= $(obj)lib$(CPU).a
START = start.o
-COBJS = serial.o interrupts.o cpu.o i2c.o pxafb.o mmc.o usb.o
+COBJS = serial.o interrupts.o cpu.o i2c.o pxafb.o usb.o
SRCS := $(START:.o=.S) $(SOBJS:.o=.S) $(COBJS:.o=.c)
OBJS := $(addprefix $(obj),$(SOBJS) $(COBJS))
diff --git a/drivers/mmc/Makefile b/drivers/mmc/Makefile
index bb0d52e..b5f1b20 100644
--- a/drivers/mmc/Makefile
+++ b/drivers/mmc/Makefile
@@ -27,6 +27,7 @@ LIB := $(obj)libmmc.a
COBJS-$(CONFIG_ATMEL_MCI) += atmel_mci.o
COBJS-$(CONFIG_OMAP3_MMC) += omap3_mmc.o
+COBJS-$(CONFIG_PXA_MMC) += pxa_mmc.o
COBJS := $(COBJS-y)
SRCS := $(COBJS:.o=.c)
diff --git a/cpu/pxa/mmc.c b/drivers/mmc/pxa_mmc.c
similarity index 99%
rename from cpu/pxa/mmc.c
rename to drivers/mmc/pxa_mmc.c
index d735c8d..c7fa1ca 100644
--- a/cpu/pxa/mmc.c
+++ b/drivers/mmc/pxa_mmc.c
@@ -28,8 +28,6 @@
#include
#include
-#ifdef CONFIG_MMC
-
extern int fat_register_device(block_dev_desc_t * dev_desc, int part_no);
static block_dev_desc_t mmc_dev;
@@ -658,5 +656,3 @@ int mmc2info(ulong addr)
}
return 0;
}
-
-#endif /* CONFIG_MMC */
diff --git a/include/configs/delta.h b/include/configs/delta.h
index abb2676..1ee9712 100644
--- a/include/configs/delta.h
+++ b/include/configs/delta.h
@@ -34,7 +34,6 @@
#ifdef CONFIG_LCD
#define CONFIG_SHARP_LM8V31
#endif
-/* #define CONFIG_MMC 1 */
#define BOARD_LATE_INIT1
#undef CONFIG_SKIP_RELOCATE_UBOOT
@@ -181,7 +180,11 @@
/* valid baudrates */
#define CONFIG_SYS_BAUDRATE_TABLE { 9600, 19200, 38400, 57600, 115200 }
-/* #define CONFIG_SYS_MMC_BASE 0xF000 */
+#ifdef CONFIG_MMC
+#define CONFIG_PXA_MMC
+#define CONFIG_CMD_MMC
+#define CONFIG_SYS_MMC_BASE0xF000
+#endif
/*
* Stack sizes
diff --git a/include/configs/lubbock.h b/include/configs/lubbock.h
index 208910e..ef16b02 100644
--- a/include/configs/lubbock.h
+++ b/include/configs/lubbock.h
@@ -40,7 +40,7 @@
#ifdef CONFIG_LCD
#define CONFIG_SHARP_LM8V31
#endif
-#define CONFIG_MMC 1
+#define CONFIG_MMC
#define BOARD_LATE_INIT1
#define CONFIG_DOS_PARTITION
@@ -83,7 +83,6 @@
*/
#include
-#define CONFIG_CMD_MMC
#define CONFIG_CMD_FAT
@@ -133,7 +132,11 @@
/* valid baudrates */
#define CONFIG_SYS_BAUDRATE_TABLE { 9600, 19200, 38400, 57600, 115200 }
+#ifdef CONFIG_MMC
+#define CONFIG_PXA_MMC
+#define CONFIG_CMD_MMC
#define CONFIG_SYS_MMC_BASE0xF000
+#endif
/*
* Stack sizes
diff --git a/include/configs/pleb2.h b/include/configs/pleb2.h
index 14f8917..59dffb7 100644
--- a/include/configs/pleb2.h
+++ b/include/configs/pleb2.h
@@ -132,6 +132,11 @@
/* valid baudrates */
#define CONFIG_SYS_BAUDRATE_TABLE { 9600, 19200, 38400, 57600, 115200 }
+#ifdef CONFIG_MMC
+#define CONFIG_PXA_MMC
+#define CONFIG_CMD_MMC
+#endif
+
/*
* Stack sizes
*
diff --git a/include/configs/pxa255_idp.h b/include/configs/pxa255_idp.h
index f81103b..2deee02 100644
--- a/include/configs/pxa255_idp.h
+++ b/include/configs/pxa255_idp.h
@@ -119,7 +119,6 @@
*/
#include
-#define CONFIG_CMD_MMC
#define CONFIG_CMD_FAT
#define CONFIG_CMD_DHCP
@@ -249,7 +248,11 @@
/* valid baudrates */
#define CONFIG_SYS_BAUDRATE_TABLE { 9600, 19200, 38400, 57600, 115200 }
+#ifdef CONFIG_MMC
+#define CONFIG_PXA_MMC
+#define CONFIG_CMD_MMC
#define CONFIG_SYS_MMC_BASE0xF000
+#endif
/*
* Stack sizes
diff --git a/include/configs/trizepsiv.h b/include/configs/trizepsiv.h
index 0a8e994..784a09f 100644
--- a/include/configs/trizepsiv.h
+++ b/include/configs/trizepsiv.h
@@ -79,7 +79,6 @@
*/
#include
-#define CONFIG_CMD_MMC
#define CONFIG_CMD_FAT
#define CONFIG_CMD_IMLS
#define CONFIG_CMD_PING
@@ -174,7 +173,11 @@
/* valid baudrates */
#define CONFIG_SYS_BAUDRATE_TABLE { 9600, 19200, 3
[U-Boot] [PATCH 4/8 V2] Reduce the scope of PXA's mmc_read/mmc_write/mmc_bread functions
From: Andy Fleming
These names are being taken over by the new MMC framework. Hopefuly
the PXA can be easily ported, and these functions will go away entirely.
Signed-off-by: Andy Fleming
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD
---
drivers/mmc/pxa_mmc.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/mmc/pxa_mmc.c b/drivers/mmc/pxa_mmc.c
index c7fa1ca..f3cb60a 100644
--- a/drivers/mmc/pxa_mmc.c
+++ b/drivers/mmc/pxa_mmc.c
@@ -214,7 +214,7 @@ mmc_block_write(ulong dst, uchar * src, int len)
int
//
-mmc_read(ulong src, uchar * dst, int size)
+pxa_mmc_read(long src, uchar * dst, int size)
//
{
ulong end, part_start, part_end, part_len, aligned_start, aligned_end;
@@ -290,7 +290,7 @@ mmc_read(ulong src, uchar * dst, int size)
int
//
-mmc_write(uchar * src, ulong dst, int size)
+pxa_mmc_write(uchar * src, ulong dst, int size)
//
{
ulong end, part_start, part_end, part_len, aligned_start, aligned_end;
@@ -371,7 +371,7 @@ mmc_write(uchar * src, ulong dst, int size)
return 0;
}
-ulong
+static ulong
//
mmc_bread(int dev_num, ulong blknr, lbaint_t blkcnt, void *dst)
//
@@ -379,7 +379,7 @@ mmc_bread(int dev_num, ulong blknr, lbaint_t blkcnt, void
*dst)
int mmc_block_size = MMC_BLOCK_SIZE;
ulong src = blknr * mmc_block_size + CONFIG_SYS_MMC_BASE;
- mmc_read(src, (uchar *) dst, blkcnt * mmc_block_size);
+ pxa_mmc_read(src, (uchar *) dst, blkcnt * mmc_block_size);
return blkcnt;
}
--
1.5.6.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [GIT PULL] Please pull mpc5xxx tree
The following changes since commit 92c20fbd3a7788c1a154f50a3f44f28a7763f99a: John Rigby (1): ADS5121 DIU Make inclusion of FSL logo optional are available in the git repository at: http://git.denx.de/u-boot-mpc5xxx.git master John Rigby (2): ADS5121 DIU Add diu_bmp_addr env ADS5121 Fix rev2 silicon pci iopad config Martha Marx (1): ADS5121 Add IC Ident Module (IIM) support Ralph Kondziella (1): ADS5121 Add PATA support board/ads5121/ads5121.c | 120 +- board/ads5121/ads5121_diu.c | 28 +++- common/cmd_ide.c |4 + cpu/mpc512x/Makefile |3 + cpu/mpc512x/iim.c| 394 ++ include/asm-ppc/immap_512x.h | 49 +- include/configs/ads5121.h| 58 ++ include/mpc512x.h| 25 +++ 8 files changed, 676 insertions(+), 5 deletions(-) create mode 100644 cpu/mpc512x/iim.c ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] lcd_putc bug fix for tab.
Signed-off-by: Derek Ou
---
common/lcd.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/common/lcd.c b/common/lcd.c
index 5f73247..2bcdba2 100644
--- a/common/lcd.c
+++ b/common/lcd.c
@@ -187,7 +187,7 @@ void lcd_putc (const char c)
return;
case '\t': /* Tab (8 chars alignment) */
- console_col |= 8;
+ console_col += 8;
console_col &= ~7;
if (console_col >= CONSOLE_COLS) {
--
1.5.4.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] using more that 2gig of Memory.
I have search through the archives, and didn't find anything. Has anyone setup u-boot to configure more than 2gig of main memory? Where does u-boot go in the 36 bit world.  is it possible to configure 2gig on each DDR controller of the MPC8572 and have u-boot run right out of the box? I know u-boot load itself way out at the end of memory, but in this case, that would be 0x1-fff8- ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [GIT PULL] Please pull mpc5xxx tree
Dear John, In message <498876f3.2070...@freescale.com> you wrote: > Wolfgang, > > The following changes since commit 92c20fbd3a7788c1a154f50a3f44f28a7763f99a: >John Rigby (1): > ADS5121 DIU Make inclusion of FSL logo optional > > are available in the git repository at: > >http://git.denx.de/u-boot-mpc5xxx.git master > > John Rigby (3): >ADS5121 DIU Add diu_bmp_addr env >ADS5121 Fix rev2 silicon pci iopad config >ADS5121 Add IC Ident Module (IIM) support > > Ralph Kondziella (1): >ADS5121 Add PATA support Sorry, but I hesitate pulling this. Commit 430b071b09 in your tree shows: Author: John Rigby 2009-01-26 18:45:07 Committer: John Rigby 2009-02-03 17:28:40 ADS5121 Add IC Ident Module (IIM) support To me it seems to match to Subject: [U-Boot] [PATCH] Add IC Identif Module (IIM) support for ADS5121 From: Martha Marx Date: Sat, 11 Oct 2008 15:34:22 -0400 To: u-boot@lists.denx.de so I would expect to see Martha listed as author? I am aware of your reposted patch Subject: [PATCH 4/5] ADS5121 Add IC Ident Module (IIM) support From: John Rigby Date: Mon, 26 Jan 2009 13:07:07 -0700 To: u-boot@lists.denx.de, ... but I feel authorship should be preserved here. What do you think? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de I don't care if you *ARE* on a bondage-and-discipline post-technical system pawned off by the nation's largest oughta-be-illegal monopoly who cannot escape the sins of their forefathers -- namely, using the wrong slash for directories when the C language and its brethren use it for something else that's very important. -- Tom Christiansen in <55oabg$1j...@csnews.cs.colorado.edu> ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 6/7] Blackfin: dynamically update UART speed when initializing
Previously, booting over the UART required the baud rate to be known ahead
of time. Using a bit of tricky simple math, we can calculate the new board
rate based on the old divisors.
Signed-off-by: Mike Frysinger
Signed-off-by: Robin Getz
---
cpu/blackfin/initcode.c | 62 +++
cpu/blackfin/serial.h | 72 --
2 files changed, 43 insertions(+), 91 deletions(-)
diff --git a/cpu/blackfin/initcode.c b/cpu/blackfin/initcode.c
index 0fdaf40..60a0554 100644
--- a/cpu/blackfin/initcode.c
+++ b/cpu/blackfin/initcode.c
@@ -20,7 +20,7 @@
#include "serial.h"
__attribute__((always_inline))
-static inline uint32_t serial_init(void)
+static inline void serial_init(void)
{
#ifdef __ADSPBF54x__
# ifdef BFIN_BOOT_UART_USE_RTS
@@ -61,25 +61,16 @@ static inline uint32_t serial_init(void)
}
#endif
- uint32_t old_baud;
- if (BFIN_DEBUG_EARLY_SERIAL || CONFIG_BFIN_BOOT_MODE == BFIN_BOOT_UART)
- old_baud = serial_early_get_baud();
- else
- old_baud = CONFIG_BAUDRATE;
-
if (BFIN_DEBUG_EARLY_SERIAL) {
+ int ucen = *pUART_GCTL & UCEN;
serial_early_init();
/* If the UART is off, that means we need to program
* the baud rate ourselves initially.
*/
- if (!old_baud) {
- old_baud = CONFIG_BAUDRATE;
+ if (ucen != UCEN)
serial_early_set_baud(CONFIG_BAUDRATE);
- }
}
-
- return old_baud;
}
__attribute__((always_inline))
@@ -93,30 +84,6 @@ static inline void serial_deinit(void)
#endif
}
-/* We need to reset the baud rate when we have early debug turned on
- * or when we are booting over the UART.
- * XXX: we should fix this to calc the old baud and restore it rather
- * than hardcoding it via CONFIG_LDR_LOAD_BAUD ... but we have
- * to figure out how to avoid the division in the baud calc ...
- */
-__attribute__((always_inline))
-static inline void serial_reset_baud(uint32_t baud)
-{
- if (!BFIN_DEBUG_EARLY_SERIAL && CONFIG_BFIN_BOOT_MODE != BFIN_BOOT_UART)
- return;
-
-#ifndef CONFIG_LDR_LOAD_BAUD
-# define CONFIG_LDR_LOAD_BAUD 115200
-#endif
-
- if (CONFIG_BFIN_BOOT_MODE == BFIN_BOOT_BYPASS)
- serial_early_set_baud(baud);
- else if (CONFIG_BFIN_BOOT_MODE == BFIN_BOOT_UART)
- serial_early_set_baud(CONFIG_LDR_LOAD_BAUD);
- else
- serial_early_set_baud(CONFIG_BAUDRATE);
-}
-
__attribute__((always_inline))
static inline void serial_putc(char c)
{
@@ -239,7 +206,14 @@ static inline void serial_putc(char c)
__attribute__((saveall))
void initcode(ADI_BOOT_DATA *bootstruct)
{
- uint32_t old_baud = serial_init();
+ /* Save the clock pieces that are used in baud rate calculation */
+ unsigned int sdivB, divB, vcoB;
+ serial_init();
+ if (BFIN_DEBUG_EARLY_SERIAL || CONFIG_BFIN_BOOT_MODE == BFIN_BOOT_UART)
{
+ sdivB = bfin_read_PLL_DIV() & 0xf;
+ vcoB = (bfin_read_PLL_CTL() >> 9) & 0x3f;
+ divB = serial_early_get_div();
+ }
#ifdef CONFIG_HW_WATCHDOG
# ifndef CONFIG_HW_WATCHDOG_TIMEOUT_INITCODE
@@ -334,8 +308,20 @@ void initcode(ADI_BOOT_DATA *bootstruct)
/* Since we've changed the SCLK above, we may need to update
* the UART divisors (UART baud rates are based on SCLK).
+* Do the division by hand as there are no native instructions
+* for dividing which means we'd generate a libgcc reference.
*/
- serial_reset_baud(old_baud);
+ if (CONFIG_BFIN_BOOT_MODE == BFIN_BOOT_UART) {
+ unsigned int sdivR, vcoR;
+ sdivR = bfin_read_PLL_DIV() & 0xf;
+ vcoR = (bfin_read_PLL_CTL() >> 9) & 0x3f;
+ int dividend = sdivB * divB * vcoR;
+ int divisor = vcoB * sdivR;
+ unsigned int quotient;
+ for (quotient = 0; dividend > 0; ++quotient)
+ dividend -= divisor;
+ serial_early_put_div(quotient - ANOMALY_05000230);
+ }
serial_putc('F');
diff --git a/cpu/blackfin/serial.h b/cpu/blackfin/serial.h
index f671096..ce39148 100644
--- a/cpu/blackfin/serial.h
+++ b/cpu/blackfin/serial.h
@@ -156,16 +156,25 @@ static inline void serial_early_init(void)
}
__attribute__((always_inline))
-static inline uint32_t serial_early_get_baud(void)
+static inline void serial_early_put_div(uint16_t divisor)
{
- /* If the UART isnt enabled, then we are booting an LDR
-* from a non-UART source (so like flash) which means
-* the baud rate here is meaningless.
-*/
- if ((*pUART_GCTL & UCEN) != UCEN)
- return 0;
+ /* Set DLAB in LCR to Access DLL and DLH */
+ ACCESS_LATCH();
+ SSYNC();
-#if (0)/*
[U-Boot] [PATCH 5/7] Blackfin: add support for fast SPI reads with Boot ROM
Newer Blackfin boot roms support using the fast SPI read command rather than
just the slow one. If the functionality is available, then use it.
Signed-off-by: Mike Frysinger
---
cpu/blackfin/initcode.c | 25 +
1 files changed, 17 insertions(+), 8 deletions(-)
diff --git a/cpu/blackfin/initcode.c b/cpu/blackfin/initcode.c
index a6e95f4..0fdaf40 100644
--- a/cpu/blackfin/initcode.c
+++ b/cpu/blackfin/initcode.c
@@ -133,12 +133,22 @@ static inline void serial_putc(char c)
}
-/* Max SCLK can be 133MHz ... dividing that by 4 gives
- * us a freq of 33MHz for SPI which should generally be
+/* Max SCLK can be 133MHz ... dividing that by (2*4) gives
+ * us a freq of 16MHz for SPI which should generally be
* slow enough for the slow reads the bootrom uses.
*/
+#if !defined(CONFIG_SPI_FLASH_SLOW_READ) && \
+((defined(__ADSPBF52x__) && __SILICON_REVISION__ >= 2) || \
+ (defined(__ADSPBF54x__) && __SILICON_REVISION__ >= 1))
+# define BOOTROM_SUPPORTS_SPI_FAST_READ 1
+#else
+# define BOOTROM_SUPPORTS_SPI_FAST_READ 0
+#endif
#ifndef CONFIG_SPI_BAUD_INITBLOCK
-# define CONFIG_SPI_BAUD_INITBLOCK 4
+# define CONFIG_SPI_BAUD_INITBLOCK (BOOTROM_SUPPORTS_SPI_FAST_READ ? 2 : 4)
+#endif
+#ifdef SPI0_BAUD
+# define bfin_write_SPI_BAUD bfin_write_SPI0_BAUD
#endif
/* PLL_DIV defines */
@@ -254,12 +264,11 @@ void initcode(ADI_BOOT_DATA *bootstruct)
* boot. Once we switch over to u-boot's SPI flash driver, we'll
* increase the speed appropriately.
*/
- if (CONFIG_BFIN_BOOT_MODE == BFIN_BOOT_SPI_MASTER)
-#ifdef SPI0_BAUD
- bfin_write_SPI0_BAUD(CONFIG_SPI_BAUD_INITBLOCK);
-#else
+ if (CONFIG_BFIN_BOOT_MODE == BFIN_BOOT_SPI_MASTER) {
+ if (BOOTROM_SUPPORTS_SPI_FAST_READ && CONFIG_SPI_BAUD_INITBLOCK
< 4)
+ bootstruct->dFlags |= BFLAG_FASTREAD;
bfin_write_SPI_BAUD(CONFIG_SPI_BAUD_INITBLOCK);
-#endif
+ }
serial_putc('B');
--
1.6.1.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 00/08 V2] Allow PCI bus address, PA, and VA to differ
This is resubmit of a series I sent back in December - I've rebased to the latest tree and split out a couple of the patches as requested. This patch series cleans up much of the VA/PA/PCI bus address confusion that is is currently causing a couple of problems on the 8641 36-bit port, and was preventing us from having a PCI mem bus address that differed from the virtual address of the region. I have fixed a number of problems, such as the ahci driver directly using the pci BAR setting as a virtual address and pci window mapping overlap. There's also some cleanup to the BAT code that were needed to make some of this cleaner. Cheers, Becky The diffstat: board/alaska/alaska.c | 36 +++--- board/etin/debris/flash.c |1 + board/etin/kvme080/kvme080.c |1 + board/freescale/mpc8641hpcn/mpc8641hpcn.c | 22 cpu/mpc86xx/cpu_init.c| 27 +++ drivers/block/ahci.c |7 +-- drivers/pci/pci.c | 19 include/74xx_7xx.h| 37 --- include/asm-ppc/e300.h| 35 -- include/asm-ppc/mmu.h | 73 ++-- include/configs/MPC8641HPCN.h | 28 +-- include/mpc824x.h | 39 --- include/mpc86xx.h | 41 include/pci.h | 28 +-- lib_ppc/bat_rw.c | 28 +++ lib_ppc/board.c |2 +- 16 files changed, 211 insertions(+), 213 deletions(-) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 7/8] drivers/block/ahci: Fix pci mapping bug
The code assumes that the pci bus address and the virtual
address used to access a region are the same, but they might
not be. Fix this assumption.
Signed-off-by: Becky Bruce
---
drivers/block/ahci.c |7 ++-
1 files changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/block/ahci.c b/drivers/block/ahci.c
index 2445e8c..e1b66fd 100644
--- a/drivers/block/ahci.c
+++ b/drivers/block/ahci.c
@@ -251,7 +251,6 @@ static void ahci_print_info(struct ahci_probe_ent
*probe_ent)
static int ahci_init_one(pci_dev_t pdev)
{
- u32 iobase;
u16 vendor;
int rc;
@@ -261,9 +260,6 @@ static int ahci_init_one(pci_dev_t pdev)
memset(probe_ent, 0, sizeof(struct ahci_probe_ent));
probe_ent->dev = pdev;
- pci_read_config_dword(pdev, AHCI_PCI_BAR, &iobase);
- iobase &= ~0xf;
-
probe_ent->host_flags = ATA_FLAG_SATA
| ATA_FLAG_NO_LEGACY
| ATA_FLAG_MMIO
@@ -272,7 +268,8 @@ static int ahci_init_one(pci_dev_t pdev)
probe_ent->pio_mask = 0x1f;
probe_ent->udma_mask = 0x7f;/*Fixme,assume to support UDMA6 */
- probe_ent->mmio_base = iobase;
+ probe_ent->mmio_base = (u32)pci_map_bar(pdev, AHCI_PCI_BAR,
+ PCI_REGION_MEM);
/* Take from kernel:
* JMicron-specific fixup:
--
1.5.6.6
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 4/8] mpc86xx: Add support to populate addr map based on BATs
If CONFIG_ADDR_MAP is enabled, update the address map
whenever we write a bat.
Signed-off-by: Becky Bruce
---
cpu/mpc86xx/cpu_init.c | 27 +++
include/asm-ppc/mmu.h | 16 +---
lib_ppc/bat_rw.c | 28
lib_ppc/board.c|2 +-
4 files changed, 69 insertions(+), 4 deletions(-)
diff --git a/cpu/mpc86xx/cpu_init.c b/cpu/mpc86xx/cpu_init.c
index a7e6036..4f29122 100644
--- a/cpu/mpc86xx/cpu_init.c
+++ b/cpu/mpc86xx/cpu_init.c
@@ -154,3 +154,30 @@ void setup_bats(void)
return;
}
+
+#ifdef CONFIG_ADDR_MAP
+/* Initialize address mapping array */
+void init_addr_map(void)
+{
+ int i;
+ ppc_bat_t bat = DBAT0;
+ phys_size_t size;
+ unsigned long upper, lower;
+
+ for (i = 0; i < CONFIG_SYS_NUM_ADDR_MAP; i++, bat++) {
+ if (read_bat(bat, &upper, &lower) != -1) {
+ if (!BATU_VALID(upper))
+ size = 0;
+ else
+ size = BATU_SIZE(upper);
+ addrmap_set_entry(BATU_VADDR(upper), BATL_PADDR(lower),
+ size, i);
+ }
+#ifdef CONFIG_HIGH_BATS
+ /* High bats are not contiguous with low BAT numbers */
+ if (bat == DBAT3)
+ bat = DBAT4 - 1;
+#endif
+ }
+}
+#endif
diff --git a/include/asm-ppc/mmu.h b/include/asm-ppc/mmu.h
index ce04e62..fa92b90 100644
--- a/include/asm-ppc/mmu.h
+++ b/include/asm-ppc/mmu.h
@@ -138,6 +138,10 @@ typedef struct _MMU_context {
extern void _tlbie(unsigned long va); /* invalidate a TLB entry */
extern void _tlbia(void); /* invalidate all TLB entries */
+#ifdef CONFIG_ADDR_MAP
+extern void init_addr_map(void);
+#endif
+
typedef enum {
IBAT0 = 0, IBAT1, IBAT2, IBAT3,
DBAT0, DBAT1, DBAT2, DBAT3,
@@ -203,6 +207,14 @@ extern void print_bats(void);
#define BPP_RX 0x01/* Read only */
#define BPP_RW 0x02/* Read/write */
+/* Macros to get values from BATs, once data is in the BAT register format */
+#define BATU_VALID(x) (x & 0x3)
+#define BATU_VADDR(x) (x & 0xfffe)
+#define BATL_PADDR(x) ((phys_addr_t)((x & 0xfffe) \
+| ((x & 0x0e00ULL) << 24) \
+| ((x & 0x04ULL) << 30)))
+#define BATU_SIZE(x) (1UL << (fls((x & BATU_BL_MAX) >> 2) + 17))
+
/* Used to set up SDR1 register */
#define HASH_TABLE_SIZE_64K0x0001
#define HASH_TABLE_SIZE_128K 0x0002
@@ -462,9 +474,7 @@ extern void set_tlb(u8 tlb, u32 epn, u64 rpn,
extern void disable_tlb(u8 esel);
extern void invalidate_tlb(u8 tlb);
extern void init_tlbs(void);
-#ifdef CONFIG_ADDR_MAP
-extern void init_addr_map(void);
-#endif
+
extern unsigned int setup_ddr_tlbs(unsigned int memsize_in_meg);
#define SET_TLB_ENTRY(_tlb, _epn, _rpn, _perms, _wimge, _ts, _esel, _sz,
_iprot) \
diff --git a/lib_ppc/bat_rw.c b/lib_ppc/bat_rw.c
index a40b377..c48c240 100644
--- a/lib_ppc/bat_rw.c
+++ b/lib_ppc/bat_rw.c
@@ -27,14 +27,23 @@
#include
#include
+#ifdef CONFIG_ADDR_MAP
+#include
+#endif
+
+DECLARE_GLOBAL_DATA_PTR;
+
int write_bat (ppc_bat_t bat, unsigned long upper, unsigned long lower)
{
+ int batn = -1;
+
sync();
switch (bat) {
case DBAT0:
mtspr (DBAT0L, lower);
mtspr (DBAT0U, upper);
+ batn = 0;
break;
case IBAT0:
mtspr (IBAT0L, lower);
@@ -43,6 +52,7 @@ int write_bat (ppc_bat_t bat, unsigned long upper, unsigned
long lower)
case DBAT1:
mtspr (DBAT1L, lower);
mtspr (DBAT1U, upper);
+ batn = 1;
break;
case IBAT1:
mtspr (IBAT1L, lower);
@@ -51,6 +61,7 @@ int write_bat (ppc_bat_t bat, unsigned long upper, unsigned
long lower)
case DBAT2:
mtspr (DBAT2L, lower);
mtspr (DBAT2U, upper);
+ batn = 2;
break;
case IBAT2:
mtspr (IBAT2L, lower);
@@ -59,6 +70,7 @@ int write_bat (ppc_bat_t bat, unsigned long upper, unsigned
long lower)
case DBAT3:
mtspr (DBAT3L, lower);
mtspr (DBAT3U, upper);
+ batn = 3;
break;
case IBAT3:
mtspr (IBAT3L, lower);
@@ -68,6 +80,7 @@ int write_bat (ppc_bat_t bat, unsigned long upper, unsigned
long lower)
case DBAT4:
mtspr (DBAT4L, lower);
mtspr (DBAT4U, upper);
+ batn = 4;
break;
case IBAT4:
mtspr (IBAT4L, lower);
@@ -76,6 +89,7 @@ int write_bat (ppc_bat_t bat, unsigned long upper, unsigned
long lower)
case DBAT5:
mtspr (DBAT5L, lower);
mtspr (DBAT5U, upper);
+ batn = 5
[U-Boot] [PATCH 5/8] mpc8641hpcn: Clean up PCI mapping concepts
Clean up PCI mapping concepts in the 8641 config - rename _BASE
to _BUS, as it's actually a PCI bus address, separate virtual
and physical addresses into _VIRT and _PHYS, and use each
appopriately.
Signed-off-by: Becky Bruce
---
board/freescale/mpc8641hpcn/mpc8641hpcn.c | 10 +-
include/configs/MPC8641HPCN.h | 17 +++--
2 files changed, 16 insertions(+), 11 deletions(-)
diff --git a/board/freescale/mpc8641hpcn/mpc8641hpcn.c
b/board/freescale/mpc8641hpcn/mpc8641hpcn.c
index 9b6b69e..28c1683 100644
--- a/board/freescale/mpc8641hpcn/mpc8641hpcn.c
+++ b/board/freescale/mpc8641hpcn/mpc8641hpcn.c
@@ -165,14 +165,14 @@ void pci_init_board(void)
/* outbound memory */
pci_set_region(r++,
- CONFIG_SYS_PCI1_MEM_BASE,
+ CONFIG_SYS_PCI1_MEM_BUS,
CONFIG_SYS_PCI1_MEM_PHYS,
CONFIG_SYS_PCI1_MEM_SIZE,
PCI_REGION_MEM);
/* outbound io */
pci_set_region(r++,
- CONFIG_SYS_PCI1_IO_BASE,
+ CONFIG_SYS_PCI1_IO_BUS,
CONFIG_SYS_PCI1_IO_PHYS,
CONFIG_SYS_PCI1_IO_SIZE,
PCI_REGION_IO);
@@ -195,7 +195,7 @@ void pci_init_board(void)
* Activate ULI1575 legacy chip by performing a fake
* memory access. Needed to make ULI RTC work.
*/
- in_be32((unsigned *) ((char *)(CONFIG_SYS_PCI1_MEM_BASE
+ in_be32((unsigned *) ((char *)(CONFIG_SYS_PCI1_MEM_VIRT
+ CONFIG_SYS_PCI1_MEM_SIZE -
0x100)));
} else {
@@ -214,14 +214,14 @@ void pci_init_board(void)
/* outbound memory */
pci_set_region(r++,
- CONFIG_SYS_PCI2_MEM_BASE,
+ CONFIG_SYS_PCI2_MEM_BUS,
CONFIG_SYS_PCI2_MEM_PHYS,
CONFIG_SYS_PCI2_MEM_SIZE,
PCI_REGION_MEM);
/* outbound io */
pci_set_region(r++,
- CONFIG_SYS_PCI2_IO_BASE,
+ CONFIG_SYS_PCI2_IO_BUS,
CONFIG_SYS_PCI2_IO_PHYS,
CONFIG_SYS_PCI2_IO_SIZE,
PCI_REGION_IO);
diff --git a/include/configs/MPC8641HPCN.h b/include/configs/MPC8641HPCN.h
index ceb8e54..ce94b7a 100644
--- a/include/configs/MPC8641HPCN.h
+++ b/include/configs/MPC8641HPCN.h
@@ -331,14 +331,17 @@ extern unsigned long get_board_sys_clk(unsigned long
dummy);
* General PCI
* Addresses are mapped 1-1.
*/
-#define CONFIG_SYS_PCI1_MEM_BASE 0x8000
+
+#define CONFIG_SYS_PCI1_MEM_VIRT 0x8000
#ifdef CONFIG_PHYS_64BIT
+#define CONFIG_SYS_PCI1_MEM_BUSCONFIG_SYS_PCI1_MEM_VIRT
#define CONFIG_SYS_PCI1_MEM_PHYS 0x000cULL
#else
-#define CONFIG_SYS_PCI1_MEM_PHYS CONFIG_SYS_PCI1_MEM_BASE
+#define CONFIG_SYS_PCI1_MEM_BUSCONFIG_SYS_PCI1_MEM_VIRT
+#define CONFIG_SYS_PCI1_MEM_PHYS CONFIG_SYS_PCI1_MEM_VIRT
#endif
#define CONFIG_SYS_PCI1_MEM_SIZE 0x2000 /* 512M */
-#define CONFIG_SYS_PCI1_IO_BASE0x
+#define CONFIG_SYS_PCI1_IO_BUS 0x
#define CONFIG_SYS_PCI1_IO_VIRT0xffc0
#define CONFIG_SYS_PCI1_IO_PHYS(CONFIG_SYS_PCI1_IO_VIRT \
| CONFIG_SYS_PHYS_ADDR_HIGH)
@@ -348,12 +351,14 @@ extern unsigned long get_board_sys_clk(unsigned long
dummy);
#define KSEG1ADDR(x) ({u32 _x=le32_to_cpu(*(u32 *)(x)); (&_x);})
#define _IO_BASE 0x
-#define CONFIG_SYS_PCI2_MEM_BASE (CONFIG_SYS_PCI1_MEM_BASE \
+#define CONFIG_SYS_PCI2_MEM_BUS(CONFIG_SYS_PCI1_MEM_BUS \
++ CONFIG_SYS_PCI1_MEM_SIZE)
+#define CONFIG_SYS_PCI2_MEM_VIRT (CONFIG_SYS_PCI1_MEM_VIRT \
+ CONFIG_SYS_PCI1_MEM_SIZE)
#define CONFIG_SYS_PCI2_MEM_PHYS (CONFIG_SYS_PCI1_MEM_PHYS \
+ CONFIG_SYS_PCI1_MEM_SIZE)
#define CONFIG_SYS_PCI2_MEM_SIZE 0x2000 /* 512M */
-#define CONFIG_SYS_PCI2_IO_BASE0x
+#define CONFIG_SYS_PCI2_IO_BUS 0x
#define CONFIG_SYS_PCI2_IO_VIRT (CONFIG_SYS_PCI1_IO_VIRT \
+ CONFIG_SYS_PCI1_IO_SIZE)
#define CONFIG_SYS_PCI2_IO_PHYS(CONFIG_SYS_PCI1_IO_PHYS \
@@ -501,7 +506,7 @@ extern unsigned long get_board_sys_clk(unsigned long dummy);
#define CONFIG_SYS_DBAT2L (BAT_PHYS_ADDR(CONFIG_SYS_PCI1_MEM_PHYS) \
| BATL_PP_RW | BATL_CACHEINHIBIT \
| BATL_GUARDEDSTORAGE)
-#define CONFIG_SYS_DBAT2U (CONFIG_SYS_PCI1_MEM_BASE | BATU_BL_1G \
+#define CONFIG_S
[U-Boot] [PATCH 8/8] mpc8641hpcn: Change PCI MEM pci bus address
Now that the rest of u-boot can support it, change the PCI bus
address of the PCI MEM regions from 0x8000 to 0xc000,
and use the same bus address for both PCI1 and PCI2. This will
maximize the amount of PCI address space left over to map RAM
on systems with large amounts of memory.
Signed-off-by: Becky Bruce
---
include/configs/MPC8641HPCN.h | 11 ++-
1 files changed, 10 insertions(+), 1 deletions(-)
diff --git a/include/configs/MPC8641HPCN.h b/include/configs/MPC8641HPCN.h
index 84708c4..f1b7eb5 100644
--- a/include/configs/MPC8641HPCN.h
+++ b/include/configs/MPC8641HPCN.h
@@ -336,7 +336,7 @@ extern unsigned long get_board_sys_clk(unsigned long dummy);
#define CONFIG_SYS_PCI1_MEM_VIRT 0x8000
#ifdef CONFIG_PHYS_64BIT
-#define CONFIG_SYS_PCI1_MEM_BUSCONFIG_SYS_PCI1_MEM_VIRT
+#define CONFIG_SYS_PCI1_MEM_BUS0xc000
#define CONFIG_SYS_PCI1_MEM_PHYS 0x000cULL
#else
#define CONFIG_SYS_PCI1_MEM_BUSCONFIG_SYS_PCI1_MEM_VIRT
@@ -353,8 +353,17 @@ extern unsigned long get_board_sys_clk(unsigned long
dummy);
#define KSEG1ADDR(x) ({u32 _x=le32_to_cpu(*(u32 *)(x)); (&_x);})
#define _IO_BASE 0x
+#ifdef CONFIG_PHYS_64BIT
+/*
+ * Use the same PCI bus address on PCI1 and PCI2 if we have PHYS_64BIT.
+ * This will increase the amount of PCI address space available for
+ * for mapping RAM.
+ */
+#define CONFIG_SYS_PCI2_MEM_BUSCONFIG_SYS_PCI1_MEM_BUS
+#else
#define CONFIG_SYS_PCI2_MEM_BUS(CONFIG_SYS_PCI1_MEM_BUS \
+ CONFIG_SYS_PCI1_MEM_SIZE)
+#endif
#define CONFIG_SYS_PCI2_MEM_VIRT (CONFIG_SYS_PCI1_MEM_VIRT \
+ CONFIG_SYS_PCI1_MEM_SIZE)
#define CONFIG_SYS_PCI2_MEM_PHYS (CONFIG_SYS_PCI1_MEM_PHYS \
--
1.5.6.6
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/8] mpc8641hpcn: Set up outbound pci windows before inbound
Because the inbound pci windows are mapped generously, set up
the more specific outbound windows first. This way, when we
search the pci regions for something, we will hit on the more
specific region. This can actually be a problem on systems
with large amounts of RAM.
Signed-off-by: Becky Bruce
---
board/freescale/mpc8641hpcn/mpc8641hpcn.c | 12 ++--
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/board/freescale/mpc8641hpcn/mpc8641hpcn.c
b/board/freescale/mpc8641hpcn/mpc8641hpcn.c
index b83ed6c..9b6b69e 100644
--- a/board/freescale/mpc8641hpcn/mpc8641hpcn.c
+++ b/board/freescale/mpc8641hpcn/mpc8641hpcn.c
@@ -163,9 +163,6 @@ void pci_init_board(void)
}
debug("\n");
- /* inbound */
- r += fsl_pci_setup_inbound_windows(r);
-
/* outbound memory */
pci_set_region(r++,
CONFIG_SYS_PCI1_MEM_BASE,
@@ -180,6 +177,9 @@ void pci_init_board(void)
CONFIG_SYS_PCI1_IO_SIZE,
PCI_REGION_IO);
+ /* inbound */
+ r += fsl_pci_setup_inbound_windows(r);
+
hose->region_count = r - hose->regions;
hose->first_busno=first_free_busno;
@@ -212,9 +212,6 @@ void pci_init_board(void)
struct pci_controller *hose = &pci2_hose;
struct pci_region *r = hose->regions;
- /* inbound */
- r += fsl_pci_setup_inbound_windows(r);
-
/* outbound memory */
pci_set_region(r++,
CONFIG_SYS_PCI2_MEM_BASE,
@@ -229,6 +226,9 @@ void pci_init_board(void)
CONFIG_SYS_PCI2_IO_SIZE,
PCI_REGION_IO);
+ /* inbound */
+ r += fsl_pci_setup_inbound_windows(r);
+
hose->region_count = r - hose->regions;
hose->first_busno=first_free_busno;
--
1.5.6.6
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/8] powerpc: Move duplicated BAT defines to mmu.h
The BAT fields are architected; there's no need for these to be in
cpu-specific files. Drop the duplication and move these to
include/asm-ppc/mmu.h. Also, remove the BL_xxx defines that were only
used by the alaska board, and switch to using the BATU_BL_xxx defines
used by all the other boards. The BL_ defines previously in use
had to be shifted into the proper position for use, which was inefficient.
Signed-off-by: Becky Bruce
---
board/alaska/alaska.c| 36 +-
board/etin/debris/flash.c|1 +
board/etin/kvme080/kvme080.c |1 +
include/74xx_7xx.h | 37 ---
include/asm-ppc/e300.h | 35 -
include/asm-ppc/mmu.h| 57 -
include/mpc824x.h| 39
include/mpc86xx.h| 41 --
8 files changed, 64 insertions(+), 183 deletions(-)
diff --git a/board/alaska/alaska.c b/board/alaska/alaska.c
index 33b4a6e..89c1abd 100644
--- a/board/alaska/alaska.c
+++ b/board/alaska/alaska.c
@@ -33,9 +33,9 @@ void setupBat (ulong size)
/* Flash 0 */
#if defined (CONFIG_SYS_AMD_BOOT)
- batu = CONFIG_SYS_FLASH0_BASE | (BL_512K << 2) | BPP_RW | BPP_RX;
+ batu = CONFIG_SYS_FLASH0_BASE | BATU_BL_512K | BPP_RW | BPP_RX;
#else
- batu = CONFIG_SYS_FLASH0_BASE | (BL_16M << 2) | BPP_RW | BPP_RX;
+ batu = CONFIG_SYS_FLASH0_BASE | BATU_BL_16M | BPP_RW | BPP_RX;
#endif
batl = CONFIG_SYS_FLASH0_BASE | 0x22;
write_bat (IBAT0, batu, batl);
@@ -43,22 +43,22 @@ void setupBat (ulong size)
/* Flash 1 */
#if defined (CONFIG_SYS_AMD_BOOT)
- batu = CONFIG_SYS_FLASH1_BASE | (BL_16M << 2) | BPP_RW | BPP_RX;
+ batu = CONFIG_SYS_FLASH1_BASE | BATU_BL_16M | BPP_RW | BPP_RX;
#else
- batu = CONFIG_SYS_FLASH1_BASE | (BL_512K << 2) | BPP_RW | BPP_RX;
+ batu = CONFIG_SYS_FLASH1_BASE | BATU_BL_512K | BPP_RW | BPP_RX;
#endif
batl = CONFIG_SYS_FLASH1_BASE | 0x22;
write_bat (IBAT1, batu, batl);
write_bat (DBAT1, batu, batl);
/* CPLD */
- batu = CONFIG_SYS_CPLD_BASE | (BL_512K << 2) | BPP_RW | BPP_RX;
+ batu = CONFIG_SYS_CPLD_BASE | BATU_BL_512K | BPP_RW | BPP_RX;
batl = CONFIG_SYS_CPLD_BASE | 0x22;
write_bat (IBAT2, 0, 0);
write_bat (DBAT2, batu, batl);
/* FPGA */
- batu = CONFIG_SYS_FPGA_BASE | (BL_512K << 2) | BPP_RW | BPP_RX;
+ batu = CONFIG_SYS_FPGA_BASE | BATU_BL_512K | BPP_RW | BPP_RX;
batl = CONFIG_SYS_FPGA_BASE | 0x22;
write_bat (IBAT3, 0, 0);
write_bat (DBAT3, batu, batl);
@@ -80,17 +80,17 @@ void setupBat (ulong size)
mtspr (DBAT5U, batu);
if (size <= 0x80) /* 8MB */
- blocksize = BL_8M << 2;
+ blocksize = BATU_BL_8M;
else if (size <= 0x100) /* 16MB */
- blocksize = BL_16M << 2;
+ blocksize = BATU_BL_16M;
else if (size <= 0x200) /* 32MB */
- blocksize = BL_32M << 2;
+ blocksize = BATU_BL_32M;
else if (size <= 0x400) /* 64MB */
- blocksize = BL_64M << 2;
+ blocksize = BATU_BL_64M;
else if (size <= 0x800) /* 128MB */
- blocksize = BL_128M << 2;
+ blocksize = BATU_BL_128M;
else if (size <= 0x1000)/* 256MB */
- blocksize = BL_256M << 2;
+ blocksize = BATU_BL_256M;
/* Memory */
batu = CONFIG_SYS_SDRAM_BASE | blocksize | BPP_RW | BPP_RX;
@@ -108,17 +108,17 @@ void setupBat (ulong size)
} else {
size -= 0x1000;
if (size <= 0x80) /* 8MB */
- blocksize = BL_8M << 2;
+ blocksize = BATU_BL_8M;
else if (size <= 0x100) /* 16MB */
- blocksize = BL_16M << 2;
+ blocksize = BATU_BL_16M;
else if (size <= 0x200) /* 32MB */
- blocksize = BL_32M << 2;
+ blocksize = BATU_BL_32M;
else if (size <= 0x400) /* 64MB */
- blocksize = BL_64M << 2;
+ blocksize = BATU_BL_64M;
else if (size <= 0x800) /* 128MB */
- blocksize = BL_128M << 2;
+ blocksize = BATU_BL_128M;
else if (size <= 0x1000)/* 256MB */
- blocksize = BL_256M << 2;
+ blocksize = BATU_BL_256M;
batu = (CONFIG_SYS_SDRAM_BASE +
0x1000) | blocksize | BPP_RW | BPP_RX;
diff --git a/board/etin/debris/flash.c b/board/etin/debris/flash.c
index a3c8138..f9e8619 100644
--- a/board/etin/debris/flash.c
+++ b/board/etin/debris/flash.c
@@ -27,6
[U-Boot] [PATCH 2/8] drivers/pci: Create pci_map_bar function
It is no longer always true that the pci bus address can be
used as the virtual address for pci accesses. pci_map_bar()
is created to return the virtual address for a pci region.
Signed-off-by: Becky Bruce
---
drivers/pci/pci.c | 19 +++
include/pci.h | 28
2 files changed, 43 insertions(+), 4 deletions(-)
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index e2b05d8..cb1217f 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -116,6 +116,25 @@ PCI_READ_VIA_DWORD_OP(word, u16 *, 0x02)
PCI_WRITE_VIA_DWORD_OP(byte, u8, 0x03, 0x00ff)
PCI_WRITE_VIA_DWORD_OP(word, u16, 0x02, 0x)
+/* Get a virtual address associated with a BAR region */
+void *pci_map_bar(pci_dev_t pdev, int bar, int flags)
+{
+ pci_addr_t pci_bus_addr;
+ u32 bar_response;
+
+ /* read BAR address */
+ pci_read_config_dword(pdev, bar, &bar_response);
+ pci_bus_addr = (pci_addr_t)(bar_response & ~0xf);
+
+ /*
+* Pass "0" as the length argument to pci_bus_to_virt. The arg
+* isn't actualy used on any platform because u-boot assumes a static
+* linear mapping. In the future, this could read the BAR size
+* and pass that as the size if needed.
+*/
+ return pci_bus_to_virt(pdev, pci_bus_addr, flags, 0, MAP_NOCACHE);
+}
+
/*
*
*/
diff --git a/include/pci.h b/include/pci.h
index 072273b..058b943 100644
--- a/include/pci.h
+++ b/include/pci.h
@@ -454,10 +454,29 @@ extern pci_addr_t pci_hose_phys_to_bus(struct
pci_controller* hose,
#define pci_bus_to_phys(dev, addr, flags) \
pci_hose_bus_to_phys(pci_bus_to_hose(PCI_BUS(dev)), (addr), (flags))
-#define pci_phys_to_mem(dev, addr) pci_phys_to_bus((dev), (addr),
PCI_REGION_MEM)
-#define pci_mem_to_phys(dev, addr) pci_bus_to_phys((dev), (addr),
PCI_REGION_MEM)
-#define pci_phys_to_io(dev, addr) pci_phys_to_bus((dev), (addr),
PCI_REGION_IO)
-#define pci_io_to_phys(dev, addr) pci_bus_to_phys((dev), (addr),
PCI_REGION_IO)
+#define pci_virt_to_bus(dev, addr, flags) \
+ pci_hose_phys_to_bus(pci_bus_to_hose(PCI_BUS(dev)), \
+(virt_to_phys(addr)), (flags))
+#define pci_bus_to_virt(dev, addr, flags, len, map_flags) \
+ map_physmem(pci_hose_bus_to_phys(pci_bus_to_hose(PCI_BUS(dev)), \
+(addr), (flags)), \
+ (len), (map_flags))
+
+#define pci_phys_to_mem(dev, addr) \
+ pci_phys_to_bus((dev), (addr), PCI_REGION_MEM)
+#define pci_mem_to_phys(dev, addr) \
+ pci_bus_to_phys((dev), (addr), PCI_REGION_MEM)
+#define pci_phys_to_io(dev, addr) pci_phys_to_bus((dev), (addr),
PCI_REGION_IO)
+#define pci_io_to_phys(dev, addr) pci_bus_to_phys((dev), (addr),
PCI_REGION_IO)
+
+#define pci_virt_to_mem(dev, addr) \
+ pci_virt_to_bus((dev), (addr), PCI_REGION_MEM)
+#define pci_mem_to_virt(dev, addr, len, map_flags) \
+ pci_bus_to_virt((dev), (addr), PCI_REGION_MEM, (len), (map_flags))
+#define pci_virt_to_io(dev, addr) \
+ pci_virt_to_bus((dev), (addr), PCI_REGION_IO)
+#define pci_io_to_virt(dev, addr, len, map_flags) \
+ pci_bus_to_virt((dev), (addr), PCI_REGION_IO, (len), (map_flags))
extern int pci_hose_read_config_byte(struct pci_controller *hose,
pci_dev_t dev, int where, u8 *val);
@@ -488,6 +507,7 @@ extern int pci_hose_write_config_byte_via_dword(struct
pci_controller *hose,
extern int pci_hose_write_config_word_via_dword(struct pci_controller *hose,
pci_dev_t dev, int where, u16
val);
+extern void *pci_map_bar(pci_dev_t pdev, int bar, int flags);
extern void pci_register_hose(struct pci_controller* hose);
extern struct pci_controller* pci_bus_to_hose(int bus);
--
1.5.6.6
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 6/8] MPC8641HPCN: Enable CONFIG_ADDR_MAP
Signed-off-by: Becky Bruce --- include/configs/MPC8641HPCN.h |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/include/configs/MPC8641HPCN.h b/include/configs/MPC8641HPCN.h index ce94b7a..84708c4 100644 --- a/include/configs/MPC8641HPCN.h +++ b/include/configs/MPC8641HPCN.h @@ -39,6 +39,7 @@ #define CONFIG_NUM_CPUS2 /* Number of CPUs in the system */ #define CONFIG_LINUX_RESET_VEC 0x100 /* Reset vector used by Linux */ /*#define CONFIG_PHYS_64BIT1*/ /* Place devices in 36-bit space */ +#define CONFIG_ADDR_MAP1 /* Use addr map */ #ifdef RUN_DIAG #define CONFIG_SYS_DIAG_ADDRCONFIG_SYS_FLASH_BASE @@ -70,6 +71,7 @@ #define CONFIG_ENV_OVERWRITE #define CONFIG_HIGH_BATS 1 /* High BATs supported and enabled */ +#define CONFIG_SYS_NUM_ADDR_MAP 8 /* Number of addr map slots = 8 dbats */ #define CONFIG_ALTIVEC 1 -- 1.5.6.6 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Pull request: u-boot-usb
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://git.denx.de/u-boot-usb.git master Remy Bohmer (1): Compile warning fix in onenand_uboot.h Stefan Roese (1): USB: Add EHCI support for VCT EHCI controller (really with driver now) drivers/usb/usb_ehci_vct.c | 58 include/onenand_uboot.h|2 + 2 files changed, 60 insertions(+), 0 deletions(-) create mode 100644 drivers/usb/usb_ehci_vct.c ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Add support for setting environment variable from RAM.
Hello Peter,
Peter Tyser wrote:
> Hi Eric,
>
> On Tue, 2009-02-03 at 08:28 -0700, Eric Nelson (Boundary Devices) wrote:
>> /
>> + * Set a new environment variable from RAM.
>> + * Requires three arguments: the variable name, a memory address and a
>> length.
>> + *
>> + * Deletes the environment variable if the length is zero.
>> + */
>> +int do_ramenv(cmd_tbl_t *cmdtp, int flag, int argc, char *argv[])
>> +{
>> +unsigned long len, i;
>> +char *addr;
>> +
>> +if (argc != 4) {
>> +cmd_usage(cmdtp);
>> +return 1;
>> +}
>> +addr = (char *)simple_strtol(argv[2], NULL, 16);
>> +len = simple_strtol(argv[3], NULL, 16);
>> +if (!addr || !len) {
>> +cmd_usage(cmdtp);
>> +return 1;
>> +}
>> +addr[len] = '\0';
>> +for (i = 0; i < len; i++) {
>> +/* turn newlines into semicolon */
>> +if (addr[i] == '\n')
>> +addr[i] = ';'; /* ignore dos-style newlines */
>> +if (addr[i] == '\r')
>> +addr[i] = ' '; /* accept sh-comments and discard them */
>> +if (addr[i] == '#') {
>> +while (addr[i] && addr[i] != '\n')
>> +addr[i++] = ' ';
>> +i--;
>> +}
>> +}
>> +setenv(argv[1], addr);
>> +return 0;
>> +}
>> +
>> +/
>> * Look up variable from environment,
>> * return address of storage for that variable,
>> * or NULL if not found
>> @@ -605,6 +643,14 @@ U_BOOT_CMD(
>> "- delete environment variable 'name'\n"
>> );
>>
>> +U_BOOT_CMD(
>> +ramenv, 4, 0, do_ramenv,
>> +"ramenv - get environment variable from ram\n",
>
> The "ramenv - " and "\n" are no longer used in the above line.
>
Oops. Can you tell I started by implementing this on an older source tree?
Re-reading it, the comment should probably also say "set environment variable
from ram" instead of "get...".
If there's interest, I'll happily re-submit the patch.
>> +"name addr maxlen\n"
>> +"- set environment variable 'name' from addr 'addr'\n"
>> +"- delete environment variable if maxlen is 0\n"
>> +);
>> +
>> #if defined(CONFIG_CMD_ASKENV)
>>
>> U_BOOT_CMD(
>
> In the email thread you mentioned above, Detlev mentions 2 alternatives
> to the "ramenv" command - loading a uImage script and running it via
> autoscr, or modifying autoscr to be able to raw files (non-uImages).
> Both of these methods seem cleaner and more flexible at a glance. Is
> there a specific reason using autoscr wouldn't work for your setup?
>
The customer requesting this feature operates in a regulated environment with
pretty strict rules about separation of code and data. Autoscr is kind of
a big stick for what we're trying to achieve: (configuring an LCD with
settings from a file on SD card).
> For example, what is the process to load multiple environment variables
> with the ramenv command? If I understand correctly, in order to load 10
> environment variables you'd have to repeat the process of "load a file
> to RAM, run ramenv" 10 times? That seems much more difficult than
> loading 1 file with 10 environment variables and running autoscr once.
>
That's certainly true, although once you have an environment variable you
could use it for iteration...
Our particular need is just for a single environment variable, so the
update works pretty well. I started by updating our 'lcdpanel' U-Boot
command to read from file, but this is much more useful.
> Best,
> Peter
>
Regards,
Eric
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] tsec: Fix a bug in soft-resetting
SOFT_RESET must be asserted for at least 3 TX clocks. Usually, that's about 30 clock cycles, so it's been mostly working. But we had no guarantee, and at slower bitrates, it's just over a microsecond (over 1000 clock cycles). This enforces a 2 microsecond gap between assertion and deassertion. Signed-off-by: Andy Fleming --- drivers/net/tsec.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/net/tsec.c b/drivers/net/tsec.c index fbc9a6d..4682c8b 100644 --- a/drivers/net/tsec.c +++ b/drivers/net/tsec.c @@ -158,6 +158,7 @@ int tsec_initialize(bd_t * bis, struct tsec_info_struct *tsec_info) /* Reset the MAC */ priv->regs->maccfg1 |= MACCFG1_SOFT_RESET; + udelay(2); /* Soft Reset must be asserted for 3 TX clocks */ priv->regs->maccfg1 &= ~(MACCFG1_SOFT_RESET); #if defined(CONFIG_MII) || defined(CONFIG_CMD_MII) \ -- 1.5.4.GIT ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [GIT PULL] Please pull mpc5xxx tree
Wolfgang, You are right, in some rebasing I neglected to include the --author. I will fix this and send a new pull req. John Wolfgang Denk wrote: > Dear John, > > In message <498876f3.2070...@freescale.com> you wrote: > >> Wolfgang, >> >> The following changes since commit 92c20fbd3a7788c1a154f50a3f44f28a7763f99a: >>John Rigby (1): >> ADS5121 DIU Make inclusion of FSL logo optional >> >> are available in the git repository at: >> >>http://git.denx.de/u-boot-mpc5xxx.git master >> >> John Rigby (3): >>ADS5121 DIU Add diu_bmp_addr env >>ADS5121 Fix rev2 silicon pci iopad config >>ADS5121 Add IC Ident Module (IIM) support >> >> Ralph Kondziella (1): >>ADS5121 Add PATA support >> > > Sorry, but I hesitate pulling this. Commit 430b071b09 in your tree > shows: > > Author: John Rigby 2009-01-26 18:45:07 > Committer: John Rigby 2009-02-03 17:28:40 > > ADS5121 Add IC Ident Module (IIM) support > > To me it seems to match to > > Subject: [U-Boot] [PATCH] Add IC Identif Module (IIM) support > for ADS5121 > From: Martha Marx > Date: Sat, 11 Oct 2008 15:34:22 -0400 > To: u-boot@lists.denx.de > > so I would expect to see Martha listed as author? I am aware of your > reposted patch > > Subject: [PATCH 4/5] ADS5121 Add IC Ident Module (IIM) support > From: John Rigby > Date: Mon, 26 Jan 2009 13:07:07 -0700 > To: u-boot@lists.denx.de, ... > > but I feel authorship should be preserved here. > > What do you think? > > > > > Best regards, > > Wolfgang Denk > > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/7] Blackfin: set default voltage levels for BF538/BF539 parts
Signed-off-by: Mike Frysinger --- cpu/blackfin/initcode.c |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/cpu/blackfin/initcode.c b/cpu/blackfin/initcode.c index b2c8238..ffa5f61 100644 --- a/cpu/blackfin/initcode.c +++ b/cpu/blackfin/initcode.c @@ -199,6 +199,9 @@ static inline void serial_putc(char c) # elif defined(__ADSPBF54x__) /* TBD; use default */ # undef CONFIG_VR_CTL_VLEV # define CONFIG_VR_CTL_VLEV VLEV_120 +# elif defined(__ADSPBF538__) || defined(__ADSPBF539__)/* TBD; use default */ +# undef CONFIG_VR_CTL_VLEV +# define CONFIG_VR_CTL_VLEV VLEV_125 # endif # ifdef CONFIG_BFIN_MAC -- 1.6.1.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 4/7] Blackfin: check for reserved settings in DDR MMRs
Some bits of the DDR MMRs should not be set. If they do, bad things may happen (like random failures or hardware destruction). Signed-off-by: Mike Frysinger --- cpu/blackfin/initcode.c |7 +++ 1 files changed, 7 insertions(+), 0 deletions(-) diff --git a/cpu/blackfin/initcode.c b/cpu/blackfin/initcode.c index ffa5f61..a6e95f4 100644 --- a/cpu/blackfin/initcode.c +++ b/cpu/blackfin/initcode.c @@ -168,11 +168,18 @@ static inline void serial_putc(char c) #ifndef CONFIG_EBIU_RSTCTL_VAL # define CONFIG_EBIU_RSTCTL_VAL 0 /* only MDDRENABLE is useful */ #endif +#if ((CONFIG_EBIU_RSTCTL_VAL & 0xFFC4) != 0) +# error invalid EBIU_RSTCTL value: must not set reserved bits +#endif #ifndef CONFIG_EBIU_MBSCTL_VAL # define CONFIG_EBIU_MBSCTL_VAL 0 #endif +#if defined(CONFIG_EBIU_DDRQUE_VAL) && ((CONFIG_EBIU_DDRQUE_VAL & 0x8000) != 0) +# error invalid EBIU_DDRQUE value: must not set reserved bits +#endif + /* Make sure our voltage value is sane so we don't blow up! */ #ifndef CONFIG_VR_CTL_VAL # define BFIN_CCLK ((CONFIG_CLKIN_HZ * CONFIG_VCO_MULT) / CONFIG_CCLK_DIV) -- 1.6.1.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/7] Blackfin updates for 2009.03 (part 3)
These are mostly updates to the startup code to fix misc bugs and get it working with recent parts and some newer bootrom features. Mike Frysinger (7): Blackfin: update anomaly lists Blackfin: use on-chip syscontrol() rom function when available Blackfin: set default voltage levels for BF538/BF539 parts Blackfin: check for reserved settings in DDR MMRs Blackfin: add support for fast SPI reads with Boot ROM Blackfin: dynamically update UART speed when initializing Blackfin: move default boot SPI CS to common code board/bf537-stamp/spi_flash.c |8 +- cpu/blackfin/initcode.c| 155 +++--- cpu/blackfin/serial.h | 72 +++- include/asm-blackfin/blackfin-config-pre.h |9 ++ include/asm-blackfin/mach-bf527/anomaly.h | 166 include/asm-blackfin/mach-bf533/anomaly.h | 55 ++ include/asm-blackfin/mach-bf537/anomaly.h | 14 ++- include/asm-blackfin/mach-bf548/anomaly.h | 45 +--- include/asm-blackfin/mach-bf561/anomaly.h | 17 +++- 9 files changed, 330 insertions(+), 211 deletions(-) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 7/7] Blackfin: move default boot SPI CS to common code
Move the default SPI CS that we boot from into common code so that it can
be used in other SPI drivers and environment settings.
Signed-off-by: Mike Frysinger
---
board/bf537-stamp/spi_flash.c |8 +---
include/asm-blackfin/blackfin-config-pre.h |9 +
2 files changed, 10 insertions(+), 7 deletions(-)
diff --git a/board/bf537-stamp/spi_flash.c b/board/bf537-stamp/spi_flash.c
index b147ce7..7b764b4 100644
--- a/board/bf537-stamp/spi_flash.c
+++ b/board/bf537-stamp/spi_flash.c
@@ -180,13 +180,7 @@ static struct manufacturer_info flash_manufacturers[] = {
* BF51x, BF533, BF561: SSEL2
*/
#ifndef CONFIG_SPI_FLASH_SSEL
-# if defined(__ADSPBF531__) || defined(__ADSPBF532__) ||
defined(__ADSPBF533__) || \
- defined(__ADSPBF538__) || defined(__ADSPBF539__) ||
defined(__ADSPBF561__) || \
- defined(__ADSPBF51x__)
-# define CONFIG_SPI_FLASH_SSEL 2
-# else
-# define CONFIG_SPI_FLASH_SSEL 1
-# endif
+# define CONFIG_SPI_FLASH_SSEL BFIN_BOOT_SPI_SSEL
#endif
#define SSEL_MASK (1 << CONFIG_SPI_FLASH_SSEL)
diff --git a/include/asm-blackfin/blackfin-config-pre.h
b/include/asm-blackfin/blackfin-config-pre.h
index a1fae5c..9df01ad 100644
--- a/include/asm-blackfin/blackfin-config-pre.h
+++ b/include/asm-blackfin/blackfin-config-pre.h
@@ -60,4 +60,13 @@ static inline const char *get_bfin_boot_mode(int bfin_boot)
}
#endif
+/* Define the default SPI CS used when booting out of SPI */
+#if defined(__ADSPBF531__) || defined(__ADSPBF532__) || defined(__ADSPBF533__)
|| \
+defined(__ADSPBF538__) || defined(__ADSPBF539__) || defined(__ADSPBF561__)
|| \
+defined(__ADSPBF51x__)
+# define BFIN_BOOT_SPI_SSEL 2
+#else
+# define BFIN_BOOT_SPI_SSEL 1
+#endif
+
#endif
--
1.6.1.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/7] Blackfin: use on-chip syscontrol() rom function when available
Newer Blackfin's have an on-chip rom with a syscontrol() function that needs
to be used to properly program the memory and voltage settings as it will
include (possibly critical) factory tested bias values.
Signed-off-by: Mike Frysinger
---
cpu/blackfin/initcode.c | 58 ++-
1 files changed, 37 insertions(+), 21 deletions(-)
diff --git a/cpu/blackfin/initcode.c b/cpu/blackfin/initcode.c
index 6091f8c..b2c8238 100644
--- a/cpu/blackfin/initcode.c
+++ b/cpu/blackfin/initcode.c
@@ -267,34 +267,50 @@ void initcode(ADI_BOOT_DATA *bootstruct)
bfin_write_SIC_IWR(1);
#endif
- serial_putc('L');
+ /* With newer bootroms, we use the helper function to set up
+* the memory controller. Older bootroms lacks such helpers
+* so we do it ourselves.
+*/
+ if (BOOTROM_CAPS_SYSCONTROL) {
+ serial_putc('S');
- bfin_write_PLL_LOCKCNT(CONFIG_PLL_LOCKCNT_VAL);
+ ADI_SYSCTRL_VALUES memory_settings;
+ memory_settings.uwVrCtl = CONFIG_VR_CTL_VAL;
+ memory_settings.uwPllCtl = CONFIG_PLL_CTL_VAL;
+ memory_settings.uwPllDiv = CONFIG_PLL_DIV_VAL;
+ memory_settings.uwPllLockCnt = CONFIG_PLL_LOCKCNT_VAL;
+ syscontrol(SYSCTRL_WRITE | SYSCTRL_VRCTL | SYSCTRL_PLLCTL |
SYSCTRL_PLLDIV | SYSCTRL_LOCKCNT |
+ (CONFIG_VR_CTL_VAL & FREQ_MASK ? SYSCTRL_INTVOLTAGE :
SYSCTRL_EXTVOLTAGE), &memory_settings, NULL);
+ } else {
+ serial_putc('L');
- serial_putc('A');
+ bfin_write_PLL_LOCKCNT(CONFIG_PLL_LOCKCNT_VAL);
- /* Only reprogram when needed to avoid triggering unnecessary
-* PLL relock sequences.
-*/
- if (bfin_read_VR_CTL() != CONFIG_VR_CTL_VAL) {
- serial_putc('!');
- bfin_write_VR_CTL(CONFIG_VR_CTL_VAL);
- asm("idle;");
- }
+ serial_putc('A');
- serial_putc('C');
+ /* Only reprogram when needed to avoid triggering unnecessary
+* PLL relock sequences.
+*/
+ if (bfin_read_VR_CTL() != CONFIG_VR_CTL_VAL) {
+ serial_putc('!');
+ bfin_write_VR_CTL(CONFIG_VR_CTL_VAL);
+ asm("idle;");
+ }
- bfin_write_PLL_DIV(CONFIG_PLL_DIV_VAL);
+ serial_putc('C');
- serial_putc('K');
+ bfin_write_PLL_DIV(CONFIG_PLL_DIV_VAL);
- /* Only reprogram when needed to avoid triggering unnecessary
-* PLL relock sequences.
-*/
- if (bfin_read_PLL_CTL() != CONFIG_PLL_CTL_VAL) {
- serial_putc('!');
- bfin_write_PLL_CTL(CONFIG_PLL_CTL_VAL);
- asm("idle;");
+ serial_putc('K');
+
+ /* Only reprogram when needed to avoid triggering unnecessary
+* PLL relock sequences.
+*/
+ if (bfin_read_PLL_CTL() != CONFIG_PLL_CTL_VAL) {
+ serial_putc('!');
+ bfin_write_PLL_CTL(CONFIG_PLL_CTL_VAL);
+ asm("idle;");
+ }
}
/* Since we've changed the SCLK above, we may need to update
--
1.6.1.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Add support for setting environment variable from RAM.
Dear Eric, In message <4988936e.3070...@boundarydevices.com> you wrote: > > > In the email thread you mentioned above, Detlev mentions 2 alternatives > > to the "ramenv" command - loading a uImage script and running it via > > autoscr, or modifying autoscr to be able to raw files (non-uImages). > > Both of these methods seem cleaner and more flexible at a glance. Is > > there a specific reason using autoscr wouldn't work for your setup? > > > The customer requesting this feature operates in a regulated environment with > pretty strict rules about separation of code and data. Autoscr is kind of > a big stick for what we're trying to achieve: (configuring an LCD with > settings from a file on SD card). Why is it a big stick? It has a couple of significant advantages over your implementation: * It already exissts in mainline. * It can set several environment variables at once (and also perform any other commands you might need on your system). * It is based on text files which are easy to edit without need for new tools. * It will verify that your file has been transmitted correctly. > Our particular need is just for a single environment variable, so the > update works pretty well. I started by updating our 'lcdpanel' U-Boot > command to read from file, but this is much more useful. I suggest you use autoscr instead. I think I will reject your patch. 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 most exciting phrase to hear in science, the one that heralds new discoveries, is not "Eureka!" (I found it!) but "That's funny ..." -- Isaac Asimov ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/7] Blackfin: update anomaly lists
Update the anomaly lists to match latest anomaly sheets. Signed-off-by: Mike Frysinger --- include/asm-blackfin/mach-bf527/anomaly.h | 166 + include/asm-blackfin/mach-bf533/anomaly.h | 55 ++ include/asm-blackfin/mach-bf537/anomaly.h | 14 +++- include/asm-blackfin/mach-bf548/anomaly.h | 45 ++--- include/asm-blackfin/mach-bf561/anomaly.h | 17 +++- 5 files changed, 213 insertions(+), 84 deletions(-) diff --git a/include/asm-blackfin/mach-bf527/anomaly.h b/include/asm-blackfin/mach-bf527/anomaly.h index 7c5127e..035e8d8 100644 --- a/include/asm-blackfin/mach-bf527/anomaly.h +++ b/include/asm-blackfin/mach-bf527/anomaly.h @@ -7,82 +7,154 @@ */ /* This file shoule be up to date with: - * - Revision C, 01/25/2008; ADSP-BF527 Blackfin Processor Anomaly List + * - Revision B, 08/12/2008; ADSP-BF526 Blackfin Processor Anomaly List + * - Revision E, 08/18/2008; ADSP-BF527 Blackfin Processor Anomaly List */ #ifndef _MACH_ANOMALY_H_ #define _MACH_ANOMALY_H_ +#if defined(__ADSPBF522__) || defined(__ADSPBF524__) || defined(__ADSPBF526__) +# define ANOMALY_BF526 1 +#else +# define ANOMALY_BF526 0 +#endif +#if defined(__ADSPBF523__) || defined(__ADSPBF525__) || defined(__ADSPBF527__) +# define ANOMALY_BF527 1 +#else +# define ANOMALY_BF527 0 +#endif + /* Multi-Issue Instruction with dsp32shiftimm in slot1 and P-reg Store in slot2 Not Supported */ #define ANOMALY_0574 (1) /* DMA_RUN Bit Is Not Valid after a Peripheral Receive Channel DMA Stops */ -#define ANOMALY_05000119 (1) +#define ANOMALY_05000119 (1) /* note: brokenness is noted in documentation, not anomaly sheet */ /* Rx.H Cannot Be Used to Access 16-bit System MMR Registers */ #define ANOMALY_05000122 (1) /* Spurious Hardware Error from an Access in the Shadow of a Conditional Branch */ #define ANOMALY_05000245 (1) /* Sensitivity To Noise with Slow Input Edge Rates on External SPORT TX and RX Clocks */ #define ANOMALY_05000265 (1) -/* Errors when SSYNC, CSYNC, or Loads to LT, LB and LC Registers Are Interrupted */ -#define ANOMALY_05000312 (1) +/* False Hardware Errors Caused by Fetches at the Boundary of Reserved Memory */ +#define ANOMALY_05000310 (1) +/* PPI Is Level-Sensitive on First Transfer In Single Frame Sync Modes */ +#define ANOMALY_05000313 (__SILICON_REVISION__ < 2) /* Incorrect Access of OTP_STATUS During otp_write() Function */ -#define ANOMALY_05000328 (1) +#define ANOMALY_05000328 (ANOMALY_BF527 && __SILICON_REVISION__ < 2) /* Disallowed Configuration Prevents Subsequent Allowed Configuration on Host DMA Port */ -#define ANOMALY_05000337 (1) +#define ANOMALY_05000337 (ANOMALY_BF527 && __SILICON_REVISION__ < 2) /* Ethernet MAC MDIO Reads Do Not Meet IEEE Specification */ -#define ANOMALY_05000341 (1) +#define ANOMALY_05000341 (ANOMALY_BF527 && __SILICON_REVISION__ < 2) /* TWI May Not Operate Correctly Under Certain Signal Termination Conditions */ -#define ANOMALY_05000342 (1) +#define ANOMALY_05000342 (ANOMALY_BF527 && __SILICON_REVISION__ < 2) /* USB Calibration Value Is Not Initialized */ -#define ANOMALY_05000346 (1) +#define ANOMALY_05000346 (ANOMALY_BF527 && __SILICON_REVISION__ < 2) +/* USB Calibration Value to use */ +#define ANOMALY_05000346_value 0xE510 /* Preboot Routine Incorrectly Alters Reset Value of USB Register */ -#define ANOMALY_05000347 (1) +#define ANOMALY_05000347 (ANOMALY_BF527 && __SILICON_REVISION__ < 2) /* Security Features Are Not Functional */ -#define ANOMALY_05000348 (__SILICON_REVISION__ < 1) +#define ANOMALY_05000348 (ANOMALY_BF527 && __SILICON_REVISION__ < 1) +/* bfrom_SysControl() Firmware Function Performs Improper System Reset */ +#define ANOMALY_05000353 (ANOMALY_BF526) /* Regulator Programming Blocked when Hibernate Wakeup Source Remains Active */ -#define ANOMALY_05000355 (1) +#define ANOMALY_05000355 (ANOMALY_BF527 && __SILICON_REVISION__ < 2) /* Serial Port (SPORT) Multichannel Transmit Failure when Channel 0 Is Disabled */ -#define ANOMALY_05000357 (1) +#define ANOMALY_05000357 (ANOMALY_BF527 && __SILICON_REVISION__ < 2) /* Incorrect Revision Number in DSPID Register */ -#define ANOMALY_05000364 (__SILICON_REVISION__ > 0) +#define ANOMALY_05000364 (ANOMALY_BF527 && __SILICON_REVISION__ == 1) /* PPI Underflow Error Goes Undetected in ITU-R 656 Mode */ #define ANOMALY_05000366 (1) -/* New Feature: Higher Default CCLK Rate */ -#define ANOMALY_05000368 (1) +/* Incorrect Default CSEL Value in PLL_DIV */ +#define ANOMALY_05000368 (ANOMALY_BF527 && __SILICON_REVISION__ < 2) /* Possible RETS Register Corruption when Subroutine Is under 5 Cycles in Duration */ -#define ANOMALY_05000371 (1) +#define ANOMALY_05000371 (ANOMALY_BF527 && __SILICON_REVISION__ < 2) /* Authentication Fails To Initiate */ -#define ANOMALY_05000376 (__SILICON_REVISION__ > 0) +#define ANOMALY_05000376 (ANOMALY_BF527 && __SILICON_REVISION__ < 2) /* Data Read From L3 Memory by USB DMA May be Corrupted */ -#define ANOMALY_05000380 (1) -
[U-Boot] [PATCH] ARM: synchronize mach-types.h with linux 2.6.29-rc3
This change is to support Zoom2. #define MACH_TYPE_OMAP_ZOOM2 1967 The file was generated from building the default arm config of git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git 18e352e4a73465349711a9324767e1b2453383e2 or tag Linux 2.6.29-rc3 It was tested with MAKEALL arm Tom >From a753c5d792fe9c61c39dfa779bfdd4a4bab43e84 Mon Sep 17 00:00:00 2001 From: Tom Rix Date: Tue, 3 Feb 2009 15:37:43 -0600 Subject: [PATCH] ARM: synchronize mach-types.h with linux 2.6.29-rc3 --- include/asm-arm/mach-types.h | 1753 +- 1 files changed, 1741 insertions(+), 12 deletions(-) diff --git a/include/asm-arm/mach-types.h b/include/asm-arm/mach-types.h index ce6d25f..2c1e69b 100644 --- a/include/asm-arm/mach-types.h +++ b/include/asm-arm/mach-types.h @@ -1376,7 +1376,7 @@ extern unsigned int __machine_arch_type; #define MACH_TYPE_OLIP81378 #define MACH_TYPE_GHI270HG 1379 #define MACH_TYPE_DAVINCI_DM6467_EVM 1380 -#define MACH_TYPE_DAVINCI_DM350_EVM1381 +#define MACH_TYPE_DAVINCI_DM355_EVM1381 #define MACH_TYPE_BLACKRIVER 1383 #define MACH_TYPE_SANDGATEWP 1384 #define MACH_TYPE_CDOTBWSG 1385 @@ -1806,7 +1806,7 @@ extern unsigned int __machine_arch_type; #define MACH_TYPE_PILZ_PMI51820 #define MACH_TYPE_JADE 1821 #define MACH_TYPE_KS8695_SOFTPLC 1822 -#define MACH_TYPE_GPRISC4 1823 +#define MACH_TYPE_GPRISC3 1823 #define MACH_TYPE_STAMP92601824 #define MACH_TYPE_SMDK6430 1825 #define MACH_TYPE_SMDKC100 1826 @@ -1857,6 +1857,139 @@ extern unsigned int __machine_arch_type; #define MACH_TYPE_IMX27IPCAM 1871 #define MACH_TYPE_NEMOC1872 #define MACH_TYPE_GENEVA 1873 +#define MACH_TYPE_HTCPHAROS1874 +#define MACH_TYPE_NEONC1875 +#define MACH_TYPE_NAS7100 1876 +#define MACH_TYPE_TEUPHONE 1877 +#define MACH_TYPE_ANNAX_ETH2 1878 +#define MACH_TYPE_CSB733 1879 +#define MACH_TYPE_BK3 1880 +#define MACH_TYPE_OMAP_EM321881 +#define MACH_TYPE_ET9261CP 1882 +#define MACH_TYPE_JASPERC 1883 +#define MACH_TYPE_ISSI_ARM91884 +#define MACH_TYPE_UED 1885 +#define MACH_TYPE_ESIBLADE 1886 +#define MACH_TYPE_EYE021887 +#define MACH_TYPE_IMX27KBD 1888 +#define MACH_TYPE_SST61VC010_FPGA 1889 +#define MACH_TYPE_KIXVP435 1890 +#define MACH_TYPE_KIXNP435 1891 +#define MACH_TYPE_AFRICA 1892 +#define MACH_TYPE_NH2331893 +#define MACH_TYPE_RD88F6183AP_GE 1894 +#define MACH_TYPE_BCM4760 1895 +#define MACH_TYPE_EDDY_V2 1896 +#define MACH_TYPE_REALVIEW_PBA81897 +#define MACH_TYPE_HID_A7 1898 +#define MACH_TYPE_HERO 1899 +#define MACH_TYPE_OMAP_POSEIDON1900 +#define MACH_TYPE_REALVIEW_PBX 1901 +#define MACH_TYPE_MICRO9S 1902 +#define MACH_TYPE_MAKO 1903 +#define MACH_TYPE_XDAFLAME 1904 +#define MACH_TYPE_PHIDGET_SBC2 1905 +#define MACH_TYPE_LIMESTONE1906 +#define MACH_TYPE_IPROBE_C32 1907 +#define MACH_TYPE_RUT100 1908 +#define MACH_TYPE_ASUSP535 1909 +#define MACH_TYPE_HTCRAPHAEL 1910 +#define MACH_TYPE_SYGDG1 1911 +#define MACH_TYPE_SYGDG2 1912 +#define MACH_TYPE_SEOUL1913 +#define MACH_TYPE_SALERNO 1914 +#define MACH_TYPE_UCN_S3C64XX 1915 +#define MACH_TYPE_MSM7201A 1916 +#define MACH_TYPE_LPR1 1917 +#define MACH_TYPE_ARMADILLO500FX 1918 +#define MACH_TYPE_G3EVM1919 +#define MACH_TYPE_Z3_DM355 1920 +#define MACH_TYPE_W90P910EVB 1921 +#define MACH_TYPE_W90P920EVB 1922 +#define MACH_TYPE_W90P950EVB 1923 +#define MACH_TYPE_W90N960EVB 1924 +#define MACH_TYPE_CAMHD1925 +#define MACH_TYPE_MVC100 1926 +#define MACH_TYPE_ELECTRUM_200 1927 +#define MACH_TYPE_HTCJADE 1928 +#define MACH_TYPE_MEMPHIS 1929 +#define MACH_TYPE_IMX27SBC 1930 +#define MACH_TYPE_LEXTAR 1931 +#define MACH_TYPE_MV88F6281GTW_GE 1932 +#define MACH_TYPE_NCP 1933 +#define MACH_TYPE_Z32AN1934 +#define MACH_TYPE_TMQ_CAPD 1935 +#define MACH_TYPE_OMAP3_WL 1936 +#define MACH_TYPE_CHUMBY 1937 +#define MACH_TYPE_ATSARM9 1938 +#define MACH_TYPE_DAVINCI_DM365_EVM1939 +#define MACH_TYPE_BAHAMAS 1940 +#define MACH_TYPE_DAS 1941 +#define MACH_TYPE_MINIDAS 1942 +#define MACH_TYPE_VK1000
Re: [U-Boot] using more that 2gig of Memory.
On Feb 3, 2009, at 5:33 PM, hamoshame Lamoteku wrote: > I have search through the archives, and didn't find anything. > > Has anyone setup u-boot to configure more than 2gig of main memory? > > Where does u-boot go in the 36 bit world. > > is it possible to configure 2gig on each DDR controller of the MPC8572 > and have u-boot run right out of the box? > > I know u-boot load itself way out at the end of memory, but in this > case, that would be > 0x1-fff8- In practice this should work with the latest u-boot (v2009.01). Additionally, changes have been going in for the next release v2009.03 for 36-bit physical on 8572. I was going to try putting 4G of DDR in a MPC8572 DS tomorrow. I'll let you know what happens. - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
