Pine64+ 2GB and RPI3 (A64 examples): Any general idea on what/when to expect for the return of USB support to head?

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

Pine64+ 2GB and RPI3 (A64 examples): Any general idea on what/when to expect for the return of USB support to head?

Mark Millard-2
[I historically use a ufs USB SSD for a (head) root file
system on a Pine64+ 2GB and a RPI3. Thus the question
below.]

Context for question (note the "USB not working for now"
in the Log Message):

> Revision 320612
>
> Author:
> manu
> Date:
> Mon Jul 3 19:30:03 2017 UTC (4 weeks, 1 day ago)
> Changed paths:
> 5
> Log Message:
> allwinner: Add A64 ccung support
>
> Upstream DTS for A64 SoC doesn't provide a /clocks node as Linux switched
> to ccu-ng
> This commit adds the necessary bits to boot on pine64 with latest DTS from
> upstream.
> USB is not working for now and some node aren't present in the DTS (like the
> PMU, Power Management Unit).
>
> Tested on: Pine64
>
> Changed paths
> Path
> Details
> head/sys/arm/allwinner/a10_mmc.c
> modified , text changed
> head/sys/arm/allwinner/clkng/aw_ccung.c
> modified , text changed
> head/sys/arm/allwinner/clkng/ccu_a64.c
> added
> head/sys/arm/allwinner/clkng/ccu_a64.h
> added
> head/sys/conf/files.arm64
> modified , text changed

/head/sys/arm/allwinner/clkng/ccu_a64.c shows an
empty "USBPHY clk sel" section:

553 /* USBPHY clk sel */
554
555 /* DRAM needs update bit */

tending to confirm the log message.


The questions:

Does anyone have a general idea that they can report for
what/when to expect for the return of USB support for
Pine64+ 2GB, RPI3, and the like A64 based contexts?

Should I just ignore updating the Pine64+ 2GB and RPI3 for
a few months more? (Because I do self-hosted builds on them
I want the USB file system to be used for such activity.)


===
Mark Millard
markmi at dsl-only.net

_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Pine64+ 2GB and RPI3 (A64 examples): Any general idea on what/when to expect for the return of USB support to head?

Emmanuel Vadot-7
On Tue, 1 Aug 2017 14:03:23 -0700
Mark Millard <[hidden email]> wrote:

> [I historically use a ufs USB SSD for a (head) root file
> system on a Pine64+ 2GB and a RPI3. Thus the question
> below.]
>
> Context for question (note the "USB not working for now"
> in the Log Message):
>
> > Revision 320612
> >
> > Author:
> > manu
> > Date:
> > Mon Jul 3 19:30:03 2017 UTC (4 weeks, 1 day ago)
> > Changed paths:
> > 5
> > Log Message:
> > allwinner: Add A64 ccung support
> >
> > Upstream DTS for A64 SoC doesn't provide a /clocks node as Linux switched
> > to ccu-ng
> > This commit adds the necessary bits to boot on pine64 with latest DTS from
> > upstream.
> > USB is not working for now and some node aren't present in the DTS (like the
> > PMU, Power Management Unit).
> >
> > Tested on: Pine64
> >
> > Changed paths
> > Path
> > Details
> > head/sys/arm/allwinner/a10_mmc.c
> > modified , text changed
> > head/sys/arm/allwinner/clkng/aw_ccung.c
> > modified , text changed
> > head/sys/arm/allwinner/clkng/ccu_a64.c
> > added
> > head/sys/arm/allwinner/clkng/ccu_a64.h
> > added
> > head/sys/conf/files.arm64
> > modified , text changed
>
> /head/sys/arm/allwinner/clkng/ccu_a64.c shows an
> empty "USBPHY clk sel" section:
>
> 553 /* USBPHY clk sel */
> 554
> 555 /* DRAM needs update bit */
>
> tending to confirm the log message.

 This is unrelated, this was a comment I've put during developement to
remind me to add the gate bits for usb.
 I'll remove it.

>
> The questions:
>
> Does anyone have a general idea that they can report for
> what/when to expect for the return of USB support for
> Pine64+ 2GB, RPI3, and the like A64 based contexts?

 I'm the only one who could have an idea (for Pine64) and I don't know.

> Should I just ignore updating the Pine64+ 2GB and RPI3 for
> a few months more? (Because I do self-hosted builds on them
> I want the USB file system to be used for such activity.)

 You can do whatever you want, either ignore or help.

--
Emmanuel Vadot <[hidden email]> <[hidden email]>
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Pine64+ 2GB and RPI3 (A64 examples): Any general idea on what/when to expect for the return of USB support to head?

Mark Millard-2
On 2017-Aug-2, at 12:06 PM, Emmanuel Vadot <manu at bidouilliste.com> wrote:

> On Tue, 1 Aug 2017 14:03:23 -0700
> Mark Millard <markmi at dsl-only.net> wrote:
>
>> [I historically use a ufs USB SSD for a (head) root file
>> system on a Pine64+ 2GB and a RPI3. Thus the question
>> below.]
>>
>> Context for question (note the "USB not working for now"
>> in the Log Message):
>>
>>> Revision 320612
>>>
>>> Author:
>>> manu
>>> Date:
>>> Mon Jul 3 19:30:03 2017 UTC (4 weeks, 1 day ago)
>>> Changed paths:
>>> 5
>>> Log Message:
>>> allwinner: Add A64 ccung support
>>>
>>> Upstream DTS for A64 SoC doesn't provide a /clocks node as Linux switched
>>> to ccu-ng
>>> This commit adds the necessary bits to boot on pine64 with latest DTS from
>>> upstream.
>>> USB is not working for now and some node aren't present in the DTS (like the
>>> PMU, Power Management Unit).
>>>
>>> Tested on: Pine64
> . . .
>>
>> The questions:
>>
>> Does anyone have a general idea that they can report for
>> what/when to expect for the return of USB support for
>> Pine64+ 2GB, RPI3, and the like A64 based contexts?
>
> I'm the only one who could have an idea (for Pine64) and I don't know.

