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

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

Hi Lior,

On 25.06.23 22:33, Lior Weintraub wrote:
> Hello Ahmad,

[Sorry for the delay, we're at EOSS 2023 currently]
 
> I failed to reproduce this issue on virt because the addresses and peripherals on virt machine are different and it is difficult to change our code to match that.
> If you think this is critical I will make extra effort to make it work.
> AFAIU, this suggestion was made to debug the "conflict" issue.

It's not critical, but I'd have liked to understand this, so I can check
if it's perhaps a barebox bug.

> Currently the workaround I am using is just to set the size of the kernel partition to match the exact size of the "Image" file.
> 
> The other issue I am facing is that Kernel seems stuck on cpu_do_idle and there is no login prompt from the kernel.

Does it call into PSCI during idle?

> As you recall, I am running on a custom QEMU that tries to emulate our platform.
> I suspect that I did something wrong with the GICv3 and Timers connectivity.
> The code I used was based on examples I saw on sbsa-ref.c and virt.c.
> In addition, I declared the GICv3 and timers on our device tree.
> 
> I running QEMU with "-d int" so I am also getting trace of exceptions and interrupts.

Nice. Didn't know about this option.

[snip]

> Exception return from AArch64 EL3 to AArch64 EL1 PC 0xffffffc00802112c
> Taking exception 13 [Secure Monitor Call] on CPU 0
> ...from EL1 to EL3
> ...with ESR 0x17/0x5e000000
> ...with ELR 0xffffffc008021640
> ...to EL3 PC 0x10005400 PSTATE 0x3cd
> Exception return from AArch64 EL3 to AArch64 EL1 PC 0xffffffc008021640

Looks fine so far? Doesn't look like it's hanging in EL1.

[snip]

> Segment Routing with IPv6
> In-situ OAM (IOAM) with IPv6
> sit: IPv6, IPv4 and MPLS over IPv4 tunneling driver
> NET: Registered PF_PACKET protocol family
> NET: Registered PF_KEY protocol family
> NET: Registered PF_VSOCK protocol family
> registered taskstats version 1
> clk: Disabling unused clocks
> Freeing unused kernel memory: 1664K

Not sure. Normally, I'd try again with pd_ignore_unused clk_ignore_unused in the
kernel arguments, but I think you define no clocks or power domains yet in the DT?

You can try again with kernel command line option initcall_debug and see what the
initcall is that is getting stuck. If nothing helps, maybe attach a hardware debugger?

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 |