All of lore.kernel.org
 help / color / mirror / Atom feed
From: Russell King - ARM Linux <linux@armlinux.org.uk>
To: Sudeep Holla <sudeep.holla@arm.com>
Cc: Philippe Robin <Philippe.Robin@arm.com>,
	devicetree@vger.kernel.org,
	Neil Armstrong <narmstrong@baylibre.com>,
	linux-kernel@vger.kernel.org, Olof Johansson <olof@lixom.net>,
	linux-amlogic@lists.infradead.org,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 0/8] firmware: arm_scpi: add support for legacy SCPI protocol
Date: Tue, 8 Nov 2016 17:46:22 +0000	[thread overview]
Message-ID: <20161108174622.GW1041@n2100.armlinux.org.uk> (raw)
In-Reply-To: <fb4348a8-197c-2219-ff01-8716e2a0b955@arm.com>

On Tue, Nov 08, 2016 at 05:37:25PM +0000, Sudeep Holla wrote:
> 
> 
> On 08/11/16 16:06, Russell King - ARM Linux wrote:
> >On Tue, Nov 08, 2016 at 03:40:38PM +0000, Russell King - ARM Linux wrote:
> >>As it contains a zero sized Image and .dtb files, I tried copying my
> >>Image and .dtb over, and also copied my original config.txt (only
> >>change is AUTORUN: FALSE).  It still doesn't appear to boot beyond
> >>this point.
> >
> >Well, it seems that I can't even go back to my original set of firmware
> >as UEFI has stopped working:
> >
> >NOTICE:  Booting Trusted Firmware
> >NOTICE:  BL1: v1.0(release):14b6608
> >NOTICE:  BL1: Built : 14:15:51, Sep  1 2014
> >NOTICE:  BL1: Booting BL2
> >NOTICE:  BL2: v1.0(release):14b6608
> >NOTICE:  BL2: Built : 14:15:51, Sep  1 2014
> >NOTICE:  BL1: Booting BL3-1
> >NOTICE:  BL3-1: v1.0(release):14b6608
> >NOTICE:  BL3-1: Built : 14:15:53, Sep  1 2014
> >UEFI firmware (version v2.1 built at 14:41:56 on Oct 23 2014)
> >Warning: Fail to load FDT file 'juno.dtb'.
> >
> 
> This again because of incompatibility of the configuration data saved in
> NOR flash. The erase command I gave early is to erase that when you
> switched between the UEFI binaries. It's really horrible mess UEFI
> created in the initial days of Juno, and hopefully they have moved to
> some standard format these days.

Yea, what it means is I've no possibility to go back to what was
originally working now, since I don't understand how to get UEFI to
behave (Will set the machine up for me, I don't have any information
on how it was originally configured other than what was on the uSD
card, which appears incomplete.)

> >and UEFI is the most unfriendly thing going - the "boot manager" thing
> >doesn't let you view the configuration:
> >
> 
> I completely agree. I had real bad times in past dealing with such
> things in UEFI.
> 
> >[1] Linux from NOR Flash
> >[2] Shell
> >[3] Boot Manager
> >Start: 3
> >[1] Add Boot Device Entry
> >[2] Update Boot Device Entry
> >[3] Remove Boot Device Entry
> >[4] Reorder Boot Device Entries
> >[5] Update FDT path
> >[6] Set Boot Timeout
> >[7] Return to main menu
> >Choice:
> >
> >and dropping into the shell... well, I've no idea how to get a listing
> >of what it thinks is in the NOR device (or even how to refer to the
> >NOR device.)  "devices" shows nothing that's even remotely English.
> >
> 
> I think startup.nsh needs some edits. Just replace it with something like:
> 
> "norkern dtb=board.dtb console=ttyAMA0,115200n8 root=/dev/nfs rw
> rootwait ip=dhcp systemd.log_target=null nfsroot=..." or something
> alike. Currently it just echos and stops.
> 
> Regarding the new firmware stopping abruptly, I have no clue, except
> asking you to erase the flash completely when switching between the
> firmware versions. That has worked for me for all UEFI related issues in
> the past. It's really annoying I understand.
> 
> flash> eraseall

