From: Lukasz Majewski <l.majewski@samsung.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH] FIX: fat: Provide correct return code from disk_{read|write} to upper layers
Date: Wed, 23 Sep 2015 10:40:48 +0200 [thread overview]
Message-ID: <20150923104048.655cf61a@amdc2363> (raw)
In-Reply-To: <560219AC.1070000@nvidia.com>
Hi Stephen,
> On 09/03/2015 08:18 AM, Lukasz Majewski wrote:
> > Hi Lukasz,
> >
> >> Hi Tom,
> >>
> >>> On Thu, Sep 03, 2015 at 02:21:39PM +0200, Lukasz Majewski wrote:
> >>>
> >>>> It is very common that FAT code is using following pattern:
> >>>> if (disk_{read|write}() < 0)
> >>>> return -1;
> >>>>
> >>>> Up till now the above code was dead, since disk_{read|write)
> >>>> could only return value >= 0.
> >>>> As a result some errors from medium layer (i.e. eMMC/SD) were not
> >>>> caught.
> >>>>
> >>>> The above behavior was caused by block_{read|write|erase}
> >>>> declared at struct block_dev_desc (@part.h). It returns unsigned
> >>>> long, where 0 indicates error and > 0 indicates that medium
> >>>> operation was correct.
> >>>>
> >>>> This patch as error regards 0 returned from
> >>>> block_{read|write|erase} when nr_blocks is grater than zero.
> >>>> Read/Write operation with nr_blocks=0 should return 0 and hence
> >>>> is not considered as an error.
> >>>>
> >>>> Signed-off-by: Lukasz Majewski <l.majewski@samsung.com>
> >>>>
> >>>> Test HW: Odroid XU3 - Exynos 5433
> >>>
> >>> Can you pick up Stephen's FAT replacement series and see if it
> >>> also fixes this problem? Thanks!
> >>>
> >>
> >> Ok, I will test this fat implementation.
> >
> > I've applied v2 of this patchset
> > on top of SHA1: 79c884d7e449a63fa8f07b7495f8f9873355c48f
> >
> > Unfortunately, DFU tests fail with first attempt to pass the test.
>
> I've found a couple of problems.
>
> First up, file_fat_write() wasn't truncating the file when writing, so
> the file size wasn't changing when over-writing a large file with a
> small file. With this fixed, I can run the DFU tests just fine for all
> the small files (<1M). I've fixed this locally and in the ff branch on
> my github.
Nice to hear that you have found the error.
>
> Second, ff is slow:
>
> Some random old build I had in flash on my system:
> > Tegra124 (Jetson TK1) # load mmc 1:1 $loadaddr dfu1.bin
> > reading dfu1.bin
> > 1048576 bytes read in 95 ms (10.5 MiB/s)
>
> With my ff branch:
> > Tegra124 (Jetson TK1) # load mmc 1:1 $loadaddr dfu1.bin
> > 1048576 bytes read in 5038 ms (203.1 KiB/s)
>
> That's quite the slow-down! I believe this is causing dfu-util to time
> out on the larger files (1M+). Just for functional testing, I'll try
> and find a way to hack dfu-util to have a much larger timeout for the
> final flush operation. I wonder if the old FAT implementation had a
> disk cache (e.g. that 32K buffer in BSS?) and we need the same for
> ff?
I think that our current Fat implementation is optimized for tiny
embedded system (and probably no cache).
> I'll try and track down why it's so slow.
>
> Perhaps there are other issues as yet unfound.
We might also check with sandbox FS set of tests.
--
Best regards,
Lukasz Majewski
Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
next prev parent reply other threads:[~2015-09-23 8:40 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-28 13:50 [U-Boot] [PATCH 1/2] mmc: dw_mmc: Increase timeout to 20 seconds Lukasz Majewski
2015-08-28 13:50 ` [U-Boot] [PATCH 2/2] mmc: dw_mmc: Make timeout error visible to u-boot console Lukasz Majewski
2015-08-28 23:21 ` Simon Glass
2015-08-29 12:09 ` Lukasz Majewski
2015-08-29 15:07 ` Simon Glass
2015-09-03 12:33 ` Lukasz Majewski
2015-09-03 12:21 ` [U-Boot] [PATCH] FIX: fat: Provide correct return code from disk_{read|write} to upper layers Lukasz Majewski
2015-09-03 12:44 ` Tom Rini
2015-09-03 13:40 ` Lukasz Majewski
2015-09-03 14:18 ` Lukasz Majewski
2015-09-23 3:17 ` Stephen Warren
2015-09-23 8:40 ` Lukasz Majewski [this message]
2015-09-25 5:47 ` Stephen Warren
2015-09-09 7:02 ` Lukasz Majewski
2015-09-17 14:44 ` Lukasz Majewski
2015-09-12 12:51 ` [U-Boot] " Tom Rini
2015-08-28 21:55 ` [U-Boot] [PATCH 1/2] mmc: dw_mmc: Increase timeout to 20 seconds Marek Vasut
2015-08-29 11:55 ` Lukasz Majewski
2015-08-29 13:52 ` Marek Vasut
2015-08-29 16:38 ` Lukasz Majewski
2015-08-29 19:19 ` Marek Vasut
2015-09-01 11:19 ` Lukasz Majewski
2015-09-01 11:33 ` Marek Vasut
2015-09-01 15:25 ` Lukasz Majewski
2015-09-01 15:35 ` Marek Vasut
2015-09-01 16:22 ` Pantelis Antoniou
2015-09-02 8:06 ` Marek Vasut
2015-09-09 7:01 ` Lukasz Majewski
2015-09-09 11:34 ` Marek Vasut
2015-09-11 17:20 ` Alexey Brodkin
2015-09-11 21:45 ` Lukasz Majewski
2015-09-12 16:13 ` Marek Vasut
2015-09-13 10:03 ` Lukasz Majewski
2015-09-13 14:00 ` Marek Vasut
2015-09-14 10:15 ` Alexey Brodkin
2015-09-14 11:22 ` Lukasz Majewski
2015-09-14 13:36 ` Marek Vasut
2015-09-17 14:43 ` Lukasz Majewski
2015-09-18 0:31 ` Tom Rini
2015-09-18 7:32 ` Lukasz Majewski
2015-09-18 8:07 ` Przemyslaw Marczak
2015-09-18 19:27 ` Tom Rini
2015-09-21 15:32 ` Pantelis Antoniou
2015-09-14 10:30 ` Alexey Brodkin
2015-09-14 11:15 ` Przemyslaw Marczak
2015-09-14 10:33 ` Przemyslaw Marczak
2015-09-25 16:25 ` [U-Boot] [PATCH] mmc: dw_mmc: Increase timeout to 4 minutes (as in Linux kernel) Lukasz Majewski
2015-09-28 13:43 ` Przemyslaw Marczak
2015-09-28 21:08 ` Tom Rini
2015-09-28 21:08 ` [U-Boot] " Tom Rini
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=20150923104048.655cf61a@amdc2363 \
--to=l.majewski@samsung.com \
--cc=u-boot@lists.denx.de \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.