Both parts are good to know. And it confirms that I've
not read the wrong content into the note.

>> Should I just ignore updating the Pine64+ 2GB and RPI3 for
>> a few months more? (Because I do self-hosted builds on them
>> I want the USB file system to be used for such activity.)
>
> You can do whatever you want, either ignore or help.

Long term having learned to "get USB going again" for A64
would be good. But I really do not expect someone to deal
with my learning curve. (I've never done anything remotely
analogous.) I'm not aware of a combination of self-study
materials that would get me there either (or close to
there).

I'm afraid that bootstrapping me into "get USB going
again" for A64 might well take more time than the direct
effort to do it would take.

Still if you can identify some way that I'd likely be
of help for the issue (or other issues that would help
clear the way for this one) that would be great. Feel
free to point me at things to read or otherwise study.


Side notes on my FreeBSD activities so far:

I've been able to identify very narrow specific points
in preexisting code such as the sp_el0 usage with
interrupts enabled in the fork_trampoline for aarch64
that was fixed once noticed. In other cases I've just
provided evidence that helped prompt someone that knew
what they were doing to identify an underlying issue,
such as loss of "dirty bits for removing PROT_WRITE on
arm64". These were examples of backtracking from odd
behavior that was observed, sometimes intermittent
behavior.

Classically my FreeBSD activities have been tied to
finding and reporting issues for clang targeting
powerpc64 and powerpc, as well as finding some oddities
somewhat analogous to finding the sp_el0 issue for
aarch64 but in a powerpc-family context. (I started
my FreeBSD activity with old PowerMacs and only later
dealt with other TARGET_ARCH's as well.)

I maintain bootable/usable freeBSD environments (head
based) for (mostly clang based in modern times, even
for the powerpc-family):

amd64 (also used for cross buildworld buildkernel)
powerpc64
powerpc
aarch64 (specifically: cortex-a53 examples)
armv6 (specifically: cortext-a7 examples, so armv7)

The variety helps make sure that my activities do not
accidentally mess up building bootable systems for
other FreeBSD contexts. But I've limited that
coverage to environments for which I (sometimes) have
access to native-hardware.

===
Mark Millard
markmi at dsl-only.net

_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Pine64+ 2GB and RPI3 (A64 examples): Any general idea on what/when to expect for the return of USB support to head?

Dustin Marquess
In reply to this post by Mark Millard-2
On a side note, if you revert just that one commit, everything seems
to be working again.  So you could update if you just back out that
one change.

-Dustin

On Tue, Aug 1, 2017 at 4:03 PM, Mark Millard <[hidden email]> wrote:

> [I historically use a ufs USB SSD for a (head) root file
> system on a Pine64+ 2GB and a RPI3. Thus the question
> below.]
>
> Context for question (note the "USB not working for now"
> in the Log Message):
>
>> Revision 320612
>>
>> Author:
>> manu
>> Date:
>> Mon Jul 3 19:30:03 2017 UTC (4 weeks, 1 day ago)
>> Changed paths:
>> 5
>> Log Message:
>> allwinner: Add A64 ccung support
>>
>> Upstream DTS for A64 SoC doesn't provide a /clocks node as Linux switched
>> to ccu-ng
>> This commit adds the necessary bits to boot on pine64 with latest DTS from
>> upstream.
>> USB is not working for now and some node aren't present in the DTS (like the
>> PMU, Power Management Unit).
>>
>> Tested on: Pine64
>>
>> Changed paths
>> Path
>> Details
>> head/sys/arm/allwinner/a10_mmc.c
>> modified , text changed
>> head/sys/arm/allwinner/clkng/aw_ccung.c
>> modified , text changed
>> head/sys/arm/allwinner/clkng/ccu_a64.c
>> added
>> head/sys/arm/allwinner/clkng/ccu_a64.h
>> added
>> head/sys/conf/files.arm64
>> modified , text changed
>
> /head/sys/arm/allwinner/clkng/ccu_a64.c shows an
> empty "USBPHY clk sel" section:
>
> 553     /* USBPHY clk sel */
> 554
> 555     /* DRAM needs update bit */
>
> tending to confirm the log message.
>
>
> The questions:
>
> Does anyone have a general idea that they can report for
> what/when to expect for the return of USB support for
> Pine64+ 2GB, RPI3, and the like A64 based contexts?
>
> Should I just ignore updating the Pine64+ 2GB and RPI3 for
> a few months more? (Because I do self-hosted builds on them
> I want the USB file system to be used for such activity.)
>
>
> ===
> Mark Millard
> markmi at dsl-only.net
>
> _______________________________________________
> [hidden email] mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-arm
> To unsubscribe, send any mail to "[hidden email]"
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Pine64+ 2GB and RPI3 (A64 examples): Any general idea on what/when to expect for the return of USB support to head?

Henri Hennebert
In reply to this post by Emmanuel Vadot-7
On 08/02/2017 21:06, Emmanuel Vadot wrote:

