lkml.org 
[lkml]   [2013]   [Aug]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRE: [PATCH] block: support embedded device command line partition
    Date
    > > +blkdevparts=<blkdev-def>[;<blkdev-def>]
    > > + <blkdev-def> := <blkdev-id>:<partdef>[,<partdef>]
    > > + <partdef> := <size>[@<offset>](part-name)
    > > +
    > > +<blkdev-id>
    > > + block device disk name, embedded device used fixed block device,
    > > + it's disk name also fixed. such as: mmcblk0, mmcblk1, mmcblk0boot0.
    >
    > The device-name isn't always fixed.
    >
    > For example, what if there are multiple SDHCI controllers, one hosting a
    > fixed eMMC device and the other an SD card? It's quite typical for the
    > eMMC's device name (which is likely what should be affected by this
    > feature) to be mmcblk0 when no SD card is present, yet be mmcblk1 when
    > an SD card is present. Is there a more precise/stable way to define
    > which device the command-line option applies to?

    Yes. Fixed is for single controller.
    For multiple controllers, currently, there is not a simple way.
    I tend to do something in the eMMC driver, such as initialize order,
    but I have not tried.

    >
    > For the root= command-line option, we use UUID= or PARTUUID= to work
    > around this issue, but that won't work for naming the whole device.
    >
    > What about using the MMIO address of the controller hosting the device,
    > or something like that?
    >

    MMIO may be not a good idea, it is not intuitive.

    > > +<size>
    > > + partition size, in bytes, such as: 512, 1m, 1G.
    >
    > s/m/M/?
    >
    > I assume M/G are MiB/GiB?
    >
    > Does it make sense to allow specifying the sizes in units of
    > sectors/blocks? If so, which specific block/sector size in the case of
    > things like NAND flash which IIRC have multiple types/levels of sectors;
    > perhaps this is a bad idea. I guess we could easily add this feature
    > later by introducing a new suffix, so no need to solve the issue now.
    >
    > > +
    > > +<offset>
    > > + partition start address, in bytes.
    > > +
    > > +(part-name)
    > > + partition name, kernel send uevent with "PARTNAME". application can create
    > > + a link to block device partition with the name "PARTNAME".
    > > + user space application can access partition by partition name.
    >
    > Do partitions usually have a PARTNAME attribute when probed through
    > normal mechanisms like MBR? If so, I guess this is fine.
    >
    > Perhaps we can just use , as the delimiter for all fields, rather than
    > special-casing part-name to use (), so:
    >
    > size,offset,partname,size,offset,partname,...
    >
    > The partname field could easily be empty if not needed.
    >

    If no need partname, your bootargs are mmcblk0:1G,1G,1G,...

    > > +Example:
    > > + eMMC disk name is "mmcblk0" and "mmcblk0boot0"
    > > +
    > > + bootargs:
    > > +
    > 'blkdevparts=mmcblk0:1G(data0),1G(data1),-;mmcblk0boot0:1m(boot),-(kernel)'
    > > +
    > > + dmesg:
    > > + mmcblk0: p1(data0) p2(data1) p3()
    > > + mmcblk0boot0: p1(boot) p2(kernel)



    \
     
     \ /
      Last update: 2013-08-16 05:01    [W:3.466 / U:0.008 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site