From: Ahmad Fatoum <a.fatoum@pengutronix.de>
To: Johannes Roith <johannes@gnu-linux.rocks>,
Sascha Hauer <s.hauer@pengutronix.de>
Cc: barebox@lists.infradead.org
Subject: Re: Porting Cora Z7 Board to barebox
Date: Fri, 16 May 2025 21:45:04 +0200 [thread overview]
Message-ID: <7d4314cb-5f25-47e7-aaa5-0f488f9e30ca@pengutronix.de> (raw)
In-Reply-To: <aBpBAxuh7vZrunZ7@InfinityCube>
Hi Johannes,
On 06.05.25 19:04, Johannes Roith wrote:
> The Zynq-7000 has a processor system (PS) with a Cortex-A9 and a
> programmable logic (PL) which is basically a FPGA. With barebox I can't
> load a bitstream to the FPGA. Or does barebox provides an interface for
> loading FPGAs?
As mentioned in the other thread, there is a framework for firmware loading,
which is already used for ZynqMP for example.
> My idea was to use Xilinx FSBL which loads the bitstream to the FPGA and
> then loads an ELF file. The problem is, if the ELF file is linked to
> address 0x0 like the FSBL, the FSBL overwrites its code when loading the
> ELF file and crashes.
>
> But if I write a small application which is loaded by the FSBL I can read
> start_dt_2nd.pblb from the mmc, put it somewhere in DRAM memory and jump to it.
> This should start the barebox proper, right?
A barebox build can generate multiple image, so if you need a separate first
stage bootloader, just create a new PBL entry point, but don't call
barebox_arm_entry. See for example arch/arm/boards/sama5d27-som1/lowlevel.c;
On the AT91, the BootROM looks for a BOOT.BIN file on the FAT and then that
BOOT.BIN file looks for a barebox.bin and loads it into DRAM after setting it up.
You'll probably notice that the PBL MMC drivers in barebox are a bit peculiar;
normally the BootROM doesn't reset the SD-Card and often even keeps the SD-Card
controller running, so barebox PBL makes use of that by just sending a
read multiple block command to the SD-Card to chainload the big barebox after
SDRAM has been set up. This saves a lot of time, complexity and image size.
The alternative would be having a MMC stack in the PBL and doing that initialization
dance for the card after resetting it. There are out-of-tree patches for that,
but I'd suggest you try doing it like other in-tree boards do if you are interested
in FSBL support inside barebox.
> I set ARCH_TEXT_BASE to 0x1000_0000 as you suggested and create a Xilinx Boot
> Image with start_dt_2nd.pbl inside, but the ELF file seems still be linked for
> 0x0. The FSBL loaded the FPGA but barebox never booted, so I guess the
> FSBL overwrote itself.
Did you see any early DEBUG_LL output at least? Or did you resolve this by now?
>> Best practice is to separate the barebox specific dts stuff from the
>> about-to-be-upstreamed stuff and put both files into arch/arm/dts.
>> With this we can just drop the non-barebox specific file once it's in
>> Linux upstream without losing the barebox specific changes.
>>
>
> Currently both files are named zynq-cora.dts. What would be a good name
> for the DT which will be replaced when upstreamed to Linux?
> zynq-cora-linux.dts?
That works I guess.
>>> And a last question: How can I change the default boot method in barebox
>>> from net to mmc0?
>>
>> nv boot.default="mmc0". See https://www.barebox.org/doc/latest/user/variables.html
>> and the output of the "magicvar" command
>
> Ok, it now tries to boot from mmc0, but I am getting an error:
>
> Board: Digilent Cora Z7
> deep-probe: supported due to xlnx,zynq-cora
> mdio_bus: miibus0: probed
> macb e000b000.ethernet@e000b000.of: Cadence GEM at 0xe000b000
> arasan-sdhci e0100000.mmc@e0100000.of: registered as mmc0
> malloc space: 0x17e00000 -> 0x1fdfffff (size 128 MiB)
> mmc0: detected SD card version 2.0
> mmc0: registered mmc0
>
> Hit any to stop autoboot: 3
> barebox@Digilent Cora Z7:/ boot
> Nothing bootable found on 'mmc0'
> Nothing bootable found
> barebox@Digilent Cora Z7:/ nv
> allow_color: true
> autoboot_timeout: 3
> boot.default: mmc0
> linux.bootargs.console: console=ttyPS1,115200 root=/dev/mmcblk0p2 rootwait
> user: none
>
> I have an SD card with a FAT32 and an EXT4 partition. On the FAT32 I
> have the zImage of the Linux kernel. Am I missing something here?
With bootm, you can explicitly name which images you want to boot.
The boot command on the other hand will try to figure out what images
should be used without hardcoding as is described in its help text.
For MMC, I'd suggest you use bootloader spec entries. Here's an example:
https://gist.github.com/a3f/f2e2b7414128cad6d1bceca0b6013cf8
Just place that at /loader/entries/cora.conf or something.
Cheers,
Ahmad
>
>>
>> Regards,
>> Sascha
>>
>> --
>> 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 |
>
> Best regard,
> Johannes
>
--
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 |
prev parent reply other threads:[~2025-05-16 19:45 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-28 17:20 johannes
2025-04-29 8:34 ` Sascha Hauer
2025-04-29 9:49 ` Ahmad Fatoum
2025-05-01 12:16 ` Johannes Roith
2025-05-01 13:56 ` Johannes Roith
2025-05-05 7:39 ` Sascha Hauer
2025-05-06 17:04 ` Johannes Roith
2025-05-16 19:45 ` Ahmad Fatoum [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=7d4314cb-5f25-47e7-aaa5-0f488f9e30ca@pengutronix.de \
--to=a.fatoum@pengutronix.de \
--cc=barebox@lists.infradead.org \
--cc=johannes@gnu-linux.rocks \
--cc=s.hauer@pengutronix.de \
/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