Uncompressing linux done booting 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. и снова в ребут.

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

Источник

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.

Источник

Uncompressing linux done booting kernel

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: 2854 Joined: Thu Jul 11, 2013 2:37 pm

Источник

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.

Источник