Please download second patches for review:
 
http://mprc.pku.edu.cn/~guanxuetao/linux/patch-2.6.37-rc2-uc32-gxt2-arch.bz2
  (above patch for arch/unicore32 directory, 149KB)
 
http://mprc.pku.edu.cn/~guanxuetao/linux/patch-2.6.37-rc2-uc32-gxt2-drivers.
bz2
  (above patch for drivers/staging/puv3 directory, which including some
necessary drivers, 31KB)
 
http://mprc.pku.edu.cn/~guanxuetao/linux/patch-2.6.37-rc2-uc32-gxt2-rest.bz2
  (above patch for rest patch code, for modifying the file not in
arch/unicore32 and drivers/staging/puv3, 2KB)

[Guan] please download x86-unicore cross toolchain from:
	http://mprc.pku.edu.cn/~guanxuetao/linux/uc4-1.0.5-hard.tgz 
	(about 100MB)
[Guan] CMDLINE will only be used when no bootloader params.
[Guan] nb0916 is for netbook and desktop, and CONFIG_MODULES must be
enabled.
  Smw0919 is for safety embedded devices, only necessary devices/drivers are
[Guan] when I set MAX_DMA_ADDRESS to PAGE_OFFSET, some pci drivers have
problem.
[Guan] For UniCore, more than forty headers are auto generated.
 However, if all non-exist headers are auto-generated, it would make a
terrible mess.
 So, it should depend on archprepare rule in arch/xxx/Makefile, but not in
Kbuild.
 I think the arch maintainers should determine which files are needed.
[Guan] we do have pci bus and pci driver. I have to implement these
[Guan] we use __NR_* as the immediate number in soft-interrupt instruction.
     And if the syscall number changed, all software and toolchain need
[Guan] Thank you very much!

Guan Xuetao


--

[ message continues ]

Just a quick proof-of-concept hack.

	Sam

diff --git a/Makefile b/Makefile
index ab5359d..e878120 100644
--- a/Makefile
+++ b/Makefile
@@ -344,7 +344,9 @@ CFLAGS_GCOV	= -fprofile-arcs -ftest-coverage
 
 # Use LINUXINCLUDE when you must reference the include/ directory.
 # Needed to be compatible with the O= option
-LINUXINCLUDE    := -I$(srctree)/arch/$(hdr-arch)/include -Iinclude \
+LINUXINCLUDE    := -I$(srctree)/arch/$(hdr-arch)/include \
+                   $(if $(KBUILD_SRC), -Iarch/$(hdr-arch)/include) \
+                   -Iinclude \
                    $(if $(KBUILD_SRC), -I$(srctree)/include) \
                    -include include/generated/autoconf.h
 
@@ -950,7 +952,13 @@ prepare1: prepare2 include/linux/version.h include/generated/utsrelease.h \
 
 archprepare: prepare1 scripts_basic
 
-prepare0: archprepare FORCE
+archheaders: $(addprefix arch/$(SRCARCH)/include/asm/, $(ARCH_GENERIC_HEADERS))
+
+$(addprefix arch/$(SRCARCH)/include/asm/, $(ARCH_GENERIC_HEADERS)): arch/$(SRCARCH)/Makefile
+	$(Q)mkdir -p $(dir $@)
+	$(Q)echo '#include <asm-generic/$(notdir $@)>' > $@
+
+prepare0: archprepare archheaders FORCE
 	$(Q)$(MAKE) $(build)=.
 	$(Q)$(MAKE) $(build)=. missing-syscalls
 
diff --git a/arch/x86/Makefile b/arch/x86/Makefile
index b02e509..fd23d01 100644
--- a/arch/x86/Makefile
+++ b/arch/x86/Makefile
@@ -12,6 +12,8 @@ endif
 # e.g.: obj-y += foo_$(BITS).o
 export BITS
 
+ARCH_GENERIC_HEADERS := termios.h
+
 ifeq ($(CONFIG_X86_32),y)
         BITS := 32
         UTS_MACHINE := i386
