On Sunday 28 July 2019 00:27:36 Reco wrote:
> On Sun, Jul 28, 2019 at 12:13:21AM -0400, Gene Heskett wrote:
> > > > That, and a whole restaraunt sized menu of dpkg stuff for
> > > > building packages is on the missing list. Gr.
> > >
> > > apt install build-essential
> >
> > I *think* I did
On Sun, Jul 28, 2019 at 6:16 PM Rainer Dorsch wrote:
> does anybody know if there is something equivalent to devregs in
>
> https://github.com/boundarydevices/imx-utils
>
> to probe and manipulate the hardware registers in an imx6 for Debian.
It looks like devregs was split out of imx-utils and
Hello again !
Le 26/07/2019 à 22:36, Matthieu CERDA a écrit :
> Le 26/07/2019 à 11:29, Arnaud Patard (Rtp) a écrit :
>> Martin Michlmayr writes:
>>> * Matthieu CERDA [2019-07-26 00:17]:
* On stretch stock kernel (4.9.0-9-marvell), qcontrol does not work:
calling it with
Hi Wookey,
many thanks for your quick and detailed response.
Am Sonntag, 28. Juli 2019, 18:11:34 CEST schrieb Wookey:
> If your ttymxc0 is being found and enabled by the kernel, but not set up by
> the installer, then that's a bug and we should work out why not.
It seems that this is the
On 2019-07-28 17:41 +0200, Rainer Dorsch wrote:
> Hi,
>
> can anybody tell if the buster armhf images automatically add a serial
> console
> (e.g. for the cubox-i) or if that is a manual step?
Are you talking about whilst running the installer, or for normal
booting after the installer has
Hi,
can anybody tell if the buster armhf images automatically add a serial console
(e.g. for the cubox-i) or if that is a manual step?
If manual, I assume I have to take the SD card after the installation and
in /etc/systemd/system/getty.target.wants
# ln -s /lib/systemd/system/getty@.service
El 28/7/19 a les 14:09, Reco ha escrit:
Yes. No. Maybe. These things are called Predictable because they aren't.
A modern systemd paradox, if you will.
:-D
Btw,
ln -s /dev/null /etc/systemd/network/99-default.link [*]
worked, at least in stretch. I hope that it still works in buster.
[*]
On Sun, Jul 28, 2019 at 11:04:41AM +0200, Luca Olivetti wrote:
> El 27/7/19 a les 23:20, Reco ha escrit:
>
> >
> > > yet it always gets the name wlxe894f615307a.
> >
> > What you're doing colud work.
> > The problem is - you have NIC that's attached via USB, so the usual
> > rules do not apply.
El 27/7/19 a les 23:20, Reco ha escrit:
yet it always gets the name wlxe894f615307a.
What you're doing colud work.
The problem is - you have NIC that's attached via USB, so the usual
rules do not apply.
The reason of it - /lib/udev/rules.d/73-usb-net-by-mac.rules, that's
applied after your
On Sun, Jul 28, 2019 at 06:50:53AM -0400, Gene Heskett wrote:
> On Sunday 28 July 2019 00:27:36 Reco wrote:
>
> > On Sun, Jul 28, 2019 at 12:13:21AM -0400, Gene Heskett wrote:
> > > > > That, and a whole restaraunt sized menu of dpkg stuff for
> > > > > building packages is on the missing list.
On Sunday 28 July 2019 03:17:48 Andrei POPESCU wrote:
> On Sb, 27 iul 19, 10:22:41, Vagrant Cascadian wrote:
> > On 2019-07-27, Michael Gratton wrote:
> > > Uboot has support for for the chipset[1]
> >
> > There is u-boot support specifically for rockpro64-rk3399 upstream
> > now. I'd be happy to
On Sunday 28 July 2019 00:27:36 Reco wrote:
> On Sun, Jul 28, 2019 at 12:13:21AM -0400, Gene Heskett wrote:
> > > > That, and a whole restaraunt sized menu of dpkg stuff for
> > > > building packages is on the missing list. Gr.
> > >
> > > apt install build-essential
> >
> > I *think* I did
Hi,
does anybody know if there is something equivalent to devregs in
https://github.com/boundarydevices/imx-utils
to probe and manipulate the hardware registers in an imx6 for Debian.
Thanks
Rainer
--
Rainer Dorsch
http://bokomoko.de/
[please follow-up on debian-arm since it is an imx6 specific issue]
Hi,
I found in the meantime
https://boundarydevices.com/i-mx6-ethernet/
describes most likely the issue I see, in particular the transfer rate
degradation to 3 Mbits/s is what I see
root@linaro-nano:~# tsecs=2 incr=200
On Jul 28 2019, Aurelien Jarno wrote:
> The two MIPS libffi patches have been accepted upstream (i.e. in the
> libffi git repository) 1.5 years ago for one and 4 years ago for the
> other. I know there hasn't been any recent libffi release, so what can
> be done to sync the gcc repository? Would
On Sun, Jul 28, 2019 at 10:17, Andrei POPESCU
wrote:
On Sb, 27 iul 19, 10:22:41, Vagrant Cascadian wrote:
On 2019-07-27, Michael Gratton wrote:
> Uboot has support for for the chipset[1]
There is u-boot support specifically for rockpro64-rk3399 upstream
now. I'd be happy to enable it in
On Sb, 27 iul 19, 10:22:41, Vagrant Cascadian wrote:
> On 2019-07-27, Michael Gratton wrote:
>
> > Uboot has support for for the chipset[1]
>
> There is u-boot support specifically for rockpro64-rk3399 upstream
> now. I'd be happy to enable it in the u-boot packaging if you or someone
> else can
17 matches
Mail list logo
