LOGIN   :::   RECOVER PASS   :::   GET ACCOUNT    
Browse
  • Projects
  • Code (CVS)
  • Forums
  • News
  • Articles
  • Polls
  •  
    OpenCores
  • FAQ
  • CVS HowTo
  • Mission
  • Media
  • Tools
  • Advertise
  • Mirrors
  • Logos
  • Contact us
  • Find Resources
  • Job Opportunity
  •  
    Tools
  • Search
      
  • Download Cores (CVSGet)
  •  
    More
  • Wishbone
  • Perlilog
  • EDA tools
  • OpenTech CD
  •  
    Navigation: All forums > Openrisc > Message List > Message Post

    Message

    Reply | Reply all
    Date Prev | Date Next | Thread Prev | Thread Next Date Index | Thread Index

    From: rich_daddio at yahoo.com<rich_daddio@y...>
    Date: Mon Mar 10 16:40:29 CET 2008
    Subject: [openrisc] ITLB miss occurs on returning from handler in 2.6.19
    Top
    Hi James,
    Do you have any more information about this? Have you tried any of the
    older images(2.6.17 or 2.6.18)? Please feel free to contact me off
    list if need be.

    Best Regards,

    Rich d

    ----- Original Message -----
    From: James Cotton<peabody124@g...>
    To:
    Date: Wed Feb 27 04:11:07 CET 2008
    Subject: [openrisc] ITLB miss occurs on returning from handler in
    2.6.19

    > I'm trying to run the RGD linux-2.6.19 patches on a 2.6.19.7 on a
    > spartan 3e starter kit out of the DDR ram. I use jtag to load the
    > code straight into ram, so I modified the vmlinux.ld.S file to have
    > a
    > load base of 0xc0000000 and a load offset of -0x40000000. The
    > kernel
    > runs fine in or1ksim (although there are some issues when you set
    > the
    > clock rate < 10 MHz in the kernel that causes the simulator to
    > hang,
    > so I'm using it compiled at 50MHz with the UART at 96000 baud to
    > fake
    > it out). However in the FPGA it gets through the "Ok, booting
    > the
    > kernel", through the clear bss, enable ic and dc (They are not
    > enabled, but are in silicon), the flush tlb section, but when it
    > enables the IMMU it immediately jumps to 0xA00 (the ITLB miss,
    > which
    > makes sense). That interrupt calls jump to ~0x4300 range, and it
    > goes
    > through all the page setup fine. The EPCR is 0x2144 which is where
    > the exception occurred. However when it calls the l.rte (return
    > from
    > exception) it goes to 0xa04 again and then bounces back into the
    > interrupt. However, this time the EPCR gets set to 0x43f4 (where
    > the
    > l.rte is) and I'm stuck in an infinite loop of returning back to
    > that
    > location.
    > My guess is somehow the table pointing to the low range is not set
    > up
    > correctly, so trying to jump back to the code triggers another
    > exception. Any ideas? Has anyone tested 2.6.19 in silicon (or could
    > they send me a link to a working 2.6 kernel?). My or1200 tree is
    > the
    > same as the cvs, and I don't think there is anything stupid in the
    > defines. I'd love to get this working and put it on the web since
    > the
    > s3esk is so cheap.
    >
    >

     
    Copyright (c) 1999 OPENCORES.ORG. All rights reserved.