From: Josh Wu <josh.wu@atmel.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH] fs/fat: add a parameter: allow_whole_dev to fat_register_device()
Date: Thu, 12 Jun 2014 15:04:32 +0800 [thread overview]
Message-ID: <53995100.9080307@atmel.com> (raw)
In-Reply-To: <20140612062648.E79553803E2@gemini.denx.de>
Dear Wolfgang
Thanks for the review.
On 6/12/2014 2:26 PM, Wolfgang Denk wrote:
> Dear Josh Wu,
>
> In message <1402552643-13297-1-git-send-email-josh.wu@atmel.com> you wrote:
>> For SPL in FAT and envrionment load/save in FAT, to support no partition
>> table device (whole device is FAT partition). We need specify the partition
>> number as 0.
> Sorry, I cannot parse this. What exactly do you mean here?
Sorry, Let me try to explain it a little bit:
In U-Boot when we access a partition of a device, we use 'ifname
dev:part' format.
For instance: 'mmc 0:1' means the MMC card's #1 partition of the device #0.
But for a case if the mmc device has no partition table (MBR), it only
has one FAT partition.
To support that case, we need to access by using 'mmc 0:0'.
So the problem is: if we specify mmc 0:0 then I cannot access the mmc
device if it has a partition table.
And if we specify mmc 0:1 then I cannot access if it has no partition table.
For the fs layer this case is solved by use 'mmc 0', or 'mmc 0:auto' by
commit:
10a37fd7a4 (disk: get_device_and_partition() "auto" partition and cleanup)
But for env fat and SPL fat, we don't use the function in above commit
as we use a simpler function fat_register_device().
So this patch make this function works too.
>
>> But in FAT SPL and environment case, when we specify the partition number as
>> 1, it is reasonable to support the device has no partition table and only a
>> FAT partition.
> Why would the expectations in SPL be different from other use cases?
For example, when I use SPL binary in mmc card, I want it to load the
file: u-boot.img from the first partition.
I expect it should work even if the mmc device has no partition table.
But when I define CONFIG_SYS_MMC_SD_FAT_BOOT_PARTITION as 1. it cannot
work when the mmc has no partition table.
same thing happens for saving environment to a FAT file in MMC.
>
>> +int fat_register_device(block_dev_desc_t *dev_desc, int part_no,
>> + bool allow_whole_dev);
> Please make this an "int" type, and use 0 and 1.
Is there any special concern for that? like cause machine compatiable issue?
Best Regards,
Josh Wu
>
> Thanks.
>
> Best regards,
>
> Wolfgang Denk
>
next prev parent reply other threads:[~2014-06-12 7:04 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-12 5:57 [U-Boot] [PATCH] fs/fat: add a parameter: allow_whole_dev to fat_register_device() Josh Wu
2014-06-12 6:26 ` Wolfgang Denk
2014-06-12 7:04 ` Josh Wu [this message]
2014-06-12 8:52 ` Wolfgang Denk
2014-06-13 3:33 ` Josh Wu
2014-06-13 4:07 ` Stephen Warren
2014-06-13 4:54 ` Josh Wu
2014-06-14 20:07 ` Tom Rini
2014-06-13 4:38 ` Wolfgang Denk
2014-06-13 13:40 ` 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=53995100.9080307@atmel.com \
--to=josh.wu@atmel.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.