Re: [U-Boot] Any outstanding ARM pull requests?
Dear Albert, On 8 March 2012 16:29, Stefano Babic wrote: > On 08/03/2012 08:20, Albert ARIBAUD wrote: >> Hi all, >> > > Hi Albert, > >> Which means there are commmits on these repo's master branches that are >> not currently in u-boot-arm. >> >> Are there any ARM pull requests pending that I would have missed or are >> about to be sent? > > On i.MX, yes - I have applied yesterday some fixes. I will send today my > pull request. > > Stefano > I have two commits (or three). I will send the pull request. Thanks :) Minkyu Kang. -- from. prom. www.promsoft.net ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] lib: zlib: update to 1.2.6
Dear Lei Wen, In message you wrote: > > > I wonder which benefits we get for this price we are paying? > > The main reason I'd like to introduce this upgrade is for I want to > add the compressing > feature for uboot. This should be make optional code, including any extensions / additional functions that may be needed for zlib. Most users will not need this, and they should not suffer (in terms of increased memory footprint) from such a change. > And the 1.2.6 has some fix for the deflate, so it > is maybe a good > base line for introducing it. Which exact fix are you referring to? > How about define a Macro like CONIFG_ENABLE_GZIP_COMPRESSION to compile > the compression related code only when this flag is on? This makes sense, but please use standard naming rules. You will probably provide a "zip" command, so make all this depend on "CONFIG_CMD_ZIP" or so. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de It must be remembered that there is nothing more difficult to plan, more doubtful of success, nor more dangerous to manage, than the creation of a new system. For the initiator has the enmity of all who would profit by the preservation of the old institutions and merely lukewarm defenders in those who would gain by the new ones. - Machiavelli ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] (no subject)
Dear Simon Glass, In message you wrote: > > > 01/10 Simon Glass[U-Boot] [PATCH v2 8/8] sandbox: Add > basic > > command line parsing > > http://article.gmane.org/gmane.comp.boot-loaders.u-boot/122324 > > Mike expanded this one significantly - I just acked it. Might stretch > the definition of 'inside merge window'? Initial patch was within merge window; we usually accapt updates, so why not here. > Yes I just cleaned up mine...it would be nice if you could select > multiple patches at the top level and perform actions on them. See the "Create bundle" function - eventually this is what you are looking for? 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 modem is a baudy house. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] lib: zlib: update to 1.2.6
Hi Wolfgang, On Thu, Mar 8, 2012 at 4:13 PM, Wolfgang Denk wrote: > Dear Lei Wen, > > In message > you > wrote: >> >> > I wonder which benefits we get for this price we are paying? >> >> The main reason I'd like to introduce this upgrade is for I want to >> add the compressing >> feature for uboot. > > This should be make optional code, including any extensions / > additional functions that may be needed for zlib. > > Most users will not need this, and they should not suffer (in terms of > increased memory footprint) from such a change. > >> And the 1.2.6 has some fix for the deflate, so it >> is maybe a good >> base line for introducing it. > > Which exact fix are you referring to? I am referring to the zlib 1.2.5->1.2.6 changelog: Added deflatePending() to return the amount of pending output Allow deflateSetDictionary() and inflateSetDictionary() at any time in raw mode deflatePrime() can now insert bits in the middle of the stream > >> How about define a Macro like CONIFG_ENABLE_GZIP_COMPRESSION to compile >> the compression related code only when this flag is on? > > This makes sense, but please use standard naming rules. You will > probably provide a "zip" command, so make all this depend on > "CONFIG_CMD_ZIP" or so. Yep, that is also what I am thinking. > > Best regards, > > Wolfgang Denk Thanks, Lei ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] TQM85xx boards failing on older gcc
Dear Andy, In message you wrote: > > One of my coworkers is seeing these errors with gcc-4.3.74 (eglibc-2.8.74-6): glibc version should be completely irrelevant when building U-Boot. > > Configuring for TQM8548_BE - Board: TQM85xx, Options: > MPC8548,TQM8548_BE=y,HOSTNAME=tqm8548,BOARDNAME="TQM8548_BE" > text data bss dec hex filename > 297931 25840 35848 359619 57cc3 ./u-boot > Configuring for TQM8555 - Board: TQM85xx, Options: > MPC8555,TQM8555=y,HOSTNAME=tqm8555,BOARDNAME="TQM8555" > powerpc-linux-gnu-ld: section .bootpg [f000 -> f407] overlaps > section .data [d9b8 -> f7db] > powerpc-linux-gnu-ld: u-boot: section .bootpg lma 0xf000 overlaps > previous sections > powerpc-linux-gnu-ld: u-boot: section .u_boot_cmd lma 0xf7dc > overlaps previous sections > powerpc-linux-gnu-ld: u-boot: section .resetvec lma 0xfffc > overlaps previous sections > make: *** [u-boot] Error 1 > > > He says the same for TQM8541, TQM8548. I don't see it on my 4.5.55 gcc I confirm that these are known issues. Currently we have no intention to fix these, though. The boards in question have reached EOL and are no longer actively maintained. The problem is - as Stefan correctly diagnosed - caused by increased code size due to some extensions and fixes in recent versions, which do not cuase problems with recent tool chains, but which would require either removal of functionality or changes to the memory map for older tool chains with not so decent code optimizations. We feel that any of these activities would be wasted efforts, so we decided to ignore these issues. In case the boards should break with recent tool chains, I will probably board send removal patches. Thanks Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Prediction is very difficult, especially of the future. - Niels Bohr ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] lib: zlib: update to 1.2.6
Dear Lei Wen, In message you wrote: > > >> And the 1.2.6 has some fix for the deflate, so it > >> is maybe a good > >> base line for introducing it. > > > > Which exact fix are you referring to? > > I am referring to the zlib 1.2.5->1.2.6 changelog: > Added deflatePending() to return the amount of pending output > Allow deflateSetDictionary() and inflateSetDictionary() at any time in > raw mode > deflatePrime() can now insert bits in the middle of the stream Are any of these relevant to U-Boot code? To me it looks more like extensions (which we do not use and thus not need) than bug fixes. But I may be wrong. Do you think it's fixes? 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 Committee, n.: A group of men who individually can do nothing but as a group decide that nothing can be done. - Fred Allen ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] ubifsmount reports "Error reading superblock", but linux can mount FS
>> I've been comparing the linux and u-boot implementations, and it looks >> like the following fix is in the kernel >> but not in u-boot. I don't really understand it, but it looks like a >> candidate. Might porting this change to >> u-boot fix the issue? > > Hard to tell. Might be worth a try, if its not too complicated. It would be > great if you could report the outcome of this. And best to send this patch to > the list as well. > Thanks, I've ported that one changeset to u-boot. (I first tried updating u-boot/fs/ubifs to the latest kernel code but this was too difficult without any real understanding.) Unfortunately I've got to wait for a repro before I can tell if it fixes the issue... so I may go quiet for a few weeks. Regards, Alex ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] ubifsmount reports "Error reading superblock", but linux can mount FS
Hi Alex, On Thursday 08 March 2012 10:49:33 Alex Zeffertt wrote: > >> I've been comparing the linux and u-boot implementations, and it looks > >> like the following fix is in the kernel > >> but not in u-boot. I don't really understand it, but it looks like a > >> candidate. Might porting this change to > >> u-boot fix the issue? > > > > Hard to tell. Might be worth a try, if its not too complicated. It would > > be great if you could report the outcome of this. And best to send this > > patch to the list as well. > > Thanks, I've ported that one changeset to u-boot. (I first tried > updating u-boot/fs/ubifs to the latest kernel code but this was too > difficult without any real understanding.) > > Unfortunately I've got to wait for a repro before I can tell if it > fixes the issue... so I may go quiet for a few weeks. Understood. Thanks for the status update so far. Thanks, Stefan -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-0 Fax: (+49)-8142-66989-80 Email: off...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] EXYNOS: Add structure for Exynos4 DMC
Dear Chander Kashyap, On 2 March 2012 22:25, Chander Kashyap wrote: > Add exynos4_dmc structure in dmc.h for exynos4 dram controllor(DMC). > > Signed-off-by: Chander Kashyap > --- > arch/arm/include/asm/arch-exynos/dmc.h | 109 > > 1 files changed, 109 insertions(+), 0 deletions(-) > applied to u-boot-samsung. Thanks. Minkyu Kang. -- from. prom. www.promsoft.net ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/8 v4] powerpc/corenet_ds: Correct the compilation errors about ENV
When defined CONFIG_ENV_IS_NOWHERE, there will be some compilation errors: ./common/env_nowhere.o: In function `env_relocate_spec': ./common/env_nowhere.c:38: multiple definition of `env_relocate_spec' ./common/env_flash.o: ./common/env_flash.c:326: first defined here ./common/env_nowhere.o: In function `env_get_char_spec': ./common/env_nowhere.c:42: multiple definition of `env_get_char_spec' ./common/env_flash.o:./common/env_flash.c:78: first defined here ./common/env_nowhere.o: In function `env_init': ./common/env_nowhere.c:51: multiple definition of `env_init' ./common/env_flash.o:./common/env_flash.c:237: first defined here make[1]: *** [./common/libcommon.o] Error 1 make[1]: Leaving directory `./common' make: *** [./common/libcommon.o] Error 2 Remove the CONFIG_ENV_IS_IN_FLASH if defined CONFIG_ENV_IS_NOWHERE. Signed-off-by: Liu Gang --- Changes in v2: - Subject changed to "powerpc/corenet_ds". - Change the commit message more clearly. Changes in v3: - No Changes in v4: - No include/configs/corenet_ds.h |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/include/configs/corenet_ds.h b/include/configs/corenet_ds.h index 77dd0a2..fd8291e 100644 --- a/include/configs/corenet_ds.h +++ b/include/configs/corenet_ds.h @@ -97,6 +97,8 @@ #define CONFIG_ENV_IS_IN_NAND #define CONFIG_ENV_SIZECONFIG_SYS_NAND_BLOCK_SIZE #define CONFIG_ENV_OFFSET (5 * CONFIG_SYS_NAND_BLOCK_SIZE) +#elif defined(CONFIG_ENV_IS_NOWHERE) +#define CONFIG_ENV_SIZE0x2000 #else #define CONFIG_ENV_IS_IN_FLASH #define CONFIG_ENV_ADDR(CONFIG_SYS_MONITOR_BASE - CONFIG_ENV_SECT_SIZE) -- 1.7.3.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/8 v4] powerpc/srio: Rewrite the struct ccsr_rio
Rewrite this struct for the support of two ports and two message
units registers.
Signed-off-by: Liu Gang
---
Changes in v2:
- Change the subject and commit message.
- Remove the offsets in the comments.
- Rewrite the struct for the support of two ports
and two message units registers.
Changes in v3:
- Move some SRIO macros to the appropriate board
configure header files.
Changes in v4:
- Move some SRIO macros to the file
arch/powerpc/include/asm/config_mpc85xx.h
arch/powerpc/include/asm/config_mpc85xx.h | 34 +++
arch/powerpc/include/asm/immap_85xx.h | 384 +
2 files changed, 258 insertions(+), 160 deletions(-)
diff --git a/arch/powerpc/include/asm/config_mpc85xx.h
b/arch/powerpc/include/asm/config_mpc85xx.h
index 8654625..94755c5 100644
--- a/arch/powerpc/include/asm/config_mpc85xx.h
+++ b/arch/powerpc/include/asm/config_mpc85xx.h
@@ -65,6 +65,11 @@
#define CONFIG_SYS_FSL_ERRATUM_NMG_DDR120
#define CONFIG_SYS_FSL_ERRATUM_NMG_LBC103
#define CONFIG_SYS_FSL_ERRATUM_NMG_ETSEC129
+#define CONFIG_SYS_FSL_SRIO_MAX_PORTS 1
+#define CONFIG_SYS_FSL_SRIO_OB_WIN_NUM 9
+#define CONFIG_SYS_FSL_SRIO_IB_WIN_NUM 5
+#define CONFIG_SYS_FSL_RMU
+#define CONFIG_SYS_FSL_SRIO_MSG_UNIT_NUM 2
#elif defined(CONFIG_MPC8555)
#define CONFIG_MAX_CPUS1
@@ -85,6 +90,11 @@
#define MAX_QE_RISC2
#define QE_NUM_OF_SNUM 28
#define CONFIG_SYS_CCSRBAR_DEFAULT 0xff70
+#define CONFIG_SYS_FSL_SRIO_MAX_PORTS 1
+#define CONFIG_SYS_FSL_SRIO_OB_WIN_NUM 9
+#define CONFIG_SYS_FSL_SRIO_IB_WIN_NUM 5
+#define CONFIG_SYS_FSL_RMU
+#define CONFIG_SYS_FSL_SRIO_MSG_UNIT_NUM 2
#elif defined(CONFIG_MPC8569)
#define CONFIG_MAX_CPUS1
@@ -94,6 +104,11 @@
#define MAX_QE_RISC4
#define QE_NUM_OF_SNUM 46
#define CONFIG_SYS_CCSRBAR_DEFAULT 0xff70
+#define CONFIG_SYS_FSL_SRIO_MAX_PORTS 1
+#define CONFIG_SYS_FSL_SRIO_OB_WIN_NUM 9
+#define CONFIG_SYS_FSL_SRIO_IB_WIN_NUM 5
+#define CONFIG_SYS_FSL_RMU
+#define CONFIG_SYS_FSL_SRIO_MSG_UNIT_NUM 2
#elif defined(CONFIG_MPC8572)
#define CONFIG_MAX_CPUS2
@@ -298,6 +313,11 @@
#define CONFIG_SYS_CCSRBAR_DEFAULT 0xff70
#define CONFIG_SYS_FSL_ERRATUM_ESDHC111
#define CONFIG_SYS_FSL_ERRATUM_ESDHC_A001
+#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
+#define CONFIG_SYS_FSL_RMU
+#define CONFIG_SYS_FSL_SRIO_MSG_UNIT_NUM 2
#elif defined(CONFIG_PPC_P2040)
#define CONFIG_MAX_CPUS4
@@ -338,6 +358,9 @@
#define CONFIG_SYS_FSL_ERRATUM_ESDHC111
#define CONFIG_SYS_FSL_ERRATUM_CPU_A003999
#define CONFIG_SYS_FSL_ERRATUM_DDR_A003474
+#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
#elif defined(CONFIG_PPC_P3041)
#define CONFIG_MAX_CPUS4
@@ -359,6 +382,9 @@
#define CONFIG_SYS_FSL_ERRATUM_ESDHC111
#define CONFIG_SYS_FSL_ERRATUM_CPU_A003999
#define CONFIG_SYS_FSL_ERRATUM_DDR_A003474
+#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
#elif defined(CONFIG_PPC_P3060)
#define CONFIG_MAX_CPUS8
@@ -417,6 +443,11 @@
#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_MAX_PORTS 2
+#define CONFIG_SYS_FSL_SRIO_OB_WIN_NUM 9
+#define CONFIG_SYS_FSL_SRIO_IB_WIN_NUM 5
+#define CONFIG_SYS_FSL_RMU
+#define CONFIG_SYS_FSL_SRIO_MSG_UNIT_NUM 2
/* P5010 is single core version of P5020 */
#elif defined(CONFIG_PPC_P5010)
@@ -458,6 +489,9 @@
#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_MAX_PORTS 2
+#define CONFIG_SYS_FSL_SRIO_OB_WIN_NUM 9
+#define CONFIG_SYS_FSL_SRIO_IB_WIN_NUM 5
#else
#error Processor type not defined for this platform
diff --git a/arch/powerpc/include/asm/immap_85xx.h
b/arch/powerpc/include/asm/immap_85xx.h
index 9b08cb8..c4d241b 100644
--- a/arch/powerpc/include/asm/immap_85xx.h
+++ b/arch/powerpc/include/asm/immap_85xx.h
@@ -1353,171 +1353,235 @@ typedef struct ccsr_cpm {
} ccsr_cpm_t;
#endif
-/* RapidIO Registers */
-typedef struct ccsr_rio {
- u32 didcar; /* Device Identity Capability */
- u32 dicar; /* Device Information Capability */
- u32 aidcar; /* Assembly Identity Capability */
- u32 aicar; /* Assembly Information Capability */
- u32 pefcar; /* Processing Element Features Capability */
- u32 spicar; /* Switch Port Information Capability */
- u32 socar; /* Source Operations Capability */
-
[U-Boot] [PATCH 3/8 v4] powerpc/corenet_ds: Document for the boot from SRIO
This document describes the implementation of the boot from SRIO, includes the introduction of envionment, an example based on P4080DS platform, an example of the slave's RCW, and the description about how to use this feature. Signed-off-by: Liu Gang --- Changes in v2: - Subject changed to "powerpc/corenet_ds". - Change the name of the document for "corenet" platform. Changes in v3: - No Changes in v4: - No doc/README.srio-boot-corenet | 103 ++ 1 files changed, 103 insertions(+), 0 deletions(-) create mode 100644 doc/README.srio-boot-corenet diff --git a/doc/README.srio-boot-corenet b/doc/README.srio-boot-corenet new file mode 100644 index 000..56b094c --- /dev/null +++ b/doc/README.srio-boot-corenet @@ -0,0 +1,103 @@ +-- +SRIO Boot on Corenet Platforms +-- + +For some PowerPC processors with SRIO interface, boot location can be configured +to SRIO by RCW. The processor booting from SRIO can do without flash for u-boot +image, ucode and ENV. All the images can be fetched from another processor's +memory space by SRIO link connected between them. + +This document describes the processes based on an example implemented on P4080DS +platforms and a RCW example with boot from SRIO configuration. + +Environment of the SRIO boot: + a) Master and slave can be SOCs in one board or SOCs in separate boards. + b) They are connected with SRIO links, whether 1x or 4x, and directly or + through switch system. + c) Only Master has NorFlash for booting, and all the Master's and Slave's + U-Boot images, UCodes will be stored in this flash. + d) Slave has its own EEPROM for RCW and PBI. + e) Slave's RCW should configure the SerDes for SRIO boot port, set the boot + location to SRIO, and holdoff all the cores if needed. + + ----- --- + | | | | | | + | | | | | | + | NorFlash|<->| Master |SRIO | Slave |<>[EEPROM] + | | | |<===>| | + | | | | | | + ----- --- + +The example based on P4080DS platform: + Two P4080DS platforms can be used to implement the boot from SRIO. Their SRIO + ports 0 will be connected directly and will be used for the boot from SRIO. + + 1. Slave's RCW example for boot from SRIO port 0 and core 0 not in holdoff. + : aa55 aa55 010e 0100 0c58 + 0010: 1818 1818 7440 4000 2000 + 0020: f400 0100 + 0030: 0083 + 0040: 0813 8040 698b 93fe + + 2. Slave's RCW example for boot from SRIO port 0 and all cores in holdoff. + : aa55 aa55 010e 0100 0c58 + 0010: 1818 1818 7440 4000 2000 + 0020: f440 0100 + 0030: 0083 + 0040: 0813 8040 063c 778f + + 3. Sequence in Step by Step. + a) Update RCW for slave with boot from SRIO port 0 configuration. + b) Program slave's U-Boot image, UCode, and ENV parameters into master's + NorFlash. + c) Start up master and it will boot up normally from its NorFlash. + Then, it will finish necessary configurations for slave's boot from + SRIO port 0. + d) Master will set inbound SRIO windows covered slave's U-Boot image stored + in master's NorFlash. + e) Master will set an inbound SRIO window covered slave's UCode stored in + master's NorFlash. + f) Master will set an inbound SRIO window covered slave's ENV stored in + master's NorFlash. + g) If need to release slave's core, master will set outbound SRIO windows + in order to configure slave's registers for the core's releasing. + h) If all cores of slave in holdoff, slave should be powered on before all + the above master's steps, and wait to be released by master. If not all + cores in holdoff, that means core 0 will start up normally, slave should + be powered on after all the above master's steps. In the startup phase + of the slave from SRIO, it will finish some necessary configurations. + i) Slave will set a specific TLB entry for the boot process. + j)
[U-Boot] [PATCH 4/8 v4] powerpc/corenet_ds: Master module for boot from SRIO
For the powerpc processors with SRIO interface, boot location can be configured
from SRIO1 or SRIO2 by RCW. The processor booting from SRIO can do without flash
for u-boot image. The image can be fetched from another processor's memory
space by SRIO link connected between them.
The processor boots from SRIO is slave, the processor boots from normal flash
memory space and can help slave to boot from its memory space is master.
They are different environments and requirements:
master:
1. NOR flash for its own u-boot image, ucode and ENV space.
2. Slave's u-boot image in master NOR flash.
3. Normally boot from local NOR flash.
4. Configure SRIO switch system if needed.
slave:
1. Just has EEPROM for RCW. No flash for u-boot image, ucode and ENV.
2. Boot location should be set to SRIO1 or SRIO2 by RCW.
3. RCW should configure the SerDes, SRIO interfaces correctly.
4. Slave must be powered on after master's boot.
For the master module, need to finish these processes:
1. Initialize the SRIO port and address space.
2. Set inbound SRIO windows covered slave's u-boot image stored in
master's NOR flash.
3. Master's u-boot image should be generated specifically by
make _SRIOBOOT_MASTER_config
4. Master must boot first, and then slave can be powered on.
Signed-off-by: Liu Gang
Signed-off-by: Shaohui Xie
---
Changes in v2:
- Subject changed to "powerpc/corenet_ds".
- Use "(void *)" instead of "(u32)" when calling "out_be32()".
- Use "NOR flash" instead of "Nor flash".
- Get rid of the base address + offset notation. Use C structs
instead.
- Get rid of hard coded magic numbers. Use macro instead.
- Use "debug()" instead of "printf()".
Changes in v3:
- No
Changes in v4:
- No
arch/powerpc/cpu/mpc85xx/cpu_init.c |6 ++-
arch/powerpc/cpu/mpc8xxx/srio.c | 51 +++
arch/powerpc/include/asm/fsl_srio.h | 61 +
arch/powerpc/include/asm/immap_85xx.h |3 ++
boards.cfg|3 ++
include/configs/corenet_ds.h | 18 ++
6 files changed, 140 insertions(+), 2 deletions(-)
create mode 100644 arch/powerpc/include/asm/fsl_srio.h
diff --git a/arch/powerpc/cpu/mpc85xx/cpu_init.c
b/arch/powerpc/cpu/mpc85xx/cpu_init.c
index 2e4a06c..97a7fe1 100644
--- a/arch/powerpc/cpu/mpc85xx/cpu_init.c
+++ b/arch/powerpc/cpu/mpc85xx/cpu_init.c
@@ -37,6 +37,7 @@
#include
#include
#include
+#include
#include
#include "mp.h"
#ifdef CONFIG_SYS_QE_FMAN_FW_IN_NAND
@@ -48,8 +49,6 @@
DECLARE_GLOBAL_DATA_PTR;
-extern void srio_init(void);
-
#ifdef CONFIG_QE
extern qe_iop_conf_t qe_iop_conf_tab[];
extern void qe_config_iopin(u8 port, u8 pin, int dir,
@@ -443,6 +442,9 @@ skip_l2:
#ifdef CONFIG_SYS_SRIO
srio_init();
+#ifdef CONFIG_SRIOBOOT_MASTER
+ srio_boot_master();
+#endif
#endif
#if defined(CONFIG_MP)
diff --git a/arch/powerpc/cpu/mpc8xxx/srio.c b/arch/powerpc/cpu/mpc8xxx/srio.c
index e46d328..77fa32f 100644
--- a/arch/powerpc/cpu/mpc8xxx/srio.c
+++ b/arch/powerpc/cpu/mpc8xxx/srio.c
@@ -21,6 +21,10 @@
#include
#include
#include
+#include
+
+#define SRIO_PORT_ACCEPT_ALL 0x1001
+#define SRIO_IB_ATMU_AR 0x80f55000
#if defined(CONFIG_FSL_CORENET)
#define _DEVDISR_SRIO1 FSL_CORENET_DEVDISR_SRIO1
@@ -84,3 +88,50 @@ void srio_init(void)
setbits_be32(&gur->devdisr, _DEVDISR_RMU);
}
}
+
+#ifdef CONFIG_SRIOBOOT_MASTER
+void srio_boot_master(void)
+{
+ struct ccsr_rio *srio = (void *)CONFIG_SYS_FSL_SRIO_ADDR;
+
+ /* set port accept-all */
+ out_be32((void *)&srio->impl.port[CONFIG_SRIOBOOT_MASTER_PORT].ptaacr,
+ SRIO_PORT_ACCEPT_ALL);
+
+ debug("SRIOBOOT - MASTER: Master port [ %d ] for srio boot.\n",
+ CONFIG_SRIOBOOT_MASTER_PORT);
+ /* configure inbound window5 for slave's u-boot image */
+ debug("SRIOBOOT - MASTER: Inbound window 5 for slave's image; "
+ "Local = 0x%llx, Srio = 0x%llx, Size = 0x%x\n",
+ (u64)CONFIG_SRIOBOOT_SLAVE_IMAGE_LAW_PHYS1,
+ (u64)CONFIG_SRIOBOOT_SLAVE_IMAGE_SRIO_PHYS1,
+ CONFIG_SRIOBOOT_SLAVE_IMAGE_SIZE);
+ out_be32((void *)&srio->atmu
+ .port[CONFIG_SRIOBOOT_MASTER_PORT].inbw[0].riwtar,
+ CONFIG_SRIOBOOT_SLAVE_IMAGE_LAW_PHYS1 >> 12);
+ out_be32((void *)&srio->atmu
+ .port[CONFIG_SRIOBOOT_MASTER_PORT].inbw[0].riwbar,
+ CONFIG_SRIOBOOT_SLAVE_IMAGE_SRIO_PHYS1 >> 12);
+ out_be32((void *)&srio->atmu
+ .port[CONFIG_SRIOBOOT_MASTER_PORT].inbw[0].riwar,
+ SRIO_IB_ATMU_AR
+ | atmu_size_mask(CONFIG_SRIOBOOT_SLAVE_IMAGE_SIZE));
+
+ /* configure inbound window4 for
[U-Boot] [PATCH 8/8 v4] powerpc/corenet_ds: Slave core in holdoff when boot from SRIO
When boot from SRIO, slave's core can be in holdoff after powered on for
some specific requirements. Master can release the slave's core at the
right time by SRIO interface.
Master needs to:
1. Set outbound SRIO windows in order to configure slave's registers
for the core's releasing.
2. Check the SRIO port status when release slave core, if no errors,
will implement the process of the slave core's releasing.
Slave needs to:
1. Set all the cores in holdoff by RCW.
2. Be powered on before master's boot.
Signed-off-by: Liu Gang
Signed-off-by: Shaohui Xie
---
Changes in v2:
- Subject changed to "powerpc/corenet_ds".
- Use "(void *)" instead of "(u32)" when calling "out_be32()".
- Use "NOR flash" instead of "Nor flash".
- Get rid of the base address + offset notation. Use C structs
instead.
- Get rid of hard coded magic numbers. Use macro instead.
- Use "debug()" instead of "printf()".
Changes in v3:
- No
Changes in v4:
- No
arch/powerpc/cpu/mpc85xx/cpu_init.c |3 +
arch/powerpc/cpu/mpc8xxx/srio.c | 125 +++
arch/powerpc/include/asm/fsl_srio.h |3 +
include/configs/corenet_ds.h|4 +
4 files changed, 135 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/cpu/mpc85xx/cpu_init.c
b/arch/powerpc/cpu/mpc85xx/cpu_init.c
index 97a7fe1..2cd5db7 100644
--- a/arch/powerpc/cpu/mpc85xx/cpu_init.c
+++ b/arch/powerpc/cpu/mpc85xx/cpu_init.c
@@ -444,6 +444,9 @@ skip_l2:
srio_init();
#ifdef CONFIG_SRIOBOOT_MASTER
srio_boot_master();
+#ifdef CONFIG_SRIOBOOT_SLAVE_HOLDOFF
+ srio_boot_master_release_slave();
+#endif
#endif
#endif
diff --git a/arch/powerpc/cpu/mpc8xxx/srio.c b/arch/powerpc/cpu/mpc8xxx/srio.c
index 5694561..c7f3949 100644
--- a/arch/powerpc/cpu/mpc8xxx/srio.c
+++ b/arch/powerpc/cpu/mpc8xxx/srio.c
@@ -25,6 +25,12 @@
#define SRIO_PORT_ACCEPT_ALL 0x1001
#define SRIO_IB_ATMU_AR 0x80f55000
+#define SRIO_OB_ATMU_AR_MAINT 0x80077000
+#define SRIO_OB_ATMU_AR_RW 0x80045000
+#define SRIO_LCSBA1CSR_OFFSET 0x5c
+#define SRIO_MAINT_WIN_SIZE 0x100 /* 16M */
+#define SRIO_RW_WIN_SIZE 0x10 /* 1M */
+#define SRIO_LCSBA1CSR 0x6000
#if defined(CONFIG_FSL_CORENET)
#define _DEVDISR_SRIO1 FSL_CORENET_DEVDISR_SRIO1
@@ -168,4 +174,123 @@ void srio_boot_master(void)
SRIO_IB_ATMU_AR
| atmu_size_mask(CONFIG_SRIOBOOT_SLAVE_ENV_SIZE));
}
+
+#ifdef CONFIG_SRIOBOOT_SLAVE_HOLDOFF
+void srio_boot_master_release_slave(void)
+{
+ struct ccsr_rio *srio = (void *)CONFIG_SYS_FSL_SRIO_ADDR;
+ u32 escsr;
+ debug("SRIOBOOT - MASTER: "
+ "Check the port status and release slave core ...\n");
+
+ escsr = in_be32((void *)&srio->lp_serial
+ .port[CONFIG_SRIOBOOT_MASTER_PORT].pescsr);
+ if (escsr & 0x2) {
+ if (escsr & 0x10100) {
+ debug("SRIOBOOT - MASTER: Port [ %d ] is error.\n",
+ CONFIG_SRIOBOOT_MASTER_PORT);
+ } else {
+ debug("SRIOBOOT - MASTER: "
+ "Port [ %d ] is ready, now release
slave's core ...\n",
+ CONFIG_SRIOBOOT_MASTER_PORT);
+ /*
+* configure outbound window
+* with maintenance attribute to set slave's LCSBA1CSR
+*/
+ out_be32((void *)&srio->atmu
+ .port[CONFIG_SRIOBOOT_MASTER_PORT]
+ .outbw[1].rowtar, 0);
+ out_be32((void *)&srio->atmu
+ .port[CONFIG_SRIOBOOT_MASTER_PORT]
+ .outbw[1].rowtear, 0);
+ if (CONFIG_SRIOBOOT_MASTER_PORT)
+ out_be32((void *)&srio->atmu
+ .port[CONFIG_SRIOBOOT_MASTER_PORT]
+ .outbw[1].rowbar,
+ CONFIG_SYS_SRIO2_MEM_PHYS >> 12);
+ else
+ out_be32((void *)&srio->atmu
+ .port[CONFIG_SRIOBOOT_MASTER_PORT]
+ .outbw[1].rowbar,
+ CONFIG_SYS_SRIO1_MEM_PHYS >> 12);
+ out_be32((void *)&srio->atmu
+ .port[CONFIG_SRIOBOOT_MASTER_PORT]
+ .outbw[1].rowar,
+ SRIO_OB_ATMU_AR_MAINT
+ | atmu_size_mask(SRIO_MAINT_WIN_SIZE));
+
+ /*
+* configure outbound window
+* with R/W attribute to set slave's BRR
+
[U-Boot] [PATCH 5/8 v4] powerpc/corenet_ds: Slave module for boot from SRIO
For the powerpc processors with SRIO interface, boot location can be configured
from SRIO1 or SRIO2 by RCW. The processor booting from SRIO can do without flash
for u-boot image. The image can be fetched from another processor's memory
space by SRIO link connected between them.
The processor boots from SRIO is slave, the processor boots from normal flash
memory space and can help slave to boot from its memory space is master.
They are different environments and requirements:
master:
1. NOR flash for its own u-boot image, ucode and ENV space.
2. Slave's u-boot image in master NOR flash.
3. Normally boot from local NOR flash.
4. Configure SRIO switch system if needed.
slave:
1. Just has EEPROM for RCW. No flash for u-boot image, ucode and ENV.
2. Boot location should be set to SRIO1 or SRIO2 by RCW.
3. RCW should configure the SerDes, SRIO interfaces correctly.
4. Slave must be powered on after master's boot.
5. Must define CONFIG_SYS_QE_FMAN_FW_IN_REMOTE because of no ucode
locally.
For the slave module, need to finish these processes:
1. Set the boot location to SRIO1 or SRIO2 by RCW.
2. Set a specific TLB entry for the boot process.
3. Set a LAW entry with the TargetID SRIO1 or SRIO2 for the boot.
4. Slave's u-boot image should be generated specifically by
make _SRIOBOOT_SLAVE_config.
This will set SYS_TEXT_BASE=0xFFF8 and other configurations.
Signed-off-by: Liu Gang
Signed-off-by: Shaohui Xie
---
Changes in v2:
- Subject changed to "powerpc/corenet_ds".
- Use "(void *)" instead of "(u32)" when calling "out_be32()".
- Use "NOR flash" instead of "Nor flash".
- Get rid of the base address + offset notation. Use C structs
instead.
- Get rid of hard coded magic numbers. Use macro instead.
- Use "debug()" instead of "printf()".
- Add the description for CONFIG_SYS_QE_FMAN_FW_IN_REMOTE and also
update the README for this.
Changes in v3:
- No
Changes in v4:
- No
README |6 ++
board/freescale/common/p_corenet/law.c |9 +
board/freescale/common/p_corenet/tlb.c |9 +
boards.cfg |3 +++
drivers/net/fm/fm.c|2 ++
include/configs/corenet_ds.h | 28
6 files changed, 57 insertions(+), 0 deletions(-)
diff --git a/README b/README
index 8964672..f8f6c0f 100644
--- a/README
+++ b/README
@@ -3384,6 +3384,12 @@ within that device.
Specifies that QE/FMAN firmware is located on the primary SPI
device. CONFIG_SYS_FMAN_FW_ADDR is the byte offset on that device.
+- CONFIG_SYS_QE_FMAN_FW_IN_REMOTE
+ Specifies that QE/FMAN firmware is located in the remote (master)
+ memory space. CONFIG_SYS_FMAN_FW_ADDR is a virtual address which
+ can be mapped from slave TLB->slave LAW->slave SRIO outbound window
+ ->master inbound window->master LAW->the ucode address in master's
+ NOR flash.
Building the Software:
==
diff --git a/board/freescale/common/p_corenet/law.c
b/board/freescale/common/p_corenet/law.c
index 09ef561..1fbab4d 100644
--- a/board/freescale/common/p_corenet/law.c
+++ b/board/freescale/common/p_corenet/law.c
@@ -48,6 +48,15 @@ struct law_entry law_table[] = {
#ifdef CONFIG_SYS_NAND_BASE_PHYS
SET_LAW(CONFIG_SYS_NAND_BASE_PHYS, LAW_SIZE_1M, LAW_TRGT_IF_LBC),
#endif
+#ifdef CONFIG_SRIOBOOT_SLAVE
+#if defined(CONFIG_SRIOBOOT_SLAVE_PORT0)
+ SET_LAW(CONFIG_SYS_SRIOBOOT_SLAVE_ADDR_PHYS,
+ LAW_SIZE_1M, LAW_TRGT_IF_RIO_1),
+#elif defined(CONFIG_SRIOBOOT_SLAVE_PORT1)
+ SET_LAW(CONFIG_SYS_SRIOBOOT_SLAVE_ADDR_PHYS,
+ LAW_SIZE_1M, LAW_TRGT_IF_RIO_2),
+#endif
+#endif
};
int num_law_entries = ARRAY_SIZE(law_table);
diff --git a/board/freescale/common/p_corenet/tlb.c
b/board/freescale/common/p_corenet/tlb.c
index 6a0026a..a8c8b3c 100644
--- a/board/freescale/common/p_corenet/tlb.c
+++ b/board/freescale/common/p_corenet/tlb.c
@@ -66,6 +66,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_SRIOBOOT_SLAVE)
+ /*
+* SRIOBOOT-SLAVE. When slave boot, the address of the
+* space is at 0xfff0, it covered the 0xf000.
+*/
+ SET_TLB_ENTRY(1, CONFIG_SYS_SRIOBOOT_SLAVE_ADDR,
+ CONFIG_SYS_SRIOBOOT_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,
diff --git a/boards.cfg b/boards.cfg
index c0b2cf9..68fa56e 100644
[U-Boot] [PATCH 6/8 v4] powerpc/corenet_ds: Slave uploads ucode when boot from SRIO
When boot from SRIO, slave's ucode can be stored in master's memory space,
then slave can fetch the ucode image through SRIO interface. For the
corenet platform, ucode is for Fman.
Master needs to:
1. Put the slave's ucode image into it's own memory space.
2. Set an inbound SRIO window covered slave's ucode stored in master's
memory space.
Slave needs to:
1. Set a specific TLB entry in order to fetch ucode from master.
2. Set a LAW entry with the TargetID SRIO1 or SRIO2 for ucode.
Signed-off-by: Liu Gang
Signed-off-by: Shaohui Xie
---
Changes in v2:
- Subject changed to "powerpc/corenet_ds".
- Use "(void *)" instead of "(u32)" when calling "out_be32()".
- Use "NOR flash" instead of "Nor flash".
- Get rid of the base address + offset notation. Use C structs
instead.
- Get rid of hard coded magic numbers. Use macro instead.
- Use "debug()" instead of "printf()".
- Correct some comment style errors.
Changes in v3:
- No
Changes in v4:
- No
arch/powerpc/cpu/mpc8xxx/srio.c| 25 +
board/freescale/common/p_corenet/law.c |4
board/freescale/common/p_corenet/tlb.c | 10 ++
include/configs/corenet_ds.h | 12 +++-
4 files changed, 46 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/cpu/mpc8xxx/srio.c b/arch/powerpc/cpu/mpc8xxx/srio.c
index 77fa32f..e593f22 100644
--- a/arch/powerpc/cpu/mpc8xxx/srio.c
+++ b/arch/powerpc/cpu/mpc8xxx/srio.c
@@ -100,8 +100,8 @@ void srio_boot_master(void)
debug("SRIOBOOT - MASTER: Master port [ %d ] for srio boot.\n",
CONFIG_SRIOBOOT_MASTER_PORT);
- /* configure inbound window5 for slave's u-boot image */
- debug("SRIOBOOT - MASTER: Inbound window 5 for slave's image; "
+ /* configure inbound window for slave's u-boot image */
+ debug("SRIOBOOT - MASTER: Inbound window for slave's image; "
"Local = 0x%llx, Srio = 0x%llx, Size = 0x%x\n",
(u64)CONFIG_SRIOBOOT_SLAVE_IMAGE_LAW_PHYS1,
(u64)CONFIG_SRIOBOOT_SLAVE_IMAGE_SRIO_PHYS1,
@@ -117,8 +117,8 @@ void srio_boot_master(void)
SRIO_IB_ATMU_AR
| atmu_size_mask(CONFIG_SRIOBOOT_SLAVE_IMAGE_SIZE));
- /* configure inbound window4 for slave's u-boot image */
- debug("SRIOBOOT - MASTER: Inbound window 4 for slave's image; "
+ /* configure inbound window for slave's u-boot image */
+ debug("SRIOBOOT - MASTER: Inbound window for slave's image; "
"Local = 0x%llx, Srio = 0x%llx, Size = 0x%x\n",
(u64)CONFIG_SRIOBOOT_SLAVE_IMAGE_LAW_PHYS2,
(u64)CONFIG_SRIOBOOT_SLAVE_IMAGE_SRIO_PHYS2,
@@ -133,5 +133,22 @@ void srio_boot_master(void)
.port[CONFIG_SRIOBOOT_MASTER_PORT].inbw[1].riwar,
SRIO_IB_ATMU_AR
| atmu_size_mask(CONFIG_SRIOBOOT_SLAVE_IMAGE_SIZE));
+
+ /* configure inbound window for slave's ucode */
+ debug("SRIOBOOT - MASTER: Inbound window for slave's ucode; "
+ "Local = 0x%llx, Srio = 0x%llx, Size = 0x%x\n",
+ (u64)CONFIG_SRIOBOOT_SLAVE_UCODE_LAW_PHYS,
+ (u64)CONFIG_SRIOBOOT_SLAVE_UCODE_SRIO_PHYS,
+ CONFIG_SRIOBOOT_SLAVE_UCODE_SIZE);
+ out_be32((void *)&srio->atmu
+ .port[CONFIG_SRIOBOOT_MASTER_PORT].inbw[2].riwtar,
+ CONFIG_SRIOBOOT_SLAVE_UCODE_LAW_PHYS >> 12);
+ out_be32((void *)&srio->atmu
+ .port[CONFIG_SRIOBOOT_MASTER_PORT].inbw[2].riwbar,
+ CONFIG_SRIOBOOT_SLAVE_UCODE_SRIO_PHYS >> 12);
+ out_be32((void *)&srio->atmu
+ .port[CONFIG_SRIOBOOT_MASTER_PORT].inbw[2].riwar,
+ SRIO_IB_ATMU_AR
+ | atmu_size_mask(CONFIG_SRIOBOOT_SLAVE_UCODE_SIZE));
}
#endif
diff --git a/board/freescale/common/p_corenet/law.c
b/board/freescale/common/p_corenet/law.c
index 1fbab4d..c4566dd 100644
--- a/board/freescale/common/p_corenet/law.c
+++ b/board/freescale/common/p_corenet/law.c
@@ -52,9 +52,13 @@ struct law_entry law_table[] = {
#if defined(CONFIG_SRIOBOOT_SLAVE_PORT0)
SET_LAW(CONFIG_SYS_SRIOBOOT_SLAVE_ADDR_PHYS,
LAW_SIZE_1M, LAW_TRGT_IF_RIO_1),
+ SET_LAW(CONFIG_SYS_SRIOBOOT_UCODE_ENV_ADDR_PHYS,
+ LAW_SIZE_1M, LAW_TRGT_IF_RIO_1),
#elif defined(CONFIG_SRIOBOOT_SLAVE_PORT1)
SET_LAW(CONFIG_SYS_SRIOBOOT_SLAVE_ADDR_PHYS,
LAW_SIZE_1M, LAW_TRGT_IF_RIO_2),
+ SET_LAW(CONFIG_SYS_SRIOBOOT_UCODE_ENV_ADDR_PHYS,
+ LAW_SIZE_1M, LAW_TRGT_IF_RIO_2),
#endif
#endif
};
diff --git a/board/freescale/common/p_corenet/tlb.c
b/board/freescale/common/p_corenet/tlb.c
index a8c8b3c..da2162
[U-Boot] [PATCH 7/8 v4] powerpc/corenet_ds: Slave reads ENV from master when boot from SRIO
When boot from SRIO, slave's ENV can be stored in master's memory space,
then slave can fetch the ENV through SRIO interface.
NOTE: Because the slave can not erase, write master's NOR flash by SRIO
interface, so it can not modify the ENV parameters stored in
master's NOR flash using "saveenv" or other commands.
Master needs to:
1. Put the slave's ENV into it's own memory space.
2. Set an inbound SRIO window covered slave's ENV stored in master's
memory space.
Slave needs to:
1. Set a specific TLB entry in order to fetch ucode and ENV from master.
2. Set a LAW entry with the TargetID SRIO1 or SRIO2 for ucode and ENV.
Signed-off-by: Liu Gang
Signed-off-by: Shaohui Xie
---
Changes in v2:
- Subject changed to "powerpc/corenet_ds".
- Update the README for "CONFIG_ENV_IS_IN_REMOTE".
- Use "(void *)" instead of "(u32)" when calling "out_be32()".
- Use "NOR flash" instead of "Nor flash".
- Get rid of the base address + offset notation. Use C structs
instead.
- Get rid of hard coded magic numbers. Use macro instead.
- Use "debug()" instead of "printf()".
- Some code styles changed.
Changes in v3:
- No
Changes in v4:
- No
README | 18 +
arch/powerpc/cpu/mpc8xxx/srio.c | 17
common/Makefile |1 +
common/cmd_nvedit.c |3 +-
common/env_remote.c | 79 +++
include/configs/corenet_ds.h| 13 ++
6 files changed, 130 insertions(+), 1 deletions(-)
create mode 100644 common/env_remote.c
diff --git a/README b/README
index f8f6c0f..6389371 100644
--- a/README
+++ b/README
@@ -2943,6 +2943,24 @@ to save the current settings.
environment area within the total memory of your DataFlash placed
at the specified address.
+- CONFIG_ENV_IS_IN_REMOTE:
+
+ Define this if you have a remote memory space which you
+ want to use for the local device's environment.
+
+ - CONFIG_ENV_ADDR:
+ - CONFIG_ENV_SIZE:
+
+ These two #defines specify the address and size of the
+ environment area within the remote memory space. The
+ local device can get the environment from remote memory
+ space by SRIO or other links.
+
+BE CAREFUL! For some special cases, the local device can not use
+"saveenv" command. For example, the local device will get the
+environment stored in a remote NOR flash by SRIO link, but it can
+not erase, write this NOR flash by SRIO interface.
+
- CONFIG_ENV_IS_IN_NAND:
Define this if you have a NAND device which you want to use
diff --git a/arch/powerpc/cpu/mpc8xxx/srio.c b/arch/powerpc/cpu/mpc8xxx/srio.c
index e593f22..5694561 100644
--- a/arch/powerpc/cpu/mpc8xxx/srio.c
+++ b/arch/powerpc/cpu/mpc8xxx/srio.c
@@ -150,5 +150,22 @@ void srio_boot_master(void)
.port[CONFIG_SRIOBOOT_MASTER_PORT].inbw[2].riwar,
SRIO_IB_ATMU_AR
| atmu_size_mask(CONFIG_SRIOBOOT_SLAVE_UCODE_SIZE));
+
+ /* configure inbound window for slave's ENV */
+ debug("SRIOBOOT - MASTER: Inbound window for slave's ENV; "
+ "Local = 0x%llx, Siro = 0x%llx, Size = 0x%x\n",
+ CONFIG_SRIOBOOT_SLAVE_ENV_LAW_PHYS,
+ CONFIG_SRIOBOOT_SLAVE_ENV_SRIO_PHYS,
+ CONFIG_SRIOBOOT_SLAVE_ENV_SIZE);
+ out_be32((void *)&srio->atmu
+ .port[CONFIG_SRIOBOOT_MASTER_PORT].inbw[3].riwtar,
+ CONFIG_SRIOBOOT_SLAVE_ENV_LAW_PHYS >> 12);
+ out_be32((void *)&srio->atmu
+ .port[CONFIG_SRIOBOOT_MASTER_PORT].inbw[3].riwbar,
+ CONFIG_SRIOBOOT_SLAVE_ENV_SRIO_PHYS >> 12);
+ out_be32((void *)&srio->atmu
+ .port[CONFIG_SRIOBOOT_MASTER_PORT].inbw[3].riwar,
+ SRIO_IB_ATMU_AR
+ | atmu_size_mask(CONFIG_SRIOBOOT_SLAVE_ENV_SIZE));
}
#endif
diff --git a/common/Makefile b/common/Makefile
index 2a31c62..4b6f054 100644
--- a/common/Makefile
+++ b/common/Makefile
@@ -58,6 +58,7 @@ COBJS-$(CONFIG_ENV_IS_IN_NAND) += env_nand.o
COBJS-$(CONFIG_ENV_IS_IN_NVRAM) += env_nvram.o
COBJS-$(CONFIG_ENV_IS_IN_ONENAND) += env_onenand.o
COBJS-$(CONFIG_ENV_IS_IN_SPI_FLASH) += env_sf.o
+COBJS-$(CONFIG_ENV_IS_IN_REMOTE) += env_remote.o
COBJS-$(CONFIG_ENV_IS_NOWHERE) += env_nowhere.o
# command
diff --git a/common/cmd_nvedit.c b/common/cmd_nvedit.c
index 22f9821..5a0ddd0 100644
--- a/common/cmd_nvedit.c
+++ b/common/cmd_nvedit.c
@@ -65,9 +65,10 @@ DECLARE_GLOBAL_DATA_PTR;
!defined(CONFIG_ENV_IS_IN_NVRAM)&& \
!defined(CONFIG_ENV_IS_IN_ONENAND) && \
!defined(CONFIG_ENV_IS_IN_SPI_FLASH)&& \
+ !defined(CONFIG_ENV_IS_IN_REMOTE) && \
!defined(CONFIG_ENV_IS_NOWHERE)
# error Define one of CONFIG_ENV_IS_IN_{EEPROM|FLASH|DATAFLASH|O
[U-Boot] [STATUS] New custodians, release status
Hello everybody, I'm more than happy to be able to announce that we have found a number of new custodians who will help to further distribute the work and especially to reduce the backlog of unprocessed patches: Here is the lst of new custodians: - AVR32:Andreas Bießmann - Network Library: Joe Hershberger - OnenNAND: Lukasz Majewski - USB Drivers: Marek Vasut All these repos are ready for immediate use. Welcome aboard, and thanks again to all of you for volunteering! Now for the release status: you have most probably realized that according to the schedule the next release would be just 4 days ahead, but we still have a long list of patches that need applying, so I decided to stretch the release; the new plan says March 31 (which would allow us to stay within the 3/6/9/12 grid), but I will not hesitate to make this a v2012/04 if this seems appropriate. 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 Motto of the Electrical Engineer: Working computer hardware is a lot like an erect penis: it stays up as long as you don't fuck with it. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/7] net/designware: Bug fixes
Dear Joe, In message you wrote: > > I'm guessing you lost my email from yesterday (filter again?)... Misplaced, not lost. And I found out which of my filter rules was a bit too generic (ber...@gmail.com). Should be fixed now. > My boss is not preventing me from accepting... so I accept. I emailed > my public key yesterday as well. Great, thanks!! You are set up - you should be able to push into the network git now. 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 There are certain things men must do to remain men. -- Kirk, "The Ultimate Computer", stardate 4929.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Building uboot image for panda board
Hi i am charles. I am building the panda uboot image, but something wrong. make[1]: Leaving directory `/home/charles/Work_100G/PandaBoard/U_boot/u-boot/arch/arm/cpu/armv7' make -C tools all make[1]: Entering directory `/home/charles/Work_100G/PandaBoard/U_boot/u-boot/tools' make[1]: Leaving directory `/home/charles/Work_100G/PandaBoard/U_boot/u-boot/tools' make -C spl/board/ti/panda all make[1]: Entering directory `/home/charles/Work_100G/PandaBoard/U_boot/u-boot/spl/board/ti/panda' /home/charles/Work_100G/PandaBoard/ICS4.0/prebuilt/linux-x86/toolchain/arm-eabi-4.4.3/bin/arm-eabi-gcc -g -Os -fno-common -ffixed-r8 -msoft-float -D__KERNEL__ -DCONFIG_SYS_TEXT_BASE=0x80e8 -I/home/charles/Work_100G/PandaBoard/U_boot/u-boot/include -fno-builtin -ffreestanding -nostdinc -isystem /home/charles/Work_100G/PandaBoard/ICS4.0/prebuilt/linux-x86/toolchain/arm-eabi-4.4.3/bin/../lib/gcc/arm-eabi/4.4.3/include -pipe -DCONFIG_ARM -D__ARM__ -marm -mno-thumb-interwork -mabi=aapcs-linux -march=armv5 -march=armv7-a -Wall -Wstrict-prototypes -fno-stack-protector -DCONFIG_PRELOADER -Os -ffixed-r8 -ffunction-sections -fdata-sections -march=armv7-a -mthumb -c -o spl-omap.o spl-omap.c cd /home/charles/Work_100G/PandaBoard/U_boot/u-boot/spl/board/ti/panda && /home/charles/Work_100G/PandaBoard/ICS4.0/prebuilt/linux-x86/toolchain/arm-eabi-4.4.3/bin/arm-eabi-ld -Bstatic -T /home/charles/Work_100G/PandaBoard/U_boot/u-boot/spl/u-boot-spl-generated.lds --gc-sections start.o reset.o lowlevel_init.o serial.o ns16550.o string.o vsprintf.o console.o stdio.o ctype.o eabi_compat.o div64.o omap_hsmmc.o omap24xx_i2c.o mmc.o time.o part.o part_dos.o fat.o syslib.o utils.o timer.o spl-omap.o board.o clocks.o emif.o sdram_elpida.o \ -L /home/charles/Work_100G/PandaBoard/ICS4.0/prebuilt/linux-x86/toolchain/arm-eabi-4.4.3/bin/../lib/gcc/arm-eabi/4.4.3/thumb -lgcc \ -Map /home/charles/Work_100G/PandaBoard/U_boot/u-boot/spl/u-boot-spl.map \ -o /home/charles/Work_100G/PandaBoard/U_boot/u-boot/spl/u-boot-spl clocks.o: In function `prcm_init': clocks.c:(.text.prcm_init+0x8a): undefined reference to `omap_set_gpio_direction' clocks.c:(.text.prcm_init+0x92): undefined reference to `omap_set_gpio_dataout' make[1]: *** [/home/charles/Work_100G/PandaBoard/U_boot/u-boot/spl/u-boot-spl] Error 1 make[1]: Leaving directory `/home/charles/Work_100G/PandaBoard/U_boot/u-boot/spl/board/ti/panda' make: *** [SPL] Error 2 Does anyone know what's wrong? Thanks~ -- View this message in context: http://old.nabble.com/Building-uboot-image-for-panda-board-tp33464297p33464297.html Sent from the Uboot - Users mailing list archive at Nabble.com. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] please pull u-boot-samsung/master
Dear Albert, The following changes since commit 32ec258f829808dd7cf74fd83ba999fdaaeab715: IXP: Fix GPIO_INT_ACT_LOW_SET() (2012-03-08 08:11:45 +0100) are available in the git repository at: git://git.denx.de/u-boot-samsung master Chander Kashyap (1): EXYNOS: Add structure for Exynos4 DMC David Müller (ELSOFT AG) (1): ARM: fix s3c2410 timer code Doug Anderson (1): EXYNOS: SMDK5250: Support all 4 UARTs arch/arm/cpu/arm920t/s3c24x0/timer.c | 64 ++- arch/arm/include/asm/arch-exynos/dmc.h | 109 board/samsung/smdk5250/smdk5250.c | 44 - 3 files changed, 171 insertions(+), 46 deletions(-) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v8] usb: align buffers at cacheline
Hi Marek,
On Thursday 08 March 2012 03:36 AM, Marek Vasut wrote:
Dear puneets,
Hi Mike,
On Tuesday 06 March 2012 08:37 AM, Mike Frysinger wrote:
* PGP Signed by an unknown key
On Monday 05 March 2012 09:46:21 Puneet Saxena wrote:
As DMA expects the buffers to be equal and larger then
cache lines, This aligns buffers at cacheline.
i don't think this statement is true. DMA doesn't care about alignment
(well, some do, but it's not related to cache lines but rather some
other restriction in the peripheral DMA itself). what does matter is
that cache operations operate on cache lines and not individual bytes.
hence the core arm code was updated to warn when someone told it to
invalidate X bytes but the hardware literally could not, so it had to
invalidate X + Y bytes.
Agreed, Will update the commit message in next patchset.
--- a/drivers/usb/host/ehci-hcd.c
+++ b/drivers/usb/host/ehci-hcd.c
static void flush_invalidate(u32 addr, int size, int flush)
{
+ /*
+* Size is the bytes actually moved during transaction,
+* which may not equal to the cache line. This results
+* stop address passed for invalidating cache may not be aligned.
+* Therfore making size as multiple of cache line size.
+*/
+ size = ALIGN(size, ARCH_DMA_MINALIGN);
+
if (flush)
flush_dcache_range(addr, addr + size);
else
i think this is wrong and merely hides the errors from higher up instead
of fixing them. the point of the warning was to tell you that the code
was invalidating *too many* bytes. this code still invalidates too many
bytes without any justification as for why it's OK to do here. further,
this code path only matters to the invalidation logic, not the flush
logic. -mike
The sole purpose of this patch to remove the warnings as start/stop
address sent for invalidating
is unaligned. Without this patch code works fine but with lots of
spew...Which we don't want and discussed
in earlier thread which Simon posted. Please have a look on following link.
As I understood, you agree that we need to align start/stop buffer
address and also agree that
to align stop address we need to align size as start address is already
aligned.
Now, "why its OK to do here"?
We could have aligned the size in two places, cache_qtd() and cache_qh()
but then we need to place alignment check
at all the places where size is passed. So I thought better Aligning at
flush_invalidate() and "ALIGN" macro does not
increase the size if size is already aligned.
Actually I have to agree with Mike here. Can you please remove that ALIGN() (and
all others you might have added)? If it does spew, that's ok and it tells us
something is wrong in the USB core subsystem. Such stuff can be fixed in
subsequent patch.
Sorry, I could not understand "(and all others you might have added)".
Do you want me remove any HACK in the patch which is using ALIGN or
making stop address
aligned? The patch has only the above line to make stop address align
and rest of the code makes
start address align. Just to confirm, you are fine with the start
address alignment code in the patch?
Best regards,
Marek Vasut
Thanx & Regards,
Puneet
---
This email message is for the sole use of the intended recipient(s) and may
contain
confidential information. Any unauthorized review, use, disclosure or
distribution
is prohibited. If you are not the intended recipient, please contact the
sender by
reply email and destroy all copies of the original message.
---
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] DEVELOPER's MEETING
Hi, I was just thinking if this year's Libre Software Meeting (LSM - from 7th to 12th July in Geneva, Switzerland) would be a suitable event to arrange a meeting of some U-Boot developers? See http://article.gmane.org/gmane.linux.kernel.embedded/3900 or http://vtk.1045678.n5.nabble.com/CfP-13th-Libre-Software-Meeting-Geneva-SWITZERLAND-td5521803.html for details. What do you think? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de In the beginning there was nothing. And the Lord said "Let There Be Light!" And still there was nothing, but at least now you could see it. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Building uboot image for panda board
Hi Charles, On Thursday 08 March 2012 04:48 PM, charlesKAO wrote: Hi i am charles. I am building the panda uboot image, but something wrong. make[1]: Leaving directory `/home/charles/Work_100G/PandaBoard/U_boot/u-boot/arch/arm/cpu/armv7' make -C tools all make[1]: Entering directory `/home/charles/Work_100G/PandaBoard/U_boot/u-boot/tools' make[1]: Leaving directory `/home/charles/Work_100G/PandaBoard/U_boot/u-boot/tools' make -C spl/board/ti/panda all make[1]: Entering directory `/home/charles/Work_100G/PandaBoard/U_boot/u-boot/spl/board/ti/panda' /home/charles/Work_100G/PandaBoard/ICS4.0/prebuilt/linux-x86/toolchain/arm-eabi-4.4.3/bin/arm-eabi-gcc -g -Os -fno-common -ffixed-r8 -msoft-float -D__KERNEL__ -DCONFIG_SYS_TEXT_BASE=0x80e8 -I/home/charles/Work_100G/PandaBoard/U_boot/u-boot/include -fno-builtin -ffreestanding -nostdinc -isystem /home/charles/Work_100G/PandaBoard/ICS4.0/prebuilt/linux-x86/toolchain/arm-eabi-4.4.3/bin/../lib/gcc/arm-eabi/4.4.3/include -pipe -DCONFIG_ARM -D__ARM__ -marm -mno-thumb-interwork -mabi=aapcs-linux -march=armv5 -march=armv7-a -Wall -Wstrict-prototypes -fno-stack-protector -DCONFIG_PRELOADER -Os -ffixed-r8 -ffunction-sections -fdata-sections -march=armv7-a -mthumb -c -o spl-omap.o spl-omap.c cd /home/charles/Work_100G/PandaBoard/U_boot/u-boot/spl/board/ti/panda&& /home/charles/Work_100G/PandaBoard/ICS4.0/prebuilt/linux-x86/toolchain/arm-eabi-4.4.3/bin/arm-eabi-ld -Bstatic -T /home/charles/Work_100G/PandaBoard/U_boot/u-boot/spl/u-boot-spl-generated.lds --gc-sections start.o reset.o lowlevel_init.o serial.o ns16550.o string.o vsprintf.o console.o stdio.o ctype.o eabi_compat.o div64.o omap_hsmmc.o omap24xx_i2c.o mmc.o time.o part.o part_dos.o fat.o syslib.o utils.o timer.o spl-omap.o board.o clocks.o emif.o sdram_elpida.o \ -L /home/charles/Work_100G/PandaBoard/ICS4.0/prebuilt/linux-x86/toolchain/arm-eabi-4.4.3/bin/../lib/gcc/arm-eabi/4.4.3/thumb -lgcc \ -Map /home/charles/Work_100G/PandaBoard/U_boot/u-boot/spl/u-boot-spl.map \ -o /home/charles/Work_100G/PandaBoard/U_boot/u-boot/spl/u-boot-spl clocks.o: In function `prcm_init': clocks.c:(.text.prcm_init+0x8a): undefined reference to `omap_set_gpio_direction' clocks.c:(.text.prcm_init+0x92): undefined reference to `omap_set_gpio_dataout' make[1]: *** [/home/charles/Work_100G/PandaBoard/U_boot/u-boot/spl/u-boot-spl] Error 1 make[1]: Leaving directory `/home/charles/Work_100G/PandaBoard/U_boot/u-boot/spl/board/ti/panda' make: *** [SPL] Error 2 I believe you are trying an older version. The current HEAD of master doesn't have gpio functions in clocks.c? br, Aneesh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] mmc: Fix warning if CONFIG_MMC_TRACE is enabled
Fix the warning
mmc.c: In function 'mmc_send_cmd':
mmc.c:87: warning: assignment from incompatible pointer type
in case CONFIG_MMC_TRACE is enabled.
Signed-off-by: Dirk Behme
CC: Andy Fleming
---
drivers/mmc/mmc.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
index 21665ec..881b5c0 100644
--- a/drivers/mmc/mmc.c
+++ b/drivers/mmc/mmc.c
@@ -84,7 +84,7 @@ int mmc_send_cmd(struct mmc *mmc, struct mmc_cmd *cmd, struct
mmc_data *data)
for (i = 0; i < 4; i++) {
int j;
printf("\t\t\t\t\t%03d - ", i*4);
- ptr = &cmd->response[i];
+ ptr = (u8 *)&cmd->response[i];
ptr += 3;
for (j = 0; j < 4; j++)
printf("%02X ", *ptr--);
--
1.7.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] mmc: fsl_esdhc: Add workaround for auto-clock gate errata ENGcm03648
This patch imports three patches from the Freescale U-Boot with the following
commit messages:
ENGR00156405 ESDHC: Add workaround for auto-clock gate errata ENGcm03648
http://git.freescale.com/git/cgit.cgi/imx/uboot-imx.git/commit/drivers/mmc/imx_esdhc.c?h=imx_v2009.08_12.01.01&id=e436525a70fe47623d346bc7d9f08f12ff8ad787
The errata, not applicable to USDHC, causes ESDHC to shut off clock to the card
when auto-clock gating is enabled for commands with busy signalling and no data
phase. The card might require the clock to exit the busy state, so the
workaround
is to disable the auto-clock gate bits in SYSCTL register for such commands. The
workaround also entails polling on DAT0 bit in the PRSSTAT register to learn
when
busy state is complete. Auto-clock gating is re-enabled at the end of busy
state.
ENGR00156670-1 ESDHC/USDHC: Remove delay before each cmd and some bug fixes
http://git.freescale.com/git/cgit.cgi/imx/uboot-imx.git/commit/drivers/mmc/imx_esdhc.c?h=imx_v2009.08_12.01.01&id=a77c6fec8596891be96b2cdbc742c9824844b92a
Removed delay of 10 ms before each command. There should not be a need to have
this
delay after the ENGR00156405 patch that polls until card is not busy anymore
before
proceeding to next cmd.
ENGR00161852: remove u-boot build warnings for mx6q
http://git.freescale.com/git/cgit.cgi/imx/uboot-imx.git/commit/drivers/mmc/imx_esdhc.c?h=imx_v2009.08_12.01.01&id=97efee177f82b082db9d2019ed641c5b99b3f54b
Remove u-boot build warnings for mx6q.
SYSCTL_RSTA was defined twice. Remove one definition.
Signed-off-by: Dirk Behme
CC: Andy Fleming
CC: Fabio Estevam
---
drivers/mmc/fsl_esdhc.c | 61 --
include/fsl_esdhc.h |4 ++-
2 files changed, 56 insertions(+), 9 deletions(-)
diff --git a/drivers/mmc/fsl_esdhc.c b/drivers/mmc/fsl_esdhc.c
index 30db030..694d6fd 100644
--- a/drivers/mmc/fsl_esdhc.c
+++ b/drivers/mmc/fsl_esdhc.c
@@ -259,6 +259,7 @@ esdhc_send_cmd(struct mmc *mmc, struct mmc_cmd *cmd, struct
mmc_data *data)
{
uintxfertyp;
uintirqstat;
+ uintsysctl_restore = 0;
struct fsl_esdhc_cfg *cfg = (struct fsl_esdhc_cfg *)mmc->priv;
volatile struct fsl_esdhc *regs = (struct fsl_esdhc *)cfg->esdhc_base;
@@ -279,13 +280,6 @@ esdhc_send_cmd(struct mmc *mmc, struct mmc_cmd *cmd,
struct mmc_data *data)
while (esdhc_read32(®s->prsstat) & PRSSTAT_DLA)
;
- /* Wait at least 8 SD clock cycles before the next command */
- /*
-* Note: This is way more than 8 cycles, but 1ms seems to
-* resolve timing issues with some cards
-*/
- udelay(1000);
-
/* Set up for a data transfer if we have one */
if (data) {
int err;
@@ -298,6 +292,14 @@ esdhc_send_cmd(struct mmc *mmc, struct mmc_cmd *cmd,
struct mmc_data *data)
/* Figure out the transfer arguments */
xfertyp = esdhc_xfertyp(cmd, data);
+ /* ESDHC errata ENGcm03648: Turn off auto-clock gate for commands
+* with busy signaling and no data
+*/
+ if (!data && (cmd->resp_type & MMC_RSP_BUSY)) {
+ sysctl_restore = esdhc_read32(®s->sysctl);
+ esdhc_write32(®s->sysctl, sysctl_restore | 0xF);
+ }
+
/* Send the command */
esdhc_write32(®s->cmdarg, cmd->cmdarg);
#if defined(CONFIG_FSL_USDHC)
@@ -307,19 +309,62 @@ esdhc_send_cmd(struct mmc *mmc, struct mmc_cmd *cmd,
struct mmc_data *data)
#else
esdhc_write32(®s->xfertyp, xfertyp);
#endif
+
+ /* Mask all irqs */
+ esdhc_write32(®s->irqsigen, 0);
+
/* Wait for the command to complete */
- while (!(esdhc_read32(®s->irqstat) & IRQSTAT_CC))
+ while (!(esdhc_read32(®s->irqstat) & (IRQSTAT_CC | IRQSTAT_CTOE)))
;
irqstat = esdhc_read32(®s->irqstat);
esdhc_write32(®s->irqstat, irqstat);
+ /* Reset CMD and DATA portions on error */
+ if (irqstat & (CMD_ERR | IRQSTAT_CTOE)) {
+ esdhc_write32(®s->sysctl, esdhc_read32(®s->sysctl) |
+ SYSCTL_RSTC);
+ while (esdhc_read32(®s->sysctl) & SYSCTL_RSTC)
+ ;
+
+ if (data) {
+ esdhc_write32(®s->sysctl,
+ esdhc_read32(®s->sysctl) |
+ SYSCTL_RSTD);
+ while ((esdhc_read32(®s->sysctl) & SYSCTL_RSTD))
+ ;
+ }
+
+ /* Restore auto-clock gate if error */
+ if (!data && (cmd->resp_type & MMC_RSP_BUSY))
+ esdhc_write32(®s->sysctl, sysctl_restore);
+ }
+
if (irqstat & CMD_ERR)
return COMM_ERR;
if (irqstat & IRQSTAT_CTOE)
return TIMEOUT;
+ /* Workaround for ESDHC errata ENGcm03648 */
+ if (!data && (cmd->resp_type & MMC_RSP_BUSY)) {
+
Re: [U-Boot] [PATCH v8] usb: align buffers at cacheline
Dear puneets,
> Hi Marek,
>
> On Thursday 08 March 2012 03:36 AM, Marek Vasut wrote:
> > Dear puneets,
> >
> >> Hi Mike,
> >>
> >> On Tuesday 06 March 2012 08:37 AM, Mike Frysinger wrote:
> >>> * PGP Signed by an unknown key
> >>>
> >>> On Monday 05 March 2012 09:46:21 Puneet Saxena wrote:
> As DMA expects the buffers to be equal and larger then
> cache lines, This aligns buffers at cacheline.
> >>>
> >>> i don't think this statement is true. DMA doesn't care about alignment
> >>> (well, some do, but it's not related to cache lines but rather some
> >>> other restriction in the peripheral DMA itself). what does matter is
> >>> that cache operations operate on cache lines and not individual bytes.
> >>> hence the core arm code was updated to warn when someone told it to
> >>> invalidate X bytes but the hardware literally could not, so it had to
> >>> invalidate X + Y bytes.
> >>
> >> Agreed, Will update the commit message in next patchset.
> >>
> --- a/drivers/usb/host/ehci-hcd.c
> +++ b/drivers/usb/host/ehci-hcd.c
>
> static void flush_invalidate(u32 addr, int size, int flush)
> {
>
> +/*
> + * Size is the bytes actually moved during transaction,
> + * which may not equal to the cache line. This results
> + * stop address passed for invalidating cache may not be
aligned.
> + * Therfore making size as multiple of cache line size.
> + */
> +size = ALIGN(size, ARCH_DMA_MINALIGN);
> +
>
> if (flush)
>
> flush_dcache_range(addr, addr + size);
>
> else
> >>>
> >>> i think this is wrong and merely hides the errors from higher up
> >>> instead of fixing them. the point of the warning was to tell you that
> >>> the code was invalidating *too many* bytes. this code still
> >>> invalidates too many bytes without any justification as for why it's
> >>> OK to do here. further, this code path only matters to the
> >>> invalidation logic, not the flush logic. -mike
> >>
> >> The sole purpose of this patch to remove the warnings as start/stop
> >> address sent for invalidating
> >> is unaligned. Without this patch code works fine but with lots of
> >> spew...Which we don't want and discussed
> >> in earlier thread which Simon posted. Please have a look on following
> >> link.
> >>
> >> As I understood, you agree that we need to align start/stop buffer
> >> address and also agree that
> >> to align stop address we need to align size as start address is already
> >> aligned.
> >> Now, "why its OK to do here"?
> >> We could have aligned the size in two places, cache_qtd() and cache_qh()
> >> but then we need to place alignment check
> >> at all the places where size is passed. So I thought better Aligning at
> >> flush_invalidate() and "ALIGN" macro does not
> >> increase the size if size is already aligned.
> >
> > Actually I have to agree with Mike here. Can you please remove that
> > ALIGN() (and all others you might have added)? If it does spew, that's
> > ok and it tells us something is wrong in the USB core subsystem. Such
> > stuff can be fixed in subsequent patch.
>
> Sorry, I could not understand "(and all others you might have added)".
> Do you want me remove any HACK in the patch which is using ALIGN or
> making stop address
No, only such hacks where it's certain they will either invalidate or flush
some
areas that weren't allocated for them, like this ALIGN you did here. This can
cause trouble that will be very hard to find.
> aligned? The patch has only the above line to make stop address align
> and rest of the code makes
> start address align. Just to confirm, you are fine with the start
> address alignment code in the patch?
The start address alignment you do also aligns the end to the cacheline,
doesn't
it? (at least that's what I believe the macro is supposed to do).
>
> > Best regards,
> > Marek Vasut
>
> Thanx & Regards,
> Puneet
>
> ---
> This email message is for the sole use of the intended
> recipient(s) and may contain confidential information. Any unauthorized
> review, use, disclosure or distribution is prohibited. If you are not the
> intended recipient, please contact the sender by reply email and destroy
> all copies of the original message.
> ---
>
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] eth: remove usb-ethernet devices before re-enumerating them
Dear Simon Glass, > Hi Marek, > > On Sun, Feb 26, 2012 at 3:10 PM, Marek Vasut wrote: > >> Fix the crash when running several times usb_init() with a USB ethernet > >> device plugged. > >> > >> Signed-off-by: Vincent Palatin > >> Tested-by: Wolfgang Grandegger > >> --- > > > > Hi, > > > > what's the status of this patch/patchset? > > I believe it should be applied. > > Regards, > Simon > Should be applied to linux-usb now, thanks! Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] PXA: Enable CONFIG_PREBOOT on zipitz2
Signed-off-by: Marek Vasut --- include/configs/zipitz2.h |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/include/configs/zipitz2.h b/include/configs/zipitz2.h index 26204af..e14f59a 100644 --- a/include/configs/zipitz2.h +++ b/include/configs/zipitz2.h @@ -32,6 +32,7 @@ #undef CONFIG_BOARD_LATE_INIT #undef CONFIG_USE_IRQ #undef CONFIG_SKIP_LOWLEVEL_INIT +#defineCONFIG_PREBOOT /* * Environment settings -- 1.7.9 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] PXA: Enable CONFIG_PREBOOT on zipitz2
Dear Marek Vasut, > Signed-off-by: Marek Vasut > --- > include/configs/zipitz2.h |1 + > 1 files changed, 1 insertions(+), 0 deletions(-) > > diff --git a/include/configs/zipitz2.h b/include/configs/zipitz2.h > index 26204af..e14f59a 100644 > --- a/include/configs/zipitz2.h > +++ b/include/configs/zipitz2.h > @@ -32,6 +32,7 @@ > #undef CONFIG_BOARD_LATE_INIT > #undef CONFIG_USE_IRQ > #undef CONFIG_SKIP_LOWLEVEL_INIT > +#define CONFIG_PREBOOT > > /* > * Environment settings Albert, can you please pick this one up directly and roll it into the pull rq? It's quite important for our testing setup. Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Any outstanding ARM pull requests?
Albert, > -Original Message- > From: Albert ARIBAUD [mailto:albert.u.b...@aribaud.net] > Sent: Thursday, March 08, 2012 12:20 AM > To: U-Boot@lists.denx.de > Cc: Reinhard Meyer; Stefano Babic; Marek Vasut; Minkyu Kang; Tom Warren > Subject: Any outstanding ARM pull requests? > > Hi all, > > On my working repo where I have all ARM subrepos as remotes, a > > git branch -r --no-merged | grep '/master' > > with HEAD set to my master branch gives the following: > >u-boot-atmel/master >u-boot-atmel/master-arm >u-boot-imx/master >u-boot-pxa/master >u-boot-samsung/master >u-boot-tegra/master > > Which means there are commmits on these repo's master branches that are not > currently in u-boot-arm. > > Are there any ARM pull requests pending that I would have missed or are > about to be sent? I hope to get a pull request together today for u-boot-tegra/master. What's the cut-off? i.e. could I push it to tomorrow if I run across a problem in testing? Thanks, Tom -- nvpublic > > Amicalement, > -- > Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Any outstanding ARM pull requests?
On 03/08/2012 01:20 AM, Albert ARIBAUD wrote: > Hi all, > > On my working repo where I have all ARM subrepos as remotes, a > > git branch -r --no-merged | grep '/master' > > with HEAD set to my master branch gives the following: > > u-boot-atmel/master > u-boot-atmel/master-arm > u-boot-imx/master > u-boot-pxa/master > u-boot-samsung/master > u-boot-tegra/master > > Which means there are commmits on these repo's master branches that are > not currently in u-boot-arm. > > Are there any ARM pull requests pending that I would have missed or are > about to be sent? > > Amicalement, The highbank fixes are still not applied. You can get them off the list or here's a pull request again: The following changes since commit 2acca35ce4604dcef933f07d90aa9c9c930e1049: Merge branch 'master' of git://git.denx.de/u-boot-mmc (2012-02-17 23:54:46 +0100) are available in the git repository at: git://sources.calxeda.com/u-boot.git fixes Rob Herring (4): net: calxedaxgmac: fix build due to missing __aligned definition ARM: highbank: fix warning for calxedaxgmac_initialize ARM: highbank: add missing get_tbclk ARM: highbank: fix us_to_tick calculation arch/arm/cpu/armv7/highbank/timer.c |9 +++-- board/highbank/highbank.c |1 + drivers/net/calxedaxgmac.c |1 + 3 files changed, 9 insertions(+), 2 deletions(-) Rob ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] TQM85xx boards failing on older gcc
On Thu, Mar 8, 2012 at 2:35 AM, Wolfgang Denk wrote: > Dear Andy, > > In message > you > wrote: >> >> One of my coworkers is seeing these errors with gcc-4.3.74 (eglibc-2.8.74-6): > > glibc version should be completely irrelevant when building U-Boot. Yeah, I only mentioned it because it was part of the versioning string. > >> >> Configuring for TQM8548_BE - Board: TQM85xx, Options: >> MPC8548,TQM8548_BE=y,HOSTNAME=tqm8548,BOARDNAME="TQM8548_BE" >> text data bss dec hex filename >> 297931 25840 35848 359619 57cc3 ./u-boot >> Configuring for TQM8555 - Board: TQM85xx, Options: >> MPC8555,TQM8555=y,HOSTNAME=tqm8555,BOARDNAME="TQM8555" >> powerpc-linux-gnu-ld: section .bootpg [f000 -> f407] overlaps >> section .data [d9b8 -> f7db] >> powerpc-linux-gnu-ld: u-boot: section .bootpg lma 0xf000 overlaps >> previous sections >> powerpc-linux-gnu-ld: u-boot: section .u_boot_cmd lma 0xf7dc >> overlaps previous sections >> powerpc-linux-gnu-ld: u-boot: section .resetvec lma 0xfffc >> overlaps previous sections >> make: *** [u-boot] Error 1 >> >> >> He says the same for TQM8541, TQM8548. I don't see it on my 4.5.55 gcc > > I confirm that these are known issues. Currently we have no intention > to fix these, though. The boards in question have reached EOL and are > no longer actively maintained. The problem is - as Stefan correctly > diagnosed - caused by increased code size due to some extensions and > fixes in recent versions, which do not cuase problems with recent tool > chains, but which would require either removal of functionality or > changes to the memory map for older tool chains with not so decent > code optimizations. We feel that any of these activities would be > wasted efforts, so we decided to ignore these issues. > > In case the boards should break with recent tool chains, I will > probably board send removal patches. That's fine by me. My coworker has upgraded his gcc, so he no longer sees the issue. I'll let you know if it stops building, in the future. Andy ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] ubifsmount reports "Error reading superblock", but linux can mount FS
On 7 March 2012 14:42, Alex Zeffertt wrote: > Hi u-booters, > > I have a short script in my u-boot environment which chooses which of > two ubifs partitions to boot > by attempting to read a release file in each one. > > Unfortunately, after an unclean shutdown sometimes the ubifsmount > fails. (By "unclean shutdown" > I mean that the board was power cycled while doing some low bandwidth > logging.) > > The strange thing is that Linux has no problem mounting the partition > as its root filesystem. This is > very confusing because it looks like the ubifs implementation in > u-boot is just a copy of the one in Linux. > > Has anyone else seen this problem? > > I've now managed to repro this problem and add some debug. It looks like u-boot is simply running out of memory whilst trying to mount a filesystem that "needs recovery". (Error -12 is -ENOMEM.) The partition it is mounting is 240MB, but only about 40MB full. The debug output is below after the "ubifsmount" command: U-Boot 2011.06-9-g3b6754e-dirty (Mar 08 2012 - 16:30:13) OpenRD-Base SoC: Kirkwood 88F6281_A1 DRAM: 128 MiB NAND: 512 MiB In:serial Out: serial Err: serial Net: egiga0 88E6351 Initialized on egiga0 Marvell>> ubi part rootfs 2048 Creating 1 MTD partitions on "nand0": 0x0100-0x1000 : "mtd=2" UBI: attaching mtd1 to ubi0 UBI: physical eraseblock size: 131072 bytes (128 KiB) UBI: logical eraseblock size:126976 bytes UBI: smallest flash I/O unit:2048 UBI: sub-page size: 512 UBI: VID header offset: 2048 (aligned 2048) UBI: data offset:4096 UBI: attached mtd1 to ubi0 UBI: MTD device name:"mtd=2" UBI: MTD device size:240 MiB UBI: number of good PEBs:1913 UBI: number of bad PEBs: 7 UBI: max. allowed volumes: 128 UBI: wear-leveling threshold:4096 UBI: number of internal volumes: 1 UBI: number of user volumes: 1 UBI: available PEBs: 0 UBI: total number of reserved PEBs: 1913 UBI: number of PEBs reserved for bad PEB handling: 19 UBI: max/mean erase counter: 7/1 Marvell>> ubifsmount rootfs UBIFS: recovery needed UBIFS error (pid 0): replay_bud: insert_node failed: err=-12 UBIFS error (pid 0): replay_buds: replay_bud failed: err=-12 UBIFS error (pid 0): ubifs_replay_journal: replay_buds failed: err=-12 UBIFS error (pid 0): mount_ubifs: ubifs_replay_journal failed: err=-12 UBIFS error (pid 0): ubifs_fill_super: mount_ubifs failed: err=-12 UBIFS error (pid 0): ubifs_get_sb: ubifs_fill_super failed: err=-12 Error reading superblock on volume 'ubi:rootfs'! Marvell>> Does this help explain the issue? Regards, Alex ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Enabling nand createbbt command
On 03/07/2012 07:56 PM, Bud Miljkovic wrote: > Does someone know how to enable the nand createbbt u-boot command? The BBT gets created automatically if it does not exist, provided the NAND controller driver asks for it. Why do you need an explicit command? -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/6] arm: adapt asm/linkage.h from Linux
This will add ARM specific over-rides for the defines from linux/linkage.h Signed-off-by: Aneesh V --- Not adding the defines for __ALIGN and __ALIGN_STR because it's not clear why alignment is set to 0 (single byte alignment). Creates a checkpatch error that can not be avoided Changes in v4: - Use STT_FUNC in the definition of ENDPROC in include/linux/linkage.h that is more portable than the '*function' versions. Now, remove the definition of ENDPROC from the arm linkage.h Changes in v3: - None Changes in v2: - Newly added --- arch/arm/include/asm/linkage.h |7 +++ include/linux/linkage.h|7 ++- 2 files changed, 13 insertions(+), 1 deletions(-) create mode 100644 arch/arm/include/asm/linkage.h diff --git a/arch/arm/include/asm/linkage.h b/arch/arm/include/asm/linkage.h new file mode 100644 index 000..dbe4b4e --- /dev/null +++ b/arch/arm/include/asm/linkage.h @@ -0,0 +1,7 @@ +#ifndef __ASM_LINKAGE_H +#define __ASM_LINKAGE_H + +#define __ALIGN .align 0 +#define __ALIGN_STR ".align 0" + +#endif diff --git a/include/linux/linkage.h b/include/linux/linkage.h index ed4cf6c..7b749bb 100644 --- a/include/linux/linkage.h +++ b/include/linux/linkage.h @@ -44,8 +44,13 @@ #define SYMBOL_NAME_LABEL(X) X: #endif +#ifndef __ALIGN #define __ALIGN .align 4 +#endif + +#ifndef __ALIGN_STR #define __ALIGN_STR".align 4" +#endif #ifdef __ASSEMBLY__ @@ -67,7 +72,7 @@ #ifndef ENDPROC #define ENDPROC(name) \ - .type name, @function; \ + .type name STT_FUNC; \ END(name) #endif -- 1.7.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/6] armv7: add appropriate headers for assembly functions
Use ENTRY and ENDPROC with assembly functions to ensure
necessary assembler directives for all functions.
Signed-off-by: Aneesh V
---
Changes in v4:
- None
Changes in v3:
- None
Changes in V2:
- Newly added
---
arch/arm/cpu/armv7/mx5/lowlevel_init.S |5 ++-
arch/arm/cpu/armv7/mx6/lowlevel_init.S |5 ++-
arch/arm/cpu/armv7/omap-common/lowlevel_init.S | 14
arch/arm/cpu/armv7/omap-common/reset.S |5 ++-
arch/arm/cpu/armv7/omap3/lowlevel_init.S | 41 ---
arch/arm/cpu/armv7/s5pc1xx/cache.S | 10 +++--
arch/arm/cpu/armv7/s5pc1xx/reset.S |5 ++-
arch/arm/cpu/armv7/start.S | 13 ---
arch/arm/cpu/armv7/tegra2/lowlevel_init.S |5 ++-
arch/arm/cpu/armv7/u8500/lowlevel.S|9 +++--
10 files changed, 61 insertions(+), 51 deletions(-)
diff --git a/arch/arm/cpu/armv7/mx5/lowlevel_init.S
b/arch/arm/cpu/armv7/mx5/lowlevel_init.S
index 01f6d75..5344410 100644
--- a/arch/arm/cpu/armv7/mx5/lowlevel_init.S
+++ b/arch/arm/cpu/armv7/mx5/lowlevel_init.S
@@ -22,6 +22,7 @@
#include
#include
#include
+#include
/*
* L2CC Cache setup/invalidation/disable
@@ -312,8 +313,7 @@
.section ".text.init", "x"
-.globl lowlevel_init
-lowlevel_init:
+ENTRY(lowlevel_init)
#if defined(CONFIG_MX51)
ldr r0, =GPIO1_BASE_ADDR
ldr r1, [r0, #0x0]
@@ -334,6 +334,7 @@ lowlevel_init:
/* r12 saved upper lr*/
mov pc,lr
+ENDPROC(lowlevel_init)
/* Board level setting value */
W_DP_OP_864: .word DP_OP_864
diff --git a/arch/arm/cpu/armv7/mx6/lowlevel_init.S
b/arch/arm/cpu/armv7/mx6/lowlevel_init.S
index 1864356..acadef2 100644
--- a/arch/arm/cpu/armv7/mx6/lowlevel_init.S
+++ b/arch/arm/cpu/armv7/mx6/lowlevel_init.S
@@ -18,7 +18,8 @@
*/
.section ".text.init", "x"
-.globl lowlevel_init
-lowlevel_init:
+#include
+ENTRY(lowlevel_init)
mov pc, lr
+ENDPROC(lowlevel_init)
diff --git a/arch/arm/cpu/armv7/omap-common/lowlevel_init.S
b/arch/arm/cpu/armv7/omap-common/lowlevel_init.S
index 35f38ac..ccc6bb6 100644
--- a/arch/arm/cpu/armv7/omap-common/lowlevel_init.S
+++ b/arch/arm/cpu/armv7/omap-common/lowlevel_init.S
@@ -27,9 +27,9 @@
*/
#include
+#include
-.global save_boot_params
-save_boot_params:
+ENTRY(save_boot_params)
/*
* See if the rom code passed pointer is valid:
* It is not valid if it is not in non-secure SRAM
@@ -76,10 +76,9 @@ save_boot_params:
strbr2, [r3, #CH_FLAGS_OFFSET]
1:
bx lr
+ENDPROC(save_boot_params)
-
-.globl lowlevel_init
-lowlevel_init:
+ENTRY(lowlevel_init)
/*
* Setup a temporary stack
*/
@@ -95,12 +94,13 @@ lowlevel_init:
*/
bl s_init
pop {ip, pc}
+ENDPROC(lowlevel_init)
-.globl set_pl310_ctrl_reg
-set_pl310_ctrl_reg:
+ENTRY(set_pl310_ctrl_reg)
PUSH{r4-r11, lr}@ save registers - ROM code may pollute
@ our registers
LDR r12, =0x102 @ Set PL310 control register - value in R0
.word 0xe1600070 @ SMC #0 - hand assembled because -march=armv5
@ call ROM Code API to set control register
POP {r4-r11, pc}
+ENDPROC(set_pl310_ctrl_reg)
diff --git a/arch/arm/cpu/armv7/omap-common/reset.S
b/arch/arm/cpu/armv7/omap-common/reset.S
index 838b122..179a476 100644
--- a/arch/arm/cpu/armv7/omap-common/reset.S
+++ b/arch/arm/cpu/armv7/omap-common/reset.S
@@ -22,9 +22,9 @@
*/
#include
+#include
-.global reset_cpu
-reset_cpu:
+ENTRY(reset_cpu)
ldr r1, rstctl @ get addr for global reset
@ reg
ldr r3, rstbit @ sw reset bit
@@ -36,3 +36,4 @@ rstctl:
.word PRM_RSTCTRL
rstbit:
.word PRM_RSTCTRL_RESET
+ENDPROC(reset_cpu)
diff --git a/arch/arm/cpu/armv7/omap3/lowlevel_init.S
b/arch/arm/cpu/armv7/omap3/lowlevel_init.S
index c42c5dd..ebf69fa 100644
--- a/arch/arm/cpu/armv7/omap3/lowlevel_init.S
+++ b/arch/arm/cpu/armv7/omap3/lowlevel_init.S
@@ -31,22 +31,22 @@
#include
#include
#include
+#include
_TEXT_BASE:
.word CONFIG_SYS_TEXT_BASE/* sdram load addr from config.mk */
#ifdef CONFIG_SPL_BUILD
-.global save_boot_params
-save_boot_params:
+ENTRY(save_boot_params)
ldr r4, =omap3_boot_device
ldr r5, [r0, #0x4]
and r5, r5, #0xff
str r5, [r4]
bx lr
+ENDPROC(save_boot_params)
#endif
-.global omap3_gp_romcode_call
-omap3_gp_romcode_call:
+ENTRY(omap3_gp_romcode_call)
PUSH {r4-r12, lr} @ Save all registers from ROM code!
MOV r12, r0 @ Copy the Service ID in R12
MOV r0, r1 @ Copy parameter to R0
@@ -55,6 +55,7 @@ omap3_gp_romcode_call:
.word 0xe1600070 @ SMC #0 to enter monitor - hand assembled
[U-Boot] [PATCH 4/6] armv7: Use -march=armv7-a and thereby enable Thumb-2
Enable -march=armv7-a for armv7 platforms if the tool-chain supports it. This in turn results in Thumb-2 code generated for these platforms if CONFIG_SYS_THUMB_BUILD is enabled. Signed-off-by: Aneesh V --- I believe armv7-a is fine for all the SoCs except Tegra2 and I see that Tegra2 is already making the necessary exception in .../armv7/tegra2/config.mk Let me know if any other SoC has a problem with armv7-a Changes in V4: - Replaced "+=" with ":=" for make variable that involves computation Changes in V3: - None Changes from V1 to V2: - None Changes from RFC to V1: - Enabled armv7-a from armv7/config.mk instead of from omap config.mk files --- arch/arm/cpu/armv7/config.mk |7 +-- 1 files changed, 5 insertions(+), 2 deletions(-) diff --git a/arch/arm/cpu/armv7/config.mk b/arch/arm/cpu/armv7/config.mk index 83ddf10..6d4b13c 100644 --- a/arch/arm/cpu/armv7/config.mk +++ b/arch/arm/cpu/armv7/config.mk @@ -22,8 +22,11 @@ # PLATFORM_RELFLAGS += -fno-common -ffixed-r8 -msoft-float -# Make ARMv5 to allow more compilers to work, even though its v7a. -PLATFORM_CPPFLAGS += -march=armv5 +# If armv7-a is not supported by GCC fall-back to armv5, which is +# supported by more tool-chains +PF_CPPFLAGS_ARMV7 := $(call cc-option, -march=armv7-a, -march=armv5) +PLATFORM_CPPFLAGS += $(PF_CPPFLAGS_ARMV7) + # = # # Supply options according to compiler version -- 1.7.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/6] ARM: enable Thumb build
Enable Thumb build and ARM-Thumb interworking based on the new config flag CONFIG_SYS_THUMB_BUILD Signed-off-by: Aneesh V --- Changes in v4: - Use ':=' instead of '+=' when computed make variables are involved Changes in v3: - None Changes from V1 to V2: - None Changes from RFC to V1: - Fixed review comments from Tom Rini --- README |8 arch/arm/config.mk | 22 +++--- 2 files changed, 23 insertions(+), 7 deletions(-) diff --git a/README b/README index 8964672..bdb428e 100644 --- a/README +++ b/README @@ -426,6 +426,14 @@ The following options need to be configured: Select high exception vectors of the ARM core, e.g., do not clear the V bit of the c1 register of CP15. + CONFIG_SYS_THUMB_BUILD + + Use this flag to build U-Boot using the Thumb instruction + set for ARM architectures. Thumb instruction set provides + better code density. For ARM architectures that support + Thumb2 this flag will result in Thumb2 code generated by + GCC. + - Linux Kernel Interface: CONFIG_CLOCKS_IN_MHZ diff --git a/arch/arm/config.mk b/arch/arm/config.mk index 45f9dca..d4fa1f8 100644 --- a/arch/arm/config.mk +++ b/arch/arm/config.mk @@ -33,25 +33,33 @@ endif PLATFORM_CPPFLAGS += -DCONFIG_ARM -D__ARM__ -# Explicitly specifiy 32-bit ARM ISA since toolchain default can be -mthumb: -PF_CPPFLAGS_ARM := $(call cc-option,-marm,) +# Choose between ARM/Thumb instruction sets +ifeq ($(CONFIG_SYS_THUMB_BUILD),y) +PF_CPPFLAGS_ARM := $(call cc-option, -mthumb -mthumb-interwork,\ + $(call cc-option,-marm,)\ + $(call cc-option,-mno-thumb-interwork,)\ + ) +else +PF_CPPFLAGS_ARM := $(call cc-option,-marm,) \ + $(call cc-option,-mno-thumb-interwork,) +endif # Try if EABI is supported, else fall back to old API, # i. e. for example: # - with ELDK 4.2 (EABI supported), use: -# -mabi=aapcs-linux -mno-thumb-interwork +# -mabi=aapcs-linux # - with ELDK 4.1 (gcc 4.x, no EABI), use: -# -mabi=apcs-gnu -mno-thumb-interwork +# -mabi=apcs-gnu # - with ELDK 3.1 (gcc 3.x), use: -# -mapcs-32 -mno-thumb-interwork +# -mapcs-32 PF_CPPFLAGS_ABI := $(call cc-option,\ - -mabi=aapcs-linux -mno-thumb-interwork,\ + -mabi=aapcs-linux,\ $(call cc-option,\ -mapcs-32,\ $(call cc-option,\ -mabi=apcs-gnu,\ )\ - ) $(call cc-option,-mno-thumb-interwork,)\ + )\ ) PLATFORM_CPPFLAGS += $(PF_CPPFLAGS_ARM) $(PF_CPPFLAGS_ABI) -- 1.7.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 5/6] omap4+: Avoid using __attribute__ ((__packed__))
Avoid using __attribute__ ((__packed__)) unless it's
absolutely necessary. "packed" will remove alignment
requirements for the respective objects and may cause
alignment issues unless alignment is also enforced
using a pragma.
Here, these packed attributes were causing alignment
faults in Thumb build.
Signed-off-by: Aneesh V
---
Changes in v4:
- None
Changes in v3:
- Newly added
---
arch/arm/include/asm/arch-omap4/mux_omap4.h |2 +-
arch/arm/include/asm/arch-omap5/mux_omap5.h |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/include/asm/arch-omap4/mux_omap4.h
b/arch/arm/include/asm/arch-omap4/mux_omap4.h
index 30bfad7..4de7c70 100644
--- a/arch/arm/include/asm/arch-omap4/mux_omap4.h
+++ b/arch/arm/include/asm/arch-omap4/mux_omap4.h
@@ -34,7 +34,7 @@ struct pad_conf_entry {
u16 val;
-} __attribute__ ((packed));
+};
#ifdef CONFIG_OFF_PADCONF
#define OFF_PD (1 << 12)
diff --git a/arch/arm/include/asm/arch-omap5/mux_omap5.h
b/arch/arm/include/asm/arch-omap5/mux_omap5.h
index b8c2185..af6874f 100644
--- a/arch/arm/include/asm/arch-omap5/mux_omap5.h
+++ b/arch/arm/include/asm/arch-omap5/mux_omap5.h
@@ -34,7 +34,7 @@ struct pad_conf_entry {
u16 val;
-} __attribute__ ((__packed__));
+};
#ifdef CONFIG_OFF_PADCONF
#define OFF_PD (1 << 12)
--
1.7.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 6/6] OMAP4: enable Thumb build
Signed-off-by: Aneesh V --- Changes in v4: - None Changes in v3: - None Changes from V1 to V2: - None Changes from RFC to V1: - None --- include/configs/omap4_common.h |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/include/configs/omap4_common.h b/include/configs/omap4_common.h index a989721..01b4d6c 100644 --- a/include/configs/omap4_common.h +++ b/include/configs/omap4_common.h @@ -287,4 +287,6 @@ #define CONFIG_SYS_ENABLE_PADS_ALL +#define CONFIG_SYS_THUMB_BUILD + #endif /* __CONFIG_OMAP4_COMMON_H */ -- 1.7.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/6] arm: adapt asm/linkage.h from Linux
Missed adding 'v4' in the subject. Please ignore this series. Will re-send correcting the subject. On Thursday 08 March 2012 10:40 PM, Aneesh V wrote: This will add ARM specific over-rides for the defines from linux/linkage.h Signed-off-by: Aneesh V --- Not adding the defines for __ALIGN and __ALIGN_STR because it's not clear why alignment is set to 0 (single byte alignment). Creates a checkpatch error that can not be avoided Changes in v4: - Use STT_FUNC in the definition of ENDPROC in include/linux/linkage.h that is more portable than the '*function' versions. Now, remove the definition of ENDPROC from the arm linkage.h Changes in v3: - None Changes in v2: - Newly added --- arch/arm/include/asm/linkage.h |7 +++ include/linux/linkage.h|7 ++- 2 files changed, 13 insertions(+), 1 deletions(-) create mode 100644 arch/arm/include/asm/linkage.h diff --git a/arch/arm/include/asm/linkage.h b/arch/arm/include/asm/linkage.h new file mode 100644 index 000..dbe4b4e --- /dev/null +++ b/arch/arm/include/asm/linkage.h @@ -0,0 +1,7 @@ +#ifndef __ASM_LINKAGE_H +#define __ASM_LINKAGE_H + +#define __ALIGN .align 0 +#define __ALIGN_STR ".align 0" + +#endif diff --git a/include/linux/linkage.h b/include/linux/linkage.h index ed4cf6c..7b749bb 100644 --- a/include/linux/linkage.h +++ b/include/linux/linkage.h @@ -44,8 +44,13 @@ #define SYMBOL_NAME_LABEL(X) X: #endif +#ifndef __ALIGN #define __ALIGN .align4 +#endif + +#ifndef __ALIGN_STR #define __ALIGN_STR ".align 4" +#endif #ifdef __ASSEMBLY__ @@ -67,7 +72,7 @@ #ifndef ENDPROC #define ENDPROC(name) \ - .type name, @function; \ + .type name STT_FUNC; \ END(name) #endif ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 0/6] Enable Thumb build for ARM platforms
Thumb is an alternate instruction set available in many ARM processors. Below is a detailed description from ARM specs: "The Thumb instruction set is a re-encoded subset of the ARM instruction set. Thumb instructions execute in their own processor state, with the architecture defining the mechanisms required to transition between ARM and Thumb states. The key difference is that Thumb instructions are half the size of ARM instructions(16 bits compared with 32 bits). Greater code density can usually be achieved by using the Thumb instruction set in preference to the ARM instruction set, at a cost of some reduction in performance" "In ARMv6T2, Thumb-2 technology is introduced. This technology makes it possible to extend the original Thumb instruction set with many 32-bit instructions. The range of 32-bit Thumb instructions included in ARMv6T2 permits Thumb code to achieve performance similar to ARM code, with code density better than that of earlier Thumb code. From ARMv6T2, the ARM and Thumb instruction sets provide almost identical functionality" This series adds Thumb support in U-Boot and enables it for OMAP4. It also fixes issues faced while booting OMAP4 with Thumb-2 images of U-Boot and SPL. Thumb mode is becoming increasingly relevant for U-Boot with the advent of SPL. It's very important to keep SPL size smaller considering the internal RAM size constraints on many platforms. On OMAP4 the size reduction enables us to use SPL on secure devices that have smaller internal RAM available for non-secure world. To enable support for new platforms you just need to add CONFIG_SYS_THUMB_BUILD in your config file. Tool-chains tried: 1. Sourcery G++ Lite 2010q1-202 arm-none-linux-gnueabi-gcc (Sourcery G++ Lite 2010q1-202) 4.4.1 GNU ld (Sourcery G++ Lite 2010q1-202) - binutils 2.19.51.20090709 2. Linaro 4.6-2012.01 arm-linux-gnueabi-gcc (crosstool-NG linaro-1.13.1-2012.01-20120125 - Linaro GCC 2012.01) 4.6.3 20120105 (prerelease) GNU ld (crosstool-NG linaro-1.13.1-2012.01-20120125 - Linaro GCC 2012.01) 2.22 Code-size reduction: Image ARM build Thumb build % Reduction u-boot.bin 190408 144676 24.01% u-boot-spl.bin 33200 25096 24.40% Performance(timestamp just before the main loop): ARM build Thumb build % Reduction 898510us878247us-2.25% Performance actually improved marginally for the Thumb build, maybe because of the reduced image sizes. Aneesh V (6): arm: adapt asm/linkage.h from Linux armv7: add appropriate headers for assembly functions ARM: enable Thumb build armv7: Use -march=armv7-a and thereby enable Thumb-2 omap4+: Avoid using __attribute__ ((__packed__)) OMAP4: enable Thumb build README |8 + arch/arm/config.mk | 22 + arch/arm/cpu/armv7/config.mk |7 +++- arch/arm/cpu/armv7/mx5/lowlevel_init.S |5 ++- arch/arm/cpu/armv7/mx6/lowlevel_init.S |5 ++- arch/arm/cpu/armv7/omap-common/lowlevel_init.S | 14 arch/arm/cpu/armv7/omap-common/reset.S |5 ++- arch/arm/cpu/armv7/omap3/lowlevel_init.S | 41 --- arch/arm/cpu/armv7/s5pc1xx/cache.S | 10 +++-- arch/arm/cpu/armv7/s5pc1xx/reset.S |5 ++- arch/arm/cpu/armv7/start.S | 13 --- arch/arm/cpu/armv7/tegra2/lowlevel_init.S |5 ++- arch/arm/cpu/armv7/u8500/lowlevel.S|9 +++-- arch/arm/include/asm/arch-omap4/mux_omap4.h|2 +- arch/arm/include/asm/arch-omap5/mux_omap5.h|2 +- arch/arm/include/asm/linkage.h |7 include/configs/omap4_common.h |2 + include/linux/linkage.h|7 +++- 18 files changed, 106 insertions(+), 63 deletions(-) create mode 100644 arch/arm/include/asm/linkage.h ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 1/6] arm: adapt asm/linkage.h from Linux
This will add ARM specific over-rides for the defines from linux/linkage.h Signed-off-by: Aneesh V --- Not adding the defines for __ALIGN and __ALIGN_STR because it's not clear why alignment is set to 0 (single byte alignment). Creates a checkpatch error that can not be avoided Changes in v4: - Use STT_FUNC in the definition of ENDPROC in include/linux/linkage.h that is more portable than the '*function' versions. Now, remove the definition of ENDPROC from the arm linkage.h Changes in v3: - None Changes in v2: - Newly added --- arch/arm/include/asm/linkage.h |7 +++ include/linux/linkage.h|7 ++- 2 files changed, 13 insertions(+), 1 deletions(-) create mode 100644 arch/arm/include/asm/linkage.h diff --git a/arch/arm/include/asm/linkage.h b/arch/arm/include/asm/linkage.h new file mode 100644 index 000..dbe4b4e --- /dev/null +++ b/arch/arm/include/asm/linkage.h @@ -0,0 +1,7 @@ +#ifndef __ASM_LINKAGE_H +#define __ASM_LINKAGE_H + +#define __ALIGN .align 0 +#define __ALIGN_STR ".align 0" + +#endif diff --git a/include/linux/linkage.h b/include/linux/linkage.h index ed4cf6c..7b749bb 100644 --- a/include/linux/linkage.h +++ b/include/linux/linkage.h @@ -44,8 +44,13 @@ #define SYMBOL_NAME_LABEL(X) X: #endif +#ifndef __ALIGN #define __ALIGN .align 4 +#endif + +#ifndef __ALIGN_STR #define __ALIGN_STR".align 4" +#endif #ifdef __ASSEMBLY__ @@ -67,7 +72,7 @@ #ifndef ENDPROC #define ENDPROC(name) \ - .type name, @function; \ + .type name STT_FUNC; \ END(name) #endif -- 1.7.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 2/6] armv7: add appropriate headers for assembly functions
Use ENTRY and ENDPROC with assembly functions to ensure
necessary assembler directives for all functions.
Signed-off-by: Aneesh V
---
Changes in v4:
- None
Changes in v3:
- None
Changes in V2:
- Newly added
---
arch/arm/cpu/armv7/mx5/lowlevel_init.S |5 ++-
arch/arm/cpu/armv7/mx6/lowlevel_init.S |5 ++-
arch/arm/cpu/armv7/omap-common/lowlevel_init.S | 14
arch/arm/cpu/armv7/omap-common/reset.S |5 ++-
arch/arm/cpu/armv7/omap3/lowlevel_init.S | 41 ---
arch/arm/cpu/armv7/s5pc1xx/cache.S | 10 +++--
arch/arm/cpu/armv7/s5pc1xx/reset.S |5 ++-
arch/arm/cpu/armv7/start.S | 13 ---
arch/arm/cpu/armv7/tegra2/lowlevel_init.S |5 ++-
arch/arm/cpu/armv7/u8500/lowlevel.S|9 +++--
10 files changed, 61 insertions(+), 51 deletions(-)
diff --git a/arch/arm/cpu/armv7/mx5/lowlevel_init.S
b/arch/arm/cpu/armv7/mx5/lowlevel_init.S
index 01f6d75..5344410 100644
--- a/arch/arm/cpu/armv7/mx5/lowlevel_init.S
+++ b/arch/arm/cpu/armv7/mx5/lowlevel_init.S
@@ -22,6 +22,7 @@
#include
#include
#include
+#include
/*
* L2CC Cache setup/invalidation/disable
@@ -312,8 +313,7 @@
.section ".text.init", "x"
-.globl lowlevel_init
-lowlevel_init:
+ENTRY(lowlevel_init)
#if defined(CONFIG_MX51)
ldr r0, =GPIO1_BASE_ADDR
ldr r1, [r0, #0x0]
@@ -334,6 +334,7 @@ lowlevel_init:
/* r12 saved upper lr*/
mov pc,lr
+ENDPROC(lowlevel_init)
/* Board level setting value */
W_DP_OP_864: .word DP_OP_864
diff --git a/arch/arm/cpu/armv7/mx6/lowlevel_init.S
b/arch/arm/cpu/armv7/mx6/lowlevel_init.S
index 1864356..acadef2 100644
--- a/arch/arm/cpu/armv7/mx6/lowlevel_init.S
+++ b/arch/arm/cpu/armv7/mx6/lowlevel_init.S
@@ -18,7 +18,8 @@
*/
.section ".text.init", "x"
-.globl lowlevel_init
-lowlevel_init:
+#include
+ENTRY(lowlevel_init)
mov pc, lr
+ENDPROC(lowlevel_init)
diff --git a/arch/arm/cpu/armv7/omap-common/lowlevel_init.S
b/arch/arm/cpu/armv7/omap-common/lowlevel_init.S
index 35f38ac..ccc6bb6 100644
--- a/arch/arm/cpu/armv7/omap-common/lowlevel_init.S
+++ b/arch/arm/cpu/armv7/omap-common/lowlevel_init.S
@@ -27,9 +27,9 @@
*/
#include
+#include
-.global save_boot_params
-save_boot_params:
+ENTRY(save_boot_params)
/*
* See if the rom code passed pointer is valid:
* It is not valid if it is not in non-secure SRAM
@@ -76,10 +76,9 @@ save_boot_params:
strbr2, [r3, #CH_FLAGS_OFFSET]
1:
bx lr
+ENDPROC(save_boot_params)
-
-.globl lowlevel_init
-lowlevel_init:
+ENTRY(lowlevel_init)
/*
* Setup a temporary stack
*/
@@ -95,12 +94,13 @@ lowlevel_init:
*/
bl s_init
pop {ip, pc}
+ENDPROC(lowlevel_init)
-.globl set_pl310_ctrl_reg
-set_pl310_ctrl_reg:
+ENTRY(set_pl310_ctrl_reg)
PUSH{r4-r11, lr}@ save registers - ROM code may pollute
@ our registers
LDR r12, =0x102 @ Set PL310 control register - value in R0
.word 0xe1600070 @ SMC #0 - hand assembled because -march=armv5
@ call ROM Code API to set control register
POP {r4-r11, pc}
+ENDPROC(set_pl310_ctrl_reg)
diff --git a/arch/arm/cpu/armv7/omap-common/reset.S
b/arch/arm/cpu/armv7/omap-common/reset.S
index 838b122..179a476 100644
--- a/arch/arm/cpu/armv7/omap-common/reset.S
+++ b/arch/arm/cpu/armv7/omap-common/reset.S
@@ -22,9 +22,9 @@
*/
#include
+#include
-.global reset_cpu
-reset_cpu:
+ENTRY(reset_cpu)
ldr r1, rstctl @ get addr for global reset
@ reg
ldr r3, rstbit @ sw reset bit
@@ -36,3 +36,4 @@ rstctl:
.word PRM_RSTCTRL
rstbit:
.word PRM_RSTCTRL_RESET
+ENDPROC(reset_cpu)
diff --git a/arch/arm/cpu/armv7/omap3/lowlevel_init.S
b/arch/arm/cpu/armv7/omap3/lowlevel_init.S
index c42c5dd..ebf69fa 100644
--- a/arch/arm/cpu/armv7/omap3/lowlevel_init.S
+++ b/arch/arm/cpu/armv7/omap3/lowlevel_init.S
@@ -31,22 +31,22 @@
#include
#include
#include
+#include
_TEXT_BASE:
.word CONFIG_SYS_TEXT_BASE/* sdram load addr from config.mk */
#ifdef CONFIG_SPL_BUILD
-.global save_boot_params
-save_boot_params:
+ENTRY(save_boot_params)
ldr r4, =omap3_boot_device
ldr r5, [r0, #0x4]
and r5, r5, #0xff
str r5, [r4]
bx lr
+ENDPROC(save_boot_params)
#endif
-.global omap3_gp_romcode_call
-omap3_gp_romcode_call:
+ENTRY(omap3_gp_romcode_call)
PUSH {r4-r12, lr} @ Save all registers from ROM code!
MOV r12, r0 @ Copy the Service ID in R12
MOV r0, r1 @ Copy parameter to R0
@@ -55,6 +55,7 @@ omap3_gp_romcode_call:
.word 0xe1600070 @ SMC #0 to enter monitor - hand assembled
[U-Boot] [PATCH v4 3/6] ARM: enable Thumb build
Enable Thumb build and ARM-Thumb interworking based on the new config flag CONFIG_SYS_THUMB_BUILD Signed-off-by: Aneesh V --- Changes in v4: - Use ':=' instead of '+=' when computed make variables are involved Changes in v3: - None Changes from V1 to V2: - None Changes from RFC to V1: - Fixed review comments from Tom Rini --- README |8 arch/arm/config.mk | 22 +++--- 2 files changed, 23 insertions(+), 7 deletions(-) diff --git a/README b/README index 8964672..bdb428e 100644 --- a/README +++ b/README @@ -426,6 +426,14 @@ The following options need to be configured: Select high exception vectors of the ARM core, e.g., do not clear the V bit of the c1 register of CP15. + CONFIG_SYS_THUMB_BUILD + + Use this flag to build U-Boot using the Thumb instruction + set for ARM architectures. Thumb instruction set provides + better code density. For ARM architectures that support + Thumb2 this flag will result in Thumb2 code generated by + GCC. + - Linux Kernel Interface: CONFIG_CLOCKS_IN_MHZ diff --git a/arch/arm/config.mk b/arch/arm/config.mk index 45f9dca..d4fa1f8 100644 --- a/arch/arm/config.mk +++ b/arch/arm/config.mk @@ -33,25 +33,33 @@ endif PLATFORM_CPPFLAGS += -DCONFIG_ARM -D__ARM__ -# Explicitly specifiy 32-bit ARM ISA since toolchain default can be -mthumb: -PF_CPPFLAGS_ARM := $(call cc-option,-marm,) +# Choose between ARM/Thumb instruction sets +ifeq ($(CONFIG_SYS_THUMB_BUILD),y) +PF_CPPFLAGS_ARM := $(call cc-option, -mthumb -mthumb-interwork,\ + $(call cc-option,-marm,)\ + $(call cc-option,-mno-thumb-interwork,)\ + ) +else +PF_CPPFLAGS_ARM := $(call cc-option,-marm,) \ + $(call cc-option,-mno-thumb-interwork,) +endif # Try if EABI is supported, else fall back to old API, # i. e. for example: # - with ELDK 4.2 (EABI supported), use: -# -mabi=aapcs-linux -mno-thumb-interwork +# -mabi=aapcs-linux # - with ELDK 4.1 (gcc 4.x, no EABI), use: -# -mabi=apcs-gnu -mno-thumb-interwork +# -mabi=apcs-gnu # - with ELDK 3.1 (gcc 3.x), use: -# -mapcs-32 -mno-thumb-interwork +# -mapcs-32 PF_CPPFLAGS_ABI := $(call cc-option,\ - -mabi=aapcs-linux -mno-thumb-interwork,\ + -mabi=aapcs-linux,\ $(call cc-option,\ -mapcs-32,\ $(call cc-option,\ -mabi=apcs-gnu,\ )\ - ) $(call cc-option,-mno-thumb-interwork,)\ + )\ ) PLATFORM_CPPFLAGS += $(PF_CPPFLAGS_ARM) $(PF_CPPFLAGS_ABI) -- 1.7.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 4/6] armv7: Use -march=armv7-a and thereby enable Thumb-2
Enable -march=armv7-a for armv7 platforms if the tool-chain supports it. This in turn results in Thumb-2 code generated for these platforms if CONFIG_SYS_THUMB_BUILD is enabled. Signed-off-by: Aneesh V --- I believe armv7-a is fine for all the SoCs except Tegra2 and I see that Tegra2 is already making the necessary exception in .../armv7/tegra2/config.mk Let me know if any other SoC has a problem with armv7-a Changes in V4: - Replaced "+=" with ":=" for make variable that involves computation Changes in V3: - None Changes from V1 to V2: - None Changes from RFC to V1: - Enabled armv7-a from armv7/config.mk instead of from omap config.mk files --- arch/arm/cpu/armv7/config.mk |7 +-- 1 files changed, 5 insertions(+), 2 deletions(-) diff --git a/arch/arm/cpu/armv7/config.mk b/arch/arm/cpu/armv7/config.mk index 83ddf10..6d4b13c 100644 --- a/arch/arm/cpu/armv7/config.mk +++ b/arch/arm/cpu/armv7/config.mk @@ -22,8 +22,11 @@ # PLATFORM_RELFLAGS += -fno-common -ffixed-r8 -msoft-float -# Make ARMv5 to allow more compilers to work, even though its v7a. -PLATFORM_CPPFLAGS += -march=armv5 +# If armv7-a is not supported by GCC fall-back to armv5, which is +# supported by more tool-chains +PF_CPPFLAGS_ARMV7 := $(call cc-option, -march=armv7-a, -march=armv5) +PLATFORM_CPPFLAGS += $(PF_CPPFLAGS_ARMV7) + # = # # Supply options according to compiler version -- 1.7.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 5/6] omap4+: Avoid using __attribute__ ((__packed__))
Avoid using __attribute__ ((__packed__)) unless it's
absolutely necessary. "packed" will remove alignment
requirements for the respective objects and may cause
alignment issues unless alignment is also enforced
using a pragma.
Here, these packed attributes were causing alignment
faults in Thumb build.
Signed-off-by: Aneesh V
---
Changes in v4:
- None
Changes in v3:
- Newly added
---
arch/arm/include/asm/arch-omap4/mux_omap4.h |2 +-
arch/arm/include/asm/arch-omap5/mux_omap5.h |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/include/asm/arch-omap4/mux_omap4.h
b/arch/arm/include/asm/arch-omap4/mux_omap4.h
index 30bfad7..4de7c70 100644
--- a/arch/arm/include/asm/arch-omap4/mux_omap4.h
+++ b/arch/arm/include/asm/arch-omap4/mux_omap4.h
@@ -34,7 +34,7 @@ struct pad_conf_entry {
u16 val;
-} __attribute__ ((packed));
+};
#ifdef CONFIG_OFF_PADCONF
#define OFF_PD (1 << 12)
diff --git a/arch/arm/include/asm/arch-omap5/mux_omap5.h
b/arch/arm/include/asm/arch-omap5/mux_omap5.h
index b8c2185..af6874f 100644
--- a/arch/arm/include/asm/arch-omap5/mux_omap5.h
+++ b/arch/arm/include/asm/arch-omap5/mux_omap5.h
@@ -34,7 +34,7 @@ struct pad_conf_entry {
u16 val;
-} __attribute__ ((__packed__));
+};
#ifdef CONFIG_OFF_PADCONF
#define OFF_PD (1 << 12)
--
1.7.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 6/6] OMAP4: enable Thumb build
Signed-off-by: Aneesh V --- Changes in v4: - None Changes in v3: - None Changes from V1 to V2: - None Changes from RFC to V1: - None --- include/configs/omap4_common.h |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/include/configs/omap4_common.h b/include/configs/omap4_common.h index a989721..01b4d6c 100644 --- a/include/configs/omap4_common.h +++ b/include/configs/omap4_common.h @@ -287,4 +287,6 @@ #define CONFIG_SYS_ENABLE_PADS_ALL +#define CONFIG_SYS_THUMB_BUILD + #endif /* __CONFIG_OMAP4_COMMON_H */ -- 1.7.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] ns16550: tegra: Specify debugging serial port at boot.
On 01/06/2012 05:51 AM, Stephen Warren wrote:
> From: Doug Anderson
>
> This works together with a kernel change that looks at the scratchpad
> register to determine which of the many UARTs it should use for early
> printing:
>
> http://www.spinics.net/lists/arm-kernel/msg154633.html
>
> While it is unfortunate to need to pass this information in a second way
> (it's already in the device tree), this does allow the very early boot
> code (decompressing stub and early assembly code) to print to the right
> port.
>
> At the moment, I'm adding this to the UART init function. Alternatively,
> we could add a more complex patch to key off of the 'console' setting.
>
> Signed-off-by: Doug Anderson
> [swarren: Limited the change to Tegra platforms]
> Signed-off-by: Stephen Warren
> Acked-by: Doug Anderson
I noticed this patch isn't applied yet that I can find. Are there any
comments on it; can it be applied? Thanks.
For reference, it's in patchwork at:
http://patchwork.ozlabs.org/patch/134712/
> ---
> drivers/serial/ns16550.c |7 +++
> 1 files changed, 7 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/serial/ns16550.c b/drivers/serial/ns16550.c
> index 0c23955..19a28cd 100644
> --- a/drivers/serial/ns16550.c
> +++ b/drivers/serial/ns16550.c
> @@ -62,6 +62,13 @@ void NS16550_init(NS16550_t com_port, int baud_divisor)
> serial_out(0, &com_port->mdr1);
> #endif
> #endif /* CONFIG_OMAP */
> +#if defined(CONFIG_TEGRA2)
> + /*
> + * Put a 'D' in the scratchpad to let the kernel know which UART
> + * for earlyprintk [D]ebugging.
> + */
> + serial_out('D', &com_port->spr);
> +#endif
> }
>
> #ifndef CONFIG_NS16550_MIN_FUNCTIONS
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] ubifsmount reports "Error reading superblock", but linux can mount FS
Dear Alex, In message you wrote: > > I've now managed to repro this problem and add some debug. It looks > like u-boot is simply running out of memory whilst trying to mount a > filesystem that "needs recovery". (Error -12 is -ENOMEM.) The > partition it is mounting is 240MB, but only about 40MB full. Can you please try out and test what happens when you increase the size of the malloc arena? "include/configs/openrd.h" includes "include/configs/mv-common.h" which sets CONFIG_SYS_MALLOC_LEN to 1 MiB - try changing it to 4 MiB. BTW: nice to "seeing" you again :-) Hope all is well for you. 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 Our OS who art in CPU, UNIX be thy name. Thy programs run, thy syscalls done, In kernel as it is in user! ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] ns16550: tegra: Specify debugging serial port at boot.
Dear Stephen Warren,
In message <4f58f5b8.6070...@wwwdotorg.org> you wrote:
>
> I noticed this patch isn't applied yet that I can find. Are there any
> comments on it; can it be applied? Thanks.
>
> For reference, it's in patchwork at:
> http://patchwork.ozlabs.org/patch/134712/
>
> > ---
> > drivers/serial/ns16550.c |7 +++
> > 1 files changed, 7 insertions(+), 0 deletions(-)
> >
> > diff --git a/drivers/serial/ns16550.c b/drivers/serial/ns16550.c
> > index 0c23955..19a28cd 100644
> > --- a/drivers/serial/ns16550.c
> > +++ b/drivers/serial/ns16550.c
> > @@ -62,6 +62,13 @@ void NS16550_init(NS16550_t com_port, int baud_divisor)
> > serial_out(0, &com_port->mdr1);
> > #endif
> > #endif /* CONFIG_OMAP */
> > +#if defined(CONFIG_TEGRA2)
> > + /*
> > +* Put a 'D' in the scratchpad to let the kernel know which UART
> > +* for earlyprintk [D]ebugging.
> > +*/
> > + serial_out('D', &com_port->spr);
> > +#endif
> > }
I don't like to see such highly architecture specific stuff in common
code, especially if it's such a dirty hack like this.
I don't really understand the arguments for the need of this patch
either. There are standard ways for passing hardware consifuration to
the kernel, and the comment shows that you are aware of these.
Inventing yet another hackish method seems not a good idea to 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
Chapter 1 -- The story so far:
In the beginning the Universe was created. This has made a lot of
people very angry and been widely regarded as a bad move.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] ns16550: tegra: Specify debugging serial port at boot.
On 03/08/2012 11:39 AM, Wolfgang Denk wrote:
> Dear Stephen Warren,
>
> In message <4f58f5b8.6070...@wwwdotorg.org> you wrote:
>>
>> I noticed this patch isn't applied yet that I can find. Are there any
>> comments on it; can it be applied? Thanks.
>>
>> For reference, it's in patchwork at:
>> http://patchwork.ozlabs.org/patch/134712/
>>
>>> ---
>>> drivers/serial/ns16550.c |7 +++
>>> 1 files changed, 7 insertions(+), 0 deletions(-)
>>>
>>> diff --git a/drivers/serial/ns16550.c b/drivers/serial/ns16550.c
>>> index 0c23955..19a28cd 100644
>>> --- a/drivers/serial/ns16550.c
>>> +++ b/drivers/serial/ns16550.c
>>> @@ -62,6 +62,13 @@ void NS16550_init(NS16550_t com_port, int baud_divisor)
>>> serial_out(0, &com_port->mdr1);
>>> #endif
>>> #endif /* CONFIG_OMAP */
>>> +#if defined(CONFIG_TEGRA2)
>>> + /*
>>> +* Put a 'D' in the scratchpad to let the kernel know which UART
>>> +* for earlyprintk [D]ebugging.
>>> +*/
>>> + serial_out('D', &com_port->spr);
>>> +#endif
>>> }
>
> I don't like to see such highly architecture specific stuff in common
> code, especially if it's such a dirty hack like this.
Are there any hooks where we can do the same thing in SoC-specific code?
> I don't really understand the arguments for the need of this patch
> either. There are standard ways for passing hardware consifuration to
> the kernel, and the comment shows that you are aware of these.
>
> Inventing yet another hackish method seems not a good idea to me.
The point of this information is to enable the kernel's earlyprintk
support, which runs well before the device tree, or other mechanisms,
are available.
As soon as the regular console, as set by the kernel command-line etc.,
is initialized by the regular "higher level" mechanisms, it takes over
from this earlyprintk code.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Enabling nand createbbt command
> -Original Message- > From: Scott Wood [mailto:scottw...@freescale.com] > Sent: Friday, 9 March 2012 5:54 a.m. > To: Bud Miljkovic > Cc: u-boot@lists.denx.de > Subject: Re: [U-Boot] Enabling nand createbbt command > > The BBT gets created automatically if it does not exist, provided the > NAND controller driver asks for it. Why do you need an explicit > command? I do not necessarily need an explicit command. I wanted to rebuild NAND BBT after scrubbing it. Is there another way to do that? Bud ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Enabling nand createbbt command
On 03/08/2012 01:38 PM, Bud Miljkovic wrote: >> -Original Message- >> From: Scott Wood [mailto:scottw...@freescale.com] >> Sent: Friday, 9 March 2012 5:54 a.m. >> To: Bud Miljkovic >> Cc: u-boot@lists.denx.de >> Subject: Re: [U-Boot] Enabling nand createbbt command >> >> The BBT gets created automatically if it does not exist, provided the >> NAND controller driver asks for it. Why do you need an explicit >> command? > > I do not necessarily need an explicit command. I wanted to rebuild NAND > BBT after scrubbing it. Is there another way to do that? It should happen automatically when nand_erase_opts() calls chip->scan_bbt(), provided the driver set the NAND_USE_FLASH_BBT flag, and that NAND_BBT_CREATE/NAND_BBT_WRITE are set in the nand_bbt_descr (this is the case if the driver doesn't override the default nand_bbt_descr). Are you not seeing it happen? What version of U-Boot are you using, with which NAND controller driver? -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] pull request: u-boot-tegra/master
Albert, Please pull u-boot-tegra/master into arm master. Thanks! The following changes since commit 32ec258f829808dd7cf74fd83ba999fdaaeab715: IXP: Fix GPIO_INT_ACT_LOW_SET() (2012-03-08 08:11:45 +0100) are available in the git repository at: git://git.denx.de/u-boot-tegra master Simon Glass (22): fdt: Add fdtdec_find_aliases() to deal with alias nodes fdt: Add tests for fdtdec fdt: Tidy up a few fdtdec problems fdt: Add functions to access phandles, arrays and bools fdt: Add basic support for decoding GPIO definitions arm: fdt: Add skeleton device tree file from kernel tegra: fdt: Add Tegra2x device tree file from kernel tegra: fdt: Add device tree file for Tegra2 Seaboard from kernel fdt: Add staging area for device tree binding documentation fdt: Add tegra-usb bindings file from linux tegra: fdt: Add additional USB binding tegra: fdt: Add clock bindings tegra: fdt: Add clock bindings for Tegra2 Seaboard tegra: usb: fdt: Add additional device tree definitions for USB ports tegra: usb: fdt: Add USB definitions for Tegra2 Seaboard usb: Add support for txfifo threshold tegra: fdt: Add function to return peripheral/clock ID tegra: usb: Add support for Tegra USB peripheral tegra: usb: Add USB support to nvidia boards tegra: usb: Add common USB defines for tegra2 boards tegra: usb: Enable USB on Seaboard tegra: fdt: Enable FDT support for Seaboard Tom Warren (2): arm: Tegra2: Fix ELDK42 gcc failure with inline asm stack pointer load tegra: fdt: Enable FDT support for Ventana README |3 + arch/arm/cpu/armv7/tegra2/Makefile |4 +- arch/arm/cpu/armv7/tegra2/ap20.c | 10 +- arch/arm/cpu/armv7/tegra2/clock.c | 58 +++ arch/arm/cpu/armv7/tegra2/config.mk|2 + arch/arm/cpu/armv7/tegra2/usb.c| 460 arch/arm/dts/skeleton.dtsi | 13 + arch/arm/dts/tegra20.dtsi | 188 arch/arm/include/asm/arch-tegra2/clock.h | 13 + arch/arm/include/asm/arch-tegra2/tegra2.h |2 + arch/arm/include/asm/arch-tegra2/usb.h | 252 +++ board/nvidia/common/board.c| 12 + board/nvidia/common/board.h|6 + board/nvidia/dts/tegra2-seaboard.dts | 74 board/nvidia/seaboard/seaboard.c |6 + doc/device-tree-bindings/README| 17 + .../clock/nvidia,tegra20-car.txt | 207 + doc/device-tree-bindings/usb/tegra-usb.txt | 25 + drivers/usb/host/Makefile |1 + drivers/usb/host/ehci-hcd.c|7 + drivers/usb/host/ehci-tegra.c | 62 +++ drivers/usb/host/ehci.h|6 +- include/configs/seaboard.h | 12 + include/configs/tegra2-common.h| 10 + include/configs/ventana.h |5 + include/fdtdec.h | 155 +++- lib/Makefile |1 + lib/fdtdec.c | 285 - lib/fdtdec_test.c | 226 ++ 29 files changed, 2105 insertions(+), 17 deletions(-) create mode 100644 arch/arm/cpu/armv7/tegra2/usb.c create mode 100644 arch/arm/dts/skeleton.dtsi create mode 100644 arch/arm/dts/tegra20.dtsi create mode 100644 arch/arm/include/asm/arch-tegra2/usb.h create mode 100644 board/nvidia/dts/tegra2-seaboard.dts create mode 100644 doc/device-tree-bindings/README create mode 100644 doc/device-tree-bindings/clock/nvidia,tegra20-car.txt create mode 100644 doc/device-tree-bindings/usb/tegra-usb.txt create mode 100644 drivers/usb/host/ehci-tegra.c create mode 100644 lib/fdtdec_test.c -- nvpublic ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Any outstanding ARM pull requests?
Hi Tom, Le 08/03/2012 17:02, Tom Warren a écrit : What's the cut-off? i.e. could I push it to tomorrow if I run across a problem in testing? No hurry. Wolfgang's pushed the deadline. :) (and yes, I saw the pull req and the subsequent hold request) Thanks, Tom Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Enabling nand createbbt command
On 03/08/2012 03:01 PM, Bud Miljkovic wrote: > >> -Original Message- >> From: Scott Wood [mailto:scottw...@freescale.com] >> Sent: Friday, 9 March 2012 9:02 a.m. >> To: Bud Miljkovic >> Cc: u-boot@lists.denx.de >> Subject: Re: [U-Boot] Enabling nand createbbt command >> >> >> It should happen automatically when nand_erase_opts() calls >> chip->scan_bbt(), provided the driver set the NAND_USE_FLASH_BBT flag, >> and that NAND_BBT_CREATE/NAND_BBT_WRITE are set in the nand_bbt_descr >> (this is the case if the driver doesn't override the default >> nand_bbt_descr). >> >> Are you not seeing it happen? What version of U-Boot are you using, >> with which NAND controller driver? > > I am using u-boot-2009.08 sources from Freescale released under SABRE > Automotive Infotainment board aka mx53_ard. Please use a recent upstream U-Boot, or contact supp...@freescale.com for support with your Freescale-supplied code. > Looking at this from the u-boot commands prospective, > - I get "nand - NAND sub-system" but it does not recognize "nand > createbbt" command Is there a reason you're expecting it to exist? > I am fairly newbee in this and would not know which NAND controller > driver is used. Why are you using the scrub command? It's an "I know what I'm doing" backdoor. There's even a warning, with confirmation prompt, telling you it's dangerous and to only use it "if you are sure of what you are doing". -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Enabling nand createbbt command
> -Original Message- > From: Scott Wood [mailto:scottw...@freescale.com] > Sent: Friday, 9 March 2012 10:09 a.m. > To: Bud Miljkovic > Cc: u-boot@lists.denx.de > Subject: Re: [U-Boot] Enabling nand createbbt command > > Please use a recent upstream U-Boot, or contact supp...@freescale.com > for support with your Freescale-supplied code. I took the what was linked at the SABRE Automotive Infotainment board Freescale page in January and applied all provided patches. I also have been trying to get some support from Freescale but not getting much there. Maybe I am not talking to the right people. > Is there a reason you're expecting it to exist? I saw such a command in some instructions I found on internet. But in essence, what I want to do it to partition the NAND device on the mx53_ard board. > Why are you using the scrub command? It's an "I know what I'm doing" > backdoor. There's even a warning, with confirmation prompt, telling > you > it's dangerous and to only use it "if you are sure of what you are > doing". I agree with you. I think I should be using nand erase instead. -Bud ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] ns16550: tegra: Specify debugging serial port at boot.
Dear Stephen, In message <4f590b25.8090...@wwwdotorg.org> you wrote: > > > I don't like to see such highly architecture specific stuff in common > > code, especially if it's such a dirty hack like this. > > Are there any hooks where we can do the same thing in SoC-specific code? Not without additional trickery, but I think this is actually a good thing. The method implemented here is but a dirty hack, and should not be used. > The point of this information is to enable the kernel's earlyprintk > support, which runs well before the device tree, or other mechanisms, > are available. Sorry, but I don't buy that this is the only possible way to do that. Or how comes only tegra2 would need that, while all other SoCs and architectures can do without it? 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 In the beginning there was nothing. And the Lord said "Let There Be Light!" And still there was nothing, but at least now you could see it. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Enabling nand createbbt command
On Thu, Mar 8, 2012 at 6:22 PM, Bud Miljkovic wrote: > > >> -Original Message- >> From: Scott Wood [mailto:scottw...@freescale.com] >> Sent: Friday, 9 March 2012 10:09 a.m. >> To: Bud Miljkovic >> Cc: u-boot@lists.denx.de >> Subject: Re: [U-Boot] Enabling nand createbbt command >> >> Please use a recent upstream U-Boot, or contact supp...@freescale.com >> for support with your Freescale-supplied code. > > I took the what was linked at the SABRE Automotive Infotainment board > Freescale page in January and applied all provided patches. I also have > been trying to get some support from Freescale but not getting much > there. Maybe I am not talking to the right people. I suggest you to work with the mainline U-boot version, Please note you would need to add mx53 support to drivers/mtd/nand/mxc_nand.c though. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] ns16550: tegra: Specify debugging serial port at boot.
On 03/08/2012 02:29 PM, Wolfgang Denk wrote:
> Dear Stephen,
>
> In message <4f590b25.8090...@wwwdotorg.org> you wrote:
>>
>>> I don't like to see such highly architecture specific stuff in common
>>> code, especially if it's such a dirty hack like this.
>>
>> Are there any hooks where we can do the same thing in SoC-specific code?
>
> Not without additional trickery, but I think this is actually a good
> thing.
>
> The method implemented here is but a dirty hack, and should not be
> used.
>
>> The point of this information is to enable the kernel's earlyprintk
>> support, which runs well before the device tree, or other mechanisms,
>> are available.
>
> Sorry, but I don't buy that this is the only possible way to do that.
> Or how comes only tegra2 would need that, while all other SoCs and
> architectures can do without it?
First, OMAP does something very similar; the kernel low-level debug code
looks at UART1's scratch pad register, and derives which UART to use
based on the value stored there. If none of the expected values is
found, it appears to default to UART1.
On Tegra, the UART registers can't be read unless the UART is clocked
and not in reset. So, the Tegra code looks at each UART in the system,
and finds one that's in that state. To cater for the scenario where
multiple UARTs are clocked-and-not-reset, the code also checks whether
the UART scratch register contains 'D' ("D"ebug) so it's sure it picked
the correct one.
So, at leasst OMAP has set precedent here. There may be others; I didn't
check.
Some other SoCs may have only 1 UART and not need to auto-select.
Some other SoCs with multiple UARTs may designate a single specific UART
as the debug port rather than the board designer apparently randomly
picking which one to use. In either of those cases, the kernel's
low-level debug code can simply hard-code the UART address and do
without the hand-shaking.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Enabling nand createbbt command
From: Fabio Estevam > Sent: Friday, 9 March 2012 10:42 a.m. > To: Bud Miljkovic > Cc: Scott Wood > Subject: Re: [U-Boot] Enabling nand createbbt command > > > > I took the what was linked at the SABRE Automotive Infotainment > > board Freescale page in January and applied all provided patches. I > > also > have > > been trying to get some support from Freescale but not getting much > > there. Maybe I am not talking to the right people. > > I suggest you to work with the mainline U-boot version, Could you elaborate this point? > > Please note you would need to add mx53 support to > drivers/mtd/nand/mxc_nand.c though. Any hints how I do this? I've tried it before but since I was not successful I went to the Freescale u-boot version. -Bud ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] Makefile: fdt: Make the final build result be u-boot.bin
Users expect the final build result to be u-boot.bin. Preserve this
expectation even when CONFIG_OF_SEPARATE is enabled.
If the user wants to append a custom DTB rather than the one the U-Boot
build process creates, they can append it to u-boot-nofdt.bin.
Signed-off-by: Stephen Warren
---
This patch fixes the issue I have with the Makefile changes in the FDT
patch series currently pending pull from u-boot-tegra.git to u-boot-arm.git.
As mentioned above, the issue I have is that the patch series changes the
name of the file that must be burned into flash for DT-enabled boards.
While this is documented in the README, people won't in general even be
aware that anything like this has changed, and hence probably won't go and
re-read the README to discover this. I'd imagine most people won't even be
aware that Seaboard now uses device tree to boot. This wouldn't be a
problem if either:
a) The expected u-boot.bin no longer existed, so it wasn't possible to use
it.
or:
b) The file u-boot.bin would print some meaningful message when burned to
flash, rather than simply being silent, or spewing garbage to the serial
port.
Those issues prevent the problem from being readily "discoverable". This
patch fixes the issue in a somewhat more direct manner, such that nobody
has to change their workflow, let alone find out why.
Tom Warren asked me to ask the U-Boot community's opinion on this problem,
so I'm doing so by posting my proposed solution.
Tom, if this is acceptable, I think this patch should be squashed into one
of the patches in your to-be-pulled branch so that there is no set of
commits where this is broken.
Potential open question: Should more than just u-boot.bin be renamed by
appending $(UBOOT_BIN_EXTRANAME)?
Makefile | 18 +-
README |6 +++---
2 files changed, 16 insertions(+), 8 deletions(-)
diff --git a/Makefile b/Makefile
index 36246b6..ebd6402 100644
--- a/Makefile
+++ b/Makefile
@@ -360,6 +360,12 @@ else
BOARD_SIZE_CHECK =
endif
+ifeq ($(CONFIG_OF_SEPARATE),y)
+UBOOT_BIN_EXTRANAME := -nodtb
+else
+UBOOT_BIN_EXTRANAME :=
+endif
+
# Always append ALL so that arch config.mk's can add custom ones
ALL-y += $(obj)u-boot.srec $(obj)u-boot.bin $(obj)System.map
@@ -368,7 +374,7 @@ ALL-$(CONFIG_ONENAND_U_BOOT) += $(obj)u-boot-onenand.bin
ONENAND_BIN ?= $(obj)onenand_ipl/onenand-ipl-2k.bin
ALL-$(CONFIG_MMC_U_BOOT) += $(obj)mmc_spl/u-boot-mmc-spl.bin
ALL-$(CONFIG_SPL) += $(obj)spl/u-boot-spl.bin
-ALL-$(CONFIG_OF_SEPARATE) += $(obj)u-boot.dtb $(obj)u-boot-dtb.bin
+ALL-$(CONFIG_OF_SEPARATE) += $(obj)u-boot.dtb
$(obj)u-boot$(UBOOT_BIN_EXTRANAME).bin
all: $(ALL-y) $(SUBDIR_EXAMPLES)
@@ -376,19 +382,21 @@ $(obj)u-boot.dtb: $(obj)u-boot
$(MAKE) -C dts binary
mv $(obj)dts/dt.dtb $@
-$(obj)u-boot-dtb.bin: $(obj)u-boot.bin $(obj)u-boot.dtb
- cat $^ >$@
-
$(obj)u-boot.hex: $(obj)u-boot
$(OBJCOPY) ${OBJCFLAGS} -O ihex $< $@
$(obj)u-boot.srec: $(obj)u-boot
$(OBJCOPY) -O srec $< $@
-$(obj)u-boot.bin: $(obj)u-boot
+$(obj)u-boot$(UBOOT_BIN_EXTRANAME).bin:$(obj)u-boot
$(OBJCOPY) ${OBJCFLAGS} -O binary $< $@
$(BOARD_SIZE_CHECK)
+ifeq ($(CONFIG_OF_SEPARATE),y)
+$(obj)u-boot.bin: $(obj)u-boot$(UBOOT_BIN_EXTRANAME).bin $(obj)u-boot.dtb
+ cat $^ > $@
+endif
+
$(obj)u-boot.ldr: $(obj)u-boot
$(CREATE_LDR_ENV)
$(LDR) -T $(CONFIG_BFIN_CPU) -c $@ $< $(LDR_FLAGS)
diff --git a/README b/README
index 7adf7c7..990cefc 100644
--- a/README
+++ b/README
@@ -865,10 +865,10 @@ The following options need to be configured:
binary. It will be called u-boot.dtb. Architecture-specific
code will locate it at run-time. Generally this works by:
- cat u-boot.bin u-boot.dtb >image.bin
+ cat u-boot-notdb.bin u-boot.dtb > u-boot.bin
- and in fact, U-Boot does this for you, creating a file called
- u-boot-dtb.bin which is useful in the common case. You can
+ and in fact, U-Boot does this for you, as part of creating
+ u-boot.bin which is useful in the common case. You can
still use the individual files if you need something more
exotic.
--
1.7.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Enabling nand createbbt command
On Thu, Mar 8, 2012 at 6:48 PM, Bud Miljkovic wrote: > Could you elaborate this point? My suggestion is that you use U-boot from git.denx.de instead of the 2009.08 from FSL. > >> >> Please note you would need to add mx53 support to >> drivers/mtd/nand/mxc_nand.c though. > > Any hints how I do this? I've tried it before but since I was not successful > I went to the Freescale u-boot version. Please post your mx53 nand patches to the list and ask for advice. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Enabling nand createbbt command
From: Fabio Estevam [mailto:feste...@gmail.com] > > Sent: Friday, 9 March 2012 11:45 a.m. > > To: Bud Miljkovic > > Cc: Scott Wood; u-boot@lists.denx.de > > Subject: Re: [U-Boot] Enabling nand createbbt command > > > > > > My suggestion is that you use U-boot from git.denx.de instead of the > > 2009.08 from FSL. Is that because the mainline U-boot id better maintained and/or ... ? -Bud ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Enabling nand createbbt command
On 03/08/2012 04:49 PM, Bud Miljkovic wrote: > > >> -Original Message- >> From: Fabio Estevam [mailto:feste...@gmail.com] >> Sent: Friday, 9 March 2012 11:45 a.m. >> To: Bud Miljkovic >> Cc: Scott Wood; u-boot@lists.denx.de >> Subject: Re: [U-Boot] Enabling nand createbbt command >> >> >> My suggestion is that you use U-boot from git.denx.de instead of the >> 2009.08 from FSL. > > Is that because the mainline U-boot id better maintained and/or ... ? Well for once thing, it's because you're asking for help on the mailing list for mainline U-Boot. :-) We can't help you with some other codebase that we know nothing about. I do expect mainline is better maintained and supported, except for missing particular features/hardware support that nobody ever bothered to submit to mainline -- which in this case appears to be hardware that you care about, so unless you're prepared to do a fair bit of work to add support to mainline, I'd try again to find a support channel for your Freescale-provided U-Boot. Or maybe we could help you figure out what it is you want to do, instead of scrubbing, if the answer doesn't depend on details of a non-standard U-Boot. Oh, and if you're curious about my freescale.com e-mail address, I work in a different part of the company and don't have i.MX knowledge or contacts. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Enabling nand createbbt command
On Thu, Mar 8, 2012 at 8:01 PM, Bud Miljkovic wrote: > Is that because the mainline U-boot id better maintained and/or ... ? Correct. In case you are interested in adding mx53 nand support into mainline U-boot, this FSL patch can be helpful as a reference: http://opensource.freescale.com/git?p=imx/uboot-imx.git;a=commitdiff;h=9bbe28258c19c28f8f85c22c932bd119368cfacb Regards, Fabio Estevam ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] ns16550: tegra: Specify debugging serial port at boot.
Hi Stephen, Wolfgang,
On Fri, Mar 9, 2012 at 8:43 AM, Stephen Warren wrote:
> On 03/08/2012 02:29 PM, Wolfgang Denk wrote:
>> Dear Stephen,
>>
>> In message <4f590b25.8090...@wwwdotorg.org> you wrote:
>>>
I don't like to see such highly architecture specific stuff in common
code, especially if it's such a dirty hack like this.
>>>
>>> Are there any hooks where we can do the same thing in SoC-specific code?
>>
>> Not without additional trickery, but I think this is actually a good
>> thing.
>>
>> The method implemented here is but a dirty hack, and should not be
>> used.
INIT_FUNC will resolve this issue long-term - Tegra can just put in:
int tegra_set_debug_port(void)
{
/*
* Put a 'D' in the scratchpad to let the kernel know which UART
* for earlyprintk [D]ebugging.
*/
serial_out('D', &com_port->spr);
return 0;
}
INIT_FUNC(set_debug_port, tegra_set_debug_port, *serial_init)
>>> The point of this information is to enable the kernel's earlyprintk
>>> support, which runs well before the device tree, or other mechanisms,
>>> are available.
>>
>> Sorry, but I don't buy that this is the only possible way to do that.
>> Or how comes only tegra2 would need that, while all other SoCs and
>> architectures can do without it?
>
> First, OMAP does something very similar; the kernel low-level debug code
> looks at UART1's scratch pad register, and derives which UART to use
> based on the value stored there. If none of the expected values is
> found, it appears to default to UART1.
>
> On Tegra, the UART registers can't be read unless the UART is clocked
> and not in reset. So, the Tegra code looks at each UART in the system,
> and finds one that's in that state. To cater for the scenario where
> multiple UARTs are clocked-and-not-reset, the code also checks whether
> the UART scratch register contains 'D' ("D"ebug) so it's sure it picked
> the correct one.
>
> So, at leasst OMAP has set precedent here. There may be others; I didn't
> check.
>
> Some other SoCs may have only 1 UART and not need to auto-select.
>
> Some other SoCs with multiple UARTs may designate a single specific UART
> as the debug port rather than the board designer apparently randomly
> picking which one to use. In either of those cases, the kernel's
> low-level debug code can simply hard-code the UART address and do
> without the hand-shaking.
As far as I am aware, earlyprintk happens well before processing the kernel
command line so, IMHO, I don't consider setting up the hardware in order
for the kernel to get some low-level information which cannot be
provided by the command line as a hack. Reading the above, I actually think
it is quite elegant
Regards,
Graeme
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Enabling nand createbbt command
Thank you Scott and Fabio, You help is much appreciated. I will try to add the nand support for mx53 mainline. However, what I am trying to do is to build a u-boot that supports NAND and have YAFFS2 as well and at moment I use the mx53_ard board since this is very close to what my custom board will be. I was able to build such a version, using Freescale u-boot sources, which included nand subsystem, and yaffs commands. Then I needed to create partitions in the nand and this is where i "discovered" I needed the support of mtdparts command. So I, guess, I need to configure the u-boot for mtdparts support. This is where I am at. -Bud > -Original Message- > From: Scott Wood > Sent: Friday, 9 March 2012 12:04 p.m. > To: Bud Miljkovic > Cc: Fabio Estevam; > Subject: Re: [U-Boot] Enabling nand createbbt command > > I do expect mainline is better maintained and supported, except for > missing particular features/hardware support that nobody ever bothered > to submit to mainline -- which in this case appears to be hardware > that you care about, so unless you're prepared to do a fair bit of > work to add support to mainline, I'd try again to find a support > channel for your Freescale-provided U-Boot. Or maybe we could help > you figure out what it is you want to do, instead of scrubbing, if the > answer doesn't depend on details of a non-standard U-Boot. > > Oh, and if you're curious about my freescale.com e-mail address, I > work in a different part of the company and don't have i.MX knowledge > or contacts. > > -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/2] tegra: Implement pre-console putc() for fdt warning
When there is not device tree file available to U-Boot, we panic.
Implement board_pre_console_putc() so that this panic will be displayed
on the serial console.
Signed-off-by: Simon Glass
---
arch/arm/cpu/armv7/tegra2/board.c | 58 +
1 files changed, 58 insertions(+), 0 deletions(-)
diff --git a/arch/arm/cpu/armv7/tegra2/board.c
b/arch/arm/cpu/armv7/tegra2/board.c
index 349d50e..4ca1e1f 100644
--- a/arch/arm/cpu/armv7/tegra2/board.c
+++ b/arch/arm/cpu/armv7/tegra2/board.c
@@ -23,9 +23,11 @@
#include
#include
+#include
#include "ap20.h"
#include
#include
+#include
#include
#include
#include
@@ -37,6 +39,7 @@ enum {
UARTA = 1 << 0,
UARTB = 1 << 1,
UARTD = 1 << 3,
+ UART_ALL = 0xf,
UART_COUNT = 4,
};
@@ -149,3 +152,58 @@ void enable_caches(void)
dcache_enable();
}
#endif
+
+
+/*
+ * Possible UART locations: we ignore UARTC at 0x70006200 and UARTE at
+ * 0x70006400, since we don't have code to init them
+ */
+static u32 uart_reg_addr[] = {
+ NV_PA_APB_UARTA_BASE,
+ NV_PA_APB_UARTB_BASE,
+ NV_PA_APB_UARTD_BASE,
+ 0
+};
+
+#ifdef CONFIG_PRE_CONSOLE_PUTC
+/*
+ * This is called when we have no console. About the only reason that this
+ * happen is if we don't have a valid fdt. So we don't know what kind of
+ * Tegra board we are. We blindly try to print a message every which way we
+ * know.
+ */
+void board_pre_console_putc(int ch)
+{
+ int uart_ids = UART_ALL;/* turn it all on! */
+ u32 *uart_addr;
+ int clock_freq, multiplier, baudrate, divisor;
+
+ /* Try to enable all possible UARTs */
+ setup_uarts(uart_ids);
+
+ /*
+* Seaboard has a UART switch on PI3. We might be a Seaboard,
+* so flip it!
+*/
+#ifdef CONFIG_SPI_UART_SWITCH
+ gpio_direction_output(GPIO_PI3, 0);
+#endif
+
+ /*
+* Now send the string out all the Tegra UARTs. We don't try all
+* possible configurations, but this could be added if required.
+*/
+ clock_freq = CONFIG_DEFAULT_NS16550_CLK;
+ multiplier = CONFIG_DEFAULT_NS16550_MULT;
+ baudrate = CONFIG_BAUDRATE;
+ divisor = (clock_freq + (baudrate * (multiplier / 2))) /
+ (multiplier * baudrate);
+
+ for (uart_addr = uart_reg_addr; *uart_addr; uart_addr++) {
+ NS16550_init((NS16550_t)*uart_addr, divisor);
+ NS16550_putc((NS16550_t)*uart_addr, ch);
+ if (ch == '\n')
+ NS16550_putc((NS16550_t)*uart_addr, '\r');
+ }
+}
+#endif
--
1.7.7.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/2] tegra: Enable pre-console putc() for Tegra boards
This is used to display panic messages before the console is active. Signed-off-by: Simon Glass --- include/configs/tegra2-common.h |7 +++ 1 files changed, 7 insertions(+), 0 deletions(-) diff --git a/include/configs/tegra2-common.h b/include/configs/tegra2-common.h index e6f385f..6ced617 100644 --- a/include/configs/tegra2-common.h +++ b/include/configs/tegra2-common.h @@ -68,11 +68,18 @@ */ #define V_NS16550_CLK 21600 /* 216MHz (pllp_out0) */ +/* Default serial clock and multiplier */ +#define CONFIG_DEFAULT_NS16550_CLK V_NS16550_CLK +#define CONFIG_DEFAULT_NS16550_MULT16 + #define CONFIG_SYS_NS16550 #define CONFIG_SYS_NS16550_SERIAL #define CONFIG_SYS_NS16550_REG_SIZE(-4) #define CONFIG_SYS_NS16550_CLK V_NS16550_CLK +/* We use this for a warning message when no device tree is present */ +#define CONFIG_PRE_CONSOLE_PUTC + /* * select serial console configuration */ -- 1.7.7.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Makefile: fdt: Make the final build result be u-boot.bin
+Jerry
Hi Stephen,
On Thu, Mar 8, 2012 at 2:29 PM, Stephen Warren wrote:
> Users expect the final build result to be u-boot.bin. Preserve this
> expectation even when CONFIG_OF_SEPARATE is enabled.
>
> If the user wants to append a custom DTB rather than the one the U-Boot
> build process creates, they can append it to u-boot-nofdt.bin.
>
> Signed-off-by: Stephen Warren
> ---
> This patch fixes the issue I have with the Makefile changes in the FDT
> patch series currently pending pull from u-boot-tegra.git to u-boot-arm.git.
Actually there are no changes to the Makefile in that series. The
behaviour you see is in U-Boot already. There was some discussion at
the time I believe.
>
> As mentioned above, the issue I have is that the patch series changes the
> name of the file that must be burned into flash for DT-enabled boards.
> While this is documented in the README, people won't in general even be
> aware that anything like this has changed, and hence probably won't go and
> re-read the README to discover this. I'd imagine most people won't even be
> aware that Seaboard now uses device tree to boot. This wouldn't be a
> problem if either:
>
> a) The expected u-boot.bin no longer existed, so it wasn't possible to use
> it.
We could put it somewhere else, but build systems that want to write
u-boot.bin and the fdt separate into flash will need it.
>
> or:
>
> b) The file u-boot.bin would print some meaningful message when burned to
> flash, rather than simply being silent, or spewing garbage to the serial
> port.
I have sent a patch to do this - it was discussed on the list some time back.
>
> Those issues prevent the problem from being readily "discoverable". This
> patch fixes the issue in a somewhat more direct manner, such that nobody
> has to change their workflow, let alone find out why.
>
> Tom Warren asked me to ask the U-Boot community's opinion on this problem,
> so I'm doing so by posting my proposed solution.
>
> Tom, if this is acceptable, I think this patch should be squashed into one
> of the patches in your to-be-pulled branch so that there is no set of
> commits where this is broken.
No, I think this is a separate patch.
>
> Potential open question: Should more than just u-boot.bin be renamed by
> appending $(UBOOT_BIN_EXTRANAME)?
>
> Makefile | 18 +-
> README | 6 +++---
> 2 files changed, 16 insertions(+), 8 deletions(-)
>
> diff --git a/Makefile b/Makefile
> index 36246b6..ebd6402 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -360,6 +360,12 @@ else
> BOARD_SIZE_CHECK =
> endif
>
> +ifeq ($(CONFIG_OF_SEPARATE),y)
> +UBOOT_BIN_EXTRANAME := -nodtb
> +else
> +UBOOT_BIN_EXTRANAME :=
> +endif
> +
> # Always append ALL so that arch config.mk's can add custom ones
> ALL-y += $(obj)u-boot.srec $(obj)u-boot.bin $(obj)System.map
>
> @@ -368,7 +374,7 @@ ALL-$(CONFIG_ONENAND_U_BOOT) += $(obj)u-boot-onenand.bin
> ONENAND_BIN ?= $(obj)onenand_ipl/onenand-ipl-2k.bin
> ALL-$(CONFIG_MMC_U_BOOT) += $(obj)mmc_spl/u-boot-mmc-spl.bin
> ALL-$(CONFIG_SPL) += $(obj)spl/u-boot-spl.bin
> -ALL-$(CONFIG_OF_SEPARATE) += $(obj)u-boot.dtb $(obj)u-boot-dtb.bin
> +ALL-$(CONFIG_OF_SEPARATE) += $(obj)u-boot.dtb
> $(obj)u-boot$(UBOOT_BIN_EXTRANAME).bin
>
> all: $(ALL-y) $(SUBDIR_EXAMPLES)
>
> @@ -376,19 +382,21 @@ $(obj)u-boot.dtb: $(obj)u-boot
> $(MAKE) -C dts binary
> mv $(obj)dts/dt.dtb $@
>
> -$(obj)u-boot-dtb.bin: $(obj)u-boot.bin $(obj)u-boot.dtb
> - cat $^ >$@
> -
> $(obj)u-boot.hex: $(obj)u-boot
> $(OBJCOPY) ${OBJCFLAGS} -O ihex $< $@
>
> $(obj)u-boot.srec: $(obj)u-boot
> $(OBJCOPY) -O srec $< $@
>
> -$(obj)u-boot.bin: $(obj)u-boot
> +$(obj)u-boot$(UBOOT_BIN_EXTRANAME).bin: $(obj)u-boot
> $(OBJCOPY) ${OBJCFLAGS} -O binary $< $@
> $(BOARD_SIZE_CHECK)
>
> +ifeq ($(CONFIG_OF_SEPARATE),y)
> +$(obj)u-boot.bin: $(obj)u-boot$(UBOOT_BIN_EXTRANAME).bin
> $(obj)u-boot.dtb
> + cat $^ > $@
> +endif
> +
> $(obj)u-boot.ldr: $(obj)u-boot
> $(CREATE_LDR_ENV)
> $(LDR) -T $(CONFIG_BFIN_CPU) -c $@ $< $(LDR_FLAGS)
> diff --git a/README b/README
> index 7adf7c7..990cefc 100644
> --- a/README
> +++ b/README
> @@ -865,10 +865,10 @@ The following options need to be configured:
> binary. It will be called u-boot.dtb. Architecture-specific
> code will locate it at run-time. Generally this works by:
>
> - cat u-boot.bin u-boot.dtb >image.bin
> + cat u-boot-notdb.bin u-boot.dtb > u-boot.bin
>
> - and in fact, U-Boot does this for you, creating a file called
> - u-boot-dtb.bin which is useful in the common case. You can
> + and in fact, U-Boot does this for you, as part of creating
> + u-boot.bin which is useful in the common case. You can
> still use the individual f
Re: [U-Boot] [PATCH 1/2] tegra: Implement pre-console putc() for fdt warning
On Thursday 08 March 2012 21:52:56 Simon Glass wrote:
> --- a/arch/arm/cpu/armv7/tegra2/board.c
> +++ b/arch/arm/cpu/armv7/tegra2/board.c
>
> +static u32 uart_reg_addr[] = {
const
-mike
signature.asc
Description: This is a digitally signed message part.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] (no subject)
On Thursday 08 March 2012 01:37:08 Simon Glass wrote: > Yes I just cleaned up mine...it would be nice if you could select > multiple patches at the top level and perform actions on them. https://chrome.google.com/webstore/detail/ldopaogbegnhconlboidfjcmidndkbeg -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] (no subject)
On Wednesday 07 March 2012 06:25:15 Wolfgang Denk wrote: > So should this not go into the upcoming release? I would expect it should. ok, i can put together a branch for you to pull > Yes - I find this still to be way more efficient that working with > the slow web interface of PW, and JK still has not incoreporated the > (long available) mail interface patches. for the sandbox ones, you can just mark them all "handled" as i've done that. if something has been missed, Simon can bug me. -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v8] usb: align buffers at cacheline
Hi Marek,
On Thursday 08 March 2012 07:42 PM, Marek Vasut wrote:
Dear puneets,
Hi Marek,
On Thursday 08 March 2012 03:36 AM, Marek Vasut wrote:
Dear puneets,
Hi Mike,
On Tuesday 06 March 2012 08:37 AM, Mike Frysinger wrote:
* PGP Signed by an unknown key
On Monday 05 March 2012 09:46:21 Puneet Saxena wrote:
As DMA expects the buffers to be equal and larger then
cache lines, This aligns buffers at cacheline.
i don't think this statement is true. DMA doesn't care about alignment
(well, some do, but it's not related to cache lines but rather some
other restriction in the peripheral DMA itself). what does matter is
that cache operations operate on cache lines and not individual bytes.
hence the core arm code was updated to warn when someone told it to
invalidate X bytes but the hardware literally could not, so it had to
invalidate X + Y bytes.
Agreed, Will update the commit message in next patchset.
--- a/drivers/usb/host/ehci-hcd.c
+++ b/drivers/usb/host/ehci-hcd.c
static void flush_invalidate(u32 addr, int size, int flush)
{
+ /*
+* Size is the bytes actually moved during transaction,
+* which may not equal to the cache line. This results
+* stop address passed for invalidating cache may not be
aligned.
+* Therfore making size as multiple of cache line size.
+*/
+ size = ALIGN(size, ARCH_DMA_MINALIGN);
+
if (flush)
flush_dcache_range(addr, addr + size);
else
i think this is wrong and merely hides the errors from higher up
instead of fixing them. the point of the warning was to tell you that
the code was invalidating *too many* bytes. this code still
invalidates too many bytes without any justification as for why it's
OK to do here. further, this code path only matters to the
invalidation logic, not the flush logic. -mike
The sole purpose of this patch to remove the warnings as start/stop
address sent for invalidating
is unaligned. Without this patch code works fine but with lots of
spew...Which we don't want and discussed
in earlier thread which Simon posted. Please have a look on following
link.
As I understood, you agree that we need to align start/stop buffer
address and also agree that
to align stop address we need to align size as start address is already
aligned.
Now, "why its OK to do here"?
We could have aligned the size in two places, cache_qtd() and cache_qh()
but then we need to place alignment check
at all the places where size is passed. So I thought better Aligning at
flush_invalidate() and "ALIGN" macro does not
increase the size if size is already aligned.
Actually I have to agree with Mike here. Can you please remove that
ALIGN() (and all others you might have added)? If it does spew, that's
ok and it tells us something is wrong in the USB core subsystem. Such
stuff can be fixed in subsequent patch.
Sorry, I could not understand "(and all others you might have added)".
Do you want me remove any HACK in the patch which is using ALIGN or
making stop address
No, only such hacks where it's certain they will either invalidate or flush some
areas that weren't allocated for them, like this ALIGN you did here. This can
cause trouble that will be very hard to find.
aligned? The patch has only the above line to make stop address align
and rest of the code makes
start address align. Just to confirm, you are fine with the start
address alignment code in the patch?
The start address alignment you do also aligns the end to the cacheline, doesn't
it? (at least that's what I believe the macro is supposed to do).
Yes, start address alignment also aligns start address at the cache
line. So, removing
stop address alignment code as depicted above, should make this patch
acceptable?
Best regards,
Marek Vasut
Thanx& Regards,
Puneet
---
This email message is for the sole use of the intended
recipient(s) and may contain confidential information. Any unauthorized
review, use, disclosure or distribution is prohibited. If you are not the
intended recipient, please contact the sender by reply email and destroy
all copies of the original message.
---
Best regards,
Marek Vasut
Thanx & Regards,
Puneet
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] arm: vexpress: Fixed get_ticks/get_tbclk build failures
On Mon, Mar 05, 2012 at 06:40:36PM -0700, matt.wad...@linaro.org wrote:
>From: Matt Waddel
>
>Added get_ticks() and get_tbclk() routines
Hi Matt waddel,
I have posted the fix before:
http://patchwork.ozlabs.org/patch/142477/
Liming Wang
>
>Signed-off-by: Matt Waddel
>---
> board/armltd/vexpress/ca9x4_ct_vxp.c | 10 ++
> 1 files changed, 10 insertions(+), 0 deletions(-)
>
>diff --git a/board/armltd/vexpress/ca9x4_ct_vxp.c
>b/board/armltd/vexpress/ca9x4_ct_vxp.c
>index da6f14d..22e5af1 100644
>--- a/board/armltd/vexpress/ca9x4_ct_vxp.c
>+++ b/board/armltd/vexpress/ca9x4_ct_vxp.c
>@@ -226,3 +226,13 @@ void lowlevel_init(void)
> ulong get_board_rev(void){
> return readl((u32 *)SYS_ID);
> }
>+
>+unsigned long long get_ticks(void)
>+{
>+ return get_timer(0);
>+}
>+
>+ulong get_tbclk(void)
>+{
>+ return (ulong)CONFIG_SYS_HZ;
>+}
>--
>1.7.5.4
>
>___
>U-Boot mailing list
>U-Boot@lists.denx.de
>http://lists.denx.de/mailman/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 00/25] SPEAr: Update platform support for SPEAr3xx/6xx
Hello Stefan, We already talked about this off list. I think it makes much sense to install an SPEAr U-Boot custodian, to offload Albert a bit. As I understand there are more SPEAr patches to be seen soon. And I also have some waiting here (SPL support etc). So who would be best suited to become SPEAr custodian? Amit, you yourself? Or Vipin Kumar, as he is currently listed as maintainer for the SPEAr eval boards? Yes, I can become a custodian on denx. Well, in that case all spear patches would be pushed through my denx.git repository. Is that right ? Also, can I create a repository myself ? and last but not the least, the workflow for custodians given at denx.de is how custodians really work or is there a deviation? Comments? Thanks, Stefan Regards Vipin -- DENX Software Engineering GmbH, MD: Wolfgang Denk& Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-0 Fax: (+49)-8142-66989-80 Email: off...@denx.de . ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 00/25] SPEAr: Update platform support for SPEAr3xx/6xx
Hi Vipin, On Friday 09 March 2012 08:29:10 Vipin Kumar wrote: > > So who would be best suited to become SPEAr custodian? Amit, you > > yourself? Or Vipin Kumar, as he is currently listed as maintainer for > > the SPEAr eval boards? > > Yes, I can become a custodian on denx. Well, in that case all spear > patches would be pushed through my denx.git repository. > Is that right ? Correct. But only the SPEAr platform patches. Not the peripheral patches like designware ethernet, USB, NAND etc. Those will still go through the responsible subsystem custodian. So its mainly those patches related to files in SPEAr board files and under arch/arm. > Also, can I create a repository myself ? I think Wolfgang will create it initially for you. Wolfgang, please correct me if I'm wrong. > and last but not the least, the workflow for custodians given at denx.de > is how custodians really work or is there a deviation? Are you referring to this page? http://www.denx.de/wiki/U-Boot/CustodianGitTrees It should be quite up-to-date. Though I haven't read it for quite a while. I suggest that you give it a try and ask on the list once you have some questions. Thanks, Stefan -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-0 Fax: (+49)-8142-66989-80 Email: off...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
