Starting kernel uncompressing linux

Running Linux 4.9 on Cortex-M4 STM32F4 (29I-DISC1)

I spend a few days trying to understand but I’m stuck. I get no more than a «Starting kernel. » message after entering ‘bootm 8100000’ on my STM32F429I-DISC1 board. Before I update uboot from 2011 to 2016 It was a «Starting Kernel. » + UNHANDED EXCEPTION HARDFAULT, but now I have just the «Starting Kernel. » message. MCU is a stm32F429, 2MB Flash + ext. 8MB RAM. Flash start addr is 0x08000000 (uboot addr) and I put my kernel on the start of the 2nd flash bank at 0x08100000. Start of External 8MB RAM is 0xD0000000 u-boot-2016.11 seems to run pretty well on that board, bdi give me:

U-Boot > bdi arch_number = 0x00000000 boot_params = 0xD0000100 DRAM bank = 0x00000000 -> start = 0xD0000000 -> size = 0x00800000 current eth = unknown ip_addr = baudrate = 115200 bps relocaddr = 0xD07D6000 reloc off = 0xC87D6000 irq_sp = 0xD05D3EE0 sp start = 0xD05D3ED0 Early malloc usage: e0 / 400 

make CROSS_COMPILE=arm-none-eabi- ARCH=arm uImage LOADADDR=08100000 -B 

U-Boot > bootm 8100000 ## Booting kernel from Legacy Image at 08100000 . Image Name: Linux-4.9.0 Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 839872 Bytes = 820.2 KiB Load Address: 08100000 Entry Point: 08100000 Verifying Checksum . OK Loading Kernel Image . OK Starting kernel . 

With the ‘robutest’/’emcraft’ kernel/config files I got the same log, unless the Entry Point seems more correct because it’s 08100001. On the robutest/emcraft kernel I tried to activate the LCD screen of the board, but nothing happen. In all my test I activate kernel config «early printk» and «DEBUG_LL_xxx» stuff. This is a link to my .config file: http://pastebin.com/gBNYx3Gs PS: I made some try with uCLinux emcraft/robutest to try to find what’s going on, but my main goal is to run Linux 4.9. Thanks for reading me. EDIT: I tried to pass the dtb «the old way», but with the same result:

U-Boot > bootm 08100000 - 08040000 ## Booting kernel from Legacy Image at 08100000 . Image Name: Linux-4.9.0 Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 805744 Bytes = 786.9 KiB Load Address: 08100000 Entry Point: 08100000 Verifying Checksum . OK ## Flattened Device Tree blob at 08040000 Booting using the fdt blob at 0x8040000 Loading Kernel Image . OK Loading Device Tree to d05ce000, end d05d2a9f . OK Starting kernel . 

I’m desperate, any ideas is welcome :'( EDIT2: I tried to uncompress the kernel with u-boot, it’s the same:

U-Boot > bootm 8100000 - 8040000 ## Booting kernel from Legacy Image at 08100000 . Image Name: uImage Image Type: ARM Linux Kernel Image (gzip compressed) Data Size: 940696 Bytes = 918.6 KiB Load Address: d0008000 Entry Point: d0008001 Verifying Checksum . OK ## Flattened Device Tree blob at 08040000 Booting using the fdt blob at 0x8040000 Uncompressing Kernel Image . OK Loading Device Tree to d05ce000, end d05d2a9f . OK Starting kernel . 

EDIT3: I checked the memory/USART1 address in the dtb, and it’s ok. Why I have no message of the kernel? EDIT4: With uxipImage:

U-Boot > bootm 08060000 - 08040000 ## Booting kernel from Legacy Image at 08060000 . Image Name: uxipImage Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 1497396 Bytes = 1.4 MiB Load Address: 08060000 Entry Point: 08060041 Verifying Checksum . OK ## Flattened Device Tree blob at 08040000 Booting using the fdt blob at 0x8040000 Loading Kernel Image . OK Loading Device Tree to d05ce000, end d05d2a9f . OK Starting kernel . 

Источник

Форум по системам видеонаблюдения и безопасности.

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

Нужна ваша помощь в восстановлении Dahua NVR

Нужна ваша помощь в восстановлении Dahua NVR

Сообщение x-dream » 02 мар 2021, 00:28

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

Record Channel:32 Alarm In:16 Alarm Out:6 SN:1B00062PAA(. ) Web:3.1.0.5 System Version:2.616.0000.0 System Version: Build Date:2015-03-16

Сначала «отвалилась» сеть. Подключение напрямую к нему монитора, R232 никакого результата не принесли.

Подключился к порту RS232 и перезагрузил устройство

При включении в логах выдаёт следующее:

