Nenhuma outra saída é vista no console após “Iniciando o Kernel…”

Question

Eu estou tentando um kernel mais novo no meu Criador CI20 (v1) , mas se eu tentar uma versão do kernel Linux 4.11.1 eu não posso obter qualquer saída após o boot. Isso leva à seguinte saída:

ci20# bootm 0x88000000;
## Booting kernel from Legacy Image at 88000000 ...
   Image Name:   Linux-4.11.1
   Image Type:   MIPS Linux Kernel Image (uncompressed)
   Data Size:    5043676 Bytes = 4.8 MiB
   Load Address: 80010000
   Entry Point:  8035d440
   Verifying Checksum ... OK
   Loading Kernel Image ... OK

Starting 

Passos do laptop:

$ git clone git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
$ git checkout v4.11.1
$ make ARCH=mips ci20_defconfig
$ make ARCH=mips CROSS_COMPILE=mipsel-linux-gnu- uImage
$ sudo cp arch/mips/boot/uImage.bin /tftpboot/uImage.4.11.1
$ sudo screen /dev/ttyUSB0 115200 

Etapas da ci20:

dhcp 0x88000000 192.168.0.14:uImage.4.11.1
bootm 0x88000000;

Se eu repetir os mesmos passos agora usando o 4.10.1, tudo funciona como esperado e eu posso ver o kernel inicializando bem:

$ git checkout v4.10.1
$ make ARCH=mips ci20_defconfig
$ make ARCH=mips CROSS_COMPILE=mipsel-linux-gnu- uImage
$ sudo cp arch/mips/boot/uImage.bin /tftpboot/uImage.4.10.1

Para referência:

$ grep CONFIG_CMDLINE ./arch/mips/configs/ci20_defconfig
CONFIG_CMDLINE_BOOL=y
CONFIG_CMDLINE="earlycon console=ttyS4,115200 clk_ignore_unused"

Como devo rastrear o problema com o tty / uart não exibindo nada (sem recorrer a uma operação do git bisect)?

    

Answer 1

Como não recebi respostas / sugestões, finalmente decidi passar por uma dolorosa operação git bisect (~ 13 iterações) entre as duas tags: v4.10.1 (bom) & v4.11.1 (ruim).

Isso me leva a:

% git bisect good
73fbc1eba7ffa3bf0ad12486232a8a1edb4e4411 is the first bad commit
commit 73fbc1eba7ffa3bf0ad12486232a8a1edb4e4411
Author: Marcin Nowakowski <[email protected]>
Date:   Wed Nov 23 14:43:49 2016 +0100

    MIPS: fix mem=X@Y commandline processing

    When a memory offset is specified through the commandline, add the
    memory in range PHYS_OFFSET:Y as reserved memory area.
    Otherwise the bootmem allocator is initialised with low page equal to
    min_low_pfn = PHYS_OFFSET, and in free_all_bootmem will process pages
    starting from min_low_pfn instead of PFN(Y).

    Signed-off-by: Marcin Nowakowski <[email protected]>
    Cc: [email protected]
    Patchwork: https://patchwork.linux-mips.org/patch/14613/
    Signed-off-by: Ralf Baechle <[email protected]>

:040000 040000 fe26fcf6d072cbaedac5a417f9f6424df16d331c b99681a22464164b88c6a3cf77b1b87957cd95d6 M  arch

Olhando para o código on-line aqui me fez perceber que o problema estava na minha configuração atual de inicialização , que afirma:

ci20# printenv 
baudrate=115200 
board_date=20140704 
board_mfr=NP 
bootargs=console=ttyS4,115200 console=tty0 mem=256M@0x0 
mem=768M@0x30000000 rootwait quiet rw root=/dev/mmcblk0p1 
bootcmd=run ethargs; ext4load mmc 0:1 0x88000000 /boot/uImage; bootm 0x88000000 
bootdelay=1 
ethact=dm9000 
ethaddr=d0:31:10:ff:7d:20 
ethargs=env set bootargs ${bootargs} dm9000.mac_addr=${ethaddr} 
loads_echo=1 
serial#=1255 
stderr=eserial0,eserial4 
stdin=eserial0,eserial4 
stdout=eserial0,eserial4 

Environment size: 488/32764 bytes 

Eu ainda não testei, mas parece que a variável mem env sempre foi inicializada com um valor falso (eu segui o instruções ), mas isso só começou recentemente a ser um problema.

Os seguintes podem indicam um erro de copiar / colar:

bootargs=console=ttyS4,115200 console=tty0 mem=256M@0x0 
mem=768M@0x30000000 rootwait quiet rw root=/dev/mmcblk0p1 

Acontece que esta foi uma regressão real introduzida:

• link