Hi Miquel,
On 06.07.2018 14:26, Miquel Raynal wrote:
Jagan Teki <jagannadh.t...@gmail.com> wrote on Fri, 6 Jul 2018 17:08:57
+0530:
On Wed, Jun 6, 2018 at 9:00 PM, Miquel Raynal <miquel.ray...@bootlin.com> wrote:
There should not be a 'nand' command, a 'sf' command and certainly not
another 'spi-nand'. Write a 'mtd' command instead to manage all MTD
devices at once. This should be the preferred way to access any MTD
device.
So are you planning to integrate sf, nand command in future, adding
them dm conversion of many stuff. I would like to reommend to go with
spinand command. I have been through this and finally added spinor
command, which I will going to in soon. once all are converted to dm,
it would be easy and meaningfull to have common command.
I'm not sure we are in sync about this. The whole point of the previous
discussion was to decide whether or not we should make full use of
the MTD stack or not. I think it was pretty clear on the fact that
people prefer to be close to Linux's architecture on this regard.
MTD being an abstraction of the type of memory, I don't get the
point in creating yet another command each time a new type of
device is supported. The fact that all the drivers of these devices
register to the MTD layer makes it trivial to interact with. So why
should we wait?
Yes, please don't add new commands for each subsystem / device-type.
I like the idea of adding one new command-set (your mtd command) and
extending this one to all other device-types over the time.
BTW: I'm testing your SPI NAND patches right now (still struggling
with some Gigadevice SPI NAND) and found that the "mtd" command is
not really in-line with the usual U-Boot commands. Here some
comments:
- Use hex values per default (addresses, sizes and soffset)
- "mtd read" just prints the read values. It makes more sense
to read into memory instead (similar to the "mtd write")
I have some patches to address these issues in the queue (still
need some massaging), which you can fold into your patchset, once
we agree on this.
Thanks,
Stefan
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
