Re: [U-Boot] Dual boot Images in Flash
From: u-boot-boun...@lists.denx.de [mailto:u-boot- Dear pshambhu, In message 1380547665536-164381.p...@n7.nabble.com you wrote: As per previous posting i got to know that, there will be only one reset entry point, can't i have the another entry point in it. You can talk to your chip vendor to provide you with some kind of logic to detect failed boot attempts and provide an alternative reset vecotr then. Guess your chances to gett that are extremely small, though. You can, of course, throw hardware at it, and for example provide duplicate storage . memory devices for booting from, so you only have to swap chip select resp. address lines to select the alternative boot device. - Why i can't have multiple entry points ? and what will be effect if i introduced ? You can't, because your processor only has one. - Where the reset entry points are defined in the u-boot code ? They are not defined in U-Boot, they are defined in the processor silicon or ROM code. Disclaimer: of course things get even more complicated when you keep in mind that there is a multiverse of different hardware solutions, some of them with special, and others with truely exotic features. you can tweak your hardware to split it, and many micro-controllers do it (especially for safety critical applications). Example: Suppose 'default' entry-point (or reset entry-point) = 0x_, Now OR your MSB bit with the fault-signal or boot-error-flag. reset-addr[31] = reset-addr_internal[31] | boot_error_flag; So in case when you primary boot fails, and boot_error_flags is set, next time when you boot, the address transforms into 0x1000_ This can also be done at board-level, where you can always re-route your default chip-select to some different memory by ORing it with boot_error_flag. But yes, you need a way to determine that your first boot failed, which is usually done by having a on-board watchdog, which timeout if system doesn't boot within given time. with regards, pekon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/3] i2c: improve s3c24x0 with High-speed and new SYS_I2C framework support
Hello Naveen,
Am 30.09.2013 12:03, schrieb Naveen Krishna Ch:
Helo Heiko,
Thanks for timely reply.
On 30 September 2013 13:35, Heiko Schocherh...@denx.de wrote:
Hello Naveen,
Am 30.09.2013 08:58, schrieb Naveen Krishna Chatradhi:
This patchset fixes few bugs in the existing s3c24x0.c code (standard i2c)
and add support for High-speed i2c bus controller available on Exynos5
SoCs
from Samsung.
Exynos5250 channels [0 ~ 3] can configured for I2C contoller or
new HSI2C controller
channels [3 ~ 7] are standard I2C controller channels
Exynos5420 channels [0 ~ 3] are standard I2C controller channels and
channels [4 ~ 10] are High-speed controller channels
Patchset:
1. exynos: i2c: Fix i2c driver to handle NACKs properly
Improvements and fixes from Vadim Bendebury for standard i2c calls
2. exynos: i2c: Change FDT bus setup code to enumerate ports correctly
FDT bus setup code from Simon Glass
3. PATCH v5: i2c: s3c24xx: add hsi2c controller support
High-speed controller register description and defines new i2c
read/write,
probe and set_bus calls.
This is been reviewed earlier at
http://lists.denx.de/pipermail/u-boot/2013-May/153245.html
Thanks for review and improvements from Vadim Bendebury.
Question:
4. RFC: samsung: i2c: Enable new CONFIG_SYS_I2C framework
I've tried to implement the new I2C multi bus framework in u-boot tree,
taking tegra-i2c.c as reference.
[...]
b). When i define 11 buses as in the case of Exynos5420, the i2c bus
lists them
SMDK5420 # i2c bus
Bus 0: s3c0
Bus 1: s3c1
Bus 2: s3c10
Bus 3: s3c2
Bus 4: s3c3
Bus 5: s3c4
Bus 6: s3c5
Bus 7: s3c6
Bus 8: s3c7
Bus 9: s3c8
Bus 10: s3c9
or (If i change the name to hsi2c)
SMDK5420 # i2c bus
Bus 0: hsi2c10
Bus 1: hsi2c4
Bus 2: hsi2c5
Bus 3: hsi2c6
Bus 4: hsi2c7
Bus 5: hsi2c8
Bus 6: hsi2c9
Bus 7: s3c0
Bus 8: s3c1
Bus 9: s3c2
Bus 10: s3c3
Whats the expected behaviour. If the above result is correct, I need to
changei
the strings to get them in the correct order.
What, if you use two digits:
Bus 0: hsi2c01
Bus 1: hsi2c02
[...]
Bus 7: s3c00
Bus 8: s3c01
[...]
?
Or with one digit:
Bus 0: hsi2c1
Bus 1: hsi2c2
[...]
Bus 7: s3c0
Bus 8: s3c1
[...]
In the Exynos5420 hardware
channels are as below
channel:
--0123--45-6---78---9---10
controller: i2c, i2c, i2c, i2c, hsi2c, hsi2c, hsi2c, hsi2c, hsi2c, hsi2c, hsi2c.
But the i2c bus command is showing the bus number according to the name
string comparison. Which seems wrong. Isn't it ??
Hmm.. you are right, seems that the compiler sorts them alphabetical ...
So, two ways:
- use another name, saying first a two digit for the channel ?
- or, use CONFIG_SYS_NUM_I2C_BUSES, CONFIG_SYS_I2C_DIRECT_BUS
and CONFIG_SYS_I2C_BUSES as described in the README (grep
for CONFIG_SYS_I2C_BUSES in include/configs and you will find
some examples ...) and you can define, which adapter is on which
i2c_bus number ...
c). What's the alternative for the
board_i2c_init(), i2c_get_bus_num_fdt(), i2c_reset_port_fdt().
Functions to get the I2C bus number and reset I2C bus using FDT node
I think, these functions are still needed.
Hmm.. that needs a general discussion, how to use fdt and i2c I think.
I would prefer a way (not really nowing, if it is possible for all
configurations) where, if using fdt, the DT gets parsed and the
availiable i2c buses gets created ... After that, normal i2c access
with i2c_set_bus_num(), i2c_read/write should be possible ... this is
currently not possible with the i2c framework, but should not be so hard
to do. Except the restriction, that it would not work in SPL case, or
before relocation for i2c buses announced through dt
once i2c_init_board() is done board_i2c_init() is not quite needed
using i2c_init_board we can avoid the relocation problem aswell.
by the definition of i2c_get_bus_num() in drivers/i2c/i2c_core.c
unsigned int i2c_get_bus_num(void)
{
return gd-cur_i2c_bus;
}
we don't need a special function i2c_get_bus_num_fdt()
Ah, ok!
IMHO, i2c_reset_port_fdt() is the only function to be discussed
And why is i2c_init() not good? Why must we have here a new function?
Define CONFIG_SYS_I2C_MAX_HOPS - CONFIG_SYS_I2C_DIRECT_BUS is not defined
so i2c_bus[] is used in drivers/i2c/i2c_core.c. Define the fix i2c buses in
the board config file with CONFIG_SYS_I2C_BUSES (if you have no fix buses,
let this empty) and add a function in drivers/i2c/i2c_core.c, which adds
new i2c buses to i2c_bus[] after the fix buses and call this new function,
from where you interpret the fdt ...
I din't quite understood this.
Can you point me to some readme or Doc or discussion Please.
just the U-Boot README ... The above was just a fast idea, how it
is possible to add i2c buses from the
Re: [U-Boot] [PATCH 0/3] i2c: improve s3c24x0 with High-speed and new SYS_I2C framework support
Hello Naveen,
Am 01.10.2013 08:19, schrieb Naveen Krishna Ch:
Hello Heiko,
On 1 October 2013 11:35, Heiko Schocherh...@denx.de wrote:
Hello Naveen,
Am 30.09.2013 12:03, schrieb Naveen Krishna Ch:
Helo Heiko,
Thanks for timely reply.
On 30 September 2013 13:35, Heiko Schocherh...@denx.de wrote:
Hello Naveen,
Am 30.09.2013 08:58, schrieb Naveen Krishna Chatradhi:
This patchset fixes few bugs in the existing s3c24x0.c code (standard
i2c)
and add support for High-speed i2c bus controller available on Exynos5
SoCs
from Samsung.
Exynos5250 channels [0 ~ 3] can configured for I2C contoller or
new HSI2C controller
channels [3 ~ 7] are standard I2C controller channels
Exynos5420 channels [0 ~ 3] are standard I2C controller channels and
channels [4 ~ 10] are High-speed controller channels
Patchset:
1. exynos: i2c: Fix i2c driver to handle NACKs properly
Improvements and fixes from Vadim Bendebury for standard i2c calls
2. exynos: i2c: Change FDT bus setup code to enumerate ports correctly
FDT bus setup code from Simon Glass
3. PATCH v5: i2c: s3c24xx: add hsi2c controller support
High-speed controller register description and defines new i2c
read/write,
probe and set_bus calls.
This is been reviewed earlier at
http://lists.denx.de/pipermail/u-boot/2013-May/153245.html
Thanks for review and improvements from Vadim Bendebury.
Question:
4. RFC: samsung: i2c: Enable new CONFIG_SYS_I2C framework
I've tried to implement the new I2C multi bus framework in u-boot tree,
taking tegra-i2c.c as reference.
[...]
channel:
--0123--45-6---78---9---10
controller: i2c, i2c, i2c, i2c, hsi2c, hsi2c, hsi2c, hsi2c, hsi2c, hsi2c,
hsi2c.
But the i2c bus command is showing the bus number according to the
name
string comparison. Which seems wrong. Isn't it ??
Hmm.. you are right, seems that the compiler sorts them alphabetical ...
So, two ways:
- use another name, saying first a two digit for the channel ?
- or, use CONFIG_SYS_NUM_I2C_BUSES, CONFIG_SYS_I2C_DIRECT_BUS
and CONFIG_SYS_I2C_BUSES as described in the README (grep
for CONFIG_SYS_I2C_BUSES in include/configs and you will find
some examples ...) and you can define, which adapter is on which
i2c_bus number ...
Will try and implement it this way.
Ok.
c). What's the alternative for the
board_i2c_init(), i2c_get_bus_num_fdt(), i2c_reset_port_fdt().
Functions to get the I2C bus number and reset I2C bus using FDT
node
I think, these functions are still needed.
Hmm.. that needs a general discussion, how to use fdt and i2c I think.
I would prefer a way (not really nowing, if it is possible for all
configurations) where, if using fdt, the DT gets parsed and the
availiable i2c buses gets created ... After that, normal i2c access
with i2c_set_bus_num(), i2c_read/write should be possible ... this is
currently not possible with the i2c framework, but should not be so hard
to do. Except the restriction, that it would not work in SPL case, or
before relocation for i2c buses announced through dt
once i2c_init_board() is done board_i2c_init() is not quite needed
using i2c_init_board we can avoid the relocation problem aswell.
by the definition of i2c_get_bus_num() in drivers/i2c/i2c_core.c
unsigned int i2c_get_bus_num(void)
{
return gd-cur_i2c_bus;
}
we don't need a special function i2c_get_bus_num_fdt()
Ah, ok!
IMHO, i2c_reset_port_fdt() is the only function to be discussed
And why is i2c_init() not good? Why must we have here a new function?
That's right, even if there is a need for i2c_reset_port_fdt().
it must be a i2c-core function instead of being in a driver.
Define CONFIG_SYS_I2C_MAX_HOPS - CONFIG_SYS_I2C_DIRECT_BUS is not
defined
so i2c_bus[] is used in drivers/i2c/i2c_core.c. Define the fix i2c buses
in
the board config file with CONFIG_SYS_I2C_BUSES (if you have no fix
buses,
let this empty) and add a function in drivers/i2c/i2c_core.c, which adds
new i2c buses to i2c_bus[] after the fix buses and call this new
function,
from where you interpret the fdt ...
I din't quite understood this.
Can you point me to some readme or Doc or discussion Please.
just the U-Boot README ... The above was just a fast idea, how it
is possible to add i2c buses from the info in the fdt ...
Here some theoretical code, how it could look like:
[...]
Thanks for this explanation.
! It is just theoretical ... you must try it ;-)
And maybe here and there some adaptions for getting this running...
Thinking of i2c_set_bus_num(), there must be now a check for
i2c_fix_bus I think ...
Adapt the README ...
And then, from the place where you interpret the fdt, call if
you have the information for one i2c bus, i2c_add_one_bus() ...
Not sure, if I overlooked here something ...
Will try and do this.
Mean while can we get the other 3 patches reviewed.
Patch 1:
[U-Boot] [i2c] Pull request
Hello Tom, please pull from u-boot-i2c.git The following changes since commit 6b40852da5c8dd710f9d61204a3c6a3c9d22: Sound: MAX98095: Support I2S0 channel (2013-09-24 09:10:33 -0400) are available in the git repository at: git://git.denx.de/u-boot-i2c.git master for you to fetch changes up to e436193269620579164d7db4296a3d7a378dbf8d: exynos: i2c: Fix i2c driver to handle NACKs properly (2013-10-01 08:33:16 +0200) Naveen Krishna Ch (1): exynos: i2c: Fix i2c driver to handle NACKs properly drivers/i2c/s3c24x0_i2c.c | 213 -- 1 file changed, 89 insertions(+), 124 deletions(-) bye, Heiko -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/3] i2c: improve s3c24x0 with High-speed and new SYS_I2C framework support
Hello Heiko,
On 1 October 2013 11:35, Heiko Schocher h...@denx.de wrote:
Hello Naveen,
Am 30.09.2013 12:03, schrieb Naveen Krishna Ch:
Helo Heiko,
Thanks for timely reply.
On 30 September 2013 13:35, Heiko Schocherh...@denx.de wrote:
Hello Naveen,
Am 30.09.2013 08:58, schrieb Naveen Krishna Chatradhi:
This patchset fixes few bugs in the existing s3c24x0.c code (standard
i2c)
and add support for High-speed i2c bus controller available on Exynos5
SoCs
from Samsung.
Exynos5250 channels [0 ~ 3] can configured for I2C contoller or
new HSI2C controller
channels [3 ~ 7] are standard I2C controller channels
Exynos5420 channels [0 ~ 3] are standard I2C controller channels and
channels [4 ~ 10] are High-speed controller channels
Patchset:
1. exynos: i2c: Fix i2c driver to handle NACKs properly
Improvements and fixes from Vadim Bendebury for standard i2c calls
2. exynos: i2c: Change FDT bus setup code to enumerate ports correctly
FDT bus setup code from Simon Glass
3. PATCH v5: i2c: s3c24xx: add hsi2c controller support
High-speed controller register description and defines new i2c
read/write,
probe and set_bus calls.
This is been reviewed earlier at
http://lists.denx.de/pipermail/u-boot/2013-May/153245.html
Thanks for review and improvements from Vadim Bendebury.
Question:
4. RFC: samsung: i2c: Enable new CONFIG_SYS_I2C framework
I've tried to implement the new I2C multi bus framework in u-boot tree,
taking tegra-i2c.c as reference.
[...]
b). When i define 11 buses as in the case of Exynos5420, the i2c bus
lists them
SMDK5420 # i2c bus
Bus 0: s3c0
Bus 1: s3c1
Bus 2: s3c10
Bus 3: s3c2
Bus 4: s3c3
Bus 5: s3c4
Bus 6: s3c5
Bus 7: s3c6
Bus 8: s3c7
Bus 9: s3c8
Bus 10: s3c9
or (If i change the name to hsi2c)
SMDK5420 # i2c bus
Bus 0: hsi2c10
Bus 1: hsi2c4
Bus 2: hsi2c5
Bus 3: hsi2c6
Bus 4: hsi2c7
Bus 5: hsi2c8
Bus 6: hsi2c9
Bus 7: s3c0
Bus 8: s3c1
Bus 9: s3c2
Bus 10: s3c3
Whats the expected behaviour. If the above result is correct, I need to
changei
the strings to get them in the correct order.
What, if you use two digits:
Bus 0: hsi2c01
Bus 1: hsi2c02
[...]
Bus 7: s3c00
Bus 8: s3c01
[...]
?
Or with one digit:
Bus 0: hsi2c1
Bus 1: hsi2c2
[...]
Bus 7: s3c0
Bus 8: s3c1
[...]
In the Exynos5420 hardware
channels are as below
channel:
--0123--45-6---78---9---10
controller: i2c, i2c, i2c, i2c, hsi2c, hsi2c, hsi2c, hsi2c, hsi2c, hsi2c,
hsi2c.
But the i2c bus command is showing the bus number according to the
name
string comparison. Which seems wrong. Isn't it ??
Hmm.. you are right, seems that the compiler sorts them alphabetical ...
So, two ways:
- use another name, saying first a two digit for the channel ?
- or, use CONFIG_SYS_NUM_I2C_BUSES, CONFIG_SYS_I2C_DIRECT_BUS
and CONFIG_SYS_I2C_BUSES as described in the README (grep
for CONFIG_SYS_I2C_BUSES in include/configs and you will find
some examples ...) and you can define, which adapter is on which
i2c_bus number ...
Will try and implement it this way.
c). What's the alternative for the
board_i2c_init(), i2c_get_bus_num_fdt(), i2c_reset_port_fdt().
Functions to get the I2C bus number and reset I2C bus using FDT
node
I think, these functions are still needed.
Hmm.. that needs a general discussion, how to use fdt and i2c I think.
I would prefer a way (not really nowing, if it is possible for all
configurations) where, if using fdt, the DT gets parsed and the
availiable i2c buses gets created ... After that, normal i2c access
with i2c_set_bus_num(), i2c_read/write should be possible ... this is
currently not possible with the i2c framework, but should not be so hard
to do. Except the restriction, that it would not work in SPL case, or
before relocation for i2c buses announced through dt
once i2c_init_board() is done board_i2c_init() is not quite needed
using i2c_init_board we can avoid the relocation problem aswell.
by the definition of i2c_get_bus_num() in drivers/i2c/i2c_core.c
unsigned int i2c_get_bus_num(void)
{
return gd-cur_i2c_bus;
}
we don't need a special function i2c_get_bus_num_fdt()
Ah, ok!
IMHO, i2c_reset_port_fdt() is the only function to be discussed
And why is i2c_init() not good? Why must we have here a new function?
That's right, even if there is a need for i2c_reset_port_fdt().
it must be a i2c-core function instead of being in a driver.
Define CONFIG_SYS_I2C_MAX_HOPS - CONFIG_SYS_I2C_DIRECT_BUS is not
defined
so i2c_bus[] is used in drivers/i2c/i2c_core.c. Define the fix i2c buses
in
the board config file with CONFIG_SYS_I2C_BUSES (if you have no fix
buses,
let this empty) and add
Re: [U-Boot] Dual boot Images in Flash
Dear Gupta, Pekon, In message 20980858cb6d3a4bae95ca194937d5e73ea18...@dbde04.ent.ti.com you wrote: you can tweak your hardware to split it, and many micro-controllers do it (especially for safety critical applications). Example: Suppose 'default' entry-point (or reset entry-point) = 0x_, Now OR your MSB bit with the fault-signal or boot-error-flag. Define fault-signal and boot-error-flag. Thise may exist on your chip, but they don't on the overwhelming majority of systems. reset-addr[31] = reset-addr_internal[31] | boot_error_flag; So in case when you primary boot fails, and boot_error_flags is set, next time when you boot, the address transforms into 0x1000_ This will only work on very specific hardware. 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 Nature there are neither rewards nor punishments, there are conse- quences.-- R.G. Ingersoll ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Dual boot Images in Flash
Hi, From: Wolfgang Denk [mailto:w...@denx.de] Dear Gupta, Pekon, In message 20980858cb6d3a4bae95ca194937d5e73ea18...@dbde04.ent.ti.com you can tweak your hardware to split it, and many micro-controllers do it (especially for safety critical applications). Example: Suppose 'default' entry-point (or reset entry-point) = 0x_, Now OR your MSB bit with the fault-signal or boot-error-flag. Define fault-signal and boot-error-flag. Thise may exist on your chip, but they don't on the overwhelming majority of systems. No, these do not exist on my chip either :-). But you can have such functionality on-board using basic components like watchdog timers. Like some of Automobile safety systems have a separate on-board watchdog timer (apart from on-chip ones). And it is periodically patted via GPIO pins, by the software running on the system. But suppose a boot failed then this watchdog timer would expire and that timeout signal can be latched as boot_error_flag. Case-1: This boot_error_flag can be used for re-routing chip-selects to other devices like (NAND), etc. Good part is such as this logic sits on board, it is independent of SoC. Bad part is it adds to your BOM cost. Case-2: You can re-route boot_error_flag back to your SoC connecting it to NMI or external reset (most SoC would atleast have reset). And then a corrective action can be taken in your reset-entry handler, or exception handler. Jumps to exception-handlers and reset-handler will mostly execute because these branching are hard-coded in processor hardware. Though I fully agree with you it's more difficult to do these things in actual than just describing the concept here. with regards, pekon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/6] powerpc: Add support 2 stage boot loader for corenet platform
Signed-off-by: Prabhakar Kushwaha prabha...@freescale.com --- Add support of 2 stage NAND boot loader in cornet platforms using SPL framework. This will be helpful for those SoC which has less internal SRAM(256K) like T1040. here, PBL initialise the internal SRAM and copy SPL(192K) in SRAM. SPL further initialise DDR using SPD and environment variables and copy u-boot(512 KB) from NAND flash to DDR. Finally SPL transer control to u-boot for futher booting. SPL has following features: - Executes within 256K - SPL size 192K - No relocation required Run time view of SPL framework == --- Area| Address | --- GD, BD | 0x0xFFFC (4K) | --- HEAP| 0xFFFC1000 (40K) grow downwards | --- STACK | 0xFFFD (20K) grow upwards | --- U-boot SPL | 0xfffD - 0xfffc (192K) | --- --- This patch set contains:- [PATCH 1/6] powerpc:Add support of SPL non-relocation [PATCH 2/6] powerpc/SPL:Allow Parsing of LAW table in both SPL non SPL [PATCH 3/6] common/env: Point default envirenoment for GD [PATCH 4/6] Makefile:Add u-boot-with-spl-pbl.bin target for SPL [PATCH 5/6] SPL:Defines function required to env read for IFC env_nand [PATCH 6/6] T1040QDS: Add support of 2 stage NAND boot loader -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] powerpc/t1040: enable PBL tool for T1040
Use a default RCW of protocol 0x66. A PBI configure file which uses CPC as 256KB SRAM. It can be used by PBL tool on T1040 to build a pbl boot image. Signed-off-by: Prabhakar Kushwaha prabha...@freescale.com --- Based upon git://git.denx.de/u-boot-mpc85xx.git branch next board/freescale/t1040qds/t1040_pbi.cfg | 27 +++ board/freescale/t1040qds/t1040_rcw.cfg |7 +++ include/configs/T1040QDS.h |2 ++ 3 files changed, 36 insertions(+) create mode 100644 board/freescale/t1040qds/t1040_pbi.cfg create mode 100644 board/freescale/t1040qds/t1040_rcw.cfg diff --git a/board/freescale/t1040qds/t1040_pbi.cfg b/board/freescale/t1040qds/t1040_pbi.cfg new file mode 100644 index 000..624398a --- /dev/null +++ b/board/freescale/t1040qds/t1040_pbi.cfg @@ -0,0 +1,27 @@ +#PBI commands +#Initialize CPC1 +0901 00200400 +09138000 +091380c0 0100 +#Configure CPC1 as 512KB SRAM +09010100 +09010104 fffc0007 +09010f00 0800 +0901 8000 +#Configure LAW for CPC1 +09000cf0 +09000cf4 fffc +09000cf8 8111 +#Configure alternate space +0910 +0914 ff00 +0918 8100 +#Configure SPI controller +0911 8403 +09110020 2d170008 +09110024 0018 +09110028 0018 +0911002c 0018 +#Flush PBL data +09138000 +091380c0 diff --git a/board/freescale/t1040qds/t1040_rcw.cfg b/board/freescale/t1040qds/t1040_rcw.cfg new file mode 100644 index 000..0d0dfa5 --- /dev/null +++ b/board/freescale/t1040qds/t1040_rcw.cfg @@ -0,0 +1,7 @@ +#PBL preamble and RCW header +aa55aa55 010e0100 +# serdes protocol 0x66 +0a1c 0c00 +6602 fc027000 0100 + 00030810 + 03fc500f diff --git a/include/configs/T1040QDS.h b/include/configs/T1040QDS.h index 2738242..7c6bec8 100644 --- a/include/configs/T1040QDS.h +++ b/include/configs/T1040QDS.h @@ -32,6 +32,8 @@ #ifdef CONFIG_RAMBOOT_PBL #define CONFIG_RAMBOOT_TEXT_BASE CONFIG_SYS_TEXT_BASE #define CONFIG_RESET_VECTOR_ADDRESS0xfffc +#define CONFIG_PBLPBI_CONFIG $(SRCTREE)/board/freescale/t1040qds/t1040_pbi.cfg +#define CONFIG_PBLRCW_CONFIG $(SRCTREE)/board/freescale/t1040qds/t1040_rcw.cfg #endif /* High Level Configuration Options */ -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/6] powerpc/SPL:Allow Parsing of LAW table in both SPL non SPL
SPL does not relocates the CCSRBAR hence it is using CCSRBAR at 0xfe00_.
U-boot relocates CCSRBAR to 0xf_fe00_.
So law talbe needs to be updated again.
Signed-off-by: Prabhakar Kushwaha prabha...@freescale.com
---
Based upon git://git.denx.de/u-boot-mpc85xx.git branch next
arch/powerpc/cpu/mpc8xxx/law.c |9 -
1 file changed, 9 deletions(-)
diff --git a/arch/powerpc/cpu/mpc8xxx/law.c b/arch/powerpc/cpu/mpc8xxx/law.c
index a401083..d76ba22 100644
--- a/arch/powerpc/cpu/mpc8xxx/law.c
+++ b/arch/powerpc/cpu/mpc8xxx/law.c
@@ -244,15 +244,6 @@ void init_laws(void)
gd-arch.used_laws |= (1 i);
}
-#if (defined(CONFIG_NAND_U_BOOT) !defined(CONFIG_NAND_SPL)) || \
- (defined(CONFIG_SPL) !defined(CONFIG_SPL_BUILD))
- /*
-* in SPL boot we've already parsed the law_table and setup those LAWs
-* so don't do it again.
-*/
- return;
-#endif
-
for (i = 0; i num_law_entries; i++) {
if (law_table[i].index == -1)
set_next_law(law_table[i].addr, law_table[i].size,
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/6] common/env: Point default envirenoment for GD
GD(Global Data) structure has pointer to envirenoment variable array.
but, it is not being assigned for SPL framwork.
So update GD pointer with env variable array.
Signed-off-by: Prabhakar Kushwaha prabha...@freescale.com
---
Based upon git://git.denx.de/u-boot-mpc85xx.git branch next
common/env_common.c |3 +++
1 file changed, 3 insertions(+)
diff --git a/common/env_common.c b/common/env_common.c
index 1ac3377..84843e1 100644
--- a/common/env_common.c
+++ b/common/env_common.c
@@ -162,6 +162,9 @@ int env_import(const char *buf, int check)
if (himport_r(env_htab, (char *)ep-data, ENV_SIZE, '\0', 0,
0, NULL)) {
gd-flags |= GD_FLG_ENV_READY;
+#ifdef CONFIG_SPL_BUILD
+ gd-env_addr = ep-data;
+#endif
return 1;
}
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/6] powerpc:Add support of SPL non-relocation
Current SPL code base has BSS section placed after reset_vector. This means
they have to relocate to use the global variables. This put an implicit
requirement of having SPL size = Memory/2.
To avoid relocation, move bss_section within SPL range.
Signed-off-by: Prabhakar Kushwaha prabha...@freescale.com
---
Based upon git://git.denx.de/u-boot-mpc85xx.git branch next
arch/powerpc/cpu/mpc85xx/u-boot-spl.lds | 25 -
1 file changed, 24 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/cpu/mpc85xx/u-boot-spl.lds
b/arch/powerpc/cpu/mpc85xx/u-boot-spl.lds
index bc13267..ffc6ad3 100644
--- a/arch/powerpc/cpu/mpc85xx/u-boot-spl.lds
+++ b/arch/powerpc/cpu/mpc85xx/u-boot-spl.lds
@@ -57,13 +57,34 @@ SECTIONS
. = ALIGN(8);
__init_begin = .;
__init_end = .;
+#ifdef CONFIG_SKIP_RELOCATE_SPL
+ /*
+* Make sure that the bss segment isn't linked at 0x0, otherwise its
+* address won't be updated during relocation fixups.
+*/
+ . |= 0x10;
+
+ . = ALIGN(4);
+ __bss_start = .;
+ .bss : {
+ *(.sbss*)
+ *(.bss*)
+ }
+ . = ALIGN(4);
+ __bss_end = .;
+#endif
/* FIXME for non-NAND SPL */
#if defined(CONFIG_FSL_IFC) /* Restrict bootpg at 4K boundry for IFC */
- .bootpg ADDR(.text) + 0x1000 :
+#ifndef BOOT_PAGE_OFFSET
+#define BOOT_PAGE_OFFSET 0x1000
+#endif
+ .bootpg ADDR(.text) + BOOT_PAGE_OFFSET :
{
arch/powerpc/cpu/mpc85xx/start.o (.bootpg)
}
+#ifndef RESET_VECTOR_OFFSET
#define RESET_VECTOR_OFFSET 0x1ffc /* IFC has 8K sram */
+#endif
#elif defined(CONFIG_FSL_ELBC)
#define RESET_VECTOR_OFFSET 0xffc /* LBC has 4k sram */
#else
@@ -80,6 +101,7 @@ SECTIONS
} = 0x
#endif
+#ifndef CONFIG_SKIP_RELOCATE_SPL
/*
* Make sure that the bss segment isn't linked at 0x0, otherwise its
* address won't be updated during relocation fixups.
@@ -94,4 +116,5 @@ SECTIONS
}
. = ALIGN(4);
__bss_end = .;
+#endif
}
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 5/6] SPL:Defines function required to env read for IFC env_nand
fsl_ifs_spl.c reads data from NAND and store at a memory location in raw mode.
It does not used MTD layer.
To read env variable from NAND MTD layer read/write required.
Hence, add mtd_block_isbad nand_read_skip_bad function required during
env variable read.
Also, avoid nand_info during env read for SPL
Signed-off-by: Prabhakar Kushwaha prabha...@freescale.com
---
Based upon git://git.denx.de/u-boot-mpc85xx.git branch next
common/env_nand.c |4
drivers/mtd/nand/fsl_ifc_spl.c | 22 ++
2 files changed, 26 insertions(+)
diff --git a/common/env_nand.c b/common/env_nand.c
index 7530962..8a33552 100644
--- a/common/env_nand.c
+++ b/common/env_nand.c
@@ -245,7 +245,11 @@ int readenv(size_t offset, u_char *buf)
size_t blocksize, len;
u_char *char_ptr;
+#ifdef CONFIG_SPL_BUILD
+ blocksize = CONFIG_ENV_SIZE;;
+#else
blocksize = nand_info[0].erasesize;
+#endif
if (!blocksize)
return 1;
diff --git a/drivers/mtd/nand/fsl_ifc_spl.c b/drivers/mtd/nand/fsl_ifc_spl.c
index d462265..0db7142 100644
--- a/drivers/mtd/nand/fsl_ifc_spl.c
+++ b/drivers/mtd/nand/fsl_ifc_spl.c
@@ -11,6 +11,28 @@
#include asm/io.h
#include asm/fsl_ifc.h
#include linux/mtd/nand.h
+#ifndef CONFIG_SPL_INIT_MINIMAL
+#include linux/mtd/mtd.h
+#endif
+
+static void nand_load(unsigned int offs, int uboot_size, uchar *dst);
+
+#ifdef CONFIG_ENV_IS_IN_NAND
+struct mtd_info nand_info[CONFIG_SYS_MAX_NAND_DEVICE];
+
+int mtd_block_isbad(struct mtd_info *mtd, loff_t ofs)
+{
+ return 0;
+}
+
+int nand_read_skip_bad(struct mtd_info *nand, loff_t offset, size_t *length,
+ size_t *actual, loff_t lim, u_char *buffer)
+{
+ nand_load(offset, *length, buffer);
+ return 0;
+}
+#endif
+
static inline int is_blank(uchar *addr, int page_size)
{
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 4/6] Makefile:Add u-boot-with-spl-pbl.bin target for SPL
This image combines the pbl format of SPL with and U-Boot. This is a
convenient way of having a single image to program on indirect boot source.
Corenet platforms like T4240, P4080 etc have PBL hardware which read data
in PBL format and copy to internal SRAM for further execution.
This image configures DDR, copy u-boot to DDR and transfer the control.
Signed-off-by: Prabhakar Kushwaha prabha...@freescale.com
---
Based upon git://git.denx.de/u-boot-mpc85xx.git branch next
Makefile |7 +++
spl/Makefile |9 +
2 files changed, 16 insertions(+)
diff --git a/Makefile b/Makefile
index 6f8f2f1..260bb65 100644
--- a/Makefile
+++ b/Makefile
@@ -496,6 +496,9 @@ endif
$(obj)u-boot-with-spl.bin: $(obj)spl/u-boot-spl.bin $(SPL_PAYLOAD)
$(call
SPL_PAD_APPEND,$,$(SPL_PAYLOAD),spl/u-boot-spl-pad.bin,$(CONFIG_SPL_PAD_TO))
+$(obj)u-boot-with-spl-pbl.bin: $(obj)spl/u-boot-spl.pbl $(SPL_PAYLOAD)
+ $(call
SPL_PAD_APPEND,$,$(SPL_PAYLOAD),spl/u-boot-spl-pad.bin,$(CONFIG_SPL_PAD_TO))
+
$(obj)tpl/u-boot-with-tpl.bin: $(obj)tpl/u-boot-tpl.bin $(obj)u-boot.bin
$(call
SPL_PAD_APPEND,$,$(obj)u-boot.bin,tpl/u-boot-tpl-pad.bin,$(CONFIG_TPL_PAD_TO))
@@ -623,6 +626,9 @@ $(obj)u-boot-nand.bin: nand_spl $(obj)u-boot.bin
$(obj)spl/u-boot-spl.bin: $(SUBDIR_TOOLS) depend
$(MAKE) -C spl all
+$(obj)spl/u-boot-spl.pbl: $(SUBDIR_TOOLS) depend
+ $(MAKE) -C spl all
+
$(obj)tpl/u-boot-tpl.bin: $(SUBDIR_TOOLS) depend
$(MAKE) -C spl all CONFIG_TPL_BUILD=y
@@ -917,6 +923,7 @@ clobber:tidy
@rm -f $(obj)nand_spl/{u-boot.{lds,lst},System.map}
@rm -f $(obj)nand_spl/{u-boot-nand_spl.lds,u-boot-spl,u-boot-spl.map}
@rm -f $(obj)spl/{u-boot-spl,u-boot-spl.bin,u-boot-spl.map}
+ @rm -f $(obj)spl/u-boot-spl.pbl
@rm -f $(obj)spl/u-boot-spl.lds
@rm -f $(obj)tpl/{u-boot-tpl,u-boot-tpl.bin,u-boot-tpl.map}
@rm -f $(obj)tpl/u-boot-spl.lds
diff --git a/spl/Makefile b/spl/Makefile
index 174d0a7..919f97e 100644
--- a/spl/Makefile
+++ b/spl/Makefile
@@ -180,6 +180,10 @@ ifdef CONFIG_SAMSUNG
ALL-y += $(obj)$(BOARD)-spl.bin
endif
+ifdef CONFIG_PBLPBI_CONFIG
+ALL-y += $(obj)$(SPL_BIN).pbl
+endif
+
all: $(ALL-y)
ifdef CONFIG_SAMSUNG
@@ -191,6 +195,11 @@ endif
$(obj)$(SPL_BIN).bin: $(obj)$(SPL_BIN)
$(OBJCOPY) $(OBJCFLAGS) -O binary $ $@
+$(obj)$(SPL_BIN).pbl: $(obj)$(SPL_BIN).bin
+ $(obj)../tools/mkimage -n $(CONFIG_PBLRCW_CONFIG) \
+ -R $(CONFIG_PBLPBI_CONFIG) -T pblimage \
+ -d $ $@
+
GEN_UBOOT = \
cd $(obj) $(LD) $(LDFLAGS) $(LDFLAGS_$(@F)) $(__START) \
--start-group $(__LIBS) --end-group $(PLATFORM_LIBS) \
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 6/6] T1040QDS: Add support of 2 stage NAND boot loader
Add support of 2 stage NAND boot loader using SPL framework.
here, PBL initialise the internal SRAM(256K) and copy SPL(192K). This further
initialise DDR using SPD and environment and copy u-boot(512 kb) from NAND to
DDR.
Finally SPL transer control to u-boot.
Initialise/create followings required for SPL framework
- Add spl.c which defines board_init_f, board_init_r
- update tlb and ddr accordingly
Signed-off-by: Prabhakar Kushwaha prabha...@freescale.com
---
Based upon git://git.denx.de/u-boot-mpc85xx.git branch next
board/freescale/t1040qds/Makefile |9 ++-
board/freescale/t1040qds/README | 33 ++
board/freescale/t1040qds/ddr.c|7 ++-
board/freescale/t1040qds/spl.c| 122 +
board/freescale/t1040qds/tlb.c|8 ++-
boards.cfg|1 +
include/configs/T1040QDS.h| 58 +++---
7 files changed, 227 insertions(+), 11 deletions(-)
create mode 100644 board/freescale/t1040qds/spl.c
diff --git a/board/freescale/t1040qds/Makefile
b/board/freescale/t1040qds/Makefile
index 8f0057b..8f3d7ef 100644
--- a/board/freescale/t1040qds/Makefile
+++ b/board/freescale/t1040qds/Makefile
@@ -8,9 +8,16 @@ include $(TOPDIR)/config.mk
LIB= $(obj)lib$(BOARD).o
+ifdef CONFIG_SPL_BUILD
+COBJS-y += spl.o
+endif
+
+ifndef CONFIG_SPL_BUILD
COBJS-y+= $(BOARD).o
+COBJS-$(CONFIG_PCI) += pci.o
+endif
+
COBJS-y+= ddr.o
-COBJS-$(CONFIG_PCI) += pci.o
COBJS-y+= law.o
COBJS-y+= tlb.o
diff --git a/board/freescale/t1040qds/README b/board/freescale/t1040qds/README
index f8b53b4..0e4d32e 100644
--- a/board/freescale/t1040qds/README
+++ b/board/freescale/t1040qds/README
@@ -167,3 +167,36 @@ T1042 Personality
T1042 is a reduced personality of T1040 without Integrated 8-port Gigabit
Ethernet switch. Rest of the blocks are same as T1040
+
+
+2 Stage boot loader
+---
+PBL initialise the internal SRAM and copy SPL(192K) in SRAM.
+SPL further initialise DDR using SPD and environment variables and copy
+u-boot(512 KB) from flash to DDR.
+Finally SPL transer control to u-boot for futher booting.
+
+SPL has following features:
+ - Executes within 256K
+ - Actual SPL size 96K + padding till 192K for extra code
+ - No relocation required
+
+ Run time view of SPL framework :-
+ ---
+ Area| Address |
+ ---
+ GD, BD | 0x0xFFFC (4K) |
+ ---
+ HEAP| 0xFFFC1000 (40K) grow downwards |
+ ---
+ STACK | 0xFFFD (20K) grow upwards |
+ ---
+ U-boot SPL | 0xfffD - 0xfffc (192K) |
+ ---
+
+Command to build 2 stage NAND boot loader
+ - modify RCW at board/freescale/t1040qds/t1040_rcw.cfg for nand boot
+ -6602 fc027000 0100
+ +6602 ec106000 0100
+ - make T1040QDS_NAND_config
+ - make u-boot-with-spl-pbl.bin
diff --git a/board/freescale/t1040qds/ddr.c b/board/freescale/t1040qds/ddr.c
index 4fd17da..dd2e0cb 100644
--- a/board/freescale/t1040qds/ddr.c
+++ b/board/freescale/t1040qds/ddr.c
@@ -107,11 +107,14 @@ phys_size_t initdram(int board_type)
puts(Initializingusing SPD\n);
+#ifdef CONFIG_SPL_BUILD
dram_size = fsl_ddr_sdram();
dram_size = setup_ddr_tlbs(dram_size / 0x10);
dram_size *= 0x10;
-
- puts(DDR: );
+#else
+ puts(DDR has been initialised by pre loader\n);
+ dram_size = 0x8000;
+#endif
return dram_size;
}
diff --git a/board/freescale/t1040qds/spl.c b/board/freescale/t1040qds/spl.c
new file mode 100644
index 000..5f39466
--- /dev/null
+++ b/board/freescale/t1040qds/spl.c
@@ -0,0 +1,122 @@
+/*
+ * Copyright 2013 Freescale Semiconductor, Inc.
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include common.h
+#include asm/processor.h
+#include asm/mmu.h
+#include ns16550.h
+#include asm/spl.h
+#include asm/fsl_law.h
+#include asm/fsl_ddr_sdram.h
+#include malloc.h
+#include nand.h
+#include i2c.h
+#include ../common/qixis.h
+#include t1040qds_qixis.h
+
+DECLARE_GLOBAL_DATA_PTR;
+
+ulong get_effective_memsize(void)
+{
+ return CONFIG_SYS_L3_SIZE;
+}
+
+unsigned long get_board_sys_clk(void)
+{
+ u8 sysclk_conf = QIXIS_READ(brdcfg[1]);
+
+ switch (sysclk_conf 0x0F) {
+ case QIXIS_SYSCLK_64:
+ return 6400;
+ case QIXIS_SYSCLK_83:
+ return 8333;
+ case QIXIS_SYSCLK_100:
+ return 1;
+ case QIXIS_SYSCLK_125:
+ return 12500;
+ case QIXIS_SYSCLK_133:
+ return 1;
+ case QIXIS_SYSCLK_150:
+ return 15000;
+ case
Re: [U-Boot] [PATCH] mx5: lowlevel_init: Remove unused macro
On 30/09/2013 23:28, Fabio Estevam wrote: From: Fabio Estevam fabio.este...@freescale.com setup_wdog macro is not used anywhere, so just remove it. Signed-off-by: Fabio Estevam fabio.este...@freescale.com --- arch/arm/cpu/armv7/mx5/lowlevel_init.S | 6 -- 1 file changed, 6 deletions(-) diff --git a/arch/arm/cpu/armv7/mx5/lowlevel_init.S b/arch/arm/cpu/armv7/mx5/lowlevel_init.S index e4cd85c..bffac67 100644 --- a/arch/arm/cpu/armv7/mx5/lowlevel_init.S +++ b/arch/arm/cpu/armv7/mx5/lowlevel_init.S @@ -375,12 +375,6 @@ setup_pll_func: #endif /* CONFIG_MX53 */ .endm -.macro setup_wdog - ldr r0, =WDOG1_BASE_ADDR - mov r1, #0x30 - strh r1, [r0] -.endm - ENTRY(lowlevel_init) mov r10, lr mov r4, #0 /* Fix R4 to 0 */ Acked-by: Stefano Babic sba...@denx.de Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] am33xx: add CONFIG_SYS_NAND_DEVICE_WIDTH to determine NAND device bus-width
On 25/09/13 06:23, Pekon Gupta wrote: NAND driver needs to know bus-width of the connected NAND device, in order to perform proper I/O and initialize itself. Currently there is no CONFIG option to provide this information to NAND driver. - SPL NAND driver does not have framework to parse ONFI parameter page. - NAND drivers which cannot self initialize !defined(CONFIG_SYS_NAND_SELF_INIT) do not have any information about device bus-width during board_nand_init(), So, any device-width specific configurations are not possible there. - There should be some mechanism to pass device bus-width information for non-ONFI compliant devices. This patch (1) adds CONFIG_SYS_NAND_DEVICE_WIDTH which can take following value 16: NAND device with x16 bus-width 8: NAND device with x8 bus-width (2) removes GPMC_NAND_ECC_LP_x16_LAYOUT, as NAND layout is determined based on ecc-scheme and oobsize during initialization in board_nand_init(). Thus this config is redundant. Signed-off-by: Pekon Gupta pe...@ti.com snip diff --git a/include/configs/am335x_evm.h b/include/configs/am335x_evm.h index 978bca7..c92cb2f 100644 --- a/include/configs/am335x_evm.h +++ b/include/configs/am335x_evm.h @@ -216,6 +216,7 @@ #ifdef CONFIG_NAND #define CONFIG_SYS_NAND_5_ADDR_CYCLE +#define CONFIG_SYS_NAND_DEVICE_WIDTH 8 This new setting ... #define CONFIG_SYS_NAND_BLOCK_SIZE 131072 #define CONFIG_SYS_NAND_PAGE_SIZE2048 #define CONFIG_SYS_NAND_OOBSIZE 64 @@ -366,7 +367,6 @@ /* NAND support */ #ifdef CONFIG_NAND #define CONFIG_CMD_NAND -#define GPMC_NAND_ECC_LP_x16_LAYOUT 1 ... does *not* match with what you're taking out here !! #if !defined(CONFIG_SPI_BOOT) !defined(CONFIG_NOR_BOOT) #define MTDIDS_DEFAULT nand0=omap2-nand.0 #define MTDPARTS_DEFAULT mtdparts=omap2-nand.0:128k(SPL), \ diff --git a/include/configs/am3517_crane.h b/include/configs/am3517_crane.h index 1fd2508..0985221 100644 --- a/include/configs/am3517_crane.h +++ b/include/configs/am3517_crane.h @@ -269,7 +269,6 @@ #define CONFIG_SYS_MONITOR_BASE CONFIG_SYS_FLASH_BASE #define CONFIG_NAND_OMAP_GPMC -#define GPMC_NAND_ECC_LP_x16_LAYOUT 1 Same here ... #define CONFIG_ENV_IS_IN_NAND1 #define SMNAND_ENV_OFFSET0x26 /* environment starts here */ @@ -332,6 +331,7 @@ /* NAND boot config */ #define CONFIG_SYS_NAND_5_ADDR_CYCLE +#define CONFIG_SYS_NAND_DEVICE_WIDTH 8 ... !! #define CONFIG_SYS_NAND_PAGE_COUNT 64 #define CONFIG_SYS_NAND_PAGE_SIZE2048 #define CONFIG_SYS_NAND_OOBSIZE 64 diff --git a/include/configs/am3517_evm.h b/include/configs/am3517_evm.h index 6500878..8593d44 100644 --- a/include/configs/am3517_evm.h +++ b/include/configs/am3517_evm.h @@ -263,7 +263,6 @@ #define CONFIG_SYS_MONITOR_BASE CONFIG_SYS_FLASH_BASE #define CONFIG_NAND_OMAP_GPMC -#define GPMC_NAND_ECC_LP_x16_LAYOUT 1 Again ... #define CONFIG_ENV_IS_IN_NAND1 #define SMNAND_ENV_OFFSET0x26 /* environment starts here */ @@ -326,6 +325,7 @@ /* NAND boot config */ #define CONFIG_SYS_NAND_5_ADDR_CYCLE +#define CONFIG_SYS_NAND_DEVICE_WIDTH 8 ... !! #define CONFIG_SYS_NAND_PAGE_COUNT 64 #define CONFIG_SYS_NAND_PAGE_SIZE2048 #define CONFIG_SYS_NAND_OOBSIZE 64 diff --git a/include/configs/cm_t35.h b/include/configs/cm_t35.h index bc5b66c..1e3dd0d 100644 --- a/include/configs/cm_t35.h +++ b/include/configs/cm_t35.h @@ -164,8 +164,6 @@ #define CONFIG_SYS_NAND_BASE NAND_BASE /* physical address */ /* to access nand at */ /* CS0 */ -#define GPMC_NAND_ECC_LP_x8_LAYOUT - And here you don't specify the new setting at all. #define CONFIG_SYS_MAX_NAND_DEVICE 1 /* Max number of NAND */ /* devices */ /* Environment information */ snip There's several other instances of the same issue through the whole patch. Mark J. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mx6: Add IOMUX_CONFIG_SION flag to all GPIO pins
Hi Otavio, On 30/09/2013 00:15, Otavio Salvador wrote: The IOMUX_CONFIG_SION allows for reading PAD value from PSR register. The following quote from the datasheet: , | ... | 28.4.2.2 GPIO Write Mode | The programming sequence for driving output signals should be as follows: | 1. Configure IOMUX to select GPIO mode (Via IOMUXC), also enable SION if need | to read loopback pad value through PSR | 2. Configure GPIO direction register to output (GPIO_GDIR[GDIR] set to 1b). | 3. Write value to data register (GPIO_DR). | ... ` This fixes the gpio_get_value to properly work when a GPIO is set for output and has no conflicts. Thanks for Benoît Thébaudeau benoit.thebaud...@advansee.com, Fabio Estevam fabio.este...@freescale.com and Eric Bénard e...@eukrea.com for helping to properly trace this down. Signed-off-by: Otavio Salvador ota...@ossystems.com.br --- I come later in the discussion, but I see you all have found the solution ;-). I suggest you add in the commit message that this patch is only for i.MX6 (if you do not plan to extend it to the other i.MXes...), so that we can track that the same must be done also for the other SOCs. Thanks, Stefano -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Dual boot Images in Flash
Thanks Wolfgang Denk and Pekon for the lots of info. Thanks Regards Pradeep S -- View this message in context: http://u-boot.10912.n7.nabble.com/Dual-boot-Images-in-Flash-tp164381p164434.html Sent from the U-Boot mailing list archive at Nabble.com. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] am33xx: add CONFIG_SYS_NAND_DEVICE_WIDTH to determine NAND device bus-width
Hi Mark, From: Mark Jackson [mailto:mpfj-l...@newflow.co.uk] To: Gupta, Pekon; scottw...@freescale.com; Rini, Tom snip diff --git a/include/configs/am335x_evm.h b/include/configs/am335x_evm.h index 978bca7..c92cb2f 100644 --- a/include/configs/am335x_evm.h +++ b/include/configs/am335x_evm.h @@ -216,6 +216,7 @@ #ifdef CONFIG_NAND #define CONFIG_SYS_NAND_5_ADDR_CYCLE +#define CONFIG_SYS_NAND_DEVICE_WIDTH 8 This new setting ... #define CONFIG_SYS_NAND_BLOCK_SIZE 131072 #define CONFIG_SYS_NAND_PAGE_SIZE 2048 #define CONFIG_SYS_NAND_OOBSIZE64 @@ -366,7 +367,6 @@ /* NAND support */ #ifdef CONFIG_NAND #define CONFIG_CMD_NAND -#define GPMC_NAND_ECC_LP_x16_LAYOUT1 ... does *not* match with what you're taking out here !! This CONFIG was used to define the layout based on (1) large-page of small-page NAND, and (2) BADBLOCK_MARKER position based on x16 or x8 device. Now this define is no more used, as ecc.layout is configured based on ecc-scheme. Please refer following patch. http://lists.denx.de/pipermail/u-boot/2013-September/163867.html Yes, I can put these into independent patch sets. However, if you can please test these patches on your system, This would at-least confirm whether these changes work, then I can re-send this series, with other comments. *Patch Series to test* http://lists.denx.de/pipermail/u-boot/2013-September/163865.html http://lists.denx.de/pipermail/u-boot/2013-September/163878.html with regards, pekon #if !defined(CONFIG_SPI_BOOT) !defined(CONFIG_NOR_BOOT) #define MTDIDS_DEFAULT nand0=omap2-nand.0 #define MTDPARTS_DEFAULT mtdparts=omap2- nand.0:128k(SPL), \ diff --git a/include/configs/am3517_crane.h b/include/configs/am3517_crane.h index 1fd2508..0985221 100644 --- a/include/configs/am3517_crane.h +++ b/include/configs/am3517_crane.h @@ -269,7 +269,6 @@ #define CONFIG_SYS_MONITOR_BASE CONFIG_SYS_FLASH_BASE #define CONFIG_NAND_OMAP_GPMC -#define GPMC_NAND_ECC_LP_x16_LAYOUT1 Same here ... #define CONFIG_ENV_IS_IN_NAND 1 #define SMNAND_ENV_OFFSET 0x26 /* environment starts here */ @@ -332,6 +331,7 @@ /* NAND boot config */ #define CONFIG_SYS_NAND_5_ADDR_CYCLE +#define CONFIG_SYS_NAND_DEVICE_WIDTH 8 ... !! #define CONFIG_SYS_NAND_PAGE_COUNT 64 #define CONFIG_SYS_NAND_PAGE_SIZE 2048 #define CONFIG_SYS_NAND_OOBSIZE64 diff --git a/include/configs/am3517_evm.h b/include/configs/am3517_evm.h index 6500878..8593d44 100644 --- a/include/configs/am3517_evm.h +++ b/include/configs/am3517_evm.h @@ -263,7 +263,6 @@ #define CONFIG_SYS_MONITOR_BASE CONFIG_SYS_FLASH_BASE #define CONFIG_NAND_OMAP_GPMC -#define GPMC_NAND_ECC_LP_x16_LAYOUT1 Again ... #define CONFIG_ENV_IS_IN_NAND 1 #define SMNAND_ENV_OFFSET 0x26 /* environment starts here */ @@ -326,6 +325,7 @@ /* NAND boot config */ #define CONFIG_SYS_NAND_5_ADDR_CYCLE +#define CONFIG_SYS_NAND_DEVICE_WIDTH 8 ... !! #define CONFIG_SYS_NAND_PAGE_COUNT 64 #define CONFIG_SYS_NAND_PAGE_SIZE 2048 #define CONFIG_SYS_NAND_OOBSIZE64 diff --git a/include/configs/cm_t35.h b/include/configs/cm_t35.h index bc5b66c..1e3dd0d 100644 --- a/include/configs/cm_t35.h +++ b/include/configs/cm_t35.h @@ -164,8 +164,6 @@ #define CONFIG_SYS_NAND_BASE NAND_BASE /* physical address */ /* to access nand at */ /* CS0 */ -#define GPMC_NAND_ECC_LP_x8_LAYOUT - And here you don't specify the new setting at all. #define CONFIG_SYS_MAX_NAND_DEVICE 1 /* Max number of NAND */ /* devices */ /* Environment information */ snip There's several other instances of the same issue through the whole patch. Mark J. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 3/4] generic board patch of manual reloc and zero gd_t
-原始邮件- 发件人: Scott Wood scottw...@freescale.com 发送时间: 2013年10月1日 星期二 收件人: Simon Glass s...@chromium.org 抄送: trini tr...@ti.com, u-boot u-boot@lists.denx.de, FengHua feng...@phytium.com.cn 主题: Re: [U-Boot] [PATCH v4 3/4] generic board patch of manual reloc and zero gd_t On Mon, 2013-09-09 at 20:54 -0500, Scott Wood wrote: It seems the problem is that when rela is used, the linker *only* puts the symbol in the rela struct. The value in the data section itself is zero, which means we can't run without relocation even if the address hasn't changed. Unless there's some way to change this linker behavior, the options I can think of are: 1. Write a utility to apply the relocations (for the pre-relocation address) at build time, or 2. Use SPL. The SPL itself would not use -pie and would not relocate. The main U-Boot would know that it has been loaded into RAM, and apply relocations prior to entering C code. Interactions with SPL being used for other purposes could be awkward. Any preferences, or other suggestions? I think either of these options is preferable to CONFIG_NEEDS_MANUAL_RELOC. I'm inclined toward option #1 as it avoids interactions with other SPL uses and in general doesn't change the runtime flow. #1 is easier to do on the u-boot.bin rather than on the ELF file[1], but apparently that doesn't do us any good with the model because it wants an ELF file. Shouldn't the model be applying the relocations if it's an ELF loader? Is there any way to get the foundation model to load a raw binary? I tried --data and --nsdata at 0x8000 (alone or in combination with --image) and wasn't able to do a write to the LEDs immediately after reset (which works when I load it as ELF). It works when I convert the binary back into an ELF using objcopy and ld, but it would be nice to avoid that... How about place u-boot.bin at 0x9000 and write a piece of code (elf format) jumping from 0x8000 to 0x9000. David, ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 7/9] net: tsec: Use portable types and accessors for BDs
On 10/1/2013 2:22 AM, Scott Wood wrote:
On Mon, 2013-09-30 at 12:44 +0300, Claudiu Manoil wrote:
+static RTXBD rtx __aligned(8);
+#define RXBD(i) rtx.rxbd[i]
+#define TXBD(i) rtx.txbd[i]
+#define GET_BD_STAT(T, i) be16_to_cpu((__force __be16)T##BD(i).status)
+#define SET_BD_STAT(T, i, v) T##BD(i).status = (__force __u16)cpu_to_be16(v)
+#define GET_BD_BLEN(T, i) be16_to_cpu((__force __be16)T##BD(i).length)
+#define SET_BD_BLEN(T, i, v) T##BD(i).length = (__force __u16)cpu_to_be16(v)
+#define GET_BD_BPTR(T, i) be32_to_cpu((__force __be32)T##BD(i).bufptr)
+#define SET_BD_BPTR(T, i, v) T##BD(i).bufptr = (__force __u32)cpu_to_be32(v)
Why the forcing? Can't you declare the data with __be16/__be32?
The __force annotation is obviously needed to suppress the sparse
warnings due to BD data declaration type not being __bexx, but the
generic uintxx_t, as you noticed as well.
Now, why I didn't use __bexx instead? The main reason would be
maintainability: the DMA descriptors may not be in big endian format
exclusively. The eTSEC hw may actually have an option to interpret
the DMA descriptors in little endian format. If we decide to use
that option for future platforms, then the __bexx type wouldn't be
correct anymore.
Besides, I noticed that most drivers prefer to use the generic type
uintxx_t for buffer descriptors, instead of the annotated __bexx/__lexx
types.
#else
#error rtx must be 64-bit aligned
#endif
@@ -275,10 +283,11 @@ void redundant_init(struct eth_device *dev)
clrbits_be32(regs-dmactrl, DMACTRL_GRS | DMACTRL_GTS);
do {
+ uint16_t status;
tsec_send(dev, (void *)pkt, sizeof(pkt));
/* Wait for buffer to be received */
- for (t = 0; rtx.rxbd[rx_idx].status RXBD_EMPTY; t++) {
+ for (t = 0; GET_BD_STAT(RX, rx_idx) RXBD_EMPTY; t++) {
What's wrong with:
for (t = 0; in_be16(rtx.rxbd[rx_idx].status) RXBD_EMPTY; t++) {
Or if you don't want to use I/O accessors on the DMA descriptors (Is
synchronization ensured some other way? We had problems with this in
the Linux driver before...):
Synchronization here is is insured by declaring the RTXBD structure
type as volatile (see RTXBD declaration, a couple of lines above).
The existing code has been working this way for quite a while on the
mpc85xx platforms, so I thought it would be better not to change this
approach. Using i/o accessors for the Buffer Descriptors would be a
significant change, and I don't see how to argue such a change: why
would the I/O accessors be better than the current approach - i.e.
declaring the DMA descriptors as volatile? Is there something wrong
with about volatile usage in this case? (afaik, this is a case were
the volatile declaration is permitted)
Also, there doesn't seem to be other net drivers using I/O accessors
for the BD rings.
for (t = 0; be16_to_cpup(rtx.rxbd[rx_idx].status) RXBD_EMPTY; t++) {
I opted for using macros instead due to code maintainability, and to
avoid overly long lines (80) and to better control these changes.
For instance, if etsec were to access it's BDs in little endian format
in the future, then it would be enough to update the implementation
of the macro accessors without touching the whole code.
-Scott
Thanks for reviewing this.
Regards,
Claudiu
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mx6: Add IOMUX_CONFIG_SION flag to all GPIO pins
On Tue, Oct 1, 2013 at 5:33 AM, Stefano Babic sba...@denx.de wrote: Hi Otavio, On 30/09/2013 00:15, Otavio Salvador wrote: The IOMUX_CONFIG_SION allows for reading PAD value from PSR register. The following quote from the datasheet: , | ... | 28.4.2.2 GPIO Write Mode | The programming sequence for driving output signals should be as follows: | 1. Configure IOMUX to select GPIO mode (Via IOMUXC), also enable SION if need | to read loopback pad value through PSR | 2. Configure GPIO direction register to output (GPIO_GDIR[GDIR] set to 1b). | 3. Write value to data register (GPIO_DR). | ... ` This fixes the gpio_get_value to properly work when a GPIO is set for output and has no conflicts. Thanks for Benoît Thébaudeau benoit.thebaud...@advansee.com, Fabio Estevam fabio.este...@freescale.com and Eric Bénard e...@eukrea.com for helping to properly trace this down. Signed-off-by: Otavio Salvador ota...@ossystems.com.br --- I come later in the discussion, but I see you all have found the solution ;-). I suggest you add in the commit message that this patch is only for i.MX6 (if you do not plan to extend it to the other i.MXes...), so that we can track that the same must be done also for the other SOCs. I think this is clear from the commit prefix. I am under heavy load now and I cannot check their datasheet to verify if they all need this or not. If someone does not does it, I can take a look for sure. -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] mmc: sdhci: Avoid commands errors by simple timeout adaptation.
Old command timeout value was too small and it caused I/O errors which
led to uncompleted read/write/erase operations and filesystem errors.
Timeout adaptation fixes this issue.
Changes in sdhci_send_command() function:
- change timeout variable to static
- increase default command timeout to 100 ms
- add definition of max command timeout value,
which can be redefined in each board config file
- wait for card ready state for max defined time
if it doesn't exceed defined maximum or return COMM_ERR
Once successfully increased timeout value will be used in next function
call. This fix was tested on Goni, Trats, Trats2 boards by testing UMS
on MMC storage.
Signed-off-by: Przemyslaw Marczak p.marc...@samsung.com
---
drivers/mmc/sdhci.c | 34 +++---
1 file changed, 27 insertions(+), 7 deletions(-)
diff --git a/drivers/mmc/sdhci.c b/drivers/mmc/sdhci.c
index 4261991..af11fc5 100644
--- a/drivers/mmc/sdhci.c
+++ b/drivers/mmc/sdhci.c
@@ -110,6 +110,22 @@ static int sdhci_transfer_data(struct sdhci_host *host,
struct mmc_data *data,
return 0;
}
+/*
+ * No command will be sent by driver if card is busy, so driver must wait
+ * for card ready state.
+ * Every time when card is busy after timeout then (last) timeout value will be
+ * increased twice but only if it doesn't exceed global defined maximum.
+ * Each function call will use last timeout value. Max timeout can be redefined
+ * in board config file.
+ */
+#ifndef CONFIG_SDHCI_CMD_MAX_TIMEOUT
+#define CONFIG_SDHCI_CMD_MAX_TIMEOUT 3200
+#endif
+#define CONFIG_SDHCI_CMD_DEFAULT_TIMEOUT 100
+
+/* Timeout unit - ms */
+static unsigned int cmd_timeout = CONFIG_SDHCI_CMD_DEFAULT_TIMEOUT;
+
int sdhci_send_command(struct mmc *mmc, struct mmc_cmd *cmd,
struct mmc_data *data)
{
@@ -118,12 +134,9 @@ int sdhci_send_command(struct mmc *mmc, struct mmc_cmd
*cmd,
int ret = 0;
int trans_bytes = 0, is_aligned = 1;
u32 mask, flags, mode;
- unsigned int timeout, start_addr = 0;
+ unsigned int time = 0, start_addr = 0;
unsigned int retry = 1;
- /* Wait max 10 ms */
- timeout = 10;
-
sdhci_writel(host, SDHCI_INT_ALL_MASK, SDHCI_INT_STATUS);
mask = SDHCI_CMD_INHIBIT | SDHCI_DATA_INHIBIT;
@@ -133,11 +146,18 @@ int sdhci_send_command(struct mmc *mmc, struct mmc_cmd
*cmd,
mask = ~SDHCI_DATA_INHIBIT;
while (sdhci_readl(host, SDHCI_PRESENT_STATE) mask) {
- if (timeout == 0) {
+ if (time == cmd_timeout) {
printf(Controller never released inhibit bit(s).\n);
- return COMM_ERR;
+ if (2 * cmd_timeout = CONFIG_SDHCI_CMD_MAX_TIMEOUT) {
+ cmd_timeout += cmd_timeout;
+ debug(Increasing command timeout to: %u ms.\n,
+ cmd_timeout);
+ } else {
+ error(Command timeout is set to max.\n);
+ return COMM_ERR;
+ }
}
- timeout--;
+ time++;
udelay(1000);
}
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mx6: Add IOMUX_CONFIG_SION flag to all GPIO pins
Dear Otavio Salvador, On Tue, Oct 1, 2013 at 5:33 AM, Stefano Babic sba...@denx.de wrote: Hi Otavio, On 30/09/2013 00:15, Otavio Salvador wrote: The IOMUX_CONFIG_SION allows for reading PAD value from PSR register. The following quote from the datasheet: , | ... | 28.4.2.2 GPIO Write Mode | The programming sequence for driving output signals should be as | follows: 1. Configure IOMUX to select GPIO mode (Via IOMUXC), also | enable SION if need to read loopback pad value through PSR | 2. Configure GPIO direction register to output (GPIO_GDIR[GDIR] set to | 1b). 3. Write value to data register (GPIO_DR). | ... ` This fixes the gpio_get_value to properly work when a GPIO is set for output and has no conflicts. Thanks for Benoît Thébaudeau benoit.thebaud...@advansee.com, Fabio Estevam fabio.este...@freescale.com and Eric Bénard e...@eukrea.com for helping to properly trace this down. Signed-off-by: Otavio Salvador ota...@ossystems.com.br --- I come later in the discussion, but I see you all have found the solution ;-). I suggest you add in the commit message that this patch is only for i.MX6 (if you do not plan to extend it to the other i.MXes...), so that we can track that the same must be done also for the other SOCs. I think this is clear from the commit prefix. The commit message should be ARM: mx6: or such btw. It'd be nice to fix it up for MX5 as well so we're consistent. I am under heavy load now and I cannot check their datasheet to verify if they all need this or not. If someone does not does it, I can take a look for sure. 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] mx6: Add IOMUX_CONFIG_SION flag to all GPIO pins
On Tue, Oct 1, 2013 at 9:43 AM, Marek Vasut ma...@denx.de wrote: Dear Otavio Salvador, On Tue, Oct 1, 2013 at 5:33 AM, Stefano Babic sba...@denx.de wrote: Hi Otavio, On 30/09/2013 00:15, Otavio Salvador wrote: The IOMUX_CONFIG_SION allows for reading PAD value from PSR register. The following quote from the datasheet: , | ... | 28.4.2.2 GPIO Write Mode | The programming sequence for driving output signals should be as | follows: 1. Configure IOMUX to select GPIO mode (Via IOMUXC), also | enable SION if need to read loopback pad value through PSR | 2. Configure GPIO direction register to output (GPIO_GDIR[GDIR] set to | 1b). 3. Write value to data register (GPIO_DR). | ... ` This fixes the gpio_get_value to properly work when a GPIO is set for output and has no conflicts. Thanks for Benoît Thébaudeau benoit.thebaud...@advansee.com, Fabio Estevam fabio.este...@freescale.com and Eric Bénard e...@eukrea.com for helping to properly trace this down. Signed-off-by: Otavio Salvador ota...@ossystems.com.br --- I come later in the discussion, but I see you all have found the solution ;-). I suggest you add in the commit message that this patch is only for i.MX6 (if you do not plan to extend it to the other i.MXes...), so that we can track that the same must be done also for the other SOCs. I think this is clear from the commit prefix. The commit message should be ARM: mx6: or such btw. It'd be nice to fix it up for MX5 as well so we're consistent. Benoit expressed some doubt if it can be assumed to behave the same for all i.MX that's why I didn't apply it for all. I cannot look at this, at this moment, so I prefer to not change it without checking the datasheet for it. -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mx6: Add IOMUX_CONFIG_SION flag to all GPIO pins
Hi Otavio, On 01/10/2013 14:01, Otavio Salvador wrote: I suggest you add in the commit message that this patch is only for i.MX6 (if you do not plan to extend it to the other i.MXes...), so that we can track that the same must be done also for the other SOCs. I think this is clear from the commit prefix. Sorry, you're right, it is fine. I am under heavy load now and I cannot check their datasheet to verify if they all need this or not. If someone does not does it, I can take a look for sure. I look at MX51 / MX53 manuals. They are different as i.MX6, and in both cases I do not read the requirement to set the SION bit, as the i.MX6 needs. The fix is then only for i.MX6, and we do not need to extend it, at least according to documentation. After this check, I think that your patch is complete and I will push it for the release. Acked-by: Szefano Babic sba...@denx.de Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Dual boot Images in Flash
Hi Wolfgang, With respect to previous mail, i have one small doubt. I have two three u-boots, u-boot_stub _ _|_ _ _ _ _ _ _ | | u-boot1 u-boot2 Can i have a small uboot_stub in the reset entry table, which will boot initially, and while booting it should select the default booting location (u-boot1).But if the default booting location fails to boot up then u-boot_stub should select bootloader u-boot2. u-boot_stub will do CRC checksum on the u-boot1, if CRC checksum fails on that, then u-boot2 will be considered for bootup. Since its the software, i think it can be done and If it is possible, can you please tell me which are the files need to be taken care for the file changes. please guide me if i am wrong Thanks Regards Pradeep S -- View this message in context: http://u-boot.10912.n7.nabble.com/Dual-boot-Images-in-Flash-tp164381p164443.html Sent from the U-Boot mailing list archive at Nabble.com. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mx6: Add IOMUX_CONFIG_SION flag to all GPIO pins
On 10/01/2013 06:08 AM, Otavio Salvador wrote: On Tue, Oct 1, 2013 at 9:43 AM, Marek Vasut ma...@denx.de wrote: Dear Otavio Salvador, On Tue, Oct 1, 2013 at 5:33 AM, Stefano Babic sba...@denx.de wrote: Hi Otavio, On 30/09/2013 00:15, Otavio Salvador wrote: The IOMUX_CONFIG_SION allows for reading PAD value from PSR register. The following quote from the datasheet: , | ... | 28.4.2.2 GPIO Write Mode | The programming sequence for driving output signals should be as | follows: 1. Configure IOMUX to select GPIO mode (Via IOMUXC), also | enable SION if need to read loopback pad value through PSR | 2. Configure GPIO direction register to output (GPIO_GDIR[GDIR] set to | 1b). 3. Write value to data register (GPIO_DR). | ... ` This fixes the gpio_get_value to properly work when a GPIO is set for output and has no conflicts. Thanks for Benoît Thébaudeau benoit.thebaud...@advansee.com, Fabio Estevam fabio.este...@freescale.com and Eric Bénard e...@eukrea.com for helping to properly trace this down. Signed-off-by: Otavio Salvador ota...@ossystems.com.br --- I come later in the discussion, but I see you all have found the solution ;-). I suggest you add in the commit message that this patch is only for i.MX6 (if you do not plan to extend it to the other i.MXes...), so that we can track that the same must be done also for the other SOCs. I think this is clear from the commit prefix. The commit message should be ARM: mx6: or such btw. It'd be nice to fix it up for MX5 as well so we're consistent. Benoit expressed some doubt if it can be assumed to behave the same for all i.MX that's why I didn't apply it for all. I cannot look at this, at this moment, so I prefer to not change it without checking the datasheet for it. The same behaviour is present on i.MX51 and i.MX53. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mx6: Add IOMUX_CONFIG_SION flag to all GPIO pins
Hi Stefano, On 10/01/2013 06:13 AM, Stefano Babic wrote: Hi Otavio, On 01/10/2013 14:01, Otavio Salvador wrote: I suggest you add in the commit message that this patch is only for i.MX6 (if you do not plan to extend it to the other i.MXes...), so that we can track that the same must be done also for the other SOCs. I think this is clear from the commit prefix. Sorry, you're right, it is fine. I am under heavy load now and I cannot check their datasheet to verify if they all need this or not. If someone does not does it, I can take a look for sure. I look at MX51 / MX53 manuals. They are different as i.MX6, and in both cases I do not read the requirement to set the SION bit, as the i.MX6 needs. The fix is then only for i.MX6, and we do not need to extend it, at least according to documentation. After this check, I think that your patch is complete and I will push it for the release. I'm not sure where you're seeing this in the RM, but in order to read the pad state when not configured as an input, the SION bit needs to be set in the pad mux register on i.MX51/53. FWIW, this also works when not muxed as a GPIO, which is really handy for verifying that a PWM is toggling, et cetera. Regards, Eric ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/6] SMDK5420: Add S2MPS11 pmic support to SMDK5420
This patchset adds support for S2MPS11 pmic on SMDK5420 This patchset has dependency on Rajeshwari's base patchset: [V4] EXYNOS5420: Add SMDK5420 board support http://comments.gmane.org/gmane.comp.boot-loaders.u-boot/170582 Also, for testing we need Naveen's i2c patchset as well: i2c: improve s3c24x0 with High-speed and new SYS_I2C framework support http://www.mail-archive.com/u-boot@lists.denx.de/msg122679.html Leela Krishna Amudala (6): exynos: Use common pmic_reg_update() definition power: Explicitly select pmic device's bus FDT: Exynos5420: Add compatible srings for PMIC SMDK5420: S2MPS11: Adds the register settings for S2MPS11 exynos: Add a common DT based PMIC driver initialization config: SMDK5420: Enable S2MPS11 pmic board/samsung/common/board.c | 40 ++- drivers/power/pmic/Makefile |1 + drivers/power/pmic/pmic_common.c | 97 + drivers/power/power_core.c | 14 drivers/power/power_i2c.c| 81 +++-- include/configs/smdk5420.h |4 ++ include/fdtdec.h |1 + include/power/pmic.h | 35 + include/power/s2mps11_pmic.h | 144 ++ lib/fdtdec.c |1 + 10 files changed, 394 insertions(+), 24 deletions(-) create mode 100644 drivers/power/pmic/pmic_common.c create mode 100644 include/power/s2mps11_pmic.h -- 1.7.10.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/6] exynos: Use common pmic_reg_update() definition
This function is used by different Exynos platforms, put it in the
common file.
Signed-off-by: Vadim Bendebury vben...@chromium.org
Signed-off-by: Leela Krishna Amudala l.kris...@samsung.com
Reviewed-by: Doug Anderson diand...@google.com
---
board/samsung/common/board.c | 19 ---
drivers/power/power_i2c.c| 19 +++
include/power/pmic.h |1 +
3 files changed, 20 insertions(+), 19 deletions(-)
diff --git a/board/samsung/common/board.c b/board/samsung/common/board.c
index ce85ddb..87ca9de 100644
--- a/board/samsung/common/board.c
+++ b/board/samsung/common/board.c
@@ -152,25 +152,6 @@ static int board_init_cros_ec_devices(const void *blob)
#if defined(CONFIG_POWER)
#ifdef CONFIG_POWER_MAX77686
-static int pmic_reg_update(struct pmic *p, int reg, uint regval)
-{
- u32 val;
- int ret = 0;
-
- ret = pmic_reg_read(p, reg, val);
- if (ret) {
- debug(%s: PMIC %d register read failed\n, __func__, reg);
- return -1;
- }
- val |= regval;
- ret = pmic_reg_write(p, reg, val);
- if (ret) {
- debug(%s: PMIC %d register write failed\n, __func__, reg);
- return -1;
- }
- return 0;
-}
-
static int max77686_init(void)
{
struct pmic *p;
diff --git a/drivers/power/power_i2c.c b/drivers/power/power_i2c.c
index ac76870..47c606f 100644
--- a/drivers/power/power_i2c.c
+++ b/drivers/power/power_i2c.c
@@ -96,6 +96,25 @@ int pmic_reg_read(struct pmic *p, u32 reg, u32 *val)
return 0;
}
+int pmic_reg_update(struct pmic *p, int reg, uint regval)
+{
+ u32 val;
+ int ret = 0;
+
+ ret = pmic_reg_read(p, reg, val);
+ if (ret) {
+ debug(%s: PMIC %d register read failed\n, __func__, reg);
+ return -1;
+ }
+ val |= regval;
+ ret = pmic_reg_write(p, reg, val);
+ if (ret) {
+ debug(%s: PMIC %d register write failed\n, __func__, reg);
+ return -1;
+ }
+ return 0;
+}
+
int pmic_probe(struct pmic *p)
{
i2c_set_bus_num(p-bus);
diff --git a/include/power/pmic.h b/include/power/pmic.h
index 0e7aa31..d17dbdc 100644
--- a/include/power/pmic.h
+++ b/include/power/pmic.h
@@ -83,6 +83,7 @@ int pmic_probe(struct pmic *p);
int pmic_reg_read(struct pmic *p, u32 reg, u32 *val);
int pmic_reg_write(struct pmic *p, u32 reg, u32 val);
int pmic_set_output(struct pmic *p, u32 reg, int ldo, int on);
+int pmic_reg_update(struct pmic *p, int reg, uint regval);
#define pmic_i2c_addr (p-hw.i2c.addr)
#define pmic_i2c_tx_num (p-hw.i2c.tx_num)
--
1.7.10.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/6] FDT: Exynos5420: Add compatible srings for PMIC
Add required compatible strings for PMIC S2MPS11
Signed-off-by: Leela Krishna Amudala l.kris...@samsung.com
---
include/fdtdec.h |1 +
lib/fdtdec.c |1 +
2 files changed, 2 insertions(+)
diff --git a/include/fdtdec.h b/include/fdtdec.h
index 6bf83bf..6290078 100644
--- a/include/fdtdec.h
+++ b/include/fdtdec.h
@@ -85,6 +85,7 @@ enum fdt_compat_id {
COMPAT_INFINEON_SLB9635_TPM,/* Infineon SLB9635 TPM */
COMPAT_INFINEON_SLB9645_TPM,/* Infineon SLB9645 TPM */
COMPAT_SAMSUNG_EXYNOS5_I2C, /* Exynos5 High Speed I2C Controller */
+ COMPAT_SAMSUNG_S2MPS11_PMIC,/* S2MPS11 PMIC */
COMPAT_COUNT,
};
diff --git a/lib/fdtdec.c b/lib/fdtdec.c
index dc35856..0ea1c08 100644
--- a/lib/fdtdec.c
+++ b/lib/fdtdec.c
@@ -58,6 +58,7 @@ static const char * const compat_names[COMPAT_COUNT] = {
COMPAT(INFINEON_SLB9635_TPM, infineon,slb9635-tpm),
COMPAT(INFINEON_SLB9645_TPM, infineon,slb9645-tpm),
COMPAT(SAMSUNG_EXYNOS5_I2C, samsung,exynos5-hsi2c),
+ COMPAT(SAMSUNG_S2MPS11_PMIC, samsung,s2mps11-pmic),
};
const char *fdtdec_get_compatible(enum fdt_compat_id id)
--
1.7.10.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 5/6] exynos: Add a common DT based PMIC driver initialization
Most of i2c PMIC drivers follow the same initialization sequence,
let's generalize it in a common file.
The initialization function finds the PMIC in the device tree, and if
found - registers it in the list of known PMICs and initializes it,
iterating through the table of settings supplied by the caller.
Signed-off-by: Vadim Bendebury vben...@chromium.org
Signed-off-by: Leela Krishna Amudala l.kris...@samsung.com
Reviewed-by: Doug Anderson diand...@google.com
---
board/samsung/common/board.c | 23 -
drivers/power/pmic/Makefile |1 +
drivers/power/pmic/pmic_common.c | 97 ++
drivers/power/power_core.c | 14 ++
include/power/pmic.h | 34 +
5 files changed, 168 insertions(+), 1 deletion(-)
create mode 100644 drivers/power/pmic/pmic_common.c
diff --git a/board/samsung/common/board.c b/board/samsung/common/board.c
index 87ca9de..561e270 100644
--- a/board/samsung/common/board.c
+++ b/board/samsung/common/board.c
@@ -19,6 +19,7 @@
#include asm/arch/power.h
#include power/pmic.h
#include power/max77686_pmic.h
+#include power/s2mps11_pmic.h
DECLARE_GLOBAL_DATA_PTR;
@@ -150,6 +151,25 @@ static int board_init_cros_ec_devices(const void *blob)
}
#endif
+#ifdef CONFIG_POWER_S2MPS11
+int board_init_s2mps11(void)
+{
+ const struct pmic_init_ops pmic_ops[] = {
+ {PMIC_REG_WRITE, S2MPS11_BUCK1_CTRL2, S2MPS11_BUCK_CTRL2_1V},
+ {PMIC_REG_WRITE, S2MPS11_BUCK2_CTRL2,
+ S2MPS11_BUCK_CTRL2_1_2625V},
+ {PMIC_REG_WRITE, S2MPS11_BUCK3_CTRL2, S2MPS11_BUCK_CTRL2_1V},
+ {PMIC_REG_WRITE, S2MPS11_BUCK4_CTRL2, S2MPS11_BUCK_CTRL2_1V},
+ {PMIC_REG_WRITE, S2MPS11_BUCK6_CTRL2, S2MPS11_BUCK_CTRL2_1V},
+ {PMIC_REG_UPDATE, S2MPS11_REG_RTC_CTRL,
+ S2MPS11_RTC_CTRL_32KHZ_CP_EN | S2MPS11_RTC_CTRL_JIT},
+ {PMIC_REG_BAIL}
+ };
+
+ return pmic_common_init(COMPAT_SAMSUNG_S2MPS11_PMIC, pmic_ops);
+}
+#endif
+
#if defined(CONFIG_POWER)
#ifdef CONFIG_POWER_MAX77686
static int max77686_init(void)
@@ -255,8 +275,9 @@ int power_init_board(void)
#ifdef CONFIG_POWER_MAX77686
ret = max77686_init();
+#elif defined(CONFIG_POWER_S2MPS11)
+ ret = board_init_s2mps11();
#endif
-
return ret;
}
#endif
diff --git a/drivers/power/pmic/Makefile b/drivers/power/pmic/Makefile
index f054470..97b945c 100644
--- a/drivers/power/pmic/Makefile
+++ b/drivers/power/pmic/Makefile
@@ -13,6 +13,7 @@ COBJS-$(CONFIG_POWER_MAX8998) += pmic_max8998.o
COBJS-$(CONFIG_POWER_MAX8997) += pmic_max8997.o
COBJS-$(CONFIG_POWER_MUIC_MAX8997) += muic_max8997.o
COBJS-$(CONFIG_POWER_MAX77686) += pmic_max77686.o
+COBJS-$(CONFIG_POWER) += pmic_common.o
COBJS := $(COBJS-y)
SRCS := $(COBJS:.o=.c)
diff --git a/drivers/power/pmic/pmic_common.c b/drivers/power/pmic/pmic_common.c
new file mode 100644
index 000..772d1ee
--- /dev/null
+++ b/drivers/power/pmic/pmic_common.c
@@ -0,0 +1,97 @@
+/*
+ * Copyright (c) 2013 The Chromium OS Authors. All rights reserved.
+ * Use of this source code is governed by a BSD-style license that can be
+ * found in the LICENSE file.
+ */
+#include common.h
+#include fdtdec.h
+#include errno.h
+#include power/pmic.h
+#include power/s2mps11_pmic.h
+#include power/max77686_pmic.h
+
+DECLARE_GLOBAL_DATA_PTR;
+
+static unsigned pmic_number_of_regs(enum fdt_compat_id pmic_compat)
+{
+ switch (pmic_compat) {
+ case COMPAT_SAMSUNG_S2MPS11_PMIC:
+ return S2MPS11_NUM_OF_REGS;
+ default:
+ break;
+ }
+ return 0;
+}
+
+int pmic_common_init(enum fdt_compat_id pmic_compat,
+const struct pmic_init_ops *pmic_ops)
+{
+ const void *blob = gd-fdt_blob;
+ struct pmic *p;
+ int node, parent, ret;
+ unsigned number_of_regs = pmic_number_of_regs(pmic_compat);
+ const char *pmic_name, *comma;
+
+ if (!number_of_regs) {
+ printf(%s: %s - not a supported PMIC\n,
+ __func__, fdtdec_get_compatible(pmic_compat));
+ return -1;
+ }
+
+ node = fdtdec_next_compatible(blob, 0, pmic_compat);
+ if (node 0) {
+ debug(PMIC: Error %s. No node for %s in device tree\n,
+ fdt_strerror(node), fdtdec_get_compatible(pmic_compat));
+ return node;
+ }
+
+ pmic_name = fdtdec_get_compatible(pmic_compat);
+ comma = strchr(pmic_name, ',');
+ if (comma)
+ pmic_name = comma + 1;
+
+ p = pmic_alloc();
+
+ if (!p) {
+ printf(%s: POWER allocation error!\n, __func__);
+ return -ENOMEM;
+ }
+ parent = fdt_parent_offset(blob, node);
+ if (parent 0) {
+ debug(%s: Cannot find node parent\n, __func__);
+ return -1;
+ }
+
+ p-bus = i2c_get_bus_num_fdt(parent);
+
[U-Boot] [PATCH 2/6] power: Explicitly select pmic device's bus
The current pmic i2c code assumes the current i2c bus is
the same as the pmic device's bus. There is nothing ensuring
that to be true. Therefore, select the proper bus before performing
a transaction.
Signed-off-by: Aaron Durbin adur...@chromium.org
Signed-off-by: Simon Glass s...@chromium.org
Signed-off-by: Leela Krishna Amudala l.kris...@samsung.com
Reviewed-by: Doug Anderson diand...@google.com
---
drivers/power/power_i2c.c | 62 +
1 file changed, 57 insertions(+), 5 deletions(-)
diff --git a/drivers/power/power_i2c.c b/drivers/power/power_i2c.c
index 47c606f..c22e01f 100644
--- a/drivers/power/power_i2c.c
+++ b/drivers/power/power_i2c.c
@@ -16,9 +16,45 @@
#include i2c.h
#include compiler.h
+static int pmic_select(struct pmic *p)
+{
+ int ret, old_bus;
+
+ old_bus = i2c_get_bus_num();
+ if (old_bus != p-bus) {
+ debug(%s: Select bus %d\n, __func__, p-bus);
+ ret = i2c_set_bus_num(p-bus);
+ if (ret) {
+ debug(%s: Cannot select pmic %s, err %d\n,
+ __func__, p-name, ret);
+ return -1;
+ }
+ }
+
+ return old_bus;
+}
+
+static int pmic_deselect(int old_bus)
+{
+ int ret;
+
+ if (old_bus != i2c_get_bus_num()) {
+ ret = i2c_set_bus_num(old_bus);
+ debug(%s: Select bus %d\n, __func__, old_bus);
+ if (ret) {
+ debug(%s: Cannot restore i2c bus, err %d\n,
+ __func__, ret);
+ return -1;
+ }
+ }
+
+ return 0;
+}
+
int pmic_reg_write(struct pmic *p, u32 reg, u32 val)
{
unsigned char buf[4] = { 0 };
+ int ret, old_bus;
if (check_reg(p, reg))
return -1;
@@ -52,23 +88,33 @@ int pmic_reg_write(struct pmic *p, u32 reg, u32 val)
return -1;
}
- if (i2c_write(pmic_i2c_addr, reg, 1, buf, pmic_i2c_tx_num))
+ old_bus = pmic_select(p);
+ if (old_bus 0)
return -1;
- return 0;
+ ret = i2c_write(pmic_i2c_addr, reg, 1, buf, pmic_i2c_tx_num);
+ pmic_deselect(old_bus);
+ return ret;
}
int pmic_reg_read(struct pmic *p, u32 reg, u32 *val)
{
unsigned char buf[4] = { 0 };
u32 ret_val = 0;
+ int ret, old_bus;
if (check_reg(p, reg))
return -1;
- if (i2c_read(pmic_i2c_addr, reg, 1, buf, pmic_i2c_tx_num))
+ old_bus = pmic_select(p);
+ if (old_bus 0)
return -1;
+ ret = i2c_read(pmic_i2c_addr, reg, 1, buf, pmic_i2c_tx_num);
+ pmic_deselect(old_bus);
+ if (ret)
+ return ret;
+
switch (pmic_i2c_tx_num) {
case 3:
if (p-sensor_byte_order == PMIC_SENSOR_BYTE_ORDER_BIG)
@@ -117,9 +163,15 @@ int pmic_reg_update(struct pmic *p, int reg, uint regval)
int pmic_probe(struct pmic *p)
{
- i2c_set_bus_num(p-bus);
+ int ret, old_bus;
+
+ old_bus = pmic_select(p);
+ if (old_bus 0)
+ return -1;
debug(Bus: %d PMIC:%s probed!\n, p-bus, p-name);
- if (i2c_probe(pmic_i2c_addr)) {
+ ret = i2c_probe(pmic_i2c_addr);
+ pmic_deselect(old_bus);
+ if (ret) {
printf(Can't find PMIC:%s\n, p-name);
return -1;
}
--
1.7.10.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 4/6] SMDK5420: S2MPS11: Adds the register settings for S2MPS11
Adds the register settings, addresses and voltages associated with S2MPS11
Signed-off-by: Alim Akhtar alim.akh...@samsung.com
Signed-off-by: Leela Krishna Amudala l.kris...@samsung.com
Reviewed-by: Vadim Bendebury vben...@google.com
---
include/power/s2mps11_pmic.h | 144 ++
1 file changed, 144 insertions(+)
create mode 100644 include/power/s2mps11_pmic.h
diff --git a/include/power/s2mps11_pmic.h b/include/power/s2mps11_pmic.h
new file mode 100644
index 000..e4f21f9
--- /dev/null
+++ b/include/power/s2mps11_pmic.h
@@ -0,0 +1,144 @@
+/*
+ * s2mps11_pmic.h
+ *
+ * Copyright (c) 2012 Samsung Electronics Co., Ltd
+ * http://www.samsung.com
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ *
+ */
+#ifndef __S2MPS11_H
+#define __S2MPS11_H
+
+/* S2MPS11 registers */
+enum s2mps11_reg {
+ S2MPS11_REG_ID,
+ S2MPS11_REG_INT1,
+ S2MPS11_REG_INT2,
+ S2MPS11_REG_INT3,
+ S2MPS11_REG_INT1M,
+ S2MPS11_REG_INT2M,
+ S2MPS11_REG_INT3M,
+ S2MPS11_REG_ST1,
+ S2MPS11_REG_ST2,
+ S2MPS11_REG_OFFSRC,
+ S2MPS11_REG_PWRONSRC,
+ S2MPS11_REG_RTC_CTRL,
+ S2MPS11_REG_CTRL1,
+ S2MPS11_REG_ETC_TEST,
+ S2MPS11_REG_RSVD3,
+ S2MPS11_REG_BU_CHG,
+ S2MPS11_REG_RAMP,
+ S2MPS11_REG_RAMP_BUCK,
+ S2MPS11_REG_LDO1_8,
+ S2MPS11_REG_LDO9_16,
+ S2MPS11_REG_LDO17_24,
+ S2MPS11_REG_LDO25_32,
+ S2MPS11_REG_LDO33_38,
+ S2MPS11_REG_LDO1_8_1,
+ S2MPS11_REG_LDO9_16_1,
+ S2MPS11_REG_LDO17_24_1,
+ S2MPS11_REG_LDO25_32_1,
+ S2MPS11_REG_LDO33_38_1,
+ S2MPS11_REG_OTP_ADRL,
+ S2MPS11_REG_OTP_ADRH,
+ S2MPS11_REG_OTP_DATA,
+ S2MPS11_REG_MON1SEL,
+ S2MPS11_REG_MON2SEL,
+ S2MPS11_REG_LEE,
+ S2MPS11_REG_RSVD_NO,
+ S2MPS11_REG_UVLO,
+ S2MPS11_REG_LEE_NO,
+ S2MPS11_REG_B1CTRL1,
+ S2MPS11_REG_B1CTRL2,
+ S2MPS11_REG_B2CTRL1,
+ S2MPS11_REG_B2CTRL2,
+ S2MPS11_REG_B3CTRL1,
+ S2MPS11_REG_B3CTRL2,
+ S2MPS11_REG_B4CTRL1,
+ S2MPS11_REG_B4CTRL2,
+ S2MPS11_REG_B5CTRL1,
+ S2MPS11_REG_BUCK5_SW,
+ S2MPS11_REG_B5CTRL2,
+ S2MPS11_REG_B5CTRL3,
+ S2MPS11_REG_B5CTRL4,
+ S2MPS11_REG_B5CTRL5,
+ S2MPS11_REG_B6CTRL1,
+ S2MPS11_REG_B6CTRL2,
+ S2MPS11_REG_B7CTRL1,
+ S2MPS11_REG_B7CTRL2,
+ S2MPS11_REG_B8CTRL1,
+ S2MPS11_REG_B8CTRL2,
+ S2MPS11_REG_B9CTRL1,
+ S2MPS11_REG_B9CTRL2,
+ S2MPS11_REG_B10CTRL1,
+ S2MPS11_REG_B10CTRL2,
+ S2MPS11_REG_L1CTRL,
+ S2MPS11_REG_L2CTRL,
+ S2MPS11_REG_L3CTRL,
+ S2MPS11_REG_L4CTRL,
+ S2MPS11_REG_L5CTRL,
+ S2MPS11_REG_L6CTRL,
+ S2MPS11_REG_L7CTRL,
+ S2MPS11_REG_L8CTRL,
+ S2MPS11_REG_L9CTRL,
+ S2MPS11_REG_L10CTRL,
+ S2MPS11_REG_L11CTRL,
+ S2MPS11_REG_L12CTRL,
+ S2MPS11_REG_L13CTRL,
+ S2MPS11_REG_L14CTRL,
+ S2MPS11_REG_L15CTRL,
+ S2MPS11_REG_L16CTRL,
+ S2MPS11_REG_L17CTRL,
+ S2MPS11_REG_L18CTRL,
+ S2MPS11_REG_L19CTRL,
+ S2MPS11_REG_L20CTRL,
+ S2MPS11_REG_L21CTRL,
+ S2MPS11_REG_L22CTRL,
+ S2MPS11_REG_L23CTRL,
+ S2MPS11_REG_L24CTRL,
+ S2MPS11_REG_L25CTRL,
+ S2MPS11_REG_L26CTRL,
+ S2MPS11_REG_L27CTRL,
+ S2MPS11_REG_L28CTRL,
+ S2MPS11_REG_L29CTRL,
+ S2MPS11_REG_L30CTRL,
+ S2MPS11_REG_L31CTRL,
+ S2MPS11_REG_L32CTRL,
+ S2MPS11_REG_L33CTRL,
+ S2MPS11_REG_L34CTRL,
+ S2MPS11_REG_L35CTRL,
+ S2MPS11_REG_L36CTRL,
+ S2MPS11_REG_L37CTRL,
+ S2MPS11_REG_L38CTRL,
+
+ S2MPS11_NUM_OF_REGS,
+};
+
+/* I2C device address for pmic S2MPS11 */
+#define S2MPS11_I2C_ADDR (0xCC 1)
+#define S2MPS11_BUS_NUM4
+
+/* Value to set voltage as 1V */
+#define S2MPS11_BUCK_CTRL2_1V 0x40
+/* Value to set voltage as 1.2V */
+#define S2MPS11_BUCK_CTRL2_1_2V0x60
+/* Value to set voltage as 1.2625V */
+#define S2MPS11_BUCK_CTRL2_1_2625V 0x6A
+
+/* Buck register addresses */
+#define S2MPS11_BUCK1_CTRL20x26
+#define S2MPS11_BUCK2_CTRL20x28
+#define S2MPS11_BUCK3_CTRL20x2a
+#define S2MPS11_BUCK4_CTRL20x2c
+#define S2MPS11_BUCK6_CTRL20x34
+#define S2MPS11_LDO22_CTRL 0x52
+
+#define S2MPS11_DEVICE_NAME S2MPS11_PMIC
+
+#define S2MPS11_RTC_CTRL_32KHZ_CP_EN (1 1)
+#define S2MPS11_RTC_CTRL_JIT (1 4)
+#endif /* __LINUX_MFD_S2MPS11_H */
--
1.7.10.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 6/6] config: SMDK5420: Enable S2MPS1111111111111111111111 pmic
configure S2MPS11 pmic on SMDK5420 Signed-off-by: Leela Krishna Amudala l.kris...@samsung.com --- include/configs/smdk5420.h |4 1 file changed, 4 insertions(+) diff --git a/include/configs/smdk5420.h b/include/configs/smdk5420.h index 447f8e5..46aeec0 100644 --- a/include/configs/smdk5420.h +++ b/include/configs/smdk5420.h @@ -53,4 +53,8 @@ #define CONFIG_MAX_I2C_NUM 11 +#define CONFIG_POWER +#define CONFIG_POWER_I2C +#define CONFIG_POWER_S2MPS11 + #endif /* __CONFIG_5420_H */ -- 1.7.10.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mx6: Add IOMUX_CONFIG_SION flag to all GPIO pins
Hi Eric, On 01/10/2013 16:26, Eric Nelson wrote: I'm not sure where you're seeing this in the RM, but in order to read the pad state when not configured as an input, the SION bit needs to be set in the pad mux register on i.MX51/53. I have checked inside the 37.3.2.2 GPIO Write for i.MX53 and 35.4.2.1 Read Value from Pad for i:MX51, I have not read anything about SION. If someone has found where it is described, please mail ! FWIW, this also works when not muxed as a GPIO, which is really handy for verifying that a PWM is toggling, et cetera. Well, if you have directly tested it, it is better proofed as by the manuals..then we need the same fix for i.MX51/i.MX53, too. Thanks, Stefano -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] usb: Fix error handling in musb_hcd.c
The wait_until_[rx|tx]ep_ready functions return a u8 to indicate success
containing the value 0, 1 or -1. This patch changes the return type to an
int to accommodate the negative return values.
These functions are used in the file using calls such as if (!wait_until...
Where a -1 is returned it is mishandled and treated as success instead of
a CRC error. This patch addresses this.
Cc: Marek Vasut ma...@denx.de
Cc: Tom Rini tr...@ti.com
Signed-off-by: Andrew Murray amur...@embedded-bits.co.uk
---
drivers/usb/musb/musb_hcd.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/usb/musb/musb_hcd.c b/drivers/usb/musb/musb_hcd.c
index ae39c4a..708fa12 100644
--- a/drivers/usb/musb/musb_hcd.c
+++ b/drivers/usb/musb/musb_hcd.c
@@ -267,7 +267,7 @@ static int wait_until_ep0_ready(struct usb_device *dev, u32
bit_mask)
/*
* waits until tx ep is ready. Returns 1 when ep is ready and 0 on error.
*/
-static u8 wait_until_txep_ready(struct usb_device *dev, u8 ep)
+static int wait_until_txep_ready(struct usb_device *dev, u8 ep)
{
u16 csr;
int timeout = CONFIG_MUSB_TIMEOUT;
@@ -299,7 +299,7 @@ static u8 wait_until_txep_ready(struct usb_device *dev, u8
ep)
/*
* waits until rx ep is ready. Returns 1 when ep is ready and 0 on error.
*/
-static u8 wait_until_rxep_ready(struct usb_device *dev, u8 ep)
+static int wait_until_rxep_ready(struct usb_device *dev, u8 ep)
{
u16 csr;
int timeout = CONFIG_MUSB_TIMEOUT;
@@ -1018,7 +1018,7 @@ int submit_bulk_msg(struct usb_device *dev, unsigned long
pipe,
writew(csr | MUSB_TXCSR_TXPKTRDY, musbr-txcsr);
/* Wait until the TxPktRdy bit is cleared */
- if (!wait_until_txep_ready(dev, MUSB_BULK_EP)) {
+ if (wait_until_txep_ready(dev, MUSB_BULK_EP) != 1) {
readw(musbr-txcsr);
usb_settoggle(dev, ep, dir_out,
(csr MUSB_TXCSR_H_DATATOGGLE_SHIFT) 1);
@@ -1053,7 +1053,7 @@ int submit_bulk_msg(struct usb_device *dev, unsigned long
pipe,
writew(csr | MUSB_RXCSR_H_REQPKT, musbr-rxcsr);
/* Wait until the RxPktRdy bit is set */
- if (!wait_until_rxep_ready(dev, MUSB_BULK_EP)) {
+ if (wait_until_rxep_ready(dev, MUSB_BULK_EP) != 1) {
csr = readw(musbr-rxcsr);
usb_settoggle(dev, ep, dir_out,
(csr MUSB_S_RXCSR_H_DATATOGGLE) 1);
@@ -1226,7 +1226,7 @@ int submit_int_msg(struct usb_device *dev, unsigned long
pipe,
writew(csr | MUSB_RXCSR_H_REQPKT, musbr-rxcsr);
/* Wait until the RxPktRdy bit is set */
- if (!wait_until_rxep_ready(dev, MUSB_INTR_EP)) {
+ if (wait_until_rxep_ready(dev, MUSB_INTR_EP) != 1) {
csr = readw(musbr-rxcsr);
usb_settoggle(dev, ep, dir_out,
(csr MUSB_S_RXCSR_H_DATATOGGLE) 1);
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] SPL: Reading large files with file_fat_read()
Hi,
I need to read a file in spl.c, which is about 675 bytes. I used the
following code:
static unsigned char helperData[675] = {0x00};
s32 err;
uint8_t i = 0;
printf(\n[D] - Reading Helper Data\r\n\n);
err = file_fat_read(filename, helperData, length);
if(err 0){
printf([D] - Received Helper Data (%d bytes):\n, err);
for(i = 0; i err; i++){
if((i%9==0)i0)printf(\n);
printf(0x%02x , helperData[i]);
}
}else{
printf([E] - Error reading Helper Data file %s from MMC\n,
filename);
}
puts();
However, during boot time it stucks while reading the file. It only outputs:
reading foo.bar
It works with smaller files fine. Do I need to implement changes to
do_fat_read() in fat.c or what could be the problem?
Best regards,
-b
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 2/2] Tegra114: Do not program CPCON field for PLLX
PLLX no longer has the CPCON field on Tegra114, so do not attempt to
program it.
Signed-off-by: Thierry Reding tred...@nvidia.com
---
Changes in v3:
- don't leak PLLX_BASE bits into PLLX_MISC
Changes in v2:
- new patch
arch/arm/cpu/arm720t/tegra-common/cpu.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/arch/arm/cpu/arm720t/tegra-common/cpu.c
b/arch/arm/cpu/arm720t/tegra-common/cpu.c
index aa1e04f..72c69b9 100644
--- a/arch/arm/cpu/arm720t/tegra-common/cpu.c
+++ b/arch/arm/cpu/arm720t/tegra-common/cpu.c
@@ -135,6 +135,7 @@ void adjust_pllp_out_freqs(void)
int pllx_set_rate(struct clk_pll_simple *pll , u32 divn, u32 divm,
u32 divp, u32 cpcon)
{
+ int chip = tegra_get_chip();
u32 reg;
/* If PLLX is already enabled, just return */
@@ -151,7 +152,10 @@ int pllx_set_rate(struct clk_pll_simple *pll , u32 divn,
u32 divm,
writel(reg, pll-pll_base);
/* Set cpcon to PLLX_MISC */
- reg = (cpcon PLL_CPCON_SHIFT);
+ if (chip == CHIPID_TEGRA20 || chip == CHIPID_TEGRA30)
+ reg = (cpcon PLL_CPCON_SHIFT);
+ else
+ reg = 0;
/* Set dccon to PLLX_MISC if freq 600MHz */
if (divn 600)
--
1.8.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 3/4] generic board patch of manual reloc and zero gd_t
On Tue, 2013-10-01 at 19:05 +0800, FengHua wrote: -原始邮件- 发件人: Scott Wood scottw...@freescale.com 发送时间: 2013年10月1日 星期二 收件人: Simon Glass s...@chromium.org 抄送: trini tr...@ti.com, u-boot u-boot@lists.denx.de, FengHua feng...@phytium.com.cn 主题: Re: [U-Boot] [PATCH v4 3/4] generic board patch of manual reloc and zero gd_t On Mon, 2013-09-09 at 20:54 -0500, Scott Wood wrote: It seems the problem is that when rela is used, the linker *only* puts the symbol in the rela struct. The value in the data section itself is zero, which means we can't run without relocation even if the address hasn't changed. Unless there's some way to change this linker behavior, the options I can think of are: 1. Write a utility to apply the relocations (for the pre-relocation address) at build time, or 2. Use SPL. The SPL itself would not use -pie and would not relocate. The main U-Boot would know that it has been loaded into RAM, and apply relocations prior to entering C code. Interactions with SPL being used for other purposes could be awkward. Any preferences, or other suggestions? I think either of these options is preferable to CONFIG_NEEDS_MANUAL_RELOC. I'm inclined toward option #1 as it avoids interactions with other SPL uses and in general doesn't change the runtime flow. #1 is easier to do on the u-boot.bin rather than on the ELF file[1], but apparently that doesn't do us any good with the model because it wants an ELF file. Shouldn't the model be applying the relocations if it's an ELF loader? Is there any way to get the foundation model to load a raw binary? I tried --data and --nsdata at 0x8000 (alone or in combination with --image) and wasn't able to do a write to the LEDs immediately after reset (which works when I load it as ELF). It works when I convert the binary back into an ELF using objcopy and ld, but it would be nice to avoid that... How about place u-boot.bin at 0x9000 and write a piece of code (elf format) jumping from 0x8000 to 0x9000. That seems even worse than converting the .bin back into an ELF... Do you know why loading the raw image at 0x8000 isn't working? -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/2] Tegra114: Do not program CPCON field for PLLX
On Mon, Sep 30, 2013 at 02:25:57PM -0700, Tom Warren wrote:
Thierry,
-Original Message-
From: Thierry Reding [mailto:thierry.red...@gmail.com]
Sent: Monday, September 23, 2013 1:08 PM
To: Tom Warren
Cc: u-boot@lists.denx.de
Subject: [PATCH v2 2/2] Tegra114: Do not program CPCON field for PLLX
PLLX no longer has the CPCON field on Tegra114, so do not attempt to
program it.
Signed-off-by: Thierry Reding tred...@nvidia.com
---
Changes in v2:
- new patch
arch/arm/cpu/arm720t/tegra-common/cpu.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/arm/cpu/arm720t/tegra-common/cpu.c
b/arch/arm/cpu/arm720t/tegra-common/cpu.c
index aa1e04f..5ab2ebf 100644
--- a/arch/arm/cpu/arm720t/tegra-common/cpu.c
+++ b/arch/arm/cpu/arm720t/tegra-common/cpu.c
@@ -135,6 +135,7 @@ void adjust_pllp_out_freqs(void) int
pllx_set_rate(struct clk_pll_simple *pll , u32 divn, u32 divm,
u32 divp, u32 cpcon)
{
+ int chip = tegra_get_chip();
u32 reg;
/* If PLLX is already enabled, just return */ @@ -151,7 +152,8 @@ int
pllx_set_rate(struct clk_pll_simple *pll , u32 divn, u32 divm,
writel(reg, pll-pll_base);
/* Set cpcon to PLLX_MISC */
- reg = (cpcon PLL_CPCON_SHIFT);
+ if (chip == CHIPID_TEGRA20 || chip == CHIPID_TEGRA30)
+ reg = (cpcon PLL_CPCON_SHIFT);
If it's not a T20/T30, reg is still set to the PLLX_BASE setting from above.
It'll then be written to PLLX_MISC w/bad bits below.
You need to set a default, or read pllx_misc first.
Ugh... you're right of course. Sent a v3 with reg = 0 in the else
branch.
Thanks,
Thierry
pgpkTp6bHL5ws.pgp
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 1/2] Tegra114: Fix PLLX M, N, P init settings
From: Jimmy Zhang jimmzh...@nvidia.com
The M, N and P width have been changed from Tegra30. The maximum value
for N is limited to 255. So, the tegra_pll_x_table for Tegra114 should
be set accordingly.
Signed-off-by: Jimmy Zhang jimmzh...@nvidia.com
Reviewed-by: Tom Warren twar...@nvidia.com
Signed-off-by: Thierry Reding tred...@nvidia.com
---
Changes in v3:
- none
Changes in v2:
- clean up table layout and comments
arch/arm/cpu/arm720t/tegra-common/cpu.c | 83 +++--
1 file changed, 59 insertions(+), 24 deletions(-)
diff --git a/arch/arm/cpu/arm720t/tegra-common/cpu.c
b/arch/arm/cpu/arm720t/tegra-common/cpu.c
index 9294611..aa1e04f 100644
--- a/arch/arm/cpu/arm720t/tegra-common/cpu.c
+++ b/arch/arm/cpu/arm720t/tegra-common/cpu.c
@@ -49,33 +49,68 @@ int get_num_cpus(void)
* Timing tables for each SOC for all four oscillator options.
*/
struct clk_pll_table tegra_pll_x_table[TEGRA_SOC_CNT][CLOCK_OSC_FREQ_COUNT] = {
- /* T20: 1 GHz */
- /* n, m, p, cpcon */
- {{ 1000, 13, 0, 12},/* OSC 13M */
-{ 625, 12, 0, 8}, /* OSC 19.2M */
-{ 1000, 12, 0, 12},/* OSC 12M */
-{ 1000, 26, 0, 12},/* OSC 26M */
+ /*
+* T20: 1 GHz
+*
+* Register Field Bits Width
+* --
+* PLLX_BASE p 22:203
+* PLLX_BASE n 17: 8 10
+* PLLX_BASE m 4: 05
+* PLLX_MISC cpcon 11: 84
+*/
+ {
+ { .n = 1000, .m = 13, .p = 0, .cpcon = 12 }, /* OSC: 13.0 MHz */
+ { .n = 625, .m = 12, .p = 0, .cpcon = 8 }, /* OSC: 19.2 MHz */
+ { .n = 1000, .m = 12, .p = 0, .cpcon = 12 }, /* OSC: 12.0 MHz */
+ { .n = 1000, .m = 26, .p = 0, .cpcon = 12 }, /* OSC: 26.0 MHz */
},
-
- /* T25: 1.2 GHz */
- {{ 923, 10, 0, 12},
-{ 750, 12, 0, 8},
-{ 600, 6, 0, 12},
-{ 600, 13, 0, 12},
+ /*
+* T25: 1.2 GHz
+*
+* Register Field Bits Width
+* --
+* PLLX_BASE p 22:203
+* PLLX_BASE n 17: 8 10
+* PLLX_BASE m 4: 05
+* PLLX_MISC cpcon 11: 84
+*/
+ {
+ { .n = 923, .m = 10, .p = 0, .cpcon = 12 }, /* OSC: 13.0 MHz */
+ { .n = 750, .m = 12, .p = 0, .cpcon = 8 }, /* OSC: 19.2 MHz */
+ { .n = 600, .m = 6, .p = 0, .cpcon = 12 }, /* OSC: 12.0 MHz */
+ { .n = 600, .m = 13, .p = 0, .cpcon = 12 }, /* OSC: 26.0 MHz */
},
-
- /* T30: 1.4 GHz */
- {{ 862, 8, 0, 8},
-{ 583, 8, 0, 4},
-{ 700, 6, 0, 8},
-{ 700, 13, 0, 8},
+ /*
+* T30: 1.4 GHz
+*
+* Register Field Bits Width
+* --
+* PLLX_BASE p 22:203
+* PLLX_BASE n 17: 8 10
+* PLLX_BASE m 4: 05
+* PLLX_MISC cpcon 11: 84
+*/
+ {
+ { .n = 862, .m = 8, .p = 0, .cpcon = 8 }, /* OSC: 13.0 MHz */
+ { .n = 583, .m = 8, .p = 0, .cpcon = 4 }, /* OSC: 19.2 MHz */
+ { .n = 700, .m = 6, .p = 0, .cpcon = 8 }, /* OSC: 12.0 MHz */
+ { .n = 700, .m = 13, .p = 0, .cpcon = 8 }, /* OSC: 26.0 MHz */
},
-
- /* T114: 1.4 GHz */
- {{ 862, 8, 0, 8},
-{ 583, 8, 0, 4},
-{ 696, 12, 0, 8},
-{ 700, 13, 0, 8},
+ /*
+* T114: 700 MHz
+*
+* Register Field Bits Width
+* --
+* PLLX_BASE p 23:204
+* PLLX_BASE n 15: 88
+* PLLX_BASE m 7: 08
+*/
+ {
+ { .n = 108, .m = 1, .p = 1 }, /* OSC: 13.0 MHz */
+ { .n = 73, .m = 1, .p = 1 }, /* OSC: 19.2 MHz */
+ { .n = 116, .m = 1, .p = 1 }, /* OSC: 12.0 MHz */
+ { .n = 108, .m = 2, .p = 1 }, /* OSC: 26.0 MHz */
},
};
--
1.8.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mpc85xx: Fix the offset of register address error
On 09/22/2013 02:33 AM, Tang Yuantian wrote:
From: Tang Yuantian yuantian.t...@freescale.com
The offset of register address within GPIO module is just
CONFIG_SYS_MPC85xx_GPIO_ADDR, no reason to add 0xc00.
Signed-off-by: Tang Yuantian yuantian.t...@freescale.com
---
arch/powerpc/include/asm/mpc85xx_gpio.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/include/asm/mpc85xx_gpio.h
b/arch/powerpc/include/asm/mpc85xx_gpio.h
index 3d11884..87bb4a0 100644
--- a/arch/powerpc/include/asm/mpc85xx_gpio.h
+++ b/arch/powerpc/include/asm/mpc85xx_gpio.h
@@ -20,7 +20,7 @@
static inline void mpc85xx_gpio_set(unsigned int mask,
unsigned int dir, unsigned int val)
{
- ccsr_gpio_t *gpio = (void *)(CONFIG_SYS_MPC85xx_GPIO_ADDR + 0xc00);
+ ccsr_gpio_t *gpio = (void *)(CONFIG_SYS_MPC85xx_GPIO_ADDR);
/* First mask off the unwanted parts of dir and val */
dir = mask;
@@ -56,7 +56,7 @@ static inline void mpc85xx_gpio_set_high(unsigned int gpios)
static inline unsigned int mpc85xx_gpio_get(unsigned int mask)
{
- ccsr_gpio_t *gpio = (void *)(CONFIG_SYS_MPC85xx_GPIO_ADDR + 0xc00);
+ ccsr_gpio_t *gpio = (void *)(CONFIG_SYS_MPC85xx_GPIO_ADDR);
/* Read the requested values */
return in_be32(gpio-gpdat) mask;
Yuantian,
Please go through the base address again. I think some SoCs do use 0xc00
offset from 0xF000, for eample P1020, P1023, MPC8572. I only spot
checked several.
York
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH][v2] boards/c29xpcie: Update TLB and LAW size for IFC NAND, CPLD
On 09/24/2013 03:28 AM, Prabhakar Kushwaha wrote: NAND,CPLD AMASK register is programmed for 64K size. so Update TLB LAW size accordingly. Signed-off-by: Prabhakar Kushwaha prabha...@freescale.com --- Based upon git://git.denx.de/u-boot.git branch master changes for v2: - Updated both CPLD and NAND Applied to u-boot-mpc85xx/next branch, pending merging to u-boot-mpc85xx/master branch. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mx6: Add IOMUX_CONFIG_SION flag to all GPIO pins
Hi Stefano, On 10/01/2013 07:49 AM, Stefano Babic wrote: Hi Eric, On 01/10/2013 16:26, Eric Nelson wrote: I'm not sure where you're seeing this in the RM, but in order to read the pad state when not configured as an input, the SION bit needs to be set in the pad mux register on i.MX51/53. I have checked inside the 37.3.2.2 GPIO Write for i.MX53 and 35.4.2.1 Read Value from Pad for i:MX51, I have not read anything about SION. If someone has found where it is described, please mail ! That documentation seems to imply that there's no dependency (i.e. there's no reference to SION), but I think that's an omission. FWIW, this also works when not muxed as a GPIO, which is really handy for verifying that a PWM is toggling, et cetera. Well, if you have directly tested it, it is better proofed as by the manuals..then we need the same fix for i.MX51/i.MX53, too. I've tested this many times, since it's a really handy way of debugging hardware setups. That said, I'm not sure that there's a huge difference between a single patch or multiple patches for each arch unless there's some functionality dependent on being able to read the actual value of a pin configured as a GPIO output. Did I miss something in this thread that does actually require that ability? It seems a pretty obscure thing in the normal case to drive an output without confidence that it will succeed. Regards, Eric ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mmc: sdhci: Avoid commands errors by simple timeout adaptation.
Hi there,
On Oct 1, 2013, at 3:16 PM, Przemyslaw Marczak wrote:
Old command timeout value was too small and it caused I/O errors which
led to uncompleted read/write/erase operations and filesystem errors.
Timeout adaptation fixes this issue.
Changes in sdhci_send_command() function:
- change timeout variable to static
- increase default command timeout to 100 ms
- add definition of max command timeout value,
which can be redefined in each board config file
- wait for card ready state for max defined time
if it doesn't exceed defined maximum or return COMM_ERR
Once successfully increased timeout value will be used in next function
call. This fix was tested on Goni, Trats, Trats2 boards by testing UMS
on MMC storage.
Signed-off-by: Przemyslaw Marczak p.marc...@samsung.com
---
drivers/mmc/sdhci.c | 34 +++---
1 file changed, 27 insertions(+), 7 deletions(-)
diff --git a/drivers/mmc/sdhci.c b/drivers/mmc/sdhci.c
index 4261991..af11fc5 100644
--- a/drivers/mmc/sdhci.c
+++ b/drivers/mmc/sdhci.c
@@ -110,6 +110,22 @@ static int sdhci_transfer_data(struct sdhci_host *host,
struct mmc_data *data,
return 0;
}
+/*
+ * No command will be sent by driver if card is busy, so driver must wait
+ * for card ready state.
+ * Every time when card is busy after timeout then (last) timeout value will
be
+ * increased twice but only if it doesn't exceed global defined maximum.
+ * Each function call will use last timeout value. Max timeout can be
redefined
+ * in board config file.
+ */
+#ifndef CONFIG_SDHCI_CMD_MAX_TIMEOUT
+#define CONFIG_SDHCI_CMD_MAX_TIMEOUT 3200
+#endif
+#define CONFIG_SDHCI_CMD_DEFAULT_TIMEOUT 100
+
+/* Timeout unit - ms */
+static unsigned int cmd_timeout = CONFIG_SDHCI_CMD_DEFAULT_TIMEOUT;
+
int sdhci_send_command(struct mmc *mmc, struct mmc_cmd *cmd,
struct mmc_data *data)
{
@@ -118,12 +134,9 @@ int sdhci_send_command(struct mmc *mmc, struct mmc_cmd
*cmd,
int ret = 0;
int trans_bytes = 0, is_aligned = 1;
u32 mask, flags, mode;
- unsigned int timeout, start_addr = 0;
+ unsigned int time = 0, start_addr = 0;
unsigned int retry = 1;
- /* Wait max 10 ms */
- timeout = 10;
-
sdhci_writel(host, SDHCI_INT_ALL_MASK, SDHCI_INT_STATUS);
mask = SDHCI_CMD_INHIBIT | SDHCI_DATA_INHIBIT;
@@ -133,11 +146,18 @@ int sdhci_send_command(struct mmc *mmc, struct mmc_cmd
*cmd,
mask = ~SDHCI_DATA_INHIBIT;
while (sdhci_readl(host, SDHCI_PRESENT_STATE) mask) {
- if (timeout == 0) {
+ if (time == cmd_timeout) {
time = cmd_timeout here.
You rely on the timeout hitting exactly the same value which is not guaranteed.
printf(Controller never released inhibit bit(s).\n);
- return COMM_ERR;
+ if (2 * cmd_timeout = CONFIG_SDHCI_CMD_MAX_TIMEOUT) {
+ cmd_timeout += cmd_timeout;
+ debug(Increasing command timeout to: %u ms.\n,
+ cmd_timeout);
+ } else {
+ error(Command timeout is set to max.\n);
+ return COMM_ERR;
+ }
}
- timeout--;
+ time++;
udelay(1000);
}
--
1.7.9.5
Other than that the concept seems sound.
Regards
-- Pantelis
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mx6: Add IOMUX_CONFIG_SION flag to all GPIO pins
Hi Eric, On 01/10/2013 17:56, Eric Nelson wrote: Hi Stefano, On 10/01/2013 07:49 AM, Stefano Babic wrote: Hi Eric, On 01/10/2013 16:26, Eric Nelson wrote: I'm not sure where you're seeing this in the RM, but in order to read the pad state when not configured as an input, the SION bit needs to be set in the pad mux register on i.MX51/53. I have checked inside the 37.3.2.2 GPIO Write for i.MX53 and 35.4.2.1 Read Value from Pad for i:MX51, I have not read anything about SION. If someone has found where it is described, please mail ! That documentation seems to imply that there's no dependency (i.e. there's no reference to SION), but I think that's an omission. Ok - this is surely not the first time we find errors in the documentation. I've tested this many times, since it's a really handy way of debugging hardware setups. That said, I'm not sure that there's a huge difference between a single patch or multiple patches for each arch unless there's some functionality dependent on being able to read the actual value of a pin configured as a GPIO output. Ok - then I tend to apply Otavio's patch, and we will fix for the other i.MXes if we really find the same issues. Did I miss something in this thread that does actually require that ability? It seems a pretty obscure thing in the normal case to drive an output without confidence that it will succeed. Yes, it seems quite strange, but it helps to debug the hardware. It is not the first time we see that, even driving the output, the signal does not go to the expected value, due for example to a conflict (another peripheral driving the signal) or to a wrong pull up resistor. As U-Boot is a great tool for hardware debugging, reading the signal back let check that the output is set to the desired value. Best regards, Stefano -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mx6: Add IOMUX_CONFIG_SION flag to all GPIO pins
Hi Stefano, On 10/01/2013 09:10 AM, Stefano Babic wrote: Hi Eric, On 01/10/2013 17:56, Eric Nelson wrote: Hi Stefano, On 10/01/2013 07:49 AM, Stefano Babic wrote: Hi Eric, On 01/10/2013 16:26, Eric Nelson wrote: I'm not sure where you're seeing this in the RM, but in order to read the pad state when not configured as an input, the SION bit needs to be set in the pad mux register on i.MX51/53. I have checked inside the 37.3.2.2 GPIO Write for i.MX53 and 35.4.2.1 Read Value from Pad for i:MX51, I have not read anything about SION. If someone has found where it is described, please mail ! That documentation seems to imply that there's no dependency (i.e. there's no reference to SION), but I think that's an omission. Ok - this is surely not the first time we find errors in the documentation. I've tested this many times, since it's a really handy way of debugging hardware setups. That said, I'm not sure that there's a huge difference between a single patch or multiple patches for each arch unless there's some functionality dependent on being able to read the actual value of a pin configured as a GPIO output. Ok - then I tend to apply Otavio's patch, and we will fix for the other i.MXes if we really find the same issues. Did I miss something in this thread that does actually require that ability? It seems a pretty obscure thing in the normal case to drive an output without confidence that it will succeed. Yes, it seems quite strange, but it helps to debug the hardware. It is not the first time we see that, even driving the output, the signal does not go to the expected value, due for example to a conflict (another peripheral driving the signal) or to a wrong pull up resistor. As U-Boot is a great tool for hardware debugging, reading the signal back let check that the output is set to the desired value. I agree with all of that, though this only covers the case of a pin set up as a GPIO output, and that same debugging approach is often used for other functions (display data pins, clock inputs and outputs, et cetera). You probably wouldn't just set SION on all pins, right? I suspect that there'd be some ramification in terms of power consumption if nothing else. Regards, Eric ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mx6: Add IOMUX_CONFIG_SION flag to all GPIO pins
Hi Eric, On Tuesday, October 1, 2013 4:26:32 PM, Eric Nelson wrote: Hi Stefano, On 10/01/2013 06:13 AM, Stefano Babic wrote: Hi Otavio, On 01/10/2013 14:01, Otavio Salvador wrote: I suggest you add in the commit message that this patch is only for i.MX6 (if you do not plan to extend it to the other i.MXes...), so that we can track that the same must be done also for the other SOCs. I think this is clear from the commit prefix. Sorry, you're right, it is fine. I am under heavy load now and I cannot check their datasheet to verify if they all need this or not. If someone does not does it, I can take a look for sure. I look at MX51 / MX53 manuals. They are different as i.MX6, and in both cases I do not read the requirement to set the SION bit, as the i.MX6 needs. The fix is then only for i.MX6, and we do not need to extend it, at least according to documentation. After this check, I think that your patch is complete and I will push it for the release. I'm not sure where you're seeing this in the RM, but in order to read the pad state when not configured as an input, the SION bit needs to be set in the pad mux register on i.MX51/53. FWIW, this also works when not muxed as a GPIO, which is really handy for verifying that a PWM is toggling, et cetera. I have just tested that on i.MX51 and i.MX35, and I confirm that GPIO.PSR does not report the correct pin level in GPIO output mode if SION is not set. The i.MX25 is also very close to the i.MX35 in terms of IPs, so it would probably also give the same results. So SION seems to be required in that case on all i.MXes, even if not all RMs mention this in the GPIO chapter. Best regards, Benoît ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] uboot panic in get_ticks
+mailing list
Hi Aviral,
On Thu, Sep 26, 2013 at 1:20 PM, Pandey, Aviral
aviral.pan...@arrisi.com wrote:
Hi Simon,
First, I would like to apologize if I am not supposed to contact you
directly about one of your changes in uboot for x86. I am using
coreboot/uboot on an Intel Cavecreek based board and really appreciate the
work you and others are doing to support coreboot with uboot.
The code I am having trouble with is in arch/x86/lib/tsc_timer.c:
u64 __attribute__((no_instrument_function)) get_ticks(void)
{
u64 now_tick = rdtsc();
/* We assume that 0 means the base hasn't been set yet */
if (!gd-arch.tsc_base)
panic(No tick base available);
return now_tick - gd-arch.tsc_base;
}
I understand that the coreboot should have supplied the tsc_base in “struct
timestamp_table” in CB_TAG_TIMESTAMPS. But the coreboot code, if not
compiled with CONFIG_COLLECT_TIMESTAMPS does not really initialize/supply
this table. I was wondering if we could simply supply a dummy base
timestamp, or not panic the uboot in the highlighted line above so that a
mismatched configuration can still boot? Or may be I am missing something?
Yes I think it would be OK to change that, but would be it be better
to update the message to tell you to define that CONFIG in Coreboot?
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] am335x: Enable CONFIG_OMAP_WATCHDOG support
There is a board-specific portion for calling watchdog enable itself, in main U-Boot. Signed-off-by: Tom Rini tr...@ti.com --- arch/arm/cpu/armv7/omap-common/boot-common.c |4 board/ti/am335x/board.c |5 + include/configs/ti_am335x_common.h |7 +++ 3 files changed, 16 insertions(+) diff --git a/arch/arm/cpu/armv7/omap-common/boot-common.c b/arch/arm/cpu/armv7/omap-common/boot-common.c index 6b4772b..1880e04 100644 --- a/arch/arm/cpu/armv7/omap-common/boot-common.c +++ b/arch/arm/cpu/armv7/omap-common/boot-common.c @@ -14,6 +14,7 @@ #include asm/arch/omap.h #include asm/arch/mmc_host_def.h #include asm/arch/sys_proto.h +#include watchdog.h DECLARE_GLOBAL_DATA_PTR; @@ -76,6 +77,9 @@ void spl_board_init(void) #if defined(CONFIG_AM33XX) defined(CONFIG_SPL_MUSB_NEW_SUPPORT) arch_misc_init(); #endif +#if defined(CONFIG_HW_WATCHDOG) + hw_watchdog_init(); +#endif } int board_mmc_init(bd_t *bis) diff --git a/board/ti/am335x/board.c b/board/ti/am335x/board.c index 0d6912b..0986646 100644 --- a/board/ti/am335x/board.c +++ b/board/ti/am335x/board.c @@ -27,6 +27,7 @@ #include miiphy.h #include cpsw.h #include environment.h +#include watchdog.h #include board.h DECLARE_GLOBAL_DATA_PTR; @@ -354,6 +355,10 @@ int board_init(void) STNOR_GPMC_CONFIG5, STNOR_GPMC_CONFIG6, STNOR_GPMC_CONFIG7 }; #endif +#if defined(CONFIG_HW_WATCHDOG) + hw_watchdog_init(); +#endif + gd-bd-bi_boot_params = CONFIG_SYS_SDRAM_BASE + 0x100; gpmc_init(); diff --git a/include/configs/ti_am335x_common.h b/include/configs/ti_am335x_common.h index 59c758c..28e7a80 100644 --- a/include/configs/ti_am335x_common.h +++ b/include/configs/ti_am335x_common.h @@ -43,6 +43,10 @@ #define CONFIG_SPL_BOOTCOUNT_LIMIT #define CONFIG_SYS_BOOTCOUNT_ADDR 0x44E3E000 +/* Enable the HW watchdog, since we can use this with bootcount */ +#define CONFIG_HW_WATCHDOG +#define CONFIG_OMAP_WATCHDOG + /* * SPL related defines. The Public RAM memory map the ROM defines the * area between 0x402F0400 and 0x4030B800 as a download area and @@ -53,6 +57,9 @@ #define CONFIG_SPL_TEXT_BASE 0x402F0400 #define CONFIG_SPL_MAX_SIZE(0x4030B800 - CONFIG_SPL_TEXT_BASE) +/* Enable the watchdog inside of SPL */ +#define CONFIG_SPL_WATCHDOG_SUPPORT + /* * Since SPL did pll and ddr initialization for us, * we don't need to do it twice. -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mmc: sdhci: Avoid commands errors by simple timeout adaptation.
Hello Pantelis,
Thank you for reply
On 10/01/2013 05:50 PM, Pantelis Antoniou wrote:
while (sdhci_readl(host, SDHCI_PRESENT_STATE) mask) {
-if (timeout == 0) {
+if (time == cmd_timeout) {
time = cmd_timeout here.
You rely on the timeout hitting exactly the same value which is not
guaranteed.
I think this condition is guaranteed here, because of time value that
is incremented only inside the loop.
Also if meets (time == cmd_timeout) condition and next if timeout will
be increased twice, then eg. if current timeout
is 100ms - next will be 200 ms, so it needs 100 loops and no more.
Am I wrong?
Regards
--
Przemyslaw Marczak
Samsung RD Institute Poland
Samsung Electronics
p.marc...@samsung.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/2] Tegra114: Do not program CPCON field for PLLX
Thierry,
Your 3 patches (Avionics maintainer change, as well as the 2-part T114
MNP/CPCON changes) have been applied to u-boot-tegra/next, built, and
tested on Dalmore.
New code (rebased against ARM/master) is available in both
u-boot-tegra/next and /master, in anticipation of a pull request to
u-boot-arm/master RSN.
Thanks,
Tom
On Tue, Oct 1, 2013 at 8:06 AM, Thierry Reding thierry.red...@gmail.comwrote:
On Mon, Sep 30, 2013 at 02:25:57PM -0700, Tom Warren wrote:
Thierry,
-Original Message-
From: Thierry Reding [mailto:thierry.red...@gmail.com]
Sent: Monday, September 23, 2013 1:08 PM
To: Tom Warren
Cc: u-boot@lists.denx.de
Subject: [PATCH v2 2/2] Tegra114: Do not program CPCON field for PLLX
PLLX no longer has the CPCON field on Tegra114, so do not attempt to
program it.
Signed-off-by: Thierry Reding tred...@nvidia.com
---
Changes in v2:
- new patch
arch/arm/cpu/arm720t/tegra-common/cpu.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/arm/cpu/arm720t/tegra-common/cpu.c
b/arch/arm/cpu/arm720t/tegra-common/cpu.c
index aa1e04f..5ab2ebf 100644
--- a/arch/arm/cpu/arm720t/tegra-common/cpu.c
+++ b/arch/arm/cpu/arm720t/tegra-common/cpu.c
@@ -135,6 +135,7 @@ void adjust_pllp_out_freqs(void) int
pllx_set_rate(struct clk_pll_simple *pll , u32 divn, u32 divm,
u32 divp, u32 cpcon)
{
+ int chip = tegra_get_chip();
u32 reg;
/* If PLLX is already enabled, just return */ @@ -151,7 +152,8 @@
int
pllx_set_rate(struct clk_pll_simple *pll , u32 divn, u32 divm,
writel(reg, pll-pll_base);
/* Set cpcon to PLLX_MISC */
- reg = (cpcon PLL_CPCON_SHIFT);
+ if (chip == CHIPID_TEGRA20 || chip == CHIPID_TEGRA30)
+ reg = (cpcon PLL_CPCON_SHIFT);
If it's not a T20/T30, reg is still set to the PLLX_BASE setting from
above. It'll then be written to PLLX_MISC w/bad bits below.
You need to set a default, or read pllx_misc first.
Ugh... you're right of course. Sent a v3 with reg = 0 in the else
branch.
Thanks,
Thierry
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/2] mmc: Fix capacity calculation and erase_group_size
These patches are addressing two issues that I had after activating enhanced user area feature for a 4GB card so the capacity was less than 2 GB afterwards. 1. The capacity for a high density device is calculated in a wrong way. I was not able to find any hints for this implementation in JEDEC 4.41. Anyhow, if we have ext_csd revision = 2 we can use SEC_COUNT field to calculate the size. 2. If we have a partitioned device, e.g. enhanced user area, the ERASE_GROUP_DEF bit in ext_csd shall be set (see JEDEC 4.41, chapter 7.2.3 Configure partitions). This bit defaults to 0 on power on. Oliver Metz (2): When using a high capacity card with a density less than 2 GB a wrong size is shown. According to JEDEC 4.41 there is no differentiation for C_SIZE register between low and high capacity cards EXT_CSD_ERASE_GROUP_DEF is lost every time after a reset or reboot. Set it if device has enhanced partitions. drivers/mmc/mmc.c | 49 +++-- include/mmc.h | 2 ++ 2 files changed, 25 insertions(+), 26 deletions(-) -- 1.8.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/2] mmc: Fix erase_grp_size for partitioned card
EXT_CSD_ERASE_GROUP_DEF is lost every time after a reset or
power off. Set it if device has enhanced partitions.
Signed-off-by: Oliver Metz oli...@freetz.org
---
drivers/mmc/mmc.c | 17 +
include/mmc.h | 2 ++
2 files changed, 15 insertions(+), 4 deletions(-)
diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
index ff11ff9..17c6b11 100644
--- a/drivers/mmc/mmc.c
+++ b/drivers/mmc/mmc.c
@@ -948,15 +948,24 @@ static int mmc_startup(struct mmc *mmc)
}
/*
-* Check whether GROUP_DEF is set, if yes, read out
-* group size from ext_csd directly, or calculate
-* the group size from the csd value.
+* Host needs to enable ERASE_GRP_DEF bit if device is
+* partitioned. This bit will be lost every time after a reset
+* or power off. This will affect erase size.
*/
- if (ext_csd[EXT_CSD_ERASE_GROUP_DEF]) {
+ if ((ext_csd[EXT_CSD_PARTITIONING_SUPPORT] PART_SUPPORT)
+ (ext_csd[EXT_CSD_PARTITIONS_ATTRIBUTE] PART_ENH_ATTRIB)) {
+ err = mmc_switch(mmc, EXT_CSD_CMD_SET_NORMAL,
+ EXT_CSD_ERASE_GROUP_DEF, 1);
+
+ if (err)
+ return err;
+
+ /* Read out group size from ext_csd */
mmc-erase_grp_size =
ext_csd[EXT_CSD_HC_ERASE_GRP_SIZE] *
MMC_MAX_BLOCK_LEN * 1024;
} else {
+ /* Calculate the group size from the csd value. */
int erase_gsz, erase_gmul;
erase_gsz = (mmc-csd[2] 0x7c00) 10;
erase_gmul = (mmc-csd[2] 0x03e0) 5;
diff --git a/include/mmc.h b/include/mmc.h
index 214b9ed..cb558da 100644
--- a/include/mmc.h
+++ b/include/mmc.h
@@ -148,6 +148,7 @@
* EXT_CSD fields
*/
#define EXT_CSD_GP_SIZE_MULT 143 /* R/W */
+#define EXT_CSD_PARTITIONS_ATTRIBUTE 156 /* R/W */
#define EXT_CSD_PARTITIONING_SUPPORT 160 /* RO */
#define EXT_CSD_RPMB_MULT 168 /* RO */
#define EXT_CSD_ERASE_GROUP_DEF175 /* R/W */
@@ -210,6 +211,7 @@
#define MMCPART_NOAVAILABLE(0xff)
#define PART_ACCESS_MASK (0x7)
#define PART_SUPPORT (0x1)
+#define PART_ENH_ATTRIB(0x1f)
/* Maximum block size for MMC */
#define MMC_MAX_BLOCK_LEN 512
--
1.8.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/2] mmc: Fix calculation of capacity for hc cards
When using a high capacity card with a density less than
2 GB a wrong size is calculated. According to JEDEC 4.41 there is no
differentiation for C_SIZE register between low and high capacity cards.
Use ext_csd sector count to calculate capacity instead.
Signed-off-by: Oliver Metz oli...@freetz.org
---
drivers/mmc/mmc.c | 20
1 file changed, 4 insertions(+), 16 deletions(-)
diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
index 84dae4d..ff11ff9 100644
--- a/drivers/mmc/mmc.c
+++ b/drivers/mmc/mmc.c
@@ -884,15 +884,9 @@ static int mmc_startup(struct mmc *mmc)
else
mmc-write_bl_len = 1 ((cmd.response[3] 22) 0xf);
- if (mmc-high_capacity) {
- csize = (mmc-csd[1] 0x3f) 16
- | (mmc-csd[2] 0x) 16;
- cmult = 8;
- } else {
- csize = (mmc-csd[1] 0x3ff) 2
- | (mmc-csd[2] 0xc000) 30;
- cmult = (mmc-csd[2] 0x00038000) 15;
- }
+ csize = (mmc-csd[1] 0x3ff) 2
+ | (mmc-csd[2] 0xc000) 30;
+ cmult = (mmc-csd[2] 0x00038000) 15;
mmc-capacity_user = (csize + 1) (cmult + 2);
mmc-capacity_user *= mmc-read_bl_len;
@@ -927,18 +921,12 @@ static int mmc_startup(struct mmc *mmc)
/* check ext_csd version and capacity */
err = mmc_send_ext_csd(mmc, ext_csd);
if (!err (ext_csd[EXT_CSD_REV] = 2)) {
- /*
-* According to the JEDEC Standard, the value of
-* ext_csd's capacity is valid if the value is more
-* than 2GB
-*/
capacity = ext_csd[EXT_CSD_SEC_CNT] 0
| ext_csd[EXT_CSD_SEC_CNT + 1] 8
| ext_csd[EXT_CSD_SEC_CNT + 2] 16
| ext_csd[EXT_CSD_SEC_CNT + 3] 24;
capacity *= MMC_MAX_BLOCK_LEN;
- if ((capacity 20) 2 * 1024)
- mmc-capacity_user = capacity;
+ mmc-capacity_user = capacity;
}
switch (ext_csd[EXT_CSD_REV]) {
--
1.8.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4] socfpga: Adding Freeze Controller driver
Hi guys,
Any further comments on this? Thanks
Chin Liang
On Tue, 2013-09-24 at 09:49 -0500, Chin Liang See wrote:
Adding Freeze Controller driver. All HPS IOs need to be
in freeze state during pin mux or IO buffer configuration.
It is to avoid any glitch which might happen
during the configuration from propagating to external devices.
Signed-off-by: Chin Liang See cl...@altera.com
Cc: Wolfgang Denk w...@denx.de
CC: Pavel Machek pa...@denx.de
Cc: Dinh Nguyen dingu...@altera.com
---
Changes for v4
- Removed additional lines
- Single function call to freeze and thaw all channels
Changes for v3
- Removed unused macro in freeze_controller.h
Changes for v2
- Removed FREEZE_CONTROLLER_FSM_HW
- Removed the get_timer_count_masked and convert to use delay in us
- Used shorter local variables
---
arch/arm/cpu/armv7/socfpga/Makefile|2 +-
arch/arm/cpu/armv7/socfpga/freeze_controller.c | 216
arch/arm/cpu/armv7/socfpga/spl.c |9 +
.../include/asm/arch-socfpga/freeze_controller.h | 50 +
4 files changed, 276 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/cpu/armv7/socfpga/freeze_controller.c
create mode 100644 arch/arm/include/asm/arch-socfpga/freeze_controller.h
diff --git a/arch/arm/cpu/armv7/socfpga/Makefile
b/arch/arm/cpu/armv7/socfpga/Makefile
index 0859e44..10d20f2 100644
--- a/arch/arm/cpu/armv7/socfpga/Makefile
+++ b/arch/arm/cpu/armv7/socfpga/Makefile
@@ -14,7 +14,7 @@ LIB = $(obj)lib$(SOC).o
SOBJS:= lowlevel_init.o
COBJS-y := misc.o timer.o reset_manager.o system_manager.o
-COBJS-$(CONFIG_SPL_BUILD) += spl.o
+COBJS-$(CONFIG_SPL_BUILD) += spl.o freeze_controller.o
COBJS:= $(COBJS-y)
SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c)
diff --git a/arch/arm/cpu/armv7/socfpga/freeze_controller.c
b/arch/arm/cpu/armv7/socfpga/freeze_controller.c
new file mode 100644
index 000..330b4aa
--- /dev/null
+++ b/arch/arm/cpu/armv7/socfpga/freeze_controller.c
@@ -0,0 +1,216 @@
+/*
+ * Copyright (C) 2013 Altera Corporation www.altera.com
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ */
+
+
+#include common.h
+#include asm/io.h
+#include asm/arch/freeze_controller.h
+#include asm/arch/timer.h
+#include asm/errno.h
+
+DECLARE_GLOBAL_DATA_PTR;
+
+static const struct socfpga_freeze_controller *freeze_controller_base =
+ (void *)(SOCFPGA_SYSMGR_ADDRESS + SYSMGR_FRZCTRL_ADDRESS);
+
+/*
+ * Default state from cold reset is FREEZE_ALL; the global
+ * flag is set to TRUE to indicate the IO banks are frozen
+ */
+static uint32_t frzctrl_channel_freeze[FREEZE_CHANNEL_NUM]
+ = { FREEZE_CTRL_FROZEN, FREEZE_CTRL_FROZEN,
+ FREEZE_CTRL_FROZEN, FREEZE_CTRL_FROZEN};
+
+/* Freeze HPS IOs */
+void sys_mgr_frzctrl_freeze_req(void)
+{
+ u32 ioctrl_reg_offset;
+ u32 reg_value;
+ u32 reg_cfg_mask;
+ u32 channel_id;
+
+ /* select software FSM */
+ writel(SYSMGR_FRZCTRL_SRC_VIO1_ENUM_SW, freeze_controller_base-src);
+
+ /* Freeze channel 0 to 2 */
+ for (channel_id = 0; channel_id = 2; channel_id++) {
+ ioctrl_reg_offset = (u32)(
+ freeze_controller_base-vioctrl +
+ (channel_id SYSMGR_FRZCTRL_VIOCTRL_SHIFT));
+
+ /*
+ * Assert active low enrnsl, plniotri
+ * and niotri signals
+ */
+ reg_cfg_mask =
+ SYSMGR_FRZCTRL_VIOCTRL_SLEW_MASK
+ | SYSMGR_FRZCTRL_VIOCTRL_WKPULLUP_MASK
+ | SYSMGR_FRZCTRL_VIOCTRL_TRISTATE_MASK;
+ clrbits_le32(ioctrl_reg_offset, reg_cfg_mask);
+
+ /*
+ * Note: Delay for 20ns at min
+ * Assert active low bhniotri signal and de-assert
+ * active high csrdone
+ */
+ reg_cfg_mask
+ = SYSMGR_FRZCTRL_VIOCTRL_BUSHOLD_MASK
+ | SYSMGR_FRZCTRL_VIOCTRL_CFG_MASK;
+ clrbits_le32(ioctrl_reg_offset, reg_cfg_mask);
+
+ /* Set global flag to indicate channel is frozen */
+ frzctrl_channel_freeze[channel_id] = FREEZE_CTRL_FROZEN;
+ }
+
+ /* Freeze channel 3 */
+ /*
+ * Assert active low enrnsl, plniotri and
+ * niotri signals
+ */
+ reg_cfg_mask
+ = SYSMGR_FRZCTRL_HIOCTRL_SLEW_MASK
+ | SYSMGR_FRZCTRL_HIOCTRL_WKPULLUP_MASK
+ | SYSMGR_FRZCTRL_HIOCTRL_TRISTATE_MASK;
+ clrbits_le32(freeze_controller_base-hioctrl, reg_cfg_mask);
+
+ /*
+ * assert active low bhniotri nfrzdrv signals,
+ * de-assert active high csrdone and assert
+ * active high frzreg and nfrzdrv signals
+ */
+ reg_value = readl(freeze_controller_base-hioctrl);
+ reg_cfg_mask
+ = SYSMGR_FRZCTRL_HIOCTRL_BUSHOLD_MASK
+ |
Re: [U-Boot] [PATCH 7/9] net: tsec: Use portable types and accessors for BDs
On Tue, 2013-10-01 at 14:38 +0300, Claudiu Manoil wrote:
On 10/1/2013 2:22 AM, Scott Wood wrote:
On Mon, 2013-09-30 at 12:44 +0300, Claudiu Manoil wrote:
+static RTXBD rtx __aligned(8);
+#define RXBD(i) rtx.rxbd[i]
+#define TXBD(i) rtx.txbd[i]
+#define GET_BD_STAT(T, i) be16_to_cpu((__force __be16)T##BD(i).status)
+#define SET_BD_STAT(T, i, v) T##BD(i).status = (__force
__u16)cpu_to_be16(v)
+#define GET_BD_BLEN(T, i) be16_to_cpu((__force __be16)T##BD(i).length)
+#define SET_BD_BLEN(T, i, v) T##BD(i).length = (__force
__u16)cpu_to_be16(v)
+#define GET_BD_BPTR(T, i) be32_to_cpu((__force __be32)T##BD(i).bufptr)
+#define SET_BD_BPTR(T, i, v) T##BD(i).bufptr = (__force
__u32)cpu_to_be32(v)
Why the forcing? Can't you declare the data with __be16/__be32?
The __force annotation is obviously needed to suppress the sparse
warnings due to BD data declaration type not being __bexx, but the
generic uintxx_t, as you noticed as well.
Now, why I didn't use __bexx instead? The main reason would be
maintainability: the DMA descriptors may not be in big endian format
exclusively. The eTSEC hw may actually have an option to interpret
the DMA descriptors in little endian format.
May have or does have?
If it does have such a feature, do you plan to use it? Usually I have
not seen such features used for (e.g.) little-endian PCI devices on big
endian hosts.
What's wrong with:
for (t = 0; in_be16(rtx.rxbd[rx_idx].status) RXBD_EMPTY; t++) {
Or if you don't want to use I/O accessors on the DMA descriptors (Is
synchronization ensured some other way? We had problems with this in
the Linux driver before...):
Synchronization here is is insured by declaring the RTXBD structure
type as volatile (see RTXBD declaration, a couple of lines above).
That does not achieve hardware synchronization, and even the effects on
the compiler are questionable due to volatile's vague semantics.
The existing code has been working this way for quite a while on the
mpc85xx platforms,
It was working for a while in Linux as well, until we encountered a
workload where it didn't (though granted, there was no volatile in that
case). See Linux commit 3b6330ce2a3e1f152f79a6203f73d23356e243a7
FWIW, I see some other places in U-Boot's TSEC driver that use
out_be32() on the descriptors (e.g. startup_tsec after Point to the
buffer descriptors).
so I thought it would be better not to change this
approach. Using i/o accessors for the Buffer Descriptors would be a
significant change, and I don't see how to argue such a change: why
would the I/O accessors be better than the current approach - i.e.
declaring the DMA descriptors as volatile? Is there something wrong
with about volatile usage in this case? (afaik, this is a case were
the volatile declaration is permitted)
Also, there doesn't seem to be other net drivers using I/O accessors
for the BD rings.
I picked some random examples, and the first driver in Linux in which I
could quickly find the BD rings uses I/O accessors
(drivers/net/ethernet/realtek/8319too.c). I then checked its U-Boot
eqivalent (drivers/net/rtl8139.c) and it also uses I/O accessors for the
descriptors.
for (t = 0; be16_to_cpup(rtx.rxbd[rx_idx].status) RXBD_EMPTY; t++) {
I opted for using macros instead due to code maintainability,
Obfuscatory macros do not help.
and to avoid overly long lines (80)
You could factor out an rxbd_empty() function, or factor that loop out
to be its own function, or have a local variable point to
rtx.rxbd[rx_idx]...
and to better control these changes.
For instance, if etsec were to access it's BDs in little endian format
in the future,
Either don't do that (preferred option), or at that point add
tsec16_to_cpup() and friends.
-Scott
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mx6: Add IOMUX_CONFIG_SION flag to all GPIO pins
Hi Eric, On Tuesday, October 1, 2013 6:17:06 PM, Eric Nelson wrote: Hi Stefano, On 10/01/2013 09:10 AM, Stefano Babic wrote: Hi Eric, On 01/10/2013 17:56, Eric Nelson wrote: Hi Stefano, On 10/01/2013 07:49 AM, Stefano Babic wrote: Hi Eric, On 01/10/2013 16:26, Eric Nelson wrote: I'm not sure where you're seeing this in the RM, but in order to read the pad state when not configured as an input, the SION bit needs to be set in the pad mux register on i.MX51/53. I have checked inside the 37.3.2.2 GPIO Write for i.MX53 and 35.4.2.1 Read Value from Pad for i:MX51, I have not read anything about SION. If someone has found where it is described, please mail ! That documentation seems to imply that there's no dependency (i.e. there's no reference to SION), but I think that's an omission. Ok - this is surely not the first time we find errors in the documentation. I've tested this many times, since it's a really handy way of debugging hardware setups. That said, I'm not sure that there's a huge difference between a single patch or multiple patches for each arch unless there's some functionality dependent on being able to read the actual value of a pin configured as a GPIO output. Ok - then I tend to apply Otavio's patch, and we will fix for the other i.MXes if we really find the same issues. Did I miss something in this thread that does actually require that ability? It seems a pretty obscure thing in the normal case to drive an output without confidence that it will succeed. Yes, it seems quite strange, but it helps to debug the hardware. It is not the first time we see that, even driving the output, the signal does not go to the expected value, due for example to a conflict (another peripheral driving the signal) or to a wrong pull up resistor. As U-Boot is a great tool for hardware debugging, reading the signal back let check that the output is set to the desired value. I agree with all of that, though this only covers the case of a pin set up as a GPIO output, and that same debugging approach is often used for other functions (display data pins, clock inputs and outputs, et cetera). You probably wouldn't just set SION on all pins, right? I suspect that there'd be some ramification in terms of power consumption if nothing else. Right. Well, instead of adding SION to the pin definition header files, then we could just add SION where needed on a per-pin basis, e.g.: --- imx_iomux_v3_setup_pad(MX6_PAD_NANDF_D1__GPIO_2_1 | IOMUX_CONFIG_SION MUX_MODE_SHIFT); --- A helper macro could be defined in arch/arm/include/asm/imx-common/iomux-v3.h in order to simplify the writing, e.g.: --- #define MUX_MODE_SION (IOMUX_CONFIG_SION MUX_MODE_SHIFT) --- imx_iomux_v3_setup_pad(MX6_PAD_NANDF_D1__GPIO_2_1 | MUX_MODE_SION); --- On the Linux side of things, the CONFIG field in the pinctrl DT bindings already provides bit 30 for SION. Hence, using MUX_MODE_SION like above would be close to Linux's pin config. Best regards, Benoît ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mx6: Add IOMUX_CONFIG_SION flag to all GPIO pins
On Tue, Oct 1, 2013 at 4:50 PM, Benoît Thébaudeau benoit.thebaud...@advansee.com wrote: Hi Eric, On Tuesday, October 1, 2013 6:17:06 PM, Eric Nelson wrote: Hi Stefano, On 10/01/2013 09:10 AM, Stefano Babic wrote: Hi Eric, On 01/10/2013 17:56, Eric Nelson wrote: Hi Stefano, On 10/01/2013 07:49 AM, Stefano Babic wrote: Hi Eric, On 01/10/2013 16:26, Eric Nelson wrote: I'm not sure where you're seeing this in the RM, but in order to read the pad state when not configured as an input, the SION bit needs to be set in the pad mux register on i.MX51/53. I have checked inside the 37.3.2.2 GPIO Write for i.MX53 and 35.4.2.1 Read Value from Pad for i:MX51, I have not read anything about SION. If someone has found where it is described, please mail ! That documentation seems to imply that there's no dependency (i.e. there's no reference to SION), but I think that's an omission. Ok - this is surely not the first time we find errors in the documentation. I've tested this many times, since it's a really handy way of debugging hardware setups. That said, I'm not sure that there's a huge difference between a single patch or multiple patches for each arch unless there's some functionality dependent on being able to read the actual value of a pin configured as a GPIO output. Ok - then I tend to apply Otavio's patch, and we will fix for the other i.MXes if we really find the same issues. Did I miss something in this thread that does actually require that ability? It seems a pretty obscure thing in the normal case to drive an output without confidence that it will succeed. Yes, it seems quite strange, but it helps to debug the hardware. It is not the first time we see that, even driving the output, the signal does not go to the expected value, due for example to a conflict (another peripheral driving the signal) or to a wrong pull up resistor. As U-Boot is a great tool for hardware debugging, reading the signal back let check that the output is set to the desired value. I agree with all of that, though this only covers the case of a pin set up as a GPIO output, and that same debugging approach is often used for other functions (display data pins, clock inputs and outputs, et cetera). You probably wouldn't just set SION on all pins, right? I suspect that there'd be some ramification in terms of power consumption if nothing else. Right. Well, instead of adding SION to the pin definition header files, then we could just add SION where needed on a per-pin basis, e.g.: --- imx_iomux_v3_setup_pad(MX6_PAD_NANDF_D1__GPIO_2_1 | IOMUX_CONFIG_SION MUX_MODE_SHIFT); --- A helper macro could be defined in arch/arm/include/asm/imx-common/iomux-v3.h in order to simplify the writing, e.g.: --- #define MUX_MODE_SION (IOMUX_CONFIG_SION MUX_MODE_SHIFT) --- imx_iomux_v3_setup_pad(MX6_PAD_NANDF_D1__GPIO_2_1 | MUX_MODE_SION); --- On the Linux side of things, the CONFIG field in the pinctrl DT bindings already provides bit 30 for SION. Hence, using MUX_MODE_SION like above would be close to Linux's pin config. Thus dropping my patch, right? Or do you think for GPIO we ought to have them? -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mx6: Add IOMUX_CONFIG_SION flag to all GPIO pins
Hi Otavio, On Tuesday, October 1, 2013 10:01:57 PM, Otavio Salvador wrote: Subject: Re: [U-Boot] [PATCH] mx6: Add IOMUX_CONFIG_SION flag to all GPIO pins On Tue, Oct 1, 2013 at 4:50 PM, Benoît Thébaudeau benoit.thebaud...@advansee.com wrote: Hi Eric, On Tuesday, October 1, 2013 6:17:06 PM, Eric Nelson wrote: Hi Stefano, On 10/01/2013 09:10 AM, Stefano Babic wrote: Hi Eric, On 01/10/2013 17:56, Eric Nelson wrote: Hi Stefano, On 10/01/2013 07:49 AM, Stefano Babic wrote: Hi Eric, On 01/10/2013 16:26, Eric Nelson wrote: I'm not sure where you're seeing this in the RM, but in order to read the pad state when not configured as an input, the SION bit needs to be set in the pad mux register on i.MX51/53. I have checked inside the 37.3.2.2 GPIO Write for i.MX53 and 35.4.2.1 Read Value from Pad for i:MX51, I have not read anything about SION. If someone has found where it is described, please mail ! That documentation seems to imply that there's no dependency (i.e. there's no reference to SION), but I think that's an omission. Ok - this is surely not the first time we find errors in the documentation. I've tested this many times, since it's a really handy way of debugging hardware setups. That said, I'm not sure that there's a huge difference between a single patch or multiple patches for each arch unless there's some functionality dependent on being able to read the actual value of a pin configured as a GPIO output. Ok - then I tend to apply Otavio's patch, and we will fix for the other i.MXes if we really find the same issues. Did I miss something in this thread that does actually require that ability? It seems a pretty obscure thing in the normal case to drive an output without confidence that it will succeed. Yes, it seems quite strange, but it helps to debug the hardware. It is not the first time we see that, even driving the output, the signal does not go to the expected value, due for example to a conflict (another peripheral driving the signal) or to a wrong pull up resistor. As U-Boot is a great tool for hardware debugging, reading the signal back let check that the output is set to the desired value. I agree with all of that, though this only covers the case of a pin set up as a GPIO output, and that same debugging approach is often used for other functions (display data pins, clock inputs and outputs, et cetera). You probably wouldn't just set SION on all pins, right? I suspect that there'd be some ramification in terms of power consumption if nothing else. Right. Well, instead of adding SION to the pin definition header files, then we could just add SION where needed on a per-pin basis, e.g.: --- imx_iomux_v3_setup_pad(MX6_PAD_NANDF_D1__GPIO_2_1 | IOMUX_CONFIG_SION MUX_MODE_SHIFT); --- A helper macro could be defined in arch/arm/include/asm/imx-common/iomux-v3.h in order to simplify the writing, e.g.: --- #define MUX_MODE_SION (IOMUX_CONFIG_SION MUX_MODE_SHIFT) --- imx_iomux_v3_setup_pad(MX6_PAD_NANDF_D1__GPIO_2_1 | MUX_MODE_SION); --- On the Linux side of things, the CONFIG field in the pinctrl DT bindings already provides bit 30 for SION. Hence, using MUX_MODE_SION like above would be close to Linux's pin config. Thus dropping my patch, right? Yes, if everybody agrees. You could replace it with a patch adding MUX_MODE_SION to iomux-v3.h, and another patch adding MUX_MODE_SION to the configuration of your status LED pin mux on your board (if it is in mainline). Or do you think for GPIO we ought to have them? SION is not GPIO-specific, so no. Eric is right: SION may slightly increase the current consumption if it is set for too many pins, so it does not make sense to set it everywhere, and it may be needed for any pin, not just for GPIOs, so setting it either for all GPIOs or for all pins would not make sense. SION should be set only where strictly required. Since SION is a hardware configuration option, let's keep it a software configuration as well, just like in Linux. Best regards, Benoît ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mx6: Add IOMUX_CONFIG_SION flag to all GPIO pins
On Tue, Oct 1, 2013 at 5:21 PM, Benoît Thébaudeau benoit.thebaud...@advansee.com wrote: SION is not GPIO-specific, so no. Eric is right: SION may slightly increase the current consumption if it is set for too many pins, so it does not make sense to set it everywhere, and it may be needed for any pin, not just for GPIOs, so setting it either for all GPIOs or for all pins would not make sense. SION should be set only where strictly required. Since SION is a hardware configuration option, let's keep it a software configuration as well, just like in Linux. Yes, this seems a good aproach. Regards, Fabio Estevam ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 6/6] config: SMDK5420: Enable S2MPS1111111111111111111111 pmic
Hello, I'll change the typo error in the patch header in next version. /Leela krishna On Oct 1, 2013 8:11 PM, Leela Krishna Amudala l.kris...@samsung.com wrote: configure S2MPS11 pmic on SMDK5420 Signed-off-by: Leela Krishna Amudala l.kris...@samsung.com --- include/configs/smdk5420.h |4 1 file changed, 4 insertions(+) diff --git a/include/configs/smdk5420.h b/include/configs/smdk5420.h index 447f8e5..46aeec0 100644 --- a/include/configs/smdk5420.h +++ b/include/configs/smdk5420.h @@ -53,4 +53,8 @@ #define CONFIG_MAX_I2C_NUM 11 +#define CONFIG_POWER +#define CONFIG_POWER_I2C +#define CONFIG_POWER_S2MPS11 + #endif /* __CONFIG_5420_H */ -- 1.7.10.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 1/1] am33xx: add CONFIG_SYS_NAND_DEVICE_WIDTH to determine NAND device bus-width
On Sat, 2013-09-28 at 06:24 +, Gupta, Pekon wrote: From: Scott Wood [mailto:scottw...@freescale.com] On Fri, 2013-09-27 at 04:18 +, Gupta, Pekon wrote: Apart from SPL, CONFIG_SYS_NAND_DEVICE_WIDTH also be useful for (1) drivers which do not use CONFIG_SYS_NAND_ONFI_DETECTION, where code for reading on-chip ONFI parameters is not enabled in nand_base.c (2) non ONFI compatible NAND devices. Unlikely, given that they've all managed to work without this so far. E.g. eLBC and IFC hardcode this information on a per-chip basis in the #defines that hold values for config registers, and prior to this patch omap_gpmc had code to read a config register (regardless of where it originally got set). (1) drivers/mtd/nand/fsl_ifc_spl.c They are doing same way as OMAP used to. They are also using controller configurations to tell driver about the]NAND bus-width port_size = (cspr CSPR_PORT_SIZE_16) ? 16 : 8; Yes. Note that CSPR is set per-chip. (2) drivers/mtd/nand/fsl_elbc_spl.c They are doing incomplete check. Rather they are not caring for x16 device Right, I forgot that eLBC doesn't support 16-bit NAND (hardware limitation). So CONFIG_SYS_NAND_DEVICE_WIDTH should help them also. right ? How would it help? So can this new CONFIG_xx be accepted ? Only for SPL usage. It looked like you were removing the code that does dynamic detection, which would also affect non-SPL. -/* If we are 16 bit dev, our gpmc config tells us that */ -if ((readl(gpmc_cfg-cs[cs].config1) 0x3000) == 0x1000) omap_gpmc.c never had dynamic detection support. Above gpmc_config bit which is used to tell whether device is x16 or x8, gets actually hard-coded in gpmc_init(). Thus it was actually a mechanism to pass hard-coded bus- width information to nand driver. Refer: arch/arm/cpu/armv7/am33xx/mem.c : gpmc_init() So, instead of hacking the gpmc_init() everytime for different devices, this patch introduces a generic CONFIG which can be used everywhere. It looks like you do more NAND config in gpmc_init() than just setting this one bit, so I don't think you save anything here. BTW, do you not need to set this bit in the config register for the hardware to work in the SPL case? Yes, I'm not changing the default configs for GPMC in gpmc_init(), because they are ok for x8 device. I'm just overriding them again during board_nand_init() if CONFIG_SYS_NAND_DEVICE_WIDTH == x16 device. Is this due to wanting to do identification as x8? -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Dual boot Images in Flash
Dear pshambhu, In message 1380633558849-164443.p...@n7.nabble.com you wrote: Can i have a small uboot_stub in the reset entry table, which will boot initially, and while booting it should select the default booting location (u-boot1).But if the default booting location fails to boot up then u-boot_stub should select bootloader u-boot2. u-boot_stub will do CRC checksum on the u-boot1, if CRC checksum fails on that, then u-boot2 will be considered for bootup. That would be pretty straight-forward (and I'm even tempted to write: trivial) to implement. Just add the CRC checking and selecting part to SPL... Since its the software, i think it can be done and If it is possible, can you please tell me which are the files need to be taken care for the file changes. On the other hand, it does not really solve your problem - how do you fix problems or perform reliable updates of this small uboot_stub? I recommend to face the real situation: yes, you can implement all levels of complicated multi-stage boot procedures that promise to provide all kinds of features and reliability - but in the end you still have that small, central critical piece of code, and guess where the nasty bug will be found? Without hardware support (switching boot devices etc.) you cannot implement a 100% reliable solution. And if it's less than 100%, then what's the difference between 99.999% and 99% ? If things go wrong, your're stuck. And I bet Murphy is looking over your right shoulder right when you can't have 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 Imagination was given to man to compensate him for what he is not; a sence of humor to console him for what he is. - Fancis Bacon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Buildman changes for release
Hi Tom, I picked up these two - a fix plus a feature that came in after the merge window for the previous release but should go into this one. The following changes since commit 6b40852da5c8dd710f9d61204a3c6a3c9d22: Sound: MAX98095: Support I2S0 channel (2013-09-24 09:10:33 -0400) are available in the git repository at: ssh://gu-...@git.denx.de/u-boot-x86.git buildman for you to fetch changes up to 4281ad8e7fcb304724127281f258d198001fd41a: buildman: Allow make flags to be specified for each board (2013-10-01 14:39:14 -0600) Simon Glass (2): buildman: Adjust tests for new boards.cfg format buildman: Allow make flags to be specified for each board tools/buildman/README | 22 ++ tools/buildman/bsettings.py | 3 --- tools/buildman/builder.py | 1 + tools/buildman/buildman.py | 13 + tools/buildman/test.py | 10 +- tools/buildman/toolchain.py | 81 +++-- 6 files changed, 120 insertions(+), 10 deletions(-) Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] RFC: Adjustments to dumpimage for Guilherme
Here are some suggested changes after I tried using your tool. It's very
useful so I hope it can be merged.
1. Truncate the output file
2. Support uImage files that hold a single image
3. Allow specifying an output filename
Signed-off-by: Simon Glass s...@chromium.org
---
tools/default_image.c | 17 +
tools/dumpimage.c | 15 ++-
tools/imagetool.h | 1 +
3 files changed, 20 insertions(+), 13 deletions(-)
diff --git a/tools/default_image.c b/tools/default_image.c
index b0a0d40..9947aaf 100644
--- a/tools/default_image.c
+++ b/tools/default_image.c
@@ -121,9 +121,9 @@ static int image_save_datafile (struct image_tool_params
*params,
ulong file_data, ulong file_len)
{
int dfd;
- const char *datafile = params-datafile;
+ const char *datafile = params-outfile;
- dfd = open (datafile, O_RDWR|O_CREAT|O_BINARY, S_IRUSR|S_IWUSR);
+ dfd = open (datafile, O_RDWR|O_CREAT|O_TRUNC|O_BINARY, S_IRUSR|S_IWUSR);
if (dfd 0) {
fprintf (stderr, %s: Can't open \%s\: %s\n,
params-cmdname, datafile, strerror(errno));
@@ -145,12 +145,12 @@ static int image_save_datafile (struct image_tool_params
*params,
static int image_extract_datafile (void *ptr, struct image_tool_params *params)
{
const image_header_t *hdr = (const image_header_t *)ptr;
+ ulong file_data;
+ ulong file_len;
if (image_check_type (hdr, IH_TYPE_MULTI)) {
ulong idx = params-pflag;
ulong count;
- ulong file_data = 0;
- ulong file_len = 0;
/* get the number of data files present in the image */
count = image_multi_count (hdr);
@@ -163,12 +163,13 @@ static int image_extract_datafile (void *ptr, struct
image_tool_params *params)
params-cmdname, idx,
params-imagefile);
return -1;
}
-
- /* save the data file into the file system */
- return image_save_datafile (params, file_data, file_len);
+ } else {
+ file_data = image_get_data(hdr);
+ file_len = image_get_size(hdr);
}
- return -1;
+ /* save the data file into the file system */
+ return image_save_datafile(params, file_data, file_len);
}
/*
diff --git a/tools/dumpimage.c b/tools/dumpimage.c
index cb5cb44..c08e398 100644
--- a/tools/dumpimage.c
+++ b/tools/dumpimage.c
@@ -192,6 +192,11 @@ main (int argc, char **argv)
params.imagefile = *(++argv);
params.iflag = 1;
goto NXTARG;
+ case 'o':
+ if (--argc = 0)
+ usage ();
+ params.outfile = *++argv;
+ goto NXTARG;
case 'p':
if (--argc = 0)
usage ();
@@ -232,12 +237,12 @@ NXTARG: ;
if (tparams-check_params (params))
usage ();
- if (params.iflag) {
+ if (params.iflag)
params.datafile = *argv;
- }
- else {
+ else
params.imagefile = *argv;
- }
+ if (!params.outfile)
+ params.outfile = params.datafile;
ifd = open (params.imagefile, O_RDONLY|O_BINARY);
if (ifd 0) {
@@ -307,7 +312,7 @@ usage (void)
fprintf (stderr, Usage: %s -l image\n
-l == list image header information\n,
params.cmdname);
- fprintf (stderr,%s -i image -p position data_file\n
+ fprintf (stderr,%s -i image [-p position] [-o outfile]
data_file\n
-i == extract from the 'image' a specific
'data_file'
, indexed by 'position' (starting at 0)\n,
params.cmdname);
diff --git a/tools/imagetool.h b/tools/imagetool.h
index d0dd4ac..b88286d 100644
--- a/tools/imagetool.h
+++ b/tools/imagetool.h
@@ -52,6 +52,7 @@ struct image_tool_params {
char *datafile;
char *imagefile;
char *cmdname;
+ const char *outfile;/* Output filename */
const char *keydir; /* Directory holding private keys */
const char *keydest;/* Destination .dtb for public key */
const char *comment;/* Comment to add to signature node */
--
1.8.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mx6: Add IOMUX_CONFIG_SION flag to all GPIO pins
Hi Benoît, On 10/01/2013 12:50 PM, Benoît Thébaudeau wrote: On Tuesday, October 1, 2013 6:17:06 PM, Eric Nelson wrote: On 10/01/2013 09:10 AM, Stefano Babic wrote: On 01/10/2013 17:56, Eric Nelson wrote: On 10/01/2013 07:49 AM, Stefano Babic wrote: On 01/10/2013 16:26, Eric Nelson wrote: ... Did I miss something in this thread that does actually require that ability? It seems a pretty obscure thing in the normal case to drive an output without confidence that it will succeed. Yes, it seems quite strange, but it helps to debug the hardware. It is not the first time we see that, even driving the output, the signal does not go to the expected value, due for example to a conflict (another peripheral driving the signal) or to a wrong pull up resistor. As U-Boot is a great tool for hardware debugging, reading the signal back let check that the output is set to the desired value. I agree with all of that, though this only covers the case of a pin set up as a GPIO output, and that same debugging approach is often used for other functions (display data pins, clock inputs and outputs, et cetera). You probably wouldn't just set SION on all pins, right? I suspect that there'd be some ramification in terms of power consumption if nothing else. Right. Well, instead of adding SION to the pin definition header files, then we could just add SION where needed on a per-pin basis, e.g.: --- imx_iomux_v3_setup_pad(MX6_PAD_NANDF_D1__GPIO_2_1 | IOMUX_CONFIG_SION MUX_MODE_SHIFT); --- A helper macro could be defined in arch/arm/include/asm/imx-common/iomux-v3.h in order to simplify the writing, e.g.: --- #define MUX_MODE_SION (IOMUX_CONFIG_SION MUX_MODE_SHIFT) --- imx_iomux_v3_setup_pad(MX6_PAD_NANDF_D1__GPIO_2_1 | MUX_MODE_SION); --- I like this approach much better since it lets the reader know there's something special about the pin. Regards, Eric ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-Boot DM2 status
+U-Boot Hi, I plan to send out a new driver-model series with mostly small changes in the next few weeks. It will not remove any existing support. I have no plan to move over all subsystems myself. I did implement GPIO just as an example, but have not done PMIC. The changes to support multiple PMICs should not be too large - there is already a list of them - it just needs to be able to initialize multiple PMICs. The Chromium tree has a change in it to support that if you are interested. Regards, Simon On Tue, Oct 1, 2013 at 6:16 AM, Mateusz Zalega m.zal...@samsung.com wrote: Hello, I'm about to refactor PMIC code to make it work in situations when there's more than one PMIC on the board, and I've been wondering, can I do that in a way that would make transition to DM2 easier? How about adding DM2 while keeping legacy code support for the time being? Are there any plans for that? Regards, -- Mateusz Zalega Samsung RD Institute Poland ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v7 09/11] arm: add customized boot command for Faraday Images
2013/9/14 Albert ARIBAUD albert.u.b...@aribaud.net: Hi Kuo-Jung, On Mon, 29 Jul 2013 13:51:51 +0800, Kuo-Jung Su dant...@gmail.com wrote: + * At the time of writting, none of Faraday NAND SPI controllers + * supports XIP (eXecute In Place). So the Faraday A360/A369 SoC has + * to implement a 1st level bootstrap code stored in the embedded ROM + * inside the SoC. + * + * After power-on, the ROM code (1st level bootstrap code) would load + * the 2nd bootstrap code into SRAM without any SDRAM initialization. + * + * The 2nd bootstrap code would then initialize SDRAM and load the + * generic firmware (u-boot/linux) into SDRAM, and finally make + * a long-jump to the firmware. + * + * Which means the SPL design of U-boot would never fit to A360/A369, + * since it's usually not possible to alter a embedded ROM code. Sorry, but I don't see why SPL could not run in SRAM as the 2nd bootloader in your description; SPL certainly does not try to alter a embedded ROM. So, please rewrite the paragraph with the correct reason why SPL cannot be the 2nd bootloader, e.g., is it - because the 2nd bootloader is actually in ROM? - because the SRAM is too small? - ... In any case: Got it, thanks. I'll try to study the SPL again, and rewrite the paragraph. + * And because both the 1st 2nd level bootstrap code use the private + * Faraday Firmware Image Format, it would be better to drop U-boot + * image support to simplify the design. Drop? Certainly not. Introduce a new image format where U-Boot is prepended with a header defined as follow..., yes -- you can even make a case that, if SPL cannot be the 2nd bootloader, then SPL is actually dropped for this platform. Please rewrite. Got it, thanks Also: could the whole description and rationale be moved to some README.* file either arch/arm/cpu/faraday or in doc/ so that readers oof the C file can see the start of the actual code without having to scroll through hundreds of comment lines? Got it, thanks Amicalement, -- Albert. -- Best wishes, Kuo-Jung Su ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 00/19] First step towards Kbuild: Use Kbuild style makefiles
FYI: In order to avoid git-pull conflict, this series uses http://patchwork.ozlabs.org/patch/268098/ http://patchwork.ozlabs.org/patch/268097/ http://patchwork.ozlabs.org/patch/268099/ as prerequisites. Those three were accepted by Albert and now stay in u-boot-arm/master, but not exist in u-boot/master. If you try applying these series, u-boot-arm/master must be merged into u-boot/master beforehand. Best Regards Masahiro Yamada ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 3/4] generic board patch of manual reloc and zero gd_t
-原始邮件- 发件人: Scott Wood scottw...@freescale.com 发送时间: 2013年10月1日 星期二 收件人: FengHua feng...@phytium.com.cn 抄送: Simon Glass s...@chromium.org, trini tr...@ti.com, u-boot u-boot@lists.denx.de 主题: Re: Re: [U-Boot] [PATCH v4 3/4] generic board patch of manual reloc and zero gd_t On Tue, 2013-10-01 at 19:05 +0800, FengHua wrote: -原始邮件- 发件人: Scott Wood scottw...@freescale.com 发送时间: 2013年10月1日 星期二 收件人: Simon Glass s...@chromium.org 抄送: trini tr...@ti.com, u-boot u-boot@lists.denx.de, FengHua feng...@phytium.com.cn 主题: Re: [U-Boot] [PATCH v4 3/4] generic board patch of manual reloc and zero gd_t On Mon, 2013-09-09 at 20:54 -0500, Scott Wood wrote: It seems the problem is that when rela is used, the linker *only* puts the symbol in the rela struct. The value in the data section itself is zero, which means we can't run without relocation even if the address hasn't changed. Unless there's some way to change this linker behavior, the options I can think of are: 1. Write a utility to apply the relocations (for the pre-relocation address) at build time, or 2. Use SPL. The SPL itself would not use -pie and would not relocate. The main U-Boot would know that it has been loaded into RAM, and apply relocations prior to entering C code. Interactions with SPL being used for other purposes could be awkward. Any preferences, or other suggestions? I think either of these options is preferable to CONFIG_NEEDS_MANUAL_RELOC. I'm inclined toward option #1 as it avoids interactions with other SPL uses and in general doesn't change the runtime flow. #1 is easier to do on the u-boot.bin rather than on the ELF file[1], but apparently that doesn't do us any good with the model because it wants an ELF file. Shouldn't the model be applying the relocations if it's an ELF loader? Is there any way to get the foundation model to load a raw binary? I tried --data and --nsdata at 0x8000 (alone or in combination with --image) and wasn't able to do a write to the LEDs immediately after reset (which works when I load it as ELF). It works when I convert the binary back into an ELF using objcopy and ld, but it would be nice to avoid that... How about place u-boot.bin at 0x9000 and write a piece of code (elf format) jumping from 0x8000 to 0x9000. That seems even worse than converting the .bin back into an ELF... Why? I could load u-boot.bin at 0x9000 as data, I think it should works. Or maybe secure state make the program jumping to secure memory. so try switching to el2 before jumping. Do you know why loading the raw image at 0x8000 isn't working? The foundation model require a elf(axf) image being loaded, it use it to determine the entry point. David ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] imximage on the MX50
Hi, I'm trying to port u-boot 2013.10-rc2 to the i.MX50 (which is very similar to the i.MX53). However I'm not having much luck with the imximage, and have so far not managed to make the unit run stand-alone. Specifically, the dcd_ptr in the v2 imx header points to an address in DDR, however I would have thought that on power-up the DCD is loaded somewhere in iRAM (since the DDR isn't running at this stage), and then only once this has been interpreted is the full image loaded into DDR. The tools/imximage.c code appears to only work with DDR addresses, and I'm assuming that this same system works fine on the MX53. Can anyone shed any light on this? Regards, Andre ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFD] OMAP5: Working HYP mode
On Wed, Sep 25, 2013 at 11:57 AM, Andre Przywara andre.przyw...@linaro.org wrote: Alexander, have you seen my series? Hi and sorry for the late reply. Yes, seen that. http://lists.denx.de/pipermail/u-boot/2013-September/163019.html [U-Boot] [PATCH v5 0/8] ARMv7: Add HYP mode switching support I am about to support more boards, but OMAP5 seems very different, probably because it starts u-boot in non-secure state already, right? Correct! So all the magic is in the firmware, which just needs to be called by smc calls, right? So it looks like one could at least use some infrastructure (CONFIG_ARMV7_VIRT and the higher level .c files) to properly merge OMAP5 support in. Also needed would be to make most code of my patch optional by using the proper defines. What do you think? I don't know, maybe just add a callback (or define the HYP initialization routine as a weak symbol). OMAP5 just works without modifying VBAR or touching anything except what's mentioned in the patch, so I probably need to read the manual about virtualization to comment on it. Regards, Andre. -- Regards, Alexander ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
