Re: [U-Boot] [PATCH] i2c:zynq: I2C multi-bus support on Zynq
Hello Michael,
Am 20.09.2013 22:40, schrieb Michael Burr:
Changes:
'zynq_i2c.c':
Adapted driver for compliance with new I2C driver model
(CONFIG_SYS_I2C).
Support for 0-length register address in 'i2c_write', 'i2c_read'.
'i2c.h', 'i2c_core.c':
Support for Texas Instruments PCA9548 bus multiplexer.
Your commit message implements, that your patch contains 3
independent changes ... it would be better to seperate your
patch in 3 pieces ... so if your patch introduces a problem,
it is better to identify, which part it introduced ...
Can you do this easy? Except of this, I have only one minor
Codingstyle comment
Tested:
Xilinx ZC702 eval board (single bus master 'I2C0' with multiplexer
PCA9548).
Write and read registers with addresses of length 0 and 1.
Note:
Mainline code does not work out of the box on ZC702 at this time;
ad hoc adaptations based on 'u-boot-xlnx' repository were needed
in order to test on this board. (Those adapatations are not included
with this patch.)
? Where can I find this repository?
Signed-off-by: Michael Burrmichael.b...@logicpd.com
Cc: Heiko Schocherh...@denx.de
Cc: Michal Simekmon...@monstr.eu
---
drivers/i2c/i2c_core.c |5 ++
drivers/i2c/zynq_i2c.c | 148 +---
include/i2c.h |3 +
3 files changed, 97 insertions(+), 59 deletions(-)
[...]
diff --git a/include/i2c.h b/include/i2c.h
index 8fd17d1..683affe 100644
--- a/include/i2c.h
+++ b/include/i2c.h
@@ -40,6 +40,7 @@
#define CONFIG_SYS_I2C_MAX_HOPS 0
#define CONFIG_SYS_NUM_I2C_BUSES ll_entry_count(struct i2c_adapter, i2c)
#else
+
Change not needed!
/* we use i2c muxes */
#undef CONFIG_SYS_I2C_DIRECT_BUS
#endif
@@ -135,6 +136,8 @@ extern struct i2c_bus_hose i2c_bus[];
#define I2C_MUX_PCA9544 {I2C_MUX_PCA9544_ID, PCA9544A}
#define I2C_MUX_PCA9547_ID4
#define I2C_MUX_PCA9547 {I2C_MUX_PCA9547_ID, PCA9547A}
+#define I2C_MUX_PCA9548_ID 5
+#define I2C_MUX_PCA9548{I2C_MUX_PCA9548_ID, PCA9548}
#endif
#ifndef I2C_SOFT_DECLARATIONS
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
[U-Boot] [PATCH] net, phy: fix AR8031 phy_mask
AR8035 driver will be never applied because of wrong mask for
AR8031 driver. Fix this.
Signed-off-by: Heiko Schocher h...@denx.de
Reported-by: Pavel Nakonechny pavel.nakonec...@skitlab.ru
Cc: Andy Fleming aflem...@freescale.com
Cc: Joe Hershberger joe.hershber...@gmail.com
---
drivers/net/phy/atheros.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/phy/atheros.c b/drivers/net/phy/atheros.c
index 0f2dfd6..ea64041 100644
--- a/drivers/net/phy/atheros.c
+++ b/drivers/net/phy/atheros.c
@@ -50,7 +50,7 @@ static struct phy_driver AR8021_driver = {
static struct phy_driver AR8031_driver = {
.name = AR8031,
.uid = 0x4dd074,
- .mask = 0xf0,
+ .mask = 0xff,
.features = PHY_GBIT_FEATURES,
.config = genphy_config,
.startup = genphy_startup,
--
1.8.3.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] mpc85xx: Fix the offset of register address error
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;
--
1.8.0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] question: why write bbt and search bbt use different ops mode in nand_bbt.c in U-boot 2013.04?
Hi all,
First, My uboot version is 2013.04.
In the function scan_write_bbt(), U-boot uses MTD_OOB_PLACE to write BBT
data and BBT pattern. See below
static int scan_write_bbt(struct mtd_info *mtd, loff_t offs, size_t len,
uint8_t *buf, uint8_t *oob)
{
struct mtd_oob_ops ops;
ops.mode = MTD_OOB_PLACE;
ops.ooboffs = 0;
ops.ooblen = mtd-oobsize;
ops.datbuf = buf;
ops.oobbuf = oob;
ops.len = len;
return mtd-write_oob(mtd, offs, ops);
}
while in funtion search_bbt() (actually in function scan_read_raw_oob()),
U-boot uses MTD_OOB_RAW to read BBT data and BBT pattern. See below.
static int scan_read_raw_oob(struct mtd_info *mtd, uint8_t *buf, loff_t
offs,
size_t len)
{
struct mtd_oob_ops ops;
int res;
ops.mode = MTD_OOB_RAW;
ops.ooboffs = 0;
ops.ooblen = mtd-oobsize;
while (len 0) {
if (len = mtd-writesize) {
ops.oobbuf = buf + len;
ops.datbuf = buf;
ops.len = len;
return mtd-read_oob(mtd, offs, ops);
} else {
ops.oobbuf = buf + mtd-writesize;
ops.datbuf = buf;
ops.len = mtd-writesize;
res = mtd-read_oob(mtd, offs, ops);
if (res)
return res;
}
buf += mtd-oobsize + mtd-writesize;
len -= mtd-writesize;
}
return 0;
}
It's confused that search BBT and write BBT uses different mtd ops mode.
And also data will not be valid if U-boot uses mtd ops MTD_OOB_RAW during
reading and no software ECC is implemented.
I also noticed that in U-boot2013.07 both search BBT and write BBT uses mtd
ops MTD_OPS_PLACE_OOB.
Could anyone please explain the reason to me?
Nick Yao
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [U-boot] OOB-Layout question in NAND Flash chip
Hi, experts: Is the u-boot's NAND OOB-layout same with linux kernel's nand drivers? Best wishes, ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] powerpc/c29xpcie: Getting DDR SPD image from 16-bit sub-address EEPROM
On Sat, Sep 21, 2013 at 8:31 PM, Po Liu po@freescale.com wrote:
+void get_spd(generic_spd_eeprom_t *spd, u8 i2c_address)
+{
+ int ret = i2c_read(i2c_address, 0, 2, (uchar *)spd,
(uchar) is wrong.
int i2c_read(uint8_t chip, unsigned int addr, int alen,
uint8_t *buffer, int len);
The type for this parameter is uint8_t.
The proper fix is to change the i2c_read() function should be changed
to take a void*.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] How do ARM platform initialize DDR?
On Tue, Sep 17, 2013 at 10:59 AM, York Sun york...@freescale.com wrote: I am wondering if there is generic DDR driver used by many ARM platforms, like the one we have for powerpc/mpc85xx SoCs. Sadly, no such thing exists. There is no generic DDR controller for ARM. I'm working on DDR controller support for our ARM chips, and it's nowhere near as elegant as Freescale's PowerPC parts. In our case, we have firmware running in the chip that does DDR initialization and then loads u-boot.bin from a SPI flash into DDR, and then it boots the main processor. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] How do ARM platform initialize DDR?
On Thu, Sep 19, 2013 at 3:57 PM, Tom Rini tr...@ti.com wrote: Thinking back, as a rule of thumb, PowerPC has SPD I2C data available, usually. That's not the rule for ARM. One of a few choices happen: Even if you do have SPD on your ARM chip, that's still no guarantee that you can program the DDR controller properly. On our chips, we have to have a table of 300+ for each frequency that we support, and the SPD only lets us tweak a few registers to account for different size DIMMs. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] How do ARM platform initialize DDR?
Dear Timur, In message caozdjxvdf7z7ya8p4nkybp1wj1cnmts736cetrnp_9yqygq...@mail.gmail.com you wrote: On Tue, Sep 17, 2013 at 10:59 AM, York Sun york...@freescale.com wrote: I am wondering if there is generic DDR driver used by many ARM platforms, like the one we have for powerpc/mpc85xx SoCs. Sadly, no such thing exists. There is no generic DDR controller for ARM. I'm working on DDR controller support for our ARM chips, and it's nowhere near as elegant as Freescale's PowerPC parts. In our MPC85xx is just one family of processors. And I don't think you really want to claim that all Freescale's PowerPC processors use the same memory controller? Try and compare the memory controllers (and the required initialization sequences) for just a selection of MPC8xx, MPC82xx, MPC83xx, MPC85xx. And even if some parts use the same IP block, usually the register interfaces to it are sufficiently different to make common code a challenge at least (compare MPC5121 and MPC5125). Yes, some of the later modes share more common IP blocks, but PowerPC is in no way better than ARM in this respect - the difference is only, that there are way more different ARM SoCs than there ver have been PPC ones, so the problems become more visible. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de A man is not complete until he is married -- then he is finished. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC 0/3] ARM: cleanup gd init
Hello, On 08/24/2013 06:32 PM, Jeroen Hofstee wrote: 4) Keep the s_init in crt0.S or move it to the board_init_f? The disadvantage of the later is that all the different board_init_f's need to call system_init. Since this has been on the mailing-list for a month without a reply, let's push this a bit. Moving s_init to board_init_f is not smart since there are many board_init_f already and likely there will be more in the future since SPL uses it as well. It also provides a chance to save bootrom registers to gd. After boad_init_f r1 is clobbered at least.. Regards, Jeroen ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] u-boot verifiied boot question
Hi Vikas, On Sun, Sep 22, 2013 at 1:16 PM, Vikas N Kumar vi...@vikaskumar.org wrote: Hi I am trying to get verified boot working for the Beaglebone Black (BBB) and have gotten the FIT image part working with a kernel and an FDT blob for the BBB. However, I am a little confused by the documentation which says that u-boot also needs an FDT blob (with CONFIG_OF_CONTROL) to embed the RSA public key. I have a few questions that might not be related to each other but can help me complete my work: - Is this uboot FDT control blob the same as the FDT blob in the FIT image for booting the kernel or are these 2 separate blobs pointing to the same hardware ? They are different, or at least are normally different. The control FDT is used for configuration in U-Boot. But if you have a Beaglebone Black device tree you use for the kernel, you can use the same one for U-Boot. - Can the uboot FDT blob be empty in the sense that all it does is store a public key and all the machine specific stuff is in the uboot image itself as it is done today for the BBB ? Yes - Can one embed the public key in u-boot without using an FDT blob ? There is a CONFIG_OF_EMBED which embeds a device tree file into the U-Boot binary, but this is intended only for debugging. It is better to use u-boot-dtb.bin or 'cat u-boot.bin u-boot.dtb image.bin' to append the device tree to U-Boot. It would be possible to implement a feature to put the public key elsewhere if you really don't want a device tree in U-Boot. Regards, Simon Thanks _vicash_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] u-boot verifiied boot question
Hi I am trying to get verified boot working for the Beaglebone Black (BBB) and have gotten the FIT image part working with a kernel and an FDT blob for the BBB. However, I am a little confused by the documentation which says that u-boot also needs an FDT blob (with CONFIG_OF_CONTROL) to embed the RSA public key. I have a few questions that might not be related to each other but can help me complete my work: - Is this uboot FDT control blob the same as the FDT blob in the FIT image for booting the kernel or are these 2 separate blobs pointing to the same hardware ? - Can the uboot FDT blob be empty in the sense that all it does is store a public key and all the machine specific stuff is in the uboot image itself as it is done today for the BBB ? - Can one embed the public key in u-boot without using an FDT blob ? Thanks _vicash_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/3] mx28evk: Propagate the error if cpu_eth_init() fails
Dear Fabio Estevam, From: Fabio Estevam fabio.este...@freescale.com If cpu_eth_init() fails we should return the error immediately. Cc: Marek Vasut ma...@denx.de Signed-off-by: Fabio Estevam fabio.este...@freescale.com Acked-by: Marek Vasut ma...@denx.de --- board/denx/m28evk/m28evk.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/board/denx/m28evk/m28evk.c b/board/denx/m28evk/m28evk.c index f4453d6..33d38cf 100644 --- a/board/denx/m28evk/m28evk.c +++ b/board/denx/m28evk/m28evk.c @@ -116,6 +116,8 @@ int board_eth_init(bd_t *bis) int ret; ret = cpu_eth_init(bis); + if (ret) + return ret; clrsetbits_le32(clkctrl_regs-hw_clkctrl_enet, CLKCTRL_ENET_TIME_SEL_MASK | CLKCTRL_ENET_CLK_OUT_EN, 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 V4 10/17] usb: gadget: mv_udc: optimize bounce
Dear Troy Kisky, On 9/20/2013 3:58 AM, Marek Vasut wrote: Dear Troy Kisky, Only perform one copy, either in the bounce routine for IN transfers, or the debounce rtn for OUT transfer. On out transfers, only copy the number of bytes received from the bounce buffer Signed-off-by: Troy Kisky troy.ki...@boundarydevices.com --- v4: no change Just a question here. Are you sure we never Send AND Reserve the data in one turn? Because that would need two copyings. ??? s/Reserve/Receive/ As far as I'm aware, a single buffer is only ever used to capture or provide data not both. But, if 2 transfers were queued, an OUT and then an IN using the same buffer, if it worked before this patch, it should work after as well. How come? Before, it was doing flush before and inval after the transfer, right ? btw what does this part of the patch do/mean ? Why is it there? @@ -387,10 +383,9 @@ static void handle_ep_complete(struct mv_ep *ep) num, in ? in : out, item-info, item-page0); len = (item-info 16) 0x7fff; - - mv_debounce(ep); - ep-req.length -= len; + mv_debounce(ep, in); + DBG(ept%d %s complete %x\n, num, in ? in : out, len); ep-req.complete(ep-ep, ep-req); 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 V4 03/17] usb: gadget: ether set wMaxPacketSize
Dear Troy Kisky, On 9/20/2013 3:52 AM, Marek Vasut wrote: Dear Troy Kisky, set wMaxPacketSize for full speed descriptors fs_source_desc, fs_sink_desc to 64. Full-speed bulk endpoint can have a maximum packet size of 8, 16, 32, or 64 bytes, so choice 64. The hs_source_desc, hs_sink_desc, already have their wMaxPacketSize set to 512. That is the only legal value for high speed bulk endpoints. Signed-off-by: Troy Kisky troy.ki...@boundarydevices.com Why do we need this patch? What issue does this fix ? Best regards, Marek Vasut I could try full speed mode without this and see how linux behaves when given bad data, but that would not says anything about other O.S.es. It seems safer just not to give out bad data. Certainly. Will this not cause issues with the MPC8xx controller and OMAP1510 controller? 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 V4 01/17] usb: gadget: mv_udc: don't check CONFIG_USB_MAX_CONTROLLER_COUNT
Dear Troy Kisky, On 9/20/2013 3:45 AM, Marek Vasut wrote: Dear Troy Kisky, i.mx6 has 1 otg controller, and 3 host ports. So, CONFIG_USB_MAX_CONTROLLER_COUNT can be greater than 1 even though only 1 device mode controller is supported. Signed-off-by: Troy Kisky troy.ki...@boundarydevices.com The problem is, will the 3 additional ports still work? I suspect they will, but then if you run 'usb reset', the gadget port will also be switched back into USB Host function, no Best regards, Marek Vasut The next patch checks the OTG id before switching to host mode. If it is grounded, then it enters host mode, otherwise it doesn't. But, running 'usb reset' on a netconsole may kill your connection. It won't if you properly ignore rhis one controller depending on the OTG pin then, no ? I haven't tested that. Do you have a suggestion to fix that? I've been testing with tftp transfers only. Thanks Troy Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] Prevent a U-Boot crash on Wandboard
Prevent a crash when PXE boot calls do_bootm with a vmlinuz formatted image. In this case, there will be a null cmdtp pointer, and we must not dereference it. Signed-off-by: Steven A. Falco stevenfa...@gmail.com --- In file cmd_pxe.c around line 687 is a call: do_bootm(NULL, 0, bootm_argc, bootm_argv); Notice that the first argument is NULL. Therefore, the cmdtp pointer will always be NULL when using the pxe boot mechanism. do_bootm() eventually calls boot_get_kernel(), still with cmdtp == NULL. In the Wandboard case, the vmlinuz binary is not legacy format, nor is it fit format, so U-Boot attempts to print: printf(Wrong Image Format for %s command\n, cmdtp-name); That is doomed to fail, because cmdtp is NULL. The following patch corrects the problem; the command name will be printed only if the pointer is valid. diff --git a/common/cmd_bootm.c b/common/cmd_bootm.c index 349f165..2249682 100644 --- a/common/cmd_bootm.c +++ b/common/cmd_bootm.c @@ -985,7 +985,10 @@ static const void *boot_get_kernel(cmd_tbl_t *cmdtp, int flag, int argc, break; #endif default: - printf(Wrong Image Format for %s command\n, cmdtp-name); + if (cmdtp) + printf(Wrong Image Format for %s command\n, cmdtp-name); + else + printf(Wrong Image Format for command\n); bootstage_error(BOOTSTAGE_ID_FIT_KERNEL_INFO); return NULL; } ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 05/12 V3] Exynos5420: Modify TZPC init to support 5420
Hi Simon,
On Fri, Sep 20, 2013 at 8:31 PM, Simon Glass s...@chromium.org wrote:
Hi Rajeshwari,
On Fri, Sep 20, 2013 at 3:32 AM, Rajeshwari Birje
rajeshwari.bi...@gmail.com wrote:
Hi Simon
Thank you for coments.
Regards,
Rajeshwari Shinde
On Thu, Sep 19, 2013 at 11:27 AM, Simon Glass s...@chromium.org wrote:
Hi Rajeshwari,
On Wed, Sep 11, 2013 at 4:01 AM, Rajeshwari S Shinde
rajeshwar...@samsung.com wrote:
From: Akshay Saraswat aksha...@samsung.com
Currently, part of TZPC init code for Exynos5 starts setting DECPROT
from the base address 0x1010 upto 0x1019 but in case of
Exynos5420 we need it to start from 0x0100E and keep end address
same as 0x1019.
Signed-off-by: Rajeshwari S Shinde rajeshwar...@samsung.com
Signed-off-by: Akshay Saraswat aksha...@samsung.com
---
Changes in V2:
- None
Changes in V3:
- None
arch/arm/cpu/armv7/exynos/tzpc.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/arch/arm/cpu/armv7/exynos/tzpc.c
b/arch/arm/cpu/armv7/exynos/tzpc.c
index 395077c..1102596 100644
--- a/arch/arm/cpu/armv7/exynos/tzpc.c
+++ b/arch/arm/cpu/armv7/exynos/tzpc.c
@@ -23,7 +23,12 @@ void tzpc_init(void)
else if (cpu_is_exynos4())
end = start + ((EXYNOS4_NR_TZPC_BANKS - 1) *
TZPC_BASE_OFFSET);
- for (addr = start; addr = end; addr += TZPC_BASE_OFFSET) {
+ if (proid_is_exynos5420())
+ addr = start - 0x2;
Shouldn't this be in a #define somewhere?
Instead of having a #define we get the start address via
samsung_get_base_tzpc, since there exception in case of 5420 where we need
to start from 0x100E we put a if condition.
Does that mean that the address returned by samsung_get_base_tzpc()
should be different for 5250 and 5420?
Yes they can be different, depends on the value you have mentioned in the
cpu.h file for that SOC.
+ else
+ addr = start;
+
+ for (; addr = end; addr += TZPC_BASE_OFFSET) {
tzpc = (struct exynos_tzpc *)addr;
if (addr == start)
--
1.7.12.4
Regards,
Simon
--
Regards,
Rajeshwari Shinde
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 11/12 V3] SPL: EXYNOS: Prepare for variable size SPL support
Hi Simon, On Thu, Sep 19, 2013 at 11:41 AM, Simon Glass s...@chromium.org wrote: On Wed, Sep 11, 2013 at 4:01 AM, Rajeshwari S Shinde rajeshwar...@samsung.com wrote: When variable size SPL is used, the BL1 expects the SPL to be encapsulated differently: instead of putting the checksum at a fixed offset in the SPL blob, prepend the blob with a header including the size and the checksum. The enhancements include - adding a command line option, '--vs' to indicate the need for the variable size encapsulation - padding the fixed size encapsulated blob with 0xff instead of random memory contents - do not silently truncate the input file, report error instead - no need to explicitly closing files/freeing memory, this all happens on exit; removing cleanups it makes code clearer - profuse commenting - modify Makefile to allow enabling the new feature per board Signed-off-by: Vadim Bendebury vben...@chromium.org Signed-off-by: Rajeshwari S Shinde rajeshwar...@samsung.com Acked-by: Simon Glass s...@chromium.org Will 5250 support variable-sized SPL also? I have tested variable size support for 5420 as have bl1 image supporting variable size for same. I don't have a bl1 image supporting variable size for 5250, but it boots fine without vriable size support even after applying this patch. -- Regards, Rajeshwari Shinde ___ 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 01/12 V3] EXYNOS5: Create a common board file
Hi Simon, On Sat, Sep 21, 2013 at 8:11 AM, Simon Glass s...@chromium.org wrote: Hi Rajeshwari, On Wed, Sep 11, 2013 at 4:01 AM, Rajeshwari S Shinde rajeshwar...@samsung.com wrote: Create a common board.c file for all functions which are common across all EXYNOS5 platforms. exynos_init function is provided for platform cpecific code. Signed-off-by: Rajeshwari S Shinde rajeshwar...@samsung.com I have a few more comments after trying this out on Pit. My source tree is here, in branch try-5420. git://git.denx.de/u-boot-x86.git This includes a few modifications to your patches to make them apply on mainline, and also one patch to fix Pit: - add a device tree - fix a few defines (CONFIG_POWER... instead of CONFIG_PMIC) - define CONFIG_POWER to get PS HOLD asserted (otherwise it powers off after 1 second) - disable MAX77686 PMIC (there is no driver for 77802) - remove PMIC code in smdk5420.c since it is already in board/samsung/common/board.c - serial support for SPL, not really needed - fix boards.cfg format - hack tools/Makefile With this I can boot to a prompt on Pit (I just type 'crosfw' inside the Chrome OS chroot to build and download over USB). I suspect SMDK5420 does not need PS_HOLD, and I think your PMIC code is not being included. I hope this helps with your patch preparation for v4 - it would be great if you could include Pit support as well as smdk5420. Hopefully they can use the same config, just a different device tree. Regards, Simon Okay, will insert these too before sending a V4 patch. -- Regards, Rajeshwari Shinde ___ 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
