From: iw3gtf@arcor.de
To: barebox@lists.infradead.org
Subject: errors copying UBI volumes
Date: Wed, 14 Sep 2016 17:52:32 +0200 (CEST) [thread overview]
Message-ID: <1875844407.837557.1473868352073.JavaMail.ngmail@webmail09.arcor-online.net> (raw)
Hi,
I'm working on an embedded board with an iMX25 arm CPU and a nand flash.
The board runs a linux kernel/userland.
When the user updates the firmware, the running userland/kernel creates some
new ubi volumes on the nand, let's say 'kernel_next' and 'userland_next'.
On the next system reboot barebox looks if it finds, lets say, the 'kernel_next' volume
and, in this case, it removes the old one ('kernel'), creates a new, empty one ('kernel'),
copies 'kernel_next' to the just created 'kernel' and finally removes the 'kernel_next'
to complete the update.
Here the relevant part of the init script:
...
if [ -e $kernel_next ]; then
echo "Update the kernel... "
ubirmvol $ubi_root kernel
ubimkvol $ubi_root kernel 8M
cp $kernel_next $kernel
if [ $? != 0 ]; then
echo "***Errors copying $kernel_next to $kernel"
sleep 2
else
echo "Update OK."
ubirmvol $ubi_root kernel_next
fi
fi
...
Now, after updating the barebox version to the current one, v2016.09.0, the 'cp' command
produces an almost endless sequence of failed assertions and stask backtraces:
...
UBI assert failed in ubi_eba_read_leb at 359
Function entered at [<87053010>] from [<87018ce0>]
Function entered at [<87018ce0>] from [<87017fb4>]
Function entered at [<87017fb4>] from [<8703f100>]
Function entered at [<8703f100>] from [<8703f2cc>]
Function entered at [<8703f2cc>] from [<8703faf8>]
Function entered at [<8703faf8>] from [<87039e78>]
Function entered at [<87039e78>] from [<87029178>]
Function entered at [<87029178>] from [<87003614>]
Function entered at [<87003614>] from [<87008e0c>]
Function entered at [<87008e0c>] from [<870083a0>]
Function entered at [<870083a0>] from [<8700908c>]
Function entered at [<8700908c>] from [<870011cc>]
Function entered at [<870011cc>] from [<870515d4>]
Function entered at [<870515d4>] from [<80052648>]
UBI assert failed in ubi_eba_read_leb at 359
Function entered at [<87053010>] from [<87018ce0>]
Function entered at [<87018ce0>] from [<87017fb4>]
Function entered at [<87017fb4>] from [<8703f100>]
Function entered at [<8703f100>] from [<8703f2cc>]
Function entered at [<8703f2cc>] from [<8703faf8>]
Function entered at [<8703faf8>] from [<87039e78>]
...
After trying different things I realized that 'cp' has problems
only with UBI volumes that were created by the kernel/userland
during the firmware update process; if I create a volume within
barebox it just work as expected.
Here is the source code snippet with the failing assertion:
(file <barebox_root>/drivers/mtd/ubi/eba.c)
int ubi_eba_read_leb(struct ubi_device *ubi, struct ubi_volume *vol, int lnum,
void *buf, int offset, int len, int check)
{
...
pnum = vol->eba_tbl[lnum];
if (pnum < 0) {
/*
* The logical eraseblock is not mapped, fill the whole buffer
* with 0xFF bytes. The exception is static volumes for which
* it is an error to read unmapped logical eraseblocks.
*/
dbg_eba("read %d bytes from offset %d of LEB %d:%d (unmapped)",
len, offset, vol_id, lnum);
leb_read_unlock(ubi, vol_id, lnum);
ubi_assert(vol->vol_type != UBI_STATIC_VOLUME);
memset(buf, 0xFF, len);
return 0;
}
...
Strange enough if I try to directly boot the system with:
# bootm -o /dev/nand0.ubi_volumes.ubi.dtb_next /dev/nand0.ubi_volumes.ubi.kernel_next
Loading ARM Linux zImage '/dev/nand0.ubi_volumes.ubi.kernel_next'
Loading devicetree from '/dev/nand0.ubi_volumes.ubi.dtb_next'
commandline: <NULL>
Booting Linux on physical CPU 0x0
...
then it works and the system boots correctly.
giorgio
Giorgio, iw3gtf@arcor.de
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
next reply other threads:[~2016-09-14 16:27 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-14 15:52 iw3gtf [this message]
2016-09-14 16:36 ` Alexander Shiyan
2016-09-15 7:56 ` Sascha Hauer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1875844407.837557.1473868352073.JavaMail.ngmail@webmail09.arcor-online.net \
--to=iw3gtf@arcor.de \
--cc=barebox@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox