mail archive of the barebox mailing list
 help / color / mirror / Atom feed
From: David Picard <david.picard@clermont.in2p3.fr>
To: barebox@lists.infradead.org
Subject: Re: moving to same chip, different board: no console output
Date: Wed, 2 Jul 2025 18:42:17 +0200	[thread overview]
Message-ID: <5dbbb1bb-a902-462b-bea2-a1cae8feb144@clermont.in2p3.fr> (raw)
In-Reply-To: <c2f82d07-f4f5-4c8b-a336-8f5f2af734aa@pengutronix.de>

Hello,

My code is here, branch board-enclustra-sa2 :
git@github.com:dpproto/barebox.git

The Enclustra DTS has a SDRAM of 1GB. My module seems to have 2.
At some point, I changed the SDRAM size from 1 to 2GB, but I can't set 
it back to 1GB.
I reset it in:
- arch/arm/dts/socfpga_cyclone5_mercury_sa2.dts
- arch/arm/boards/enclustra-sa2/lowlevel.c
But I still get a size of 0x8000000. I cleaned and recompiled many times.

The latest log:
-----------------------------
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...
arch/arm/boards/enclustra-sa2/lowlevel.c: __start_socfpga_sa2() >>> start
include/mach/socfpga/lowlevel.h: start_socfpga_c5_common() >>> start
uncompress.c: memory at 0x00000000, size 0x80000000
mmu: enabling MMU, ttb @ 0x7ffe0000
endmem                = 0x80000000
arm_mem_scratch       = 0x7fff8000+0x00008000
arm_mem_stack         = 0x7fff0000+0x00008000
arm_mem_ttb           = 0x7ffe0000+0x00010000
arm_mem_barebox_image = 0x7fe00000+0x00200000
arm_mem_early_malloc  = 0x7fde0000+0x00020000
membase               = 0x00000000+0x80000000
uncompress.c: uncompressing barebox binary at 0x3ff8c740 (size 
0x00056b66) to 0x7fe00000 (uncompressed size: 0x000778b0)
uncompress.c: jumping to uncompressed image at 0x7fe00001
uncompress.c: calling armv7_switch_to_hyp()...
uncompress.c: armv7_switch_to_hyp() OK. Now jumping...
-----------------------------

David

Le 02/07/2025 à 14:12, Ahmad Fatoum a écrit :
> 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
>>>>>>>
>>>>>>>
>>>>>>>




      reply	other threads:[~2025-07-02 18:51 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-06-06 14:43 David Picard
2025-06-06 17:46 ` Ahmad Fatoum
2025-06-11 11:46   ` David Picard
2025-06-16 10:39     ` Ahmad Fatoum
     [not found]       ` <a547bc92-6d37-4db7-9eab-3576009c12ec@clermont.in2p3.fr>
2025-06-25 10:32         ` Ahmad Fatoum
2025-06-30 13:23       ` David Picard
2025-07-01 14:24         ` David Picard
2025-07-02 12:12           ` Ahmad Fatoum
2025-07-02 16:42             ` David Picard [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5dbbb1bb-a902-462b-bea2-a1cae8feb144@clermont.in2p3.fr \
    --to=david.picard@clermont.in2p3.fr \
    --cc=barebox@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox