14:12 <deathcamel57> I'm working on a linux port for a niche SoC that's not supported. I'm struggling to get my IRQ chip initialized. `irqchip_init` is called on a `arm,pl390` compatible GIC, even though I have the GIC in the DTSI set as compatible with `arm,cortex-a9-gic`. I have `CONFIG_ARM_GIC` set as well. Any pointers on where I can look to figure out why it's not initializing my GIC?

14:30 <geertu> deathcamel57: arm,cortex-a9-gic or arm,pl390 shouldn't matter much, as all GICs are initialized using the same entry point gic_of_init()

14:36 <deathcamel57> geertu: Changing the compatible string to `arm,pl390` results in `of_irq_init` looking for a compatible string `arm,pl390`, but the `for_each_matching_node_and_match` isn't finding it for some reason.

14:56 <maz> deathcamel57: please post your DTS somewhere so that we can have a look.

14:57 <deathcamel57> maz: https://pastebin.com/K5nwUgp1 It's a total mess, it's my first time trying to port linux. Lines 35-44 are GIC.

14:58 <maz> looks OK to me. not sure what you mean about `for_each_matching_node_and_match`, as there is no such code in the GIC driver.

14:59 <maz> ah no, you

15:00 <maz> ah no, you're on about irqchip_init()

15:01 <deathcamel57> So I added a bunch of debugging messages. `init_IRQ` -> `irqchip_init` -> `of_irq_init`. `of_irq_init` has a `for_each_matching_node_and_match` that I'm pretty sure is supposed to scan for matching GICs. However, it's not finding any, and completely skips the `for_each_matching_node_and_match` section.

15:06 <geertu> deathcamel57: If you want to be sure about the exact tGIC type, you can read the GIC_DIST_IIDR address at offset 8 from e.g. U-Boot

15:07 <mrutland> Are you sure that kernel's getting the right DT?

15:09 <mrutland> If it's not getting into the body of for_each_matching_node_and_match(), then either there's no matching node in the DT, or the match table is messed up somehow

15:13 <deathcamel57> I'm using this in U-Boot to load in the DTB from a flash drive `fatload usb 0 0x82000000 uImage; fatload usb 0 0x83000000 hi3520dv200-demb.dtb;bootm 0x82000000 - 0x83000000`. The `DT_MACHINE_START`->`.dt_compat` contains `hisilicon,hi3520dv200-demb` and my DTS for the board contains that string as well. Is there anything else I should look into to see if the DTB is the right one?

15:24 <deathcamel57> `setup_machine_fdt` returns `NULL` due to `if (!dt_virt || !early_init_dt_verify(dt_virt))` being true. So maybe my device tree isn't loading?

15:32 <mrutland> That's possible, or the DTB might be too close to the kernel and be getting clobbered during boot?

15:33 <mrutland> Either way, the kernel isn't finding a valid DTB

15:37 <deathcamel57> Moving the kernel address to earlier in memory has the same issue. Is the command I'm using in U-Boot accurate to load in the uImage and DTB, then boot the kernel properly?

16:04 <geertu> deathcamel57: hat if you move the DTB to 0x81000000?

16:04 <geertu> s/hat/what/

16:06 <deathcamel57> Unfortunately `fdt_check_early_init_dt_verify` still returns false because `fdt_check_header` does

16:09 <deathcamel57> Kind of confused, since inspecting `0x81000000` after loading it from USB, that address does contain the DTB. However when starting the kernel with `bootm 0x83000000 - 0x81000000`, the kernel can't find it.

16:47 <deathcamel57> So I think I'm getting closer. `fdt_check_header` gives `FDT_ERR_BADMAGIC`. My device stores the data in little endian, and I think the kernel is loading the DTB in the wrong endian? Doing a memory inspect, I can see that memory holds `0xedfe0dd0`, whereas linux is expecting `0xd00dfeed`. How can I go about swapping the endian that the kernel is looking for?

17:00 <silurian_invader> deathcamel57: devicetree is always big-endian; if you have a little-endian machine the above is correct, since the kernel will automatically perform byte-swapping as necessary