O sistema de arquivos rootfs.jffs2 não cabe no mtd3

Eu tenho um sistema de arquivos que estou tentando colocar na partição mtd3 de memória flash. Inicializo primeiro usando o uboot e depois faço o run sdbootboot usando o cartão SD, como mostrado abaixo:

U-Boot-PetaLinux>
U-Boot-PetaLinux> printenv mtdparts
mtdparts=mtdparts=0:5M(boot),128K(bootenv),10752K(image),4M(spare)
U-Boot-PetaLinux>run sdboot

Agora eu tenho um sistema linux em execução.

.
.
.
.
root@Xilinx-ZC702-14_7:/mnt/flashboot# nandwrite -p /dev/mtd3 rootfs.jffs2
Image 3513340 bytes, NAND page 1 bytes, OOB area 0 bytes, device size 393216 bytes
nandwrite: error!: Input file does not fit into device
           error 0 (Success)
nandwrite: error!: Data was only partially written due to error
           error 0 (Success)

Então, por que isso mostra:

nandwrite: error !: O arquivo de entrada não cabe no dispositivo

Você pode ver minhas variáveis ​​ambientais na primeira linha, forneci espaço suficiente de 4 MB. Por que uma imagem do tamanho 3513340 bytes (3,35 MB) não cabe em um dispositivo? E de onde isso

tamanho do dispositivo 393216 bytes chegando?

informação adicional

#cat /proc/cmdline
console=ttyPS0,115200

mtdinfo:

Count of MTD devices:           4
Present MTD devices:            mtd0, mtd1, mtd2, mtd3
Sysfs interface supported:      yes

partições

root@Xilinx-ZC702-14_7:/# cat /proc/mtd
dev: size erasesize name
mtd0: 00500000 00010000 "boot"
mtd1: 00020000 00010000 "bootenv"
mtd2: 00a80000 00010000 "image"
mtd3: 00060000 00010000 "spare"

também pode ser visto que:

root@Xilinx-ZC702-14_7:/mnt/flash# mtdinfo /dev/mtd0
mtd0
Name:                           boot
Type:                           nor
Eraseblock size:                65536 bytes, 64.0 KiB
Amount of eraseblocks:          80 (5242880 bytes, 5.0 MiB)
Minimum input/output unit size: 1 byte
Sub-page size:                  1 byte
Character device major/minor:   90:0
Bad blocks are allowed:         false
Device is writable:             true

root@Xilinx-ZC702-14_7:/mnt/flash# mtdinfo /dev/mtd1
mtd1
Name:                           bootenv
Type:                           nor
Eraseblock size:                65536 bytes, 64.0 KiB
Amount of eraseblocks:          2 (131072 bytes, 128.0 KiB)
Minimum input/output unit size: 1 byte
Sub-page size:                  1 byte
Character device major/minor:   90:2
Bad blocks are allowed:         false
Device is writable:             true

root@Xilinx-ZC702-14_7:/mnt/flash# mtdinfo /dev/mtd2
mtd2
Name:                           image
Type:                           nor
Eraseblock size:                65536 bytes, 64.0 KiB
Amount of eraseblocks:          168 (11010048 bytes, 10.5 MiB)
Minimum input/output unit size: 1 byte
Sub-page size:                  1 byte
Character device major/minor:   90:4
Bad blocks are allowed:         false
Device is writable:             true

root@Xilinx-ZC702-14_7:/mnt/flash# mtdinfo /dev/mtd3
mtd3
Name:                           spare
Type:                           nor
Eraseblock size:                65536 bytes, 64.0 KiB
Amount of eraseblocks:          6 (393216 bytes, 384.0 KiB)
Minimum input/output unit size: 1 byte
Sub-page size:                  1 byte
Character device major/minor:   90:6
Bad blocks are allowed:         false
Device is writable:             true

Sistema

petalinux rodando no córtex ARM A9

http://www.wiki.xilinx.com/Linux

https://github.com/Xilinx

Árvore de dispositivos http://git.yoctoproject.org/cgit/cgit.cgi/meta-xilinx/plain/conf/machine/boards/zedboard/zedboard-zynq7-board.dtsi

