Re: [U-Boot] [PATCH v3] [ARM] at91: Add support for taskit AT91SAM9G20 boards
Hello Tom, are there still objections to our patch or has it just got forgotten? Kind regards Achim -- product manager email:aehrl...@taskit.de Tel.: ++49 30 611295-25 Fax: ++49 30 611295-11 -- taskit GmbH Seelenbinderstr. 33 | D-12555 Berlin web:http://www.taskit.de Amtsgericht Charlottenburg: 93HRB39014 Managing director: Thorsten Raulfs -- ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] libfdt: make fdt_increase_size() available to everyone
Dear Timur Tabi, In message 4bf4623b.1080...@freescale.com you wrote: Why would this in any way be a board specific implementation? This makes no sense to me. The feature to include some binary data into the DTB is IMO in no way dependent on or specific to a certain board. The data I'm trying to embed is firmware for various devices on some of our SOCs, such as the QE on the MPC8360. Only boards with SOCs that have these devices come with firmware, and not all of them require the firmware to be passed to Linux. Yes, I know all of this. This is your specific use case. But maybe you can take the blinkers off for a moment, and face up to other potential use cases as well? User A might want to ambed a FPGA bit stream, user B something we don't even dream of yet. Instead of implementing this feature in a way that makes it restricted to your current use case only we can as well make it generic enough so others can use it as well. Please note that fdt_increase_size() is just a front-end to fdt_open_into(), so technically I don't need to fdt_increase_size(). However, you said you would reject any patch that uses fdt_open_into() in this manner, so we're back to square one. Back to square one? I did not realize you ever left that position ;-) Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Do not simplify the design of a program if a way can be found to make it complex and wonderful. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/1] Fix hang trying to protect flash sectors
Dear Chris Packham, In message loom.20100520t005209-...@post.gmane.org you wrote: While it would be possible to shuffle the memory map around there is one problem with the hardware design that I don't think can be overcome (I'd love to be proven wrong). The boot chip select is mapped to the _bottom_ of the first flash chip. It was done this way so that we could expand the flash in the future as a rolling production change (we're now shipping units with 64MB fitted). i.e. we knew we could rely on a fixed base address so thats where we pointed the boot chip select. I don't see why this should be relevant. Usually you can set up nearly any memory map in software, independent of the CPU state at boot time. Which exact processor family are we talking about? I think in hindsight we could have modified our flash detection code to start at the top and jump backwards looking for extra chips. Unfortunately What do you mean by our flash detection code? Are you using any private code for that? Why? U-Boot already has all the needed stuff, just use it. we're not able to change the hardware design for this product but we can take this into account on future designs. I'm not convinced that any hardware changes would be needed. 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 Don't panic. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] *** Warning - bad CRC, using default environment
On 20/05/10 04:43, anup behare wrote: Hi Nick, I observed that when i used saveenv the warning never occurred, but when i used to erase the flash and burn the u-boot that warning comes again hence I will have to use saveenv on u-boot command prompt. ~Anup Yes, indeed! The warning was trying to let you know that your work flow is wrong. Flash can be eased in sectors. The env should be in a sector(s) on it's own. There is no need to erase that sector(s) to re-flash U-Boot. Erase only U-Boot before re-flashing U-Boot. This will keep all you env data (which is valuable) intact and the warning will not reappear. If it does reappear you've done /something/ wrong and the warning will catch that for you again. It's a good warning, honestly. Hang on to it. Learn to love it. Nick. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] flash: Check info pointer in flash_protect().
Dear Mark Tomlinson, In message 1274160395-9308-2-git-send-email-mark.tomlin...@alliedtelesis.co.nz you wrote: Some calls to flash_protect() do not check that info is not NULL. This change prevents this from causing random memory to be stomped on. When exactly would that be the case? NOTICE: This message contains privileged and confidential information intended only for the use of the addressee named above. If you are not the intended recipient of ... Such terms are obviously unacceptable for any code that is supposed to go into mainline. 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 C-shell doesn't parse. It adhoculates. - casper@holland.sun.com in 3ol96k$...@engnews2.eng.sun.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Support similar boards at same board file?
Dear Wolfgang, I will post two boards aquila and goni. (s5pc110 soc) These board are very similar and can detect the board by gpio. (at runtime) So, I want to support these two boards at same board file. Thus, I will use same binary at two boards. How you think? Please give your opinion. Thanks Minkyu Kang -- from. prom. www.promsoft.net ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Booting with rootfs on ramdisk
Hi Peter Thanks for your help, I did as you suggested and it seems to go further, however, it couldn't successfully mount the rootfs, and come back as No filesystem could mount root, tried: ext2 cramfs msdos vfat Is there anything I should compile in the linux kernel, I've make sure, ticks in ltib for followings: 1. Second extended fs support 2. Kernel automounter version 4 support (..) Any pointers much appreciated, and thanks in advance. Ayewin Full boot output. === uboot run bootcmd HW MAC address: A0:70:64:6B:58:C7 Link Active Port 0 Speed 100Mbits, FullDuplex. TFTP from server 192.168.2.4; our IP address is 192.168.2.6 Filename 'uImage'. Load address: 0x8000 Loading: # done Bytes transferred = 1416776 (159e48 hex) HW MAC address: A0:70:64:6B:58:C7 Link Active Port 0 Speed 100Mbits, FullDuplex. TFTP from server 192.168.2.4; our IP address is 192.168.2.6 Filename 'rootfs.ext2.gz.uboot'. Load address: 0x8100 Loading: # # # # # # ## done Bytes transferred = 5745973 (57ad35 hex) ## Booting kernel from Legacy Image at 8000 ... Image Name: Linux-2.6.27.8 Image Type: ARM Linux Kernel Image (uncompressed) Data Size:1416712 Bytes = 1.4 MB Load Address: 80008000 Entry Point: 80008000 Verifying Checksum ... OK ## Loading init Ramdisk from Legacy Image at 8100 ... Image Name: uboot ext2 ramdisk rootfs Image Type: ARM Linux RAMDisk Image (gzip compressed) Data Size:5745909 Bytes = 5.5 MB Load Address: Entry Point: Verifying Checksum ... OK Loading Kernel Image ... OK OK Starting kernel ... Uncompressing Linux... done, booting the kernel. �Linux version 2.6.27.8 (engin...@maymyo) (gcc version 4.1.2) #58 PREEMPT Thu May 20 09:37:03 BST 2010 CPU: ARM926EJ-S [41069264] revision 4 (ARMv5TEJ), cr=00053177 Machine: Padauk Systems PTP16P Board Memory policy: ECC disabled, Data cache writeback CPU0: D VIVT write-back cache CPU0: I cache: 32768 bytes, associativity 4, 32 byte lines, 256 sets CPU0: D cache: 32768 bytes, associativity 4, 32 byte lines, 256 sets Built 1 zonelists in Zone order, mobility grouping off. Total pages: 4064 Kernel command line: mem=16M console=ttyS0,115200n8 root=/dev/ram rw ramdisk_size=16384 ip=dhcp ethaddr=a0:70:64:6b:58:c7 PID hash table entries: 64 (order: 6, 256 bytes) Console: colour dummy device 80x30 Dentry cache hash table entries: 2048 (order: 1, 8192 bytes) Inode-cache hash table entries: 1024 (order: 0, 4096 bytes) Memory: 16MB = 16MB total Memory: 13188KB available (2696K code, 199K data, 104K init) Calibrating delay loop... 84.73 BogoMIPS (lpj=169472) Mount-cache hash table entries: 512 CPU: Testing write buffer coherency: ok net_namespace: 288 bytes NET: Registered protocol family 16 LPC32XX DMA driver LPC32XX unique ID: 0006291c75701b6e58dc8cb71086f480 SCSI subsystem initialized NET: Registered protocol family 2 IP route cache hash table entries: 1024 (order: 0, 4096 bytes) TCP established hash table entries: 512 (order: 0, 4096 bytes) TCP bind hash table entries: 512 (order: -1, 2048 bytes) TCP: Hash tables configured (established 512 bind 512) TCP reno registered NET: Registered protocol family 1 NetWinder Floating Point Emulator V0.97 (double precision) JFFS2 version 2.2. (NAND) (SUMMARY) © 2001-2006 Red Hat, Inc. msgmni has been set to 25 io scheduler noop registered io scheduler anticipatory registered io scheduler deadline registered io scheduler cfq registered (default) Serial: 8250/16550 driver4 ports, IRQ sharing disabled serial8250.0: ttyS0 at MMIO 0x4009 (irq = 9) is a 16550A console [ttyS0] enabled brd: module loaded loop: module loaded LPC32XX_mii_bus: probed eth0: LPC32XX mac at 0x3106 irq 29 eth0: attached PHY driver [Generic PHY] (mii_bus:phy_addr=0:00, irq=-1) Driver 'sd' needs updating - please use bus_type methods NAND device: Manufacturer ID: 0xad, Chip ID: 0xda (Hynix NAND 256MiB 3,3V 8-bit) Scanning device for bad blocks Creating 7 MTD partitions on lpc32xx_nand: 0x-0x0004 : ptp16p-kickstart 0x0004-0x000c : ptp16p-s1l 0x000c-0x0022 : ptp16p-wlv 0x0022-0x0026 : ptp16p-bparams 0x0026-0x0036 : ptp16p-uboot 0x0040-0x0200 : ptp16p-kernel 0x0200-0x1000 : ptp16p-rootfs mice: PS/2 mouse device common for all mice rtc-lpc32xx rtc-lpc32xx: rtc core: registered rtc-lpc32xx as rtc0 i2c /dev entries driver PNX4008-WDT:
Re: [U-Boot] Support similar boards at same board file?
Hi Minkyu, On Thursday 20 May 2010 10:46:43 Minkyu Kang wrote: I will post two boards aquila and goni. (s5pc110 soc) These board are very similar and can detect the board by gpio. (at runtime) So, I want to support these two boards at same board file. Thus, I will use same binary at two boards. How you think? Please give your opinion. We usually don't want or even accept code duplications resulting from similar boards. So I definitely prefer such a runtime detection of the board type. Cheers, Stefan -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-0 Fax: (+49)-8142-66989-80 Email: off...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Support similar boards at same board file?
Dear Minkyu Kang, In message aanlktikgitnfue9uqzpgjw5gitmrwylk6asqbqqml...@mail.gmail.com you wrote: I will post two boards aquila and goni. (s5pc110 soc) These board are very similar and can detect the board by gpio. (at runtime) So, I want to support these two boards at same board file. Thus, I will use same binary at two boards. OK. How you think? Please give your opinion. Sorry, but I fail to see a question? 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 ever becomes real until it is experienced. - John Keats ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] libfdt: make fdt_increase_size() available to everyone
On Thu, May 20, 2010 at 3:28 AM, Wolfgang Denk w...@denx.de wrote: Dear Timur Tabi, In message 4bf4623b.1080...@freescale.com you wrote: Why would this in any way be a board specific implementation? This makes no sense to me. The feature to include some binary data into the DTB is IMO in no way dependent on or specific to a certain board. The data I'm trying to embed is firmware for various devices on some of our SOCs, such as the QE on the MPC8360. Only boards with SOCs that have these devices come with firmware, and not all of them require the firmware to be passed to Linux. Yes, I know all of this. This is your specific use case. But maybe you can take the blinkers off for a moment, and face up to other potential use cases as well? Come on, Wolfgang. Why do you think I posted this patch in the first place? I even said so in the title of patch: make fdt_increase_size() available to everyone. You asked why the information would be board-specific, and I answered that question. Now I believe you're intentionally trying to be difficult. User A might want to ambed a FPGA bit stream, user B something we don't even dream of yet. Which is exactly why I want fdt_increase_size() to be available to everyone. Instead of implementing this feature in a way that makes it restricted to your current use case only we can as well make it generic enough so others can use it as well. Exactly! And the best way to do that is to make the function that adds space to the fdt available to everyone. Please note that fdt_increase_size() is just a front-end to fdt_open_into(), so technically I don't need to fdt_increase_size(). However, you said you would reject any patch that uses fdt_open_into() in this manner, so we're back to square one. Back to square one? I did not realize you ever left that position ;-) How silly of me. For a moment, I forgot that I was trying to improve U-Boot. -- Timur Tabi Linux kernel developer at Freescale ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Watchdog support for ppc4xx
Hi Mark,
On Thursday 20 May 2010 00:27:50 Mark Maestas wrote:
I have a question about watchdog support for PPC_4xx. When I define
CONFIG_WATCHDOG in canyonlands.h, I get an error when building
cpu_init.c. The error code reads:
{standard input}: Assembler messages:
{standard input}:133: Error: unsupported relocation against tcr
{standard input}:141: Error: unsupported relocation against tcr
{standard input}:146: Error: unsupported relocation against tsr
{standard input}:154: Error: unsupported relocation against tsr
make[1]: *** [cpu_init.o] Error 1
Shouldn't this work?
It *should*. But unfortunately it doesn't. I just checked this here myself. I
get the same error. Seems that the tcr/tsr defines need to be converted to
upper-case. It would be great if you could send a patch for this.
Also I would like to determine in u-boot if a
reset was caused by the watchdog timer using the TSR WRS field. If it
was reset by the watchdog we will boot into a failsafe partition to
protect against system update errors.
Has anyone done something like this?
Such a detection is not implemented for PPC4xx. Not sure if it's implemented
for any other architecture.
Cheers,
Stefan
--
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-0 Fax: (+49)-8142-66989-80 Email: off...@denx.de
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] x86 Custodianship
Hi Wolfgang, I've been a bit busy at home with bub #2 to chase this up, but have you decided whether or not to create an x86 repository? If so, I would be happy to take up custodianship of it and 'fly the flag' for U-Boot on the x86 platform. I sent you my public RSA key earlier - let me know if you want me to resend Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] libfdt: make fdt_increase_size() available to everyone
Kumar Gala wrote:
int boot_relocate_fdt (struct lmb *lmb, ulong bootmap_base,
char **of_flat_tree, ulong *of_size)
{
...
if ((fdt_blob + *of_size + fdt_board_size()) =
((char *)CONFIG_SYS_BOOTMAPSZ + bootmap_base))
relocate = 1;
Kumar, what do you think about having boot_relocate_fdt() always relocate
the fdt, even if it is already in the bootmap? That would ensure that it
gets resized and put into an lmb region.
--
Timur Tabi
Linux kernel developer at Freescale
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] *** Warning - bad CRC, using default environment
Hi Nick, Yes, indeed! The warning was trying to let you know that your work flow is wrong. Flash can be eased in sectors. The env should be in a sector(s) on it's own. There is no need to erase that sector(s) to re-flash U-Boot. Erase only U-Boot before re-flashing U-Boot. This will keep all you env data (which is valuable) intact and the warning will not reappear. If it does reappear you've done /something/ wrong and the warning will catch that for you again. Just for completeness, let me mention that we have configurations where the environment is embedded into the U-Boot image, so there you have to erase the env in flash to reprogram U-Boot. Furtunately one usually updates U-Boot out of a running copy of it, so after the reflash a saveenv solves this specific problem nicely ;) Cheers Detlev -- Narren sind alle, die es scheinen, und die Haelfte derer, die es nicht scheinen .. Jedoch ist der groesste Narr, wer es nicht zu sein glaubt und alle andern dafuer erklaert. --- Baltasar Gracian -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: d...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] libfdt: make fdt_increase_size() available to everyone
On May 19, 2010, at 5:06 PM, Wolfgang Denk wrote:
Dear Kumar Gala,
In message 52e9d06a-e721-4907-9024-11bdc8d00...@kernel.crashing.org you
wrote:
So I tried to read this whole thread and got lost in the discussion.
I'm wondering of something along the following lines would address your
concerns:
My concerns are simple: if we need to increase the size of the FDT
because we pull in some random amountof data, we should make sure to
have enough room for this, or fail with a clear error message.
And we should not try to use fixed sized buffers, but instead adapt
to the actual amount required by the end user.
Timur assumes that all such code and it's sizess will be known in
advance, and I disagree - other users will have other ideas what they
can do with this, and his assumptions will break.
#define CONFIG_SYS_FDT_PAD 0x3000
Where exactly is this 0x3000 coming from?
I think this was done to manage some growth of the dtb based on board fix ups.
However, not sure where the number came from.
/* Allow for arch specific config before we boot */
int __fdt_board_size(void)
{
return CONFIG_SYS_FDT_PAD;
}
int fdt_board_size(void) __attribute__((weak, alias(__
fdt_board_size)));
int boot_relocate_fdt (struct lmb *lmb, ulong bootmap_base,
char **of_flat_tree, ulong *of_size)
{
...
if ((fdt_blob + *of_size + fdt_board_size()) =
((char *)CONFIG_SYS_BOOTMAPSZ + bootmap_base))
relocate = 1;
...
}
Than board specific code knows what fix ups might happen and can
implement dynamic behavior and do something like:
If any board specific code can determine the needed sizes, then how
would such code differ from one board to another?
Why would this in any way be a board specific implementation? This
makes no sense to me. The feature to include some binary data into the
DTB is IMO in no way dependent on or specific to a certain board.
I agree this isn't 100% board specific, but my intent was to leave it under the
board control. One assumes the board knows if it needs firmware blob A in dtb
or not.
It follows the same logic as why we have ft_board_setup.
- k
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/2] powerpc/bootcount: Add bootcount support for MPC512x
From: Michael Weiss michael.we...@ifm.com This also uses the breadcrumb register as on MPC5200. Signed-off-by: Michael Weiss michael.we...@ifm.com Signed-off-by: Detlev Zundel d...@denx.de --- arch/powerpc/lib/bootcount.c |5 + 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/arch/powerpc/lib/bootcount.c b/arch/powerpc/lib/bootcount.c index 6346527..0373a20 100644 --- a/arch/powerpc/lib/bootcount.c +++ b/arch/powerpc/lib/bootcount.c @@ -35,6 +35,11 @@ #define CONFIG_SYS_BOOTCOUNT_SINGLEWORD #endif /* defined(CONFIG_MPC5xxx) */ +#if defined(CONFIG_MPC512X) +#define CONFIG_SYS_BOOTCOUNT_ADDR (((immap_t *)CONFIG_SYS_IMMR)-clk.bcr) +#define CONFIG_SYS_BOOTCOUNT_SINGLEWORD +#endif /* defined(CONFIG_MPC512X) */ + #if defined(CONFIG_8xx) #define CONFIG_SYS_BOOTCOUNT_ADDR (((immap_t *)CONFIG_SYS_IMMR)-im_cpm.cp_dpmem + \ CPM_BOOTCOUNT_ADDR) -- 1.6.2.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/2] powerpc/bootcount: Fix endianness problem
From: Michael Weiss michael.we...@ifm.com For CONFIG_SYS_BOOTCOUNT_SINGLEWORD the code had an endianness problem. Signed-off-by: Michael Weiss michael.we...@ifm.com Signed-off-by: Detlev Zundel d...@denx.de --- arch/powerpc/lib/bootcount.c |6 -- 1 files changed, 4 insertions(+), 2 deletions(-) diff --git a/arch/powerpc/lib/bootcount.c b/arch/powerpc/lib/bootcount.c index 0373a20..07ef28d 100644 --- a/arch/powerpc/lib/bootcount.c +++ b/arch/powerpc/lib/bootcount.c @@ -82,10 +82,12 @@ ulong bootcount_load(void) void *reg = (void *)CONFIG_SYS_BOOTCOUNT_ADDR; #if defined(CONFIG_SYS_BOOTCOUNT_SINGLEWORD) - if (in_be16(reg + 2) != (BOOTCOUNT_MAGIC 0x)) + u32 tmp = in_be32(reg); + + if ((tmp 0x) != (BOOTCOUNT_MAGIC 0x)) return 0; else - return in_be16(reg); + return (tmp 0x); #else if (in_be32(reg + 4) != BOOTCOUNT_MAGIC) return 0; -- 1.6.2.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/2] fsl/85xx: add clkdvdr to global utilities structure definition
Add the 'clkdvdr' to the 85xx definition of struct ccsr_gur.
Signed-off-by: Timur Tabi ti...@freescale.com
---
arch/powerpc/include/asm/immap_85xx.h |9 ++---
1 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/include/asm/immap_85xx.h
b/arch/powerpc/include/asm/immap_85xx.h
index e7954e6..5b205d1 100644
--- a/arch/powerpc/include/asm/immap_85xx.h
+++ b/arch/powerpc/include/asm/immap_85xx.h
@@ -1912,7 +1912,8 @@ typedef struct ccsr_gur {
#define MPC85xx_PMUXCR_SD_DATA 0x8000
#define MPC85xx_PMUXCR_SDHC_CD 0x4000
#define MPC85xx_PMUXCR_SDHC_WP 0x2000
- u8 res6[12];
+ u32 pmuxcr2;/* Alt. function signal multiplex control 2 */
+ u8 res6[8];
u32 devdisr;/* Device disable control */
#define MPC85xx_DEVDISR_PCI1 0x8000
#define MPC85xx_DEVDISR_PCI2 0x4000
@@ -1949,10 +1950,12 @@ typedef struct ccsr_gur {
#if defined(CONFIG_MPC8568)||defined(CONFIG_MPC8569)
u8 res10b[76];
par_io_t qe_par_io[7];
- u8 res10c[3136];
+ u8 res10c[1600];
#else
- u8 res10b[3404];
+ u8 res10b[1868];
#endif
+ u32 clkdvdr;/* Clock Divide register */
+ u8 res10d[1532];
u32 clkocr; /* Clock out select */
u8 res11[12];
u32 ddrdllcr; /* DDR DLL control */
--
1.6.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/2] fsl: rename 'dma' to 'brdcfg1' in the ngPIXIS structure
The ngPIXIS is a board-specific FPGA, but the definition of the registers
is mostly consistent. On boards where it matter, register 9 is called
'brdcfg1' instead of 'dma', so rename the variable in the ngpixis_t
definition.
Signed-off-by: Timur Tabi ti...@freescale.com
---
board/freescale/common/ngpixis.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/board/freescale/common/ngpixis.h b/board/freescale/common/ngpixis.h
index 284d044..3c59ea8 100644
--- a/board/freescale/common/ngpixis.h
+++ b/board/freescale/common/ngpixis.h
@@ -24,7 +24,7 @@ typedef struct ngpixis {
u8 aux;
u8 spd;
u8 brdcfg0;
- u8 dma;
+ u8 brdcfg1; /* On some boards, this register is called 'dma' */
u8 addr;
u8 res2[2];
u8 data;
--
1.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] fsl/85xx: add clkdvdr to global utilities structure definition
Hello.
Timur Tabi wrote:
Add the 'clkdvdr' to the 85xx definition of struct ccsr_gur.
You're also adding 'pmuxcr2'...
Signed-off-by: Timur Tabi ti...@freescale.com
---
arch/powerpc/include/asm/immap_85xx.h |9 ++---
1 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/include/asm/immap_85xx.h
b/arch/powerpc/include/asm/immap_85xx.h
index e7954e6..5b205d1 100644
--- a/arch/powerpc/include/asm/immap_85xx.h
+++ b/arch/powerpc/include/asm/immap_85xx.h
@@ -1912,7 +1912,8 @@ typedef struct ccsr_gur {
#define MPC85xx_PMUXCR_SD_DATA 0x8000
#define MPC85xx_PMUXCR_SDHC_CD 0x4000
#define MPC85xx_PMUXCR_SDHC_WP 0x2000
- u8 res6[12];
+ u32 pmuxcr2;/* Alt. function signal multiplex control 2 */
+ u8 res6[8];
u32 devdisr;/* Device disable control */
WBR, Sergei
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] mtest: Fix end address of increment/decrement test
From: John Schmoller jschmol...@xes-inc.com The incrememt/decrement test has an off-by-one error which results in an extra 4 bytes being tested past the specified end address. For instance, when running mtest 0x1000 0x2000, the bytes 0x2000-0x2003 would be tested which is counterintuitive and at odds with the end address calculation of other U-Boot memory tests. Example of original behavior: = md 0x2000 10 2000: deadbeef deadbeef deadbeef deadbeef 2010: deadbeef deadbeef deadbeef deadbeef 2020: deadbeef deadbeef deadbeef deadbeef 2030: deadbeef deadbeef deadbeef deadbeef = mtest 0x1000 0x2000 1 1 Testing 1000 ... 2000: Tested 1 iteration(s) with 0 errors. = md 0x2000 10 2000: deadbeef deadbeef deadbeef 2010: deadbeef deadbeef deadbeef deadbeef 2020: deadbeef deadbeef deadbeef deadbeef 2030: deadbeef deadbeef deadbeef deadbeef = This change results in the memory at 0x2000 not being modified by mtest in the example above. Signed-off-by: John Schmoller jschmol...@xes-inc.com Signed-off-by: Peter Tyser pty...@xes-inc.com --- common/cmd_mem.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/common/cmd_mem.c b/common/cmd_mem.c index 1839330..0bc3c70 100644 --- a/common/cmd_mem.c +++ b/common/cmd_mem.c @@ -862,7 +862,7 @@ int do_mem_mtest (cmd_tbl_t *cmdtp, int flag, int argc, char *argv[]) * * Returns: 0 if the test succeeds, 1 if the test fails. */ - num_words = ((ulong)end - (ulong)start)/sizeof(vu_long) + 1; + num_words = ((ulong)end - (ulong)start)/sizeof(vu_long); /* * Fill memory with a known pattern. -- 1.7.0.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] fsl/85xx: add clkdvdr and pmuxcr2 to global utilities structure definition
Add the 'clkdvdr' and 'pmuxcr2' registers to the 85xx definition of
struct ccsr_gur.
Signed-off-by: Timur Tabi ti...@freescale.com
---
This patch replaces fsl/85xx: add clkdvdr to global utilities structure
definition.
Thanks to Sergei Shtylyov.
arch/powerpc/include/asm/immap_85xx.h |9 ++---
1 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/include/asm/immap_85xx.h
b/arch/powerpc/include/asm/immap_85xx.h
index e7954e6..5b205d1 100644
--- a/arch/powerpc/include/asm/immap_85xx.h
+++ b/arch/powerpc/include/asm/immap_85xx.h
@@ -1912,7 +1912,8 @@ typedef struct ccsr_gur {
#define MPC85xx_PMUXCR_SD_DATA 0x8000
#define MPC85xx_PMUXCR_SDHC_CD 0x4000
#define MPC85xx_PMUXCR_SDHC_WP 0x2000
- u8 res6[12];
+ u32 pmuxcr2;/* Alt. function signal multiplex control 2 */
+ u8 res6[8];
u32 devdisr;/* Device disable control */
#define MPC85xx_DEVDISR_PCI1 0x8000
#define MPC85xx_DEVDISR_PCI2 0x4000
@@ -1949,10 +1950,12 @@ typedef struct ccsr_gur {
#if defined(CONFIG_MPC8568)||defined(CONFIG_MPC8569)
u8 res10b[76];
par_io_t qe_par_io[7];
- u8 res10c[3136];
+ u8 res10c[1600];
#else
- u8 res10b[3404];
+ u8 res10b[1868];
#endif
+ u32 clkdvdr;/* Clock Divide register */
+ u8 res10d[1532];
u32 clkocr; /* Clock out select */
u8 res11[12];
u32 ddrdllcr; /* DDR DLL control */
--
1.6.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Watchdog support for ppc4xx
Thanks Stefan,
I actually determined that after the git repository build did the same
thing. I changed it to use the SPRN_TCR and SPRN_TSR values but I did
see in processor.h where TSR and TCR are defined so I will modify it
based on those values. The watchdog reset notification is very useful
and we have done that with red boot on a different project so I will
make an attempt to implement the same functionality. Basically you need
to detect if the watchdog did force a reset and ideally how long the
system was running before it reset to determine which partition to boot
in a dual partition setup.
Thanks for the quick response. I will work to create a patch for this
functionality according to the u-boot standards.
Mark
-Original Message-
From: Stefan Roese [mailto:s...@denx.de]
Sent: Thursday, May 20, 2010 4:55 AM
To: u-boot@lists.denx.de
Cc: Mark Maestas
Subject: Re: [U-Boot] Watchdog support for ppc4xx
Hi Mark,
On Thursday 20 May 2010 00:27:50 Mark Maestas wrote:
I have a question about watchdog support for PPC_4xx. When I define
CONFIG_WATCHDOG in canyonlands.h, I get an error when building
cpu_init.c. The error code reads:
{standard input}: Assembler messages:
{standard input}:133: Error: unsupported relocation against tcr
{standard input}:141: Error: unsupported relocation against tcr
{standard input}:146: Error: unsupported relocation against tsr
{standard input}:154: Error: unsupported relocation against tsr
make[1]: *** [cpu_init.o] Error 1
Shouldn't this work?
It *should*. But unfortunately it doesn't. I just checked this here
myself. I
get the same error. Seems that the tcr/tsr defines need to be
converted to
upper-case. It would be great if you could send a patch for this.
Also I would like to determine in u-boot if a
reset was caused by the watchdog timer using the TSR WRS field. If it
was reset by the watchdog we will boot into a failsafe partition to
protect against system update errors.
Has anyone done something like this?
Such a detection is not implemented for PPC4xx. Not sure if it's
implemented
for any other architecture.
Cheers,
Stefan
--
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-0 Fax: (+49)-8142-66989-80 Email: off...@denx.de
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mtest: Fix end address of increment/decrement test
Dear Peter Tyser, In message 1274375283-13004-1-git-send-email-pty...@xes-inc.com you wrote: The incrememt/decrement test has an off-by-one error which results in an extra 4 bytes being tested past the specified end address. For instance, when running mtest 0x1000 0x2000, the bytes 0x2000-0x2003 would be tested which is counterintuitive and at odds with the end address calculation of other U-Boot memory tests. I disagree. I understand your reasoning, but actually it has always been the case that commands that take an address reagion specify as end address the last address to be used, not oni behind the range. You may not like this, but that's how it has been implemented 10 years ago, and many people are trained on this behaviour. See for example the flash erase command, wehre you will type something like = erase 4004 4007 Here, like in other places, we really use the end address. So for the sake of consisteny I tend to 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 A Perl script is correct if it's halfway readable and gets the job done before your boss fires you. - L. Wall R. L. Schwartz, _Programming Perl_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Watchdog support for ppc4xx
Dear Stefan Roese, In message 201005201355.01964...@denx.de you wrote: Also I would like to determine in u-boot if a reset was caused by the watchdog timer using the TSR WRS field. If it was reset by the watchdog we will boot into a failsafe partition to protect against system update errors. Has anyone done something like this? Such a detection is not implemented for PPC4xx. Not sure if it's implemented for any other architecture. I think lwmon5 performs such checking; eventually this is buryied somewhere in the POST code. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de It ain't so much the things we don't know that get us in trouble. It's the things we know that ain't so. - Artemus Ward aka Charles Farrar Brown ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Business Proposal
Hello, I am Mr. Chen Guangyuan, Foreign operations manager of bank of China, Hong Kong, It is understandable that you might be a little bit apprehensive because you do not know me but I have a lucrative business proposal of $17,300,000.00 to share with you. If interested please send me your: 1, Full names, 2, Occupation, 3, Private phone number, 4, Current residential address. NOTE: Please you are to reply me via this email address :mr.chenguangyua...@yahoo.com Regards Mr.Chen Guangyuan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/1] Fix hang trying to protect flash sectors
Hi Wolfgang, On Thu, May 20, 2010 at 1:35 AM, Wolfgang Denk w...@denx.de wrote: Dear Chris Packham, In message loom.20100520t005209-...@post.gmane.org you wrote: While it would be possible to shuffle the memory map around there is one problem with the hardware design that I don't think can be overcome (I'd love to be proven wrong). The boot chip select is mapped to the _bottom_ of the first flash chip. It was done this way so that we could expand the flash in the future as a rolling production change (we're now shipping units with 64MB fitted). i.e. we knew we could rely on a fixed base address so thats where we pointed the boot chip select. I don't see why this should be relevant. Usually you can set up nearly any memory map in software, independent of the CPU state at boot time. Which exact processor family are we talking about? Freescale MPC8541. CS0 is mapped by an external CPLD to either the bottom block of flash _or_ to a plug in card which has physical EPROMs which we use when we're bringing the board up. On newer designs we actually use pre-programmed flash chips in the factory and JTAG in circuit debuggers for development. I think in hindsight we could have modified our flash detection code to start at the top and jump backwards looking for extra chips. Unfortunately What do you mean by our flash detection code? Are you using any private code for that? Why? U-Boot already has all the needed stuff, just use it. This design was originally done for a proprietary boot loader before we saw the light and switched to u-boot. That was what I meant by our flash detection code. Recently we've just switched to using the CFI driver in the latest u-boot version. Prior to this (based on version 1.1.4) we still had our own board/.../flash.c. we're not able to change the hardware design for this product but we can take this into account on future designs. I'm not convinced that any hardware changes would be needed. I think we'd need 2 different boot loaders configurations, one for running from EPROM, one for running from flash. If we ignore the EPROM it wouldn't be too hard to re-define the memory map such that we have flash arranged with the boot loader and environment in the bottom 1MB of the first flash chip with the file system in the top 31MB and optionally the second flash chip. The plug in EPROM card is still very useful when you accidentally brick your board so we'd still want to have that, which could be done easily with the existing configuration. I'll look into shuffling the memory map around. It'd also be a good opportunity to start using the mtd maps in Linux. - C ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mtest: Fix end address of increment/decrement test
Hi Wolfgang, In message 1274375283-13004-1-git-send-email-pty...@xes-inc.com you wrote: The incrememt/decrement test has an off-by-one error which results in an extra 4 bytes being tested past the specified end address. For instance, when running mtest 0x1000 0x2000, the bytes 0x2000-0x2003 would be tested which is counterintuitive and at odds with the end address calculation of other U-Boot memory tests. I disagree. I understand your reasoning, but actually it has always been the case that commands that take an address reagion specify as end address the last address to be used, not oni behind the range. You may not like this, but that's how it has been implemented 10 years ago, and many people are trained on this behaviour. See for example the flash erase command, wehre you will type something like = erase 4004 4007 Here, like in other places, we really use the end address. So for the sake of consisteny I tend to reject your patch. I can see your point but the current memtest code is not consistent with your description. - Every other test other than the increment/decrement tests the region end address. Eg in the start:0x1000 end:0x2000 example, the *only* test that touches 0x2000-0x2003 region is the increment/decrement test. Either its broken, or the other memory test functions are. - The output of 'mtest' is misleading: = mtest 0x1000 0x2000 1 1 Testing 1000 ... 2000: That should be 1000 ... 2003 then, correct? (I know it should be 1000 ... 1fff to be consistent with this patch's implementation, so this argument is weak...) How would you like this cleaned up? Bring the address coverage of the other tests inline with the increment/decrement test? Improve the mtest output so its obvious what exactly is being tested? Best, Peter ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mtest: Fix end address of increment/decrement test
Dear Peter Tyser, In message 1274382441.18152.37.ca...@petert you wrote: I can see your point but the current memtest code is not consistent with your description. - Every other test other than the increment/decrement tests the region end address. Eg in the start:0x1000 end:0x2000 example, the *only* test that touches 0x2000-0x2003 region is the increment/decrement test. Either its broken, or the other memory test functions are. I think this might indeed be the case. IIRC I originally wrote only the simple increment/decrement test, and the other tests got added later by others, probably with nobody noticing the differing behaviour. - The output of 'mtest' is misleading: = mtest 0x1000 0x2000 1 1 Testing 1000 ... 2000: That should be 1000 ... 2003 then, correct? (I know it should No, it should not. The output shows the addresses where data is written to. If you write a 32 bit word to address 2000, this writes to the byte addresses 2000, 2001, 2002 and 2003 (assuming a big endian system). So the output actually is correct. be 1000 ... 1fff to be consistent with this patch's implementation, so this argument is weak...) No, because we do not actually write to this address (which would also be misaligned for a word write). How would you like this cleaned up? Bring the address coverage of the other tests inline with the increment/decrement test? Improve the mtest output so its obvious what exactly is being tested? Both, of course :-) Although I think the output is even correct, it just leaves room for misinterpretation. 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 ADVISORY: There is an Extremely Small but Nonzero Chance That, Through a Process Know as Tunneling, This Product May Spontaneously Disappear from Its Present Location and Reappear at Any Random Place in the Universe, Including Your Neighbor's Domicile. The Manufacturer Will Not Be Responsible for Any Damages or Inconvenience That May Result. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mtest: Fix end address of increment/decrement test
snip - The output of 'mtest' is misleading: = mtest 0x1000 0x2000 1 1 Testing 1000 ... 2000: That should be 1000 ... 2003 then, correct? (I know it should No, it should not. The output shows the addresses where data is written to. If you write a 32 bit word to address 2000, this writes to the byte addresses 2000, 2001, 2002 and 2003 (assuming a big endian system). So the output actually is correct. The current output leaves a lot of interpretation up to the user. Without digging into the code they won't know that 32-bits is written at 0x2000. They may think its a byte at 0x2000. Or maybe a 64-bit quantity, they'd have no idea. be 1000 ... 1fff to be consistent with this patch's implementation, so this argument is weak...) No, because we do not actually write to this address (which would also be misaligned for a word write). It depends on interpretation. eg: = mtest 0x1000 0x1ffd 1 1 Testing 1000 ... 1ffd: This is *really* testing bytes 0x1000-0x1fff. It's impossible for Joe User to figure that out though... How would you like this cleaned up? Bring the address coverage of the other tests inline with the increment/decrement test? Improve the mtest output so its obvious what exactly is being tested? Both, of course :-) Although I think the output is even correct, it just leaves room for misinterpretation. As far as the output, my vote would be to align the end address to a 32-bit address and add 3. eg assuming a starting address of 1000 and ending addresses of: 0x1ffc - output: Testing 1000 ... 1fff 0x1ffd - output: Testing 1000 ... 1fff 0x1ffe - output: Testing 1000 ... 1fff 0x1fff - output: Testing 1000 ... 1fff 0x2000 - output: Testing 1000 ... 2003 0x2001 - output: Testing 1000 ... 2003 ... This would tell the user explicitly what bytes have been tested and they wouldn't have to calculate alignments or know word sizes. Another possibility would be to replace the end address argument with a size argument. So mtest 0x1000 0x1000 would test 0x1000 bytes at address 0x1000, from 0x1000-0x1fff. I think that would be clearer to most people, but the downside is you'd have to do some math to calculate the size parameter in some cases (eg testing the region after exception vectors, but before the U-Boot image in RAM). Let me know what you think about how to display the tested memory region. I'm fine with leaving the end addr vs size debate for the next release, if at all. Best, Peter ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mtest: Fix end address of increment/decrement test
Dear Peter Tyser, In message 1274386292.18152.119.ca...@petert you wrote: The current output leaves a lot of interpretation up to the user. Agreed. This is one of the typical commands that where never well designed or even intnded for normal users, but serrved a purpose, and found useful, so it stuck. No surprise it has sharp edges ;-) It depends on interpretation. eg: = mtest 0x1000 0x1ffd 1 1 Testing 1000 ... 1ffd: To be honest - I wasn't even aware we support such a notation ;-) This is *really* testing bytes 0x1000-0x1fff. It's impossible for Joe User to figure that out though... ...not without reading the source code, indeed. But then, this is always a good excercise :-) As far as the output, my vote would be to align the end address to a 32-bit address and add 3. eg assuming a starting address of 1000 and ending addresses of: 0x1ffc - output: Testing 1000 ... 1fff 0x1ffd - output: Testing 1000 ... 1fff 0x1ffe - output: Testing 1000 ... 1fff 0x1fff - output: Testing 1000 ... 1fff 0x2000 - output: Testing 1000 ... 2003 0x2001 - output: Testing 1000 ... 2003 No, please do not implement such automatic alignment; it may be useful for some cases, but it may as well hurt, for example if you intentionally want to run mtest with misalignment, like giving both odd start and end addresses. Another possibility would be to replace the end address argument with a size argument. So mtest 0x1000 0x1000 would test 0x1000 bytes at address 0x1000, from 0x1000-0x1fff. I think that would be clearer to most people, but the downside is you'd have to do some math to calculate the size parameter in some cases (eg testing the region after exception vectors, but before the U-Boot image in RAM). I think it is more difficult to calculate the sizes instead of the end addresses. Let me know what you think about how to display the tested memory region. I'm fine with leaving the end addr vs size debate for the next release, if at all. I always appreciate is someone is thorough and willing enough to clean up such old mess. 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 For every complex problem, there is a solution that is simple, neat, and wrong. -- H. L. Mencken ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] Blackfin: nand: drain the write buffer before returning
On Fri, May 07, 2010 at 03:10:07PM -0400, Mike Frysinger wrote: From: Andrew Caldwell andrew.caldw...@analog.com The current Blackfin nand write function fills up the write buffer but returns before it has had a chance to drain. On faster systems, this isn't a problem as the operation finishes before the ECC registers are read, but on slower systems the ECC may be incomplete when the core tries to read it. So wait for the buffer to drain once we're done writing to it. Signed-off-by: Andrew Caldwell andrew.caldw...@analog.com Signed-off-by: Mike Frysinger vap...@gentoo.org --- v2 - fix inverted logic reminded by Andrew Applied to u-boot-nand-flash. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mtest: Fix end address of increment/decrement test
Hi Wolfgang, As far as the output, my vote would be to align the end address to a 32-bit address and add 3. eg assuming a starting address of 1000 and ending addresses of: 0x1ffc - output: Testing 1000 ... 1fff 0x1ffd - output: Testing 1000 ... 1fff 0x1ffe - output: Testing 1000 ... 1fff 0x1fff - output: Testing 1000 ... 1fff 0x2000 - output: Testing 1000 ... 2003 0x2001 - output: Testing 1000 ... 2003 No, please do not implement such automatic alignment; it may be useful for some cases, but it may as well hurt, for example if you intentionally want to run mtest with misalignment, like giving both odd start and end addresses. I didn't express it well, but what I was getting at was that the Testing X .. Y would ideally state exactly what is being tested. Unaligned addresses would still be allowed. I think right now the end address is always automatically aligned to the same alignment as the start address though, so the current output is very misleading. eg: mw.l 0x1000 0x12345678 0x1000 mtest 0x1003 0x1ffc 1 1 Testing 1003 ... 1ffc: ... md 0x1000 10; md 0x1ff0 10 1000: 12345600 .4V. 1010: 1020: 1030: 1ff0: 0078...x 2000: 12345678 12345678 12345678 12345678.4Vx.4Vx.4Vx.4Vx 2010: 12345678 12345678 12345678 12345678.4Vx.4Vx.4Vx.4Vx 2020: 12345678 12345678 12345678 12345678.4Vx.4Vx.4Vx.4Vx You can see the starting alignment was respected, but the ending alignment was truncated to be 32-bit aligned to the starting address. In the above example, I think it would be nice to see Testing 1003 ... 1ffe. Or some other way such that the user knows that their input wasn't executed to a T; their end address was truncated. Best, Peter ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] powerpc: add support for the Freescale P1022DS reference board
Add basic suport for the Freescale P1022DS reference board.
Signed-off-by: Timur Tabi ti...@freescale.com
---
This patch requires the following two patches to be applied first:
fsl/85xx: add clkdvdr and pmuxcr2 to global utilities structure definition
fsl: rename 'dma' to 'brdcfg1' in the ngPIXIS structure
Makefile |3 +
arch/powerpc/cpu/mpc8xxx/pci_cfg.c| 26 ++
board/freescale/p1022ds/Makefile | 40 +++
board/freescale/p1022ds/config.mk | 14 +
board/freescale/p1022ds/ddr.c | 108 +++
board/freescale/p1022ds/law.c | 27 ++
board/freescale/p1022ds/p1022ds.c | 369
board/freescale/p1022ds/p1022ds_diu.c | 151 ++
board/freescale/p1022ds/tlb.c | 76 +
include/configs/P1022DS.h | 505 +
10 files changed, 1319 insertions(+), 0 deletions(-)
create mode 100644 board/freescale/p1022ds/Makefile
create mode 100644 board/freescale/p1022ds/config.mk
create mode 100644 board/freescale/p1022ds/ddr.c
create mode 100644 board/freescale/p1022ds/law.c
create mode 100644 board/freescale/p1022ds/p1022ds.c
create mode 100644 board/freescale/p1022ds/p1022ds_diu.c
create mode 100644 board/freescale/p1022ds/tlb.c
create mode 100644 include/configs/P1022DS.h
diff --git a/Makefile b/Makefile
index 1445e8b..583a576 100644
--- a/Makefile
+++ b/Makefile
@@ -2493,6 +2493,9 @@ P2020DS_36BIT_config \
P2020DS_config:unconfig
@$(MKCONFIG) -t $(@:_config=) P2020DS powerpc mpc85xx p2020ds freescale
+P1022DS_config:unconfig
+ @$(MKCONFIG) -t $(@:_config=) P1022DS powerpc mpc85xx p1022ds freescale
+
P1011RDB_config\
P1011RDB_NAND_config \
P1011RDB_SDCARD_config \
diff --git a/arch/powerpc/cpu/mpc8xxx/pci_cfg.c
b/arch/powerpc/cpu/mpc8xxx/pci_cfg.c
index 85995ca..fc79fe1 100644
--- a/arch/powerpc/cpu/mpc8xxx/pci_cfg.c
+++ b/arch/powerpc/cpu/mpc8xxx/pci_cfg.c
@@ -186,6 +186,32 @@ static struct pci_info pci_config_info[] =
(1 0x16) | (1 0x17) | (1 0x18) | (1 0x1c),
},
};
+#elif defined(CONFIG_P1022)
+static struct pci_info pci_config_info[] =
+{
+ [LAW_TRGT_IF_PCIE_1] = {
+ .agent = (1 0) | (1 1),
+ .cfg = (1 6) | (1 7) | (1 9) | (1 0xa) |
+(1 0xb) | (1 0xd) | (1 0xe) |
+(1 0xf) | (1 0x15) | (1 0x16) |
+(1 0x17) | (1 0x18) | (1 0x19) |
+(1 0x1a) | (1 0x1b) | (1 0x1c) |
+(1 0x1d) | (1 0x1e) | (1 0x1f),
+ },
+ [LAW_TRGT_IF_PCIE_2] = {
+ .agent = (1 0) | (1 2),
+ .cfg = (1 0) | (1 1) | (1 6) | (1 7) |
+(1 9) | (1 0xa) | (1 0xb) | (1 0xd) |
+(1 0x15) | (1 0x16) | (1 0x17) |
+(1 0x18) | (1 0x1c),
+ },
+ [LAW_TRGT_IF_PCIE_3] = {
+ .agent = (1 0) | (1 3),
+ .cfg = (1 6) | (1 7) | (1 9) | (1 0xd) |
+(1 0x15) | (1 0x16) | (1 0x17) | (1 0x18) |
+(1 0x19) | (1 0x1a) | (1 0x1b),
+ },
+};
#elif defined(CONFIG_P2010) || defined(CONFIG_P2020)
static struct pci_info pci_config_info[] =
{
diff --git a/board/freescale/p1022ds/Makefile b/board/freescale/p1022ds/Makefile
new file mode 100644
index 000..4596c35
--- /dev/null
+++ b/board/freescale/p1022ds/Makefile
@@ -0,0 +1,40 @@
+#
+# Copyright 2010 Freescale Semiconductor, Inc.
+#
+# This program is free software; you can redistribute it and/or modify it
+# under the terms of the GNU General Public License as published by the Free
+# Software Foundation; either version 2 of the License, or (at your option)
+# any later version.
+#
+
+include $(TOPDIR)/config.mk
+
+LIB= $(obj)lib$(BOARD).a
+
+COBJS-y+= $(BOARD).o
+COBJS-y+= ddr.o
+COBJS-y+= law.o
+COBJS-y+= tlb.o
+COBJS-${CONFIG_FSL_DIU_FB} += p1022ds_diu.o
+
+SRCS := $(SOBJS:.o=.S) $(COBJS-y:.o=.c)
+OBJS := $(addprefix $(obj),$(COBJS-y))
+SOBJS := $(addprefix $(obj),$(SOBJS))
+
+$(LIB):$(obj).depend $(OBJS) $(SOBJS)
+ $(AR) $(ARFLAGS) $@ $(OBJS)
+
+clean:
+ rm -f $(OBJS) $(SOBJS)
+
+distclean: clean
+ rm -f $(LIB) core *.bak .depend
+
+#
+
+# defines $(obj).depend target
+include $(SRCTREE)/rules.mk
+
+sinclude $(obj).depend
+
+#
diff --git a/board/freescale/p1022ds/config.mk
b/board/freescale/p1022ds/config.mk
new file mode 100644
index 000..4581d20
--- /dev/null
+++ b/board/freescale/p1022ds/config.mk
@@ -0,0 +1,14 @@
+#
+# Copyright 2010 Freescale Semiconductor, Inc.
+#
+# This program is free software; you can redistribute it and/or modify it
+#
Re: [U-Boot] [PATCH] mtest: Fix end address of increment/decrement test
Dear Peter Tyser, In message 1274392850.18152.253.ca...@petert you wrote: I didn't express it well, but what I was getting at was that the Testing X .. Y would ideally state exactly what is being tested. We have full agreement here. Unaligned addresses would still be allowed. I think right now the end address is always automatically aligned to the same alignment as the start address though, so the current output is very misleading. Agreed, too. You can see the starting alignment was respected, but the ending alignment was truncated to be 32-bit aligned to the starting address. In the above example, I think it would be nice to see Testing 1003 ... 1ffe. Or some other way such that the user knows that their input wasn't executed to a T; their end address was truncated. Yep. We are in sync. 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 Who alone has reason to *lie himself out* of actuality? He who *suffers* from it. - Friedrich Nietzsche ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] powerpc: add support for the Freescale P1022DS reference board
Dear Timur Tabi,
In message 1274392909-16422-1-git-send-email-ti...@freescale.com you wrote:
Add basic suport for the Freescale P1022DS reference board.
Signed-off-by: Timur Tabi ti...@freescale.com
---
This patch requires the following two patches to be applied first:
fsl/85xx: add clkdvdr and pmuxcr2 to global utilities structure definition
fsl: rename 'dma' to 'brdcfg1' in the ngPIXIS structure
Makefile |3 +
arch/powerpc/cpu/mpc8xxx/pci_cfg.c| 26 ++
board/freescale/p1022ds/Makefile | 40 +++
board/freescale/p1022ds/config.mk | 14 +
board/freescale/p1022ds/ddr.c | 108 +++
board/freescale/p1022ds/law.c | 27 ++
board/freescale/p1022ds/p1022ds.c | 369
board/freescale/p1022ds/p1022ds_diu.c | 151 ++
board/freescale/p1022ds/tlb.c | 76 +
include/configs/P1022DS.h | 505
+
10 files changed, 1319 insertions(+), 0 deletions(-)
create mode 100644 board/freescale/p1022ds/Makefile
create mode 100644 board/freescale/p1022ds/config.mk
create mode 100644 board/freescale/p1022ds/ddr.c
create mode 100644 board/freescale/p1022ds/law.c
create mode 100644 board/freescale/p1022ds/p1022ds.c
create mode 100644 board/freescale/p1022ds/p1022ds_diu.c
create mode 100644 board/freescale/p1022ds/tlb.c
create mode 100644 include/configs/P1022DS.h
Entries to MAKEALL and MAINTAINERS missing.
diff --git a/Makefile b/Makefile
index 1445e8b..583a576 100644
--- a/Makefile
+++ b/Makefile
@@ -2493,6 +2493,9 @@ P2020DS_36BIT_config \
P2020DS_config: unconfig
@$(MKCONFIG) -t $(@:_config=) P2020DS powerpc mpc85xx p2020ds freescale
+P1022DS_config: unconfig
+ @$(MKCONFIG) -t $(@:_config=) P1022DS powerpc mpc85xx p1022ds freescale
+
P1011RDB_config \
P1011RDB_NAND_config \
P1011RDB_SDCARD_config \
Please keep lists sorted / sort them.
diff --git a/board/freescale/p1022ds/ddr.c b/board/freescale/p1022ds/ddr.c
new file mode 100644
index 000..c43c902
--- /dev/null
+++ b/board/freescale/p1022ds/ddr.c
...
+void fsl_ddr_get_spd(ddr3_spd_eeprom_t *ctrl_dimms_spd, unsigned int
ctrl_num)
+{
+ int ret;
+
+ /* The P1022 has only one DDR controller, and the board has only one
+DIMM slot. */
Incorrect multiline comment style.
...
+/* ranges for parameters:
+ * wr_data_delay = 0-6
+ * clk adjust = 0-8
+ * cpo 2-0x1E (30)
+ */
Incorrect multiline comment style.
+static const board_specific_parameters_t bsp[] = {
+/* memory controller 0 */
+/* lo| hi| num| clk| cpo|wrdata|2T*/
+/*mhz| mhz|ranks|adjst|| delay| */
Incorrect multiline comment style.
Please fix globally!
+ { 0, 333,1,5, 31,3, 0},
+ {334, 400,1,5, 31,3, 0},
+ {401, 549,1,5, 31,3, 0},
+ {550, 680,1,5, 31,5, 0},
+ {681, 850,1,5, 31,5, 0},
+ { 0, 333,2,5, 31,3, 0},
+ {334, 400,2,5, 31,3, 0},
+ {401, 549,2,5, 31,3, 0},
+ {550, 680,2,5, 31,5, 0},
+ {681, 850,2,5, 31,5, 0},
Please use TABs for vertical alignment.
+void fsl_ddr_board_options(memctl_options_t *popts, dimm_params_t *pdimm,
+unsigned int ctrl_num)
+{
...
+ /* Per AN4039, enable ZQ calibration. */
+ popts-zq_en = 1;
+
+
+ /*
Drop one of these empty lines, please.
+int board_early_init_f(void)
+{
+ ccsr_gur_t *gur = (void *)CONFIG_SYS_MPC85xx_GUTS_ADDR;
+
+ /* Set pmuxcr to allow both i2c1 and i2c2 */
+ setbits_be32(gur-pmuxcr, 0x1000);
+ in_be32(gur-pmuxcr);
What is this in_be32() needed for? Either add a comment why it's
needed, or remove it.
...
+phys_size_t initdram(int board_type)
+{
+ phys_size_t dram_size = 0;
+
+ puts(Initializing\n);
+
+ dram_size = fsl_ddr_sdram();
+ dram_size = setup_ddr_tlbs(dram_size / 0x10);
+ dram_size *= 0x10;
+
+ puts(DDR: );
+ return dram_size;
How about using get_ram_size() for autosizing / testing?
+ /* Enable the TFP410 Encoder (I2C address 0x38)
+ */
Please use a symbolic name instead of the hard-wired constant.
+void pci_init_board(void)
+{
+ volatile ccsr_gur_t *gur = (void *)(CONFIG_SYS_MPC85xx_GUTS_ADDR);
+ struct fsl_pci_info pci_info[3];
+ u32 devdisr, pordevsr, io_sel;
+ int first_free_busno = 0;
+ int num = 0;
+
+ int pcie_ep, pcie_configured;
+
+ devdisr = in_be32(gur-devdisr);
+ pordevsr = in_be32(gur-pordevsr);
+ io_sel = (pordevsr MPC85xx_PORDEVSR_IO_SEL) 18;
+
+ debug ( pci_init_board: devdisr=%x, io_sel=%x\n, devdisr, io_sel);
+
+ if (!(pordevsr MPC85xx_PORDEVSR_SGMII2_DIS))
+ printf(eTSEC2 is in
Re: [U-Boot] [PATCH] powerpc: add support for the Freescale P1022DS reference board
On May 20, 2010, at 5:33 PM, Wolfgang Denk wrote:
...
+phys_size_t initdram(int board_type)
+{
+phys_size_t dram_size = 0;
+
+puts(Initializing\n);
+
+dram_size = fsl_ddr_sdram();
+dram_size = setup_ddr_tlbs(dram_size / 0x10);
+dram_size *= 0x10;
+
+puts(DDR: );
+return dram_size;
How about using get_ram_size() for autosizing / testing?
Why, the board is SPD based?
- k
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] powerpc: add support for the Freescale P1022DS reference board
On Thu, May 20, 2010 at 5:33 PM, Wolfgang Denk w...@denx.de wrote:
Entries to MAKEALL and MAINTAINERS missing.
Ok.
+P1022DS_config: unconfig
+ @$(MKCONFIG) -t $(@:_config=) P1022DS powerpc mpc85xx p1022ds freescale
+
P1011RDB_config \
P1011RDB_NAND_config \
P1011RDB_SDCARD_config \
Please keep lists sorted / sort them.
Ok.
+void fsl_ddr_get_spd(ddr3_spd_eeprom_t *ctrl_dimms_spd, unsigned int
ctrl_num)
+{
+ int ret;
+
+ /* The P1022 has only one DDR controller, and the board has only one
+ DIMM slot. */
Incorrect multiline comment style.
Ok.
...
+/* ranges for parameters:
+ * wr_data_delay = 0-6
+ * clk adjust = 0-8
+ * cpo 2-0x1E (30)
+ */
Incorrect multiline comment style.
Sorry, what's wrong with this, specifically? Should it look like this:
/*
* ranges for parameters:
* wr_data_delay = 0-6
* clk adjust = 0-8
* cpo 2-0x1E (30)
*/
Please keep in mind that a lot of this code is taken from the existing
p2020ds support that's already in your repository, so many of your
comments are really criticisms of code that you have already accepted.
+ { 0, 333, 1, 5, 31, 3, 0},
+ {334, 400, 1, 5, 31, 3, 0},
+ {401, 549, 1, 5, 31, 3, 0},
+ {550, 680, 1, 5, 31, 5, 0},
+ {681, 850, 1, 5, 31, 5, 0},
+ { 0, 333, 2, 5, 31, 3, 0},
+ {334, 400, 2, 5, 31, 3, 0},
+ {401, 549, 2, 5, 31, 3, 0},
+ {550, 680, 2, 5, 31, 5, 0},
+ {681, 850, 2, 5, 31, 5, 0},
Please use TABs for vertical alignment.
I thought I did.
+void fsl_ddr_board_options(memctl_options_t *popts, dimm_params_t *pdimm,
+ unsigned int ctrl_num)
+{
...
+ /* Per AN4039, enable ZQ calibration. */
+ popts-zq_en = 1;
+
+
+ /*
Drop one of these empty lines, please.
Ok. I don't know how that got in there.
+int board_early_init_f(void)
+{
+ ccsr_gur_t *gur = (void *)CONFIG_SYS_MPC85xx_GUTS_ADDR;
+
+ /* Set pmuxcr to allow both i2c1 and i2c2 */
+ setbits_be32(gur-pmuxcr, 0x1000);
+ in_be32(gur-pmuxcr);
What is this in_be32() needed for? Either add a comment why it's
needed, or remove it.
Ok. It's for serializing the I/O. The PIXIS won't complete the read
until after the write is finished.
+phys_size_t initdram(int board_type)
+{
+ phys_size_t dram_size = 0;
+
+ puts(Initializing\n);
+
+ dram_size = fsl_ddr_sdram();
+ dram_size = setup_ddr_tlbs(dram_size / 0x10);
+ dram_size *= 0x10;
+
+ puts( DDR: );
+ return dram_size;
How about using get_ram_size() for autosizing / testing?
That's what fsl_ddr_sdram() does. It returns the size based on SPD.
+ /* Enable the TFP410 Encoder (I2C address 0x38)
+ */
Please use a symbolic name instead of the hard-wired constant.
Ok.
+void pci_init_board(void)
+{
+ volatile ccsr_gur_t *gur = (void *)(CONFIG_SYS_MPC85xx_GUTS_ADDR);
+ struct fsl_pci_info pci_info[3];
+ u32 devdisr, pordevsr, io_sel;
+ int first_free_busno = 0;
+ int num = 0;
+
+ int pcie_ep, pcie_configured;
+
+ devdisr = in_be32(gur-devdisr);
+ pordevsr = in_be32(gur-pordevsr);
+ io_sel = (pordevsr MPC85xx_PORDEVSR_IO_SEL) 18;
+
+ debug ( pci_init_board: devdisr=%x, io_sel=%x\n, devdisr, io_sel);
+
+ if (!(pordevsr MPC85xx_PORDEVSR_SGMII2_DIS))
+ printf( eTSEC2 is in sgmii mode.\n);
+ if (!(pordevsr MPC85xx_PORDEVSR_SGMII3_DIS))
+ printf( eTSEC3 is in sgmii mode.\n);
+
+ puts(\n);
Drop that.
This code is identical to the code in the p2020ds.c, so I'm just
mirroring it. The only difference is the names of the slots in the
printf. I would prefer to keep this new code as close as possible to
our existing code. I suspect that we'll be unifying the PCI code in
the future, and keeping it similar will make it easier.
+#ifdef CONFIG_PCIE1
+ pcie_configured = is_fsl_pci_cfg(LAW_TRGT_IF_PCIE_1, io_sel);
+
+ if (pcie_configured !(devdisr MPC85xx_DEVDISR_PCIE)) {
+ SET_STD_PCIE_INFO(pci_info[num], 1);
+ pcie_ep = fsl_setup_hose(pcie1_hose, pci_info[num].regs);
+ printf( PCIE1 connected to Slot 1 as %s (base addr %lx)\n,
+ pcie_ep ? Endpoint : Root Complex,
+ pci_info[num].regs);
+ first_free_busno = fsl_pci_init_port(pci_info[num++],
+ pcie1_hose, first_free_busno);
+ } else {
+ printf( PCIE1: disabled\n);
+ }
+ puts(\n);
Ditto.
Hm... looks as if you were repeating the same code 3 times. Please make
this a function.
The code isn't really the same. I would need to pass a lot of
parameters to this function: the hose, the devdisr mask, the slot
name, the slot number, the bus
Re: [U-Boot] [PATCH] powerpc: add support for the FreescaleP1022DS reference board
Add basic suport for the Freescale P1022DS reference board.
snip
+#elif defined(CONFIG_P1022)
+static struct pci_info pci_config_info[] =
+{
+ [LAW_TRGT_IF_PCIE_1] = {
+ .agent = (1 0) | (1 1),
+ .cfg = (1 6) | (1 7) | (1 9) | (1 0xa) |
+ (1 0xb) | (1 0xd) | (1 0xe) |
+ (1 0xf) | (1 0x15) | (1 0x16) |
+ (1 0x17) | (1 0x18) | (1 0x19) |
+ (1 0x1a) | (1 0x1b) | (1 0x1c) |
+ (1 0x1d) | (1 0x1e) | (1 0x1f),
+ },
Tiimur,
Did you grab the patch from our latest BSP tree?
It seems like your patch doesn't base on latest upstream tree, IIRC, the
PCI stuff
in mpc8xxx/pci_cfg.c is ready in upstream tree.
Did you have a test the patch on V2 board? The V2 board has big change
from V1
board. Anyway I would like we have sufficient test on V2 board before it
is merged to
main tree.
Thanks, Dave
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] nios2: allow STANDALONE_LOAD_ADDR overriding
This patch allows users to override default STANDALONE_LOAD_ADDR. The gcclibdir path was duplicated in the standalone Makefile and can be removed. Signed-off-by: Thomas Chou tho...@wytron.com.tw --- arch/nios2/config.mk |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/nios2/config.mk b/arch/nios2/config.mk index 6789038..793cc43 100644 --- a/arch/nios2/config.mk +++ b/arch/nios2/config.mk @@ -24,7 +24,7 @@ CROSS_COMPILE ?= nios2-elf- -STANDALONE_LOAD_ADDR = 0x0200 -L $(gcclibdir) +STANDALONE_LOAD_ADDR ?= 0x0200 PLATFORM_CPPFLAGS += -DCONFIG_NIOS2 -D__NIOS2__ PLATFORM_CPPFLAGS += -G0 -- 1.7.1.86.g0e460 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] nios2: fix r15 issue for gcc4
The -ffixed-r15 option doesn't work well for gcc4. Since we
don't use gp for small data with option -G0, we can use gp
as global data pointer. This allows compiler to use r15. It
is necessary for gcc4 to work properly.
Signed-off-by: Thomas Chou tho...@wytron.com.tw
---
v2: update standalone stubs and doc.
README |8
arch/nios2/config.mk |2 +-
arch/nios2/cpu/start.S |7 ---
arch/nios2/include/asm/global_data.h |2 +-
doc/README.standalone| 13 +++--
examples/standalone/stubs.c |6 +++---
6 files changed, 20 insertions(+), 18 deletions(-)
diff --git a/README b/README
index 81692c0..acb3308 100644
--- a/README
+++ b/README
@@ -4023,6 +4023,14 @@ On ARM, the following registers are used:
== U-Boot will use R8 to hold a pointer to the global data
+On Nios II, the ABI is documented here:
+ http://www.altera.com/literature/hb/nios2/n2cpu_nii51016.pdf
+
+== U-Boot will use gp to hold a pointer to the global data
+
+Note: on Nios II, we give -G0 option to gcc and don't use gp
+to access small data sections, so gp is free.
+
NOTE: DECLARE_GLOBAL_DATA_PTR must be used with file-global scope,
or current versions of GCC may optimize the code too much.
diff --git a/arch/nios2/config.mk b/arch/nios2/config.mk
index 8e5d6ef..6789038 100644
--- a/arch/nios2/config.mk
+++ b/arch/nios2/config.mk
@@ -27,6 +27,6 @@ CROSS_COMPILE ?= nios2-elf-
STANDALONE_LOAD_ADDR = 0x0200 -L $(gcclibdir)
PLATFORM_CPPFLAGS += -DCONFIG_NIOS2 -D__NIOS2__
-PLATFORM_CPPFLAGS += -ffixed-r15 -G0
+PLATFORM_CPPFLAGS += -G0
LDSCRIPT ?= $(SRCTREE)/$(CPUDIR)/u-boot.lds
diff --git a/arch/nios2/cpu/start.S b/arch/nios2/cpu/start.S
index d1016ea..76d3b52 100644
--- a/arch/nios2/cpu/start.S
+++ b/arch/nios2/cpu/start.S
@@ -113,13 +113,6 @@ _cur: movhi r5, %hi(_cur - _start)
bner5, r6, 4b
5:
- /* GLOBAL POINTER -- the global pointer is used to reference
-* small data (see -G switch). The linker script must
-* provide the gp address.
-*/
-movhi gp, %hi(_gp)
-origp, gp, %lo(_gp)
-
/* JUMP TO RELOC ADDR */
movhi r4, %hi(_reloc)
ori r4, r4, %lo(_reloc)
diff --git a/arch/nios2/include/asm/global_data.h
b/arch/nios2/include/asm/global_data.h
index 34aa962..f1b3482 100644
--- a/arch/nios2/include/asm/global_data.h
+++ b/arch/nios2/include/asm/global_data.h
@@ -48,6 +48,6 @@ typedef struct global_data {
#defineGD_FLG_LOGINIT 0x00020 /* Log Buffer has been
initialized */
#define GD_FLG_DISABLE_CONSOLE 0x00040 /* Disable console (in out)
*/
-#define DECLARE_GLOBAL_DATA_PTR register gd_t *gd asm (r15)
+#define DECLARE_GLOBAL_DATA_PTR register gd_t *gd asm (gp)
#endif /* __ASM_NIOS2_GLOBALDATA_H_ */
diff --git a/doc/README.standalone b/doc/README.standalone
index 885c92f..6381087 100644
--- a/doc/README.standalone
+++ b/doc/README.standalone
@@ -19,12 +19,12 @@ Design Notes on Exporting U-Boot Functions to Standalone
Applications:
thus the compiler cannot perform type checks on these assignments.
2. The pointer to the jump table is passed to the application in a
- machine-dependent way. PowerPC, ARM, MIPS and Blackfin architectures
- use a dedicated register to hold the pointer to the 'global_data'
- structure: r2 on PowerPC, r8 on ARM, k0 on MIPS, and P3 on Blackfin.
- The x86 architecture does not use such a register; instead, the
- pointer to the 'global_data' structure is passed as 'argv[-1]'
- pointer.
+ machine-dependent way. PowerPC, ARM, MIPS, Blackfin and Nios II
+ architectures use a dedicated register to hold the pointer to the
+ 'global_data' structure: r2 on PowerPC, r8 on ARM, k0 on MIPS,
+ P3 on Blackfin and gp on Nios II. The x86 architecture does not
+ use such a register; instead, the pointer to the 'global_data'
+ structure is passed as 'argv[-1]' pointer.
The application can access the 'global_data' structure in the same
way as U-Boot does:
@@ -56,6 +56,7 @@ Design Notes on Exporting U-Boot Functions to Standalone
Applications:
ARM 0x0c10 0x0c10
MIPS0x8020 0x8020
Blackfin0x1000 0x1000
+ Nios II 0x0200 0x0200
For example, the hello world application may be loaded and
executed on a PowerPC board with the following commands:
diff --git a/examples/standalone/stubs.c b/examples/standalone/stubs.c
index ce3371d..0187708 100644
--- a/examples/standalone/stubs.c
+++ b/examples/standalone/stubs.c
@@ -84,7 +84,7 @@ gd_t *global_data;
: : i(offsetof(gd_t, jt)), i(XF_ ## x) : r0);
#elif defined(CONFIG_NIOS2)
/*
- * r15 holds the pointer to the global_data, r8 is call-clobbered
+ * gp holds the pointer to the global_data, r8 is call-clobbered
*/
Re: [U-Boot] [PATCH Repost] bugfix: Guruplug: Use standard miiphy call to reset PHY chip.
-Original Message-
From: u-boot-boun...@lists.denx.de
[mailto:u-boot-boun...@lists.denx.de] On Behalf Of Mahavir Jain
Sent: Wednesday, May 19, 2010 2:26 PM
To: u-boot@lists.denx.de
Cc: Mahavir Jain
Subject: [U-Boot] [PATCH Repost] bugfix: Guruplug: Use
standard miiphy call to reset PHY chip.
Current PHY Software Reset operation in guruplug does not
poll reset bit in control register to go to 0(auto clearing)
for making sure reset was successful.This patch uses standard
miiphy call miiphy_reset to make sure proper PHY reset operation.
Signed-off-by: Mahavir Jain mj...@marvell.com
---
board/Marvell/guruplug/guruplug.c |9 +
1 files changed, 1 insertions(+), 8 deletions(-)
diff --git a/board/Marvell/guruplug/guruplug.c
b/board/Marvell/guruplug/guruplug.c
index ba47ca1..c028a53 100644
--- a/board/Marvell/guruplug/guruplug.c
+++ b/board/Marvell/guruplug/guruplug.c
@@ -146,14 +146,7 @@ void mv_phy_88e1121_init(char *name)
miiphy_write(name, devadr, MV88E1121_PGADR_REG, 0);
/* reset the phy */
- if (miiphy_read (name, devadr, PHY_BMCR, reg) != 0) {
- printf(Err..(%s) PHY status read failed\n,
__FUNCTION__);
- return;
- }
- if (miiphy_write (name, devadr, PHY_BMCR, reg | 0x8000) != 0) {
- printf(Err..(%s) PHY reset failed\n, __FUNCTION__);
- return;
- }
+ miiphy_reset(name, devadr);
printf(88E1121 Initialized on %s\n, name);
}
--
Applied to u-boot-marvell.git master branch
Regards..
Prafulla . .
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Flash Erase and Write timeout for S29GL512P
Hi All, I am using 64MB CFI compliant flash on my board. For that I need to configure the erase and write timeout for this chip in configs/boardname.h file Flash chip I am using is S29GL512P and as per datasheet flash erase time is 1024 Seconds and flash program time is 492 Seconds. So CONFIG_SYS_FLASH_ERASE_TOUT should be 1024000 ms and CONFIG_SYS_FLASH_WRITE_TOUT should be 492000 ms. But, in Uboot, I am seeing that most boards have configured CONFIG_SYS_FLASH_ERASE_TOUT to 24 ms and CONFIG_SYS_FLASH_WRITE_TOUT to 200-400 ms range for flash of size 1GB or moroe. Can anyone please tell what value I should use for my chip. Regards, Prakash ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 0/2] Support for TI's DA850/OMAP-L138 platform
This patch series adds support for TI's DA850/OMAP-L138
platform. I have reworked on this series based on the
comments by Wolfgang Denk at [1]. This series is dependant
on [2] which has been Acked by Nick Thompson nick.thomp...@ge.com
at [3].
[1] http://lists.denx.de/pipermail/u-boot/2010-May/071236.html
[2] http://lists.denx.de/pipermail/u-boot/2010-April/070383.html
[3] http://lists.denx.de/pipermail/u-boot/2010-April/070668.html
Sudhakar Rajashekhara (2):
TI: DaVinci: Prepare for da850 support
TI: DaVinci: Add board specific code for da850 EVM
MAINTAINERS |4 +
MAKEALL |1 +
Makefile|5 +-
arch/arm/include/asm/arch-davinci/hardware.h|1 +
board/davinci/{da830evm = da8xxevm}/Makefile |5 +-
board/davinci/{da830evm = da8xxevm}/config.mk |0
board/davinci/{da830evm = da8xxevm}/da830evm.c |0
board/davinci/da8xxevm/da850evm.c | 111 ++
include/configs/da850evm.h | 140 +++
9 files changed, 264 insertions(+), 3 deletions(-)
rename board/davinci/{da830evm = da8xxevm}/Makefile (91%)
rename board/davinci/{da830evm = da8xxevm}/config.mk (100%)
rename board/davinci/{da830evm = da8xxevm}/da830evm.c (100%)
create mode 100644 board/davinci/da8xxevm/da850evm.c
create mode 100644 include/configs/da850evm.h
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 1/2] TI: DaVinci: Prepare for da850 support
DA850/OMAP-L138 is a new SoC from Texas Instruments
(http://focus.ti.com/docs/prod/folders/print/omap-l138.html).
This SoC is similar to DA830/OMAP-L137 in many aspects. Hence
rename the da830 specific files and folders to da8xx to
accommodate DA850/OMAP-L138.
Signed-off-by: Sudhakar Rajashekhara sudhakar@ti.com
---
Makefile|2 +-
board/davinci/{da830evm = da8xxevm}/Makefile |4 +++-
board/davinci/{da830evm = da8xxevm}/config.mk |0
board/davinci/{da830evm = da8xxevm}/da830evm.c |0
4 files changed, 4 insertions(+), 2 deletions(-)
rename board/davinci/{da830evm = da8xxevm}/Makefile (94%)
rename board/davinci/{da830evm = da8xxevm}/config.mk (100%)
rename board/davinci/{da830evm = da8xxevm}/da830evm.c (100%)
diff --git a/Makefile b/Makefile
index 2d96574..3668cda 100644
--- a/Makefile
+++ b/Makefile
@@ -2917,7 +2917,7 @@ cp1026_config: unconfig
@board/armltd/integrator/split_by_variant.sh cp $@
da830evm_config: unconfig
- @$(MKCONFIG) $(@:_config=) arm arm926ejs da830evm davinci davinci
+ @$(MKCONFIG) $(@:_config=) arm arm926ejs da8xxevm davinci davinci
davinci_dvevm_config : unconfig
@$(MKCONFIG) $(@:_config=) arm arm926ejs dvevm davinci davinci
diff --git a/board/davinci/da830evm/Makefile b/board/davinci/da8xxevm/Makefile
similarity index 94%
rename from board/davinci/da830evm/Makefile
rename to board/davinci/da8xxevm/Makefile
index 02636fa..20f4915 100644
--- a/board/davinci/da830evm/Makefile
+++ b/board/davinci/da8xxevm/Makefile
@@ -27,7 +27,9 @@ include $(TOPDIR)/config.mk
LIB= $(obj)lib$(BOARD).a
-COBJS := da830evm.o
+COBJS-$(CONFIG_MACH_DAVINCI_DA830_EVM) += da830evm.o
+
+COBJS := $(sort $(COBJS-y))
SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c)
OBJS := $(addprefix $(obj),$(COBJS))
diff --git a/board/davinci/da830evm/config.mk b/board/davinci/da8xxevm/config.mk
similarity index 100%
rename from board/davinci/da830evm/config.mk
rename to board/davinci/da8xxevm/config.mk
diff --git a/board/davinci/da830evm/da830evm.c
b/board/davinci/da8xxevm/da830evm.c
similarity index 100%
rename from board/davinci/da830evm/da830evm.c
rename to board/davinci/da8xxevm/da830evm.c
--
1.5.6
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 2/2] TI: DaVinci: Add board specific code for da850 EVM
Provides initial support for TI OMAP-L138/DA850 SoC devices on
a Logic PD EVM board.
Provides:
Initial boot and configuration.
Support for i2c.
UART support (console).
Signed-off-by: Sudhakar Rajashekhara sudhakar@ti.com
---
MAINTAINERS |4 +
MAKEALL |1 +
Makefile |3 +-
arch/arm/include/asm/arch-davinci/hardware.h |1 +
board/davinci/da8xxevm/Makefile |1 +
board/davinci/da8xxevm/da850evm.c| 111
include/configs/da850evm.h | 140 ++
7 files changed, 260 insertions(+), 1 deletions(-)
create mode 100644 board/davinci/da8xxevm/da850evm.c
create mode 100644 include/configs/da850evm.h
diff --git a/MAINTAINERS b/MAINTAINERS
index 5cbc845..82e0692 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -349,6 +349,10 @@ Daniel Poirot dan.poi...@windriver.com
sbc8240 MPC8240
sbc405 PPC405GP
+Sudhakar Rajashekhara sudhakar@ti.com
+
+ da850evmARM926EJS (DA850/OMAP-L138)
+
Ricardo Ribalda ricardo.riba...@uam.es
ml507 PPC440x5
diff --git a/MAKEALL b/MAKEALL
index bb09627..4f7f23e 100755
--- a/MAKEALL
+++ b/MAKEALL
@@ -561,6 +561,7 @@ LIST_ARM9= \
cp946es \
cp966 \
da830evm\
+ da850evm\
edb9301 \
edb9302 \
edb9302a\
diff --git a/Makefile b/Makefile
index 3668cda..4fcbd8f 100644
--- a/Makefile
+++ b/Makefile
@@ -2916,7 +2916,8 @@ cp922_XA10_config \
cp1026_config: unconfig
@board/armltd/integrator/split_by_variant.sh cp $@
-da830evm_config: unconfig
+da830evm_config\
+da850evm_config: unconfig
@$(MKCONFIG) $(@:_config=) arm arm926ejs da8xxevm davinci davinci
davinci_dvevm_config : unconfig
diff --git a/arch/arm/include/asm/arch-davinci/hardware.h
b/arch/arm/include/asm/arch-davinci/hardware.h
index 81cc8ab..3520cf8 100644
--- a/arch/arm/include/asm/arch-davinci/hardware.h
+++ b/arch/arm/include/asm/arch-davinci/hardware.h
@@ -398,6 +398,7 @@ struct davinci_syscfg_regs {
#define DAVINCI_SYSCFG_SUSPSRC_EMAC(1 5)
#define DAVINCI_SYSCFG_SUSPSRC_I2C (1 16)
#define DAVINCI_SYSCFG_SUSPSRC_SPI0(1 21)
+#define DAVINCI_SYSCFG_SUSPSRC_SPI1(1 22)
#define DAVINCI_SYSCFG_SUSPSRC_UART2 (1 20)
#define DAVINCI_SYSCFG_SUSPSRC_TIMER0 (1 27)
diff --git a/board/davinci/da8xxevm/Makefile b/board/davinci/da8xxevm/Makefile
index 20f4915..bcf315c 100644
--- a/board/davinci/da8xxevm/Makefile
+++ b/board/davinci/da8xxevm/Makefile
@@ -28,6 +28,7 @@ include $(TOPDIR)/config.mk
LIB= $(obj)lib$(BOARD).a
COBJS-$(CONFIG_MACH_DAVINCI_DA830_EVM) += da830evm.o
+COBJS-$(CONFIG_MACH_DAVINCI_DA850_EVM) += da850evm.o
COBJS := $(sort $(COBJS-y))
diff --git a/board/davinci/da8xxevm/da850evm.c
b/board/davinci/da8xxevm/da850evm.c
new file mode 100644
index 000..197df22
--- /dev/null
+++ b/board/davinci/da8xxevm/da850evm.c
@@ -0,0 +1,111 @@
+/*
+ * Copyright (C) 2010 Texas Instruments Incorporated
+ *
+ * Based on da830evm.c. Original Copyrights follow:
+ *
+ * Copyright (C) 2009 Nick Thompson, GE Fanuc, Ltd. nick.thomp...@gefanuc.com
+ * Copyright (C) 2007 Sergey Kubushyn k...@koi8.net
+ *
+ * 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., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+
+#include common.h
+#include i2c.h
+#include asm/arch/hardware.h
+#include asm/io.h
+#include ../common/misc.h
+
+DECLARE_GLOBAL_DATA_PTR;
+
+#define pinmux davinci_syscfg_regs-pinmux
+
+/* SPI0 pin muxer settings */
+static const struct pinmux_config spi1_pins[] = {
+ { pinmux[5], 1, 1 },
+ { pinmux[5], 1, 2 },
+ { pinmux[5], 1, 4 },
+ { pinmux[5], 1, 5 }
+};
+
+/* UART pin muxer settings */
+static const struct pinmux_config uart_pins[] = {
+ { pinmux[0], 4, 6 },
+ { pinmux[0], 4, 7 },
+ { pinmux[4], 2, 4 },
+ { pinmux[4], 2, 5 }
+};
+
+/* I2C pin muxer settings */
+static const struct pinmux_config i2c_pins[] = {
+ { pinmux[4], 2, 2 },
+ { pinmux[4], 2, 3 }
+};
+
+static const struct
