LinuxQuestions.org
Review your favorite Linux distribution.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Newbie
User Name
Password
Linux - Newbie This Linux forum is for members that are new to Linux.
Just starting out and have a question? If it is not in the man pages or the how-to's this is the place!

Notices


Reply
  Search this Thread
Old 08-24-2017, 07:28 AM   #1
vivek thullimalli
LQ Newbie
 
Registered: Aug 2017
Posts: 5

Rep: Reputation: Disabled
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.
 
Old 08-24-2017, 10:08 AM   #2
business_kid
LQ Guru
 
Registered: Jan 2006
Location: Ireland
Distribution: Slackware, RPi OS, Mint & Android
Posts: 13,016

Rep: Reputation: 1732Reputation: 1732Reputation: 1732Reputation: 1732Reputation: 1732Reputation: 1732Reputation: 1732Reputation: 1732Reputation: 1732Reputation: 1732Reputation: 1732
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?
 
Old 08-24-2017, 10:49 AM   #3
sundialsvcs
LQ Guru
 
Registered: Feb 2004
Location: SE Tennessee, USA
Distribution: Gentoo, LFS
Posts: 9,240
Blog Entries: 4

Rep: Reputation: 3263Reputation: 3263Reputation: 3263Reputation: 3263Reputation: 3263Reputation: 3263Reputation: 3263Reputation: 3263Reputation: 3263Reputation: 3263Reputation: 3263
Quote:
Originally Posted by business_kid View Post
Nobody had the foresight to imagine Gigs of memory, or Terabytes of hard disk. 640k was all the imagination they had.
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.

Last edited by sundialsvcs; 08-24-2017 at 10:51 AM.
 
Old 08-24-2017, 11:44 AM   #4
business_kid
LQ Guru
 
Registered: Jan 2006
Location: Ireland
Distribution: Slackware, RPi OS, Mint & Android
Posts: 13,016

Rep: Reputation: 1732Reputation: 1732Reputation: 1732Reputation: 1732Reputation: 1732Reputation: 1732Reputation: 1732Reputation: 1732Reputation: 1732Reputation: 1732Reputation: 1732
Quote:
Originally Posted by sundialsvcs View Post
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.
 
Old 08-26-2017, 11:49 AM   #5
vivek thullimalli
LQ Newbie
 
Registered: Aug 2017
Posts: 5

Original Poster
Rep: Reputation: Disabled
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.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
Virtual IRQ mapping in Linux kernel 4.6.0 zephyr93 Linux - Kernel 1 05-24-2017 09:38 AM
Mapping Kernel virtual address space to Physical memory zones (ZONE_DMA, ZONE_NORMAL) kumart Linux - Newbie 2 04-03-2012 09:11 AM
Find virtual to physical address mapping in Kernel? bkankru Linux - Kernel 2 11-09-2009 02:15 PM
API for mapping Physical Address to Virtual Address Lakshman_smt Linux - Software 2 10-15-2006 09:08 PM
Memory Mapping (same physical address = virtual address) skd.tech Linux - Kernel 7 07-24-2006 11:13 PM

LinuxQuestions.org > Forums > Linux Forums > Linux - Newbie

All times are GMT -5. The time now is 05:10 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration