Remap UART physical address through simple-bus ranges

[bsz_semihalf.com]

Summary

Kernel console init routine mapped the physical address of UART using only
the 'ranges' property of its immediate parent. However, further parents
may also have address space mappings and they need to be taken into account
to calculate the final physical base address of UART registers.

This commit adds a translation routine similar to
simplebus_alloc_resource() which remaps the address through all simple-bus
parents of the UART node.

NOTE: buffers for ranges data are placed on the stack as malloc cannot be used so early in the kernel.

Obtained from: Semihalf
Sponsored by: Stormshield
Submitted by: Michal Stanek <[e-mail]>

[imp]

I'd think we'd want this mapping in simplebus itself, or at the very least this function.

sys/dev/uart/uart_cpu_fdt.c

250

Why is this in uart? Isn't this a more generic problem with cascaded simple-bus
typologies?

[bsz_semihalf.com]

Function moved to simplebus' code.

[bsz_semihalf.com]

sys/dev/uart/uart_cpu_fdt.c

243–347

imp, please let me know if updated diff looks fine to you, so we can commit the patch series.

[andrew]

Why doesn't fdt_get_ranges work? It should already walk up the tree.

[andrew]

In D4217#94426, @andrew wrote:

Why doesn't fdt_get_ranges work?

This should say: Why doesn't fdt_get_range work?
i.e. the no trailing s.

[• ian]

In D4217#95770, @andrew wrote:

In D4217#94426, @andrew wrote:

Why doesn't fdt_get_ranges work?

This should say: Why doesn't fdt_get_range work?
i.e. the no trailing s.

After spending some time digging through the various code we have that tries to process ranges properties (existing implementations fdt_reg_to_rl(), fdt_get_range(), fdt_get_range_by_busaddr(), and their callers) it looks like this new simplebus_get_base_addr() is the only implementation that actually does it correctly. The only problem I'm seeing with it is that the operation is not really specific to simplebus -- according to ePAPR any node that has children can have a ranges property.

I think it's probably not fair to ask semihalf to drain this whole swamp (now that it has become clear that we are standing in the middle of a swamp) before committing this fix.

We could let this be committed as-is, and then come along later and refactor it to be less simplebus-specific and clean up all the callers of the old routines at that time. It might make sense to do that after D4544 expands the size of rman-managed data using a new typedef, then we can redefine this fdt stuff that works with address resources in terms of that datatype.

[imp]

While I'd prefer that we fix the underlying issue, I'm happy to go along with Ian's suggestion.

[nwhitehorn]

This is not a simplebus-specific thing. What should happen is something like OF_decode_addr() in /sys/powerpc/ofw/ofw_machdep.c (or exactly that function). In simplebus, the resource decoding using newbus allocation cascading to achieve this. Early boot (for UARTs) has different requirements and needs addresses cascaded all the way to CPU space. OF_decode_addr() is mostly not MD and I think would work as-is on ARM. You can see how it is used in uart_cpu_powerpc.c.

[• ian]

After talking with Nathan about this on irc, I extracted the MI parts of the powerpc OF_decode_addr() to a new common subroutine, then used that to implement OF_decode_addr() on arm. That should now be the correct way to do the translation of the reg to a bus_space tag and handle.

That change is in D4664.

[• ian]

Now that OF_decode_addr() works on all fdt/ofw platforms (after r292579), it's the right way to set up early console access. Unfortunately, even though phabricator is supposed to be a collaboration tool, I can't update the diff attached to this revision, so I created a new revision D4675 to replace this one.

[bsz_semihalf.com]

Abandoned because D4675 replaces it.