I've tried that, it still stops at the same point, after:

FV2 Hob           0xFE07B000 - 0xFE8253BF

and remains unresponsive.

I do notice that the uSD card becomes visible through USB at this point
though.

Okay, well, I'm going to have to disable Juno from the nightly boots
until we get some kind of resolution on this, as my Juno is now
incapable of booting anything.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

WARNING: multiple messages have this Message-ID (diff)
From: linux@armlinux.org.uk (Russell King - ARM Linux)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 0/8] firmware: arm_scpi: add support for legacy SCPI protocol
Date: Tue, 8 Nov 2016 17:46:22 +0000	[thread overview]
Message-ID: <20161108174622.GW1041@n2100.armlinux.org.uk> (raw)
In-Reply-To: <fb4348a8-197c-2219-ff01-8716e2a0b955@arm.com>

On Tue, Nov 08, 2016 at 05:37:25PM +0000, Sudeep Holla wrote:
> 
> 
> On 08/11/16 16:06, Russell King - ARM Linux wrote:
> >On Tue, Nov 08, 2016 at 03:40:38PM +0000, Russell King - ARM Linux wrote:
> >>As it contains a zero sized Image and .dtb files, I tried copying my
> >>Image and .dtb over, and also copied my original config.txt (only
> >>change is AUTORUN: FALSE).  It still doesn't appear to boot beyond
> >>this point.
> >
> >Well, it seems that I can't even go back to my original set of firmware
> >as UEFI has stopped working:
> >
> >NOTICE:  Booting Trusted Firmware
> >NOTICE:  BL1: v1.0(release):14b6608
> >NOTICE:  BL1: Built : 14:15:51, Sep  1 2014
> >NOTICE:  BL1: Booting BL2
> >NOTICE:  BL2: v1.0(release):14b6608
> >NOTICE:  BL2: Built : 14:15:51, Sep  1 2014
> >NOTICE:  BL1: Booting BL3-1
> >NOTICE:  BL3-1: v1.0(release):14b6608
> >NOTICE:  BL3-1: Built : 14:15:53, Sep  1 2014
> >UEFI firmware (version v2.1 built at 14:41:56 on Oct 23 2014)
> >Warning: Fail to load FDT file 'juno.dtb'.
> >
> 
> This again because of incompatibility of the configuration data saved in
> NOR flash. The erase command I gave early is to erase that when you
> switched between the UEFI binaries. It's really horrible mess UEFI
> created in the initial days of Juno, and hopefully they have moved to
> some standard format these days.

Yea, what it means is I've no possibility to go back to what was
originally working now, since I don't understand how to get UEFI to
behave (Will set the machine up for me, I don't have any information
on how it was originally configured other than what was on the uSD
card, which appears incomplete.)

> >and UEFI is the most unfriendly thing going - the "boot manager" thing
> >doesn't let you view the configuration:
> >
> 
> I completely agree. I had real bad times in past dealing with such
> things in UEFI.
> 
> >[1] Linux from NOR Flash
> >[2] Shell
> >[3] Boot Manager
> >Start: 3
> >[1] Add Boot Device Entry
> >[2] Update Boot Device Entry
> >[3] Remove Boot Device Entry
> >[4] Reorder Boot Device Entries
> >[5] Update FDT path
> >[6] Set Boot Timeout
> >[7] Return to main menu
> >Choice:
> >
> >and dropping into the shell... well, I've no idea how to get a listing
> >of what it thinks is in the NOR device (or even how to refer to the
> >NOR device.)  "devices" shows nothing that's even remotely English.
> >
> 
> I think startup.nsh needs some edits. Just replace it with something like:
> 
> "norkern dtb=board.dtb console=ttyAMA0,115200n8 root=/dev/nfs rw
> rootwait ip=dhcp systemd.log_target=null nfsroot=..." or something
> alike. Currently it just echos and stops.
> 
> Regarding the new firmware stopping abruptly, I have no clue, except
> asking you to erase the flash completely when switching between the
> firmware versions. That has worked for me for all UEFI related issues in
> the past. It's really annoying I understand.
> 
> flash> eraseall

