RE: Follow up on 4 Gig of DDR on MPC8548E
>> apparently after more investigations - it looks like there is something in >> the ext2 driver code >> that is mal-adjustedI haven't talked to the guy today who was looking at >> that - but the ext2 >> driver code that was openning a 'virtual file' / console - had some problems >> mapping that >> space - again, my gut is telling me more stronger there is a problem with >> signed/unsigned... >> now deeper in the ext2 code... > I very much doubt there is a signed/unsigned issue in ext2 or elsewhere... > > You have CONFIG_HIGHMEM ? What are your setting for KERNELBASE and > PAGE_OFFSET ? Ben, I am sorry it I alluded to ext2 code itself having a signed/unsigned problem - just that the problem was manifesting itself inside the ext2 code in a very strange way ...with something that I guessed below it that was violating a signed/unsigned API and I was wrong with this hunch (gotta check my hunch meter)... It was a nuance in the configuration of inbound windows for PCI/PEX that was dribbling onto the memory that was consistently being i/o mapped to the ext2 driver - which then got confused and bailed completely. We now have it working as we want it to with all 4 GIG of DDR working as we want it. Thank you for pushing us to push through the hunch and get to the root cause. It was a tough one to find. Tom ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
RE: Follow up on 4 Gig of DDR on MPC8548E
> apparently after more investigations - it looks like there is something in > the ext2 driver code > that is mal-adjustedI haven't talked to the guy today who was looking at > that - but the ext2 > driver code that was openning a 'virtual file' / console - had some problems > mapping that > space - again, my gut is telling me more stronger there is a problem with > signed/unsigned... > now deeper in the ext2 code... I very much doubt there is a signed/unsigned issue in ext2 or elsewhere... You have CONFIG_HIGHMEM ? What are your setting for KERNELBASE and PAGE_OFFSET ? Ben. ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
RE: Follow up on 4 Gig of DDR on MPC8548E
>> 0x_ to 0x_ or do you have 64GB of mem... 4 GIG DDR Memory...that we say...there is 3 GIG for the moment... the LAW's are setup in priority order - thus, if you have overlapping regions (aka: PCI & DDR memory) the one with the lower #'d LAW is the one it is mapped to >> If you have all physical mem in the first 32bit, where are your PCI >> windows set? >> And in modst cases the PCI devices (if they are bus-mastring ) need 1-1 >> inbound mapping to be able to write to memory. you can use the LAW's to remap anything to anywhere... see above for priority - but in our case, we are mapping the PCI/PEX/Local Bus to the last 4 GIG at a higher priority LAW than the DDR...that is what the MPC8548 spec says how it works...and it does - if you don't tell the kernel there is more than 2GIG (and ioremap that last GIG to access the full 'other' 2 GIG... that is not the issue here apparently after more investigations - it looks like there is something in the ext2 driver code that is mal-adjustedI haven't talked to the guy today who was looking at that - but the ext2 driver code that was openning a 'virtual file' / console - had some problems mapping that space - again, my gut is telling me more stronger there is a problem with signed/unsigned... now deeper in the ext2 code... Am at the Freescale Technical Forum the next few days - if any of you guys are down here in Florida...I am intending to track down a few freescale folk on this issue...:-) Tom ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
RE: Follow up on 4 Gig of DDR on MPC8548E
> From: Morrison, Tom > Sent: Friday, June 22, 2007 12:50 PM > Setup: >1) 4 Gig of DDR RAM (at physical addresses 0-0xF__) 0x_ to 0x_ or do you have 64GB of mem... > >> EXT2-fs warning: mounting unchecked fs, running e2fsck is > recommended > >> VFS: Mounted root (ext2 filesystem). > >> 316k init > >> EXT2-fs error (device sda1): ext2_check_page: bad entry in > directory > #2: >> unaligned directory entry - offset=0, inode=128, > rec_len=8961,name_len=69 > >> Warning: unable to open an initial console. > My gut tells me this might be something to do with the 2 > Gig boundary and specifically a "signed" versus "unsigned" > address/offsets mismatch maybe somewhere in the file system?? If you have all physical mem in the first 32bit, where are your PCI windows set? And in modst cases the PCI devices (if they are bus-mastring ) need 1-1 inbound mapping to be able to write to memory. ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