Partição na ferramenta de configuração Essa é a ferramenta de configuração que utilizo antes da criação do image.ub. Veja o tamanho do jffs2 que é maior que o tamanho real do arquivo rootfs.jffs2.

/ sys / class / mtd

root@Xilinx-ZC702-14_7:/sys/class/mtd# ls -ld *
lrwxrwxrwx    1 root     root             0 Jan  1 00:00 mtd0 -> ../../devices/amba.0/e000d000.ps7-qspi/spi_master/spi32766/spi32766.0/mtd/mtd0
lrwxrwxrwx    1 root     root             0 Jan  1 00:00 mtd0ro -> ../../devices/amba.0/e000d000.ps7-qspi/spi_master/spi32766/spi32766.0/mtd/mtd0ro
lrwxrwxrwx    1 root     root             0 Jan  1 00:00 mtd1 -> ../../devices/amba.0/e000d000.ps7-qspi/spi_master/spi32766/spi32766.0/mtd/mtd1
lrwxrwxrwx    1 root     root             0 Jan  1 00:00 mtd1ro -> ../../devices/amba.0/e000d000.ps7-qspi/spi_master/spi32766/spi32766.0/mtd/mtd1ro
lrwxrwxrwx    1 root     root             0 Jan  1 00:00 mtd2 -> ../../devices/amba.0/e000d000.ps7-qspi/spi_master/spi32766/spi32766.0/mtd/mtd2
lrwxrwxrwx    1 root     root             0 Jan  1 00:00 mtd2ro -> ../../devices/amba.0/e000d000.ps7-qspi/spi_master/spi32766/spi32766.0/mtd/mtd2ro
lrwxrwxrwx    1 root     root             0 Jan  1 00:00 mtd3 -> ../../devices/amba.0/e000d000.ps7-qspi/spi_master/spi32766/spi32766.0/mtd/mtd3
lrwxrwxrwx    1 root     root             0 Jan  1 00:00 mtd3ro -> ../../devices/amba.0/e000d000.ps7-qspi/spi_master/spi32766/spi32766.0/mtd/mtd3ro
root@Xilinx-ZC702-14_7:/sys/class/mtd#

Drivers

root@Xilinx-ZC702-14_7:~# ls /sys/bus/*/drivers

/sys/bus/amba/drivers:

/sys/bus/clocksource/drivers:

/sys/bus/cpu/drivers:

/sys/bus/hid/drivers:
hid-generic

/sys/bus/i2c/drivers:
at24     dummy    pca954x

/sys/bus/mdio_bus/drivers:
Generic PHY

/sys/bus/mmc/drivers:
mmcblk

/sys/bus/platform/drivers:
alarmtimer       vexpress-sysreg  xilinx-gpio      xusbps-dr
of-flash         xadcps           xilinx_emaclite  xusbps-ehci
physmap-flash    xdevcfg          xqspips          xusbps-otg
sdhci-zynq       xemacps          xslcr            xusbps-udc
uio_pdrv_genirq  xgpiops          xsmcps           xwdtps
vexpress-reset   xi2cps           xuartps          zynq_remoteproc

/sys/bus/rpmsg/drivers:
rpmsg_proto          rpmsg_server_sample

/sys/bus/scsi/drivers:
ch    osst  sd    sr    st

/sys/bus/sdio/drivers:

/sys/bus/serio/drivers:

/sys/bus/spi/drivers:
m25p80

/sys/bus/usb/drivers:
hub          usb          usb-storage  usbfs        usbhid

/sys/bus/virtio/drivers:
virtio_rpmsg_bus
root@Xilinx-ZC702-14_7:~#

drivers mmc