I've tried that, it still stops at the same point, after:

FV2 Hob           0xFE07B000 - 0xFE8253BF

and remains unresponsive.

I do notice that the uSD card becomes visible through USB at this point
though.

Okay, well, I'm going to have to disable Juno from the nightly boots
until we get some kind of resolution on this, as my Juno is now
incapable of booting anything.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

WARNING: multiple messages have this Message-ID (diff)
From: linux@armlinux.org.uk (Russell King - ARM Linux)
To: linus-amlogic@lists.infradead.org
Subject: [PATCH 0/8] firmware: arm_scpi: add support for legacy SCPI protocol
Date: Tue, 8 Nov 2016 17:46:22 +0000	[thread overview]
Message-ID: <20161108174622.GW1041@n2100.armlinux.org.uk> (raw)
In-Reply-To: <fb4348a8-197c-2219-ff01-8716e2a0b955@arm.com>

On Tue, Nov 08, 2016 at 05:37:25PM +0000, Sudeep Holla wrote:
> 
> 
> On 08/11/16 16:06, Russell King - ARM Linux wrote:
> >On Tue, Nov 08, 2016 at 03:40:38PM +0000, Russell King - ARM Linux wrote:
> >>As it contains a zero sized Image and .dtb files, I tried copying my
> >>Image and .dtb over, and also copied my original config.txt (only
> >>change is AUTORUN: FALSE).  It still doesn't appear to boot beyond
> >>this point.
> >
> >Well, it seems that I can't even go back to my original set of firmware
> >as UEFI has stopped working:
> >
> >NOTICE:  Booting Trusted Firmware
> >NOTICE:  BL1: v1.0(release):14b6608
> >NOTICE:  BL1: Built : 14:15:51, Sep  1 2014
> >NOTICE:  BL1: Booting BL2
> >NOTICE:  BL2: v1.0(release):14b6608
> >NOTICE:  BL2: Built : 14:15:51, Sep  1 2014
> >NOTICE:  BL1: Booting BL3-1
> >NOTICE:  BL3-1: v1.0(release):14b6608
> >NOTICE:  BL3-1: Built : 14:15:53, Sep  1 2014
> >UEFI firmware (version v2.1 built at 14:41:56 on Oct 23 2014)
> >Warning: Fail to load FDT file 'juno.dtb'.
> >
> 
> This again because of incompatibility of the configuration data saved in
> NOR flash. The erase command I gave early is to erase that when you
> switched between the UEFI binaries. It's really horrible mess UEFI
> created in the initial days of Juno, and hopefully they have moved to
> some standard format these days.

Yea, what it means is I've no possibility to go back to what was
originally working now, since I don't understand how to get UEFI to
behave (Will set the machine up for me, I don't have any information
on how it was originally configured other than what was on the uSD
card, which appears incomplete.)

> >and UEFI is the most unfriendly thing going - the "boot manager" thing
> >doesn't let you view the configuration:
> >
> 
> I completely agree. I had real bad times in past dealing with such
> things in UEFI.
> 
> >[1] Linux from NOR Flash
> >[2] Shell
> >[3] Boot Manager
> >Start: 3
> >[1] Add Boot Device Entry
> >[2] Update Boot Device Entry
> >[3] Remove Boot Device Entry
> >[4] Reorder Boot Device Entries
> >[5] Update FDT path
> >[6] Set Boot Timeout
> >[7] Return to main menu
> >Choice:
> >
> >and dropping into the shell... well, I've no idea how to get a listing
> >of what it thinks is in the NOR device (or even how to refer to the
> >NOR device.)  "devices" shows nothing that's even remotely English.
> >
> 
> I think startup.nsh needs some edits. Just replace it with something like:
> 
> "norkern dtb=board.dtb console=ttyAMA0,115200n8 root=/dev/nfs rw
> rootwait ip=dhcp systemd.log_target=null nfsroot=..." or something
> alike. Currently it just echos and stops.
> 
> Regarding the new firmware stopping abruptly, I have no clue, except
> asking you to erase the flash completely when switching between the
> firmware versions. That has worked for me for all UEFI related issues in
> the past. It's really annoying I understand.
> 
> flash> eraseall