> On Tue, 1 Aug 2017 14:03:23 -0700
> Mark Millard <[hidden email]> wrote:
>
>> [I historically use a ufs USB SSD for a (head) root file
>> system on a Pine64+ 2GB and a RPI3. Thus the question
>> below.]
>>
>> Context for question (note the "USB not working for now"
>> in the Log Message):
>>
>>> Revision 320612
>>>
>>> Author:
>>> manu
>>> Date:
>>> Mon Jul 3 19:30:03 2017 UTC (4 weeks, 1 day ago)
>>> Changed paths:
>>> 5
>>> Log Message:
>>> allwinner: Add A64 ccung support
>>>
>>> Upstream DTS for A64 SoC doesn't provide a /clocks node as Linux switched
>>> to ccu-ng
>>> This commit adds the necessary bits to boot on pine64 with latest DTS from
>>> upstream.
>>> USB is not working for now and some node aren't present in the DTS (like the
>>> PMU, Power Management Unit).
>>>
>>> Tested on: Pine64
>>>
>>> Changed paths
>>> Path
>>> Details
>>> head/sys/arm/allwinner/a10_mmc.c
>>> modified , text changed
>>> head/sys/arm/allwinner/clkng/aw_ccung.c
>>> modified , text changed
>>> head/sys/arm/allwinner/clkng/ccu_a64.c
>>> added
>>> head/sys/arm/allwinner/clkng/ccu_a64.h
>>> added
>>> head/sys/conf/files.arm64
>>> modified , text changed
>>
>> /head/sys/arm/allwinner/clkng/ccu_a64.c shows an
>> empty "USBPHY clk sel" section:
>>
>> 553 /* USBPHY clk sel */
>> 554
>> 555 /* DRAM needs update bit */
>>
>> tending to confirm the log message.
>
>   This is unrelated, this was a comment I've put during developement to
> remind me to add the gate bits for usb.
>   I'll remove it.
>
>>
>> The questions:
>>
>> Does anyone have a general idea that they can report for
>> what/when to expect for the return of USB support for
>> Pine64+ 2GB, RPI3, and the like A64 based contexts?
>
>   I'm the only one who could have an idea (for Pine64) and I don't know.

If it can help, I succeed at least one time to boot r321003 and have the
APs released. Then it detect my usb hub and mount a root on zfs from my
usb disk.

For now, the APs not started is the only problem I encounter with PINE64+

I try r321776 but the APs not started is still present.

Henri
>
>> Should I just ignore updating the Pine64+ 2GB and RPI3 for
>> a few months more? (Because I do self-hosted builds on them
>> I want the USB file system to be used for such activity.)
>
>   You can do whatever you want, either ignore or help.
>
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Pine64+ 2GB and RPI3 (A64 examples): Any general idea on what/when to expect for the return of USB support to head?

Henri Hennebert
In reply to this post by Emmanuel Vadot-7
On 08/02/2017 21:06, Emmanuel Vadot wrote:

> On Tue, 1 Aug 2017 14:03:23 -0700
> Mark Millard <[hidden email]> wrote:
>
>> [I historically use a ufs USB SSD for a (head) root file
>> system on a Pine64+ 2GB and a RPI3. Thus the question
>> below.]
>>
>> Context for question (note the "USB not working for now"
>> in the Log Message):
>>
>>> Revision 320612
>>>
>>> Author:
>>> manu
>>> Date:
>>> Mon Jul 3 19:30:03 2017 UTC (4 weeks, 1 day ago)
>>> Changed paths:
>>> 5
>>> Log Message:
>>> allwinner: Add A64 ccung support
>>>
>>> Upstream DTS for A64 SoC doesn't provide a /clocks node as Linux switched
>>> to ccu-ng
>>> This commit adds the necessary bits to boot on pine64 with latest DTS from
>>> upstream.
>>> USB is not working for now and some node aren't present in the DTS (like the
>>> PMU, Power Management Unit).
>>>
>>> Tested on: Pine64
>>>
>>> Changed paths
>>> Path
>>> Details
>>> head/sys/arm/allwinner/a10_mmc.c
>>> modified , text changed
>>> head/sys/arm/allwinner/clkng/aw_ccung.c
>>> modified , text changed
>>> head/sys/arm/allwinner/clkng/ccu_a64.c
>>> added
>>> head/sys/arm/allwinner/clkng/ccu_a64.h
>>> added
>>> head/sys/conf/files.arm64
>>> modified , text changed
>>
>> /head/sys/arm/allwinner/clkng/ccu_a64.c shows an
>> empty "USBPHY clk sel" section:
>>
>> 553 /* USBPHY clk sel */
>> 554
>> 555 /* DRAM needs update bit */
>>
>> tending to confirm the log message.
>
>   This is unrelated, this was a comment I've put during developement to
> remind me to add the gate bits for usb.
>   I'll remove it.
>
>>
>> The questions:
>>
>> Does anyone have a general idea that they can report for
>> what/when to expect for the return of USB support for
>> Pine64+ 2GB, RPI3, and the like A64 based contexts?
>
>   I'm the only one who could have an idea (for Pine64) and I don't know.

Today I build GENERIC-NODEBUG r321776. I install it on the mmcsd and reboot:

[root@norquay ~]# shutdown -r now
Shutdown NOW!
shutdown: [pid 13227]
[root@norquay ~]#

*** FINAL System shutdown message from [hidden email] ***


System going down IMMEDIATELY


 

--- clip ---

