mail archive of the barebox mailing list
 help / color / mirror / Atom feed
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: Wed, 31 May 2023 19:59:27 +0200	[thread overview]
Message-ID: <fc2868f9-6b56-eefc-c0c2-24c75201f5fd@pengutronix.de> (raw)
In-Reply-To: <3340583d-12cd-1a52-4c9c-d237c58bfca7@pengutronix.de>

On 31.05.23 19:55, Ahmad Fatoum wrote:
> Hi Lior,
> 
> On 31.05.23 18:13, Lior Weintraub wrote:
>> Hi Ahmad,
>>
>> Using end of SRAM as PBL stack is currently not working because we need 40bit address (0xC0_0020_0000).
>> This needs a fix to ENTRY_FUNCTION_WITHSTACK macro.
> 
> Ah, right. I just sent an (untested) patch. Would be cool if you could
> try it out.
> 
>> I tried just to change const u32 __stack_top = (stack_top); to const u64 __stack_top = (stack_top); but there were linking errors caused by:
>> ASSERT(. - __pbl_board_stack_top <= 8, "Only One PBL per Image allowed")
> 
> The easy way would have been using a __attribute__((naked)) function, but
> those are only supported for arm32, not arm64. The alternative is thus
> writing the entry point in assembly and to make board authors life easier
> the linker script ensures that the stack setup entry point is invoked prior
> to the board entry.
> 
>> Regarding the arm timer:
>> Adding the timer entry to DT solved the issue.
>>
>> Regarding the UART:
>> Indeed CONFIG_SERIAL_AMBA_PL011 was set on spider_defconfig (also verified it generated the correct entry on .config).
>> I also noticed that if I remove the putc_ll implementation there is no Tx at all from Barebox.
> 
> I've led you astray. Indeed:
> 
>>>> of_platform_bus_create() - skipping /soc, no compatible prop
> 
> points at the issue.
> 
> Try adding into /soc
> 
>   compatible = "simple,bus";

"simple-bus". If you need an example, check out aforementioned jh7100.dtsi

>   ranges;
>   dma-ranges;
> 
> This matches /soc with the simple bus driver which just instantiates devices for the
> contained children. Those in turn should be matched by the drivers.
> 
> The ranges stuff just tells that memory and SoC peripherals exist in the same
> address space.
> 
> When it probes you may need to describe the clock in the DT. Eventually, you will
> want to have a clock driver for your hardware (good news: barebox and Linux have
> basically the same API, so you only need to write it once). But for now, you can
> fake it using fixed-clock in the DT. Take a look at:
> 
> snps,dw-apb-uart in arch/riscv/dts/jh7100.dtsi and compare with dts/src/arm/imx28.dtsi
> to see how to map that to PL011.
> 
>> Could it be a hint?
> 
> DEBUG_LL bridges the gap until a driver registers a console that's enabled. If this
> never happens, you are left with a non-interactive shell.
> 
> Cheers,
> Ahmad
> 
>>
>> Thanks,
>> Lior.
>>
>>> -----Original Message-----
>>> From: Ahmad Fatoum <a.fatoum@pengutronix.de>
>>> Sent: Wednesday, May 31, 2023 11:40 AM
>>> 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 Lior,
>>>
>>> On 31.05.23 10:05, Lior Weintraub wrote:
>>>> Hi Ahmad,
>>>>
>>>> Thanks again for your prompt reply and accurate tips!
>>>> Took the following changes:
>>>> 1. Increasing the DRAM size to 128MB (let barebox start from 0).
>>>> 2. Set PBL stack to offset 2MB from DRAM
>>>
>>> Just use end of SRAM, so you are completely independent of DRAM
>>> until you call barebox_arm_entry.
>>>
>>>> 3. Fix the device tree "memory" entry to have 128MB.
>>>
>>> (y)
>>>
>>>> 4. Load barebox-spider-mk1-evk.img to SRAM and run from there.
>>>>
>>>> Now I can see the following logs:
>>>> uncompress.c: memory at 0x00000000, size 0x08000000
>>>> uncompress.c: uncompressing barebox binary at 0x000000c0000021c0
>>> (size 0x0001e3a4) to 0x07e00000 (uncompressed size: 0x000390d0)
>>>> uncompress.c: jumping to uncompressed image at 0x0000000007e00000
>>>> start.c: memory at 0x00000000, size 0x08000000
>>>> start.c: found DTB in boarddata, copying to 0x07dffcc0
>>>> start.c: initializing malloc pool at 0x079ffcc0 (size 0x00400000)
>>>> start.c: starting barebox...
>>>> initcall-> command_slice_init+0x0/0x3c
>>>> initcall-> globalvar_init+0x0/0x80
>>>> register_device: global
>>>> register_device: nv
>>>> initcall-> platform_init+0x0/0x1c
>>>> register_device: platform
>>>> initcall-> amba_bus_init+0x0/0x1c
>>>> register_device: amba
>>>> initcall-> spi_bus_init+0x0/0x1c
>>>> register_device: spi
>>>> initcall-> gpio_desc_alloc+0x0/0x24
>>>> initcall-> fs_bus_init+0x0/0x1c
>>>> register_device: fs
>>>> initcall-> aarch64_init_vectors+0x0/0x50
>>>> initcall-> gpio_gate_clock_driver_register+0x0/0x1c
>>>> register_driver: gpio-gate-clock
>>>> initcall-> of_arm_init+0x0/0x5c
>>>> start.c: barebox_arm_boot_dtb: using barebox_boarddata
>>>> using boarddata provided DTB
>>>> adding DT alias:serial0: stem=serial id=0 node=/soc/serial@d000307000
>>>> register_device: machine
>>>> of_platform_bus_create() - skipping /chosen, no compatible prop
>>>> of_platform_bus_create() - skipping /aliases, no compatible prop
>>>> of_platform_bus_create() - skipping /cpus, no compatible prop
>>>> of_platform_bus_create() - skipping /memory@0, no compatible prop
>>>> of_platform_bus_create() - skipping /soc, no compatible prop
>>>> initcall-> register_autoboot_vars+0x0/0x70
>>>> initcall-> arm_arch_timer_driver_register+0x0/0x1c
>>>> register_driver: arm-architected-timer
>>>> initcall-> of_timer_init+0x0/0x20
>>>> initcall-> init_fs+0x0/0x3c
>>>> initcall-> pl011_driver_register+0x0/0x1c
>>>> register_driver: uart-pl011
>>>> initcall-> of_stdoutpath_init+0x0/0x28
>>>> initcall-> of_probe_memory+0x0/0x60
>>>> __request_region ok: 0x00000000:0x07ffffff flags=0x0
>>>> initcall-> __bare_init_end+0x0/0x6c
>>>> register_device: mem0
>>>> initcall-> of_reserved_mem_walk+0x0/0x1ac
>>>> initcall-> mem_malloc_resource+0x0/0xa8
>>>> __request_region ok: 0x079ffcc0:0x07dffcbf flags=0x200
>>>> __request_region ok: 0x07e00000:0x07e2aeff flags=0x200
>>>> __request_region ok: 0x07e2af00:0x07e390cf flags=0x200
>>>> __request_region ok: 0x07e390d0:0x07e3adaf flags=0x200
>>>> initcall-> bootsource_init+0x0/0x40
>>>> initcall-> ramfs_init+0x0/0x1c
>>>> register_driver: ramfs
>>>> initcall-> devfs_init+0x0/0x1c
>>>> register_driver: devfs
>>>> initcall-> arm_request_stack+0x0/0x398
>>>> __request_region ok: 0x07ff0000:0x07ff7fff flags=0x200
>>>> initcall-> mount_root+0x0/0x7c
>>>> mount: none on / type ramfs, options=
>>>> register_device: ramfs0
>>>>     probe-> ramfs0
>>>> mount: none on /dev type devfs, options=
>>>> register_device: devfs0
>>>>     probe-> devfs0
>>>> initcall-> binfmt_sh_init+0x0/0x1c
>>>> initcall-> binfmt_uimage_init+0x0/0x1c
>>>> initcall-> console_common_init+0x0/0x48
>>>> initcall-> of_kernel_init+0x0/0x28
>>>> initcall-> console_ctrlc_init+0x0/0x30
>>>> initcall-> mem_init+0x0/0x90
>>>> register_device: mem1
>>>> register_driver: mem
>>>>     probe-> mem0
>>>>     probe-> mem1
>>>> initcall-> of_partition_init+0x0/0x48
>>>> initcall-> prng_init+0x0/0x40
>>>> initcall-> null_init+0x0/0x40
>>>> initcall-> full_init+0x0/0x40
>>>> initcall-> zero_init+0x0/0x40
>>>> initcall-> spider_board_driver_register+0x0/0x1c
>>>> register_driver: board-spider
>>>>     probe-> machine
>>>> initcall-> barebox_memory_areas_init+0x0/0x40
>>>> __request_region ok: 0x07dffcc0:0x07dfffce flags=0x200
>>>> initcall-> barebox_of_populate+0x0/0x28
>>>> initcall-> of_register_memory_fixup+0x0/0x20
>>>> initcall-> dummy_csrc_warn+0x0/0x44
>>>> WARNING: Warning: Using dummy clocksource
>>>
>>> Add a arm,armv8-timer node into your SoC device tree.
>>> This lets barebox and Linux know that you have the ARM
>>> architected timer available. Without that, you'll notice
>>> that timeouts are wrong.
>>>
>>>> initcall-> bootm_init+0x0/0xf4
>>>> initcall-> init_command_list+0x0/0x40
>>>> register command bootm
>>>> register command cat
>>>> register command cd
>>>> register command clear
>>>> register command cp
>>>> register command cpuinfo
>>>> register command devinfo
>>>> register command drvinfo
>>>> register command echo
>>>> register command exit
>>>> register command false
>>>> register command help
>>>> register command ?
>>>> register command ll
>>>> register command ls
>>>> register command md
>>>> register command memcmp
>>>> register command memcpy
>>>> register command memset
>>>> register command mkdir
>>>> register command mount
>>>> register command mw
>>>> register command pwd
>>>> register command rm
>>>> register command rmdir
>>>> register command setenv
>>>> register command sh
>>>> register command source
>>>> register command .
>>>> register command test
>>>> register command [
>>>> register command true
>>>> register command :
>>>> register command umount
>>>> register command version
>>>> initcall-> display_meminfo+0x0/0xa8
>>>> barebox code: 0x7e00000 -> 0x7e2aeff
>>>> bss segment:  0x7e390d0 -> 0x7e3adaf
>>>> malloc space: 0x079ffcc0 -> 0x07dffcbf (size 4 MiB)
>>>> initcall-> of_register_bootargs_fixup+0x0/0x3c
>>>> initcall-> device_probe_deferred+0x0/0x14c
>>>> initcall-> of_init_hostname+0x0/0x28
>>>> initcall-> aarch64_register_image_handler+0x0/0x2c
>>>> 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
>>>>
>>>> Hit any to stop autoboot:    0
>>>> boot: No such file or directory
>>>> barebox:/
>>>>
>>>>
>>>> Few questions:
>>>> 1. The serial input doesn't work. i.e. I cannot type anything hence cannot
>>> interact with barebox terminal.
>>>
>>> DEBUG_LL only does otuput. For input, you will want to load the driver.
>>> Do you have CONFIG_SERIAL_AMBA_PL011 enabled?
>>>
>>>>      Does it require GIC and setting interrupts for it to work?
>>>
>>> No interrupts needed. barebox runs with interrupts disabled and everything
>>> is done cooperatively.
>>>
>>>> 2. What does "of_platform_bus_create() - skipping" means? Do I need to fix
>>> that?
>>>
>>> That's normal debugging output. Some device tree nodes are busses, which
>>> have
>>> children. These entries are skipped because they have no compatible. This is
>>> expected. I'd suggest you remove your VERBOSED_DEBUG define, so you are
>>> not
>>> spammed by too much debugging output.
>>>
>>>> 3. Looks like I am still missing some stuff (rootfs? Environment? Mounting?
>>> Partitions?)
>>>
>>> Take multi_v8_defconfig, open menuconfig and enable your SoC and use that.
>>> That will be quicker than enabling everything yourself. If it doesn't work
>>> out of the box, try imx_v8_defconfig.
>>>
>>> Once you get around to upstreaming your SoC, I'd suggest you just add it
>>> to multi_v8_defconfig. Not all ARMv8 SoCs are supported there, but those
>>> that are make development easier, because we don't need to build as many
>>> different configs..
>>>
>>> Cheers,
>>> Ahmad
>>>
>>>>
>>>> Thanks,
>>>> Have a great day,
>>>> Lior.
>>>>
>>>>
>>>>> -----Original Message-----
>>>>> From: Ahmad Fatoum <a.fatoum@pengutronix.de>
>>>>> Sent: Wednesday, May 31, 2023 9:11 AM
>>>>> 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 Lior,
>>>>>
>>>>> On 30.05.23 22:10, Lior Weintraub wrote:
>>>>>> Hello Ahmad,
>>>>>>
>>>>>> Thanks again for your kind support!
>>>>>> Your comments helped me progress and the current situation is as
>>> follows:
>>>>>> Our QEMU Spider machine is running a BL1.elf file using the following
>>>>> command:
>>>>>> QEMU_AUDIO_DRV=none qemu-system-aarch64 -M spider-soc -smp 1 -
>>> m
>>>>> 128M -nographic \
>>>>>>       -device loader,file=BL1.elf -cpu cortex-a53,rvbar=0xC004000000 \
>>>>>>       -d unimp -semihosting-config enable=on,target=native \
>>>>>>       -monitor telnet:localhost:1235,server,nowait \
>>>>>>       -gdb tcp::1236
>>>>>>
>>>>>> The BL1.elf is our BootROM application that runs from ROM address
>>>>> 0xC004000000.
>>>>>> Just for debugging purpose we've increased the ROM size so it can include
>>>>> the images/barebox-spider-mk1-evk.img (as a const array).
>>>>>> BL1 then copy it (using memcpy) to address 0 and jumps there for
>>>>> execution.
>>>>>
>>>>> Sounds ok.
>>>>>
>>>>>> On the real ASIC this address will be the DRAM and indeed will need to be
>>>>> initialized before the copy but here on QEMU it is not required.
>>>>>
>>>>> I see. You could still have your bootrom move barebox into SRAM and then
>>>>>
>>>>>   barebox_arm_entry(DRAM_ADDR, SZ_128M,
>>> __dtb_spider_mk1_evk_start);
>>>>>
>>>>> To have PBL extract barebox to DRAM. Even if you don't need need DRAM
>>>>> setup in QEMU, the flow would be similar to what you will have on actual
>>>>> silicon.
>>>>>
>>>>>> The lowlevel.c of spider-evk was modified to use DRAM_ADDR 0x400000
>>>>> (4MB from start) and MY_STACK_TOP was set to 0x8000000 (128M).
>>>>>
>>>>> That's not needed. While you don't have control where barebox PBL will be
>>>>> located
>>>>> (depends on BootROM), barebox will extract itself to the end of DRAM
>>>>> without
>>>>> overwriting itself, so you can just use DRAM_ADDR 0 normally. Eventually,
>>>>> stack
>>>>> top should go into SRAM, but anywhere that works is ok.
>>>>>
>>>>>> In addition, I implemented putc_ll (currently hard-coded in
>>>>> include/debug_ll.h) and opened log level to VERBOSE_DEBUG (currently
>>> just
>>>>> hard-coded in printk.h).
>>>>>
>>>>> There's CONFIG_DEBUG_PBL you can enable to get all these messages by
>>>>> default.
>>>>>
>>>>>> I see the following (which makes sense) logs on QEMU terminal:
>>>>>> uncompress.c: memory at 0x00400000, size 0x00200000
>>>>>> uncompress.c: uncompressing barebox binary at 0x0000000000002200
>>>>> (size 0x0001d3b2) to 0x00400000 (uncompressed size: 0x000373d0)
>>>>>
>>>>> Why pass only 2M to barebox_arm_entry? While this need not be the
>>> whole
>>>>> of RAM, this
>>>>> initial memory is what barebox will use for itself including its final stack and
>>>>> malloc area. barebox will also not place itself into the last 1M AFAIK, so 2M
>>>>> may not work ok. You should use the minimum possible RAM here or if you
>>>>> can detect
>>>>> in PBL how much RAM you have or just the whole RAM bank. I am not sure
>>>>> anything lower
>>>>> than SZ_4M would work ok. (Note this is DRAM size, not SRAM. barebox
>>> PBL
>>>>> is fine being
>>>>> called from 64K SRAMs, it just needs DRAM to extract to).
>>>>>
>>>>>> I then connect with aarch64-none-elf-gdb, load the barebox symbols (to
>>>>> 0x400000) and check the current execution state (program counter and
>>>>> stack).
>>>>>> Looks like the code is stuck on function register_autoboot_vars:
>>>>>> sp             0x5f7e60            0x5f7e60
>>>>>> pc             0x401264            0x401264 <register_autoboot_vars+24>
>>>>>>
>>>>>> Few observations:
>>>>>> 1. The PBL was using stack top located on 0x8000000 (which is
>>>>> MY_STACK_TOP). Found it be causing a breakpoint on the PBL.
>>>>>> 2. Barebox uses a stack top on 0x600000 which is probably calculated
>>> from
>>>>> my new DRAM_ADDR and SZ_2M given to the function call:
>>>>>>     barebox_arm_entry(DRAM_ADDR, SZ_2M,
>>> __dtb_spider_mk1_evk_start);
>>>>>>
>>>>>> This is great! I am starting to find my way.
>>>>>
>>>>> :) Ye, the ENTRY_FUNCTION_WITHSTACK is only when the BootROM
>>> doesn't
>>>>> enter
>>>>> with a valid stack pointer. It's overwritten as soon as barebox is told
>>>>> about the initial memory layout (with barebox_arm_entry).
>>>>>
>>>>>> When the barebox execution didn't print anything to the terminal I
>>>>> remembered that we used a place holder on the dtsi for the uart.
>>>>>> So now I changed it to:
>>>>>> uart0: serial@d000307000 {
>>>>>>        compatible = "arm,pl011", "arm,primecell";
>>>>>>        reg = <0xd0 0x307000 0 0x1000>;
>>>>>> }
>>>>>> (Our QEMU UART is currently using pl011 device.)
>>>>>
>>>>> Looks ok. Don't forget to enable the driver (via make menuconfig).
>>>>>
>>>>>> After some time (trying to debug by enabling MMU but then reverted the
>>>>> code back), I got to a point that when I try to run again I am getting an
>>>>> exception.
>>>>>> I can swear all code changes were reverted back to the point where I saw
>>> the
>>>>> barebox stuck on register_autoboot_vars but now it just cases an
>>> exception.
>>>>>> The exception vector code is located on our ROM (part of BL1 code) and
>>> the
>>>>> logs shows that the link register has the value 0x401218 which suggest the
>>>>> following code:
>>>>>> 0000000000001200 <load_environment>:
>>>>>> 1200: a9be7bfd        stp     x29, x30, [sp, #-32]!
>>>>>> 1204: 910003fd        mov     x29, sp
>>>>>> 1208: a90153f3        stp     x19, x20, [sp, #16]
>>>>>> 120c: 94000a07        bl      3a28 <default_environment_path_get>
>>>>>> 1210: d00000f3        adrp    x19, 1f000 <do_cpuinfo+0x1f0>
>>>>>> 1214: 912a7273        add     x19, x19, #0xa9c
>>>>>> 1218: aa0003f4        mov     x20, x0
>>>>>>
>>>>>> Any ideas or suggestions how to proceed with the debugging?
>>>>>
>>>>> You shouldn't need to touch the MMU code. If your initial memory setup
>>>>> is wonky, you may end up overwriting stuff. Try again with bigger memory.
>>>>>
>>>>>> BTW, to answer your questions:
>>>>>> The SRAM of 4MB is the only one we have because we assumed it is only
>>> for
>>>>> BootROM to load a PBL
>>>>>
>>>>> Ok. Sometimes there are SRAMs for use with DMA. I asked, because a
>>> SRAM
>>>>> in the first 4M
>>>>> would lend itself nicely as stack, but if there is none, we can adjust
>>>>> ENTRY_FUNCTION_WITHSTACK to accept a 64-bit parameter.
>>>>>
>>>>> Cheers,
>>>>> Ahmad
>>>>>
>>>>>> Thank you very much,
>>>>>> Cheers,
>>>>>> Lior.
>>>>>>
>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Ahmad Fatoum <a.fatoum@pengutronix.de>
>>>>>>> Sent: Monday, May 29, 2023 10:03 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 29.05.23 15:34, Lior Weintraub wrote:
>>>>>>>> Hi Ahmad,
>>>>>>>>
>>>>>>>> I have revised the addresses and used DRAM address @ 0 instead:
>>>>>>>> #define UARTBASE        (0xD000307000)
>>>>>>>> #define DRAM_ADDR       (0x00000000)
>>>>>>>> #define MY_STACK_TOP    (0x00000000 + SZ_2M) // Set the stack 2MB
>>>>> from
>>>>>>> DRAM start
>>>>>>>
>>>>>>> Is DRAM configured by the time barebox runs? If not, you should keep
>>>>> stack
>>>>>>> top
>>>>>>> in SRAM, until you have setup memory in prebootloader (PBL). Is the 4M
>>>>>>> SRAM
>>>>>>> the only on-chip SRAM you have?
>>>>>>>
>>>>>>>> static inline void spider_serial_putc(void *base, int c)
>>>>>>>> {
>>>>>>>>     *((volatile unsigned *)base) = c;
>>>>>>>
>>>>>>> There's a helper for that: writel(c, base); In barebox, it's equivalent
>>>>>>> to the volatile access, but in Linux it involves a write memory barrier.
>>>>>>> We try to write code in barebox, so it's easily reusable in Linux (and
>>>>>>> the other way round).
>>>>>>>
>>>>>>>> }
>>>>>>>>
>>>>>>>> I will try to test it on QEMU using an initial QEMU machine we made for
>>>>>>> Spider.
>>>>>>>> In this machine we only have 3 memory regions and a PL011 UART:
>>>>>>>> spider_soc_memories soc_memories[] = {
>>>>>>>>     {.name = "SPIDER_GPRAM",   .add = 0xC000000000ULL, .size = 4 *
>>> MiB},
>>>>>>>>     {.name = "SPIDER_ROM",     .add = 0xC004000000ULL, .size = 128 *
>>>>> KiB},
>>>>>>>>     {.name = "SPIDER_DRAM",    .add = 0x0000000000ULL, .size = 1 *
>>> GiB},
>>>>>>>> };
>>>>>>>>
>>>>>>>> This special QEMU machine can run our BL1 code from "ROM" address
>>>>> (we
>>>>>>> set the RVBAR to point there).
>>>>>>>> So my idea is to test the barebox image by the following steps:
>>>>>>>> 1. Modify the QEMU code to have a "ROM" with the size of 128M.
>>>>>>>> 2. Compile our BL1 code to include the barebox.bin as a const array,
>>> copy
>>>>> it
>>>>>>> to "DRAM" @ address 0 and jump there.
>>>>>>>
>>>>>>> Why not map QEMU -bios option to SRAM? (Or DRAM directly, if it
>>> needs
>>>>> no
>>>>>>> special setup from
>>>>>>> barebox side).
>>>>>>>
>>>>>>>> For this to work I wanted to understand how to call (i.e. what
>>> arguments
>>>>> to
>>>>>>> pass) to barebox.
>>>>>>>
>>>>>>> barebox doesn't expect any arguments, because most BootROMs don't
>>>>> pass
>>>>>>> anything useful.
>>>>>>> Some pass information about bootsource though, so that's why the
>>>>>>> ENTRY_FUNCTION has
>>>>>>> r0, r1 and r2 as parameters, but you need not use them.
>>>>>>>
>>>>>>>> So I checked the barebox.map and found the function "start" on
>>> address
>>>>> 0.
>>>>>>>
>>>>>>> You may know that Linux on some platforms comes with a decompressor
>>>>> that
>>>>>>> is glued to the
>>>>>>> front of the kernel image and extracts the compressed kernel image.
>>>>> barebox
>>>>>>> has the same
>>>>>>> concept. The prebootloader is uncompressed and runs (starting from
>>>>>>> ENTRY_FUNCTION) and
>>>>>>> then does some early setup (e.g. enable clocks, configure PMIC, setup
>>>>> DRAM,
>>>>>>> load secure
>>>>>>> monitor (BL31), ...etc.) and then it decompresses barebox proper into
>>>>> DRAM.
>>>>>>>
>>>>>>> barebox.bin <- barebox proper. You don't usually need that.
>>>>>>> barebox.elf <- ELF binary for the above (for gdb)
>>>>>>> barebox.map <- map file of the above
>>>>>>>
>>>>>>> images/barebox-spider-mk1-evk.img   <- complete barebox image (PBL +
>>>>>>> barebox proper)
>>>>>>> images/start_spider_mk1_evk.pbl     <- ELF image for the above
>>>>>>> images/start_spider_mk1_evk.pbl.map <- map file of the above
>>>>>>>
>>>>>>> If you want to follow barbeox from the start, begin at
>>>>> start_spider_mk1_evk.
>>>>>>>
>>>>>>>> Then I went to arch/arm/cpu/start.c and realized that the code is
>>> compiled
>>>>>>> with CONFIG_PBL_IMAGE.
>>>>>>>> In that case I assume I need to pass 3 arguments and use this function
>>>>>>> prototype:
>>>>>>>> void start(unsigned long membase, unsigned long memsize, void
>>>>>>> *boarddata);
>>>>>>>
>>>>>>> barebox prebootloader takes care of this, so you don't need to do
>>> anything.
>>>>>>>
>>>>>>>> Few questions:
>>>>>>>> 1. Will that call work:
>>>>>>>>     typedef void (*barebox_start)(unsigned long , unsigned long , void *);
>>>>>>>>     #define DRAM_START  (0)
>>>>>>>>     barebox_start p_barebox = (barebox_start)DRAM_START;
>>>>>>>>     p_barebox(DRAM_START, DRAM_START+SZ_2M, (void
>>>>>>> *)(DRAM_START+SZ_4M));
>>>>>>>>     This assumes that my BL1 code also copied the device tree (barebox-
>>> dt-
>>>>>>> 2nd.img? start_dt_2nd.pblb? start_spider_mk1_evk.pblb?)
>>>>>>>
>>>>>>> The device tree is built into the PBL and passed to barebox proper. This
>>>>>>> allows us to use the same barebox proper binary and link it with a
>>> different
>>>>>>> prebootloader for each SoC/board, all in the same build.
>>>>>>>
>>>>>>> barebox-dt-2nd.img is a special image that looks exactly like a Linux
>>> kernel:
>>>>>>>
>>>>>>>   images/barebox-dt-2nd.img: Linux kernel ARM64 boot executable
>>> Image,
>>>>>>> little-endian, 4K pages
>>>>>>>
>>>>>>> and can thus be used for booting for easy chainloading from other
>>>>>>> bootloaders or for running
>>>>>>> with QEMU -kernel. You shouldn't need it right now.
>>>>>>>
>>>>>>>> 2. Do I want to have my code compiled with CONFIG_PBL_IMAGE?
>>>>>>>>     If I understand correctly, it means that my code will provide a PBL
>>> (a.k.a
>>>>>>> BL2) which will set the DRAM and STACK among other things (MMU?).
>>>>>>>
>>>>>>> The patch I sent already builds a PBL. You will need to fill out
>>>>>>> start_spider_mk1_evk
>>>>>>> to do all the other early initialization you need. Then you call
>>>>>>> barebox_arm_entry
>>>>>>> with device tree and memory size and it will take care to do stack setup in
>>>>> new
>>>>>>> memory region, MMU setup (if enabled) and chainloading barebox
>>> proper.
>>>>>>>
>>>>>>> Note that PBL isn't necessary BL2. You can chainload barebox from within
>>>>>>> barebox (i.e.
>>>>>>> in EL2 or EL1), which is useful for debugging. You will thus often find PBL
>>>>> code
>>>>>>> that
>>>>>>> does
>>>>>>>
>>>>>>>   if (current_el() == 3) {
>>>>>>>         /* Do BL2 setup */
>>>>>>>         chainload();
>>>>>>>         __builtin_unreachable();
>>>>>>>   }
>>>>>>>
>>>>>>>   barebox_arm_entry(...)
>>>>>>>
>>>>>>> See for example arch/arm/boards/innocomm-imx8mm-wb15/lowlevel.c
>>>>>>>
>>>>>>> to see a real-world example of another Cortex-A53.
>>>>>>>
>>>>>>>>     In that case I assume it is OK.
>>>>>>>> 3. If I try to remove it by having CONFIG_PBL_IMAGE=n on
>>>>> spider_defconfig
>>>>>>> this doesn't do anything
>>>>>>>>     The build (make spider_defconfig) ignores it and say that " No change
>>> to
>>>>>>> .config ".
>>>>>>>
>>>>>>> Another symbol forces it to be enabled. If you are curious, run make
>>>>>>> menuconfig
>>>>>>> and then search (/) for the symbol and it will list, whether it's enabled
>>> and
>>>>>>> why:
>>>>>>>
>>>>>>>   Selected by [y]:
>>>>>>>     - PBL_MULTI_IMAGES [=y] && HAVE_PBL_MULTI_IMAGES [=y]
>>>>>>>
>>>>>>> I'd suggest you avoid modifying the .config file manually. always use
>>>>>>> menuconfig.
>>>>>>>
>>>>>>>> 4. I also tried to understand how to implement PUTC_LL but not sure I
>>>>>>> understand.
>>>>>>>>    4.1 When I set "CONFIG_DEBUG_LL=y" on spider_defconfig it is again
>>>>> not
>>>>>>> written to .config and I get " No change to .config " message.
>>>>>>>
>>>>>>> You must:
>>>>>>>
>>>>>>>   - select HAS_DEBUG_LL from MACH_SPIDER
>>>>>>>   - Add your arch to arch/arm/include/asm/debug_ll.h
>>>>>>>   - Then implement PUTC_LL in e.g. mach/spider/debug_ll.h
>>>>>>>
>>>>>>>>    4.2 Do I need to have my own debug_ll.h file?
>>>>>>>
>>>>>>> Yes. See above.
>>>>>>>
>>>>>>>> 5. When I make changes to spider_defconfig and try to regenerate the
>>>>>>> .config and I get " No change to .config " message, does it mean that
>>> those
>>>>>>> macros are "hidden" symbols like you said about the CONFIG_CPU_V8?
>>>>>>>
>>>>>>> Yes. Just check menuconfig to see how symbols relate to each other.
>>>>>>> This is 1:1 like it's in Linux, so it'll come in handy when you do
>>>>>>> the kernel port too ;)
>>>>>>>
>>>>>>>> Apologize for so many questions :-)
>>>>>>>
>>>>>>> No problem. Looking forward to your patches ;)
>>>>>>>
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Ahmad
>>>>>>>
>>>>>>>> Cheers,
>>>>>>>> Lior.
>>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: Lior Weintraub
>>>>>>>> Sent: Sunday, May 28, 2023 11:16 PM
>>>>>>>> To: Ahmad Fatoum <ahmad@a3f.at>; barebox@lists.infradead.org
>>>>>>>> Subject: RE: [PATCH v2] Porting barebox to a new SoC
>>>>>>>>
>>>>>>>> Hi Ahmad,
>>>>>>>>
>>>>>>>> Thank you so much for your kind support!
>>>>>>>>
>>>>>>>> Indeed we also have a 16GB DRAM that starts from address 0 (though
>>>>>>> currently we don't have the controller settings (under development)).
>>>>>>>>
>>>>>>>> I also wrote the BootROM (BL1) for this SoC (128KB ROM @ address
>>>>>>> 0xC004000000).
>>>>>>>> I understand now that it would be best for me to develop BL2 that will
>>> run
>>>>>>> from our SRAM.
>>>>>>>>
>>>>>>>> As this BL2 code is bare-metal I have no problem or limitations with the
>>> 40
>>>>>>> bit addresses.
>>>>>>>> The BL2 code will initialize the DRAM controller and then copy Barebox
>>>>> image
>>>>>>> from NOR Flash to address 0 of the DRAM.
>>>>>>>> Our NOR Flash is 128MB in size and it is accessed via QSPI controller.
>>>>>>>>
>>>>>>>> I tried applying your suggested patch but got an error while doing so:
>>>>>>>> $git apply 0002-Ahmad.patch
>>>>>>>> 0002-Ahmad.patch:115: trailing whitespace.
>>>>>>>>       .of_compatible = spider_board_of_match, };
>>>>>>>> error: corrupt patch at line 117
>>>>>>>>
>>>>>>>> After some digging I found that my Outlook probably messed with the
>>>>> patch
>>>>>>> format (even though I am using text only and no HTML format).
>>>>>>>> When I went to the web and copied the patch from there (mailing list
>>>>>>> archive) it was working well (i.e. no compilation error).
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>> Lior.
>>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: Ahmad Fatoum <ahmad@a3f.at>
>>>>>>>> Sent: Sunday, May 28, 2023 6:38 PM
>>>>>>>> To: barebox@lists.infradead.org
>>>>>>>> Cc: Lior Weintraub <liorw@pliops.com>
>>>>>>>> Subject: [PATCH v2] Porting barebox to a new SoC
>>>>>>>>
>>>>>>>> CAUTION: External Sender
>>>>>>>>
>>>>>>>> From: Lior Weintraub <liorw@pliops.com>
>>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> I tried to follow the porting guide on https://ddec1-0-en-
>>>>>>>
>>>>>
>>> ctp.trendmicro.com:443/wis/clicktime/v1/query?url=https%3a%2f%2fwww.
>>>>>>>
>>>>>
>>> barebox.org%2fdoc%2flatest%2fdevel%2fporting.html%23&umid=60097eda
>>>>>>> -f136-45a1-9c8e-
>>>>>>> cf6a76e45cf8&auth=860a7ebb9feba264acc79b6e38eb59582349362c-
>>>>>>> 480ae23736add41c88ab8d30c090a75517ca7f9e but couldn't follow
>>> the
>>>>>>> instructions.
>>>>>>>> I would like to port barebox to a new SoC (which is not a derivative of
>>> any
>>>>>>> known SoC).
>>>>>>>> It has the following:
>>>>>>>> * Single Cortex A53
>>>>>>>> * SRAM (4MB) located on address 0xC000000000
>>>>>>>>
>>>>>>>> The below patch shows my initial test to try and have a starting point.
>>>>>>>> I am setting env variables:
>>>>>>>> export ARCH=arm64
>>>>>>>> export CROSS_COMPILE=/home/pliops/workspace/ARM/arm-gnu-
>>>>>>> toolchain/bin/aarch64-none-elf-
>>>>>>>>
>>>>>>>> Then I build with:
>>>>>>>> make spider_defconfig && make
>>>>>>>>
>>>>>>>> This gives an error:
>>>>>>>> aarch64-none-elf-gcc: error: unrecognized argument in option '-
>>>>> mabi=apcs-
>>>>>>> gnu'
>>>>>>>> aarch64-none-elf-gcc: note: valid arguments to '-mabi=' are: ilp32 lp64
>>>>>>>> aarch64-none-elf-gcc: error: unrecognized command-line option '-
>>> msoft-
>>>>>>> float'
>>>>>>>> aarch64-none-elf-gcc: error: unrecognized command-line option '-mno-
>>>>>>> unaligned-access'
>>>>>>>> /home/pliops/workspace/simplest-linux-
>>>>>>> demo/barebox/scripts/Makefile.build:140: recipe for target
>>>>>>> 'scripts/mod/empty.o' failed
>>>>>>>> make[2]: *** [scripts/mod/empty.o] Error 1
>>>>>>>>
>>>>>>>> Not sure why the compiler flags get -mabi=apcs-gnu when I explicitly set
>>>>>>> CONFIG_CPU_V8 and the arch/arm/Makefile has:
>>>>>>>> ifeq ($(CONFIG_CPU_V8), y)
>>>>>>>> CFLAGS_ABI      :=-mabi=lp64
>>>>>>>>
>>>>>>>> The changes I did:
>>>>>>>> >From 848b5f9b18bb1bb96d197cbc1b368ee0a729d581 Mon Sep 17
>>>>>>> 00:00:00 2001
>>>>>>>> ---
>>>>>>>>  arch/arm/Kconfig                      | 13 ++++++++
>>>>>>>>  arch/arm/Makefile                     |  1 +
>>>>>>>>  arch/arm/boards/Makefile              |  1 +
>>>>>>>>  arch/arm/boards/spider-evk/Makefile   |  4 +++
>>>>>>>>  arch/arm/boards/spider-evk/board.c    | 26 +++++++++++++++
>>>>>>>>  arch/arm/boards/spider-evk/lowlevel.c | 30 +++++++++++++++++
>>>>>>>>  arch/arm/configs/spider_defconfig     |  8 +++++
>>>>>>>>  arch/arm/dts/Makefile                 |  1 +
>>>>>>>>  arch/arm/dts/spider-mk1-evk.dts       | 10 ++++++
>>>>>>>>  arch/arm/dts/spider-mk1.dtsi          | 46
>>> +++++++++++++++++++++++++++
>>>>>>>>  arch/arm/mach-spider/Kconfig          | 16 ++++++++++
>>>>>>>>  arch/arm/mach-spider/Makefile         |  1 +
>>>>>>>>  arch/arm/mach-spider/lowlevel.c       | 14 ++++++++
>>>>>>>>  images/Makefile                       |  1 +
>>>>>>>>  images/Makefile.spider                |  5 +++
>>>>>>>>  include/mach/spider/lowlevel.h        |  7 ++++
>>>>>>>>  16 files changed, 184 insertions(+)
>>>>>>>>  create mode 100644 arch/arm/boards/spider-evk/Makefile
>>>>>>>>  create mode 100644 arch/arm/boards/spider-evk/board.c
>>>>>>>>  create mode 100644 arch/arm/boards/spider-evk/lowlevel.c
>>>>>>>>  create mode 100644 arch/arm/configs/spider_defconfig  create mode
>>>>>>> 100644 arch/arm/dts/spider-mk1-evk.dts  create mode 100644
>>>>>>> arch/arm/dts/spider-mk1.dtsi  create mode 100644 arch/arm/mach-
>>>>>>> spider/Kconfig  create mode 100644 arch/arm/mach-spider/Makefile
>>>>> create
>>>>>>> mode 100644 arch/arm/mach-spider/lowlevel.c  create mode 100644
>>>>>>> images/Makefile.spider  create mode 100644
>>>>> include/mach/spider/lowlevel.h
>>>>>>>>
>>>>>>>> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index
>>>>>>> e76ee0f6dfe1..e5dcf128447e 100644
>>>>>>>> --- a/arch/arm/Kconfig
>>>>>>>> +++ b/arch/arm/Kconfig
>>>>>>>> @@ -255,6 +255,18 @@ config ARCH_ROCKCHIP
>>>>>>>>         select HAS_DEBUG_LL
>>>>>>>>         imply GPIO_ROCKCHIP
>>>>>>>>
>>>>>>>> +config ARCH_SPIDER
>>>>>>>> +       bool "Pliops Spider based"
>>>>>>>> +       depends on 64BIT
>>>>>>>> +       depends on ARCH_MULTIARCH
>>>>>>>> +       select GPIOLIB
>>>>>>>> +       select HAVE_PBL_MULTI_IMAGES
>>>>>>>> +       select COMMON_CLK
>>>>>>>> +       select CLKDEV_LOOKUP
>>>>>>>> +       select COMMON_CLK_OF_PROVIDER
>>>>>>>> +       select OFTREE
>>>>>>>> +       select OFDEVICE
>>>>>>>> +
>>>>>>>>  config ARCH_STM32MP
>>>>>>>>         bool "STMicroelectronics STM32MP"
>>>>>>>>         depends on 32BIT
>>>>>>>> @@ -331,6 +343,7 @@ source "arch/arm/mach-omap/Kconfig"
>>>>>>>>  source "arch/arm/mach-pxa/Kconfig"
>>>>>>>>  source "arch/arm/mach-rockchip/Kconfig"
>>>>>>>>  source "arch/arm/mach-socfpga/Kconfig"
>>>>>>>> +source "arch/arm/mach-spider/Kconfig"
>>>>>>>>  source "arch/arm/mach-stm32mp/Kconfig"
>>>>>>>>  source "arch/arm/mach-versatile/Kconfig"
>>>>>>>>  source "arch/arm/mach-vexpress/Kconfig"
>>>>>>>> diff --git a/arch/arm/Makefile b/arch/arm/Makefile index
>>>>>>> 35ebc70f44e2..4c63dfee48f4 100644
>>>>>>>> --- a/arch/arm/Makefile
>>>>>>>> +++ b/arch/arm/Makefile
>>>>>>>> @@ -101,6 +101,7 @@ machine-$(CONFIG_ARCH_MXS)          += mxs
>>>>>>>>  machine-$(CONFIG_ARCH_MVEBU)           += mvebu
>>>>>>>>  machine-$(CONFIG_ARCH_NOMADIK)         += nomadik
>>>>>>>>  machine-$(CONFIG_ARCH_OMAP)            += omap
>>>>>>>> +machine-$(CONFIG_ARCH_SPIDER)          += spider
>>>>>>>>  machine-$(CONFIG_ARCH_PXA)             += pxa
>>>>>>>>  machine-$(CONFIG_ARCH_ROCKCHIP)                += rockchip
>>>>>>>>  machine-$(CONFIG_ARCH_SAMSUNG)         += samsung
>>>>>>>> diff --git a/arch/arm/boards/Makefile b/arch/arm/boards/Makefile
>>> index
>>>>>>> 2877debad535..6fe0a90c81ea 100644
>>>>>>>> --- a/arch/arm/boards/Makefile
>>>>>>>> +++ b/arch/arm/boards/Makefile
>>>>>>>> @@ -135,6 +135,7 @@ obj-
>>>>>>> $(CONFIG_MACH_SOCFPGA_TERASIC_DE10_NANO)        += terasic-
>>> de10-
>>>>>>> nano/
>>>>>>>>  obj-$(CONFIG_MACH_SOCFPGA_TERASIC_SOCKIT)      += terasic-
>>> sockit/
>>>>>>>>  obj-$(CONFIG_MACH_SOLIDRUN_CUBOX)              += solidrun-cubox/
>>>>>>>>  obj-$(CONFIG_MACH_SOLIDRUN_MICROSOM)           += solidrun-
>>>>>>> microsom/
>>>>>>>> +obj-$(CONFIG_MACH_SPIDER_MK1_EVK)              += spider-evk/
>>>>>>>>  obj-$(CONFIG_MACH_STM32MP15XX_DKX)             += stm32mp15xx-
>>>>> dkx/
>>>>>>>>  obj-$(CONFIG_MACH_STM32MP13XX_DK)              += stm32mp13xx-
>>> dk/
>>>>>>>>  obj-$(CONFIG_MACH_LXA_MC1)                     += lxa-mc1/
>>>>>>>> diff --git a/arch/arm/boards/spider-evk/Makefile
>>>>>>> b/arch/arm/boards/spider-evk/Makefile
>>>>>>>> new file mode 100644
>>>>>>>> index 000000000000..da63d2625f7a
>>>>>>>> --- /dev/null
>>>>>>>> +++ b/arch/arm/boards/spider-evk/Makefile
>>>>>>>> @@ -0,0 +1,4 @@
>>>>>>>> +# SPDX-License-Identifier: GPL-2.0-only
>>>>>>>> +
>>>>>>>> +obj-y += board.o
>>>>>>>> +lwl-y += lowlevel.o
>>>>>>>> diff --git a/arch/arm/boards/spider-evk/board.c
>>>>> b/arch/arm/boards/spider-
>>>>>>> evk/board.c
>>>>>>>> new file mode 100644
>>>>>>>> index 000000000000..3920e83b457d
>>>>>>>> --- /dev/null
>>>>>>>> +++ b/arch/arm/boards/spider-evk/board.c
>>>>>>>> @@ -0,0 +1,26 @@
>>>>>>>> +#include <bbu.h>
>>>>>>>> +#include <boot.h>
>>>>>>>> +#include <bootm.h>
>>>>>>>> +#include <common.h>
>>>>>>>> +#include <deep-probe.h>
>>>>>>>> +#include <environment.h>
>>>>>>>> +#include <fcntl.h>
>>>>>>>> +#include <globalvar.h>
>>>>>>>> +
>>>>>>>> +static int spider_board_probe(struct device *dev) {
>>>>>>>> +      /* Do some board-specific setup */
>>>>>>>> +      return 0;
>>>>>>>> +}
>>>>>>>> +
>>>>>>>> +static const struct of_device_id spider_board_of_match[] = {
>>>>>>>> +      { .compatible = "pliops,spider-mk1-evk" },
>>>>>>>> +      { /* sentinel */ },
>>>>>>>> +};
>>>>>>>> +
>>>>>>>> +static struct driver spider_board_driver = {
>>>>>>>> +      .name = "board-spider",
>>>>>>>> +      .probe = spider_board_probe,
>>>>>>>> +      .of_compatible = spider_board_of_match, };
>>>>>>>> +device_platform_driver(spider_board_driver);
>>>>>>>> diff --git a/arch/arm/boards/spider-evk/lowlevel.c
>>>>>>> b/arch/arm/boards/spider-evk/lowlevel.c
>>>>>>>> new file mode 100644
>>>>>>>> index 000000000000..e36fcde4208e
>>>>>>>> --- /dev/null
>>>>>>>> +++ b/arch/arm/boards/spider-evk/lowlevel.c
>>>>>>>> @@ -0,0 +1,30 @@
>>>>>>>> +#include <common.h>
>>>>>>>> +#include <asm/barebox-arm.h>
>>>>>>>> +#include <mach/spider/lowlevel.h>
>>>>>>>> +
>>>>>>>> +#define BASE_ADDR       (0xD000307000)
>>>>>>>> +#define GPRAM_ADDR      (0xC000000000)
>>>>>>>> +#define MY_STACK_TOP    (0xC000000000 + SZ_2M) // Set the stack
>>>>> 2MB
>>>>>>> from GPRAM start (excatly in the middle)
>>>>>>>> +static inline void spider_serial_putc(void *base, int c) {
>>>>>>>> +//     if (!(readl(base + UCR1) & UCR1_UARTEN))
>>>>>>>> +//             return;
>>>>>>>> +//
>>>>>>>> +//     while (!(readl(base + USR2) & USR2_TXDC));
>>>>>>>> +//
>>>>>>>> +//     writel(c, base + URTX0);
>>>>>>>> +}
>>>>>>>> +
>>>>>>>> +ENTRY_FUNCTION_WITHSTACK(start_spider_mk1_evk,
>>> MY_STACK_TOP,
>>>>>>> r0, r1,
>>>>>>>> +r2) {
>>>>>>>> +       extern char __dtb_spider_mk1_evk_start[];
>>>>>>>> +
>>>>>>>> +       spider_lowlevel_init();
>>>>>>>> +
>>>>>>>> +       relocate_to_current_adr();
>>>>>>>> +       setup_c();
>>>>>>>> +
>>>>>>>> +       pbl_set_putc(spider_serial_putc, (void *)BASE_ADDR);
>>>>>>>> +
>>>>>>>> +       barebox_arm_entry(GPRAM_ADDR, SZ_2M,
>>>>>>>> +__dtb_spider_mk1_evk_start); }
>>>>>>>> diff --git a/arch/arm/configs/spider_defconfig
>>>>>>> b/arch/arm/configs/spider_defconfig
>>>>>>>> new file mode 100644
>>>>>>>> index 000000000000..c91bb889d97f
>>>>>>>> --- /dev/null
>>>>>>>> +++ b/arch/arm/configs/spider_defconfig
>>>>>>>> @@ -0,0 +1,8 @@
>>>>>>>> +CONFIG_ARCH_SPIDER=y
>>>>>>>> +CONFIG_MACH_SPIDER_MK1_EVK=y
>>>>>>>> +CONFIG_BOARD_ARM_GENERIC_DT=y
>>>>>>>> +CONFIG_MALLOC_TLSF=y
>>>>>>>> +CONFIG_KALLSYMS=y
>>>>>>>> +CONFIG_RELOCATABLE=y
>>>>>>>> +CONFIG_CONSOLE_ALLOW_COLOR=y
>>>>>>>> +CONFIG_PBL_CONSOLE=y
>>>>>>>> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile index
>>>>>>> 98f4c4e0194b..94b304d4878f 100644
>>>>>>>> --- a/arch/arm/dts/Makefile
>>>>>>>> +++ b/arch/arm/dts/Makefile
>>>>>>>> @@ -134,6 +134,7 @@ lwl-$(CONFIG_MACH_SOLIDRUN_CUBOX) +=
>>>>> dove-
>>>>>>> cubox-bb.dtb.o
>>>>>>>>  lwl-$(CONFIG_MACH_SOLIDRUN_MICROSOM) += imx6dl-
>>>>>>> hummingboard.dtb.o imx6q-hummingboard.dtb.o \
>>>>>>>>                                 imx6dl-hummingboard2.dtb.o imx6q-
>>>>>>> hummingboard2.dtb.o \
>>>>>>>>                                 imx6q-h100.dtb.o
>>>>>>>> +lwl-$(CONFIG_MACH_SPIDER_MK1_EVK) += spider-mk1-evk.dtb.o
>>>>>>>>  lwl-$(CONFIG_MACH_SKOV_IMX6) += imx6s-skov-imx6.dtb.o imx6dl-
>>>>> skov-
>>>>>>> imx6.dtb.o imx6q-skov-imx6.dtb.o
>>>>>>>>  lwl-$(CONFIG_MACH_SKOV_ARM9CPU) += at91-skov-arm9cpu.dtb.o
>>>>>>>>  lwl-$(CONFIG_MACH_SEEED_ODYSSEY) += stm32mp157c-
>>> odyssey.dtb.o
>>>>>>> diff --git a/arch/arm/dts/spider-mk1-evk.dts b/arch/arm/dts/spider-
>>> mk1-
>>>>>>> evk.dts new file mode 100644 index 000000000000..b8081cb85bf8
>>>>>>>> --- /dev/null
>>>>>>>> +++ b/arch/arm/dts/spider-mk1-evk.dts
>>>>>>>> @@ -0,0 +1,10 @@
>>>>>>>> +// SPDX-License-Identifier: GPL-2.0 OR X11
>>>>>>>> +
>>>>>>>> +/dts-v1/;
>>>>>>>> +
>>>>>>>> +#include "spider-mk1.dtsi"
>>>>>>>> +
>>>>>>>> +/ {
>>>>>>>> +       model = "Pliops Spider MK-I EVK";
>>>>>>>> +       compatible = "pliops,spider-mk1-evk"; };
>>>>>>>> diff --git a/arch/arm/dts/spider-mk1.dtsi b/arch/arm/dts/spider-
>>> mk1.dtsi
>>>>>>> new file mode 100644 index 000000000000..d4613848169d
>>>>>>>> --- /dev/null
>>>>>>>> +++ b/arch/arm/dts/spider-mk1.dtsi
>>>>>>>> @@ -0,0 +1,46 @@
>>>>>>>> +// SPDX-License-Identifier: GPL-2.0 OR X11
>>>>>>>> +
>>>>>>>> +/ {
>>>>>>>> +       #address-cells = <2>;
>>>>>>>> +       #size-cells = <2>;
>>>>>>>> +
>>>>>>>> +       chosen {
>>>>>>>> +               stdout-path = &uart0;
>>>>>>>> +       };
>>>>>>>> +
>>>>>>>> +       aliases {
>>>>>>>> +               serial0 = &uart0;
>>>>>>>> +       };
>>>>>>>> +
>>>>>>>> +       cpus {
>>>>>>>> +               #address-cells = <1>;
>>>>>>>> +               #size-cells = <0>;
>>>>>>>> +
>>>>>>>> +               cpu0: cpu@0 {
>>>>>>>> +                       device_type = "cpu";
>>>>>>>> +                       compatible = "arm,cortex-a53";
>>>>>>>> +                       reg = <0x0>;
>>>>>>>> +               };
>>>>>>>> +       };
>>>>>>>> +
>>>>>>>> +       memory@1000000 {
>>>>>>>> +               reg = <0x0 0x1000000 0x0 0x400000>; /* 128M */
>>>>>>>> +               device_type = "memory";
>>>>>>>> +       };
>>>>>>>> +
>>>>>>>> +       soc {
>>>>>>>> +               #address-cells = <2>;
>>>>>>>> +               #size-cells = <2>;
>>>>>>>> +               ranges;
>>>>>>>> +
>>>>>>>> +               sram@c000000000 {
>>>>>>>> +                       compatible = "mmio-sram";
>>>>>>>> +                       reg = <0xc0 0x0 0x0 0x400000>;
>>>>>>>> +               };
>>>>>>>> +
>>>>>>>> +               uart0: serial@d000307000 {
>>>>>>>> +                       compatible = "pliops,spider-uart";
>>>>>>>> +                       reg = <0xd0 0x307000 0 0x1000>;
>>>>>>>> +               };
>>>>>>>> +       };
>>>>>>>> +};
>>>>>>>> diff --git a/arch/arm/mach-spider/Kconfig b/arch/arm/mach-
>>>>> spider/Kconfig
>>>>>>> new file mode 100644 index 000000000000..6d2f888a5fd8
>>>>>>>> --- /dev/null
>>>>>>>> +++ b/arch/arm/mach-spider/Kconfig
>>>>>>>> @@ -0,0 +1,16 @@
>>>>>>>> +# SPDX-License-Identifier: GPL-2.0-only
>>>>>>>> +
>>>>>>>> +if ARCH_SPIDER
>>>>>>>> +
>>>>>>>> +config ARCH_SPIDER_MK1
>>>>>>>> +       bool
>>>>>>>> +       select CPU_V8
>>>>>>>> +       help
>>>>>>>> +         The first Cortex-A53-based SoC of the spider family.
>>>>>>>> +         This symbol is invisble and select by boards
>>>>>>>> +
>>>>>>>> +config MACH_SPIDER_MK1_EVK
>>>>>>>> +       bool "Pliops Spider Reference Design Board"
>>>>>>>> +       select ARCH_SPIDER_MK1
>>>>>>>> +
>>>>>>>> +endif
>>>>>>>> diff --git a/arch/arm/mach-spider/Makefile b/arch/arm/mach-
>>>>>>> spider/Makefile new file mode 100644 index
>>>>> 000000000000..b08c4a93ca27
>>>>>>>> --- /dev/null
>>>>>>>> +++ b/arch/arm/mach-spider/Makefile
>>>>>>>> @@ -0,0 +1 @@
>>>>>>>> +lwl-y += lowlevel.o
>>>>>>>> diff --git a/arch/arm/mach-spider/lowlevel.c b/arch/arm/mach-
>>>>>>> spider/lowlevel.c new file mode 100644 index
>>>>>>> 000000000000..5d62ef0f39e5
>>>>>>>> --- /dev/null
>>>>>>>> +++ b/arch/arm/mach-spider/lowlevel.c
>>>>>>>> @@ -0,0 +1,14 @@
>>>>>>>> +// SPDX-License-Identifier:     GPL-2.0+
>>>>>>>> +
>>>>>>>> +#include <linux/types.h>
>>>>>>>> +#include <mach/spider/lowlevel.h>
>>>>>>>> +#include <asm/barebox-arm-head.h>
>>>>>>>> +
>>>>>>>> +void spider_lowlevel_init(void)
>>>>>>>> +{
>>>>>>>> +       arm_cpu_lowlevel_init();
>>>>>>>> +       /*
>>>>>>>> +        * not yet relocated, only do writel/readl for stuff that's
>>>>>>>> +        * critical to run early. No global variables allowed.
>>>>>>>> +        */
>>>>>>>> +}
>>>>>>>> diff --git a/images/Makefile b/images/Makefile index
>>>>>>> c93f9e268978..97521e713228 100644
>>>>>>>> --- a/images/Makefile
>>>>>>>> +++ b/images/Makefile
>>>>>>>> @@ -150,6 +150,7 @@ include $(srctree)/images/Makefile.mxs
>>> include
>>>>>>> $(srctree)/images/Makefile.omap3  include
>>>>>>> $(srctree)/images/Makefile.rockchip
>>>>>>>>  include $(srctree)/images/Makefile.socfpga
>>>>>>>> +include $(srctree)/images/Makefile.spider
>>>>>>>>  include $(srctree)/images/Makefile.stm32mp
>>>>>>>>  include $(srctree)/images/Makefile.tegra  include
>>>>>>> $(srctree)/images/Makefile.versatile
>>>>>>>> diff --git a/images/Makefile.spider b/images/Makefile.spider new file
>>>>> mode
>>>>>>> 100644 index 000000000000..c32f2762df04
>>>>>>>> --- /dev/null
>>>>>>>> +++ b/images/Makefile.spider
>>>>>>>> @@ -0,0 +1,5 @@
>>>>>>>> +# SPDX-License-Identifier: GPL-2.0-only
>>>>>>>> +
>>>>>>>> +pblb-$(CONFIG_MACH_SPIDER_MK1_EVK) += start_spider_mk1_evk
>>>>>>>> +FILE_barebox-spider-mk1-evk.img = start_spider_mk1_evk.pblb
>>>>>>>> +image-$(CONFIG_MACH_SPIDER_MK1_EVK) += barebox-spider-mk1-
>>>>>>> evk.img
>>>>>>>> diff --git a/include/mach/spider/lowlevel.h
>>>>>>> b/include/mach/spider/lowlevel.h new file mode 100644 index
>>>>>>> 000000000000..6e0ce1c77f7e
>>>>>>>> --- /dev/null
>>>>>>>> +++ b/include/mach/spider/lowlevel.h
>>>>>>>> @@ -0,0 +1,7 @@
>>>>>>>> +/* SPDX-License-Identifier: GPL-2.0+ */ #ifndef __MACH_SPIDER_H_
>>>>>>>> +#define __MACH_SPIDER_H_
>>>>>>>> +
>>>>>>>> +void spider_lowlevel_init(void);
>>>>>>>> +
>>>>>>>> +#endif
>>>>>>>> --
>>>>>>>> 2.38.4
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> 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 |




  reply	other threads:[~2023-05-31 18:00 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 [this message]
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
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=fc2868f9-6b56-eefc-c0c2-24c75201f5fd@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