U-Boot 2010.06-svn1660 (Feb 03 2015 - 13:20:41) TI8168-GP rev 2.1 ARM clk: 1200MHz DDR clk: 796MHz DSP clk: 813MHz IVA clk: 531MHz M3 clk: 250MHz DRAM: 1 GiB SPI: info: found S25FL256S (32MiB) Net: Detected MACID:4c:11:bf:27:77:b4 Ethernet PHY: GENERIC[0x70431] @ 0x00 DaVinci EMAC Hit any key to stop autoboot: 0 NET_autoLipDetect timeout Using DaVinci EMAC device TFTP from server 192.168.254.254; our IP address is 192.168.1.108 Filename 'upgrade_info_7db780a713a4.txt'. Load address: 0x80100000 Loading: Failed to get info.txt SPI: info: found S25FL256S (32MiB) SPI probe: 32768 KiB S25FL256S at 0:0 is now current device ### CRAMFS loading '/boot/uImage' to 0x81000000 ### CRAMFS load complete: 2601556 bytes loaded to 0x81000000 ## Booting kernel from Legacy Image at 81000000 . Image Name: Linux-2.6.37 Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 2601492 Bytes = 2.5 MiB Load Address: 80008000 Entry Point: 80008000 Verifying Checksum . OK Loading Kernel Image . OK OK Starting kernel . Uncompressing Linux. done, booting the kernel. 

Не запускается система. Висит какое-то время на Uncompressing Linux. done, booting the kernel. и снова в ребут.

Подскажите, пожалуйста из вашего опыта, можно ли его восстановить и каким способом?

Источник

When soft reboot Linux kernel hangs at «Uncompressing Linux. done, booting the kernel» [closed]

I dont know why I am facing this on each soft reboot. To avoid this I need to hard reset (power off and power on again).

Why I am facing this issue? Is there any clean up function missing in kernel? How to debug this issue?

I think you won’t find the critical mass on SO to answer this question. If it is an ARM board, you will perhaps find better support on arm-linux-kernel mailing list. By the way you should specify the specific CPU your board is based on.

that i havnt tested. But i have some patches on kernel for my custom board so i am doubt that it will not work on non-custom board

Wow, so many votes to close. Why? Do so many people think that device drivers don’t belong here either? In the days of the Intel 80286, would so many people think that problems in programming a BIOS weren’t programming problems? This is a programming question, people!

There are kernel related question in SO. The problem here is that it seems to be a very narrow problem, possibly hardware related, and yet the question is missing imporant details (architecture, SoC type). However, I would understand if the question was closed as too localised, but it is definitely not off-topic, unless it is a hardware bug

3 Answers 3

Yes, it sounds like somewhere in the platform support for you hardware you are missing some logic to cope with a soft reboot.

Adding clean-up code doesn’t solve the problem, because the system may crash, and then be soft rebooted.

So the code that boots up the system needs to be written to cope with the system being soft rebooted.

To debug you’ll first need to find out where the kernel is getting stuck during the soft reboot. The easiest way to do that is with a hardware debugger.

The other option is to read through the boot up code and try and spot any areas that might be relying on a cold reboot to work, eg. code that expects the TLB to be cleared at boot or similar.

Источник

Starting kernel uncompressing linux

I’m trying to setup the UART of pi to talk with PC, I am using a TTL-232r-3v3 cable which has usb at one end and 3 pins (GND,RX,TX) at other end, connected as per tutorials.

I tried running it in NOOBS but it went into rescue mode and I saw on this forum that UART wont work in NOOBS OS.

So I am now using Raspbian OS. I followed the numerous tutorials that all have the same procedure for setting this up, but when I try to execute over UART «Uncompressing Linux. done, booting the kernel» is the only thing that comes up in my Putty window.

I’ve read other threads about this but they dont have a solution for me.

Any help is appreciate. New to Raspberry pi so descriptive solutions are welcome.

The Pi runs normally when I have it hooked up to HDMI, so its just the UART is the problem

Re: Uncompressing Linux. done, booting the kernel.

Which tutorials have you used? There could be an issue with permissions. Mind the difference between su and sudo.

Re: Uncompressing Linux. done, booting the kernel.

Are 2 sources I referred to during setup.
There are more but I cant find the links, but they more or less have the same procedure

I’ve changed the /boot/cmdline.txt and /etc/inittab and Putty works over wifi dongle.

jdb Raspberry Pi Engineer & Forum Moderator
Posts: 2853 Joined: Thu Jul 11, 2013 2:37 pm

Источник

Linux kernel hangs at «Starting kernel . «

I have enabled Secure Boot on an embedded device successfully. The problem is that when I am booting in this mode the process seems to get stuck right after the line: Starting kernel . once U-boot has copied the kernel in memory and issued a bootm command. In a debugger I am able to capture that the PC is stuck on a yield instruction followed by an assignment to pc = pc-4 — so essentially a loop. I have never brought up linux at this low of a level before so I am unsure where to begin looking. I did notice, though, that I was able to successfully boot the kernel image when not in secure mode, so this might be a more appropriate questions for the vendor. 1) In general, where can I find U-boot diagnostic information regarding the execution hand-off stage? 2) At what point is execution fully given to the kernel? i.e. when is U-boot defunct?

The «Starting kernel . » message is not from U-Boot but from the Linux Kernel provided «zImage» wrapper as it starts the kernel after decompression. If you have a debugger, have it start looking in as soon as that code begins execution (ie you start executing at wherever you’ve said the entry point is).

Is this true on all platforms? The device is a rather obscure embedded system that boots a FIT image; the kernel, device tree bridge, and roofts are all bundled into this one «itb» binary that is loaded/executed by U-Boot.

I misspoke, sorry. That is the last print from U-Boot. But still, my recommendation is to start by having your debugger halt at the entry point and work from there.

When the zImage decompresses, both the compressed and decompressed kernel are in memory, for a period of time. I used to get the same problem when my kernel was to large to fit into memory.

Источник