Waiting (max 60 seconds) for system process `vnlru' to stop... done
Waiting (max 60 seconds) for system process `bufdaemon' to stop... done
Waiting (max 60 seconds) for system process `syncer' to stop...
Syncing disks, vnodes remaining... 0 0 0 0 0 0 done
All buffers synced.
Uptime: 20h44m6s
GEOM_MIRROR: Device swap: provider destroyed.
GEOM_MIRROR: Device swap destroyed.
HELLO! BOOT0 is starting!
boot0 commit : 045061a8bb2580cb3fa02e301f52a015040c158f

boot0 version : 4.0.0
set pll start
set pll end
rtc[0] value = 0x00000000
rtc[1] value = 0x00000000
rtc[2] value = 0x00000000
rtc[3] value = 0x00000000
rtc[4] value = 0x00000000
rtc[5] value = 0x00000000
DRAM driver version: V1.1
rsb_send_initseq: rsb clk 400Khz -> 3Mhz
PMU: AXP81X
ddr voltage = 1500 mv
DRAM Type = 3 (2:DDR2,3:DDR3,6:LPDDR2,7:LPDDR3)
DRAM clk = 672 MHz
DRAM zq value: 003b3bbb
DRAM single rank full DQ OK
DRAM size = 2048 MB
DRAM init ok
dram size =2048
card boot number = 0, boot0 copy = 0
card no is 0
sdcard 0 line count 4
[mmc]: mmc driver ver 2015-05-08 20:06
[mmc]: sdc0 spd mode error, 2
[mmc]: Wrong media type 0x00000000
[mmc]: ***Try SD card 0***
[mmc]: HSSDR52/SDR25 4 bit
[mmc]: 50000000 Hz
[mmc]: 15193 MB
[mmc]: ***SD/MMC 0 init OK!!!***
sdcard 0 init ok
The size of uboot is 0007a000.
sum=27054d7f
src_sum=27054d7f
Succeed in loading uboot from sdmmc flash.
boot0: start load other image
boot0: Loading BL3-1
Loading file 0 at address 0x40000000,size 0x0005ec00 success
boot0: Loading scp
Loading file 2 at address 0x00040000,size 0x00019a00 success
set arisc reset to de-assert state
Ready to disable icache.
Jump to secend Boot.
INFO:    Configuring SPC Controller
NOTICE:  BL3-1: v1.0(debug):
NOTICE:  BL3-1: Built : 20:53:17, Jan 12 2017
NOTICE:  BL3-1 commit: 8
INFO:    BL3-1: Initializing runtime services
INFO:    BL3-1: arisc probe
[SCP] :sunxi-arisc driver begin startup 2
[SCP] :arisc_para size:1a8
[SCP] :arisc version: [v0.1.76]
[SCP] :sunxi-arisc driver v1.10 is starting

 >> FreeBSD EFI boot block
    Loader path: /boot/loader.efi

    Initializing modules: ZFS UFS
    Probing 3 block devices.....* done
     ZFS found no pools
     UFS found 1 partition
Consoles: EFI console
Command line arguments: loader.efi
Image base: 0xb8dc5000
EFI version: 2.05
EFI Firmware: Das U-boot (rev 0.00)

FreeBSD/arm64 EFI loader, Revision 1.1
(Tue Jul 25 03:58:20 CEST 2017 [hidden email])
EFI boot environment
Loading /boot/defaults/loader.conf
/boot/kernel/kernel text=0x7c33a0 data=0xa2980+0x39d0de
syms=[0x8+0x106a88+0x8+0xfb330]
/boot/entropy size=0x1000
/boot/kernel/zfs.ko text=0x7a418 text=0xdc3b0 data=0x11528+0x9e970
syms=[0x8+0x1ddd8+0x8+0x18d38]
/boot/kernel/opensolaris.ko text=0x1358 text=0xd90 data=0x10160+0x125d0
syms=[0x8+0x1020+0x8+0x8ca]

Hit [Enter] to boot immediately, or any other key for command prompt.


Type '?' for a list of commands, 'help' for more detailed help.
OK unload
OK load /boot/kernel/kernel
/boot/kernel/kernel text=0x7c33a0 data=0xa2980+0x39d0de
syms=[0x8+0x106a88+0x8+0xfb330]
OK boot -s
Booting...
Using DTB provided by EFI at 0x49000000.
KDB: debugger backends: ddb
KDB: current backend: ddb
Copyright (c) 1992-2017 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 12.0-CURRENT #0 r321776M: Thu Aug  3 10:40:36 CEST 2017
     [hidden email]:/usr/obj/usr/src/sys/GENERIC-NODEBUG arm64
FreeBSD clang version 5.0.0 (trunk 308421) (based on LLVM 5.0.0svn)
VT: init without driver.
Starting CPU 1 (1)
Starting CPU 2 (2)
Starting CPU 3 (3)
FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs
arc4random: no preloaded entropy cache
random: entropy device external interface
kbd0 at kbdmux0
ofwbus0: <Open Firmware Device Tree>
aw_ccu0: <Allwinner Clock Control Unit> on ofwbus0
clk_fixed0: <Fixed clock> on aw_ccu0
clk_fixed1: <Fixed clock> on aw_ccu0
aw_pll0: <Allwinner PLL Clock> mem 0x1c20000-0x1c20003 on aw_ccu0
aw_pll1: <Allwinner PLL Clock> mem 0x1c20028-0x1c2002b on aw_ccu0
clk_fixed2: <Fixed factor clock> on aw_ccu0
aw_pll2: <Allwinner PLL Clock> mem 0x1c2002c-0x1c2002f on aw_ccu0
aw_cpuclk0: <Allwinner CPU Clock> mem 0x1c20050-0x1c20053 on aw_ccu0
aw_axiclk0: <Allwinner AXI Clock> mem 0x1c20050-0x1c20053 on aw_ccu0
aw_ahbclk0: <Allwinner AHB Clock> mem 0x1c20054-0x1c20057 on aw_ccu0
aw_ahbclk1: <Allwinner AHB Clock> mem 0x1c2005c-0x1c2005f on aw_ccu0
aw_apbclk0: <Allwinner APB Clock> mem 0x1c20054-0x1c20057 on aw_ccu0
aw_apbclk1: <Allwinner APB Clock> mem 0x1c20058-0x1c2005b on aw_ccu0
aw_gate0: <Allwinner Multi Bus Clock Gates> mem 0x1c20060-0x1c20073 on
aw_ccu0
aw_modclk0: <Allwinner Module Clock> mem 0x1c20088-0x1c2008b on aw_ccu0
aw_modclk1: <Allwinner Module Clock> mem 0x1c2008c-0x1c2008f on aw_ccu0
aw_modclk2: <Allwinner Module Clock> mem 0x1c20090-0x1c20093 on aw_ccu0
aw_pll3: <Allwinner PLL Clock> mem 0x1c20044-0x1c20047 on aw_ccu0
aw_usbclk0: <Allwinner USB Clocks> mem 0x1c200cc-0x1c200cf on aw_ccu0
aw_thsclk0: <Allwinner THS Clock> mem 0x1c20074-0x1c20077 on aw_ccu0
simplebus0: <Flattened device tree simple bus> on ofwbus0
aw_reset0: <Allwinner Module Resets> mem 0x1c202c0-0x1c202cb on simplebus0
aw_reset1: <Allwinner Module Resets> mem 0x1c202d0-0x1c202d3 on simplebus0
aw_reset2: <Allwinner Module Resets> mem 0x1c202d8-0x1c202db on simplebus0
iichb0: <Allwinner Integrated I2C Bus Controller> mem
0x1c2b000-0x1c2b3ff irq 19 on simplebus0
iicbus0: <OFW I2C bus> on iichb0
regfix0: <Fixed Regulator> on simplebus0
psci0: <ARM Power State Co-ordination Interface Driver> on ofwbus0
aw_sid0: <Allwinner Secure ID Controller> mem 0x1c14000-0x1c143ff on
simplebus0
iichb1: <Allwinner RSB> mem 0x1f03400-0x1f037ff irq 24 on simplebus0
iicbus1: <OFW I2C bus> on iichb1
awusbphy0: <Allwinner USB PHY> mem
0x1c19400-0x1c19423,0x1c1a800-0x1c1a803,0x1c1b800-0x1c1b803 on simplebus0
gic0: <ARM Generic Interrupt Controller> mem
0x1c81000-0x1c81fff,0x1c82000-0x1c83fff,0x1c84000-0x1c85fff,0x1c86000-0x1c87fff
irq 0 0
gic0: pn 0x2, arch 0x2, rev 0x1, implementer 0x43b irqs 224
gpio0: <Allwinner GPIO/Pinmux controller> mem 0x1c20800-0x1c20bff irq
8,9,10 on simplebus0
gpiobus0: <OFW GPIO bus> on gpio0
aw_nmi0: <Allwinner NMI Controller> mem 0x1f00c0c-0x1f00c43 irq 23 on
simplebus0
axp81x_pmu0: <X-Powers AXP81x Power Management Unit> at addr 0x746 irq
30 on iicbus1
gpiobus1: <OFW GPIO bus> on axp81x_pmu0
generic_timer0: <ARMv8 Generic Timer> irq 1,2,3,4 on ofwbus0
Timecounter "ARM MPCore Timecounter" frequency 24000000 Hz quality 1000
Event timer "ARM MPCore Eventtimer" frequency 24000000 Hz quality 1000
rtc0: <Allwinner RTC> mem 0x1f00000-0x1f00053 irq 16,17 on simplebus0
rtc0: registered as a time-of-day clock, resolution 1.000000s
cpulist0: <Open Firmware CPU Group> on ofwbus0
cpu0: <Open Firmware CPU> on cpulist0
cpufreq_dt0: <Generic cpufreq driver> on cpu0
cpu1: <Open Firmware CPU> on cpulist0
cpu2: <Open Firmware CPU> on cpulist0
cpu3: <Open Firmware CPU> on cpulist0
a10_mmc0: <Allwinner Integrated MMC/SD controller> mem
0x1c0f000-0x1c0ffff irq 5 on simplebus0
mmc0: <MMC/SD bus> on a10_mmc0
gpioc0: <GPIO controller> on gpio0
uart0: <16750 or compatible> mem 0x1c28000-0x1c283ff irq 11 on simplebus0
uart0: console (115384,n,8,1)
iic0: <I2C generic I/O> on iicbus0
awg0: <Allwinner Gigabit Ethernet> mem
0x1c30000-0x1c300ff,0x1c00030-0x1c00033 irq 21 on simplebus0
miibus0: <MII bus> on awg0
rgephy0: <RTL8169S/8110S/8211 1000BASE-T media interface> PHY 0 on miibus0
rgephy0:  none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX,
100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, w
rgephy1: <RTL8169S/8110S/8211 1000BASE-T media interface> PHY 1 on miibus0
rgephy1:  none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX,
100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, w
awg0: Ethernet address: 02:ba:4c:17:07:8b
aw_wdog0: <Allwinner A31 Watchdog> mem 0x1c20ca0-0x1c20cbf irq 22 on
simplebus0
gpioc1: <GPIO controller> on axp81x_pmu0
iic1: <I2C generic I/O> on iicbus1
aw_thermal0: <Allwinner Thermal Sensor Controller> mem
0x1c25000-0x1c253ff irq 25 on simplebus0
ohci0: <Generic OHCI Controller> mem 0x1c1a400-0x1c1a4ff irq 26 on
simplebus0
usbus0 on ohci0
ehci0: <Allwinner Integrated USB 2.0 controller> mem 0x1c1a000-0x1c1a0ff
irq 27 on simplebus0
usbus1: EHCI version 1.0
usbus1 on ehci0
ohci1: <Generic OHCI Controller> mem 0x1c1b400-0x1c1b4ff irq 28 on
simplebus0
usbus2 on ohci1
ehci1: <Allwinner Integrated USB 2.0 controller> mem 0x1c1b000-0x1c1b0ff
irq 29 on simplebus0
usbus3: EHCI version 1.0
usbus3 on ehci1
cryptosoft0: <software crypto>
Timecounters tick every 1.000 msec
usbus0: 12Mbps Full Speed USB v1.0
usbus1: 480Mbps High Speed USB v2.0
usbus2: 12Mbps Full Speed USB v1.0
usbus3: 480Mbps High Speed USB v2.0
ugen0.1: <Generic OHCI root HUB> at usbus0
uhub0: <Generic OHCI root HUB, class 9/0, rev 1.00/1.00, addr 1> on usbus0
ugen1.1: <Allwinner EHCI root HUB> at usbus1
uhub1: <Allwinner EHCI root HUB, class 9/0, rev 2.00/1.00, addr 1> on usbus1
ugen2.1: <Generic OHCI root HUB> at usbus2
uhub2: <Generic OHCI root HUB, class 9/0, rev 1.00/1.00, addr 1> on usbus2
ugen3.1: <Allwinner EHCI root HUB> at usbus3
uhub3: <Allwinner EHCI root HUB, class 9/0, rev 2.00/1.00, addr 1> on usbus3
mmcsd0: 16GB <SDHC SL16G 8.0 SN A9A41D45 MFG 03/2017 by 3 SD> at mmc0
50.0MHz/4bit/65535-block
Release APs
CPU  0: ARM Cortex-A53 r0p4 affinity:  0
  Instruction Set Attributes 0 = <AES+PMULL,SHA1,SHA2,CRC32>
  Instruction Set Attributes 1 = <0>
          Processor Features 0 = <AdvSIMD,Float,EL3 32,EL2 32,EL1 32,EL0 32>
          Processor Features 1 = <0>
       Memory Model Features 0 = <4k Granule,64k
Granule,MixedEndian,S/NS Mem,16bit ASID,1TB PA>
       Memory Model Features 1 = <>
              Debug Features 0 = <2 CTX Breakpoints,4 Watchpoints,6
Breakpoints,PMUv3,Debug v8>
              Debug Features 1 = <0>
          Auxiliary Features 0 = <0>
          Auxiliary Features 1 = <0>
CPU  1: ARM Cortex-A53 r0p4 affinity:  1
CPU  2: ARM Cortex-A53 r0p4 affinity:  2
CPU  3: ARM Cortex-A53 r0p4 affinity:  3
arc4random: no preloaded entropy cache
Trying to mount root from zfs:rpool/ROOT/default [rw,noatime]...
Mounting from zfs:rpool/ROOT/default failed with error 2: unknown file
system.
uhub0: 1 port with 1 removable, self powered
uhub2: 1 port with 1 removable, self powered
Root mount waiting for: usbus3 usbus1
uhub1: 1 port with 1 removable, self powered
uhub3: 1 port with 1 removable, self powered
ugen3.2: <VIA Labs, Inc. USB2.0 Hub> at usbus3
uhub4 on uhub3
uhub4: <VIA Labs, Inc. USB2.0 Hub, class 9/0, rev 2.10/b.e0, addr 2> on
usbus3
Root mount waiting for: usbus3
uhub4: 4 ports with 4 removable, self powered
Root mount waiting for: usbus3
Root mount waiting for: usbus3
ugen3.3: <Western Digital Elements 25A2> at usbus3
umass0 on uhub4
umass0: <Western Digital Elements 25A2, class 0/0, rev 2.10/10.14, addr
3> on usbus3
umass0:  SCSI over Bulk-Only; quirks = 0x8100
umass0:0:0: Attached to scbus0
da0 at umass-sim0 bus 0 scbus0 target 0 lun 0
da0: <WD Elements 25A2 1014> Fixed Direct Access SPC-4 SCSI device
da0: Serial Number 57583831453636343533344D
da0: 40.000MB/s transfers
da0: 476908MB (976707584 512 byte sectors)
da0: quirks=0x2<NO_6_BYTE>
ugen3.4: <Western Digital Elements 25A2> at usbus3
umass1 on uhub4
umass1: <Western Digital Elements 25A2, class 0/0, rev 2.10/10.14, addr
4> on usbus3
umass1:  SCSI over Bulk-Only; quirks = 0x8100
umass1:1:1: Attached to scbus1
da1 at umass-sim1 bus 1 scbus1 target 0 lun 0
da1: <WD Elements 25A2 1014> Fixed Direct Access SPC-4 SCSI device
da1: Serial Number 575857314141364346534839
da1: 40.000MB/s transfers
da1: 476908MB (976707584 512 byte sectors)
da1: quirks=0x2<NO_6_BYTE>

(da0:umass-sim0:0:0:0): READ(10). CDB: 28 00 3a 37 5f ff 00 00 01 00

(da0:umass-sim0:0:0:0): CAM status: CCB request completed with an error

(da0:umass-sim0:0:0:0): Retrying command

 

Loader variables:

   vfs.root.mountfrom=zfs:rpool/ROOT/default

   vfs.root.mountfrom.options=rw,noatime

 

Manual root filesystem specification:

   <fstype>:<device> [options]

       Mount <device> using filesystem <fstype>

       and with the specified (optional) option list.

 

     eg. ufs:/dev/da0s1a

         zfs:tank

         cd9660:/dev/cd0 ro

           (which is equivalent to: mount -t cd9660 -o ro /dev/cd0 /)

 

   ?               List valid disk boot devices
   .               Yield 1 second (for background tasks)
   <empty line>    Abort manual input

mountroot> ufs:/dev/mmcsd0s2
Trying to mount root from ufs:/dev/mmcsd0s2 []...
random: unblocking device.
arc4random: no preloaded entropy cache
arc4random: no preloaded entropy cache
Enter full pathname of shell or RETURN for /bin/sh:
#

So USB is working but the 'CCB request completed with an error' prevent
the access to zfs.

Henri

PS

- this error crop up from time to time even with r320599.

- I switch off and on the PINE64+ and GENERIC-NODEBUG encounter the
   APs not started error multiple times.

>
>> Should I just ignore updating the Pine64+ 2GB and RPI3 for
>> a few months more? (Because I do self-hosted builds on them
>> I want the USB file system to be used for such activity.)
>
>   You can do whatever you want, either ignore or help.
>
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Pine64+ 2GB and RPI3 (A64 examples): Any general idea on what/when to expect for the return of USB support to head?

Michael Tuexen-2
In reply to this post by Emmanuel Vadot-7
> On 2. Aug 2017, at 21:06, Emmanuel Vadot <[hidden email]> wrote:

>
> On Tue, 1 Aug 2017 14:03:23 -0700
> Mark Millard <[hidden email]> wrote:
>
>> [I historically use a ufs USB SSD for a (head) root file
>> system on a Pine64+ 2GB and a RPI3. Thus the question
>> below.]
>>
>> Context for question (note the "USB not working for now"
>> in the Log Message):
>>
>>> Revision 320612
>>>
>>> Author:
>>> manu
>>> Date:
>>> Mon Jul 3 19:30:03 2017 UTC (4 weeks, 1 day ago)
>>> Changed paths:
>>> 5
>>> Log Message:
>>> allwinner: Add A64 ccung support
>>>
>>> Upstream DTS for A64 SoC doesn't provide a /clocks node as Linux switched
>>> to ccu-ng
>>> This commit adds the necessary bits to boot on pine64 with latest DTS from
>>> upstream.
>>> USB is not working for now and some node aren't present in the DTS (like the
>>> PMU, Power Management Unit).
>>>
>>> Tested on: Pine64
>>>
>>> Changed paths
>>> Path
>>> Details
>>> head/sys/arm/allwinner/a10_mmc.c
>>> modified , text changed
>>> head/sys/arm/allwinner/clkng/aw_ccung.c
>>> modified , text changed
>>> head/sys/arm/allwinner/clkng/ccu_a64.c
>>> added
>>> head/sys/arm/allwinner/clkng/ccu_a64.h
>>> added
>>> head/sys/conf/files.arm64
>>> modified , text changed
>>
>> /head/sys/arm/allwinner/clkng/ccu_a64.c shows an
>> empty "USBPHY clk sel" section:
>>
>> 553 /* USBPHY clk sel */
>> 554
>> 555 /* DRAM needs update bit */
>>
>> tending to confirm the log message.
>
> This is unrelated, this was a comment I've put during developement to
> remind me to add the gate bits for usb.
> I'll remove it.
>
>>
>> The questions:
>>
>> Does anyone have a general idea that they can report for
>> what/when to expect for the return of USB support for
>> Pine64+ 2GB, RPI3, and the like A64 based contexts?
>
> I'm the only one who could have an idea (for Pine64) and I don't know.
Just to get a clear understanding of the current situation:
Is this related to problem where an RPI3 without ZFS, not using a
USB storage device, can't boot with the "APs not being started"?

Should I be able to get a bootable RPI3 back when locally reverting r320612?
Just to be crystal clear: I'm only interested in a RPI3, not the allwinner
device.

Best regards
Michael

>
>> Should I just ignore updating the Pine64+ 2GB and RPI3 for
>> a few months more? (Because I do self-hosted builds on them
>> I want the USB file system to be used for such activity.)
>
> You can do whatever you want, either ignore or help.
>
> --
> Emmanuel Vadot <[hidden email]> <[hidden email]>
> _______________________________________________
> [hidden email] mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-arm
> To unsubscribe, send any mail to "[hidden email]"


smime.p7s (7K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Pine64+ 2GB and RPI3 (A64 examples): Any general idea on what/when to expect for the return of USB support to head?

Mark Millard-2
In reply to this post by Mark Millard-2
Michael Tuexen tuexen at fh-muenster.de wrote on
Thu Aug 3 16:13:09 UTC 2017 :

> Just to get a clear understanding of the current situation:
> Is this related to problem where an RPI3 without ZFS, not using a
> USB storage device, can't boot with the "APs not being started"?
>
> Should I be able to get a bootable RPI3 back when locally reverting r320612?
> Just to be crystal clear: I'm only interested in a RPI3, not the allwinner
> device.

I munged up the original submittal by stupidly referencing
RPI3 incorrectly as an A64 example: RPI3 is not based on
an ALLWINNER System On a Chip at all.

I meant to refer to examples of just what soc_allwinner_a64
and

sys/arm/allwinner/a64/

covers. (What I sometimes have access to for that is:
Pine64+ 2GB. I also sometimes have access to an rpi3.)

If I interpret right:

sys/conf/files.arm64

does not suggest soc_allwinner_a64 and RPi3's soc_brcm_bcm2837
sharing the changes made for A64.

Sorry for the confusion.


Note: My Pine64+ 2GB and RPI3 configuration are still back
before the INO64 changes. I've not experimented with updates
yet. Instead I've been trying to first figure out what to
expect and if I should upgrade and what I might be required
to do for the update to be reasonable for me.

So I also am interested in avoiding "APs not being started"
for the RPI3 context.

===
Mark Millard
markmi at dsl-only.net

_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Pine64+ 2GB and RPI3 (A64 examples): Any general idea on what/when to expect for the return of USB support to head?

Mark Millard-2
In reply to this post by Mark Millard-2
Dustin Marquess dmarquess at gmail.com wrote on
Thu Aug 3 01:52:28 UTC 2017 :

> On a side note, if you revert just that one commit, everything seems
> to be working again.  So you could update if you just back out that
> one change.

I assume this was before ports head/sysutils/u-boot-pine64 -r447112
that switched to using head/sysutils/u-boot-master  to build u-boot
for Pine64 variants. I do not know if the new vs. old u-boot mixes
well with the different update-status of the 5 CURRENT-12 files:

sys/arm/allwinner/a10_mmc.c
sys/arm/allwinner/clkng/aw_ccung.c
sys/arm/allwinner/clkng/ccu_a64.c
sys/arm/allwinner/clkng/ccu_a64.h
sys/conf/files.arm64

(for -r320612+ vs. before). For all I know only some of the 4
combinations might be expected to work, not all 4.



Note: My Pine64+ 2GB and RPI3 configuration are still back
before the INO64 changes. I've not experimented with updates
yet. Instead I've been trying to first figure out what to
expect and if I should upgrade and what I might be required
to do for the update to be reasonable for me.

===
Mark Millard
markmi at dsl-only.net

_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Pine64+ 2GB and RPI3 (A64 examples): Any general idea on what/when to expect for the return of USB support to head?

Dustin Marquess
Correct.  I'm using the old U-Boot from was included in the
HardenedBSD Pine64 image from  2017-06-21.

On my RPi3, everything works as-is without backing out anything (also
on HardenedBSD), which seems to be expected since that commit was only
for Allwinner.  Just throwing that out there for the ones asking about
RPi3.

-Dustin

On Thu, Aug 3, 2017 at 11:00 PM, Mark Millard <[hidden email]> wrote:

> Dustin Marquess dmarquess at gmail.com wrote on
> Thu Aug 3 01:52:28 UTC 2017 :
>
>> On a side note, if you revert just that one commit, everything seems
>> to be working again.  So you could update if you just back out that
>> one change.
>
> I assume this was before ports head/sysutils/u-boot-pine64 -r447112
> that switched to using head/sysutils/u-boot-master  to build u-boot
> for Pine64 variants. I do not know if the new vs. old u-boot mixes
> well with the different update-status of the 5 CURRENT-12 files:
>
> sys/arm/allwinner/a10_mmc.c
> sys/arm/allwinner/clkng/aw_ccung.c
> sys/arm/allwinner/clkng/ccu_a64.c
> sys/arm/allwinner/clkng/ccu_a64.h
> sys/conf/files.arm64
>
> (for -r320612+ vs. before). For all I know only some of the 4
> combinations might be expected to work, not all 4.
>
>
>
> Note: My Pine64+ 2GB and RPI3 configuration are still back
> before the INO64 changes. I've not experimented with updates
> yet. Instead I've been trying to first figure out what to
> expect and if I should upgrade and what I might be required
> to do for the update to be reasonable for me.
>
> ===
> Mark Millard
> markmi at dsl-only.net
>
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Pine64+ 2GB and RPI3 (A64 examples): Any general idea on what/when to expect for the return of USB support to head?

Shawn Webb-3
I've uploaded a new build of HardenedBSD for the RPI3 here:

https://hardenedbsd.org/~shawn/rpi3/2017-08-04/HardenedBSD-RaspberryPi3-aarch64-12.0-HARDENEDBSD-e6e174b43590.img.xz

It uses the HARDENEDBSD kernel instead of HARDENEDBSD-NODEBUG. Emmanuel
let me know there's something going on that's only manifest in the
GENERIC-NODEBUG kernel.

Thanks,

Shawn

On Fri, Aug 04, 2017 at 01:28:01AM -0500, Dustin Marquess wrote:

> Correct.  I'm using the old U-Boot from was included in the
> HardenedBSD Pine64 image from  2017-06-21.
>
> On my RPi3, everything works as-is without backing out anything (also
> on HardenedBSD), which seems to be expected since that commit was only
> for Allwinner.  Just throwing that out there for the ones asking about
> RPi3.
>
> -Dustin
>
> On Thu, Aug 3, 2017 at 11:00 PM, Mark Millard <[hidden email]> wrote:
> > Dustin Marquess dmarquess at gmail.com wrote on
> > Thu Aug 3 01:52:28 UTC 2017 :
> >
> >> On a side note, if you revert just that one commit, everything seems
> >> to be working again.  So you could update if you just back out that
> >> one change.
> >
> > I assume this was before ports head/sysutils/u-boot-pine64 -r447112
> > that switched to using head/sysutils/u-boot-master  to build u-boot
> > for Pine64 variants. I do not know if the new vs. old u-boot mixes
> > well with the different update-status of the 5 CURRENT-12 files:
> >
> > sys/arm/allwinner/a10_mmc.c
> > sys/arm/allwinner/clkng/aw_ccung.c
> > sys/arm/allwinner/clkng/ccu_a64.c
> > sys/arm/allwinner/clkng/ccu_a64.h
> > sys/conf/files.arm64
> >
> > (for -r320612+ vs. before). For all I know only some of the 4
> > combinations might be expected to work, not all 4.
> >
> >
> >
> > Note: My Pine64+ 2GB and RPI3 configuration are still back
> > before the INO64 changes. I've not experimented with updates
> > yet. Instead I've been trying to first figure out what to
> > expect and if I should upgrade and what I might be required
> > to do for the update to be reasonable for me.
> >
> > ===
> > Mark Millard
> > markmi at dsl-only.net
> >
> _______________________________________________
> [hidden email] mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-arm
> To unsubscribe, send any mail to "[hidden email]"
--
Shawn Webb
Cofounder and Security Engineer
HardenedBSD

GPG Key ID:          0x6A84658F52456EEE
GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89  3D9E 6A84 658F 5245 6EEE

signature.asc (849 bytes) Download Attachment