#11830: Remove more constants from common_runtime_address_map

[blozano-tt]

Ticket

#11830

Problem description

See issue

What's changed

MEM_MAP_END moved behind Hal
L1_KERNEL_CONFIG_BASE/SIZE is already behind the HAL, remove it from common_runtime_address_map

Checklist

https://github.com/tenstorrent/tt-metal/actions/runs/11337042262

• Post commit CI passes
• Blackhole Post commit (if applicable)
• Model regression CI testing passes (if applicable)
• Device performance regression CI testing passes (if applicable)
• New/Existing tests provide coverage for changes

[abhullar-tt]

The idea with moving L1_KERNEL_CONFIG is that it shouldn't belong in the HAL because it is a host side concept.

HalL1MemAddrType::UNRESERVED should point to MEM_MAP_END (we could rename UNRESERVED to MEMORY_MAP_END) to be more clear.

The original idea was to create a L1 Buffer (that is allocated bottom up) to hold the kernel config and users of HalL1MemAddrType::KERNEL_CONFIG would query device to get the kernel config buffer address. This won't work for ethernet cores because our allocator does not allocate buffers on ethernet cores.

To handle all programmable core types in the same manner, Device could reserve space for kernel config on all programmable core types and then update l1_unreserved_base that is passed into AllocatorConfig to follow kernel config

[blozano-tt]

The idea with moving L1_KERNEL_CONFIG is that it shouldn't belong in the HAL because it is a host side concept.

Can we file a separate issue to track this as an enhancement? Today it is behind Hal, and this PR just leaves it there.

HalL1MemAddrType::UNRESERVED should point to MEM_MAP_END

Currently UNRESERVED is being set differently depending on core type.
I don't see it being set to the equivalent of MEM_MAP_END anywhere, for instance I see this:
((L1_KERNEL_CONFIG_BASE + L1_KERNEL_CONFIG_SIZE - 1) | (max_alignment - 1)) + 1;

Maybe I don't have the necessary background to make this change.