Re: [PATCH v2] Porting barebox to a new SoC

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

On 19.06.23 08:40, Lior Weintraub wrote:
> Hello Ahmad,
> 
> Thanks again for your great tips.
> Using the addpart command seems to work and give same results as the pre-partitioned flash node on the DT.
> When I deleted the whole flash node and extended the memory node to include all 768MB the following commands worked on barebox:
> addpart /dev/ram0 "512M@0(dram512),0xB30000@0x20000000(kernel),0x8000@0x20FF8000(oftree),0x800000@0x21000000(rootfs),-"
> After that, checking the devinfo gave:
>    `-- mem0
>       `-- 0x00000000-0x2fffffff (   768 MiB): /dev/ram0
>       `-- 0x00000000-0x1fffffff (   512 MiB): /dev/ram0.dram512
>       `-- 0x20000000-0x20b2ffff (  11.2 MiB): /dev/ram0.kernel
>       `-- 0x20ff8000-0x20ffffff (    32 KiB): /dev/ram0.oftree
>       `-- 0x21000000-0x217fffff (     8 MiB): /dev/ram0.rootfs
>       `-- 0x21800000-0x2fffffff (   232 MiB): /dev/
> Now running the bootm:
> bootm -o /dev/ram0.oftree -r /dev/ram0.rootfs -a 0 /dev/ram0.kernel
> 
> The Linux kernel starts running but has issues (still probably missing parts on my QEMU machine).
> 
> Notice that I had to set the "kernel" partition to size 0xB30000 because otherwise it gave me the same error of "conflict":
> __request_region ok: 0x00000000:0x00ffffff flags=0x200
> __request_region ok: 0x00000000:0x00ff7fff flags=0x200
> __request_region: 0x00b30000:0x00b4ffff (image) conflicts with 0x00000000:0x00ff7fff (image)
> unable to request SDRAM 0x00b30000-0x00b4ffff
> handler failed with: Out of memory
> 
> Could it be somehow related to the way I build the kernel?

Can you reproduce this with normal qemu aarch64 virt machine?

Cheers,
Ahmad

> Cheers,
> Lior.
> 
> 
>> -----Original Message-----
>> From: Ahmad Fatoum <a.fatoum@pengutronix.de>
>> Sent: Friday, June 16, 2023 7:21 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 14.06.23 08:42, Lior Weintraub wrote:
>>> Hi Ahmad,
>>>
>>> Looks like I found the issue :-)
>>>
>>> When I declared the flash@0 node I used about 16MB for the kernel
>> partition even though currently my kernel image is around 11MB:
>>> flash@0 {
>>>     compatible = "mtd-rom";
>>>     probe-type = "map_rom";
>>>     reg = <0x0 0x20000000 0x0 0x10000000>; /* Offset 512MB, size 256MB
>> */
>>>     bank-width = <4>;
>>>     device-width = <1>;
>>>
>>>     #address-cells = <1>;
>>>     #size-cells = <1>;
>>>     kernel@0 { /* 16MB (minus 32KB) */
>>>         label = "kernel";
>>>         //reg = <0x0 0x00FF8000>; // This line caused the error
>>>         reg =   <0x0 0x00b30000>;
>>>     };
>>>     oftree@00FF8000 { /* 32KB for DTB image */
>>>         label = "oftree";
>>>         reg = <0x00FF8000 0x00008000>;
>>>     };
>>>     rootfs@1000000 { /* Offset 512MB+16MB with size 8MB */
>>>         label = "rootfs";
>>>         reg = <0x01000000 0x00800000>;
>>>     };
>>> };
>>>
>>> From the error message I saw that barebox tried to place the rootfs on
>> address 0xb30000 and that conflicted with the kernel:
>>> mtdrom0.kernel: read ofs: 0x00fe0000 count: 0x00018000
>>> __request_region ok: 0x00000000:0x00ff7fff flags=0x200
>>> mtdrom0.rootfs: read ofs: 0x00000000 count: 0x00000800
>>> __request_region: 0x00b30000:0x00b4ffff (image) conflicts with
>> 0x00000000:0x00ff7fff (image)
>>
>> This error message still doesn't make sense to me. No idea why this conflicts.
>> I see now though that I made this more complicated that it needs be. Please
>> scratch all that, remove the mtd-rom and revert the /memory node to
>> encompass
>> all memory. Then you can at runtime, just create the partitions with the
>> addpart
>> command (see help addpart for info). Then you can boot normally.
>>
>>>
>>> So I changed the kernel@0 node and used size 0x00b30000 and now kernel
>> starts running.
>>> The kernel is producing all kinds of errors but at least it's a start :-)
>>> The errors are now related to pieces of HW that we didn't implement on
>> QEMU so it is understandable.
>>>
>>> How can we control where the rootfs is copied to?
>>
>> Normally, global.bootm.initrd.loadaddr, but you shouldn't need to do
>> that. Try it with addpart and let me know.
>>
>> Cheers,
>> Ahmad
>>
>>>
>>> Thanks again for your kind advise and patience.
>>> Cheers,
>>> Lior.
>>>
>>>> -----Original Message-----
>>>> From: Lior Weintraub
>>>> Sent: Tuesday, June 13, 2023 4:28 PM
>>>> To: Ahmad Fatoum <a.fatoum@pengutronix.de>; Ahmad Fatoum
>>>> <ahmad@a3f.at>; barebox@lists.infradead.org
>>>> Subject: RE: [PATCH v2] Porting barebox to a new SoC
>>>>
>>>> Hi Ahmad,
>>>>
>>>> I also thought that load address was suspicious (0x8000000) but then I
>> saw
>>>> the following comment on nxp_imx8mq_evk_start:
>>>>              /*
>>>>               * On completion the TF-A will jump to
>>>> MX8MQ_ATF_BL33_BASE_ADDR
>>>>               * in EL2. Copy the image there, but replace the PBL part of
>>>>               * that image with ourselves. On a high assurance boot only
>>>> the
>>>>               * currently running code is validated and contains the
>>>> checksum
>>>>               * for the piggy data, so we need to ensure that we are
>>>> running
>>>>               * the same code in DRAM.
>>>>               */
>>>> Our code was based on this function and as a result it copies the barebox
>>>> image into address 0x8000000 (which is our settings of
>>>> ATF_BL33_BASE_ADDR).
>>>> The fact that Linux image is also copied there seemed reasonable (I might be
>>>> wrong here) because once loading is done and we jump to Linux there is no
>>>> need for barebox code anymore.
>>>>
>>>> In any case, at that time when I thought it was wrong I also tried to run the
>>>> bootm command with "-a 0" but I got exactly the same error:
>>>> barebox:/ bootm -o /dev/mtdrom0.oftree -r /dev/mtdrom0.rootfs -a 0
>>>> /dev/mtdrom0.kernel
>>>> getopt: optindex: 1 nonopts: 0 optind: 1
>>>> getopt: optindex: 1 nonopts: 0 optind: 3
>>>> getopt: optindex: 1 nonopts: 0 optind: 5
>>>> getopt: optindex: 1 nonopts: 0 optind: 7
>>>> mtdrom0.kernel: read ofs: 0x00000000 count: 0x00001000
>>>>
>>>> Loading ARM aarch64 Linux image '/dev/mtdrom0.kernel'
>>>> header 00000000: 4d 5a 40 fa 3f 1a 23 14 00 00 00 00 00 00 00 00
>>>> MZ@.?.#.........
>>>> header 00000010: 00 00 b3 00 00 00 00 00 0a 00 00 00 00 00 00 00
>>>> ................
>>>> header 00000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>>>> ................
>>>> header 00000030: 00 00 00 00 00 00 00 00 41 52 4d 64 40 00 00 00
>>>> ........ARMd@...
>>>> header 00000040: 50 45 00 00 64 aa 02 00 00 00 00 00 00 00 00 00
>>>> PE..d...........
>>>> booti: Kernel to be loaded to 0+b30000
>>>> __request_region ok: 0x00000000:0x0001ffff flags=0x200
>>>> mtdrom0.kernel: read ofs: 0x00000000 count: 0x00020000
>>>> __request_region ok: 0x00000000:0x0003ffff flags=0x200
>>>> mtdrom0.kernel: read ofs: 0x00020000 count: 0x00020000
>>>> __request_region ok: 0x00000000:0x0005ffff flags=0x200
>>>> .
>>>> .
>>>> mtdrom0.kernel: read ofs: 0x00fe0000 count: 0x00018000
>>>> __request_region ok: 0x00000000:0x00ff7fff flags=0x200
>>>> mtdrom0.rootfs: read ofs: 0x00000000 count: 0x00000800
>>>> __request_region: 0x00b30000:0x00b4ffff (image) conflicts with
>>>> 0x00000000:0x00ff7fff (image)
>>>> unable to request SDRAM 0x00b30000-0x00b4ffff
>>>> handler failed with: Out of memory
>>>>
>>>>
>>>> The iomem before:
>>>> barebox:/ iomem
>>>> 0x0000000000000000 - 0xffffffffffffffff (size 0x0000000000000000)
>> iomem
>>>>   0x0000000000000000 - 0x000000001fffffff (size
>> 0x0000000020000000)
>>>> ram0
>>>>     0x00000000079fef00 - 0x0000000007dfeeff (size
>> 0x0000000000400000)
>>>> malloc space
>>>>     0x0000000007dfef00 - 0x0000000007dfffd1 (size
>> 0x00000000000010d2)
>>>> board data
>>>>     0x0000000007e00000 - 0x0000000007e3d95f (size
>>>> 0x000000000003d960) barebox
>>>>     0x0000000007e3d960 - 0x0000000007e50bb7 (size
>>>> 0x0000000000013258) barebox data
>>>>     0x0000000007e50bb8 - 0x0000000007e53b3f (size
>>>> 0x0000000000002f88) bss
>>>>     0x0000000007ff0000 - 0x0000000007ff7fff (size
>> 0x0000000000008000)
>>>> stack
>>>>   0x0000000020000000 - 0x000000002fffffff (size
>> 0x0000000010000000)
>>>> 20000000.flash@0.of
>>>>   0x000000d000307000 - 0x000000d000307fff (size
>>>> 0x0000000000001000) amba
>>>>
>>>> After:
>>>> barebox:/ iomem
>>>> 0x0000000000000000 - 0xffffffffffffffff (size 0x0000000000000000)
>> iomem
>>>>   0x0000000000000000 - 0x000000001fffffff (size
>> 0x0000000020000000)
>>>> ram0
>>>>     0x00000000079fef00 - 0x0000000007dfeeff (size
>> 0x0000000000400000)
>>>> malloc space
>>>>     0x0000000007dfef00 - 0x0000000007dfffd1 (size
>> 0x00000000000010d2)
>>>> board data
>>>>     0x0000000007e00000 - 0x0000000007e3d95f (size
>>>> 0x000000000003d960) barebox
>>>>     0x0000000007e3d960 - 0x0000000007e50bb7 (size
>>>> 0x0000000000013258) barebox data
>>>>     0x0000000007e50bb8 - 0x0000000007e53b3f (size
>>>> 0x0000000000002f88) bss
>>>>     0x0000000007ff0000 - 0x0000000007ff7fff (size
>> 0x0000000000008000)
>>>> stack
>>>>   0x0000000020000000 - 0x000000002fffffff (size
>> 0x0000000010000000)
>>>> 20000000.flash@0.of
>>>>   0x000000d000307000 - 0x000000d000307fff (size
>>>> 0x0000000000001000) amba
>>>>
>>>> I did not set global.bootm.image.loadaddr
>>>> Speaking of env, the last few lines on the barebox terminal are:
>>>> initcall-> load_environment+0x0/0x4c
>>>> loading defaultenv
>>>> environment load /dev/env0: No such file or directory
>>>> Maybe you have to create the partition.
>>>> initcalls done
>>>>
>>>> When I run "printenv" I am getting:
>>>> barebox:/ printenv
>>>> locals:
>>>> globals:
>>>> bootsource=unknown
>>>> bootsource_instance=unknown
>>>> PATH=/env/bin
>>>>
>>>> Hope this info can help.
>>>> Cheers,
>>>> Lior.
>>>>
>>>>
>>>>> -----Original Message-----
>>>>> From: Ahmad Fatoum <a.fatoum@pengutronix.de>
>>>>> Sent: Tuesday, June 13, 2023 3:51 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
>>>>>
>>>>> On 13.06.23 14:39, Lior Weintraub wrote:
>>>>>> Hi Ahmad,
>>>>>>
>>>>>> As usual, your comments are spot on :-)
>>>>>>
>>>>>> After fixing the DT, devinfo command shows correct flash node:
>>>>>>    `-- 20000000.flash@0.of
>>>>>>       `-- mtdrom0
>>>>>>          `-- 0x00000000-0x0fffffff (   256 MiB): /dev/mtdrom0
>>>>>>          `-- mtdrom0.kernel
>>>>>>             `-- 0x00000000-0x00ff7fff (    16 MiB): /dev/mtdrom0.kernel
>>>>>>          `-- mtdrom0.oftree
>>>>>>             `-- 0x00000000-0x00007fff (    32 KiB): /dev/mtdrom0.oftree
>>>>>>          `-- mtdrom0.rootfs
>>>>>>             `-- 0x00000000-0x007fffff (     8 MiB): /dev/mtdrom0.rootfs
>>>>>>
>>>>>> As can be seen above, we chose to map this "flash" node on DRAM
>>>> address
>>>>> 0x20000000 (offset 512MB).
>>>>>> The BL1 code correctly copy the 3 artifacts into those location (verified
>> the
>>>>> content via "md -l -s /dev/mtdrom0.kernel").
>>>>>> Running "drvinfo" shows:
>>>>>> mtdram
>>>>>>         20000000.flash@0.of
>>>>>>
>>>>>> Now when I try to run "bootm -o /dev/mtdrom0.oftree -r
>>>>> /dev/mtdrom0.rootfs /dev/mtdrom0.kernel" I am getting this error:
>>>>>>
>>>>>> barebox:/ bootm -o /dev/mtdrom0.oftree -r /dev/mtdrom0.rootfs
>>>>> /dev/mtdrom0.kernel
>>>>>> getopt: optindex: 1 nonopts: 0 optind: 1
>>>>>> getopt: optindex: 1 nonopts: 0 optind: 3
>>>>>> getopt: optindex: 1 nonopts: 0 optind: 5
>>>>>> mtdrom0.kernel: read ofs: 0x00000000 count: 0x00001000
>>>>>>
>>>>>> Loading ARM aarch64 Linux image '/dev/mtdrom0.kernel'
>>>>>> header 00000000: 4d 5a 40 fa 3f 1a 23 14 00 00 00 00 00 00 00 00
>>>>> MZ@.?.#.........
>>>>>> header 00000010: 00 00 b3 00 00 00 00 00 0a 00 00 00 00 00 00 00
>>>>> ................
>>>>>> header 00000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>>>>> ................
>>>>>> header 00000030: 00 00 00 00 00 00 00 00 41 52 4d 64 40 00 00 00
>>>>> ........ARMd@...
>>>>>> header 00000040: 50 45 00 00 64 aa 02 00 00 00 00 00 00 00 00 00
>>>>> PE..d...........
>>>>>> booti: Kernel to be loaded to 8000000+b30000
>>>>>
>>>>> Kernel image is relocatable and ARM64 header in hexdump says that
>>>>> load offset is zero. Yet, barebox wants to load your image to
>>>>> 8000000, which is already reserved.
>>>>>
>>>>> What's the output of the iomem command before and after the failed
>>>>> boot attempt?
>>>>>
>>>>>> __request_region ok: 0x08000000:0x0801ffff flags=0x200
>>>>>> mtdrom0.kernel: read ofs: 0x00000000 count: 0x00020000
>>>>>> __request_region ok: 0x08000000:0x0803ffff flags=0x200
>>>>>> mtdrom0.kernel: read ofs: 0x00020000 count: 0x00020000
>>>>>> .
>>>>>> .
>>>>>> mtdrom0.kernel: read ofs: 0x00fe0000 count: 0x00018000
>>>>>> __request_region ok: 0x08000000:0x08ff7fff flags=0x200
>>>>>> mtdrom0.rootfs: read ofs: 0x00000000 count: 0x00000800
>>>>>> __request_region: 0x08b30000:0x08b4ffff (image) conflicts with
>>>>> 0x08000000:0x08ff7fff (image)
>>>>>> unable to request SDRAM 0x08b30000-0x08b4ffff
>>>>>> handler failed with: Out of memory
>>>>>
>>>>> Just to be sure: You don't set global.bootm.image.loadaddr, right?
>>>>>
>>>>> Cheers,
>>>>> Ahmad
>>>>>
>>>>>>
>>>>>> Appreciate your advice,
>>>>>> Cheers,
>>>>>> Lior.
>>>>>>
>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Ahmad Fatoum <a.fatoum@pengutronix.de>
>>>>>>> Sent: Monday, June 12, 2023 6:08 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
>>>>>>>
>>>>>>> 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
>>>> |
>>>>>>
>>>>>
>>>>> --
>>>>> 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 |
> 

-- 
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 |