LINUX.ORG.RU

Как работает команда bootm в u-boot?

 , ,


0

1

Добрый день! Задача загрузится с флэшки ,на которой лежит kernel.img(образ ядра) и rk3399_rkb.dtb(device tree). файловая система fat32. Использую команду fatload, все считывается в память, расстояние между образами выбираю приличное. После чего запускаю команду bootm.

rkboot # fatload usb 0:1 0x02800000 kernel.img
reading kernel.img
20207636 bytes read in 525 ms (36.7 MiB/s)
rkboot # fatload usb 0:1 0x0A800000 rk3399_jd3399_lvds_rkb.dtb
reading rk3399_jd3399_lvds_rkb.dtb
79716 bytes read in 27 ms (2.8 MiB/s)
rkboot # bootm 0x02800000 - 0x0A800000
Wrong Image Format for bootm command
ERROR: can't get kernel image!

Соответственно отсюда вопрос, что я делаю не так??? То ли не туда считываю ядро и device tree ,то ли формат ядра совсем другой(даже не представляю какой еще может быть, тут обычный «IMG») , то ли bootm нужно что-то еще в качестве третьего аргумента, например ramdisk. Подскажите кто сталкивался с подобной проблемой?

ERROR: can’t get kernel image!

Ты сам собирал ядро в образ? После сборки ядра из исходников ты не забыл обернуть ядро «юбутовской» программкой «mkimage»? В ней «Ю-бут» добавляет к ядру адреса куда переносить ядро в ОЗУ. Файловая система пока нипричем. Я бы посмотрел как создавался образ ядра или сделал его заново из собранного ядра.

Enthusiast ()

Она же аглицким языком пишет: Wrong Image Format for bootm command

zloy_starper ★★★ ()

booti 0x02800000 - 0x0A800000

anonymous ()
Ответ на: комментарий от Enthusiast

Образ ядра создавался предположительно с помощью команд

$ cd kernel
$ cp rk3399_rkb_defconfig  .config

$ make ARCH=arm64 rk3399_jd3399_lvds_rkb.img -j8

$ cd ..

в итоге должен был получиться файл kernel.img и еще файл resource.img в котором лежит device tree. Я не оборачивал образ mkimag-ем ,т.к. получил следующее сообщение и думаю, я что-то делаю не так опять же.

/u-boot/tools# ./mkimage -l kernel.img
./mkimage: Bad Magic Number: "kernel.img" is no valid image
GP Header: Size 4b524e4c LoadAddr 8583401

И как действовать дальше я не знаю

krokodil ()
Ответ на: комментарий от krokodil

И как действовать дальше я не знаю.

  1. Насколько я понимаю, образ ядра собирал не ты? Почему тогда не возьмёшь проверенный рабочий образ?
  2. Если работоспособного работающего образа ядра найти не удаётся, то придётся собирать ядро из исходных текстов самостоятельно.
  3. У тебя размер ядра составляет около 20 МБ. Не многовато? Возможно, что после копирования настроек сборки ядра необходимо выполнить команду:
make ARCH=arm64 menuconfig
  1. Сборку осуществляешь на целевой плате? Если плата рабочая, то и работающее ядро должно уже быть. Зачем ты пытаешься собрать новое ядро-то? Чем работающее ядро не устраивает?
Enthusiast ()
Ответ на: комментарий от Enthusiast

У меня есть рабочее ядро и устройство запускается на нем. Я понял почему я получаю ошибку Bad magic number - мое ядро (kernel.img) не заархивировано, т.е. это не zImage. Поэтому у меня возник сейчас вопрос - можно ли как то из обычного ядра получить самораспаковывающийся zImage?

krokodil ()
Ответ на: комментарий от krokodil

Поэтому у меня возник сейчас вопрос - можно ли как то из обычного ядра получить самораспаковывающийся zImage?

Я вижу два возможных пути решения задачи:

а) собранное ядро не сжимать, а просто пересоздать образ ядра командой «mkimage», указав ей, что ядро не сжато;

б) собранное ядро сжать командой «gzip -k CompiledKernelFileName» и пересоздать образ ядра из этого сжатого ядра через «mkimage».

