[PATCH] bmp support: Use unaligned accessors
Some fields in the bmp header are unaligned. Use unaligned accessor
functions to acces them.
Signed-off-by: Sascha Hauer s.ha...@pengutronix.de
---
lib/gui/bmp.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/lib/gui/bmp.c b/lib/gui/bmp.c
index 6943a1c..d457c01 100644
--- a/lib/gui/bmp.c
+++ b/lib/gui/bmp.c
@@ -7,6 +7,7 @@
#include gui/graphic_utils.h
#include init.h
#include gui/image_renderer.h
+#include asm/unaligned.h
struct image *bmp_open(char *inbuf, int insize)
{
@@ -19,9 +20,9 @@ struct image *bmp_open(char *inbuf, int insize)
}
img-data = inbuf;
- img-height = le32_to_cpu(bmp-header.height);
- img-width = le32_to_cpu(bmp-header.width);
- img-bits_per_pixel = le16_to_cpu(bmp-header.bit_count);
+ img-height = get_unaligned_le32(bmp-header.height);
+ img-width = get_unaligned_le32(bmp-header.width);
+ img-bits_per_pixel = get_unaligned_le16(bmp-header.bit_count);
pr_debug(bmp: %d x %d x %d data@0x%p\n, img-width, img-height,
img-bits_per_pixel, img-data);
@@ -76,7 +77,7 @@ static int bmp_renderer(struct screen *sc, struct surface *s,
struct image *img)
for (y = 0; y height; y++) {
image = (char *)bmp +
- le32_to_cpu(bmp-header.data_offset);
+
get_unaligned_le32(bmp-header.data_offset);
image += (img-height - y - 1) * img-width *
(bits_per_pixel 3);
adr = buf + (y + starty) * sc-info.line_length +
startx * (sc-info.bits_per_pixel 3);
@@ -98,7 +99,7 @@ static int bmp_renderer(struct screen *sc, struct surface *s,
struct image *img)
for (y = 0; y height; y++) {
image = (char *)bmp +
- le32_to_cpu(bmp-header.data_offset);
+
get_unaligned_le32(bmp-header.data_offset);
image += (img-height - y - 1) * img-width *
(bits_per_pixel 3);
adr = buf + (y + starty) * sc-info.line_length +
startx * (sc-info.bits_per_pixel 3);
--
2.1.4
___
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
Re: Compiling barebox for newest Yocto/meta-freescale
You better ask in some Yocto-specific mailing list, this isn't really the problem of Barebox anymore. :-) The soft-float option might come from one of your inherited configuration files. Soft-Float is definitely not optimal for the i.MX6, because this one has FPU commands. ___ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox
Re: Compiling barebox for newest Yocto/meta-freescale
Better make a Yocto patch. Not everyone compiles Barebox with a build environment. ___ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox
[PATCH 5/5] MFD/DA9053: da9053: add basic da9053 driver
Signed-off-by: Jan Luebbe j...@pengutronix.de
Signed-off-by: Juergen Borleis j...@pengutronix.de
---
drivers/mfd/Kconfig | 8 ++
drivers/mfd/Makefile | 1 +
drivers/mfd/da9053.c | 337 +++
3 files changed, 346 insertions(+)
create mode 100644 drivers/mfd/da9053.c
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 3af904d..6ec66ac 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -4,6 +4,14 @@ config MFD_ACT8846
depends on I2C
bool ACT8846 driver
+config MFD_DA9053
+ depends on I2C
+ bool DA9053 PMIC driver
+ help
+ This power management controller provides configureable power
supplies,
+ a machine restart feature and a watchdog which are effective machine
+ wide.
+
config MFD_LP3972
depends on I2C
bool LP3972 driver
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 49b9e35..2899dde 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -1,4 +1,5 @@
obj-$(CONFIG_MFD_ACT8846) += act8846.o
+obj-$(CONFIG_MFD_DA9053) += da9053.o
obj-$(CONFIG_MFD_LP3972) += lp3972.o
obj-$(CONFIG_MFD_MC13XXX) += mc13xxx.o
obj-$(CONFIG_MFD_MC34704) += mc34704.o
diff --git a/drivers/mfd/da9053.c b/drivers/mfd/da9053.c
new file mode 100644
index 000..6e86195
--- /dev/null
+++ b/drivers/mfd/da9053.c
@@ -0,0 +1,337 @@
+/*
+ * Copyright (C) 2013 Jan Luebbe j...@pengutronix.de
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ *
+ */
+
+#include common.h
+#include init.h
+#include driver.h
+#include xfuncs.h
+#include errno.h
+#include watchdog.h
+
+#include i2c/i2c.h
+#include restart.h
+#include restart.h
+
+#define DRIVERNAME da9053
+
+/* STATUS REGISTERS */
+#define DA9053_STATUS_A_REG1
+#define DA9053_STATUS_B_REG2
+#define DA9053_STATUS_C_REG3
+#define DA9053_STATUS_D_REG4
+
+/* PARK REGISTER */
+#define DA9053_PARK_REGISTER DA9053_STATUS_D_REG
+
+/* EVENT REGISTERS */
+#define DA9053_EVENT_A_REG 5
+#define DA9053_EVENT_B_REG 6
+#define DA9053_EVENT_C_REG 7
+#define DA9053_EVENT_D_REG 8
+#define DA9053_FAULTLOG_REG9
+
+/* IRQ REGISTERS */
+#define DA9053_IRQ_MASK_A_REG 10
+#define DA9053_IRQ_MASK_B_REG 11
+#define DA9053_IRQ_MASK_C_REG 12
+#define DA9053_IRQ_MASK_D_REG 13
+
+/* CONTROL REGISTERS */
+#define DA9053_CONTROL_A_REG 14
+#define DA9053_CONTROL_B_REG 15
+#define DA9053_CONTROL_C_REG 16
+#define DA9053_CONTROL_D_REG 17
+
+#define DA9053_PDDIS_REG 18
+#define DA9053_INTERFACE_REG 19
+#define DA9053_RESET_REG 20
+
+/* FAULT LOG REGISTER BITS */
+#define DA9053_FAULTLOG_WAITSET0X80
+#define DA9053_FAULTLOG_NSDSET 0X40
+#define DA9053_FAULTLOG_KEYSHUT0X20
+#define DA9053_FAULTLOG_TEMPOVER 0X08
+#define DA9053_FAULTLOG_VDDSTART 0X04
+#define DA9053_FAULTLOG_VDDFAULT 0X02
+#define DA9053_FAULTLOG_TWDERROR 0X01
+
+/* CONTROL REGISTER B BITS */
+#define DA9053_CONTROLB_SHUTDOWN 0X80
+#define DA9053_CONTROLB_DEEPSLEEP 0X40
+#define DA9053_CONTROLB_WRITEMODE 0X20
+#define DA9053_CONTROLB_BBATEN 0X10
+#define DA9053_CONTROLB_OTPREADEN 0X08
+#define DA9053_CONTROLB_AUTOBOOT 0X04
+#define DA9053_CONTROLB_ACTDIODE 0X02
+#define DA9053_CONTROLB_BUCKMERGE 0X01
+
+/* CONTROL REGISTER D BITS */
+#define DA9053_CONTROLD_WATCHDOG 0X80
+#define DA9053_CONTROLD_ACCDETEN 0X40
+#define DA9053_CONTROLD_GPI1415SD 0X20
+#define DA9053_CONTROLD_NONKEYSD 0X10
+#define DA9053_CONTROLD_KEEPACTEN 0X08
+#define DA9053_CONTROLD_TWDSCALE 0X07
+
+struct da9053_priv {
+ struct cdev cdev;
+ struct watchdog wd;
+ struct i2c_client *client;
+};
+
+#define cdev_to_da9053_priv(x) container_of(x, struct da9053_priv, cdev)
+#define wd_to_da9053_priv(x) container_of(x, struct da9053_priv, wd)
+
+static int da9053_reg_read(struct da9053_priv *da9053, u32 reg, u8 *val)
+{
+ int ret;
+
+ ret = i2c_read_reg(da9053-client, reg, val, 1);
+
+ return ret == 1 ? 0 : ret;
+}
+
+static int da9053_reg_write(struct da9053_priv *da9053, u32 reg, u8 val)
+{
+ int ret;
+
+ ret = i2c_write_reg(da9053-client, reg, val, 1);
+
+ return ret == 1 ? 0 : ret;
[PATCH 4/5] Watchdog/i.MX: make the watchdog driver a regular driver
Even if the driver for the internal watchdog unit is disabled, it gets enabled again silently if we select an i.MX platform. This change compiles the driver on user demand only. Barebox can handle one watchdog and one reset source. This change enables a user to select a different one if the built-in unit cannot be used due to hardware issues like power management and voltage changes the internal watchdog cannot reset correctly. Signed-off-by: Juergen Borleis j...@pengutronix.de --- arch/arm/Kconfig | 1 - drivers/watchdog/Kconfig | 3 --- drivers/watchdog/Makefile | 2 +- 3 files changed, 1 insertion(+), 5 deletions(-) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 50f3095..b115d10 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -101,7 +101,6 @@ config ARCH_IMX select GPIOLIB select COMMON_CLK select CLKDEV_LOOKUP - select WATCHDOG_IMX_RESET_SOURCE select HAS_DEBUG_LL config ARCH_MVEBU diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig index 7f7b02e..f43c101 100644 --- a/drivers/watchdog/Kconfig +++ b/drivers/watchdog/Kconfig @@ -1,7 +1,4 @@ -config WATCHDOG_IMX_RESET_SOURCE - bool - menuconfig WATCHDOG bool Watchdog support help diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile index 865fc47..446056d 100644 --- a/drivers/watchdog/Makefile +++ b/drivers/watchdog/Makefile @@ -1,4 +1,4 @@ obj-$(CONFIG_WATCHDOG) += wd_core.o obj-$(CONFIG_WATCHDOG_MXS28) += im28wd.o obj-$(CONFIG_WATCHDOG_JZ4740) += jz4740.o -obj-$(CONFIG_WATCHDOG_IMX_RESET_SOURCE) += imxwd.o +obj-$(CONFIG_WATCHDOG_IMX) += imxwd.o -- 2.1.4 ___ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox
Re: Compiling barebox for newest Yocto/meta-freescale
Hi, You better ask in some Yocto-specific mailing list, this isn't really the problem of Barebox anymore. :-) The soft-float option might come from one of your inherited configuration files. I am completely confused now, because Yocto guys said that the problem is in Barebox... :-) At least i can compile thousands of recipes on Yocto, currently Barebox is the only one having this issue. I spent a lot of time debugging this problem in the recent days and i see the float abi is set to hard in the bitbake environment, and the soft float is not even supported by gcc (that is the problem). Currently i blame the kernel build system used by Barebox about setting soft float abi. Soft-Float is definitely not optimal for the i.MX6, because this one has FPU commands. I agree. Regards Gyorgy Kovesdi ___ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox
Re: Compiling barebox for newest Yocto/meta-freescale
Look at barebox/arch/arm/Makefile. Around line 47 you see -msoft-float specified to both CPPFLAGS and AFLAGS. So specifying CC=-msoft-hard would bites with this. Does compiling Barebox outside of Yocto work? E.g. something like: make ARCH=arm CROSS_COMPILE=/home/schurig/d/mkarm/gcc-linaro-arm-linux-gnueabihf-4.8-2014.04_linux/bin/arm-linux-gnueabihf- (I'm using http://releases.linaro.org/14.04/components/toolchain/binaries/gcc-linaro-arm-linux-gnueabihf-4.8-2014.04_linux.tar.xz, but you'd of corse specify your own prefix). Also note that my compiler is gnueabiarmhf (hf is hard-float), but has not trouble compiling in something with -msoft-float. Maybe your cross-compiler cannot do that? PS: despite I was once heavily involved into the early bitbake (during OpenEmbedded time), I stopped using it. I now run Debian on my i.MX6 and don't fuzz with bitbake/OE/Poky/Yocto anymore :-) ___ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox
[PATCH 2/5] System restart: add a scope value to the system restart feature
Some systems have more than one feature to restart it. Maybe these restarts features are all equal or it is very important which restart feauture is used to restart the system in a reliable manner. For example if external devices must be reset in conjunction with the SoC some SoC's internal restart features cannot be used. Then an external restart feature must be forced instead by using the restart feature with the wider scope. Signed-off-by: Juergen Borleis j...@pengutronix.de --- Documentation/user/system-reset.rst | 41 ++ arch/arm/lib/bootm.c | 7 +-- arch/arm/mach-at91/at91rm9200_time.c | 12 -- arch/arm/mach-bcm2835/core.c | 21 - arch/arm/mach-clps711x/reset.c | 10 - arch/arm/mach-davinci/time.c | 12 -- arch/arm/mach-digic/core.c | 25 --- arch/arm/mach-ep93xx/clocksource.c | 17 +--- arch/arm/mach-highbank/reset.c | 12 +- arch/arm/mach-mvebu/armada-370-xp.c | 9 ++-- arch/arm/mach-mvebu/common.c | 13 -- arch/arm/mach-mvebu/dove.c | 9 ++-- arch/arm/mach-mvebu/include/mach/common.h| 1 - arch/arm/mach-mvebu/kirkwood.c | 9 ++-- arch/arm/mach-mxs/soc-imx23.c| 8 ++-- arch/arm/mach-mxs/soc-imx28.c| 13 -- arch/arm/mach-netx/generic.c | 11 - arch/arm/mach-nomadik/reset.c| 13 -- arch/arm/mach-omap/am33xx_generic.c | 4 +- arch/arm/mach-omap/include/mach/am33xx-generic.h | 2 +- arch/arm/mach-omap/include/mach/omap3-generic.h | 2 +- arch/arm/mach-omap/include/mach/omap4-generic.h | 2 +- arch/arm/mach-omap/omap3_generic.c | 5 +-- arch/arm/mach-omap/omap4_generic.c | 4 +- arch/arm/mach-omap/omap_generic.c| 12 +++--- arch/arm/mach-pxa/common.c | 12 +- arch/arm/mach-rockchip/core.c| 14 -- arch/arm/mach-samsung/generic.c | 13 -- arch/arm/mach-socfpga/reset-manager.c| 12 +- arch/arm/mach-tegra/tegra20-pmc.c| 6 +-- arch/arm/mach-uemd/reset.c | 24 --- arch/arm/mach-versatile/core.c | 7 +-- arch/arm/mach-vexpress/reset.c | 13 -- arch/arm/mach-zynq/zynq.c| 12 -- arch/blackfin/lib/cpu.c | 11 - arch/efi/efi/efi.c | 11 - arch/mips/mach-ar231x/ar231x_reset.c | 8 ++-- arch/mips/mach-ath79/reset.c | 13 -- arch/mips/mach-bcm47xx/reset.c | 14 -- arch/mips/mach-loongson/loongson1_reset.c| 13 -- arch/mips/mach-malta/reset.c | 14 -- arch/nios2/cpu/cpu.c | 12 +- arch/openrisc/cpu/cpu.c | 11 - arch/ppc/mach-mpc5xxx/cpu.c | 11 - arch/ppc/mach-mpc85xx/cpu.c | 12 -- arch/sandbox/os/common.c | 10 - arch/x86/mach-i386/reset.c | 30 - commands/reset.c | 3 +- common/misc.c| 3 +- common/restart.c | 55 drivers/usb/gadget/f_fastboot.c | 3 +- drivers/watchdog/imxwd.c | 21 - drivers/watchdog/jz4740.c| 33 ++ include/common.h | 1 - include/restart.h| 6 +++ 55 files changed, 432 insertions(+), 250 deletions(-) delete mode 100644 arch/arm/mach-digic/core.c delete mode 100644 arch/arm/mach-uemd/reset.c delete mode 100644 arch/x86/mach-i386/reset.c diff --git a/Documentation/user/system-reset.rst b/Documentation/user/system-reset.rst index e902026..6770371 100644 --- a/Documentation/user/system-reset.rst +++ b/Documentation/user/system-reset.rst @@ -3,6 +3,11 @@ System Restart -- +.. _system_reset_pitfalls: + +Common Pitfalls +~~~ + When running the reset command barebox restarts the SoC somehow. Restart can be done in software, but a more reliable way is to use a hard reset line, which really resets the whole machine. @@ -63,3 +68,39 @@ detect the :ref:`reset_reason` anymore. From the SoC point of view it is always a POR when the PMIC handles the system reset. If you are in luck the PMIC instead can provide this information if you depend on it. Refer :ref:`reset_reason_scope` for further information. + +Handling the system restart from the developers point of view
[PATCHv2] Change barebox regarding machine-restart, reset cause detection und watchdog usage
This is V2 of this patch set. Changelog: - some functions are renamed to better reflect their meaning (*_register_handler instead of *_add_scope) - collect most of the new features in one sourcefile, due to the fact they manage system reset and share some data - clean up and remove some files, because they do not provide a function anymore (due to the removement of reset_cpu()). - the reset cause detection and restart feature is now always part of barebox Currently the architectures in barebox using a fixed approach to restart the machine: they just provide a cpu_reset() function and are done. Every architecture then does what the developer has selected in order to reset the CPU, the SoC or the whole machine. This approach is nice and simple but can fail. For example on a machine where some kind of power management changes power supply voltages in order to save power. Everything works with reduced clock speeds and voltages. It works until a warm start is triggered and the SoC and it clocks are reset to their POR defaults - but not the external power supply. In this case a restart feature is required with a wider scope - which resets the power supplies back to their POR values. To honor the scope of a restart feature is the intention of this patch series. And while a machine restart needs such a scope the use of a watchdog needs such a scope as well. And at the end of this topic, the detection of the reset cause also. BTW: everything works in a reliable manner only, if the kernel honors these scopes as well. Patch 2/5 removes the reset_cpu() function barebox wide and replaces it by registering an architecture dependend restart feature including a scope. Patch 5/5 adds a new driver to handle the DA9055 PMIC which can act as a reset cause detection, a watchdog and a restart unit. It is an example for a unit which has a machine wide scope for all of these three featured. Comments are welcome Juergen ___ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox
[PATCH 3/5] Watchdog: add a scope value to the watchdog feature
Sometimes the SoC internal watchdogs are inappropriate to restart the machine in a reliable manner. This change should help to handle more than one watchdog unit by adding a scope parameter. The framework always prefers the watchdog with the widest scope. For example a watchdog which is able to restart the whole machine (SoC + external devices) gets precedence over a watchdog which can restart the SoC only. Signed-off-by: Juergen Borleis j...@pengutronix.de --- Documentation/user/user-manual.rst | 1 + Documentation/user/watchdog.rst| 74 ++ common/restart.c | 6 drivers/watchdog/im28wd.c | 1 + drivers/watchdog/imxwd.c | 1 + drivers/watchdog/wd_core.c | 24 +++-- include/watchdog.h | 3 ++ 7 files changed, 108 insertions(+), 2 deletions(-) create mode 100644 Documentation/user/watchdog.rst diff --git a/Documentation/user/user-manual.rst b/Documentation/user/user-manual.rst index 0d6daee..8a32469 100644 --- a/Documentation/user/user-manual.rst +++ b/Documentation/user/user-manual.rst @@ -30,6 +30,7 @@ Contents: system-setup reset-reason system-reset + watchdog * :ref:`search` * :ref:`genindex` diff --git a/Documentation/user/watchdog.rst b/Documentation/user/watchdog.rst new file mode 100644 index 000..d8e6e76 --- /dev/null +++ b/Documentation/user/watchdog.rst @@ -0,0 +1,74 @@ +.. _watchdog_usage: + +Using a watchdog + + +Watchdogs are commonly used to prevent bad software from hanging the whole +system for ever. Sometimes a simple approach can help to make a system work +if hanging failures are happen very seldom: just restart the system and do +everything again in the same way as it was done when the system starts the +last time. + +But using a watchdog should always be the 'last resort' to keep a machine +working. The focus should still be on finding and fixing the bug ;) + +A more complex way to use a watchdog in a real-word example is when the state +frameworks comes into play. Then the watchdog's task isn't only to keep the +machine working. It also monitors the whole health of the machine including +hardware and software. Especially something like a firmware update can go +wrong: a wrong firmware was programmed (wrong release or for a different machine), +programming was incomplete due to a user intervention or power fail and so on. + +In this case the watchdog does not just restart the system if the software hangs, +it also provides 'additional' information about the firmware by this restart. +The barebox's state framework is now able to run some kind of state machine to handle +firmware updates in a correct manner: trying the new firmware once and if it fails falling +back to the previous firmware (if available) for example. + +Refer the :ref:`reset_reason` how to detect the reason why the bootloader runs. +This information can be used by the barebox's state framework. + +.. _watchdog_restart_pitfalls: + +Watchdog Pitfalls +~ + +If a watchdog triggers a machine restart it suffers from the same issues like +a regular user triggered system machine restart. Refer :ref:`system_reset_pitfalls` +for further details. +So keep this in mind when you select an available watchdog on your machine for +this task. And if you are a hardware designer keep this in mind even more, and +provide a reliable restart source for the software developers and to keep their +headache low. + +Watchdogs from the developers point of view +~~~ + +Watchdogs gets registered in barebox with a scope. When you register your own +watchdog driver, check its hardware scope carefully and use one of the +definitions from the file ``include/restart.h``. + +The list of defined scopes (defined in file ``include/restart.h``): + +* ``FEATURE_SCOPE_UNKNOWN``: completely useless watchdog, maybe a last resort.. +* ``FEATURE_SCOPE_CPU``: this watchdog is able to restart the core CPU only. + Regarding to the issues in :ref:`system_reset_pitfalls` this kind of watchdog + seems more or less useless. +* ``FEATURE_SCOPE_SOC``: this watchdog is able to restart the whole SoC. Regarding + to the issues in :ref:`system_reset_pitfalls` this scope is more reliable, but + depends on the machine and its hardware design if is able to bring the machine + back into life under every circumstance. +* ``FEATURE_SCOPE_MACHINE``: it is able to restart the whole machine and does + the same like a real ``POR`` does. Best scope and always reliable. + +The selected scope is very important because barebox will always use +the watchdog with the best available scope. + +But that is true only for watchdogs used in barebox and as long barebox is +running. + +If an operating system runs later on, it is the task of this OS to use a watchdog +with a correct scope. Otherwise it suffers from the :ref:`system_reset_pitfalls` +as well. This is even
[PATCH 1/5] Reset reason: add a scope value to the reset reason feature
Some systems do have more than one source to detect the reason of a reset.
In this case it depends on the initialization order which reason will be
reported to barebox. To avoid this race, this change adds a scope to the
function call to always accept settings with a wider scope and ignore
all settings with a limited scope.
This change is required to support systems where one reset reason source
is more reliable than other sources. Examples are all i.MX SoCs with
an internal reset reason detector and an external PMIC which has the same
capabilities. For these systems the external PMIC provides the correct
reset cause while the internal unit flags a POR only all the time. In order
to support one binary for more than one machine we cannot just disable the
internal reset reason detector, so we need this scope mechanism.
Assumption in this change is, the reset cause sources with a wider scope are
always reporting the correct reason and not vice versa.
Signed-off-by: Juergen Borleis j...@pengutronix.de
---
Documentation/user/reset-reason.rst | 30 ++
Documentation/user/system-reset.rst | 3 +-
arch/arm/mach-imx/imx1.c | 8 ++--
arch/arm/mach-omap/am33xx_generic.c | 14 +++
arch/arm/mach-pxa/pxa2xx.c| 12 +++---
arch/arm/mach-pxa/pxa3xx.c| 12 +++---
arch/arm/mach-samsung/reset_source.c | 8 ++--
arch/arm/mach-tegra/tegra20-pmc.c | 14 +++
common/Kconfig| 8
common/Makefile | 2 +-
common/reset_source.c | 56 ---
common/restart.c | 73 +++
drivers/watchdog/im28wd.c | 12 +++---
drivers/watchdog/imxwd.c | 8 ++--
include/{reset_source.h = restart.h} | 29 +++---
15 files changed, 164 insertions(+), 125 deletions(-)
delete mode 100644 common/reset_source.c
create mode 100644 common/restart.c
rename include/{reset_source.h = restart.h} (71%)
diff --git a/Documentation/user/reset-reason.rst
b/Documentation/user/reset-reason.rst
index a4872fa..525ade2 100644
--- a/Documentation/user/reset-reason.rst
+++ b/Documentation/user/reset-reason.rst
@@ -3,6 +3,9 @@
Reset Reason
+Using the Reset Reason
+~~
+
To handle a device in a secure and safty manner many applications are using
a watchdog or other ways to reset a system to bring it back into life if it
hangs or crashes somehow.
@@ -45,3 +48,30 @@ The following values can help to detect the reason why the
bootloader runs:
It depends on your board/SoC and its features if the hardware is able to detect
these reset reasons. Most of the time only ``POR`` and ``RST`` are supported
but often ``WDG`` as well.
+
+.. _reset_reason_scope:
+
+Scope of Reset Reason
+~
+
+Some machines can detect the reset reason via different devices, for example
+via a SoC internal devices and an externally attached device. Both can provide
+the correct reason - or not. If their reset reason point of view differ, you
+need a ``scope`` to decide what reason is the correct one. Barebox provides
+the reset reason scope via the global variable ``system.reset.scope`` and
+the following values:
+
+* ``unknown``: the software can't define the scope of the reset reason.
+* ``cpu``: the inner core CPU only point of view.
+* ``soc``: the full SoC point of view.
+* ``machine``: the full machine point of view
+
+The scopes are rated: lowest rate is ``unknown`` and ``cpu``. The highest
+rate has the ``machine`` point of view. The ``soc`` point of view in inbetween.
+
+Why can the reset reason differ due to different scopes? Think about a SoC
which
+is powered by a PMIC: the reset reason detection inside the SoC has the ``soc``
+scope, the PMIC's reset reason detection has the ``machine`` scope. In this
case
+the ``soc`` scope reset reason is always ``POR``, while the ``machine`` scope
+reset reason is ``POR`` only on a real POR, ``RST`` due to an user
+intervention and ``WDG`` because the system has failed somehow.
diff --git a/Documentation/user/system-reset.rst
b/Documentation/user/system-reset.rst
index e76e3a2..e902026 100644
--- a/Documentation/user/system-reset.rst
+++ b/Documentation/user/system-reset.rst
@@ -61,4 +61,5 @@ wide reset, like the POR is.
Drawback of the PMIC solution is, you can't use the SoC's internal mechanisms
to
detect the :ref:`reset_reason` anymore. From the SoC point of view it is always
a POR when the PMIC handles the system reset. If you are in luck the PMIC
-instead can provide this information if you depend on it.
+instead can provide this information if you depend on it. Refer
+:ref:`reset_reason_scope` for further information.
diff --git a/arch/arm/mach-imx/imx1.c b/arch/arm/mach-imx/imx1.c
index 51bdcbf..a3759df 100644
--- a/arch/arm/mach-imx/imx1.c
+++ b/arch/arm/mach-imx/imx1.c
@@ -18,7 +18,7 @@
#include mach/weim.h
#include mach/iomux-v1.h
Re: Compiling barebox for newest Yocto/meta-freescale
Hi all, Better make a Yocto patch. Not everyone compiles Barebox with a build environment. Ok, i will do that. However, IMHO it is a wrong idea to hard-wire such a setting, because everybody will run into this problem having hard-float-only environment. At least it should be configurable. BTW everybody must have a (cross) gcc which takes care about that. Regards Gyorgy Kovesdi ___ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox
Re: Compiling barebox for newest Yocto/meta-freescale
Am Dienstag, den 23.06.2015, 19:57 +0200 schrieb Gyorgy Kovesdi: Hi all, Better make a Yocto patch. Not everyone compiles Barebox with a build environment. Ok, i will do that. However, IMHO it is a wrong idea to hard-wire such a setting, because everybody will run into this problem having hard-float-only environment. At least it should be configurable. BTW everybody must have a (cross) gcc which takes care about that. It's a completely reasonable decision to explicitly build with the soft-float ABI for a bare metal component like Barebox, in order to prevent the toolchain from using any part of the ARM VFP state, which may not be initialized at that point. This has nothing to do with the decision to build your userspace with hard-float enabled. Building barebox with the hard-float ABI may actively yield broken binaries. So no, this is not a thing that should be configurable. Also you don't have a hard-float only environment, your toolchain is perfectly able to build with the soft-float ABI, it's just that Yocto apparently passes the mfloat-abi=hard flag everywhere instead of setting a reasonable toolchain default. Regards, Lucas ___ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox
[PATCH 2/2] PCI: remove bogus host bridge setup skipping
Apparently this was here to fix issues with some QEMU version,
but hasn't worked in the intended way for a long time. The probe
code should be mature enough by now, so this workaround isn't
needed anymore.
Signed-off-by: Lucas Stach d...@lynxeye.de
---
drivers/pci/pci.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index 1e45907..191561d 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -420,11 +420,6 @@ unsigned int pci_scan_bus(struct pci_bus *bus)
bus-number, dev-devfn, dev-vendor,
dev-device, class, hdr_type);
continue;
}
-
- if (class == PCI_CLASS_BRIDGE_HOST) {
- pr_debug(skip pci host bridge\n);
- continue;
- }
}
/*
--
2.1.0
___
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
[PATCH 1/2] PCI: rework BAR size calculation
The probe code now does a much better job at detecting bad BARs.
Also make sure to preserve any previous content of the BAR
registers if we don't relocate them.
Signed-off-by: Lucas Stach d...@lynxeye.de
---
I hope this fixes the problems seen with new versions of QEMU on
MIPS malta.
---
drivers/pci/pci.c | 39 ++-
1 file changed, 34 insertions(+), 5 deletions(-)
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index 3a0e7a5..1e45907 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -129,10 +129,24 @@ static struct pci_dev *alloc_pci_dev(void)
return dev;
}
+static u32 pci_size(u32 base, u32 maxbase, u32 mask)
+{
+ u32 size = maxbase mask;
+ if (!size)
+ return 0;
+
+ size = (size ~(size-1)) - 1;
+
+ if (base == maxbase ((base | size) mask) != mask)
+ return 0;
+
+ return size + 1;
+}
+
+
static void setup_device(struct pci_dev *dev, int max_bar)
{
- int bar, size;
- u32 mask;
+ int bar;
u8 cmd;
pci_read_config_byte(dev, PCI_COMMAND, cmd);
@@ -141,9 +155,12 @@ static void setup_device(struct pci_dev *dev, int max_bar)
for (bar = 0; bar max_bar; bar++) {
resource_size_t last_addr;
+ u32 orig, mask, size;
+ pci_read_config_dword(dev, PCI_BASE_ADDRESS_0 + bar * 4, orig);
pci_write_config_dword(dev, PCI_BASE_ADDRESS_0 + bar * 4,
0xfffe);
pci_read_config_dword(dev, PCI_BASE_ADDRESS_0 + bar * 4, mask);
+ pci_write_config_dword(dev, PCI_BASE_ADDRESS_0 + bar * 4, orig);
if (mask == 0 || mask == 0x) {
pr_debug(pbar%d set bad mask\n, bar);
@@ -151,7 +168,11 @@ static void setup_device(struct pci_dev *dev, int max_bar)
}
if (mask 0x01) { /* IO */
- size = ((~(mask 0xfffe)) 0x) + 1;
+ size = pci_size(orig, mask, 0xfffe);
+ if (!size) {
+ pr_debug(pbar%d bad IO mask\n, bar);
+ continue;
+ }
pr_debug(pbar%d: mask=%08x io %d bytes\n, bar, mask,
size);
if (last_io + size
dev-bus-resource[PCI_BUS_RESOURCE_IO]-end) {
@@ -164,7 +185,11 @@ static void setup_device(struct pci_dev *dev, int max_bar)
last_io += size;
} else if ((mask PCI_BASE_ADDRESS_MEM_PREFETCH)
last_mem_pref) /* prefetchable MEM */ {
- size = (~(mask 0xfff0)) + 1;
+ size = pci_size(orig, mask, 0xfff0);
+ if (!size) {
+ pr_debug(pbar%d bad P-MEM mask\n, bar);
+ continue;
+ }
pr_debug(pbar%d: mask=%08x P memory %d bytes\n,
bar, mask, size);
if (last_mem_pref + size
@@ -178,7 +203,11 @@ static void setup_device(struct pci_dev *dev, int max_bar)
last_addr = last_mem_pref;
last_mem_pref += size;
} else { /* non-prefetch MEM */
- size = (~(mask 0xfff0)) + 1;
+ size = pci_size(orig, mask, 0xfff0);
+ if (!size) {
+ pr_debug(pbar%d bad NP-MEM mask\n, bar);
+ continue;
+ }
pr_debug(pbar%d: mask=%08x NP memory %d bytes\n,
bar, mask, size);
if (last_mem + size
--
2.1.0
___
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
Re: [PATCH] libdt: fix detection of eeprom devicepath
On 06/23/2015 08:32 AM, Jan Remmet wrote: Works here with the NAND-partition backend. However udev from systemd-220 fails to find NAND-partition while systemd-219 works, no matter if your patch is applied or not. Which systemd/udev version are you using? Here I use it in a initramfs with libudev.so.1.6.0, but no running daemon. The .so version cannot be mapped directly tothe tarball version. For the record: systemd-220 is broken, 219 and 221 are working. If you need 220, cherry-pick commit 5f529f4c97a141457301477505ae7eb4c28cf610 from the systemd.git repo. Marc -- Pengutronix e.K. | Marc Kleine-Budde | Industrial Linux Solutions| Phone: +49-231-2826-924 | Vertretung West/Dortmund | Fax: +49-5121-206917- | Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de | signature.asc Description: OpenPGP digital signature ___ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox
[PATCH] param_enum: protect against invalid values
Since dev_add_param_enum is passed a pointer containing the actual value
it can contain an invalid value. Protect against it so that we do not
access invalid array elements.
Signed-off-by: Sascha Hauer s.ha...@pengutronix.de
---
lib/parameter.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/lib/parameter.c b/lib/parameter.c
index 0ac3b90..9e9f993 100644
--- a/lib/parameter.c
+++ b/lib/parameter.c
@@ -381,7 +381,7 @@ struct param_d *dev_add_param_int(struct device_d *dev,
const char *name,
struct param_enum {
struct param_d param;
- int *value;
+ unsigned int *value;
const char * const *names;
int num_names;
int (*set)(struct param_d *p, void *priv);
@@ -433,7 +433,11 @@ static const char *param_enum_get(struct device_d *dev,
struct param_d *p)
}
free(p-value);
- p-value = strdup(pe-names[*pe-value]);
+
+ if (*pe-value = pe-num_names)
+ p-value = asprintf(invalid:%d, *pe-value);
+ else
+ p-value = strdup(pe-names[*pe-value]);
return p-value;
}
--
2.1.4
___
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
Re: Fw: [Qemu-devel] [PATCH v7 0/4] i.MX: Add i.MX25 support through the 3DS evaluation board.
Hi Antony, On Tue, Jun 23, 2015 at 12:06:55AM +0300, Antony Pavlov wrote: Hi Sascha! AFAIR i.MX chips are your favorite chips. There is the qemu i.MX25 support proposal. Can we run barebox on this emulated board? Yes, we have board support for this board. This hasn't been actively touched for a long time though, so it's quite outdated. Might be worth giving a try on Qemu. Unfortunately we broke our board a few years ago, so there's no way for me to test on real hardware anymore. Sascha -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | ___ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox
[PATCH] devinfo: fix return value
devinfo on a non existing device prints:
no such device: blah
devinfo: Operation not permitted
The second message comes because devinfo returns -1 which is -EPERM.
Just return -ENODEV which will print:
devinfo: No such device
Signed-off-by: Sascha Hauer s.ha...@pengutronix.de
---
commands/devinfo.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/commands/devinfo.c b/commands/devinfo.c
index e61aaa2..3c9d6a6 100644
--- a/commands/devinfo.c
+++ b/commands/devinfo.c
@@ -68,11 +68,8 @@ static int do_devinfo(int argc, char *argv[])
}
} else {
dev = get_device_by_name(argv[1]);
-
- if (!dev) {
- printf(no such device: %s\n,argv[1]);
- return -1;
- }
+ if (!dev)
+ return -ENODEV;
if (dev-num_resources)
printf(Resources:\n);
--
2.1.4
___
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
Re: [PATCH] libdt: fix detection of eeprom devicepath
On Sun, Jun 21, 2015 at 08:36:39PM +0200, Marc Kleine-Budde wrote: On 06/19/2015 09:52 AM, Marc Kleine-Budde wrote: At the end of of_get_devicepath there is a check for eeproms, but then of_parse_partition looks for a reg property which is in a casse of a i2c eeprom is the i2c address. This results in a wrong offset. doh! With this patch a i2c eeprom backend works. It's not tested with a mtd device or a eeprom with a partition layout. AFAIK on Linux partition layouts are not supported on eeprom devices, as they are not handled by the mtd layer. I'll apply this patch and test on my standard device, which uses a mtd device. applied to master. Works here with the NAND-partition backend. However udev from systemd-220 fails to find NAND-partition while systemd-219 works, no matter if your patch is applied or not. Which systemd/udev version are you using? Here I use it in a initramfs with libudev.so.1.6.0, but no running daemon. Jan Marc -- Pengutronix e.K. | Marc Kleine-Budde | Industrial Linux Solutions| Phone: +49-231-2826-924 | Vertretung West/Dortmund | Fax: +49-5121-206917- | Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de | ___ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox ___ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox
[PATCH] param_enum: Make name strings const
Not only the array containing the pointers should be const but
also the strings themselves, so instead of using const char **
use const char * const *.
Signed-off-by: Sascha Hauer s.ha...@pengutronix.de
---
include/globalvar.h | 4 ++--
include/param.h | 4 ++--
lib/parameter.c | 4 ++--
3 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/include/globalvar.h b/include/globalvar.h
index 8b2caf1..e9fa348 100644
--- a/include/globalvar.h
+++ b/include/globalvar.h
@@ -46,7 +46,7 @@ static inline int globalvar_add_simple_bool(const char *name,
}
static inline int globalvar_add_simple_enum(const char *name,
- int *value, const char **names, int max)
+ int *value, const char * const *names, int max)
{
struct param_d *p;
@@ -98,7 +98,7 @@ static inline int globalvar_add_simple_bool(const char *name,
}
static inline int globalvar_add_simple_enum(const char *name,
- int *value, const char **names, int max)
+ int *value, const char * const *names, int max)
{
return 0;
}
diff --git a/include/param.h b/include/param.h
index 3a851fc..3fb4740 100644
--- a/include/param.h
+++ b/include/param.h
@@ -50,7 +50,7 @@ struct param_d *dev_add_param_bool(struct device_d *dev,
const char *name,
struct param_d *dev_add_param_enum(struct device_d *dev, const char *name,
int (*set)(struct param_d *p, void *priv),
int (*get)(struct param_d *p, void *priv),
- int *value, const char **names, int max, void *priv);
+ int *value, const char * const *names, int max, void *priv);
struct param_d *dev_add_param_int_ro(struct device_d *dev, const char *name,
int value, const char *format);
@@ -120,7 +120,7 @@ static inline struct param_d *dev_add_param_int(struct
device_d *dev, const char
static inline struct param_d *dev_add_param_enum(struct device_d *dev, const
char *name,
int (*set)(struct param_d *p, void *priv),
int (*get)(struct param_d *p, void *priv),
- int *value, const char **names, int max, void *priv)
+ int *value, const char * const *names, int max, void *priv)
{
return ERR_PTR(-ENOSYS);
diff --git a/lib/parameter.c b/lib/parameter.c
index 865ad9f..0ac3b90 100644
--- a/lib/parameter.c
+++ b/lib/parameter.c
@@ -382,7 +382,7 @@ struct param_d *dev_add_param_int(struct device_d *dev,
const char *name,
struct param_enum {
struct param_d param;
int *value;
- const char **names;
+ const char * const *names;
int num_names;
int (*set)(struct param_d *p, void *priv);
int (*get)(struct param_d *p, void *priv);
@@ -459,7 +459,7 @@ static void param_enum_info(struct param_d *p)
struct param_d *dev_add_param_enum(struct device_d *dev, const char *name,
int (*set)(struct param_d *p, void *priv),
int (*get)(struct param_d *p, void *priv),
- int *value, const char **names, int num_names, void *priv)
+ int *value, const char * const *names, int num_names, void
*priv)
{
struct param_enum *pe;
struct param_d *p;
--
2.1.4
___
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
Re: Compiling barebox for newest Yocto/meta-freescale
Hi, On Mo, 2015-06-22 at 17:18 +0200, György Kövesdi wrote: I have a i.MX6 based board and want to compile barebox using Yocto. It was successful so far, but something is changed in the gcc behaviour. The first thing is that some arch-specific parameters must be passed, or else the compilation fails. I could fix it, but there is another problem. I had to change - oe_runmake + oe_runmake CC=$CC for recent yocto versions. What was your fix? The option -mfloat-abi=soft is used in barebox compilation, which seems not supported by gcc. Adding -mfloat-abi=hard is not enough, the original -mfloat-abi=soft should be removed. Unfortunately, i could not find where this option is added and how to remove it. Can anybody help me to fix it? Which yocto and gcc version are you using? Could you show us the actual error messages and yocto recipe? Regards, Jan -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | ___ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox
Re: Compiling barebox for newest Yocto/meta-freescale
Hi Jan,
I had to change
- oe_runmake
+ oe_runmake CC=$CC
for recent yocto versions. What was your fix?
My fix was more complicated, by exporting ${TOOLCHAIN_OPTIONS} and
${HOST_CC_ARCH}. Thanks for this simpler solution.
The option -mfloat-abi=soft is used in barebox compilation, which
seems not supported by gcc. Adding -mfloat-abi=hard is not enough, the
original -mfloat-abi=soft should be removed. Unfortunately, i could
not find where this option is added and how to remove it.
Can anybody help me to fix it?
Which yocto and gcc version are you using? Could you show us the actual
error messages and yocto recipe?
The current fido and master branches use gcc 4.9.2 and the problem is
that soft float abi support seems missing and the option
-mfloat-abi=soft is always added by the make rules of barebox.
If i use the above mentioned fix, the result is:
arm-poky-linux-gnueabi-gcc: error: -mfloat-abi=soft and -mfloat-abi=hard
may not be used together
because -mfloat-abi=hard is passed in ${CC} variable.
If i remove the option -mfloat-abi=hard, then got this error:
... stubs.h:7:29: fatal error: gnu/stubs-soft.h: No such file or directory
that's why i think the soft abi support is missing.
IMHO the float abi should not be set by the make rules because it is
hardware specific, and therefore should be set by the build system.
Regards
György Kövesdi
___
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
