Octeon snapshots

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

Octeon snapshots

Daniel Ouellet
I saw a commit today on this platform. The last snapshot is almost a
month old.

10/18/15 2:19:00 AM.

Just wonder if the snapshot might get some love.

If not, totally fine, just wonder.

I may just go buy myself a bigger USB drive to try to compile it on my
Ubiquiti box and see how many days that might take. (;>

Reply | Threaded
Open this post in threaded view
|

Re: Octeon snapshots

jungle Boogie
On 13 November 2015 at 09:02, Daniel Ouellet <[hidden email]> wrote:
> I saw a commit today on this platform. The last snapshot is almost a
> month old.
>
> 10/18/15        2:19:00 AM.
>
> Just wonder if the snapshot might get some love.
>
> If not, totally fine, just wonder.


I would also gratefully appreciate an updated Octeon build. I'm happy
to have one post 5.8, but openbsd is a fast moving target and many
great changes have already occurred for -current.

--
-------
inum: 883510009027723
sip: [hidden email]
xmpp: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Octeon snapshots

Daniel Ouellet
In reply to this post by Daniel Ouellet
On 11/13/15 12:02 PM, Daniel Ouellet wrote:

> I saw a commit today on this platform. The last snapshot is almost a
> month old.
>
> 10/18/15 2:19:00 AM.
>
> Just wonder if the snapshot might get some love.
>
> If not, totally fine, just wonder.
>
> I may just go buy myself a bigger USB drive to try to compile it on my
> Ubiquiti box and see how many days that might take. (;>

To the kind sole.

Not sure who did the new current updated release, but many thanks to who
ever did it!

I very much appreciate it.

Daniel

Reply | Threaded
Open this post in threaded view
|

Re: Octeon snapshots

Peter Kay-5
On 5 December 2015 09:36:29 GMT+00:00, Daniel Ouellet <[hidden email]> wrote:
>On 11/13/15 12:02 PM, Daniel Ouellet wrote:
>To the kind sole.
>
>Not sure who did the new current updated release, but many thanks to
>who
>ever did it!
It cod not have come at a better time, it stopped me going 'oh roe is me, my Octeon does not work well'. I for one am r-eel-y grateful ;)

Reply | Threaded
Open this post in threaded view
|

Re: Octeon snapshots

Daniel Ouellet
it's a nice box. Not the most powerful, but for most case it works well
so far.

I did a few tcpbench on it to see.

About 85 to 90Mb routing before the CPU is 100% in use and then well,
that's as much as you get.

If you do both ways at the same time, then it goes down to ~42 to 45.

I also try with GRE tunnel to see. The 85 - 90 got down to ~62Mb and
then full duplex goes down to 28 to 32.

Full pf running, doing nat as well, stand smtp, not sending, dhcp.

Anyway, these tests are NOT very exhausting, but just an idea and it's
not bad for the $85 I pay for the new unit and the very low power this
needs to work.

I was curious and i will test more. I was trying to see if the
EdgeRouter Pro works, so far, no success yet, or may be never, but I am
just to tired to figure it out now.

I can say for sure that it does WAY, WAY more then a Cisco 2651XM
router! (:>

Daniel


On 12/5/15 8:20 AM, Peter Kay wrote:

>  
>
> On 5 December 2015 09:36:29 GMT+00:00, Daniel Ouellet <[hidden email]> wrote:
>> On 11/13/15 12:02 PM, Daniel Ouellet wrote:
>> To the kind sole.
>>
>> Not sure who did the new current updated release, but many thanks to
>> who
>> ever did it!
> It cod not have come at a better time, it stopped me going 'oh roe is me, my Octeon does not work well'. I for one am r-eel-y grateful ;)

Reply | Threaded
Open this post in threaded view
|

Re: Octeon snapshots

jungle Boogie
In reply to this post by Daniel Ouellet
On 5 December 2015 at 01:36, Daniel Ouellet <[hidden email]> wrote:
> I very much appreciate it.


I appreciate this too, but I can't complete the install. I tried an
update and now an install.

Like the first time, I'm following the network boot instructions here:
ftp://ftp.openbsd.org/pub/OpenBSD/snapshots/octeon/INSTALL.octeon

I can get the bsd.rd file fine from my server and boot into the installer.

This is the problem:
Available disks are: sd0.
Which disk is the root disk? ('?' for details) [sd0]
Disk: sd0       geometry: 1946/255/63 [31266816 Sectors]
Offset: 0       Signature: 0xAA55
            Starting         Ending         LBA Info:
 #: id      C   H   S -      C   H   S [       start:        size ]
-------------------------------------------------------------------------------
*0: 0C      0   1   2 -      2  11   9 [          64:       32768 ] Win95 FAT32L
 1: 00      0   0   0 -      0   0   0 [           0:           0 ] unused
 2: 00      0   0   0 -      0   0   0 [           0:           0 ] unused
 3: A6      2  11  10 -   1946  68  42 [       32832:    31233984 ] OpenBSD
Use (W)hole disk, use the (O)penBSD area or (E)dit the MBR? [OpenBSD]
The auto-allocated layout for sd0 is:
#                size           offset  fstype [fsize bsize  cpg]
  a:           464.9M            32832  4.2BSD   2048 16384    1 # /
  b:           465.1M           984896    swap
  c:         15267.0M                0  unused
  d:           735.8M          1937472  4.2BSD   2048 16384    1 # /tmp
  e:          1080.7M          3444416  4.2BSD   2048 16384    1 # /var
  f:          1284.9M          5657696  4.2BSD   2048 16384    1 # /usr
  g:           742.9M          8289120  4.2BSD   2048 16384    1 # /usr/X11R6
  h:          2817.8M          9810624  4.2BSD   2048 16384    1 # /usr/local
  i:            16.0M               64   MSDOS
  j:          1178.0M         15581408  4.2BSD   2048 16384    1 # /usr/src
  k:          1607.9M         17993856  4.2BSD   2048 16384    1 # /usr/obj
  l:          4872.9M         21286848  4.2BSD   2048 16384    1 # /home
Use (A)uto layout, (E)dit auto layout, or create (C)ustom layout? [a]
disklabel(27018): syscall 5 "cpath"
Abort trap


What's syscall 5 cpath and why does it cause an abort trap?

I've tried with two different thumb drives with the same abort trap message.

Thanks!






--
-------
inum: 883510009027723
sip: [hidden email]
xmpp: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Octeon snapshots

Daniel Ouellet
On 12/5/15 8:01 PM, jungle Boogie wrote:

> On 5 December 2015 at 01:36, Daniel Ouellet <[hidden email]> wrote:
>> I very much appreciate it.
>
>
> I appreciate this too, but I can't complete the install. I tried an
> update and now an install.
>
> Like the first time, I'm following the network boot instructions here:
> ftp://ftp.openbsd.org/pub/OpenBSD/snapshots/octeon/INSTALL.octeon
>
> I can get the bsd.rd file fine from my server and boot into the installer.
>
> This is the problem:
> Available disks are: sd0.
> Which disk is the root disk? ('?' for details) [sd0]
> Disk: sd0       geometry: 1946/255/63 [31266816 Sectors]
> Offset: 0       Signature: 0xAA55
>             Starting         Ending         LBA Info:
>  #: id      C   H   S -      C   H   S [       start:        size ]
> -------------------------------------------------------------------------------
> *0: 0C      0   1   2 -      2  11   9 [          64:       32768 ] Win95 FAT32L
>  1: 00      0   0   0 -      0   0   0 [           0:           0 ] unused
>  2: 00      0   0   0 -      0   0   0 [           0:           0 ] unused
>  3: A6      2  11  10 -   1946  68  42 [       32832:    31233984 ] OpenBSD
> Use (W)hole disk, use the (O)penBSD area or (E)dit the MBR? [OpenBSD]
> The auto-allocated layout for sd0 is:
> #                size           offset  fstype [fsize bsize  cpg]
>   a:           464.9M            32832  4.2BSD   2048 16384    1 # /
>   b:           465.1M           984896    swap
>   c:         15267.0M                0  unused
>   d:           735.8M          1937472  4.2BSD   2048 16384    1 # /tmp
>   e:          1080.7M          3444416  4.2BSD   2048 16384    1 # /var
>   f:          1284.9M          5657696  4.2BSD   2048 16384    1 # /usr
>   g:           742.9M          8289120  4.2BSD   2048 16384    1 # /usr/X11R6
>   h:          2817.8M          9810624  4.2BSD   2048 16384    1 # /usr/local
>   i:            16.0M               64   MSDOS
>   j:          1178.0M         15581408  4.2BSD   2048 16384    1 # /usr/src
>   k:          1607.9M         17993856  4.2BSD   2048 16384    1 # /usr/obj
>   l:          4872.9M         21286848  4.2BSD   2048 16384    1 # /home
> Use (A)uto layout, (E)dit auto layout, or create (C)ustom layout? [a]
> disklabel(27018): syscall 5 "cpath"
> Abort trap
>
>
> What's syscall 5 cpath and why does it cause an abort trap?
>
> I've tried with two different thumb drives with the same abort trap message.
>
> Thanks!

Well I can't say what you did or didn't do.

Below there is WAY more information then needed.

But I just did it again all the way and here are all the steps by steps
I did and here is what my layout is before I started:

# fdisk sd0
Disk: sd0       geometry: 1946/255/63 [31266816 Sectors]
Offset: 0       Signature: 0xAA55
            Starting         Ending         LBA Info:
 #: id      C   H   S -      C   H   S [       start:        size ]
-------------------------------------------------------------------------------
*0: 0C      0   1   2 -      2  11   9 [          64:       32768 ]
Win95 FAT32L
 1: 00      0   0   0 -      0   0   0 [           0:           0 ] unused
 2: 00      0   0   0 -      0   0   0 [           0:           0 ] unused
 3: A6      2  11  10 -   1946  68  42 [       32832:    31233984 ] OpenBSD

# disklabel sd0
# /dev/rsd0c:
type: SCSI
disk: SCSI disk
label: Cruzer Fit
duid: 55072c2137c3a4e7
flags:
bytes/sector: 512
sectors/track: 63
tracks/cylinder: 255
sectors/cylinder: 16065
cylinders: 1946
total sectors: 31266816
boundstart: 32832
boundend: 31266816
drivedata: 0

16 partitions:
#                size           offset  fstype [fsize bsize  cpg]
  a:          1059584            32832  4.2BSD   2048 16384    1 # /
  b:          1044229          1092416    swap                   # none
  c:         31266816                0  unused
  d:          2104480          2136672  4.2BSD   2048 16384    1 # /tmp
  e:         10474368          4241152  4.2BSD   2048 16384    1 # /var
  f:          2088448         14715520  4.2BSD   2048 16384    1 # /var/log
  g:         10474400         16803968  4.2BSD   2048 16384    1 # /usr
  h:          3988448         27278368  4.2BSD   2048 16384    1 # /home
  i:            32768               64   MSDOS

And here are the step by step:

# mount_msdos /dev/sd0i /mnt
# cd /mnt
# ls -al
total 22664
drwxr-xr-x   1 root  wheel    16384 Dec 31  1979 .
drwxr-xr-x  13 root  wheel      512 Dec  5 00:11 ..
-rwxr-xr-x   1 root  wheel  4020931 Nov 14 17:29 bsd
-rwxr-xr-x   1 root  wheel  7562057 Nov 14 17:29 bsd.rd

# ftp ftp://ftp.openbsd.org/pub/OpenBSD/snapshots/octeon/bsd.rd
Connected to openbsd.sunsite.ualberta.ca.
220 openbsd.srv.ualberta.ca FTP server ready.
<snip>...
Retrieving pub/OpenBSD/snapshots/octeon/bsd*.*
local: bsd.mp remote: bsd.mp
150 Opening BINARY mode data connection for 'bsd.mp' (4057768 bytes).
100% |**************************************************|  3962 KB    00:06
226 Transfer complete.
4057768 bytes received in 6.87 seconds (576.76 KB/s)
local: bsd.rd remote: bsd.rd
150 Opening BINARY mode data connection for 'bsd.rd' (7568951 bytes).
100% |**************************************************|  7391 KB    00:12
226 Transfer complete.
7568951 bytes received in 12.04 seconds (613.83 KB/s)
221 Goodbye.

# ls -al
total 30604
drwxr-xr-x   1 root  wheel    16384 Dec 31  1979 .
drwxr-xr-x  13 root  wheel      512 Dec  5 00:11 ..
-rwxr-xr-x   1 root  wheel  4020931 Nov 14 17:29 bsd
-rwxr-xr-x   1 root  wheel  4057768 Nov 27 03:42 bsd.mp
-rwxr-xr-x   1 root  wheel  7568951 Nov 27 03:42 bsd.rd

# cd /
# umount /mnt
# reboot

In my U-Boot I have for testing reason setup the variable

bootdelay=10 so that I have time to press enter to stop the boot process
and make changes if I need to, you can set it up to 5, or 3 if you like.
You will see the count down anyway on the console.

You can change it like this:

Octeon ubnt_e100# setenv bootdelay '5'
Octeon ubnt_e100# saveenv

so in the future you are good to go and see the count down when to press
enter to stop the boot process.

Anyway, here when it start to boot you need to tell it to load the
bsd.rd and this is how I do it. I just don't save it in the env
variables, just preset what I need to get it going one time, so at the
next reset it is what ot was before I did this install.

Octeon ubnt_e100# setenv bootcmd 'fatload usb 0 $loadaddr bsd.rd;
bootoctlinux rootdev=/dev/sd0'

Octeon ubnt_e100# run bootcmd

And then install as usual keeping my previous working partition name and
all, just wiping out everything and do it fresh as I have notes for my
install and did copy the configurations files I needed to keep. I like
fresh clean install all the time. But upgrade works to and is faster too.

And normal install:

At your question that you are not sure, I just press enter, or that
would be the default to be OpenBSD the A6 id partition.

I didn't copy the full stuff here as it is boring and the same seen
multiple times already.

Formatting the partitions is kind of slow, on the USB I have anyway.

Then I install the files from a decent mirrors and reboot.

and here is the end results:

# dmesg
Copyright (c) 1982, 1986, 1989, 1991, 1993
        The Regents of the University of California.  All rights reserved.
Copyright (c) 1995-2015 OpenBSD. All rights reserved.
http://www.OpenBSD.org

OpenBSD 5.8-current (GENERIC) #1: Thu Nov 26 15:01:01 CET 2015
    [hidden email]:/usr/src/sys/arch/octeon/compile/GENERIC
real mem = 247463936 (236MB)
avail mem = 245170176 (233MB)
warning: no entropy supplied by boot loader
mainbus0 at root
cpu0 at mainbus0: Cavium OCTEON CPU rev 0.1 500 MHz, Software FP emulation
cpu0: cache L1-I 32KB 4 way D 8KB 64 way, L2 128KB 8 way
clock0 at mainbus0: int 5
iobus0 at mainbus0
dwctwo0 at iobus0 base 0x1180068000000 irq 56
usb0 at dwctwo0: USB revision 2.0
uhub0 at usb0 "Octeon DWC2 root hub" rev 2.00/1.00 addr 1
octrng0 at iobus0 base 0x1400000000000 irq 0
cn30xxgmx0 at iobus0 base 0x1180008000000 irq 48
cnmac0 at cn30xxgmx0: RGMII, address 44:d9:e7:40:ac:f8
atphy0 at cnmac0 phy 7: F1 10/100/1000 PHY, rev. 2
cnmac1 at cn30xxgmx0: RGMII, address 44:d9:e7:40:ac:f9
atphy1 at cnmac1 phy 6: F1 10/100/1000 PHY, rev. 2
cnmac2 at cn30xxgmx0: RGMII, address 44:d9:e7:40:ac:fa
atphy2 at cnmac2 phy 5: F1 10/100/1000 PHY, rev. 2
uartbus0 at mainbus0
com0 at uartbus0 base 0x1180000000800 irq 34: ns16550, no working fifo
com0: console
com1 at uartbus0 base 0x1180000000c00 irq 35: ns16550, no working fifo
/dev/ksyms: Symbol table not valid.
umass0 at uhub0 port 1 configuration 1 interface 0 "SanDisk Cruzer Fit"
rev 2.00/1.27 addr 2
umass0: using SCSI over Bulk-Only
scsibus0 at umass0: 2 targets, initiator 0
sd0 at scsibus0 targ 1 lun 0: <SanDisk, Cruzer Fit, 1.27> SCSI4 0/direct
removable serial.07815571360927117103
sd0: 15267MB, 512 bytes/sector, 31266816 sectors
vscsi0 at root
scsibus1 at vscsi0: 256 targets
softraid0 at root
scsibus2 at softraid0: 256 targets
boot device: sd0
root on sd0a (55072c2137c3a4e7.a) swap on sd0b dump on sd0b
WARNING: No TOD clock, believing file system.
WARNING: CHECK AND RESET THE DATE!

So, I see no problem and just did it again to s=be 100% sure even if
that was good before too and try to give you way more details then
needed to help you.

May be somehow you didn't boot the bsd.rd file you think the system did?
That's why I put these details steps in here.

I hope it help you some anyway.

Daniel

Reply | Threaded
Open this post in threaded view
|

Re: Octeon snapshots

413x
Hi Everybody,

Has anyone successfully installed on a D-Link DSR-500N (HW A1)?

I have tried again with the last snapshot, and I am still stuck [1].

Thanks,

[1]: https://www.mail-archive.com/tech%40openbsd.org/msg26048.html

On 12/06/15 05:54, Daniel Ouellet wrote:

> On 12/5/15 8:01 PM, jungle Boogie wrote:
>> On 5 December 2015 at 01:36, Daniel Ouellet <[hidden email]> wrote:
>>> I very much appreciate it.
>>
>>
>> I appreciate this too, but I can't complete the install. I tried an
>> update and now an install.
>>
>> Like the first time, I'm following the network boot instructions here:
>> ftp://ftp.openbsd.org/pub/OpenBSD/snapshots/octeon/INSTALL.octeon
>>
>> I can get the bsd.rd file fine from my server and boot into the installer.
>>
>> This is the problem:
>> Available disks are: sd0.
>> Which disk is the root disk? ('?' for details) [sd0]
>> Disk: sd0       geometry: 1946/255/63 [31266816 Sectors]
>> Offset: 0       Signature: 0xAA55
>>              Starting         Ending         LBA Info:
>>   #: id      C   H   S -      C   H   S [       start:        size ]
>> -------------------------------------------------------------------------------
>> *0: 0C      0   1   2 -      2  11   9 [          64:       32768 ] Win95 FAT32L
>>   1: 00      0   0   0 -      0   0   0 [           0:           0 ] unused
>>   2: 00      0   0   0 -      0   0   0 [           0:           0 ] unused
>>   3: A6      2  11  10 -   1946  68  42 [       32832:    31233984 ] OpenBSD
>> Use (W)hole disk, use the (O)penBSD area or (E)dit the MBR? [OpenBSD]
>> The auto-allocated layout for sd0 is:
>> #                size           offset  fstype [fsize bsize  cpg]
>>    a:           464.9M            32832  4.2BSD   2048 16384    1 # /
>>    b:           465.1M           984896    swap
>>    c:         15267.0M                0  unused
>>    d:           735.8M          1937472  4.2BSD   2048 16384    1 # /tmp
>>    e:          1080.7M          3444416  4.2BSD   2048 16384    1 # /var
>>    f:          1284.9M          5657696  4.2BSD   2048 16384    1 # /usr
>>    g:           742.9M          8289120  4.2BSD   2048 16384    1 # /usr/X11R6
>>    h:          2817.8M          9810624  4.2BSD   2048 16384    1 # /usr/local
>>    i:            16.0M               64   MSDOS
>>    j:          1178.0M         15581408  4.2BSD   2048 16384    1 # /usr/src
>>    k:          1607.9M         17993856  4.2BSD   2048 16384    1 # /usr/obj
>>    l:          4872.9M         21286848  4.2BSD   2048 16384    1 # /home
>> Use (A)uto layout, (E)dit auto layout, or create (C)ustom layout? [a]
>> disklabel(27018): syscall 5 "cpath"
>> Abort trap
>>
>>
>> What's syscall 5 cpath and why does it cause an abort trap?
>>
>> I've tried with two different thumb drives with the same abort trap message.
>>
>> Thanks!
>
> Well I can't say what you did or didn't do.
>
> Below there is WAY more information then needed.
>
> But I just did it again all the way and here are all the steps by steps
> I did and here is what my layout is before I started:
>
> # fdisk sd0
> Disk: sd0       geometry: 1946/255/63 [31266816 Sectors]
> Offset: 0       Signature: 0xAA55
>              Starting         Ending         LBA Info:
>   #: id      C   H   S -      C   H   S [       start:        size ]
> -------------------------------------------------------------------------------
> *0: 0C      0   1   2 -      2  11   9 [          64:       32768 ]
> Win95 FAT32L
>   1: 00      0   0   0 -      0   0   0 [           0:           0 ] unused
>   2: 00      0   0   0 -      0   0   0 [           0:           0 ] unused
>   3: A6      2  11  10 -   1946  68  42 [       32832:    31233984 ] OpenBSD
>
> # disklabel sd0
> # /dev/rsd0c:
> type: SCSI
> disk: SCSI disk
> label: Cruzer Fit
> duid: 55072c2137c3a4e7
> flags:
> bytes/sector: 512
> sectors/track: 63
> tracks/cylinder: 255
> sectors/cylinder: 16065
> cylinders: 1946
> total sectors: 31266816
> boundstart: 32832
> boundend: 31266816
> drivedata: 0
>
> 16 partitions:
> #                size           offset  fstype [fsize bsize  cpg]
>    a:          1059584            32832  4.2BSD   2048 16384    1 # /
>    b:          1044229          1092416    swap                   # none
>    c:         31266816                0  unused
>    d:          2104480          2136672  4.2BSD   2048 16384    1 # /tmp
>    e:         10474368          4241152  4.2BSD   2048 16384    1 # /var
>    f:          2088448         14715520  4.2BSD   2048 16384    1 # /var/log
>    g:         10474400         16803968  4.2BSD   2048 16384    1 # /usr
>    h:          3988448         27278368  4.2BSD   2048 16384    1 # /home
>    i:            32768               64   MSDOS
>
> And here are the step by step:
>
> # mount_msdos /dev/sd0i /mnt
> # cd /mnt
> # ls -al
> total 22664
> drwxr-xr-x   1 root  wheel    16384 Dec 31  1979 .
> drwxr-xr-x  13 root  wheel      512 Dec  5 00:11 ..
> -rwxr-xr-x   1 root  wheel  4020931 Nov 14 17:29 bsd
> -rwxr-xr-x   1 root  wheel  7562057 Nov 14 17:29 bsd.rd
>
> # ftp ftp://ftp.openbsd.org/pub/OpenBSD/snapshots/octeon/bsd.rd
> Connected to openbsd.sunsite.ualberta.ca.
> 220 openbsd.srv.ualberta.ca FTP server ready.
> <snip>...
> Retrieving pub/OpenBSD/snapshots/octeon/bsd*.*
> local: bsd.mp remote: bsd.mp
> 150 Opening BINARY mode data connection for 'bsd.mp' (4057768 bytes).
> 100% |**************************************************|  3962 KB    00:06
> 226 Transfer complete.
> 4057768 bytes received in 6.87 seconds (576.76 KB/s)
> local: bsd.rd remote: bsd.rd
> 150 Opening BINARY mode data connection for 'bsd.rd' (7568951 bytes).
> 100% |**************************************************|  7391 KB    00:12
> 226 Transfer complete.
> 7568951 bytes received in 12.04 seconds (613.83 KB/s)
> 221 Goodbye.
>
> # ls -al
> total 30604
> drwxr-xr-x   1 root  wheel    16384 Dec 31  1979 .
> drwxr-xr-x  13 root  wheel      512 Dec  5 00:11 ..
> -rwxr-xr-x   1 root  wheel  4020931 Nov 14 17:29 bsd
> -rwxr-xr-x   1 root  wheel  4057768 Nov 27 03:42 bsd.mp
> -rwxr-xr-x   1 root  wheel  7568951 Nov 27 03:42 bsd.rd
>
> # cd /
> # umount /mnt
> # reboot
>
> In my U-Boot I have for testing reason setup the variable
>
> bootdelay=10 so that I have time to press enter to stop the boot process
> and make changes if I need to, you can set it up to 5, or 3 if you like.
> You will see the count down anyway on the console.
>
> You can change it like this:
>
> Octeon ubnt_e100# setenv bootdelay '5'
> Octeon ubnt_e100# saveenv
>
> so in the future you are good to go and see the count down when to press
> enter to stop the boot process.
>
> Anyway, here when it start to boot you need to tell it to load the
> bsd.rd and this is how I do it. I just don't save it in the env
> variables, just preset what I need to get it going one time, so at the
> next reset it is what ot was before I did this install.
>
> Octeon ubnt_e100# setenv bootcmd 'fatload usb 0 $loadaddr bsd.rd;
> bootoctlinux rootdev=/dev/sd0'
>
> Octeon ubnt_e100# run bootcmd
>
> And then install as usual keeping my previous working partition name and
> all, just wiping out everything and do it fresh as I have notes for my
> install and did copy the configurations files I needed to keep. I like
> fresh clean install all the time. But upgrade works to and is faster too.
>
> And normal install:
>
> At your question that you are not sure, I just press enter, or that
> would be the default to be OpenBSD the A6 id partition.
>
> I didn't copy the full stuff here as it is boring and the same seen
> multiple times already.
>
> Formatting the partitions is kind of slow, on the USB I have anyway.
>
> Then I install the files from a decent mirrors and reboot.
>
> and here is the end results:
>
> # dmesg
> Copyright (c) 1982, 1986, 1989, 1991, 1993
>          The Regents of the University of California.  All rights reserved.
> Copyright (c) 1995-2015 OpenBSD. All rights reserved.
> http://www.OpenBSD.org
>
> OpenBSD 5.8-current (GENERIC) #1: Thu Nov 26 15:01:01 CET 2015
>      [hidden email]:/usr/src/sys/arch/octeon/compile/GENERIC
> real mem = 247463936 (236MB)
> avail mem = 245170176 (233MB)
> warning: no entropy supplied by boot loader
> mainbus0 at root
> cpu0 at mainbus0: Cavium OCTEON CPU rev 0.1 500 MHz, Software FP emulation
> cpu0: cache L1-I 32KB 4 way D 8KB 64 way, L2 128KB 8 way
> clock0 at mainbus0: int 5
> iobus0 at mainbus0
> dwctwo0 at iobus0 base 0x1180068000000 irq 56
> usb0 at dwctwo0: USB revision 2.0
> uhub0 at usb0 "Octeon DWC2 root hub" rev 2.00/1.00 addr 1
> octrng0 at iobus0 base 0x1400000000000 irq 0
> cn30xxgmx0 at iobus0 base 0x1180008000000 irq 48
> cnmac0 at cn30xxgmx0: RGMII, address 44:d9:e7:40:ac:f8
> atphy0 at cnmac0 phy 7: F1 10/100/1000 PHY, rev. 2
> cnmac1 at cn30xxgmx0: RGMII, address 44:d9:e7:40:ac:f9
> atphy1 at cnmac1 phy 6: F1 10/100/1000 PHY, rev. 2
> cnmac2 at cn30xxgmx0: RGMII, address 44:d9:e7:40:ac:fa
> atphy2 at cnmac2 phy 5: F1 10/100/1000 PHY, rev. 2
> uartbus0 at mainbus0
> com0 at uartbus0 base 0x1180000000800 irq 34: ns16550, no working fifo
> com0: console
> com1 at uartbus0 base 0x1180000000c00 irq 35: ns16550, no working fifo
> /dev/ksyms: Symbol table not valid.
> umass0 at uhub0 port 1 configuration 1 interface 0 "SanDisk Cruzer Fit"
> rev 2.00/1.27 addr 2
> umass0: using SCSI over Bulk-Only
> scsibus0 at umass0: 2 targets, initiator 0
> sd0 at scsibus0 targ 1 lun 0: <SanDisk, Cruzer Fit, 1.27> SCSI4 0/direct
> removable serial.07815571360927117103
> sd0: 15267MB, 512 bytes/sector, 31266816 sectors
> vscsi0 at root
> scsibus1 at vscsi0: 256 targets
> softraid0 at root
> scsibus2 at softraid0: 256 targets
> boot device: sd0
> root on sd0a (55072c2137c3a4e7.a) swap on sd0b dump on sd0b
> WARNING: No TOD clock, believing file system.
> WARNING: CHECK AND RESET THE DATE!
>
> So, I see no problem and just did it again to s=be 100% sure even if
> that was good before too and try to give you way more details then
> needed to help you.
>
> May be somehow you didn't boot the bsd.rd file you think the system did?
> That's why I put these details steps in here.
>
> I hope it help you some anyway.
>
> Daniel
>

--
Alexis de BRUYN

Reply | Threaded
Open this post in threaded view
|

Re: Octeon snapshots

Paul Irofti-4
> [1]: https://www.mail-archive.com/tech%40openbsd.org/msg26048.html

You have to use the octeon native objcopy by building the cross
compiler:

  # cd /usr/src
  # make -f Makefile.cross TARGET=octeon cross-gcc

And then use the objcopy from

  /usr/cross/octeon/usr/mips64-unknown-openbsd5.8/bin/objcopy

Reply | Threaded
Open this post in threaded view
|

Re: Octeon snapshots

413x
On 12/09/15 12:58, Paul Irofti wrote:

>> [1]: https://www.mail-archive.com/tech%40openbsd.org/msg26048.html
>
> You have to use the octeon native objcopy by building the cross
> compiler:
>
>    # cd /usr/src
>    # make -f Makefile.cross TARGET=octeon cross-gcc
>
> And then use the objcopy from
>
>    /usr/cross/octeon/usr/mips64-unknown-openbsd5.8/bin/objcopy
>

Thank you Paul. bsd.rd is now booting.

--
Alexis de BRUYN