Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1314332 > unrolled thread

Re: [PATCH v3 3/5] soc: rockchip: add reboot notifier driver

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH v3 3/5] soc: rockchip: add reboot notifier driver Thierry Reding <treding@nvidia.com> - 2016-01-21 17:30 +0100

#1314332 — Re: [PATCH v3 3/5] soc: rockchip: add reboot notifier driver

[Multipart message — attachments visible in raw view] — view raw

On Mon, Dec 28, 2015 at 04:35:46PM +0100, Arnd Bergmann wrote:
> On Monday 28 December 2015 10:20:56 Thierry Reding wrote:
> > > > > HTC apparently uses a separate RAM area to pass the reboot reason,
> > > > > and they have a driver to store that, which is separate from the
> > > > > driver that they use for actually rebooting the machine.
> > > > 
> > > > I wasn't very clear, but the PMC_SCRATCH0 register is used to store the
> > > > reset reason. It supports the recovery mode, which I think is really an
> > > > Android thing, "bootloader" will typically cause the bootloader not to
> > > > boot anything, and "forced-recovery" will go into a recovery mode that
> > > > is used to bootstrap the device (usually by uploading a "miniloader"
> > > > that initializes RAM, downloads a bootloader for booting or flashing an
> > > > operating system, ...).
> > > > 
> > > > The write that resets the SoC is to a different register.
> > > 
> > > So is this scratch register interpreted by some maskrom code, or by code that
> > > can be provided by the OEM?
> > 
> > My understanding is that its interpreted both by what's called BootROM
> > on Tegra (I guess that's what you call "maskrom code") and the system's
> > bootloader. The BootROM cannot typically be replaced by the OEM, but it
> > is quite typical for the bootloader to differ between devices.
> 
> Ok, so not maskrom (which would not be OEM specific, but hardcoded for
> the chip) but rather some form of PROM. This means we can only guess
> that all OEMs use the same protocol but in theory someone could have
> implemented an incompatible BootROM, but it's also possible that HTC
> just ignore the register entirely and implement the same thing separately.

I wasn't being clear, the BootROM is hardcoded for the chip, I'm not
aware of a way to replace it once the chip's taped out.

Thierry

[toc] | [standalone]

Back to top | Article view | linux.kernel

csiph-web