diff --git a/arch/x86/include/asm/termios.h b/arch/x86/include/asm/termios.h
deleted file mode 100644
index 280d78a..0000000
--- a/arch/x86/include/asm/termios.h
+++ /dev/null
@@ -1 +0,0 @@
-#include <asm-generic/termios.h>
--

[ message continues ]

Well, my point was more specifically that having to provide
options on the command line that are hardware specific is wrong,
independent of whether they come from the hardcoded command line
or from u-boot.

The command line can of course be used for boot device configuration
like the NFS root stuff (which I still would not put in the defconfig),
but memory size and screen resolution are something that should

The defconfig is not typically used without modifications on real systems,
but serves as a starting point. If it's reasonable to build a configuration
with all the smw0919 device drivers built-in and the additional nb0916 
drivers as loadable modules, I guess that would make a reasonable defconfig.
On smw0919 hardware, you can then just choose not to install the modules into

Interesting. You already allow to override MAX_DMA_ADDRESS to
(PAGE_OFFSET + SZ_128M) when PCI is enabled. It would be good to
find out (and document!) the signficance of the extra 128MB here.

If it turns out to be required, please make a patch to the
asm-generic/dma.h file to allow overriding MAX_DMA_ADDRESS in the

In what way does the architecture enforce this? What are the contents
of this page? Can you make it an actual VDSO rather than a magic page

Would it be an option to have a fixed 2GB/2GB split between user and physical
address space? That would limit the user addressable range to something
just under 2GB (because of vmalloc/ioremap pages), but would significantly

Good idea. The ioremap parts of io.h are really specific to nommu
architectures, while the other parts are specific to architectures that

That is a bug, as far as I can tell. I think it should be changed to
a hardcoded (-1) in the amba drivers as we do elsewhere.

Until now, I was not even aware that we had an amba bus driver,
and I'm not conviced that it's a good idea to use it either
in its current form.

Most of the users of the amba bus currently declare static devices
in the architecture tree, which is ...
[ message continues ]

PCI controller in PKUnity-3 masks highest 5-bit for upstream channel, so we
must
Limit the DMA allocation with 128M physical memory for supporting PCI
I need to check it later. 
I suppose MAX_DMA_ADDRESS is virtual address, so it should be larger than
Page table is created for vector page and exceptions entry stub.
Yes, it works. I think it's not a good idea. Kernel should be independent on
The ZONE_DMA only limits pci devices, not a general limitation.
However, many chips could be connected to different bus, 
so this limit influences global in our architecture.

Guan Xuetao


--

[ message continues ]

I had a closer look again at this. MAX_DMA_ADDRESS is meant to reflect
the size of ZONE_DMA, which it does in your patch.

However, something else is really wrong, in that ZONE_DMA (i.e. GFP_DMA)
should only be used for legacy ISA devices like floppy or parallel port,
not for PCI devices.

If your PCI bus can only do DMA to a limited memory range, you can not
in general use MAX_DMA_ADDRESS/ZONE_DMA for this, but instead need to
use the swiotlb code or a hardware IOMMU in place of your asm/dma-mapping.h

Interesting. So if it's not mapped into user space, why do you even
need to have the vectors at a specific page? I think ARM only maps it
to the high page because that page is shared to user space, while most
architectures just have their interrupt vectors in the linar mapping,


I've seen both libgcc based and standalone library approaches in
architectures, but I could never see a strong reaons for one way
or another. Why do you think it should be independent? Licensing

As mentioned above, the drivers behind the PCI (except PCI-ISA bridges) should
be using dma_map_single/dma_alloc_coherent instead of GFP_DMA to get DMA
capable memory, so what you need instead is swiotlb.

	Arnd
--

[ message continues ]

Ok, thanks.

Guan Xuetao

--

[ message continues ]

Ok. I see.

The arch_exit_mmap() and arch_setup_additional_pages() functions seems to refer to
how ARM maps this page into user space as well, you should probably change that.

I've finished the second half of the code review now, I'll follow up with an
email but drop the personal Cc to everyone besides us, in case people are getting
bored from the discussion by now ;-)

	Arnd
--

[ message continues ]

Vector page is also used as kuser page, so arch_setup_additional_pages need
to 
Thanks again.

Guan Xuetao

--

[ message continues ]