Orange PI Zero

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Orange PI Zero

Luiz Gustavo dos S. Costa
Hello list,

Yesterday, received a new board to a lab with Linux for a product,
but, my principal intencion is use with OpenBSD.

Image: http://imgur.com/a/fRWky
Describe: http://www.orangepi.org/orangepizero/

Ok, i burned a new sdcard with a ready image from Openbsd 6-current
and orange dtb (Orange PC) and i obtained this dmesg:

.... (complete dmesg here: http://pastebin.com/29qjkNXC )

gpio7 at sxipio0: 28 pins
gpio8 at sxipio0: 22 pins

uvm_fault(0xc0ceb8a4, 8b6af000, 1, 0) -> e
Fatal kernel mode data abort: 'Translation fault (L1)'
trapframe: 0xca8f4d08
DFSR=00000005, DFAR=8b6afe2c, spsr=20000113
r0 =8b6afe2c, r1 =00000001, r2 =ca8f4d7c, r3 =c0c94dac
r4 =c04f2234, r5 =ca8f4d7c, r6 =c04f2234, r7 =00000020
r8 =017d7840, r9 =00000000, r10=c0ceb940, r11=ca8f4d74
r12=ca8f4d78, ssp=ca8f4d58, slr=c04088d4, pc =c040869c

panic: Fatal abort
syncing disks... done
rebooting...

My question is: How to begin make a debug to solution to this panic ?

Where to start? What do i have to change? Ok, ok ... I know i need the
sources, etc ... but is there a "path to the stones"?

Thanks !

--
Luiz Gustavo Costa  |  +55 (21) 9-8834-6998
-----------------------------------------------------------------
Mundounix - Consultoria em Software Livre
http://www.mundounix.com.br
Skype: mundounix

Reply | Threaded
Open this post in threaded view
|

Re: Orange PI Zero

Jonathan Gray-11
On Thu, Dec 22, 2016 at 12:11:36PM -0200, Luiz Gustavo dos S. Costa wrote:

> Hello list,
>
> Yesterday, received a new board to a lab with Linux for a product,
> but, my principal intencion is use with OpenBSD.
>
> Image: http://imgur.com/a/fRWky
> Describe: http://www.orangepi.org/orangepizero/
>
> Ok, i burned a new sdcard with a ready image from Openbsd 6-current
> and orange dtb (Orange PC) and i obtained this dmesg:
>
> .... (complete dmesg here: http://pastebin.com/29qjkNXC )
>
> gpio7 at sxipio0: 28 pins
> gpio8 at sxipio0: 22 pins
>
> uvm_fault(0xc0ceb8a4, 8b6af000, 1, 0) -> e
> Fatal kernel mode data abort: 'Translation fault (L1)'
> trapframe: 0xca8f4d08
> DFSR=00000005, DFAR=8b6afe2c, spsr=20000113
> r0 =8b6afe2c, r1 =00000001, r2 =ca8f4d7c, r3 =c0c94dac
> r4 =c04f2234, r5 =ca8f4d7c, r6 =c04f2234, r7 =00000020
> r8 =017d7840, r9 =00000000, r10=c0ceb940, r11=ca8f4d74
> r12=ca8f4d78, ssp=ca8f4d58, slr=c04088d4, pc =c040869c
>
> panic: Fatal abort
> syncing disks... done
> rebooting...
>
> My question is: How to begin make a debug to solution to this panic ?
>
> Where to start? What do i have to change? Ok, ok ... I know i need the
> sources, etc ... but is there a "path to the stones"?
>
> Thanks !

The ramdisk kernels do not have the kernel debugger (ddb).

If you mount /dev/sdXa (where sdX is your sd/mmc device) you can replace
/mnt/bsd with
http://ftp.openbsd.org/pub/OpenBSD/snapshots/armv7/bsd

You will then be able to run "trace" and "show registers" at the
ddb prompt.

Reply | Threaded
Open this post in threaded view
|

Re: Orange PI Zero

Daniel Bolgheroni-6
In reply to this post by Luiz Gustavo dos S. Costa
On Thu, Dec 22, 2016 at 12:11:36PM -0200, Luiz Gustavo dos S. Costa wrote:
> Yesterday, received a new board to a lab with Linux for a product,
> but, my principal intencion is use with OpenBSD.

I booted on an Orange Pi One this week, with the Allwinner H3 SoC (the
same as in C.H.I.P. board). It went fine, however I can't install
because, iirc, sd/mmc access times out. I will post the full dmesg when
I get access to the board again.

Reply | Threaded
Open this post in threaded view
|

Re: Orange PI Zero

Mark Kettenis
> Date: Fri, 23 Dec 2016 21:01:38 -0200
> From: Daniel Bolgheroni <[hidden email]>
>
> On Thu, Dec 22, 2016 at 12:11:36PM -0200, Luiz Gustavo dos S. Costa wrote:
> > Yesterday, received a new board to a lab with Linux for a product,
> > but, my principal intencion is use with OpenBSD.
>
> I booted on an Orange Pi One this week, with the Allwinner H3 SoC (the
> same as in C.H.I.P. board). It went fine, however I can't install
> because, iirc, sd/mmc access times out. I will post the full dmesg when
> I get access to the board again.

The H3 support is still somewhat under development.  My H3-based
Banana Pi M2+ had similar sd/mmc issues which I tracked down to a
problem with the lack of pull-ups in the device tree.  See the diff
below.  You might have to make similar changes to the device tree of
the Orange Pi One to make it work.  That requires rebuilding u-boot.

Linux worked because it had a bug and always enabled the pull-ups.
Then they started fixing things and things have become a bit messy.  I
think device trees from a the head of the Linux kernel tree do things
differently now and probably won't work with OpenBSD anymore.  Not
sure of those new trees have landed in u-boot yet.  I any case I
decided to wait a bit for things to stablise in Linux-land.


commit f6ad0c701632a02ec03ea219394c14981abe7aab
Author: Mark Kettenis <[hidden email]>
Date:   Sun Sep 18 17:49:05 2016 +0200

    ARM: dts: sun8i: Enable pull-ups for bananapi-m2-plus SD slot
   
    Board doesn't seem to have external pull-ups and some (but not all) SD cards
    don't work without pull-ups.
   
    Signed-off-by: Mark Kettenis <[hidden email]>

diff --git a/arch/arm/boot/dts/sun8i-h3-bananapi-m2-plus.dts b/arch/arm/boot/dts/sun8i-h3-bananapi-m2-plus.dts
index 06fddaae8edd..e30ab03f5eee 100644
--- a/arch/arm/boot/dts/sun8i-h3-bananapi-m2-plus.dts
+++ b/arch/arm/boot/dts/sun8i-h3-bananapi-m2-plus.dts
@@ -117,6 +117,10 @@
  status = "okay";
 };
 
+&mmc0_pins_a {
+ allwinner,pull = <SUN4I_PINCTRL_PULL_UP>;
+};
+
 &mmc1 {
  pinctrl-names = "default";
  pinctrl-0 = <&mmc1_pins_a>;

Reply | Threaded
Open this post in threaded view
|

Re: Orange PI Zero

Daniel Bolgheroni-6
On Sat, Dec 24, 2016 at 12:26:34AM +0100, Mark Kettenis wrote:

> > Date: Fri, 23 Dec 2016 21:01:38 -0200
> > From: Daniel Bolgheroni <[hidden email]>
> >
> > On Thu, Dec 22, 2016 at 12:11:36PM -0200, Luiz Gustavo dos S. Costa wrote:
> > > Yesterday, received a new board to a lab with Linux for a product,
> > > but, my principal intencion is use with OpenBSD.
> >
> > I booted on an Orange Pi One this week, with the Allwinner H3 SoC (the
> > same as in C.H.I.P. board). It went fine, however I can't install
> > because, iirc, sd/mmc access times out. I will post the full dmesg when
> > I get access to the board again.
>
> The H3 support is still somewhat under development.  My H3-based
> Banana Pi M2+ had similar sd/mmc issues which I tracked down to a
> problem with the lack of pull-ups in the device tree.  See the diff
> below.  You might have to make similar changes to the device tree of
> the Orange Pi One to make it work.  That requires rebuilding u-boot.
>
> Linux worked because it had a bug and always enabled the pull-ups.
> Then they started fixing things and things have become a bit messy.  I
> think device trees from a the head of the Linux kernel tree do things
> differently now and probably won't work with OpenBSD anymore.  Not
> sure of those new trees have landed in u-boot yet.  I any case I
> decided to wait a bit for things to stablise in Linux-land.
>
>
> commit f6ad0c701632a02ec03ea219394c14981abe7aab
> Author: Mark Kettenis <[hidden email]>
> Date:   Sun Sep 18 17:49:05 2016 +0200
>
>     ARM: dts: sun8i: Enable pull-ups for bananapi-m2-plus SD slot
>    
>     Board doesn't seem to have external pull-ups and some (but not all) SD cards
>     don't work without pull-ups.
>    
>     Signed-off-by: Mark Kettenis <[hidden email]>
>
> diff --git a/arch/arm/boot/dts/sun8i-h3-bananapi-m2-plus.dts b/arch/arm/boot/dts/sun8i-h3-bananapi-m2-plus.dts
> index 06fddaae8edd..e30ab03f5eee 100644
> --- a/arch/arm/boot/dts/sun8i-h3-bananapi-m2-plus.dts
> +++ b/arch/arm/boot/dts/sun8i-h3-bananapi-m2-plus.dts
> @@ -117,6 +117,10 @@
>   status = "okay";
>  };
>  
> +&mmc0_pins_a {
> + allwinner,pull = <SUN4I_PINCTRL_PULL_UP>;
> +};
> +
>  &mmc1 {
>   pinctrl-names = "default";
>   pinctrl-0 = <&mmc1_pins_a>;

Reporting my findings.

Tried the corresponding change to sun8i-h3-orangepi-one.dts instead of the dts
of the Banana Pi, recompiled u-boot and regenerated the miniroot for the board.

Thank you.

--

U-Boot SPL 2016.11 (Dec 27 2016 - 21:01:57)
DRAM: 512 MiB
Trying to boot from MMC1


U-Boot 2016.11 (Dec 27 2016 - 21:01:57 -0200) Allwinner Technology

CPU:   Allwinner H3 (SUN8I 1680)
Model: Xunlong Orange Pi One
DRAM:  512 MiB
MMC:   SUNXI SD/MMC: 0
*** Warning - bad CRC, using default environment

In:    serial
Out:   serial
Err:   serial
Net:   phy interface0
eth0: ethernet@1c30000
starting USB...
USB0:   USB EHCI 1.00
USB1:   USB OHCI 1.0
scanning bus 0 for devices... 1 USB Device(s) found
Hit any key to stop autoboot:  0
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
reading /sun8i-h3-orangepi-one.dtb
12157 bytes read in 25 ms (474.6 KiB/s)
Found EFI removable media binary efi/boot/bootarm.efi
reading efi/boot/bootarm.efi
64716 bytes read in 39 ms (1.6 MiB/s)
## Starting EFI application at 0x42000000 ...
CACHE: Misaligned operation at range [5af2d000, 5af3cccc]
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/armv7 BOOTARM 0.5
boot>
cannot open sd0a:/etc/random.seed: No such file or directory
booting sd0a:/bsd: 3717676+154280+578652 [80+493936+229419]=0x4f3a8c

OpenBSD/armv7 booting ...
arg0 0xc07f3a8c arg1 0x0 arg2 0x48000000
Allocating page tables
freestart = 0x407f4000, free_pages = 129036 (0x0001f80c)
IRQ stack: p0x40822000 v0xc0822000
ABT stack: p0x40823000 v0xc0823000
UND stack: p0x40824000 v0xc0824000
SVC stack: p0x40825000 v0xc0825000
Creating L1 page table at 0x407f4000
Mapping kernel
Constructing L2 page tables
undefined page pmap [ using 723848 bytes of bsd ELF symbol table ]
board type: 0
Copyright (c) 1982, 1986, 1989, 1991, 1993
        The Regents of the University of California.  All rights reserved.
Copyright (c) 1995-2016 OpenBSD. All rights reserved.  https://www.OpenBSD.org

OpenBSD 6.0-current (GENERIC) #0: Thu Dec 22 13:45:42 MST 2016
    [hidden email]:/usr/src/sys/arch/armv7/compile/GENERIC
real mem  = 536870912 (512MB)
avail mem = 517820416 (493MB)
warning: no entropy supplied by boot loader
mainbus0 at root: Xunlong Orange Pi One
cpu0 at mainbus0: ARM Cortex A7 rev 5 (ARMv7 core)
cpu0: DC enabled IC enabled WB disabled EABT branch prediction enabled
cpu0: 32KB(32b/l,2way) I-cache, 32KB(64b/l,4way) wr-back D-cache
cortex0 at mainbus0
agtimer0 at mainbus0: tick rate 24000 KHz
sxiccmu0 at mainbus0
simplebus0 at mainbus0: "soc"
sxiccmu1 at simplebus0
sxipio0 at simplebus0: 94 pins
sximmc0 at simplebus0
sdmmc0 at sximmc0: 4-bit, sd high-speed, mmc high-speed, dma
ehci0 at simplebus0
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 configuration 1 interface 0 "Allwinner EHCI root hub" rev 2.00/1.00 addr 1
sxidog0 at simplebus0
com0 at simplebus0: ns16550, no working fifo
com0: console
ampintc0 at simplebus0 nirq 160
gpio0 at sxipio0: 18 pins
gpio1 at sxipio0: 24 pins
gpio2 at sxipio0: 25 pins
gpio3 at sxipio0: 28 pins
gpio4 at sxipio0: 12 pins
gpio5 at sxipio0: 6 pins
gpio6 at sxipio0: 12 pins
gpio7 at sxipio0: 28 pins
gpio8 at sxipio0: 22 pins

uvm_fault(0xc06fd9c4, 8104f000, 1, 0) -> e
Fatal kernel mode data abort: 'Translation fault (L1)'
trapframe: 0xcb1e3ca0
DFSR=00000005, DFAR=8104f4d0, spsr=20000113
r0 =8104f4d0, r1 =00000001, r2 =cb1e3d18, r3 =c069857c
r4 =c066f26c, r5 =cb1e3d18, r6 =c066f26c, r7 =00000020
r8 =017d7840, r9 =00000000, r10=c06fda60, r11=cb1e3d14
r12=cb1e3d18, ssp=cb1e3cf0, slr=c0525088, pc =c0524e4c

Stopped at      fdt_node_property+0x34: ldr     r3, [r0]
ddb> trace
fdt_node_property+0x10
        scp=0xc0524e28 rlv=0xc0525088 (OF_getproplen+0x2c)
        rsp=0xcb1e3d18 rfp=0xcb1e3d3c
        r6=0xc066f26c r5=0x8104f4d0 r4=0x00000001
OF_getproplen+0x10
        scp=0xc052506c rlv=0xc0536904 (clock_get_frequency_idx+0x20)
        rsp=0xcb1e3d40 rfp=0xcb1e3d64
        r6=0xcb1e3da4 r5=0xc08284d0 r4=0x00000001
clock_get_frequency_idx+0xc
        scp=0xc05368f0 rlv=0xc05feb3c (sxiccmu_mmc_set_frequency+0x64)
        rsp=0xcb1e3d68 rfp=0xcb1e3d94
        r7=0x00000020 r6=0xcb1e3da4 r5=0xc89e1800 r4=0x017d7840
sxiccmu_mmc_set_frequency+0xc
        scp=0xc05feae4 rlv=0xc05fecbc (sxiccmu_ccu_set_frequency+0x9c)
        rsp=0xcb1e3d98 rfp=0xcb1e3e0c
        r10=0xc06fda60 r8=0x017d7840 r7=0x00000020 r6=0xc89e17e0
        r5=0xc89e1800 r4=0x017d7840
sxiccmu_ccu_set_frequency+0xc
        scp=0xc05fec2c rlv=0xc0535ff4 (clock_set_frequency_cells+0x60)
        rsp=0xcb1e3e10 rfp=0xcb1e3e24
        r4=0x00000000
clock_set_frequency_cells+0x10
        scp=0xc0535fa4 rlv=0xc0536708 (clock_set_frequency_idx+0xc4)
        rsp=0xcb1e3e28 rfp=0xcb1e3e54
clock_set_frequency_idx+0xc
        scp=0xc0536650 rlv=0xc06033a0 (sximmc_set_clock+0x38)
        rsp=0xcb1e3e58 rfp=0xcb1e3e74
        r8=0xc89e0464 r7=0xc4ac8a00 r6=0x000061a8 r5=0xc89e0300
        r4=0x000061a8
sximmc_set_clock+0xc
        scp=0xc0603374 rlv=0xc06034b8 (sximmc_bus_clock+0xd0)
        rsp=0xcb1e3e78 rfp=0xcb1e3e9c
        r5=0xc89e0300 r4=0x00000000
sximmc_bus_clock+0x10
        scp=0xc06033f8 rlv=0xc053a6f8 (sdmmc_mem_sd_init+0x30)
        rsp=0xcb1e3ea0 rfp=0xcb1e3f1c
        r6=0xc89e0400 r5=0xc89e0400 r4=0xc89e0400
sdmmc_mem_sd_init+0x10
        scp=0xc053a6d8 rlv=0xc0537724 (sdmmc_init+0x78)
        rsp=0xcb1e3f20 rfp=0xcb1e3f3c
        r10=0xc06fda60 r8=0xc89e0464 r7=0xc069a894 r6=0xc89e0400
        r5=0xc89e0400 r4=0xc4ac8a00
sdmmc_init+0xc
        scp=0xc05376b8 rlv=0xc0537a98 (sdmmc_card_attach+0x8c)
        rsp=0xcb1e3f40 rfp=0xcb1e3f5c
        r5=0xc89e049c r4=0xc89e0400
sdmmc_card_attach+0xc
        scp=0xc0537a18 rlv=0xc0537bb4 (sdmmc_discover_task+0xac)
        rsp=0xcb1e3f60 rfp=0xcb1e3f7c
        r5=0xc89e0400 r4=0xc89e046c
sdmmc_discover_task+0xc
        scp=0xc0537b14 rlv=0xc0537c20 (sdmmc_task_thread+0x64)
        rsp=0xcb1e3f80 rfp=0xcb1e3fac
        r5=0x00000000 r4=0xc89e046c
sdmmc_task_thread+0xc
        scp=0xc0537bc8 rlv=0xc052c358 (proc_trampoline+0x18)
        rsp=0xcb1e3fb0 rfp=0xc0826ecc
        r8=0xc06fdc48 r7=0x00000000 r6=0x00000000 r5=0xc89e0400
        r4=0xc0537bbc
Bad frame pointer: 0xc0826ecc
ddb> ps
   PID   PPID   PGRP    UID  S       FLAGS  WAIT          COMMAND
 56142      0      0      0  3     0x14200  bored         crynlk
 42855      0      0      0  3     0x14200  bored         crypto
  3608      0      0      0  3     0x14200  pftm          pfpurge
 43823      0      0      0  3     0x14200  usbtsk        usbtask
 76858      0      0      0  3     0x14200  usbatsk       usbatsk
*99005      0      0      0  7     0x14200                sdmmc0
  3586      0      0      0  3     0x14200  bored         softnet
 52042      0      0      0  3     0x14200  bored         systqmp
 52037      0      0      0  3     0x14200  bored         systq
 43156      0      0      0  3  0x40014200  bored         softclock
 49973      0      0      0  3  0x40014200                idle0
 15463      0      0      0  3     0x14200  kmalloc       kmthread
     1      0      0      0  3           0  initexec      swapper
     0     -1      0      0  3     0x10200  cfpend        swapper
ddb>

--
db

Reply | Threaded
Open this post in threaded view
|

Re: Orange PI Zero

Luiz Gustavo dos S. Costa
In reply to this post by Mark Kettenis
2016-12-23 21:26 GMT-02:00 Mark Kettenis <[hidden email]>:
>
> The H3 support is still somewhat under development.  My H3-based
> Banana Pi M2+ had similar sd/mmc issues which I tracked down to a
> problem with the lack of pull-ups in the device tree.  See the diff
> below.  You might have to make similar changes to the device tree of
> the Orange Pi One to make it work.  That requires rebuilding u-boot.

Thanks Mark, with this patch, now boot is working. But without disk detected.

next works... :)

Welcome to the OpenBSD/armv7 6.0 installation program.
(I)nstall, (U)pgrade, (A)utoinstall or (S)hell? s
# dmesg

OpenBSD 6.0-current (RAMDISK) #0: Mon Oct 31 15:19:56 MDT 2016
    [hidden email]:/usr/src/sys/arch/armv7/compile/RAMDISK
real mem  = 268435456 (256MB)
avail mem = 248795136 (237MB)
mainbus0 at root: Xunlong Orange Pi PC
cpu0 at mainbus0: ARM Cortex A7 rev 5 (ARMv7 core)
cpu0: DC enabled IC enabled WB disabled EABT branch prediction enabled
cpu0: 32KB(32b/l,2way) I-cache, 32KB(64b/l,4way) wr-back D-cache
cortex0 at mainbus0
agtimer0 at mainbus0: tick rate 24000 KHz
sxiccmu0 at mainbus0
simplebus0 at mainbus0: "soc"
sxiccmu1 at simplebus0
sxipio0 at simplebus0: 94 pins
ehci0 at simplebus0
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 configuration 1 interface 0 "Allwinner EHCI root hub"
rev 2.00/1.00 addr 1
ehci1 at simplebus0
usb1 at ehci1: USB revision 2.0
uhub1 at usb1 configuration 1 interface 0 "Allwinner EHCI root hub"
rev 2.00/1.00 addr 1
ehci2 at simplebus0
usb2 at ehci2: USB revision 2.0
uhub2 at usb2 configuration 1 interface 0 "Allwinner EHCI root hub"
rev 2.00/1.00 addr 1
sxidog0 at simplebus0
com0 at simplebus0: ns16550, no working fifo
com0: console
ampintc0 at simplebus0 nirq 160
gpio0 at sxipio0: 18 pins
gpio1 at sxipio0: 24 pins
gpio2 at sxipio0: 25 pins
gpio3 at sxipio0: 28 pins
gpio4 at sxipio0: 12 pins
gpio5 at sxipio0: 6 pins
gpio6 at sxipio0: 12 pins
gpio7 at sxipio0: 28 pins
gpio8 at sxipio0: 22 pins
boot device: lookup 'sd0a:/bsd' failed.
root on rd0a swap on rd0b dump on rd0b
WARNING: CHECK AND RESET THE DATE!


--
Luiz Gustavo Costa  |  +55 (21) 9-8834-6998
-----------------------------------------------------------------
Mundounix - Consultoria em Software Livre
http://www.mundounix.com.br
Skype: mundounix

Reply | Threaded
Open this post in threaded view
|

Re: Orange PI Zero

Mark Kettenis
> From: "Luiz Gustavo dos S. Costa" <[hidden email]>
> Date: Wed, 28 Dec 2016 22:17:32 -0200
>
> 2016-12-23 21:26 GMT-02:00 Mark Kettenis <[hidden email]>:
> >
> > The H3 support is still somewhat under development.  My H3-based
> > Banana Pi M2+ had similar sd/mmc issues which I tracked down to a
> > problem with the lack of pull-ups in the device tree.  See the diff
> > below.  You might have to make similar changes to the device tree of
> > the Orange Pi One to make it work.  That requires rebuilding u-boot.
>
> Thanks Mark, with this patch, now boot is working. But without disk detected.

Well, that's a bit useless isn't it?  Not sure what type of "disk" you
tried; USB should at work I think.  But SD card doesn't because the
Orange Pi PC apparently doesn't have an SD slot and leaves the
controller for it disabled.

According to:

  http://linux-sunxi.org/Xunlong_Orange_Pi_Zero

the clostest match for the Orange Pi Zero is a u-boot built from
orange_one_defconfig.

Reply | Threaded
Open this post in threaded view
|

Re: Orange PI Zero

Luiz Gustavo dos S. Costa
2016-12-29 7:44 GMT-02:00 Mark Kettenis <[hidden email]>:
> Well, that's a bit useless isn't it?  Not sure what type of "disk" you
> tried; USB should at work I think.  But SD card doesn't because the
> Orange Pi PC apparently doesn't have an SD slot and leaves the
> controller for it disabled.
>

Yes, the sdcard is not functional, as i only have one usb port
available, I preferred to use with a wifi adapter to have network

run0 at uhub0 port 1 configuration 1 interface 0 "Ralink 802.11 n
WLAN" rev 2.00/1.01 addr 2
run0: MAC/BBP RT5390 (rev 0x0502), RF RT5370 (MIMO 1T1R), address
00:c1:40:67:0d:0e

Still has a job to be done, I have no ethernet and no wifi .... I play
with what I can in it.

> According to:
>
>   http://linux-sunxi.org/Xunlong_Orange_Pi_Zero
>
> the clostest match for the Orange Pi Zero is a u-boot built from
> orange_one_defconfig.
>

Happy new year !

--
Luiz Gustavo Costa  |  +55 (21) 9-8834-6998
-----------------------------------------------------------------
Mundounix - Consultoria em Software Livre
http://www.mundounix.com.br
Skype: mundounix

Reply | Threaded
Open this post in threaded view
|

Re: Orange PI Zero

Mark Kettenis
In reply to this post by Daniel Bolgheroni-6
> Date: Tue, 27 Dec 2016 22:42:15 -0200
> From: Daniel Bolgheroni <[hidden email]>
>
> OpenBSD 6.0-current (GENERIC) #0: Thu Dec 22 13:45:42 MST 2016
>     [hidden email]:/usr/src/sys/arch/armv7/compile/GENERIC
> real mem  = 536870912 (512MB)
> avail mem = 517820416 (493MB)
> warning: no entropy supplied by boot loader
> mainbus0 at root: Xunlong Orange Pi One
> cpu0 at mainbus0: ARM Cortex A7 rev 5 (ARMv7 core)
> cpu0: DC enabled IC enabled WB disabled EABT branch prediction enabled
> cpu0: 32KB(32b/l,2way) I-cache, 32KB(64b/l,4way) wr-back D-cache
> cortex0 at mainbus0
> agtimer0 at mainbus0: tick rate 24000 KHz
> sxiccmu0 at mainbus0
> simplebus0 at mainbus0: "soc"
> sxiccmu1 at simplebus0
> sxipio0 at simplebus0: 94 pins
> sximmc0 at simplebus0
> sdmmc0 at sximmc0: 4-bit, sd high-speed, mmc high-speed, dma
> ehci0 at simplebus0
> usb0 at ehci0: USB revision 2.0
> uhub0 at usb0 configuration 1 interface 0 "Allwinner EHCI root hub" rev 2.00/1.00 addr 1
> sxidog0 at simplebus0
> com0 at simplebus0: ns16550, no working fifo
> com0: console
> ampintc0 at simplebus0 nirq 160
> gpio0 at sxipio0: 18 pins
> gpio1 at sxipio0: 24 pins
> gpio2 at sxipio0: 25 pins
> gpio3 at sxipio0: 28 pins
> gpio4 at sxipio0: 12 pins
> gpio5 at sxipio0: 6 pins
> gpio6 at sxipio0: 12 pins
> gpio7 at sxipio0: 28 pins
> gpio8 at sxipio0: 22 pins
>
> uvm_fault(0xc06fd9c4, 8104f000, 1, 0) -> e
> Fatal kernel mode data abort: 'Translation fault (L1)'
> trapframe: 0xcb1e3ca0
> DFSR=00000005, DFAR=8104f4d0, spsr=20000113
> r0 =8104f4d0, r1 =00000001, r2 =cb1e3d18, r3 =c069857c
> r4 =c066f26c, r5 =cb1e3d18, r6 =c066f26c, r7 =00000020
> r8 =017d7840, r9 =00000000, r10=c06fda60, r11=cb1e3d14
> r12=cb1e3d18, ssp=cb1e3cf0, slr=c0525088, pc =c0524e4c

Just committed a fix for this issue.  With that fix my Banana Pi M2+
boots again.

Cheers,

Mark