Issue with dcahe enabling.

[KARTHIK SEKURU]

Hi,



I'm doing kernel porting to arm926 based FPGA board, very minimal setup.

Only UART and timer devices are available as part of FPGA.





Board details –



Using ARM926e-js processor with 128MB SDRAM., Clock-33Mhz

SDRAM Size = 128M



CONFIG_PAGE_OFFSET = 0xc0000000

CONFIG_PHYS_OFFSET= 0x80000000



Kernel Lowmem = 32M including 8M for initramfs (starting from  24M to 32M).

HighMEM is not configured.



Vmalloc_start =     end address of LowMem (i.e 0xC200000)

VMALLOC_END =  Vmalloc_start + 64M  = 0xC6000000



If I enable data cache and debug with JTAG, Kernel ends up in
ENTRY(__delay).

This is due to the corruption of the “meminfo” structure.



I could also observe during step by step using trace32 , after excuting few
instructions that modifies memory(*refer label*), the data in that
particular memory is not modify.

Because of which there is corruption of the meminfo structure ending up in
looping in  “ setup_arch -->paging_init --> prepare_page_table”.



*Label:*

The instructions that should actually  modify memory, but the memory is not
modified are from parse_early_param() --> parse_early_options -->
parse_args --> next_arg -->



for (i = 0; args[i]; i++) {

                if (isspace(args[i]) && !in_quote)

                        break;

                if (equals == 0) {

                        if (args[i] == '=')

                                equals = i;

                }

                if (args[i] == '"')

                        in_quote = !in_quote;

        }



        *param = args;

        if (!equals)

                *val = NULL;

        else {

                args[equals] = '\0';





which modifies the command line args passed. The instruction that sets the
‘=’ location to ‘NULL’ as highlighted is not modifying the memory .



Please let me know how dcahe enabling is creating this effect.,as with
dcache disabled(CPU_DCACHE_DISABLE = y)  this instruction is replacing the
‘=’ symbol with NULL.



 Karthik.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20120327/73f3ac91/attachment.html