Re: near future (Rpi3)

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

Re: near future (Rpi3)

Tuyosi Takesima
Hi !

there is a very good reading at
http://www.undeadly.org/cgi?action=article&sid=20170409123528&mode=flat%20%EF%BF%BC
.

i only follow it .


sd card A USB card reader :Rpi3:micro sd card B in it's slot

at this state , i install openbsd into sd0 ( namely sd card A)

and reboot
at this state is the same
namely
sd card A USB card reader :Rpi3:micro sd card B in it's slot

but at boot

setenv boot_targets usb0 mmc0 pxe dhcp
saveenv
boot

-----------------
details is next

<power on>

minicom -s

Welcome to minicom 2.7

OPTIONS: I18n
Compiled on Sep  6 2015, 19:49:19.
Port /dev/ttyUSB0, 14:15:36

Press CTRL-A Z for help on special keys



U-Boot 2017.03 (Apr 01 2017 - 04:27:09 -0600)

DRAM:  944 MiB
RPI 3 Model B (0xa02082)
MMC:   bcm2835_sdhci: 0
reading uboot.env

** Unable to read "uboot.env" from mmc0:1 **
Using default environment

In:    serial
Out:   lcd
Err:   lcd

Net:   Net Initialization Skipped

No ethernet found.

starting USB...

USB0:   Core Release: 2.80a

scanning bus 0 for devices... 4 USB Device(s) found

       scanning usb for storage devices... 1 Storage Device(s) found

       scanning usb for ethernet devices... 1 Ethernet Device(s) found

Hit any key to stop autoboot:  0

U-Boot> setenv boot_targets usb0 mmc0 pxe dhcp   <---######################

U-Boot> saveenv <---######################

Saving Environment to FAT...

writing uboot.env

Error: Invalid FAT entry: 0xffffffe2

Invalid FAT entry

FAT: Misaligned buffer address (000000003ab2ab50)

sdhci_send_command: MMC: 0 busy timeout increasing to: 200 ms.

sdhci_send_command: MMC: 0 busy timeout increasing to: 400 ms.

done

U-Boot> boot    <---######################



USB device 0:

    Device 0: Vendor: MXT-USB Rev: 1308 Prod: Storage Device

            Type: Removable Hard Disk

            Capacity: 15343.0 MB = 14.9 GB (31422464 x 512)

... is now current device

Scanning usb 0:1...

Found EFI removable media binary efi/boot/bootaa64.efi

reading efi/boot/bootaa64.efi

75737 bytes read in 76 ms (972.7 KiB/s)

## Starting EFI application at 01000000 ...

Scanning disks on usb...

Scanning disks on mmc...

MMC Device 1 not found

MMC Device 2 not found

MMC Device 3 not found

Found 5 disks

>> OpenBSD/arm64 BOOTAA64 0.2

boot>

booting sd0a:/bsd: 3734688+568700+500888+672784 [86+438360+232975]=0x7c2c68

[ using 672704 bytes of bsd ELF symbol table ]

Copyright (c) 1982, 1986, 1989, 1991, 1993

        The Regents of the University of California.  All rights reserved.

Copyright (c) 1995-2017 OpenBSD. All rights reserved.
https://www.OpenBSD.org


OpenBSD 6.1 (GENERIC) #0: Sun Apr  2 17:05:03 AEST 2017

    [hidden email]:/usr/src/sys/arch/arm64/compile/GENERIC

real mem  = 989855744 (944MB)

avail mem = 931606528 (888MB)

mainbus0 at root: Raspberry Pi 3 Model B Rev 1.2

simplefb0 at mainbus0: 656x416

wsdisplay0 at simplefb0 mux 1

wsdisplay0: screen 0 added (std, vt100 emulation)

simplebus0 at mainbus0: "soc"

bcmintc0 at simplebus0

bcmdog0 at simplebus0

pluart0 at simplebus0

com0 at simple�].�.r��6550, no workingcom0: console

dwctwo0 at simplebus0

