00:04 <MahNaz> I didn't find anything there

00:04 <MahNaz> I guess there should be somewhere in the reference manual

00:07 <MahNaz> isn't that right?

00:14 <MahNaz> liquidAcid I guess the interrupt numbers are different for various SoCs

06:40 <sjoerd> MahNaz: they're described in device-tree

06:40 <sjoerd> MahNaz: what specifically are yo looking for

06:52 <javier__> indy: these are the commands I use to create a FIT image for u-boot http://pastebin.com/raw.php?i=CqTdMBup

06:53 <javier__> MahNaz: as sjoerd said in the DTS there are the HW IRQ numbers but the kernel uses a single virtual IRQ number space

06:55 <javier__> MahNaz: so for example a GPIO-IRQ and a real IRQ from the GIC will be mapped to the same virtual IRQ space

06:55 <javier__> you only see the virtua IRQ number in /proc/interrupts

06:56 <javier__> MahNaz: but the question is as sjoerd said, what are you looking for

07:25 <indy> javier__, thanks

07:27 <javier__> indy: yw

07:34 <indy> javier__, why i can't load and boot uboot.img directly? like kernel?

07:35 <sjoerd> you can

07:35 <sjoerd> but the factory u-boot will only load signed fit images

07:36 <javier__> indy: what sjoerd said, the verified boot only loads a binary that can be trusted

07:37 <indy> sjoerd, javier__ i do not have factory u-boot in spi :)

07:37 <sjoerd> Well then you can do whatever you want :p

07:38 <javier__> well, it depends which binary was flashed there

07:39 <javier__> indy: so why do you want to chain load a u-boot then? why not boot a kernel directly?

07:40 <indy> javier__, because that misterious archlinux uboot doesn't boot upstream kernel

07:41 <javier__> indy: ok, then replace factory u-boot on my previous sentence to "a u-boot that only can boot verified images"

07:41 <javier__> which seems to be the case of your archlinux u-boot

07:46 <indy> javier__, sjoerd must be that signed partition first one on mmc/sdcard? or can i put it at the end?

07:48 <javier__> indy: you can put in whatever partition you want as long as is the gpt partition with the highest priority

07:48 <javier__> use cgpt to change that

07:48 <indy> javier__, sjoerd that uboot can boot fit image from chromeos, so why not use same workflow for generation uboot.img? i saw some fit related articles for signing binaries inside

07:49 <sjoerd> it is the same workflow....

08:02 <javier__> indy: sorry, I didn't understand your last comment

08:03 <javier__> in both cases you sign the binary, it only that in one case is a FIT with a kernel image and in the other one is an u-boot binary

08:09 <indy> \o/

08:09 <indy> ext2load mmc 0:1 $ubotaddr u-boot-dtb.bin; go $ubootaddr

08:09 <indy> all the time i tried to load it as kernel image

08:10 <sjoerd> oh you were trying to bootz/bootm it?

08:10 <indy> yes

08:10 <indy> instead of go

08:10 <indy> as for uboot application

08:11 <sjoerd> Ah right yes, bootm and bootz try to parse a legacy u-boot image or a vmlinuz image respectively

13:00 <indy> hmm

13:01 <indy> seems spl needs to be loaded too

17:10 <MahNaz> sjoerd, javier__, in fact I'm looking for arm-pmu interrupts, but they are not available in the device tree of any of the devices that utilize Exynos5420, Exynos5422, or Exynos5800

17:11 <MahNaz> I should have the IRQ numbers to be able to add the arm-pmu to the device tree