Hi,
On Thursday, 05.04.2018 at 15:54, Andre Przywara wrote:
> >> So can you please replace the last line in the olinuxino.dts:
> >>
> >> - usb0_vbus-supply = <®_usb0_vbus>;
> >> + usb0_vbus_power-supply = <®_usb0_vbus>;
> >>
> >> Then you should not need the regulator-always-on hack above.
> >
Hi,
thanks for doing the experiments!
On 05/04/18 14:17, Martin Lucina wrote:
> Hi,
>
> On Thursday, 05.04.2018 at 12:20, Andre Przywara wrote:
>>> [1]
>>> https://github.com/apritzel/linux/blob/f1827ce503ca19e6873847128f86849788cfc7db/arch/arm64/boot/dts/allwinner/sun50i-a64-olinuxino.dts
>>>
>
Hi,
On Thursday, 05.04.2018 at 12:20, Andre Przywara wrote:
> > [1]
> > https://github.com/apritzel/linux/blob/f1827ce503ca19e6873847128f86849788cfc7db/arch/arm64/boot/dts/allwinner/sun50i-a64-olinuxino.dts
> >
> > For reference, I've uploaded a full dmesg of this kernel booting, here:
> > https:
Hi,
On 05/04/18 11:01, Martin Lucina wrote:
> Hi,
>
> On Wednesday, 04.04.2018 at 14:07, Andre Przywara wrote:
>> Ah, interesting, but would make some sense: PG9 is pulled high on the
>> board, so you have to actively drive it *low* to *disable* the power.
>> Do you have some nodes for the WiFi/B
On Wednesday, 04.04.2018 at 14:07, Andre Przywara wrote:
> > When I add that line to ATF I get 5V on the micro-B port after
> > initialisation and it stays powered up even after the kernel has booted.
>
> Good, so that's some confirmation. I recently found that the BananaPi
> M64 uses the very sam
Hi,
On Wednesday, 04.04.2018 at 14:07, Andre Przywara wrote:
> Ah, interesting, but would make some sense: PG9 is pulled high on the
> board, so you have to actively drive it *low* to *disable* the power.
> Do you have some nodes for the WiFi/BT module in the DT? The UART1 CTS
> is also on PG9, an
Hi,
On 04/04/18 10:42, Martin Lucina wrote:
> Hi,
>
> On Thursday, 22.03.2018 at 20:47, André Przywara wrote:
>>> Ok, I just measured both ports (via a cannibalised USB cable + OTG for the
>>> micro-USB) and there's no power on either of them. Cross-checked the
>>> measurement setup against an ol
Hi,
On Thursday, 22.03.2018 at 20:47, André Przywara wrote:
> > Ok, I just measured both ports (via a cannibalised USB cable + OTG for the
> > micro-USB) and there's no power on either of them. Cross-checked the
> > measurement setup against an old Thinkpad to be sure.
One more data point which I
USB works for me. Didn't check before ... but I did add this to ATF. This
is boot log:
http://ix.io/12WM
Dne četrtek, 22. marec 2018 21.48.08 UTC+1 je oseba André Przywara napisala:
>
> Hi,
>
> On 22/03/18 10:45, Martin Lucina wrote:
> > On Tuesday, 20.03.2018 at 11:10, Andre Przywara wrote:
Hi,
On 22/03/18 10:45, Martin Lucina wrote:
> On Tuesday, 20.03.2018 at 11:10, Andre Przywara wrote:
>>> Tried a flash drive in the standard-size USB with these changes, nothing
>>> shows up. Is there an easy way of testing the micro-USB (OTG?) port?
>>
>> Can you try to measure if there is 5V on
Hi,
On 22/03/18 10:45, Martin Lucina wrote:
> Hi,
>
> On Tuesday, 20.03.2018 at 11:10, Andre Przywara wrote:
>>> Tried a flash drive in the standard-size USB with these changes, nothing
>>> shows up. Is there an easy way of testing the micro-USB (OTG?) port?
>>
>> Can you try to measure if there
Hi,
On Tuesday, 20.03.2018 at 11:10, Andre Przywara wrote:
> > Tried a flash drive in the standard-size USB with these changes, nothing
> > shows up. Is there an easy way of testing the micro-USB (OTG?) port?
>
> Can you try to measure if there is 5V on the outer pins of the USB socket?
>
> For
Hi,
On 20/03/18 10:42, Martin Lucina wrote:
> Hi,
>
> On Monday, 19.03.2018 at 17:50, Martin Lucina wrote:
>> Hi,
>>
>> On Monday, 19.03.2018 at 16:06, Andre Przywara wrote:
>>> Can you add:
>>> dr_mode = "otg";
>>> to the usb_otg node?
>>> According to the generic binding doc this should be t
Hi,
On Monday, 19.03.2018 at 17:50, Martin Lucina wrote:
> Hi,
>
> On Monday, 19.03.2018 at 16:06, Andre Przywara wrote:
> > Can you add:
> > dr_mode = "otg";
> > to the usb_otg node?
> > According to the generic binding doc this should be the default if not
> > specified, but the sunxi-musb
Hi,
On Monday, 19.03.2018 at 16:06, Andre Przywara wrote:
> Can you add:
> dr_mode = "otg";
> to the usb_otg node?
> According to the generic binding doc this should be the default if not
> specified, but the sunxi-musb driver requires this property, explicitly.
That stops the error -22 and
Hi,
On 19/03/18 15:25, Martin Lucina wrote:
> Hi,
>
> On Monday, 19.03.2018 at 11:59, Andre Przywara wrote:
>>> Any ideas on what I need to do to get working Ethernet based on the other
>>> information I sent last week? Or at least USB -- might that work with just
>>> the relevant bits from the P
Hi,
On Monday, 19.03.2018 at 11:59, Andre Przywara wrote:
> > Any ideas on what I need to do to get working Ethernet based on the other
> > information I sent last week? Or at least USB -- might that work with just
> > the relevant bits from the Pine64 DTB? If so, which ones?
>
> I pushed a branc
Hi,
On 19/03/18 10:44, Martin Lucina wrote:
> Hi,
>
> On Monday, 19.03.2018 at 10:38, Andre Przywara wrote:
>>> I've given the SPL you put together a go and left a comment in the Github
>>> issue [1]. To keep the information also in this thread, in summary, the
>>> PMIC setup on a warm boot appea
Hi,
On Monday, 19.03.2018 at 10:38, Andre Przywara wrote:
> > I've given the SPL you put together a go and left a comment in the Github
> > issue [1]. To keep the information also in this thread, in summary, the
> > PMIC setup on a warm boot appears to succeed but the reported DRAM voltage
> > is
Hi,
On 19/03/18 10:12, Martin Lucina wrote:
> Hi,
>
> On Friday, 16.03.2018 at 10:36, Andre Przywara wrote:
>> So I looked at this a64-olinuxino.dts you referenced in that other mail,
>> which has those values spelt out in the "dram" node. Interestingly they
>> are somewhat different from the val
Hi,
On Friday, 16.03.2018 at 10:36, Andre Przywara wrote:
> So I looked at this a64-olinuxino.dts you referenced in that other mail,
> which has those values spelt out in the "dram" node. Interestingly they
> are somewhat different from the values in this boot0, also different
> from the values us
Hi,
On 15/03/18 14:26, Martin Lucina wrote:
> Hi,
>
> On Thursday, 15.03.2018 at 13:52, Andre Przywara wrote:
>>> Still running at 648 Mhz and haven't seen the BUG again, but am only
>>> moderately loading the board with building and running self-tests for the
>>> project I'm working on [1] out o
Hi,
On Thursday, 15.03.2018 at 15:22, Andre Przywara wrote:
> Briefly - while compiling ;-) - looked at the schematics. There is a
> jumper (PHYRST1) that needs to be empty, also PD24 must not be tied low.
> PD14 is used for that on the Pine64, and so far we get away with doing
> nothing there. Th
Hi,
On 15/03/18 13:42, Martin Lucina wrote:
> On Thursday, 15.03.2018 at 11:47, Andre Przywara wrote:
>>> You did mention that only the kernel DTBs see the Ethernet device,
>>> so with U-boot 2018.83 I the "No ethernet found" is expected?
>>
>> Not really, the U-Boot .dtbs should always work with
Hi,
On Thursday, 15.03.2018 at 13:52, Andre Przywara wrote:
> > Still running at 648 Mhz and haven't seen the BUG again, but am only
> > moderately loading the board with building and running self-tests for the
> > project I'm working on [1] out of tmpfs.
Running for an hour or so now and "BUG: b
Hi,
On 15/03/18 13:42, Martin Lucina wrote:
> On Thursday, 15.03.2018 at 11:47, Andre Przywara wrote:
>>> You did mention that only the kernel DTBs see the Ethernet device,
>>> so with U-boot 2018.83 I the "No ethernet found" is expected?
>>
>> Not really, the U-Boot .dtbs should always work with
Hi,
On 15/03/18 13:40, Martin Lucina wrote:
> Hi,
>
> On Thursday, 15.03.2018 at 11:43, Andre Przywara wrote:
>>> 648 MHz seems to have helped a lot, I've done several warm and cold boots
>>> and only seen the BUG once so far. Will try lowering the frequency further
>>
>> Cool! I see other Allwin
On Thursday, 15.03.2018 at 11:47, Andre Przywara wrote:
> > You did mention that only the kernel DTBs see the Ethernet device,
> > so with U-boot 2018.83 I the "No ethernet found" is expected?
>
> Not really, the U-Boot .dtbs should always work with U-Boot's Ethernet
> driver. What doesn't work at
On Thursday, 15.03.2018 at 14:40, Martin Lucina wrote:
> Still running at 648 Mhz and haven't seen the BUG again, but am only
> moderately loading the board with building and running self-tests for the
> project I'm working on [1] out of tmpfs.
[1] https://github.com/Solo5/solo5
-mato
--
You re
Hi,
On Thursday, 15.03.2018 at 11:43, Andre Przywara wrote:
> > 648 MHz seems to have helped a lot, I've done several warm and cold boots
> > and only seen the BUG once so far. Will try lowering the frequency further
>
> Cool! I see other Allwinner boards using 624 MHz, so that might be a
> sweet
Hi,
On 15/03/18 11:27, Martin Lucina wrote:
> Hi,
>
> On Thursday, 15.03.2018 at 09:23, Andre Przywara wrote:
>> Yeah, I think I need to remove the molly guards in ATF when setting up
>> the PMIC. The code checks whether the PMIC registers it touches contain
>> certain values, to make sure it is
Hi,
On 15/03/18 11:24, Martin Lucina wrote:
> Hi,
>
> On Thursday, 15.03.2018 at 09:34, Andre Przywara wrote:
>> So that might be a DRAM issue then.
>> Can you try to lower the frequency?
>> Just set CONFIG_DRAM_CLK in your U-Boot .config (or _defconfig) to 648
>> for a start, or try lower values
Hi,
On Thursday, 15.03.2018 at 09:23, Andre Przywara wrote:
> Yeah, I think I need to remove the molly guards in ATF when setting up
> the PMIC. The code checks whether the PMIC registers it touches contain
> certain values, to make sure it is in a sensible state.
> Now with Linux driving the PMIC
Hi,
On Thursday, 15.03.2018 at 09:34, Andre Przywara wrote:
> So that might be a DRAM issue then.
> Can you try to lower the frequency?
> Just set CONFIG_DRAM_CLK in your U-Boot .config (or _defconfig) to 648
> for a start, or try lower values in 24MHz steps. The default value for
> A64 boards is
Hi,
On 14/03/18 22:06, Martin Lucina wrote:
> On Wednesday, 14.03.2018 at 16:09, Martin Lucina wrote:
>> On Wednesday, 14.03.2018 at 15:51, Martin Lucina wrote:
>>> I've now done a full cross debootstrap on the host to work around the
>>> kernel BUG, adding the kernel modules from 4.16-rc5 manuall
Hi,
On 14/03/18 14:51, Martin Lucina wrote:
> On Tuesday, 13.03.2018 at 17:52, Andre Przywara wrote:
>> For now I would take the one from the kernel, if you care about
>> Ethernet. However I will soon resend a DT update series which would
>> allow you to use $fdtcontroladdr.
>
> I've now done a f
On Wednesday, 14.03.2018 at 16:09, Martin Lucina wrote:
> On Wednesday, 14.03.2018 at 15:51, Martin Lucina wrote:
> > I've now done a full cross debootstrap on the host to work around the
> > kernel BUG, adding the kernel modules from 4.16-rc5 manually to the rootfs.
> > Interestingly, U-boot or th
On Wednesday, 14.03.2018 at 15:51, Martin Lucina wrote:
> I've now done a full cross debootstrap on the host to work around the
> kernel BUG, adding the kernel modules from 4.16-rc5 manually to the rootfs.
> Interestingly, U-boot or the kernel don't seem to see the ethernet device
> at all. Also, t
On Tuesday, 13.03.2018 at 17:52, Andre Przywara wrote:
> For now I would take the one from the kernel, if you care about
> Ethernet. However I will soon resend a DT update series which would
> allow you to use $fdtcontroladdr.
I've now done a full cross debootstrap on the host to work around the
k
On Wed, Mar 14, 2018 at 12:52:22PM +0100, Martin Lucina wrote:
> On Wednesday, 14.03.2018 at 00:45, 'Ondřej Jirman' via linux-sunxi wrote:
> > On Tue, Mar 13, 2018 at 08:20:35PM +0100, Martin Lucina wrote:
> > > Hi,
> > >
> > > > > However, while running the debootstrap 2nd stage on the board, it
On Wednesday, 14.03.2018 at 00:45, 'Ondřej Jirman' via linux-sunxi wrote:
> On Tue, Mar 13, 2018 at 08:20:35PM +0100, Martin Lucina wrote:
> > Hi,
> >
> > > > However, while running the debootstrap 2nd stage on the board, it seems
> > > > that
> > > > the kernel is not stable:
> > >
> > > Anothe
On Tue, Mar 13, 2018 at 08:20:35PM +0100, Martin Lucina wrote:
> Hi,
>
> > > However, while running the debootstrap 2nd stage on the board, it seems
> > > that
> > > the kernel is not stable:
> >
> > Another thing to check if you are seeing stability issues is the power
> > supply (including cab
Hi,
On Tuesday, 13.03.2018 at 17:52, Andre Przywara wrote:
> > setenv bootargs console=ttyS0,115200 root=/dev/mmcblk0p2 rootwait
> > panic=10
> > load mmc 0:1 0x4300 dtb
> > load mmc 0:1 0x4100 Image
> > booti 0x4100 - 0x4300
>
> Please don't use those old values from th
Hi,
On 13/03/18 14:18, Martin Lucina wrote:
> Hi,
>
> I'm trying to bootstrap Debian on an Olimex A64-OLinuXino board from
> scratch with mainline U-boot and kernel, using Debian stretch on x86_64 as
> the build host. For reference, here is the procedure I'm using:
>
> - cross-built mainline U-b
> So just to make sure it's not a hardware failure, does it work with any
earlier version of Linux? Have you got it working before?
This is a new board, recently purchased from Olimex.
I've not tried any other kernels. The Olimex site only has some torrent with
(according to the docs) an ancie
Martin Lucina:
> Any ideas? This is with U-boot 2018.03 (released a few hours ago) and
> mainline Linux 4.16-rc5.
So just to make sure it's not a hardware failure, does it work with any
earlier version of Linux? Have you got it working before?
Joonas
--
You received this message because you ar
On Tuesday, 13.03.2018 at 17:30, Martin Lucina wrote:
> On Tuesday, 13.03.2018 at 15:18, Martin Lucina wrote:
> > I've now also tried with a 4.16-rc5 kernel and get the same "bad page
> > state" early in the boot process.
> >
> > Are current mainline kernels stable on this board, or do I need some
On Tuesday, 13.03.2018 at 15:18, Martin Lucina wrote:
> I've now also tried with a 4.16-rc5 kernel and get the same "bad page
> state" early in the boot process.
>
> Are current mainline kernels stable on this board, or do I need some extra
> patches? Headless operation is enough for me.
I just
Hi Chris,
On Tuesday, 13.03.2018 at 14:31, Chris Obbard wrote:
> You can do a 2nd stage cross-debootstrap on your host machine.
Right, I just ran it on the board since that seemed simpler (and exposed
the kernel instability).
> Also, you can build DTS as part of Linux make.
I do that, what I do
Hi Martin,
You can do a 2nd stage cross-debootstrap on your host machine.
Also, you can build DTS as part of Linux make.
Where are your Kernel modules?
We (64 Studio) are making a scripted auto-debian image maker, watch
this space :-). If you are interested in helping or have some input
please co
Hi,
I'm trying to bootstrap Debian on an Olimex A64-OLinuXino board from
scratch with mainline U-boot and kernel, using Debian stretch on x86_64 as
the build host. For reference, here is the procedure I'm using:
- cross-built mainline U-boot 2018.01 including the SPL and BL31 from latest
https:
51 matches
Mail list logo