From tinguely at casselton.net Wed Sep 2 16:49:12 2009 From: tinguely at casselton.net (Mark Tinguely) Date: Wed Sep 2 16:49:18 2009 Subject: remove dangling allocations Message-ID: <200909021649.n82GnBb1072783@casselton.net> Without the pressure of getting something to work for FreeBSD 8.0, I would like to revisit this issue. Revisions 181296 and 195779 added cache fixes, and I think we should also remove a couple dangling allocations. Without removing the dangling allocation, the next time we map that page, our cache fixing code will think these pages are still used somewhere else and will unnecessarially turn off caching. As the system runs for days, more and more pages could dangle and performance could suffer. Removing the dangling allocation, may allow future simplification of the cache fixing code. Index: arm/arm/vm_machdep.c =================================================================== --- arm/arm/vm_machdep.c (revision 196359) +++ arm/arm/vm_machdep.c (working copy) @@ -172,6 +172,9 @@ sf_buf_free(struct sf_buf *sf) if (sf->ref_count == 0) { TAILQ_INSERT_TAIL(&sf_buf_freelist, sf, free_entry); nsfbufsused--; + pmap_kremove(sf->kva); + sf->m = NULL; + LIST_REMOVE(sf, list_entry); if (sf_buf_alloc_want > 0) wakeup_one(&sf_buf_freelist); } @@ -452,9 +455,12 @@ arm_unmap_nocache(void *addr, vm_size_t size) size = round_page(size); i = (raddr - arm_nocache_startaddr) / (PAGE_SIZE); - for (; size > 0; size -= PAGE_SIZE, i++) + for (; size > 0; size -= PAGE_SIZE, i++) { arm_nocache_allocated[i / BITS_PER_INT] &= ~(1 << (i % BITS_PER_INT)); + pmap_kremove(raddr); + raddr += PAGE_SIZE; + } } #ifdef ARM_USE_SMALL_ALLOC From don at donhayford.com Thu Sep 3 13:16:21 2009 From: don at donhayford.com (Donald T Hayford) Date: Thu Sep 3 13:16:27 2009 Subject: Marvel Sheevaplug In-Reply-To: References: Message-ID: <4A8EBAD5.9070300@donhayford.com> Rafael Mentz Aquino wrote: > Marvell>> dhcp > BOOTP broadcast 1 > *** Unhandled DHCP Option in OFFER/ACK: 52 > *** Unhandled DHCP Option in OFFER/ACK: 52 > DHCP client bound to address 192.168.2.103 > Marvell>> set serverip 192.168.2.10 > Marvell>> tftpboot 90000 kernel.bin > Using egiga0 device > TFTP from server 192.168.2.10; our IP address is 192.168.2.103 > Filename 'kernel.bin'. > Load address: 0x90000 > Loading: ################################################################# > ################################################################# > ################################################################# > ################################################################# > ################################################################# > ################################################################# > ################################################################# > ################################################################# > ############# > done > Bytes transferred = 2728820 (29a374 hex) > Marvell>> go 90000 > ## Starting application at 0x00090000 ... > Try a load address of 0x900000, not 0x90000. Regards, Don From bugmaster at FreeBSD.org Mon Sep 7 11:06:55 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Sep 7 11:07:25 2009 Subject: Current problem reports assigned to freebsd-arm@FreeBSD.org Message-ID: <200909071106.n87B6ssG010152@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o arm/134368 arm [patch] nslu2_led driver for the LEDs on the NSLU2 o arm/134338 arm [patch] Lock GPIO accesses on ixp425 o arm/134092 arm [patch] NSLU.hints contains wrong hints for on board n 3 problems total. From jack.avenger at gmail.com Wed Sep 9 16:40:07 2009 From: jack.avenger at gmail.com (Jack Avenger) Date: Wed Sep 9 16:40:16 2009 Subject: Can't boot Marvel Sheevaplug from USB Message-ID: <54EFFA76-B976-4370-85EC-DA2EE200EA35@gmail.com> Which options should be included in kernel configuration to boot 8- CURRENT on SHEEVAPLUG? I tried options ROOTDEVNAME="ufs:/dev/da0s1a", but no success: usbus0: 480Mbps High Speed USB v2.0 Root mount waiting for: usbus0 ugen0.1: at usbus0 uhub0: on usbus0 uhub0: 1 port with 1 removable, self powered Root mount waiting for: usbus0 ugen0.2: at usbus0 umass0: on usbus0 umass0: SCSI over Bulk-Only; quirks = 0x0000 Root mount waiting for: usbus0 umass0:0:0:-1: Attached to scbus0 Trying to mount root from ufs:/dev/da0a ROOT MOUNT ERROR: If you have invalid mount options, reboot, and first try the following from the loader prompt: set vfs.root.mountfrom.options=rw and then remove invalid mount options from /etc/fstab. Loader variables: vfs.root.mountfrom= vfs.root.mountfrom.options= Manual root filesystem specification: : Mount using filesystem eg. ufs:/dev/da0s1a eg. cd9660:/dev/acd0 This is equivalent to: mount -t cd9660 /dev/ acd0 / ? List valid disk boot devices Abort manual input mountroot> it seems like there is an error accessing USB Flash, but it work when boot from NFS is compiled into kernel. From raj at semihalf.com Sat Sep 12 18:06:58 2009 From: raj at semihalf.com (Rafal Jaworowski) Date: Sat Sep 12 18:07:04 2009 Subject: Can't boot Marvel Sheevaplug from USB In-Reply-To: <54EFFA76-B976-4370-85EC-DA2EE200EA35@gmail.com> References: <54EFFA76-B976-4370-85EC-DA2EE200EA35@gmail.com> Message-ID: <46DC49CD-65C6-4B4F-9ACA-AAAF1CF6E243@semihalf.com> On 2009-09-09, at 18:07, Jack Avenger wrote: > Which options should be included in kernel configuration to boot 8- > CURRENT on SHEEVAPLUG? > > I tried options ROOTDEVNAME="ufs:/dev/da0s1a", but no success: > > usbus0: 480Mbps High Speed USB v2.0 > Root mount waiting for: usbus0 > ugen0.1: at usbus0 > uhub0: on > usbus0 > uhub0: 1 port with 1 removable, self powered > Root mount waiting for: usbus0 > ugen0.2: at usbus0 > umass0: on > usbus0 > umass0: SCSI over Bulk-Only; quirks = 0x0000 > Root mount waiting for: usbus0 > umass0:0:0:-1: Attached to scbus0 > Trying to mount root from ufs:/dev/da0a > ROOT MOUNT ERROR: > If you have invalid mount options, reboot, and first try the > following from > the loader prompt: Is your device really a sliced ufs:/dev/da0s1a (in the log there's only attempted ufs:/dev/da0a)? Please show output of the '?' command at mount root prompt. Rafal From bugmaster at FreeBSD.org Mon Sep 14 11:06:55 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Sep 14 11:07:33 2009 Subject: Current problem reports assigned to freebsd-arm@FreeBSD.org Message-ID: <200909141106.n8EB6taL072253@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o arm/134368 arm [patch] nslu2_led driver for the LEDs on the NSLU2 o arm/134338 arm [patch] Lock GPIO accesses on ixp425 o arm/134092 arm [patch] NSLU.hints contains wrong hints for on board n 3 problems total. From jack.avenger at gmail.com Mon Sep 14 17:12:58 2009 From: jack.avenger at gmail.com (Jack Avenger) Date: Mon Sep 14 17:13:07 2009 Subject: Can't boot Marvel Sheevaplug from USB References: Message-ID: <19AEA5AF-21CD-4EE7-9D4F-DD1CBC68218E@gmail.com> On 12 ???. 2009, at 21:06, Rafal Jaworowski wrote: > > On 2009-09-09, at 18:07, Jack Avenger wrote: > >> Which options should be included in kernel configuration to boot 8- >> CURRENT on SHEEVAPLUG? >> >> I tried options ROOTDEVNAME="ufs:/dev/da0s1a", but no success: >> >> usbus0: 480Mbps High Speed USB v2.0 >> Root mount waiting for: usbus0 >> ugen0.1: at usbus0 >> uhub0: on >> usbus0 >> uhub0: 1 port with 1 removable, self powered >> Root mount waiting for: usbus0 >> ugen0.2: at usbus0 >> umass0: on >> usbus0 >> umass0: SCSI over Bulk-Only; quirks = 0x0000 >> Root mount waiting for: usbus0 >> umass0:0:0:-1: Attached to scbus0 >> Trying to mount root from ufs:/dev/da0a >> ROOT MOUNT ERROR: >> If you have invalid mount options, reboot, and first try the >> following from >> the loader prompt: > > Is your device really a sliced ufs:/dev/da0s1a (in the log there's > only attempted ufs:/dev/da0a)? Ooops. Of course it was ufs:/dev/da0s1a usbus0: 480Mbps High Speed USB v2.0 Root mount waiting for: usbus0 ugen0.1: at usbus0 uhub0: on usbus0 uhub0: 1 port with 1 removable, self powered Root mount waiting for: usbus0 ugen0.2: at usbus0 umass0: on usbus0 umass0: SCSI over Bulk-Only; quirks = 0x0000 Root mount waiting for: usbus0 umass0:0:0:-1: Attached to scbus0 Trying to mount root from ufs:/dev/da0s1a ROOT MOUNT ERROR: If you have invalid mount options, reboot, and first try the following from the loader prompt: set vfs.root.mountfrom.options=rw and then remove invalid mount options from /etc/fstab. Loader variables: vfs.root.mountfrom= vfs.root.mountfrom.options= Manual root filesystem specification: : Mount using filesystem eg. ufs:/dev/da0s1a eg. cd9660:/dev/acd0 This is equivalent to: mount -t cd9660 /dev/ acd0 / ? List valid disk boot devices Abort manual input mountroot> > Please show output of the '?' command at mount root prompt. mountroot> ? List of GEOM managed disk devices: Loader variables: vfs.root.mountfrom= vfs.root.mountfrom.options= Manual root filesystem specification: : Mount using filesystem eg. ufs:/dev/da0s1a eg. cd9660:/dev/acd0 This is equivalent to: mount -t cd9660 /dev/ acd0 / ? List valid disk boot devices Abort manual input mountroot> From bugmaster at FreeBSD.org Mon Sep 21 11:06:51 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Sep 21 11:07:37 2009 Subject: Current problem reports assigned to freebsd-arm@FreeBSD.org Message-ID: <200909211106.n8LB6oFn030174@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o arm/134368 arm [patch] nslu2_led driver for the LEDs on the NSLU2 o arm/134338 arm [patch] Lock GPIO accesses on ixp425 o arm/134092 arm [patch] NSLU.hints contains wrong hints for on board n 3 problems total. From tom at tomjudge.com Mon Sep 21 16:22:45 2009 From: tom at tomjudge.com (Tom Judge) Date: Mon Sep 21 16:23:18 2009 Subject: Adding support for the Intel SS4000-E NAS aka the EM-7210 Message-ID: <4AB7A398.4040905@tomjudge.com> Hi, I am trying to add support for the Intel SS4000-E/EM7210 to FreeBSD, I have copied all of the files for the EP80219 as this seems to be what the board is based on, and modified the interrupt assignment code. See the patch agains sys/arm here: http://www.tomjudge.com/tmp/em-7210-patch I am also having trouble with loading the kernel at the default location, (instructions from here: http://wiki.freebsd.org/FreeBSDAvila) as RedBoot reports that there is no memory at the load address. Currently when I try to load this kernel at the phys address using reboot and try to run the kernel I get nothing outputed on the console. I used the phys address from the addresses that the linux kernel is loaded into out of flash. (see output below) Could someone please give me some hints on what I am doing wrong and need to change? The board is currently supported by the Linux kernel (as the em7210.c) so I was hoping that adding support to FreeBSD would not be difficult. More information about the system can be found here: http://em7210.kwaak.net/ Thanks in advance for any help, Tom > $ sudo cu -l cuau0 -s 115200 Password: Connected +No network interfaces found EM-7210 ver.T04 2005-12-12 (For ver.AA) == Executing boot script in 1.000 seconds - enter ^C to abort ^C RedBoot> ^C RedBoot> fis load rammode RedBoot> go +Ethernet eth0: MAC address 00:0e:0c:b6:bf:1a IP: 10.9.9.1/255.255.255.0, Gateway: 10.9.9.1 Default server: 10.9.9.10, DNS server IP: 0.0.0.0 EM-7210 (RAM mode) 2005-12-22 == Executing boot script in 1.000 seconds - enter ^C to abort ^C RedBoot> ^C RedBoot> fis list Name FLASH addr Mem addr Length Entry point RedBoot 0xF0000000 0xF0000000 0x00040000 0x00000000 RedBoot config 0xF1FC0000 0xF1FC0000 0x00001000 0x00000000 FIS directory 0xF1FE0000 0xF1FE0000 0x00020000 0x00000000 rammode 0xF0060000 0x00200000 0x00040000 0x00200000 log 0xF0040000 0xF0040000 0x00020000 0x00000000 naskey 0xF00A0000 0xF00A0000 0x00020000 0x01008000 zImage 0xF00C0000 0x01008000 0x00200000 0x01008000 ramdisk.gz 0xF02C0000 0x01800000 0x00400000 0x01800000 vendor 0xF06C0000 0xF06C0000 0x01880000 0x01800000 wmdata 0xF1F40000 0xF1F40000 0x00080000 0x01800000 RedBoot> From rpaulo at gmail.com Fri Sep 25 12:06:38 2009 From: rpaulo at gmail.com (Rui Paulo) Date: Fri Sep 25 12:06:44 2009 Subject: Adding support for the Intel SS4000-E NAS aka the EM-7210 In-Reply-To: <4AB7A398.4040905@tomjudge.com> References: <4AB7A398.4040905@tomjudge.com> Message-ID: <5B269040-CEB8-4E07-9023-9605B04A62DA@gmail.com> On 21 Sep 2009, at 17:02, Tom Judge wrote: > Hi, > > I am trying to add support for the Intel SS4000-E/EM7210 to FreeBSD, I > have copied all of the files for the EP80219 as this seems to be what > the board is based on, and modified the interrupt assignment code. > See > the patch agains sys/arm here: http://www.tomjudge.com/tmp/em-7210-patch > > I am also having trouble with loading the kernel at the default > location, (instructions from here: http://wiki.freebsd.org/FreeBSDAvila > ) > as RedBoot reports that there is no memory at the load address. > Currently when I try to load this kernel at the phys address using > reboot and try to run the kernel I get nothing outputed on the > console. > I used the phys address from the addresses that the linux kernel is > loaded into out of flash. (see output below) > > Could someone please give me some hints on what I am doing wrong and > need to change? The board is currently supported by the Linux kernel > (as the em7210.c) so I was hoping that adding support to FreeBSD would > not be difficult. Are you sure 0x200000 is the correct load address? -- Rui Paulo From rpaulo at freebsd.org Fri Sep 25 12:16:32 2009 From: rpaulo at freebsd.org (Rui Paulo) Date: Fri Sep 25 12:16:37 2009 Subject: Exporting cpu_class Message-ID: Hi, I need to export cpu_class to the outside world, so I plan to commit the attached patch soon. If you don't like it, please speak up. Thanks, -- Rui Paulo -------------- next part -------------- A non-text attachment was scrubbed... Name: exportcpuclass.diff Type: application/octet-stream Size: 1750 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-arm/attachments/20090925/4ca9d1fc/exportcpuclass.obj -------------- next part -------------- From stas at FreeBSD.org Fri Sep 25 12:58:48 2009 From: stas at FreeBSD.org (Stanislav Sedov) Date: Fri Sep 25 13:00:18 2009 Subject: Exporting cpu_class In-Reply-To: References: Message-ID: <20090925165843.88eecdcd.stas@FreeBSD.org> On Fri, 25 Sep 2009 12:48:40 +0100 Rui Paulo mentioned: > Hi, > I need to export cpu_class to the outside world, so I plan to commit > the attached patch soon. If you don't like it, please speak up. > Looks ok to me. -- Stanislav Sedov ST4096-RIPE -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 801 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-arm/attachments/20090925/ae3013ea/attachment.pgp From tom at tomjudge.com Fri Sep 25 13:08:27 2009 From: tom at tomjudge.com (Tom Judge) Date: Fri Sep 25 13:08:33 2009 Subject: Adding support for the Intel SS4000-E NAS aka the EM-7210 In-Reply-To: <5B269040-CEB8-4E07-9023-9605B04A62DA@gmail.com> References: <4AB7A398.4040905@tomjudge.com> <5B269040-CEB8-4E07-9023-9605B04A62DA@gmail.com> Message-ID: <4ABCC0AA.7040003@tomjudge.com> Rui Paulo wrote: > On 21 Sep 2009, at 17:02, Tom Judge wrote: > >> Hi, >> >> I am trying to add support for the Intel SS4000-E/EM7210 to FreeBSD, I >> have copied all of the files for the EP80219 as this seems to be what >> the board is based on, and modified the interrupt assignment code. See >> the patch agains sys/arm here: http://www.tomjudge.com/tmp/em-7210-patch >> >> I am also having trouble with loading the kernel at the default >> location, (instructions from here: http://wiki.freebsd.org/FreeBSDAvila) >> as RedBoot reports that there is no memory at the load address. >> Currently when I try to load this kernel at the phys address using >> reboot and try to run the kernel I get nothing outputed on the console. >> I used the phys address from the addresses that the linux kernel is >> loaded into out of flash. (see output below) >> >> Could someone please give me some hints on what I am doing wrong and >> need to change? The board is currently supported by the Linux kernel >> (as the em7210.c) so I was hoping that adding support to FreeBSD would >> not be difficult. > > Are you sure 0x200000 is the correct load address? > > -- > Rui Paulo > > > Hi Rui, First I would like to say thanks for replying, this is my first experiment with trying to get freebsd to work on another platform so please treat me a newbe to all this (thanks). Looking that where the linux kernel is loaded it seems the load address is 0x01008000. However it seems like it could be loaded at 0x200000, as there is a second copy of redboot on the unit, that supports the NIC, that is loaded add this address. See this here for the details of what get loaded where on the unit: http://www.tomjudge.com/index.php/SS4000-E/FreeBSD_Install Tom From stas at FreeBSD.org Fri Sep 25 13:20:52 2009 From: stas at FreeBSD.org (Stanislav Sedov) Date: Fri Sep 25 13:20:59 2009 Subject: Adding support for the Intel SS4000-E NAS aka the EM-7210 In-Reply-To: <4ABCC0AA.7040003@tomjudge.com> References: <4AB7A398.4040905@tomjudge.com> <5B269040-CEB8-4E07-9023-9605B04A62DA@gmail.com> <4ABCC0AA.7040003@tomjudge.com> Message-ID: <20090925172049.ebecbd64.stas@FreeBSD.org> On Fri, 25 Sep 2009 13:07:54 +0000 Tom Judge mentioned: > Rui Paulo wrote: > > On 21 Sep 2009, at 17:02, Tom Judge wrote: > > > >> Hi, > >> > >> I am trying to add support for the Intel SS4000-E/EM7210 to FreeBSD, I > >> have copied all of the files for the EP80219 as this seems to be what > >> the board is based on, and modified the interrupt assignment code. See > >> the patch agains sys/arm here: http://www.tomjudge.com/tmp/em-7210-patch > >> > >> I am also having trouble with loading the kernel at the default > >> location, (instructions from here: http://wiki.freebsd.org/FreeBSDAvila) > >> as RedBoot reports that there is no memory at the load address. > >> Currently when I try to load this kernel at the phys address using > >> reboot and try to run the kernel I get nothing outputed on the console. > >> I used the phys address from the addresses that the linux kernel is > >> loaded into out of flash. (see output below) > >> > >> Could someone please give me some hints on what I am doing wrong and > >> need to change? The board is currently supported by the Linux kernel > >> (as the em7210.c) so I was hoping that adding support to FreeBSD would > >> not be difficult. > > > > Are you sure 0x200000 is the correct load address? > > > > -- > > Rui Paulo > > > > > > > Hi Rui, > > First I would like to say thanks for replying, this is my first > experiment with trying to get freebsd to work on another platform so > please treat me a newbe to all this (thanks). > > Looking that where the linux kernel is loaded it seems the load address > is 0x01008000. > > However it seems like it could be loaded at 0x200000, as there is a > second copy of redboot on the unit, that supports the NIC, that is > loaded add this address. > > See this here for the details of what get loaded where on the unit: > http://www.tomjudge.com/index.php/SS4000-E/FreeBSD_Install The default load address of the AVILA FreeBSD kernel is 10200000 so it expects to be loaded here. As I see from your patch you changed it to be 0x01008000 instead. So you should probably either load the kernel to this address, or change the corresponding KERNPHYSADDR parameter to 0x200000. Does this board has JTAG port available? It will make the debugging much easier. -- Stanislav Sedov ST4096-RIPE -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 801 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-arm/attachments/20090925/2b3cfd4e/attachment.pgp From stas at FreeBSD.org Fri Sep 25 13:34:03 2009 From: stas at FreeBSD.org (Stanislav Sedov) Date: Fri Sep 25 13:34:09 2009 Subject: Adding support for the Intel SS4000-E NAS aka the EM-7210 In-Reply-To: <4AB7A398.4040905@tomjudge.com> References: <4AB7A398.4040905@tomjudge.com> Message-ID: <20090925173400.48407c77.stas@FreeBSD.org> On Mon, 21 Sep 2009 16:02:32 +0000 Tom Judge mentioned: > Hi, > > I am trying to add support for the Intel SS4000-E/EM7210 to FreeBSD, I > have copied all of the files for the EP80219 as this seems to be what > the board is based on, and modified the interrupt assignment code. See > the patch agains sys/arm here: http://www.tomjudge.com/tmp/em-7210-patch > Hi, Tom! It's great to hear you're working on this project! It's hard to say what's wrong with your setup, but here're some things I noteced. First, KERNVIRTADDR appears to be incorrect in your setup as you're trying to map the kernel very low (0x01008000). In this case very low amount of virtual address space will be left for user-level applications. Try to map it to some address above 0xc0000000, e.g. to 0xc1008000. I also do not quite understand why you're using address 0xa0100000 for the first helper page mapping? What is the layout of memory on your board? Is anything useable is mapped here? Good luck! -- Stanislav Sedov ST4096-RIPE -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 801 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-arm/attachments/20090925/0304b99f/attachment.pgp From tom at tomjudge.com Fri Sep 25 13:54:38 2009 From: tom at tomjudge.com (Tom Judge) Date: Fri Sep 25 13:54:45 2009 Subject: Adding support for the Intel SS4000-E NAS aka the EM-7210 In-Reply-To: <20090925172049.ebecbd64.stas@FreeBSD.org> References: <4AB7A398.4040905@tomjudge.com> <5B269040-CEB8-4E07-9023-9605B04A62DA@gmail.com> <4ABCC0AA.7040003@tomjudge.com> <20090925172049.ebecbd64.stas@FreeBSD.org> Message-ID: <4ABCCB7D.9030503@tomjudge.com> Stanislav Sedov wrote: > On Fri, 25 Sep 2009 13:07:54 +0000 > Tom Judge mentioned: > > >> Rui Paulo wrote: >> >>> On 21 Sep 2009, at 17:02, Tom Judge wrote: >>> >>> >>> Are you sure 0x200000 is the correct load address? >>> >>> -- >>> Rui Paulo >>> >>> >>> >>> >> Hi Rui, >> >> First I would like to say thanks for replying, this is my first >> experiment with trying to get freebsd to work on another platform so >> please treat me a newbe to all this (thanks). >> >> Looking that where the linux kernel is loaded it seems the load address >> is 0x01008000. >> >> However it seems like it could be loaded at 0x200000, as there is a >> second copy of redboot on the unit, that supports the NIC, that is >> loaded add this address. >> >> See this here for the details of what get loaded where on the unit: >> http://www.tomjudge.com/index.php/SS4000-E/FreeBSD_Install >> > > The default load address of the AVILA FreeBSD kernel is 10200000 so > it expects to be loaded here. As I see from your patch you changed > it to be 0x01008000 instead. So you should probably either load the > kernel to this address, or change the corresponding KERNPHYSADDR > parameter to 0x200000. > > When I had KERNPHYSADDR and KERNVIRTADDR set to 0x01008000 I was unable to make any progress on getting the system to boot. Last night I was working on the patch again, and started by using the std.aliva file as a base for my std.em7210 rather than std.ep80219. However I have not yet had a chance to test this as I was working my way though making user the devmap matched the devmap used by the linux kernel. I have also been looking at alvia_machdep.c + eq80219_machdep.c and comparing it to the em7210_machdep.c to remove magic numbers and replace them with macros/defines as used in the aliva board. Here is my current work: http://www.tomjudge.com/tmp/patch-em7210-round2 > Does this board has JTAG port available? It will make the debugging > much easier. > > Yes there is a jtag port on the board, it seems to be a standard 20 pin ARM header on the board (see image here: http://www.kwaak.net/fotos/fotos-nas/slide_14.html). Can anyone recommend a reasonably priced jtag cable? Preferable that would work on FreeBSD. Thanks TJ From stas at FreeBSD.org Fri Sep 25 14:14:31 2009 From: stas at FreeBSD.org (Stanislav Sedov) Date: Fri Sep 25 14:14:38 2009 Subject: Adding support for the Intel SS4000-E NAS aka the EM-7210 In-Reply-To: <4ABCCB7D.9030503@tomjudge.com> References: <4AB7A398.4040905@tomjudge.com> <5B269040-CEB8-4E07-9023-9605B04A62DA@gmail.com> <4ABCC0AA.7040003@tomjudge.com> <20090925172049.ebecbd64.stas@FreeBSD.org> <4ABCCB7D.9030503@tomjudge.com> Message-ID: <20090925181428.5cfc759f.stas@FreeBSD.org> On Fri, 25 Sep 2009 13:54:05 +0000 Tom Judge mentioned: > Stanislav Sedov wrote: > > On Fri, 25 Sep 2009 13:07:54 +0000 > > Tom Judge mentioned: > > > > > >> Rui Paulo wrote: > >> > >>> On 21 Sep 2009, at 17:02, Tom Judge wrote: > >>> > >>> > >>> Are you sure 0x200000 is the correct load address? > >>> > >>> -- > >>> Rui Paulo > >>> > >>> > >>> > >>> > >> Hi Rui, > >> > >> First I would like to say thanks for replying, this is my first > >> experiment with trying to get freebsd to work on another platform so > >> please treat me a newbe to all this (thanks). > >> > >> Looking that where the linux kernel is loaded it seems the load address > >> is 0x01008000. > >> > >> However it seems like it could be loaded at 0x200000, as there is a > >> second copy of redboot on the unit, that supports the NIC, that is > >> loaded add this address. > >> > >> See this here for the details of what get loaded where on the unit: > >> http://www.tomjudge.com/index.php/SS4000-E/FreeBSD_Install > >> > > > > The default load address of the AVILA FreeBSD kernel is 10200000 so > > it expects to be loaded here. As I see from your patch you changed > > it to be 0x01008000 instead. So you should probably either load the > > kernel to this address, or change the corresponding KERNPHYSADDR > > parameter to 0x200000. > > > > > > When I had KERNPHYSADDR and KERNVIRTADDR set to 0x01008000 I was unable > to make any progress on getting the system to boot. Last night I was > working on the patch again, and started by using the std.aliva file as a > base for my std.em7210 rather than std.ep80219. However I have not yet > had a chance to test this as I was working my way though making user the > devmap matched the devmap used by the linux kernel. > > I have also been looking at alvia_machdep.c + eq80219_machdep.c and > comparing it to the em7210_machdep.c to remove magic numbers and replace > them with macros/defines as used in the aliva board. > > Here is my current work: http://www.tomjudge.com/tmp/patch-em7210-round2 This looks better, but you're still using weird addresses for phys_avail and dump_avail ARM_USE_SMALL_ALLOC case. I don't know the memory layout of this board, but using addresses starting from 0xa0000000 for page mappings looks really wrong to me. BTW, I noticed you're using 0x0 address for the start address of the physical memory? Is it correct? Usualy, this address is the CPU start address and thus boot ROM gets mapped here so CPU can start executing ROM code upon boot. But your board may use different layout so you'd need to check this. > > > Does this board has JTAG port available? It will make the debugging > > much easier. > > > > > Yes there is a jtag port on the board, it seems to be a standard 20 pin > ARM header on the board (see image here: > http://www.kwaak.net/fotos/fotos-nas/slide_14.html). > > Can anyone recommend a reasonably priced jtag cable? Preferable that > would work on FreeBSD. > The choice of JTAG depends on the software that will be used. For me, OpenOCD works well. I can recommend the FTDI based cables as they're really fast and well supported (OpenMoko, for example, distributes one of them; they're usually Jtagkey clones). Simple Wiggler-like cables are much clower and less reliable, but is very cheap and can be made easily at home if not availble in shops (as it's merealy a pin-to-pin conversion from JTAG to IEEE1284). They requre the parallel LPT port to be present, though. -- Stanislav Sedov ST4096-RIPE -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 801 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-arm/attachments/20090925/b506c0d0/attachment.pgp From imp at bsdimp.com Fri Sep 25 15:24:43 2009 From: imp at bsdimp.com (M. Warner Losh) Date: Fri Sep 25 15:24:50 2009 Subject: Exporting cpu_class In-Reply-To: References: Message-ID: <20090925.092309.38327923.imp@bsdimp.com> In message: Rui Paulo writes: : Hi, : I need to export cpu_class to the outside world, so I plan to commit : the attached patch soon. If you don't like it, please speak up. Looks good to me. What do you need it for in the outside world? Warner From rpaulo at FreeBSD.org Fri Sep 25 22:08:06 2009 From: rpaulo at FreeBSD.org (Rui Paulo) Date: Fri Sep 25 22:08:12 2009 Subject: Exporting cpu_class In-Reply-To: <20090925.092309.38327923.imp@bsdimp.com> References: <20090925.092309.38327923.imp@bsdimp.com> Message-ID: <30297FD8-7811-4878-96E6-B29B2C518256@FreeBSD.org> On 25 Sep 2009, at 16:23, M. Warner Losh wrote: > In message: > Rui Paulo writes: > : Hi, > : I need to export cpu_class to the outside world, so I plan to commit > : the attached patch soon. If you don't like it, please speak up. > > Looks good to me. > > What do you need it for in the outside world? arm HWPMC. Namely in sys/dev/hwpmc/hwpmc_arm.c. -- Rui Paulo From tom at tomjudge.com Sat Sep 26 05:47:43 2009 From: tom at tomjudge.com (Tom Judge) Date: Sat Sep 26 05:47:50 2009 Subject: Adding support for the Intel SS4000-E NAS aka the EM-7210 In-Reply-To: <20090925181428.5cfc759f.stas@FreeBSD.org> References: <4AB7A398.4040905@tomjudge.com> <5B269040-CEB8-4E07-9023-9605B04A62DA@gmail.com> <4ABCC0AA.7040003@tomjudge.com> <20090925172049.ebecbd64.stas@FreeBSD.org> <4ABCCB7D.9030503@tomjudge.com> <20090925181428.5cfc759f.stas@FreeBSD.org> Message-ID: <4ABDAADC.6060008@tomjudge.com> <> Hi, Stanislav, Rue first thanks for your help with this. I have since relised the errors in my ways and now have a booting kernel that I can load at 0x01008000. It seems the first mistake that I made was to use the ep80219 as the base for my port. I should have read the linux notes more carefully as it states that they can boot the iq31244 kernel on this board. I have since then migrated the code to use the iq31244 as the base, and have a kernel that kind of boots. Fist thing I have noticed is I get this error while booting: pmap_bootstrap: WARNING! wrong cache mode for L2 pte @ 0xc1003c00 I don't really know how to fix this so some pointers would be welcome. The next problem is that I get the following error when either em or ata are compiled into my kernel: Fatal kernel mode data abort: 'External Linefetch Abort (P)' If I remove both ata and em from the kernel then the kernel gets to trying to mount the rootfs and fails because it wants to mount an NFS root from em0. Bellow is a full backtrace for the em crash and a backtrace for the ata crash can be found here: http://www.tomjudge.com/index.php/SS4000-E/Notes And my current code can be found as a patch here: http://www.tomjudge.com/tmp/em7210.patch Thanks in advance for the help Tom RedBoot> load -b 0x01008000 kernel Using default protocol (TFTP) Address offset = 0x40000000 Entry point: 0x01008100, address range: 0x01008000-0x01337274 RedBoot> go pmap_bootstrap: WARNING! wrong cache mode for L2 pte @ 0xc1003c00 KDB: debugger backends: ddb KDB: current backend: ddb Copyright (c) 1992-2009 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 9.0-CURRENT #14: Sat Sep 26 05:30:30 UTC 2009 root@rita.nodomain:/data/arm_build/arm/usr/src/sys/EM-7210 CPU: i80219 400MHz step A-0 (XScale core) DC enabled IC enabled WB enabled LABT branch prediction enabled 32KB/32B 32-way Instruction cache 32KB/32B 32-way write-back-locking Data cache real memory = 536870912 (512 MB) avail memory = 503738368 (480 MB) iq0: on motherboard obio0 on iq0 uart0: <16550 or compatible> on obio0 uart0: [FILTER] uart0: console (115200,n,8,1) itimer0: on iq0 iopwdog0: on iq0 pcib0: on iq0 pci0: on pcib0 Device 1 routed to irq 27 Device 2 routed to irq 30 Device 3 routed to irq 29 Device 5 routed to irq 30 Device 5 routed to irq 29 Device 5 routed to irq 27 em0: port 0xfe400000-0xfe40003f mem 0-0x1ffff,0x20000-0x3ffff irq 27 at device 1.0 on pci0 Fatal kernel mode data abort: 'External Linefetch Abort (P)' trapframe: 0xc00faae4 FSR=00000406, FAR=Invalid, spsr=200000d3 r0 =c13e3c00, r1 =cd5b9000, r2 =00000010, r3 =0000000a r4 =c317e008, r5 =cd5b9000, r6 =c13e3c00, r7 =c128d4fc r8 =c317e008, r9 =c1397280, r10=c317e000, r11=c00fab54 r12=c00fab58, ssp=c00fab30, slr=c1022a88, pc =c1022a84 [thread pid 0 tid 100000 ] Stopped at e1000_init_script_state_82541+0x24c: blx r7 db> bt Tracing pid 0 tid 100000 td 0xc133b240 db_trace_thread() at db_trace_thread+0xc scp=0xc1291910 rlv=0xc100d0f0 (db_command_init+0x2a8) rsp=0xc00fa7e0 rfp=0xc00fa7fc r10=0x00000001 r9=0xc1340d94 r8=0xc13385c4 r7=0x00000062 r6=0x00000002 r5=0x00000010 r4=0xc133b240 db_command_init() at db_command_init+0x1d0 scp=0xc100d018 rlv=0xc100cba0 (db_skip_to_eol+0x49c) rsp=0xc00fa800 rfp=0xc00fa8a4 r5=0x00000000 r4=0xc13188d0 db_skip_to_eol() at db_skip_to_eol+0x1d0 scp=0xc100c8d4 rlv=0xc100cd0c (db_command_loop+0x60) rsp=0xc00fa8a8 rfp=0xc00fa8b4 r10=0x00000000 r8=0x00000406 r7=0xc00faae4 r6=0xc1340d90 r5=0x600000d3 r4=0xc00fa8c0 db_command_loop() at db_command_loop+0xc scp=0xc100ccb8 rlv=0xc100f050 (X_db_sym_numargs+0xf4) rsp=0xc00fa8b8 rfp=0xc00fa9d4 X_db_sym_numargs() at X_db_sym_numargs+0x14 scp=0xc100ef70 rlv=0xc10fc0c4 (kdb_trap+0xa4) rsp=0xc00fa9d8 rfp=0xc00faa00 r4=0x000000c0 kdb_trap() at kdb_trap+0xc scp=0xc10fc02c rlv=0xc12a1dc4 (badaddr_read+0x280) rsp=0xc00faa04 rfp=0xc00faa20 r10=0x00000000 r9=0xc1397280 r8=0xc00faae4 r7=0x00000406 r6=0x00000000 r5=0x00000406 r4=0xc00faae4 badaddr_read() at badaddr_read+0xfc scp=0xc12a1c40 rlv=0xc12a225c (prefetch_abort_handler+0x440) rsp=0xc00faa24 rfp=0xc00faa44 r6=0xc133b240 r5=0xc00faef8 r4=0xc00faae4 prefetch_abort_handler() at prefetch_abort_handler+0x378 scp=0xc12a2194 rlv=0xc12a2428 (data_abort_handler+0x110) rsp=0xc00faa48 rfp=0xc00faae0 r7=0xc133b240 r6=0xc13e3c00 r5=0xc00faef8 r4=0xc133af78 data_abort_handler() at data_abort_handler+0xc scp=0xc12a2324 rlv=0xc129334c (address_exception_entry+0x50) rsp=0xc00faae4 rfp=0xc00fab54 r10=0xc317e000 r9=0xc1397280 r8=0xc317e008 r7=0xc128d4fc r6=0xc13e3c00 r5=0xffff1004 r4=0xc317e008 e1000_init_script_state_82541() at e1000_init_script_state_82541+0x20c scp=0xc1022a44 rlv=0xc10319d0 (e1000_init_nvm_params+0x24) rsp=0xc00fab58 rfp=0xc00fab64 r7=0xc0000002 r6=0x00000001 r5=0xc317e008 r4=0x00000000 e1000_init_nvm_params() at e1000_init_nvm_params+0xc scp=0xc10319b8 rlv=0xc1032914 (e1000_setup_init_funcs+0x150) rsp=0xc00fab68 rfp=0xc00fab80 e1000_setup_init_funcs() at e1000_setup_init_funcs+0xc scp=0xc10327d0 rlv=0xc101d8e0 (db_write_cmd+0xa85c) rsp=0xc00fab84 rfp=0xc00fac0c r6=0x0000443c r5=0xc1397280 r4=0x00004400 db_write_cmd() at db_write_cmd+0x9ee8 scp=0xc101cf6c rlv=0xc10f6d1c (device_attach+0x2c8) rsp=0xc00fac10 rfp=0xc00fac4c r10=0xc1397280 r9=0x00000009 r8=0xffffffff r7=0xc10f53c4 r6=0xc13972cc r5=0x80000000 r4=0xc1397300 device_attach() at device_attach+0xc scp=0xc10f6a60 rlv=0xc10f80e0 (device_probe_and_attach+0x34) rsp=0xc00fac50 rfp=0xc00fac60 r10=0xc1397300 r8=0xffffffff r7=0xc10f53c4 r6=0x00000000 r5=0x00000000 r4=0xc1397280 device_probe_and_attach() at device_probe_and_attach+0xc scp=0xc10f80b8 rlv=0xc10f8104 (bus_generic_attach+0x20) rsp=0xc00fac64 rfp=0xc00fac74 r4=0xc1397280 bus_generic_attach() at bus_generic_attach+0xc scp=0xc10f80f0 rlv=0xc105c318 (pci_add_children+0x240) rsp=0xc00fac78 rfp=0xc00fac98 r4=0xc1397300 pci_add_children() at pci_add_children+0x154 scp=0xc105c22c rlv=0xc10f6d1c (device_attach+0x2c8) rsp=0xc00fac9c rfp=0xc00facd8 r6=0xc139734c r5=0x80000000 r4=0xc13da400 device_attach() at device_attach+0xc scp=0xc10f6a60 rlv=0xc10f80e0 (device_probe_and_attach+0x34) rsp=0xc00facdc rfp=0xc00facec r10=0xc13da400 r8=0xffffffff r7=0x00000000 r6=0xc13da400 r5=0xc13b6318 r4=0xc1397300 device_probe_and_attach() at device_probe_and_attach+0xc scp=0xc10f80b8 rlv=0xc10f8104 (bus_generic_attach+0x20) rsp=0xc00facf0 rfp=0xc00fad00 r4=0xc1397300 bus_generic_attach() at bus_generic_attach+0xc scp=0xc10f80f0 rlv=0xc12a7824 (i80321_sdram_bounds+0x860) rsp=0xc00fad04 rfp=0xc00fad20 r4=0xc13b6360 i80321_sdram_bounds() at i80321_sdram_bounds+0x6f4 scp=0xc12a76b8 rlv=0xc10f6d1c (device_attach+0x2c8) rsp=0xc00fad24 rfp=0xc00fad60 r7=0xc10f53c4 r6=0xc13da44c r5=0x80000000 r4=0xc13da680 device_attach() at device_attach+0xc scp=0xc10f6a60 rlv=0xc10f80e0 (device_probe_and_attach+0x34) rsp=0xc00fad64 rfp=0xc00fad74 r10=0xc13da680 r8=0xc13da680 r7=0x40000004 r6=0xc13e3c00 r5=0x00000000 r4=0xc13da400 device_probe_and_attach() at device_probe_and_attach+0xc scp=0xc10f80b8 rlv=0xc10f8104 (bus_generic_attach+0x20) rsp=0xc00fad78 rfp=0xc00fad88 r4=0xc13da400 bus_generic_attach() at bus_generic_attach+0xc scp=0xc10f80f0 rlv=0xc12a8460 (iq80321_attach+0x370) rsp=0xc00fad8c rfp=0xc00fadb8 r4=0xc12de3c8 iq80321_attach() at iq80321_attach+0xc scp=0xc12a80fc rlv=0xc10f6d1c (device_attach+0x2c8) rsp=0xc00fadbc rfp=0xc00fadf8 r8=0xffffffff r7=0xc10f53c4 r6=0xc13da6cc r5=0x80000000 r4=0xc13da700 device_attach() at device_attach+0xc scp=0xc10f6a60 rlv=0xc10f80e0 (device_probe_and_attach+0x34) rsp=0xc00fadfc rfp=0xc00fae0c r10=0xc13da700 r8=0xffffffff r7=0xc10f53c4 r6=0xc13da74c r5=0x80000000 r4=0xc13da680 device_probe_and_attach() at device_probe_and_attach+0xc scp=0xc10f80b8 rlv=0xc10f8104 (bus_generic_attach+0x20) rsp=0xc00fae10 rfp=0xc00fae20 r4=0xc13da680 bus_generic_attach() at bus_generic_attach+0xc scp=0xc10f80f0 rlv=0xc1296270 (minidumpsys+0xaf4) rsp=0xc00fae24 rfp=0xc00fae34 r4=0xc13da700 minidumpsys() at minidumpsys+0xae4 scp=0xc1296260 rlv=0xc10f6d1c (device_attach+0x2c8) rsp=0xc00fae38 rfp=0xc00fae74 r4=0xc12d1318 device_attach() at device_attach+0xc scp=0xc10f6a60 rlv=0xc10f80e0 (device_probe_and_attach+0x34) rsp=0xc00fae78 rfp=0xc00fae88 r10=0x0000000a r8=0x00000000 r7=0xa10081a4 r6=0xc13dab80 r5=0xc1335374 r4=0xc13da700 device_probe_and_attach() at device_probe_and_attach+0xc scp=0xc10f80b8 rlv=0xc10f83c4 (bus_generic_new_pass+0xe4) rsp=0xc00fae8c rfp=0xc00faea4 r4=0xc13da700 bus_generic_new_pass() at bus_generic_new_pass+0xc scp=0xc10f82ec rlv=0xc10f43c0 (bus_set_pass+0x98) rsp=0xc00faea8 rfp=0xc00faec0 r6=0x7fffffff r5=0xc13dab80 r4=0xc13f1a80 bus_set_pass() at bus_set_pass+0xc scp=0xc10f4334 rlv=0xc10f4408 (root_bus_configure+0x14) rsp=0xc00faec4 rfp=0xc00faed0 r6=0x00000006 r5=0xa10081b0 r4=0xc12e0358 root_bus_configure() at root_bus_configure+0xc scp=0xc10f4400 rlv=0xc128c310 (xdr_sizeof+0x1d0) rsp=0xc00faed4 rfp=0xc00faee0 xdr_sizeof() at xdr_sizeof+0x1cc scp=0xc128c30c rlv=0xc1083620 (mi_startup+0xdc) rsp=0xc00faee4 rfp=0xc00faef4 mi_startup() at mi_startup+0xc scp=0xc1083550 rlv=0xc1008248 (btext+0x148) rsp=0xc00faef8 rfp=0x00000000 r4=0xa1008288 db> From andrew at fubar.geek.nz Sat Sep 26 10:24:58 2009 From: andrew at fubar.geek.nz (Andrew Turner) Date: Sat Sep 26 10:25:05 2009 Subject: FreeBSD on s3c2410 Message-ID: <20090926220754.31c97b1d@fubar.geek.nz> I've been working on porting FreeBSD to the s3c24x0 family of ARM CPU's from Samsung. I've got FreeBSD running to multi-user mode running on an s3c2410 cpu. The board I've been using is the LN2410SBC from [1]. The required files are in a tarball at [2]. You will need to extract it over a recent svn checkout and build the LN2410SBC ARN kernel. It expects to find a filesystem at da0s1. Andrew [1] http://www.littlechips.com/sbc_main.htm [2] http://fubar.geek.nz/files/freebsd/s3c2xx0/freebsd-s3c24x0-20090926.tar.gz From stas at FreeBSD.org Sat Sep 26 10:50:35 2009 From: stas at FreeBSD.org (Stanislav Sedov) Date: Sat Sep 26 10:50:44 2009 Subject: FreeBSD on s3c2410 In-Reply-To: <20090926220754.31c97b1d@fubar.geek.nz> References: <20090926220754.31c97b1d@fubar.geek.nz> Message-ID: <20090926145025.04aa3ad0.stas@FreeBSD.org> On Sat, 26 Sep 2009 22:07:54 +1200 Andrew Turner mentioned: > I've been working on porting FreeBSD to the s3c24x0 family of ARM CPU's > from Samsung. I've got FreeBSD running to multi-user mode running on an > s3c2410 cpu. The board I've been using is the LN2410SBC from [1]. > > The required files are in a tarball at [2]. You will need to extract it > over a recent svn checkout and build the LN2410SBC ARN kernel. It > expects to find a filesystem at da0s1. > Hello, Andrew! Thank you for working on this! I'll try your patches on my S3C2410 OpenMoko phone. BTW, do you think it makes sense to commit this work into HEAD already? It looks like it is in a very good shape now. What are the outstanding issues you're working on, if any? Best regards, -- Stanislav Sedov ST4096-RIPE -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 801 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-arm/attachments/20090926/0043cedc/attachment.pgp From andrew at fubar.geek.nz Sat Sep 26 23:04:27 2009 From: andrew at fubar.geek.nz (Andrew Turner) Date: Sat Sep 26 23:04:33 2009 Subject: FreeBSD on s3c2410 In-Reply-To: <20090926145025.04aa3ad0.stas@FreeBSD.org> References: <20090926220754.31c97b1d@fubar.geek.nz> <20090926145025.04aa3ad0.stas@FreeBSD.org> Message-ID: <20090927120417.2d9003b9@fubar.geek.nz> On Sat, 26 Sep 2009 14:50:25 +0400 Stanislav Sedov wrote: > On Sat, 26 Sep 2009 22:07:54 +1200 > Andrew Turner mentioned: > > > I've been working on porting FreeBSD to the s3c24x0 family of ARM > > CPU's from Samsung. I've got FreeBSD running to multi-user mode > > running on an s3c2410 cpu. The board I've been using is the > > LN2410SBC from [1]. > > > > The required files are in a tarball at [2]. You will need to > > extract it over a recent svn checkout and build the LN2410SBC ARN > > kernel. It expects to find a filesystem at da0s1. > > > > Hello, Andrew! > > Thank you for working on this! I'll try your patches on my S3C2410 > OpenMoko phone. The kernel should work with the Neo 1973 with the neo specific files from Perforce [1]. I've not managed to get the kernel to boot on Mine (only the Neo Freerunner which is s3c2442 based). The only way to get a filesystem on the OpenMoko will be to embed it within the kernel as a MFS image. > > BTW, do you think it makes sense to commit this work into HEAD > already? It looks like it is in a very good shape now. There are no major issues I'm aware of that would hold it back from HEAD. > What are the > outstanding issues you're working on, if any? I'm mostly working on drivers now and tracking down a bug with USB on s3c2440 (not on s3c2410 though) stopping it from booting. Andrew [1] //depot/projects/arm/src/sys/arm/s3c2xx0/*neo* From rpaulo at FreeBSD.org Sun Sep 27 20:04:29 2009 From: rpaulo at FreeBSD.org (Rui Paulo) Date: Sun Sep 27 20:05:05 2009 Subject: XScale PMC Message-ID: <339C618A-08A1-4BE1-BD1C-DBB82B1393D9@FreeBSD.org> Looking at the arm code, I noticed that we have the PMC stuff from NetBSD, but we don't use it. NetBSD has XScale PMC support but we haven't ported it yet. In any case, I plan to port the NetBSD code to our hwpmc, so we can remove NetBSD PMC defines. See http://people.freebsd.org/~rpaulo/xscalepmc.diff for what I'm trying to accomplish. -- Rui Paulo From tinderbox at freebsd.org Sun Sep 27 22:10:25 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Sun Sep 27 22:10:38 2009 Subject: [head tinderbox] failure on arm/arm Message-ID: <200909272210.n8RMAOnD042132@freebsd-current.sentex.ca> TB --- 2009-09-27 21:50:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-09-27 21:50:00 - starting HEAD tinderbox run for arm/arm TB --- 2009-09-27 21:50:00 - cleaning the object tree TB --- 2009-09-27 21:53:08 - cvsupping the source tree TB --- 2009-09-27 21:53:08 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/arm/arm/supfile TB --- 2009-09-27 21:55:49 - building world TB --- 2009-09-27 21:55:49 - MAKEOBJDIRPREFIX=/obj TB --- 2009-09-27 21:55:49 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-09-27 21:55:49 - TARGET=arm TB --- 2009-09-27 21:55:49 - TARGET_ARCH=arm TB --- 2009-09-27 21:55:49 - TZ=UTC TB --- 2009-09-27 21:55:49 - __MAKE_CONF=/dev/null TB --- 2009-09-27 21:55:49 - cd /src TB --- 2009-09-27 21:55:49 - /usr/bin/make -B buildworld >>> World build started on Sun Sep 27 21:55:52 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] sh /src/tools/install.sh -o root -g wheel -m 444 ca_ES.ISO8859-1.cat /obj/arm/src/tmp/usr/share/nls/ca_ES.ISO8859-1/libc.cat sh /src/tools/install.sh -o root -g wheel -m 444 de_DE.ISO8859-1.cat /obj/arm/src/tmp/usr/share/nls/de_DE.ISO8859-1/libc.cat sh /src/tools/install.sh -o root -g wheel -m 444 el_GR.ISO8859-7.cat /obj/arm/src/tmp/usr/share/nls/el_GR.ISO8859-7/libc.cat sh /src/tools/install.sh -o root -g wheel -m 444 es_ES.ISO8859-1.cat /obj/arm/src/tmp/usr/share/nls/es_ES.ISO8859-1/libc.cat sh /src/tools/install.sh -o root -g wheel -m 444 fi_FI.ISO8859-1.cat /obj/arm/src/tmp/usr/share/nls/fi_FI.ISO8859-1/libc.cat sh /src/tools/install.sh -o root -g wheel -m 444 fr_FR.ISO8859-1.cat /obj/arm/src/tmp/usr/share/nls/fr_FR.ISO8859-1/libc.cat sh /src/tools/install.sh -o root -g wheel -m 444 gl_ES.ISO8859-1.cat /obj/arm/src/tmp/usr/share/nls/gl_ES.ISO8859-1/libc.cat install: /obj/arm/src/tmp/usr/share/nls/gl_ES.ISO8859-1/libc.cat: No such file or directory *** Error code 71 Stop in /src/lib/libc. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-09-27 22:10:24 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-09-27 22:10:24 - ERROR: failed to build world TB --- 2009-09-27 22:10:24 - 459.07 user 103.38 system 1224.21 real http://tinderbox.des.no/tinderbox-head-HEAD-arm-arm.full From bugmaster at FreeBSD.org Mon Sep 28 11:06:50 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Sep 28 11:07:30 2009 Subject: Current problem reports assigned to freebsd-arm@FreeBSD.org Message-ID: <200909281106.n8SB6oFh063932@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o arm/134368 arm [patch] nslu2_led driver for the LEDs on the NSLU2 o arm/134338 arm [patch] Lock GPIO accesses on ixp425 o arm/134092 arm [patch] NSLU.hints contains wrong hints for on board n 3 problems total.