[Linux-Xtensa] Re: [patch 0/8] xtensa: s6000 & s6105 - Git Repo Pulled; will try to merge early next week and get back to ya.

linux-xtensa at linux-xtensa.org linux-xtensa at linux-xtensa.org
Tue Mar 31 05:44:27 PDT 2009

On Tue, Mar 31, 2009 at 03:15:50AM -0700, Piet Delaney wrote:

> I'm currently getting a problem with your memory Zone changes;
> getting an exception went it's cleared.
> #0                memset () at arch/xtensa/lib/memset.S:46
> #1  0xd02b392d in init_bootmem_core (bdata=0xd02c03b8, mapstart=0x0, 
> start=0x0, end=0x4000) at mm/bootmem.c:108
> #2  0xd02b398a in init_bootmem_node (pgdat=0xd02921e0, freepfn=0x0, 
> startpfn=0x0, endpfn=0x4000) at mm/bootmem.c:128
> #3  0xd02b1e20 in bootmem_init () at arch/xtensa/mm/init.c:162
> #4  0xd02b1846 in setup_arch (cmdline_p=0xd02adfd0) at 
> arch/xtensa/kernel/setup.c:462
> #5  0xd02b0a09 in start_kernel () at init/main.c:559
> #6  0xd0001111 in _startup () at arch/xtensa/kernel/head.S:284
>   The area in 1st page can't be cleared on a platform with a full MMU.
> Problem was bit nasty to uncover due to the dispatch table not having been 
> set up yet;
> something I'd really like fix.

I don't see a connection to the zone changes.  This misbehaviour
occurs long before the buddy allocator is activated.  This is a
problem of how bootmem is configured.

> Joe Taylor deferred the initialization of the
> exception dispatch table while makeing it per_cpu.
> (gdb) print *bdata
> $49 = {
>   node_min_pfn = 0x0,
>   node_low_pfn = 0x4000,
>   node_bootmem_map = 0x0,
>   last_end_off = 0x0,
>   hint_idx = 0x0,
>   list = {
>     next = 0x0,
>     prev = 0x0
>   }
> }

This comes from data points in the sysmem structure.  They obviously
tell that RAM is usable from PFN zero.  Look at how min_low_pfn is
figured out in arch/xtensa/mm/init.c.  And this from xt2000 e.g.:

	void platform_init(bp_tag_t* first)
	        /* Set default memory block if not provided by the bootloader. */
	        if (sysmem.nr_banks == 0) {
	                sysmem.nr_banks = 1;
	                sysmem.bank[0].start = PLATFORM_DEFAULT_MEM_START;
	                sysmem.bank[0].end = PLATFORM_DEFAULT_MEM_START
	                                     + PLATFORM_DEFAULT_MEM_SIZE;

And, well, if the platform says `start from PFN 0', then the mm code
will.  So this seems to be a bug in xt2000.

My changes shouldn't have triggered this at all, though.  I bet that
even with them reverted you will see this problem.

>   I have to start getting up earlier, meeting with  Dr. Cord Seele et. al. 
>   on Wends at 10:00am;
> so I'll delay fixing it till tomorrow. It's likely very easy; like skipping 
> PAGE 0.

Adjusting the sysmem contents I guess.

>   The memory changes and the IRQ changes are the most risky.


> I discussed 
>   the VARIANT change with
> Marc this afternoon with a Makefile now being required for a Variant. We 
> were wondering why you
> don't put this code in the platform dir. Seem Chris Zankel's philosophy was 
> that the platform
> directory should be as tight as possible.

We tried hard to separate what is core-specific and what is specific
to our eval board so if somebody else puts the S6000 on a different
board, she should be able to just port to the new platform and use the
s6000 support code from the variant directory instead of duplicating
it in the platform directory.

> I like the way your handling interrupt distribution. Once we are up I'll 
> consider
> doing ours more like yours.

What exactly do you mean?

> Marc and I looked a bit at the ARM and MIPS arch in search of the correct 
> paradigm
> for VARIANT code.

They do it all differently ;) Our conclusion is that there isn't a
'right way', it strongly depends on the environment where the
architecture is used.  I.e. what organization of code brings the least
hassle if new hardware pops up etc.

>   Perhaps you could start a discussion with Marc on this while I get the
> merge running on LX60 and LX200; hopefully tomorrow. Marc is an early
> riser, east coast time, I suspect that he likely will be on line before
> you take off in Germany and might enjoy discussing the VARIANT code issue
> with ya. He has a extremely in depth and long time horizon on the Xtensa
> architecture.


> menu "Xtensa Processor type and features"
> choice
> 	prompt "Xtensa Processor Configuration"
> 	bool "fsf - default (not generic) configuration"
> 	select MMU
> 	bool "mmubasele - base little-endian processor configuration"
> 	help
> 	This variant refers to a base little-endian processor configuration (mmubasele)
> 	that is a subset of the Diamond 232L Standard cores.
> 	bool "dc232a - Diamond 232L Standard Core Rev.A (LE)"
> 	help
> 	This variant refers to Tensilica's Diamond 232L Standard core Rev.A (LE).
> 	bool "dc232b - Diamond 232L Standard Core Rev.B (LE)"
> 	select MMU
> 	help
> 	  This variant refers to Tensilica's Diamond 232L Standard core Rev.B (LE).
> config XTENSA_VARIANT_S6000
> 	bool "fsf - default (not generic) configuration"

Hm, merge wreckage?


> config SMP
> 	bool "Enable Symmetric multi-processing support"
> 	depends on ARCH_HAS_SMP
> 	help
> 	  Enabled SMP Software; allows more than one CPU/CORE
> 	  to be activated during startup.
> config NR_CPUS
>         depends on SMP
>         int "Maximum number of CPUs (2-32)"
>         range 2 32
>         default "4"
> 	def_bool n
> 	depends on !XTENSA_PLATFORM_LX60

I think I already fixed those to use select on the user-side instead.

> 	help
> 	  On some platforms (XT2000, for example), the CPU clock rate can
> 	  vary.  The frequency can be determined, however, by measuring
> 	  against a well known, fixed frequency, such as an UART oscillator.
> 	def_bool n
> 	def_bool n
> 	depends on ARCH_HAS_SMP
> 	help
> 	  Enabled SMP Software; allows more than one CPU/CORE
> 	  to be activated during startup.

Merge wreckage?

> endmenu
> menu "Xtensa Platform options"
> choice
> 	prompt "Xtensa System Type"
> 	bool "ISS"

See, you don't need the weird dependencies in XTENSA_CALIBRATE_CCOUNT

> 	help
> 	  ISS is an acronym for Tensilica's Instruction Set Simulator.


> menu "Xtensa Bus options"
> config PCI
> 	bool "PCI support" if !XTENSA_PLATFORM_LX60
> 	depends on !XTENSA_PLATFORM_LX60

Here the same.  Just disable it by default and let the platforms
select it when they want it.  This above enables PCI for S6105 which
doesn't make sense.  And this problem will come up again and again.
If you really want it as user selectable option, add
CONFIG_PLATFORM_HAS_PCI, select it by the platform and make CONFIG_PCI
depend on it being set like you did with SMP and ARCH_HAS_SMP.


More information about the linux-xtensa mailing list