agtimer0 at simplebus0: tick rate 19200 KHz

simplebus1 at mainbus0: "clocks"

usb0 at dwctwo0: USB revision 2.0

uhub0 at usb0 configuration 1 interface 0 "Broadcom DWC2 root hub" rev
2.00/1.01
uhub1 at uhub0 port 1 configuration 1 interface 0 "Standard Microsystems
produc2
smsc0 at uhub1 port 1 configuration 1 interface 0 "Standard Microsystems
SMSC953
smsc0: address b8:27:eb:c3:cc:1a

ukphy0 at smsc0 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI
0x0001fc
umass0 at uhub1 port 2 configuration 1 interface 0 "MXTronics MXT USB
Device" r4
umass0: using SCSI over Bulk-Only

scsibus0 at umass0: 2 targets, initiator 0

sd0 at scsibus0 targ 1 lun 0: <MXT-USB, Storage Device, 1308> SCSI0
0/direct ree
sd0: 15343MB, 512 bytes/sector, 31422464 sectors

vscsi0 at root

scsibus1 at vscsi0: 256 targets

softraid0 at root

scsibus2 at softraid0: 256 targets

bootfile: sd0a:/bsd

boot device: sd0

root on sd0a (a81499ded4c64177.a) swap on sd0b dump on sd0b

WARNING: /mnt was not properly unmounted

WARNING: CHECK AND RESET THE DATE!

Automatic boot in progress: starting file system checks.

/dev/sd0a (a81499ded4c64177.a): 1437 files, 21388 used, 223443 free (35
frags, )
/dev/sd0a (a81499ded4c64177.a): MARKING FILE SYSTEM CLEAN

/dev/sd0l (a81499ded4c64177.l): file system is clean; not checking

/dev/sd0d (a81499ded4c64177.d): file system is clean; not checking

/dev/sd0f (a81499ded4c64177.f): file system is clean; not checking

/dev/sd0g (a81499ded4c64177.g): file system is clean; not checking

/dev/sd0h (a81499ded4c64177.h): file system is clean; not checking

/dev/sd0k (a81499ded4c64177.k): file system is clean; not checking

/dev/sd0j (a81499ded4c64177.j): file system is clean; not checking

/dev/sd0e (a81499ded4c64177.e): file system is clean; not checking

setting tty flags

pf enabled

starting network

DHCPREQUEST on smsc0 to 255.255.255.255

DHCPACK from 192.168.80.1 (c8:3a:35:3b:c4:d0)

bound to 192.168.80.102 -- renewal in 43200 seconds.

reordering libraries:

 done.

openssl: generating isakmpd/iked RSA keys... done.

ssh-keygen: generating new host keys: RSA DSA ECDSA ED25519

starting early daemons: syslogd pflogd ntpd.

starting RPC daemons:.

savecore: no core dump

checking quotas: done.

clearing /tmp

kern.securelevel: 0 -> 1

creating runtime link editor directory cache.

preserving editor files.

starting network daemons: sshd smtpd sndiod.

Path to firmware: http://firmware.openbsd.org/firmware/6.1/

No devices found which need firmware files to be downloaded.

starting local daemons: cron.

Sun Apr  2 16:26:36 JST 2017



OpenBSD/arm64 (foo.my.domain) (console)



login: root

Password:

OpenBSD 6.1 (GENERIC) #0: Sun Apr  2 17:05:03 AEST 2017



Welcome to OpenBSD: The proactively secure Unix-like operating system.



Please use the sendbug(1) utility to report bugs in the system.

Before reporting a bug, please try to reproduce it with the latest

version of the code.  With bug reports, please try to ensure that

enough information to reproduce the problem is enclosed, and if a

known fix for it exists, include that as well.



You have new mail.

#


----------
regards
Reply | Threaded
Open this post in threaded view
|

Re: near future (Rpi3)

Laurence Rochfort
there is a very good reading at
http://www.undeadly.org/cgi?action=article&sid=20170409123528&mode=flat%20%EF%BF%BC

