This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

no output after "starting kernel..."

Hello,

We're using the latest SDK ( 07.00 ). We've successfully build a kernel and DTB file to use. From our bootloader we load both these files ( which places the address of the fdt in it's special register which is passed to the kernel ). However, after the line "starting kernel..." is shown, nothing else seems to appear on our uart.

The uart is connected to UART0, no other uarts are routed, so we can't access them. Also, when turning on low-level debugging, we can't use a predefined value, since all the predefined values state UART1,2,3,4...but never 0. Luckily, we have an option to not specify it: "DEBUG_LL_UART_NONE", which states that this relies on our platform choosing the right UART defintion internally. However, that doesn't compile, since its missing the "mach/debug-macro.S" file.

I feel like we are running in circles...

Kind regards,

Arend

  • Hello Arend,

    I ran into the same issue yesterday, I don't think this is a UART problem. Please see some of the google results for kernel hang. In my case, it was to do with the internal RTC.

    I'm not using the internal RTC so I had to disable it in the dts file before the kernel starts executing. I'm guessing that the init code tried to setup 32KHz clock for RTC but since none is present, it just locks up and stays there. This was the problem for me, I thought it might be helpful.

    I can safely say that unless you are doing something special, there should be no issues. One more item to check, please take a look at the bootargs in uboot and make sure the console is set to ttyO0 and not something else.

    Hope this helps...good luck.

    - Santhosh

  • Wauw, really half an hour ago I was thinking about the same thing but saw nothing in my dts file...until I saw at the top that I had included the entire AM33XX.dtsi file, in which the RTC was enabled.

    I will only be able to test it tomorrow, but I'm actually fairly sure that that will solve it, because my bootloader hanged on it too. May I ask, how did you solve it within the bootloader? I added a conditional part around the init of RTC, since this code is defined in common code, but I suspect better options are available?

    By tomorrow I hope I can mark this question as solved! Thank you so much for the input! Since we're thinking the same it MUST be that! :p

    Kind regards,

    Arend 

  • Hello Arend,


    Well I'm glad it helped. I solved the problem for uboot, by modifying the rtc enable function in one of the clock.c file. I allowed the board file to continue calling the function, but within the function I would return without doing anything if it was my board. For all other boards, it will continue calling that function.

    For the dts file, I added the following in my dts file and made one minor modification to the am33xx.dtsi file. Here is the snippet from my dts file, the comments show what needs to be done to the am33xx.dtsi file. I added the snipped under the ocp bus structure.

    /*
                We need to disable the internal RTC and use only the external RTC
                This is done along with a patch to the am33xx.dtsi file --> in that file...
                    rtc@44e3e000 {                -- Remove
                    am335xrtc: rtc@44e3e000 {    ++ Add    
            */        
            am335xrtc: rtc@44e3e000 {
                   status = "disabled";
                   ti,hwmods = "disabled";
            };


    There is an ugly warning that you will get when the kernel boots, but this link and post explains why it is and why that is okay. If you find better explanation please do let me know.

    https://www.mail-archive.com/linux-omap@vger.kernel.org/msg98432.html

    Hope this helps.

    Regards

    Santhosh