[U-Boot] Enabling external watchdog support u-boot NXP imx6
Hello, I'm using external watchdog MAX6751 for imx6q board and i need to trigger it in u-boot, otherwise system would reset. The reset time is about 1 sec. I've added initialization of GPIO PAD to the board support code and function hw_watchdog_reset(). When i enable CONFIG_HW_WATCHDOG and compile u-boot, it does not load at all. When i disable CONFIG_HW_WATCHSOG, everything boots fine. Did anybody have any issues of auto-triggering watchdogs in u-boot? Thanks a lot Konstantyn ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Problem Mounting/Unmounting several UBI volumes in u-boot.
Hello Heiko,
Sorry for the delay, I was pulled to another project. Just tested your patch
and it seems to work. The mtd_devs parameter gets zeroed out when I call
'ubi part partition' which calls do_ubi-ubi_part-ubi_exit which clears out
the parameter, so when further we setup partitions, we start with index 0 in
the mtd_dev_param[].
Thank you.
Regards,
Konstantyn
-Original Message-
From: Heiko Schocher [mailto:h...@denx.de]
Sent: Thursday, January 29, 2015 4:04 AM
To: Konstantyn Prokopenko
Cc: u-boot@lists.denx.de
Subject: Re: [U-Boot] Problem Mounting/Unmounting several UBI volumes in u-boot.
Hello Konstantyn,
Am 21.01.2015 15:57, schrieb Konstantyn Prokopenko:
Hello Heiko,
I'll try the patch today. Thank you very much!
Did you found time for trying it? I want to prepare a pull-request for ubi, and
it would be nice to have fixed your problem too ;-)
bye,
Heiko
Regards,
Konstantyn
-Original Message-
From: Heiko Schocher [mailto:h...@denx.de]
Sent: Wednesday, January 21, 2015 12:57 AM
To: Konstantyn Prokopenko
Cc: u-boot@lists.denx.de
Subject: Re: [U-Boot] Problem Mounting/Unmounting several UBI volumes in
u-boot.
Hello Konstantyn,
Am 20.01.2015 17:09, schrieb Konstantyn Prokopenko:
Hello,
I'm using the latest u-boot on our custom board. The u-boot is located on
the NAND flash in the first 4MB partition. I break 256MB NAND into 4 MTD
partitions: u-boot(4MB), kernel(4MB), rootfs(100MB), safefs(40MB),
varfs(108MB).
We are using Freescale iMX6 processor (nitrogen6x BSP in u-boot). I've
modified board support code to include our pad configurations and additional
hardware.
Also I added misc driver for our system initialization. The driver would
mount rootfs UBI fs on rootfs MTD partition and validate system. If failed,
it would unmounts it and mount UBI fs on safefs MTD partition and load it.
The problem was with unmounting rootfs and initializing safefs partition.
Here is the relevant portion of my initialization script:
echo Loading just in case, default kernel from
installation partition...; \
nand read 1080 40 40; \
echo Configuring NAND flash for MTD...; \
mtdparts default; mtdparts; \
echo Mounting Root filesystem; \
ubi part rootfs; \
ubifsmount ubi0:rootfs; \
echo Verifying if filesystem and kernel is OK...; \
parallax validate 1 kernel; \
if test ${parallax_result} = 0; then \
echo Reading kernel file from rootfs; \
else \
echo ROOTFS or Rootfs Kernel appears to be BAD.
Trying SAFEFS...; \
ubifsumount; \
ubi part safefs; \
ubifsmount ubi0:safefs; \
parallax validate 2 kernel; \
if test ${parallax_result} = 0; then \
echo Reading kernel file from safefs; \
else \
echo All FILESYSTEMS are bad, booting from MTD1
kernel partition; \
nand read 1080 40 40; bootm
1080; \
fi; \
fi; \
ubifsload 1080 kernel; \
ubifsumount; \
bootm 1080;\0 \
The parallax module is our own driver which is relevant to our system
operations. It tests for validity currently mounted partition. Nothing
fancy, just a bunch of MD5 checks.
OK, I've digged into the MTD/UBI code and found the problem. When mounting
the first partition, no matter which one, the mtd_dev_param[] array is
populated with the MTD device parameters entry (the first mounted
partition). The ubi_init() finds it first and successfully attaches it.
When unmounting this partition, the mtd_dev_param[] array still includes the
same entry and when attempting to mount the second partition, the array
includes two mtd_dev_param enties: The first one for already unmounted MTD
partition and the second for the next candidate.
The ubi_init start accessing this array from ID0 and after trying to attach
entry 0 errors out ignoring the second entry.
I've added a temporary hack to avoid this problem. Because UBIFS can mount
only a signgle partition at a time, I've introduced a global parameter:
Char *device_to_attach[] which is populated when ubi_mtd_param_parse() is
called.
Now, in ubi_init() I check if the current entry to the mtd_dev_array matches
the device to attach. Also I added check for NULL if we are out of devices.
...
/* Attach MTD devices */
for (i = 0; i mtd_devs; i++) {
struct mtd_dev_param *p = mtd_dev_param[i];
struct mtd_info *mtd;
if(p == NULL
Re: [U-Boot] Problem Mounting/Unmounting several UBI volumes in u-boot.
Hello Heiko,
I'll try the patch today. Thank you very much!
Regards,
Konstantyn
-Original Message-
From: Heiko Schocher [mailto:h...@denx.de]
Sent: Wednesday, January 21, 2015 12:57 AM
To: Konstantyn Prokopenko
Cc: u-boot@lists.denx.de
Subject: Re: [U-Boot] Problem Mounting/Unmounting several UBI volumes in u-boot.
Hello Konstantyn,
Am 20.01.2015 17:09, schrieb Konstantyn Prokopenko:
Hello,
I'm using the latest u-boot on our custom board. The u-boot is located on the
NAND flash in the first 4MB partition. I break 256MB NAND into 4 MTD
partitions: u-boot(4MB), kernel(4MB), rootfs(100MB), safefs(40MB),
varfs(108MB).
We are using Freescale iMX6 processor (nitrogen6x BSP in u-boot). I've
modified board support code to include our pad configurations and additional
hardware.
Also I added misc driver for our system initialization. The driver would
mount rootfs UBI fs on rootfs MTD partition and validate system. If failed,
it would unmounts it and mount UBI fs on safefs MTD partition and load it.
The problem was with unmounting rootfs and initializing safefs partition.
Here is the relevant portion of my initialization script:
echo Loading just in case, default kernel from installation
partition...; \
nand read 1080 40 40; \
echo Configuring NAND flash for MTD...; \
mtdparts default; mtdparts; \
echo Mounting Root filesystem; \
ubi part rootfs; \
ubifsmount ubi0:rootfs; \
echo Verifying if filesystem and kernel is OK...; \
parallax validate 1 kernel; \
if test ${parallax_result} = 0; then \
echo Reading kernel file from rootfs; \
else \
echo ROOTFS or Rootfs Kernel appears to be BAD. Trying
SAFEFS...; \
ubifsumount; \
ubi part safefs; \
ubifsmount ubi0:safefs; \
parallax validate 2 kernel; \
if test ${parallax_result} = 0; then \
echo Reading kernel file from safefs; \
else \
echo All FILESYSTEMS are bad, booting from MTD1
kernel partition; \
nand read 1080 40 40; bootm 1080; \
fi; \
fi; \
ubifsload 1080 kernel; \
ubifsumount; \
bootm 1080;\0 \
The parallax module is our own driver which is relevant to our system
operations. It tests for validity currently mounted partition. Nothing fancy,
just a bunch of MD5 checks.
OK, I've digged into the MTD/UBI code and found the problem. When mounting
the first partition, no matter which one, the mtd_dev_param[] array is
populated with the MTD device parameters entry (the first mounted partition).
The ubi_init() finds it first and successfully attaches it.
When unmounting this partition, the mtd_dev_param[] array still includes the
same entry and when attempting to mount the second partition, the array
includes two mtd_dev_param enties: The first one for already unmounted MTD
partition and the second for the next candidate.
The ubi_init start accessing this array from ID0 and after trying to attach
entry 0 errors out ignoring the second entry.
I've added a temporary hack to avoid this problem. Because UBIFS can mount
only a signgle partition at a time, I've introduced a global parameter:
Char *device_to_attach[] which is populated when ubi_mtd_param_parse() is
called.
Now, in ubi_init() I check if the current entry to the mtd_dev_array matches
the device to attach. Also I added check for NULL if we are out of devices.
...
/* Attach MTD devices */
for (i = 0; i mtd_devs; i++) {
struct mtd_dev_param *p = mtd_dev_param[i];
struct mtd_info *mtd;
if(p == NULL) {
printk(KERN_INFO UBI_INIT: Could not find device:
%s\n, device_to_attach);
err = -ENODEV;
goto out_slab;
}
if(strcmp(p-name, device_to_attach) != 0)
continue;
This is a temp hack, just to make it work for our needs. Please advice if
there are better ways or maybe we can just clean the mtd_dev_param array
after unmounts being called.
Can you try this patch?
http://patchwork.ozlabs.org/patch/430909/
bye,
Heiko
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Problem Mounting/Unmounting several UBI volumes in u-boot.
Hello,
I'm using the latest u-boot on our custom board. The u-boot is located on the
NAND flash in the first 4MB partition. I break 256MB NAND into 4 MTD
partitions: u-boot(4MB), kernel(4MB), rootfs(100MB), safefs(40MB), varfs(108MB).
We are using Freescale iMX6 processor (nitrogen6x BSP in u-boot). I've modified
board support code to include our pad configurations and additional hardware.
Also I added misc driver for our system initialization. The driver would mount
rootfs UBI fs on rootfs MTD partition and validate system. If failed, it would
unmounts it and mount UBI fs on safefs MTD partition and load it.
The problem was with unmounting rootfs and initializing safefs partition. Here
is the relevant portion of my initialization script:
echo Loading just in case, default kernel from installation
partition...; \
nand read 1080 40 40; \
echo Configuring NAND flash for MTD...; \
mtdparts default; mtdparts; \
echo Mounting Root filesystem; \
ubi part rootfs; \
ubifsmount ubi0:rootfs; \
echo Verifying if filesystem and kernel is OK...; \
parallax validate 1 kernel; \
if test ${parallax_result} = 0; then \
echo Reading kernel file from rootfs; \
else \
echo ROOTFS or Rootfs Kernel appears to be BAD. Trying
SAFEFS...; \
ubifsumount; \
ubi part safefs; \
ubifsmount ubi0:safefs; \
parallax validate 2 kernel; \
if test ${parallax_result} = 0; then \
echo Reading kernel file from safefs; \
else \
echo All FILESYSTEMS are bad, booting from MTD1 kernel
partition; \
nand read 1080 40 40; bootm 1080; \
fi; \
fi; \
ubifsload 1080 kernel; \
ubifsumount; \
bootm 1080;\0 \
The parallax module is our own driver which is relevant to our system
operations. It tests for validity currently mounted partition. Nothing fancy,
just a bunch of MD5 checks.
OK, I've digged into the MTD/UBI code and found the problem. When mounting the
first partition, no matter which one, the mtd_dev_param[] array is populated
with the MTD device parameters entry (the first mounted partition). The
ubi_init() finds it first and successfully attaches it.
When unmounting this partition, the mtd_dev_param[] array still includes the
same entry and when attempting to mount the second partition, the array
includes two mtd_dev_param enties: The first one for already unmounted MTD
partition and the second for the next candidate.
The ubi_init start accessing this array from ID0 and after trying to attach
entry 0 errors out ignoring the second entry.
I've added a temporary hack to avoid this problem. Because UBIFS can mount only
a signgle partition at a time, I've introduced a global parameter:
Char *device_to_attach[] which is populated when ubi_mtd_param_parse() is
called.
Now, in ubi_init() I check if the current entry to the mtd_dev_array matches
the device to attach. Also I added check for NULL if we are out of devices.
...
/* Attach MTD devices */
for (i = 0; i mtd_devs; i++) {
struct mtd_dev_param *p = mtd_dev_param[i];
struct mtd_info *mtd;
if(p == NULL) {
printk(KERN_INFO UBI_INIT: Could not find device: %s\n,
device_to_attach);
err = -ENODEV;
goto out_slab;
}
if(strcmp(p-name, device_to_attach) != 0)
continue;
This is a temp hack, just to make it work for our needs. Please advice if there
are better ways or maybe we can just clean the mtd_dev_param array after
unmounts being called.
Thank you for your time
Regards,
Konstantyn
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