Tl;dr

How have the closed blob issues been overcome? I believed they were a
blocker for support of the Pi?
Reply | Threaded
Open this post in threaded view
|

Re: near future (Rpi3)

Tuyosi Takesima
In reply to this post by Tuyosi Takesima
i have no skill of programming .

i only pick a gold coin in the deapth of big lake .

---
regards
Reply | Threaded
Open this post in threaded view
|

Re: near future (Rpi3)

Tuyosi Takesima
In reply to this post by Tuyosi Takesima
Hi all .

if we  use proper SATA-USB converter cable .
we can use arm as server .

in fact
# df

Filesystem  512-blocks      Used     Avail Capacity  Mounted on

/dev/sd0a      2057756     86744   1868128     4%    /

/dev/sd0l    247708268        36 235322820     0%    /home
about 120GB

/dev/sd0d      8250812        20   7838252     0%    /tmp

/dev/sd0f      4122108    899864   3016140    23%    /usr

/dev/sd0g      2057756    346328   1608544    18%    /usr/X11R6

/dev/sd0h     20636924       436  19604644     0%    /usr/local

/dev/sd0k      4122108         4   3916000     0%    /usr/obj

/dev/sd0j      4122108         4   3916000     0%    /usr/src

/dev/sd0e     12058396      8660  11446820     0%    /var


in my case , i use USB-CVIDE5 made by sanwa .

---------------

regards
http://openbsd-akita.blogspot.jp/2017/03/openbsd-61-on-raspberry-pi-3.html
Reply | Threaded
Open this post in threaded view
|

Re: near future (Rpi3)

Mark Kettenis
In reply to this post by Laurence Rochfort
> From: Laurence Rochfort <[hidden email]>
> Date: Sat, 15 Apr 2017 05:45:50 +0000
>
> How have the closed blob issues been overcome? I believed they were a
> blocker for support of the Pi?

It's never been a blocking issue.

The firmware that runs on the graphics core of the Pi is
closed-source.  This isn't really any different from firmware running
on the GPU on a PC.  The graphics core has almost unrestricted access
to main memory of the Pi.  But so has the GPU in a PC.  But the
firmware does run in a different address space.  In the end the only
weird thing is that the graphics core firmware plays a major role in
booting the Pi and that the firmware needs to be present on the SD
card that the Pi is booted from.  At least the Pi firmware is
redistributable.

In the end the Pi isn't a particularly brilliant design.  The USB
controller sucks, the SD/MMC controllers are slow, the Ethernet
controller is a USB device.  On the other hand, the hardware is cheap,
widely available and the hardware seems to be a bit more reliable than
som of the cheap devices that come directly from China.  So we decided
that it was worth supporting anyway.

The current Pine64 firmware contains a closed-source blob as well,
which actually runs on the ARM CPU itself.  It is unclear under what
terms that firmware can be redistributed, which is why we don't offer
Pine64 install media right now.  But, completely open-source firmware
for the Pine64 and maybe other Allwinner A64 and H5 based boards
should be available soon.  So if you're really paranoid you might want
to use one of those boards instead.

Cheers,

Mark

Reply | Threaded
Open this post in threaded view
|

Re: near future (Rpi3)

Tuyosi Takesima
In reply to this post by Tuyosi Takesima
thanks for good information .

how about odroid ?

--------------------------
The ODROID means Open + Android.
It is a development platform with hardware as well as software.
Reply | Threaded
Open this post in threaded view
|

Re: near future (Rpi3)

Mark Kettenis
> From: Tuyosi T <[hidden email]>
> Date: Tue, 18 Apr 2017 03:02:04 +0900
>
> how about odroid ?

