[U-Boot] I2C register access
Hi, I have problem in accessing registers of I2C . I am calling my application from u-boot. In my application i can access registers of I2C1 but can't access registers of I2C2. Is there any thing done in u-boot for initializing I2Ci ; i=1,2,3 for accessing registers? -- View this message in context: http://u-boot.10912.n7.nabble.com/I2C-register-access-tp149189.html Sent from the U-Boot mailing list archive at Nabble.com. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] ARM: mx6: use common CPU errata config options
On 07/03/2013 20:19, Stephen Warren wrote: On 03/07/2013 10:24 AM, Stefano Babic wrote: On 26/02/2013 23:28, Stephen Warren wrote: From: Stephen Warren swar...@nvidia.com Now that U-Boot has common CONFIG_ options to work around some ARM CPU errata, enable the relevant options on MX6, and remove the custom lowlevel_init.S, since it's just duplicated code now. Signed-off-by: Stephen Warren swar...@nvidia.com --- Hi Stephen, applied to u-boot-imx. It is not effective until Alber apply 1/3, but it does not hurt. If you do that, then won't the imx6-specific WAR code be removed before the generic implementation is added, so that there will be a period where the WAR won't be enabled? You're right - there is a period where it is not enabled. I hope it is quite short, and I will track this patchset to check when flows into u-boot-arm. I suppose if you send your pull request after Albert has merged the generic implementation there won't be an issue in u-boot-arm, but until u-boot-imx picks up the latest u-boot-arm, the issue will exist there. Right - there is some grey zone when a patchset belongs to different areas. My supposition (please correct if I am wrong) is that this patchset is ready to be merged and will not require another iteration, and I do not want to delay it while expecting something from my side. When Albert will pick it up the rest, everything will be fine. Stefano -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v7 07/31] Define CONFIG_SYS_LEGACY_BOARD everywhere
Dear Simon Glass, In message 1362715633-20556-8-git-send-email-...@chromium.org you wrote: We are introducing a new unified board setup and we want this to be the default. So we need to opt all architectures out first. ... +- CONFIG_SYS_LEGACY_BOARD + This option should not be defined by board config files. + This is an internal CONFIG defined by architectures which do not + support CONFIG_SYS_GENERIC_BOARD. It is used as a check that boards + don't accidentally define CONFIG_SYS_GENERIC_BOARD when their + architecture cannot support it, and U-Boot would then either not + build or not work. When an architecture supports generic board, + then CONFIG_SYS_LEGACY_BOARD can be removed from the architecture's + config.mk file so that generic board becomes available. Hm... I understand that you selected the ...LEGACY_BOARD name to make it easy to see the relation to ...GENERIC_BOARD? But then, the name is misleading - if my understanding is correct, then ...LEGACY_BOARD is NOT a _board_ specific config option, but an _architecture_ speci- fic one. Actually this is then not a real CONFIG_SYS_ thing at all. Should we rather use something like __HAVE_ARCH_GENERIC_BOARD ?? This would also make clear this is an internal macro only. 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 No journaling file system can recover your data if the disk dies. - Steve Rago in d4cw1p@plc.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/4] ARM: atmel: add sama5d3xek support
Hi Andreas,
On 3/8/2013 15:32, Andreas Bießmann wrote:
[snip]
+void at91_periph_clk_enable(int id)
+{
+struct at91_pmc *pmc = (struct at91_pmc *)ATMEL_BASE_PMC;
The write protect is meant to be right here?
I am sorry, I don't get the right means.
Well, this seems to be the first SoC from Atmel which has write
protection bit WPEN in pmc-wpmr for write access to pmc-pcer{0|1}. My
question here is, should we rely on reset state of the WPEN bit or
should we explicitly disable write protection on every call to
at91_periph_clk_enable() or should we do this conditional?
Additionally we may ask if we should enable write protection afterwards.
Now, we depends on reset state. This the reset value of this register is
0x, so no protect.
If we really need the write protect feature, will add it in future.
[snip]
+
+void at91_serial0_hw_init(void)
+{
+at91_set_a_periph(AT91_PIO_PORTD, 18, 1);/* TXD0 */
Why enabling PUP here for TX ...
I will correct it to use PUP.
Don't get me wrong, please do not use the PUP define which is
conditional. We should enable pullup for each TX line _unconditional_
which means place a '1' at last argument for each TX line (also for the
serial1_hw line which didn't had it in this patch). I don't know if the
mentioned errata (in comment above) also hits the sama5, but I think it
is good to have the TX line pulled up even if some external PU exists.
The internal PU is about 100 to 300 kOhms, a typical external PU is
about 10kOhms or 100kOhms, so the resulting resistance is nearly 10kOhm
(for 10k external) or about 50k to 75k, depending on concrete internal
resistance. I think this is ok.
The RX line instead should be conditional with PUP define, how do you
think about?
It's my fault.
OK, I will put TX line unconditional pull up. And Rx line without pull up.
[snip]
+#if defined(CONFIG_ATMEL_SPI)
+void at91_spi0_hw_init(unsigned long cs_mask)
+{
+at91_set_a_periph(AT91_PIO_PORTD, 10, 0); /* SPI0_MISO */
+at91_set_a_periph(AT91_PIO_PORTD, 11, 0); /* SPI0_MOSI */
+at91_set_a_periph(AT91_PIO_PORTD, 12, 0); /* SPI0_SPCK */
+
+if (cs_mask (1 0))
+at91_set_pio_output(AT91_PIO_PORTD, 13, 0);
+if (cs_mask (1 1))
+at91_set_pio_output(AT91_PIO_PORTD, 14, 0);
+if (cs_mask (1 2))
+at91_set_pio_output(AT91_PIO_PORTD, 15, 0);
+if (cs_mask (1 3))
+at91_set_pio_output(AT91_PIO_PORTD, 16, 0);
PUP for the PIO's? The comment above states 'Good to have if hardware is
soldered optionally or in case of SPI no slave is selected.' ...
Here, I think, we should set as PIO with pull up. when we need to access
spi flash, then we active this pin.
You are right, but should we use PUP or set pull up unconditionally?
I will set them pull up unconditionally. The atmel spi driver will set
the GPIO to 1 when activate, set to 0 when deactivate.
snip
+#ifdef CONFIG_LCD
+void at91_lcd_hw_init(void)
+{
Can you place an hint here, that this currently supports only wireing of
LCDDx on PORTA up to 16 bit? Or something like 'only sama5d3x board
style currently imlemented'.
I am not fully understand about this. why should we put this here?
Well, I checked the PIO lines and found out, that PIOA0 to PIOA29
(without the gap from PIOA15 to PIOA23) is sufficient to drive the 24bit
LCD. On sama5d3xek however they use PORTC and PORTE to drive the LCDD16
to LCDD23. I think it is at least worth an comment. Or we use some
parameter to distinguish between the different setups.
Maybe we should check LCD_OUTPUT_BPP to set whether need high 8 bit
(port C configuration)?
I forgot that LCD can be used with just 16bit, so the PORTA up to
PORTA15 would be sufficient. But that can somebody implement when he
needs it. What we need now is some way to differentiate between the
setups. I personally find the avr32 solution good, have a look at
arch/avr32/cpu/at32ap700x/portmux.c:portmux_enable_lcdc(). This however
will not match our case here cause the ap700x has two complete outputs
for one lcdc where the sama5 has only one option for the lcd control
lines and first 16 data lines but two options for the higher data lines.
I suggest we keep the lower 16 bit line here, and put the higher 8 bit
line to board file (sama5d3xek.c). Then if someone want to use higher 8
bit line which is different with sama5d3xek, then they can implement it
in board file.
+at91_set_a_periph(AT91_PIO_PORTA, 24, 0);/* LCDPWM */
+at91_set_a_periph(AT91_PIO_PORTA, 25, 0);/* LCDDISP */
+at91_set_a_periph(AT91_PIO_PORTA, 26, 0);/* LCDVSYNC */
+at91_set_a_periph(AT91_PIO_PORTA, 27, 0);/* LCDHSYNC */
+at91_set_a_periph(AT91_PIO_PORTA, 28, 0);/* LCDDOTCK */
+at91_set_a_periph(AT91_PIO_PORTA, 29, 0);/* LCDDEN */
+
+at91_set_a_periph(AT91_PIO_PORTA, 0, 0);/* LCDD0 */
+at91_set_a_periph(AT91_PIO_PORTA, 1, 0);/* LCDD1 */
+at91_set_a_periph(AT91_PIO_PORTA, 2, 0);
[U-Boot] [PATCH 7/7] powerpc/t4qds: Slave module for boot from SRIO and PCIE
When a T4 board boots from SRIO or PCIE, it needs to finish these processes:
1. Set all the cores in holdoff status.
2. Set the boot location to one PCIE or SRIO interface by RCW.
3. Set a specific TLB entry for the boot process.
4. Set a LAW entry with the TargetID of one PCIE or SRIO for the boot.
5. Set a specific TLB entry in order to fetch ucode and ENV from
master.
6. Set a LAW entry with the TargetID one of the PCIE ports for
ucode and ENV.
7. Slave's u-boot image should be generated specifically by
make _SRIO_PCIE_BOOT_config.
This will set SYS_TEXT_BASE=0xFFF8 and other configurations.
For more information about the feature of Boot from SRIO/PCIE, please
refer to the document doc/README.srio-pcie-boot-corenet.
Signed-off-by: Liu Gang gang@freescale.com
---
arch/powerpc/include/asm/immap_85xx.h |1 +
board/freescale/t4qds/tlb.c | 19 ++
boards.cfg|1 +
include/configs/t4qds.h | 34 ++--
4 files changed, 48 insertions(+), 7 deletions(-)
diff --git a/arch/powerpc/include/asm/immap_85xx.h
b/arch/powerpc/include/asm/immap_85xx.h
index d0a2eb0..8f86324 100644
--- a/arch/powerpc/include/asm/immap_85xx.h
+++ b/arch/powerpc/include/asm/immap_85xx.h
@@ -1840,6 +1840,7 @@ typedef struct ccsr_gur {
#define FSL_CORENET2_RCWSR4_SRDS3_PRTCL_SHIFT 11
#define FSL_CORENET2_RCWSR4_SRDS4_PRTCL0x00f8
#define FSL_CORENET2_RCWSR4_SRDS4_PRTCL_SHIFT 3
+#define FSL_CORENET_RCWSR6_BOOT_LOC0x0f80
#elif defined(CONFIG_PPC_B4860) || defined(CONFIG_PPC_B4420)
#define FSL_CORENET2_RCWSR4_SRDS1_PRTCL0xfe00
#define FSL_CORENET2_RCWSR4_SRDS1_PRTCL_SHIFT 25
diff --git a/board/freescale/t4qds/tlb.c b/board/freescale/t4qds/tlb.c
index 80eb511..58febf2 100644
--- a/board/freescale/t4qds/tlb.c
+++ b/board/freescale/t4qds/tlb.c
@@ -55,6 +55,15 @@ struct fsl_e_tlb_entry tlb_table[] = {
SET_TLB_ENTRY(1, CONFIG_SYS_INIT_L3_ADDR, CONFIG_SYS_INIT_L3_ADDR,
MAS3_SX|MAS3_SW|MAS3_SR, MAS2_I|MAS2_G,
0, 0, BOOKE_PAGESZ_1M, 1),
+#elif defined(CONFIG_SRIO_PCIE_BOOT_SLAVE)
+ /*
+* SRIO_PCIE_BOOT-SLAVE. When slave boot, the address of the
+* space is at 0xfff0, it covered the 0xf000.
+*/
+ SET_TLB_ENTRY(1, CONFIG_SYS_SRIO_PCIE_BOOT_SLAVE_ADDR,
+ CONFIG_SYS_SRIO_PCIE_BOOT_SLAVE_ADDR_PHYS,
+ MAS3_SX|MAS3_SW|MAS3_SR, MAS2_W|MAS2_G,
+ 0, 0, BOOKE_PAGESZ_1M, 1),
#else
SET_TLB_ENTRY(1, 0xf000, 0xf000,
MAS3_SX|MAS3_SW|MAS3_SR, MAS2_I|MAS2_G,
@@ -130,6 +139,16 @@ struct fsl_e_tlb_entry tlb_table[] = {
SET_TLB_ENTRY(1, QIXIS_BASE, QIXIS_BASE_PHYS,
MAS3_SX|MAS3_SW|MAS3_SR, MAS2_I|MAS2_G,
0, 17, BOOKE_PAGESZ_4K, 1),
+#ifdef CONFIG_SRIO_PCIE_BOOT_SLAVE
+ /*
+* SRIO_PCIE_BOOT-SLAVE. 1M space from 0xffe0 for
+* fetching ucode and ENV from master
+*/
+ SET_TLB_ENTRY(1, CONFIG_SYS_SRIO_PCIE_BOOT_UCODE_ENV_ADDR,
+ CONFIG_SYS_SRIO_PCIE_BOOT_UCODE_ENV_ADDR_PHYS,
+ MAS3_SX|MAS3_SW|MAS3_SR, MAS2_G,
+ 0, 18, BOOKE_PAGESZ_1M, 1),
+#endif
};
diff --git a/boards.cfg b/boards.cfg
index 95b0c46..b163770 100644
--- a/boards.cfg
+++ b/boards.cfg
@@ -875,6 +875,7 @@ stxssa_4Mpowerpc mpc85xx stxssa
stx
T4240QDS powerpc mpc85xx t4qds
freescale
T4240QDS_SDCARD powerpc mpc85xx t4qds
freescale - T4240QDS:RAMBOOT_PBL,SDCARD,SYS_TEXT_BASE=0xFFF8
T4240QDS_SPIFLASHpowerpc mpc85xx t4qds
freescale - T4240QDS:RAMBOOT_PBL,SPIFLASH,SYS_TEXT_BASE=0xFFF8
+T4240QDS_SRIO_PCIE_BOOT powerpc mpc85xx t4qds
freescale -
T4240QDS:SRIO_PCIE_BOOT_SLAVE,SYS_TEXT_BASE=0xFFF8
B4860QDS powerpc mpc85xx b4860qds
freescale - B4860QDS:PPC_B4860
B4860QDS_NAND powerpc mpc85xx b4860qds
freescale -
B4860QDS:PPC_B4860,RAMBOOT_PBL,NAND,SYS_TEXT_BASE=0xFFF8
B4860QDS_SPIFLASHpowerpc mpc85xx b4860qds
freescale -
B4860QDS:PPC_B4860,RAMBOOT_PBL,SPIFLASH,SYS_TEXT_BASE=0xFFF8
diff --git a/include/configs/t4qds.h b/include/configs/t4qds.h
index a0c96f2..5077cf3 100644
--- a/include/configs/t4qds.h
+++ b/include/configs/t4qds.h
@@ -31,6 +31,15 @@
#define CONFIG_RESET_VECTOR_ADDRESS0xfffc
#endif
+#ifdef CONFIG_SRIO_PCIE_BOOT_SLAVE
+/* Set 1M boot space */
+#define CONFIG_SYS_SRIO_PCIE_BOOT_SLAVE_ADDR
[U-Boot] [PATCH 1/7] powerpc/doc: Update the README.srio-pcie-boot-corenet
1. Misalignment will be found in the doc/README.srio-pcie-boot-corenet file when the tabs are set to 8 characters. And the standard for u-boot should be 8 character tabs! So this issue should be amended. 2. Add a NOTE for the ENV parameters of the Slave. Signed-off-by: Liu Gang gang@freescale.com --- doc/README.srio-pcie-boot-corenet | 34 -- 1 files changed, 20 insertions(+), 14 deletions(-) diff --git a/doc/README.srio-pcie-boot-corenet b/doc/README.srio-pcie-boot-corenet index cd7e7ee..2b1f76b 100644 --- a/doc/README.srio-pcie-boot-corenet +++ b/doc/README.srio-pcie-boot-corenet @@ -21,13 +21,13 @@ Environment of the SRIO or PCIE boot: e) Slave's RCW should configure the SerDes for SRIO or PCIE boot port, set the boot location to SRIO or PCIE, and holdoff all the cores. - ----- --- - | | | | | | - | | | | | | + --- --- --- + | | | | | | + | | | | | | | NorFlash|-| Master |SRIO or PCIE | Slave |[EEPROM] - | | | |===| | - | | | | | | - ----- --- + | | | |===| | + | | | | | | + --- --- --- The example based on P4080DS platform: Two P4080DS platforms can be used to implement the boot from SRIO or PCIE. @@ -87,26 +87,32 @@ How to use this feature: Please refer to the examples given above. 2. U-Boot image's compilation. - For master, U-Boot image should be generated normally. + For master, U-Boot image should be generated normally. - For example, master U-Boot image used on P4080DS should be compiled with + For example, master U-Boot image used on P4080DS should be compiled with make P4080DS_config. - For slave, U-Boot image should be generated specifically by + For slave, U-Boot image should be generated specifically by make _SRIO_PCIE_BOOT_config. - For example, slave U-Boot image used on P4080DS should be compiled with + For example, slave U-Boot image used on P4080DS should be compiled with make P4080DS_SRIO_PCIE_BOOT_config. 3. Necessary modifications based on a specific environment. - For a specific environment, the addresses of the slave's U-Boot image, - UCode, ENV stored in master's NorFlash, and any other configurations - can be modified in the file: - include/configs/corenet_ds.h. + For a specific environment, the addresses of the slave's U-Boot image, + UCode, ENV stored in master's NorFlash, and any other configurations + can be modified in the file: + include/configs/corenet_ds.h. 4. Set and save the environment variable bootmaster with SRIO1, SRIO2 or PCIE1, PCIE2, PCIE3 for master, and then restart it in order to perform the role as a master for boot from SRIO or PCIE. + +NOTE: When the Slave's ENV parameters are stored in Master's NorFlash, + it can fetch them through PCIE or SRIO interface. But the ENV + parameters can not be modified by saveenv or other commands under + the Slave's u-boot environment, because the Slave can not erase, + write Master's NorFlash by PCIE or SRIO link. -- 1.7.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/7] powerpc/boot: Change the macro of Boot from SRIO and PCIE master module
Change the macro CONFIG_SYS_FSL_SRIO_PCIE_BOOT_MASTER to
CONFIG_SRIO_PCIE_BOOT_MASTER, remove them from
arch/powerpc/include/asm/config_mpc85xx.h file, and add those macros
in configuration header file of each board which can support the
master module of Boot from SRIO and PCIE.
Signed-off-by: Liu Gang gang@freescale.com
---
README|3 +++
arch/powerpc/cpu/mpc85xx/cpu_init.c |2 +-
arch/powerpc/cpu/mpc8xxx/srio.c |4 ++--
arch/powerpc/include/asm/config_mpc85xx.h |4
drivers/pci/fsl_pci_init.c|6 +++---
include/configs/P2041RDB.h|1 +
include/configs/P3041DS.h |2 +-
include/configs/P4080DS.h |2 +-
include/configs/P5020DS.h |2 +-
9 files changed, 13 insertions(+), 13 deletions(-)
diff --git a/README b/README
index 42544ce..a749094 100644
--- a/README
+++ b/README
@@ -3706,6 +3706,9 @@ Low Level (hardware related) configuration options:
- CONFIG_SRIO2:
Board has SRIO 2 port available
+- CONFIG_SRIO_PCIE_BOOT_MASTER
+ Board can support master function for Boot from SRIO and PCIE
+
- CONFIG_SYS_SRIOn_MEM_VIRT:
Virtual Address of SRIO port 'n' memory region
diff --git a/arch/powerpc/cpu/mpc85xx/cpu_init.c
b/arch/powerpc/cpu/mpc85xx/cpu_init.c
index de9d916..d860eba 100644
--- a/arch/powerpc/cpu/mpc85xx/cpu_init.c
+++ b/arch/powerpc/cpu/mpc85xx/cpu_init.c
@@ -564,7 +564,7 @@ skip_l2:
#ifdef CONFIG_SYS_SRIO
srio_init();
-#ifdef CONFIG_SYS_FSL_SRIO_PCIE_BOOT_MASTER
+#ifdef CONFIG_SRIO_PCIE_BOOT_MASTER
char *s = getenv(bootmaster);
if (s) {
if (!strcmp(s, SRIO1)) {
diff --git a/arch/powerpc/cpu/mpc8xxx/srio.c b/arch/powerpc/cpu/mpc8xxx/srio.c
index 6e6f7dc..90d1065 100644
--- a/arch/powerpc/cpu/mpc8xxx/srio.c
+++ b/arch/powerpc/cpu/mpc8xxx/srio.c
@@ -24,7 +24,7 @@
#include asm/fsl_srio.h
#include asm/errno.h
-#ifdef CONFIG_SYS_FSL_SRIO_PCIE_BOOT_MASTER
+#ifdef CONFIG_SRIO_PCIE_BOOT_MASTER
#define SRIO_PORT_ACCEPT_ALL 0x1001
#define SRIO_IB_ATMU_AR 0x80f55000
#define SRIO_OB_ATMU_AR_MAINT 0x80077000
@@ -299,7 +299,7 @@ void srio_init(void)
}
}
-#ifdef CONFIG_SYS_FSL_SRIO_PCIE_BOOT_MASTER
+#ifdef CONFIG_SRIO_PCIE_BOOT_MASTER
void srio_boot_master(int port)
{
struct ccsr_rio *srio = (void *)CONFIG_SYS_FSL_SRIO_ADDR;
diff --git a/arch/powerpc/include/asm/config_mpc85xx.h
b/arch/powerpc/include/asm/config_mpc85xx.h
index d57c178..51daf80 100644
--- a/arch/powerpc/include/asm/config_mpc85xx.h
+++ b/arch/powerpc/include/asm/config_mpc85xx.h
@@ -335,7 +335,6 @@
#define CONFIG_SYS_FSL_ERRATUM_NMG_CPU_A011
#define CONFIG_SYS_FSL_ERRATUM_CPU_A003999
#define CONFIG_SYS_FSL_ERRATUM_DDR_A003474
-#define CONFIG_SYS_FSL_SRIO_PCIE_BOOT_MASTER
#define CONFIG_SYS_FSL_SRIO_MAX_PORTS 2
#define CONFIG_SYS_FSL_SRIO_OB_WIN_NUM 9
#define CONFIG_SYS_FSL_SRIO_IB_WIN_NUM 5
@@ -367,7 +366,6 @@
#define CONFIG_SYS_FSL_ERRATUM_NMG_CPU_A011
#define CONFIG_SYS_FSL_ERRATUM_CPU_A003999
#define CONFIG_SYS_FSL_ERRATUM_DDR_A003474
-#define CONFIG_SYS_FSL_SRIO_PCIE_BOOT_MASTER
#define CONFIG_SYS_FSL_SRIO_MAX_PORTS 2
#define CONFIG_SYS_FSL_SRIO_OB_WIN_NUM 9
#define CONFIG_SYS_FSL_SRIO_IB_WIN_NUM 5
@@ -409,7 +407,6 @@
#define CONFIG_SYS_P4080_ERRATUM_SERDES_A005
#define CONFIG_SYS_FSL_ERRATUM_CPU_A003999
#define CONFIG_SYS_FSL_ERRATUM_DDR_A003474
-#define CONFIG_SYS_FSL_SRIO_PCIE_BOOT_MASTER
#define CONFIG_SYS_FSL_SRIO_MAX_PORTS 2
#define CONFIG_SYS_FSL_SRIO_OB_WIN_NUM 9
#define CONFIG_SYS_FSL_SRIO_IB_WIN_NUM 5
@@ -443,7 +440,6 @@
#define CONFIG_SYS_FSL_USB_INTERNAL_UTMI_PHY
#define CONFIG_SYS_FSL_ERRATUM_ESDHC111
#define CONFIG_SYS_FSL_ERRATUM_DDR_A003474
-#define CONFIG_SYS_FSL_SRIO_PCIE_BOOT_MASTER
#define CONFIG_SYS_FSL_SRIO_MAX_PORTS 2
#define CONFIG_SYS_FSL_SRIO_OB_WIN_NUM 9
#define CONFIG_SYS_FSL_SRIO_IB_WIN_NUM 5
diff --git a/drivers/pci/fsl_pci_init.c b/drivers/pci/fsl_pci_init.c
index 77ac1f7..621c899 100644
--- a/drivers/pci/fsl_pci_init.c
+++ b/drivers/pci/fsl_pci_init.c
@@ -211,7 +211,7 @@ static int fsl_pci_setup_inbound_windows(struct
pci_controller *hose,
return 1;
}
-#ifdef CONFIG_SYS_FSL_SRIO_PCIE_BOOT_MASTER
+#ifdef CONFIG_SRIO_PCIE_BOOT_MASTER
static void fsl_pcie_boot_master(pit_t *pi)
{
/* configure inbound window for slave's u-boot image */
@@ -388,7 +388,7 @@ void fsl_pci_init(struct pci_controller *hose, struct
fsl_pci_info *pci_info)
/* see if we are a PCIe or PCI controller */
pci_hose_read_config_byte(hose, dev, FSL_PCIE_CAP_ID, pcie_cap);
-#ifdef CONFIG_SYS_FSL_SRIO_PCIE_BOOT_MASTER
+#ifdef CONFIG_SRIO_PCIE_BOOT_MASTER
/* boot from PCIE --master */
char *s = getenv(bootmaster);
char pcie[6];
@@ -624,7 +624,7 @@ int fsl_pci_init_port(struct fsl_pci_info *pci_info,
if (fsl_is_pci_agent(hose)) {
[U-Boot] [PATCH 4/7] powerpc/b4860qds: Enable master module for boot from SRIO and PCIE
B4860QDS can support the feature of Boot from SRIO/PCIE, and the macro CONFIG_SRIO_PCIE_BOOT_MASTER will enable the master module of this feature when building the u-boot image. You can get some description about this macro in README file, and for more information about the feature of Boot from SRIO/PCIE, please refer to the document doc/README.srio-pcie-boot-corenet. Signed-off-by: Liu Gang gang@freescale.com --- include/configs/B4860QDS.h |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/include/configs/B4860QDS.h b/include/configs/B4860QDS.h index b09119a..81cd584 100644 --- a/include/configs/B4860QDS.h +++ b/include/configs/B4860QDS.h @@ -64,6 +64,7 @@ #define CONFIG_SYS_SRIO #define CONFIG_SRIO1 /* SRIO port 1 */ #define CONFIG_SRIO2 /* SRIO port 2 */ +#define CONFIG_SRIO_PCIE_BOOT_MASTER #endif #define CONFIG_FSL_LAW /* Use common FSL init code */ -- 1.7.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 5/7] powerpc/b4860qds: Slave module for boot from SRIO and PCIE
When a b4860qds board boots from SRIO or PCIE, it needs to finish these
processes:
1. Set all the cores in holdoff status.
2. Set the boot location to one PCIE or SRIO interface by RCW.
3. Set a specific TLB entry for the boot process.
4. Set a LAW entry with the TargetID of one PCIE or SRIO for the boot.
5. Set a specific TLB entry in order to fetch ucode and ENV from
master.
6. Set a LAW entry with the TargetID one of the PCIE ports for
ucode and ENV.
7. Slave's u-boot image should be generated specifically by
make _SRIO_PCIE_BOOT_config.
This will set SYS_TEXT_BASE=0xFFF8 and other configurations.
For more information about the feature of Boot from SRIO/PCIE, please
refer to the document doc/README.srio-pcie-boot-corenet.
Signed-off-by: Liu Gang gang@freescale.com
---
arch/powerpc/include/asm/immap_85xx.h |1 +
board/freescale/b4860qds/tlb.c| 19 +++
boards.cfg|1 +
include/configs/B4860QDS.h| 32 +++-
4 files changed, 48 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/include/asm/immap_85xx.h
b/arch/powerpc/include/asm/immap_85xx.h
index 4eb3f79..d0a2eb0 100644
--- a/arch/powerpc/include/asm/immap_85xx.h
+++ b/arch/powerpc/include/asm/immap_85xx.h
@@ -1845,6 +1845,7 @@ typedef struct ccsr_gur {
#define FSL_CORENET2_RCWSR4_SRDS1_PRTCL_SHIFT 25
#define FSL_CORENET2_RCWSR4_SRDS2_PRTCL0x00ff
#define FSL_CORENET2_RCWSR4_SRDS2_PRTCL_SHIFT 16
+#define FSL_CORENET_RCWSR6_BOOT_LOC0x0f80
#endif
#define FSL_CORENET2_RCWSR5_SRDS_PLL_PD_S1_PLL10x0080
#define FSL_CORENET2_RCWSR5_SRDS_PLL_PD_S1_PLL20x0040
diff --git a/board/freescale/b4860qds/tlb.c b/board/freescale/b4860qds/tlb.c
index 6d634bf..0ea4976 100644
--- a/board/freescale/b4860qds/tlb.c
+++ b/board/freescale/b4860qds/tlb.c
@@ -52,6 +52,15 @@ struct fsl_e_tlb_entry tlb_table[] = {
SET_TLB_ENTRY(1, CONFIG_SYS_INIT_L3_ADDR, CONFIG_SYS_INIT_L3_ADDR,
MAS3_SX|MAS3_SW|MAS3_SR, MAS2_I|MAS2_G,
0, 0, BOOKE_PAGESZ_1M, 1),
+#elif defined(CONFIG_SRIO_PCIE_BOOT_SLAVE)
+ /*
+* SRIO_PCIE_BOOT-SLAVE. When slave boot, the address of the
+* space is at 0xfff0, it covered the 0xf000.
+*/
+ SET_TLB_ENTRY(1, CONFIG_SYS_SRIO_PCIE_BOOT_SLAVE_ADDR,
+ CONFIG_SYS_SRIO_PCIE_BOOT_SLAVE_ADDR_PHYS,
+ MAS3_SX|MAS3_SW|MAS3_SR, MAS2_W|MAS2_G,
+ 0, 0, BOOKE_PAGESZ_1M, 1),
#else
SET_TLB_ENTRY(1, 0xf000, 0xf000,
MAS3_SX|MAS3_SW|MAS3_SR, MAS2_I|MAS2_G,
@@ -137,6 +146,16 @@ struct fsl_e_tlb_entry tlb_table[] = {
MAS3_SW|MAS3_SR, MAS2_I|MAS2_G,
0, 16, BOOKE_PAGESZ_256M, 1),
#endif
+#ifdef CONFIG_SRIO_PCIE_BOOT_SLAVE
+ /*
+* SRIO_PCIE_BOOT-SLAVE. 1M space from 0xffe0 for
+* fetching ucode and ENV from master
+*/
+ SET_TLB_ENTRY(1, CONFIG_SYS_SRIO_PCIE_BOOT_UCODE_ENV_ADDR,
+ CONFIG_SYS_SRIO_PCIE_BOOT_UCODE_ENV_ADDR_PHYS,
+ MAS3_SX|MAS3_SW|MAS3_SR, MAS2_G,
+ 0, 17, BOOKE_PAGESZ_1M, 1),
+#endif
};
int num_tlb_entries = ARRAY_SIZE(tlb_table);
diff --git a/boards.cfg b/boards.cfg
index 136ea0a..95b0c46 100644
--- a/boards.cfg
+++ b/boards.cfg
@@ -878,6 +878,7 @@ T4240QDS_SPIFLASHpowerpc mpc85xx t4qds
freesca
B4860QDS powerpc mpc85xx b4860qds
freescale - B4860QDS:PPC_B4860
B4860QDS_NAND powerpc mpc85xx b4860qds
freescale -
B4860QDS:PPC_B4860,RAMBOOT_PBL,NAND,SYS_TEXT_BASE=0xFFF8
B4860QDS_SPIFLASHpowerpc mpc85xx b4860qds
freescale -
B4860QDS:PPC_B4860,RAMBOOT_PBL,SPIFLASH,SYS_TEXT_BASE=0xFFF8
+B4860QDS_SRIO_PCIE_BOOT powerpc mpc85xx b4860qds
freescale -
B4860QDS:PPC_B4860,SRIO_PCIE_BOOT_SLAVE,SYS_TEXT_BASE=0xFFF8
B4420QDS powerpc mpc85xx b4860qds
freescale - B4860QDS:PPC_B4420
B4420QDS_NAND powerpc mpc85xx b4860qds
freescale -
B4860QDS:PPC_B4420,RAMBOOT_PBL,NAND,SYS_TEXT_BASE=0xFFF8
B4420QDS_SPIFLASHpowerpc mpc85xx b4860qds
freescale -
B4860QDS:PPC_B4420,RAMBOOT_PBL,SPIFLASH,SYS_TEXT_BASE=0xFFF8
diff --git a/include/configs/B4860QDS.h b/include/configs/B4860QDS.h
index 81cd584..00ee5ac 100644
--- a/include/configs/B4860QDS.h
+++ b/include/configs/B4860QDS.h
@@ -34,6 +34,15 @@
#define CONFIG_RESET_VECTOR_ADDRESS0xfffc
#endif
+#ifdef CONFIG_SRIO_PCIE_BOOT_SLAVE
+/* Set 1M boot space */
[U-Boot] [PATCH 3/7] powerpc/b4860qds: Add the tlb entries for SRIO interfaces
Add the tlb entries based on the configuration of the SRIO interfaces.
Every SRIO interface has 256M space:
#define CONFIG_SYS_SRIO1_MEM_VIRT 0xa000
#define CONFIG_SYS_SRIO1_MEM_PHYS 0xc2000ull
#define CONFIG_SYS_SRIO2_MEM_VIRT 0xb000
#define CONFIG_SYS_SRIO2_MEM_PHYS 0xc3000ull
Signed-off-by: Liu Gang gang@freescale.com
---
board/freescale/b4860qds/tlb.c | 19 +--
1 files changed, 17 insertions(+), 2 deletions(-)
diff --git a/board/freescale/b4860qds/tlb.c b/board/freescale/b4860qds/tlb.c
index 373cb78..6d634bf 100644
--- a/board/freescale/b4860qds/tlb.c
+++ b/board/freescale/b4860qds/tlb.c
@@ -111,8 +111,6 @@ struct fsl_e_tlb_entry tlb_table[] = {
#ifdef CONFIG_SYS_NAND_BASE
/*
* *I*G - NAND
-* entry 14 and 15 has been used hard coded, they will be disabled
-* in cpu_init_f, so we use entry 16 for nand.
*/
SET_TLB_ENTRY(1, CONFIG_SYS_NAND_BASE, CONFIG_SYS_NAND_BASE_PHYS,
MAS3_SX|MAS3_SW|MAS3_SR, MAS2_I|MAS2_G,
@@ -122,6 +120,23 @@ struct fsl_e_tlb_entry tlb_table[] = {
MAS3_SX|MAS3_SW|MAS3_SR, MAS2_I|MAS2_G,
0, 12, BOOKE_PAGESZ_4K, 1),
+ /*
+* *I*G - SRIO
+* entry 14 and 15 has been used hard coded, they will be disabled
+* in cpu_init_f, so we use entry 16 for SRIO2.
+*/
+#ifdef CONFIG_SYS_SRIO1_MEM_PHYS
+ /* *I*G* - SRIO1 */
+ SET_TLB_ENTRY(1, CONFIG_SYS_SRIO1_MEM_VIRT, CONFIG_SYS_SRIO1_MEM_PHYS,
+ MAS3_SW|MAS3_SR, MAS2_I|MAS2_G,
+ 0, 13, BOOKE_PAGESZ_256M, 1),
+#endif
+#ifdef CONFIG_SYS_SRIO2_MEM_PHYS
+ /* *I*G* - SRIO2 */
+ SET_TLB_ENTRY(1, CONFIG_SYS_SRIO2_MEM_VIRT, CONFIG_SYS_SRIO2_MEM_PHYS,
+ MAS3_SW|MAS3_SR, MAS2_I|MAS2_G,
+ 0, 16, BOOKE_PAGESZ_256M, 1),
+#endif
};
int num_tlb_entries = ARRAY_SIZE(tlb_table);
--
1.7.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 6/7] powerpc/t4qds: Enable master module for Boot from SRIO and PCIE
T4 can support the feature of Boot from SRIO/PCIE, and the macro CONFIG_SRIO_PCIE_BOOT_MASTER will enable the master module of this feature when building the u-boot image. You can get some description about this macro in README file, and for more information about the feature of Boot from SRIO/PCIE, please refer to the document doc/README.srio-pcie-boot-corenet. Signed-off-by: Liu Gang gang@freescale.com --- include/configs/t4qds.h |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/include/configs/t4qds.h b/include/configs/t4qds.h index 2c665b8..a0c96f2 100644 --- a/include/configs/t4qds.h +++ b/include/configs/t4qds.h @@ -64,6 +64,7 @@ #define CONFIG_SYS_SRIO #define CONFIG_SRIO1 /* SRIO port 1 */ #define CONFIG_SRIO2 /* SRIO port 2 */ +#define CONFIG_SRIO_PCIE_BOOT_MASTER #define CONFIG_FSL_LAW /* Use common FSL init code */ -- 1.7.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Possible GPL violation
fre 2013-03-08 klockan 10:46 +1300 skrev Charles Manning: I have had to deal with this a bit so I'll give my 2c. Under the GPL2, the company only has to provide source, or make an offer to do so, to customers buying the product containing the GPL code. If you go the written offer path then it's not limited to your customers, the written offer is valid for any third party which pretty much means anyone. This is to cover that your customers have the right to redistribute non-commercially with a copy of your written offer. Regards Henrik ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Regarding Kernel not starting
Hi Friends, I have successfully run u-boot our my custom board but I can't run kernel. Problem is that I have saved uImage.bin at NOR location 0x80 and load into DRAM:0x4100. Here u-boot can get kernel info and print into UART consol but after loading uncompressed image from 0x4100 to 0x4002 u-boot transfer its control to linux kernel and here my hardware goes reset means can't run kernel at 0x4002. Following is the log of consol: U-Boot 2011.09 (Jan 23 2013 - 17:16:07) CPU: BTAM MCF5329 (Mask:54 Version:2) CPU CLK 240 MHz BUS CLK 80 MHz Board: BTAM 5329 I2C: ready DRAM: 32 MiB Flash: 16 MiB In:serial Out: serial Err: serial Net: Link UP timeout FEC0 Hit any key to stop autoboot: 5 4 3 2 1 0 ## Booting kernel from Legacy Image at 4100 ... Image Name: Created: 2013-03-04 12:03:52 UTC Image Type: M68K Linux Kernel Image (gzip compressed) Data Size:1549021 Bytes = 1.5 MiB Load Address: 4002 Entry Point: 4002 Verifying Checksum ... OK Uncompressing Kernel Image ... OK U-Boot 2011.09 (Jan 23 2013 - 17:16:07) CPU: BTAM MCF5329 (Mask:54 Version:2) CPU CLK 240 MHz BUS CLK 80 MHz Board: BTAM 5329 I2C: ready DRAM: 32 MiB Flash: 16 MiB In:serial Out: serial Err: serial Net: Link UP timeout FEC0 Hit any key to stop autoboot: 5 4 3 2 1 0 ## Booting kernel from Legacy Image at 4100 ... Image Name: Created: 2013-03-04 12:03:52 UTC Image Type: M68K Linux Kernel Image (gzip compressed) Data Size:1549021 Bytes = 1.5 MiB Load Address: 4002 Entry Point: 4002 Verifying Checksum ... OK Uncompressing Kernel Image ... OK U-Boot 2011.09 (Jan 23 2013 - 17:16:07) CPU: BTAM MCF5329 (Mask:54 Version:2) CPU CLK 240 MHz BUS CLK 80 MHz Thanks Regards, Ramesh ~~Disclaimer~~~ Information contained and transmitted by this e-mail is confidential and proprietary to iGATE and its affiliates and is intended for use only by the recipient. If you are not the intended recipient, you are hereby notified that any dissemination, distribution, copying or use of this e-mail is strictly prohibited and you are requested to delete this e-mail immediately and notify the originator or mailad...@igate.com mailto:mailad...@igate.com. iGATE does not enter into any agreement with any party by e-mail. Any views expressed by an individual do not necessarily reflect the view of iGATE. iGATE is not responsible for the consequences of any actions taken on the basis of information provided, through this email. The contents of an attachment to this e-mail may contain software viruses, which could damage your own computer system. While iGATE has taken every reasonable precaution to minimise this risk, we cannot accept liability for any damage which you sustain as a result of software viruses. You should carry out your own virus checks before opening an attachment. To know more about iGATE please visit www.igate.com http://www.igate.com. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Regarding Kernel not starting
On 08/03/13 09:56, Ramesh K Khokhani wrote: Hi Friends, I have successfully run u-boot our my custom board but I can't run kernel. Problem is that I have saved uImage.bin at NOR location 0x80 and load into DRAM:0x4100. Here u-boot can get kernel info and print into UART consol but after loading uncompressed image from 0x4100 to 0x4002 u-boot transfer its control to linux kernel and here my hardware goes reset means can't run kernel at 0x4002. Following is the log of consol: U-Boot 2011.09 (Jan 23 2013 - 17:16:07) CPU: BTAM MCF5329 (Mask:54 Version:2) CPU CLK 240 MHz BUS CLK 80 MHz Board: BTAM 5329 I2C: ready DRAM: 32 MiB Flash: 16 MiB In:serial Out: serial Err: serial Net: Link UP timeout FEC0 Hit any key to stop autoboot: 5 4 3 2 1 0 ## Booting kernel from Legacy Image at 4100 ... Image Name: Created: 2013-03-04 12:03:52 UTC Image Type: M68K Linux Kernel Image (gzip compressed) Data Size:1549021 Bytes = 1.5 MiB Load Address: 4002 Entry Point: 4002 Verifying Checksum ... OK Uncompressing Kernel Image ... OK Once you've got this point, you're no longer in the U-Boot environment. I suggest you repost over on one of the Linux mailing lists. Regards Mark J. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5] Exynos5: Pinmux: Add fdt for pinmux
Hi Simon,
Hi Akshay,
On Thu, Mar 7, 2013 at 6:09 AM, Akshay Saraswat aksha...@samsung.com wrote:
This patch adds fdt nodes for peripherals which require
pin muxing and configuration. Device tree bindings for pinctrl
are kept same as required for Linux. Existing pinmux code
modified to retrieve gpio range and function related info from fdt.
Depends-on: [U-Boot] [PATCH 0/4 V3] EXYNOS5: Add GPIO numbering feature
URL: http://lists.denx.de/pipermail/u-boot/2013-February/146151.html
Signed-off-by: Akshay Saraswat aksha...@samsung.com
---
Changes since v1:
- Device tree bindings changed to linux style.
- Added documentation for samsung pinctrl.
Changes since v2:
- Rebased as per new version of GPIO numbering patch-set.
Changes since v3:
- Added comments to reduce ambiguity and increase readability.
- Fixed few other nits.
Changes since v4:
- Added support for reading peripheral pinctrl subnode names from
preipheral's node instead of hard coding.
Well I have to say this is looking really nice. From what I can tell
you are using the Linux binding for samsung,pinctrl-names - please can
you add in that binding information to your binding file - I can't see
it there?
samsung,pinctrl-names is already mentioned in example 3 of
doc/device-tree-bindings/samsung-pinctrl.txt.
samsung-pinctrl.txt in u-boot and kernel are same except the name exynos5
replaced exynos4210.
Please tell me, if I misunderstood the requirement.
The interesting thing is that you should at some point (further patch)
be able to remove the alias stuff and have the driver's pass their
node offset into this function. Then we can drop the peripheral IDs
altogether perhaps?
I think for now we should keep PERIPH_ID's because same pinmux.c and functions
are being used by
exynos4 and exynos4x12. Since, I thought we should not break support for these
SoC's, I kept node
retrieval in Pinmux itself instead of drivers or smdk5250.c. Please suggest.
arch/arm/cpu/armv7/exynos/pinmux.c | 357 +++---
arch/arm/dts/exynos5250-pinctrl.dtsi | 675
+++
arch/arm/dts/exynos5250.dtsi | 92
board/samsung/dts/exynos5250-smdk5250.dts| 11 +
doc/device-tree-bindings/samsung-pinctrl.txt | 253 ++
include/fdtdec.h | 4 +
lib/fdtdec.c | 4 +
7 files changed, 1231 insertions(+), 165 deletions(-)
create mode 100644 arch/arm/dts/exynos5250-pinctrl.dtsi
create mode 100644 doc/device-tree-bindings/samsung-pinctrl.txt
[..]
diff --git a/include/fdtdec.h b/include/fdtdec.h
index 77f244f..26692e5 100644
--- a/include/fdtdec.h
+++ b/include/fdtdec.h
@@ -81,6 +81,10 @@ enum fdt_compat_id {
COMPAT_SAMSUNG_EXYNOS_EHCI, /* Exynos EHCI controller */
COMPAT_SAMSUNG_EXYNOS_USB_PHY, /* Exynos phy controller for usb2.0
*/
COMPAT_MAXIM_MAX77686_PMIC, /* MAX77686 PMIC */
+ COMPAT_SAMSUNG_EXYNOS_UART, /* Exynos serial */
+ COMPAT_SAMSUNG_EXYNOS_MSHC, /* Exynos MMC controller */
+ COMPAT_SAMSUNG_EXYNOS_I2S, /* Exynos MMC controller */
+ COMPAT_SAMSUNG_PINCTRL, /* PINCTRL */
COMPAT_COUNT,
};
diff --git a/lib/fdtdec.c b/lib/fdtdec.c
index 3ae348d..88dd669 100644
--- a/lib/fdtdec.c
+++ b/lib/fdtdec.c
@@ -56,6 +56,10 @@ static const char * const compat_names[COMPAT_COUNT] = {
COMPAT(SAMSUNG_EXYNOS_EHCI, samsung,exynos-ehci),
COMPAT(SAMSUNG_EXYNOS_USB_PHY, samsung,exynos-usb-phy),
COMPAT(MAXIM_MAX77686_PMIC, maxim,max77686_pmic),
+ COMPAT(SAMSUNG_EXYNOS_UART, samsung,exynos-uart),
+ COMPAT(SAMSUNG_EXYNOS_MSHC, samsung,exynos-mshc),
+ COMPAT(SAMSUNG_EXYNOS_I2S, samsung,exynos-i2s),
+ COMPAT(SAMSUNG_PINCTRL, samsung,pinctrl),
Do these match the kernel names?
In kernel these are mentioned as samsung,exynos5250-dw-mshc
samsung,exynos4210-uart.
I wanted to keep it consistent with others like samsung,exynos-ehci,
samsung,exynos-spi etc.,
hence, made samsung,exynos-mshc samsung,exynos-uart. Shall I change it ?
};
Regards,
Akshay Saraswat
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v9 15/30] autoconfig.mk: Make it possible to define configs from other configs
Dear Wolfgang Denk, On Friday, March 8, 2013 6:25:19 AM, Wolfgang Denk wrote: Dear Marek Vasut, In message 201303080429.00780.ma...@denx.de you wrote: + # ... and from configs defined from other configs + s/=\(CONFIG_[A-Za-z0-9_][A-Za-z0-9_]*\)/=$(\1)/; Should we not remove the lower case letters here? Such are not supposed to be used in macro names. btw. CONFIG_[[:alnum:]_]\+ is shorter ;-) ...and has the same issue of including the unwanted lower case letters. Does it mean that you have also read my 2 messages and that you confirm that you absolutely want this change despite the exiting configs with lowercase letters? Best regards, Benoît ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2 v2] Exynos5: spl: Reduce clock init in spl
Hi simon, + Albert, Tom who might know about this Hi Akshay, On Wed, Mar 6, 2013 at 7:36 AM, Akshay Saraswat aksha...@samsung.com wrote: Hi Simon, Hi Akshay, On Tue, Mar 5, 2013 at 2:53 AM, Akshay Saraswat aksha...@samsung.com wrote: This patch subtracts a part of clock init from spl and executes it after relocation. spl_clock_init executes in spl and system_clock_init executes after relocation in u-boot. This is done to gain some space by removing initially not necessary code. Signed-off-by: Akshay Saraswat aksha...@samsung.com --- Looks good - just one question below. Changes since v1: - Rebased on ToT. board/samsung/smdk5250/Makefile | 3 +- board/samsung/smdk5250/clock_init.c | 429 + board/samsung/smdk5250/clock_init.h | 2 + board/samsung/smdk5250/lowlevel_init.S | 4 +- board/samsung/smdk5250/setup.h | 1 + board/samsung/smdk5250/smdk5250.c | 4 + board/samsung/smdk5250/spl_clock_init.c | 469 7 files changed, 482 insertions(+), 430 deletions(-) create mode 100644 board/samsung/smdk5250/spl_clock_init.c diff --git a/board/samsung/smdk5250/Makefile b/board/samsung/smdk5250/Makefile index 47c6a5a..3ceb7e2 100644 --- a/board/samsung/smdk5250/Makefile +++ b/board/samsung/smdk5250/Makefile @@ -26,12 +26,13 @@ LIB = $(obj)lib$(BOARD).o SOBJS := lowlevel_init.o -COBJS := clock_init.o +COBJS := spl_clock_init.o Shouldn't this only be included in the SPL build? I tried to do that but, since other files are using some of the data defined in this file, we need it in u-boot as well. Please tell me if it's required I'll make another file for common data. Are you saying that U-Boot proper is using the same data as SPL? I'm not sure, but I believe that we should not access SPL data from U-Boot, since they should be setting up separate things. Can you please be more specific about what is being shared? Sorry, misunderstood the compiler errors. Actually data is not shared in spl and u-boot, but in the Makefile if I keep all the spl related files in ifdef CONFIG_SPL_BUILD lowlevel_init.s is not able to find tzpc, dmc and clock init function definitions. And if I keep lowlevel init as well in ifdef CONFIG_SPL_BUILD, start.o is not able to find function definitions in lowlevel_init.s. In the next version of this patch-set, I'll fix it. COBJS += dmc_common.o dmc_init_ddr3.o COBJS += tzpc_init.o COBJS += smdk5250_spl.o ifndef CONFIG_SPL_BUILD +COBJS += clock_init.o COBJS += smdk5250.o endif ... Regards, Simon Regards, Akshay Saraswat ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v9 15/30] autoconfig.mk: Make it possible to define configs from other configs
Hi Marek, On Friday, March 8, 2013 4:29:00 AM, Marek Vasut wrote: Dear Wolfgang Denk, Dear Benoît Thébaudeau, In message 1362596377-5827-15-git-send-email-benoit.thebaud...@advansee.com you wrote: + # ... and from configs defined from other configs + s/=\(CONFIG_[A-Za-z0-9_][A-Za-z0-9_]*\)/=$(\1)/; Should we not remove the lower case letters here? Such are not supposed to be used in macro names. btw. CONFIG_[[:alnum:]_]\+ is shorter ;-) and less portable: see commit 02409f8. Best regards, Benoît ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 00/12] cmd_sf: Add support for read and write instructions
2013/3/5 Tom Rini tr...@ti.com: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/05/2013 01:34 PM, Jagan Teki wrote: Okay.. what I understand is - Currently, all the flash supported commands are provided to user as choice. what what i suppose to implement. He needs to choose the best option based on what the controller and chip connected supports. I guess your idea is to dynamically perform the fastest read/write command based on fastest command supported by controller and chip. I don't know how to support this. Dang, OK. Any update on this? Thanks, Michal -- Michal Simek, Ing. (M.Eng) w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/ Maintainer of Linux kernel - Xilinx Zynq ARM architecture Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/2 V2] EXYNOS5: Enable Gigabyte device GD25LQ and GD25Q64B
Dear Rajeshwari, On 23/01/13 15:30, Rajeshwari Shinde wrote: This patch set adds driver for Gigabyte device GD25LQ and GD25Q64B required for Snow board and enables same in config file. Based on following patches submitted by Simon Glass: sf: Add spi_flash_alloc() to create a new SPI flash struct sf: Use spi_flash_alloc() in each SPI flash driver Changes in V2: - Added U-Boot copyright header to gigadevice.c - Removed unnecessary blank lines. Rajeshwari Shinde (2): SF: Add driver for Gigabyte device GD25LQ and GD25Q64B SMDK5250: Enable SPI Gigabyte device. drivers/mtd/spi/Makefile |1 + drivers/mtd/spi/gigadevice.c | 81 ++ drivers/mtd/spi/spi_flash.c |3 + drivers/mtd/spi/spi_flash_internal.h |1 + include/configs/exynos5250-dt.h |1 + 5 files changed, 87 insertions(+), 0 deletions(-) create mode 100644 drivers/mtd/spi/gigadevice.c I've got compiler warning and error on this patch. gigadevice.c: In function 'spi_flash_probe_gigadevice': gigadevice.c:68:2: warning: implicit declaration of function 'spi_flash_alloc_base' [-Wimplicit-function-declaration] gigadevice.c:68:8: warning: assignment makes pointer from integer without a cast [enabled by default] drivers/mtd/spi/libspi_flash.o: In function `spi_flash_probe_gigadevice': /home/share/Work/u-boot-samsung/drivers/mtd/spi/gigadevice.c:68: undefined reference to `spi_flash_alloc_base' There is any dependency with other patches? then, please let me know. Thanks, Minkyu Kang. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/6 V4] EXYNOS5: Add audio support for Snow
On 15/02/13 14:46, Rajeshwari Shinde wrote: Driver for MAX98095 is added and support for same is incorporated in sound driver and Snow Board. This patchset is based on top of EXYNOS5: SNOW: Add initial dts and config file Changes in V2: - Corrected multi-line comment style Changes in V3: - Removed non DT support for MAX98095 - Config for both MAX98095 and WM8994 added in exynos5 config file. Changes in V4: - Separated the patches to create initial dts and config file for Snow - Modified XXTI clock source function as per Exynos naming convention Rajeshwari Shinde (6): EXYNOS5: Add function to enable XXTI clock source Sound: MAX98095: Add the driver for codec Sound: Support for MAX98095 codec in driver EXYNOS5: GPIO to enable MAX98095 EXYNOS5: FDT: Add compatible strings for MAX98095 config: Snow: Enable MAX98095 codec arch/arm/cpu/armv7/exynos/power.c| 17 + arch/arm/include/asm/arch-exynos/power.h | 11 + board/samsung/smdk5250/smdk5250.c| 15 + drivers/sound/Makefile |1 + drivers/sound/max98095.c | 550 ++ drivers/sound/max98095.h | 311 + drivers/sound/sound.c|9 +- include/configs/exynos5250-dt.h |1 + include/fdtdec.h |1 + include/sound.h |1 + lib/fdtdec.c |1 + 11 files changed, 916 insertions(+), 2 deletions(-) create mode 100644 drivers/sound/max98095.c create mode 100644 drivers/sound/max98095.h applied to u-boot-samsung. Thanks, Minkyu Kang. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mx28evk: Introduce a new target for saving env vars to NAND
On Thu, Mar 7, 2013 at 6:28 PM, Fabio Estevam fabio.este...@freescale.com wrote: Introduce 'mx28evk_nand' target for saving environment variables into NAND. The mx28evk board does not come with a NAND flash populated from the factory. It comes with an empty slot (U23), which allows the insertion of a 48-pin TSOP flash device. Tested with a K9LBG08U0D. Signed-off-by: Fabio Estevam fabio.este...@freescale.com Reviewed-by: Otavio Salvador ota...@ossystems.com.br -- Otavio Salvador O.S. Systems E-mail: ota...@ossystems.com.br http://www.ossystems.com.br Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v9 15/30] autoconfig.mk: Make it possible to define configs from other configs
Dear Wolfgang Denk, Dear Marek Vasut, In message 201303080429.00780.ma...@denx.de you wrote: + # ... and from configs defined from other configs + s/=\(CONFIG_[A-Za-z0-9_][A-Za-z0-9_]*\)/=$(\1)/; Should we not remove the lower case letters here? Such are not supposed to be used in macro names. btw. CONFIG_[[:alnum:]_]\+ is shorter ;-) ...and has the same issue of including the unwanted lower case letters. What about the CONFIG_8xx_* variables then ? :) Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v9 15/30] autoconfig.mk: Make it possible to define configs from other configs
Dear Benoît Thébaudeau, Hi Marek, On Friday, March 8, 2013 4:29:00 AM, Marek Vasut wrote: Dear Wolfgang Denk, Dear Benoît Thébaudeau, In message 1362596377-5827-15-git-send-email-benoit.thebaud...@advansee.com you wrote: + # ... and from configs defined from other configs + s/=\(CONFIG_[A-Za-z0-9_][A-Za-z0-9_]*\)/=$(\1)/; Should we not remove the lower case letters here? Such are not supposed to be used in macro names. btw. CONFIG_[[:alnum:]_]\+ is shorter ;-) and less portable: see commit 02409f8. $ echo -ne =CONFIG_FOO\n=CONFIG_Bar\n=CONFIG_bAz\n | sed s/=\(CONFIG_[[:alnum:]_]\+\)/=$(\1)/ -bash: 1: command not found =CONFIG_FOO =CONFIG_Bar =CONFIG_bAz $ uname -a FreeBSD foo.bar.baz 8.3-RELEASE-p6 FreeBSD 8.3-RELEASE-p6 #9: Tue Feb 26 17:05:09 CET 2013 f...@bar.baz.foo:/usr/obj/usr/src/sys/X amd64 I dont exactly understand the commit message, it works on this freebsd box. I won't go digging through the CVSes to find when it was added though ;-) Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v9 15/30] autoconfig.mk: Make it possible to define configs from other configs
Dear Marek, In message 201303081508.49239.ma...@denx.de you wrote: Should we not remove the lower case letters here? Such are not supposed to be used in macro names. btw. CONFIG_[[:alnum:]_]\+ is shorter ;-) ...and has the same issue of including the unwanted lower case letters. What about the CONFIG_8xx_* variables then ? :) Argh... well, actually these should be fixed. 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 mouse is an elephant built by the Japanese. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v9 15/30] autoconfig.mk: Make it possible to define configs from other configs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/08/2013 09:28 AM, Wolfgang Denk wrote: Dear Marek, In message 201303081508.49239.ma...@denx.de you wrote: Should we not remove the lower case letters here? Such are not supposed to be used in macro names. btw. CONFIG_[[:alnum:]_]\+ is shorter ;-) ...and has the same issue of including the unwanted lower case letters. What about the CONFIG_8xx_* variables then ? :) Argh... well, actually these should be fixed. I think the giant list from Benoit got lost. It's a HUGE thing to change. I think we should just accept that config variables are mixed case, or at least not block this patch on a very large unrelated fixup. - -- Tom -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJROfh5AAoJENk4IS6UOR1WnEkQALMU7vrooNXtIVBaWh6Hri3y wd+czZG+8u99c8qfos2VhMVIiFmO7aQWOw4qd3Isw1DI86MByG1FVzQrp3JSFCFV 79orvgFMbWKBKjZ9hKCgrWWy98ZEyZb6iRduOUfY9r1e1ZWbDz2TQQYpYi2HTt54 HOb3j6TV26VKtHX3oi+cRiNNBgmISFxixbxdy337++MSb/INn3mHNN3/WbB4VVFH E5u7dD7XEU2uhqmLP3sqO38RAakX7OojptXUUlfXlFaCEUvx/4QXCwXwkKD5FW96 zUXCYfcfoM3NggAzd0RHOSH2qtsBvVdR6NurcnnOM379ceGFM+MZUFYt1VYP1Jhq SZxLH/IV8QQ1t40q655aZBFdxOI1j3j5U0el/MTweEfi/2AXgBwgSDA0Qdn0cMfk Hsx8jhW2BdsA5KvOCCDY4fOpyAZM+A+Up5+WnqUAiVXe6YkSED6Rg5RTg4yUIJT6 lvuF8V/oONGlLnoiUQp/OyhfLvNDjbEv3+pVIvByyTfTVUXLhqUnBe3zvfre5um8 hGjMJhzv+Qo5SybPADKIFhWPdz8P5AfKqS3cTYH02ficYAFXkiK6YVKXNnYfo+2d n+WU8coJgMG5ayJGNul0lKxBfzn9ztZrX68D15SYs5MxL6cAHbKqQUbl++vaGHlO 5PCNuzBab+pvEgU1gX6X =e6TD -END PGP SIGNATURE- ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] mx28evk: Disable CONFIG_CMD_I2C
From: Fabio Estevam fabio.este...@freescale.com When loading a Freescale 2.6.35 on a mx28evk the following issue is seen: sgtl5000_hw_read: read reg error : Reg 0x00 Device with ID register 0 is not a SGTL5000 Disabling CONFIG_CMD_I2C makes the sgtl5000 probe to succeed. Mainline kernel does not show this problem. Until the real cause is not identified, disable 'CONFIG_CMD_I2C' for the time being. Signed-off-by: Fabio Estevam fabio.este...@freescale.com --- Stefano, Since 2013.04 is approaching I prefer to disable this option until the real cause is identified. This patch applies on top of http://patchwork.ozlabs.org/patch/225950/ include/configs/mx28evk.h |1 - 1 file changed, 1 deletion(-) diff --git a/include/configs/mx28evk.h b/include/configs/mx28evk.h index 9cc236f..cf93ec8 100644 --- a/include/configs/mx28evk.h +++ b/include/configs/mx28evk.h @@ -68,7 +68,6 @@ #define CONFIG_CMD_SPI #define CONFIG_CMD_USB #define CONFIG_CMD_BOOTZ -#define CONFIG_CMD_I2C #define CONFIG_CMD_NAND /* -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v9 15/30] autoconfig.mk: Make it possible to define configs from other configs
On Fri, Mar 8, 2013 at 11:40 AM, Tom Rini tr...@ti.com wrote: I think the giant list from Benoit got lost. It's a HUGE thing to change. I think we should just accept that config variables are mixed case, or at least not block this patch on a very large unrelated fixup. Agreed. Benoit's patch series contains 30 patches and it is at version 9. It would be better to treat this fixup seperately. Currently mx31pdk is broken in mainline and Benoit's series fixes it, so hopefully this can make into 2013.04. Regards, Fabio Estevam ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] dfu:mmc: When doing block operations, operate on the given length
On Thu, Mar 07, 2013 at 09:25:44AM -0500, Tom Rini wrote: When working on RAW partitions, it's possible that the whole area is larger than DDR. So what we need to do is make sure that the length we are given is aligned with the LBA block size, then pass that length in as our count of LBA blocks to operate on. In doing this, we no longer need to modify *len on read operations. Cc: Lukasz Majewski l.majew...@samsung.com Signed-off-by: Tom Rini tr...@ti.com As I dig at and fix the other problem (which Michael points out, 4MiB files crash), this patch is more for comment / confirmation that this change is fine on trats as well. These same concepts are part of my patch now that updates Pantelis' patch, without breaking file writes. -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v9 15/30] autoconfig.mk: Make it possible to define configs from other configs
Dear Tom Rini, In message 5139f87a.7000...@ti.com you wrote: What about the CONFIG_8xx_* variables then ? :) Argh... well, actually these should be fixed. I think the giant list from Benoit got lost. It's a HUGE thing to change. I think we should just accept that config variables are mixed case, or at least not block this patch on a very large unrelated fixup. That's fine with me. 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 good marriage would be between a blind wife and deaf husband. -- Michel de Montaigne ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] dfu:mmc: When doing block operations, operate on the given length
Hi Tom,
When working on RAW partitions, it's possible that the whole area
is larger than DDR. So what we need to do is make sure that the
length we are given is aligned with the LBA block size, then pass
that length in as our count of LBA blocks to operate on. In doing
this, we no longer need to modify *len on read operations.
Cc: Lukasz Majewski l.majew...@samsung.com
Signed-off-by: Tom Rini tr...@ti.com
---
drivers/dfu/dfu_mmc.c | 21 ++---
1 file changed, 14 insertions(+), 7 deletions(-)
diff --git a/drivers/dfu/dfu_mmc.c b/drivers/dfu/dfu_mmc.c
index 083d745..0bed405 100644
--- a/drivers/dfu/dfu_mmc.c
+++ b/drivers/dfu/dfu_mmc.c
@@ -34,14 +34,21 @@ static int mmc_block_op(enum dfu_mmc_op op,
struct dfu_entity *dfu, {
char cmd_buf[DFU_CMD_BUF_SIZE];
- sprintf(cmd_buf, mmc %s 0x%x %x %x,
- op == DFU_OP_READ ? read : write,
- (unsigned int) buf,
- dfu-data.mmc.lba_start,
- dfu-data.mmc.lba_size);
+ /*
+ * We must ensure that we read in lba_blk_size chunks, so
ALIGN
+ * this value.
+ */
+ *len = ALIGN(*len, dfu-data.mmc.lba_blk_size);
+
+ if (*len (dfu-data.mmc.lba_size *
dfu-data.mmc.lba_blk_size)) {
+ puts(Request would exceed designated area!\n);
+ return -EINVAL;
+ }
- if (op == DFU_OP_READ)
- *len = dfu-data.mmc.lba_blk_size *
dfu-data.mmc.lba_size;
+ sprintf(cmd_buf, mmc %s 0x%x %x %lx,
+ op == DFU_OP_READ ? read : write,
+ (unsigned int) buf, dfu-data.mmc.lba_start,
+ *len / dfu-data.mmc.lba_blk_size);
debug(%s: %s 0x%p\n, __func__, cmd_buf, cmd_buf);
return run_command(cmd_buf, 0);
Acked-by: Lukasz Majewski l.majew...@samsung.com
Tested-at: TRATS (Exynos4210)
Tested-by: Lukasz Majewski l.majew...@samsung.com
--
Best regards,
Lukasz Majewski
Samsung RD Poland (SRPOL) | Linux Platform Group
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/3 v3] ppc4xx: Add lcd4_lwmon5 support
This patch adds the fast booting LWMON5 derivat lcd4_lwmon5.
Its a stripped down version of the full blown lwmon5 support,
without ECC, USB, POST and some other stuff. It used the newly
introduced SPL infrastrucure for SPL from NOR flash booting
on the PPC4xx.
By setting the environment variable boot_os to yes, Linux
will be started from the SPL version. If not, the normal
U-Boot will be started.
Signed-off-by: Stefan Roese s...@denx.de
---
v3:
- Clear all soft-reset bits in the SRSTn registers in SPL. Otherwise
Linux will generate an floating point exception as the FPU is
still disabled.
v2:
- Call board_init_f() from spl_board_init(). This initializes
the PFC registers needed for example for working ethernet in Linux.
board/lwmon5/lwmon5.c| 75 ++--
board/lwmon5/sdram.c | 4 ++-
boards.cfg | 1 +
include/configs/lwmon5.h | 68 +--
4 files changed, 142 insertions(+), 6 deletions(-)
diff --git a/board/lwmon5/lwmon5.c b/board/lwmon5/lwmon5.c
index ecd9536..f7f64e7 100644
--- a/board/lwmon5/lwmon5.c
+++ b/board/lwmon5/lwmon5.c
@@ -1,5 +1,5 @@
/*
- * (C) Copyright 2007-2010
+ * (C) Copyright 2007-2013
* Stefan Roese, DENX Software Engineering, s...@denx.de.
*
* This program is free software; you can redistribute it and/or
@@ -200,9 +200,11 @@ int misc_init_r(void)
u32 pbcr;
int size_val = 0;
u32 reg;
+#ifndef CONFIG_LCD4_LWMON5
unsigned long usb2d0cr = 0;
unsigned long usb2phy0cr, usb2h0cr = 0;
unsigned long sdr0_pfc1, sdr0_srst;
+#endif
/*
* FLASH stuff...
@@ -233,6 +235,7 @@ int misc_init_r(void)
CONFIG_ENV_ADDR_REDUND + 2 * CONFIG_ENV_SECT_SIZE - 1,
flash_info[cfi_flash_num_flash_banks - 1]);
+#ifndef CONFIG_LCD4_LWMON5
/*
* USB suff...
*/
@@ -306,6 +309,7 @@ int misc_init_r(void)
/* 7. Reassert internal PHY reset: */
mtsdr(SDR0_SRST1, SDR0_SRST1_USB20PHY);
udelay(1000);
+#endif
/*
* Clear resets
@@ -313,7 +317,9 @@ int misc_init_r(void)
mtsdr(SDR0_SRST1, 0x);
mtsdr(SDR0_SRST0, 0x);
+#ifndef CONFIG_LCD4_LWMON5
printf(USB: Host(int phy) Device(ext phy)\n);
+#endif
/*
* Clear PLB4A0_ACR[WRP]
@@ -323,10 +329,12 @@ int misc_init_r(void)
reg = mfdcr(PLB4A0_ACR) ~PLB4Ax_ACR_WRP_MASK;
mtdcr(PLB4A0_ACR, reg);
+#ifndef CONFIG_LCD4_LWMON5
/*
* Init matrix keyboard
*/
misc_init_r_kbd();
+#endif
return 0;
}
@@ -336,7 +344,7 @@ int checkboard(void)
char buf[64];
int i = getenv_f(serial#, buf, sizeof(buf));
- puts(Board: lwmon5);
+ printf(Board: %s, __stringify(CONFIG_HOSTNAME));
if (i 0) {
puts(, serial# );
@@ -495,3 +503,66 @@ void board_reset(void)
{
gpio_write_bit(CONFIG_SYS_GPIO_BOARD_RESET, 1);
}
+
+#ifdef CONFIG_SPL_OS_BOOT
+/*
+ * lwmon5 specific implementation of spl_start_uboot()
+ *
+ * RETURN
+ * 0 if booting into OS is selected (default)
+ * 1 if booting into U-Boot is selected
+ */
+int spl_start_uboot(void)
+{
+ char s[8];
+
+ env_init();
+ getenv_f(boot_os, s, sizeof(s));
+ if ((s != NULL) (strcmp(s, yes) == 0))
+ return 0;
+
+ return 1;
+}
+
+/*
+ * This function is called from the SPL U-Boot version for
+ * early init stuff, that needs to be done for OS (e.g. Linux)
+ * booting. Doing it later in the real U-Boot would not work
+ * in case that the SPL U-Boot boots Linux directly.
+ */
+void spl_board_init(void)
+{
+ const gdc_regs *regs = board_get_regs();
+
+ /*
+* Setup PFC registers, mainly for ethernet support
+* later on in Linux
+*/
+ board_early_init_f();
+
+ /*
+* Clear resets
+*/
+ mtsdr(SDR0_SRST1, 0x);
+ mtsdr(SDR0_SRST0, 0x);
+
+ /*
+* Reset Lime controller
+*/
+ gpio_write_bit(CONFIG_SYS_GPIO_LIME_S, 1);
+ udelay(500);
+ gpio_write_bit(CONFIG_SYS_GPIO_LIME_RST, 1);
+
+ out_be32((void *)CONFIG_SYS_LIME_SDRAM_CLOCK, CONFIG_SYS_MB862xx_CCF);
+ udelay(300);
+ out_be32((void *)CONFIG_SYS_LIME_MMR, CONFIG_SYS_MB862xx_MMR);
+
+ while (regs-index) {
+ out_be32((void *)(CONFIG_SYS_LIME_BASE_0 + GC_DISP_BASE) +
+regs-index, regs-value);
+ regs++;
+ }
+
+ board_backlight_brightness(DEFAULT_BRIGHTNESS);
+}
+#endif
diff --git a/board/lwmon5/sdram.c b/board/lwmon5/sdram.c
index b64b35a..78b8fbc 100644
--- a/board/lwmon5/sdram.c
+++ b/board/lwmon5/sdram.c
@@ -6,7 +6,7 @@
* Alain Saurel, AMCC/IBM, alain.sau...@fr.ibm.com
* Robert Snyder, AMCC/IBM, rob.sny...@fr.ibm.com
*
- * (C) Copyright 2007-2008
+ * (C) Copyright 2007-2013
Re: [U-Boot] Beginners Questions on modding a NAS
Hi Mike, Sorry, I am partly off-topic. but since cross compiling and uboot images are still close to uboot, i'll stay here. Am 05.03.2013 21:30, schrieb Michael Cashwell: On Mar 5, 2013, at 2:25 PM, JPT j-...@gmx.net wrote: *** Next step, booting from disk ... this works, but the kernel doesn't know where to find the root partition. how do I have to pass the root= parameter to linux kernel? this didn't work: set bootargs console=ttyS0,115200 root=/dev/sda1 bootargs is how you pass arguments to the kernel, so you're on track there. The trick is what to pass. Your root= item is in the right direction. But the kernel needs to be configured appropriately. By that I'm talking about things like what bus (ATA, SATA, USB, etc.), what partitioning (MBR, GUID, MTD, etc.) and what file system (FAT*, ext2/3/4, etc.) the root fs will have. You have to have the supporting kernel configs enabled for those things. If I boot using the initrd, the USB drive is /dev/sda1 Since it's the same kernel, I guessed I have to use /dev/sda1 as well. You also need /dev to be setup early or the root argument will hit a dead end. I use these often: CONFIG_DEVTMPFS=y CONFIG_DEVTMPFS_MOUNT=y I am rather sure missing DEVTMPFS is the problem. after hours and days of searching I found out: DEVTMPFS is not available in kernel 2.6.31.*, it's included from 2.6.34 on. Way 1: Upgrade to longterm kernel 2.6.34.14 A) build kernel Tries to crosscompile but fails: arm-mv5sft-linux-gnueabi-gcc: not found did hardly find anything on this file in the internet. Since I haven't got any experience with crosscompiling, I set up a ARM machine in QEMU... but it still tries to crosscompile, same error. B) patch new kernal with duov2 patches. boy, its a 20 MB patchfile! a lot of patches failed. I don't believe this is going to work! Way 2: Patch original kernel with DEVTMPFS. No idea, did not try yet. where do I get a patch from? Still need a way to compile the kernel. Way 3: Create a new uboot initrd.img is there any way to unpack the original image into it's pieces? Would be far easier to just exchange those parts that have to be changed. Way 4: see below. Or do I have to boot the real system after booting from initrd? You need to decide that. How do I boot linux from linux? could you give a keyword to search for? thanks, Jan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] Tegra: All Tamonten-derived boards use onboard NAND
On Mon, Mar 4, 2013 at 4:39 PM, Stephen Warren swar...@wwwdotorg.org wrote: On 03/04/2013 04:26 PM, Tom Warren wrote: Thierry, On Mon, Mar 4, 2013 at 3:41 PM, Thierry Reding thierry.red...@avionic-design.de wrote: On Mon, Mar 04, 2013 at 01:46:48PM -0700, Tom Warren wrote: [...] I kinda lost track of this patchset. I'd like to move it into u-boot-tegra/next if you think it's ready, but I'm not sure if it conflicts with/works with Stephen's 4th patch of his v2 series (ARM: tegra: enable a common set of disk-related commands). I can rebase my patches on top of Stephen's work and resend them if it helps. Thierry The only problem I see is that Stephen's patchset isn't exclusively Tegra-based, so I'm not sure I want to bring it into the Tegra tree and cause problems when I do a PR. The other half of the patchset is assigned to Tom Rini. Stephen - how would you like me to resolve this? Hmmm. Thierry's patch series does quite a few things at once. I'd suggest that Thierry posts a series that /just/ enables NAND support. It should be possible to apply that on its own without any conflicts/dependencies on my series. Enabling FIT could also be a separate series without any conflicts/dependencies. A lot of the rest of that series is effectively part of my series, since I ended up enabling all those new options in the various common Tegra config files in my series. The only thing left over is the removal of the custom definition of CONFIG_BOOTCOMMAND in the AD headers. That should happen after my series. Re: How to get my series into Tegra's tree. I think it'd be fine to apply my series to the Tegra tree even though it touches disk/partition code if you can get the/a maintainer for that code to ack it. Probably someone like Tom Rini. That way, Thierry's CONFIG_BOOTCOMMAND changes wouldn't have to wait long I hope. Sorry, kinda dropped the ball on this while I was working on the padcfg changes. Tom Rini - do you agree with Stephen's approach for the disk parts of his patchset? If so, I can apply it to u-boot-tegra/next today push. Thierry - assuming the above happens, can you rework/split your patchset as Stephen outlines above? Then I can apply your patches push and we'll be ready for a PR early next week after some testing/MAKEALL/etc. Thanks, Tom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] Tegra: All Tamonten-derived boards use onboard NAND
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/08/2013 11:36 AM, Tom Warren wrote: On Mon, Mar 4, 2013 at 4:39 PM, Stephen Warren swar...@wwwdotorg.org wrote: On 03/04/2013 04:26 PM, Tom Warren wrote: Thierry, On Mon, Mar 4, 2013 at 3:41 PM, Thierry Reding thierry.red...@avionic-design.de wrote: On Mon, Mar 04, 2013 at 01:46:48PM -0700, Tom Warren wrote: [...] I kinda lost track of this patchset. I'd like to move it into u-boot-tegra/next if you think it's ready, but I'm not sure if it conflicts with/works with Stephen's 4th patch of his v2 series (ARM: tegra: enable a common set of disk-related commands). I can rebase my patches on top of Stephen's work and resend them if it helps. Thierry The only problem I see is that Stephen's patchset isn't exclusively Tegra-based, so I'm not sure I want to bring it into the Tegra tree and cause problems when I do a PR. The other half of the patchset is assigned to Tom Rini. Stephen - how would you like me to resolve this? Hmmm. Thierry's patch series does quite a few things at once. I'd suggest that Thierry posts a series that /just/ enables NAND support. It should be possible to apply that on its own without any conflicts/dependencies on my series. Enabling FIT could also be a separate series without any conflicts/dependencies. A lot of the rest of that series is effectively part of my series, since I ended up enabling all those new options in the various common Tegra config files in my series. The only thing left over is the removal of the custom definition of CONFIG_BOOTCOMMAND in the AD headers. That should happen after my series. Re: How to get my series into Tegra's tree. I think it'd be fine to apply my series to the Tegra tree even though it touches disk/partition code if you can get the/a maintainer for that code to ack it. Probably someone like Tom Rini. That way, Thierry's CONFIG_BOOTCOMMAND changes wouldn't have to wait long I hope. Sorry, kinda dropped the ball on this while I was working on the padcfg changes. Tom Rini - do you agree with Stephen's approach for the disk parts of his patchset? If so, I can apply it to u-boot-tegra/next today push. Can you give me some patchwork links? I'm getting going on another round of pulling things into master today. Thanks! - -- Tom -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJROhV4AAoJENk4IS6UOR1WgboP/iZFuJFTOf9lLyR38dNHk66p 7h/wexQRQr7CIMYUwHsS55IStunXNif4Njm9u6ehNbjz45v0vpIVUlV37NjhFG82 3XwTRLvt1w9Aag6h8jB/We+Z73rArhHfpq3dbB5FuyX4n+J3Dq+7sRp7kZkRu7gS skSzcAE5b0eMB6OiPwuG0zkVkMaf0ryYZAzjsRvXgT9302YSigHdM0TnZColzcLt LQREK58EiQiO20DGuTYIyRUzEG9MlSiv9J7GOLbtgdEbXES/P/v40lybvPwtNdre q3UmPrDRCMJ2eqtyVZbTRLEAxN9vUhd11cfDBb2HOSsFTilJkpu1GBaR80nmca3p HgyeHvZnABQ/rvAVRPHP54UT+iXF531Z3CRUF5vQcT0N/JHH1LuyHVuij23b5Fxt LcM51YNijmFkisZVTxgX4mrFNpGmSvP+4jEky+t6Vz26uZ8YYfa26Lwlby6EFrKy Nz8QduohPsuSi92QQjSb5LJn86QxFNwz+20UjXPLilQRet/W5WosGJqdUKdH1aun tkZlUZw7mtu9lIEqJJq4JpNKYP7NoMmDygyob0v+VCUPshqKig6Xs3voQMaAC44i 90OBzokS/Vj/AYJQ7eXwpVsdYkrPc5UXBU70/5QMftEVDR6wk0cLHou18F3wYeQd HpIFPnhpM0/7rMKXchV3 =FTH6 -END PGP SIGNATURE- ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] Tegra: All Tamonten-derived boards use onboard NAND
Tom On Fri, Mar 8, 2013 at 9:44 AM, Tom Rini tr...@ti.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/08/2013 11:36 AM, Tom Warren wrote: On Mon, Mar 4, 2013 at 4:39 PM, Stephen Warren swar...@wwwdotorg.org wrote: On 03/04/2013 04:26 PM, Tom Warren wrote: Thierry, On Mon, Mar 4, 2013 at 3:41 PM, Thierry Reding thierry.red...@avionic-design.de wrote: On Mon, Mar 04, 2013 at 01:46:48PM -0700, Tom Warren wrote: [...] I kinda lost track of this patchset. I'd like to move it into u-boot-tegra/next if you think it's ready, but I'm not sure if it conflicts with/works with Stephen's 4th patch of his v2 series (ARM: tegra: enable a common set of disk-related commands). I can rebase my patches on top of Stephen's work and resend them if it helps. Thierry The only problem I see is that Stephen's patchset isn't exclusively Tegra-based, so I'm not sure I want to bring it into the Tegra tree and cause problems when I do a PR. The other half of the patchset is assigned to Tom Rini. Stephen - how would you like me to resolve this? Hmmm. Thierry's patch series does quite a few things at once. I'd suggest that Thierry posts a series that /just/ enables NAND support. It should be possible to apply that on its own without any conflicts/dependencies on my series. Enabling FIT could also be a separate series without any conflicts/dependencies. A lot of the rest of that series is effectively part of my series, since I ended up enabling all those new options in the various common Tegra config files in my series. The only thing left over is the removal of the custom definition of CONFIG_BOOTCOMMAND in the AD headers. That should happen after my series. Re: How to get my series into Tegra's tree. I think it'd be fine to apply my series to the Tegra tree even though it touches disk/partition code if you can get the/a maintainer for that code to ack it. Probably someone like Tom Rini. That way, Thierry's CONFIG_BOOTCOMMAND changes wouldn't have to wait long I hope. Sorry, kinda dropped the ball on this while I was working on the padcfg changes. Tom Rini - do you agree with Stephen's approach for the disk parts of his patchset? If so, I can apply it to u-boot-tegra/next today push. Can you give me some patchwork links? I'm getting going on another round of pulling things into master today. Thanks! - -- Tom Sure: http://patchwork.ozlabs.org/patch/224204/ http://patchwork.ozlabs.org/patch/224205/ http://patchwork.ozlabs.org/patch/224206/ http://patchwork.ozlabs.org/patch/224207/ 204/205 are assigned to you; 206/207 to me. Tom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 3/4] disk: define HAVE_BLOCK_DEVICE if CONFIG_CMD_PART
On Thu, Feb 28, 2013 at 06:03:47PM -0700, Stephen Warren wrote: From: Stephen Warren swar...@nvidia.com Various code that is conditional upon HAVE_BLOCK_DEVICE is required by code conditional upon CONFIG_CMD_PART. So, enable HAVE_BLOCK_DEVICE if CONFIG_CMD_PART is enabled. Signed-off-by: Stephen Warren swar...@nvidia.com Acked-by: Tom Rini tr...@ti.com -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 2/4] disk: define HAVE_BLOCK_DEVICE in a common place
On Thu, Feb 28, 2013 at 06:03:46PM -0700, Stephen Warren wrote: From: Stephen Warren swar...@nvidia.com This set of ifdefs is used in a number of places. Move its definition somewhere common so it doesn't have to be repeated. Signed-off-by: Stephen Warren swar...@nvidia.com Acked-by: Tom Rini tr...@ti.com -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] Tegra: All Tamonten-derived boards use onboard NAND
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/08/2013 11:48 AM, Tom Warren wrote: On Fri, Mar 8, 2013 at 9:44 AM, Tom Rini tr...@ti.com wrote: On 03/08/2013 11:36 AM, Tom Warren wrote: On Mon, Mar 4, 2013 at 4:39 PM, Stephen Warren swar...@wwwdotorg.org wrote: On 03/04/2013 04:26 PM, Tom Warren wrote: Thierry, On Mon, Mar 4, 2013 at 3:41 PM, Thierry Reding thierry.red...@avionic-design.de wrote: On Mon, Mar 04, 2013 at 01:46:48PM -0700, Tom Warren wrote: [...] I kinda lost track of this patchset. I'd like to move it into u-boot-tegra/next if you think it's ready, but I'm not sure if it conflicts with/works with Stephen's 4th patch of his v2 series (ARM: tegra: enable a common set of disk-related commands). I can rebase my patches on top of Stephen's work and resend them if it helps. Thierry The only problem I see is that Stephen's patchset isn't exclusively Tegra-based, so I'm not sure I want to bring it into the Tegra tree and cause problems when I do a PR. The other half of the patchset is assigned to Tom Rini. Stephen - how would you like me to resolve this? Hmmm. Thierry's patch series does quite a few things at once. I'd suggest that Thierry posts a series that /just/ enables NAND support. It should be possible to apply that on its own without any conflicts/dependencies on my series. Enabling FIT could also be a separate series without any conflicts/dependencies. A lot of the rest of that series is effectively part of my series, since I ended up enabling all those new options in the various common Tegra config files in my series. The only thing left over is the removal of the custom definition of CONFIG_BOOTCOMMAND in the AD headers. That should happen after my series. Re: How to get my series into Tegra's tree. I think it'd be fine to apply my series to the Tegra tree even though it touches disk/partition code if you can get the/a maintainer for that code to ack it. Probably someone like Tom Rini. That way, Thierry's CONFIG_BOOTCOMMAND changes wouldn't have to wait long I hope. Sorry, kinda dropped the ball on this while I was working on the padcfg changes. Tom Rini - do you agree with Stephen's approach for the disk parts of his patchset? If so, I can apply it to u-boot-tegra/next today push. Can you give me some patchwork links? I'm getting going on another round of pulling things into master today. Thanks! Sure: http://patchwork.ozlabs.org/patch/224204/ http://patchwork.ozlabs.org/patch/224205/ http://patchwork.ozlabs.org/patch/224206/ http://patchwork.ozlabs.org/patch/224207/ 204/205 are assigned to you; 206/207 to me. OK, ack'd, lets move them along the tegra tree since that's where they're really used. - -- Tom -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJROhiQAAoJENk4IS6UOR1Wr50P/RIsDFVP62XXxKOfcpQtAUYX 7QHGLX1+qS58pAFRwclIxs64VzIm2dT5xDplzilABJH8BTE6MnUyKqkKbeP4M8pR dtwsVROHK8QdI09bZWN3sBn8B9derkLlsg58lzK8YooeOHJznQhdCxNXEa99/5HJ WLVx7buxUyMYQINyFQH83pCm9e67R/k7KYmr+D3yyvLLpxSyJI++1BpgRDzNhG74 DHacV6gBqD+bMBS62TTtfxGBOHXZgfrSxxuooFHJa8kJef73xt6LKOWwY6KV/eVj cbk6utg7kiSr50AknVwatIZ+aig/uBuXmoLs6IRIkrgn9fVj4yYmmiLcdgfbqgdU mZSE//EW9xQ2mL6qQDEFOOdqrZ2xs9ipf59LqAzKloh41SAWzpxrr2KSp5jpz7rX mjpMPUMZ7lsWNET8x+1rj22MnFWXtfl3EAHTF3WX1FdvWbm63MRLRYmGEf3LzdXW NuA5vpbQEgjnabwg6IGWcxGtPFKCChePThZ3lsK9DT/ozn4pmlvQMzFGL7PHZjX7 ZJcSW/mHTR5HxZC5P7+sgVbGPpwnuUT/Hia/j0kkM+cyCVaqRka649+fIM3Ozrgh yvpqPu2R6JhbwGECmW6AusFGx8Vi/XXC70XfryymGGJB8tDU/6h0HogYYB9PS21e yxBeqziVVusJSwPqn6E1 =d+6W -END PGP SIGNATURE- ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] Tegra: All Tamonten-derived boards use onboard NAND
On Fri, Mar 8, 2013 at 9:57 AM, Tom Rini tr...@ti.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/08/2013 11:48 AM, Tom Warren wrote: On Fri, Mar 8, 2013 at 9:44 AM, Tom Rini tr...@ti.com wrote: On 03/08/2013 11:36 AM, Tom Warren wrote: On Mon, Mar 4, 2013 at 4:39 PM, Stephen Warren swar...@wwwdotorg.org wrote: On 03/04/2013 04:26 PM, Tom Warren wrote: Thierry, On Mon, Mar 4, 2013 at 3:41 PM, Thierry Reding thierry.red...@avionic-design.de wrote: On Mon, Mar 04, 2013 at 01:46:48PM -0700, Tom Warren wrote: [...] I kinda lost track of this patchset. I'd like to move it into u-boot-tegra/next if you think it's ready, but I'm not sure if it conflicts with/works with Stephen's 4th patch of his v2 series (ARM: tegra: enable a common set of disk-related commands). I can rebase my patches on top of Stephen's work and resend them if it helps. Thierry The only problem I see is that Stephen's patchset isn't exclusively Tegra-based, so I'm not sure I want to bring it into the Tegra tree and cause problems when I do a PR. The other half of the patchset is assigned to Tom Rini. Stephen - how would you like me to resolve this? Hmmm. Thierry's patch series does quite a few things at once. I'd suggest that Thierry posts a series that /just/ enables NAND support. It should be possible to apply that on its own without any conflicts/dependencies on my series. Enabling FIT could also be a separate series without any conflicts/dependencies. A lot of the rest of that series is effectively part of my series, since I ended up enabling all those new options in the various common Tegra config files in my series. The only thing left over is the removal of the custom definition of CONFIG_BOOTCOMMAND in the AD headers. That should happen after my series. Re: How to get my series into Tegra's tree. I think it'd be fine to apply my series to the Tegra tree even though it touches disk/partition code if you can get the/a maintainer for that code to ack it. Probably someone like Tom Rini. That way, Thierry's CONFIG_BOOTCOMMAND changes wouldn't have to wait long I hope. Sorry, kinda dropped the ball on this while I was working on the padcfg changes. Tom Rini - do you agree with Stephen's approach for the disk parts of his patchset? If so, I can apply it to u-boot-tegra/next today push. Can you give me some patchwork links? I'm getting going on another round of pulling things into master today. Thanks! Sure: http://patchwork.ozlabs.org/patch/224204/ http://patchwork.ozlabs.org/patch/224205/ http://patchwork.ozlabs.org/patch/224206/ http://patchwork.ozlabs.org/patch/224207/ 204/205 are assigned to you; 206/207 to me. OK, ack'd, lets move them along the tegra tree since that's where they're really used. - -- Tom Will do - thanks. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] Tegra: All Tamonten-derived boards use onboard NAND
Thierry, On Fri, Mar 8, 2013 at 9:58 AM, Tom Warren twarren.nvi...@gmail.com wrote: On Fri, Mar 8, 2013 at 9:57 AM, Tom Rini tr...@ti.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/08/2013 11:48 AM, Tom Warren wrote: On Fri, Mar 8, 2013 at 9:44 AM, Tom Rini tr...@ti.com wrote: On 03/08/2013 11:36 AM, Tom Warren wrote: On Mon, Mar 4, 2013 at 4:39 PM, Stephen Warren swar...@wwwdotorg.org wrote: On 03/04/2013 04:26 PM, Tom Warren wrote: Thierry, On Mon, Mar 4, 2013 at 3:41 PM, Thierry Reding thierry.red...@avionic-design.de wrote: On Mon, Mar 04, 2013 at 01:46:48PM -0700, Tom Warren wrote: [...] I kinda lost track of this patchset. I'd like to move it into u-boot-tegra/next if you think it's ready, but I'm not sure if it conflicts with/works with Stephen's 4th patch of his v2 series (ARM: tegra: enable a common set of disk-related commands). I can rebase my patches on top of Stephen's work and resend them if it helps. Thierry The only problem I see is that Stephen's patchset isn't exclusively Tegra-based, so I'm not sure I want to bring it into the Tegra tree and cause problems when I do a PR. The other half of the patchset is assigned to Tom Rini. Stephen - how would you like me to resolve this? Hmmm. Thierry's patch series does quite a few things at once. I'd suggest that Thierry posts a series that /just/ enables NAND support. It should be possible to apply that on its own without any conflicts/dependencies on my series. Enabling FIT could also be a separate series without any conflicts/dependencies. A lot of the rest of that series is effectively part of my series, since I ended up enabling all those new options in the various common Tegra config files in my series. The only thing left over is the removal of the custom definition of CONFIG_BOOTCOMMAND in the AD headers. That should happen after my series. Re: How to get my series into Tegra's tree. I think it'd be fine to apply my series to the Tegra tree even though it touches disk/partition code if you can get the/a maintainer for that code to ack it. Probably someone like Tom Rini. That way, Thierry's CONFIG_BOOTCOMMAND changes wouldn't have to wait long I hope. Sorry, kinda dropped the ball on this while I was working on the padcfg changes. Tom Rini - do you agree with Stephen's approach for the disk parts of his patchset? If so, I can apply it to u-boot-tegra/next today push. Can you give me some patchwork links? I'm getting going on another round of pulling things into master today. Thanks! Sure: http://patchwork.ozlabs.org/patch/224204/ http://patchwork.ozlabs.org/patch/224205/ http://patchwork.ozlabs.org/patch/224206/ http://patchwork.ozlabs.org/patch/224207/ 204/205 are assigned to you; 206/207 to me. OK, ack'd, lets move them along the tegra tree since that's where they're really used. - -- Tom Will do - thanks. I've applied Stephen's patchset to u-boot-tegra/next (on top of my padcfg/ctrl patchset and the T30 MMC patchset). PTAL and either send me new discrete patches as Stephen outlined, or let me know how to apply your patchset individually w/current /next TOT. Thanks, Tom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v5 1/9] README: Document current DFU CONFIG options
Add documentation for the current DFU config options. DFU is a standard USB device class so more information is available from usb.org Signed-off-by: Tom Rini tr...@ti.com --- Changes in v5: - New patch to document existing DFU CONFIG options Changes in v4: None Changes in v3: None Changes in v2: None README | 13 + 1 file changed, 13 insertions(+) diff --git a/README b/README index 42544ce..900ae5f 100644 --- a/README +++ b/README @@ -1325,6 +1325,19 @@ The following options need to be configured: CONFIG_SH_MMCIF_CLK Define the clock frequency for MMCIF +- USB Device Firmware Update (DFU) class support: + CONFIG_DFU_FUNCTION + This enables the USB portion of the DFU USB class + + CONFIG_CMD_DFU + This enables the command dfu which is used to have + U-Boot create a DFU class device via USB. This command + requires that the dfu_alt_info environment variable be + set and define the alt settings to expose to the host. + + CONFIG_DFU_MMC + This enables support for exposing (e)MMC devices via DFU. + - Journaling Flash filesystem support: CONFIG_JFFS2_NAND, CONFIG_JFFS2_NAND_OFF, CONFIG_JFFS2_NAND_SIZE, CONFIG_JFFS2_NAND_DEV -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v5 0/9] Improve DFU support, enable for am335x_evm
This series does a few things. I've updated Pantelis Antoniou's patch
that allows for transfering of files larger than 4MiB to still allow for
filesystem writes to work. I also document the existing DFU CONFIG
options, and then the new options this series adds. Then we update
nand_(read|write)_skip_bad so that we can add DFU support for NAND
(started by Pantelis). Finally, we enable all of this for am335x_evm.
This series has been compile-tested on all ARM and PowerPC targets and
run-time tested on am335x_evm for NAND and MMC and eMMC.
This series depends on u-boot-usb/master but with a09f955 removed (as we
replace that patch here).
--
Tom
Changes in v5:
- New patch to document existing DFU CONFIG options
- Rework Pantelis' dfu: Support larger than memory transfers to not
break filesystem writing
- New patch to re-align defines in dfu.h
- Document CONFIG_DFU_NAND in README
- Add RAW MMC examples to include/configs/am335x_evm.h
Changes in v4:
- Further reword nand_util.c comments, from Scott
- In nand_write_skip_bad make sure *actual is 0 for YAFFS2 errors too,
reminded by Scott.
- In cmd_nand.c don't drop the size is less than maxsize check in
arg_off_size as other nand functions need this still (Scott).
- Add patch to fix CONFIG_CMD_NAND_YAFFS
Changes in v3:
- Reworked skip_check_len changes to just add accounting for *used to
the logic.
- Allow for actual to be NULL in nand_(read|write)_skip_bad, only DFU
calls this with a non-NULL parameter. Make sure the comments for both
functions explain the parameters and their behavior.
- Other style changes requested by Scott.
- As nand_(write|read)_skip_bad passes back just a used length now.
- Rework logic in nand_block_op for nand_(read|write)_skip_bad returning
just a size for actual used length.
- Remove unused externs from drivers/dfu/dfu_nand.c
- Fix checkpatch.pl warnings in include/configs/am335x_evm.h
Changes in v2:
- NAND skip_check_len changes reworked to allow
nand_(read|write)_skip_bad to return this information to the caller.
- nand_block_op calls nand_(read|write)_skip_bad directly.
- Bugfix in dfu_nand to make sure we set dfu-skip_bad to 0 on each
iteration.
- Add CONFIG_CMD_MTDPARTS and relevant information to am335x_evm
- Enable DFU for NAND and MMC, set dfu_alt_info_(nand|mmc) as examples
for both in am335x_evm.h
- Increase CONFIG_SYS_MAXARGS due to hush parsing bugs that would
otherwise prevent 'setenv dfu_alt_info ${dfu_alt_info_nand}' on
am335x_evm
Pantelis Antoniou (4):
dfu: Support larger than memory transfers.
dfu: NAND specific routines for DFU operation
am335x_evm: Define CONFIG_SYS_CACHELINE_SIZE
am335x_evm: Enable DFU for NAND and MMC, provide example alt_infos
Tom Rini (5):
README: Document current DFU CONFIG options
dfu: Change indentation of defines in dfu.h
nand: Extend nand_(read|write)_skip_bad with *actual and limit
parameters
cmd_nand.c: Fix CONFIG_CMD_NAND_YAFFS
am335x_evm: Add CONFIG_CMD_MTDPARTS and relevant defaults
README | 23
common/cmd_nand.c| 55 +
common/env_nand.c|3 +-
drivers/dfu/Makefile |1 +
drivers/dfu/dfu.c| 251 +-
drivers/dfu/dfu_mmc.c| 116 ++-
drivers/dfu/dfu_nand.c | 195
drivers/mtd/nand/nand_util.c | 68 ++--
include/configs/am335x_evm.h | 52 -
include/dfu.h| 53 -
include/nand.h |4 +-
11 files changed, 700 insertions(+), 121 deletions(-)
create mode 100644 drivers/dfu/dfu_nand.c
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v5 3/9] dfu: Change indentation of defines in dfu.h
Signed-off-by: Tom Rini tr...@ti.com --- Changes in v5: - New patch to re-align defines in dfu.h Changes in v4: None Changes in v3: None Changes in v2: None include/dfu.h |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/include/dfu.h b/include/dfu.h index 5182c6c..0aae856 100644 --- a/include/dfu.h +++ b/include/dfu.h @@ -57,8 +57,8 @@ static inline unsigned int get_mmc_blk_size(int dev) return find_mmc_device(dev)-read_bl_len; } -#define DFU_NAME_SIZE 32 -#define DFU_CMD_BUF_SIZE 128 +#define DFU_NAME_SIZE 32 +#define DFU_CMD_BUF_SIZE 128 #define DFU_DATA_BUF_SIZE (64 10) /* 64 KiB */ #ifndef CONFIG_SYS_DFU_MAX_FILE_SIZE #define CONFIG_SYS_DFU_MAX_FILE_SIZE (4 20) /* 4 MiB */ -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v5 2/9] dfu: Support larger than memory transfers.
From: Pantelis Antoniou pa...@antoniou-consulting.com
Previously we didn't support upload/download larger than available
memory. This is pretty bad when you have to update your root filesystem
for example.
This patch removes that limitation (and the crashes when you transfered
any file larger than 4MB) by making raw image writes be done in chunks
and making file maximum size be configurable.
The sequence number is a 16 bit counter; make sure we handle rollover
correctly. This fixes the wrong transfers for large ( 256MB) images.
Also utilize a variable to handle initialization, so that we don't rely
on just the counter sent by the host.
Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com
Signed-off-by: Tom Rini tr...@ti.com
---
Changes in v5:
- Rework Pantelis' dfu: Support larger than memory transfers to not
break filesystem writing
Changes in v4: None
Changes in v3: None
Changes in v2: None
README|7 ++
drivers/dfu/dfu.c | 245 ++---
drivers/dfu/dfu_mmc.c | 116 +--
include/dfu.h | 26 +-
4 files changed, 310 insertions(+), 84 deletions(-)
diff --git a/README b/README
index 900ae5f..154b82f 100644
--- a/README
+++ b/README
@@ -1338,6 +1338,13 @@ The following options need to be configured:
CONFIG_DFU_MMC
This enables support for exposing (e)MMC devices via DFU.
+ CONFIG_SYS_DFU_MAX_FILE_SIZE
+ When updating files rather than the raw storage device,
+ we use a static buffer to copy the file into and then write
+ the buffer once we've been given the whole file. Define
+ this to the maximum filesize (in bytes) for the buffer.
+ Default is 4 MiB if undefined.
+
- Journaling Flash filesystem support:
CONFIG_JFFS2_NAND, CONFIG_JFFS2_NAND_OFF,
CONFIG_JFFS2_NAND_SIZE,
CONFIG_JFFS2_NAND_DEV
diff --git a/drivers/dfu/dfu.c b/drivers/dfu/dfu.c
index e8477fb..2fecf77 100644
--- a/drivers/dfu/dfu.c
+++ b/drivers/dfu/dfu.c
@@ -44,90 +44,229 @@ static int dfu_find_alt_num(const char *s)
static unsigned char __aligned(CONFIG_SYS_CACHELINE_SIZE)
dfu_buf[DFU_DATA_BUF_SIZE];
+static int dfu_write_buffer_drain(struct dfu_entity *dfu)
+{
+ long w_size;
+ int ret;
+
+ /* flush size? */
+ w_size = dfu-i_buf - dfu-i_buf_start;
+ if (w_size == 0)
+ return 0;
+
+ /* update CRC32 */
+ dfu-crc = crc32(dfu-crc, dfu-i_buf_start, w_size);
+
+ ret = dfu-write_medium(dfu, dfu-offset, dfu-i_buf_start, w_size);
+ if (ret)
+ debug(%s: Write error!\n, __func__);
+
+ /* point back */
+ dfu-i_buf = dfu-i_buf_start;
+
+ /* update offset */
+ dfu-offset += w_size;
+
+ puts(#);
+
+ return ret;
+}
+
int dfu_write(struct dfu_entity *dfu, void *buf, int size, int blk_seq_num)
{
- static unsigned char *i_buf;
- static int i_blk_seq_num;
- long w_size = 0;
int ret = 0;
+ int tret;
+
+ debug(%s: name: %s buf: 0x%p size: 0x%x p_num: 0x%x
+ offset: 0x%llx bufoffset: 0x%x\n,
+ __func__, dfu-name, buf, size, blk_seq_num, dfu-offset,
+ dfu-i_buf - dfu-i_buf_start);
+
+ if (!dfu-inited) {
+ /* initial state */
+ dfu-crc = 0;
+ dfu-offset = 0;
+ dfu-i_blk_seq_num = 0;
+ dfu-i_buf_start = dfu_buf;
+ dfu-i_buf_end = dfu_buf + sizeof(dfu_buf);
+ dfu-i_buf = dfu-i_buf_start;
+
+ dfu-inited = 1;
+ }
- debug(%s: name: %s buf: 0x%p size: 0x%x p_num: 0x%x i_buf: 0x%p\n,
- __func__, dfu-name, buf, size, blk_seq_num, i_buf);
+ if (dfu-i_blk_seq_num != blk_seq_num) {
+ printf(%s: Wrong sequence number! [%d] [%d]\n,
+ __func__, dfu-i_blk_seq_num, blk_seq_num);
+ return -1;
+ }
- if (blk_seq_num == 0) {
- i_buf = dfu_buf;
- i_blk_seq_num = 0;
+ /* DFU 1.1 standard says:
+* The wBlockNum field is a block sequence number. It increments each
+* time a block is transferred, wrapping to zero from 65,535. It is used
+* to provide useful context to the DFU loader in the device.
+*
+* This means that it's a 16 bit counter that roll-overs at
+* 0x - 0x. By having a typical 4K transfer block
+* we roll-over at exactly 256MB. Not very fun to debug.
+*
+* Handling rollover, and having an inited variable,
+* makes things work.
+*/
+
+ /* handle rollover */
+ dfu-i_blk_seq_num = (dfu-i_blk_seq_num + 1) 0x;
+
+ /* flush buffer if overflow */
+ if ((dfu-i_buf + size) dfu-i_buf_end) {
+ tret
[U-Boot] [PATCH v5 5/9] cmd_nand.c: Fix CONFIG_CMD_NAND_YAFFS
The flag changed from WITH_INLINE_OOB to WITH_YAFFS_OOB by accident in
418396e.
Signed-off-by: Tom Rini tr...@ti.com
---
Changes in v5: None
Changes in v4:
- Add patch to fix CONFIG_CMD_NAND_YAFFS
Changes in v3: None
Changes in v2: None
common/cmd_nand.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/common/cmd_nand.c b/common/cmd_nand.c
index 76f4d3f..d9010d2 100644
--- a/common/cmd_nand.c
+++ b/common/cmd_nand.c
@@ -673,7 +673,7 @@ static int do_nand(cmd_tbl_t *cmdtp, int flag, int argc,
char * const argv[])
}
ret = nand_write_skip_bad(nand, off, rwsize, NULL,
maxsize, (u_char *)addr,
- WITH_INLINE_OOB);
+ WITH_YAFFS_OOB);
#endif
} else if (!strcmp(s, .oob)) {
/* out-of-band data */
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v5 6/9] dfu: NAND specific routines for DFU operation
From: Pantelis Antoniou pa...@antoniou-consulting.com
Support for NAND storage devices to work with the DFU framework.
Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com
Signed-off-by: Tom Rini tr...@ti.com
---
Changes in v5:
- Document CONFIG_DFU_NAND in README
Changes in v4: None
Changes in v3:
- Rework logic in nand_block_op for nand_(read|write)_skip_bad returning
just a size for actual used length.
- Remove unused externs from drivers/dfu/dfu_nand.c
Changes in v2:
- nand_block_op calls nand_(read|write)_skip_bad directly.
- Bugfix in dfu_nand to make sure we set dfu-skip_bad to 0 on each
iteration.
README |3 +
drivers/dfu/Makefile |1 +
drivers/dfu/dfu.c |8 ++
drivers/dfu/dfu_nand.c | 195
include/dfu.h | 23 ++
5 files changed, 230 insertions(+)
create mode 100644 drivers/dfu/dfu_nand.c
diff --git a/README b/README
index 154b82f..c70251e 100644
--- a/README
+++ b/README
@@ -1338,6 +1338,9 @@ The following options need to be configured:
CONFIG_DFU_MMC
This enables support for exposing (e)MMC devices via DFU.
+ CONFIG_DFU_NAND
+ This enables support for exposing NAND devices via DFU.
+
CONFIG_SYS_DFU_MAX_FILE_SIZE
When updating files rather than the raw storage device,
we use a static buffer to copy the file into and then write
diff --git a/drivers/dfu/Makefile b/drivers/dfu/Makefile
index 7b717bc..153095d 100644
--- a/drivers/dfu/Makefile
+++ b/drivers/dfu/Makefile
@@ -27,6 +27,7 @@ LIB = $(obj)libdfu.o
COBJS-$(CONFIG_DFU_FUNCTION) += dfu.o
COBJS-$(CONFIG_DFU_MMC) += dfu_mmc.o
+COBJS-$(CONFIG_DFU_NAND) += dfu_nand.o
SRCS:= $(COBJS-y:.o=.c)
OBJS := $(addprefix $(obj),$(COBJS-y))
diff --git a/drivers/dfu/dfu.c b/drivers/dfu/dfu.c
index 2fecf77..84139bd 100644
--- a/drivers/dfu/dfu.c
+++ b/drivers/dfu/dfu.c
@@ -86,6 +86,7 @@ int dfu_write(struct dfu_entity *dfu, void *buf, int size,
int blk_seq_num)
/* initial state */
dfu-crc = 0;
dfu-offset = 0;
+ dfu-bad_skip = 0;
dfu-i_blk_seq_num = 0;
dfu-i_buf_start = dfu_buf;
dfu-i_buf_end = dfu_buf + sizeof(dfu_buf);
@@ -235,6 +236,8 @@ int dfu_read(struct dfu_entity *dfu, void *buf, int size,
int blk_seq_num)
dfu-i_buf = dfu-i_buf_start;
dfu-b_left = 0;
+ dfu-bad_skip = 0;
+
dfu-inited = 1;
}
@@ -264,6 +267,8 @@ int dfu_read(struct dfu_entity *dfu, void *buf, int size,
int blk_seq_num)
dfu-i_buf = dfu-i_buf_start;
dfu-b_left = 0;
+ dfu-bad_skip = 0;
+
dfu-inited = 0;
}
@@ -286,6 +291,9 @@ static int dfu_fill_entity(struct dfu_entity *dfu, char *s,
int alt,
if (strcmp(interface, mmc) == 0) {
if (dfu_fill_entity_mmc(dfu, s))
return -1;
+ } else if (strcmp(interface, nand) == 0) {
+ if (dfu_fill_entity_nand(dfu, s))
+ return -1;
} else {
printf(%s: Device %s not (yet) supported!\n,
__func__, interface);
diff --git a/drivers/dfu/dfu_nand.c b/drivers/dfu/dfu_nand.c
new file mode 100644
index 000..b7f60dd
--- /dev/null
+++ b/drivers/dfu/dfu_nand.c
@@ -0,0 +1,195 @@
+/*
+ * dfu_nand.c -- DFU for NAND routines.
+ *
+ * Copyright (C) 2012-2013 Texas Instruments, Inc.
+ *
+ * Based on dfu_mmc.c which is:
+ * Copyright (C) 2012 Samsung Electronics
+ * author: Lukasz Majewski l.majew...@samsung.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+#include common.h
+#include malloc.h
+#include errno.h
+#include div64.h
+#include dfu.h
+#include linux/mtd/mtd.h
+#include jffs2/load_kernel.h
+#include nand.h
+
+enum dfu_nand_op {
+ DFU_OP_READ = 1,
+ DFU_OP_WRITE,
+};
+
+static int nand_block_op(enum dfu_nand_op op, struct dfu_entity *dfu,
+ u64 offset, void *buf, long *len)
+{
+ loff_t start;
+ size_t count, actual;
+ int ret;
+ int dev;
+ nand_info_t *nand;
+
+ /* if buf == NULL return
[U-Boot] [PATCH v5 7/9] am335x_evm: Define CONFIG_SYS_CACHELINE_SIZE
From: Pantelis Antoniou pa...@antoniou-consulting.com drivers/usb/gadget/composite.c requires that this is defined early. Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com Signed-off-by: Tom Rini tr...@ti.com Acked-by: Tom Rini tr...@ti.com --- Changes in v5: None Changes in v4: None Changes in v3: None Changes in v2: None include/configs/am335x_evm.h |2 ++ 1 file changed, 2 insertions(+) diff --git a/include/configs/am335x_evm.h b/include/configs/am335x_evm.h index 33ee2c4..59647d1 100644 --- a/include/configs/am335x_evm.h +++ b/include/configs/am335x_evm.h @@ -39,6 +39,8 @@ #define CONFIG_SETUP_MEMORY_TAGS #define CONFIG_INITRD_TAG +#define CONFIG_SYS_CACHELINE_SIZE 64 + /* commands to include */ #include config_cmd_default.h -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v5 8/9] am335x_evm: Add CONFIG_CMD_MTDPARTS and relevant defaults
Signed-off-by: Tom Rini tr...@ti.com --- Changes in v5: None Changes in v4: None Changes in v3: None Changes in v2: - Add CONFIG_CMD_MTDPARTS and relevant information to am335x_evm include/configs/am335x_evm.h |9 + 1 file changed, 9 insertions(+) diff --git a/include/configs/am335x_evm.h b/include/configs/am335x_evm.h index 59647d1..61b861d 100644 --- a/include/configs/am335x_evm.h +++ b/include/configs/am335x_evm.h @@ -60,6 +60,8 @@ fdtfile=\0 \ console=ttyO0,115200n8\0 \ optargs=\0 \ + mtdids= MTDIDS_DEFAULT \0 \ + mtdparts= MTDPARTS_DEFAULT \0 \ mmcdev=0\0 \ mmcroot=/dev/mmcblk0p2 ro\0 \ mmcrootfstype=ext4 rootwait\0 \ @@ -341,6 +343,13 @@ /* NAND support */ #ifdef CONFIG_NAND #define CONFIG_CMD_NAND +#define CONFIG_CMD_MTDPARTS +#define MTDIDS_DEFAULT nand0=omap2-nand.0 +#define MTDPARTS_DEFAULT mtdparts=omap2-nand.0:128k(SPL), \ + 128k(SPL.backup1), \ + 128k(SPL.backup2), \ + 128k(SPL.backup3),1920k(u-boot), \ + 128k(u-boot-env),5m(kernel),-(rootfs) #define CONFIG_NAND_OMAP_GPMC #define GPMC_NAND_ECC_LP_x16_LAYOUT1 #define CONFIG_SYS_NAND_BASE (0x0800)/* physical address */ -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v5 9/9] am335x_evm: Enable DFU for NAND and MMC, provide example alt_infos
From: Pantelis Antoniou pa...@antoniou-consulting.com
- Add CONFIG_DFU_NAND, CONFIG_DFU_MMC
- Set dfu_alt_info_nand, dfu_alt_info_emmc and dfu_alt_info_mmc to show
working examples for those cases.
- Increase CONFIG_SYS_MAXARGS due to hush parsing bugs that would
otherwise disallow 'setenv dfu_alt_info ${dfu_alt_info_nand}'.
- Enable CONFIG_FAT_WRITE to allow updating on MMC
Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com
Signed-off-by: Tom Rini tr...@ti.com
---
Changes in v5:
- Add RAW MMC examples to include/configs/am335x_evm.h
Changes in v4: None
Changes in v3:
- Fix checkpatch.pl warnings in include/configs/am335x_evm.h
Changes in v2:
- Enable DFU for NAND and MMC, set dfu_alt_info_(nand|mmc) as examples
for both in am335x_evm.h
- Increase CONFIG_SYS_MAXARGS due to hush parsing bugs that would
otherwise prevent 'setenv dfu_alt_info ${dfu_alt_info_nand}' on
am335x_evm
include/configs/am335x_evm.h | 41 +++--
1 file changed, 39 insertions(+), 2 deletions(-)
diff --git a/include/configs/am335x_evm.h b/include/configs/am335x_evm.h
index 61b861d..6b487c2 100644
--- a/include/configs/am335x_evm.h
+++ b/include/configs/am335x_evm.h
@@ -62,6 +62,9 @@
optargs=\0 \
mtdids= MTDIDS_DEFAULT \0 \
mtdparts= MTDPARTS_DEFAULT \0 \
+ dfu_alt_info_mmc= DFU_ALT_INFO_MMC \0 \
+ dfu_alt_info_emmc=rawemmc mmc 0 3751936\0 \
+ dfu_alt_info_nand= DFU_ALT_INFO_NAND \0 \
mmcdev=0\0 \
mmcroot=/dev/mmcblk0p2 ro\0 \
mmcrootfstype=ext4 rootwait\0 \
@@ -118,8 +121,8 @@
#define CONFIG_CMD_ECHO
-/* max number of command args */
-#define CONFIG_SYS_MAXARGS 16
+/* We set the max number of command args high to avoid HUSH bugs. */
+#define CONFIG_SYS_MAXARGS 64
/* Console I/O Buffer Size */
#define CONFIG_SYS_CBSIZE 512
@@ -148,6 +151,7 @@
#define CONFIG_CMD_MMC
#define CONFIG_DOS_PARTITION
#define CONFIG_CMD_FAT
+#define CONFIG_FAT_WRITE
#define CONFIG_CMD_EXT2
#define CONFIG_SPI
@@ -158,6 +162,38 @@
#define CONFIG_CMD_SF
#define CONFIG_SF_DEFAULT_SPEED(2400)
+/* USB Composite download gadget - g_dnl */
+#define CONFIG_USB_GADGET
+#define CONFIG_USBDOWNLOAD_GADGET
+
+/* USB TI's IDs */
+#define CONFIG_USBD_HS
+#define CONFIG_G_DNL_VENDOR_NUM 0x0403
+#define CONFIG_G_DNL_PRODUCT_NUM 0xBD00
+#define CONFIG_G_DNL_MANUFACTURER Texas Instruments
+
+/* USB Device Firmware Update support */
+#define CONFIG_DFU_FUNCTION
+#define CONFIG_DFU_MMC
+#define CONFIG_DFU_NAND
+#define CONFIG_CMD_DFU
+#define DFU_ALT_INFO_MMC \
+ boot part 0 1; \
+ rootfs part 0 2; \
+ MLO fat 0 1; \
+ MLO.raw mmc 100 100; \
+ u-boot.img.raw mmc 300 3C0; \
+ u-boot.img fat 0 1; \
+ uEnv.txt fat 0 1
+#define DFU_ALT_INFO_NAND \
+ SPL part 0 1; \
+ SPL.backup1 part 0 2; \
+ SPL.backup2 part 0 3; \
+ SPL.backup3 part 0 4; \
+ u-boot part 0 5; \
+ kernel part 0 7; \
+ rootfs part 0 8
+
/* Physical Memory Map */
#define CONFIG_NR_DRAM_BANKS 1 /* 1 bank of DRAM */
#define PHYS_DRAM_10x8000 /* DRAM Bank #1 */
@@ -302,6 +338,7 @@
#define CONFIG_MUSB_GADGET
#define CONFIG_MUSB_PIO_ONLY
#define CONFIG_USB_GADGET_DUALSPEED
+#define CONFIG_USB_GADGET_VBUS_DRAW2
#define CONFIG_MUSB_HOST
#define CONFIG_AM335X_USB0
#define CONFIG_AM335X_USB0_MODEMUSB_PERIPHERAL
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] am33xx:ddr:Fix config_sdram to work for all DDR
From: Steve Kipisz s-kipi...@ti.com The original write to sdram_config is correct for DDR3 but incorrect for DDR2 so SPL was hanging. For DDR2, the write to sdram_config should be after the writes to ref_ctrl. This was working for DDR3 because there was a write of 0x2800 to ref_ctrl before a write to sdram_config. Tested on: GP EVM 1.1A (DDR2), GP EVM 1.5A (DDR3), Beaglebone A6 (DDR2), Beagleone Blacd A4A (DDR3) Signed-off-by: Steve Kipisz s-kipi...@ti.com --- arch/arm/cpu/armv7/am33xx/ddr.c |5 - 1 files changed, 4 insertions(+), 1 deletions(-) diff --git a/arch/arm/cpu/armv7/am33xx/ddr.c b/arch/arm/cpu/armv7/am33xx/ddr.c index 448cc40..7932a39 100644 --- a/arch/arm/cpu/armv7/am33xx/ddr.c +++ b/arch/arm/cpu/armv7/am33xx/ddr.c @@ -54,10 +54,13 @@ void config_sdram(const struct emif_regs *regs) writel(0x2800, emif_reg-emif_sdram_ref_ctrl); writel(regs-zq_config, emif_reg-emif_zq_config); writel(regs-sdram_config, cstat-secure_emif_sdram_config); + writel(regs-sdram_config, emif_reg-emif_sdram_config); + writel(regs-ref_ctrl, emif_reg-emif_sdram_ref_ctrl); + writel(regs-ref_ctrl, emif_reg-emif_sdram_ref_ctrl_shdw); } - writel(regs-sdram_config, emif_reg-emif_sdram_config); writel(regs-ref_ctrl, emif_reg-emif_sdram_ref_ctrl); writel(regs-ref_ctrl, emif_reg-emif_sdram_ref_ctrl_shdw); + writel(regs-sdram_config, emif_reg-emif_sdram_config); } /** -- 1.7.2.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-x86.git
On Mon, Mar 04, 2013 at 04:01:52PM -0800, Simon Glass wrote: Hi Tom, Great to see the previous lot made it in. Here is the next x86 series. The following changes since commit 2536850d7cd90bdb75bf3ff86838f913392b68db: Prepare v2013.04-rc1 (2013-03-04 16:29:17 -0500) are available in the git repository at: git://git.denx.de/u-boot-x86.git master for you to fetch changes up to fc959081d41aab2d6f4614c5fb3dd1b77ffcdcf4: x86: Enable CONFIG_OF_CONTROL on coreboot (2013-03-04 15:57:52 -0800) Simon Glass (9): x86: Add function to get top of usable ram x86: Add basic cache operations x86: Permit bootstage and timer data to be used prior to relocation x86: Add an __end symbol to signal the end of the U-Boot binary x86: Rearrange the output input to remove BSS x86: Support relocation of FDT on start-up x86: Add error checking to x86 relocation code x86: Adjust link device tree include file x86: Enable CONFIG_OF_CONTROL on coreboot arch/x86/cpu/coreboot/coreboot.c| 15 +--- arch/x86/cpu/coreboot/sdram.c | 18 +++--- arch/x86/cpu/cpu.c | 23 + arch/x86/cpu/interrupts.c | 7 +++--- arch/x86/cpu/u-boot.lds | 21 ++-- arch/x86/include/asm/global_data.h | 4 +++ arch/x86/include/asm/init_helpers.h | 2 ++ arch/x86/include/asm/relocate.h | 1 + arch/x86/include/asm/u-boot-x86.h | 1 + arch/x86/lib/board.c| 3 +++ arch/x86/lib/init_helpers.c | 49 - arch/x86/lib/init_wrappers.c| 1 + arch/x86/lib/relocate.c | 37 ++-- arch/x86/lib/timer.c| 9 +++ board/chromebook-x86/dts/link.dts | 2 +- include/configs/coreboot.h | 6 + 16 files changed, 146 insertions(+), 53 deletions(-) Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4] Introduced btrfs file-system with btrload command
Hi Adnan, On Fri, Mar 8, 2013 at 3:11 AM, Adnan Ali adnan@codethink.co.uk wrote: Hi On 08/03/13 05:03, Simon Glass wrote: +U-Boot et al Hi, On Thu, Mar 7, 2013 at 2:35 AM, Adnan Ali adnan@codethink.co.uk wrote: Introduces btrfs file-system to read file from volume/sub-volumes with btrload command. This implementation has read-only support. This btrfs implementation is based on syslinux btrfs code, commit 269ebc845ebc8b46ef4b0be7fa0005**c7fdb95b8d. Here are some comments, hope it helps. Most of your comments in btrfs.c is about ported code. which we have already discussed to leave it as it for easy of future re sync. I will also wait for others to respond, so that i know what to change before sending other revision of patch. Please find my comments below Yes, I'm sorry, now I remember that discussion. I think if you can fit it in to work with the new fs.c changes then all will be well. Please just take account of my comments that relate to fitting it into U-Boot, and ignore the ones that concern code style/readability. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] 8xx: Fix build warnings
MPC8xx based systems throw this warning:
cpu.c:81:2: warning: dereferencing type-punned pointer will break
strict-aliasing rules [-Wstrict-aliasing]
Fix it.
Signed-off-by: Wolfgang Denk w...@denx.de
Cc: Andy Fleming aflem...@gmail.com
---
arch/powerpc/cpu/mpc8xx/cpu.c| 4 +++-
arch/powerpc/include/asm/8xx_immap.h | 5 +
2 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/cpu/mpc8xx/cpu.c b/arch/powerpc/cpu/mpc8xx/cpu.c
index b6b733d..f48d602 100644
--- a/arch/powerpc/cpu/mpc8xx/cpu.c
+++ b/arch/powerpc/cpu/mpc8xx/cpu.c
@@ -78,7 +78,9 @@ static int check_CPU (long clock, uint pvr, uint immr)
if ((pvr 16) != 0x0050)
return -1;
- k = (immr 16) | *((ushort *) immap-im_cpm.cp_dparam[0xB0]);
+ k = (immr 16) |
+ immap-im_cpm.cp_dparam[PROFF_REVNUM] 8 |
+ immap-im_cpm.cp_dparam[PROFF_REVNUM + 1] ;
m = 0;
suf = ;
diff --git a/arch/powerpc/include/asm/8xx_immap.h
b/arch/powerpc/include/asm/8xx_immap.h
index 40679cb..3b29b39 100644
--- a/arch/powerpc/include/asm/8xx_immap.h
+++ b/arch/powerpc/include/asm/8xx_immap.h
@@ -488,6 +488,11 @@ typedef struct comm_proc {
u_char cp_dparam[0x400]; /* Parameter RAM */
} cpm8xx_t;
+/*
+ * Parameter RAM offsets from the base.
+ */
+#define PROFF_REVNUM ((uint)0x00B0)
+
/* Internal memory map.
*/
typedef struct immap {
--
1.7.11.7
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] Feature Removal: disable mtest command by default
The mtest command is of little practical use (if any), and experience has shown that a large number of board configurations define useless or even dangerous start and end addresses. If not even the board maintainers are able to figure out which memory range can be reliably tested, how can we expect such from the end users? As this problem comes up repeatedly, we rather do not enable this command by default, so only people who know what they are doing will be confronted with it. As this changes the user interface, we allow for a grace period before this change takes effect. For now, we make mtest configurable through the CONFIG_CMD_MEMTEST variable, which is defined in include/config_cmd_default.h; we also add an entry to doc/feature-removal-schedule.txt which announces the removal of this default setting in two releases from now, i. e. with v2013.07. Signed-off-by: Wolfgang Denk w...@denx.de Cc: Tom Rini tr...@ti.com --- README | 3 +- common/cmd_mem.c | 5 +- doc/README.memory-test | 98 doc/feature-removal-schedule.txt | 17 +++ include/config_cmd_all.h | 3 +- include/config_cmd_default.h | 3 +- 6 files changed, 125 insertions(+), 4 deletions(-) create mode 100644 doc/README.memory-test diff --git a/README b/README index 42544ce..869694f 100644 --- a/README +++ b/README @@ -860,7 +860,8 @@ The following options need to be configured: (requires CONFIG_CMD_MEMORY and CONFIG_MD5) CONFIG_CMD_MEMINFO * Display detailed memory information CONFIG_CMD_MEMORY md, mm, nm, mw, cp, cmp, crc, base, - loop, loopw, mtest + loop, loopw + CONFIG_CMD_MEMTESTmtest CONFIG_CMD_MISC Misc functions like sleep etc CONFIG_CMD_MMC * MMC memory mapped support CONFIG_CMD_MII * MII utility commands diff --git a/common/cmd_mem.c b/common/cmd_mem.c index 042c994..53572f7 100644 --- a/common/cmd_mem.c +++ b/common/cmd_mem.c @@ -910,6 +910,7 @@ static ulong mem_test_quick(vu_long *buf, ulong start_addr, ulong end_addr, return 0; } +#ifdef CONFIG_CMD_MEMTEST /* * Perform a memory test. A more complete alternative test can be * configured using CONFIG_SYS_ALT_MEMTEST. The complete test loops until @@ -1002,7 +1003,7 @@ static int do_mem_mtest(cmd_tbl_t *cmdtp, int flag, int argc, return ret; /* not reached */ } - +#endif /* CONFIG_CMD_MEMTEST */ /* Modify memory. * @@ -1240,11 +1241,13 @@ U_BOOT_CMD( ); #endif /* CONFIG_LOOPW */ +#ifdef CONFIG_CMD_MEMTEST U_BOOT_CMD( mtest, 5, 1, do_mem_mtest, simple RAM read/write test, [start [end [pattern [iterations ); +#endif /* CONFIG_CMD_MEMTEST */ #ifdef CONFIG_MX_CYCLIC U_BOOT_CMD( diff --git a/doc/README.memory-test b/doc/README.memory-test new file mode 100644 index 000..1e9520b --- /dev/null +++ b/doc/README.memory-test @@ -0,0 +1,98 @@ +The most frequent cause of problems when porting U-Boot to new +hardware, or when using a sloppy port on some board, is memory errors. +In most cases these are not caused by failing hardware, but by +incorrect initialization of the memory controller. So it appears to +be a good idea to always test if the memory is working correctly, +before looking for any other potential causes of any problems. + +U-Boot implements 3 different approaches to perform memory tests: + +1. The get_ram_size() function (see common/memsize.c). + + This function is supposed to be used in each and every U-Boot port + determine the presence and actual size of each of the potential + memory banks on this piece of hardware. The code is supposed to be + very fast, so running it for each reboot does not hurt. It is a + little known and generally underrated fact that this code will also + catch 99% of hardware related (i. e. reliably reproducable) memory + errors. It is strongly recommended to always use this function, in + each and every port of U-Boot. + +2. The mtest command. + + This is probably the best known memory test utility in U-Boot. + Unfortunately, it is also the most problematic, and the most + useless one. + + There are a number of serious problems with this command: + + - It is terribly slow. Running mtest on the whole system RAM + takes a _long_ time before there is any significance in the fact + that no errors have been found so far. + + - It is difficult to configure, and to use. And any errors here + will reliably crash or hang your system. mtest is dump and has + no knowledge about memory ranges that may be in use for other + purposes, like exception code, U-Boot code and data, stack, + malloc arena, video buffer, log buffer, etc. If you
Re: [U-Boot] [PATCH] Feature Removal: disable mtest command by default
On Fri, Mar 08, 2013 at 08:08:24PM +0100, Wolfgang Denk wrote: The mtest command is of little practical use (if any), and experience has shown that a large number of board configurations define useless or even dangerous start and end addresses. If not even the board maintainers are able to figure out which memory range can be reliably tested, how can we expect such from the end users? As this problem comes up repeatedly, we rather do not enable this command by default, so only people who know what they are doing will be confronted with it. As this changes the user interface, we allow for a grace period before this change takes effect. For now, we make mtest configurable through the CONFIG_CMD_MEMTEST variable, which is defined in include/config_cmd_default.h; we also add an entry to doc/feature-removal-schedule.txt which announces the removal of this default setting in two releases from now, i. e. with v2013.07. Signed-off-by: Wolfgang Denk w...@denx.de Cc: Tom Rini tr...@ti.com Hi Wolfgang Denk, I noticed a couple of small typos, and thought I'd point them out. Hope it helps, Ira --- README | 3 +- common/cmd_mem.c | 5 +- doc/README.memory-test | 98 doc/feature-removal-schedule.txt | 17 +++ include/config_cmd_all.h | 3 +- include/config_cmd_default.h | 3 +- 6 files changed, 125 insertions(+), 4 deletions(-) create mode 100644 doc/README.memory-test diff --git a/README b/README index 42544ce..869694f 100644 --- a/README +++ b/README @@ -860,7 +860,8 @@ The following options need to be configured: (requires CONFIG_CMD_MEMORY and CONFIG_MD5) CONFIG_CMD_MEMINFO * Display detailed memory information CONFIG_CMD_MEMORY md, mm, nm, mw, cp, cmp, crc, base, - loop, loopw, mtest + loop, loopw + CONFIG_CMD_MEMTESTmtest CONFIG_CMD_MISC Misc functions like sleep etc CONFIG_CMD_MMC * MMC memory mapped support CONFIG_CMD_MII * MII utility commands diff --git a/common/cmd_mem.c b/common/cmd_mem.c index 042c994..53572f7 100644 --- a/common/cmd_mem.c +++ b/common/cmd_mem.c @@ -910,6 +910,7 @@ static ulong mem_test_quick(vu_long *buf, ulong start_addr, ulong end_addr, return 0; } +#ifdef CONFIG_CMD_MEMTEST /* * Perform a memory test. A more complete alternative test can be * configured using CONFIG_SYS_ALT_MEMTEST. The complete test loops until @@ -1002,7 +1003,7 @@ static int do_mem_mtest(cmd_tbl_t *cmdtp, int flag, int argc, return ret; /* not reached */ } - +#endif /* CONFIG_CMD_MEMTEST */ /* Modify memory. * @@ -1240,11 +1241,13 @@ U_BOOT_CMD( ); #endif /* CONFIG_LOOPW */ +#ifdef CONFIG_CMD_MEMTEST U_BOOT_CMD( mtest, 5, 1, do_mem_mtest, simple RAM read/write test, [start [end [pattern [iterations ); +#endif /* CONFIG_CMD_MEMTEST */ #ifdef CONFIG_MX_CYCLIC U_BOOT_CMD( diff --git a/doc/README.memory-test b/doc/README.memory-test new file mode 100644 index 000..1e9520b --- /dev/null +++ b/doc/README.memory-test @@ -0,0 +1,98 @@ +The most frequent cause of problems when porting U-Boot to new +hardware, or when using a sloppy port on some board, is memory errors. +In most cases these are not caused by failing hardware, but by +incorrect initialization of the memory controller. So it appears to +be a good idea to always test if the memory is working correctly, +before looking for any other potential causes of any problems. + +U-Boot implements 3 different approaches to perform memory tests: + +1. The get_ram_size() function (see common/memsize.c). + + This function is supposed to be used in each and every U-Boot port + determine the presence and actual size of each of the potential + memory banks on this piece of hardware. The code is supposed to be + very fast, so running it for each reboot does not hurt. It is a + little known and generally underrated fact that this code will also + catch 99% of hardware related (i. e. reliably reproducable) memory + errors. It is strongly recommended to always use this function, in + each and every port of U-Boot. + +2. The mtest command. + + This is probably the best known memory test utility in U-Boot. + Unfortunately, it is also the most problematic, and the most + useless one. + + There are a number of serious problems with this command: + + - It is terribly slow. Running mtest on the whole system RAM + takes a _long_ time before there is any significance in the fact + that no errors have been found so far. + + - It is difficult to configure, and to use. And any
Re: [U-Boot] [U-Boot, v2] env: don't generate callback list entries for SPL
On Thu, Dec 20, 2012 at 11:51:05AM -, Scott Wood wrote: SPL doesn't write to the environment. These list entries prevent the functions from being garbage-collected, even though nothing will look at the list. This caused several SPL builds (e.g. P2020RDB-PC_NAND) to break due to size limitations and/or unresolved symbols. A static inline function is used to provide a context in which we can consume the callback, and thus avoid unused function warnings. Signed-off-by: Scott Wood scottw...@freescale.com Acked-by: Joe Hershberger joe.hershber...@gmail.com Acked-by: Kim Phillips kim.phill...@freescale.com OK, this isn't quite right. On am335x_evm where SPL does use the full version of the environment, rather than the restricted version that say a3m071 we need these these callbacks to be generated. We usually build successfully since in these cases our #include of u-boot.lst picks up the one in include that the main SPL generates. But with enough cores we build SPL before we build this list for non-SPL, and the build fails. I shall submit a patch shortly for this. -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, v2] env: don't generate callback list entries for SPL
On 03/08/2013 02:27:48 PM, Tom Rini wrote: On Thu, Dec 20, 2012 at 11:51:05AM -, Scott Wood wrote: SPL doesn't write to the environment. These list entries prevent the functions from being garbage-collected, even though nothing will look at the list. This caused several SPL builds (e.g. P2020RDB-PC_NAND) to break due to size limitations and/or unresolved symbols. A static inline function is used to provide a context in which we can consume the callback, and thus avoid unused function warnings. Signed-off-by: Scott Wood scottw...@freescale.com Acked-by: Joe Hershberger joe.hershber...@gmail.com Acked-by: Kim Phillips kim.phill...@freescale.com OK, this isn't quite right. On am335x_evm where SPL does use the full version of the environment, rather than the restricted version that say a3m071 we need these these callbacks to be generated. We usually build successfully since in these cases our #include of u-boot.lst picks up the one in include that the main SPL generates. But with enough cores we build SPL before we build this list for non-SPL, and the build fails. I shall submit a patch shortly for this. What does am335x_evm do in the SPL that requires modifying the environment, and how does omitting the callbacks cause a build break? The u-boot.lst issue sounds unrelated to this patch. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Feature Removal: disable mtest command by default
Dear Ira, In message 20130308194131.ge23...@ovro.caltech.edu you wrote: I noticed a couple of small typos, and thought I'd point them out. Thanks a lot, highly appreciated! 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 Madness takes its toll. Please have exact change. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] Feature Removal: disable mtest command by default
The mtest command is of little practical use (if any), and experience has shown that a large number of board configurations define useless or even dangerous start and end addresses. If not even the board maintainers are able to figure out which memory range can be reliably tested, how can we expect such from the end users? As this problem comes up repeatedly, we rather do not enable this command by default, so only people who know what they are doing will be confronted with it. As this changes the user interface, we allow for a grace period before this change takes effect. For now, we make mtest configurable through the CONFIG_CMD_MEMTEST variable, which is defined in include/config_cmd_default.h; we also add an entry to doc/feature-removal-schedule.txt which announces the removal of this default setting in two releases from now, i. e. with v2013.07. Signed-off-by: Wolfgang Denk w...@denx.de Cc: Tom Rini tr...@ti.com --- v2: - Fix spelling errors in doc/README.memory-test; kudos to Ira W. Snyder README | 3 +- common/cmd_mem.c | 5 +- doc/README.memory-test | 98 doc/feature-removal-schedule.txt | 17 +++ include/config_cmd_all.h | 3 +- include/config_cmd_default.h | 3 +- 6 files changed, 125 insertions(+), 4 deletions(-) create mode 100644 doc/README.memory-test diff --git a/README b/README index 42544ce..869694f 100644 --- a/README +++ b/README @@ -860,7 +860,8 @@ The following options need to be configured: (requires CONFIG_CMD_MEMORY and CONFIG_MD5) CONFIG_CMD_MEMINFO * Display detailed memory information CONFIG_CMD_MEMORY md, mm, nm, mw, cp, cmp, crc, base, - loop, loopw, mtest + loop, loopw + CONFIG_CMD_MEMTESTmtest CONFIG_CMD_MISC Misc functions like sleep etc CONFIG_CMD_MMC * MMC memory mapped support CONFIG_CMD_MII * MII utility commands diff --git a/common/cmd_mem.c b/common/cmd_mem.c index 042c994..53572f7 100644 --- a/common/cmd_mem.c +++ b/common/cmd_mem.c @@ -910,6 +910,7 @@ static ulong mem_test_quick(vu_long *buf, ulong start_addr, ulong end_addr, return 0; } +#ifdef CONFIG_CMD_MEMTEST /* * Perform a memory test. A more complete alternative test can be * configured using CONFIG_SYS_ALT_MEMTEST. The complete test loops until @@ -1002,7 +1003,7 @@ static int do_mem_mtest(cmd_tbl_t *cmdtp, int flag, int argc, return ret; /* not reached */ } - +#endif /* CONFIG_CMD_MEMTEST */ /* Modify memory. * @@ -1240,11 +1241,13 @@ U_BOOT_CMD( ); #endif /* CONFIG_LOOPW */ +#ifdef CONFIG_CMD_MEMTEST U_BOOT_CMD( mtest, 5, 1, do_mem_mtest, simple RAM read/write test, [start [end [pattern [iterations ); +#endif /* CONFIG_CMD_MEMTEST */ #ifdef CONFIG_MX_CYCLIC U_BOOT_CMD( diff --git a/doc/README.memory-test b/doc/README.memory-test new file mode 100644 index 000..eb60e8d --- /dev/null +++ b/doc/README.memory-test @@ -0,0 +1,98 @@ +The most frequent cause of problems when porting U-Boot to new +hardware, or when using a sloppy port on some board, is memory errors. +In most cases these are not caused by failing hardware, but by +incorrect initialization of the memory controller. So it appears to +be a good idea to always test if the memory is working correctly, +before looking for any other potential causes of any problems. + +U-Boot implements 3 different approaches to perform memory tests: + +1. The get_ram_size() function (see common/memsize.c). + + This function is supposed to be used in each and every U-Boot port + determine the presence and actual size of each of the potential + memory banks on this piece of hardware. The code is supposed to be + very fast, so running it for each reboot does not hurt. It is a + little known and generally underrated fact that this code will also + catch 99% of hardware related (i. e. reliably reproducible) memory + errors. It is strongly recommended to always use this function, in + each and every port of U-Boot. + +2. The mtest command. + + This is probably the best known memory test utility in U-Boot. + Unfortunately, it is also the most problematic, and the most + useless one. + + There are a number of serious problems with this command: + + - It is terribly slow. Running mtest on the whole system RAM + takes a _long_ time before there is any significance in the fact + that no errors have been found so far. + + - It is difficult to configure, and to use. And any errors here + will reliably crash or hang your system. mtest is dumb and has + no knowledge about memory ranges that may be in use for other + purposes, like exception code, U-Boot
Re: [U-Boot] [U-Boot, v2] env: don't generate callback list entries for SPL
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/08/2013 03:34 PM, Scott Wood wrote: On 03/08/2013 02:27:48 PM, Tom Rini wrote: On Thu, Dec 20, 2012 at 11:51:05AM -, Scott Wood wrote: SPL doesn't write to the environment. These list entries prevent the functions from being garbage-collected, even though nothing will look at the list. This caused several SPL builds (e.g. P2020RDB-PC_NAND) to break due to size limitations and/or unresolved symbols. A static inline function is used to provide a context in which we can consume the callback, and thus avoid unused function warnings. Signed-off-by: Scott Wood scottw...@freescale.com Acked-by: Joe Hershberger joe.hershber...@gmail.com Acked-by: Kim Phillips kim.phill...@freescale.com OK, this isn't quite right. On am335x_evm where SPL does use the full version of the environment, rather than the restricted version that say a3m071 we need these these callbacks to be generated. We usually build successfully since in these cases our #include of u-boot.lst picks up the one in include that the main SPL generates. But with enough cores we build SPL before we build this list for non-SPL, and the build fails. I shall submit a patch shortly for this. What does am335x_evm do in the SPL that requires modifying the environment, and how does omitting the callbacks cause a build break? It requires the full network stack which in turn means we can't just discard most of the environment related functions. And some parts of the callback infrastructure aren't opt-in'able. The u-boot.lst issue sounds unrelated to this patch. The problem is undefined references at link time to _u_boot_env_clbk__start/__end from common/env_callbacks.c where it tries to look at our empty list of callbacks (we are able to discard all of those). And part of the issue is that we're always using the wrong u-boot.lst file for SPL. It's just that in most cases the wrong one (the main U-Boot one) is also fine enough for SPL since it's just a few extra symbols and we aren't so constrained for space that we've noticed. - -- Tom -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJROlFDAAoJENk4IS6UOR1WEvwQAJtEjtnUs/Zu38rQ5oFV/W2V a/MX3hTmFF1bhJ9oiP52j1liB/V+hLCAhzveGllWLnvICFvv6F5nFrDwhhlUIRkX ZC99JvkYFHbQexnpwWqwR35reXsQWIhISLN9yeKtQ3GF0b9nztIXARLwpcLRJp95 fctdiTPrWi/jqLsmX63BkQyhbfpc5ltgDu1kn7PQSgzDt49OJUlqvMrMGM9xY98h wfKkuUE8Ez4Xq9rsTwa21oECEcgNRuAbsHyePMyuNeVuSfyjwin4d8y3xK7H0Kp5 Z12tnSNet4G4e06Hz+NRdpEa6DqSbyvQpX8rhctEYBxEaA/VpGUIFrrUOEa8jdDh J49/rF8xhYBTeKfpbYrfCS5iQUKnuJxGW7+2PYH8+y1RxQdLkkhuJdQVoAJ4cNsL HP3AeoI7Urc7QYVINyBNCG8Ak6/skDI9Ia6eFqJbNm1X0jDnvV6wh1JoK0lxgJio Uw2NdFIlIHUMHAGMW8R/Zj1eCqaLkwWtTRPqgENPwcOtTdaf/Y/57R2yYRDvz52l Dl9AikeDu8tr0y431b3WJo5aXi5XXAeQiEJzWj48nExSv29fh48gc3IEVO6+Xnnp 2tQbUarWwoptp1QALmuMJlPeIdfGNg1/AoQeise8WtoS0GSl868QG+NJVpmKhEl+ GYiBfxNk+pGlJZmRjHhQ =Bx5L -END PGP SIGNATURE- ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] powerpc: fix 8xx and 82xx type-punning warnings with GCC 4.7
Dear Scott, In message 1357696756-31079-1-git-send-email-scottw...@freescale.com you wrote: C99's strict aliasing rules are insane to use in low-level code such as a bootloader, but as Wolfgang has rejected -fno-strict-aliasing in the past, add a union so that 16-bit accesses can be performed. Sorry, I saw this patch only after re-inventing the fix for 8xx. #ifdef CONFIG_HARD_I2C - *((unsigned short*)(immr-im_dprambase[PROFF_I2C_BASE])) = 0; + immr-im_dprambase16[PROFF_I2C_BASE / 2] = 0; I have to admit that I dislike this approach pretty much. I think we agree that, if we attempted to play strictly by the rules, this code should probably rewritten using C structs and proper I/O accessors. But then, both 8xx and 82xx are essentially dead horses, and I guess you have no more enthusiasm in cleaning up that old code than me. So let's ignore that for now. But this ...[OFFSET / 2] is basicly unreadable. Can we please at least make this ...[OFFSET / sizeof(u16)] so the reader gets a hint of where this is coming from? --- a/arch/powerpc/cpu/mpc8xx/cpu.c +++ b/arch/powerpc/cpu/mpc8xx/cpu.c @@ -79,7 +79,7 @@ static int check_CPU (long clock, uint pvr, uint immr) if ((pvr 16) != 0x0050) return -1; - k = (immr 16) | *((ushort *) immap-im_cpm.cp_dparam[0xB0]); + k = (immr 16) | immap-im_cpm.cp_dparam16[0xB0 / 2]; m = 0; suf = ; @@ -195,7 +195,7 @@ static int check_CPU (long clock, uint pvr, uint immr) if ((pvr 16) != 0x0050) return -1; - k = (immr 16) | *((ushort *) immap-im_cpm.cp_dparam[0xB0]); + k = (immr 16) | in_be16((ushort *)immap-im_cpm.cp_dparam[0xB0]); Now this is very inconsistent - you convert the very same code line in very different ways here. Please don't. Is there any specific reason you did not use a similar approach of using in_be16() in the other locations? Actually I feel this is still the most readable version - I prefer this, even though it clashes with the style of the rest of the code. Oh, and can we please get rid of this magic number 0xB0 here, and introduce PROFF_REVNUM like we do everywhere else? See http://patchwork.ozlabs.org/patch/226185/ for the needed addition to arch/powerpc/include/asm/8xx_immap.h 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 Uncertain fortune is thoroughly mastered by the equity of the calcu- lation. - Blaise Pascal ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] 8xx: Fix build warnings
Hi, In message 1362768757-11425-1-git-send-email...@denx.de you wrote: MPC8xx based systems throw this warning: cpu.c:81:2: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing] Fix it. I withdraw this patch in favour of Scott's older and more complete patch http://patchwork.ozlabs.org/patch/210599/ 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 Nearly everyone is in favor of going to heaven but too many are hoping they'll live long enough to see an easing of the entrance requirements. Never appeal to a man's better nature. he might not have one. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5] Exynos5: Pinmux: Add fdt for pinmux
Hi Akshay,
On Fri, Mar 8, 2013 at 4:08 AM, Akshay Saraswat aksha...@samsung.comwrote:
Hi Simon,
Hi Akshay,
On Thu, Mar 7, 2013 at 6:09 AM, Akshay Saraswat aksha...@samsung.com
wrote:
This patch adds fdt nodes for peripherals which require
pin muxing and configuration. Device tree bindings for pinctrl
are kept same as required for Linux. Existing pinmux code
modified to retrieve gpio range and function related info from fdt.
Depends-on: [U-Boot] [PATCH 0/4 V3] EXYNOS5: Add GPIO numbering feature
URL: http://lists.denx.de/pipermail/u-boot/2013-February/146151.html
Signed-off-by: Akshay Saraswat aksha...@samsung.com
---
Changes since v1:
- Device tree bindings changed to linux style.
- Added documentation for samsung pinctrl.
Changes since v2:
- Rebased as per new version of GPIO numbering patch-set.
Changes since v3:
- Added comments to reduce ambiguity and increase readability.
- Fixed few other nits.
Changes since v4:
- Added support for reading peripheral pinctrl subnode names
from preipheral's node instead of hard coding.
Well I have to say this is looking really nice. From what I can tell
you are using the Linux binding for samsung,pinctrl-names - please can
you add in that binding information to your binding file - I can't see
it there?
samsung,pinctrl-names is already mentioned in example 3 of
doc/device-tree-bindings/samsung-pinctrl.txt.
samsung-pinctrl.txt in u-boot and kernel are same except the name exynos5
replaced exynos4210.
Please tell me, if I misunderstood the requirement.
I don't see 'samsung,pinctrl-names' in example 3, but also, is it possible
to mention this in the binding somehow?
The names should match the kernel if possible.
The interesting thing is that you should at some point (further patch)
be able to remove the alias stuff and have the driver's pass their
node offset into this function. Then we can drop the peripheral IDs
altogether perhaps?
I think for now we should keep PERIPH_ID's because same pinmux.c and
functions are being used by
exynos4 and exynos4x12. Since, I thought we should not break support for
these SoC's, I kept node
retrieval in Pinmux itself instead of drivers or smdk5250.c. Please
suggest.
That's fine. I suspect perhaps driver could pass their node offset, but
let's worry about that another time.
arch/arm/cpu/armv7/exynos/pinmux.c | 357 +++---
arch/arm/dts/exynos5250-pinctrl.dtsi | 675
+++
arch/arm/dts/exynos5250.dtsi | 92
board/samsung/dts/exynos5250-smdk5250.dts| 11 +
doc/device-tree-bindings/samsung-pinctrl.txt | 253 ++
include/fdtdec.h | 4 +
lib/fdtdec.c | 4 +
7 files changed, 1231 insertions(+), 165 deletions(-)
create mode 100644 arch/arm/dts/exynos5250-pinctrl.dtsi
create mode 100644 doc/device-tree-bindings/samsung-pinctrl.txt
[..]
diff --git a/include/fdtdec.h b/include/fdtdec.h
index 77f244f..26692e5 100644
--- a/include/fdtdec.h
+++ b/include/fdtdec.h
@@ -81,6 +81,10 @@ enum fdt_compat_id {
COMPAT_SAMSUNG_EXYNOS_EHCI, /* Exynos EHCI controller */
COMPAT_SAMSUNG_EXYNOS_USB_PHY, /* Exynos phy controller for
usb2.0 */
COMPAT_MAXIM_MAX77686_PMIC, /* MAX77686 PMIC */
+ COMPAT_SAMSUNG_EXYNOS_UART, /* Exynos serial */
+ COMPAT_SAMSUNG_EXYNOS_MSHC, /* Exynos MMC controller */
+ COMPAT_SAMSUNG_EXYNOS_I2S, /* Exynos MMC controller */
This comment should be I2C.
+ COMPAT_SAMSUNG_PINCTRL, /* PINCTRL */
COMPAT_COUNT,
};
diff --git a/lib/fdtdec.c b/lib/fdtdec.c
index 3ae348d..88dd669 100644
--- a/lib/fdtdec.c
+++ b/lib/fdtdec.c
@@ -56,6 +56,10 @@ static const char * const compat_names[COMPAT_COUNT]
= {
COMPAT(SAMSUNG_EXYNOS_EHCI, samsung,exynos-ehci),
COMPAT(SAMSUNG_EXYNOS_USB_PHY, samsung,exynos-usb-phy),
COMPAT(MAXIM_MAX77686_PMIC, maxim,max77686_pmic),
+ COMPAT(SAMSUNG_EXYNOS_UART, samsung,exynos-uart),
+ COMPAT(SAMSUNG_EXYNOS_MSHC, samsung,exynos-mshc),
+ COMPAT(SAMSUNG_EXYNOS_I2S, samsung,exynos-i2s),
+ COMPAT(SAMSUNG_PINCTRL, samsung,pinctrl),
Do these match the kernel names?
In kernel these are mentioned as samsung,exynos5250-dw-mshc
samsung,exynos4210-uart.
I wanted to keep it consistent with others like samsung,exynos-ehci,
samsung,exynos-spi etc.,
hence, made samsung,exynos-mshc samsung,exynos-uart. Shall I change
it ?
Yes, sorry, but I think we should keep things the same as the kernel.
Perhaps that should be a separate patch to sync up the names?
Regards,
Simon
};
Regards,
Akshay Saraswat
___
U-Boot mailing list
U-Boot@lists.denx.de
Re: [U-Boot] [RFC PATCH] Add support for Boundary Devices Nitrogen6x boards
Hi Eric, On Wed, Jan 30, 2013 at 4:10 PM, Eric Nelson eric.nel...@boundarydevices.com wrote: This patch adds support for the Nitrogen6X board(s) from Boundary Devices. The boards are based on the i.MX6x processor family with two major variants: i.MX6Quad/6Dual i.MX6Dual-Lite/6Solo board/boundary/nitrogen6x/800mhz_2x128mx16.cfg | 37 + board/boundary/nitrogen6x/800mhz_2x256mx16.cfg | 37 + board/boundary/nitrogen6x/800mhz_4x128mx16.cfg | 37 + board/boundary/nitrogen6x/800mhz_4x256mx16.cfg | 37 + Good work, I really like this series. I managed to test it and added support for a mx6dl board. I would like to suggest if you could move the different memory inits (like 800mhz_4x256mx16.cfg) into a common directory so that other boards can pull their DDR init from there when possible. Do you think we still can make this go into 2013.04? Thanks, Fabio Estevam ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH] Add support for Boundary Devices Nitrogen6x boards
Thanks for the review Fabio, On 03/08/2013 03:49 PM, Fabio Estevam wrote: Hi Eric, On Wed, Jan 30, 2013 at 4:10 PM, Eric Nelson eric.nel...@boundarydevices.com wrote: This patch adds support for the Nitrogen6X board(s) from Boundary Devices. The boards are based on the i.MX6x processor family with two major variants: i.MX6Quad/6Dual i.MX6Dual-Lite/6Solo board/boundary/nitrogen6x/800mhz_2x128mx16.cfg | 37 + board/boundary/nitrogen6x/800mhz_2x256mx16.cfg | 37 + board/boundary/nitrogen6x/800mhz_4x128mx16.cfg | 37 + board/boundary/nitrogen6x/800mhz_4x256mx16.cfg | 37 + Good work, I really like this series. Glad to hear it. I managed to test it and added support for a mx6dl board. I would like to suggest if you could move the different memory inits (like 800mhz_4x256mx16.cfg) into a common directory so that other boards can pull their DDR init from there when possible. Okay, but this might be a bit of a stretch. We went through a lot of our SABRE Lite, Nitrogen6x, and Nitrogen6x SOM boards to select the right median values for the termination values and such. These may not apply for other boards, so another level of indirection might be appropriate. IOW, while most of the registers in the files like 800mhz_4x256mx16.cfg are for the memory **arrangement**, some of them are or could be specific to the layout and PCB fabrication details. Do you think we still can make this go into 2013.04? Yep. Now that this guy at Freescale fixed up the HDMI stuff, I can even re-send the HDMI detect patch ;) I'll send V2 tomorrow. Regards, Eric ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v7 07/31] Define CONFIG_SYS_LEGACY_BOARD everywhere
Hi Wolfgang, On Fri, Mar 8, 2013 at 12:31 AM, Wolfgang Denk w...@denx.de wrote: Dear Simon Glass, In message 1362715633-20556-8-git-send-email-...@chromium.org you wrote: We are introducing a new unified board setup and we want this to be the default. So we need to opt all architectures out first. ... +- CONFIG_SYS_LEGACY_BOARD + This option should not be defined by board config files. + This is an internal CONFIG defined by architectures which do not + support CONFIG_SYS_GENERIC_BOARD. It is used as a check that boards + don't accidentally define CONFIG_SYS_GENERIC_BOARD when their + architecture cannot support it, and U-Boot would then either not + build or not work. When an architecture supports generic board, + then CONFIG_SYS_LEGACY_BOARD can be removed from the architecture's + config.mk file so that generic board becomes available. Hm... I understand that you selected the ...LEGACY_BOARD name to make it easy to see the relation to ...GENERIC_BOARD? But then, the name is misleading - if my understanding is correct, then ...LEGACY_BOARD is NOT a _board_ specific config option, but an _architecture_ speci- fic one. That's right. Actually this is then not a real CONFIG_SYS_ thing at all. Should we rather use something like __HAVE_ARCH_GENERIC_BOARD ?? This would also make clear this is an internal macro only. Yes, I will do that. It switches the meaning to positive, but there is no sense in it being the 'default' right now anyway. Since it doesn't start with CONFIG_ I will have to define it in the Makefile, since it won't appear in autoconf.mk, but that is fine too, since only Makefiles will reference it. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v8 07/31] __HAVE_ARCH_GENERIC_BOARD controls availabilty of generic board
We are introducing a new unified board setup. Add a check to make sure that board config files do not define CONFIG_SYS_GENERIC_BOARD unless their architecture defines __HAVE_ARCH_GENERIC_BOARD __HAVE_ARCH_GENERIC_BOARD will currently not be the default setting, but we can switch this later when most architecture support generic board. Signed-off-by: Simon Glass s...@chromium.org --- Changes in v8: - Switch polarity: !CONFIG_SYS_LEGACY_BOARD becomes __HAVE_ARCH_GENERIC_BOARD Changes in v7: - Add description of CONFIG_SYS_LEGACY_BOARD to README Changes in v6: None Changes in v5: None Changes in v4: None Changes in v3: None Changes in v2: None README| 10 ++ config.mk | 8 2 files changed, 18 insertions(+) diff --git a/README b/README index 42544ce..2c36e00 100644 --- a/README +++ b/README @@ -3211,6 +3211,16 @@ Configuration Settings: If defined, don't allow the -f switch to env set override variable access flags. +- CONFIG_SYS_GENERIC_BOARD + This selects the architecture-generic board system instead of the + architecture-specific board files. It is intended to move boards + to this new framework over time. Defining this will disable the + arch/foo/lib/board.c file and use common/board_f.c and + common/board_r.c instead. To use this option your architecture + must support it (i.e. must define __HAVE_ARCH_GENERIC_BOARD in + its config.mk file). If you find problems enabling this option on + your board please report the problem and send patches! + The following definitions that deal with the placement and management of environment data (variable area); in general, we support the following configurations: diff --git a/config.mk b/config.mk index b7cd481..9886415 100644 --- a/config.mk +++ b/config.mk @@ -221,6 +221,14 @@ ifeq ($(CONFIG_SPL_BUILD),y) CPPFLAGS += -DCONFIG_SPL_BUILD endif +# Does this architecture support generic board init? +ifeq ($(__HAVE_ARCH_GENERIC_BOARD),) +ifneq ($(CONFIG_SYS_GENERIC_BOARD),) +$(error Your architecture does not support generic board. Please undefined \ +CONFIG_SYS_GENERIC_BOARD in your board config file) +endif +endif + ifneq ($(RESET_VECTOR_ADDRESS),) CPPFLAGS += -DRESET_VECTOR_ADDRESS=$(RESET_VECTOR_ADDRESS) endif -- 1.8.1.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v8 13/31] arm: Enable generic board support
This enables generic board support so that ARM boards can define
CONFIG_SYS_GENERIC_BOARD.
Signed-off-by: Simon Glass s...@chromium.org
---
Changes in v8:
- Define __HAVE_ARCH_GENERIC_BOARD in ARM's config.mk
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None
arch/arm/config.mk| 3 +++
arch/arm/include/asm/u-boot.h | 9 +
arch/arm/lib/Makefile | 3 +++
3 files changed, 15 insertions(+)
diff --git a/arch/arm/config.mk b/arch/arm/config.mk
index 24b9d7c..a0c89b7 100644
--- a/arch/arm/config.mk
+++ b/arch/arm/config.mk
@@ -31,6 +31,9 @@ CONFIG_STANDALONE_LOAD_ADDR = 0xc10
endif
endif
+# Support generic board on ARM
+__HAVE_ARCH_GENERIC_BOARD := y
+
PLATFORM_CPPFLAGS += -DCONFIG_ARM -D__ARM__
# Choose between ARM/Thumb instruction sets
diff --git a/arch/arm/include/asm/u-boot.h b/arch/arm/include/asm/u-boot.h
index 2ba98bc..8e7e27b 100644
--- a/arch/arm/include/asm/u-boot.h
+++ b/arch/arm/include/asm/u-boot.h
@@ -36,6 +36,12 @@
#ifndef _U_BOOT_H_
#define _U_BOOT_H_ 1
+#ifdef CONFIG_SYS_GENERIC_BOARD
+/* Use the generic board which requires a unified bd_info */
+#include asm-generic/u-boot.h
+#else
+
+#ifndef __ASSEMBLY__
typedef struct bd_info {
unsigned intbi_baudrate;/* serial console baudrate */
ulong bi_arch_number; /* unique id for this board */
@@ -49,6 +55,9 @@ typedef struct bd_info {
ulong size;
} bi_dram[CONFIG_NR_DRAM_BANKS];
} bd_t;
+#endif
+
+#endif /* nCONFIG_SYS_GENERIC_BOARD */
/* For image.h:image_check_target_arch() */
#define IH_ARCH_DEFAULT IH_ARCH_ARM
diff --git a/arch/arm/lib/Makefile b/arch/arm/lib/Makefile
index 57111af..24c7e7a 100644
--- a/arch/arm/lib/Makefile
+++ b/arch/arm/lib/Makefile
@@ -39,7 +39,10 @@ GLCOBJS += div0.o
SOBJS-y += crt0.o
ifndef CONFIG_SPL_BUILD
+ifndef CONFIG_SYS_GENERIC_BOARD
COBJS-y+= board.o
+endif
+
COBJS-y+= bootm.o
COBJS-$(CONFIG_SYS_L2_PL310) += cache-pl310.o
SOBJS-$(CONFIG_USE_ARCH_MEMSET) += memset.o
--
1.8.1.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v8 17/31] ppc: Enable generic board support
This enables generic board support so that ppc boards can define
CONFIG_SYS_GENERIC_BOARD.
Signed-off-by: Simon Glass s...@chromium.org
---
Changes in v8:
- Define __HAVE_ARCH_GENERIC_BOARD in PPC's config.mk
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None
arch/powerpc/config.mk| 3 +++
arch/powerpc/include/asm/u-boot.h | 7 +++
arch/powerpc/lib/Makefile | 2 ++
3 files changed, 12 insertions(+)
diff --git a/arch/powerpc/config.mk b/arch/powerpc/config.mk
index b706281..e32d2bf 100644
--- a/arch/powerpc/config.mk
+++ b/arch/powerpc/config.mk
@@ -29,6 +29,9 @@ PLATFORM_RELFLAGS += -fpic -mrelocatable -ffunction-sections
-fdata-sections
PLATFORM_CPPFLAGS += -DCONFIG_PPC -D__powerpc__
PLATFORM_LDFLAGS += -n
+# Support generic board on PPC
+__HAVE_ARCH_GENERIC_BOARD := y
+
#
# When cross-compiling on NetBSD, we have to define __PPC__ or else we
# will pick up a va_list declaration that is incompatible with the
diff --git a/arch/powerpc/include/asm/u-boot.h
b/arch/powerpc/include/asm/u-boot.h
index 7229a98..951dd6a 100644
--- a/arch/powerpc/include/asm/u-boot.h
+++ b/arch/powerpc/include/asm/u-boot.h
@@ -34,6 +34,11 @@
* include/asm-ppc/u-boot.h
*/
+#ifdef CONFIG_SYS_GENERIC_BOARD
+/* Use the generic board which requires a unified bd_info */
+#include asm-generic/u-boot.h
+#else
+
#ifndef __ASSEMBLY__
typedef struct bd_info {
@@ -144,6 +149,8 @@ typedef struct bd_info {
#endif /* __ASSEMBLY__ */
+#endif /* nCONFIG_SYS_GENERIC_BOARD */
+
/* For image.h:image_check_target_arch() */
#define IH_ARCH_DEFAULT IH_ARCH_PPC
diff --git a/arch/powerpc/lib/Makefile b/arch/powerpc/lib/Makefile
index 86cf02a..59c723b 100644
--- a/arch/powerpc/lib/Makefile
+++ b/arch/powerpc/lib/Makefile
@@ -59,8 +59,10 @@ SOBJS-y += reloc.o
COBJS-$(CONFIG_BAT_RW) += bat_rw.o
ifndef CONFIG_SPL_BUILD
+ifndef CONFIG_SYS_GENERIC_BOARD
COBJS-y+= board.o
endif
+endif
COBJS-y+= bootm.o
COBJS-y+= cache.o
COBJS-y+= extable.o
--
1.8.1.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v8 21/31] x86: Enable generic board support
This enables generic board support so that x86 boards can define
CONFIG_SYS_GENERIC_BOARD.
Signed-off-by: Simon Glass s...@chromium.org
---
Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in v5:
- Avoid setting up gd on x86 as it is already done
Changes in v4: None
Changes in v3: None
Changes in v2: None
arch/x86/include/asm/u-boot.h | 11 +++
arch/x86/lib/Makefile | 3 +++
common/board_r.c | 2 ++
3 files changed, 16 insertions(+)
diff --git a/arch/x86/include/asm/u-boot.h b/arch/x86/include/asm/u-boot.h
index 2f45c7b..19c038a 100644
--- a/arch/x86/include/asm/u-boot.h
+++ b/arch/x86/include/asm/u-boot.h
@@ -39,6 +39,13 @@
#include config.h
#include compiler.h
+#ifdef CONFIG_SYS_GENERIC_BOARD
+/* Use the generic board which requires a unified bd_info */
+#include asm-generic/u-boot.h
+#else
+
+#ifndef __ASSEMBLY__
+
typedef struct bd_info {
unsigned long bi_memstart;/* start of DRAM memory */
phys_size_t bi_memsize; /* size of DRAM memory in bytes */
@@ -60,6 +67,10 @@ typedef struct bd_info {
}bi_dram[CONFIG_NR_DRAM_BANKS];
} bd_t;
+#endif /* __ASSEMBLY__ */
+
+#endif /* nCONFIG_SYS_GENERIC_BOARD */
+
/* For image.h:image_check_target_arch() */
#define IH_ARCH_DEFAULT IH_ARCH_I386
diff --git a/arch/x86/lib/Makefile b/arch/x86/lib/Makefile
index 9b24dc5..ee89354 100644
--- a/arch/x86/lib/Makefile
+++ b/arch/x86/lib/Makefile
@@ -25,7 +25,10 @@ include $(TOPDIR)/config.mk
LIB= $(obj)lib$(ARCH).o
+ifeq ($(CONFIG_SYS_GENERIC_BOARD),)
COBJS-y+= board.o
+endif
+
COBJS-y+= bootm.o
COBJS-y+= cmd_boot.o
COBJS-y+= gcc.o
diff --git a/common/board_r.c b/common/board_r.c
index 29eccdf..230887d 100644
--- a/common/board_r.c
+++ b/common/board_r.c
@@ -509,11 +509,13 @@ static int show_model_r(void)
#endif
/* enable exceptions */
+#ifdef CONFIG_ARM
static int initr_enable_interrupts(void)
{
enable_interrupts();
return 0;
}
+#endif
#ifdef CONFIG_CMD_NET
static int initr_ethaddr(void)
--
1.8.1.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 00/12] cmd_sf: Add support for read and write instructions
Hi, On Sat, Mar 2, 2013 at 12:29 AM, Jagan Teki jagannadh.t...@gmail.comwrote: Hi All, On Fri, Jan 11, 2013 at 7:46 AM, Simon Glass s...@chromium.org wrote: Hi Jagannadha, On Mon, Dec 31, 2012 at 3:13 AM, Jagannadha Sutradharudu Teki jagannadh.t...@gmail.com wrote: All these patches are added a support for read and write instruction for programming/reading SPI flash. I think this is all great and very useful - since no one else has commented I will have a try. Read and Write instruction are implemented as a command line arguments for 'sf write' , 'sf read' and 'sf update' commands. Currently I have added below instructions those are commonly available on all flash types. Maybe you could use flags like -d for dual, -q for quad, -p for page, -s for slow, -o for output only. So maybe: -p pp - Page Program (existing one) -qp qpp - Quad-input Page Program empty afr - Array Fast Read (existing one) -s asr - Array Slow Read -do dofr - Dual Output Fast Read -qo qofr - Quad Output Fast Read -d diofr - Dual IO Fast Read -q qiofr - Quad IO Fast Read I worry that your scheme would be hard to remember. I have tested mostly of the instruction on real h/w. This entire implementation will change the current sf framework little bit but I thought these changes are worth to add. Yes very much so. Request for all your comment, so-that I can move forward. Please let me know for any issue regarding this new implementation. Regards, Simon Thanks, Jagan. Jagannadha Sutradharudu Teki (12): cmd_sf: Add wr_inst argument to 'sf write' command cmd_sf: Add rd_inst argument to 'sf read' command cmd_sf: Add wr_inst argument to 'sf update' command cmd_sf: Add rd_inst argument to 'sf update' command cmd_sf: Define a functions for parsing read and write instructions cmd_sf: Add QPP(Quad-input Page Program) write instruction support cmd_sf: Add ASR(Array Slow Read) read instruction support cmd_sf: Add DOFR(Dual Output Fast Read) read instruction support cmd_sf: Add QOFR(Quad Output Fast Read) read instruction support cmd_sf: Add DIOFR(Dual IO Fast Read) read instruction support cmd_sf: Add QIOFR(Quad IO Fast Read) read instruction support sf: Pass rd_qeb_req variable as 0 for status and config reg reads common/cmd_sf.c | 198 +- drivers/mtd/spi/spi_flash.c | 40 +-- drivers/mtd/spi/spi_flash_internal.h | 10 +- include/spi_flash.h | 22 ++-- include/spi_flash_inst.h | 39 +++ 5 files changed, 257 insertions(+), 52 deletions(-) create mode 100644 include/spi_flash_inst.h Since these changes I have sent long back, I am just re-modified the framework to add new features at the same time with backward comparability for current commands. Current command setup: sf write sf read sf update Changed command set: [no changes in the argument count] sf write --- current command sf write.pp -- same as sf write sf write.qp -- quad program sf read -- current read sf read.af --- array flast read, same as sf read sf read.as -- array slow read sf read.do --- dual out sf read.qo -- quad out sf read.dio -- dual io sf read.qio -- quad io sf update -- current update sf update.pp.af -- write page program, read array fast, same as sf update sf update.pp.as - write page program, read array slow sf update.pp.do - write page program, read dual out sf update.pp.qo - write page program, read quad out sf update.pp.dio - write page program, read dual io sf update.pp.qio - write page program, read quad io sf update.qp.af - write quad program, read array fast sf update.qp.as - write quad program, read array slow sf update.qp.do - write quad program, read dual out sf update.qp.qo - write quad program, read quad out sf update.qp.dio - write quad program, read dual io sf update.qp.qio - write quad program, read quad io Though it seems to be lengthy, but may useful with lot of combinations from user. My intention is to use the existing argument count with changes in the command set. Request for your inputs. I think your new scheme sounds reasonable. Regarding the capability of drivers to support these commands, I suppose you are going to need to add new spi_slave flags which drivers can set, to indicate that each mode is available? Still, the question is whether these modes are selected at 'sf probe' time, or at 'sf read/write' time? The latter is more flexible and makes it easier for cases where you must use one more for read and another for write (no need to probe again in between). But you will then need to add flags to spi_setup_slave() for these modes, right? Regards, Simon Thanks, Jagan. ___ U-Boot mailing list U-Boot@lists.denx.de
Re: [U-Boot] [PATCH] powerpc: fix 8xx and 82xx type-punning warnings with GCC 4.7
On 03/08/2013 03:16:52 PM, Wolfgang Denk wrote: Dear Scott, In message 1357696756-31079-1-git-send-email-scottw...@freescale.com you wrote: C99's strict aliasing rules are insane to use in low-level code such as a bootloader, but as Wolfgang has rejected -fno-strict-aliasing in the past, add a union so that 16-bit accesses can be performed. Sorry, I saw this patch only after re-inventing the fix for 8xx. #ifdef CONFIG_HARD_I2C - *((unsigned short*)(immr-im_dprambase[PROFF_I2C_BASE])) = 0; + immr-im_dprambase16[PROFF_I2C_BASE / 2] = 0; I have to admit that I dislike this approach pretty much. I think we agree that, if we attempted to play strictly by the rules, this code should probably rewritten using C structs and proper I/O accessors. But then, both 8xx and 82xx are essentially dead horses, and I guess you have no more enthusiasm in cleaning up that old code than me. So let's ignore that for now. Yeah. Especially since I don't have easy access to hardware to test this stuff, I wanted to be as conservative as possible with the changes, to just address the build breakage. But this ...[OFFSET / 2] is basicly unreadable. Can we please at least make this ...[OFFSET / sizeof(u16)] so the reader gets a hint of where this is coming from? OK. --- a/arch/powerpc/cpu/mpc8xx/cpu.c +++ b/arch/powerpc/cpu/mpc8xx/cpu.c @@ -79,7 +79,7 @@ static int check_CPU (long clock, uint pvr, uint immr) if ((pvr 16) != 0x0050) return -1; - k = (immr 16) | *((ushort *) immap-im_cpm.cp_dparam[0xB0]); + k = (immr 16) | immap-im_cpm.cp_dparam16[0xB0 / 2]; m = 0; suf = ; @@ -195,7 +195,7 @@ static int check_CPU (long clock, uint pvr, uint immr) if ((pvr 16) != 0x0050) return -1; - k = (immr 16) | *((ushort *) immap-im_cpm.cp_dparam[0xB0]); + k = (immr 16) | in_be16((ushort *)immap-im_cpm.cp_dparam[0xB0]); Now this is very inconsistent - you convert the very same code line in very different ways here. Please don't. Sorry -- I started to use the accessor approach, and then changed my mind, and some of that accidentally leaked through. Is there any specific reason you did not use a similar approach of using in_be16() in the other locations? Actually I feel this is still the most readable version - I prefer this, even though it clashes with the style of the rest of the code. Besides the issue of so much else not using accessors -- I certainly didn't want to get asked to convert the entire thing :-) -- switching to an I/O accessor would change the generated code slightly, and I wanted to avoid that since I can't test it. It also doesn't really address the problem -- it's still type-punning, just not noticed by the compiler due to how in_be16() is implemented. I'm not sure why this is acceptable but -fno-strict-aliasing isn't. Oh, and can we please get rid of this magic number 0xB0 here, and introduce PROFF_REVNUM like we do everywhere else? I suppose, though again I'd rather not get into doing random cleanups on this code. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, v2] env: don't generate callback list entries for SPL
On 03/08/2013 02:59:47 PM, Tom Rini wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/08/2013 03:34 PM, Scott Wood wrote: On 03/08/2013 02:27:48 PM, Tom Rini wrote: On Thu, Dec 20, 2012 at 11:51:05AM -, Scott Wood wrote: SPL doesn't write to the environment. These list entries prevent the functions from being garbage-collected, even though nothing will look at the list. This caused several SPL builds (e.g. P2020RDB-PC_NAND) to break due to size limitations and/or unresolved symbols. A static inline function is used to provide a context in which we can consume the callback, and thus avoid unused function warnings. Signed-off-by: Scott Wood scottw...@freescale.com Acked-by: Joe Hershberger joe.hershber...@gmail.com Acked-by: Kim Phillips kim.phill...@freescale.com OK, this isn't quite right. On am335x_evm where SPL does use the full version of the environment, rather than the restricted version that say a3m071 we need these these callbacks to be generated. We usually build successfully since in these cases our #include of u-boot.lst picks up the one in include that the main SPL generates. But with enough cores we build SPL before we build this list for non-SPL, and the build fails. I shall submit a patch shortly for this. What does am335x_evm do in the SPL that requires modifying the environment, and how does omitting the callbacks cause a build break? It requires the full network stack which in turn means we can't just discard most of the environment related functions. And some parts of the callback infrastructure aren't opt-in'able. I still don't follow -- the only effect of this patch should be that the callbacks don't get called, which is only relevant when writing to the environment. We're not ripping out anything, just declining to reference the callback functions. If something else still references them, they'll be retained. The u-boot.lst issue sounds unrelated to this patch. The problem is undefined references at link time to _u_boot_env_clbk__start/__end from common/env_callbacks.c where it tries to look at our empty list of callbacks (we are able to discard all of those). Why would eliminating all individual callbacks cause start/end to go away? If that's the way the list mechanism works, the mechanism needs fixing. And part of the issue is that we're always using the wrong u-boot.lst file for SPL. It's just that in most cases the wrong one (the main U-Boot one) is also fine enough for SPL since it's just a few extra symbols and we aren't so constrained for space that we've noticed. That sounds familiar: a6d0f62a0ccac7669b1efe320e28c276b1b8084b :-) -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 4/9] nand: Extend nand_(read|write)_skip_bad with *actual and limit parameters
On 03/08/2013 11:37:23 AM, Tom Rini wrote: We make these two functions take a size_t pointer to how much space was used on NAND to read or write the buffer (when reads/writes happen) so that bad blocks can be accounted for. We also make them take an loff_t limit on how much data can be read or written. This means that we can now catch the case of when writing to a partition would exceed the partition size due to bad blocks. To do this we also need to make check_skip_len count not just complete blocks used but partial ones as well. All callers of nand_(read|write)_skip_bad are adjusted to call these with the most sensible limits available. The changes were started by Pantelis and finished by Tom. Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com Signed-off-by: Tom Rini tr...@ti.com --- Changes in v5: None Changes in v4: - Further reword nand_util.c comments, from Scott - In nand_write_skip_bad make sure *actual is 0 for YAFFS2 errors too, reminded by Scott. - In cmd_nand.c don't drop the size is less than maxsize check in arg_off_size as other nand functions need this still (Scott). Changes in v3: - Reworked skip_check_len changes to just add accounting for *used to the logic. - Allow for actual to be NULL in nand_(read|write)_skip_bad, only DFU calls this with a non-NULL parameter. Make sure the comments for both functions explain the parameters and their behavior. - Other style changes requested by Scott. - As nand_(write|read)_skip_bad passes back just a used length now. Changes in v2: - NAND skip_check_len changes reworked to allow nand_(read|write)_skip_bad to return this information to the caller. common/cmd_nand.c| 53 ++-- common/env_nand.c|3 +- drivers/mtd/nand/nand_util.c | 68 +- include/nand.h |4 +-- 4 files changed, 95 insertions(+), 33 deletions(-) Acked-by: Scott Wood scottw...@freescale.com -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 6/9] dfu: NAND specific routines for DFU operation
On 03/08/2013 11:37:25 AM, Tom Rini wrote:
From: Pantelis Antoniou pa...@antoniou-consulting.com
Support for NAND storage devices to work with the DFU framework.
Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com
Signed-off-by: Tom Rini tr...@ti.com
---
Changes in v5:
- Document CONFIG_DFU_NAND in README
Changes in v4: None
Changes in v3:
- Rework logic in nand_block_op for nand_(read|write)_skip_bad
returning
just a size for actual used length.
- Remove unused externs from drivers/dfu/dfu_nand.c
Changes in v2:
- nand_block_op calls nand_(read|write)_skip_bad directly.
- Bugfix in dfu_nand to make sure we set dfu-skip_bad to 0 on each
iteration.
README |3 +
drivers/dfu/Makefile |1 +
drivers/dfu/dfu.c |8 ++
drivers/dfu/dfu_nand.c | 195
include/dfu.h | 23 ++
5 files changed, 230 insertions(+)
create mode 100644 drivers/dfu/dfu_nand.c
diff --git a/README b/README
index 154b82f..c70251e 100644
--- a/README
+++ b/README
@@ -1338,6 +1338,9 @@ The following options need to be configured:
CONFIG_DFU_MMC
This enables support for exposing (e)MMC devices via
DFU.
+ CONFIG_DFU_NAND
+ This enables support for exposing NAND devices via DFU.
+
CONFIG_SYS_DFU_MAX_FILE_SIZE
When updating files rather than the raw storage device,
we use a static buffer to copy the file into and then
write
diff --git a/drivers/dfu/Makefile b/drivers/dfu/Makefile
index 7b717bc..153095d 100644
--- a/drivers/dfu/Makefile
+++ b/drivers/dfu/Makefile
@@ -27,6 +27,7 @@ LIB = $(obj)libdfu.o
COBJS-$(CONFIG_DFU_FUNCTION) += dfu.o
COBJS-$(CONFIG_DFU_MMC) += dfu_mmc.o
+COBJS-$(CONFIG_DFU_NAND) += dfu_nand.o
SRCS:= $(COBJS-y:.o=.c)
OBJS := $(addprefix $(obj),$(COBJS-y))
diff --git a/drivers/dfu/dfu.c b/drivers/dfu/dfu.c
index 2fecf77..84139bd 100644
--- a/drivers/dfu/dfu.c
+++ b/drivers/dfu/dfu.c
@@ -86,6 +86,7 @@ int dfu_write(struct dfu_entity *dfu, void *buf,
int size, int blk_seq_num)
/* initial state */
dfu-crc = 0;
dfu-offset = 0;
+ dfu-bad_skip = 0;
dfu-i_blk_seq_num = 0;
dfu-i_buf_start = dfu_buf;
dfu-i_buf_end = dfu_buf + sizeof(dfu_buf);
@@ -235,6 +236,8 @@ int dfu_read(struct dfu_entity *dfu, void *buf,
int size, int blk_seq_num)
dfu-i_buf = dfu-i_buf_start;
dfu-b_left = 0;
+ dfu-bad_skip = 0;
+
dfu-inited = 1;
}
@@ -264,6 +267,8 @@ int dfu_read(struct dfu_entity *dfu, void *buf,
int size, int blk_seq_num)
dfu-i_buf = dfu-i_buf_start;
dfu-b_left = 0;
+ dfu-bad_skip = 0;
+
dfu-inited = 0;
}
@@ -286,6 +291,9 @@ static int dfu_fill_entity(struct dfu_entity
*dfu, char *s, int alt,
if (strcmp(interface, mmc) == 0) {
if (dfu_fill_entity_mmc(dfu, s))
return -1;
+ } else if (strcmp(interface, nand) == 0) {
+ if (dfu_fill_entity_nand(dfu, s))
+ return -1;
} else {
printf(%s: Device %s not (yet) supported!\n,
__func__, interface);
diff --git a/drivers/dfu/dfu_nand.c b/drivers/dfu/dfu_nand.c
new file mode 100644
index 000..b7f60dd
--- /dev/null
+++ b/drivers/dfu/dfu_nand.c
@@ -0,0 +1,195 @@
+/*
+ * dfu_nand.c -- DFU for NAND routines.
+ *
+ * Copyright (C) 2012-2013 Texas Instruments, Inc.
+ *
+ * Based on dfu_mmc.c which is:
+ * Copyright (C) 2012 Samsung Electronics
+ * author: Lukasz Majewski l.majew...@samsung.com
+ *
+ * This program is free software; you can redistribute it and/or
modify
+ * it under the terms of the GNU General Public License as published
by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA
02111-1307 USA
+ */
+
+#include common.h
+#include malloc.h
+#include errno.h
+#include div64.h
+#include dfu.h
+#include linux/mtd/mtd.h
+#include jffs2/load_kernel.h
+#include nand.h
+
+enum dfu_nand_op {
+ DFU_OP_READ = 1,
+ DFU_OP_WRITE,
+};
+
+static int nand_block_op(enum dfu_nand_op op, struct dfu_entity *dfu,
+ u64 offset, void *buf, long *len)
+{
+ loff_t start;
+ size_t count, actual;
+ int ret;
+ int dev;
+ nand_info_t
Re: [U-Boot] Atheros ART data crc calculation
Hi, We need your help on this question, we had the same problem, did you figure out how the CRC was calculated to the device? This is very important. Can you help me on this? -- View this message in context: http://u-boot.10912.n7.nabble.com/Re-Atheros-ART-data-crc-calculation-tp143096p149334.html Sent from the U-Boot mailing list archive at Nabble.com. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Add U_BOOT_TIMESTAMP definition
Dear Matt, In message 1345733053-5023-1-git-send-email-m...@genesi-usa.com you wrote: This gives us a string like 20120822150855 which encodes the build time. This allows automated version checking and flashing of U-Boot to be performed, for example, in boot.scr files (or scripting in general). I just noticed that this was never applied. Sorry... Makefile |1 + 1 file changed, 1 insertion(+) diff --git a/Makefile b/Makefile index 1df4c1d..c042206 100644 --- a/Makefile +++ b/Makefile @@ -664,6 +664,7 @@ $(TIMESTAMP_FILE): @mkdir -p $(dir $(TIMESTAMP_FILE)) @LC_ALL=C date +'#define U_BOOT_DATE %b %d %C%y' $@.tmp @LC_ALL=C date +'#define U_BOOT_TIME %T' $@.tmp + @LC_ALL=C date +'#define U_BOOT_TIMESTAMP %Y%m%d%H%M%S' $@.tmp @cmp -s $@ $@.tmp rm -f $@.tmp || mv -f $@.tmp $@ But then - you only add a new #define to the build environment, without any users of it, i. e. dead code. Did you intend to post any code that would use this (in this case these patches should be merged into one, or at least into a series), or can we simply drop this 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 Great teachers have small audiences while they are still alive. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/7] omap mmc: implement card detect and write protection
Hi guys, This patch set is floating already for _three_ months. All comments were addressed, it introduces negative diff stat, and provides two useful features (also for production automation). Andy hasn't been responding for quite a while. I think this patch set is good enough for merging. There is no reason for it to float any longer. Please, merge it either via Tom's tree or anyone else's staging. Thanks! On 12/03/12 14:19, Nikita Kiryanov wrote: This patchset implements card detection and write protection check for omap mmc. The write protect implementation also adds generic code that is usable by other mmc drivers. The first 3 patches are preparation patches that contain general maintenance for omap mmc driver. This patchset depends on http://patchwork.ozlabs.org/patch/202384/ Nikita Kiryanov (7): omap: consolidate common mmc definitions omap_hsmmc: fix out of bounds array access omap_hsmmc: introduce omap_hsmmc_data struct omap_hsmmc: implement driver check for card detection cm-t35: implement board specific card detect check mmc: add support for write protection omap_hsmmc: add driver check for write protection arch/arm/cpu/armv7/am33xx/board.c |4 +- arch/arm/cpu/armv7/omap-common/boot-common.c|4 +- arch/arm/cpu/armv7/omap3/board.c|4 +- arch/arm/include/asm/arch-am33xx/mmc_host_def.h | 140 +-- arch/arm/include/asm/arch-omap3/mmc_host_def.h | 139 +-- arch/arm/include/asm/arch-omap4/mmc_host_def.h | 140 +-- arch/arm/include/asm/arch-omap5/mmc_host_def.h | 140 +-- arch/arm/include/asm/omap_mmc.h | 168 +++ board/cm_t35/cm_t35.c | 13 +- board/comelit/dig297/dig297.c |3 +- board/corscience/tricorder/tricorder.c |2 +- board/htkw/mcx/mcx.c|2 +- board/isee/igep0020/igep0020.c |3 +- board/isee/igep0030/igep0030.c |3 +- board/logicpd/am3517evm/am3517evm.c |3 +- board/logicpd/omap3som/omap3logic.c |2 +- board/logicpd/zoom1/zoom1.c |3 +- board/logicpd/zoom2/zoom2.c |3 +- board/matrix_vision/mvblx/mvblx.c |4 +- board/nokia/rx51/rx51.c |4 +- board/overo/overo.c |3 +- board/pandora/pandora.c |3 +- board/technexion/twister/twister.c |2 +- board/teejet/mt_ventoux/mt_ventoux.c|2 +- board/ti/am3517crane/am3517crane.c |3 +- board/ti/beagle/beagle.c|3 +- board/ti/evm/evm.c |3 +- board/ti/omap5_evm/evm.c|4 +- board/ti/panda/panda.c |3 +- board/ti/sdp3430/sdp.c |3 +- board/ti/sdp4430/sdp.c |4 +- board/timll/devkit8000/devkit8000.c |3 +- common/cmd_mmc.c|7 + drivers/mmc/arm_pl180_mmci.c|1 + drivers/mmc/bfin_sdh.c |1 + drivers/mmc/davinci_mmc.c |1 + drivers/mmc/fsl_esdhc.c |1 + drivers/mmc/ftsdc010_esdhc.c|1 + drivers/mmc/gen_atmel_mci.c |1 + drivers/mmc/mmc.c | 17 +++ drivers/mmc/mmc_spi.c |1 + drivers/mmc/mxcmmc.c|1 + drivers/mmc/mxsmmc.c|1 + drivers/mmc/omap_hsmmc.c| 78 +-- drivers/mmc/sdhci.c |1 + drivers/mmc/sh_mmcif.c |1 + drivers/mmc/tegra_mmc.c |1 + include/mmc.h |2 + 48 files changed, 324 insertions(+), 612 deletions(-) create mode 100644 arch/arm/include/asm/omap_mmc.h -- Regards, Igor. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
