Re: moving to same chip, different board: no console output

[Ahmad Fatoum <a.fatoum@pengutronix.de>]

Hello David,

On 01.07.25 16:24, David Picard wrote:
> I copied the handoff files from a Quartus sample project released by the manufacturer, Enclustra.
> 
> Any hint about the debug output below is welcome.
> 
> I put some pr_debug() in arch/arm/cpu/uncompress.c, and it seems to execute until the last line: barebox(membase, memsize, handoff_data);

First some context: The barebox binary consists of two parts: A
prebootloader (PBL) that's very barebones and does the low level
initialization of setting up the DRAM while running from on-chip SRAM
and then loads the full barebox proper.

The entry point of barebox proper is that barebox function pointer in
uncompress.c. So you are hanging on first jump to DRAM or shortly after.

Given that you just added code for DRAM setup, I suspect that the code
may be erroneous in part. I have also seen similar effects before on
other SoCs, when the DRAM controller was setup the wrong way:
Writes were posted and didn't trigger hangs/aborts, but system locked up
on first read or execute.

Can you push your code somewhere, so we can take a look?

Cheers,
Ahmad


> https://github.com/barebox/barebox/blob/796506e790596a0b59c186651cf98112eafe01c5/arch/arm/cpu/uncompress.c#L106
> 
> I'm trying to boot from the SD card. I copied and adapted Buildroot genimage.cfg from the Terasic DE0 board.
> Device             Boot Start    End Sectors  Size Id Type
> images/sdcard.img1          1   2048    2048    1M a2 unknown
> images/sdcard.img2 *     2049  18432   16384    8M  c W95 FAT32 (LBA)
> images/sdcard.img3      18433 264192  245760  120M 83 Linux
> 
> The FAT32 partition contains:
> -rwxr-xr-x 1 root root 375K juil.  1  2025 barebox.bin
> -rwxr-xr-x 1 root root  600 juil.  1  2025 barebox.env
> -rwxr-xr-x 1 root root  26K juil.  1  2025 socfpga_cyclone5_mercury_sa2.dtb
> -rwxr-xr-x 1 root root 5,9M juil.  1  2025 zImage
> 
> 
> David
> 
> Le 30/06/2025 à 15:23, David Picard a écrit :
>> Hello,
>>
>> I can get an output on the console! I switched to v2025.06.1 and enabled CONFIG_DEBUG_LL, CONFIG_PBL_CONSOLE and CONFIG_DEBUG_PBL.
>>
>> Could you help me to interpret this ?
>>
>> -------------------------
>>
>> barebox 2025.06.1 #2 Mon Jun 30 15:01:21 CEST 2025
>>
>>
>> Board: SoCFPGA
>> No consoles were activated. Activating all consoles as fallback!
>> dw_mmc dw_mmc0: registered as mci0
>> mci0: detected SD card version 2.0
>> mci0: registered disk0
>> starting bootloader...
>> uncompress.c: memory at 0x00000000, size 0x40000000
>> mmu: enabling MMU, ttb @ 0x3ffe0000
>> endmem                = 0x40000000
>> arm_mem_scratch       = 0x3fff8000+0x00008000
>> arm_mem_stack         = 0x3fff0000+0x00008000
>> arm_mem_ttb           = 0x3ffe0000+0x00010000
>> arm_mem_barebox_image = 0x3fe00000+0x00200000
>> arm_mem_early_malloc  = 0x3fde0000+0x00020000
>> membase               = 0x00000000+0x40000000
>> uncompress.c: uncompressing barebox binary at 0x1ff8c5e0 (size 0x00056c32) to 0x3fe00000 (uncompressed size: 0x000778b0)
>> uncompress.c: jumping to uncompressed image at 0x3fe00001
>>
>> -----------
>>
>> End of log, no prompt.
>>
>> David
>>
>>
>> Le 16/06/2025 à 12:39, Ahmad Fatoum a écrit :
>>> Hi David,
>>>
>>> On 6/11/25 13:46, David Picard wrote:
>>>> Hello,
>>>>
>>>> I took the same Buildroot configuration. I replaced the .dts* files with
>>>> the ones provided by the new board BSP. Actually, they differ quite a
>>>> lot from the Altera SoC FPGA .dts* files in the Linux tree. Then, I
>>>> compiled and flashed the SD card.
>>> The device trees don't have the whole story. There is Quartus-generated
>>> C board code that sets up the DRAM controller for example, so just
>>> replacing the device tree doesn't work so early.
>>>
>>>> I enabled CONFIG_DEBUG_LL with no change. CONFIG_DEBUG_PBL doesn't exist
>>>> in my case. For some reason, the defconfig I built upon, uses Barebox
>>>> v2021.07.0, which is probably outdated...
>>> v2021.07.0 predated CONFIG_DEBUG_PBL, yes.
>>>
>>> Cheers,
>>> Ahmad
>>>
>>>> David
>>>>
>>>> Le 06/06/2025 à 19:46, Ahmad Fatoum a écrit :
>>>>> Hello David,
>>>>>
>>>>> On 06.06.25 16:43, David Picard wrote:
>>>>>> Hello,
>>>>>>
>>>>>> I am working on a project for which we selected an Intel/Altera
>>>>>> Cyclone 5 SoC FPGA (an FPGA with an ARM core). As the project
>>>>>> evolves, I have to change boards and I am facing issues to boot:
>>>>>> absolutely no output on the serial console (USB virtual COM port),
>>>>>> not even from Barebox.
>>>>>>
>>>>>> Previous working configuration:
>>>>>> - SD card image produced by Buildroot with Barebox as the bootloader
>>>>>> - Terasic ADC-SoC demo board, booting from the SD card.
>>>>>> https://www.terasic.com.tw/cgi-bin/page/archive.pl?
>>>>>> Language=English&No=1061&PartNo=1
>>>>>>
>>>>>> Current non-working configuration:
>>>>>> - Eclustra Mercury+ SA2 module, also with a Cyclone 5, plus SDRAM,
>>>>>> RTC, QSPI flash, etc. I think that the main difference between both
>>>>>> Cyclone 5 chips is the size of the logic section is bigger on the
>>>>>> module. The module has more RAM.
>>>>>> https://www.enclustra.com/en/products/system-on-chip-modules/mercury-
>>>>>> sa2/
>>>>>> - Enclustra ST1 demo baseboard. It has a JTAG port, should this
>>>>>> information be of interest.
>>>>>> https://www.enclustra.com/en/products/base-boards/mercury-st1/
>>>>>>
>>>>>> I the current configuration, I get no output on the serial console.
>>>>> So you tried to use the exact same image on both boards or were
>>>>> there changes?
>>>>>
>>>>>> What I did:
>>>>>> - I checked the hardware configuration (switches to select booting
>>>>>> from the SD card and USB config) with a bare-metal application
>>>>>> provided by Enclustra.
>>>>>> - I used Enclutra's .dts and .dtsi files, which differ very slightly
>>>>>> from the Linux kernel tree files.
>>>>>> - I checked how the SD card is connected: to the exact same pins in
>>>>>> both configurations.
>>>>>> - I had a look at Barebox menuconfig, but nothing caught my eye.
>>>>>>
>>>>>> So, now I'm stuck, and I'm looking for some guidance.
>>>>> You can try enabling CONFIG_DEBUG_LL and CONFIG_DEBUG_PBL and see if you
>>>>> get some debugging output maybe. You'll have to choose which UART to use.
>>>>>
>>>>> I think your new SoM may have different RAM and thus you can't use the
>>>>> same image, but need one suitable to RAM integrated on your new board.
>>>>>
>>>>> Cheers,
>>>>> Ahmad
>>>>>
>>>>>> David
>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>
>>
> 
> 
> 


-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |