facing trouble with virtual address mapping in linux kernel porting!
 

Hi,

I am a beginner in kernel porting. I am trying to port Linux kernel (version- 4.9.22) on Custom SoC (cpu = arm1176jzfs based) for custom evaluation Board.I am currently using Raspberry Pi Kernel version 4.9.22.

I am facing issues with my virtual address map. The DDR(256MByte) in my Custom Eval. Board is physically mapped from 0xC000_0000 to 0xCFFF_FFFF. And currently my PHYS_OFFSET & PAGE_OFFSET are configured as 0xC000_0000 & 0xC000_0000. when I am trying to initialize my VIC driver (where VIC is physically mapped at 0x4800_0000 in my custom SoC), kernel booting fails by showing up the following log:


[ 0.000000] Unable to handle kernel paging request at virtual address 48000fe0
[ 0.000000] pgd = c0004000
[ 0.000000] [48000fe0] *pgd=00000000
[ 0.000000] Internal error: Oops: 5 [#1] ARM
[ 0.000000] Modules linked in:
[ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 4.9.22+ #69

........
Any suggestions on this issue? or any suggestions configuring user and kernel space split?

Thanks,
Vivek T.

So, a Custom SoC - some @£&€%$! big fpga with an arm core in there. I take it you're in hardware design. The kernel obviously doesn't like the address 0x48000fe0, or 0x48000000 although it's in range. I would explain exactly what you mean by 'physically mapped.' That would usually be high address lines being control or /CS, and lower ones the actual address bus. I'd verify timings, in case your /CS takes several clock cycles, or something off the wall like that.

I'd look at getting the physical addresses lower, in case there's some upper limit in the kernel neither of us know about. The original IBM pc design seemed designed to get the LEAST out of the hardware: The 8088 was a 16 bit cpu with an 8 bit data bus; The 8086 had a 20 bit address bus, but only 16 bit registers, so paging registers were added to address the top 4 lines; Everything later suffered under the curse of backward compatibility. Nobody had the foresight to imagine Gigs of memory, or Terabytes of hard disk. 640k was all the imagination they had.

A discreet email to the module maintainer or query on the LKML (Linux Kernel Mailing List) may point you at sensible regions to try. Ditto for the VIC driver (Whassat anyhow?). I never crossed those particular bridges in my own hardware days.

Things like the Raspberry Pi and many poser phones and tablets are out there running arm kernels with memory. Can't you get some ideas there?

But, to their credit, it was also all the silicon they had. I'm told that there were concerns that the 80386 designs wouldn't fit on the available chip space, or that usable-yields would be unprofitably low. ("Wider buses" are, well, wider!) As it was, the math coprocessor was originally external. The constraints of those days were very physical. All of the magical densities and speeds that we now enjoy originate from incredible advances in chip-fab technology.

Yes Yes, we have gone from 2uM to 14nM in wafer fab, and it's probably gone smaller now. They will get down to about 5nM. But they hamstrung and spanceled the original pc hardware, largely through lack of foresight. Then they ran it at 4.77 Mhz; There were Z80s going faster. That matters, because the kernel was designed to run on one ropey hardware design, and the OP is porting it to another (His own).

I was familiar with the silicon of the time. There was 1.2uM or smaller available. Most compatibles ran at least 8 Mhz. Chips of the time were good for about 10 Mhz, but the current demands were extraordinary, the boards were too big, needless extra ISA sockets complicated 'worst case' analysis, resulting in low value pullups and doubtful levels at the wrong end of long pcb traces. The stray capacitance was huge, and design techniques of the day allowed glitches all over the place. So boards were throttled back to avoid a bad company reputation. Today with more silicon, glitches are all but gone.

Hi ,

The issue got resolved after incorporating a small piece of code. The issue is related to address translation fault. it is something like to obtain a virtual address using ioremap() function. That virtual address was given vic_init() function. Looks like the VIC is initialized and I am able to observe peripheral id while booting.