2014-10-29 24 views
5

Próbuję uzyskać własną kompilację U-Boot, aby uruchomić system Linux na płycie Jetson TK1. Podczas gdy piszemy o zweryfikowany rozruch, używam Flat Image Tree (ujednoliconego obrazu jądra, bloba drzewa urządzenia, ...) do opisania mojego systemu. U-Boot może załadować plik ITB i próbuje uruchomić jądro, ale system zawiesza się po tym komunikacie.Linux: argumenty startowe z U-Boot i Flat Image Tree (FIT)

Zakładam, że dzieje się tak dlatego, że żadne argumenty rozruchowe nie są przekazywane do jądra (oryginalny start dodaje mnóstwo argumentów), ale jestem trochę zaskoczony, jak przekazać argumenty do jądra. Próbowałem ustawić zmienną środowiskową bootargs, ale to nie zmieniło sytuacji.

Jak przekazać argumenty jądra do jądra podczas korzystania z pliku ITB?

argumenty wiersza poleceń (wzięte z polecenie append z extlinux.conf przykłady):

console=ttyS0,115200n8 console=tty1 no_console_suspend=1 
[email protected] video=tegrafb [email protected] memtype=255 [email protected] 
section=256M pmuboard=0x0177:0x0000:0x02:0x43:0x00 [email protected] [email protected] 
otf_key=c75e5bb91eb3bd947560357b64422f85 usbcore.old_scheme_first=1 core_edp_mv=1150 
core_edp_ma=4000 tegraid=40.1.1.0.0 debug_uartport=lsport,3 power_supply=Adapter 
audio_codec=rt5640 modem_id=0 android.kerneltype=normal usb_port_owner_info=0 
fbcon=map:1 commchip_id=0 usb_port_owner_info=0 lane_owner_info=6 emc_max_dvfs=0 
[email protected] [email protected] board_info=0x0177:0x0000:0x02:0x43:0x00 
root=/dev/mmcblk0p1 rw rootwait tegraboot=sdmmc gpt 

Zawartość pliku ITS:

/dts-v1/; 

/{ 
    description = "Simple image with single Linux kernel and FDT blob"; 
    #address-cells = <1>; 

    images { 
     [email protected] { 
      description = "Vanilla Linux kernel"; 
      data = /incbin/("./zImage"); 
      type = "kernel"; 
      arch = "arm"; 
      os = "linux"; 
      compression = "none"; 
      load = <0x81008000>; 
      entry = <0x81008000>; 
      [email protected] { 
       algo = "crc32"; 
      }; 
      [email protected] { 
       algo = "sha1"; 
      }; 
     }; 
     [email protected] { 
      description = "Flattened Device Tree blob"; 
      data = /incbin/("./tegra124-pm375.dtb"); 
      type = "flat_dt"; 
      arch = "arm"; 
      compression = "none"; 
      [email protected] { 
       algo = "crc32"; 
      }; 
      [email protected] { 
       algo = "sha1"; 
      }; 
     }; 
    }; 

    configurations { 
     default = "[email protected]"; 
     [email protected] { 
      description = "Boot Linux kernel with FDT blob"; 
      kernel = "[email protected]"; 
      fdt = "[email protected]"; 
     }; 
    }; 
}; 

U-Boot wyjściowa:

Tegra124 (Jetson TK1) # fatload mmc 1 0x90000000 /kernel_fdt.itb 
reading /kernel_fdt.itb 
5946200 bytes read in 497 ms (11.4 MiB/s) 
Tegra124 (Jetson TK1) # bootm 0x90000000 
## Loading kernel from FIT Image at 90000000 ... 
    Using '[email protected]' configuration 
    Verifying Hash Integrity ... OK 
    Trying '[email protected]' kernel subimage 
    Description: Vanilla Linux kernel 
    Type:   Kernel Image 
    Compression: uncompressed 
    Data Start: 0x900000ec 
    Data Size: 5910168 Bytes = 5.6 MiB 
    Architecture: ARM 
    OS:   Linux 
    Load Address: 0x00000000 
    Entry Point: 0x00000000 
    Hash algo: crc32 
    Hash value: c5b4b377 
    Hash algo: sha1 
    Hash value: f001007efe83f563425bfe0659186a32395c946c 
    Verifying Hash Integrity ... crc32+ sha1+ OK 
## Loading fdt from FIT Image at 90000000 ... 
    Using '[email protected]' configuration 
    Trying '[email protected]' fdt subimage 
    Description: Flattened Device Tree blob 
    Type:   Flat Device Tree 
    Compression: uncompressed 
    Data Start: 0x905a30ac 
    Data Size: 34678 Bytes = 33.9 KiB 
    Architecture: ARM 
    Hash algo: crc32 
    Hash value: e466b23e 
    Hash algo: sha1 
    Hash value: ec909ae16e62233d0ed1e1f4c909085abc9b5879 
    Verifying Hash Integrity ... crc32+ sha1+ OK 
    Booting using the fdt blob at 0x905a30ac 
    Loading Kernel Image ... OK 
    Using Device Tree in place at 905a30ac, end 905ae821 

Starting kernel ... 
+0

Czy możesz podać dane wyjściowe konsoli i bieżące bootowania, abyśmy mogli sprawdzić, gdzie zatrzymuje się rozruch? – Claudio

Odpowiedz

2

Podczas korzystania z drzewa urządzeń nadal można używać argumentów w postaci bootargs.

sprawdzić:

  • po wykompilowaniu drzewa (przy użyciu kompilatora scripts/dtc/dtc wewnątrz jądra Linux)
  • Wsparcie drzewa urządzenie jest włączone w jądrze (symbol CONFIG_USE_OF) (gdzie podpórek „Open Firmware”)
  • Podany U-Boot adres drzewa: bootm <uImage address> - <dtb address>
  • konsoli szeregowej jest włączona w jądrze pod Device Drivers -> Urządzenia postaci -> Sterowniki szeregowe
  • konsola jest włączona w bootargs (np console=ttyS0,115200)
+0

Należy pamiętać, że używam drzewa obrazów, które jednoczy obraz jądra, drzewo urządzenia blob i inne rzeczy (konfiguracje, ramdyski, ...) w jednym pliku. – LostBoy

+0

Lepiej. Czy włączono 'CONFIG_USE_OF' i konsolę w' bootargs'? – Claudio

+0

Oba są włączone – LostBoy

6

Istotną kwestią jest to, że system wydaje się powiesić po U-Boot wyprowadza tekst

Starting kernel ... 

Jeśli załadowano nieskompresowany plik jądra Image, wówczas aktualny kod startowy jądra zostanie wykonany jako następny.
ale jeśli uImage lub zImage plik został załadowany (które są również zgłaszane jako „nieskompresowanego”, ponieważ są one na własny wydobycia), a następny kod wykonywany byłby rutyna dekompresji, który jest dołączony do pliku zImage . Normalnie to dekompresja rutyna tekst wyjściowy wola takich jak

Uncompressing Linux............ done, booting the kernel. 

przed rzeczywisty kod startowy jądra byłyby wykonywane przed każdym przetwarzanie linii poleceń jądra, przed każdym przetwarzania urządzenia Drzewo blob, a przed każdym wyjściem konsoli z jądra (w tym earlyprintk).


Istnieje rozbieżność między adresów startowych jądra obciążenie & określonych w nagłówku obrazu

Load Address: 0x00000000 
Entry Point: 0x00000000 

versus co jest określone w DT:

 load = <0x81008000>; 
     entry = <0x81008000>; 

Ponieważ obraz jądra jest tymczasowo Załadowano pod

## Loading kernel from FIT Image at 90000000 ... 

adresy w DT wydają się poprawne, a adresy w nagłówku obrazu są fałszywe.

Zakładając, że nie ma fizycznej pamięci RAM przy 0x00000000, wynikiem będzie, że obraz jądra zostanie skopiowany (lub zdekompresowany) do fałszywego adresu ładowania 0, a następnie obraz jądra zostanie wykonany przez rozgałęzienie do fałszywego wpisu punkt 0. Procesor prawdopodobnie zawiesi się, próbując wyrzucać śmieci z nieistniejącej pamięci, i to doskonale koresponduje z tym, co raportujesz.

Rozwiązanie to (1) potwierdzają, że jądro jest związana z prawidłowym adresem i (2), aby określić odpowiednie adresy w poleceniu MKIMAGE używając opcji polecenia -a i -e.
Ta poprawka powinna przynajmniej doprowadzić Cię do tego punktu.

0

Doświadczyłem tego samego lub podobnego problemu. Moim rozwiązaniem (lub obejściem) tego problemu było ustawienie zmiennych środowiskowych U-Boot initrd_high i fdt_high na adres w pamięci RAM przed relokowanym U-bootem (w moim przypadku 8effffff).