lea todos los 256MB NOR flash, pero solo borre los primeros 139MB de Linux - uboot está bien [cerrado]

1

Fondo:

Recientemente actualicé mi flash NOR de 64 MB en mi placa integrada PowerPC (P2020) a un flash NOR de 256 MB. (La placa tiene 2 GB de memoria RAM DDR). Tuve que disminuir el desplazamiento de la página para proporcionar suficiente espacio para VMALLOC de los 256MB NOR, así:

enlace

Problema:

Esto me permite ver los 256 MB del NOR desde el espacio de usuarios de Linux. (Lo he verificado escribiendo en u-boot, reiniciando y leyendo desde un usuario de Linux).

Sin embargo, solo puedo borrar los primeros 139 MB de 256 MB. Curiosamente, el límite de la memoria virtual donde los borrados comienzan a fallar está cerca de 0xE0000000. (Tal vez no sea nada.)

Instalé el código del kernel (printk) y verifiqué que el borrado falla por encima de 139MB, porque el controlador CFI no lee 0xFFFF como se esperaba después de borrar.

Como puedo leer y escribir todo el NOR de u-boot, sospecho que este es un problema de software. Específicamente, me temo que se trata de algún tipo de problema de diseño de la memoria virtual del kernel de Linux, pero no estoy seguro de lo que me permitiría leer toda la región de la memoria, pero solo escribir en una parte de la misma región.

Pregunta:

¿Hay alguna configuración de memoria (alta, baja, virtual) en el kernel que explique este comportamiento, pudiendo leer los 256 MB de NOR pero solo poder escribir en los primeros 139 MB? Desde que verifiqué el hardware en u-boot, ¿qué otro problema de software debería tener en cuenta, si no es el núcleo?

¡Gracias!

Registro de arranque:

FWIW, en el arranque, el diseño de la memoria del núcleo virtual se informa como:

[    0.000000] Zone PFN ranges:
[    0.000000]   DMA      0x00000000 -> 0x00020000
[    0.000000]   Normal   0x00020000 -> 0x00020000
[    0.000000]   HighMem  0x00020000 -> 0x00080000
[    0.000000] Movable zone start PFN for each node
[    0.000000] early_node_map[1] active PFN ranges
[    0.000000]     0: 0x00000000 -> 0x00080000
[    0.000000] MMU: Allocated 1088 bytes of context maps for 255 contexts
[    0.000000] PERCPU: Embedded 7 pages/cpu @b1c0d000 s7688 r8192 d12792 u65536
[    0.000000] pcpu-alloc: s7688 r8192 d12792 u65536 alloc=16*4096
[    0.000000] pcpu-alloc: [0] 0 [0] 1 
[    0.000000] Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 520192
...
[    0.000000] PID hash table entries: 2048 (order: 1, 8192 bytes)
[    0.000000] Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
[    0.000000] Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
[    0.000000] Memory: 2072548k/2097152k available (6360k kernel code, 23728k reserved, 252k data, 151k bss, 232k init)
[    0.000000] Kernel virtual memory layout:
[    0.000000]   * 0xfffe0000..0xfffff000  : fixmap
[    0.000000]   * 0xff800000..0xffc00000  : highmem PTEs
[    0.000000]   * 0xff7fe000..0xff800000  : early ioremap
[    0.000000]   * 0xd1000000..0xff7fe000  : vmalloc & ioremap
[    0.000000] SLUB: Genslabs=13, HWalign=32, Order=0-3, MinObjects=0, CPUs=2, Nodes=1
...
[ 1546.968602] e0000000.nor: Found 1 x16 devices at 0x0 in 16-bit bank
[ 1546.974874]  Amd/Fujitsu Extended Query Table at 0x0040
[ 1546.980463] Using buffer write method
[ 1546.984122] e0000000.nor: CFI does not contain boot bank location. Assuming top.
[ 1546.991518] number of CFI chips: 1
[ 1546.994912] cfi_cmdset_0002: Disabling erase-suspend-program due to code brokenness.
[ 1547.002680] Searching for RedBoot partition table in e0000000.nor at offset 0xffe0000
[ 1547.133862] No RedBoot partition table detected in e0000000.nor
[ 1547.139807] Creating 8 MTD partitions on "e0000000.nor":
[ 1547.145120] 0x000000000000-0x000002700000 : "NOR Partition 1"
[ 1547.153078] mtd: Giving out device 0 to NOR Partition 1
[ 1547.160343] 0x000002700000-0x000002800000 : "NOR Partition 2"
[ 1547.167177] mtd: Giving out device 1 to NOR Partition 2
[ 1547.173324] 0x000002800000-0x000003300000 : "NOR Partition 3"
[ 1547.181109] mtd: Giving out device 2 to NOR Partition 3
[ 1547.188201] 0x00000f300000-0x00000fe00000 : "NOR Partition 4"
[ 1547.195743] mtd: Giving out device 3 to NOR Partition 4
[ 1547.202574] 0x00000fe00000-0x00000ff40000 : "NOR Partition 5"
[ 1547.209759] mtd: Giving out device 4 to NOR Partition 5
[ 1547.216244] 0x00000ff40000-0x00000ff60000 : "NOR Partition 6 - DTB"
[ 1547.223602] mtd: Giving out device 5 to NOR Partition 6 - DTB
[ 1547.230273] 0x00000ff60000-0x00000ff80000 : "NOR Partition 7 - ENV"
[ 1547.238674] mtd: Giving out device 6 to NOR Partition 7 - ENV
[ 1547.246405] 0x00000ff80000-0x000010000000 : "NOR Partition 8 - u-boot"
[ 1547.254371] mtd: Giving out device 7 to NOR Partition 8 - u-boot
    
pregunta Trevor

1 respuesta

0

Especifique el rango de chips en el árbol de dispositivos:

Nuevo para mí ... Aparentemente, es posible incluir varios chips en el mismo paquete, cada uno con su propia dirección de control única. El controlador de Linux CFI cmdset-2 ya está equipado para manejar esto, pero el "número de chips" y su rango deben proporcionarse en el archivo de la placa o en el árbol de dispositivos, como por ejemplo:

....
localbus@ffe05000 {
    #address-cells = <2>;
    #size-cells = <1>;
    compatible = "fsl,p2020-elbc", "fsl,elbc", "simple-bus";
    reg = <0 0xffe05000 0 0x1000>;
    interrupts = <19 2>;
    interrupt-parent = <&mpic>;

    /* NOR Flash */
    ranges = <0x0 0x0 0x0 0xE0000000 0x10000000>;

    nor@0,0 {
        #address-cells = <1>;
        #size-cells = <1>;
        compatible = "cfi-flash";
        /* 2 chips of 128MB = 256M total */
        reg = <0x0 0x00000000 0x08000000
               0x0 0x08000000 0x08000000>;
        bank-width = <2>;
        device-width = <1>;

        partition@0 {
            /* 39 MB for SquashFS Root File System - Image #1 */
            reg = <0x00000000 0x02700000>;
            label = "NOR (RO) SquashFS Root File System";
            /* read-only; */
        };
        ...

Observe que el rango completo de NOR se subdivide en 2 rangos de registro separados. La modificación de mi árbol de dispositivos, como anteriormente, resolvió mi problema.

Espero que esto ayude a alguien más! :)

Kernel Docs:

Ver:

enlace

Específicamente:

enlace

y

enlace

    
respondido por el Trevor

Lea otras preguntas en las etiquetas