I've tried that, it still stops at the same point, after:

FV2 Hob           0xFE07B000 - 0xFE8253BF

and remains unresponsive.

I do notice that the uSD card becomes visible through USB at this point
though.

Okay, well, I'm going to have to disable Juno from the nightly boots
until we get some kind of resolution on this, as my Juno is now
incapable of booting anything.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

  reply	other threads:[~2016-11-08 17:46 UTC|newest]

Thread overview: 116+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-11-03  4:52 [PATCH 0/8] firmware: arm_scpi: add support for legacy SCPI protocol Sudeep Holla
2016-11-03  4:52 ` Sudeep Holla
2016-11-03  4:52 ` Sudeep Holla
2016-11-03  4:52 ` Sudeep Holla
2016-11-03  4:52 ` [PATCH v5 1/8] firmware: arm_scpi: add command indirection to support legacy commands Sudeep Holla
2016-11-03  4:52   ` Sudeep Holla
2016-11-03  4:52   ` Sudeep Holla
2016-11-03  4:52 ` [PATCH v5 2/8] firmware: arm_scpi: increase MAX_DVFS_OPPS to 16 entries Sudeep Holla
2016-11-03  4:52   ` Sudeep Holla
2016-11-03  4:52   ` Sudeep Holla
2016-11-03  4:52   ` Sudeep Holla
2016-11-03  4:52 ` [PATCH v5 3/8] firmware: arm_scpi: add alternative legacy structures, functions and macros Sudeep Holla
2016-11-03  4:52   ` Sudeep Holla
2016-11-03  4:52   ` Sudeep Holla
2016-11-03  4:52   ` Sudeep Holla
2016-11-03  4:52 ` [PATCH v5 4/8] firmware: arm_scpi: allow firmware with get_capabilities not implemented Sudeep Holla
2016-11-03  4:52   ` Sudeep Holla
2016-11-03  4:52   ` Sudeep Holla
2016-11-03  4:52   ` Sudeep Holla
2016-11-03  4:52 ` [PATCH v5 5/8] Documentation: bindings: decouple juno specific details from generic binding Sudeep Holla
2016-11-03  4:52   ` Sudeep Holla
2016-11-03  4:52   ` Sudeep Holla
2016-11-10  1:18   ` Rob Herring
2016-11-10  1:18     ` Rob Herring
2016-11-10  1:18     ` Rob Herring
2016-11-03  4:52 ` [PATCH v5 6/8] Documentation: bindings: add compatible specific to legacy SCPI protocol Sudeep Holla
2016-11-03  4:52   ` Sudeep Holla
2016-11-03  4:52   ` Sudeep Holla
2016-11-08 14:32   ` Sudeep Holla
2016-11-08 14:32     ` Sudeep Holla
2016-11-08 14:32     ` Sudeep Holla
2016-11-08 14:32     ` Sudeep Holla
2016-11-10  1:22   ` Rob Herring
2016-11-10  1:22     ` Rob Herring
2016-11-10  1:22     ` Rob Herring
2016-11-10  1:22     ` Rob Herring
2016-11-10 10:26     ` Sudeep Holla
2016-11-10 10:26       ` Sudeep Holla
2016-11-10 10:26       ` Sudeep Holla
2016-11-10 10:26       ` Sudeep Holla
2016-11-10 14:12       ` Rob Herring
2016-11-10 14:12         ` Rob Herring
2016-11-10 14:12         ` Rob Herring
2016-11-10 14:12         ` Rob Herring
2016-11-10 14:34         ` Sudeep Holla
2016-11-10 14:34           ` Sudeep Holla
2016-11-10 14:34           ` Sudeep Holla
2016-11-10 14:34           ` Sudeep Holla
2016-11-10 19:03           ` Olof Johansson
2016-11-10 19:03             ` Olof Johansson
2016-11-10 19:03             ` Olof Johansson
2016-11-10 19:03             ` Olof Johansson
2016-11-11  7:48             ` Sudeep Holla
2016-11-11  7:48               ` Sudeep Holla
2016-11-11  7:48               ` Sudeep Holla
2016-11-11  7:48               ` Sudeep Holla
2016-11-11 13:34               ` Rob Herring
2016-11-11 13:34                 ` Rob Herring
2016-11-11 13:34                 ` Rob Herring
2016-11-11 13:34                 ` Rob Herring
2016-11-11 14:19                 ` Sudeep Holla
2016-11-11 14:19                   ` Sudeep Holla
2016-11-11 14:19                   ` Sudeep Holla
2016-11-11 14:19                   ` Sudeep Holla
2016-11-15 16:36                   ` Sudeep Holla
2016-11-15 16:36                     ` Sudeep Holla
2016-11-15 16:36                     ` Sudeep Holla
2016-11-15 16:36                     ` Sudeep Holla
2016-11-03  4:52 ` [PATCH v5 7/8] Documentation: bindings: Add support for Amlogic GXBB " Sudeep Holla
2016-11-03  4:52   ` Sudeep Holla
2016-11-03  4:52   ` Sudeep Holla
2016-11-03  4:52   ` Sudeep Holla
2016-11-10  1:23   ` Rob Herring
2016-11-10  1:23     ` Rob Herring
2016-11-10  1:23     ` Rob Herring
2016-11-10  1:23     ` Rob Herring
2016-11-03  4:52 ` [PATCH v5 8/8] firmware: arm_scpi: add support for legacy SCPI compatible Sudeep Holla
2016-11-03  4:52   ` Sudeep Holla
2016-11-03  4:52   ` Sudeep Holla
2016-11-03  9:12 ` [PATCH 0/8] firmware: arm_scpi: add support for legacy SCPI protocol Neil Armstrong
2016-11-03  9:12   ` Neil Armstrong
2016-11-03  9:12   ` Neil Armstrong
2016-11-08 14:51 ` Russell King - ARM Linux
2016-11-08 14:51   ` Russell King - ARM Linux
2016-11-08 14:51   ` Russell King - ARM Linux
2016-11-08 14:51   ` Russell King - ARM Linux
2016-11-08 15:11   ` Sudeep Holla
2016-11-08 15:11     ` Sudeep Holla
2016-11-08 15:11     ` Sudeep Holla
2016-11-08 15:11     ` Sudeep Holla
2016-11-08 15:40     ` Russell King - ARM Linux
2016-11-08 15:40       ` Russell King - ARM Linux
2016-11-08 15:40       ` Russell King - ARM Linux
2016-11-08 16:06       ` Russell King - ARM Linux
2016-11-08 16:06         ` Russell King - ARM Linux
2016-11-08 16:06         ` Russell King - ARM Linux
2016-11-08 17:37         ` Sudeep Holla
2016-11-08 17:37           ` Sudeep Holla
2016-11-08 17:37           ` Sudeep Holla
2016-11-08 17:46           ` Russell King - ARM Linux [this message]
2016-11-08 17:46             ` Russell King - ARM Linux
2016-11-08 17:46             ` Russell King - ARM Linux
2016-11-21 15:04             ` Ryan Harkin
2016-11-21 15:04               ` Ryan Harkin
2016-11-21 15:04               ` Ryan Harkin
2016-11-21 15:04               ` Ryan Harkin
2016-11-21 15:12               ` Sudeep Holla
2016-11-21 15:12                 ` Sudeep Holla
2016-11-21 15:12                 ` Sudeep Holla
2016-11-21 15:12                 ` Sudeep Holla
2016-11-08 16:08       ` Sudeep Holla
2016-11-08 16:08         ` Sudeep Holla
2016-11-08 16:08         ` Sudeep Holla
2016-11-08 16:13         ` Russell King - ARM Linux
2016-11-08 16:13           ` Russell King - ARM Linux
2016-11-08 16:13           ` Russell King - ARM Linux

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20161108174622.GW1041@n2100.armlinux.org.uk \
    --to=linux@armlinux.org.uk \
    --cc=Philippe.Robin@arm.com \
    --cc=devicetree@vger.kernel.org \
    --cc=linux-amlogic@lists.infradead.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=narmstrong@baylibre.com \
    --cc=olof@lixom.net \
    --cc=sudeep.holla@arm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.