powerpc/85xx: minor clean-ups to the P2020DS board header file
Subsystems (2)
PATCH 1/6 powerpc/85xx: minor clean-ups to the P2020DS board header file
Remove some unused macros and remove all #undef macros.
The RTL8139 network adapter is not shipped with the board nor commonly used, so don't define it by default. The E1000 is still defined.
Add 57,600 baud as an option. For some reason, this baud rate is missing from many boards.
--- include/configs/P2020DS.h | 22 +--------------------- 1 files changed, 1 insertions(+), 21 deletions(-)
include/configs/P2020DS.h +1 -21
@@ -128,7 +128,6 @@#else #define CONFIG_FSL_DDR3 1#endif -#undef CONFIG_FSL_DDR_INTERACTIVE/* ECC will be enabled based on perf_mode environment variable */ /* #define CONFIG_DDR_ECC */
@@ -207,8 +206,6 @@* */ -#undef CONFIG_CLOCKS_IN_MHZ -/* * Memory map *
@@ -251,7 +248,6 @@#define CONFIG_SYS_MAX_FLASH_BANKS 2/* number of banks */ #define CONFIG_SYS_MAX_FLASH_SECT 1024/* sectors per device */ -#undef CONFIG_SYS_FLASH_CHECKSUM#define CONFIG_SYS_FLASH_ERASE_TOUT 60000/* Flash Erase Timeout (ms) */ #define CONFIG_SYS_FLASH_WRITE_TOUT 500/* Flash Write Timeout (ms) */
@@ -373,7 +369,7 @@#define CONFIG_SYS_NS16550_CLK get_bus_freq(0)#define CONFIG_SYS_BAUDRATE_TABLE \ - {300, 600, 1200, 2400, 4800, 9600, 19200, 38400,115200} + {300, 600, 1200, 2400, 4800, 9600, 19200, 38400, 57600, 115200}#define CONFIG_SYS_NS16550_COM1 (CONFIG_SYS_CCSRBAR+0x4500)#define CONFIG_SYS_NS16550_COM2 (CONFIG_SYS_CCSRBAR+0x4600)
@@ -394,7 +390,6 @@/* I2C */ #define CONFIG_FSL_I2C /* Use FSL common I2C driver */ #define CONFIG_HARD_I2C /* I2C with hardware support */ -#undef CONFIG_SOFT_I2C/* I2C bit-banged */ #define CONFIG_I2C_MULTI_BUS #define CONFIG_SYS_I2C_SPEED 400000/* I2C speed and slave address */ #define CONFIG_SYS_I2C_EEPROM_ADDR 0x57
@@ -529,17 +524,6 @@#define CONFIG_SYS_SRIO2_MEM_SIZE 0x20000000/* 512M */ #define CONFIG_PCI_PNP /* do pci plug-and-play */ - -#undef CONFIG_EEPRO100 -#undef CONFIG_TULIP -#define CONFIG_RTL8139 - -#ifndef CONFIG_PCI_PNP -#define PCI_ENET0_IOADDR CONFIG_SYS_PCIE3_IO_BUS -#define PCI_ENET0_MEMADDR CONFIG_SYS_PCIE3_IO_BUS -#define PCI_IDSEL_NUMBER 0x11/* IDSEL = AD11 */ -#endif -#define CONFIG_PCI_SCAN_SHOW /* show pci devices on startup */ #define CONFIG_DOS_PARTITION #define CONFIG_SCSI_AHCI
@@ -566,7 +550,6 @@#define CONFIG_TSEC3 1#define CONFIG_TSEC3_NAME "eTSEC3" -#define CONFIG_PIXIS_SGMII_CMD #define CONFIG_FSL_SGMII_RISER 1#define SGMII_RISER_PHY_OFFSET 0x1b
@@ -655,8 +638,6 @@#define CONFIG_EHCI_HCD_INIT_AFTER_RESET #endif -#undef CONFIG_WATCHDOG/* watchdog disabled */ -/* * SDHC/MMC */
@@ -732,7 +713,6 @@#define CONFIG_LOADADDR 1000000#define CONFIG_BOOTDELAY 10/* -1 disables auto-boot */ -#undef CONFIG_BOOTARGS/* the boot command will set bootargs */ #define CONFIG_BAUDRATE 115200
Signature · 1 line
1.7.3.4
PATCH 2/6 powerpc/85xx: fdt_set_phy_handle() should return an error code
fdt_set_phy_handle() makes several FDT calls that could fail, so it should not be hiding these errors.
--- board/freescale/common/fman.c | 36 +++++++++++++++++++----------------- board/freescale/common/fman.h | 2 +- 2 files changed, 20 insertions(+), 18 deletions(-)
board/freescale/common/fman.c +19 -17
@@ -37,31 +37,33 @@* ... update that Ethernet node's phy-handle property to point to the * ethernet-phy node. This is how we link an Ethernet node to its PHY, so each * PHY in a virtual MDIO node must have an alias. +* +* Returns 0 on success, or a negative FDT error code on error. */ -void fdt_set_phy_handle (void *fdt,char *compat,phys_addr_t addr, +int fdt_set_phy_handle (void *fdt,char *compat,phys_addr_t addr,const char *alias) { -int offset, ph; +int offset; +unsigned int ph;const char *path;/* Get a path to the node that 'alias' points to */ path =fdt_get_alias (fdt, alias); -if (path) { -/* Get the offset of that node */ -int off =fdt_path_offset (fdt, path); -if (off >0 ) - ph =fdt_create_phandle (fdt, off); -else -return ; - }else { -return ; - } +if (!path) +return -FDT_ERR_BADPATH ; + +/* Get the offset of that node */ + offset =fdt_path_offset (fdt, path); +if (offset <0 ) +return offset; -/* failed to create a phandle */ -if (ph <=0 ) -return ; + ph =fdt_create_phandle (fdt, offset); +if (!ph) +return -FDT_ERR_BADPHANDLE ; offset =fdt_node_offset_by_compat_reg (fdt, compat, addr); -if (offset >0 ) -fdt_setprop (fdt, offset,"phy-handle" , &ph,sizeof (ph)); +if (offset <0 ) +return offset; + +return fdt_setprop (fdt, offset,"phy-handle" , &ph,sizeof (ph)); }
board/freescale/common/fman.h +1 -1
@@ -20,7 +20,7 @@#ifndef __FMAN_BOARD_HELPER__#define __FMAN_BOARD_HELPER__ -void fdt_set_phy_handle (void *fdt,char *compat,phys_addr_t addr, +int fdt_set_phy_handle (void *fdt,char *compat,phys_addr_t addr,const char *alias);#endif
Signature · 1 line
1.7.3.4
PATCH 3/6 powerpc/85xx: clean up P1022DS board configuration header file
In reply to Timur TabiRemove some unused default environment variables (memctl_intlv_ctl, perf_mode, diuregs, dium, and diuerr), update 'tftpflash' variable, and add videobootargs as a Linux command line variable (so that we can easily pass video= to the kernel).
--- include/configs/P1022DS.h | 43 +++++++++++++++++++------------------------ 1 files changed, 19 insertions(+), 24 deletions(-)
include/configs/P1022DS.h +19 -24
@@ -488,35 +488,30 @@#define CONFIG_LOADADDR 1000000#define CONFIG_BOOTDELAY 10/* -1 disables auto-boot */ -#define CONFIG_BOOTARGS #define CONFIG_BAUDRATE 115200 -#define CONFIG_EXTRA_ENV_SETTINGS \ - "perf_mode=stable\0" \ - "memctl_intlv_ctl=2\0" \ - "netdev=eth0\0" \ - "uboot=" MK_STR(CONFIG_UBOOTPATH) "\0" \ - "tftpflash=tftpboot $loadaddr $uboot; " \ - "protect off " MK_STR(CONFIG_SYS_TEXT_BASE) " +$filesize; " \ - "erase " MK_STR(CONFIG_SYS_TEXT_BASE) " +$filesize; " \ - "cp.b $loadaddr " MK_STR(CONFIG_SYS_TEXT_BASE) " $filesize; " \ - "protect on " MK_STR(CONFIG_SYS_TEXT_BASE) " +$filesize; " \ - "cmp.b $loadaddr " MK_STR(CONFIG_SYS_TEXT_BASE) " $filesize\0" \ - "consoledev=ttyS0\0" \ - "ramdiskaddr=2000000\0" \ - "ramdiskfile=uramdisk\0" \ - "fdtaddr=c00000\0" \ - "fdtfile=p1022ds.dtb\0" \ - "bdev=sda3\0" \ - "diuregs=md e002c000 1d\0" \ - "dium=mw e002c01c\0" \ - "diuerr=md e002c014 1\0" \ +#define CONFIG_EXTRA_ENV_SETTINGS \ + "netdev=eth0\0" \ + "uboot=" MK_STR(CONFIG_UBOOTPATH) "\0" \ + "ubootaddr=" MK_STR(CONFIG_SYS_TEXT_BASE) "\0" \ + "tftpflash=tftpboot $loadaddr $uboot && " \ + "protect off $ubootaddr +$filesize && " \ + "erase $ubootaddr +$filesize && " \ + "cp.b $loadaddr $ubootaddr $filesize && " \ + "protect on $ubootaddr +$filesize && " \ + "cmp.b $loadaddr $ubootaddr $filesize\0" \ + "consoledev=ttyS0\0" \ + "ramdiskaddr=2000000\0" \ + "ramdiskfile=rootfs.ext2.gz.uboot\0" \ + "fdtaddr=c00000\0" \ + "fdtfile=p1022ds.dtb\0" \ + "bdev=sda3\0" \ "hwconfig=esdhc;audclk:12\0"#define CONFIG_HDBOOT \ "setenv bootargs root=/dev/$bdev rw " \ - "console=$consoledev,$baudrate $othbootargs;" \ + "console=$consoledev,$baudrate $othbootargs $videobootargs;" \ "tftp $loadaddr $bootfile;" \ "tftp $fdtaddr $fdtfile;" \ "bootm $loadaddr - $fdtaddr"
@@ -525,14 +520,14 @@"setenv bootargs root=/dev/nfs rw " \"nfsroot=$serverip:$rootpath " \"ip=$ipaddr:$serverip:$gatewayip:$netmask:$hostname:$netdev:off " \ -"console=$consoledev,$baudrate $othbootargs;" \ +"console=$consoledev,$baudrate $othbootargs $videobootargs;" \"tftp $loadaddr $bootfile;" \"tftp $fdtaddr $fdtfile;" \"bootm $loadaddr - $fdtaddr" #define CONFIG_RAMBOOTCOMMAND \"setenv bootargs root=/dev/ram rw " \ -"console=$consoledev,$baudrate $othbootargs;" \ +"console=$consoledev,$baudrate $othbootargs $videobootargs;" \"tftp $ramdiskaddr $ramdiskfile;" \"tftp $loadaddr $bootfile;" \"tftp $fdtaddr $fdtfile;" \
Signature · 1 line
1.7.3.4
PATCH 4/6 lib/powerpc: addrmap_phys_to_virt() should return a pointer
In reply to Timur Tabiaddrmap_phys_to_virt() converts a physical address (phys_addr_t) to a virtual address, so it should return a pointer instead of an unsigned long. Its counterpart, addrmap_virt_to_phys(), takes a pointer, so now they're orthogonal.
The only caller of addrmap_phys_to_virt() converts the return value to a pointer anyway.
--- arch/powerpc/include/asm/io.h | 2 +- include/addr_map.h | 2 +- lib/addr_map.c | 19 +++++++++++-------- 3 files changed, 13 insertions(+), 10 deletions(-)
arch/powerpc/include/asm/io.h +1 -1
@@ -295,7 +295,7 @@ static inline void * map_physmem(phys_addr_t paddr, unsigned long len, unsigned long flags) { #ifdef CONFIG_ADDR_MAP - return (void *)(addrmap_phys_to_virt(paddr)); + return addrmap_phys_to_virt(paddr);#else return (void *)((unsigned long )paddr);#endif
include/addr_map.h +1 -1
@@ -22,7 +22,7 @@#include <asm/types.h> extern phys_addr_t addrmap_virt_to_phys (void *vaddr); -extern unsigned long addrmap_phys_to_virt (phys_addr_t paddr); +void *addrmap_phys_to_virt (phys_addr_t paddr);extern void addrmap_set_entry (unsigned long vaddr,phys_addr_t paddr,phys_size_t size,int idx);
lib/addr_map.c +11 -8
@@ -47,26 +47,29 @@ phys_addr_t addrmap_virt_to_phys(void * vaddr)return (phys_addr_t)(~0 ); } -unsigned long addrmap_phys_to_virt (phys_addr_t paddr) +void *addrmap_phys_to_virt (phys_addr_t paddr) {int i;for (i =0 ; i <CONFIG_SYS_NUM_ADDR_MAP ; i++) { -u64 base, upper, addr; +phys_addr_t base, upper;if (address_map[i].size ==0 )continue ; - addr = (u64 )paddr; - base = (u64)(address_map[i].paddr); - upper = (u64)(address_map[i].size) + base -1 ; + base = address_map[i].paddr; + upper = address_map[i].size + base -1 ; -if (addr >= base && addr <= upper) { -return paddr - address_map[i].paddr + address_map[i].vaddr; +if (paddr >= base && paddr <= upper) { +phys_addr_t offset; + + offset = address_map[i].paddr - address_map[i].vaddr; + +return (void *)(unsigned long )(paddr - offset); } } -return (unsigned long )(~0 ); +return (void *)(~0 ); } void addrmap_set_entry(unsigned long vaddr, phys_addr_t paddr,
Signature · 1 line
1.7.3.4
PATCH 5/6 cmd_nvedit.c: allow board-specific code before/after saving the environment
In reply to Timur TabiIntroduce board_start_saveenv() and board_finish_saveenv(), two "weak" functions that are called before and after saving the environment. This allows for board-specific functions that "prepare" the board for saving the environment. This is useful if, for some reason, the non-volatile storage is normally unavailable (e.g. blocked via a mux).
--- common/cmd_nvedit.c | 24 +++++++++++++++++++++++- 1 files changed, 23 insertions(+), 1 deletions(-)
common/cmd_nvedit.c +23 -1
@@ -595,11 +595,33 @@ ulong getenv_ulong(const char *name, int base, ulong default_val) }#if defined(CONFIG_CMD_SAVEENV ) && !defined(CONFIG_ENV_IS_NOWHERE ) + +static int __board_start_saveenv (void ) +{ +return 0 ; +} +int board_start_saveenv (void ) __attribute__((weak,alias ("__board_start_saveenv" ))); + +static void __board_finish_saveenv (void ) +{ +} +void board_finish_saveenv (void ) __attribute__((weak,alias ("__board_finish_saveenv" ))); +int do_env_save (cmd_tbl_t *cmdtp,int flag,int argc,char *const argv[]) { +int ret; +printf ("Saving Environment to %s...\n" , env_name_spec); -return saveenv () ?1 :0 ; + ret =board_start_saveenv (); +if (ret) +return 0 ; + + ret =saveenv () ?1 :0 ; + +board_finish_saveenv (); + +return ret; } U_BOOT_CMD(
Signature · 1 line
1.7.3.4
PATCH 5/6 cmd_nvedit.c: allow board-specific code before/after saving the environment
Quoted 5 lines · On Friday 04 May 2012 18:21:31 Timur Tabi wrote:
Introduce
board_start_saveenv()andboard_finish_saveenv(), two "weak" functions that are called before and after saving the environment. This allows for board-specific functions that "prepare" the board for saving the environment. This is useful if, for some reason, the non-volatile storage is normally unavailable (e.g. blocked via a mux).
all these board hooks are paper-cutting us to death with unused bloat
Quoted 23 lines
common/cmd_nvedit.c +6
-0#if defined(CONFIG_CMD_SAVEENV ) && !defined(CONFIG_ENV_IS_NOWHERE ) + +static int __board_start_saveenv (void ) +{ +return 0 ; +} +int board_start_saveenv(void) __attribute__((weak,
alias("__board_start_saveenv"))); +common/cmd_nvedit.c +4
-0+static void __board_finish_saveenv (void ) +{ +} +void board_finish_saveenv(void) __attribute__((weak,
alias("__board_finish_saveenv"))); +
intdo_env_save(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[]){common/cmd_nvedit.c +2
-1+int ret; +printf ("Saving Environment to %s...\n" , env_name_spec); -return saveenv () ?1 :0 ;
common/cmd_nvedit.c ulong getenv_ulong(const char *name, int base, ulong default_val) · line 625
Quoted 10 lines
common/cmd_nvedit.c +9
-0+ ret =board_start_saveenv (); +if (ret) +return 0 ; + + ret =saveenv () ?1 :0 ; + +board_finish_saveenv (); + +return ret; }
this is less bloat:
int board_start_saveenv(void) __attribute__((weak, alias("saveenv")));
int do_env_save(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
{
printf("Saving Environment to %s...\n", env_name_spec);
return board_saveenv() ? 1 : 0;
}-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20120514/5fd0154f/attachment.pgp>
PATCH 5/6 cmd_nvedit.c: allow board-specific code before/after saving the environment
Quoted 8 lines · Mike Frysinger
Quoted 5 lines · On Friday 04 May 2012 18:21:31 Timur Tabi wrote:
Introduce
board_start_saveenv()andboard_finish_saveenv(), two "weak" functions that are called before and after saving the environment. This allows for board-specific functions that "prepare" the board for saving the environment. This is useful if, for some reason, the non-volatile storage is normally unavailable (e.g. blocked via a mux).all these board hooks are paper-cutting us to death with unused bloat
I know, and I don't like it either. I hate how our hardware designers are always breaking the "rules", forcing us software developers to hack up our software more and more. The muxing on this chip is a like a cruel joke being played on me. I've even been told that I'm trying too hard to make it work.
Quoted 8 lines
this is less bloat:
intboard_start_saveenv(void)__attribute__((weak, alias("saveenv")));int
do_env_save(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[]){ printf("Saving Environment to %s...\n", env_name_spec); return board_saveenv() ? 1 : 0; }
Ah, I see. This forces the board-specific function to call saveenv(). That gives us more flexibility in the board code.
However, I was trying to mimic what we have in the NAND layer, with nand_get_device() and nand_release_device(). That is, before we save the environment, we have to "get" it, and then after we save it, we can "release" it.
Your approach, although it eliminates two weak functions, is not as "architecturally clean" as mine, IMHO.
I'm happy to do it your way if that's the consensus. I just want everyone to understand my approach first.
Signature · 2 lines
Timur Tabi Linux kernel developer at Freescale
PATCH 5/6 cmd_nvedit.c: allow board-specific code before/after saving the environment
Quoted 12 lines · On Monday 14 May 2012 12:10:48 Timur Tabi wrote:
Quoted 10 lines · Mike Frysinger
this is less bloat:
intboard_start_saveenv(void)__attribute__((weak, alias("saveenv")));int
do_env_save(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[]){printf("Saving Environment to %s...\n", env_name_spec); return board_saveenv() ? 1 : 0;}
Quoted 7 lines
Ah, I see. This forces the board-specific function to call
saveenv(). That gives us more flexibility in the board code.However, I was trying to mimic what we have in the NAND layer, with
nand_get_device()andnand_release_device(). That is, before we save the environment, we have to "get" it, and then after we save it, we can "release" it.
i don't think the nand approach is terribly applicable. different solutions for different cases.
Quoted 2 lines
Your approach, although it eliminates two weak functions, is not as "architecturally clean" as mine, IMHO.
i'd prefer my approach because it keeps down the bloat for the vast majority of people out there while not restricting boards who want this override -mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20120515/8e4e7844/attachment.pgp>
PATCH 5/6 cmd_nvedit.c: allow board-specific code before/after saving the environment
In reply to Timur TabiDear Timur Tabi,
Quoted 8 lines · In message <[email protected]> you wrote:
Quoted 2 lines
all these board hooks are paper-cutting us to death with unused bloat
I know, and I don't like it either. I hate how our hardware designers are always breaking the "rules", forcing us software developers to hack up our software more and more. The muxing on this chip is a like a cruel joke being played on me. I've even been told that I'm trying too hard to make it work.
I think whoever told you this was right. Let it break.
We cannot add pre- and post-hooks all ever the place for brain-dead designs that need to do this and that before and after doing perfectly things.
It makes no sense adding this to saveenv, because there will be othe rplaces in the code that need to to the same - like if it's NAND flash, you will probabaly need to do the same for all NAND related commands.
cmd_nvedit.c is definitely the wrong place for this.
Best regards,
Wolfgang Denk
Signature · 5 lines
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: wd at denx.de Bradley's Bromide: If computers get too powerful, we can organize them into a committee - that will do them in.
PATCH 5/6 cmd_nvedit.c: allow board-specific code before/after saving the environment
Quoted 1 line · Wolfgang Denk
I think whoever told you this was right. Let it break.
Come on, Wolfgang. That's not acceptable.
Quoted 3 lines
We cannot add pre- and post-hooks all ever the place for brain-dead designs that need to do this and that before and after doing perfectly things.
Well, I already have code in U-boot that does this. If you look at board/freescale/p1022ds/diu.c, you'll see that I override each of the NOR flash accessors. This is horribly inefficient, but it works. Unfortunately, it only covers NOR flash. The new design covers NOR and NAND.
The last two patches of this patchset are a vast improvement, but they require a board hook (and using Mike's idea, only one hook is necessary, not two).
As for 'all over the place", I think it's unfair to say my one board hook function is going to result in "all over the place" hacks.
Quoted 4 lines
It makes no sense adding this to saveenv, because there will be othe rplaces in the code that need to to the same - like if it's NAND flash, you will probabaly need to do the same for all NAND related commands.
Actually, the same code works for saving the environment to NAND flash. This is how the board code will look:
/*
* While the DIU is active, the localbus is not available. Therefore, in
* order to support the saveenv command to localbus devices, we need to
* temporarily disable the DIU and enable the localbus. To do this, we
* provide our own implementation of board_saveenv(). This function is called
* by do_env_save().
*/
#if defined(CONFIG_ENV_IS_IN_NAND) || defined(CONFIG_ENV_IS_IN_FLASH) int board_saveenv(void)
{
int switched, ret;
switched = set_mux_to_lbc();
ret = saveenv();
if (switched)
set_mux_to_diu();
return ret;
}#endif
Quoted 1 line
cmd_nvedit.cis definitely the wrong place for this.
If you have a better idea, then I'm all ears. I could implement my own version of saveenv(), but the current design of U-boot does not allow me to have two functions called saveenv().
Signature · 2 lines
Timur Tabi Linux kernel developer at Freescale
PATCH 5/6 cmd_nvedit.c: allow board-specific code before/after saving the environment
Quoted 5 lines · On Thursday 17 May 2012 18:35:25 Timur Tabi wrote:
Well, I already have code in U-boot that does this. If you look at
board/freescale/p1022ds/diu.c, you'll see that I override each of the NOR flash accessors. This is horribly inefficient, but it works. Unfortunately, it only covers NOR flash. The new design covers NOR and NAND.
oh, i see what you're on about now. we do a similar thing, but to support some address lines being controlled via GPIOs. you can see what we did here:
board/cm-bf537e/gpio_cfi_flash.c
unfortunately, we run up to the same issue you describe where doing saveenv doesn't go through the normal flash API, so the lines don't get set right, so we end up writing to the wrong part of flash.
when i brought this up before, the suggestion was to extend the existing mtd framework to support this because the existing nor flash framework is supposed to make the assumption that the entire thing is directly addressable. but i never found time or inclination, and i'm much less likely to do so today :).
the thread was titled:
flread: new command for reading indirect mapped flashes
and dates June 2009 :)
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20120517/3f8c7f57/attachment.pgp>
PATCH 5/6 cmd_nvedit.c: allow board-specific code before/after saving the environment
In reply to Timur TabiDear Timur,
Quoted 4 lines · In message <[email protected]> you wrote:
Quoted 2 lines
I think whoever told you this was right. Let it break.
Come on, Wolfgang. That's not acceptable.
Why not? But adding arbitrary complexity and ugliness into U-Boot mainline is acceptable? Why?
Quoted 7 lines
Quoted 3 lines
We cannot add pre- and post-hooks all ever the place for brain-dead designs that need to do this and that before and after doing perfectly things.
Well, I already have code in U-boot that does this. If you look at
board/freescale/p1022ds/diu.c, you'll see that I override each of the NOR flash accessors. This is horribly inefficient, but it works.
This is already streching the code to the limits, and the only reason you ever got this thrugh is that it's FSL specific code, you you have to deal yourself with this ugliness. I don;t think you will find good arguments to convince me adding such stuff into common code, though.
Quoted 1 line
Unfortunately, it only covers NOR flash. The new design covers NOR and NAND.
Well, your code does not really cover NOR flash. I think it covers only a small subset of the use cases, but horribly fails else.
For example, what happens when I just use "md" or "itest *addr" or similar trying to read NOR flash while the display is on?
You _do_ have a broken hardware design, and if you cannot access NOR flash with display running, and vice versa, than just accept this fact.
Feel free to provide commands to switch mode, but don't lard the code with hooks here and there trying to fix what cannot be fixed.
Quoted 6 lines
The last two patches of this patchset are a vast improvement, but they require a board hook (and using Mike's idea, only one hook is necessary, not two).
As for 'all over the place", I think it's unfair to say my one board hook function is going to result in "all over the place" hacks.
Well, you try again to fix just a single use-case, leaving all the others unsolved. It makes zero sense to fix "saveenv" while not fixing all other access modes to the same storage device.
Yes, it is a pain if you have to run something like
=> busmux flash;saveenv;busmux diu
but the ugliness comes from the hardware design, so we have no reasoin to camouflage it. Let people see what is going on under the hood - if this is done in a clean way, you don't have to be ashamed.
Quoted 7 lines
Quoted 4 lines
It makes no sense adding this to saveenv, because there will be othe rplaces in the code that need to to the same - like if it's NAND flash, you will probabaly need to do the same for all NAND related commands.
Actually, the same code works for saving the environment to NAND flash. This is how the board code will look:
But this again works only for thesingle use case of the "saveenv" command.
This makes no sense - it's still broken, and trying to fix it using this approach does not scale and/or does not work.
Quoted 3 lines
If you have a better idea, then I'm all ears. I could implement my own version of
saveenv(), but the current design of U-boot does not allow me to have two functions calledsaveenv().
Your problem is not just "saveenv". Your problem is that you need to switch modes. So provide a command to switch modes, and use this.
Yes, this is a pain, and it is less from perfect. But you cannot have a perfect solution on broken hardware. It makes no sense to waste lots of efforts on this. If you're ugly, you are still ugly even if wearing expensive clothes.
Best regards,
Wolfgang Denk
Signature · 5 lines
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: wd at denx.de Keep your head and your heart going in the right direction and you will not have to worry about your feet.
PATCH 5/6 cmd_nvedit.c: allow board-specific code before/after saving the environment
Quoted 4 lines · Wolfgang Denk
This is already streching the code to the limits, and the only reason you ever got this thrugh is that it's FSL specific code, you you have to deal yourself with this ugliness. I don;t think you will find good arguments to convince me adding such stuff into common code, though.
Well, I guess we'll just have to agree to disagree. I didn't think Mike's idea was a bad one, but if you don't like it, then I'll drop it.
Quoted 7 lines
Quoted 1 line
Unfortunately, it only covers NOR flash. The new design covers NOR and NAND.
Well, your code does not really cover NOR flash. I think it covers only a small subset of the use cases, but horribly fails else.
For example, what happens when I just use "md" or "itest *addr" or similar trying to read NOR flash while the display is on?
The reason I make a big deal about saveenv is because I use an environment variable ("video-mode") to enable video support. Once the console is switched to the video display, the only way to switch it back to the serial port is to delete the environment variable, save the environment, and reboot.
If we had a command that switched the console back to the serial port, I wouldn't need any of this.
Quoted 6 lines
You _do_ have a broken hardware design, and if you cannot access NOR flash with display running, and vice versa, than just accept this fact.
Feel free to provide commands to switch mode, but don't lard the code with hooks here and there trying to fix what cannot be fixed.
Is there a way to switch the console
Quoted 7 lines
Well, you try again to fix just a single use-case, leaving all the others unsolved. It makes zero sense to fix "saveenv" while not fixing all other access modes to the same storage device.
Yes, it is a pain if you have to run something like
=> busmux flash;saveenv;busmux diu
Hmmm... that's not a bad idea. I'll think about it.
Quoted 3 lines
but the ugliness comes from the hardware design, so we have no reasoin to camouflage it. Let people see what is going on under the hood - if this is done in a clean way, you don't have to be ashamed.
LOL.
Signature · 2 lines
Timur Tabi Linux kernel developer at Freescale
PATCH 5/6 cmd_nvedit.c: allow board-specific code before/after saving the environment
Quoted 1 line · Timur Tabi
Is there a way to switch the console
setenv stdout serial
works for me..
Regards,
Jeroen
PATCH 5/6 cmd_nvedit.c: allow board-specific code before/after saving the environment
Dear Jeroen Hofstee,
Quoted 5 lines · In message <[email protected]> you wrote:
Quoted 1 line · Timur Tabi
Is there a way to switch the console
setenv stdout serial
works for me..
Hey. Don't share insider information like that ;-)
Best regards,
Wolfgang Denk
Signature · 5 lines
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: wd at denx.de Presidency: The greased pig in the field game of American politics. - Ambrose Bierce
PATCH 5/6 cmd_nvedit.c: allow board-specific code before/after saving the environment
In reply to Timur TabiDear Timur,
Quoted 9 lines · In message <[email protected]> you wrote:
Quoted 3 lines
For example, what happens when I just use "md" or "itest *addr" or similar trying to read NOR flash while the display is on?
The reason I make a big deal about saveenv is because I use an environment variable ("video-mode") to enable video support. Once the console is switched to the video display, the only way to switch it back to the serial port is to delete the environment variable, save the environment, and reboot.
Please try to look over the rim of your plate. Even if you make "saveenv" work with some magic, your end users may have a zillion other ideas why they want to access the flash - for example, to store a copy of the environment created using "env export", or to reload such a saved profile using "env import". Why should their needs be ignored?
Quoted 4 lines
Quoted 2 lines
Feel free to provide commands to switch mode, but don't lard the code with hooks here and there trying to fix what cannot be fixed.
Is there a way to switch the console
Sure. Delete the env var, switch mode to flash access, run saveenv, run reset.
Best regards,
Wolfgang Denk
Signature · 4 lines
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: wd at denx.de Often it is fatal to live too long. - Racine
PATCH 5/6 cmd_nvedit.c: allow board-specific code before/after saving the environment
In reply to Timur TabiQuoted 8 lines · Timur Tabi
The reason I make a big deal about saveenv is because I use an environment variable ("video-mode") to enable video support. ?Once the console is switched to the video display, the only way to switch it back to the serial port is to delete the environment variable, save the environment, and reboot.
If we had a command that switched the console back to the serial port, I wouldn't need any of this.
Yes, I noticed it last week when working with mx51evk.
The suggestion I got from the list and that worked for me was to force setenv("stdout", "serial"); inside board_late_init.
Take a look at:
https://github.com/fabioestevam/u-boot-imx/commit/bbd9e6eac8dfbce2fe64e84f01c292ab708124b5
PATCH 5/6 cmd_nvedit.c: allow board-specific code before/after saving the environment
In reply to Wolfgang DenkQuoted 14 lines · Wolfgang Denk
Dear Timur Tabi,
Quoted 8 lines · In message <[email protected]> you wrote:
Quoted 2 lines
all these board hooks are paper-cutting us to death with unused bloat
I know, and I don't like it either. I hate how our hardware designers are always breaking the "rules", forcing us software developers to hack up our software more and more. The muxing on this chip is a like a cruel joke being played on me. I've even been told that I'm trying too hard to make it work.
I think whoever told you this was right. Let it break.
Quoted 8 lines
We cannot add pre- and post-hooks all ever the place for brain-dead designs that need to do this and that before and after doing perfectly things.
It makes no sense adding this to saveenv, because there will be othe rplaces in the code that need to to the same - like if it's NAND flash, you will probabaly need to do the same for all NAND related commands.
NAND doesn't need it because NAND goes through an API rather than direct memory-mapped access, and has more coarse-grained operations. NAND should be able to take care of this entirely in the driver using the select_chip() callback.
Timur, is there any reason to use NOR rather than NAND with this chip?
-Scott
PATCH 5/6 cmd_nvedit.c: allow board-specific code before/after saving the environment
Quoted 4 lines · Scott Wood
NAND doesn't need it because NAND goes through an API rather than direct memory-mapped access, and has more coarse-grained operations. NAND should be able to take care of this entirely in the driver using the
select_chip()callback.
Fair enough. How do I enable that feature? Do I create my own board_nand_init() and then do this:
this->select_chip = p1022ds_nand_select_chip;
Quoted 1 line
Timur, is there any reason to use NOR rather than NAND with this chip?
Well, as with most of our boards, NOR is the default configuration. Also, there's no NAND support upstream yet.
Signature · 2 lines
Timur Tabi Linux kernel developer at Freescale
PATCH 5/6 cmd_nvedit.c: allow board-specific code before/after saving the environment
Quoted 10 lines · Timur Tabi
Quoted 4 lines · Scott Wood
NAND doesn't need it because NAND goes through an API rather than direct memory-mapped access, and has more coarse-grained operations. NAND should be able to take care of this entirely in the driver using the
select_chip()callback.Fair enough. How do I enable that feature? Do I create my own
board_nand_init()and then do this:this->select_chip = p1022ds_nand_select_chip;
board_nand_init() is implemented in drivers/mtd/nand/fsl_elbc_nand.c. You'll need to add some board hook there.
Quoted 4 lines
Quoted 1 line
Timur, is there any reason to use NOR rather than NAND with this chip?
Well, as with most of our boards, NOR is the default configuration. Also, there's no NAND support upstream yet.
What isn't upstream, besides the muxing hack? Does it need the 4K page hack?
-Scott
PATCH 5/6 cmd_nvedit.c: allow board-specific code before/after saving the environment
Quoted 4 lines · Scott Wood
Quoted 2 lines
Quoted 2 lines
Well, as with most of our boards, NOR is the default configuration. Also, there's no NAND support upstream yet.
What isn't upstream, besides the muxing hack? Does it need the 4K page hack?
There's no NAND support at all. However, I just tried the two SDK patches that add it, and they apply cleanly, so that's an easy fix.
I guess we can drop patches #5 and #6, and just use the existing code to support NOR flash. I'll add NAND flash support.
Signature · 2 lines
Timur Tabi Linux kernel developer at Freescale
PATCH 5/6 cmd_nvedit.c: allow board-specific code before/after saving the environment
Quoted 7 lines · On 05/17/2012 09:21 PM, Tabi Timur-B04825 wrote:
Quoted 4 lines · Scott Wood
Quoted 2 lines
Quoted 2 lines
Well, as with most of our boards, NOR is the default configuration. Also, there's no NAND support upstream yet.
What isn't upstream, besides the muxing hack? Does it need the 4K page hack?
There's no NAND support at all.
Of course there's NAND support. I was asking what, besides the mux, makes that existing support not work on this board.
Quoted 2 lines
However, I just tried the two SDK patches
that add it, and they apply cleanly, so that's an easy fix.
Which patches are those?
-Scott
PATCH 5/6 cmd_nvedit.c: allow board-specific code before/after saving the environment
Quoted 3 lines · Scott Wood
Quoted 1 line
There's no NAND support at all.
Of course there's NAND support. I was asking what, besides the mux, makes that existing support not work on this board.
No, there is no NAND support for the P1022DS upstream.
[b04825 at efes u-boot.0]$ grep -i nand include/configs/P1022DS.h [b04825 at efes u-boot.0]$
Quoted 3 lines
Quoted 2 lines
Quoted 2 lines
However, I just tried the two SDK patches
that add it, and they apply cleanly, so that's an easy fix.Which patches are those?
powerpc/85xx: add SPI and SD builds for P1022DS powerpc/p1022ds: Add support for NAND and NAND boot
Signature · 2 lines
Timur Tabi Linux kernel developer at Freescale
PATCH 5/6 cmd_nvedit.c: allow board-specific code before/after saving the environment
Quoted 9 lines · Timur Tabi
Quoted 3 lines · Scott Wood
Quoted 1 line
There's no NAND support at all.
Of course there's NAND support. I was asking what, besides the mux, makes that existing support not work on this board.
No, there is no NAND support for the P1022DS upstream.
[b04825 at efes u-boot.0]$ grep -i nand
include/configs/P1022DS.h[b04825 at efes u-boot.0]$
That's the equivalent of saying Linux doesn't support something because nobody bothered to enable it in a certain defconfig.
Quoted 6 lines
Quoted 3 lines
Quoted 2 lines
Quoted 2 lines
However, I just tried the two SDK patches
that add it, and they apply cleanly, so that's an easy fix.Which patches are those?
powerpc/85xx: add SPI and SD builds for P1022DS powerpc/p1022ds: Add support for NAND and NAND boot
I'm not sure what SPI and SD have to do with it...
Most of the latter patch is concerned with NAND boot, which is a different issue from NAND support, but still pretty important if you're going NAND-only. It looks like the patches were actually initially separate, but Kumar oh-so-helpfully squashed them together.
One thing I would like to see fixed in at upstream version of p1022ds NAND boot support is for it to use SPD like a normal p1022ds boot. This will likely require reviving the three-stage boot discussion (TPL).
-Scott
PATCH 5/6 cmd_nvedit.c: allow board-specific code before/after saving the environment
Quoted 2 lines · Scott Wood
That's the equivalent of saying Linux doesn't support something because nobody bothered to enable it in a certain defconfig.
Well, that's exactly what I meant. When you boot an upstream U-boot on a P1022DS, there is no support for NAND chips. The 'nand' command does not exist. You cannot build a u-boot.bin that will boot from NAND. That pretty much means "there is no NAND support".
Quoted 8 lines
Quoted 6 lines
Quoted 3 lines
Quoted 2 lines
Quoted 2 lines
However, I just tried the two SDK patches
that add it, and they apply cleanly, so that's an easy fix.Which patches are those?
powerpc/85xx: add SPI and SD builds for P1022DS powerpc/p1022ds: Add support for NAND and NAND boot
I'm not sure what SPI and SD have to do with it...
The 2nd patch applies on top of the first.
Quoted 4 lines
Most of the latter patch is concerned with NAND boot, which is a different issue from NAND support, but still pretty important if you're going NAND-only. It looks like the patches were actually initially separate, but Kumar oh-so-helpfully squashed them together.
It's a good thing we don't do that any more.
Quoted 3 lines
One thing I would like to see fixed in at upstream version of p1022ds NAND boot support is for it to use SPD like a normal p1022ds boot. This will likely require reviving the three-stage boot discussion (TPL).
I just posted those two patches for upstream. I don't want the TPL work to hold up these patches.
Signature · 2 lines
Timur Tabi Linux kernel developer at Freescale
PATCH 5/6 cmd_nvedit.c: allow board-specific code before/after saving the environment
Quoted 9 lines · Timur Tabi
Quoted 2 lines · Scott Wood
That's the equivalent of saying Linux doesn't support something because nobody bothered to enable it in a certain defconfig.
Well, that's exactly what I meant. When you boot an upstream U-boot on a P1022DS, there is no support for NAND chips. The 'nand' command does not exist. You cannot build a u-boot.bin that will boot from NAND. That pretty much means "there is no NAND support".
I was under the impression that this was a developer discussion about what it would take to get this working, not an end user support forum.
Quoted 6 lines
Quoted 3 lines
One thing I would like to see fixed in at upstream version of p1022ds NAND boot support is for it to use SPD like a normal p1022ds boot. This will likely require reviving the three-stage boot discussion (TPL).
I just posted those two patches for upstream. I don't want the TPL work to hold up these patches.
It was over a year ago that I made that request internally. And still the answer is "I need this now now now!".
NACK any non-SPD NAND boot for a board that otherwise uses SPD, particularly if it has socketed RAM. It's not as if we don't know how to make this work.
Wolfgang will also probably object to adding another board to the old nand_spl infrastrucutre.
-Scott
PATCH 5/6 cmd_nvedit.c: allow board-specific code before/after saving the environment
Quoted 2 lines · Scott Wood
It was over a year ago that I made that request internally. And still the answer is "I need this now now now!".
Who's going to do that work, if not you?
Quoted 3 lines
NACK any non-SPD NAND boot for a board that otherwise uses SPD, particularly if it has socketed RAM. It's not as if we don't know how to make this work.
Well, *I* don't know how to do that.
Signature · 2 lines
Timur Tabi Linux kernel developer at Freescale
PATCH 5/6 cmd_nvedit.c: allow board-specific code before/after saving the environment
Quoted 5 lines · Timur Tabi
Quoted 2 lines · Scott Wood
It was over a year ago that I made that request internally. And still the answer is "I need this now now now!".
Who's going to do that work, if not you?
Matthew had something working a while ago, I thought.
Quoted 5 lines
Quoted 3 lines
NACK any non-SPD NAND boot for a board that otherwise uses SPD, particularly if it has socketed RAM. It's not as if we don't know how to make this work.
Well, *I* don't know how to do that.
Use a three stage boot where the middle stage runs out of L2 SRAM.
-Scott
PATCH 5/6 cmd_nvedit.c: allow board-specific code before/after saving the environment
Quoted 9 lines · Scott Wood
Quoted 5 lines · Timur Tabi
Quoted 2 lines · Scott Wood
It was over a year ago that I made that request internally. ?And still the answer is "I need this now now now!".
Who's going to do that work, if not you?
Matthew had something working a while ago, I thought.
Quoted 7 lines
Quoted 5 lines
Quoted 3 lines
NACK any non-SPD NAND boot for a board that otherwise uses SPD, particularly if it has socketed RAM. ?It's not as if we don't know how to make this work.
Well, *I* don't know how to do that.
Use a three stage boot where the middle stage runs out of L2 SRAM.
Then upstream u-boot reworked SPL so we need to rework using that implementation.
-M
PATCH 5/6 cmd_nvedit.c: allow board-specific code before/after saving the environment
In reply to Scott WoodDear Scott,
Quoted 3 lines · In message <[email protected]> you wrote:
Wolfgang will also probably object to adding another board to the old
nand_splinfrastrucutre.
True. This gives a NAK reliably.
Best regards,
Wolfgang Denk
Signature · 4 lines
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: wd at denx.de To be is to program.
PATCH 5/6 cmd_nvedit.c: allow board-specific code before/after saving the environment
In reply to Mike FrysingerQuoted 8 lines · Mike Frysinger
this is less bloat:
intboard_saveenv(void)__attribute__((weak, alias("saveenv")));int
do_env_save(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[]){ printf("Saving Environment to %s...\n", env_name_spec); return board_saveenv() ? 1 : 0; }
I don't think this can work:
cmd_nvedit.c:599:5: error: 'board_saveenv' aliased to undefined symbol 'saveenv'
cmd_nvedit.c:599:5: error: 'board_saveenv' aliased to undefined symbol 'saveenv'
make[1]: *** [/home/b04825/git/u-boot.0/1022/common/cmd_nvedit.o] Error 1
It looks like weak functions can't be in another source file?
If I change it to this, then it works:
static int __saveenv(void)
{
return saveenv();
}int board_saveenv(void) __attribute__((weak, alias("__saveenv")));
int do_env_save(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
{
printf("Saving Environment to %s...\n", env_name_spec);
return board_saveenv() ? 1 : 0;
}Signature · 2 lines
Timur Tabi Linux kernel developer at Freescale
PATCH 6/6 powerpc/85xx: p1022ds: use the saveenv board preparation functions
In reply to Timur TabiOn the P1022, the DIU video signals are muxed with the localbus, so when the DIU is active, the localbus is unavailable. The saveenv command now supports board-specific functions that allow the DIU/LBC mux to be switched while saving the environment.
This is much more efficient than switching the mux for each NOR flash transaction (which is what the current code does), and it also allows us to support any localbus device, not just NOR flash.
--- board/freescale/p1022ds/diu.c | 173 +++++++---------------------------------- include/configs/P1022DS.h | 6 -- 2 files changed, 28 insertions(+), 151 deletions(-)
board/freescale/p1022ds/diu.c +28 -145
@@ -147,10 +147,7 @@ int platform_diu_init(unsigned int xres, unsigned int yres, const char *port)* * On the Freescale P1022, the DIU video signal and the LBC address/data lines * share the same pins, which means that when the DIU is active (e.g. the -* console is on the DVI display), NOR flash cannot be accessed. So we use the -* weak accessor feature of the CFI flash code to temporarily switch the pin -* mux from DIU to LBC whenever we want to read or write flash. This has a -* significant performance penalty, but it's the only way to make it work. +* console is on the DVI display), NOR flash cannot be accessed. * * There are two muxes: one on the chip, and one on the board. The chip mux * controls whether the pins are used for the DIU or the LBC, and it is
@@ -213,6 +210,33 @@ static void set_mux_to_diu(void) }/* +* While the DIU is active, the localbus is not available. Therefore, in +* order to support the saveenv command, we need to temporarily disable the +* DIU and enable the localbus. To do this, we provide our own +* implementations of the board_start_saveenv() and board_finish_saveenv() +* weak functions. These functions are called by do_env_save() before and +* after the environment is saved. +*/ + +/* Remember if we switched the MUX, so that we know to switch it back */ +static int switched; + +int board_start_saveenv (void ) +{ + switched =set_mux_to_lbc (); + +return 0 ; +} + +void board_finish_saveenv (void ) +{ +if (switched) +set_mux_to_diu (); + + switched =0 ; +} + +/* * pixis_read - board-specific function to read from the PIXIS * * This function overrides the generic pixis_read() function, so that it can
@@ -271,144 +295,3 @@ void pixis_bank_reset(void)while (1 ); } - -#ifdef CONFIG_CFI_FLASH_USE_WEAK_ACCESSORS - -void flash_write8 (u8 value,void *addr) -{ -int sw =set_mux_to_lbc (); - -__raw_writeb (value, addr); -if (sw) { -/* -* To ensure the post-write is completed to eLBC, software must -* perform a dummy read from one valid address from eLBC space -* before changing the eLBC_DIU from NOR mode to DIU mode. -* set_mux_to_diu() includes a sync that will ensure the -* __raw_readb() completes before it switches the mux. -*/ -__raw_readb (addr); -set_mux_to_diu (); - } -} - -void flash_write16 (u16 value,void *addr) -{ -int sw =set_mux_to_lbc (); - -__raw_writew (value, addr); -if (sw) { -/* -* To ensure the post-write is completed to eLBC, software must -* perform a dummy read from one valid address from eLBC space -* before changing the eLBC_DIU from NOR mode to DIU mode. -* set_mux_to_diu() includes a sync that will ensure the -* __raw_readb() completes before it switches the mux. -*/ -__raw_readb (addr); -set_mux_to_diu (); - } -} - -void flash_write32 (u32 value,void *addr) -{ -int sw =set_mux_to_lbc (); - -__raw_writel (value, addr); -if (sw) { -/* -* To ensure the post-write is completed to eLBC, software must -* perform a dummy read from one valid address from eLBC space -* before changing the eLBC_DIU from NOR mode to DIU mode. -* set_mux_to_diu() includes a sync that will ensure the -* __raw_readb() completes before it switches the mux. -*/ -__raw_readb (addr); -set_mux_to_diu (); - } -} - -void flash_write64 (u64 value,void *addr) -{ -int sw =set_mux_to_lbc (); -uint32_t *p = addr; - -/* -* There is no __raw_writeq(), so do the write manually. We don't trust -* the compiler, so we use inline assembly. -*/ - __asm__ __volatile__( -"stw%U0%X0 %2,%0;\n" -"stw%U1%X1 %3,%1;\n" - :"=m" (*p),"=m" (*(p +1 )) - :"r" ((uint32_t ) (value >>32 )),"r" ((uint32_t ) (value))); - -if (sw) { -/* -* To ensure the post-write is completed to eLBC, software must -* perform a dummy read from one valid address from eLBC space -* before changing the eLBC_DIU from NOR mode to DIU mode. We -* read addr+4 because we just wrote to addr+4, so that's how we -* maintain execution order. set_mux_to_diu() includes a sync -* that will ensure the __raw_readb() completes before it -* switches the mux. -*/ -__raw_readb (addr +4 ); -set_mux_to_diu (); - } -} - -u8 flash_read8 (void *addr) -{ -u8 ret; - -int sw =set_mux_to_lbc (); - - ret =__raw_readb (addr); -if (sw) -set_mux_to_diu (); - -return ret; -} - -u16 flash_read16 (void *addr) -{ -u16 ret; - -int sw =set_mux_to_lbc (); - - ret =__raw_readw (addr); -if (sw) -set_mux_to_diu (); - -return ret; -} - -u32 flash_read32 (void *addr) -{ -u32 ret; - -int sw =set_mux_to_lbc (); - - ret =__raw_readl (addr); -if (sw) -set_mux_to_diu (); - -return ret; -} - -u64 flash_read64 (void *addr) -{ -u64 ret; - -int sw =set_mux_to_lbc (); - -/* There is no __raw_readq(), so do the read manually */ - ret = *(volatile u64 *)addr; -if (sw) -set_mux_to_diu (); - -return ret; -} - -#endif
include/configs/P1022DS.h +0 -6
@@ -206,12 +206,6 @@#define CONFIG_VGA_AS_SINGLE_DEVICE #define CONFIG_VIDEO_LOGO #define CONFIG_VIDEO_BMP_LOGO -#define CONFIG_CFI_FLASH_USE_WEAK_ACCESSORS -/* -* With CONFIG_CFI_FLASH_USE_WEAK_ACCESSORS, flash I/O is really slow, so -* disable empty flash sector detection, which is I/O-intensive. -*/ -#undef CONFIG_SYS_FLASH_EMPTY_INFO#endif #ifndef CONFIG_FSL_DIU_FB
Signature · 1 line
1.7.3.4