[U-Boot] [PATCH] treewide: remove unneeded semicolons
Signed-off-by: Masahiro Yamada
---
arch/powerpc/cpu/ppc4xx/speed.c| 2 +-
board/amcc/bamboo/bamboo.c | 2 +-
board/amcc/luan/luan.c | 2 +-
board/freescale/s32v234evb/clock.c | 2 +-
board/ti/beagle/beagle.c | 6 +++---
board/tqc/tqm5200/cmd_stk52xx.c| 2 +-
drivers/ddr/marvell/axp/ddr3_dqs.c | 2 +-
drivers/mtd/dataflash.c| 12 ++--
drivers/net/fsl_mcdmafec.c | 2 +-
drivers/net/mpc512x_fec.c | 2 +-
drivers/net/ne2000_base.c | 2 +-
fs/yaffs2/yaffs_uboot_glue.c | 2 +-
include/linux/compat.h | 2 +-
tools/img2srec.c | 2 +-
14 files changed, 21 insertions(+), 21 deletions(-)
diff --git a/arch/powerpc/cpu/ppc4xx/speed.c b/arch/powerpc/cpu/ppc4xx/speed.c
index 3e1a7016d949..49a8295bb363 100644
--- a/arch/powerpc/cpu/ppc4xx/speed.c
+++ b/arch/powerpc/cpu/ppc4xx/speed.c
@@ -709,7 +709,7 @@ unsigned long determine_pci_clock_per(void)
pci_period = PERIOD_66_66MHZ;
break;
default:
- pci_period = PERIOD_33_33MHZ;;
+ pci_period = PERIOD_33_33MHZ;
break;
}
diff --git a/board/amcc/bamboo/bamboo.c b/board/amcc/bamboo/bamboo.c
index 6a50b393f462..9f642071cc5d 100644
--- a/board/amcc/bamboo/bamboo.c
+++ b/board/amcc/bamboo/bamboo.c
@@ -1880,7 +1880,7 @@ void configure_ppc440ep_pins(void)
if (ppc440ep_core_selection[PACKET_REJ_FUNC_EN] == CORE_SELECTED)
{
mfsdr(SDR0_MFR, sdr0_mfr);
- sdr0_mfr = (sdr0_mfr & ~SDR0_MFR_PKT_REJ_MASK) |
SDR0_MFR_PKT_REJ_EN;;
+ sdr0_mfr = (sdr0_mfr & ~SDR0_MFR_PKT_REJ_MASK) |
SDR0_MFR_PKT_REJ_EN;
mtsdr(SDR0_MFR, sdr0_mfr);
}
diff --git a/board/amcc/luan/luan.c b/board/amcc/luan/luan.c
index 774671db4321..f98231a8da6c 100644
--- a/board/amcc/luan/luan.c
+++ b/board/amcc/luan/luan.c
@@ -161,7 +161,7 @@ static void l2cache_enable(void)/* see p258 7.4.1
Enabling L2 Cache */
mtdcr( L2_CACHE_CMD, 0x8000 ); /* issue HCLEAR command via
L2_CMD */
- while (!(mfdcr( L2_CACHE_STAT ) & 0x8000 )) ;; /* poll L2_SR for
completion */
+ while (!(mfdcr( L2_CACHE_STAT ) & 0x8000 )) ; /* poll L2_SR for
completion */
mtdcr( L2_CACHE_CMD, 0x1000 ); /* clear cache errors
L2_CMD[CCP] */
diff --git a/board/freescale/s32v234evb/clock.c
b/board/freescale/s32v234evb/clock.c
index d218c21419b1..e8996e094f92 100644
--- a/board/freescale/s32v234evb/clock.c
+++ b/board/freescale/s32v234evb/clock.c
@@ -45,7 +45,7 @@ static int select_pll_source_clk(enum pll_type pll, u32
refclk_freq)
pll_idx = 1;
break;
case DDR_PLL:
- pll_idx = 2;;
+ pll_idx = 2;
break;
default:
pll_idx = pll;
diff --git a/board/ti/beagle/beagle.c b/board/ti/beagle/beagle.c
index 00d127e21b3a..887b577b6adf 100644
--- a/board/ti/beagle/beagle.c
+++ b/board/ti/beagle/beagle.c
@@ -443,13 +443,13 @@ int misc_init_r(void)
printf("Recognized BeagleBoardToys WiFi board\n");
MUX_BBTOYS_WIFI()
setenv("buddy", "bbtoys-wifi");
- break;;
+ break;
case BBTOYS_VGA:
printf("Recognized BeagleBoardToys VGA board\n");
- break;;
+ break;
case BBTOYS_LCD:
printf("Recognized BeagleBoardToys LCD board\n");
- break;;
+ break;
case BCT_BRETTL3:
printf("Recognized bct electronic GmbH brettl3 board\n");
break;
diff --git a/board/tqc/tqm5200/cmd_stk52xx.c b/board/tqc/tqm5200/cmd_stk52xx.c
index dc22ee402480..a3916ed9571d 100644
--- a/board/tqc/tqm5200/cmd_stk52xx.c
+++ b/board/tqc/tqm5200/cmd_stk52xx.c
@@ -142,7 +142,7 @@ void amplifier_init(void)
static void i2s_init(void)
{
unsigned long i;
- struct mpc5xxx_psc *psc = (struct mpc5xxx_psc*)MPC5XXX_PSC2;;
+ struct mpc5xxx_psc *psc = (struct mpc5xxx_psc*)MPC5XXX_PSC2;
struct mpc5xxx_gpio *gpio = (struct mpc5xxx_gpio*)MPC5XXX_GPIO;
gpio->port_config |= 0x0070; /* PSC2 ports as Codec with MCLK */
diff --git a/drivers/ddr/marvell/axp/ddr3_dqs.c
b/drivers/ddr/marvell/axp/ddr3_dqs.c
index 71a986d54f18..46443364d13b 100644
--- a/drivers/ddr/marvell/axp/ddr3_dqs.c
+++ b/drivers/ddr/marvell/axp/ddr3_dqs.c
@@ -1268,7 +1268,7 @@ int ddr3_set_dqs_centralization_results(MV_DRAM_INFO
*dram_info, u32 cs,
max_pup = (ecc + (1 - ecc) * dram_info->num_of_std_pups);
- DEBUG_DQS_RESULTS_S("\n LOG LEVEL 2(Windows margins)
\n");;
+ DEBUG_DQS_RESULTS_S("\n LOG LEVEL 2(Windows margins)
\n");
if (is_tx) {
DEBUG_DQS_RESULTS_C("DDR3 - DQS TX - Set Dqs Centralizat
Re: [U-Boot] dtb build issue on U-Boot
Hi Kever, Simon, Sorry for my late reply. 2017-06-07 6:16 GMT+09:00 Simon Glass : > +Masahiro > > On 6 June 2017 at 05:45, Kever Yang wrote: >> >> I notice that the dtb content in spl/u-boot-spl.bin and u-boot.bin not >> >> able to update after I modify the dts file and make again, I have to >> >> "make clean" first, and then the "make" can update the dtb content >> >> to output binary, which lead to bad efficiency when try to modify dts. >> >> I have try below command, the dtb file also not updated before "make clean". >> >> dtc -I dtb -O dts spl/u-boot-spl.dtb >> >> Is there any one can help fix this issue? > > I have noticed this too, and also that changing a .dtsi file is not noticed. > > Probably it is missing a dependency in the makefile. I could not reproduce the issue for me. Editing a DT file and re-compiling gave me the expected result. masahiro@pug:~/ref/u-boot$ make -s mrproper masahiro@pug:~/ref/u-boot$ make -s CROSS_COMPILE=aarch64-linux-gnu- uniphier_v8_defconfig all masahiro@pug:~/ref/u-boot$ nano arch/arm/dts/uniphier-ld20.dtsi (add hello-world property) masahiro@pug:~/ref/u-boot$ make CROSS_COMPILE=aarch64-linux-gnu- CHK include/config/uboot.release CHK include/generated/version_autogenerated.h CHK include/generated/timestamp_autogenerated.h UPD include/generated/timestamp_autogenerated.h CHK include/generated/generic-asm-offsets.h CHK include/generated/asm-offsets.h HOSTCC tools/mkenvimage.o HOSTLD tools/mkenvimage HOSTCC tools/fit_image.o HOSTCC tools/image-host.o HOSTCC tools/dumpimage.o HOSTLD tools/dumpimage HOSTCC tools/mkimage.o HOSTLD tools/mkimage CC arch/arm/cpu/armv8/fwcall.o LD arch/arm/cpu/armv8/built-in.o CC cmd/version.o CHK cmd/config_data_gz.h CHK cmd/config_data_size.h LD cmd/built-in.o CC common/main.o LD common/built-in.o CC lib/efi_loader/helloworld.o LD lib/efi_loader/helloworld.so OBJCOPY lib/efi_loader/helloworld.efi CC lib/smbios.o CC lib/display_options.o LD lib/built-in.o LD u-boot OBJCOPY u-boot.srec OBJCOPY u-boot-nodtb.bin start=$(aarch64-linux-gnu-nm u-boot | grep __rel_dyn_start | cut -f 1 -d ' '); end=$(aarch64-linux-gnu-nm u-boot | grep __rel_dyn_end | cut -f 1 -d ' '); tools/relocate-rela u-boot-nodtb.bin 0x8400 $start $end DTC arch/arm/dts/uniphier-ld20-ref.dtb make[2]: 'arch/arm/dts/uniphier-ld20-ref.dtb' is up to date. SHIPPED dts/dt.dtb CAT u-boot-dtb.bin COPYu-boot.bin SYM u-boot.sym MKIMAGE u-boot.img COPYu-boot.dtb MKIMAGE u-boot-dtb.img CFGCHK u-boot.cfg masahiro@pug:~/ref/u-boot$ dtc -I dtb -O dts u-boot.dtb | grep hello-world hello-world; If I am missing something, could you tell me the command you used for reproducing the problem? -- Best Regards Masahiro Yamada ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] am335x_evm_usbspl_defconfig testint
On Monday 12 June 2017 10:12 PM, Jason Kridner wrote: > I see you submitted this defconfig: > https://lists.denx.de/pipermail/u-boot/2016-November/272425.html > > I have a Google Summer of Code student intern attempting to use it and he's > seeing it hang without entering UMS mode. Details are below. > > Can you give any advice on how you tested this? Could you try this patch that I posted sometime back: https://patchwork.ozlabs.org/patch/748877/ I forgot to follow that up and looks like it did not make into the u-boot master branch. Regards Vignesh > > I believe he still needs to do something to explicitly enable UMS. Can you > confirm? > > Ravi, > > If Stefan cannot answer, I'd suggest adjusting the default boot command to > invoke UMS. Have you been able to stop the boot process using the serial > port and get to the u-boot console? At the console, have you tried running > the 'ums' command? > > Regards, > Jason > > On Sun, Jun 11, 2017 at 4:18 PM Ravi Kumar Prasad <7rav...@gmail.com> wrote: > >> Hi, >> I'm porting BBBlfs bootloader server to nodejs. Now, after receiving tftp >> request for SPL, I'm transferring SPL. >> I built spl/uboot with config am335x_evm_usbspl_defconfig . After SPL >> transfer it fails to boot, here's the serial output: >> >> U-Boot SPL 2017.07-rc1-00163-g8cb3ce6 (Jun 11 2017 - 01:09:02) >> SPL: failed to boot from all boot devices >> ### ERROR ### Please RESET the board ### >> >> Please help me to debug this problem. >> Code for server: https://github.com/ravikp7/node-beagle-boot >> Thanks >> Ravi >> >> -- >> You received this message because you are subscribed to the Google Groups >> "BeagleBoard GSoC" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to beagleboard-gsoc+unsubscr...@googlegroups.com. >> For more options, visit https://groups.google.com/d/optout. >> > ___ > U-Boot mailing list > U-Boot@lists.denx.de > https://lists.denx.de/listinfo/u-boot > -- Regards Vignesh ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 12/12] power: regulator: lp87565: get_enable should return integer
get_enable should be able to return error values. Hence change
the return type to integer.
Signed-off-by: Keerthy
---
drivers/power/regulator/lp87565_regulator.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/power/regulator/lp87565_regulator.c
b/drivers/power/regulator/lp87565_regulator.c
index 2a0b8ca..d908f6d 100644
--- a/drivers/power/regulator/lp87565_regulator.c
+++ b/drivers/power/regulator/lp87565_regulator.c
@@ -166,7 +166,7 @@ static int buck_set_value(struct udevice *dev, int uV)
return lp87565_buck_val(dev, PMIC_OP_SET, &uV);
}
-static bool buck_get_enable(struct udevice *dev)
+static int buck_get_enable(struct udevice *dev)
{
bool enable = false;
int ret;
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 08/12] power: regulator: rk8xx: get_enable should return integer
get_enable should be able to return error values. Hence change
the return type to integer.
Signed-off-by: Keerthy
---
drivers/power/regulator/rk8xx.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/power/regulator/rk8xx.c b/drivers/power/regulator/rk8xx.c
index c1ece96..3dc15e4 100644
--- a/drivers/power/regulator/rk8xx.c
+++ b/drivers/power/regulator/rk8xx.c
@@ -164,7 +164,7 @@ static int buck_set_enable(struct udevice *dev, bool enable)
return _buck_set_enable(dev->parent, buck, enable);
}
-static bool buck_get_enable(struct udevice *dev)
+static int buck_get_enable(struct udevice *dev)
{
int buck = dev->driver_data - 1;
int ret;
@@ -223,7 +223,7 @@ static int ldo_set_enable(struct udevice *dev, bool enable)
enable ? mask : 0);
}
-static bool ldo_get_enable(struct udevice *dev)
+static int ldo_get_enable(struct udevice *dev)
{
int ldo = dev->driver_data - 1;
int ret;
@@ -249,7 +249,7 @@ static int switch_set_enable(struct udevice *dev, bool
enable)
enable ? mask : 0);
}
-static bool switch_get_enable(struct udevice *dev)
+static int switch_get_enable(struct udevice *dev)
{
int sw = dev->driver_data - 1;
int ret;
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 00/12] regulator: Change get_enable return type to integer from bool
Change get_enable return type to int so errors can be returned. The series converts the return type of get_enable hook in the dm_regulator_ops to integer from bool. This enables it to return any error values if any. Compile tested. Keerthy (12): regulator: Change get_enable return type to integer from bool power: regulator: fixed: get_enable should return integer power: regulator: act8846: get_enable should return integer power: regulator: max77686: get_enable should return integer power: regulator: palmas: get_enable should return integer power: regulator: pfuze100: get_enable should return integer power: regulator: tps65090: get_enable should return integer power: regulator: rk8xx: get_enable should return integer power: sandbox: fixed: get_enable should return integer power: regulator: s5m8767: get_enable should return integer power: regulator: lp873x: get_enable should return integer power: regulator: lp87565: get_enable should return integer drivers/power/regulator/act8846.c| 2 +- drivers/power/regulator/fixed.c | 2 +- drivers/power/regulator/lp873x_regulator.c | 4 ++-- drivers/power/regulator/lp87565_regulator.c | 2 +- drivers/power/regulator/max77686.c | 4 ++-- drivers/power/regulator/palmas_regulator.c | 4 ++-- drivers/power/regulator/pfuze100.c | 2 +- drivers/power/regulator/regulator-uclass.c | 2 +- drivers/power/regulator/rk8xx.c | 6 +++--- drivers/power/regulator/s5m8767.c| 4 ++-- drivers/power/regulator/sandbox.c| 4 ++-- drivers/power/regulator/tps65090_regulator.c | 2 +- include/power/regulator.h| 8 13 files changed, 23 insertions(+), 23 deletions(-) -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 03/12] power: regulator: act8846: get_enable should return integer
get_enable should be able to return error values. Hence change
the return type to integer.
Signed-off-by: Keerthy
---
drivers/power/regulator/act8846.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/power/regulator/act8846.c
b/drivers/power/regulator/act8846.c
index d506165..7d86aae 100644
--- a/drivers/power/regulator/act8846.c
+++ b/drivers/power/regulator/act8846.c
@@ -115,7 +115,7 @@ static int reg_set_enable(struct udevice *dev, bool enable)
enable ? LDO_EN_MASK : 0);
}
-static bool reg_get_enable(struct udevice *dev)
+static int reg_get_enable(struct udevice *dev)
{
int reg = dev->driver_data;
int ret;
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 05/12] power: regulator: palmas: get_enable should return integer
get_enable should be able to return error values. Hence change
the return type to integer.
Signed-off-by: Keerthy
---
drivers/power/regulator/palmas_regulator.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/power/regulator/palmas_regulator.c
b/drivers/power/regulator/palmas_regulator.c
index 841c03a..99614b0 100644
--- a/drivers/power/regulator/palmas_regulator.c
+++ b/drivers/power/regulator/palmas_regulator.c
@@ -304,7 +304,7 @@ static int ldo_set_value(struct udevice *dev, int uV)
return palmas_ldo_val(dev, PMIC_OP_SET, &uV);
}
-static bool ldo_get_enable(struct udevice *dev)
+static int ldo_get_enable(struct udevice *dev)
{
bool enable = false;
int ret;
@@ -411,7 +411,7 @@ static int smps_set_value(struct udevice *dev, int uV)
return palmas_smps_val(dev, PMIC_OP_SET, &uV);
}
-static bool smps_get_enable(struct udevice *dev)
+static int smps_get_enable(struct udevice *dev)
{
bool enable = false;
int ret;
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 02/12] power: regulator: fixed: get_enable should return integer
get_enable should be able to return error values. Hence change
the return type to integer.
Signed-off-by: Keerthy
---
drivers/power/regulator/fixed.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/power/regulator/fixed.c b/drivers/power/regulator/fixed.c
index 656371b..35c2922 100644
--- a/drivers/power/regulator/fixed.c
+++ b/drivers/power/regulator/fixed.c
@@ -89,7 +89,7 @@ static int fixed_regulator_get_current(struct udevice *dev)
return uc_pdata->min_uA;
}
-static bool fixed_regulator_get_enable(struct udevice *dev)
+static int fixed_regulator_get_enable(struct udevice *dev)
{
struct fixed_regulator_platdata *dev_pdata = dev_get_platdata(dev);
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 09/12] power: sandbox: fixed: get_enable should return integer
get_enable should be able to return error values. Hence change
the return type to integer.
Signed-off-by: Keerthy
---
drivers/power/regulator/sandbox.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/power/regulator/sandbox.c
b/drivers/power/regulator/sandbox.c
index 2cca579..06c09fd 100644
--- a/drivers/power/regulator/sandbox.c
+++ b/drivers/power/regulator/sandbox.c
@@ -234,7 +234,7 @@ static int buck_set_current(struct udevice *dev, int uA)
buck_current_range, uA);
}
-static bool buck_get_enable(struct udevice *dev)
+static int buck_get_enable(struct udevice *dev)
{
if (out_get_mode(dev) == BUCK_OM_OFF)
return false;
@@ -310,7 +310,7 @@ static int ldo_set_current(struct udevice *dev, int uA)
ldo_current_range, uA);
}
-static bool ldo_get_enable(struct udevice *dev)
+static int ldo_get_enable(struct udevice *dev)
{
if (out_get_mode(dev) == LDO_OM_OFF)
return false;
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 10/12] power: regulator: s5m8767: get_enable should return integer
get_enable should be able to return error values. Hence change
the return type to integer.
Signed-off-by: Keerthy
---
drivers/power/regulator/s5m8767.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/power/regulator/s5m8767.c
b/drivers/power/regulator/s5m8767.c
index 93a3c94..871da12 100644
--- a/drivers/power/regulator/s5m8767.c
+++ b/drivers/power/regulator/s5m8767.c
@@ -186,7 +186,7 @@ static int reg_set_enable(struct udevice *dev, const struct
s5m8767_para *param,
return ret;
}
-static bool ldo_get_enable(struct udevice *dev)
+static int ldo_get_enable(struct udevice *dev)
{
int ldo = dev->driver_data;
@@ -226,7 +226,7 @@ static int buck_set_value(struct udevice *dev, int uv)
return reg_set_value(dev, &buck_param[buck], uv);
}
-static bool buck_get_enable(struct udevice *dev)
+static int buck_get_enable(struct udevice *dev)
{
int buck = dev->driver_data;
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 11/12] power: regulator: lp873x: get_enable should return integer
get_enable should be able to return error values. Hence change
the return type to integer.
Signed-off-by: Keerthy
---
drivers/power/regulator/lp873x_regulator.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/power/regulator/lp873x_regulator.c
b/drivers/power/regulator/lp873x_regulator.c
index dcb19ff..11371a7 100644
--- a/drivers/power/regulator/lp873x_regulator.c
+++ b/drivers/power/regulator/lp873x_regulator.c
@@ -256,7 +256,7 @@ static int ldo_set_value(struct udevice *dev, int uV)
return lp873x_ldo_val(dev, PMIC_OP_SET, &uV);
}
-static bool ldo_get_enable(struct udevice *dev)
+static int ldo_get_enable(struct udevice *dev)
{
bool enable = false;
int ret;
@@ -310,7 +310,7 @@ static int buck_set_value(struct udevice *dev, int uV)
return lp873x_buck_val(dev, PMIC_OP_SET, &uV);
}
-static bool buck_get_enable(struct udevice *dev)
+static int buck_get_enable(struct udevice *dev)
{
bool enable = false;
int ret;
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 07/12] power: regulator: tps65090: get_enable should return integer
get_enable should be able to return error values. Hence change
the return type to integer.
Signed-off-by: Keerthy
---
drivers/power/regulator/tps65090_regulator.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/power/regulator/tps65090_regulator.c
b/drivers/power/regulator/tps65090_regulator.c
index affc504..32aeab9 100644
--- a/drivers/power/regulator/tps65090_regulator.c
+++ b/drivers/power/regulator/tps65090_regulator.c
@@ -23,7 +23,7 @@ static int tps65090_fet_probe(struct udevice *dev)
return 0;
}
-static bool tps65090_fet_get_enable(struct udevice *dev)
+static int tps65090_fet_get_enable(struct udevice *dev)
{
struct udevice *pmic = dev_get_parent(dev);
int ret, fet_id;
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 06/12] power: regulator: pfuze100: get_enable should return integer
get_enable should be able to return error values. Hence change
the return type to integer.
Signed-off-by: Keerthy
---
drivers/power/regulator/pfuze100.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/power/regulator/pfuze100.c
b/drivers/power/regulator/pfuze100.c
index 4702161..3edc2aa 100644
--- a/drivers/power/regulator/pfuze100.c
+++ b/drivers/power/regulator/pfuze100.c
@@ -516,7 +516,7 @@ static int pfuze100_regulator_set_value(struct udevice
*dev, int uV)
return pfuze100_regulator_val(dev, PMIC_OP_SET, &uV);
}
-static bool pfuze100_regulator_get_enable(struct udevice *dev)
+static int pfuze100_regulator_get_enable(struct udevice *dev)
{
int ret;
bool enable = false;
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 04/12] power: regulator: max77686: get_enable should return integer
get_enable should be able to return error values. Hence change
the return type to integer.
Signed-off-by: Keerthy
---
drivers/power/regulator/max77686.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/power/regulator/max77686.c
b/drivers/power/regulator/max77686.c
index 5e5815f..8780806 100644
--- a/drivers/power/regulator/max77686.c
+++ b/drivers/power/regulator/max77686.c
@@ -688,7 +688,7 @@ static int ldo_set_value(struct udevice *dev, int uV)
return max77686_ldo_val(dev, PMIC_OP_SET, &uV);
}
-static bool ldo_get_enable(struct udevice *dev)
+static int ldo_get_enable(struct udevice *dev)
{
bool enable = false;
int ret;
@@ -752,7 +752,7 @@ static int buck_set_value(struct udevice *dev, int uV)
return max77686_buck_val(dev, PMIC_OP_SET, &uV);
}
-static bool buck_get_enable(struct udevice *dev)
+static int buck_get_enable(struct udevice *dev)
{
bool enable = false;
int ret;
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 01/12] regulator: Change get_enable return type to integer from bool
Change get_enable return type to int so errors can be returned.
Signed-off-by: Keerthy
---
drivers/power/regulator/regulator-uclass.c | 2 +-
include/power/regulator.h | 8
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/power/regulator/regulator-uclass.c
b/drivers/power/regulator/regulator-uclass.c
index 0a1d1b3..426a933 100644
--- a/drivers/power/regulator/regulator-uclass.c
+++ b/drivers/power/regulator/regulator-uclass.c
@@ -96,7 +96,7 @@ int regulator_set_current(struct udevice *dev, int uA)
return ops->set_current(dev, uA);
}
-bool regulator_get_enable(struct udevice *dev)
+int regulator_get_enable(struct udevice *dev)
{
const struct dm_regulator_ops *ops = dev_get_driver_ops(dev);
diff --git a/include/power/regulator.h b/include/power/regulator.h
index 1a8e575..2bbc1e5 100644
--- a/include/power/regulator.h
+++ b/include/power/regulator.h
@@ -211,9 +211,9 @@ struct dm_regulator_ops {
* @dev - regulator device
* Sets:
* @enable - set true - enable or false - disable
-* @return true/false for get; or 0 / -errno for set.
+* @return true/false for get or -errno if fail; 0 / -errno for set.
*/
- bool (*get_enable)(struct udevice *dev);
+ int (*get_enable)(struct udevice *dev);
int (*set_enable)(struct udevice *dev, bool enable);
/**
@@ -291,9 +291,9 @@ int regulator_set_current(struct udevice *dev, int uA);
* regulator_get_enable: get regulator device enable state.
*
* @dev- pointer to the regulator device
- * @return - true/false of enable state
+ * @return - true/false of enable state or -errno val if fails
*/
-bool regulator_get_enable(struct udevice *dev);
+int regulator_get_enable(struct udevice *dev);
/**
* regulator_set_enable: set regulator enable state
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/3] regulator: lp873x: Fix the return value of ldo_get_enable function
On Tuesday 13 June 2017 05:21 AM, Simon Glass wrote:
> On 10 June 2017 at 23:01, Keerthy wrote:
>> The function wrongly returned an integer while it is supposed to
>> return boolean. Fix that.
>>
>> Fixes: 99785de83 ("power: regulator: lp873x: Add regulator support")
>> Signed-off-by: Keerthy
>> ---
>> drivers/power/regulator/lp873x_regulator.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>
> Reviewed-by: Simon Glass
>
> I think in fact we should return int from this method in struct
> dm_regulator_ops. I don't really like not being able to return an
> error.
>
> So bonus points if you can change that :-)
I did not touch it as it was being used at many places. Seems like that
is the right thing to do. I believe this series can be discarded. I will
post a series where in all are changed to return int.
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v8 4/7] arm: socfpga: Enable FPGA driver on SPL
On Isn, 2017-06-12 at 16:38 +0800, Chee, Tien Fong wrote: > On Jum, 2017-06-09 at 08:52 -0500, Dinh Nguyen wrote: > > > > > > On 06/09/2017 03:25 AM, Marek Vasut wrote: > > > > > > > > > > > > I didn't really look since we still have a discussion open on V8 > > > . > > > There > > > is no point in sending new versions while discussion is still > > > open. > > > Also, I'd like some review from Ley/Dinh > > I've reviewed v6 and gave my Reviewed-by. Now I see there's a v10. > > Should I be reviewing v10 or wait for a new version? > > > > Dinh > If Marek agree with my planning, code cleaning for gen5 in different > patchset. v10 is updated based on Mareks' comments on v9, then v10 > should be the final version. > > Thanks. Hi Marek, I think Dinh is still waiting answer from you. Could you please to advice? Thanks. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 23/29] dm: ahci: Create a local version of two SCSI functions
On Tue, Jun 6, 2017 at 3:15 AM, Simon Glass wrote: > With driver model we need to define implementations of exec() and > bus_reset() separately for each SCSI driver. As a first step, create a > local version of each function in the AHCI driver and call each from its > global version. > > Signed-off-by: Simon Glass > --- > > drivers/ata/ahci.c | 15 +-- > 1 file changed, 13 insertions(+), 2 deletions(-) > Reviewed-by: Bin Meng ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 20/29] dm: scsi: Add operations
On Tue, Jun 6, 2017 at 3:15 AM, Simon Glass wrote: > Add operations for SCSI. These are not yet implemented, but we have the > struct. > > Signed-off-by: Simon Glass > --- > > include/scsi.h | 20 > 1 file changed, 20 insertions(+) > Reviewed-by: Bin Meng ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 19/29] dm: ahci: Drop use of probe_ent
On Tue, Jun 6, 2017 at 3:15 AM, Simon Glass wrote: > With driver model we cannot have static data or assume that there is only > one device of each time. Adjust the code so that 'probe_ent' is not needed > with driver model. Add a new ahci_init_dm() function which can init AHCI > for driver model without re-allocating the uclass data. Move over the only > existing driver to use this new function. > > Signed-off-by: Simon Glass > --- > > drivers/ata/ahci.c | 75 > +++--- > drivers/ata/dwc_ahci.c | 2 +- > include/ahci.h | 8 ++ > 3 files changed, 55 insertions(+), 30 deletions(-) > Reviewed-by: Bin Meng ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 24/29] dm: scsi: Add operations for SCSI devices
On Tue, Jun 6, 2017 at 3:15 AM, Simon Glass wrote: > The SCSI uclass currently has no operations. It just uses the global SCSI > functions. Fix this by adding operations to the only two drivers that use > the uclass, and replacing the global functions with those defined locally > in the SCSI code. > > Signed-off-by: Simon Glass > --- > > drivers/ata/ahci.c | 7 +++ > drivers/ata/dwc_ahci.c | 1 + > drivers/ata/sata_ceva.c| 1 + > drivers/scsi/scsi-uclass.c | 20 > include/scsi.h | 28 +++- > 5 files changed, 52 insertions(+), 5 deletions(-) > Reviewed-by: Bin Meng ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 28/29] dm: scsi: Drop scsi_init() when driver model is used
On Tue, Jun 6, 2017 at 3:15 AM, Simon Glass wrote: > This function should not be used with driver model. Update the code to > reflect this. > > Signed-off-by: Simon Glass > --- > > drivers/scsi/scsi.c | 6 -- > 1 file changed, 4 insertions(+), 2 deletions(-) > Reviewed-by: Bin Meng ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 26/29] dm: scsi: Split out the bus scanning code
On Tue, Jun 6, 2017 at 3:15 AM, Simon Glass wrote: > Split out the code that scans a single SCSI bus into a separate function. > This will allow it to be used from driver model. > > Signed-off-by: Simon Glass > --- > > drivers/scsi/scsi.c | 35 +++ > include/scsi.h | 8 > 2 files changed, 31 insertions(+), 12 deletions(-) > Reviewed-by: Bin Meng ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 29/29] RFC: x86: Move link to use driver model for SCSI
Hi Simon,
On Tue, Jun 6, 2017 at 3:15 AM, Simon Glass wrote:
> As a demonstration of how to use SCSI with driver model, move link over
> to use this. This patch needs more work, but illustrates the concept.
>
> Signed-off-by: Simon Glass
> ---
>
> arch/x86/cpu/ivybridge/sata.c | 38 +-
> configs/chromebook_link_defconfig | 2 ++
> 2 files changed, 39 insertions(+), 1 deletion(-)
>
This is great! Thanks a lot.
> diff --git a/arch/x86/cpu/ivybridge/sata.c b/arch/x86/cpu/ivybridge/sata.c
> index 0f5e190425..5bbe65d442 100644
> --- a/arch/x86/cpu/ivybridge/sata.c
> +++ b/arch/x86/cpu/ivybridge/sata.c
> @@ -6,6 +6,7 @@
> */
>
> #include
> +#include
> #include
> #include
> #include
> @@ -208,6 +209,20 @@ static void bd82x6x_sata_enable(struct udevice *dev)
> dm_pci_write_config16(dev, 0x90, map);
> }
>
> +static int bd82x6x_sata_bind(struct udevice *dev)
> +{
> + struct udevice *scsi_dev;
> + int ret;
> +
> + if (gd->flags & GD_FLG_RELOC) {
> + ret = ahci_bind_scsi(dev, &scsi_dev);
> + if (ret)
> + return ret;
> + }
> +
> + return 0;
> +}
> +
> static int bd82x6x_sata_probe(struct udevice *dev)
> {
> struct udevice *pch;
> @@ -219,8 +234,12 @@ static int bd82x6x_sata_probe(struct udevice *dev)
>
> if (!(gd->flags & GD_FLG_RELOC))
> bd82x6x_sata_enable(dev);
> - else
> + else {
> bd82x6x_sata_init(dev, pch);
> + ret = ahci_probe_scsi(dev);
> + if (ret)
> + return ret;
> + }
>
> return 0;
> }
> @@ -234,5 +253,22 @@ U_BOOT_DRIVER(ahci_ivybridge_drv) = {
> .name = "ahci_ivybridge",
> .id = UCLASS_AHCI,
> .of_match = bd82x6x_ahci_ids,
> + .bind = bd82x6x_sata_bind,
> .probe = bd82x6x_sata_probe,
> };
> +
> +static struct pci_device_id chromebook_ssd_supported[] = {
> + { PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_NM10_AHCI) },
> + { PCI_DEVICE(PCI_VENDOR_ID_INTEL,
> +PCI_DEVICE_ID_INTEL_COUGARPOINT_AHCI_MOBILE) },
> + { PCI_DEVICE(PCI_VENDOR_ID_INTEL,
> +PCI_DEVICE_ID_INTEL_COUGARPOINT_AHCI_SERIES6) },
> + { PCI_DEVICE(PCI_VENDOR_ID_INTEL,
> +PCI_DEVICE_ID_INTEL_PANTHERPOINT_AHCI_MOBILE) },
> + { PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_LYNXPOINT_AHCI)
> },
> + { PCI_DEVICE(PCI_VENDOR_ID_INTEL,
> +PCI_DEVICE_ID_INTEL_WILDCATPOINT_AHCI) },
> + {},
> +};
Since AHCI is pretty generic, instead of providing device list
filter, can we just use PCI class and sub-class for AHCI, like USB?
For Ivybridge specific stuff, we can call the low level initialization
function as part of the SoC/platform initialization codes.
> +
> +U_BOOT_PCI_DEVICE(ahci_ivybridge_drv, chromebook_ssd_supported);
> diff --git a/configs/chromebook_link_defconfig
> b/configs/chromebook_link_defconfig
> index a463270514..503581dfce 100644
> --- a/configs/chromebook_link_defconfig
> +++ b/configs/chromebook_link_defconfig
> @@ -40,6 +40,8 @@ CONFIG_OF_CONTROL=y
> CONFIG_REGMAP=y
> CONFIG_SYSCON=y
> CONFIG_SCSI=y
> +CONFIG_DM_SCSI=y
> +CONFIG_BLK=y
> CONFIG_CPU=y
> CONFIG_DM_I2C=y
> CONFIG_SYS_I2C_INTEL=y
> --
Regards,
Bin
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 25/29] dm: scsi: Adjust return value of scsi_exec()
On Tue, Jun 6, 2017 at 3:15 AM, Simon Glass wrote: > Change this function to return an error number instead of true/false. > This allows us to return a proper error number. > > Signed-off-by: Simon Glass > --- > > drivers/ata/ahci.c | 6 +++--- > drivers/scsi/scsi.c | 8 > 2 files changed, 7 insertions(+), 7 deletions(-) > Reviewed-by: Bin Meng ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 18/29] dm: ahci: Unwind the confusing init code
On Tue, Jun 6, 2017 at 3:15 AM, Simon Glass wrote: > Two AHCI drivers use SCSI with CONFIG_DM_SCSI. The SCSI uclass calls > scsi_low_level_init() which is implemented by ahci.c. If > CONFIG_SCSI_AHCI_PLAT is defined it does one thing and if it is not > it does something else. > > We don't need to call through scsi_low_level_init() to get the init > completed. Instead, adjust the two drivers to call into AHCI directly. > Drop the post-probe init in the SCSI uclass. This means that driver model > doesn't need to use scsi_low_level_init(). It is a legacy function and > driver model should use a driver's probe() method instead. > > While we are hear, add a comment to the top of the file explaining what typo: we are 'here' > ahci.c does. > > Signed-off-by: Simon Glass > --- > > drivers/ata/ahci.c | 26 -- > drivers/ata/dwc_ahci.c | 6 +- > drivers/ata/sata_ceva.c| 3 ++- > drivers/scsi/scsi-uclass.c | 8 > include/ahci.h | 16 > include/scsi.h | 4 +--- > 6 files changed, 44 insertions(+), 19 deletions(-) > Reviewed-by: Bin Meng ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 17/29] dm: ahci: Move common code for starting ports into a function
On Tue, Jun 6, 2017 at 3:15 AM, Simon Glass wrote: > This code is duplicated. Create a ahci_start_ports() function to handle > this and call it from both places. > > Signed-off-by: Simon Glass > --- > > drivers/ata/ahci.c | 45 ++--- > 1 file changed, 22 insertions(+), 23 deletions(-) > Reviewed-by: Bin Meng ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 27/29] dm: ahci: Add a driver for SCSI on AHCI
Hi Simon,
On Tue, Jun 6, 2017 at 3:15 AM, Simon Glass wrote:
> Some AHCI drivers use SCSI under the hood. Rather than making the AHCI
> driver be in the SCSI uclass it makes sense to have the AHCI device create
> a SCSI device as a child. That way we can handle any AHCI-specific
> operations rather than trying to pretend tha the device is just SCSI.
>
> To handle this we need to provide a way for AHCI drivers to bind a SCSI
> device as its child, and probe it. Add functions for this.
>
> Signed-off-by: Simon Glass
> ---
>
> drivers/ata/ahci.c | 52
> include/ahci.h | 22 ++
> 2 files changed, 74 insertions(+)
>
> diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c
> index 3528a1f3da..c67a144f02 100644
> --- a/drivers/ata/ahci.c
> +++ b/drivers/ata/ahci.c
> @@ -23,6 +23,8 @@
> #include
> #include
> #include
> +#include
> +#include
>
> static int ata_io_flush(struct ahci_uc_priv *uc_priv, u8 port);
>
> @@ -1142,10 +1144,60 @@ static int ahci_scsi_bus_reset(struct udevice *dev)
> }
>
> #ifdef CONFIG_DM_SCSI
> +int ahci_bind_scsi(struct udevice *ahci_dev, struct udevice **devp)
> +{
> + struct udevice *dev;
> + int ret;
> +
> + ret = device_bind_driver(ahci_dev, "ahci_scsi", "ahci_scsi", &dev);
> + if (ret)
> + return ret;
> + *devp = dev;
> +
> + return 0;
> +}
> +
> +int ahci_probe_scsi(struct udevice *ahci_dev)
> +{
> + struct ahci_uc_priv *uc_priv;
> + struct scsi_platdata *uc_plat;
> + struct udevice *dev;
> + int ret;
> +
> + device_find_first_child(ahci_dev, &dev);
> + if (!dev)
> + return -ENODEV;
> + uc_plat = dev_get_uclass_platdata(dev);
> + uc_plat->base = (ulong)dm_pci_map_bar(ahci_dev, PCI_BASE_ADDRESS_5,
> + PCI_REGION_MEM);
This assumes AHCI controller is on PCI bus. How about other AHCI
controllers integrated directly into the SoC?
> + uc_plat->max_lun = 1;
> + uc_plat->max_id = 2;
> + uc_priv = dev_get_uclass_priv(dev);
> + ret = ahci_init_one(uc_priv, dev);
> + if (ret)
> + return ret;
> + ret = ahci_start_ports(uc_priv);
> + if (ret)
> + return ret;
> +
> + debug("Scanning %s\n", dev->name);
> + ret = scsi_scan_dev(dev, true);
> + if (ret)
> + return ret;
> +
> + return 0;
> +}
> +
> struct scsi_ops scsi_ops = {
> .exec = ahci_scsi_exec,
> .bus_reset = ahci_scsi_bus_reset,
> };
> +
> +U_BOOT_DRIVER(ahci_scsi) = {
> + .name = "ahci_scsi",
> + .id = UCLASS_SCSI,
> + .ops= &scsi_ops,
> +};
> #else
> int scsi_exec(struct udevice *dev, struct scsi_cmd *pccb)
> {
> diff --git a/include/ahci.h b/include/ahci.h
> index 648e56a4cf..746bff083a 100644
> --- a/include/ahci.h
> +++ b/include/ahci.h
> @@ -203,4 +203,26 @@ int achi_start_ports_dm(struct udevice *dev);
> */
> int ahci_init_dm(struct udevice *dev, void __iomem *base);
>
> +/**
> + * ahci_bind_scsi() - bind a new SCSI bus as a child
> + *
> + * Note that the SCSI bus device will itself bind block devices
> + *
> + * @ahci_dev: AHCI parent device
> + * @devp: Returns new SCSI bus device
> + * @return 0 if OK, -ve on error
> + */
> +int ahci_bind_scsi(struct udevice *ahci_dev, struct udevice **devp);
> +
> +/**
> + * ahci_probe_scsi() - probe and scan the attached SCSI bus
> + *
> + * Note that the SCSI device will itself bind block devices for any storage
> + * devices it finds.
> + *
> + * @ahci_dev: AHCI parent device
> + * @return 0 if OK, -ve on error
> + */
> +int ahci_probe_scsi(struct udevice *ahci_dev);
> +
> #endif
> --
Regards,
Bin
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 21/29] dm: scsi: Add a device pointer to scan_exec(), scsi_bus_reset()
On Tue, Jun 6, 2017 at 3:15 AM, Simon Glass wrote: > With driver model these functions need a device pointer. Add one even > when CONFIG_DM_SCSI is not defined. This avoids having ugly conditional > function prototypes, When CONFIG_DM_SCSI is not defined we can just ignore > the pointer. > > Signed-off-by: Simon Glass > --- > > arch/arm/mach-omap2/sata.c | 4 +++- > cmd/scsi.c | 2 +- > drivers/ata/ahci.c | 13 ++--- > drivers/scsi/sandbox_scsi.c | 5 +++-- > drivers/scsi/scsi.c | 31 +++ > include/scsi.h | 4 ++-- > 6 files changed, 38 insertions(+), 21 deletions(-) > Reviewed-by: Bin Meng ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 13/29] dm: ahci: Rename struct ahci_probe_ent
On Tue, Jun 6, 2017 at 3:15 AM, Simon Glass wrote: > This is not a very useful name since once it is probed it still hangs > around. With driver model we will use uclass data for this, so rename the > struct. > > Signed-off-by: Simon Glass > --- > > board/highbank/ahci.c| 2 +- > drivers/ata/ahci.c | 16 +-- > drivers/ata/dwc_ahsata.c | 74 > > include/ahci.h | 13 - > 4 files changed, 58 insertions(+), 47 deletions(-) > Reviewed-by: Bin Meng ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 11/29] dm: scsi: Drop the ccb typedef
On Tue, Jun 6, 2017 at 3:14 AM, Simon Glass wrote: > We should not be using typedefs in U-Boot and 'ccb' is a pretty short > name. It is also used with variables. Drop the typedef and use 'struct' > instead. > > Signed-off-by: Simon Glass > --- > > common/usb_storage.c| 44 ++-- > drivers/ata/ahci.c | 12 ++-- > drivers/scsi/sandbox_scsi.c | 2 +- > drivers/scsi/scsi.c | 23 --- > include/scsi.h | 6 +++--- > 5 files changed, 44 insertions(+), 43 deletions(-) > Reviewed-by: Bin Meng ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 22/29] dm: scsi: Document and rename the scsi_scan() parameter
On Tue, Jun 6, 2017 at 3:15 AM, Simon Glass wrote: > The 'mode' parameter is actually a flag to determine whether to display > a list of devices found during the scan. Rename it to reflect this, add a > function comment and adjust callers to use a boolean. > > Signed-off-by: Simon Glass > --- > > arch/arm/cpu/armv7/ls102xa/ls102xa_sata.c | 2 +- > arch/arm/cpu/armv8/fsl-layerscape/soc.c | 4 ++-- > board/highbank/highbank.c | 2 +- > cmd/scsi.c| 4 ++-- > common/spl/spl_sata.c | 2 +- > drivers/scsi/scsi.c | 20 ++-- > include/scsi.h| 8 +--- > 7 files changed, 22 insertions(+), 20 deletions(-) > Reviewed-by: Bin Meng ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 14/29] dm: sata: Move ataid into struct ahci_uc_priv
On Tue, Jun 6, 2017 at 3:15 AM, Simon Glass wrote: > This array relates to the AHCI controller so should be exist out on its > own in the file. Move it into the structure. Adjust functions that need > access to this to take the structure as a parameter. > > Signed-off-by: Simon Glass > --- > > drivers/ata/ahci.c | 50 +++--- > include/ahci.h | 1 + > 2 files changed, 28 insertions(+), 23 deletions(-) > Reviewed-by: Bin Meng ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 16/29] dm: scsi: Indent the confusing #ifdefs
On Tue, Jun 6, 2017 at 3:15 AM, Simon Glass wrote: > These are very confusing without some sort of indentation. At some point > we will be able to remove them, but for now, indent them. > > Signed-off-by: Simon Glass > --- > > drivers/scsi/scsi.c | 26 +- > 1 file changed, 13 insertions(+), 13 deletions(-) > Reviewed-by: Bin Meng ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 15/29] dm: ahci: Refactor to avoid static variables
On Tue, Jun 6, 2017 at 3:15 AM, Simon Glass wrote: > With driver model we need each device to have its own state. As a step > towards this, restrict use of the global 'probe_ent' to just a few places > in the file. This will allow us to add driver-model functions which can > pass the correct data around. > > Signed-off-by: Simon Glass > --- > > drivers/ata/ahci.c | 144 > - > 1 file changed, 76 insertions(+), 68 deletions(-) > Reviewed-by: Bin Meng ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 12/29] dm: scsi: Use the uclass platform data
On Tue, Jun 6, 2017 at 3:14 AM, Simon Glass wrote: > At present the two driver-model SCSI drivers use device platform data to > store information that relates to the uclass. It is better to use uclass > platform data in this situation. Update the code to do this. > > Signed-off-by: Simon Glass > --- > > drivers/ata/ahci.c | 2 +- > drivers/ata/dwc_ahci.c | 3 +-- > drivers/ata/sata_ceva.c| 5 ++--- > drivers/scsi/scsi-uclass.c | 1 + > drivers/scsi/scsi.c| 2 +- > 5 files changed, 6 insertions(+), 7 deletions(-) > Reviewed-by: Bin Meng ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 10/29] dm: scsi: Rename struct SCSI_cmd_block to struct scsi_cmd
On Tue, Jun 6, 2017 at 3:14 AM, Simon Glass wrote: > This name should be lower case. Also the _block suffix is superfluous. > Rename it. > > Signed-off-by: Simon Glass > --- > > drivers/usb/emul/sandbox_flash.c | 2 +- > include/scsi.h | 2 +- > 2 files changed, 2 insertions(+), 2 deletions(-) > Reviewed-by: Bin Meng ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 09/29] dm: scsi: Rearrange header file for driver model
On Tue, Jun 6, 2017 at 3:14 AM, Simon Glass wrote: > Put the driver-model declarations first since we are migrating to that. > Also drop scsi_init() when driver model is used. > > Signed-off-by: Simon Glass > --- > > include/scsi.h | 34 ++ > 1 file changed, 14 insertions(+), 20 deletions(-) > Reviewed-by: Bin Meng ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] imx: mx6ull: fix USB bmode for i.MX 6UL and 6ULL
On 2017-06-12 01:51, Esponde, Joel wrote: > Hi Stefan, > > Why did you take the value 0x20 in the table entry instead of the > value 0x00 as it is, for example, in the NXP U-Boot? 0x00 would mean b, which is WEIM (OneNAND/NOR flash, which is probably a likely boot device). 0x20 is no defined boot device, and since it works, it will make sure that bmode usb works for all users of i.MX 6UL/ULL... -- Stefan > > Is it because this boot mode does not exist in the iMX6UL SOC? > > Joël Esponde > Honeywell | Safety and Productivity Solutions > >> -Message d'origine- >> De : Fabio Estevam [mailto:feste...@gmail.com] >> Envoyé : samedi 10 juin 2017 00:10 >> À : Stefan Agner ; Esponde, Joel >> >> Cc : Stefano Babic ; Fabio Estevam >> ; Stefan Agner ; U- >> Boot-Denx >> Objet : Re: [U-Boot] [PATCH] imx: mx6ull: fix USB bmode for i.MX 6UL and >> 6ULL >> >> On Fri, Jun 9, 2017 at 5:13 PM, Stefan Agner wrote: >> > From: Stefan Agner >> > >> > i.MX 6UL and 6ULL have different boot device capabilities and use >> > therefor use a different boot device selection table than other i.MX 6 >> > devices. Particularly, the value which has been used so far (b0001) is >> > assigned to QSPI boot for these two devices. >> > >> > There is no common reserved value for all i.MX 6devices. Use >> > b0010 for i.MX 6UL and 6ULL via compile time ifdef. >> > >> > Reported-by: Joël Esponde >> > Signed-off-by: Stefan Agner >> >> Thanks for the patch. >> >> Joël, could you please test it and reply with your Tested-by? >> >> Thanks ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 06/29] Kconfig: Add CONFIG_SATA to enable SATA
On Tue, Jun 6, 2017 at 3:14 AM, Simon Glass wrote: > At present CONFIG_CMD_SATA enables the 'sata' command which also brings > in SATA support. Some boards may wish to enable SATA without the command. > Add a separate CONFIG to permit this. > > Signed-off-by: Simon Glass > --- > > api/api_storage.c | 2 +- > arch/arm/cpu/armv7/mx6/clock.c| 6 +++--- > arch/arm/imx-common/Makefile | 2 +- > arch/arm/imx-common/cpu.c | 2 +- > arch/powerpc/cpu/mpc85xx/cpu_init.c | 2 +- > board/advantech/dms-ba16/dms-ba16.c | 2 +- > board/bachmann/ot1200/ot1200.c| 2 +- > board/boundary/nitrogen6x/nitrogen6x.c| 2 +- > board/congatec/cgtqmx6eval/cgtqmx6eval.c | 2 +- > board/gateworks/gw_ventana/gw_ventana.c | 2 +- > board/kosagi/novena/novena.c | 2 +- > board/toradex/apalis_imx6/apalis_imx6.c | 2 +- > board/toradex/colibri_imx6/colibri_imx6.c | 2 +- > board/udoo/udoo.c | 2 +- > board/wandboard/wandboard.c | 2 +- > cmd/Kconfig | 1 + > common/Makefile | 2 +- > common/splash_source.c| 2 +- > drivers/block/Kconfig | 15 ++- > fs/fat/fat.c | 2 +- > include/config_distro_bootcmd.h | 6 +++--- > include/config_fallbacks.h| 2 +- > 22 files changed, 39 insertions(+), 25 deletions(-) > Reviewed-by: Bin Meng ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 08/29] scsi: Move drivers into new drivers/scsi directory
On Tue, Jun 6, 2017 at 3:14 AM, Simon Glass wrote:
> At present we have the SCSI drivers in the drivers/block and common/
> directories. It is better to split them out into their own place. Use
> drivers/scsi which is what Linux does.
>
> Signed-off-by: Simon Glass
> ---
>
> common/Makefile| 4
> drivers/Kconfig| 2 ++
> drivers/Makefile | 3 ++-
> drivers/block/Kconfig | 18 --
> drivers/block/Makefile | 2 +-
> drivers/scsi/Kconfig | 17 +
> drivers/scsi/Makefile | 19 +++
> drivers/{block => scsi}/sandbox_scsi.c | 0
> drivers/{block => scsi}/scsi-uclass.c | 0
> {common => drivers/scsi}/scsi.c| 0
> 10 files changed, 41 insertions(+), 24 deletions(-)
> create mode 100644 drivers/scsi/Kconfig
> create mode 100644 drivers/scsi/Makefile
> rename drivers/{block => scsi}/sandbox_scsi.c (100%)
> rename drivers/{block => scsi}/scsi-uclass.c (100%)
> rename {common => drivers/scsi}/scsi.c (100%)
>
Reviewed-by: Bin Meng
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 04/29] scsi: Drop scsi_print_error()
On Tue, Jun 6, 2017 at 3:14 AM, Simon Glass wrote: > This function is only defined by one driver and is empty. Move it into > the SCSI implementation itself. We could remove it, but it should be > useful for debugging. > > Signed-off-by: Simon Glass > --- > > common/scsi.c| 5 + > drivers/block/ahci.c | 5 - > drivers/block/sandbox_scsi.c | 4 > include/scsi.h | 1 - > 4 files changed, 5 insertions(+), 10 deletions(-) > Reviewed-by: Bin Meng ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 07/29] sata: Move drivers into new drivers/ata directory
On Tue, Jun 6, 2017 at 3:14 AM, Simon Glass wrote:
> At present we have the SATA and PATA drivers mixed up in the drivers/block
> directory. It is better to split them out into their own place. Use
> drivers/ata which is what Linux does.
>
> Signed-off-by: Simon Glass
> ---
>
> arch/powerpc/cpu/mpc85xx/cpu_init.c | 2 +-
> common/Makefile | 1 -
> drivers/Kconfig | 2 ++
> drivers/Makefile | 3 +-
> drivers/ata/Kconfig | 62
> +++
> drivers/ata/Makefile | 22 +
> drivers/{block => ata}/ahci-uclass.c | 0
> drivers/{block => ata}/ahci.c | 0
> drivers/{block => ata}/dwc_ahci.c | 0
> drivers/{block => ata}/dwc_ahsata.c | 0
> drivers/{block => ata}/dwc_ahsata.h | 0
> drivers/{block => ata}/fsl_sata.c | 0
> drivers/{block => ata}/fsl_sata.h | 0
> drivers/{block => ata}/libata.c | 0
> drivers/{block => ata}/mvsata_ide.c | 0
> drivers/{block => ata}/mxc_ata.c | 0
> {common => drivers/ata}/sata.c| 0
> drivers/{block => ata}/sata_ceva.c| 0
> drivers/{block => ata}/sata_dwc.c | 0
> drivers/{block => ata}/sata_dwc.h | 0
> drivers/{block => ata}/sata_mv.c | 0
> drivers/{block => ata}/sata_sandbox.c | 0
> drivers/{block => ata}/sata_sil.c | 0
> drivers/{block => ata}/sata_sil.h | 0
> drivers/{block => ata}/sata_sil3114.c | 0
> drivers/{block => ata}/sata_sil3114.h | 0
> drivers/block/Kconfig | 45 -
> drivers/block/Makefile| 16 +
> 28 files changed, 90 insertions(+), 63 deletions(-)
> create mode 100644 drivers/ata/Kconfig
> create mode 100644 drivers/ata/Makefile
> rename drivers/{block => ata}/ahci-uclass.c (100%)
> rename drivers/{block => ata}/ahci.c (100%)
> rename drivers/{block => ata}/dwc_ahci.c (100%)
> rename drivers/{block => ata}/dwc_ahsata.c (100%)
> rename drivers/{block => ata}/dwc_ahsata.h (100%)
> rename drivers/{block => ata}/fsl_sata.c (100%)
> rename drivers/{block => ata}/fsl_sata.h (100%)
> rename drivers/{block => ata}/libata.c (100%)
> rename drivers/{block => ata}/mvsata_ide.c (100%)
> rename drivers/{block => ata}/mxc_ata.c (100%)
> rename {common => drivers/ata}/sata.c (100%)
> rename drivers/{block => ata}/sata_ceva.c (100%)
> rename drivers/{block => ata}/sata_dwc.c (100%)
> rename drivers/{block => ata}/sata_dwc.h (100%)
> rename drivers/{block => ata}/sata_mv.c (100%)
> rename drivers/{block => ata}/sata_sandbox.c (100%)
> rename drivers/{block => ata}/sata_sil.c (100%)
> rename drivers/{block => ata}/sata_sil.h (100%)
> rename drivers/{block => ata}/sata_sil3114.c (100%)
> rename drivers/{block => ata}/sata_sil3114.h (100%)
>
Reviewed-by: Bin Meng
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 05/29] Convert CONFIG_CMD_SATA to Kconfig
On Tue, Jun 6, 2017 at 3:14 AM, Simon Glass wrote: > This converts the following to Kconfig: >CONFIG_CMD_SATA > > Signed-off-by: Simon Glass > --- > > arch/Kconfig | 1 + > arch/arm/cpu/armv7/mx6/Kconfig | 4 ++ > arch/arm/mach-mvebu/Kconfig| 2 + > arch/powerpc/cpu/mpc83xx/Kconfig | 1 + > arch/powerpc/cpu/mpc85xx/Kconfig | 45 > ++ > cmd/Kconfig| 12 ++ > configs/MPC8315ERDB_defconfig | 1 + > configs/MPC8349ITX_LOWBOOT_defconfig | 1 + > configs/MPC8349ITX_defconfig | 1 + > configs/MPC837XERDB_defconfig | 1 + > configs/canyonlands_defconfig | 1 + > configs/cgtqmx6eval_defconfig | 1 + > configs/cm_fx6_defconfig | 1 + > .../controlcenterd_36BIT_SDCARD_DEVELOP_defconfig | 1 + > configs/controlcenterd_36BIT_SDCARD_defconfig | 1 + > configs/db-mv784mp-gp_defconfig| 1 + > configs/m53evk_defconfig | 1 + > configs/mx53loco_defconfig | 1 + > configs/mx6qsabrelite_defconfig| 1 + > configs/nitrogen6q2g_defconfig | 1 + > configs/nitrogen6q_defconfig | 1 + > configs/novena_defconfig | 1 + > configs/tbs2910_defconfig | 1 + > configs/udoo_defconfig | 1 + > configs/wandboard_defconfig| 1 + > include/configs/MPC8315ERDB.h | 1 - > include/configs/MPC8349ITX.h | 4 -- > include/configs/MPC837XEMDS.h | 1 - > include/configs/MPC837XERDB.h | 1 - > include/configs/MPC8536DS.h| 1 - > include/configs/P1010RDB.h | 1 - > include/configs/P1022DS.h | 1 - > include/configs/P2041RDB.h | 1 - > include/configs/P4080DS.h | 1 - > include/configs/T102xQDS.h | 1 - > include/configs/T1040QDS.h | 1 - > include/configs/T104xRDB.h | 1 - > include/configs/T208xQDS.h | 1 - > include/configs/T208xRDB.h | 1 - > include/configs/T4240QDS.h | 1 - > include/configs/T4240RDB.h | 2 - > include/configs/UCP1020.h | 1 - > include/configs/advantech_dms-ba16.h | 1 - > include/configs/apalis_imx6.h | 4 -- > include/configs/canyonlands.h | 1 - > include/configs/cgtqmx6eval.h | 1 - > include/configs/cm_fx6.h | 1 - > include/configs/controlcenterd.h | 1 - > include/configs/corenet_ds.h | 1 - > include/configs/cyrus.h| 1 - > include/configs/db-mv784mp-gp.h| 1 - > include/configs/gw_ventana.h | 1 - > include/configs/m53evk.h | 1 - > include/configs/mx53loco.h | 1 - > include/configs/nitrogen6x.h | 4 -- > include/configs/novena.h | 1 - > include/configs/ot1200.h | 4 -- > include/configs/p1_p2_rdb_pc.h | 1 - > include/configs/p1_twr.h | 1 - > include/configs/sandbox.h | 1 - > include/configs/t4qds.h| 1 - > include/configs/tbs2910.h | 1 - > include/configs/theadorable.h | 1 - > include/configs/udoo.h | 1 - > include/configs/wandboard.h| 1 - > scripts/config_whitelist.txt | 1 - > 66 files changed, 84 insertions(+), 54 deletions(-) > Reviewed-by: Bin Meng ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 03/29] scsi: Drop sym53c8xx driver
On Tue, Jun 6, 2017 at 3:14 AM, Simon Glass wrote: > This driver is for a PowerPC board that will likely be removed soon. > Rather than converting it to driver model, drop it. > > Signed-off-by: Simon Glass > --- > > README | 5 - > board/mpl/pip405/README | 5 +- > common/scsi.c| 9 +- > configs/PIP405_defconfig | 1 - > drivers/block/Makefile | 1 - > drivers/block/sym53c8xx.c| 851 > --- > include/configs/PIP405.h | 9 - > scripts/config_whitelist.txt | 2 - > 8 files changed, 3 insertions(+), 880 deletions(-) > delete mode 100644 drivers/block/sym53c8xx.c > Reviewed-by: Bin Meng ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 02/29] Convert CONFIG_SCSI to Kconfig
Hi Simon, On Tue, Jun 6, 2017 at 3:14 AM, Simon Glass wrote: > This converts the following to Kconfig: >CONFIG_SCSI > > Signed-off-by: Simon Glass > --- > > README | 1 - > arch/Kconfig| 1 + > arch/arm/Kconfig| 10 ++ > arch/arm/cpu/armv7/ls102xa/Kconfig | 1 + > arch/arm/cpu/armv8/fsl-layerscape/Kconfig | 2 ++ > arch/arm/include/asm/arch-ls102xa/config.h | 1 - > arch/arm/mach-mvebu/Kconfig | 2 ++ > arch/arm/mach-omap2/omap5/Kconfig | 2 ++ > arch/powerpc/cpu/mpc85xx/Kconfig| 1 + > arch/powerpc/cpu/mpc86xx/Kconfig| 1 + > board/congatec/Kconfig | 1 + > board/dfi/Kconfig | 1 + > configs/A10-OLinuXino-Lime_defconfig| 1 + > configs/A20-OLinuXino-Lime2_defconfig | 1 + > configs/A20-OLinuXino-Lime_defconfig| 1 + > configs/A20-OLinuXino_MICRO_defconfig | 1 + > configs/A20-Olimex-SOM-EVB_defconfig| 1 + > configs/Bananapi_M2_Ultra_defconfig | 1 + > configs/Bananapi_defconfig | 1 + > configs/Bananapro_defconfig | 1 + > configs/Cubieboard2_defconfig | 1 + > configs/Cubieboard_defconfig| 1 + > configs/Cubietruck_defconfig| 1 + > configs/Itead_Ibox_A20_defconfig| 1 + > configs/Lamobo_R1_defconfig | 1 + > configs/Linksprite_pcDuino3_Nano_defconfig | 1 + > configs/Linksprite_pcDuino3_defconfig | 1 + > configs/MPC8544DS_defconfig | 1 + > configs/MPC8610HPCD_defconfig | 1 + > configs/Marsboard_A10_defconfig | 1 + > configs/Mele_A1000_defconfig| 1 + > configs/Mele_M5_defconfig | 1 + > configs/Orangepi_defconfig | 1 + > configs/Orangepi_mini_defconfig | 1 + > configs/PIP405_defconfig| 1 + > configs/Wits_Pro_A20_DKT_defconfig | 1 + > configs/bayleybay_defconfig | 1 + > configs/chromebook_link64_defconfig | 1 + > configs/chromebook_link_defconfig | 1 + > configs/chromebook_samus_defconfig | 1 + > configs/chromebox_panther_defconfig | 1 + > configs/cm_t54_defconfig| 1 + > configs/controlcenterdc_defconfig | 1 + > configs/cougarcanyon2_defconfig | 1 + > configs/crownbay_defconfig | 1 + > configs/db-88f6820-gp_defconfig | 1 + > configs/highbank_defconfig | 1 + > configs/ls1012aqds_qspi_defconfig | 1 + > configs/ls2081ardb_defconfig| 1 + > configs/minnowmax_defconfig | 1 + > configs/omap5_uevm_defconfig| 1 + > configs/som-db5800-som-6867_defconfig | 1 + > configs/xilinx_zynqmp_ep_defconfig | 1 + > configs/xilinx_zynqmp_zcu102_defconfig | 1 + > configs/xilinx_zynqmp_zcu102_revB_defconfig | 1 + > drivers/block/Kconfig | 9 + > include/config_cmd_all.h| 1 - > include/configs/MPC8544DS.h | 1 - > include/configs/MPC8572DS.h | 1 - > include/configs/MPC8610HPCD.h | 1 - > include/configs/MPC8641HPCN.h | 1 - > include/configs/PIP405.h| 1 - > include/configs/am57xx_evm.h| 1 - > include/configs/cm_t54.h| 1 - > include/configs/controlcenterdc.h | 1 - > include/configs/db-88f6820-gp.h | 1 - > include/configs/dra7xx_evm.h| 1 - > include/configs/efi-x86.h | 1 - > include/configs/galileo.h | 1 - > include/configs/highbank.h | 1 - > include/configs/ls1012aqds.h| 1 - > include/configs/ls1012ardb.h| 1 - > include/configs/ls1043aqds.h| 1 - > include/configs/ls1046aqds.h| 1 - > include/configs/ls1046ardb.h| 1 - > include/configs/ls2080aqds.h| 1 - > include/configs/ls2080ardb.h| 1 - > include/configs/mvebu_armada-37xx.h | 1 - > include/configs/mvebu_armada-8k.h | 1 - > include/configs/omap5_uevm.h| 1 - > include/configs/qemu-x86.h | 1 - > include/configs/sandbox.h | 1 - > include/configs/sunxi-common.h | 1 - > include/configs/x86-common.h| 1 - > include/configs/xilinx_zynqmp.h | 1 - > scripts/config_whitelist.txt| 1 - > 86 files changed, 74 insertions(+), 32 deletions(-) > Reviewed-by: Bin Meng But please see nits below. > diff --git a/README b/README > index 075d919df3..750b7351fe 1
Re: [U-Boot] [PATCH 2/2] mmc: rpmb: update size format for write_counter
Hi Simon,
On 06/09/2017 08:28 PM, Simon Glass wrote:
On 7 June 2017 at 19:20, Kever Yang wrote:
According to MMC spec, the write_counter is 4-byte length,
use 'int' instead of 'long' type for the 'long' is not 4-byte
in 64 bit CPU.
Signed-off-by: Jason Zhu
Signed-off-by: Kever Yang
---
drivers/mmc/rpmb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
So should we use uint32_t?
Yes, we can use uint32_t, I use 'unsigned int' just for the same format
with other
members in the structure which using unsigned char/short.
Is there a doc for which kind of data format prefer to use first in U-Boot?
unsigned int, uint32_t, u32;
Thanks,
- Kever
diff --git a/drivers/mmc/rpmb.c b/drivers/mmc/rpmb.c
index 1c6888f..0b6b622 100644
--- a/drivers/mmc/rpmb.c
+++ b/drivers/mmc/rpmb.c
@@ -67,7 +67,7 @@ struct s_rpmb {
unsigned char mac[RPMB_SZ_MAC];
unsigned char data[RPMB_SZ_DATA];
unsigned char nonce[RPMB_SZ_NONCE];
- unsigned long write_counter;
+ unsigned int write_counter;
unsigned short address;
unsigned short block_count;
unsigned short result;
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] rockchip: clk: rk3036: correct setting for pll integer mode
According to rk3036 TRM, pll_con1[12] should be set to '1' for the pll
integer mode, while the '0' means the frac mode.
series-version: 2
series-changes: 2
- fix tpyo interger/integer
Signed-off-by: Kever Yang
Reviewed-by: Philipp Tomsich
Acked-by: Simon Glass
---
drivers/clk/rockchip/clk_rk3036.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/clk/rockchip/clk_rk3036.c
b/drivers/clk/rockchip/clk_rk3036.c
index 28652df..5ecf512 100644
--- a/drivers/clk/rockchip/clk_rk3036.c
+++ b/drivers/clk/rockchip/clk_rk3036.c
@@ -40,7 +40,7 @@ enum {
#hz "Hz cannot be hit with PLL "\
"divisors on line " __stringify(__LINE__));
-/* use interge mode*/
+/* use integer mode*/
static const struct pll_div apll_init_cfg = PLL_DIVISORS(APLL_HZ, 1, 3, 1);
static const struct pll_div gpll_init_cfg = PLL_DIVISORS(GPLL_HZ, 2, 2, 1);
@@ -61,8 +61,8 @@ static int rkclk_set_pll(struct rk3036_cru *cru, enum
rk_clk_id clk_id,
assert(vco_hz >= VCO_MIN_HZ && vco_hz <= VCO_MAX_HZ &&
output_hz >= OUTPUT_MIN_HZ && output_hz <= OUTPUT_MAX_HZ);
- /* use interger mode */
- rk_clrreg(&pll->con1, 1 << PLL_DSMPD_SHIFT);
+ /* use integer mode */
+ rk_setreg(&pll->con1, 1 << PLL_DSMPD_SHIFT);
rk_clrsetreg(&pll->con0,
PLL_POSTDIV1_MASK | PLL_FBDIV_MASK,
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, RFC, 2/5] rockchip: boot0: align to 0x20 for armv7 '_start'
Hi Philipp, On 06/10/2017 02:47 AM, Philipp Tomsich wrote: On Wed, 31 May 2017, Kever Yang wrote: The '_start' is using as vector table base address, and will write to VBAR register, need to align to 0x20 for armv7. Signed-off-by: Kever Yang --- arch/arm/include/asm/arch-rockchip/boot0.h | 9 - 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/arch/arm/include/asm/arch-rockchip/boot0.h b/arch/arm/include/asm/arch-rockchip/boot0.h index 7346876..88f0ff6 100644 --- a/arch/arm/include/asm/arch-rockchip/boot0.h +++ b/arch/arm/include/asm/arch-rockchip/boot0.h @@ -13,10 +13,17 @@ */ #ifdef CONFIG_SPL_BUILD -.space 0x4 /* space for the 'RK33' */ +.space 0x4 /* space for Rockchip SoC tag like 'RK33' */ #endif b reset +/* For armv7, the addr '_start' will used as vector start address + * and write to VBAR register, which need to aligned to 0x20. + */ +#ifdef CONFIG_CPU_V7 +.align(5) +#endif + #if defined(CONFIG_ROCKCHIP_RK3399) && defined(CONFIG_SPL_BUILD) .space CONFIG_ROCKCHIP_SPL_RESERVE_IRAM/* space for the ATF data */ #endif You'll need to adapt this for whatever fix we decide on for those platforms that need their boot0-hook after the vector-table (e.g. socfpga). Thanks very much for your review and comments, I know we need fix other platforms like socfpga, bcm and sunxi, that's why this patch set prefixed with 'RFC'. It looks like the U-Boot mailing list is not very active and there is not response from bcm or sunxi although I CCed the author who commit the patch for boot0-hook in other platform, and Marek only replied with "you broke socfpga" without a solution. Maybe I need to wait more time. Thanks, - Kever Reviewed-by: Philipp Tomsich ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 1/5] armv7: move boot hook before '_start'
Hi Marek, On 06/07/2017 02:28 PM, Marek Vasut wrote: On 06/07/2017 04:28 AM, Kever Yang wrote: Hi Andre, Steve, Marek, Could you help to check how to make it work with this patch on sunxi, bcm and socfpga platform? The socfpga expects the hook at that exact position (0x40 I think) , so if you moved it somewhere, you broke socfpga. I know this break socfpga, and that's why I cc you for help, could you help the take a look if we can have a solution on socfpga to "make it work with this patch"? Comments from Philipp[0] show that its reasonable for this patch set, I don't know how the boot0-hook works in socfpga and also sunxi and bcm, could you help me to fix the hook content upon this patch? Thanks, - Kever [0]https://www.mail-archive.com/u-boot@lists.denx.de/msg252823.html Thanks, - Kever On 05/31/2017 06:50 PM, Kever Yang wrote: The boot0 hook suppose to add some data before the SPL data, let's move it at very begining and before '_start'. Signed-off-by: Kever Yang --- arch/arm/lib/vectors.S | 19 ++- 1 file changed, 10 insertions(+), 9 deletions(-) diff --git a/arch/arm/lib/vectors.S b/arch/arm/lib/vectors.S index f53b1e9..b4cd825 100644 --- a/arch/arm/lib/vectors.S +++ b/arch/arm/lib/vectors.S @@ -35,6 +35,16 @@ .section ".vectors", "ax" +#ifdef CONFIG_ENABLE_ARM_SOC_BOOT0_HOOK +/* + * Various SoCs need something special and SoC-specific up front in + * order to boot, allow them to set that in their boot0.h file and then + * use it here. + */ +#include + +#endif + /* * * @@ -60,15 +70,6 @@ _start: ldrpc, _irq ldrpc, _fiq -#ifdef CONFIG_ENABLE_ARM_SOC_BOOT0_HOOK -/* - * Various SoCs need something special and SoC-specific up front in - * order to boot, allow them to set that in their boot0.h file and then - * use it here. - */ -#include -#endif - /* * * ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 0/5] move boot0 hook in the beginning for armv7
Hi Simon, On 06/09/2017 08:27 PM, Simon Glass wrote: Hi Kever, On 7 June 2017 at 04:55, Kever Yang wrote: Simon, On 06/07/2017 11:15 AM, Simon Glass wrote: Hi Kever, On 6 June 2017 at 20:41, Kever Yang wrote: Simon, On 06/07/2017 05:08 AM, Simon Glass wrote: Hi Kever, On 31 May 2017 at 04:50, Kever Yang wrote: I think the boot0 hook is suppose to add some data in the very beginning of the SPL image, am I right? Rockchip SoCs bootrom design is like this: - First 2KB or 4KB internal memory is for bootrom stack and heap; - Then the first 4-byte suppose to be a TAG like 'RK33'; - The the following memory address end with '0004' is the first instruction load and running by bootrom; Example for RK3288: Before this patch set, the SPL_TEXT_BASE is ff704004, and image write to media device after mkimage like this: ff704000: 32334b52 RK32 ff704010: ff704020: ea0f e59ff014 e59ff014 e59ff014 ff704030: e59ff014 e59ff014 e59ff014 e59ff014 Where the first instruction from bootrom is '', which is a undefined instruction. The '_start' and 'reset' have to align to 0x20 for the requirement of VBAR, the memory offset '004'~'01c' are filled with ''. We can use the boot0 hook to fix this issue, after this patch set, the SPL_TEXT_BASE is ff704000 and image write to media device after mkimage like this: ff704000: 32334b52 ea1d e320f000 e320f000RK32.. ... . ff704010: e320f000 e320f000 e320f000 e320f000.. ... ... ... . ff704020: ea16 e59ff014 e59ff014 e59ff014 ff704030: e59ff014 e59ff014 e59ff014 e59ff014 The first instruction from bootrom is a 'b reset', and memory of '008'~'01c' are filled with 'nop' instruction. This patch set does not provide patch for socfpga, bcm and sunxi SoCs which also enable BOOT0_HOOK, so this is a RFC patch, please advice how to make it compatible with those three platforms. Kever Yang (5): armv7: move boot hook before '_start' rockchip: boot0: align to 0x20 for armv7 '_start' rockchip: enable BOOT0_HOOK for SoCs rockchip: configs: use aligned address for SPL_TEXT_BASE rockchip: mkimage: use spl_boot0 for all Rockchip SoCs arch/arm/include/asm/arch-rockchip/boot0.h | 9 - arch/arm/lib/vectors.S | 19 ++- arch/arm/mach-rockchip/Kconfig | 3 +++ include/configs/rk3036_common.h| 2 +- include/configs/rk3288_common.h| 2 +- tools/rkcommon.c | 8 6 files changed, 27 insertions(+), 16 deletions(-) -- 1.9.1 Do will still need this series now that (I think) we have a fix for the return-to-brom feature in u-boot-rockchip/master? Could you point me out exactly which fix do you talking about? These ones: a079e52d35 rockchip: mkimage: set init_boot_size to avoid confusing the boot ROM ee2c63912b rockchip: mkimage: force 2KB alignment for init_size 99c700c794 rockchip: mkimage: add support for verify_header/print_header This is not about return-to-brom, it's about the first instruction from Bootrom to SPL. So this is need for all Rockchip armv7 SoCs. OK, how did we survive before? What has changed to make this series needed? After check with JTAG, I find that I'm wrong with cmd code '', this is 'andeq r0, r0, r0', but not undefined in armv7, so it can work. I still want this patch set applied because it's better to make all the Rockchip's SPL have the same format(with 4-byte TAG space reserved), and the ddr binary from Rockchip always have pre-padding 4-byte TAG, with this patch set, we can replace each other easily and work with one mkimage tool. I'm not sure how to apply this since on the other thread[1] Marek says it will break socfpga. I know this must break socfpga platform, and as I have said in cover letter, I think this patch also break bcm and sunxi platform, I add 'RFC' for this patch set because I don't know the detail requirement of hook0 for other 3 platform, I'm not asking if this patch set break other 3 platforms or not, but I'm asking for the solution for those 3 platform so that we can apply this patch set. I think my patch is correct in what HOOK0 wants to do, just like Philipp's opinion in another mail. I hope to get help from maintainer for socfpga, bcm, sunxi platform. Thanks, - Kever Would it be possible to change the DDR binary to not include the padding? Regards, Simon [1] armv7: move boot hook before '_start' ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 01/29] configs: Resync with savedefconfig
+Tom Hi Tom, On Tue, Jun 6, 2017 at 3:14 AM, Simon Glass wrote: > Rsync all defconfig files using moveconfig.py > > Signed-off-by: Simon Glass > --- > > configs/Sinovoip_BPI_M2_Plus_defconfig | 1 - > configs/UCP1020_SPIFLASH_defconfig | 2 +- > configs/UCP1020_defconfig| 2 +- > configs/adp-ae3xx_defconfig | 6 +-- > configs/adp-ag101p_defconfig | 6 +-- > configs/am335x_baltos_defconfig | 4 +- > configs/am335x_boneblack_vboot_defconfig | 1 - > configs/am335x_evm_defconfig | 1 - > configs/am335x_hs_evm_defconfig | 4 -- > configs/am335x_igep003x_defconfig| 6 +-- > configs/am335x_shc_defconfig | 4 +- > configs/am335x_shc_ict_defconfig | 4 +- > configs/am335x_shc_netboot_defconfig | 4 +- > configs/am335x_shc_prompt_defconfig | 4 +- > configs/am335x_shc_sdboot_defconfig | 4 +- > configs/am335x_shc_sdboot_prompt_defconfig | 4 +- > configs/am335x_sl50_defconfig| 4 +- > configs/am43xx_evm_defconfig | 3 +- > configs/am43xx_evm_usbhost_boot_defconfig| 1 - > configs/am43xx_hs_evm_defconfig | 3 +- > configs/am57xx_evm_defconfig | 5 +- > configs/am57xx_hs_evm_defconfig | 5 +- > configs/at91sam9263ek_norflash_boot_defconfig| 2 +- > configs/at91sam9263ek_norflash_defconfig | 2 +- > configs/bcm958622hr_defconfig| 2 +- > configs/birdland_bav335a_defconfig | 2 +- > configs/birdland_bav335b_defconfig | 2 +- > configs/blanche_defconfig| 1 - > configs/brppt1_mmc_defconfig | 2 +- > configs/brppt1_nand_defconfig| 2 +- > configs/brppt1_spi_defconfig | 2 +- > configs/brxre1_defconfig | 2 +- > configs/chiliboard_defconfig | 4 +- > configs/chromebook_minnie_defconfig | 2 +- > configs/clearfog_defconfig | 2 - > configs/cm_fx6_defconfig | 2 +- > configs/cm_t335_defconfig| 2 +- > configs/cm_t43_defconfig | 2 +- > configs/colibri_imx7_defconfig | 2 +- > configs/colibri_vf_defconfig | 2 +- > configs/comtrend_ar5387un_ram_defconfig | 66 ++- > configs/comtrend_ct5361_ram_defconfig| 68 > ++-- > configs/comtrend_vr3032u_ram_defconfig | 66 ++- > configs/dra7xx_evm_defconfig | 12 ++--- > configs/dra7xx_hs_evm_defconfig | 9 ++-- > configs/evb-ast2500_defconfig| 12 ++--- > configs/evb-rk3399_defconfig | 5 +- > configs/firefly-rk3399_defconfig | 1 - > configs/gwventana_emmc_defconfig | 2 +- > configs/gwventana_gw5904_defconfig | 2 +- > configs/gwventana_nand_defconfig | 2 +- > configs/huawei_hg556a_ram_defconfig | 67 ++- > configs/imx6qdl_icore_mmc_defconfig | 4 +- > configs/imx6qdl_icore_rqs_mmc_defconfig | 2 +- > configs/k2e_evm_defconfig| 5 +- > configs/k2e_hs_evm_defconfig | 3 +- > configs/k2g_evm_defconfig| 5 +- > configs/k2g_hs_evm_defconfig | 6 +-- > configs/k2hk_evm_defconfig | 4 +- > configs/k2hk_hs_evm_defconfig| 3 +- > configs/k2l_evm_defconfig| 4 +- > configs/ls2081ardb_defconfig | 13 ++--- > configs/ls2088ardb_qspi_defconfig| 13 ++--- > configs/m53evk_defconfig | 2 +- > configs/mx51evk_defconfig| 2 +- > configs/mx53cx9020_defconfig | 2 +- > configs/mx53loco_defconfig | 2 +- > configs/mx6cuboxi_defconfig | 2 +- > configs/mx6sxsabresd_defconfig | 2 +- > configs/mx6sxsabresd_spl_defconfig | 2 +- > configs/mx7dsabresd_defconfig| 2 +- > configs/nanopi_neo_air_defconfig | 2 +- > configs/nanopi_neo_defconfig | 2 +- > configs/netgear_cg3100d_ram_defconfig| 66 ++- > configs/novena_defconfig | 2 +- > configs/omap3_logic_defconfig| 1 - > configs/opos6uldev_defconfig | 2 +- > configs/orangepi_2_defconfig | 1 - > configs/orangepi_lite_defconfig
Re: [U-Boot] [PATCH v2 3/3] test: Add a test for snprintf() and the banner/version
On Sun, Jun 11, 2017 at 1:59 AM, Simon Glass wrote: > Add a simple test to make sure that these functions obey the buffer size > passed into them. > > Signed-off-by: Simon Glass > --- > > Changes in v2: > - Fix buffer overflow problem when there is not enough space for the build tag > - Add test to check for buffer overflow problems > > test/Makefile | 1 + > test/print_ut.c | 83 > + > 2 files changed, 84 insertions(+) > create mode 100644 test/print_ut.c > Reviewed-by: Bin Meng ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/3] Allow displaying the U-Boot banner on a video display
Hi Simon,
On Mon, Jun 12, 2017 at 11:17 PM, Simon Glass wrote:
> Hi Bin,
>
> On 12 June 2017 at 09:13, Bin Meng wrote:
>> Hi Simon,
>>
>> On Sun, Jun 11, 2017 at 1:59 AM, Simon Glass wrote:
>>> At present the U-Boot banner is only displayed on the serial console. If
>>> this is not visible to the user, the banner does not show. Some devices
>>> have a video display which can usefully display this information.
>>>
>>> Add a banner which is printed after relocation only on non-serial devices
>>> if CONFIG_DISPLAY_BOARDINFO_LATE is defined.
>>>
>>> Signed-off-by: Simon Glass
>>> ---
>>>
>>> Changes in v2:
>>> - Reword function comment for console_announce_r() slighty
>>>
>>> common/board_r.c | 1 +
>>> common/console.c | 15 +++
>>> include/console.h | 12
>>> 3 files changed, 24 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/common/board_r.c b/common/board_r.c
>>> index 15977e4bca..ff11eba5d3 100644
>>> --- a/common/board_r.c
>>> +++ b/common/board_r.c
>>> @@ -846,6 +846,7 @@ static init_fnc_t init_sequence_r[] = {
>>> #endif
>>> console_init_r, /* fully init console as a device */
>>> #ifdef CONFIG_DISPLAY_BOARDINFO_LATE
>>> + console_announce_r,
>>> show_board_info,
>>> #endif
>>> #ifdef CONFIG_ARCH_MISC_INIT
>>> diff --git a/common/console.c b/common/console.c
>>> index 1232808df5..3fcd7ce66b 100644
>>> --- a/common/console.c
>>> +++ b/common/console.c
>>> @@ -202,7 +202,6 @@ static void console_putc(int file, const char c)
>>> }
>>> }
>>>
>>> -#if CONFIG_IS_ENABLED(PRE_CONSOLE_BUFFER)
>>
>> Why removing this? Without PRE_CONSOLE_BUFFER, I doubt it works.
>
> I want to be able to call the function below. It seems to work OK and
> it doesn't rely on that option.
>
See comments below.
>>
>>> static void console_puts_noserial(int file, const char *s)
>>> {
>>> int i;
>>> @@ -214,7 +213,6 @@ static void console_puts_noserial(int file, const char
>>> *s)
>>> dev->puts(dev, s);
>>> }
>>> }
>>> -#endif
>>>
>>> static void console_puts(int file, const char *s)
>>> {
>>> @@ -248,13 +246,11 @@ static inline void console_putc(int file, const char
>>> c)
>>> stdio_devices[file]->putc(stdio_devices[file], c);
>>> }
>>>
>>> -#if CONFIG_IS_ENABLED(PRE_CONSOLE_BUFFER)
>>> static inline void console_puts_noserial(int file, const char *s)
>>> {
>>> if (strcmp(stdio_devices[file]->name, "serial") != 0)
>>> stdio_devices[file]->puts(stdio_devices[file], s);
>>> }
>>> -#endif
>>>
>>> static inline void console_puts(int file, const char *s)
>>> {
>>> @@ -699,6 +695,17 @@ static void console_update_silent(void)
>>> #endif
>>> }
>>>
>>> +int console_announce_r(void)
>>> +{
>>> + char buf[DISPLAY_OPTIONS_BANNER_LENGTH];
>>> +
>>> + display_options_get_banner(false, buf, sizeof(buf));
>>> +
>>> + console_puts_noserial(stdout, buf);
Then I think we should do something like this:
int console_announce_r(void)
{
#ifndef CONFIG_PRE_CONSOLE_BUFFER
char buf[DISPLAY_OPTIONS_BANNER_LENGTH];
display_options_get_banner(false, buf, sizeof(buf));
console_puts_noserial(stdout, buf);
#endif
}
If we don't do this, there will be duplicated U-Boot version string
shown on the screen if CONFIG_PRE_CONSOLE_BUFFER is defined.
>>> +
>>> + return 0;
>>> +}
>>> +
>>> /* Called before relocation - use serial functions */
>>> int console_init_f(void)
>>> {
>>> diff --git a/include/console.h b/include/console.h
>>> index 3d37f6a53b..cea29ed6dc 100644
>>> --- a/include/console.h
>>> +++ b/include/console.h
>>> @@ -42,6 +42,18 @@ void console_record_reset(void);
>>> */
>>> void console_record_reset_enable(void);
>>>
>>> +/**
>>> + * console_announce_r() - print a U-Boot console on non-serial consoles
>>> + *
>>> + * When U-Boot starts up with a display it generally does not announce
>>> itself
>>> + * on the display. The banner is instead emitted on the UART before
>>> relocation.
>>> + * This function prints a banner on devices which (we assume) did not
>>> receive
>>> + * it before relocation.
>>> + *
>>> + * @return 0 (meaning no errors)
>>> + */
>>> +int console_announce_r(void);
>>> +
>>> /*
>>> * CONSOLE multiplexing.
>>> */
>>> --
>>
>> And I see another (same) patch @
>> https://patchwork.ozlabs.org/patch/769426/ which got applied, but this
>> one was sent later than the applied one. I am confused..
>
> Another patch in this series caused a breakage using a long BUILD_TAG
> due to a bug in how the snprintf() calls were done. So I dropped two
> patches from that series and sent this series instead.
>
> It wasn't noticed since I don't use BUILD_TAG and no tests were in
> place. It just happened that Stephen Warren has automated testing that
> caught it before it was pulled to mainline.
OK, thanks for the clarification.
Regards,
Bin
___
U-Boot mailing list
U-Boot@lists.denx.de
Re: [U-Boot] [PATCH v2 1/3] display_options: Refactor to allow obtaining the banner
On Tue, Jun 13, 2017 at 3:28 AM, Stephen Warren wrote: > On 06/10/2017 11:59 AM, Simon Glass wrote: >> >> Move the display options code into a separate function so that the U-Boot >> banner can be obtained from other code. Adjust the 'version' command to >> use it. > > > This series passed my automated testing, so: > Tested-by: Stephen Warren Tested on Intel MinnowMax Tested-by: Bin Meng ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1 0/4] Add FIT support for falcon boot
On 06/12/2017 04:16 PM, André Przywara wrote:
> On 09/06/17 19:48, york sun wrote:
>
> Hi York,
>
>> On 05/19/2017 02:56 AM, Andre Przywara wrote:
>>> Hi York,
>>>
>>> On 16/05/17 16:54, york sun wrote:
On 05/15/2017 10:42 PM, Lokesh Vutla wrote:
> + Andre
>
>
> On Monday 15 May 2017 09:31 PM, York Sun wrote:
>> This patch set adds FIT support for falcon boot. GZIP is enabled
>> to supported compressed image.
>
> Did you get a chance to look at Andre's "SPL: extend FIT loading
> support"[1] patch series? This series addresses similar problem in a
> more generic way.
>
> [1]
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.mail-archive.com%2Fu-boot%40lists.denx.de%2Fmsg246692.html&data=01%7C01%7Cyork.sun%40nxp.com%7C63ec3a7e245445e2253d08d49c1e542b%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0&sdata=XrCyv6JBg02fwP7MEMo1hg8rVCOGnEQ741Hs0oLwZVg%3D&reserved=0
I only received partial patches from Andre's set. Looks like that set
should cover my changes by supporting multiple images. I was focusing on
a fast boot path for the past two months. I can rebase my patch once
Andre's set is merged.
>>>
>>> FYI: My patches have been merged into u-boot-sunxi/master[1], which is
>>> based on origin/master as of earlier this week.
>>> I take it they get merged into origin before -rc1, but meanwhile you
>>> could base on u-boot-sunxi/master.
>>>
>>
>> Andre,
>>
>> Reading through your commits, I am glad to see you can support multiple
>> images. My understanding is you use "loadables" to indicate extra images
>> to load after loading U-Boot. The spl_image->entry_point is set to
>> either the last image's entry point (if set), or to the
>> spl_image->load_addr. Do I get it right?
>
> The idea is to use the start address from the _first_ image that
> provides an entry point.
> So if the "firmware" image has one, this is used, if not, the first
> image from the loadables section which provides an explicit "entry"
> property wins.
> This is used for Allwinner, where we want to load U-Boot and append the
> right DTB, but need to branch into the Trusted Firmware image.
>
>> When you process the images, if there is a "firmware" image, you presume
>> it is U-Boot and load it. If no such image, you take the first image in
>> "loadables", presuming it is U-Boot. Do I understand you correctly?
>
> Yes, this is right.
> This whole scheme is just meant to provide compatibility with the
> existing behaviour (with just the single image load).
> The whole reason why U-Boot proper is treated specially here is to be
> able to append the right DTB, which has to be loaded right behind the
> end of the U-Boot image (to match the expectation of
> CONFIG_OF_SEPARATE). Other than that U-Boot isn't very special.
>
>> In
>> your example its file, you demonstrated multiple "firmware" images, and
>> U-Boot has type of "standalone". Since you didn't put "firmware" in the
>> config node, I presume you would hit the "loadables". Correct?
>
> Exactly. U-Boot proper is just a loadable here. This special treatment
> of the "firmware" node is just there to support older .its files.
> Not sure if that is really needed, as I would expect the .its file *for
> the SPL* to be generated and shipped with U-Boot, though.
>
>> While I try to rebase my patch on top of yours, I realize you still
>> presume U-Boot image always exists. This is what I am trying to change
>> for falcon boot. I think the easiest way is to leave "firmware" node
>> absent in config node, and check the image type before setting
>> spl_image->os. After that I can follow the code flow to load ramdisk,
>> etc.
>
> So you want to load Linux directly, without U-Boot proper?
> FWIW, I once made an setup where I still use U-Boot proper, but load the
> kernel and initrd together with it (by the SPL), so the default
> environment can just proceed to booti, without needing to load anything.
I am trying to make the falcon boot work with FIT image. We only need
the SPL part of U-Boot.
>
>> I just have to add the "loadables" into my its. How about this flow
>> with pseudo code
>>
>> node = spl_fit_get_image_node(fit, images, "firmware", 0);
>> if (node < 0) {
>> node = spl_fit_get_image_node(fit, images, "loadables", 0);
>> index = 1;
>> }
>> if (node < 0)
>> return -1;
>>
>> if (image_type(node) == IH_TYPE_KERNEL) {
>> index = 0; /* reset to first image */
>> } else {
>> /* presuming U-Boot */
>> spl_image->os = IH_OS_U_BOOT;
>> continue_to_read_device_tree();
>> }
>>
>> /* check if there are more images to load */
>> for (; ; index++) {
>> /* keep existing code */
>> }
>>
>> What do you think?
>
> Yes, that sounds correct. Actually I was already toying with the idea of
> supporting special image types in the SPL (like the kernel here), but
> didn't want to extend the tight SPL code just for the sake of it.
> But since you have a use case, I think t
Re: [U-Boot] [beagleboard-gsoc] Re: am335x_evm_usbspl_defconfig testint
On Mon, Jun 12, 2017 at 10:42:40AM -0700, Ravi Kumar Prasad wrote: > > > On Monday, June 12, 2017 at 10:13:08 PM UTC+5:30, Jason Kridner wrote: > > > > Stefan, > > > > I see you submitted this defconfig: > > https://lists.denx.de/pipermail/u-boot/2016-November/272425.html > > > > I have a Google Summer of Code student intern attempting to use it and > > he's seeing it hang without entering UMS mode. Details are below. > > > > Can you give any advice on how you tested this? > > > > I believe he still needs to do something to explicitly enable UMS. Can you > > confirm? > > > > Ravi, > > > > If Stefan cannot answer, I'd suggest adjusting the default boot command to > > invoke UMS. > > > But SPL isn't booting first :( It was a configuration issue. I sent a patch to the U-Boot mailinglist. Should see it after it approved by the moderator. > > > Have you been able to stop the boot process using the serial port and get > > to the u-boot console? At the console, have you tried running the 'ums' > > command? > > > Yes, I tried running ums command from console, => ums 0 mmc 1 and the emmc > was mounted as mass storage device. > The problem was earlier in the boot than this. > > > > Regards, > > Jason > > > > On Sun, Jun 11, 2017 at 4:18 PM Ravi Kumar Prasad <7ra...@gmail.com > > > wrote: > > > >> Hi, > >> I'm porting BBBlfs bootloader server to nodejs. Now, after receiving tftp > >> request for SPL, I'm transferring SPL. > >> I built spl/uboot with config am335x_evm_usbspl_defconfig . After SPL > >> transfer it fails to boot, here's the serial output: > >> > >> U-Boot SPL 2017.07-rc1-00163-g8cb3ce6 (Jun 11 2017 - 01:09:02) > >> SPL: failed to boot from all boot devices > >> ### ERROR ### Please RESET the board ### Here is a pastebin after the configuration changes were applied: https://pastebin.com/MbKfB7bF He should be back in business. > >> > >> Please help me to debug this problem. > >> Code for server: https://github.com/ravikp7/node-beagle-boot > >> Thanks > >> Ravi > >> > >> -- > >> You received this message because you are subscribed to the Google Groups > >> "BeagleBoard GSoC" group. > >> To unsubscribe from this group and stop receiving emails from it, send an > >> email to beagleboard-gs...@googlegroups.com . > >> For more options, visit https://groups.google.com/d/optout. > >> > > > > -- > You received this message because you are subscribed to the Google Groups > "BeagleBoard GSoC" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to beagleboard-gsoc+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1 0/4] Add FIT support for falcon boot
On 09/06/17 19:48, york sun wrote:
Hi York,
> On 05/19/2017 02:56 AM, Andre Przywara wrote:
>> Hi York,
>>
>> On 16/05/17 16:54, york sun wrote:
>>> On 05/15/2017 10:42 PM, Lokesh Vutla wrote:
+ Andre
On Monday 15 May 2017 09:31 PM, York Sun wrote:
> This patch set adds FIT support for falcon boot. GZIP is enabled
> to supported compressed image.
Did you get a chance to look at Andre's "SPL: extend FIT loading
support"[1] patch series? This series addresses similar problem in a
more generic way.
[1]
https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.mail-archive.com%2Fu-boot%40lists.denx.de%2Fmsg246692.html&data=01%7C01%7Cyork.sun%40nxp.com%7C63ec3a7e245445e2253d08d49c1e542b%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0&sdata=XrCyv6JBg02fwP7MEMo1hg8rVCOGnEQ741Hs0oLwZVg%3D&reserved=0
>>>
>>> I only received partial patches from Andre's set. Looks like that set
>>> should cover my changes by supporting multiple images. I was focusing on
>>> a fast boot path for the past two months. I can rebase my patch once
>>> Andre's set is merged.
>>
>> FYI: My patches have been merged into u-boot-sunxi/master[1], which is
>> based on origin/master as of earlier this week.
>> I take it they get merged into origin before -rc1, but meanwhile you
>> could base on u-boot-sunxi/master.
>>
>
> Andre,
>
> Reading through your commits, I am glad to see you can support multiple
> images. My understanding is you use "loadables" to indicate extra images
> to load after loading U-Boot. The spl_image->entry_point is set to
> either the last image's entry point (if set), or to the
> spl_image->load_addr. Do I get it right?
The idea is to use the start address from the _first_ image that
provides an entry point.
So if the "firmware" image has one, this is used, if not, the first
image from the loadables section which provides an explicit "entry"
property wins.
This is used for Allwinner, where we want to load U-Boot and append the
right DTB, but need to branch into the Trusted Firmware image.
> When you process the images, if there is a "firmware" image, you presume
> it is U-Boot and load it. If no such image, you take the first image in
> "loadables", presuming it is U-Boot. Do I understand you correctly?
Yes, this is right.
This whole scheme is just meant to provide compatibility with the
existing behaviour (with just the single image load).
The whole reason why U-Boot proper is treated specially here is to be
able to append the right DTB, which has to be loaded right behind the
end of the U-Boot image (to match the expectation of
CONFIG_OF_SEPARATE). Other than that U-Boot isn't very special.
> In
> your example its file, you demonstrated multiple "firmware" images, and
> U-Boot has type of "standalone". Since you didn't put "firmware" in the
> config node, I presume you would hit the "loadables". Correct?
Exactly. U-Boot proper is just a loadable here. This special treatment
of the "firmware" node is just there to support older .its files.
Not sure if that is really needed, as I would expect the .its file *for
the SPL* to be generated and shipped with U-Boot, though.
> While I try to rebase my patch on top of yours, I realize you still
> presume U-Boot image always exists. This is what I am trying to change
> for falcon boot. I think the easiest way is to leave "firmware" node
> absent in config node, and check the image type before setting
> spl_image->os. After that I can follow the code flow to load ramdisk,
> etc.
So you want to load Linux directly, without U-Boot proper?
FWIW, I once made an setup where I still use U-Boot proper, but load the
kernel and initrd together with it (by the SPL), so the default
environment can just proceed to booti, without needing to load anything.
> I just have to add the "loadables" into my its. How about this flow
> with pseudo code
>
> node = spl_fit_get_image_node(fit, images, "firmware", 0);
> if (node < 0) {
> node = spl_fit_get_image_node(fit, images, "loadables", 0);
> index = 1;
> }
> if (node < 0)
> return -1;
>
> if (image_type(node) == IH_TYPE_KERNEL) {
> index = 0; /* reset to first image */
> } else {
> /* presuming U-Boot */
> spl_image->os = IH_OS_U_BOOT;
> continue_to_read_device_tree();
> }
>
> /* check if there are more images to load */
> for (; ; index++) {
> /* keep existing code */
> }
>
> What do you think?
Yes, that sounds correct. Actually I was already toying with the idea of
supporting special image types in the SPL (like the kernel here), but
didn't want to extend the tight SPL code just for the sake of it.
But since you have a use case, I think this is a sensible extension.
It might even be worse to make this more flexible and provide some means
to extend this support for further image types later.
> I will need to modify spl_load_fit_image() a little bit to support
> compressed kernel image.
Please consi
Re: [U-Boot] [PATCH v3 00/35] dm: tegra: Move nyan-big, jetson-tk1, beaver to livetree
Hi Stephen, On 12 June 2017 at 13:52, Stephen Warren wrote: > On 06/12/2017 06:21 AM, Simon Glass wrote: >> >> This moves three entire boards to use a live device tree as an example of >> the impact. > > > This series appears to cause problems on a couple of boards: > > On both Jetson TK1 and Jetson TX1 (p2372-180), "pci enum" fails with: > > ERROR: tegra-pcie: failed to power on PHY: -110 > > at .../pci_tegra.c:774/tegra_pcie_enable_controller() > ERROR: tegra-pcie: failed to enable controller > at .../pci_tegra.c:1154/pci_tegra_probe() I seem to get this error always (before these patches) on TK1. I thought it was because I corrupted my PMIC. Do it happen on vanilla mainline for you? I did get a TX1 but unfortunately I am temporarily misplaced it. Too many boards :-( Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 00/35] dm: tegra: Move nyan-big, jetson-tk1, beaver to livetree
On 06/12/2017 02:09 PM, Simon Glass wrote: Hi Stephen, On 12 June 2017 at 13:52, Stephen Warren wrote: On 06/12/2017 06:21 AM, Simon Glass wrote: This moves three entire boards to use a live device tree as an example of the impact. This series appears to cause problems on a couple of boards: On both Jetson TK1 and Jetson TX1 (p2372-180), "pci enum" fails with: ERROR: tegra-pcie: failed to power on PHY: -110 at .../pci_tegra.c:774/tegra_pcie_enable_controller() ERROR: tegra-pcie: failed to enable controller at .../pci_tegra.c:1154/pci_tegra_probe() I seem to get this error always (before these patches) on TK1. I thought it was because I corrupted my PMIC. Do it happen on vanilla mainline for you? No, this error doesn't occur in mainline AFAIK; git hash 8cb3ce64f936 from mainline ran through testing a couple of days ago without any issue. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] defconfig: arm335x_evm_usbspl: Update MUSB Ethernet
Adds CONFIG_SPL_USB_GADGET_SUPPORT and CONFIG_SPL_USBETH_SUPPORT. Removes CONFIG_SPL_NAND_SUPPORT, CONFIG_SPL_MTD_SUPPORT, and CONFIG_SPL_YMODEM_SUPPORT to free up space to fit in RAM. Signed-off-by: Michael Welling --- configs/am335x_evm_usbspl_defconfig | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/configs/am335x_evm_usbspl_defconfig b/configs/am335x_evm_usbspl_defconfig index ee3405c..1ba0310 100644 --- a/configs/am335x_evm_usbspl_defconfig +++ b/configs/am335x_evm_usbspl_defconfig @@ -11,9 +11,9 @@ CONFIG_VERSION_VARIABLE=y CONFIG_ARCH_MISC_INIT=y CONFIG_SPL=y CONFIG_SPL_STACK_R=y -CONFIG_SPL_MTD_SUPPORT=y CONFIG_SPL_MUSB_NEW_SUPPORT=y CONFIG_SPL_NET_SUPPORT=y +# CONFIG_SPL_NAND_SUPPORT is not set CONFIG_SPL_OS_BOOT=y # CONFIG_CMD_IMLS is not set # CONFIG_CMD_FLASH is not set @@ -35,3 +35,6 @@ CONFIG_G_DNL_MANUFACTURER="Texas Instruments" CONFIG_G_DNL_VENDOR_NUM=0x0451 CONFIG_G_DNL_PRODUCT_NUM=0xd022 CONFIG_OF_LIBFDT=y +CONFIG_SPL_USB_GADGET_SUPPORT=y +CONFIG_SPL_USBETH_SUPPORT=y +# CONFIG_SPL_YMODEM_SUPPORT is not set -- 2.1.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 00/35] dm: tegra: Move nyan-big, jetson-tk1, beaver to livetree
On 06/12/2017 06:21 AM, Simon Glass wrote: This moves three entire boards to use a live device tree as an example of the impact. This series appears to cause problems on a couple of boards: On both Jetson TK1 and Jetson TX1 (p2372-180), "pci enum" fails with: ERROR: tegra-pcie: failed to power on PHY: -110 at .../pci_tegra.c:774/tegra_pcie_enable_controller() ERROR: tegra-pcie: failed to enable controller at .../pci_tegra.c:1154/pci_tegra_probe() ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] am335x_evm_usbspl_defconfig testint
On Monday, June 12, 2017 at 10:13:08 PM UTC+5:30, Jason Kridner wrote: > > Stefan, > > I see you submitted this defconfig: > https://lists.denx.de/pipermail/u-boot/2016-November/272425.html > > I have a Google Summer of Code student intern attempting to use it and > he's seeing it hang without entering UMS mode. Details are below. > > Can you give any advice on how you tested this? > > I believe he still needs to do something to explicitly enable UMS. Can you > confirm? > > Ravi, > > If Stefan cannot answer, I'd suggest adjusting the default boot command to > invoke UMS. > But SPL isn't booting first :( > Have you been able to stop the boot process using the serial port and get > to the u-boot console? At the console, have you tried running the 'ums' > command? > Yes, I tried running ums command from console, => ums 0 mmc 1 and the emmc was mounted as mass storage device. > > Regards, > Jason > > On Sun, Jun 11, 2017 at 4:18 PM Ravi Kumar Prasad <7ra...@gmail.com > > wrote: > >> Hi, >> I'm porting BBBlfs bootloader server to nodejs. Now, after receiving tftp >> request for SPL, I'm transferring SPL. >> I built spl/uboot with config am335x_evm_usbspl_defconfig . After SPL >> transfer it fails to boot, here's the serial output: >> >> U-Boot SPL 2017.07-rc1-00163-g8cb3ce6 (Jun 11 2017 - 01:09:02) >> SPL: failed to boot from all boot devices >> ### ERROR ### Please RESET the board ### >> >> Please help me to debug this problem. >> Code for server: https://github.com/ravikp7/node-beagle-boot >> Thanks >> Ravi >> >> -- >> You received this message because you are subscribed to the Google Groups >> "BeagleBoard GSoC" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to beagleboard-gs...@googlegroups.com . >> For more options, visit https://groups.google.com/d/optout. >> > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 3/4] rockchip: Add basic support for phyCORE-RK3288 SoM based carrier board
On 12 June 2017 at 03:59, Wadim Egorov wrote: > The phyCORE-RK3288 is a SoM (System on Module) containing a RK3288 SoC. > The module can be connected to different carrier boards. > It can be also equipped with different RAM, SPI flash and eMMC variants. > The Rapid Development Kit option is using the following setup: > > - 1 GB DDR3 RAM (2 Banks) > - 1x 4 KB EEPROM > - DP83867 Gigabit Ethernet PHY > - 16 MB SPI Flash > - 4 GB eMMC Flash > > Add basic support for the PCM-947 carrier board, a RK3288 based development > board made by PHYTEC. This board works in a combination with > the phyCORE-RK3288 System on Module. > > Signed-off-by: Wadim Egorov > --- > Changes in v3: > - Added u-boot,dm-pre-reloc to regulators subnode > (PMIC failed to bind because of the missing regulators node) > - Removed the hacky PMIC setup from phycore_init > - Use CONFIG_TARGET_PHYCORE_RK3288 to cover board-specific stuff > > Things get ugly when I use of_machine_is_compatible(). > Boards whith CONFIG_SPL_OF_PLATDATA disabled would compile in > of_machine_is_compatible() which checks for my board. > phycore_init() calls rk818_spl_configure_*() which depends on > CONFIG_SPL_POWER_SUPPORT. So this will cause undefined reference linker > warnings for every other rockchip board. > That's the reason why I moved back to CONFIG_TARGET_PHYCORE_RK3288. > > --- > arch/arm/dts/Makefile| 1 + > arch/arm/dts/rk3288-phycore-rdk.dts | 294 > arch/arm/dts/rk3288-phycore-som.dtsi | 506 > +++ > arch/arm/mach-rockchip/rk3288-board-spl.c| 35 ++ > arch/arm/mach-rockchip/rk3288/Kconfig| 10 + > board/phytec/phycore_rk3288/Kconfig | 15 + > board/phytec/phycore_rk3288/MAINTAINERS | 6 + > board/phytec/phycore_rk3288/Makefile | 8 + > board/phytec/phycore_rk3288/phycore-rk3288.c | 8 + > configs/phycore-rk3288_defconfig | 70 > include/configs/phycore_rk3288.h | 23 ++ > 11 files changed, 976 insertions(+) > create mode 100644 arch/arm/dts/rk3288-phycore-rdk.dts > create mode 100644 arch/arm/dts/rk3288-phycore-som.dtsi > create mode 100644 board/phytec/phycore_rk3288/Kconfig > create mode 100644 board/phytec/phycore_rk3288/MAINTAINERS > create mode 100644 board/phytec/phycore_rk3288/Makefile > create mode 100644 board/phytec/phycore_rk3288/phycore-rk3288.c > create mode 100644 configs/phycore-rk3288_defconfig > create mode 100644 include/configs/phycore_rk3288.h Reviewed-by: Simon Glass (assuming we need to set up the battery / charger in SPL) But can you please check the compatible string to decide whether you need to do the phytec stuff, instead of an #ifdef on the target? I suppose if it increase code size it is OK to have both, but the #ifdef should be a size optimisation, not the main method of selecting the code Is there a way to describe what is needed in the DT? ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 4/4] doc: rockchip: Add phyCORE-RK3288 RDK to board list
On 12 June 2017 at 03:59, Wadim Egorov wrote: > Signed-off-by: Wadim Egorov > Acked-by: Simon Glass > --- > Changes in v3: > - Added Acked-by: Simon Glass > --- > doc/README.rockchip | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/3] regulator: lp873x: Fix the return value of ldo_get_enable function
On 10 June 2017 at 23:01, Keerthy wrote:
> The function wrongly returned an integer while it is supposed to
> return boolean. Fix that.
>
> Fixes: 99785de83 ("power: regulator: lp873x: Add regulator support")
> Signed-off-by: Keerthy
> ---
> drivers/power/regulator/lp873x_regulator.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
Reviewed-by: Simon Glass
I think in fact we should return int from this method in struct
dm_regulator_ops. I don't really like not being able to return an
error.
So bonus points if you can change that :-)
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 2/4] power: regulator: rk8xx: Allow input current/charger shutdown configuration
Hi Wadim, On 12 June 2017 at 03:59, Wadim Egorov wrote: > The RK818 PMIC contains a charger. Add very basic charger functionality > to be able to regulate the USB input current and charger shutdown limits. > > Signed-off-by: Wadim Egorov > --- > drivers/power/regulator/rk8xx.c | 34 ++ > include/power/rk8xx_pmic.h | 2 ++ > 2 files changed, 36 insertions(+) Does this have to be done in SPL? Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] regulator: lp87565: Fix the return value of buck_get_enable function
On 10 June 2017 at 23:01, Keerthy wrote:
> The function wrongly returned an integer while it is supposed to
> return boolean. Fix that.
>
> Fixes: 2dd9dc02a3("power: regulator: lp87565: add regulator support")
> Reported-by: Nishanth Menon
> Signed-off-by: Keerthy
> ---
> drivers/power/regulator/lp87565_regulator.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Reviewed-by: Simon Glass
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 13/13] rockchip: rk3066: add sdram init code for tpl
Hi Pawel,
On 9 June 2017 at 07:15, Paweł Jarosz wrote:
>
>
> W dniu 09.06.2017 o 14:27, Simon Glass pisze:
>
>> Hi Pawel,
>>
>> On 7 June 2017 at 09:44, Paweł Jarosz wrote:
>>>
>>> Hi Simon,
>>>
>>>
>>> W dniu 06.06.2017 o 23:10, Simon Glass pisze:
>>>
Hi Pawel,
On 6 June 2017 at 12:53, Paweł Jarosz wrote:
>
> Add sdram initialisation code which will be ussed by tpl first boot
> stage.
> We need to implement sdram initialisation in tpl due to size issues on
> rk3066
> platform.
>
> Signed-off-by: Paweł Jarosz
> ---
>arch/arm/include/asm/arch-rockchip/ddr_rk3188.h | 5 +
>arch/arm/mach-rockchip/rk3066/sdram_init.c | 995
>
>2 files changed, 1000 insertions(+)
>create mode 100644 arch/arm/mach-rockchip/rk3066/sdram_init.c
>
> diff --git a/arch/arm/include/asm/arch-rockchip/ddr_rk3188.h
> b/arch/arm/include/asm/arch-rockchip/ddr_rk3188.h
> index 3d7929f..74d11c6 100644
> --- a/arch/arm/include/asm/arch-rockchip/ddr_rk3188.h
> +++ b/arch/arm/include/asm/arch-rockchip/ddr_rk3188.h
> @@ -10,6 +10,11 @@
>#include
>
>/*
> + * RK3066 Tpl memory init.
> + */
> +void sdram_initialise(void);
> +
> +/*
> * RK3188 Memory scheduler register map.
> */
>struct rk3188_msch {
> diff --git a/arch/arm/mach-rockchip/rk3066/sdram_init.c
> b/arch/arm/mach-rockchip/rk3066/sdram_init.c
> new file mode 100644
> index 000..e7e506a
> --- /dev/null
> +++ b/arch/arm/mach-rockchip/rk3066/sdram_init.c
> @@ -0,0 +1,995 @@
> +/*
> + * (C) Copyright 2015 Google, Inc
> + * Copyright 2014 Rockchip Inc.
> + *
> + * SPDX-License-Identifier: GPL-2.0
> + *
> + * Adapted from the very similar rk3288 ddr init.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +DECLARE_GLOBAL_DATA_PTR;
> +
> +struct pll_div {
> + u32 nr;
> + u32 nf;
> + u32 no;
> +};
> +
> +enum {
> + VCO_MAX_HZ = 1416U * 100,
> + VCO_MIN_HZ = 300 * 100,
> + OUTPUT_MAX_HZ = 1416U * 100,
> + OUTPUT_MIN_HZ = 30 * 100,
> + FREF_MAX_HZ = 1416U * 100,
> + FREF_MIN_HZ = 30 * 1000,
> +};
> +
> +enum {
> + /* PLL CON0 */
> + PLL_OD_MASK = 0x0f,
> +
> + /* PLL CON1 */
> + PLL_NF_MASK = 0x1fff,
> +
> + /* PLL CON2 */
> + PLL_BWADJ_MASK = 0x0fff,
> +
> + /* PLL CON3 */
> + PLL_RESET_SHIFT = 5,
> +
> + /* GRF_SOC_STATUS0 */
> + SOCSTS_DPLL_LOCK= 1 << 4,
> + SOCSTS_APLL_LOCK= 1 << 5,
> + SOCSTS_CPLL_LOCK= 1 << 6,
> + SOCSTS_GPLL_LOCK= 1 << 7,
> +};
> +
> +#define CRU_BASE 0x2000
> +#define GRF_BASE 0x20008000
> +#define PMU_BASE 0x20004000
> +#define PCTL_BASE 0x2002
> +#define PUBL_BASE 0x2004
> +#define NOC_BASE 0x10128000
I'm assume we cannot use the DT / syscon because of space constraints?
>>>
>>> Correct.
>
> +
> +#define RK3066_PCTL_TIMING_DEFAULT { \
Do you need this? Why not just put these values below and avoid the
indirection?
>>>
>>> Some board may need this in the future as sdram timings are not
>>> universal.
>>> Default timings are dumped from rockchip proprietary loader.
>>> Look here:
>>
>> In that case these should go in the device tree like with other Rockchip
>> boards.
>> [...]
>
>
> It's tpl build. Is device tree supported in tpl?
Well maybe, but you only use TPL if things are really tight, so I
wouldn't recommend it.
>
How similar is this to rk3288? Could we put common code in a separate
file?
>>>
>>> Not sure how similar is it to rk3288. CRU, GRF, PMU differ a little
>>> between
>>> socs.
>>
>> Where did you get the code from? I want to avoid duplicate code and
>> factor out the differences if we can.
>
>
> It's adjusted code from rk3188 sdram driver.
>
>>> Also i needed to add few adjustments to make it build and run with tpl.
>>
>> I am still hoping we can drop TPL.
>>
>> Regards,
>> Simon
>
>
> Regards
> Paweł
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 1/4] power: regulator: rk8xx: Build get_ldo_reg only for SPL
On 12 June 2017 at 03:58, Wadim Egorov wrote: > Enabling CONFIG_SPL_POWER_SUPPORT will cause a compiler warning: > ‘get_ldo_reg’ defined but not used [-Wunused-function] > > Let's wrap get_ldo_reg(), rk808_ldo and rk818_ldo with ENABLE_DRIVER > which is only set for non SPL builds. > > Signed-off-by: Wadim Egorov > --- > drivers/power/regulator/rk8xx.c | 40 +--- > 1 file changed, 21 insertions(+), 19 deletions(-) Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] blk: dm: make blk_create_device() take a number of block instead of a size
On 9 June 2017 at 08:45, Jean-Jacques Hiblot wrote: > There is an overflow problem when taking the size instead of the number > of blocks in blk_create_device(). This results in a wrong device size: the > device apparent size is its real size modulo 4GB. > Using the number of blocks instead of the device size fixes the problem and > is more coherent with the internals of the block layer. > > Signed-off-by: Jean-Jacques Hiblot > --- > common/scsi.c | 2 +- > drivers/block/blk-uclass.c | 8 > drivers/block/sandbox.c| 2 +- > include/blk.h | 8 > test/dm/blk.c | 6 +++--- > 5 files changed, 13 insertions(+), 13 deletions(-) Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v5 02/11] reset: add reset_count()
Hi Patrice,
On 12 June 2017 at 01:51, Patrice CHOTARD wrote:
>
>
> On 06/12/2017 09:27 AM, Patrice CHOTARD wrote:
>> Hi Simon
>>
>> On 06/06/2017 11:08 PM, Simon Glass wrote:
>>> Hi,
>>>
>>> On 5 June 2017 at 05:18, Marek Vasut wrote:
On 06/05/2017 11:34 AM, Patrice CHOTARD wrote:
> Hi Marek
>
> On 06/03/2017 08:02 AM, Marek Vasut wrote:
>> On 06/01/2017 01:36 PM, patrice.chot...@st.com wrote:
>>> From: Patrice Chotard
>>>
>>> Add reset_count() method to be able to get the number
>>> of resets contained into a resets property. This will allow
>>> to allocate the right amount of memory in order to keep resets
>>> reference. These resets reference can be used later on error path
>>> or in .remove callback to release these resets.
>>>
>>> Signed-off-by: Patrice Chotard
>>> ---
>>> v5: _ replace fdtdec_parse_phandle_with_args() by
>>> dev_read_phandle_with_args()
>>> v4: _ add reset_count() method
>>>
>>> drivers/reset/reset-uclass.c | 13 +
>>> include/reset.h | 11 +++
>>> 2 files changed, 24 insertions(+)
>>>
>>> diff --git a/drivers/reset/reset-uclass.c b/drivers/reset/reset-uclass.c
>>> index 4fd82b9..4b17d4c 100644
>>> --- a/drivers/reset/reset-uclass.c
>>> +++ b/drivers/reset/reset-uclass.c
>>> @@ -97,6 +97,19 @@ int reset_get_by_name(struct udevice *dev, const
>>> char *name,
>>> return reset_get_by_index(dev, index, reset_ctl);
>>> }
>>>
>>> +int reset_count(struct udevice *dev)
>>> +{
>>> + int count;
>>> + struct ofnode_phandle_args args;
>>> +
>>> + for (count = 0; ; count++) {
>>> + if (dev_read_phandle_with_args(dev,
>>> + "resets", "#reset-cells", 0,
>>> + count, &args))
>>
>> Don't we have some generic thing in libfdt to count number of phandle
>> args ? This looks weird to me ...
>
> I didn't find anything in libfdt doing that.
Maybe someone else can hop in, I'm quite sure there should be something
like that.
>>>
>>> In linux there is of_count_phandle_with_args(). Now that we have
>>> livetree we could copy that function over. Then for flat tree we could
>>> use fdtdec_parse_phandle_with_args() passing a -ve index.
>>>
>>> Then we need something like dev_read_phandle_count().
>>>
>>> Patrice what do you think?
>>
>> Agree with that.
>> Ping me when this will be available, then i will update and resubmit my
>> series.
>
> Or do you prefer me to do this ? just tell me ?
Please go ahead, thanks.
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] dm: bcm6345_gpio: Set proper output level in bcm6345_gpio_direction_output
On 8 June 2017 at 03:20, Axel Lin wrote: > Current code does not set output level in bcm6345_gpio_direction_output, > fix it. > > Signed-off-by: Axel Lin > --- > drivers/gpio/bcm6345_gpio.c | 2 ++ > 1 file changed, 2 insertions(+) Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 0/5] move boot0 hook in the beginning for armv7
Hi Philipp, On 9 June 2017 at 06:59, Dr. Philipp Tomsich wrote: > Simon, > >> On 09 Jun 2017, at 14:27, Simon Glass wrote: >> >> Hi Kever, >> >> On 7 June 2017 at 04:55, Kever Yang wrote: >>> Simon, >>> >>> >>> >>> On 06/07/2017 11:15 AM, Simon Glass wrote: Hi Kever, On 6 June 2017 at 20:41, Kever Yang wrote: > > Simon, > > > > On 06/07/2017 05:08 AM, Simon Glass wrote: >> >> Hi Kever, >> >> On 31 May 2017 at 04:50, Kever Yang wrote: >>> >>> I think the boot0 hook is suppose to add some data in the very >>> beginning >>> of the SPL image, am I right? >>> >>> Rockchip SoCs bootrom design is like this: >>> - First 2KB or 4KB internal memory is for bootrom stack and heap; >>> - Then the first 4-byte suppose to be a TAG like 'RK33'; >>> - The the following memory address end with '0004' is the first >>>instruction load and running by bootrom; >>> >>> Example for RK3288: >>> Before this patch set, the SPL_TEXT_BASE is ff704004, and image write >>> to >>> media device after mkimage like this: >>> >>> ff704000: 32334b52 RK32 >>> ff704010: >>> ff704020: ea0f e59ff014 e59ff014 e59ff014 >>> ff704030: e59ff014 e59ff014 e59ff014 e59ff014 >>> >>> Where the first instruction from bootrom is '', which is a >>> undefined instruction. >>> The '_start' and 'reset' have to align to 0x20 for the requirement of >>> VBAR, the memory offset '004'~'01c' are filled with ''. >>> >>> We can use the boot0 hook to fix this issue, after this patch set, >>> the SPL_TEXT_BASE is ff704000 and image write to media device after >>> mkimage like this: >>> >>> ff704000: 32334b52 ea1d e320f000 e320f000RK32.. ... . >>> ff704010: e320f000 e320f000 e320f000 e320f000.. ... ... ... . >>> ff704020: ea16 e59ff014 e59ff014 e59ff014 >>> ff704030: e59ff014 e59ff014 e59ff014 e59ff014 >>> >>> The first instruction from bootrom is a 'b reset', and memory of >>> '008'~'01c' are filled with 'nop' instruction. >>> >>> This patch set does not provide patch for socfpga, bcm and sunxi SoCs >>> which also >>> enable BOOT0_HOOK, so this is a RFC patch, please advice how to make it >>> compatible with those three platforms. >>> >>> >>> >>> Kever Yang (5): >>>armv7: move boot hook before '_start' >>>rockchip: boot0: align to 0x20 for armv7 '_start' >>>rockchip: enable BOOT0_HOOK for SoCs >>>rockchip: configs: use aligned address for SPL_TEXT_BASE >>>rockchip: mkimage: use spl_boot0 for all Rockchip SoCs >>> >>> arch/arm/include/asm/arch-rockchip/boot0.h | 9 - >>> arch/arm/lib/vectors.S | 19 ++- >>> arch/arm/mach-rockchip/Kconfig | 3 +++ >>> include/configs/rk3036_common.h| 2 +- >>> include/configs/rk3288_common.h| 2 +- >>> tools/rkcommon.c | 8 >>> 6 files changed, 27 insertions(+), 16 deletions(-) >>> >>> -- >>> 1.9.1 >>> >> Do will still need this series now that (I think) we have a fix for >> the return-to-brom feature in u-boot-rockchip/master? > > > Could you point me out exactly which fix do you talking about? These ones: a079e52d35 rockchip: mkimage: set init_boot_size to avoid confusing the boot ROM ee2c63912b rockchip: mkimage: force 2KB alignment for init_size 99c700c794 rockchip: mkimage: add support for verify_header/print_header > This is not about return-to-brom, it's about the first instruction from > Bootrom to SPL. > So this is need for all Rockchip armv7 SoCs. OK, how did we survive before? What has changed to make this series needed? >>> >>> >>> After check with JTAG, I find that I'm wrong with cmd code '', >>> this is 'andeq r0, r0, r0', but not undefined in armv7, so it can work. >>> >>> I still want this patch set applied because it's better to make all the >>> Rockchip's >>> SPL have the same format(with 4-byte TAG space reserved), and the ddr binary >>> from Rockchip always have pre-padding 4-byte TAG, with this patch set, we >>> can replace each other easily and work with one mkimage tool. >> >> I'm not sure how to apply this since on the other thread[1] Marek says >> it will break socfpga. > > To me it looks as if we need to fix the BOOT0 handling across all ARMv7 > platforms, as it looks as if the current implementation and its documentation > contradict each other. > > Here’s how BOOT0 was intended: > > 1. from Kconfig: > If the SoC's BOOT0 requires a head
Re: [U-Boot] [PATCH 12/13] armv7: support rk3066 early back to bootrom in start.S
Hi Pawel, On 9 June 2017 at 06:31, Paweł Jarosz wrote: > > > W dniu 09.06.2017 o 13:46, Heiko Stuebner pisze: > >> Am Mittwoch, 7. Juni 2017, 17:37:13 CEST schrieb Paweł Jarosz: >>> >>> Hi Simon, >>> >>> >>> W dniu 06.06.2017 o 23:10, Simon Glass pisze: Hi Pawel, On 6 June 2017 at 12:53, Paweł Jarosz wrote: > > Rockchip bootrom first reads 1KB data from nand at offset 0x10080C00 > and > executes it. Then waits for back to bootrom and loads another 32KB to > sram > which also executes. Sdram initialisation code needs to be in one of > these two > steps. Then bootloader loads another ~200KB of data at offset > 0x6000 > and jumps to it. > > 32KB of data is a little low for tpl + spl part and ~200KB data is to > low for > u-boot part(for example to boot from mmc you need to disable usb > support. > > My solution to size problem is to move sdram initialisation code to tpl > stage, > move spl part to third stage(reading 200KB data) and add support for > loading > u-boot by spl from ext2/4, fat partitions. > > But moving sdram initialisation code to tpl increases size of tpl above > 1KB > (first boot stage). Solution to this is to add code which will be below > 1KB > offset in tpl binary and do back to bootrom at very beginning of the > tpl > execution. So do you mean that TPL starts and then loads more of itself? Why not put SDRAM init in SPL? You say above that 32KB is 'too low', but It's not clear why. >>> >>> Ad.1 No. Tpl starts and at the first execution returns to bootrom. >>> Bootrom then loads >>> rest of the tpl (31KB) and executes it for a second time. >>> >>> Ad.2,3 Due to size issues (200KB limit) i needed to move main u-boot to >>> mmc. To load u-boot from >>> mmc by SPL (there is 32KB bootrom limit, not enough space for mmc >>> support) i moved SPL to sdram. >>> Code executed in sdram can't mess with sdram settings because it will >>> hang the board. Sdram setup >>> needs to be done by code in SRAM (tpl). >> >> At least the rk3288-Firefly was able to also have mmc stack in the SPL in >> the past, without requiring the back_to_bootrom at all. So question would >> be why this doesn't fit anymore, or on the rk3066 specifically. >> >> Also, it seems like I got my hands on a preliminary (linux/mtd) nand >> driver >> (rk3228 but cursory glance at the registers suggests that it may actually >> work on previous socs down to the rk3066 as well) and it may be possible >> to adapt that for uboot, therefore making the spl able to also load the >> full u-boot from without needing back_to_bootrom. >> >> >> Heiko > > I was not able to get mmc support on rk3066 in spl in ~31kb (32kb - 1kb for > tpl)size limit. > One (or two i didn't check how much) back to bootrom is required on rk3066. > If not done bootrom stays in weird state and halts on bringup secondary cpu > in kernel. So it's rk3066 specific. What size do you get? With firefly-rk3288 I get about 25KB with SDRAM init and MMC stack. Are you building with Thumb 2? If you are on irc we could try to clear this up more quicky (I am sjg1) Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 06/13] rockchip: rk3066: add core support
Hi Pawel,
On 9 June 2017 at 07:03, Paweł Jarosz wrote:
>
>
> W dniu 09.06.2017 o 14:27, Simon Glass pisze:
>
>> Hi Pawel,
>>
>> On 7 June 2017 at 09:22, Paweł Jarosz wrote:
>>>
>>> Hi Simon
>>>
>>>
>>> W dniu 06.06.2017 o 23:10, Simon Glass pisze:
Hi Pawel,
On 6 June 2017 at 12:50, Paweł Jarosz wrote:
>
> +#include
> +#include
> +#include
> +#include
That should go below spi.h
>>> Ok
>
> +
> +DECLARE_GLOBAL_DATA_PTR;
> +
> +u32 spl_boot_device(void)
> +{
This function seems to be common. Can you please (in a separate patch)
move it into a separate shared file and delete all the copies?
>>>
>>> Ok
> +
> + sdram_initialise();
How come TPL is setting up the DRAM? Shouldn't that be done in SPL?
>>> Due to size issues i needed to move spl load to sdram (not sram) and
>>> sdram
>>> settings
>>> should be done by code executed in SRAM or you get to hang a board.
>>
>> What is the size limit on SRAM?
>
>
> RK3066 has 64KB SRAM but bootrom only reads 1KB + 31KB.
That is not a very low limit. RK3288 uses SPL (and not TPL) and it has
the same limit. Can we not just drop the use of TPL?
>
>> [...]
>>
> +config SYS_SOC
> +default "rockchip"
> +
> +config SYS_MALLOC_F_LEN
> +default 0x0800
> +
> +config SPL_LIBCOMMON_SUPPORT
You should be able to add these as 'imply' options now (to the
ROCKCHIP_RK3066 config)
>>> What do you mean by 'imply' options?
>>
>> Things like:
>>
>> config ROCKCHIP_RK3288
>> bool "Support Rockchip RK3288"
>> select CPU_V7
>> select SPL_BOARD_INIT if SPL
>> select SUPPORT_SPL
>> select SPL
>> imply SPL_LIBCOMMON_SUPPORT
>>
>> Either select or imply cause that option to be enabled.
>>
> +#define CONFIG_SPL_FRAMEWORK 1
> +#define CONFIG_SPL_CLK 1
> +#define CONFIG_SPL_PINCTRL 1
> +#define CONFIG_SPL_REGMAP 1
Many of these should be set in Kconfig or the defconfig file.
>>> Yes but some have gave me tpl build issues that's why i did that here
>>
>> We need to figure out if TPL is really needed. E.g. I don't think
>> kylin_rk3036 needs it. It produces an SPL that is about 4KB.
>
>
> RK3036 has a different bootrom load process so we shouldn't compare those
> two.
> Better is to compare RK3066 and RK3188 as those are similiar(RK3188 is
> without 200KB limit i think)
OK, still I don't understand why SPL cannot work.
>
> Paweł
>>
>> Regards,
>> Simon
>
>
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: provide a valid exception stack address for startup code
On 8 June 2017 at 02:16, Lothar Waßmann wrote: > Create exception stack in IRAM if available to facilitate debugging of > pre-relocation code by catching exceptions rather than stopping dead. > > Signed-off-by: Lothar Waßmann > --- > arch/arm/lib/vectors.S | 5 - > 1 file changed, 4 insertions(+), 1 deletion(-) Reviewed-by: Simon Glass But please see below. > > diff --git a/arch/arm/lib/vectors.S b/arch/arm/lib/vectors.S > index f53b1e9..1019091 100644 > --- a/arch/arm/lib/vectors.S > +++ b/arch/arm/lib/vectors.S > @@ -117,7 +117,6 @@ data_abort: > not_used: > irq: > fiq: > - What is this? > 1: > bl 1b /* hang and never return */ > > @@ -126,7 +125,11 @@ fiq: > /* IRQ stack memory (calculated at run-time) + 8 bytes */ > .globl IRQ_STACK_START_IN > IRQ_STACK_START_IN: > +#ifdef IRAM_BASE_ADDR > + .word IRAM_BASE_ADDR + 0x20 > +#else > .word 0x0badc0de > +#endif > > @ > @ IRQ stack frame. > -- > 2.1.4 > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: remove bogus cp_delay() function
On 8 June 2017 at 01:48, Lothar Waßmann wrote:
> The cp_delay() function was introduced because of a missing 'volatile'
> attribute to the 'asm' statement in get_cr() which led to the 'mrc'
> instruction in get_cr() being optimised out eventually.
> This has been fixed in commit 53fd4b8c22bb ("arm: mmu: Add missing volatile
> for reading SCTLR register")
> but the bogus cp_delay() function which was introduced as a workaround
> for the malfunctioning get_cr() was never removed.
>
> Signed-off-by: Lothar Waßmann
> ---
> arch/arm/lib/cache-cp15.c | 15 +--
> 1 file changed, 1 insertion(+), 14 deletions(-)
Reviewed-by: Simon Glass
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] Pull request, u-boot-tegra/master
Tom, Please pull u-boot-tegra/master into U-Boot/master. Thanks! All Tegra builds are OK, and Stephen's automated test system reports that all tests pass. The following changes since commit 8cb3ce64f936f5dedbcfc1935c5caf31bb682474: Merge git://git.denx.de/u-boot-dm (2017-06-10 18:01:22 -0400) are available in the git repository at: git://git.denx.de/u-boot-tegra.git master for you to fetch changes up to 2eb3e28b2c69261d274bc22321f688c193985e7b: ARM: tegra: remove Whistler support (2017-06-12 13:03:50 -0700) Stephen Warren (1): ARM: tegra: remove Whistler support arch/arm/dts/Makefile | 1 - arch/arm/dts/tegra20-whistler.dts | 77 --- arch/arm/mach-tegra/tegra20/Kconfig | 5 --- board/nvidia/whistler/Kconfig | 12 -- board/nvidia/whistler/MAINTAINERS | 7 board/nvidia/whistler/Makefile | 8 board/nvidia/whistler/whistler.c| 80 - configs/whistler_defconfig | 29 -- include/configs/whistler.h | 49 --- 9 files changed, 268 deletions(-) delete mode 100644 arch/arm/dts/tegra20-whistler.dts delete mode 100644 board/nvidia/whistler/Kconfig delete mode 100644 board/nvidia/whistler/MAINTAINERS delete mode 100644 board/nvidia/whistler/Makefile delete mode 100644 board/nvidia/whistler/whistler.c delete mode 100644 configs/whistler_defconfig delete mode 100644 include/configs/whistler.h ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 00/35] dm: tegra: Move nyan-big, jetson-tk1, beaver to livetree
Hi Stephen, On 12 June 2017 at 15:39, Stephen Warren wrote: > On 06/12/2017 03:15 PM, Simon Glass wrote: >> >> [trimming the cc list a bit] >> >> Hi Stephen, >> >> On 12 June 2017 at 15:02, Stephen Warren wrote: >>> >>> On 06/12/2017 02:09 PM, Simon Glass wrote: Hi Stephen, On 12 June 2017 at 13:52, Stephen Warren wrote: > > > On 06/12/2017 06:21 AM, Simon Glass wrote: >> >> >> >> This moves three entire boards to use a live device tree as an example >> of >> the impact. > > > This series appears to cause problems on a couple of boards: > > On both Jetson TK1 and Jetson TX1 (p2372-180), "pci enum" fails with: > > ERROR: tegra-pcie: failed to power on PHY: -110 > > at .../pci_tegra.c:774/tegra_pcie_enable_controller() > ERROR: tegra-pcie: failed to enable controller > at .../pci_tegra.c:1154/pci_tegra_probe() I seem to get this error always (before these patches) on TK1. I thought it was because I corrupted my PMIC. Do it happen on vanilla mainline for you? >>> >>> >>> No, this error doesn't occur in mainline AFAIK; git hash 8cb3ce64f936 >>> from >>> mainline ran through testing a couple of days ago without any issue. >> >> >> That does make me think my board is broken as mentioned. Here's what I >> get with that commit which looks very similar to you: >> > >> U-Boot 2017.07-rc1-00163-g8cb3ce6 (Jun 12 2017 - 15:12:24 -0600) > > > OK, that's the same commit that ran OK on my test system. > >> Tegra124 (Jetson TK1) # boot >> MMC: no card present >> mmc_init: -123, time 0 >> tegra_mmc_send_cmd_bounced: MMC Timeout >> Interrupt status0x0001 >> Interrupt status enable 0x003b >> Interrupt signal enable 0x0002 >> Present status 0x01fb02f6 >> mmc_init: -1, time 8042 > > > I haven't seen that error occur in any commit/branch; perhaps something is > wrong with your system. This is fixed by this patch: http://patchwork.ozlabs.org/patch/772771/ I'm unsure how your board could work without that patch. > > ... >> >> USB device 0: unknown device >> ERROR: tegra-pcie: failed to power on PHY: -110 >> >> at >> /scratch/sglass/cosarm/src/third_party/u-boot/files/drivers/pci/pci_tegra.c:779/tegra_pcie_enable_controller() >> ERROR: tegra-pcie: failed to enable controller >> at >> /scratch/sglass/cosarm/src/third_party/u-boot/files/drivers/pci/pci_tegra.c:1159/pci_tegra_probe() > > > That's the issue I saw in your branch though, even though your build is for > an upstream commit. > > ... >> >> ERROR: tegra-pcie: failed to power on PHY: -110 >> >> at >> /scratch/sglass/cosarm/src/third_party/u-boot/files/drivers/pci/pci_tegra.c:779/tegra_pcie_enable_controller() >> ERROR: tegra-pcie: failed to enable controller >> at >> /scratch/sglass/cosarm/src/third_party/u-boot/files/drivers/pci/pci_tegra.c:1159/pci_tegra_probe() >> No ethernet found. >> No ethernet found. > > > Same there. > > It seems coincidental that your broken board would give the exact same error > message as my test system sees with your branch. I wonder if you have an > incremental build issue; have you tried deleting all the build results and > trying again? Yes, but same result. It works OK on beaver though. Can you try it on beaver? Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] arm: adjust PC displayed in exception handlers to point to the failing instruction
On Thu, Jun 08, 2017 at 09:52:33AM +0200, Lothar Waßmann wrote: > Adjust the program counter register to point to the failing > instruction depending on the exeption type. > This makes it easier to localize the offending instruction leading to > a fatal exception. > > Signed-off-by: Lothar Waßmann Reviewed-by: Tom Rini -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] MAINTAINERS: mpc83xx: Add new custodian
On Fri, Jun 09, 2017 at 02:50:47PM +0200, mario@gdsys.cc wrote: > Add myself as mpc83xx custodian. Reviewed-by: Tom Rini -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] dm: bcm6345_gpio: Set proper output level in bcm6345_gpio_direction_output
On Thu, Jun 08, 2017 at 05:20:12PM +0800, Axel Lin wrote: > Current code does not set output level in bcm6345_gpio_direction_output, > fix it. > > Signed-off-by: Axel Lin Reviewed-by: Tom Rini -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, 1/2] serial: stm32x7: align compatible with kernel one
On Thu, Jun 08, 2017 at 09:26:54AM +0200, Patrice Chotard wrote: > From: Patrice Chotard > > stm32x7.c driver is dedicated for STM32F7. > In kernel, "st,stm32-usart" and "st,stm32-uart" compatible > strings are dedicated for STM32F4. > > To keep U-boot and kernel aligned, replace the serial compatible > string from "st,stm32-usart", "st,stm32-uart" to > "st,stm32f7-usart", "st,stm32f7-uart" specific for STM32F7. > > Signed-off-by: Patrice Chotard > Reviewed-by: Christophe KERELLO > Reviewed-by: Patrick DELAUNAY > Acked-by: Vikas MANOCHA Reviewed-by: Tom Rini -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, 03/10] fdtgrep: Deal with NULL data passed to check_type_include()
On Wed, Jun 07, 2017 at 10:28:40AM -0600, Simon Glass wrote: > Since the parameter can be NULL we must be careful not to dereference it > in this case. > > Signed-off-by: Simon Glass > Reported-by: Coverity (CID: 163250) > Fixes: 1043d0a0 (fdt: Add fdtgrep tool) Reviewed-by: Tom Rini -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] cmd: nvedit: bring error message in sync with condition under which it appears
On Thu, Jun 08, 2017 at 02:16:14PM +0200, Lothar Waßmann wrote: > The list of symbols listed in the error message for missing Kconfig > symbols is out of sync with the symbols actually tested. > Add the missing symbols and reorder their appearance to be in sync > with the #if statement for easier checking. > > Signed-off-by: Lothar Waßmann Reviewed-by: Tom Rini -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] cmd: mtdparts: fix uninitialized variable warning
On Thu, Jun 08, 2017 at 02:04:03PM +0200, Lothar Waßmann wrote:
> commit 06a040a31bcf ("cmd: mtdparts: fix null pointer dereference in
> parse_mtdparts")
> removed the initialization of a pointer variable, which is
> subsequently used in a debug() call. This produces an uninitialized
> variable warning, when compiling with DEBUG defined.
>
> Signed-off-by: Lothar Waßmann
Reviewed-by: Tom Rini
--
Tom
signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, 04/10] fdt: Add a check to do_fdt() for coverity
On Wed, Jun 07, 2017 at 10:28:41AM -0600, Simon Glass wrote: > We know that fdt_getprop() does not return NULL when len is > 0 but > coverity does not. Add an extra check to keep it happy. > > Signed-off-by: Simon Glass > Reported-by: Coverity (CID: 163249) > Fixes: bc80295b (fdt: Add get commands to fdt) Reviewed-by: Tom Rini -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] ARM: provide a valid exception stack address for startup code
On Thu, Jun 08, 2017 at 10:16:36AM +0200, Lothar Waßmann wrote: > Create exception stack in IRAM if available to facilitate debugging of > pre-relocation code by catching exceptions rather than stopping dead. > > Signed-off-by: Lothar Waßmann Reviewed-by: Tom Rini -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] tools/tbot: update README
On Fri, Jun 09, 2017 at 06:13:34AM +0200, Heiko Schocher wrote: > refer in the README to tbots webpage, and delete > the README in tools/tbot, as the latest documentation > for tbot is on this webpage. > > Signed-off-by: Heiko Schocher Reviewed-by: Tom Rini -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, v2, 3/3] arm: dra7: Set fastboot variables in environment
On Mon, May 22, 2017 at 07:16:42PM +0300, Semen Protsenko wrote: > One can obtain those variables using next commands: > > $ fastboot getvar cpu > $ fastboot getvar secure > $ fastboot getvar board_rev > $ fastboot getvar userdata_size > > Those variables are needed for fastboot.sh script. > > Signed-off-by: Sam Protsenko > Reviewed-by: Tom Rini Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, 2/2] serial: stm32x7: simplify baud rate register calculation
On Thu, Jun 08, 2017 at 09:26:55AM +0200, Patrice Chotard wrote: > From: Patrice Chotard > > Simplify baud rate register formula and use the oversampling > uart feature. > This code is aligned with what is implemented in kernel driver > drivers/tty/serial/stm32-usart.c since kernel v4.9. > > Signed-off-by: Patrice Chotard > Reviewed-by: Christophe KERELLO > Reviewed-by: Patrick DELAUNAY > Acked-by: Vikas MANOCHA Reviewed-by: Tom Rini -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, 01/10] test: pwm: Add a check that dev is not NULL
On Wed, Jun 07, 2017 at 10:28:38AM -0600, Simon Glass wrote: > We know that uclass_get_device() does not return NULL for dev when it > succeeds but coverity does not. Add an extra check to hopefully keep it > happy. > > Signed-off-by: Simon Glass > Reported-by: Coverity (CID: 161690) > Fixes: 43b4156 (dm: sandbox: pwm: Add a basic pwm test) Reviewed-by: Tom Rini -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, 08/10] dm: core: Supress dead-code warning in __of_get_next_child()
On Wed, Jun 07, 2017 at 10:28:45AM -0600, Simon Glass wrote: > Suppress a warning on next = next->sibling. > > Signed-off-by: Simon Glass > Reported-by: Coverity (CID: 163245) > Fixes 644ec0a (dm: core: Add livetree access functions) Reviewed-by: Tom Rini -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] arm: am57xx: Keep environment in eMMC
On Fri, Jun 09, 2017 at 05:12:56PM +0300, Semen Protsenko wrote: > Use eMMC (instead of SD card) to store U-Boot environment. Use > "reserved" partition for U-Boot environment. > > Signed-off-by: Sam Protsenko > Reviewed-by: Lokesh Vutla Reviewed-by: Tom Rini -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, 09/10] board_f: Use IS_ENABLED instead of #ifdef in initf_bootstage()
On Wed, Jun 07, 2017 at 10:28:46AM -0600, Simon Glass wrote: > The current implementation makes it look like the 'if (from_spl)' part is > dead code because these features are not enabled for sandbox. We could > enable it for sandbox_spl, but this is not done yet (it requires sharing > memory between SPL and U-Boot proper which is in fact supported). > > It is probably nicer to avoid #ifdef anyway. Change it. > > Signed-off-by: Simon Glass > Reported-by: Coverity (CID: 163244) > Fixes: 824bb1b (bootstage: Support SPL) Reviewed-by: Tom Rini -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] board: ti: am335x: Fix scale_vcore for beaglebones
On Sat, Jun 10, 2017 at 01:22:56PM +0530, Lokesh Vutla wrote:
> commit 0650798824 ("board: am335x: Introduce scale_vcores")
> updated voltages of each board based on efuse. It updated
> beagle bone specific voltages under the condition board_is_bone().
> But this is true only for BeagleBoneWhite. Due to which voltages
> are not configured for BBB, BBW as wrong device is being probed.
>
> So create a common function board_is_beaglebonex() which includes
> am335x based beagle family. Use this for updating voltages.
>
> Also remove extra if condition for selecting voltages which is
> done later using a switch case and match usb current limit as
> before the commit 0650798824.
>
> Fixes: 0650798824 ("board: am335x: Introduce scale_vcores")
> Reported-by: Emmanuel Vadot
> Signed-off-by: Lokesh Vutla
Reviewed-by: Tom Rini
--
Tom
signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] arm: am57xx: Increase "bootloader" partition size
On Fri, Jun 09, 2017 at 05:12:41PM +0300, Semen Protsenko wrote: > Increase the size of u-boot.img, so that it conforms with new DFU > configuration (see commit [1]). > > [1] 7a53a1a8115b ARM: ti: Update layout for MMC and eMMC (env and dfu) > > Signed-off-by: Sam Protsenko > Reviewed-by: Tom Rini Reviewed-by: Tom Rini -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] ARM: remove bogus cp_delay() function
On Thu, Jun 08, 2017 at 09:48:41AM +0200, Lothar Waßmann wrote:
> The cp_delay() function was introduced because of a missing 'volatile'
> attribute to the 'asm' statement in get_cr() which led to the 'mrc'
> instruction in get_cr() being optimised out eventually.
> This has been fixed in commit 53fd4b8c22bb ("arm: mmu: Add missing volatile
> for reading SCTLR register")
> but the bogus cp_delay() function which was introduced as a workaround
> for the malfunctioning get_cr() was never removed.
>
> Signed-off-by: Lothar Waßmann
Reviewed-by: Tom Rini
--
Tom
signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
