From: Ahmad Fatoum <a.fatoum@pengutronix.de>
To: Lior Weintraub <liorw@pliops.com>, Ahmad Fatoum <ahmad@a3f.at>,
"barebox@lists.infradead.org" <barebox@lists.infradead.org>
Subject: Re: [PATCH v2] Porting barebox to a new SoC
Date: Mon, 12 Jun 2023 17:07:34 +0200 [thread overview]
Message-ID: <15f8d795-f486-1914-9eba-e5a315bf2083@pengutronix.de> (raw)
In-Reply-To: <PR3P195MB0555C35406A3BC621BA1038EC354A@PR3P195MB0555.EURP195.PROD.OUTLOOK.COM>
Hi,
On 12.06.23 16:59, Lior Weintraub wrote:
> Hello Ahmad,
>
> Just for simple simulations we make the ROM size 192MB so it can include all needed artifacts.
I am not convinced that this is much of a simplification over having
your Qemu machine provide cfi-flash.
> When we get this simple system to work we will move the relevant parts to BL2.
Ok.
> DRAM is also simulated now as SRAM so we are not worried about initializations.
>
> So if I understand correctly, we can decide that address 0x10000000 will be reserved for "flash" and add the following node:
> flash@0 {
flash@10000000, but that's just for informational purposes.
> compatible = "mtd-rom";
> probe-type = "map_rom";
> reg = <0x10000000 0x10000000>;
> bank-width = <4>;
> device-width = <1>;
>
> #address-cells = <1>;
> #size-cells = <1>;
> kernel@0 {
> label = "kernel";
> reg = <0x0 0x01000000>;
> };
> rootfs@1000000 {
> label = "rootfs";
> reg = <0x01000000 0x00800000>;
> };
> };
>
> When I use this node on our DT I see the following devinfo:
> barebox:/ devinfo
> `-- global
> `-- nv
> `-- platform
> `-- machine
> `-- psci.of
> `-- 1000000010000000.flash@0.of
As you can see the address is wrong. That's because you have
#address-cells = <2>;
#size-cells = <2>;
Yet, you wrote reg as if it was <1>/<1>. Change it to
reg = <0x0 0x10000000 0x0 0x10000000>;
Remember all device tree integers are 32-bit big endian.
> `-- soc.of
> `-- c000000000.sram@c000000000.of
> `-- soc:pmu.of
> `-- soc:timer.of
> `-- e000000000.interrupt-controller@E000000000.of
> `-- mem0
> `-- 0x00000000-0x0fffffff ( 256 MiB): /dev/ram0
> `-- mem1
> `-- 0x00000000-0xffffffffffffffff ( 0 Bytes): /dev/mem
> `-- amba
> `-- d000307000.serial@d000307000.of
> `-- cs0
> `-- 0x00000000-0xffffffffffffffff ( 0 Bytes): /dev/cs0
> `-- spi
> `-- fs
> `-- ramfs0
> `-- devfs0
> `-- pstore0
>
> Not sure how to proceed from here...
Type drvinfo command to see what drivers are bound to what devices.
If you see no driver bound to your flash device, then maybe you need
to enable the correct driver, that would be CONFIG_MTD_MTDRAM (which
handles both read-only and read-write memory mapped MTD).
Cheers,
Ahmad
> Cheers,
> Lior.
>
>> -----Original Message-----
>> From: Ahmad Fatoum <a.fatoum@pengutronix.de>
>> Sent: Monday, June 12, 2023 3:29 PM
>> To: Lior Weintraub <liorw@pliops.com>; Ahmad Fatoum <ahmad@a3f.at>;
>> barebox@lists.infradead.org
>> Subject: Re: [PATCH v2] Porting barebox to a new SoC
>>
>> CAUTION: External Sender
>>
>> Hello Lior,
>>
>> On 12.06.23 11:27, Lior Weintraub wrote:
>>> Hi Ahmad,
>>>
>>> Regarding the rootfs and Linux run question:
>>> Our board doesn't include eMMC\SD card.
>>> We only have our NOR Flash to store the binaries and our BL1 code will make
>> sure to copy those blobs into DRAM.
>>
>> How could BL1 copy artifacts in DRAM when BL2 first needs to set up DRAM?
>>
>>> The use of QEMU needs to be as simple as possible so no hidden virtio
>> drivers and such because we would like to simulate the real HW flow.
>>
>> cfi-flash is just memory-mapped flash, which is the next simplest thing
>> after BL1 copies stuff into (limited-to-4M) on-chip SRAM.
>>
>>> Our DTS file now includes the GIC, timer and arm,psci-1.0.
>>> We have an initial build of Linux kernel Image (using buildroot) and a
>> rootfs.cpio.xz.
>>> I assume we can somehow reserve a portion of the DRAM to store those
>> binaries and let barebox boot this Linux.
>>
>> You can make this work, but this is not how your actual system will
>> look like and trying to make this work is harder than it needs to be.
>>
>> Just add a cfi-flash that corresponds to the Linux/rootfs flash in
>> your actual system, then boot with bootm (type help bootm for info
>> on how to use it). You don't need to hardcode the load addresses,
>> barebox will determine them automatically.
>>
>>> Can you please advise how to make it work?
>>
>> For completion's sake, if you have 64M of RAM that's preloaded with
>> boot images:
>>
>> - Remove the 64M from the barebox /memory node. You can use a different
>> DT for kernel, but if you have memory that barebox shouldn't override,
>> you need to tell it that.
>>
>> - Add a mtd-rom node that describes these 64M that you have. You can
>> add partitions for the region used for kernel and oftree
>>
>> - boot with bootm -o /dev/mtdrom0.oftree -r /dev/mtdrom0.initrd \
>> /dev/mtdrom0.kernel
>>
>> That's admittedly cumbersome, but necessary, so barebox knows what
>> memory
>> it may use for itself and what memory may be used for boot.
>>
>> Correct solution is to use cfi-flash or similar.
>>
>> Cheers,
>> Ahmad
>> --
>> 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 |
>
--
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 |
next prev parent reply other threads:[~2023-06-12 15:08 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-28 13:04 Lior Weintraub
2023-05-28 15:35 ` Ahmad Fatoum
2023-05-28 15:37 ` [PATCH v2] " Ahmad Fatoum
2023-05-28 20:15 ` Lior Weintraub
2023-05-29 13:34 ` Lior Weintraub
2023-05-29 19:03 ` Ahmad Fatoum
2023-05-30 20:10 ` Lior Weintraub
2023-05-31 6:10 ` Ahmad Fatoum
2023-05-31 8:05 ` Lior Weintraub
2023-05-31 8:40 ` Ahmad Fatoum
2023-05-31 16:13 ` Lior Weintraub
2023-05-31 17:55 ` Ahmad Fatoum
2023-05-31 17:59 ` Ahmad Fatoum
2023-06-01 8:54 ` Lior Weintraub
2023-06-01 9:29 ` Ahmad Fatoum
2023-06-01 11:45 ` Lior Weintraub
2023-06-01 12:35 ` Ahmad Fatoum
2023-06-06 12:54 ` Lior Weintraub
2023-06-06 14:34 ` Ahmad Fatoum
2023-06-12 9:27 ` Lior Weintraub
2023-06-12 12:28 ` Ahmad Fatoum
2023-06-12 14:59 ` Lior Weintraub
2023-06-12 15:07 ` Ahmad Fatoum [this message]
2023-06-13 12:39 ` Lior Weintraub
2023-06-13 12:50 ` Ahmad Fatoum
2023-06-13 13:27 ` Lior Weintraub
2023-06-14 6:42 ` Lior Weintraub
2023-06-16 16:20 ` Ahmad Fatoum
2023-06-19 6:40 ` Lior Weintraub
2023-06-19 15:22 ` Ahmad Fatoum
2023-06-25 20:33 ` Lior Weintraub
2023-06-30 5:52 ` Ahmad Fatoum
2023-08-03 11:17 ` Lior Weintraub
2023-08-22 8:00 ` Ahmad Fatoum
2023-08-22 8:48 ` Lior Weintraub
2023-09-07 8:32 ` Ahmad Fatoum
2023-09-07 9:07 ` Lior Weintraub
2023-09-07 9:35 ` Ahmad Fatoum
2023-09-07 11:02 ` Lior Weintraub
2023-09-12 6:04 ` Lior Weintraub
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=15f8d795-f486-1914-9eba-e5a315bf2083@pengutronix.de \
--to=a.fatoum@pengutronix.de \
--cc=ahmad@a3f.at \
--cc=barebox@lists.infradead.org \
--cc=liorw@pliops.com \
/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