Замысел в том, чтобы дать знать загрузчику «Ю-буту» сжато ли ядро или нет через входные параметры команды «mkimage».

У тебя сборка происходит таким образом, что образ ядра создаётся автоматически и не нужно вручную запускать команду «mkimage»? Тогда может потребоваться прописать команду сжатия ядра «Гзипом» сразу после сборки и перед созданием образа ядра.

Enthusiast ()
Ответ на: комментарий от Enthusiast

Я имею уже готовый Image ядра, новый скомпилировать не могу ввиду ошибок сборки. Mkimage приходится запускать вручную. У меня вопрос по пункту Б. Если я просто выполню команду описанную в Б ,я получу именно zImage или просто сжатый образ. Просто как я понял zImage это некий особый формат с хедером и самораспаковывающимся кодом. Есть ли между ними разница? Вариант А пробовал реализовать. создал uImage из Image, указав что ядро не сжато. Потом закинул образ на флэшку с файловой системой fat32. Далее вошел в командную строку юбута и загрузил в память образ с помощью команды fatload, по адресу указанному в параметрах mkimage. Далее вызываю bootm 0x…. (адрес загрузки) и получаю сообщение

Wrong Image Format for bootm command
ERROR: can't get kernel image!

Что говорит о том ,что что-то я делаю не так

krokodil ()
Ответ на: комментарий от krokodil

Так, сейчас еще раз попробовал проделать данную последовательность действий и bootm сжалился надо мной… но не надолго. Теперь вылетает новая ошибка

rkboot # bootm 0x00008000
## Booting kernel from Legacy Image at 00008000 ...
  Image Name:   Linux kernel
  Image Type:   ARM Linux Kernel Image (gzip compressed)
  Data Size:    8470859 Bytes = 8.1 MiB
  Load Address: 00008000
  Entry Point:  00008000
Unsupported Architecture 0x2
ERROR: can't get kernel image!
rkboot #

причем с несжатым ядром точно такая же ошибка. Как можно это пофиксить? может bootm нужен еще device tree или ramdisk?

krokodil ()
Ответ на: комментарий от krokodil

Все, с этой проблемой тоже разобрался(надо было поменять архитектуру с arm на arm64:) но теперь у меня новое несчастье.

rkboot # bootm 0x00008000
## Booting kernel from Legacy Image at 00008000 ...
   Image Name:   Linux kernel
   Image Type:   AArch64 Linux Kernel Image (uncompressed)
   Data Size:    20207636 Bytes = 19.3 MiB
   Load Address: 00008000
   Entry Point:  00008000
ehci_hcd_stop,complete
   Loading Kernel Image ... OK

Starting kernel ...

"Synchronous Abort" handler, esr 0x02000000
ELR:     8000
LR:      489583c
x0 : 0000000000000000 x1 : 0000000000000000
x2 : 0000000000000000 x3 : 0000000000000000
x4 : ffffffffffffffff x5 : 000000000000001c
x6 : ffffffffffffffff x7 : 0000000000000000
x8 : 0000000004922310 x9 : 0000000000000002
x10: 000000000a200023 x11: 0000000000000002
x12: 0000000000000002 x13: 0000000000000100
x14: 000000000000000d x15: 00000000048928d0
x16: 0000000004892e38 x17: 0000000000000170
x18: 0000000004690920 x19: 00000000049866f0
x20: 0000000000000000 x21: 0000000000008000
x22: 0000000000000000 x23: 0000000000000400
x24: 0000000000000001 x25: 0000000004924170
x26: 00000000048959f8 x27: 0000000001345814
x28: 0000000000000000 x29: 0000000004895820

Resetting CPU ...

И вот тут у меня опять только 1 идея. Проблема с ramdisk или с device tree. Если кто-то сталкивался с этой проблемой ,хелп!)

krokodil ()
Ответ на: комментарий от krokodil

«Synchronous Abort» handler, esr 0x02000000

Передача управления от загрузчика ядру произошла успешно. До подгрузки файловой системы дело еще не дошло, ошибка вряд ли вызвана этим.

