From tvan5bee at yahoo.com Tue Dec 1 15:56:20 2015 From: tvan5bee at yahoo.com (Ted Victorio) Date: Tue, 1 Dec 2015 20:56:20 +0000 (UTC) Subject: [uClinux-dev] Configure M5329 NAND for Freescale MCF5329EVB (uClinux-dist-20150808) References: <453285614.10976718.1449003380771.JavaMail.yahoo.ref@mail.yahoo.com> Message-ID: <453285614.10976718.1449003380771.JavaMail.yahoo@mail.yahoo.com> I am unable to compile for the M5329 NAND using the configuration below. Distro:??????? uClinux-dist-20150808 Tool:?????????? m68k-uclinux-tools-20101118 Platform:?? Freescale MCF5329EVB # Linux/m68k 4.0.0-uc0 Kernel Configuration # Disk-On-Chip Device Drivers CONFIG_MTD_NAND=y CONFIG_MTD_NAND_M5329=y CONFIG_MTD_NAND_IDS=y # Bus devices CONFIG_MTD=y # User Modules And Translation Layers CONFIG_MTD_BLKDEVS=y CONFIG_MTD_BLOCK=y # RAM/ROM/Flash chip drivers CONFIG_MTD_CFI=y CONFIG_MTD_GEN_PROBE=y CONFIG_MTD_MAP_BANK_WIDTH_1=y CONFIG_MTD_MAP_BANK_WIDTH_2=y CONFIG_MTD_MAP_BANK_WIDTH_4=y CONFIG_MTD_CFI_I1=y CONFIG_MTD_CFI_I2=y CONFIG_MTD_CFI_UTIL=y CONFIG_MTD_RAM=y CONFIG_MTD_ROM=y # Mapping drivers for chip access CONFIG_MTD_UCLINUX=y CONFIG_MTD_UCLINUX_EBSS=y Errors: drivers/mtd/nand/m5329.c: In function 5329_init: drivers/mtd/nand/m5329.c:85:2: error: lvalue required as left operand of assignment drivers/mtd/nand/m5329.c:90:4: error: lvalue required as left operand of assignment drivers/mtd/nand/m5329.c:92:4: error: lvalue required as left operand of assignment drivers/mtd/nand/m5329.c:131:2: error: implicit declaration of function add_mtd_partitions Do I need additional options? Or something else? Thank you very much. Regards, Ted Note: I have the same "Disk-On-Chip Device Drivers" set up with uClinux-dist-20080808 on MCF5329EVB, and the board is working fine. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gerg at uclinux.org Wed Dec 2 09:33:30 2015 From: gerg at uclinux.org (Greg Ungerer) Date: Thu, 3 Dec 2015 00:33:30 +1000 Subject: [uClinux-dev] Configure M5329 NAND for Freescale MCF5329EVB (uClinux-dist-20150808) In-Reply-To: <453285614.10976718.1449003380771.JavaMail.yahoo@mail.yahoo.com> References: <453285614.10976718.1449003380771.JavaMail.yahoo.ref@mail.yahoo.com> <453285614.10976718.1449003380771.JavaMail.yahoo@mail.yahoo.com> Message-ID: <565F013A.4090402@uclinux.org> Hi Ted, On 02/12/15 06:56, Ted Victorio wrote: > I am unable to compile for the M5329 NAND using the configuration below. > > Distro: uClinux-dist-20150808 > Tool: m68k-uclinux-tools-20101118 > Platform: Freescale MCF5329EVB > > # Linux/m68k 4.0.0-uc0 Kernel Configuration [snip] > > Errors: > drivers/mtd/nand/m5329.c: In function 5329_init: > drivers/mtd/nand/m5329.c:85:2: error: lvalue required as left operand of > assignment > drivers/mtd/nand/m5329.c:90:4: error: lvalue required as left operand of > assignment > drivers/mtd/nand/m5329.c:92:4: error: lvalue required as left operand of > assignment > drivers/mtd/nand/m5329.c:131:2: error: implicit declaration of function > add_mtd_partitions > > Do I need additional options? Or something else? The definitions for register addresses were sanitized for Coldfire hardware a few kernel revisions back. They are now all register addresses (or offsets) - not access macros as some were. You will need the patch below to fix this driver (compile tested only). The include of mtdcore is a little ugly, but it should get you going for now. Regards Greg --- linux/drivers/mtd/nand/m5329.c.org 2015-12-03 00:19:18.324085936 +1000 +++ linux/drivers/mtd/nand/m5329.c 2015-12-03 00:27:49.644082361 +1000 @@ -27,6 +27,7 @@ #include #include #include +#include "../mtdcore.h" /* * MTD structure for M5329EVB board @@ -82,14 +83,14 @@ struct nand_chip *this; /* Setup NAND flash chip select signals */ - MCF_FBCS2_CSAR = NAND_FLASH_ADDRESS; - MCF_FBCS2_CSCR = (MCF_FBCS_CSCR_PS_8 - | MCF_FBCS_CSCR_BEM - | MCF_FBCS_CSCR_AA - | MCF_FBCS_CSCR_SBM - | MCF_FBCS_CSCR_WS(7)); - MCF_FBCS2_CSMR = (MCF_FBCS_CSMR_BAM_16M - | MCF_FBCS_CSMR_V); + writel(NAND_FLASH_ADDRESS, MCF_FBCS2_CSAR); + writel(MCF_FBCS_CSCR_PS_8 + | MCF_FBCS_CSCR_BEM + | MCF_FBCS_CSCR_AA + | MCF_FBCS_CSCR_SBM + | MCF_FBCS_CSCR_WS(7), + MCF_FBCS2_CSCR); + writel(MCF_FBCS_CSMR_BAM_16M | MCF_FBCS_CSMR_V, MCF_FBCS2_CSMR); /* Allocate memory for MTD device structure and private data */ m5329_mtd = kmalloc (sizeof(struct mtd_info)+sizeof (struct nand_chip), From cristobal.chaves at hotmail.com Wed Dec 2 10:13:58 2015 From: cristobal.chaves at hotmail.com (Cristobal Chaves) Date: Wed, 2 Dec 2015 16:13:58 +0100 Subject: [uClinux-dev] Configure M5329 NAND for Freescale MCF5329EVB (uClinux-dist-20150808) In-Reply-To: <565F013A.4090402@uclinux.org> References: <453285614.10976718.1449003380771.JavaMail.yahoo.ref@mail.yahoo.com>, <453285614.10976718.1449003380771.JavaMail.yahoo@mail.yahoo.com>, <565F013A.4090402@uclinux.org> Message-ID: Hi, First of all you have to compile the drivers if you wanna add the drivers, then you have to modify the kconfig file adding the names of the divers files *.o and *.c. Once you have added the files to the configure file you can patch the kernel and finally add the drivers configuring the kernel graphically or manually. Just follow the steps of bellow: 1) Compile drivers2) Add names of files *.o and *.c to the respective KCONFIG3) Patch Kernel using Diff tool4) Compile Kernel5) Add drivers to the configuration of custom kernel6) Compile Kernel 7) Done, you have your custom kernel with new drivers added. BR, Cristobal > To: uclinux-dev at uclinux.org > From: gerg at uclinux.org > Date: Thu, 3 Dec 2015 00:33:30 +1000 > Subject: Re: [uClinux-dev] Configure M5329 NAND for Freescale MCF5329EVB (uClinux-dist-20150808) > > Hi Ted, > > On 02/12/15 06:56, Ted Victorio wrote: > > I am unable to compile for the M5329 NAND using the configuration below. > > > > Distro: uClinux-dist-20150808 > > Tool: m68k-uclinux-tools-20101118 > > Platform: Freescale MCF5329EVB > > > > # Linux/m68k 4.0.0-uc0 Kernel Configuration > [snip] > > > > Errors: > > drivers/mtd/nand/m5329.c: In function 5329_init: > > drivers/mtd/nand/m5329.c:85:2: error: lvalue required as left operand of > > assignment > > drivers/mtd/nand/m5329.c:90:4: error: lvalue required as left operand of > > assignment > > drivers/mtd/nand/m5329.c:92:4: error: lvalue required as left operand of > > assignment > > drivers/mtd/nand/m5329.c:131:2: error: implicit declaration of function > > add_mtd_partitions > > > > Do I need additional options? Or something else? > > The definitions for register addresses were sanitized for Coldfire > hardware a few kernel revisions back. They are now all register > addresses (or offsets) - not access macros as some were. > > You will need the patch below to fix this driver (compile tested > only). The include of mtdcore is a little ugly, but it should get > you going for now. > > Regards > Greg > > > > --- linux/drivers/mtd/nand/m5329.c.org 2015-12-03 00:19:18.324085936 +1000 > +++ linux/drivers/mtd/nand/m5329.c 2015-12-03 00:27:49.644082361 +1000 > @@ -27,6 +27,7 @@ > #include > #include > #include > +#include "../mtdcore.h" > > /* > * MTD structure for M5329EVB board > @@ -82,14 +83,14 @@ > struct nand_chip *this; > > /* Setup NAND flash chip select signals */ > - MCF_FBCS2_CSAR = NAND_FLASH_ADDRESS; > - MCF_FBCS2_CSCR = (MCF_FBCS_CSCR_PS_8 > - | MCF_FBCS_CSCR_BEM > - | MCF_FBCS_CSCR_AA > - | MCF_FBCS_CSCR_SBM > - | MCF_FBCS_CSCR_WS(7)); > - MCF_FBCS2_CSMR = (MCF_FBCS_CSMR_BAM_16M > - | MCF_FBCS_CSMR_V); > + writel(NAND_FLASH_ADDRESS, MCF_FBCS2_CSAR); > + writel(MCF_FBCS_CSCR_PS_8 > + | MCF_FBCS_CSCR_BEM > + | MCF_FBCS_CSCR_AA > + | MCF_FBCS_CSCR_SBM > + | MCF_FBCS_CSCR_WS(7), > + MCF_FBCS2_CSCR); > + writel(MCF_FBCS_CSMR_BAM_16M | MCF_FBCS_CSMR_V, MCF_FBCS2_CSMR); > > /* Allocate memory for MTD device structure and private data */ > m5329_mtd = kmalloc (sizeof(struct mtd_info)+sizeof (struct nand_chip), > > > _______________________________________________ > uClinux-dev mailing list > uClinux-dev at uclinux.org > http://mailman.uclinux.org/mailman/listinfo/uclinux-dev > This message was resent by uclinux-dev at uclinux.org > To unsubscribe see: > http://mailman.uclinux.org/mailman/options/uclinux-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From gerg at uclinux.org Wed Dec 2 19:06:14 2015 From: gerg at uclinux.org (Greg Ungerer) Date: Thu, 3 Dec 2015 10:06:14 +1000 Subject: [uClinux-dev] Configure M5329 NAND for Freescale MCF5329EVB (uClinux-dist-20150808) In-Reply-To: References: <453285614.10976718.1449003380771.JavaMail.yahoo.ref@mail.yahoo.com> <453285614.10976718.1449003380771.JavaMail.yahoo@mail.yahoo.com> <565F013A.4090402@uclinux.org> Message-ID: <565F8776.4000308@uclinux.org> Hi Cristobal, On 03/12/15 01:13, Cristobal Chaves wrote: > First of all you have to compile the drivers if you wanna add the drivers, then you have to modify the kconfig file adding the names of the divers files *.o and *.c. Once you have added the files to the configure file you can patch the kernel and finally add the drivers configuring the kernel graphically or manually. Just follow the steps of bellow: This really makes no sense. And it seems unnecessary given the original poster was clearly already compiling the driver in the kernel tree. The m5329.c driver source in that tree is broken - the compile error messages give that. You don't add *.c or *.o names into a Kconfig. They would only ever go into a Makefile. Regards Greg > 1) Compile drivers > 2) Add names of files *.o and *.c to the respective KCONFIG > 3) Patch Kernel using Diff tool > 4) Compile Kernel > 5) Add drivers to the configuration of custom kernel > 6) Compile Kernel > 7) Done, you have your custom kernel with new drivers added. > > BR, > > Cristobal > >> To: uclinux-dev at uclinux.org >> From: gerg at uclinux.org >> Date: Thu, 3 Dec 2015 00:33:30 +1000 >> Subject: Re: [uClinux-dev] Configure M5329 NAND for Freescale MCF5329EVB (uClinux-dist-20150808) >> >> Hi Ted, >> >> On 02/12/15 06:56, Ted Victorio wrote: >> > I am unable to compile for the M5329 NAND using the configuration below. >> > >> > Distro: uClinux-dist-20150808 >> > Tool: m68k-uclinux-tools-20101118 >> > Platform: Freescale MCF5329EVB >> > >> > # Linux/m68k 4.0.0-uc0 Kernel Configuration >> [snip] >> > >> > Errors: >> > drivers/mtd/nand/m5329.c: In function 5329_init: >> > drivers/mtd/nand/m5329.c:85:2: error: lvalue required as left operand of >> > assignment >> > drivers/mtd/nand/m5329.c:90:4: error: lvalue required as left operand of >> > assignment >> > drivers/mtd/nand/m5329.c:92:4: error: lvalue required as left operand of >> > assignment >> > drivers/mtd/nand/m5329.c:131:2: error: implicit declaration of function >> > add_mtd_partitions >> > >> > Do I need additional options? Or something else? >> >> The definitions for register addresses were sanitized for Coldfire >> hardware a few kernel revisions back. They are now all register >> addresses (or offsets) - not access macros as some were. >> >> You will need the patch below to fix this driver (compile tested >> only). The include of mtdcore is a little ugly, but it should get >> you going for now. >> >> Regards >> Greg >> >> >> >> --- linux/drivers/mtd/nand/m5329.c.org 2015-12-03 00:19:18.324085936 +1000 >> +++ linux/drivers/mtd/nand/m5329.c 2015-12-03 00:27:49.644082361 +1000 >> @@ -27,6 +27,7 @@ >> #include >> #include >> #include >> +#include "../mtdcore.h" >> >> /* >> * MTD structure for M5329EVB board >> @@ -82,14 +83,14 @@ >> struct nand_chip *this; >> >> /* Setup NAND flash chip select signals */ >> - MCF_FBCS2_CSAR = NAND_FLASH_ADDRESS; >> - MCF_FBCS2_CSCR = (MCF_FBCS_CSCR_PS_8 >> - | MCF_FBCS_CSCR_BEM >> - | MCF_FBCS_CSCR_AA >> - | MCF_FBCS_CSCR_SBM >> - | MCF_FBCS_CSCR_WS(7)); >> - MCF_FBCS2_CSMR = (MCF_FBCS_CSMR_BAM_16M >> - | MCF_FBCS_CSMR_V); >> + writel(NAND_FLASH_ADDRESS, MCF_FBCS2_CSAR); >> + writel(MCF_FBCS_CSCR_PS_8 >> + | MCF_FBCS_CSCR_BEM >> + | MCF_FBCS_CSCR_AA >> + | MCF_FBCS_CSCR_SBM >> + | MCF_FBCS_CSCR_WS(7), >> + MCF_FBCS2_CSCR); >> + writel(MCF_FBCS_CSMR_BAM_16M | MCF_FBCS_CSMR_V, MCF_FBCS2_CSMR); >> >> /* Allocate memory for MTD device structure and private data */ >> m5329_mtd = kmalloc (sizeof(struct mtd_info)+sizeof (struct nand_chip), >> >> >> _______________________________________________ >> uClinux-dev mailing list >> uClinux-dev at uclinux.org >> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev >> This message was resent by uclinux-dev at uclinux.org >> To unsubscribe see: >> http://mailman.uclinux.org/mailman/options/uclinux-dev > > > _______________________________________________ > uClinux-dev mailing list > uClinux-dev at uclinux.org > http://mailman.uclinux.org/mailman/listinfo/uclinux-dev > This message was resent by uclinux-dev at uclinux.org > To unsubscribe see: > http://mailman.uclinux.org/mailman/options/uclinux-dev > From tvan5bee at yahoo.com Thu Dec 3 04:24:24 2015 From: tvan5bee at yahoo.com (Ted Victorio) Date: Thu, 3 Dec 2015 09:24:24 +0000 (UTC) Subject: [uClinux-dev] Configure M5329 NAND for Freescale MCF5329EVB (uClinux-dist-20150808) In-Reply-To: <565F8776.4000308@uclinux.org> References: <565F8776.4000308@uclinux.org> Message-ID: <560036656.11786959.1449134664269.JavaMail.yahoo@mail.yahoo.com> Hi Greg, Your patch works! The m5329.c compiled. But I got 2 additional undefined errors ref to nand_ecc.c, so I corrected by adding MTD_NAND_ECC to linux config: ??? # Disk-On-Chip Device Drivers ??? # ??? CONFIG_MTD_NAND_ECC=y ??? CONFIG_MTD_NAND_M5329=y ??? CONFIG_MTD_NAND=y ??? CONFIG_MTD_NAND_IDS=y And I added these two lines to uClinux-dist/vendors/Freescale/M5329EVB/Makefile (as I did to make uClinux-dist-20080808 work) ??? mtd0,c,90,0 mtd1,c,90,2 mtd2,c,90,4 \ ??? mtdblock0,b,31,0 mtdblock1,b,31,1 mtdblock2,b,31,2 \ The image.bin was succesfully built. However, the problem now is the image.bin booting has stopped at 0x000000000000-0x00000016e000 : "ROMfs" (see captured display below) I noticed differences between 2015 and 2008: (1) Is m53xx compatible to m532x?? [2015] uClinux/COLDFIRE(m53xx)? vs? [2008] uClinux/COLDFIRE(m532x) (2) Why different sizes for RAM probe?? [2015] uclinux[mtd]: probe address=0x4029bc20 size=0x16e000? vs? [2008] uclinux[mtd]: RAM probe address=0x401c83b8 size=0x3f7000 (3) Why does 2015 not display NAND found like in 2008?? [2008] NAND device: Manufacturer ID: 0x20, Chip ID: 0x73 (ST Micro NAND 16MiB 3,3V 8-bit) (3) MTD partition creation? [2015] Creating 1 MTD partitions on "ram": 0x000000000000-0x00000016e000 : "ROMfs"? vs? [2008] Creating 1 MTD partitions on "NAND 16MiB 3,3V 8-bit": 0x00000000-0x01000000 : "M5329 flash partition 1" Any clues to solve this? Thanks again, Ted --------------------------- dBUG> go 0x40020000 Linux version 4.0.0-uc0 (root at RHEL6) (gcc version 4.5.1 (GCC) ) #9 Wed Dec 2 20:51:10 PST 2015 uClinux/COLDFIRE(m53xx) COLDFIRE port done by Greg Ungerer, gerg at snapgear.com Flat model support (C) 1998,1999 Kenneth Albanowski, D. Jeff Dionne Built 1 zonelists in Zone order, mobility grouping off.? Total pages: 4080 Kernel command line: console=ttyS0,19200 rootfstype=romfs PID hash table entries: 2048 (order: 0, 8192 bytes) Dentry cache hash table entries: 4096 (order: 1, 16384 bytes) Inode-cache hash table entries: 2048 (order: 0, 8192 bytes) Memory: 28416K/32768K available (1945K kernel code, 118K rwdata, 328K rodata, 72K init, 79K bss, 4352K reserved, 0K cma-reserved) Virtual kernel memory layout: ??? vector? : 0x40000000 - 0x40000400?? (?? 1 KiB) ??? kmap??? : 0x00000000 - 0xffffffff?? (4095 MiB) ??? vmalloc : 0x00000000 - 0xffffffff?? (4095 MiB) ??? lowmem? : 0x40000000 - 0x42000000?? (? 32 MiB) ????? .init : 0x40276000 - 0x40288000?? (? 72 KiB) ????? .text : 0x40020000 - 0x40206490?? (1946 KiB) ????? .data : 0x40206490 - 0x40275e00?? ( 447 KiB) ????? .bss? : 0x40288000 - 0x4029bc20?? (? 80 KiB) SLUB: HWalign=16, Order=0-3, MinObjects=0, CPUs=1, Nodes=8 NR_IRQS:256 Console: colour dummy device 80x25 Calibrating delay loop... 159.12 BogoMIPS (lpj=795648) pid_max: default: 32768 minimum: 301 Mount-cache hash table entries: 2048 (order: 0, 8192 bytes) Mountpoint-cache hash table entries: 2048 (order: 0, 8192 bytes) NET: Registered protocol family 16 Switched to clocksource tmr NET: Registered protocol family 2 TCP established hash table entries: 2048 (order: 0, 8192 bytes) TCP bind hash table entries: 2048 (order: 0, 8192 bytes) TCP: Hash tables configured (established 2048 bind 2048) TCP: reno registered UDP hash table entries: 512 (order: 0, 8192 bytes) UDP-Lite hash table entries: 512 (order: 0, 8192 bytes) NET: Registered protocol family 1 jffs2: version 2.2. (NAND) ?? 2001-2006 Red Hat, Inc. romfs: ROMFS MTD (C) 2007 Red Hat, Inc. io scheduler noop registered (default) Initing M532x Framebuffer Console: switching to colour frame buffer device 100x37 fb0: M532x FB frame buffer device @0x41a00000 ColdFire internal UART serial driver mcfuart.0: ttyS0 at MMIO 0xfc060000 (irq = 90, base_baud = 5000000) is a ColdFire UART console [ttyS0] enabled mcfuart.0: ttyS1 at MMIO 0xfc064000 (irq = 91, base_baud = 5000000) is a ColdFire UART mcfuart.0: ttyS2 at MMIO 0xfc068000 (irq = 92, base_baud = 5000000) is a ColdFire UART brd: module loaded loop: module loaded nbd: registered device at major 43 uclinux[mtd]: probe address=0x4029bc20 size=0x16e000 uclinux[mtd]: set ROMfs to be root filesystem Creating 1 MTD partitions on "ram": 0x000000000000-0x00000016e000 : "ROMfs" --------------------------- On Wednesday, December 2, 2015 4:06 PM, Greg Ungerer wrote: Hi Cristobal, On 03/12/15 01:13, Cristobal Chaves wrote: > First of all you have to compile the drivers if you wanna add the drivers, then you have to modify the kconfig file adding the names of the divers files *.o and *.c. Once you have added the files to the configure file you can patch the kernel and finally add the drivers configuring the kernel graphically or manually. Just follow the steps of bellow: This really makes no sense. And it seems unnecessary given the original poster was clearly already compiling the driver in the kernel tree. The m5329.c driver source in that tree is broken - the compile error messages give that. You don't add *.c or *.o names into a Kconfig. They would only ever go into a Makefile. Regards Greg > 1) Compile drivers > 2) Add names of files *.o and *.c to the respective KCONFIG > 3) Patch Kernel using Diff tool > 4) Compile Kernel > 5) Add drivers to the configuration of custom kernel > 6) Compile Kernel > 7) Done, you have your custom kernel with new drivers added. > > BR, > > Cristobal > >> To: uclinux-dev at uclinux.org >> From: gerg at uclinux.org >> Date: Thu, 3 Dec 2015 00:33:30 +1000 >> Subject: Re: [uClinux-dev] Configure M5329 NAND for Freescale MCF5329EVB (uClinux-dist-20150808) >> >> Hi Ted, >> >> On 02/12/15 06:56, Ted Victorio wrote: >> > I am unable to compile for the M5329 NAND using the configuration below. >> > >> > Distro: uClinux-dist-20150808 >> > Tool: m68k-uclinux-tools-20101118 >> > Platform: Freescale MCF5329EVB >> > >> > # Linux/m68k 4.0.0-uc0 Kernel Configuration >> [snip] >> > >> >> The definitions for register addresses were sanitized for Coldfire >> hardware a few kernel revisions back. They are now all register >> addresses (or offsets) - not access macros as some were. >> >> You will need the patch below to fix this driver (compile tested >> only). The include of mtdcore is a little ugly, but it should get >> you going for now. >> >> Regards >> Greg ? _______________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From gerg at uclinux.org Thu Dec 3 08:46:38 2015 From: gerg at uclinux.org (Greg Ungerer) Date: Thu, 3 Dec 2015 23:46:38 +1000 Subject: [uClinux-dev] Configure M5329 NAND for Freescale MCF5329EVB (uClinux-dist-20150808) In-Reply-To: <560036656.11786959.1449134664269.JavaMail.yahoo@mail.yahoo.com> References: <565F8776.4000308@uclinux.org> <560036656.11786959.1449134664269.JavaMail.yahoo@mail.yahoo.com> Message-ID: <566047BE.2020700@uclinux.org> Hi Ted, On 03/12/15 19:24, Ted Victorio wrote: > Your patch works! The m5329.c compiled. > But I got 2 additional undefined errors ref to nand_ecc.c, so I > corrected by adding MTD_NAND_ECC to linux config: > # Disk-On-Chip Device Drivers > # > CONFIG_MTD_NAND_ECC=y > CONFIG_MTD_NAND_M5329=y > CONFIG_MTD_NAND=y > CONFIG_MTD_NAND_IDS=y > > And I added these two lines to > uClinux-dist/vendors/Freescale/M5329EVB/Makefile (as I did to make > uClinux-dist-20080808 work) > mtd0,c,90,0 mtd1,c,90,2 mtd2,c,90,4 \ > mtdblock0,b,31,0 mtdblock1,b,31,1 mtdblock2,b,31,2 \ > > The image.bin was succesfully built. However, the problem now is the > image.bin booting has stopped at 0x000000000000-0x00000016e000 : "ROMfs" > (see captured display below) > > I noticed differences between 2015 and 2008: > (1) Is m53xx compatible to m532x? [2015] uClinux/COLDFIRE(m53xx) vs > [2008] uClinux/COLDFIRE(m532x) Yes, that is the intention. 53xx is meant to cater for similar parts such as the 5329 and 537x families. > (2) Why different sizes for RAM probe? [2015] uclinux[mtd]: probe > address=0x4029bc20 size=0x16e000 vs [2008] uclinux[mtd]: RAM probe > address=0x401c83b8 size=0x3f7000 How big is your images/romfs.img file? This size should match that (rounded to 4k I think). Perhaps the default user space tool set is quite different, thus producing a quite different size romfs (root filesystem). > (3) Why does 2015 not display NAND found like in 2008? [2008] NAND > device: Manufacturer ID: 0x20, Chip ID: 0x73 (ST Micro NAND 16MiB 3,3V > 8-bit) My first guess is that this probing is where the kernel is stuck. So without the nand enabled do you get a complete all the way up boot of 20150808? > (3) MTD partition creation? [2015] Creating 1 MTD partitions on "ram": > 0x000000000000-0x00000016e000 : "ROMfs" vs [2008] Creating 1 MTD > partitions on "NAND 16MiB 3,3V 8-bit": 0x00000000-0x01000000 : "M5329 > flash partition 1" > > Any clues to solve this? I would suggest adding some more printk trace in the m5239.c nand driver to see where it is possibly getting stuck. Regards Greg > --------------------------- > dBUG> go 0x40020000 > Linux version 4.0.0-uc0 (root at RHEL6) (gcc version 4.5.1 (GCC) ) #9 Wed > Dec 2 20:51:10 PST 2015 > > uClinux/COLDFIRE(m53xx) > COLDFIRE port done by Greg Ungerer, gerg at snapgear.com > Flat model support (C) 1998,1999 Kenneth Albanowski, D. Jeff Dionne > Built 1 zonelists in Zone order, mobility grouping off. Total pages: 4080 > Kernel command line: console=ttyS0,19200 rootfstype=romfs > PID hash table entries: 2048 (order: 0, 8192 bytes) > Dentry cache hash table entries: 4096 (order: 1, 16384 bytes) > Inode-cache hash table entries: 2048 (order: 0, 8192 bytes) > Memory: 28416K/32768K available (1945K kernel code, 118K rwdata, 328K > rodata, 72K init, 79K bss, 4352K reserved, 0K cma-reserved) > Virtual kernel memory layout: > vector : 0x40000000 - 0x40000400 ( 1 KiB) > kmap : 0x00000000 - 0xffffffff (4095 MiB) > vmalloc : 0x00000000 - 0xffffffff (4095 MiB) > lowmem : 0x40000000 - 0x42000000 ( 32 MiB) > .init : 0x40276000 - 0x40288000 ( 72 KiB) > .text : 0x40020000 - 0x40206490 (1946 KiB) > .data : 0x40206490 - 0x40275e00 ( 447 KiB) > .bss : 0x40288000 - 0x4029bc20 ( 80 KiB) > SLUB: HWalign=16, Order=0-3, MinObjects=0, CPUs=1, Nodes=8 > NR_IRQS:256 > Console: colour dummy device 80x25 > Calibrating delay loop... 159.12 BogoMIPS (lpj=795648) > pid_max: default: 32768 minimum: 301 > Mount-cache hash table entries: 2048 (order: 0, 8192 bytes) > Mountpoint-cache hash table entries: 2048 (order: 0, 8192 bytes) > NET: Registered protocol family 16 > Switched to clocksource tmr > NET: Registered protocol family 2 > TCP established hash table entries: 2048 (order: 0, 8192 bytes) > TCP bind hash table entries: 2048 (order: 0, 8192 bytes) > TCP: Hash tables configured (established 2048 bind 2048) > TCP: reno registered > UDP hash table entries: 512 (order: 0, 8192 bytes) > UDP-Lite hash table entries: 512 (order: 0, 8192 bytes) > NET: Registered protocol family 1 > jffs2: version 2.2. (NAND) ?? 2001-2006 Red Hat, Inc. > romfs: ROMFS MTD (C) 2007 Red Hat, Inc. > io scheduler noop registered (default) > Initing M532x Framebuffer > Console: switching to colour frame buffer device 100x37 > fb0: M532x FB frame buffer device @0x41a00000 > ColdFire internal UART serial driver > mcfuart.0: ttyS0 at MMIO 0xfc060000 (irq = 90, base_baud = 5000000) is a > ColdFire UART > console [ttyS0] enabled > mcfuart.0: ttyS1 at MMIO 0xfc064000 (irq = 91, base_baud = 5000000) is a > ColdFire UART > mcfuart.0: ttyS2 at MMIO 0xfc068000 (irq = 92, base_baud = 5000000) is a > ColdFire UART > brd: module loaded > loop: module loaded > nbd: registered device at major 43 > uclinux[mtd]: probe address=0x4029bc20 size=0x16e000 > uclinux[mtd]: set ROMfs to be root filesystem > Creating 1 MTD partitions on "ram": > 0x000000000000-0x00000016e000 : "ROMfs" > --------------------------- > > > On Wednesday, December 2, 2015 4:06 PM, Greg Ungerer > wrote: > > Hi Cristobal, > > On 03/12/15 01:13, Cristobal Chaves wrote: > > First of all you have to compile the drivers if you wanna add the > drivers, then you have to modify the kconfig file adding the names of > the divers files *.o and *.c. Once you have added the files to the > configure file you can patch the kernel and finally add the drivers > configuring the kernel graphically or manually. Just follow the steps of > bellow: > > This really makes no sense. And it seems unnecessary given the > original poster was clearly already compiling the driver in > the kernel tree. The m5329.c driver source in that tree is > broken - the compile error messages give that. > > You don't add *.c or *.o names into a Kconfig. They would only > ever go into a Makefile. > > Regards > Greg > > > 1) Compile drivers > > 2) Add names of files *.o and *.c to the respective KCONFIG > > 3) Patch Kernel using Diff tool > > 4) Compile Kernel > > 5) Add drivers to the configuration of custom kernel > > 6) Compile Kernel > > 7) Done, you have your custom kernel with new drivers added. > > > > BR, > > > > Cristobal > > > >> To: uclinux-dev at uclinux.org > >> From: gerg at uclinux.org > >> Date: Thu, 3 Dec 2015 00:33:30 +1000 > >> Subject: Re: [uClinux-dev] Configure M5329 NAND for Freescale > MCF5329EVB (uClinux-dist-20150808) > >> > >> Hi Ted, > >> > >> On 02/12/15 06:56, Ted Victorio wrote: > >> > I am unable to compile for the M5329 NAND using the configuration > below. > >> > > >> > Distro: uClinux-dist-20150808 > >> > Tool: m68k-uclinux-tools-20101118 > >> > Platform: Freescale MCF5329EVB > >> > > >> > # Linux/m68k 4.0.0-uc0 Kernel Configuration > >> [snip] > >> > > >> > >> The definitions for register addresses were sanitized for Coldfire > >> hardware a few kernel revisions back. They are now all register > >> addresses (or offsets) - not access macros as some were. > >> > >> You will need the patch below to fix this driver (compile tested > >> only). The include of mtdcore is a little ugly, but it should get > >> you going for now. > >> > >> Regards > >> Greg > > > > > > > > > _______________________________________________ > > > > _______________________________________________ > uClinux-dev mailing list > uClinux-dev at uclinux.org > http://mailman.uclinux.org/mailman/listinfo/uclinux-dev > This message was resent by uclinux-dev at uclinux.org > To unsubscribe see: > http://mailman.uclinux.org/mailman/options/uclinux-dev > From andrew.cagney at gmail.com Fri Dec 4 09:48:59 2015 From: andrew.cagney at gmail.com (Andrew Cagney) Date: Fri, 4 Dec 2015 09:48:59 -0500 Subject: [uClinux-dev] cvs repository? Message-ID: Hi, The link to the CVS repository (cvs.uclinux.org) on the home page doesn't seem to go to anywhere real. Is there an official CVS or git repository somewhere public? I'm slowly working through my hacks (https://bitbucket.org/cagney/uclinux) to get libreswan running on a no-mmu system and I'd like to avoid duplicating work already completed in upstream code bases like this. Andrew From mdurrant at uclinux.org Fri Dec 4 10:37:15 2015 From: mdurrant at uclinux.org (Michael) Date: Fri, 4 Dec 2015 10:37:15 -0500 Subject: [uClinux-dev] cvs repository? In-Reply-To: References: Message-ID: <5661B32B.105@uclinux.org> Andrew the CVS died the death about 5 years ago. Mike Frysinger and others from ADI had already converted it to a GIT repo .. but no one provided a copy of the new repo(s) back for uClinux.org to host for them. On 2015-12-04 (W49) 9:48 AM, Andrew Cagney wrote: > Hi, > > The link to the CVS repository (cvs.uclinux.org) on the home page > doesn't seem to go to anywhere real. Is there an official CVS or git > repository somewhere public? I'm slowly working through my hacks > (https://bitbucket.org/cagney/uclinux) to get libreswan running on a > no-mmu system and I'd like to avoid duplicating work already completed > in upstream code bases like this. > > Andrew > _______________________________________________ > uClinux-dev mailing list > uClinux-dev at uclinux.org > http://mailman.uclinux.org/mailman/listinfo/uclinux-dev > This message was resent by uclinux-dev at uclinux.org > To unsubscribe see: > http://mailman.uclinux.org/mailman/options/uclinux-dev > > From lsorense at csclub.uwaterloo.ca Fri Dec 4 10:51:23 2015 From: lsorense at csclub.uwaterloo.ca (Lennart Sorensen) Date: Fri, 4 Dec 2015 10:51:23 -0500 Subject: [uClinux-dev] cvs repository? In-Reply-To: <5661B32B.105@uclinux.org> References: <5661B32B.105@uclinux.org> Message-ID: <20151204155123.GI25177@csclub.uwaterloo.ca> On Fri, Dec 04, 2015 at 10:37:15AM -0500, Michael wrote: > Andrew the CVS died the death about 5 years ago. Mike Frysinger and > others from ADI had already converted it to a GIT repo .. but no one > provided > a copy of the new repo(s) back for uClinux.org to host for them. So is the sourceforge link (which seems to lead to a place with a release from August 2015) the most "official" at the moment? -- Len Sorensen From mdurrant at uclinux.org Fri Dec 4 15:55:54 2015 From: mdurrant at uclinux.org (Michael) Date: Fri, 4 Dec 2015 15:55:54 -0500 Subject: [uClinux-dev] cvs repository? In-Reply-To: <20151204155123.GI25177@csclub.uwaterloo.ca> References: <5661B32B.105@uclinux.org> <20151204155123.GI25177@csclub.uwaterloo.ca> Message-ID: <5661FDDA.4050702@uclinux.org> Yes. You are welcome to email patches for Greg to integrate to this mailing list. -- Michael On 2015-12-04 (W49) 10:51 AM, Lennart Sorensen wrote: > On Fri, Dec 04, 2015 at 10:37:15AM -0500, Michael wrote: >> Andrew the CVS died the death about 5 years ago. Mike Frysinger and >> others from ADI had already converted it to a GIT repo .. but no one >> provided >> a copy of the new repo(s) back for uClinux.org to host for them. > So is the sourceforge link (which seems to lead to a place with a release > from August 2015) the most "official" at the moment? > From gerg at uclinux.org Sun Dec 6 07:01:25 2015 From: gerg at uclinux.org (Greg Ungerer) Date: Sun, 6 Dec 2015 22:01:25 +1000 Subject: [uClinux-dev] cvs repository? In-Reply-To: <5661FDDA.4050702@uclinux.org> References: <5661B32B.105@uclinux.org> <20151204155123.GI25177@csclub.uwaterloo.ca> <5661FDDA.4050702@uclinux.org> Message-ID: <56642395.2050605@uclinux.org> On 05/12/15 06:55, Michael wrote: > Yes. > > You are welcome to email patches for Greg to integrate to this mailing > list. Yes, please. Patches to this list is a great place to start. Michael: can we remove the cvs link from the main www page? It is long dead and not coming back, so we can stop some confusion by at least removing it. Regards Greg > On 2015-12-04 (W49) 10:51 AM, Lennart Sorensen wrote: >> On Fri, Dec 04, 2015 at 10:37:15AM -0500, Michael wrote: >>> Andrew the CVS died the death about 5 years ago. Mike Frysinger and >>> others from ADI had already converted it to a GIT repo .. but no one >>> provided >>> a copy of the new repo(s) back for uClinux.org to host for them. >> So is the sourceforge link (which seems to lead to a place with a release >> from August 2015) the most "official" at the moment? >> > > _______________________________________________ > uClinux-dev mailing list > uClinux-dev at uclinux.org > http://mailman.uclinux.org/mailman/listinfo/uclinux-dev > This message was resent by uclinux-dev at uclinux.org > To unsubscribe see: > http://mailman.uclinux.org/mailman/options/uclinux-dev > From andrew.cagney at gmail.com Mon Dec 7 12:56:31 2015 From: andrew.cagney at gmail.com (Andrew Cagney) Date: Mon, 7 Dec 2015 12:56:31 -0500 Subject: [uClinux-dev] cvs repository? In-Reply-To: <56642395.2050605@uclinux.org> References: <5661B32B.105@uclinux.org> <20151204155123.GI25177@csclub.uwaterloo.ca> <5661FDDA.4050702@uclinux.org> <56642395.2050605@uclinux.org> Message-ID: On 6 December 2015 at 07:01, Greg Ungerer wrote: > > On 05/12/15 06:55, Michael wrote: >> >> Yes. >> >> You are welcome to email patches for Greg to integrate to this mailing >> list. > > > Yes, please. Patches to this list is a great place to start. > > Michael: can we remove the cvs link from the main www page? > It is long dead and not coming back, so we can stop some > confusion by at least removing it. Yes please :-) > Regards > Greg From andrew.cagney at gmail.com Mon Dec 7 13:23:31 2015 From: andrew.cagney at gmail.com (Andrew Cagney) Date: Mon, 7 Dec 2015 13:23:31 -0500 Subject: [uClinux-dev] out-of-date libgmp / building for M5208 Message-ID: Hi, The libgmp bundled with uClinux, by default, doesn't build for the M5208 - the m68k assembler uses instructions dropped from early Coldfires. The hack I'm using locally is to configure with --host=none (I got this trick second hand from somewhere). Anyway I noticed that libgmp is, er, a little out-of-date. The latest version has --disable-assembly which looks to be a cleaner way to handle the assembler problem. (How to decide when to configure with that option is an open question, a Kconfig option). As anyone looked at updating this; or to turn the question round, is there anything needed in the existing version that would prevent this? Andrew From kreolekragol at free.fr Mon Dec 7 16:14:31 2015 From: kreolekragol at free.fr (kreolekragol at free.fr) Date: Mon, 7 Dec 2015 22:14:31 +0100 Subject: [uClinux-dev] Fw: important message Message-ID: <000081ab8747$c47a3181$9e359b49$@free.fr> Hello! New message, please read kreolekragol at free.fr -------------- next part -------------- An HTML attachment was scrubbed... URL: From gerg at uclinux.org Tue Dec 8 07:03:15 2015 From: gerg at uclinux.org (Greg Ungerer) Date: Tue, 8 Dec 2015 22:03:15 +1000 Subject: [uClinux-dev] out-of-date libgmp / building for M5208 In-Reply-To: References: Message-ID: <5666C703.1000809@uclinux.org> Hi Andrew, On 08/12/15 04:23, Andrew Cagney wrote: > The libgmp bundled with uClinux, by default, doesn't build for the > M5208 - the m68k assembler uses instructions dropped from early > Coldfires. > The hack I'm using locally is to configure with --host=none (I got > this trick second hand from somewhere). > > Anyway I noticed that libgmp is, er, a little out-of-date. The latest > version has --disable-assembly which looks to be a cleaner way to > handle the assembler problem. > (How to decide when to configure with that option is an open question, > a Kconfig option). > > As anyone looked at updating this; or to turn the question round, is > there anything needed in the existing version that would prevent this? Nothing stopping updating as far as I know. Can I suggest that if you do decide to update it that you convert it to automake building. The trend over the last couple of years is that if we are updating a package then convert it. There are quite a few examples to follow in the lib directory. Just look for directories that contain a "makefile" and optionally a patches directory and not much else. Regards Greg From andrew.cagney at gmail.com Wed Dec 9 13:03:12 2015 From: andrew.cagney at gmail.com (Andrew Cagney) Date: Wed, 9 Dec 2015 13:03:12 -0500 Subject: [uClinux-dev] out-of-date libgmp / building for M5208 In-Reply-To: <5666C703.1000809@uclinux.org> References: <5666C703.1000809@uclinux.org> Message-ID: On 8 December 2015 at 07:03, Greg Ungerer wrote: > Hi Andrew, > > On 08/12/15 04:23, Andrew Cagney wrote: >> >> The libgmp bundled with uClinux, by default, doesn't build for the >> M5208 - the m68k assembler uses instructions dropped from early >> Coldfires. >> The hack I'm using locally is to configure with --host=none (I got >> this trick second hand from somewhere). >> >> Anyway I noticed that libgmp is, er, a little out-of-date. The latest >> version has --disable-assembly which looks to be a cleaner way to >> handle the assembler problem. >> (How to decide when to configure with that option is an open question, >> a Kconfig option). >> >> As anyone looked at updating this; or to turn the question round, is >> there anything needed in the existing version that would prevent this? > > > Nothing stopping updating as far as I know. > > Can I suggest that if you do decide to update it that you convert > it to automake building. Yes, that's the plan. I've noticed that the framework's improved significantly over the years and I've been able to drop some of my local hacks. > The trend over the last couple of years > is that if we are updating a package then convert it. There > are quite a few examples to follow in the lib directory. Just > look for directories that contain a "makefile" and optionally a > patches directory and not much else. Any pointers for how to handle --disable-assembly configure option? For instance, since libreswan requires libgmp, it would have: select LIB_LIBGMP but libreswan doesn't know if --disable-assembly is required, that would be set by a vendor/platform files? Andrew > _______________________________________________ > uClinux-dev mailing list > uClinux-dev at uclinux.org > http://mailman.uclinux.org/mailman/listinfo/uclinux-dev > This message was resent by uclinux-dev at uclinux.org > To unsubscribe see: > http://mailman.uclinux.org/mailman/options/uclinux-dev From ucdevel at gmail.com Wed Dec 9 17:35:27 2015 From: ucdevel at gmail.com (David McCullough) Date: Thu, 10 Dec 2015 08:35:27 +1000 Subject: [uClinux-dev] out-of-date libgmp / building for M5208 In-Reply-To: References: <5666C703.1000809@uclinux.org> Message-ID: <20151209223527.GB13464@spottygum.com> Andrew Cagney wrote the following: > On 8 December 2015 at 07:03, Greg Ungerer wrote: > > Hi Andrew, > > > > On 08/12/15 04:23, Andrew Cagney wrote: > >> > >> The libgmp bundled with uClinux, by default, doesn't build for the > >> M5208 - the m68k assembler uses instructions dropped from early > >> Coldfires. > >> The hack I'm using locally is to configure with --host=none (I got > >> this trick second hand from somewhere). > >> > >> Anyway I noticed that libgmp is, er, a little out-of-date. The latest > >> version has --disable-assembly which looks to be a cleaner way to > >> handle the assembler problem. > >> (How to decide when to configure with that option is an open question, > >> a Kconfig option). > >> > >> As anyone looked at updating this; or to turn the question round, is > >> there anything needed in the existing version that would prevent this? > > > > > > Nothing stopping updating as far as I know. > > > > Can I suggest that if you do decide to update it that you convert > > it to automake building. > > Yes, that's the plan. I've noticed that the framework's improved > significantly over the years and I've been able to drop some of my > local hacks. > > > The trend over the last couple of years > > is that if we are updating a package then convert it. There > > are quite a few examples to follow in the lib directory. Just > > look for directories that contain a "makefile" and optionally a > > patches directory and not much else. > > Any pointers for how to handle --disable-assembly configure option? > For instance, since libreswan requires libgmp, it would have: > select LIB_LIBGMP > but libreswan doesn't know if --disable-assembly is required, that > would be set by a vendor/platform files? Yep, make that part of the libgmp setup. If you switch to automake you can add that option to a Kconfig in the libgmp directory, again, there are quite a few examples in the tree. some have their own Kconfig files: grep -l automake lib/*/makefile user/*/makefile ls lib/*/Kconfig user/*/Kconfig to find them all. Cheers, Davidm -- David McCullough, davidm at spottygum.com, Ph: 0410 560 763 From andrew.cagney at gmail.com Thu Dec 10 15:07:24 2015 From: andrew.cagney at gmail.com (Andrew Cagney) Date: Thu, 10 Dec 2015 15:07:24 -0500 Subject: [uClinux-dev] support .lz (lzip) compression Message-ID: Surprise! libgmp uses yet another compression format ... My work-in-progress libgmp makefile tests it, trust me :-) Andrew -------------- next part -------------- commit e66e173f93a09f25e6fd47763152c0e2b549c3f9 Author: Andrew Cagney Date: Thu Dec 10 14:54:31 2015 -0500 support .lz (lzip) compression diff --git a/tools/automake.inc b/tools/automake.inc index baa2446..7b6ba93 100644 --- a/tools/automake.inc +++ b/tools/automake.inc @@ -94,9 +94,11 @@ ifeq ($(AUTOMAKE_y)$(AUTOMAKE_n)$(AUTOMAKE_),) PKG := $(PKG:.tar.gz=) PKG := $(PKG:.tar.bz2=) PKG := $(PKG:.tar.xz=) + PKG := $(PKG:.tar.lz=) PKG := $(PKG:.tgz=) PKG := $(PKG:.tbz2=) PKG := $(PKG:.txz=) + PKG := $(PKG:.tlz=) PKG := $(PKG:.zip=) PKG := $(PKG:.git=) endif @@ -208,6 +210,7 @@ build/$(1)-extracted: downloads/$($(1)_DOWNLOADNAME) *zip) rm -rf build/$(1); mkdir -p build/$(1); pkg=`pwd`/$$<; (cd build/$(1); unzip $$$$pkg);; \ *bz2) bunzip2 < $$< | (cd build; tar xf -);; \ *xz) unxz < $$< | (cd build; tar xf -);; \ + *lz) lzip -d < $$< | (cd build; tar xf -);; \ *) gunzip < $$< | (cd build; tar xf -);; \ esac || exit 1 $(AT)touch $$@ From andrew.cagney at gmail.com Fri Dec 11 12:03:06 2015 From: andrew.cagney at gmail.com (Andrew Cagney) Date: Fri, 11 Dec 2015 12:03:06 -0500 Subject: [uClinux-dev] out-of-date libgmp / building for M5208 In-Reply-To: <20151209223527.GB13464@spottygum.com> References: <5666C703.1000809@uclinux.org> <20151209223527.GB13464@spottygum.com> Message-ID: I came up with the attached. The existing libgmp configuration in lib/Kconfig would need removing. On 9 December 2015 at 17:35, David McCullough wrote: > > Andrew Cagney wrote the following: >> On 8 December 2015 at 07:03, Greg Ungerer wrote: >> > Hi Andrew, >> > >> > On 08/12/15 04:23, Andrew Cagney wrote: >> >> >> >> The libgmp bundled with uClinux, by default, doesn't build for the >> >> M5208 - the m68k assembler uses instructions dropped from early >> >> Coldfires. >> >> The hack I'm using locally is to configure with --host=none (I got >> >> this trick second hand from somewhere). >> >> >> >> Anyway I noticed that libgmp is, er, a little out-of-date. The latest >> >> version has --disable-assembly which looks to be a cleaner way to >> >> handle the assembler problem. >> >> (How to decide when to configure with that option is an open question, >> >> a Kconfig option). >> >> >> >> As anyone looked at updating this; or to turn the question round, is >> >> there anything needed in the existing version that would prevent this? >> > >> > >> > Nothing stopping updating as far as I know. >> > >> > Can I suggest that if you do decide to update it that you convert >> > it to automake building. >> >> Yes, that's the plan. I've noticed that the framework's improved >> significantly over the years and I've been able to drop some of my >> local hacks. >> >> > The trend over the last couple of years >> > is that if we are updating a package then convert it. There >> > are quite a few examples to follow in the lib directory. Just >> > look for directories that contain a "makefile" and optionally a >> > patches directory and not much else. >> >> Any pointers for how to handle --disable-assembly configure option? >> For instance, since libreswan requires libgmp, it would have: >> select LIB_LIBGMP >> but libreswan doesn't know if --disable-assembly is required, that >> would be set by a vendor/platform files? > > Yep, make that part of the libgmp setup. If you switch to automake you > can add that option to a Kconfig in the libgmp directory, again, there > are quite a few examples in the tree. some have their own Kconfig files: > > grep -l automake lib/*/makefile user/*/makefile > > ls lib/*/Kconfig user/*/Kconfig > > to find them all. > > Cheers, > Davidm > > -- > David McCullough, davidm at spottygum.com, Ph: 0410 560 763 > _______________________________________________ > uClinux-dev mailing list > uClinux-dev at uclinux.org > http://mailman.uclinux.org/mailman/listinfo/uclinux-dev > This message was resent by uclinux-dev at uclinux.org > To unsubscribe see: > http://mailman.uclinux.org/mailman/options/uclinux-dev -------------- next part -------------- A non-text attachment was scrubbed... Name: Kconfig Type: application/octet-stream Size: 1063 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: makefile Type: application/octet-stream Size: 819 bytes Desc: not available URL: From andrew.cagney at gmail.com Fri Dec 11 12:50:20 2015 From: andrew.cagney at gmail.com (Andrew Cagney) Date: Fri, 11 Dec 2015 12:50:20 -0500 Subject: [uClinux-dev] nspr Message-ID: The patch "nspr.diff" adds a standalone and up-to-date NSPR library. It is always built statically. For the patches: nspr-00--done--nspr-configure-in--m68k-is-not-m68020-60.patch I believe it's been accepted nspr-02--hold--ifdef-have-dlfcn-h.patch: it's been submitted and hopefully accepted nspr-03--todo--barf-fork-call.patch: hack: I don't think s/fork/vfork/ would work here, and since I don't need it to work I took the easy way out I should point out that while Mozilla thinks NSPR and NSS should go hand-in-hand (per the current lib/nss directory which tries to build both) I found things became much easier when I split those two and built them separately (NSPR uses autoconf, abet incorrectly; NSS uses GNU make; NSS+NSPR uses GNU make to invoke autoconf ....). The patch "wip-nss.diff" (do not apply) hints at how I'm getting lib/nss to use the previously built NSPR Andrew -------------- next part -------------- diff --git a/lib/nspr/.gitignore b/lib/nspr/.gitignore new file mode 100644 index 0000000..dc3f997 --- /dev/null +++ b/lib/nspr/.gitignore @@ -0,0 +1,2 @@ +/build +/downloads diff --git a/lib/nspr/makefile b/lib/nspr/makefile new file mode 100644 index 0000000..e195237 --- /dev/null +++ b/lib/nspr/makefile @@ -0,0 +1,20 @@ +URL = https://ftp.mozilla.org/pub/nspr/releases/v4.11/src/nspr-4.11.tar.gz + +NVR = $(subst -, , $(patsubst %.tar.gz,%,$(notdir $(URL)))) +PKG = $(word 1,$(NVR)) +VERSION = $(word 2,$(NVR)) +SRCDIR = $(PKG)-$(VERSION) +BUILDDIR = $(SRCDIR)/nspr + +# $(AUTORECONF) is run from $(SRCDIR), not $(BUILDDIR) +AUTORECONF = cd nspr ; autoconf + +include $(ROOTDIR)/tools/automake.inc + +# Disable build of shared library. Should this be controled by +# automake.mk somehow? +MAKEVARS = 'SHARED_LIBRARY=' + +# When it comes to the definition of build, host, and target, Mozilla +# are still living in the 90's: target->[] build->host host->target. +CONFIGURE_OPTS:=$(patsubst --build=%,--host=%,$(patsubst --host=%,--target=%,$(patsubst --target=%,,$(CONFIGURE_OPTS)))) diff --git a/lib/nspr/patches/nspr-00--done--nspr-configure-in--m68k-is-not-m68020-60.patch b/lib/nspr/patches/nspr-00--done--nspr-configure-in--m68k-is-not-m68020-60.patch new file mode 100644 index 0000000..bbdced2 --- /dev/null +++ b/lib/nspr/patches/nspr-00--done--nspr-configure-in--m68k-is-not-m68020-60.patch @@ -0,0 +1,11 @@ +--- nspr-4.10.9/nspr/configure.in.orig 2015-11-25 15:17:14.732725317 -0500 ++++ nspr-4.10.9/nspr/configure.in 2015-11-25 20:09:38.299725384 -0500 +@@ -1857,8 +1865,4 @@ + fi + ;; +- m68k) +- CFLAGS="$CFLAGS -m68020-60" +- CXXFLAGS="$CXXFLAGS -m68020-60" +- ;; + esac + ;; diff --git a/lib/nspr/patches/nspr-02--hold--ifdef-have-dlfcn-h.patch b/lib/nspr/patches/nspr-02--hold--ifdef-have-dlfcn-h.patch new file mode 100644 index 0000000..7f80842 --- /dev/null +++ b/lib/nspr/patches/nspr-02--hold--ifdef-have-dlfcn-h.patch @@ -0,0 +1,57 @@ +--- nspr-4.11/nspr/configure.in.orig 2015-12-02 12:38:53.626997958 -0500 ++++ nspr-4.11/nspr/configure.in 2015-12-02 13:55:03.438024691 -0500 +@@ -2518,8 +2518,9 @@ + *-darwin*|*-beos*|*-os2*) + ;; + *) ++ dnl define HAVE_DLFCN_H when present + AC_CHECK_LIB(dl, dlopen, +- [AC_CHECK_HEADER(dlfcn.h, ++ [AC_CHECK_HEADERS(dlfcn.h, + OS_LIBS="-ldl $OS_LIBS")]) + ;; + esac +--- nspr-4.11/nspr/pr/include/md/_linux.h.orig 2015-12-02 14:06:23.694020882 -0500 ++++ nspr-4.11/nspr/pr/include/md/_linux.h 2015-12-02 14:07:37.706046831 -0500 +@@ -74,10 +74,12 @@ + #undef HAVE_STACK_GROWING_UP + + /* +- * Elf linux supports dl* functions ++ * Elf linux supports dl* functions but uClinux may not. + */ ++#if defined(HAVE_DLFCN_H) + #define HAVE_DLL + #define USE_DLFCN ++#endif + #if defined(ANDROID) + #define NO_DLOPEN_NULL + #endif +--- nspr-4.11/nspr/pr/src/pthreads/ptthread.c.orig 2015-11-18 07:36:52.000000000 -0500 ++++ nspr-4.11/nspr/pr/src/pthreads/ptthread.c 2015-12-02 14:15:10.850057366 -0500 +@@ -19,7 +19,9 @@ + #include + #include + #include ++#ifdef HAVE_DLFCN_H + #include ++#endif + + #ifdef SYMBIAN + /* In Open C sched_get_priority_min/max do not work properly, so we undefine +@@ -1764,6 +1766,7 @@ + int (*dynamic_pthread_setname_np)(pthread_t, const char*); + #endif + ++#if defined(HAVE_DLL) + *(void**)(&dynamic_pthread_setname_np) = + dlsym(RTLD_DEFAULT, "pthread_setname_np"); + if (!dynamic_pthread_setname_np) +@@ -1801,6 +1804,7 @@ + PR_SetError(PR_UNKNOWN_ERROR, result); + return PR_FAILURE; + } ++#endif /* HAVE_DLL */ + return PR_SUCCESS; + } + diff --git a/lib/nspr/patches/nspr-03--todo--barf-fork-call.patch b/lib/nspr/patches/nspr-03--todo--barf-fork-call.patch new file mode 100644 index 0000000..5c17255 --- /dev/null +++ b/lib/nspr/patches/nspr-03--todo--barf-fork-call.patch @@ -0,0 +1,31 @@ +For moment, when no fork() replace the call with a barf. +Should, perhaps, eventually look at changing the code to +be vfork proof. + +--- nspr-4.11/nspr/configure.in.LSW 2015-12-04 12:22:02.942504176 -0500 ++++ nspr-4.11/nspr/configure.in 2015-12-04 12:23:32.594522058 -0500 +@@ -2540,7 +2540,7 @@ + AC_PROG_GCC_TRADITIONAL + _SAVE_LIBS="$LIBS" + LIBS="$LIBS $OS_LIBS" +-AC_CHECK_FUNCS(dladdr gettid lchown setpriority strerror syscall) ++AC_CHECK_FUNCS(dladdr gettid lchown setpriority strerror syscall fork) + LIBS="$_SAVE_LIBS" + + dnl ======================================================== +--- nspr-4.11/nspr/pr/src/md/unix/uxproces.c.LSW 2015-12-04 12:21:59.453465794 -0500 ++++ nspr-4.11/nspr/pr/src/md/unix/uxproces.c 2015-12-04 12:25:52.282503511 -0500 +@@ -237,8 +237,12 @@ + if (fd_map[2] != 2) + close(fd_map[2]); + } +-#else ++#elif defined(HAVE_FORK) + process->md.pid = fork(); ++#else ++ /* XXX: code that follows isn't exactly vfork() proof so just fail. */ ++ fprintf(stderr, "XXX: barfing fork() call\n"); ++ process->md.pid = -1; + #endif + if ((pid_t) -1 == process->md.pid) { + PR_SetError(PR_INSUFFICIENT_RESOURCES_ERROR, errno); -------------- next part -------------- diff --git a/lib/nss/makefile b/lib/nss/makefile index 95ad618..7db8f8a 100644 --- a/lib/nss/makefile +++ b/lib/nss/makefile @@ -1,8 +1,32 @@ - URL := ftp://ftp.mozilla.org/pub/mozilla.org/security/nss/releases/NSS_3_17_4_RTM/src/nss-3.17.4-with-nspr-4.10.7.tar.gz -BUILDDIR = nss-3.17.4 -CONFIGURE = : +# pluck out the nss version +NVR = $(subst -, , $(patsubst %.tar.gz,%,$(notdir $(URL)))) +PKG = $(word 1,$(NVR)) +VERSION = $(word 2,$(NVR)) +# Building happens within the NSS sub-directory +SRCDIR = $(PKG)-$(VERSION) +BUILDDIR = $(SRCDIR)/nss + +# skip NSPR +BUILD = all + +# Copies stuff from dist to where it should be. +INSTALLTARGET = install-dist + +MAKEVARS = \ + OS_TARGET=uClinux-dist OS_RELEASE= \ + NSPR_INCLUDE_DIR=$(STAGEDIR)/include/nspr \ + NSPR_LIB_DIR=$(STAGEDIR)/lib include $(ROOTDIR)/tools/automake.inc +build/%-$(INSTALLTARGET): build/%-$(BUILDTARGET) + rm -rf build/$*-install + mkdir -p build/$*-install + : include + cp -v -r build/$(SRCDIR)/dist/public build/$*-install/include + : lib + cp -v -r build/$(SRCDIR)/dist/uClinux-dist/lib build/$*-install/lib + : bin + cp -v build/$(SRCDIR)/dist/uClinux-dist/bin build/$*-install/bin From gerg at uclinux.org Sun Dec 13 19:39:08 2015 From: gerg at uclinux.org (Greg Ungerer) Date: Mon, 14 Dec 2015 10:39:08 +1000 Subject: [uClinux-dev] support .lz (lzip) compression In-Reply-To: References: Message-ID: <566E0FAC.4020803@uclinux.org> Hi Andrew, On 11/12/15 06:07, Andrew Cagney wrote: > Surprise! libgmp uses yet another compression format ... > > My work-in-progress libgmp makefile tests it, trust me :-) Thanks, that looks good. I'll apply that to the working tree. Regards Greg From gerg at uclinux.org Sun Dec 13 19:43:04 2015 From: gerg at uclinux.org (Greg Ungerer) Date: Mon, 14 Dec 2015 10:43:04 +1000 Subject: [uClinux-dev] out-of-date libgmp / building for M5208 In-Reply-To: References: <5666C703.1000809@uclinux.org> <20151209223527.GB13464@spottygum.com> Message-ID: <566E1098.2040100@uclinux.org> Hi Andrew, On 12/12/15 03:03, Andrew Cagney wrote: > I came up with the attached. The existing libgmp configuration in > lib/Kconfig would need removing. I would suggest not bothering to make it a menu on its own. And the config entry for LIB_LIBGMP_DISABLE_ASSEMBLY should have a "depends on LIB_LIBGMP". Otherwise it is looking good. Regards Greg > On 9 December 2015 at 17:35, David McCullough wrote: >> >> Andrew Cagney wrote the following: >>> On 8 December 2015 at 07:03, Greg Ungerer wrote: >>>> Hi Andrew, >>>> >>>> On 08/12/15 04:23, Andrew Cagney wrote: >>>>> >>>>> The libgmp bundled with uClinux, by default, doesn't build for the >>>>> M5208 - the m68k assembler uses instructions dropped from early >>>>> Coldfires. >>>>> The hack I'm using locally is to configure with --host=none (I got >>>>> this trick second hand from somewhere). >>>>> >>>>> Anyway I noticed that libgmp is, er, a little out-of-date. The latest >>>>> version has --disable-assembly which looks to be a cleaner way to >>>>> handle the assembler problem. >>>>> (How to decide when to configure with that option is an open question, >>>>> a Kconfig option). >>>>> >>>>> As anyone looked at updating this; or to turn the question round, is >>>>> there anything needed in the existing version that would prevent this? >>>> >>>> >>>> Nothing stopping updating as far as I know. >>>> >>>> Can I suggest that if you do decide to update it that you convert >>>> it to automake building. >>> >>> Yes, that's the plan. I've noticed that the framework's improved >>> significantly over the years and I've been able to drop some of my >>> local hacks. >>> >>>> The trend over the last couple of years >>>> is that if we are updating a package then convert it. There >>>> are quite a few examples to follow in the lib directory. Just >>>> look for directories that contain a "makefile" and optionally a >>>> patches directory and not much else. >>> >>> Any pointers for how to handle --disable-assembly configure option? >>> For instance, since libreswan requires libgmp, it would have: >>> select LIB_LIBGMP >>> but libreswan doesn't know if --disable-assembly is required, that >>> would be set by a vendor/platform files? >> >> Yep, make that part of the libgmp setup. If you switch to automake you >> can add that option to a Kconfig in the libgmp directory, again, there >> are quite a few examples in the tree. some have their own Kconfig files: >> >> grep -l automake lib/*/makefile user/*/makefile >> >> ls lib/*/Kconfig user/*/Kconfig >> >> to find them all. >> >> Cheers, >> Davidm >> >> -- >> David McCullough, davidm at spottygum.com, Ph: 0410 560 763 >> _______________________________________________ >> uClinux-dev mailing list >> uClinux-dev at uclinux.org >> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev >> This message was resent by uclinux-dev at uclinux.org >> To unsubscribe see: >> http://mailman.uclinux.org/mailman/options/uclinux-dev >> >> >> _______________________________________________ >> uClinux-dev mailing list >> uClinux-dev at uclinux.org >> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev >> This message was resent by uclinux-dev at uclinux.org >> To unsubscribe see: >> http://mailman.uclinux.org/mailman/options/uclinux-dev From gerg at uclinux.org Sun Dec 13 20:35:45 2015 From: gerg at uclinux.org (Greg Ungerer) Date: Mon, 14 Dec 2015 11:35:45 +1000 Subject: [uClinux-dev] out-of-date libgmp / building for M5208 In-Reply-To: References: <5666C703.1000809@uclinux.org> <20151209223527.GB13464@spottygum.com> Message-ID: <566E1CF1.5020108@uclinux.org> Hi Andrew, On 12/12/15 03:03, Andrew Cagney wrote: > I came up with the attached. The existing libgmp configuration in > lib/Kconfig would need removing. Just a heads up... But some other targets in the tree that currently have libgmp enabled no longer compile with this in place. For example building an ARM target fails at: ... Executing: /bin/sh -c 'ucfront-gcc' 'arm-linux-gnueabi-20150104-gcc' '-std=gnu99' '-DHAVE_CONFIG_H' '-I.' '-D__GMP_WITHIN_GMP' '-O1' '-pipe' '-fno-common' '-fno-builtin' '-Wall' '-Dlinux' '-D__linux__' '-Dunix' '-DEMBED' '-c' 'tal-reent.c' '-fPIC' '-o' 'tal-reent.o' Executing: touch tal-reent.lo make[5]: *** No rule to make target `mpn/add_n.lo', needed by `libgmp.la'. Stop. make[5]: Leaving directory `/home/gerg/uclinux-dist.foo/lib/libgmp/build/gmp-6.1.0' make[4]: *** [all-recursive] Error 1 Regards Greg > On 9 December 2015 at 17:35, David McCullough wrote: >> >> Andrew Cagney wrote the following: >>> On 8 December 2015 at 07:03, Greg Ungerer wrote: >>>> Hi Andrew, >>>> >>>> On 08/12/15 04:23, Andrew Cagney wrote: >>>>> >>>>> The libgmp bundled with uClinux, by default, doesn't build for the >>>>> M5208 - the m68k assembler uses instructions dropped from early >>>>> Coldfires. >>>>> The hack I'm using locally is to configure with --host=none (I got >>>>> this trick second hand from somewhere). >>>>> >>>>> Anyway I noticed that libgmp is, er, a little out-of-date. The latest >>>>> version has --disable-assembly which looks to be a cleaner way to >>>>> handle the assembler problem. >>>>> (How to decide when to configure with that option is an open question, >>>>> a Kconfig option). >>>>> >>>>> As anyone looked at updating this; or to turn the question round, is >>>>> there anything needed in the existing version that would prevent this? >>>> >>>> >>>> Nothing stopping updating as far as I know. >>>> >>>> Can I suggest that if you do decide to update it that you convert >>>> it to automake building. >>> >>> Yes, that's the plan. I've noticed that the framework's improved >>> significantly over the years and I've been able to drop some of my >>> local hacks. >>> >>>> The trend over the last couple of years >>>> is that if we are updating a package then convert it. There >>>> are quite a few examples to follow in the lib directory. Just >>>> look for directories that contain a "makefile" and optionally a >>>> patches directory and not much else. >>> >>> Any pointers for how to handle --disable-assembly configure option? >>> For instance, since libreswan requires libgmp, it would have: >>> select LIB_LIBGMP >>> but libreswan doesn't know if --disable-assembly is required, that >>> would be set by a vendor/platform files? >> >> Yep, make that part of the libgmp setup. If you switch to automake you >> can add that option to a Kconfig in the libgmp directory, again, there >> are quite a few examples in the tree. some have their own Kconfig files: >> >> grep -l automake lib/*/makefile user/*/makefile >> >> ls lib/*/Kconfig user/*/Kconfig >> >> to find them all. >> >> Cheers, >> Davidm >> >> -- >> David McCullough, davidm at spottygum.com, Ph: 0410 560 763 >> _______________________________________________ >> uClinux-dev mailing list >> uClinux-dev at uclinux.org >> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev >> This message was resent by uclinux-dev at uclinux.org >> To unsubscribe see: >> http://mailman.uclinux.org/mailman/options/uclinux-dev >> >> >> _______________________________________________ >> uClinux-dev mailing list >> uClinux-dev at uclinux.org >> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev >> This message was resent by uclinux-dev at uclinux.org >> To unsubscribe see: >> http://mailman.uclinux.org/mailman/options/uclinux-dev From andrew.cagney at gmail.com Sun Dec 13 21:18:57 2015 From: andrew.cagney at gmail.com (Andrew Cagney) Date: Sun, 13 Dec 2015 21:18:57 -0500 Subject: [uClinux-dev] out-of-date libgmp / building for M5208 In-Reply-To: <566E1098.2040100@uclinux.org> References: <5666C703.1000809@uclinux.org> <20151209223527.GB13464@spottygum.com> <566E1098.2040100@uclinux.org> Message-ID: On 13 December 2015 at 19:43, Greg Ungerer wrote: > Hi Andrew, > > On 12/12/15 03:03, Andrew Cagney wrote: >> I came up with the attached. The existing libgmp configuration in >> lib/Kconfig would need removing. > > I would suggest not bothering to make it a menu on its own. > And the config entry for LIB_LIBGMP_DISABLE_ASSEMBLY should > have a "depends on LIB_LIBGMP". I tried that. Consider: - target board is M5208EVB which isn't supported by libgmp's assembly files - libreswan requires libgmp so it's Kconfig includes a line to enable building libgmp So the developer uses menuconfig, selects "libreswan", and builds. Unfortunately it fails because the disable-assembly option needs to be set manually. Having it as a separate flag and not requiring LIB_LIBGMP made it possible to save it in the vendor config file regardless of LIB_LIBGMP status. idea's welcome. - LIB_LIBGMP is some > Otherwise it is looking good. > > Regards > Greg From gerg at uclinux.org Sun Dec 13 23:32:36 2015 From: gerg at uclinux.org (Greg Ungerer) Date: Mon, 14 Dec 2015 14:32:36 +1000 Subject: [uClinux-dev] out-of-date libgmp / building for M5208 In-Reply-To: References: <5666C703.1000809@uclinux.org> <20151209223527.GB13464@spottygum.com> <566E1098.2040100@uclinux.org> Message-ID: <566E4664.5060103@uclinux.org> Hi Andrew, On 14/12/15 12:18, Andrew Cagney wrote: > On 13 December 2015 at 19:43, Greg Ungerer wrote: >> Hi Andrew, >> >> On 12/12/15 03:03, Andrew Cagney wrote: >>> I came up with the attached. The existing libgmp configuration in >>> lib/Kconfig would need removing. >> >> I would suggest not bothering to make it a menu on its own. >> And the config entry for LIB_LIBGMP_DISABLE_ASSEMBLY should >> have a "depends on LIB_LIBGMP". > > I tried that. Consider: > > - target board is M5208EVB which isn't supported by libgmp's assembly files > > - libreswan requires libgmp so it's Kconfig includes a line to enable > building libgmp > > So the developer uses menuconfig, selects "libreswan", and builds. > > Unfortunately it fails because the disable-assembly option needs to be > set manually. > > Having it as a separate flag and not requiring LIB_LIBGMP made it > possible to save it in the vendor config file regardless of LIB_LIBGMP > status. But what user would set the disable assembler option correctly when they don't even think they need libgmp? I don't think it logically follows that it should be an always selectable option. > idea's welcome. In your example above it is not the M5208EVB that is the selection criteria. It is probably the fact that a ColdFire architecture CPU is the target. Maybe make time setting would work better in this case. Have a look in the lib/libssl/makefile for an example that has to solve a similar problem. Regards Greg From andrew.cagney at gmail.com Mon Dec 14 10:11:26 2015 From: andrew.cagney at gmail.com (Andrew Cagney) Date: Mon, 14 Dec 2015 10:11:26 -0500 Subject: [uClinux-dev] out-of-date libgmp / building for M5208 In-Reply-To: <566E4664.5060103@uclinux.org> References: <5666C703.1000809@uclinux.org> <20151209223527.GB13464@spottygum.com> <566E1098.2040100@uclinux.org> <566E4664.5060103@uclinux.org> Message-ID: On 13 December 2015 at 23:32, Greg Ungerer wrote: > Hi Andrew, > > On 14/12/15 12:18, Andrew Cagney wrote: >> On 13 December 2015 at 19:43, Greg Ungerer wrote: >>> Hi Andrew, >>> >>> On 12/12/15 03:03, Andrew Cagney wrote: >>>> I came up with the attached. The existing libgmp configuration in >>>> lib/Kconfig would need removing. >>> >>> I would suggest not bothering to make it a menu on its own. >>> And the config entry for LIB_LIBGMP_DISABLE_ASSEMBLY should >>> have a "depends on LIB_LIBGMP". >> >> I tried that. Consider: >> >> - target board is M5208EVB which isn't supported by libgmp's assembly files >> >> - libreswan requires libgmp so it's Kconfig includes a line to enable >> building libgmp >> >> So the developer uses menuconfig, selects "libreswan", and builds. >> >> Unfortunately it fails because the disable-assembly option needs to be >> set manually. >> >> Having it as a separate flag and not requiring LIB_LIBGMP made it >> possible to save it in the vendor config file regardless of LIB_LIBGMP >> status. > > But what user would set the disable assembler option correctly > when they don't even think they need libgmp? I don't think it > logically follows that it should be an always selectable option. > > >> idea's welcome. > > In your example above it is not the M5208EVB that is the selection > criteria. It is probably the fact that a ColdFire architecture CPU > is the target. > > Maybe make time setting would work better in this case. Have a look > in the lib/libssl/makefile for an example that has to solve a > similar problem. Yea, that's along the lines of my plan B - put the matic closer to the problem in lib/libgmp/makefile. Thanks for the pointer. Andrew From andrew.cagney at gmail.com Mon Dec 14 11:11:42 2015 From: andrew.cagney at gmail.com (Andrew Cagney) Date: Mon, 14 Dec 2015 11:11:42 -0500 Subject: [uClinux-dev] out-of-date libgmp / building for M5208 In-Reply-To: <566E1CF1.5020108@uclinux.org> References: <5666C703.1000809@uclinux.org> <20151209223527.GB13464@spottygum.com> <566E1CF1.5020108@uclinux.org> Message-ID: On 13 December 2015 at 20:35, Greg Ungerer wrote: > Hi Andrew, > > On 12/12/15 03:03, Andrew Cagney wrote: >> I came up with the attached. The existing libgmp configuration in >> lib/Kconfig would need removing. > > Just a heads up... But some other targets in the tree that > currently have libgmp enabled no longer compile with this > in place. > > For example building an ARM target fails at: > > ... > Executing: /bin/sh -c 'ucfront-gcc' 'arm-linux-gnueabi-20150104-gcc' '-std=gnu99' '-DHAVE_CONFIG_H' '-I.' '-D__GMP_WITHIN_GMP' '-O1' '-pipe' '-fno-common' '-fno-builtin' '-Wall' '-Dlinux' '-D__linux__' '-Dunix' '-DEMBED' '-c' 'tal-reent.c' '-fPIC' '-o' 'tal-reent.o' > Executing: touch tal-reent.lo > make[5]: *** No rule to make target `mpn/add_n.lo', needed by `libgmp.la'. Stop. > make[5]: Leaving directory `/home/gerg/uclinux-dist.foo/lib/libgmp/build/gmp-6.1.0' > make[4]: *** [all-recursive] Error 1 What happens if you point the URL at 5.x series, for instance: https://gmplib.org/download/gmp/gmp-5.1.3.tar.xz This thread: http://stackoverflow.com/a/16726435/1357163 lead me to this patch: https://gmplib.org/repo/gmp-5.1/rev/2347fd4901ad which I don't seem to be able to find in 6.x's ChangeLog. (and of course, just my luck that --disable-assembly was only added in 6.x) > Regards > Greg > > > >> On 9 December 2015 at 17:35, David McCullough wrote: >>> >>> Andrew Cagney wrote the following: >>>> On 8 December 2015 at 07:03, Greg Ungerer wrote: >>>>> Hi Andrew, >>>>> >>>>> On 08/12/15 04:23, Andrew Cagney wrote: >>>>>> >>>>>> The libgmp bundled with uClinux, by default, doesn't build for the >>>>>> M5208 - the m68k assembler uses instructions dropped from early >>>>>> Coldfires. >>>>>> The hack I'm using locally is to configure with --host=none (I got >>>>>> this trick second hand from somewhere). >>>>>> >>>>>> Anyway I noticed that libgmp is, er, a little out-of-date. The latest >>>>>> version has --disable-assembly which looks to be a cleaner way to >>>>>> handle the assembler problem. >>>>>> (How to decide when to configure with that option is an open question, >>>>>> a Kconfig option). >>>>>> >>>>>> As anyone looked at updating this; or to turn the question round, is >>>>>> there anything needed in the existing version that would prevent this? >>>>> >>>>> >>>>> Nothing stopping updating as far as I know. >>>>> >>>>> Can I suggest that if you do decide to update it that you convert >>>>> it to automake building. >>>> >>>> Yes, that's the plan. I've noticed that the framework's improved >>>> significantly over the years and I've been able to drop some of my >>>> local hacks. >>>> >>>>> The trend over the last couple of years >>>>> is that if we are updating a package then convert it. There >>>>> are quite a few examples to follow in the lib directory. Just >>>>> look for directories that contain a "makefile" and optionally a >>>>> patches directory and not much else. >>>> >>>> Any pointers for how to handle --disable-assembly configure option? >>>> For instance, since libreswan requires libgmp, it would have: >>>> select LIB_LIBGMP >>>> but libreswan doesn't know if --disable-assembly is required, that >>>> would be set by a vendor/platform files? >>> >>> Yep, make that part of the libgmp setup. If you switch to automake you >>> can add that option to a Kconfig in the libgmp directory, again, there >>> are quite a few examples in the tree. some have their own Kconfig files: >>> >>> grep -l automake lib/*/makefile user/*/makefile >>> >>> ls lib/*/Kconfig user/*/Kconfig >>> >>> to find them all. >>> >>> Cheers, >>> Davidm >>> >>> -- >>> David McCullough, davidm at spottygum.com, Ph: 0410 560 763 >>> _______________________________________________ >>> uClinux-dev mailing list >>> uClinux-dev at uclinux.org >>> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev >>> This message was resent by uclinux-dev at uclinux.org >>> To unsubscribe see: >>> http://mailman.uclinux.org/mailman/options/uclinux-dev >>> >>> >>> _______________________________________________ >>> uClinux-dev mailing list >>> uClinux-dev at uclinux.org >>> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev >>> This message was resent by uclinux-dev at uclinux.org >>> To unsubscribe see: >>> http://mailman.uclinux.org/mailman/options/uclinux-dev > > _______________________________________________ > uClinux-dev mailing list > uClinux-dev at uclinux.org > http://mailman.uclinux.org/mailman/listinfo/uclinux-dev > This message was resent by uclinux-dev at uclinux.org > To unsubscribe see: > http://mailman.uclinux.org/mailman/options/uclinux-dev From gerg at uclinux.org Tue Dec 15 00:32:20 2015 From: gerg at uclinux.org (Greg Ungerer) Date: Tue, 15 Dec 2015 15:32:20 +1000 Subject: [uClinux-dev] out-of-date libgmp / building for M5208 In-Reply-To: References: <5666C703.1000809@uclinux.org> <20151209223527.GB13464@spottygum.com> <566E1CF1.5020108@uclinux.org> Message-ID: <566FA5E4.4000005@uclinux.org> Hi Andrew, On 15/12/15 02:11, Andrew Cagney wrote: > On 13 December 2015 at 20:35, Greg Ungerer wrote: >> On 12/12/15 03:03, Andrew Cagney wrote: >>> I came up with the attached. The existing libgmp configuration in >>> lib/Kconfig would need removing. >> >> Just a heads up... But some other targets in the tree that >> currently have libgmp enabled no longer compile with this >> in place. >> >> For example building an ARM target fails at: >> >> ... >> Executing: /bin/sh -c 'ucfront-gcc' 'arm-linux-gnueabi-20150104-gcc' '-std=gnu99' '-DHAVE_CONFIG_H' '-I.' '-D__GMP_WITHIN_GMP' '-O1' '-pipe' '-fno-common' '-fno-builtin' '-Wall' '-Dlinux' '-D__linux__' '-Dunix' '-DEMBED' '-c' 'tal-reent.c' '-fPIC' '-o' 'tal-reent.o' >> Executing: touch tal-reent.lo >> make[5]: *** No rule to make target `mpn/add_n.lo', needed by `libgmp.la'. Stop. >> make[5]: Leaving directory `/home/gerg/uclinux-dist.foo/lib/libgmp/build/gmp-6.1.0' >> make[4]: *** [all-recursive] Error 1 > > What happens if you point the URL at 5.x series, for instance: > https://gmplib.org/download/gmp/gmp-5.1.3.tar.xz Same result. Fails to build with same error. > This thread: > http://stackoverflow.com/a/16726435/1357163 > lead me to this patch: > https://gmplib.org/repo/gmp-5.1/rev/2347fd4901ad > which I don't seem to be able to find in 6.x's ChangeLog. The problem doesn't appear to be ARM specific. I tried a compile of an x86_64 target and it failed in a similar way: make[5]: *** No rule to make target `mpn/invert_limb_table.lo', needed by `libgmp.la'. Stop. Regards Greg > (and of course, just my luck that --disable-assembly was only added in 6.x) > > >> Regards >> Greg >> >> >> >>> On 9 December 2015 at 17:35, David McCullough wrote: >>>> >>>> Andrew Cagney wrote the following: >>>>> On 8 December 2015 at 07:03, Greg Ungerer wrote: >>>>>> Hi Andrew, >>>>>> >>>>>> On 08/12/15 04:23, Andrew Cagney wrote: >>>>>>> >>>>>>> The libgmp bundled with uClinux, by default, doesn't build for the >>>>>>> M5208 - the m68k assembler uses instructions dropped from early >>>>>>> Coldfires. >>>>>>> The hack I'm using locally is to configure with --host=none (I got >>>>>>> this trick second hand from somewhere). >>>>>>> >>>>>>> Anyway I noticed that libgmp is, er, a little out-of-date. The latest >>>>>>> version has --disable-assembly which looks to be a cleaner way to >>>>>>> handle the assembler problem. >>>>>>> (How to decide when to configure with that option is an open question, >>>>>>> a Kconfig option). >>>>>>> >>>>>>> As anyone looked at updating this; or to turn the question round, is >>>>>>> there anything needed in the existing version that would prevent this? >>>>>> >>>>>> >>>>>> Nothing stopping updating as far as I know. >>>>>> >>>>>> Can I suggest that if you do decide to update it that you convert >>>>>> it to automake building. >>>>> >>>>> Yes, that's the plan. I've noticed that the framework's improved >>>>> significantly over the years and I've been able to drop some of my >>>>> local hacks. >>>>> >>>>>> The trend over the last couple of years >>>>>> is that if we are updating a package then convert it. There >>>>>> are quite a few examples to follow in the lib directory. Just >>>>>> look for directories that contain a "makefile" and optionally a >>>>>> patches directory and not much else. >>>>> >>>>> Any pointers for how to handle --disable-assembly configure option? >>>>> For instance, since libreswan requires libgmp, it would have: >>>>> select LIB_LIBGMP >>>>> but libreswan doesn't know if --disable-assembly is required, that >>>>> would be set by a vendor/platform files? >>>> >>>> Yep, make that part of the libgmp setup. If you switch to automake you >>>> can add that option to a Kconfig in the libgmp directory, again, there >>>> are quite a few examples in the tree. some have their own Kconfig files: >>>> >>>> grep -l automake lib/*/makefile user/*/makefile >>>> >>>> ls lib/*/Kconfig user/*/Kconfig >>>> >>>> to find them all. >>>> >>>> Cheers, >>>> Davidm >>>> >>>> -- >>>> David McCullough, davidm at spottygum.com, Ph: 0410 560 763 >>>> _______________________________________________ >>>> uClinux-dev mailing list >>>> uClinux-dev at uclinux.org >>>> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev >>>> This message was resent by uclinux-dev at uclinux.org >>>> To unsubscribe see: >>>> http://mailman.uclinux.org/mailman/options/uclinux-dev >>>> >>>> >>>> _______________________________________________ >>>> uClinux-dev mailing list >>>> uClinux-dev at uclinux.org >>>> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev >>>> This message was resent by uclinux-dev at uclinux.org >>>> To unsubscribe see: >>>> http://mailman.uclinux.org/mailman/options/uclinux-dev >> >> _______________________________________________ >> uClinux-dev mailing list >> uClinux-dev at uclinux.org >> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev >> This message was resent by uclinux-dev at uclinux.org >> To unsubscribe see: >> http://mailman.uclinux.org/mailman/options/uclinux-dev > _______________________________________________ > uClinux-dev mailing list > uClinux-dev at uclinux.org > http://mailman.uclinux.org/mailman/listinfo/uclinux-dev > This message was resent by uclinux-dev at uclinux.org > To unsubscribe see: > http://mailman.uclinux.org/mailman/options/uclinux-dev > From kreolekragol at free.fr Thu Dec 17 08:28:55 2015 From: kreolekragol at free.fr (kreolekragol at free.fr) Date: Thu, 17 Dec 2015 14:28:55 +0100 Subject: [uClinux-dev] Fw: important message Message-ID: <0000136ab9e6$5ef55734$1087a5cc$@free.fr> Hello! New message, please read kreolekragol at free.fr -------------- next part -------------- An HTML attachment was scrubbed... URL: From geert at linux-m68k.org Fri Dec 18 09:27:21 2015 From: geert at linux-m68k.org (Geert Uytterhoeven) Date: Fri, 18 Dec 2015 15:27:21 +0100 Subject: [uClinux-dev] [PATCH] serial: Remove 68328 driver In-Reply-To: <1450438103-1059-1-git-send-email-frederik.voelkel@fau.de> References: <1449830170-15096-1-git-send-email-frederik.voelkel@fau.de> <1450438103-1059-1-git-send-email-frederik.voelkel@fau.de> Message-ID: CC linux-m68k, uClinux-dev On Fri, Dec 18, 2015 at 12:28 PM, Frederik V?lkel wrote: > It's old, messy and mostly unmaintained. > Remove it as suggested by Peter Hurley and Alan. > > Signed-off-by: Frederik V?lkel > Signed-off-by: Lukas Braun > --- > Should we remove other drivers like framebuffer as well? > It is probably useless without serial support. > --- > drivers/tty/serial/68328serial.c | 1322 -------------------------------------- > drivers/tty/serial/Kconfig | 11 - > drivers/tty/serial/Makefile | 1 - > 3 files changed, 1334 deletions(-) > delete mode 100644 drivers/tty/serial/68328serial.c > > diff --git a/drivers/tty/serial/68328serial.c b/drivers/tty/serial/68328serial.c > deleted file mode 100644 > index 0140ba4..0000000 > --- a/drivers/tty/serial/68328serial.c > +++ /dev/null > @@ -1,1322 +0,0 @@ > -/* 68328serial.c: Serial port driver for 68328 microcontroller > - * > - * Copyright (C) 1995 David S. Miller > - * Copyright (C) 1998 Kenneth Albanowski > - * Copyright (C) 1998, 1999 D. Jeff Dionne > - * Copyright (C) 1999 Vladimir Gurevich > - * Copyright (C) 2002-2003 David McCullough > - * Copyright (C) 2002 Greg Ungerer > - * > - * VZ Support/Fixes Evan Stawnyczy > - * Multiple UART support Daniel Potts > - * Power management support Daniel Potts > - * VZ Second Serial Port enable Phil Wilshire > - * 2.4/2.5 port David McCullough > - */ > - > -#include > -#include > -#include > -#include > -#include > -#include > -#include > -#include > -#include > -#include > -#include > -#include > -#include > -#include > -#include > -#include > -#include > -#include > -#include > -#include > -#include > -#include > - > -#include > -#include > -#include > -#include > - > -/* (es) */ > -/* note: perhaps we can murge these files, so that you can just > - * define 1 of them, and they can sort that out for themselves > - */ > -#if defined(CONFIG_M68EZ328) > -#include > -#else > -#if defined(CONFIG_M68VZ328) > -#include > -#else > -#include > -#endif /* CONFIG_M68VZ328 */ > -#endif /* CONFIG_M68EZ328 */ > - > -/* Turn off usage of real serial interrupt code, to "support" Copilot */ > -#ifdef CONFIG_XCOPILOT_BUGS > -#undef USE_INTS > -#else > -#define USE_INTS > -#endif > - > -/* > - * I believe this is the optimal setting that reduces the number of interrupts. > - * At high speeds the output might become a little "bursted" (use USTCNT_TXHE > - * if that bothers you), but in most cases it will not, since we try to > - * transmit characters every time rs_interrupt is called. Thus, quite often > - * you'll see that a receive interrupt occures before the transmit one. > - * -- Vladimir Gurevich > - */ > -#define USTCNT_TX_INTR_MASK (USTCNT_TXEE) > - > -/* > - * 68328 and 68EZ328 UARTS are a little bit different. EZ328 has special > - * "Old data interrupt" which occures whenever the data stay in the FIFO > - * longer than 30 bits time. This allows us to use FIFO without compromising > - * latency. '328 does not have this feature and without the real 328-based > - * board I would assume that RXRE is the safest setting. > - * > - * For EZ328 I use RXHE (Half empty) interrupt to reduce the number of > - * interrupts. RXFE (receive queue full) causes the system to lose data > - * at least at 115200 baud > - * > - * If your board is busy doing other stuff, you might consider to use > - * RXRE (data ready intrrupt) instead. > - * > - * The other option is to make these INTR masks run-time configurable, so > - * that people can dynamically adapt them according to the current usage. > - * -- Vladimir Gurevich > - */ > - > -/* (es) */ > -#if defined(CONFIG_M68EZ328) || defined(CONFIG_M68VZ328) > -#define USTCNT_RX_INTR_MASK (USTCNT_RXHE | USTCNT_ODEN) > -#elif defined(CONFIG_M68328) > -#define USTCNT_RX_INTR_MASK (USTCNT_RXRE) > -#else > -#error Please, define the Rx interrupt events for your CPU > -#endif > -/* (/es) */ > - > -/* > - * This is our internal structure for each serial port's state. > - */ > -struct m68k_serial { > - struct tty_port tport; > - char is_cons; /* Is this our console. */ > - int magic; > - int baud_base; > - int port; > - int irq; > - int type; /* UART type */ > - int custom_divisor; > - int x_char; /* xon/xoff character */ > - int line; > - unsigned char *xmit_buf; > - int xmit_head; > - int xmit_tail; > - int xmit_cnt; > -}; > - > -#define SERIAL_MAGIC 0x5301 > - > -/* > - * Define the number of ports supported and their irqs. > - */ > -#define NR_PORTS 1 > - > -static struct m68k_serial m68k_soft[NR_PORTS]; > - > -static unsigned int uart_irqs[NR_PORTS] = { UART_IRQ_NUM }; > - > -/* multiple ports are contiguous in memory */ > -m68328_uart *uart_addr = (m68328_uart *)USTCNT_ADDR; > - > -struct tty_driver *serial_driver; > - > -static void change_speed(struct m68k_serial *info, struct tty_struct *tty); > - > -/* > - * Setup for console. Argument comes from the boot command line. > - */ > - > -/* note: this is messy, but it works, again, perhaps defined somewhere else?*/ > -#ifdef CONFIG_M68VZ328 > -#define CONSOLE_BAUD_RATE 19200 > -#define DEFAULT_CBAUD B19200 > -#endif > - > - > -#ifndef CONSOLE_BAUD_RATE > -#define CONSOLE_BAUD_RATE 9600 > -#define DEFAULT_CBAUD B9600 > -#endif > - > - > -static int m68328_console_initted = 0; > -static int m68328_console_baud = CONSOLE_BAUD_RATE; > -static int m68328_console_cbaud = DEFAULT_CBAUD; > - > - > -static inline int serial_paranoia_check(struct m68k_serial *info, > - char *name, const char *routine) > -{ > -#ifdef SERIAL_PARANOIA_CHECK > - static const char *badmagic = > - "Warning: bad magic number for serial struct %s in %s\n"; > - static const char *badinfo = > - "Warning: null m68k_serial for %s in %s\n"; > - > - if (!info) { > - printk(badinfo, name, routine); > - return 1; > - } > - if (info->magic != SERIAL_MAGIC) { > - printk(badmagic, name, routine); > - return 1; > - } > -#endif > - return 0; > -} > - > -/* > - * This is used to figure out the divisor speeds and the timeouts > - */ > -static int baud_table[] = { > - 0, 50, 75, 110, 134, 150, 200, 300, 600, 1200, 1800, 2400, 4800, > - 9600, 19200, 38400, 57600, 115200, 0 }; > - > -/* Utility routines */ > -static inline int get_baud(struct m68k_serial *ss) > -{ > - unsigned long result = 115200; > - unsigned short int baud = uart_addr[ss->line].ubaud; > - if (GET_FIELD(baud, UBAUD_PRESCALER) == 0x38) result = 38400; > - result >>= GET_FIELD(baud, UBAUD_DIVIDE); > - > - return result; > -} > - > -/* > - * ------------------------------------------------------------ > - * rs_stop() and rs_start() > - * > - * This routines are called before setting or resetting tty->stopped. > - * They enable or disable transmitter interrupts, as necessary. > - * ------------------------------------------------------------ > - */ > -static void rs_stop(struct tty_struct *tty) > -{ > - struct m68k_serial *info = (struct m68k_serial *)tty->driver_data; > - m68328_uart *uart = &uart_addr[info->line]; > - unsigned long flags; > - > - if (serial_paranoia_check(info, tty->name, "rs_stop")) > - return; > - > - local_irq_save(flags); > - uart->ustcnt &= ~USTCNT_TXEN; > - local_irq_restore(flags); > -} > - > -static int rs_put_char(char ch) > -{ > - unsigned long flags; > - int loops = 0; > - > - local_irq_save(flags); > - > - while (!(UTX & UTX_TX_AVAIL) && (loops < 1000)) { > - loops++; > - udelay(5); > - } > - > - UTX_TXDATA = ch; > - udelay(5); > - local_irq_restore(flags); > - return 1; > -} > - > -static void rs_start(struct tty_struct *tty) > -{ > - struct m68k_serial *info = (struct m68k_serial *)tty->driver_data; > - m68328_uart *uart = &uart_addr[info->line]; > - unsigned long flags; > - > - if (serial_paranoia_check(info, tty->name, "rs_start")) > - return; > - > - local_irq_save(flags); > - if (info->xmit_cnt && info->xmit_buf && !(uart->ustcnt & USTCNT_TXEN)) { > -#ifdef USE_INTS > - uart->ustcnt |= USTCNT_TXEN | USTCNT_TX_INTR_MASK; > -#else > - uart->ustcnt |= USTCNT_TXEN; > -#endif > - } > - local_irq_restore(flags); > -} > - > -static void receive_chars(struct m68k_serial *info, unsigned short rx) > -{ > - m68328_uart *uart = &uart_addr[info->line]; > - unsigned char ch, flag; > - > - /* > - * This do { } while() loop will get ALL chars out of Rx FIFO > - */ > -#ifndef CONFIG_XCOPILOT_BUGS > - do { > -#endif > - ch = GET_FIELD(rx, URX_RXDATA); > - > - if(info->is_cons) { > - if(URX_BREAK & rx) { /* whee, break received */ > - return; > -#ifdef CONFIG_MAGIC_SYSRQ > - } else if (ch == 0x10) { /* ^P */ > - show_state(); > - show_free_areas(0); > - show_buffers(); > -/* show_net_buffers(); */ > - return; > - } else if (ch == 0x12) { /* ^R */ > - emergency_restart(); > - return; > -#endif /* CONFIG_MAGIC_SYSRQ */ > - } > - } > - > - flag = TTY_NORMAL; > - > - if (rx & URX_PARITY_ERROR) > - flag = TTY_PARITY; > - else if (rx & URX_OVRUN) > - flag = TTY_OVERRUN; > - else if (rx & URX_FRAME_ERROR) > - flag = TTY_FRAME; > - > - tty_insert_flip_char(&info->tport, ch, flag); > -#ifndef CONFIG_XCOPILOT_BUGS > - } while((rx = uart->urx.w) & URX_DATA_READY); > -#endif > - > - tty_schedule_flip(&info->tport); > -} > - > -static void transmit_chars(struct m68k_serial *info, struct tty_struct *tty) > -{ > - m68328_uart *uart = &uart_addr[info->line]; > - > - if (info->x_char) { > - /* Send next char */ > - uart->utx.b.txdata = info->x_char; > - info->x_char = 0; > - goto clear_and_return; > - } > - > - if ((info->xmit_cnt <= 0) || !tty || tty->stopped) { > - /* That's peculiar... TX ints off */ > - uart->ustcnt &= ~USTCNT_TX_INTR_MASK; > - goto clear_and_return; > - } > - > - /* Send char */ > - uart->utx.b.txdata = info->xmit_buf[info->xmit_tail++]; > - info->xmit_tail = info->xmit_tail & (SERIAL_XMIT_SIZE-1); > - info->xmit_cnt--; > - > - if(info->xmit_cnt <= 0) { > - /* All done for now... TX ints off */ > - uart->ustcnt &= ~USTCNT_TX_INTR_MASK; > - goto clear_and_return; > - } > - > -clear_and_return: > - /* Clear interrupt (should be auto)*/ > - return; > -} > - > -/* > - * This is the serial driver's generic interrupt routine > - */ > -irqreturn_t rs_interrupt(int irq, void *dev_id) > -{ > - struct m68k_serial *info = dev_id; > - struct tty_struct *tty = tty_port_tty_get(&info->tport); > - m68328_uart *uart; > - unsigned short rx; > - unsigned short tx; > - > - uart = &uart_addr[info->line]; > - rx = uart->urx.w; > - > -#ifdef USE_INTS > - tx = uart->utx.w; > - > - if (rx & URX_DATA_READY) > - receive_chars(info, rx); > - if (tx & UTX_TX_AVAIL) > - transmit_chars(info, tty); > -#else > - receive_chars(info, rx); > -#endif > - tty_kref_put(tty); > - > - return IRQ_HANDLED; > -} > - > -static int startup(struct m68k_serial *info, struct tty_struct *tty) > -{ > - m68328_uart *uart = &uart_addr[info->line]; > - unsigned long flags; > - > - if (info->tport.flags & ASYNC_INITIALIZED) > - return 0; > - > - if (!info->xmit_buf) { > - info->xmit_buf = (unsigned char *) __get_free_page(GFP_KERNEL); > - if (!info->xmit_buf) > - return -ENOMEM; > - } > - > - local_irq_save(flags); > - > - /* > - * Clear the FIFO buffers and disable them > - * (they will be reenabled in change_speed()) > - */ > - > - uart->ustcnt = USTCNT_UEN; > - uart->ustcnt = USTCNT_UEN | USTCNT_RXEN | USTCNT_TXEN; > - (void)uart->urx.w; > - > - /* > - * Finally, enable sequencing and interrupts > - */ > -#ifdef USE_INTS > - uart->ustcnt = USTCNT_UEN | USTCNT_RXEN | > - USTCNT_RX_INTR_MASK | USTCNT_TX_INTR_MASK; > -#else > - uart->ustcnt = USTCNT_UEN | USTCNT_RXEN | USTCNT_RX_INTR_MASK; > -#endif > - > - if (tty) > - clear_bit(TTY_IO_ERROR, &tty->flags); > - info->xmit_cnt = info->xmit_head = info->xmit_tail = 0; > - > - /* > - * and set the speed of the serial port > - */ > - > - change_speed(info, tty); > - > - info->tport.flags |= ASYNC_INITIALIZED; > - local_irq_restore(flags); > - return 0; > -} > - > -/* > - * This routine will shutdown a serial port; interrupts are disabled, and > - * DTR is dropped if the hangup on close termio flag is on. > - */ > -static void shutdown(struct m68k_serial *info, struct tty_struct *tty) > -{ > - m68328_uart *uart = &uart_addr[info->line]; > - unsigned long flags; > - > - uart->ustcnt = 0; /* All off! */ > - if (!(info->tport.flags & ASYNC_INITIALIZED)) > - return; > - > - local_irq_save(flags); > - > - if (info->xmit_buf) { > - free_page((unsigned long) info->xmit_buf); > - info->xmit_buf = 0; > - } > - > - if (tty) > - set_bit(TTY_IO_ERROR, &tty->flags); > - > - info->tport.flags &= ~ASYNC_INITIALIZED; > - local_irq_restore(flags); > -} > - > -struct { > - int divisor, prescale; > -} > -#ifndef CONFIG_M68VZ328 > - hw_baud_table[18] = { > - {0,0}, /* 0 */ > - {0,0}, /* 50 */ > - {0,0}, /* 75 */ > - {0,0}, /* 110 */ > - {0,0}, /* 134 */ > - {0,0}, /* 150 */ > - {0,0}, /* 200 */ > - {7,0x26}, /* 300 */ > - {6,0x26}, /* 600 */ > - {5,0x26}, /* 1200 */ > - {0,0}, /* 1800 */ > - {4,0x26}, /* 2400 */ > - {3,0x26}, /* 4800 */ > - {2,0x26}, /* 9600 */ > - {1,0x26}, /* 19200 */ > - {0,0x26}, /* 38400 */ > - {1,0x38}, /* 57600 */ > - {0,0x38}, /* 115200 */ > -}; > -#else > - hw_baud_table[18] = { > - {0,0}, /* 0 */ > - {0,0}, /* 50 */ > - {0,0}, /* 75 */ > - {0,0}, /* 110 */ > - {0,0}, /* 134 */ > - {0,0}, /* 150 */ > - {0,0}, /* 200 */ > - {0,0}, /* 300 */ > - {7,0x26}, /* 600 */ > - {6,0x26}, /* 1200 */ > - {0,0}, /* 1800 */ > - {5,0x26}, /* 2400 */ > - {4,0x26}, /* 4800 */ > - {3,0x26}, /* 9600 */ > - {2,0x26}, /* 19200 */ > - {1,0x26}, /* 38400 */ > - {0,0x26}, /* 57600 */ > - {1,0x38}, /* 115200 */ > -}; > -#endif > -/* rate = 1036800 / ((65 - prescale) * (1< - > -/* > - * This routine is called to set the UART divisor registers to match > - * the specified baud rate for a serial port. > - */ > -static void change_speed(struct m68k_serial *info, struct tty_struct *tty) > -{ > - m68328_uart *uart = &uart_addr[info->line]; > - unsigned short port; > - unsigned short ustcnt; > - unsigned cflag; > - int i; > - > - cflag = tty->termios.c_cflag; > - port = info->port; > - if (!port) > - return; > - > - ustcnt = uart->ustcnt; > - uart->ustcnt = ustcnt & ~USTCNT_TXEN; > - > - i = cflag & CBAUD; > - if (i & CBAUDEX) { > - i = (i & ~CBAUDEX) + B38400; > - } > - > - uart->ubaud = PUT_FIELD(UBAUD_DIVIDE, hw_baud_table[i].divisor) | > - PUT_FIELD(UBAUD_PRESCALER, hw_baud_table[i].prescale); > - > - ustcnt &= ~(USTCNT_PARITYEN | USTCNT_ODD_EVEN | USTCNT_STOP | USTCNT_8_7); > - > - if ((cflag & CSIZE) == CS8) > - ustcnt |= USTCNT_8_7; > - > - if (cflag & CSTOPB) > - ustcnt |= USTCNT_STOP; > - > - if (cflag & PARENB) > - ustcnt |= USTCNT_PARITYEN; > - if (cflag & PARODD) > - ustcnt |= USTCNT_ODD_EVEN; > - > -#ifdef CONFIG_SERIAL_68328_RTS_CTS > - if (cflag & CRTSCTS) { > - uart->utx.w &= ~ UTX_NOCTS; > - } else { > - uart->utx.w |= UTX_NOCTS; > - } > -#endif > - > - ustcnt |= USTCNT_TXEN; > - > - uart->ustcnt = ustcnt; > - return; > -} > - > -/* > - * Fair output driver allows a process to speak. > - */ > -static void rs_fair_output(void) > -{ > - int left; /* Output no more than that */ > - unsigned long flags; > - struct m68k_serial *info = &m68k_soft[0]; > - char c; > - > - if (info == NULL) return; > - if (info->xmit_buf == NULL) return; > - > - local_irq_save(flags); > - left = info->xmit_cnt; > - while (left != 0) { > - c = info->xmit_buf[info->xmit_tail]; > - info->xmit_tail = (info->xmit_tail+1) & (SERIAL_XMIT_SIZE-1); > - info->xmit_cnt--; > - local_irq_restore(flags); > - > - rs_put_char(c); > - > - local_irq_save(flags); > - left = min(info->xmit_cnt, left-1); > - } > - > - /* Last character is being transmitted now (hopefully). */ > - udelay(5); > - > - local_irq_restore(flags); > - return; > -} > - > -/* > - * m68k_console_print is registered for printk. > - */ > -void console_print_68328(const char *p) > -{ > - char c; > - > - while((c=*(p++)) != 0) { > - if(c == '\n') > - rs_put_char('\r'); > - rs_put_char(c); > - } > - > - /* Comment this if you want to have a strict interrupt-driven output */ > - rs_fair_output(); > - > - return; > -} > - > -static void rs_set_ldisc(struct tty_struct *tty) > -{ > - struct m68k_serial *info = (struct m68k_serial *)tty->driver_data; > - > - if (serial_paranoia_check(info, tty->name, "rs_set_ldisc")) > - return; > - > - info->is_cons = (tty->termios.c_line == N_TTY); > - > - printk("ttyS%d console mode %s\n", info->line, info->is_cons ? "on" : "off"); > -} > - > -static void rs_flush_chars(struct tty_struct *tty) > -{ > - struct m68k_serial *info = (struct m68k_serial *)tty->driver_data; > - m68328_uart *uart = &uart_addr[info->line]; > - unsigned long flags; > - > - if (serial_paranoia_check(info, tty->name, "rs_flush_chars")) > - return; > -#ifndef USE_INTS > - for(;;) { > -#endif > - > - /* Enable transmitter */ > - local_irq_save(flags); > - > - if (info->xmit_cnt <= 0 || tty->stopped || !info->xmit_buf) { > - local_irq_restore(flags); > - return; > - } > - > -#ifdef USE_INTS > - uart->ustcnt |= USTCNT_TXEN | USTCNT_TX_INTR_MASK; > -#else > - uart->ustcnt |= USTCNT_TXEN; > -#endif > - > -#ifdef USE_INTS > - if (uart->utx.w & UTX_TX_AVAIL) { > -#else > - if (1) { > -#endif > - /* Send char */ > - uart->utx.b.txdata = info->xmit_buf[info->xmit_tail++]; > - info->xmit_tail = info->xmit_tail & (SERIAL_XMIT_SIZE-1); > - info->xmit_cnt--; > - } > - > -#ifndef USE_INTS > - while (!(uart->utx.w & UTX_TX_AVAIL)) udelay(5); > - } > -#endif > - local_irq_restore(flags); > -} > - > -extern void console_printn(const char * b, int count); > - > -static int rs_write(struct tty_struct * tty, > - const unsigned char *buf, int count) > -{ > - int c, total = 0; > - struct m68k_serial *info = (struct m68k_serial *)tty->driver_data; > - m68328_uart *uart = &uart_addr[info->line]; > - unsigned long flags; > - > - if (serial_paranoia_check(info, tty->name, "rs_write")) > - return 0; > - > - if (!tty || !info->xmit_buf) > - return 0; > - > - local_save_flags(flags); > - while (1) { > - local_irq_disable(); > - c = min_t(int, count, min(SERIAL_XMIT_SIZE - info->xmit_cnt - 1, > - SERIAL_XMIT_SIZE - info->xmit_head)); > - local_irq_restore(flags); > - > - if (c <= 0) > - break; > - > - memcpy(info->xmit_buf + info->xmit_head, buf, c); > - > - local_irq_disable(); > - info->xmit_head = (info->xmit_head + c) & (SERIAL_XMIT_SIZE-1); > - info->xmit_cnt += c; > - local_irq_restore(flags); > - buf += c; > - count -= c; > - total += c; > - } > - > - if (info->xmit_cnt && !tty->stopped) { > - /* Enable transmitter */ > - local_irq_disable(); > -#ifndef USE_INTS > - while(info->xmit_cnt) { > -#endif > - > - uart->ustcnt |= USTCNT_TXEN; > -#ifdef USE_INTS > - uart->ustcnt |= USTCNT_TX_INTR_MASK; > -#else > - while (!(uart->utx.w & UTX_TX_AVAIL)) udelay(5); > -#endif > - if (uart->utx.w & UTX_TX_AVAIL) { > - uart->utx.b.txdata = info->xmit_buf[info->xmit_tail++]; > - info->xmit_tail = info->xmit_tail & (SERIAL_XMIT_SIZE-1); > - info->xmit_cnt--; > - } > - > -#ifndef USE_INTS > - } > -#endif > - local_irq_restore(flags); > - } > - > - return total; > -} > - > -static int rs_write_room(struct tty_struct *tty) > -{ > - struct m68k_serial *info = (struct m68k_serial *)tty->driver_data; > - int ret; > - > - if (serial_paranoia_check(info, tty->name, "rs_write_room")) > - return 0; > - ret = SERIAL_XMIT_SIZE - info->xmit_cnt - 1; > - if (ret < 0) > - ret = 0; > - return ret; > -} > - > -static int rs_chars_in_buffer(struct tty_struct *tty) > -{ > - struct m68k_serial *info = (struct m68k_serial *)tty->driver_data; > - > - if (serial_paranoia_check(info, tty->name, "rs_chars_in_buffer")) > - return 0; > - return info->xmit_cnt; > -} > - > -static void rs_flush_buffer(struct tty_struct *tty) > -{ > - struct m68k_serial *info = (struct m68k_serial *)tty->driver_data; > - unsigned long flags; > - > - if (serial_paranoia_check(info, tty->name, "rs_flush_buffer")) > - return; > - local_irq_save(flags); > - info->xmit_cnt = info->xmit_head = info->xmit_tail = 0; > - local_irq_restore(flags); > - tty_wakeup(tty); > -} > - > -/* > - * ------------------------------------------------------------ > - * rs_throttle() > - * > - * This routine is called by the upper-layer tty layer to signal that > - * incoming characters should be throttled. > - * ------------------------------------------------------------ > - */ > -static void rs_throttle(struct tty_struct * tty) > -{ > - struct m68k_serial *info = (struct m68k_serial *)tty->driver_data; > - > - if (serial_paranoia_check(info, tty->name, "rs_throttle")) > - return; > - > - if (I_IXOFF(tty)) > - info->x_char = STOP_CHAR(tty); > - > - /* Turn off RTS line (do this atomic) */ > -} > - > -static void rs_unthrottle(struct tty_struct * tty) > -{ > - struct m68k_serial *info = (struct m68k_serial *)tty->driver_data; > - > - if (serial_paranoia_check(info, tty->name, "rs_unthrottle")) > - return; > - > - if (I_IXOFF(tty)) { > - if (info->x_char) > - info->x_char = 0; > - else > - info->x_char = START_CHAR(tty); > - } > - > - /* Assert RTS line (do this atomic) */ > -} > - > -/* > - * ------------------------------------------------------------ > - * rs_ioctl() and friends > - * ------------------------------------------------------------ > - */ > - > -static int get_serial_info(struct m68k_serial * info, > - struct serial_struct * retinfo) > -{ > - struct serial_struct tmp; > - > - if (!retinfo) > - return -EFAULT; > - memset(&tmp, 0, sizeof(tmp)); > - tmp.type = info->type; > - tmp.line = info->line; > - tmp.port = info->port; > - tmp.irq = info->irq; > - tmp.flags = info->tport.flags; > - tmp.baud_base = info->baud_base; > - tmp.close_delay = info->tport.close_delay; > - tmp.closing_wait = info->tport.closing_wait; > - tmp.custom_divisor = info->custom_divisor; > - if (copy_to_user(retinfo, &tmp, sizeof(*retinfo))) > - return -EFAULT; > - > - return 0; > -} > - > -static int set_serial_info(struct m68k_serial *info, struct tty_struct *tty, > - struct serial_struct * new_info) > -{ > - struct tty_port *port = &info->tport; > - struct serial_struct new_serial; > - struct m68k_serial old_info; > - int retval = 0; > - > - if (!new_info) > - return -EFAULT; > - if (copy_from_user(&new_serial, new_info, sizeof(new_serial))) > - return -EFAULT; > - old_info = *info; > - > - if (!capable(CAP_SYS_ADMIN)) { > - if ((new_serial.baud_base != info->baud_base) || > - (new_serial.type != info->type) || > - (new_serial.close_delay != port->close_delay) || > - ((new_serial.flags & ~ASYNC_USR_MASK) != > - (port->flags & ~ASYNC_USR_MASK))) > - return -EPERM; > - port->flags = ((port->flags & ~ASYNC_USR_MASK) | > - (new_serial.flags & ASYNC_USR_MASK)); > - info->custom_divisor = new_serial.custom_divisor; > - goto check_and_exit; > - } > - > - if (port->count > 1) > - return -EBUSY; > - > - /* > - * OK, past this point, all the error checking has been done. > - * At this point, we start making changes..... > - */ > - > - info->baud_base = new_serial.baud_base; > - port->flags = ((port->flags & ~ASYNC_FLAGS) | > - (new_serial.flags & ASYNC_FLAGS)); > - info->type = new_serial.type; > - port->close_delay = new_serial.close_delay; > - port->closing_wait = new_serial.closing_wait; > - > -check_and_exit: > - retval = startup(info, tty); > - return retval; > -} > - > -/* > - * get_lsr_info - get line status register info > - * > - * Purpose: Let user call ioctl() to get info when the UART physically > - * is emptied. On bus types like RS485, the transmitter must > - * release the bus after transmitting. This must be done when > - * the transmit shift register is empty, not be done when the > - * transmit holding register is empty. This functionality > - * allows an RS485 driver to be written in user space. > - */ > -static int get_lsr_info(struct m68k_serial * info, unsigned int *value) > -{ > -#ifdef CONFIG_SERIAL_68328_RTS_CTS > - m68328_uart *uart = &uart_addr[info->line]; > -#endif > - unsigned char status; > - unsigned long flags; > - > - local_irq_save(flags); > -#ifdef CONFIG_SERIAL_68328_RTS_CTS > - status = (uart->utx.w & UTX_CTS_STAT) ? 1 : 0; > -#else > - status = 0; > -#endif > - local_irq_restore(flags); > - return put_user(status, value); > -} > - > -/* > - * This routine sends a break character out the serial port. > - */ > -static void send_break(struct m68k_serial * info, unsigned int duration) > -{ > - m68328_uart *uart = &uart_addr[info->line]; > - unsigned long flags; > - if (!info->port) > - return; > - local_irq_save(flags); > -#ifdef USE_INTS > - uart->utx.w |= UTX_SEND_BREAK; > - msleep_interruptible(duration); > - uart->utx.w &= ~UTX_SEND_BREAK; > -#endif > - local_irq_restore(flags); > -} > - > -static int rs_ioctl(struct tty_struct *tty, > - unsigned int cmd, unsigned long arg) > -{ > - struct m68k_serial * info = (struct m68k_serial *)tty->driver_data; > - int retval; > - > - if (serial_paranoia_check(info, tty->name, "rs_ioctl")) > - return -ENODEV; > - > - if ((cmd != TIOCGSERIAL) && (cmd != TIOCSSERIAL) && > - (cmd != TIOCSERCONFIG) && (cmd != TIOCSERGWILD) && > - (cmd != TIOCSERSWILD) && (cmd != TIOCSERGSTRUCT)) { > - if (tty->flags & (1 << TTY_IO_ERROR)) > - return -EIO; > - } > - > - switch (cmd) { > - case TCSBRK: /* SVID version: non-zero arg --> no break */ > - retval = tty_check_change(tty); > - if (retval) > - return retval; > - tty_wait_until_sent(tty, 0); > - if (!arg) > - send_break(info, 250); /* 1/4 second */ > - return 0; > - case TCSBRKP: /* support for POSIX tcsendbreak() */ > - retval = tty_check_change(tty); > - if (retval) > - return retval; > - tty_wait_until_sent(tty, 0); > - send_break(info, arg ? arg*(100) : 250); > - return 0; > - case TIOCGSERIAL: > - return get_serial_info(info, > - (struct serial_struct *) arg); > - case TIOCSSERIAL: > - return set_serial_info(info, tty, > - (struct serial_struct *) arg); > - case TIOCSERGETLSR: /* Get line status register */ > - return get_lsr_info(info, (unsigned int *) arg); > - case TIOCSERGSTRUCT: > - if (copy_to_user((struct m68k_serial *) arg, > - info, sizeof(struct m68k_serial))) > - return -EFAULT; > - return 0; > - default: > - return -ENOIOCTLCMD; > - } > - return 0; > -} > - > -static void rs_set_termios(struct tty_struct *tty, struct ktermios *old_termios) > -{ > - struct m68k_serial *info = (struct m68k_serial *)tty->driver_data; > - > - change_speed(info, tty); > - > - if ((old_termios->c_cflag & CRTSCTS) && > - !(tty->termios.c_cflag & CRTSCTS)) > - rs_start(tty); > - > -} > - > -/* > - * ------------------------------------------------------------ > - * rs_close() > - * > - * This routine is called when the serial port gets closed. First, we > - * wait for the last remaining data to be sent. Then, we unlink its > - * S structure from the interrupt chain if necessary, and we free > - * that IRQ if nothing is left in the chain. > - * ------------------------------------------------------------ > - */ > -static void rs_close(struct tty_struct *tty, struct file * filp) > -{ > - struct m68k_serial * info = (struct m68k_serial *)tty->driver_data; > - struct tty_port *port = &info->tport; > - m68328_uart *uart = &uart_addr[info->line]; > - unsigned long flags; > - > - if (serial_paranoia_check(info, tty->name, "rs_close")) > - return; > - > - local_irq_save(flags); > - > - if (tty_hung_up_p(filp)) { > - local_irq_restore(flags); > - return; > - } > - > - if ((tty->count == 1) && (port->count != 1)) { > - /* > - * Uh, oh. tty->count is 1, which means that the tty > - * structure will be freed. Info->count should always > - * be one in these conditions. If it's greater than > - * one, we've got real problems, since it means the > - * serial port won't be shutdown. > - */ > - printk("rs_close: bad serial port count; tty->count is 1, " > - "port->count is %d\n", port->count); > - port->count = 1; > - } > - if (--port->count < 0) { > - printk("rs_close: bad serial port count for ttyS%d: %d\n", > - info->line, port->count); > - port->count = 0; > - } > - if (port->count) { > - local_irq_restore(flags); > - return; > - } > - port->flags |= ASYNC_CLOSING; > - /* > - * Now we wait for the transmit buffer to clear; and we notify > - * the line discipline to only process XON/XOFF characters. > - */ > - tty->closing = 1; > - if (port->closing_wait != ASYNC_CLOSING_WAIT_NONE) > - tty_wait_until_sent(tty, port->closing_wait); > - /* > - * At this point we stop accepting input. To do this, we > - * disable the receive line status interrupts, and tell the > - * interrupt driver to stop checking the data ready bit in the > - * line status register. > - */ > - > - uart->ustcnt &= ~USTCNT_RXEN; > - uart->ustcnt &= ~(USTCNT_RXEN | USTCNT_RX_INTR_MASK); > - > - shutdown(info, tty); > - rs_flush_buffer(tty); > - > - tty_ldisc_flush(tty); > - tty->closing = 0; > - tty_port_tty_set(&info->tport, NULL); > -#warning "This is not and has never been valid so fix it" > -#if 0 > - if (tty->ldisc.num != ldiscs[N_TTY].num) { > - if (tty->ldisc.close) > - (tty->ldisc.close)(tty); > - tty->ldisc = ldiscs[N_TTY]; > - tty->termios.c_line = N_TTY; > - if (tty->ldisc.open) > - (tty->ldisc.open)(tty); > - } > -#endif > - if (port->blocked_open) { > - if (port->close_delay) > - msleep_interruptible(jiffies_to_msecs(port->close_delay)); > - wake_up_interruptible(&port->open_wait); > - } > - port->flags &= ~(ASYNC_NORMAL_ACTIVE|ASYNC_CLOSING); > - local_irq_restore(flags); > -} > - > -/* > - * rs_hangup() --- called by tty_hangup() when a hangup is signaled. > - */ > -void rs_hangup(struct tty_struct *tty) > -{ > - struct m68k_serial * info = (struct m68k_serial *)tty->driver_data; > - > - if (serial_paranoia_check(info, tty->name, "rs_hangup")) > - return; > - > - rs_flush_buffer(tty); > - shutdown(info, tty); > - info->tport.count = 0; > - info->tport.flags &= ~ASYNC_NORMAL_ACTIVE; > - tty_port_tty_set(&info->tport, NULL); > - wake_up_interruptible(&info->tport.open_wait); > -} > - > -/* > - * This routine is called whenever a serial port is opened. It > - * enables interrupts for a serial port, linking in its S structure into > - * the IRQ chain. It also performs the serial-specific > - * initialization for the tty structure. > - */ > -int rs_open(struct tty_struct *tty, struct file * filp) > -{ > - struct m68k_serial *info; > - int retval; > - > - info = &m68k_soft[tty->index]; > - > - if (serial_paranoia_check(info, tty->name, "rs_open")) > - return -ENODEV; > - > - info->tport.count++; > - tty->driver_data = info; > - tty_port_tty_set(&info->tport, tty); > - > - /* > - * Start up serial port > - */ > - retval = startup(info, tty); > - if (retval) > - return retval; > - > - return tty_port_block_til_ready(&info->tport, tty, filp); > -} > - > -/* Finally, routines used to initialize the serial driver. */ > - > -static void show_serial_version(void) > -{ > - printk("MC68328 serial driver version 1.00\n"); > -} > - > -static const struct tty_operations rs_ops = { > - .open = rs_open, > - .close = rs_close, > - .write = rs_write, > - .flush_chars = rs_flush_chars, > - .write_room = rs_write_room, > - .chars_in_buffer = rs_chars_in_buffer, > - .flush_buffer = rs_flush_buffer, > - .ioctl = rs_ioctl, > - .throttle = rs_throttle, > - .unthrottle = rs_unthrottle, > - .set_termios = rs_set_termios, > - .stop = rs_stop, > - .start = rs_start, > - .hangup = rs_hangup, > - .set_ldisc = rs_set_ldisc, > -}; > - > -static const struct tty_port_operations rs_port_ops = { > -}; > - > -/* rs_init inits the driver */ > -static int __init > -rs68328_init(void) > -{ > - unsigned long flags; > - int i; > - struct m68k_serial *info; > - > - serial_driver = alloc_tty_driver(NR_PORTS); > - if (!serial_driver) > - return -ENOMEM; > - > - show_serial_version(); > - > - /* Initialize the tty_driver structure */ > - /* SPARC: Not all of this is exactly right for us. */ > - > - serial_driver->name = "ttyS"; > - serial_driver->major = TTY_MAJOR; > - serial_driver->minor_start = 64; > - serial_driver->type = TTY_DRIVER_TYPE_SERIAL; > - serial_driver->subtype = SERIAL_TYPE_NORMAL; > - serial_driver->init_termios = tty_std_termios; > - serial_driver->init_termios.c_cflag = > - m68328_console_cbaud | CS8 | CREAD | HUPCL | CLOCAL; > - serial_driver->flags = TTY_DRIVER_REAL_RAW; > - tty_set_operations(serial_driver, &rs_ops); > - > - local_irq_save(flags); > - > - for(i=0;i - > - info = &m68k_soft[i]; > - tty_port_init(&info->tport); > - info->tport.ops = &rs_port_ops; > - info->magic = SERIAL_MAGIC; > - info->port = (int) &uart_addr[i]; > - info->irq = uart_irqs[i]; > - info->custom_divisor = 16; > - info->x_char = 0; > - info->line = i; > - info->is_cons = 1; /* Means shortcuts work */ > - > - printk("%s%d at 0x%08x (irq = %d)", serial_driver->name, info->line, > - info->port, info->irq); > - printk(" is a builtin MC68328 UART\n"); > - > -#ifdef CONFIG_M68VZ328 > - if (i > 0 ) > - PJSEL &= 0xCF; /* PSW enable second port output */ > -#endif > - > - if (request_irq(uart_irqs[i], > - rs_interrupt, > - 0, > - "M68328_UART", info)) > - panic("Unable to attach 68328 serial interrupt\n"); > - > - tty_port_link_device(&info->tport, serial_driver, i); > - } > - local_irq_restore(flags); > - > - if (tty_register_driver(serial_driver)) { > - put_tty_driver(serial_driver); > - for (i = 0; i < NR_PORTS; i++) > - tty_port_destroy(&m68k_soft[i].tport); > - printk(KERN_ERR "Couldn't register serial driver\n"); > - return -ENOMEM; > - } > - > - return 0; > -} > - > -module_init(rs68328_init); > - > - > - > -static void m68328_set_baud(void) > -{ > - unsigned short ustcnt; > - int i; > - > - ustcnt = USTCNT; > - USTCNT = ustcnt & ~USTCNT_TXEN; > - > -again: > - for (i = 0; i < ARRAY_SIZE(baud_table); i++) > - if (baud_table[i] == m68328_console_baud) > - break; > - if (i >= ARRAY_SIZE(baud_table)) { > - m68328_console_baud = 9600; > - goto again; > - } > - > - UBAUD = PUT_FIELD(UBAUD_DIVIDE, hw_baud_table[i].divisor) | > - PUT_FIELD(UBAUD_PRESCALER, hw_baud_table[i].prescale); > - ustcnt &= ~(USTCNT_PARITYEN | USTCNT_ODD_EVEN | USTCNT_STOP | USTCNT_8_7); > - ustcnt |= USTCNT_8_7; > - ustcnt |= USTCNT_TXEN; > - USTCNT = ustcnt; > - m68328_console_initted = 1; > - return; > -} > - > - > -int m68328_console_setup(struct console *cp, char *arg) > -{ > - int i, n = CONSOLE_BAUD_RATE; > - > - if (!cp) > - return(-1); > - > - if (arg) > - n = simple_strtoul(arg,NULL,0); > - > - for (i = 0; i < ARRAY_SIZE(baud_table); i++) > - if (baud_table[i] == n) > - break; > - if (i < ARRAY_SIZE(baud_table)) { > - m68328_console_baud = n; > - m68328_console_cbaud = 0; > - if (i > 15) { > - m68328_console_cbaud |= CBAUDEX; > - i -= 15; > - } > - m68328_console_cbaud |= i; > - } > - > - m68328_set_baud(); /* make sure baud rate changes */ > - return(0); > -} > - > - > -static struct tty_driver *m68328_console_device(struct console *c, int *index) > -{ > - *index = c->index; > - return serial_driver; > -} > - > - > -void m68328_console_write (struct console *co, const char *str, > - unsigned int count) > -{ > - if (!m68328_console_initted) > - m68328_set_baud(); > - while (count--) { > - if (*str == '\n') > - rs_put_char('\r'); > - rs_put_char( *str++ ); > - } > -} > - > - > -static struct console m68328_driver = { > - .name = "ttyS", > - .write = m68328_console_write, > - .device = m68328_console_device, > - .setup = m68328_console_setup, > - .flags = CON_PRINTBUFFER, > - .index = -1, > -}; > - > - > -static int __init m68328_console_init(void) > -{ > - register_console(&m68328_driver); > - return 0; > -} > - > -console_initcall(m68328_console_init); > diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig > index f38beb2..a261457 100644 > --- a/drivers/tty/serial/Kconfig > +++ b/drivers/tty/serial/Kconfig > @@ -790,17 +790,6 @@ config SERIAL_CORE_CONSOLE > config CONSOLE_POLL > bool > > -config SERIAL_68328 > - bool "68328 serial support" > - depends on M68328 || M68EZ328 || M68VZ328 > - help > - This driver supports the built-in serial port of the Motorola 68328 > - (standard, EZ and VZ varieties). > - > -config SERIAL_68328_RTS_CTS > - bool "Support RTS/CTS on 68328 serial port" > - depends on SERIAL_68328 > - > config SERIAL_MCF > bool "Coldfire serial support" > depends on COLDFIRE > diff --git a/drivers/tty/serial/Makefile b/drivers/tty/serial/Makefile > index 5ab4111..9d35387 100644 > --- a/drivers/tty/serial/Makefile > +++ b/drivers/tty/serial/Makefile > @@ -34,7 +34,6 @@ obj-$(CONFIG_SERIAL_MAX3100) += max3100.o > obj-$(CONFIG_SERIAL_MAX310X) += max310x.o > obj-$(CONFIG_SERIAL_IP22_ZILOG) += ip22zilog.o > obj-$(CONFIG_SERIAL_MUX) += mux.o > -obj-$(CONFIG_SERIAL_68328) += 68328serial.o > obj-$(CONFIG_SERIAL_MCF) += mcf.o > obj-$(CONFIG_SERIAL_PMACZILOG) += pmac_zilog.o > obj-$(CONFIG_SERIAL_HS_LPC32XX) += lpc32xx_hs.o > -- > 1.9.1 Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds From kreolekragol at free.fr Wed Dec 30 07:04:33 2015 From: kreolekragol at free.fr (kreolekragol at free.fr) Date: Wed, 30 Dec 2015 13:04:33 +0100 Subject: [uClinux-dev] Fw: important message Message-ID: <000037b3a4d6$4f525901$4604bc48$@free.fr> Hello! New message, please read kreolekragol at free.fr -------------- next part -------------- An HTML attachment was scrubbed... URL: From wbx at openadk.org Wed Dec 30 18:55:44 2015 From: wbx at openadk.org (Waldemar Brodkorb) Date: Thu, 31 Dec 2015 00:55:44 +0100 Subject: [uClinux-dev] [PATCH 2/6] recent binutils for h8/300 no longer use prefix In-Reply-To: <1451519748-20229-1-git-send-email-wbx@openadk.org> References: <1451519748-20229-1-git-send-email-wbx@openadk.org> Message-ID: <1451519748-20229-3-git-send-email-wbx@openadk.org> Remove SYMBOL_PREFIX for h8/300. Signed-off-by: Waldemar Brodkorb Signed-off-by: Yoshinori Sato --- configure.ac | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configure.ac b/configure.ac index adf5883..5ca70d5 100644 --- a/configure.ac +++ b/configure.ac @@ -181,7 +181,7 @@ fi SYMBOL_PREFIX= case $target in - h8300|bfin*) + bfin*) SYMBOL_PREFIX=_ ;; esac -- 1.7.10.4 From wbx at openadk.org Wed Dec 30 18:55:43 2015 From: wbx at openadk.org (Waldemar Brodkorb) Date: Thu, 31 Dec 2015 00:55:43 +0100 Subject: [uClinux-dev] [PATCH 1/6] dlopen is used by newer binutils, so check for it In-Reply-To: <1451519748-20229-1-git-send-email-wbx@openadk.org> References: <1451519748-20229-1-git-send-email-wbx@openadk.org> Message-ID: <1451519748-20229-2-git-send-email-wbx@openadk.org> Add a check for dlopen to configure.ac Signed-off-by: Waldemar Brodkorb --- configure.ac | 1 + 1 file changed, 1 insertion(+) diff --git a/configure.ac b/configure.ac index 4e7df5a..adf5883 100644 --- a/configure.ac +++ b/configure.ac @@ -192,6 +192,7 @@ dnl redirect some functions to the system symbols, but other local symbols dnl come from libiberty/libbfd. dnl int getopt(int, char * const [], const char *) __asm("_" "getopt" "$UNIX2003"); AC_CHECK_LIB(c, malloc, LIBS="-lc $LIBS") +AC_CHECK_LIB(dl, dlopen) dnl Checks for header files. AC_HEADER_STDC -- 1.7.10.4 From wbx at openadk.org Wed Dec 30 18:55:45 2015 From: wbx at openadk.org (Waldemar Brodkorb) Date: Thu, 31 Dec 2015 00:55:45 +0100 Subject: [uClinux-dev] [PATCH 3/6] h8300 address space is 24bit. In-Reply-To: <1451519748-20229-1-git-send-email-wbx@openadk.org> References: <1451519748-20229-1-git-send-email-wbx@openadk.org> Message-ID: <1451519748-20229-4-git-send-email-wbx@openadk.org> From: Yoshinori Sato Signed-off-by: Yoshinori Sato Signed-off-by: Waldemar Brodkorb --- flthdr.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/flthdr.c b/flthdr.c index 8a8b97c..0401e20 100644 --- a/flthdr.c +++ b/flthdr.c @@ -167,8 +167,16 @@ process_file(const char *ifile, const char *ofile) r = ntohl(relocs[i]); raddr = flat_get_relocate_addr(r); printf(" %u\t0x%08lx (0x%08"PRIx32")\t", i, r, raddr); +#if defined(TARGET_h8300) + raddr &= ~0x00000001; +#endif fseek_stream(&ifp, sizeof(old_hdr) + raddr, SEEK_SET); fread_stream(&addr, sizeof(addr), 1, &ifp); +#if defined(TARGET_h8300) + addr = ntohl(addr); + if (r & 1) + addr &= 0x00ffffff; +#endif printf("%"PRIx32"\n", addr); } -- 1.7.10.4 From wbx at openadk.org Wed Dec 30 18:55:42 2015 From: wbx at openadk.org (Waldemar Brodkorb) Date: Thu, 31 Dec 2015 00:55:42 +0100 Subject: [uClinux-dev] [PATCH 0/6] sync with uClibc-ng elf2flt Message-ID: <1451519748-20229-1-git-send-email-wbx@openadk.org> Sync part of the patches from http://cgit.uclibc-ng.org/cgi/cgit/elf2flt.git/ required to support H8/300 and Xtensa. Tested with GDB simulator for H8/300 and Qemu for Xtensa. Waldemar Brodkorb (3): dlopen is used by newer binutils, so check for it recent binutils for h8/300 no longer use prefix Add xtensa support Yoshinori Sato (3): h8300 address space is 24bit. H8/300 relocation fix R_H8_DIR24 fix configure.ac | 3 ++- elf2flt.c | 83 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++ elf2flt.ld.in | 7 +++-- flthdr.c | 8 ++++++ 4 files changed, 98 insertions(+), 3 deletions(-) -- 1.7.10.4 From wbx at openadk.org Wed Dec 30 18:55:46 2015 From: wbx at openadk.org (Waldemar Brodkorb) Date: Thu, 31 Dec 2015 00:55:46 +0100 Subject: [uClinux-dev] [PATCH 4/6] H8/300 relocation fix In-Reply-To: <1451519748-20229-1-git-send-email-wbx@openadk.org> References: <1451519748-20229-1-git-send-email-wbx@openadk.org> Message-ID: <1451519748-20229-5-git-send-email-wbx@openadk.org> From: Yoshinori Sato Add new relocation R_H8_DISP32A16. hi-byte clear on R_H8_DIR32 R_H8_DIR24A8 R_H8_DIR24R8 R_H8_DIR32A16 R_H8_DISP32A16 Signed-off-by: Yoshinori Sato Signed-off-by: Waldemar Brodkorb --- elf2flt.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/elf2flt.c b/elf2flt.c index 60f5207..17affd9 100644 --- a/elf2flt.c +++ b/elf2flt.c @@ -723,6 +723,17 @@ dump_symbols(symbols, number_of_symbols); flat_reloc_count++; break; +#elif defined (TARGET_h8300) + case R_H8_DIR32: + case R_H8_DIR24A8: + case R_H8_DIR24R8: + case R_H8_DIR32A16: + case R_H8_DISP32A16: + r_mem[0] = 0; + goto good_32bit_resolved_reloc; + case R_H8_PCREL8: + case R_H8_PCREL16: + continue; #else default: /* The default is to assume that the @@ -878,6 +889,7 @@ dump_symbols(symbols, number_of_symbols); break; case R_H8_DIR32: case R_H8_DIR32A16: /* currently 32, could be made 16 */ + case R_H8_DISP32A16: if (sym_reloc_size != 4) { printf("R_H8_DIR32 size %d\n", sym_reloc_size); bad_relocs++; @@ -889,6 +901,7 @@ dump_symbols(symbols, number_of_symbols); sym_addr += sym_vma + q->addend; break; case R_H8_PCREL16: + relocation_needed = 0; sym_vma = 0; sym_addr = (*(q->sym_ptr_ptr))->value; sym_addr += sym_vma + q->addend; @@ -898,6 +911,7 @@ dump_symbols(symbols, number_of_symbols); bfd_big_endian(abs_bfd) ? htons(sym_addr) : sym_addr; continue; case R_H8_PCREL8: + relocation_needed = 0; sym_vma = 0; sym_addr = (*(q->sym_ptr_ptr))->value; sym_addr += sym_vma + q->addend; -- 1.7.10.4 From wbx at openadk.org Wed Dec 30 18:55:47 2015 From: wbx at openadk.org (Waldemar Brodkorb) Date: Thu, 31 Dec 2015 00:55:47 +0100 Subject: [uClinux-dev] [PATCH 5/6] R_H8_DIR24 fix In-Reply-To: <1451519748-20229-1-git-send-email-wbx@openadk.org> References: <1451519748-20229-1-git-send-email-wbx@openadk.org> Message-ID: <1451519748-20229-6-git-send-email-wbx@openadk.org> From: Yoshinori Sato R_H8_DIR24A8 / R_H8_DIR24R8 keep all byte. Signed-off-by: Yoshinori Sato Signed-off-by: Waldemar Brodkorb --- elf2flt.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/elf2flt.c b/elf2flt.c index 17affd9..6134961 100644 --- a/elf2flt.c +++ b/elf2flt.c @@ -725,11 +725,11 @@ dump_symbols(symbols, number_of_symbols); break; #elif defined (TARGET_h8300) case R_H8_DIR32: - case R_H8_DIR24A8: - case R_H8_DIR24R8: case R_H8_DIR32A16: case R_H8_DISP32A16: r_mem[0] = 0; + case R_H8_DIR24A8: + case R_H8_DIR24R8: goto good_32bit_resolved_reloc; case R_H8_PCREL8: case R_H8_PCREL16: -- 1.7.10.4 From wbx at openadk.org Wed Dec 30 18:55:48 2015 From: wbx at openadk.org (Waldemar Brodkorb) Date: Thu, 31 Dec 2015 00:55:48 +0100 Subject: [uClinux-dev] [PATCH 6/6] Add xtensa support In-Reply-To: <1451519748-20229-1-git-send-email-wbx@openadk.org> References: <1451519748-20229-1-git-send-email-wbx@openadk.org> Message-ID: <1451519748-20229-7-git-send-email-wbx@openadk.org> This is forward ported version of patch from 2006' elf2flt by Oskar Schirmer . Signed-off-by: Max Filippov Signed-off-by: Waldemar Brodkorb --- elf2flt.c | 69 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++ elf2flt.ld.in | 7 ++++-- 2 files changed, 74 insertions(+), 2 deletions(-) diff --git a/elf2flt.c b/elf2flt.c index 6134961..fcd797c 100644 --- a/elf2flt.c +++ b/elf2flt.c @@ -6,6 +6,7 @@ * ELF format file handling. Extended relocation support for all of * text and data. * + * (c) 2008-2009, Xtensa support, Oskar Schirmer * (c) 2006 Support the -a (use_resolved) option for TARGET_arm. * Shaun Jackman * (c) 2004, Nios II support, Wentao Xu @@ -57,6 +58,8 @@ const char *elf2flt_progname; #include /* TARGET_* ELF support for the BFD library */ #elif defined(__CYGWIN__) || defined(__MINGW32__) || defined(TARGET_nios) || defined(TARGET_nios2) #include "cygwin-elf.h" /* Cygwin uses a local copy */ +#elif defined(TARGET_xtensa) +#include /* TARGET_* ELF support for the BFD library */ #elif defined(TARGET_microblaze) #include /* TARGET_* ELF support for the BFD library */ #elif defined(TARGET_v850) @@ -110,6 +113,8 @@ const char *elf2flt_progname; #define ARCH "nios" #elif defined(TARGET_nios2) #define ARCH "nios2" +#elif defined(TARGET_xtensa) +#define ARCH "xtensa" #else #error "Don't know how to support your CPU architecture??" #endif @@ -734,6 +739,53 @@ dump_symbols(symbols, number_of_symbols); case R_H8_PCREL8: case R_H8_PCREL16: continue; +#elif defined(TARGET_xtensa) + case R_XTENSA_NONE: + case R_XTENSA_OP0: + case R_XTENSA_OP1: + case R_XTENSA_OP2: + case R_XTENSA_SLOT0_OP: + case R_XTENSA_SLOT1_OP: + case R_XTENSA_SLOT2_OP: + case R_XTENSA_SLOT3_OP: + case R_XTENSA_SLOT4_OP: + case R_XTENSA_SLOT5_OP: + case R_XTENSA_SLOT6_OP: + case R_XTENSA_SLOT7_OP: + case R_XTENSA_SLOT8_OP: + case R_XTENSA_SLOT9_OP: + case R_XTENSA_SLOT10_OP: + case R_XTENSA_SLOT11_OP: + case R_XTENSA_SLOT12_OP: + case R_XTENSA_SLOT13_OP: + case R_XTENSA_SLOT14_OP: + case R_XTENSA_SLOT0_ALT: + case R_XTENSA_SLOT1_ALT: + case R_XTENSA_SLOT2_ALT: + case R_XTENSA_SLOT3_ALT: + case R_XTENSA_SLOT4_ALT: + case R_XTENSA_SLOT5_ALT: + case R_XTENSA_SLOT6_ALT: + case R_XTENSA_SLOT7_ALT: + case R_XTENSA_SLOT8_ALT: + case R_XTENSA_SLOT9_ALT: + case R_XTENSA_SLOT10_ALT: + case R_XTENSA_SLOT11_ALT: + case R_XTENSA_SLOT12_ALT: + case R_XTENSA_SLOT13_ALT: + case R_XTENSA_SLOT14_ALT: + case R_XTENSA_ASM_EXPAND: + case R_XTENSA_ASM_SIMPLIFY: + case R_XTENSA_DIFF8: + case R_XTENSA_DIFF16: + case R_XTENSA_DIFF32: + case R_XTENSA_32_PCREL: + continue; + case R_XTENSA_32: + case R_XTENSA_PLT: + goto good_32bit_resolved_reloc; + default: + goto bad_resolved_reloc; #else default: /* The default is to assume that the @@ -769,6 +821,23 @@ dump_symbols(symbols, number_of_symbols); } } else { /* Calculate the sym address ourselves. */ +#if defined(TARGET_xtensa) + /* For xtensa, calculation of addresses won't + work this way. binutils "ld -r" generate + different relocation types, among others + type 20, R_XTENSA_SLOT0_OP. The latter is + produced for various opcodes that differ + in size and format, some will have the + addend filled in when linking, others won't. + For elf2flt to handle these relocations + would involve analysing the opcodes in + detail. Therefore, elf2flt for xtensa is + patched to work with "-a" option solely, + which will take output of "ld -q". + */ + printf("ERROR: cannot run without '-a'\n"); + exit(1); +#endif sym_reloc_size = bfd_get_reloc_size(q->howto); #if !defined(TARGET_h8300) && !defined(TARGET_e1) && !defined(TARGET_bfin) && !defined(TARGET_m68k) diff --git a/elf2flt.ld.in b/elf2flt.ld.in index 5353413..bfda0ef 100644 --- a/elf2flt.ld.in +++ b/elf2flt.ld.in @@ -16,15 +16,18 @@ SECTIONS { . = . + 4; . = ALIGN(0x4) ; @SYMBOL_PREFIX at _stext = . ; - *(.text) - *(.text.*) + *(.literal .text) + *(.literal.* .text.*) *(.gnu.warning) *(.stub) + *(.gnu.linkonce.literal.*) *(.gnu.linkonce.t*) *(.glue_7t) *(.glue_7) *(.jcr) + *(.init.literal) KEEP (*(.init)) + *(.fini.literal) KEEP (*(.fini)) W_RODAT *(.rodata) -- 1.7.10.4