root@Xilinx-ZC702-14_7:/# cd /sys/bus/mmc/drivers/mmcblk/
root@Xilinx-ZC702-14_7:/sys/bus/mmc/drivers/mmcblk# ls
bind       mmc0:1234  uevent     unbind
root@Xilinx-ZC702-14_7:/sys/bus/mmc/drivers/mmcblk# cd mmc0\:1234/
root@Xilinx-ZC702-14_7:/sys/devices/amba.0/e0100000.ps7-sdio/mmc_host/mmc0/mmc0:1234# ls
cid                   hwrev                 scr
csd                   manfid                serial
date                  name                  subsystem
driver                oemid                 type
erase_size            power                 uevent
fwr

Solução

Eu o resolvi usando a ferramenta de configuração e fazendo as seguintes seleções que não foram selecionadas anteriormente.

File systems  ---> 
-*- Native language support  --->
    <*>   Codepage 437 (United States, Canada)
    ...
    <*>   NLS ISO 8859-1  (Latin 1; Western European Languages)
    ... 

Primeiro, não acho que a mtdpartsvariável ambiental transmita informações significativas sobre o tamanho real das partições. mtdpartsdeve ser um parâmetro de inicialização do kernel, em vez de uma variável ambiental. Pode ser que o PetaLinux esteja colocando esses valores no ambiente durante a inicialização. No entanto, mesmo assim, parece estar no formato errado. Para ver os parâmetros de inicialização do kernel, você pode fazer cat /proc/cmdline.

Para descobrir os tamanhos de partição que o kernel tenta criar, você pode ver abaixo, /proc/mtdconforme sua outra pergunta. Para descobrir o tamanho do dispositivo de bloco real criado (em bytes), você pode fazer blockdev --getsize64 /dev/mtd3(precisa de privilégios de root). Tudo indo bem, os dois devem combinar!

Agora, supondo que o tamanho da partição seja muito pequeno, você desejará aumentar o tamanho da partição (é isso que a outra pergunta faz!). A especificação do mtdpartsparâmetro no momento da inicialização é a maneira correta de fazer isso. A partir drivers/mtd/cmdlinepart.cdo código-fonte do kernel (note que este oferece um pouco mais informação do que o trecho de quase idêntico de drivers/mtd/Kconfigque foi usado anteriormente), esta é a especificação do formato correto:

 * The format for the command line is as follows:
 *
 * mtdparts=<mtddef>[;<mtddef]
 * <mtddef>  := <mtd-id>:<partdef>[,<partdef>]
 * <partdef> := <size>[@<offset>][<name>][ro][lk]
 * <mtd-id>  := unique name used in mapping driver/device (mtd->name)
 * <size>    := standard linux memsize OR "-" to denote all remaining space
 *              size is automatically truncated at end of device
 *              if specified or trucated size is 0 the part is skipped
 * <offset>  := standard linux memsize
 *              if omitted the part will immediately follow the previous part
 *              or 0 if the first part
 * <name>    := '(' NAME ')'
 *              NAME will appear in /proc/mtd
 *
 * <size> and <offset> can be specified such that the parts are out of order
 * in physical memory and may even overlap.
 *
 * The parts are assigned MTD numbers in the order they are specified in the
 * command line regardless of their order in physical memory.
 *
 * Examples:
 *
 * 1 NOR Flash, with 1 single writable partition:
 * edb7312-nor:-
 *
 * 1 NOR Flash with 2 partitions, 1 NAND with one
 * edb7312-nor:256k(ARMboot)ro,-(root);edb7312-nand:-(home)

O que exatamente se entende por standard linux memsizenão é claro. Documentation/kernel-parameters.txtforneça o seguinte parágrafo:

Finally, the [KMG] suffix is commonly described after a number of kernel
parameter values. These 'K', 'M', and 'G' letters represent the _binary_
multipliers 'Kilo', 'Mega', and 'Giga', equalling 2^10, 2^20, and 2^30
bytes respectively. Such letter suffixes can also be entirely omitted.

É o esperado usar letras maiúsculas, mas se a minúscula kusada no exemplo especifica a mesma ou diferente potência que Knão é mencionada (é melhor ignorar isso e usar maiúsculas pela aparência).

De sua pergunta, a mtdparts=mtdparts=parte parece estar errada. Normalmente, para uma variável ambiental, o nome da variável não faz parte do valor da variável. Também 0não parece válido mtd-id.

Tudo o resto para o seu dado mtdpartsparece bem. O tamanho da partição deve ser cuidadosamente escolhido para ter o mesmo tamanho dos blocos de apagamento, mas esse parece ser o caso, considerando o tamanho do bloco de apagamento de 64KiB /proc/mtdpara sua outra pergunta.

Encontrando o correto mtd-id

Parece não haver método para determinar isso em um sistema em execução. Embora várias informações sobre dispositivos mtd possam ser encontradas em /sys/class/mtd, essas informações estão indisponíveis no momento. O mtdinfocomando parece não fazer nada além de ler e formatar essas informações, de modo que também não é muito útil

No entanto, dado o driver sendo usado, deve ser possível descobrir isso observando o código fonte do kernel. Para conseguir isso, você pode fazer o checkout da última árvore de fontes estáveis ​​com:

git clone git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git

Ou você pode preferir usar o código da sua distribuição para a versão do kernel usada. Observe que provavelmente não haverá espaço suficiente no próprio dispositivo para o download de ~ 1,4 GB. De dentro da raiz da árvore de origem, o comando a seguir revela uma boa parte dos locais onde um mtd->namevalor é definido (observe que o código não precisa usar o nome mtdda estrutura, mas geralmente o fará):

grep -rE 'mtd(\.|->|-)name[[:space:]]*='

Na maioria dos casos, é codificado no driver ou as informações estão em um .dtsarquivo. Também mostra que é provável que o driver que estamos procurando esteja abaixo drivers/mtd. Indo mais longe, usando comandos como este:

for drv in a bunch of drivers; do
  find . -iname "*$drv*"
done | grep mtd

mostra que o driver mtd é m25p80. Isso é para vários dispositivos flash que se comunicam via SPI (isso explica por que procurar coisas relacionadas ao PCI não foi útil). Observando o arquivo de origem drivers/mtd/devices/m25p80.c, vemos que mtd->nameé definido no seguinte trecho:

  if (data && data->name)
    flash->mtd.name = data->name;
  else
    flash->mtd.name = dev_name(&spi->dev);

Infelizmente, não há um único nome específico usado por esse driver, mas os nomes são definidos em outros lugares e dependem do hardware usado. Indo além, vemos que dataé uma flash_platform_dataestrutura. Procurando sua definição, temos este comentário em include/linux/spi/flash.h:

 * struct flash_platform_data: board-specific flash data
 * @name: optional flash device name (eg, as used with mtdparts=)
 * @parts: optional array of mtd_partitions for static partitioning
 * @nr_parts: number of mtd_partitions for static partitoning
 * @type: optional flash device type (e.g. m25p80 vs m25p64), for use
 *  with chips that can't be queried for JEDEC or other IDs
 *
 * Board init code (in arch/.../mach-xxx/board-yyy.c files) can
 * provide information about SPI flash parts (such as DataFlash) to
 * help set up the device and its appropriate default partitioning.
 *
 * Note that for DataFlash, sizes for pages, blocks, and sectors are
 * rarely powers of two; and partitions should be sector-aligned.

Parece que isso mtd-idé específico da placa e não da própria memória flash. Ele fornece usos dessa estrutura, -A 2imprime duas linhas após a partida e mostra a maioria dos nomes usados:

grep -rA 2 '[[:space:]]flash_platform_data'

Os nomes dos arquivos também refletem os nomes das placas, então espero que a sua esteja lá. Bastante basta usar m25p80como o mtd-id, então provavelmente é isso.

Se isso não ocorrer, o outro ramo do trecho de código será rastreado até init_nameo dispositivo, embora eu não saiba como encontrar isso ( dmesg?).

Supondo que m25p80seja mtd-id, o parâmetro do kernel deve ser:

mtdparts=m25p80:5M(boot),128K(bootenv),10752K(image),4M(spare)

Tudo o que resta é reconfigurar o U Boot com isso adicionado ao bootargsparâmetro. Reinicie e esperamos que você tenha os tamanhos de partição necessários.