Первым делом я бы проверил адрес в ОЗУ куда загрузчик кладет распакованное ядро, не затираются ли данные наложением друг на друга. Затем можно включить вывод ранних отладочных сообщений ядра в консоль при загрузке. Это включается в настройках сборки ядра в разделе «kernel hacking» или вроде того. Ищи настройку «early printk». Ядро нужно будет пересобрать в этом случае. Дальше уже видно будет что не так.

Enthusiast ()
Ответ на: комментарий от Enthusiast

Как можно проверить куда загрузчик кладет ядро? (и кстати ядро не сжато ,так что и распаковки не должно быть вроде бы). Насчет early printk: у меня в bootargs имеется строчка earlycon=uart8250 и когда я гружусь с eMMC где у меня лежит это же самое ядро у меня выводится подробная отладочная информация наподобие такой:

Starting kernel ...

[    0.000000] Booting Linux on physical CPU 0x0
[    0.000000] Initializing cgroup subsys cpuset
[    0.000000] Initializing cgroup subsys cpu
[    0.000000] Initializing cgroup subsys cpuacct
[    0.000000] Initializing cgroup subsys schedtune
[    0.000000] Linux version 4.4.126 (root@android7sdk) (gcc version 6.3.1 20170404 (Linaro GCC 6.3-2017.05) ) #4 SMP PREEMPT Wed May 29 15:40:08 MSK 2019
[    0.000000] Boot CPU: AArch64 Processor [410fd034]
[    0.000000] earlycon: Early serial console at MMIO32 0xff1a0000 (options '')
[    0.000000] bootconsole [uart0] enabled
[    0.000000] Reserved memory: failed to reserve memory for node 'stb-devinfo@00000000': base 0x0000000000000000, size 0 MiB

и т.д. так что вроде бы и включать ничего не надо. Может ли быть такое что ядро не грузится из-за того что я его загружаю в область памяти не являющейся ОЗУ, потому что я сейчас изучаю карту памяти rk3399 и там по адресам по которым я загружаю uImage находится bootrom или flash

0xA0000000 -
0xDFFFFFFF Device XN Peripherals

0x80000000 -
0x9FFFFFFF Normal WT Off chip RAM

0x60000000 -
0x7FFFFFFF Normal WBWA Off chip RAM

0x40000000 -
0x5FFFFFFF
Device XN Peripherals Before Remap + 0xB8000000

0x20000000 -
0x3FFFFFFF Normal WBWA On chip RAM

0x00000000 -
0x1FFFFFFF Normal WT ROM or flash

либо я совсем запутался и мне нужно еще читать и читать документацию

krokodil ()
Ответ на: комментарий от krokodil

Как можно проверить куда загрузчик кладет ядро?

В загрузчике «Ю-буте» сделано таким образом, что запуская на исполнение ядро «Линукса» командой «bootm KernelAddressInSdram», само ядро перед запуском на исполнение будет скопировано с этого адреса по новому адресу, который ты указал при создании образа ядра во входных параметрах команды «mkimage».

Почему «Ю-бут» сразу не распаковывает сжатое ядро и файловую систему по адресам исполнения, а сначала распаковывает в одну область ОЗУ, а затем копирует перед исполнением в другую? Я пока не догадался, может быть, народ тут подскажет.

В остальном ты мыслишь в правильном направлении: вывод отладочных сообщений можно включать через входные параметры ядра при загрузке. Ты это верно подметил. Дальше если будут ошибки, то по тексту сообщения об ошибке можно найти строку исходного кода ядра где эта ошибка выявляется. Иногда я просто убираю лишние проверки в исходнике ядра таким образом, пересобираюсь и ошибки уже как не бывало.

Enthusiast ()
Ответ на: комментарий от Enthusiast

Я посмотрел исходники.

"Synchronous Abort" handler, esr 0x02000000

данная строчка есть только в исходниках u-boot-a. То есть по идее после передачи управления ядру ,юбут вызывает какое-то исключение а не ядро

krokodil ()
Ответ на: комментарий от krokodil

«Synchronous Abort» handler, esr 0x02000000

Выложи сюда полный лог отладочных сообщений, начиная мгновением включения питания твоей платы до аварийной перезагрузки процессора. Посмотрим вместе.

Enthusiast ()
Ответ на: комментарий от Enthusiast
DDR Version 1.19 20190305
In
Channel 0: LPDDR3, 800MHz
CS = 0
MR0=0x58
MR1=0x58
MR2=0x58
MR3=0x58
MR4=0x2
MR5=0x1
MR6=0x5
MR7=0x0
MR8=0x1F
MR9=0x1F
MR10=0x1F
MR11=0x1F
MR12=0x1F
MR13=0x1F
MR14=0x1F
MR15=0x1F
MR16=0x1F
Bus Width=32 Col=10 Bank=8 Row=15 CS=1 Die Bus-Width=32 Size=1024MB
Channel 1: LPDDR3, 800MHz
CS = 0
MR0=0x58
MR1=0x58
MR2=0x58
MR3=0x58
MR4=0x2
MR5=0x1
MR6=0x5
MR7=0x0
MR8=0x1F
MR9=0x1F
MR10=0x1F
MR11=0x1F
MR12=0x1F
MR13=0x1F
MR14=0x1F
MR15=0x1F
MR16=0x1F
Bus Width=32 Col=10 Bank=8 Row=15 CS=1 Die Bus-Width=32 Size=1024MB
256B stride
ch 0 ddrconfig = 0x101, ddrsize = 0x20
ch 1 ddrconfig = 0x101, ddrsize = 0x20
pmugrf_os_reg[2] = 0x3280D280, stride = 0x9
OUT
Boot1: 2019-01-17, version: 1.18
CPUId = 0x0
ChipType = 0x10, 223
SdmmcInit=2 0
BootCapSize=100000
UserCapSize=14910MB
FwPartOffset=2000 , 100000
mmc0:cmd8,20
mmc0:cmd5,20
mmc0:cmd55,20
mmc0:cmd1,20
mmc0:cmd8,20
mmc0:cmd5,20
mmc0:cmd55,20
mmc0:cmd1,20
mmc0:cmd8,20
mmc0:cmd5,20
mmc0:cmd55,20
mmc0:cmd1,20
SdmmcInit=0 1
StorageInit ok = 67691
SecureMode = 0
SecureInit read PBA: 0x4
SecureInit read PBA: 0x404
SecureInit read PBA: 0x804
SecureInit read PBA: 0xc04
SecureInit read PBA: 0x1004
SecureInit read PBA: 0x1404
SecureInit read PBA: 0x1804
SecureInit read PBA: 0x1c04
SecureInit ret = 0, SecureMode = 0
atags_set_bootdev: ret:(0)
GPT 0x3380ec0 signature is wrong
recovery gpt...
GPT 0x3380ec0 signature is wrong
recovery gpt fail!
LoadTrust Addr:0x4000
LoadTrust Addr:0x4400
LoadTrust Addr:0x4800
LoadTrust Addr:0x4c00
LoadTrust Addr:0x5000
No find bl30.bin
Load uboot, ReadLba = 2000
Load OK, addr=0x200000, size=0x926a4
RunBL31 0x10000
NOTICE:  BL31: v1.3(debug):370ab80
NOTICE:  BL31: Built : 09:23:41, Mar  4 2019
NOTICE:  BL31: Rockchip release version: v1.1
INFO:    GICv3 with legacy support detected. ARM GICV3 driver initialized in EL3
INFO:    Using opteed sec cpu_context!
INFO:    boot cpu mask: 0
INFO:    plat_rockchip_pmu_init(1181): pd status 3e
INFO:    BL31: Initializing runtime services
INFO:    BL31: Initializing BL32
INF [0x0] TEE-CORE:init_primary_helper:337: Initializing (1.1.0-195-g8f090d20 #6 Fri Dec  7 06:11:20 UTC 2018 aarch64)

INF [0x0] TEE-CORE:init_primary_helper:338: Release version: 1.2

INF [0x0] TEE-CORE:init_teecore:83: teecore inits done
INFO:    BL31: Preparing for EL3 exit to normal world
INFO:    Entry point address = 0x200000
INFO:    SPSR = 0x3c9


HELLO



U-Boot 2014.10-RK3399-06-03493-g77036c3f6b-dirty (Aug 26 2020 - 17:02:02)

CPU: rk3399
cpu version = 0
CPU's clock information:
    aplll = 816000000HZ
    apllb = 24000000HZ
    gpll = 800000000HZ
               aclk_periph_h = 133333333HZ, hclk_periph_h = 66666666HZ, pclk_periph_h = 33333333HZ
               aclk_periph_l0 = 266666666HZ, hclk_periph_l0 = 88888888HZ, pclk_periph_l0 = 44444444HZ
               hclk_periph_l1 = 100000000HZ, pclk_periph_l1 = 50000000HZ
    cpll = 800000000HZ
    dpll = 800000000HZ
    vpll = 24000000HZ
    npll = 24000000HZ
    ppll = 676000000HZ
Board:  Rockchip platform Board
Uboot as second level loader
DRAM:  Found dram banks: 1
Adding bank:0000000000200000(000000007fe00000)
Reserve memory for trust os.
dram reserve bank: base = 0x08400000, size = 0x01e00000
128 MiB
1 USB controller selected, name ehci-host
Boot from usb device ehci-host @ 00000000fe3c0000
USB0:   ehci_hcd_init index 0,complete lol
USB EHCI 1.00
scanning bus 0 for devices... 2 USB Device(s) found
       scanning usb for storage devices... 1 Storage Device(s) found
Deinit USB Host
ehci_hcd_stop,complete
SdmmcInit = 0 20
storage init OK!
Using default environment

GetParam
Load FDT from resource image.
power key: bank-0 pin-5
can't find dts node for fixed
usb bc: can find node by path: /dwc-control-usb/usb_bc
pmic:rk808
can't find dts node for pwm1
set pwm voltage ok,pwm_id =2 vol=900000,pwm_value=16
CPU's clock information:
    aplll = 816000000HZ
    apllb = 24000000HZ
    gpll = 800000000HZ
               aclk_periph_h = 133333333HZ, hclk_periph_h = 66666666HZ, pclk_periph_h = 33333333HZ
               aclk_periph_l0 = 266666666HZ, hclk_periph_l0 = 88888888HZ, pclk_periph_l0 = 44444444HZ
               hclk_periph_l1 = 100000000HZ, pclk_periph_l1 = 50000000HZ
    cpll = 800000000HZ
    dpll = 800000000HZ
    vpll = 24000000HZ
    npll = 24000000HZ
    ppll = 676000000HZ
can't find dts node for ec-battery
Can't find dts node for charger bq25700
misc partition not found!
SecureBootEn = 0, SecureBootLock = 0

#Boot ver: 2019-10-01#1.18
empty serial no.
normal boot.
checkKey
vbus = 1
no fuel gauge found
no fuel gauge found
Rockchip UBOOT DRM driver version: develop-v1.0.0
Warn: route-edp: connector node is not available
read logo on state from dts [1]
no fuel gauge found
Using display timing dts
Detailed mode clock 148500 kHz, flags[a]
    H: 1920 2080 2100 2200
    V: 1080 1090 1100 1125
bus_format: 100e
rk lcdc - 0 dclk set: dclk = 148500000HZ, pll select = 1, div = 1
final DSI-Link bandwidth: 992 Mbps x 4
misc partition not found!
Hit any key to stop autoboot:  0
rkboot #
Unknown command 'г▒' - try 'help'
rkboot # usb start
(Re)start USB...
USB0:   ehci_hcd_init index 0,complete lol
USB EHCI 1.00
scanning bus 0 for devices... 2 USB Device(s) found
       scanning usb for storage devices... 1 Storage Device(s) found
rkboot # fatload usb 0:1 0x00008000 uimage
reading uimage
20207700 bytes read in 540 ms (35.7 MiB/s)
rkboot # bootm 00008000
## Booting kernel from Legacy Image at 00008000 ...
   Image Name:   Linux kernel
   Image Type:   AArch64 Linux Kernel Image (uncompressed)
   Data Size:    20207636 Bytes = 19.3 MiB
   Load Address: 00280000
   Entry Point:  00280000
ehci_hcd_stop,complete
   Loading Kernel Image ... OK

Starting kernel ...

"Synchronous Abort" handler, esr 0x02000000
ELR:     280000
LR:      489e8d4
x0 : 0000000000000000 x1 : 0000000000000000
x2 : 0000000000000000 x3 : 0000000000000000
x4 : 0000000004699080 x5 : 00000000ffffffc8
x6 : 0000000000000000 x7 : 0000000000000000
x8 : 0000000000000000 x9 : 0000000000000002
x10: 000000000a200023 x11: 0000000000000002
x12: 0000000000000002 x13: 0000000000000100
x14: 000000000000000d x15: 000000000489b8d0
x16: 000000000489be38 x17: 0000000000000170
x18: 0000000004699920 x19: 0000000004987bf0
x20: 0000000000280000 x21: 0000000000000000
x22: 0000000000000000 x23: 0000000000000400
x24: 0000000000000001 x25: 00000000049256a0
x26: 000000000489eaa8 x27: 0000000001345814
x28: 0000000000000000 x29: 000000000489e8ac

Resetting CPU ...

resetting ...
krokodil ()
Ответ на: комментарий от krokodil

вот полный вывод консоли при загрузке с usb с ядром упакованным в обертку от mkimage. А вот вывод консоли при успешной загрузке ,когда ядро лежит на eMMC с помощью команды bootrk, вшитой в модифицированный юбут. Адреса загрузки и там и там одинаковые, поэтому хз в чем может быть проблема.

krokodil ()
Ответ на: комментарий от krokodil
    dpll = 800000000HZ
    vpll = 24000000HZ
    npll = 24000000HZ
    ppll = 676000000HZ
can't find dts node for ec-battery
Can't find dts node for charger bq25700
misc partition not found!
SecureBootEn = 0, SecureBootLock = 0

#Boot ver: 2019-10-01#1.18
empty serial no.
normal boot.
checkKey
vbus = 1
no fuel gauge found
no fuel gauge found
Rockchip UBOOT DRM driver version: develop-v1.0.0
Warn: route-edp: connector node is not available
read logo on state from dts [1]
no fuel gauge found
Using display timing dts
Detailed mode clock 148500 kHz, flags[a]
    H: 1920 2080 2100 2200
    V: 1080 1090 1100 1125
bus_format: 100e
rk lcdc - 0 dclk set: dclk = 148500000HZ, pll select = 1, div = 1
final DSI-Link bandwidth: 992 Mbps x 4
misc partition not found!
Hit any key to stop autoboot:  0
rkboot # b
Unknown command 'ищ▒b' - try 'help'
rkboot # bootrk
load fdt from resouce.
2 _ 2 _ 32before choice
Secure Boot state: 0
kernel   @ 0x00280000 (0x01345808)
ramdisk  @ 0x04bf0000 (0x0048b800)
bootrk: do_bootm_linux...
   Loading Device Tree to 0000000004600000, end 0000000004616763 ... OK
Add bank:0000000000200000, 0000000008200000
Add bank:000000000a200000, 0000000075e00000
WARNING: could not set reg FDT_ERR_BADOFFSET.
hex: 280000
 pointer: 0000000000280000
 ul: 2621440
▒▒image_start:036fdt: ▒
 load:0
 compression: %hu
 type:%hu
 os:%hu

Starting kernel ...

before udc_disconnect
before cleanup
after cleanup
before_nonsec
before kernel_entry
[    0.000000] Booting Linux on physical CPU 0x0
[    0.000000] Initializing cgroup subsys cpuset
[    0.000000] Initializing cgroup subsys cpu
[    0.000000] Initializing cgroup subsys cpuacct
[    0.000000] Initializing cgroup subsys schedtune
[    0.000000] Linux version 4.4.126 (root@android7sdk) (gcc version 6.3.1 20170404 (Linaro GCC 6.3-2017.05) ) #4 SMP PREEMPT Wed May 29 15:40:08 MSK 2019
[    0.000000] Boot CPU: AArch64 Processor [410fd034]
[    0.000000] earlycon: Early serial console at MMIO32 0xff1a0000 (options '')
[    0.000000] bootconsole [uart0] enabled
[    0.000000] Reserved memory: failed to reserve memory for node 'stb-devinfo@00000000': base 0x0000000000000000, size 0 MiB
[    0.000000] cma: Reserved 16 MiB at 0x000000007f000000
[    0.000000] psci: probing for conduit method from DT.
[    0.000000] psci: PSCIv1.0 detected in firmware.
[    0.000000] psci: Using standard PSCI v0.2 function IDs
[    0.000000] psci: Trusted OS migration not required
[    0.000000] PERCPU: Embedded 21 pages/cpu @ffffffc07eefb000 s45528 r8192 d32296 u86016
[    0.000000] Detected VIPT I-cache on CPU0
[    0.000000] CPU features: enabling workaround for ARM erratum 845719
[    0.000000] Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 507912
[    0.000000] Kernel command line: earlycon=uart8250,mmio32,0xff1a0000 swiotlb=1 coherent_pool=1m console=ttyFIQ,115200 init=/sbin/init root=/dev/mmcblk1p5 rw rootwait net.ifnames=0 biosdevname=0  mtdparts=rk29xxnand:0x00002000@0x00002000(uboot),0x00008000@0x00006000(resource),0x0000C000@0x0000E000(kernel),0x00024000@0x0001A000(boot),-@0x003e000(linuxroot)F▒▒y storagemedia=emmc androidboot.oem_unlocked=0 uboot_logo=0x02000000@0x7dc00000 loader.timestamp=2020-08-26_17:02:02 SecureBootCheckOk=0
[    0.000000] PID hash table entries: 4096 (order: 3, 32768 bytes)
[    0.000000] Dentry cache hash table entries: 262144 (order: 9, 2097152 bytes)
[    0.000000] Inode-cache hash table entries: 131072 (order: 8, 1048576 bytes)
[    0.000000] software IO TLB [mem 0x7eeb3000-0x7eef3000] (0MB) mapped at [ffffffc07eeb3000-ffffffc07eef2fff]

``` я тут только часть разместил т.к. начало одинаковое
krokodil ()
Ответ на: комментарий от krokodil

Starting kernel … «Synchronous Abort» handler, esr 0x02000000

Действительно, загрузка валится в «Ю-буте», до ядра ещё не доходит дело.

rkboot # bootrk

Насколько я понимаю, ты используешь видоизменённый рокчиповцами «Ю-бут» с «Гитхаба»?

Раз ядро у тебя грузится с флэш-карты, то оно уже обернуто «mkimage’м» для загрузки после сборки из исходных текстов. А раз так, то я бы попробовал вынуть информацию об адресах загрузки из самого файла образа ядра. Зачем гадать куда грузить ядро, если в образе эта информация уже имеется? Как именно вынуть информацию прямо сейчас я не готов сказать, нужно читать.

В «Ю-буте» перед загрузкой ядра выведи значения переменных:

printenv bootargs
printenv bootm_low
printenv bootm_mapsize
printenv bootm_size

Посмотрим какой размер памяти у тебя выделен для загрузки ядра из ОЗУ и какие параметры подсовываются ядру «Ю-бутом».

Enthusiast ()
Ответ на: комментарий от Enthusiast

Посмотрим какой размер памяти у тебя выделен для загрузки ядра из ОЗУ и какие параметры подсовываются ядру «Ю-бутом».

А лучше все переменные окружения «Ю-бута» выведи. Посмотрим как загрузка настроена.

printenv
Enthusiast ()
Ответ на: комментарий от krokodil

вот полный вывод консоли при загрузке с usb с ядром упакованным в обертку от mkimage. А вот вывод консоли при успешной загрузке ,когда ядро лежит на eMMC с помощью команды bootrk, вшитой в модифицированный юбут. Адреса загрузки и там и там одинаковые, поэтому хз в чем может быть проблема.

Крокодил, ты чего притих-то? Я представляю, что перезагрузка процессора происходит из-за того, что память под «bootm» не выделена. Рокчиповцы грузятся через «bootrk», а мы через «bootm» с невыделенной для этого памятью. «Ю-бут» пытается очистить невыделенную память «bootm’a» и валится.

С тремя переменными «Ю-бута» осталось разобраться: bootm_low, bootm_mapsize, bootm_size. Продолжай начатое дело, осталось немного и победим.

Enthusiast ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.