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 --
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> --
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 ...
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 --
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 --
Ok, thanks. Guan Xuetao --
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 --
Vector page is also used as kuser page, so arch_setup_additional_pages need to Thanks again. Guan Xuetao --