next »

[wolrah]

My Routerstation Pro + Enclosure kit just arrived earlier this morning.  Obviously I'm excited to get this thing working, unfortunately I have run in to a problem.

I'm stuck at flashing the kernel.  Here's what I get:

Code:

RedBoot> load kernel
Using default protocol (TFTP)
Entry point: 0x80095fc0, address range: 0x80050000-0x805a6df4
RedBoot> fis create pfsense0
... Erase from 0xbf030000-0xbf586df4: ......................................................................................
... Program from 0x80050000-0x805a6df4 at 0xbf030000: ......................................................................................
... Erase from 0xbfff0000-0xc0000000: .
... Program from 0x87ff0000-0x88000000 at 0xbfff0000: .
RedBoot> fis create pfsense1
... Erase from 0xbf580000-0xbfaddbe8: ......................................................................................
... Program from 0x80050000-0x805a6df4 at 0xbf586df4: V
Can't program region at 0xbf586df4: Unknown error
RedBoot>

Now during the TFTP transfer of the kernel, it gets to 93% and then stops according to my TFTP server (TFTPD32 running on Windows 7).  Since we fail in the second part of the write, I think this might be related.  Unfortunately ATFTPD on my local server has decided to not cooperate with me, so I don't have any other TFTP servers available at the moment.

Since this machine is using RedBoot I do not really expect to be able to brick it, so I tried booting anyways.  Obviously that did not work, and failed like so:

Code:

AR8316 PHY found on MAC0
AR8316 PHY found on MAC1
Ethernet eth0: MAC address 00:15:6d:c1:3d:8c
IP: 192.168.1.20/255.255.255.0, Gateway: 0.0.0.0
Default server: 0.0.0.0

RedBoot(tm) bootstrap and debug environment [ROMRAM]
Ubiquiti Networks certified release, version 0.9.00318M.0905121200 - built 12:01:38, May 12 2009

Copyright (C) 2000, 2001, 2002, 2003, 2004 Red Hat, Inc.

Board: Ubiquiti RouterStation PRO
 Arch: ar7100pro
  RAM: 0x80000000-0x88000000, [0x8003bf00-0x87fe1000] available
Flash: 0xbf000000-0xc0000000, in 256 blocks of 0x00010000 bytes each
== Executing boot script in 1.000 seconds - enter ^C to abort
RedBoot> fis load pfsense0
** Warning - checksum failure.  stored: 0xfae7b839, computed: 0xf6191fff
RedBoot> exec -c "vfs.root.mountfrom=ufs:/dev/da0s1"
Can't execute Linux - invalid entry address
RedBoot>

Not sure if that part is of any use to anyone, but I figured I'd throw it out there.

I will continue trying to find another TFTP server, but if anyone has successfully installed the 11/23/2009 RSPro build and can see something I'm doing wrong please let me know.

[wolrah]

I've been screwing around and managed to get it to actually boot the kernel by simply skipping the pfsense1 part.  I don't know what the implications of skipping that are, but it does begin to load.

I've put the entire boot as seen from the serial port on the pastebin, but what I think is important is below:

Code:

Trying to mount root from ufs:/dev/da0s1. Press CTRL+C to abort.
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.

