RE: [PATCH v5 0/5] cramfs refresh for embedded usage
On Fri, 6 Oct 2017, Chris Brandt wrote:
> On Friday, October 06, 2017, Christoph Hellwig wrote:
> > This is still missing a proper API for accessing the file system,
> > as said before specifying a physical address in the mount command
> > line is a an absolute non-no.
> >
> > Either work with the mtd folks to get the mtd core down to an absolute
> > minimum suitable for you, or figure out a way to specify fs nodes
> > through DT or similar.
>
> On my system, the QSPI Flash is memory mapped and set up by the boot
> loader. In order to test the upstream kernel, I use a squashfs image and
> mtd-rom.
>
> So, 0x1800 is the physical address of flash as it is seen by the
> CPU.
>
> Is there any benefit to doing something similar to this?
>
> /* File System */
> /* Requires CONFIG_MTD_ROM=y */
> qspi@1800 {
> compatible = "mtd-rom";
> probe-type = "map_rom";
> reg = <0x1800 0x400>; /* 64 MB*/
> bank-width = <4>;
> device-width = <1>;
>
> #address-cells = <1>;
> #size-cells = <1>;
>
> partition@80 {
> label ="user";
> reg = <0x080 0x80>; /* 8MB @ 0x1880 */
> read-only;
> };
> };
>
>
> Of course this basically ioremaps the entire space on probe, but I think
> what you really want to do is just ioremap pages at a time (maybe..I
> might not be following your code correctly)
No need for ioremaping pages individually. This creates unneeded
overhead, both in terms of code execution and TLB trashing. With a
single map, the ARM code at least is smart enough to fit large MMU
descriptors when possible with a single TLB for a large region. And if
you're interested in XIP cramfs then you do have huge vmalloc space to
spare anyway.
As to the requirement for a different interface than a raw physical
address: I'm investigating factoring out the MTD partition parsing code
so it could be used with or without the rest of MTD. Incidentally, the
person who wrote the very first incarnation of MTD partitioning 17 years
ago was actually me, so with luck I might be able to figure out
something sensible.
Nicolas
RE: [PATCH v5 0/5] cramfs refresh for embedded usage
On Fri, 6 Oct 2017, Chris Brandt wrote:
> On Friday, October 06, 2017, Christoph Hellwig wrote:
> > This is still missing a proper API for accessing the file system,
> > as said before specifying a physical address in the mount command
> > line is a an absolute non-no.
> >
> > Either work with the mtd folks to get the mtd core down to an absolute
> > minimum suitable for you, or figure out a way to specify fs nodes
> > through DT or similar.
>
> On my system, the QSPI Flash is memory mapped and set up by the boot
> loader. In order to test the upstream kernel, I use a squashfs image and
> mtd-rom.
>
> So, 0x1800 is the physical address of flash as it is seen by the
> CPU.
>
> Is there any benefit to doing something similar to this?
>
> /* File System */
> /* Requires CONFIG_MTD_ROM=y */
> qspi@1800 {
> compatible = "mtd-rom";
> probe-type = "map_rom";
> reg = <0x1800 0x400>; /* 64 MB*/
> bank-width = <4>;
> device-width = <1>;
>
> #address-cells = <1>;
> #size-cells = <1>;
>
> partition@80 {
> label ="user";
> reg = <0x080 0x80>; /* 8MB @ 0x1880 */
> read-only;
> };
> };
>
>
> Of course this basically ioremaps the entire space on probe, but I think
> what you really want to do is just ioremap pages at a time (maybe..I
> might not be following your code correctly)
No need for ioremaping pages individually. This creates unneeded
overhead, both in terms of code execution and TLB trashing. With a
single map, the ARM code at least is smart enough to fit large MMU
descriptors when possible with a single TLB for a large region. And if
you're interested in XIP cramfs then you do have huge vmalloc space to
spare anyway.
As to the requirement for a different interface than a raw physical
address: I'm investigating factoring out the MTD partition parsing code
so it could be used with or without the rest of MTD. Incidentally, the
person who wrote the very first incarnation of MTD partitioning 17 years
ago was actually me, so with luck I might be able to figure out
something sensible.
Nicolas
RE: [PATCH v5 0/5] cramfs refresh for embedded usage
On Friday, October 06, 2017, Christoph Hellwig wrote:
> This is still missing a proper API for accessing the file system,
> as said before specifying a physical address in the mount command
> line is a an absolute non-no.
>
> Either work with the mtd folks to get the mtd core down to an absolute
> minimum suitable for you, or figure out a way to specify fs nodes
> through DT or similar.
On my system, the QSPI Flash is memory mapped and set up by the boot
loader. In order to test the upstream kernel, I use a squashfs image and
mtd-rom.
So, 0x1800 is the physical address of flash as it is seen by the
CPU.
Is there any benefit to doing something similar to this?
/* File System */
/* Requires CONFIG_MTD_ROM=y */
qspi@1800 {
compatible = "mtd-rom";
probe-type = "map_rom";
reg = <0x1800 0x400>; /* 64 MB*/
bank-width = <4>;
device-width = <1>;
#address-cells = <1>;
#size-cells = <1>;
partition@80 {
label ="user";
reg = <0x080 0x80>; /* 8MB @ 0x1880 */
read-only;
};
};
Of course this basically ioremaps the entire space on probe, but I think
what you really want to do is just ioremap pages at a time (maybe..I
might not be following your code correctly)
Chris
RE: [PATCH v5 0/5] cramfs refresh for embedded usage
On Friday, October 06, 2017, Christoph Hellwig wrote:
> This is still missing a proper API for accessing the file system,
> as said before specifying a physical address in the mount command
> line is a an absolute non-no.
>
> Either work with the mtd folks to get the mtd core down to an absolute
> minimum suitable for you, or figure out a way to specify fs nodes
> through DT or similar.
On my system, the QSPI Flash is memory mapped and set up by the boot
loader. In order to test the upstream kernel, I use a squashfs image and
mtd-rom.
So, 0x1800 is the physical address of flash as it is seen by the
CPU.
Is there any benefit to doing something similar to this?
/* File System */
/* Requires CONFIG_MTD_ROM=y */
qspi@1800 {
compatible = "mtd-rom";
probe-type = "map_rom";
reg = <0x1800 0x400>; /* 64 MB*/
bank-width = <4>;
device-width = <1>;
#address-cells = <1>;
#size-cells = <1>;
partition@80 {
label ="user";
reg = <0x080 0x80>; /* 8MB @ 0x1880 */
read-only;
};
};
Of course this basically ioremaps the entire space on probe, but I think
what you really want to do is just ioremap pages at a time (maybe..I
might not be following your code correctly)
Chris
Re: [PATCH v5 0/5] cramfs refresh for embedded usage
This is still missing a proper API for accessing the file system, as said before specifying a physical address in the mount command line is a an absolute non-no. Either work with the mtd folks to get the mtd core down to an absolute minimum suitable for you, or figure out a way to specify fs nodes through DT or similar.
Re: [PATCH v5 0/5] cramfs refresh for embedded usage
This is still missing a proper API for accessing the file system, as said before specifying a physical address in the mount command line is a an absolute non-no. Either work with the mtd folks to get the mtd core down to an absolute minimum suitable for you, or figure out a way to specify fs nodes through DT or similar.
