Since "57cebc4 mtd: ubi: Fix scrubbing during attach" we make sure
that the wear level worker does not start too early. However, now
there are cases when the worker starts too late. When a ubi image is
freshly written a volume may be autoresized. This has to be done
after the wear level worker is started because otherwise the initial
fastmap update will not be able to find any anchor PEBs.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
When a initrd is given we calculate the next free memory position
as:
free_mem = PAGE_ALIGN(initrd_end);
This is wrong when initrd_end exactly falls on a page boundary.
In this case PAGE_ALIGN() does nothing and free_mem becomes
initrd_end and the following bootm_load_devicetree() and thus
booting fails with -ENOMEM.
Fix this by correctly advancing to the next free memory position.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
ensure_wear_leveling() is called at the end of ubi_wl_init() and may
come to the decision to scrub some blocks. In the Kernel this is done
in a separate thread, but in barebox we do this synchronously. The
problem is that during ubi_wl_init() the EBA system is not yet
initialized (ubi_eba_init() is not yet called), so the wear level worker
hits a NULL pointer deref when the fastmap needs to be updated and
ubi_write_fastmap() accesses vol->eba_tbl.
Solve this by honoring the ubi->thread_enabled flag which is only set
to true when UBI is sufficiently initialized. This means we now can
have multiple works queued, so we can no longer simply do one work when
queued, but instead have to continue to do work until all work is done.
The best place to do so is a ubi_thread() function which behaves similar
to the Kernel function with the same name, but is called synchronously
in barebox. To make sure that the initially queued works are done, the
call to (no-op) wake_up_process() at the end of ubi_attach_mtd_dev()
is replaced with a call to ubi_thread().
While at it also honor the ubi->ro_mode flag to make sure we do not do
any wear leveling work on readonly UBI devices.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
The Auvidea H100 is a baseboard for the SolidRun MicroSOM, which
provides HDMI IN/OUT capabilities.
Currently supported is only a combination of the H100 baseboard
with a i2eX MicroSOM.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Instead of hardcoding the different RAM sizes.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
So far it was hardcoded for each board if defenv-1 or defenv-2 is used.
Make this a user choice so that a particular board no longer enforces
a defenv type.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Currently it's hardcoded for each board which defaultenv version is
used. This is unfortunate since some people like the other defaultenv
version better and may want to select it.
This patch removes the board specific environment path
CONFIG_DEFAULT_ENVIRONMENT_PATH and instead adds it via:
if (IS_ENABLED(CONFIG_DEFAULT_ENVIRONMENT_GENERIC))
defaultenv_append_directory(defaultenv_<board>);
This way we can make sure that the defaultenv-1 board specific bits are
only compiled in when defaultenv-1 is actually in use.
The next step is to make the defaultenv version selection a user visible
choice.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
OnRISC Baltos devices are based on a am335x SoC and can be booted
either from MMC or NAND.
Signed-off-by: Yegor Yefremov <yegorslists@googlemail.com>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Devices can have a dot in the name, so we can't expect to find the
full device name before the first dot. Currently parameters of devices
with a dot in the name are inaccessible from the shell.
Fix this by iterating over the possible device name / parameter name
combinations to find a existing combination.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
It was found that pin 63 also works as input and so the respective function
is renamed from "gpo" to "gpio". The respective commit in Linux is:
a526973e0291 ("pinctrl: mvebu: Fix mapping of pin 63 (gpo -> gpio)")
which appeared in v4.1-rc3. The devicetrees are fixed accordingly since
commit
ce5cad51f381 ("ARM: dts: armada-370: Update the mpp63 function in the device tree on Armada 370")
which appeared in v4.6-rc1.
This fixes a runtime warning on the affected machines
(globalscale-mirabox and netgear-rn104) and makes the pin functional
again.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
kwboot knows how to work with an image for a different boot medium now.
So there is no reason to generate a dedicated UART image any more.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Sending an image that specifies one of the alternative boot sources doesn't
make sense. So change the boot source to UART on the fly.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
There was only a single caller who passes prot=PROT_READ unconditionally.
So drop this parameter and simplify accordingly.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Together with the previous changes that allow to handle the scenario where
too many messages were sent, this greatly improves the probability to hit
the time window during which the CPU accepts a boot message.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
After entering uart boot mode the CPU prints some diagnostic messages.
Showing them to the user helps her to notice when the message window was
missed or there is an other problem.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
When flushing input before sending of a boot message the acknowledging
reply for the previous message from the CPU might be discarded and so
missed.
So only flush once before sending boot messages in a loop.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
If we sent the boot message too often the CPU might already have started
to interpret this as an xmodem packet. As sender and receiver are not in
sync it's impossible to transfer a packet successfully.
So when we get a NAK send '\xff' bytes until the receiver reaches the
packet boundary. When we send too many the SoC replies with a NAK for
each byte and doesn't interpret it as the start of a new package (which
must start with SOH == '\x01').
A slower alternative would be to wait for another NAK which is sent when
reception of the already started packet times out.
This was tested on an Armada XP based machine with bootrom version 1.20.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Without first assigning to ret it doesn't make sense to check it.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
The current ARM64 implementation is lacking the lowlevel functions
to do the relocation. Don't allow to select it.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
ARM64 has native instructions for division and thus doesn't need the
helper functions implemented in those files.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Don't allow it to be selected in a ARM64 build.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
The unwind code to support this feature is not there yet.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
We don't yet have an implementation for those two features on ARM64, so move
them to a place where they are only selected for a 32bit barebox.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
The current ARM64 lowlevel code needs the exception vector to set
up all the ELs. Select ARM_EXCEPTIONS to make sure this is always
present.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
The eDP part need to be able to read the panel EDID.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
The DCC console uses coprocessor registers registers accesses, the
implementation of those for ARMv8 is currently missing.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Register imx6_fixup_cpus() for MX6Q+ as well as for MX6Q and MX6DL.
Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Factor out CPU revision identification code from imx6_init() into a
standalone inline function (similar to imx6_cpu_type()), so that it
would be possible to use that functionality in PBL code.
Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
