[U-Boot] Problem building am335x_evm config
Hi, I'm having some very basic problem with building u-boot. Using clean v2014.04 checkout, I run config: make CROSS_COMPILE=arm-none-eabi- O=out/am335x_evm am335x_evm_config Which passes fine. But when I run the actual build after that I'm getting an error: $ make CROSS_COMPILE=arm-none-eabi- O=out/am335x_evm am335x_evm GEN include/autoconf.mk.dep GEN include/autoconf.mk make[1]: *** No rule to make target 'am335x_evm'. Stop. Makefile:138: recipe for target 'sub-make' failed make: *** [sub-make] Error 2 What am I doing wrong? Best regards, Vasili ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Problem building am335x_evm config
Hi Vasisli, On Sun, May 4, 2014 at 12:56 PM, Vasili Galka wrote: > Hi, > > I'm having some very basic problem with building u-boot. Using clean > v2014.04 checkout, I run config: > > make CROSS_COMPILE=arm-none-eabi- O=out/am335x_evm am335x_evm_config Add to parameters also ARCH=arm > > Which passes fine. But when I run the actual build after that I'm getting > an error: > > $ make CROSS_COMPILE=arm-none-eabi- O=out/am335x_evm am335x_evm > GEN include/autoconf.mk.dep > GEN include/autoconf.mk > make[1]: *** No rule to make target 'am335x_evm'. Stop. > Makefile:138: recipe for target 'sub-make' failed > make: *** [sub-make] Error 2 > > What am I doing wrong? > > Best regards, > Vasili > > ___ > U-Boot mailing list > U-Boot@lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot > BR, marek -- as simple and primitive as possible - Marek Belisko - OPEN-NANDRA Freelance Developer Ruska Nova Ves 219 | Presov, 08005 Slovak Republic Tel: +421 915 052 184 skype: marekwhite twitter: #opennandra web: http://open-nandra.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Problem building am335x_evm config
Hi Vasili, please do not top post. On Sun, May 4, 2014 at 1:18 PM, Vasili Galka wrote: > Hi Marek, > > I've followed your advice and tried the following two on clean tree: > > make ARCH=arm CROSS_COMPILE=arm-none-eabi- O=out/am335x_evm > am335x_evm_config > > make ARCH=arm CROSS_COMPILE=arm-none-eabi- O=out/am335x_evm am335x_evm > > Unfortunately, this does not help. I'm still getting the same error. Try: make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- am335x_evm_defconfig make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- it works for me (please update your CROSS_COMPILE) > > Best, > Vasili > > > > On Sun, May 4, 2014 at 2:12 PM, Belisko Marek > wrote: >> >> Hi Vasisli, >> >> On Sun, May 4, 2014 at 12:56 PM, Vasili Galka wrote: >> > Hi, >> > >> > I'm having some very basic problem with building u-boot. Using clean >> > v2014.04 checkout, I run config: >> > >> > make CROSS_COMPILE=arm-none-eabi- O=out/am335x_evm am335x_evm_config >> Add to parameters also ARCH=arm >> > >> > Which passes fine. But when I run the actual build after that I'm >> > getting >> > an error: >> > >> > $ make CROSS_COMPILE=arm-none-eabi- O=out/am335x_evm am335x_evm >> > GEN include/autoconf.mk.dep >> > GEN include/autoconf.mk >> > make[1]: *** No rule to make target 'am335x_evm'. Stop. >> > Makefile:138: recipe for target 'sub-make' failed >> > make: *** [sub-make] Error 2 >> > >> > What am I doing wrong? >> > >> > Best regards, >> > Vasili >> > >> > ___ >> > U-Boot mailing list >> > U-Boot@lists.denx.de >> > http://lists.denx.de/mailman/listinfo/u-boot >> > >> >> BR, >> >> marek >> >> -- >> as simple and primitive as possible >> - >> Marek Belisko - OPEN-NANDRA >> Freelance Developer >> >> Ruska Nova Ves 219 | Presov, 08005 Slovak Republic >> Tel: +421 915 052 184 >> skype: marekwhite >> twitter: #opennandra >> web: http://open-nandra.com > > BR, marek -- as simple and primitive as possible - Marek Belisko - OPEN-NANDRA Freelance Developer Ruska Nova Ves 219 | Presov, 08005 Slovak Republic Tel: +421 915 052 184 skype: marekwhite twitter: #opennandra web: http://open-nandra.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Problem building am335x_evm config
Hi Marek, I've followed your advice and tried the following two on clean tree: make ARCH=arm CROSS_COMPILE=arm-none-eabi- O=out/am335x_evm am335x_evm_config make ARCH=arm CROSS_COMPILE=arm-none-eabi- O=out/am335x_evm am335x_evm Unfortunately, this does not help. I'm still getting the same error. Best, Vasili On Sun, May 4, 2014 at 2:12 PM, Belisko Marek wrote: > Hi Vasisli, > > On Sun, May 4, 2014 at 12:56 PM, Vasili Galka wrote: > > Hi, > > > > I'm having some very basic problem with building u-boot. Using clean > > v2014.04 checkout, I run config: > > > > make CROSS_COMPILE=arm-none-eabi- O=out/am335x_evm am335x_evm_config > Add to parameters also ARCH=arm > > > > Which passes fine. But when I run the actual build after that I'm getting > > an error: > > > > $ make CROSS_COMPILE=arm-none-eabi- O=out/am335x_evm am335x_evm > > GEN include/autoconf.mk.dep > > GEN include/autoconf.mk > > make[1]: *** No rule to make target 'am335x_evm'. Stop. > > Makefile:138: recipe for target 'sub-make' failed > > make: *** [sub-make] Error 2 > > > > What am I doing wrong? > > > > Best regards, > > Vasili > > > > ___ > > U-Boot mailing list > > U-Boot@lists.denx.de > > http://lists.denx.de/mailman/listinfo/u-boot > > > > BR, > > marek > > -- > as simple and primitive as possible > - > Marek Belisko - OPEN-NANDRA > Freelance Developer > > Ruska Nova Ves 219 | Presov, 08005 Slovak Republic > Tel: +421 915 052 184 > skype: marekwhite > twitter: #opennandra > web: http://open-nandra.com > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Latest u-boot release on BeagleBone Black for FreeBSD
Hello Xuebing, (freebsd-arm added on cc),
On di, 2014-04-08 at 16:52 +0800, Xuebing Wang wrote:
> Hi u-boot community,
>
> I am trying to port u-boot (release u-boot-2014.04-rc3.tar.bz2) to
> FreeBSD on BeagleBone Black.
>
> In FreeBSD, there is a u-boot loader (named ubldr), which can call
> u-boot API to get fdt (Flat Device Tree) data.
>
> I have to comment out below 3 lines, in order to get correct fdt data in
> FreeBSD ubldr from u-boot. Would you please advice what is the best way
> to fix this?
>
> In file common/env_common.c:
> const uchar *env_get_addr(int index)
> {
> // if (gd->env_valid)
> // return (uchar *)(gd->env_addr + index);
> // else
> return &default_environment[index];
> }
>
Assuming that you checked that your environment is valid you might be
facing the fact that the gd pointer is corrupted. gd is a pointer to the
"global data" and used for storing globals which are available before
and after relocation. On (32bit) ARM this value used to be stored in
register r8 but moved to r9 (llvm cannot reserve an arbitrary register,
but can reserve r9 for platform specific usage). If ubldr uses r9 you
end up with a invalid gd pointer when calling back into u-boot. ubldr
now reserves r8 and r9 so a recent version should work fine on an older
U-boot as well as current master.
Can you check the latest ubldr?
Regards,
Jeroen
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Problem building am335x_evm config
On Sun, May 4, 2014 at 2:24 PM, Belisko Marek wrote: > Hi Vasili, > > please do not top post. > > On Sun, May 4, 2014 at 1:18 PM, Vasili Galka wrote: > > Hi Marek, > > > > I've followed your advice and tried the following two on clean tree: > > > > make ARCH=arm CROSS_COMPILE=arm-none-eabi- O=out/am335x_evm > > am335x_evm_config > > > > make ARCH=arm CROSS_COMPILE=arm-none-eabi- O=out/am335x_evm am335x_evm > > > > Unfortunately, this does not help. I'm still getting the same error. > Try: > make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- am335x_evm_defconfig > make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- > > it works for me (please update your CROSS_COMPILE) > > > > > Best, > > Vasili > > > > > > > > On Sun, May 4, 2014 at 2:12 PM, Belisko Marek > > wrote: > >> > >> Hi Vasisli, > >> > >> On Sun, May 4, 2014 at 12:56 PM, Vasili Galka wrote: > >> > Hi, > >> > > >> > I'm having some very basic problem with building u-boot. Using clean > >> > v2014.04 checkout, I run config: > >> > > >> > make CROSS_COMPILE=arm-none-eabi- O=out/am335x_evm am335x_evm_config > >> Add to parameters also ARCH=arm > >> > > >> > Which passes fine. But when I run the actual build after that I'm > >> > getting > >> > an error: > >> > > >> > $ make CROSS_COMPILE=arm-none-eabi- O=out/am335x_evm am335x_evm > >> > GEN include/autoconf.mk.dep > >> > GEN include/autoconf.mk > >> > make[1]: *** No rule to make target 'am335x_evm'. Stop. > >> > Makefile:138: recipe for target 'sub-make' failed > >> > make: *** [sub-make] Error 2 > >> > > >> > What am I doing wrong? > >> > > >> > Best regards, > >> > Vasili > >> > > >> > ___ > >> > U-Boot mailing list > >> > U-Boot@lists.denx.de > >> > http://lists.denx.de/mailman/listinfo/u-boot > >> > > >> > >> BR, > >> > >> marek > >> > >> -- > >> as simple and primitive as possible > >> - > >> Marek Belisko - OPEN-NANDRA > >> Freelance Developer > >> > >> Ruska Nova Ves 219 | Presov, 08005 Slovak Republic > >> Tel: +421 915 052 184 > >> skype: marekwhite > >> twitter: #opennandra > >> web: http://open-nandra.com > > > > > > BR, > > marek > > > -- > as simple and primitive as possible > - > Marek Belisko - OPEN-NANDRA > Freelance Developer > > Ruska Nova Ves 219 | Presov, 08005 Slovak Republic > Tel: +421 915 052 184 > skype: marekwhite > twitter: #opennandra > web: http://open-nandra.com > Dear Marek, First, many thanks for your help! Second, please excuse me if I did something wrong, that was merely of inexperience, hope now it is fine. Third, maybe I should have described my configuration a little more on the beginning, as it is not totally standard: I'm building on Cygwin using arm-none-eabi tool-chain that I've built myself. Up until now I was working on v2013.10 based branch and all was building fine. Today I wanted to migrate to v2014.04 bumped into the above problem. I don't fully understand why my tool-chain is not good enough for the newer branch and what I shall do now. Looking forward for your advice. Regards, Vasili ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Problem building am335x_evm config
Hello Vasili, On zo, 2014-05-04 at 14:48 +0300, Vasili Galka wrote: > On Sun, May 4, 2014 at 2:24 PM, Belisko Marek wrote: > > > > > > > I've followed your advice and tried the following two on clean tree: > > > > > > make ARCH=arm CROSS_COMPILE=arm-none-eabi- O=out/am335x_evm > > > am335x_evm_config > > > > > > make ARCH=arm CROSS_COMPILE=arm-none-eabi- O=out/am335x_evm am335x_evm > > > > > > Unfortunately, this does not help. I'm still getting the same error. > > Try: > > make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- am335x_evm_defconfig > > make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- > > > > it works for me (please update your CROSS_COMPILE) > > As Marek showed above, just use make after configure. I.o.w. remove the board name as an argument to the second make command. Regards, Jeroen ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Problem building am335x_evm config
On Sun, May 4, 2014 at 4:12 PM, Jeroen Hofstee wrote: > Hello Vasili, > > On zo, 2014-05-04 at 14:48 +0300, Vasili Galka wrote: > > On Sun, May 4, 2014 at 2:24 PM, Belisko Marek >wrote: > > > > > > > > > > I've followed your advice and tried the following two on clean tree: > > > > > > > > make ARCH=arm CROSS_COMPILE=arm-none-eabi- O=out/am335x_evm > > > > am335x_evm_config > > > > > > > > make ARCH=arm CROSS_COMPILE=arm-none-eabi- O=out/am335x_evm > am335x_evm > > > > > > > > Unfortunately, this does not help. I'm still getting the same error. > > > Try: > > > make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- am335x_evm_defconfig > > > make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- > > > > > > it works for me (please update your CROSS_COMPILE) > > > > > As Marek showed above, just use make after configure. I.o.w. remove > the board name as an argument to the second make command. > > Regards, > Jeroen > > Oh, I see. Missed this. Thank you guys! ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] mx6sabred: Add PFUZE100 PMIC support
From: Fabio Estevam
mx6sabresd boards have a PFUZE100 PMIC connected to I2C2 bus.
Add support for it.
Signed-off-by: Fabio Estevam
---
board/freescale/mx6sabresd/mx6sabresd.c | 83 +
include/configs/mx6sabresd.h| 14 ++
include/power/pfuze100_pmic.h | 4 ++
3 files changed, 101 insertions(+)
diff --git a/board/freescale/mx6sabresd/mx6sabresd.c
b/board/freescale/mx6sabresd/mx6sabresd.c
index 3e314da..9e35711 100644
--- a/board/freescale/mx6sabresd/mx6sabresd.c
+++ b/board/freescale/mx6sabresd/mx6sabresd.c
@@ -12,6 +12,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -23,6 +24,9 @@
#include
#include
#include
+#include
+#include
+#include
DECLARE_GLOBAL_DATA_PTR;
#define UART_PAD_CTRL (PAD_CTL_PUS_100K_UP | \
@@ -39,6 +43,14 @@ DECLARE_GLOBAL_DATA_PTR;
#define SPI_PAD_CTRL (PAD_CTL_HYS | PAD_CTL_SPEED_MED | \
PAD_CTL_DSE_40ohm | PAD_CTL_SRE_FAST)
+#define I2C_PAD_CTRL (PAD_CTL_PUS_100K_UP | \
+ PAD_CTL_SPEED_MED | PAD_CTL_DSE_40ohm | PAD_CTL_HYS | \
+ PAD_CTL_ODE | PAD_CTL_SRE_FAST)
+
+#define I2C_PMIC 1
+
+#define I2C_PAD MUX_PAD_CTRL(I2C_PAD_CTRL)
+
int dram_init(void)
{
gd->ram_size = get_ram_size((void *)PHYS_SDRAM, PHYS_SDRAM_SIZE);
@@ -129,6 +141,19 @@ iomux_v3_cfg_t const ecspi1_pads[] = {
MX6_PAD_KEY_ROW1__GPIO4_IO09 | MUX_PAD_CTRL(NO_PAD_CTRL),
};
+static struct i2c_pads_info i2c_pad_info1 = {
+ .scl = {
+ .i2c_mode = MX6_PAD_KEY_COL3__I2C2_SCL | I2C_PAD,
+ .gpio_mode = MX6_PAD_KEY_COL3__GPIO4_IO12 | I2C_PAD,
+ .gp = IMX_GPIO_NR(4, 12)
+ },
+ .sda = {
+ .i2c_mode = MX6_PAD_KEY_ROW3__I2C2_SDA | I2C_PAD,
+ .gpio_mode = MX6_PAD_KEY_ROW3__GPIO4_IO13 | I2C_PAD,
+ .gp = IMX_GPIO_NR(4, 13)
+ }
+};
+
static void setup_spi(void)
{
imx_iomux_v3_setup_multiple_pads(ecspi1_pads, ARRAY_SIZE(ecspi1_pads));
@@ -426,6 +451,64 @@ int board_init(void)
#ifdef CONFIG_MXC_SPI
setup_spi();
#endif
+ setup_i2c(1, CONFIG_SYS_I2C_SPEED, 0x7f, &i2c_pad_info1);
+
+ return 0;
+}
+
+int misc_init_r(void)
+{
+ struct pmic *p;
+ int ret;
+ unsigned int reg;
+
+ ret = pmic_init(I2C_PMIC);
+ if (ret)
+ return ret;
+
+ p = pmic_get("PFUZE100_PMIC");
+ ret = pmic_probe(p);
+ if (ret)
+ return ret;
+
+ pmic_reg_read(p, PFUZE100_DEVICEID, ®);
+ printf("PMIC: PFUZE100 ID=0x%02x\n", reg);
+
+ /* Increase VGEN3 from 2.5 to 2.8V */
+ pmic_reg_read(p, PFUZE100_VGEN3VOL, ®);
+ reg &= ~0xf;
+ reg |= 0xa;
+ pmic_reg_write(p, PFUZE100_VGEN3VOL, reg);
+
+ /* Increase VGEN5 from 2.8 to 3V */
+ pmic_reg_read(p, PFUZE100_VGEN5VOL, ®);
+ reg &= ~0xf;
+ reg |= 0xc;
+ pmic_reg_write(p, PFUZE100_VGEN5VOL, reg);
+
+ /* Set SW1AB stanby volage to 0.975V */
+ pmic_reg_read(p, PFUZE100_SW1ABSTBY, ®);
+ reg &= ~0x3f;
+ reg |= 0x1b;
+ pmic_reg_write(p, PFUZE100_SW1ABSTBY, reg);
+
+ /* Set SW1AB/VDDARM step ramp up time from 16us to 4us/25mV */
+ pmic_reg_read(p, PUZE_100_SW1ABCONF, ®);
+ reg &= ~0xc0;
+ reg |= 0x40;
+ pmic_reg_write(p, PUZE_100_SW1ABCONF, reg);
+
+ /* Set SW1C standby voltage to 0.975V */
+ pmic_reg_read(p, PFUZE100_SW1CSTBY, ®);
+ reg &= ~0x3f;
+ reg |= 0x1b;
+ pmic_reg_write(p, PFUZE100_SW1CSTBY, reg);
+
+ /* Set SW1C/VDDSOC step ramp up time from 16us to 4us/25mV */
+ pmic_reg_read(p, PFUZE100_SW1CCONF, ®);
+ reg &= ~0xc0;
+ reg |= 0x40;
+ pmic_reg_write(p, PFUZE100_SW1CCONF, reg);
return 0;
}
diff --git a/include/configs/mx6sabresd.h b/include/configs/mx6sabresd.h
index 0fa6573..fe846e6 100644
--- a/include/configs/mx6sabresd.h
+++ b/include/configs/mx6sabresd.h
@@ -25,6 +25,8 @@
#define CONFIG_SUPPORT_EMMC_BOOT /* eMMC specific */
+#define CONFIG_MISC_INIT_R
+
#include "mx6sabre_common.h"
#define CONFIG_SYS_FSL_USDHC_NUM 3
@@ -59,4 +61,16 @@
#define CONFIG_PCIE_IMX_POWER_GPIO IMX_GPIO_NR(3, 19)
#endif
+/* I2C Configs */
+#define CONFIG_CMD_I2C
+#define CONFIG_SYS_I2C
+#define CONFIG_SYS_I2C_MXC
+#define CONFIG_SYS_I2C_SPEED 10
+
+/* PMIC */
+#define CONFIG_POWER
+#define CONFIG_POWER_I2C
+#define CONFIG_POWER_PFUZE100
+#define CONFIG_POWER_PFUZE100_I2C_ADDR 0x08
+
#endif /* __MX6QSABRESD_CONFIG_H */
diff --git a/include/power/pfuze100_pmic.h b/include/power/pfuze100_pmic.h
index 2a9032a..8968678 100644
--- a/include/power/pfuze100_pmic.h
+++ b/include/power/pfuze100_pmic.h
@@ -15,7 +15,11 @@ enum {
PFUZE100_FABID = 0x04,
PFUZE100_SW1ABVOL = 0x20,
+ PFUZE100_SW1ABSTBY = 0x21,
+ PUZE_100_SW1ABCONF
Re: [U-Boot] [PATCH 1/2] fs:ext4:cleanup: Remove superfluous code
Hi Simon,
> On 30 April 2014 03:39, Lukasz Majewski
> wrote:
> > Code responsible for handling situation when ext4 has block size of
> > 1024B can be ordered to take less space.
> >
> > This patch does that for ext4 common and write files.
> >
> > Signed-off-by: Lukasz Majewski
>
> Reviewed-by: Simon Glass
>
> > ---
> > fs/ext4/ext4_common.c |6 ++
> > fs/ext4/ext4_write.c | 50
> > - 2 files changed,
> > 18 insertions(+), 38 deletions(-)
> >
> > diff --git a/fs/ext4/ext4_common.c b/fs/ext4/ext4_common.c
> > index 02da75c..62e2e80 100644
> > --- a/fs/ext4/ext4_common.c
> > +++ b/fs/ext4/ext4_common.c
> [snip]
>
> > @@ -181,10 +179,8 @@ static void
> > delete_double_indirect_block(struct ext2_inode *inode) break;
> >
> > debug("DICB releasing %u\n", *di_buffer);
> > - if (fs->blksz != 1024) {
> > - bg_idx = (*di_buffer) / blk_per_grp;
> > - } else {
> > - bg_idx = (*di_buffer) / blk_per_grp;
> > + bg_idx = (*di_buffer) / blk_per_grp;
>
> You don't need the brackets here (or below).
Maybe the GIT formatting is a bit misleading, but I've double checked
and it seems that those parenthesis are necessary here.
>
> > + if (fs->blksz == 1024) {
> > remainder = (*di_buffer) %
> > blk_per_grp; if (!remainder)
> > bg_idx--;
> > @@ -213,10 +209,8 @@ static void
> > delete_double_indirect_block(struct ext2_inode *inode)
> >
> > /* removing the parent double indirect block */
> > blknr = inode->b.blocks.double_indir_block;
> > - if (fs->blksz != 1024) {
> > - bg_idx = blknr / blk_per_grp;
> > - } else {
> > - bg_idx = blknr / blk_per_grp;
> > + bg_idx = blknr / blk_per_grp;
> > + if (fs->blksz == 1024) {
> > remainder = blknr % blk_per_grp;
> > if (!remainder)
> > bg_idx--;
> > @@ -293,11 +287,8 @@ static void
> > delete_triple_indirect_block(struct ext2_inode *inode) for (j = 0;
> > j < fs->blksz / sizeof(int); j++) { if (*tip_buffer == 0)
> > break;
> > - if (fs->blksz != 1024) {
> > - bg_idx = (*tip_buffer) /
> > blk_per_grp;
> > - } else {
> > - bg_idx = (*tip_buffer) /
> > blk_per_grp; -
> > + bg_idx = (*tip_buffer) /
> > blk_per_grp;
> > + if (fs->blksz == 1024) {
> > remainder = (*tip_buffer) %
> > blk_per_grp; if (!remainder)
> > bg_idx--;
> > @@ -336,11 +327,8 @@ static void
> > delete_triple_indirect_block(struct ext2_inode *inode)
> > * removing the grand parent blocks
> > * which is connected to inode
> > */
> > - if (fs->blksz != 1024) {
> > - bg_idx = (*tigp_buffer) /
> > blk_per_grp;
> > - } else {
> > - bg_idx = (*tigp_buffer) /
> > blk_per_grp; -
> > + bg_idx = (*tigp_buffer) / blk_per_grp;
> > + if (fs->blksz == 1024) {
> > remainder = (*tigp_buffer) %
> > blk_per_grp; if (!remainder)
> > bg_idx--;
> > @@ -371,10 +359,8 @@ static void
> > delete_triple_indirect_block(struct ext2_inode *inode)
> >
> > /* removing the grand parent triple indirect block
> > */ blknr = inode->b.blocks.triple_indir_block;
> > - if (fs->blksz != 1024) {
> > - bg_idx = blknr / blk_per_grp;
> > - } else {
> > - bg_idx = blknr / blk_per_grp;
> > + bg_idx = blknr / blk_per_grp;
> > + if (fs->blksz == 1024) {
> > remainder = blknr % blk_per_grp;
> > if (!remainder)
> > bg_idx--;
> > @@ -452,10 +438,8 @@ static int ext4fs_delete_file(int inodeno)
> >
> > for (i = 0; i < no_blocks; i++) {
> > blknr =
> > read_allocated_block(&(node_inode->inode), i);
> > - if (fs->blksz != 1024) {
> > - bg_idx = blknr / blk_per_grp;
> > - } else {
> > - bg_idx = blknr / blk_per_grp;
> > + bg_idx = blknr / blk_per_grp;
> > + if (fs->blksz == 1024) {
Re: [U-Boot] [PATCH 2/2] fs:ext4:write:fix: Reinitialize global variables after updating a file
Hi Simon,
> Hi Lukasz,
>
> On 30 April 2014 03:39, Lukasz Majewski
> wrote:
> > This bug shows up when file stored on the ext4 file system is
> > updated.
> >
> > The ext4fs_delete_file() is responsible for deleting file's (e.g.
> > uImage) data.
> > However some global data (especially ext4fs_indir2_block), which is
> > used during file deletion are left unchanged.
> >
> > The ext4fs_indir2_block pointer stores reference to old ext4 double
> > indirect allocated blocks. When it is unchanged, after file
> > deletion, ext4fs_write_file() uses the same pointer (since it is
> > already initialized
> > - i.e. not NULL) to return number of blocks to write. This trunks
> > larger file when previous one was smaller.
> >
> > Lets consider following scenario:
> >
> > 1. Flash target with ext4 formatted boot.img (which has uImage [*]
> > on itself) 2. Developer wants to upload their custom uImage [**]
> > - When new uImage [**] is smaller than the [*] - everything
> > works correctly - we are able to store the whole smaller file with
> > corrupted ext4fs_indir2_block pointer
> > - When new uImage [**] is larger than the [*] - theCRC is
> > corrupted, since truncation on data stored at eMMC was done.
> > 3. When uImage CRC error appears, then reboot and THOR/DFU
> > reflashing causes proper setting of ext4fs_indir2_block() and after
> > that uImage[**] is successfully stored (correct uImage [*] metadata
> > is stored at an eMMC on the first flashing).
> >
> > Due to above the bug was very difficult to reproduce.
>
> I wonder if a sandbox test would be a good idea? You could fairly easy
> mkfs in a loopback file and write a U-Boot script to operate on it.
> See test/ for some examples.
If my time budget allows, I will try to add test to sandbox.
>
> > This patch sets default values for all ext4fs_indir*
> > pointers/variables.
> >
> > Signed-off-by: Lukasz Majewski
> > ---
> > fs/ext4/ext4_common.c | 23 ++-
> > fs/ext4/ext4_write.c |1 +
> > include/ext4fs.h |1 +
> > 3 files changed, 16 insertions(+), 9 deletions(-)
> >
> > diff --git a/fs/ext4/ext4_common.c b/fs/ext4/ext4_common.c
> > index 62e2e80..d0de285 100644
> > --- a/fs/ext4/ext4_common.c
> > +++ b/fs/ext4/ext4_common.c
> > @@ -1841,16 +1841,8 @@ long int read_allocated_block(struct
> > ext2_inode *inode, int fileblock) return blknr;
> > }
> >
> > -void ext4fs_close(void)
> > +void ext4fs_reinit_global(void)
> > {
> > - if ((ext4fs_file != NULL) && (ext4fs_root != NULL)) {
> > - ext4fs_free_node(ext4fs_file,
> > &ext4fs_root->diropen);
> > - ext4fs_file = NULL;
> > - }
> > - if (ext4fs_root != NULL) {
> > - free(ext4fs_root);
> > - ext4fs_root = NULL;
> > - }
> > if (ext4fs_indir1_block != NULL) {
> > free(ext4fs_indir1_block);
> > ext4fs_indir1_block = NULL;
> > @@ -1870,6 +1862,19 @@ void ext4fs_close(void)
> > ext4fs_indir3_blkno = -1;
> > }
> > }
> > +void ext4fs_close(void)
> > +{
> > + if ((ext4fs_file != NULL) && (ext4fs_root != NULL)) {
> > + ext4fs_free_node(ext4fs_file,
> > &ext4fs_root->diropen);
> > + ext4fs_file = NULL;
> > + }
> > + if (ext4fs_root != NULL) {
> > + free(ext4fs_root);
> > + ext4fs_root = NULL;
> > + }
> > +
> > + ext4fs_reinit_global();
> > +}
> >
> > int ext4fs_iterate_dir(struct ext2fs_node *dir, char *name,
> > struct ext2fs_node **fnode, int
> > *ftype) diff --git a/fs/ext4/ext4_write.c b/fs/ext4/ext4_write.c
> > index 46c573b..4a5f652 100644
> > --- a/fs/ext4/ext4_write.c
> > +++ b/fs/ext4/ext4_write.c
> > @@ -562,6 +562,7 @@ static int ext4fs_delete_file(int inodeno)
> >
> > ext4fs_update();
> > ext4fs_deinit();
> > + ext4fs_reinit_global();
> >
> > if (ext4fs_init() != 0) {
> > printf("error in File System init\n");
> > diff --git a/include/ext4fs.h b/include/ext4fs.h
> > index aacb147..fbbb002 100644
> > --- a/include/ext4fs.h
> > +++ b/include/ext4fs.h
> > @@ -133,6 +133,7 @@ int ext4fs_open(const char *filename);
> > int ext4fs_read(char *buf, unsigned len);
> > int ext4fs_mount(unsigned part_length);
> > void ext4fs_close(void);
> > +void ext4fs_reinit_global(void);
>
> Can we have a comment as to what this function does?
I can add comment to the source code. No problem.
>
> > int ext4fs_ls(const char *dirname);
> > int ext4fs_exists(const char *filename);
> > void ext4fs_free_node(struct ext2fs_node *node, struct ext2fs_node
> > *currroot); --
> > 1.7.10.4
> >
>
> Regards,
> Simon
--
Best regards,
Lukasz Majewski
Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-Boot, dm, ubi: struct device is declared twice
Hello Simon,
Am 02.05.2014 16:29, schrieb Simon Glass:
Hi,
On 2 May 2014 01:16, Heiko Schocher wrote:
Hello Marek,
Am 02.05.2014 08:06, schrieb Marek Vasut:
On Friday, May 02, 2014 at 07:19:01 AM, Heiko Schocher wrote:
Hello Simon, Marek,
just updating to current mainline code and defining
CONFIG_SYS_GENERIC_BOARD pops up the following error:
CC common/board_r.o
In file included from include/linux/mtd/flashchip.h:21:0,
from include/linux/mtd/nand.h:31,
from include/nand.h:39,
from common/board_r.c:40:
include/ubi_uboot.h:202:8: error: redefinition of 'struct device'
struct device {
^
In file included from include/dm.h:10:0,
from common/board_r.c:21:
include/dm/device.h:56:8: note: originally defined here
struct device {
^
make[1]: *** [common/board_r.o] Fehler 1
make: *** [common] Fehler 2
pollux:u-boot hs [20140502] $
for a not yet mainlined imx6 board using UBI/UBIFS on nand. I am
currently sync current Linux MTD/UBI and UBIFS code to U-Boot, but
I think this error should pop up for all boards using DM and UBI ...
In the ideal case, we should use the same struct device for both UBI and
DM, but
Yes, that was also my first thought ...
we cannot do that. Thus, renaming the DM struct device would be the best
option
for now.
Ok. I prepare a patch for this.
Linux also has struct device, so I wondered how it avoids this problem
and took a look.
Yes, the MTD/UBI and UBIFS subsystem is Code from Linux and it uses
the linux "struct device". I wonder, how DM and UBI compile together.
Is this tried somewhere?
(As I see drivers/usb/musb-new uses also "struct device" ...)
This header file seems like a special thing for U-Boot - I wonder if
Yes, it includes some missing defines, structs for the UBI Subsystem,
so we could use Linux Code ... but we have also "include/linux/compat.h
for this ... Maybe it is worth to delete this include/ubi_uboot.h
and move the missing symbols to include/linux/compat.h?
it would be better to use #define at the top of the C file for the
Yes, I thought about this too ...
The UBI subsystem in U-Boot has defined "UBI_LINUX" instead of
"__UBOOT__" ... which surprised me too.
maybe I prepare such a change (delete "UBI_LINUX" and use
"__UBOOT__") for the new sync with current Linux MTD/UBI and UBIFS
layer?
compatibility stuff (#define device ubi_device) rather than modify dm?
Hmm... I can try this ... but I am not really happy to have
such a define.
It does seem very strange to me, particularly as from what I can tell,
struct device is just a cut down version of the Linux struct.
Wouldn;t it be better to move this to include/linux/device.h then?
Looking in U-Boot:include/dm/device.h "struct device":
struct device {
*struct driver *driver;
*const char *name;
*void *platdata;
*int of_offset;
struct device *parent;
*void *priv;
*struct uclass *uclass;
*void *uclass_priv;
*struct list_head uclass_node;
*struct list_head child_head;
*struct list_head sibling_node;
*uint32_t flags;
};
All "*" are different to current mainline linux or not in it ...
so I prefer first to rename the DM "struct device" into for example
"struct u_device" ... Maybe we can sync them once with the linux
"struct device"
bye,
Heiko
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] lcd: Add support for CONFIG_LCD_NOSTDOUT
Hi Jeroen, many thanks for answer. Unfortunately no. The LCD-framework does overrule this environment settings. I guess the reason for this behaviour is, that environment ist loaded _before_ the lcd-driver is initialized. best regards, hannes Jeroen Hofstee wrote: > On do, 2014-03-06 at 15:26 +0100, Hannes Petermaier wrote: >> - Adds support for CONFIG_LCD_NOSTDOUT, which prevents switching >> stdout to the LCD screen, usefull in case when only lcd_puts(...), >> lcd_printf(...) is used for displaying status informations. >> >> Signed-off-by: Hannes Petermaier >> --- >> > > Perhaps I am missing something, but doesn't 'setenv stdout serial' not > already do what you want to achieve? > > Regards, > Jeroen > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
