Hello Måns,
On Sun, 30 Nov 2014, Måns Rullgård wrote:
Date: Sun, 30 Nov 2014 12:20:17 +0000
From: Måns Rullgård <mans@xxxxxxxxx>
To: peter fuerst <post@xxxxxxxx>
Cc: linux-mips@xxxxxxxxxxxxxx
Subject: Re: fast_iob() vs PHYS_OFFSET
Date: Sun, 30 Nov 2014 04:49:30 +0000 (UTC)
To: Måns Rullgård <mans@xxxxxxxxx>
Sorry for the mistake below: should be CKSEG[01], not CKSEG[12].
peter fuerst <post@xxxxxxxx> writes:
Hello,
i don't know where fast_iob() is currently defined (it used to be in
system.h in 2.6 kernels) and so don't know its current definition. But
It's in asm/barrier.h, and looks like this for non-IP28:
#define __fast_iob() \
...
: "m" (*(int *)CKSEG1) \
...
# endif
this looks as it used to look since long.
if PHYS_OFFSET appears in the definition, this may be plain wrong.
(and any conjunction of PHYS_OFFSET with CKSEG1 would be bizarre).
PHYS_OFFSET is (at least on IP28) just the physical address, where the
RAM starts, and has no righteous place in address-calculations, MIPS's
"unmapped" kernel-addresses (CKSEG[12], XKPHYS) are independent from
soldering the RAM.
CKSEG[01] map to physical addresses starting from 0 bypassing the MMU.
If there is no RAM at address 0, I wouldn't expect reading from the
first word of CKSEG1 to work very well.
On IP28, with PHYS_OFFSET 0x20000000, RAM consequently begins at the
kernel-address(es) 0xXY00000020000000. (Btw, you won't reach the RAM
with CKSEG[12] here, XKPHYS is needed)
IP28 has a special definition of __fast_iob() that reads from
CKSEG1ADDR(0x1fa00004). I have no idea what lives at that address, but
IOC2, HPC3, ...
presumably something that responds to reads in a RAM-like fashion.
My concern is over systems like AR7. It defines PHYS_OFFSET to
0x14000000 and UNCAC_BASE, correspondingly, to 0xb4000000. According to
I'm confused. Shouldn't *CAC_BASE point to the begin of an address-space?
the linux-mips wiki, there is some on-chip RAM at physical address 0,
which explains why the __fast_iob() macro works there.
I'm dealing with another chip with non-zero PHYS_OFFSET which AFAIK does
not have anything mapped at physical address 0 (I don't have data sheets).
The Evil Vendor Tree has ifdefs all over the place, most of them bizarre
and wrong, and I'm trying to clean things up a bit.
There are mailing list members, that worked a lot on AR7, perhaps they
can help you. At least provide you with data sheets.
Besides AR7, (more or less) precise definitions of *CAC_BASE, PAGE_OFFSET,
PHYS_OFFSET, ... perhaps wouldn't hurt either.
The spread of PHYS_OFFSET began several years ago with someone
introducing '#define PAGE_OFFSET (CAC_BASE + PHYS_OFFSET)' instead of
the former '#define PAGE_OFFSET CAC_BASE'.
...thus opening Pandora's can.
Perhaps just to allow retaining 'free_area_init(zones_size)' instead of
the need to replace this by 'free_area_init_node(0, NODE_DATA(0),
zones_size, PHYS_OFFSET, NULL)', since the "new" PAGE_OFFSET brings in
PHYS_OFFSET through the backdoor.
But, since kernel-addresses are (canonically ;-) calculated by adding or
subtracting PAGE_OFFSET, the new definition had/has to be compensated
for by introducing PHYS_OFFSET into macros in numerous places (maybe
by some trial-and-error actions ;-)
That was more or less the impression I got while chasing the values
through the various macro definitions.
kind regards
peter
On Fri, 28 Nov 2014, Måns Rullgård wrote:
Date: Fri, 28 Nov 2014 23:50:16 +0000
From: Måns Rullgård <mans@xxxxxxxxx>
To: linux-mips@xxxxxxxxxxxxxx
Subject: fast_iob() vs PHYS_OFFSET
I'm a little confused over the interaction between fast_iob() and
non-zero PHYS_OFFSET.
The __fast_iob() macro performs a load from CKSEG1. AFAICT, CKSEG1 is
always (on 32-bit systems) defined to 0xa0000000. In case of a non-zero
PHYS_OFFSET, this address might not map to anything in particular, and
almost certainly not RAM. There is a special case for IP28, but this is
not the only system with an unusual address map.
What am I missing?
--
Måns Rullgård
mans@xxxxxxxxx
--
Måns Rullgård
mans@xxxxxxxxx
best wishes
peter
