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