ugen0.2: <Generic> at usbus0
umass0: <Generic USB Storage, class 0/0, rev 2.00/94.51, addr 2> on usbus0
umass0:  SCSI over Bulk-Only; quirks = 0x0000
Trying to mount root from ufs:/dev/da0s1. Press CTRL+C to abort.
umass0:0:0:-1: Attached to scbus0
(probe0:umass-sim0:0:0:0): Down reving Protocol Version from 2 to 0?
(probe0:umass-sim0:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0
(probe0:umass-sim0:0:0:0): CAM Status: SCSI Status Error
(probe0:umass-sim0:0:0:0): SCSI Status: Check Condition
(probe0:umass-sim0:0:0:0): UNIT ATTENTION asc:28,0
(probe0:umass-sim0:0:0:0): Not ready to ready change, medium may have changed
(probe0:umass-sim0:0:0:0): (probe0:umass-sim0:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0
(probe0:umass-sim0:0:0:0): UNIT ATTENTION asc:28,0
(probe0:umass-sim0:0:0:0): Not ready to ready change, medium may have changed
Retrying Command (per Sense Data)
(probe0:umass-sim0:0:0:0): Retrying Command
GEOM: new disk da0
da0 at umass-sim0 bus 0 target 0 lun 0
da0: <Generic STORAGE DEVICE 9451> Removable Direct Access SCSI-0 device
da0: 40.000MB/s transfers
da0: 1920MB (3932160 512 byte sectors: 255H 63S/T 244C)
Trying to mount root from ufs:/dev/da0s1. Press CTRL+C to abort.
warning: no time-of-day clock registered, system time will not be set accurately
start_init: trying /sbin/init
t_delta 16.01c53f09b0619840 too long
t_delta 16.01c6837d95952c20 too long
t_delta 16.01c61493140b26e0 too long
t_delta 16.01c61374bf44b460 too long
t_delta 16.01c60289fd0b3090 too long
t_delta 16.01c6428684395c40 too long

All it does at this point is sit there spitting out that t_delta message every minute or so forever.  I'm very unfamiliar with FreeBSD's boot messages (more of a Linux/Mac guy), but it looks like it isn't mounting the SD card properly and is getting stuck there.

I copied the image to the SD card using the command dd if=nanobsd.img of=/dev/disk1 bs=16k on my Macbook Pro running 10.6 through a Vizo Mirrorbox "32-in-1" USB adapter.  The SD card is a 2GB Kingston MicroSD which I have tested in my cell phone and Nintendo DS, sitting in a Kingston MicroSD to full-size adapter.

[wallabybob]

Are you sure the Router Station Pro has a x86 CPU? I suspect it has an Atheros (MIPS?) AR7161 CPU which is incompatible with the pfSense kernel and much of the pfSense software. (pfSense is built for x86 CPUs.)

But I note on http://www.netgate.com/product_info.php?cPath=60_83&products_id=749 NEW! If you like to bleed, we're very happy to announce pfSense ALPHA for the RouterStationPRO! We are not able to load it for you at this time, so you will need to follow the directions on the pfSense wiki if you want to test it out.

I haven't gone looking for the referenced Wiki instructions, but at the risk of asking the obvious, have you downloaded the appropriate kit rather than the "standard" x86 kit?

I guess http://devwiki.pfsense.org/RouterStationPRO is the wiki page Netgate is referring to.

I don't know the appropriate forum for reporting problems with the port for the RouterStation Pro, so if you report problems in the regular forums it would probably be helpful to the readers if you prefaced your report with a remark that you are using a special kit for a new CPU architecture.

[jimp]

The RSPro is newly "supported" in that it has been made to work by the developers, and some users have managed to get it running based on their work, but I'm not sure very many people have actually tried it yet.

The http://devwiki.pfsense.org/RouterStationPRO link is the proper set of instructions to follow, and has a link to the images you need to download.

[wolrah]

That is the guide I have followed.  I apologize for not noting the special platform, there has been a lot of talk about this board in the WRT-type router community and I had seen sullrich's tweets about the build for it, so I assumed it was semi-known.

I'm going to reflash the stock firmware tomorrow and run a few tests to determine if the flash chip might be bad.

[sullrich]

Try starting over but only erase and install one kernel.   Upgrading support is not complete so the external kernel + steps is unnecessary at the moment.

[wolrah]

I still have not managed to flash back to stock, as finding the stock image is proving rather tricky, but I did do an erase and reload with no luck.

I started fresh from the top of the guide, again skipping the "fis create pfsense1" part since that errors out and prevents it from even booting the kernel.  This time I also took the MicroSD adapter and USB SD reader out of the equation by using an 8GB SDHC card a friend loaned me and writing to it with my Dell Mini 9 from Linux.

Unfortunately the results were the same.  Pastebin here for the boot messages.  The problem seems to be related to mounting the root partition, but I don't understand why since it clearly sees the SD card just fine and both times the write has gone well.

[wallabybob]

I think your root partition has mounted fine and that you have run into some kernel problem related to the clock.

Clearly the kernel stutters in recognising your mass storage, but then it is recognised:

GEOM: new disk da0
da0 at umass-sim0 bus 0 target 0 lun 0
da0: <Generic STORAGE DEVICE 9451> Removable Direct Access SCSI-0 device
da0: 40.000MB/s transfers
da0: 7580MB (15523840 512 byte sectors: 255H 63S/T 966C)

If there was a problem mounting the root partition I would expect it to be reported after:

Trying to mount root from ufs:/dev/da0s1. Press CTRL+C to abort.

I think your problem is related to

t_delta 16.01c52313690069c0 too long

which may also be related to

warning: no time-of-day clock registered, system time will not be set accurately

I don't have the FreeBSD sources for this particular platform (nor do I know where to get them) so I can't investigate further, but my guess is that its something related to interval timer initialisation and it might go away if you can successfully boot some other OS before booting FreeBSD/pfSense.

[wolrah]

Sorry for the long delay, I got frustrated with this device and put it away for a few weeks.

Unfortunately it is not the clock.  I loaded the latest OpenWRT trunk build on it and set the clock, installed packages, and generally tested the device.  As far as I can tell the hardware is fine.  I also have a new 2GB SD card to remove any possible concerns over the microSD adapter or the SDHC card I had tried with previously.  The machine has not been unplugged since the OpenWRT install was running, I just rebooted it and ^C'd in to redboot to start the pfsense install, so the hardware clock has no reason to have lost its setting.

I still can't flash pfsense1 and it still pukes when trying to mount the root, then stalling at the same t_delta messages as always.