The Odroid-XU4, and almost certainly the Odroid-XU3 use a Samsung
Exynos5 SoC and are supported by OpenBSD/armv7.  Only USB works, but
the onboard ethernet is ure(4), so that works as well.  You need a
closed-source first-stage "secure" bootloader from Hardkernel and it
is unclear under what terms that binary can be redistributed.  So
you're unlikely to see official OpenBSD installation images for this
hardware.  The first-stage bootloader remains active and provides some
power management interfaces to the non-secure world.  This interface
is used to spin up secondary CPU cores.  Unfortunately it doesn't
provide the standard PSCI interface for that.  On the bright side,
Hardkernel provides a version of the first-stage bootloader that can
load mainline U-Boot.

The situation on the Odroid-C2 is worse.  The Amlogic S905 SoC needs a
closed-source first-stage bootloader as well, and this bootloader can
only boot a U-Boot that has been signed.  Hardkernel provides a
closed-source Linux binary to do the signing.  Not good.  Therefore
there is no real interest in supporting this hardware in OpenBSD/arm64.

> --------------------------
> The ODROID means Open + Android.
> It is a development platform with hardware as well as software.

For some definition of Open...

In the end we're a small group and we we can only support a limited
subset of all the ARMv7 and ARMv8 hardware out there.  We'll select
platforms that either have good support in mainline U-Boot or come
with preloaded UEFI firmware and defenitely prefer ones with
completely open source firmware.

Reply | Threaded
Open this post in threaded view
|

Re: near future (Rpi3)

Tuyosi Takesima
In reply to this post by Tuyosi Takesima
Thank MARK  for the clear explanation .

i can use raspberry pi 3 's openbsd as ssh server and http server .
That's enough because i think server shoud not run X .
( a special sata-usb converter works well , so big space is OK )

surely now state  Rpi3 cannot install lftp by ports ,
but by using sftp archlinux push files to Rpi3 .

and robot wirh Rpi3's openbsd is controlled by ssh .
other OS including linux of arm is not secure about ssh .
so arm's future is open to openbsd .

----
regard

http://openbsd-akita.blogspot.jp/2017/03/openbsd-61-on-raspberry-pi-3.html
Reply | Threaded
Open this post in threaded view
|

Re: near future (Rpi3)

Stuart Henderson
On 2017/04/18 05:54, Tuyosi T wrote:
> surely now state  Rpi3 cannot install lftp by ports ,

lftp works fine on aarch64. Install a snapshot, pkg_add lftp.

Reply | Threaded
Open this post in threaded view
|

Re: near future (Rpi3)

tinkr
In reply to this post by Mark Kettenis
On 2017-04-17 19:29, Mark Kettenis wrote:

>> From: Tuyosi T <[hidden email]>
>> Date: Tue, 18 Apr 2017 03:02:04 +0900
>>
>> how about odroid ?
>
> The Odroid-XU4, and almost certainly the Odroid-XU3 use a Samsung
> Exynos5 SoC and are supported by OpenBSD/armv7.  Only USB works, but
> the onboard ethernet is ure(4), so that works as well.  You need a
> closed-source first-stage "secure" bootloader from Hardkernel and it
> is unclear under what terms that binary can be redistributed.  So
> you're unlikely to see official OpenBSD installation images for this
> hardware.  The first-stage bootloader remains active and provides some
> power management interfaces to the non-secure world.  This interface
> is used to spin up secondary CPU cores.  Unfortunately it doesn't
> provide the standard PSCI interface for that.  On the bright side,
> Hardkernel provides a version of the first-stage bootloader that can
> load mainline U-Boot.

Wait this should be added to https://www.openbsd.org/arm64.html /
https://www.openbsd.org/armv7.html ?

> The situation on the Odroid-C2 is worse.  The Amlogic S905 SoC needs a
> closed-source first-stage bootloader as well, and this bootloader can
> only boot a U-Boot that has been signed.  Hardkernel provides a
> closed-source Linux binary to do the signing.  Not good.  Therefore
> there is no real interest in supporting this hardware in OpenBSD/arm64.

So derpy. Luckily the Amlogic S905 is really unimportant in the
ecosystem - it's slow, not cheap, etc.