Patrick Wildt wrote:
> Well actually, maybe we should just rm -rf the whole port, then
> there's no frustration on either end. ;)
How does the port relate to the (IIUC neccessary) files in e.g.
miniroot-am335x-*.img, if at all?
Thanks
//Peter
On Tue, May 09, 2023 at 09:54:59AM +1000, David Gwynne wrote:
>
>
> > On 8 May 2023, at 22:44, Mark Kettenis wrote:
> >
> >> From: Patrick Wildt
> >> Date: Mon, 8 May 2023 14:14:27 +0200
> >>
> >>> Am 07.05.2023 um 19:54 schrieb Klemens Nanni :
> >>>
> >>> On Sun, May 07, 2023 at 06:30:55PM
Mark Kettenis wrote:
> Unfortunately there isn't a good source for pre-built U-Boot binaries,
> let alone a source of pre-built U-Boot binaries that didn't somehow
> fuck up EFI support.
I'd like if EFI wasn't the only supported interface, especially since
DTB is prefered over MSFT ACPI when avail
> On 8 May 2023, at 22:44, Mark Kettenis wrote:
>
>> From: Patrick Wildt
>> Date: Mon, 8 May 2023 14:14:27 +0200
>>
>>> Am 07.05.2023 um 19:54 schrieb Klemens Nanni :
>>>
>>> On Sun, May 07, 2023 at 06:30:55PM +0200, Mark Kettenis wrote:
As I've said before, the u-boot developers have
> From: Patrick Wildt
> Date: Mon, 8 May 2023 14:14:27 +0200
>
> > Am 07.05.2023 um 19:54 schrieb Klemens Nanni :
> >
> > On Sun, May 07, 2023 at 06:30:55PM +0200, Mark Kettenis wrote:
> >> As I've said before, the u-boot developers have poor quality control
> >> and this will almost certainly
> Am 07.05.2023 um 19:54 schrieb Klemens Nanni :
>
> On Sun, May 07, 2023 at 06:30:55PM +0200, Mark Kettenis wrote:
>> As I've said before, the u-boot developers have poor quality control
>> and this will almost certainly break some targets.
>>
>> I think the way forward is to have a u-boot p
> Date: Sun, 7 May 2023 17:54:17 +
> From: Klemens Nanni
>
> On Sun, May 07, 2023 at 06:30:55PM +0200, Mark Kettenis wrote:
> > As I've said before, the u-boot developers have poor quality control
> > and this will almost certainly break some targets.
> >
> > I think the way forward is to h
On Sun, May 07, 2023 at 06:30:55PM +0200, Mark Kettenis wrote:
> As I've said before, the u-boot developers have poor quality control
> and this will almost certainly break some targets.
>
> I think the way forward is to have a u-boot port per SoC such that we
> can leave older SoCs using an older
> Date: Sat, 6 May 2023 17:36:53 +0200
> From: Patrick Wildt
>
> On Fri, Nov 18, 2022 at 12:53:44PM +, Klemens Nanni wrote:
> > On Mon, Nov 14, 2022 at 11:37:05PM +0100, Patrick Wildt wrote:
> > > Hi,
> > >
> > > the u-boot and dtb ports haven't been updated in a while, mostly because
> > >
On Fri, Nov 18, 2022 at 12:53:44PM +, Klemens Nanni wrote:
> On Mon, Nov 14, 2022 at 11:37:05PM +0100, Patrick Wildt wrote:
> > Hi,
> >
> > the u-boot and dtb ports haven't been updated in a while, mostly because
> > updating those regularly breaks working machines. I think it's time for
> >
> Date: Fri, 2 Dec 2022 18:44:27 +
> From: Peter Stuge
>
> Jan Stary wrote:
> > > > > Replacing the DTBs with those from the dtb package is not supposed to
> > > > > work.
> >
> > Is this specific to the Raspberry, or is that true in general?
>
> I think this was specifically in response to
Jan Stary wrote:
> > > > Replacing the DTBs with those from the dtb package is not supposed to
> > > > work.
>
> Is this specific to the Raspberry, or is that true in general?
I think this was specifically in response to the test on an RPi.
> The content of the dtb package is a bunch of DTBs un
On Nov 28 00:39:09, patr...@blueri.se wrote:
> Am Mon, Nov 28, 2022 at 12:22:30AM +0100 schrieb Patrick Wildt:
> > Am Fri, Nov 25, 2022 at 12:52:24AM + schrieb Peter Stuge:
> > > Jan Stary wrote:
> > > > Here is the cpsw problem:
> > > >
> > > > -cpsw0 at omsysc46: version 1.12 (0), address 90
> > > > > This breakes my RPI4.
> > > > >
> > > > > After replacing the DTBs on the dos partition
> > > > > with those from the new dtb port, the rpi4
> > > > > does not emit anything on the console,
> > > > > and is not reachable over the network.
> > >
> > > Replacing the DTBs with those from t
On Tue, Nov 22, 2022 at 04:18:55PM +0100, Jan Stary wrote:
> On Nov 22 15:42:20, mark.kette...@xs4all.nl wrote:
> > > Date: Tue, 22 Nov 2022 14:40:06 +0100
> > > From: Jan Stary
> > >
> > > On Nov 22 13:52:52, h...@stare.cz wrote:
> > > > On Nov 14 23:37:05, patr...@blueri.se wrote:
> > > > > the
Mark Kettenis wrote:
> > As I understand the driver, cpsw0 will always have a zero address if
> > the "ti,cpsw" device tree node has either no child nodes at all or
> > none named "local-mac-address".
> >
> > If a "local-mac-address" child node exists then that address is used.
>
> Small correcti
Am Mon, Nov 28, 2022 at 12:22:30AM +0100 schrieb Patrick Wildt:
> Am Fri, Nov 25, 2022 at 12:52:24AM + schrieb Peter Stuge:
> > Jan Stary wrote:
> > > Here is the cpsw problem:
> > >
> > > -cpsw0 at omsysc46: version 1.12 (0), address 90:59:af:82:2e:7e
> > > +cpsw0 at omsysc46: version 1.12 (0
Am Fri, Nov 25, 2022 at 12:52:24AM + schrieb Peter Stuge:
> Jan Stary wrote:
> > Here is the cpsw problem:
> >
> > -cpsw0 at omsysc46: version 1.12 (0), address 90:59:af:82:2e:7e
> > +cpsw0 at omsysc46: version 1.12 (0), address 00:00:00:00:00:00
>
> I confirm this on beaglebone black but I'm
> Date: Fri, 25 Nov 2022 00:52:24 +
> From: Peter Stuge
>
> Jan Stary wrote:
> > Here is the cpsw problem:
> >
> > -cpsw0 at omsysc46: version 1.12 (0), address 90:59:af:82:2e:7e
> > +cpsw0 at omsysc46: version 1.12 (0), address 00:00:00:00:00:00
>
> I confirm this on beaglebone black but I
Jan Stary wrote:
> Here is the cpsw problem:
>
> -cpsw0 at omsysc46: version 1.12 (0), address 90:59:af:82:2e:7e
> +cpsw0 at omsysc46: version 1.12 (0), address 00:00:00:00:00:00
I confirm this on beaglebone black but I'm not sure it's actually a
dtb bug, more on that below.
I could anyway DHCP
On Nov 18 15:59:01, mark.kette...@xs4all.nl wrote:
> Let me explain the situation once more. In principle the only thing
> you need is a (working) U-Boot for you board/machine. But in some
> cases the DTB that comes with U-Boot is broken. In that case you may
> be able to make your board/machine
On Nov 22 15:42:20, mark.kette...@xs4all.nl wrote:
> > Date: Tue, 22 Nov 2022 14:40:06 +0100
> > From: Jan Stary
> >
> > On Nov 22 13:52:52, h...@stare.cz wrote:
> > > On Nov 14 23:37:05, patr...@blueri.se wrote:
> > > > the u-boot and dtb ports haven't been updated in a while, mostly because
> >
> Date: Tue, 22 Nov 2022 14:40:06 +0100
> From: Jan Stary
>
> On Nov 22 13:52:52, h...@stare.cz wrote:
> > On Nov 14 23:37:05, patr...@blueri.se wrote:
> > > the u-boot and dtb ports haven't been updated in a while, mostly because
> > > updating those regularly breaks working machines. I think i
On 2022/11/22 14:29, Jan Stary wrote:
> On Nov 14 23:37:05, patr...@blueri.se wrote:
> > I can provide pre-built unsigned packages upon request.
>
> How did you build on arm, when both u-boot
> and the required arm-none-eabi-gcc-linaro
> are marked BROKEN for arm?
>
> Trying to build u-boot on Be
On Nov 22 13:50:58, s...@spacehopper.org wrote:
> On 2022/11/22 14:29, Jan Stary wrote:
> > On Nov 14 23:37:05, patr...@blueri.se wrote:
> > > I can provide pre-built unsigned packages upon request.
> >
> > How did you build on arm, when both u-boot
> > and the required arm-none-eabi-gcc-linaro
>
On Nov 14 23:37:05, patr...@blueri.se wrote:
> I can provide pre-built unsigned packages upon request.
How did you build on arm, when both u-boot
and the required arm-none-eabi-gcc-linaro
are marked BROKEN for arm?
Trying to build u-boot on BeagleBone Black (arm),
I am naively commenting out the
On Nov 14 23:37:05, patr...@blueri.se wrote:
> the u-boot and dtb ports haven't been updated in a while, mostly because
> updating those regularly breaks working machines. I think it's time for
> another update, so here's a diff for both.
>
> Before this heads into the tree it would be nice to ge
> Here is the cpsw problem:
>
> -cpsw0 at omsysc46: version 1.12 (0), address 90:59:af:82:2e:7e
> +cpsw0 at omsysc46: version 1.12 (0), address 00:00:00:00:00:00
>
> The booted BBB did assign an address to its cpsw0,
>
> cpsw0: flags=808843 mtu 1500
> lladdr 00:00:00:00:00:00
> index
Am Fri, Nov 18, 2022 at 12:53:44PM + schrieb Klemens Nanni:
> On Mon, Nov 14, 2022 at 11:37:05PM +0100, Patrick Wildt wrote:
> > Hi,
> >
> > the u-boot and dtb ports haven't been updated in a while, mostly because
> > updating those regularly breaks working machines. I think it's time for
> >
> Date: Fri, 18 Nov 2022 12:53:44 +
> From: Klemens Nanni
>
> On Mon, Nov 14, 2022 at 11:37:05PM +0100, Patrick Wildt wrote:
> > Hi,
> >
> > the u-boot and dtb ports haven't been updated in a while, mostly because
> > updating those regularly breaks working machines. I think it's time for
>
On Mon, Nov 14, 2022 at 11:37:05PM +0100, Patrick Wildt wrote:
> Hi,
>
> the u-boot and dtb ports haven't been updated in a while, mostly because
> updating those regularly breaks working machines. I think it's time for
> another update, so here's a diff for both.
>
> Before this heads into the
Hi,
the u-boot and dtb ports haven't been updated in a while, mostly because
updating those regularly breaks working machines. I think it's time for
another update, so here's a diff for both.
Before this heads into the tree it would be nice to get some testing
from people with Pinebook Pro, Rock
32 matches
Mail list logo
