Thank you very much, that clears things up a lot.
Thanks,
Caleb
On 04/04/2023 05:33, Florian Fainelli wrote:
On 4/3/2023 7:00 AM, Caleb James DeLisle wrote:
Hello folks,
I've been working on trying to port an en7526 and in doing so I'm trying to learn how to at least
partially write a DTS file from an old style header full of #defines.
I ran into a bit of a quandry, I'm comparing the mt7621.dtsi file to an older MT7621 memory map
header:
https://github.com/openwrt/openwrt/blob/master/target/linux/ramips/dts/mt7621.dtsi#L100
https://github.com/keenetic/kernel-49/blob/master/arch/mips/include/asm/rt2880/rt_mmap.h#L48
```
palmbus: palmbus@1e000000 {
compatible = "palmbus";
reg = <0x1e000000 0x100000>;
ranges = <0x0 0x1e000000 0x0fffff>;
[...]
i2c: i2c@900 {
compatible = "mediatek,mt7621-i2c";
reg = <0x900 0x100>;
```
For me, means there should be an I2C controller mapped at address 0x1e000900.
Correct.
But looking at rt_mmap.h I see:
```
#define RALINK_I2C_BASE 0xBE000900
```
And in fact almost everything is based on 0xBE000000, except UART and USB addresses which are
"correct". And I see these 0xBE000000 addresses being passed through KSEG1ADDR() so it seems they
are physical memory addresses, not virtual.
KSEG1ADDR does a logical or so it would not be altering RALINK_I2C_BASE when OR'd with 0xa0000000
(KSEG1) you would still get 0xBE000900.
It seems to me like in places where it may be necessary to pass a physical address they used
physical addresses such that ioremap() ends-up returning a proper kernel virtual address in KSEG1,
however everywhere else the driver might have just directly de-referenced the constant which ends-up
working just fine as well.
HTH
_______________________________________________
openwrt-devel mailing list
[email protected]
https://lists.openwrt.org/mailman/listinfo/openwrt-devel