Hi Stefan, Thanks for looking at this.
I've been using that TRM in my efforts and using the 0x1000 and 0x2000 for the distributor and the cpu interface registers. I know they are correct and my base is correct as I can md in u-boot and see the non-zero initialized register values at the locations indicated in the ARM documentation.
I'm now back looking at the placement new operator functioning as my debugging leads me to the Pic constructor call in that operator as the location of the failure. Strangely, creating an instance of the Pic class locally works correctly....in the goodness of time I will figure it out!
Bob
Get Outlook for Androidhttps://aka.ms/ghei36
From: Stefan Kalkowski <stefan.kalkowski@...1...> Sent: Thursday, October 19, 2017 11:30:23 AM To: genode-main@lists.sourceforge.net Subject: Re: Base-hw kernel GIC issue with a Cortex--A7 processor.
Hi Bob,
I wonder whether your problem has to do with a different memory map of the GIC. When looking at the documentation for Cortex A9 and A7, I could see they differ with respect to the offset of distributor and core-specific interface of the GIC within the cpu local private memory.
Please, introduce a new Hw::Cortex_a7_mmio structure analogue to the already existent Hw::Cortex_a9_mmio and Hw::Cortex_a15_mmio variants. You can find the right values for the A7 specific IRQ_CONTROLLER_DISTR_BASE and IRQ_CONTROLLER_CPU_BASE here (page 180):
http://infocenter.arm.com/help/topic/com.arm.doc.ddi0464d/DDI0464D_cortex_a7...
Of course, you'll need to replace the occurrences of Cortex_a9_mmio in your board.h file(s).
I hope it will help you.
Regards Stefan
On 10/16/2017 03:18 PM, Bob Stewart wrote:
Thanks for the reply, Martin. Comments in-line:
On 10/12/2017 07:12 AM, Martin Stein wrote:
Hi Bob,
Am 12.10.2017 um 01:33 schrieb Bob Stewart:
A big oops by me Martin on the register declarations. I had forgotten the bitfield format was a position a followed by length type as opposed to start and end bit positions.
This is why I wrote you an explanation of the Bitfield interface two emails ago :-)
Thanks for defining the steps in start up which I was a bit familiar with through reading code. I only had time today to debug the core_mmio translation table which had the expected physical addresses based on the initialization list for the platform board object. The virtual addresses started at 0xxF0000000. I'll next figure out why a Pic object can be successfully constructed during the bootstrap where the physical addresses for the distributor and the cpu interface are used in the initialization list but the construction appears to fail in kernel init when a singleton version of it is created using virtual addresses in the initialization list.
You said that you do not even enter the constructor but are you sure you don't enter the first initializer in the initializer list or have you only checked whether you enter the constructor body?
It is dying in the Initializers. It never gets to the body of the constructor.
I assume that there are several initializers like the distributer and CPU interface MMIO like in our ARM-GIC implementation:
Hw::Pic::Pic() :
_distr(Platform::mmio_to_virt(Board::Cpu_mmio::IRQ_CONTROLLER_DISTR_BASE)),
_cpui(Platform::mmio_to_virt(Board::Cpu_mmio::IRQ_CONTROLLER_CPU_BASE)), _last_iar(Cpu_interface::Iar::Irq_id::bits(spurious_id)), _max_irq(_distr.max_irq()) { }
I'm using core/spec/arm_gic (and therefore the Hw::Pic in lib/hw/spec/arm as the base class). So the only difference between this implementation and the Cortex A9 implementation is what the values are for IRQ_CONTROLLER_DISTR_BASE and IRQ_CONTROLLER_CPU_BASE. In kernel's init.cc I created a local object for Pic and used that to pass to the cpu init method instead of the reference to the unmanaged singleton object. When I did that the kernel init completed successfully and the log code was executed and completed with the expected results. This would indicate that the Pic object is correctly constructed, would it not.
Then, you could print '_base' in the 'Mmio_plain_access' constructor [1] for debugging. If you truely do not enter the first initializer your problem is most likely not related to any PIC IO mappings. I would suggest you to aim for the exact point where your system gets stuck.
For the first initializer, for the distributor object, base() returns 0x0. This would indicate that a Pic object was not being constructed correctly in the placement new operator, which is hard to imagine why. I will go over my core make files again to see if I've got an incorrect include path specified or specified an incorrect location for a source file. Beyond that?
Bob
Cheers, Martin
[1] base/include/util/mmio.h
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
-- Stefan Kalkowski Genode Labs
https://github.com/skalk · http://genode.org/
------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main