[U-Boot] [PATCH U-Boot] ARM: rpi_b: detect board revision
sjg at chromium.org
Sun Aug 2 14:29:32 PDT 2015
On 24 July 2015 at 00:26, Stephen Warren <swarren at wwwdotorg.org> wrote:
> On 11/24/2014 08:50 AM, Simon Glass wrote:
>> Hi Stephen,
>> On 18 November 2014 at 21:40, Stephen Warren <swarren at wwwdotorg.org> wrote:
>>> Detect the board revision early during boot, and print the decoded
>>> model name.
>>> Eventually, this information can be used for tasks such as:
>>> - Allowing/preventing USB device mode; some models have a USB device on-
>>> board so only host mode makes sense. Others connect the SoC directly
>>> to the USB connector, so device-mode might make sense.
>>> - The on-board USB hub/Ethernet requires different GPIOs to enable it,
>>> although luckily the default appears to be fine so far.
>>> - The compute module contains an on-board eMMC device, so we could store
>>> the environment there. Other models use an SD card and so don't support
>>> saving the environment (unless we store it in a file on the FAT boot
>>> Set $fdtfile based on this information. At present, the mainline Linux
>>> kernel doesn't contain a separate DTB for most models, but I hope that
>>> will change soon.
>>> Signed-off-by: Stephen Warren <swarren at wwwdotorg.org>
>>> I'm considering renaming rpi_b -> rpi in U-Boot since it supports many
>>> models. Hopefully I can persuade U-Boot to load the environment from
>>> different places at run-time, so we won't need different builds based
>>> on whether the environment is in eMMC or not for example.
>>> arch/arm/include/asm/arch-bcm2835/mbox.h | 33 +++++++++
>>> board/raspberrypi/rpi_b/rpi_b.c | 122 ++++++++++++++++++++++++++++++-
>>> include/configs/rpi_b.h | 1 -
>>> 3 files changed, 152 insertions(+), 4 deletions(-)
>> I tried this out. It worked OK for me except that it can't find the
>> device tree file bcm2835-rpi-b-rev2.dtb.
>> Oddly I can fatload it from /bcm2835-rpi-b-rev2.dtb but when I try
>> from /syslinux/..//bcm2835-rpi-b-rev2.dtb it fails and cannot find the
>> file. Reducing the filename length to 8 chars works. I wonder what
>> year of my life FAT will stop plaguing me?
> Did you ever find a solution to this issue? It's hitting me now.
> I found a thread about this topic:
> [U-Boot] [PATCH] fs: fat: read: fix fat16 ls/read issue
> However, there didn't seem to be any conclusion there. I did look at the
> FAT code a bit, but didn't make much headway yet. Having turned on
> #define DEBUG, I did notice that the code path for running ls on the
> root directory appears completely different to the code path for running
> ls on a sub-directory, and I think that latter path is being used to
> parse the root directory via the path /extlinux/../xxx. Judging purely
> by debug output, the code for the root directory appears to read n
> sectors (3 in my case) and dump directory entries from all of those
> sectors (my filesystem has quite a few files in the root), whereas the
> code for sub-directories appears to read and dump only a single sector,
> even when run on the root directory that needs 3 sectors dumped. That's
> the cause of the missing results from ls, but I haven't worked out
> what's triggering that in the code yet.
I think I saw a patch from you go by so it looks like you figured it out!
More information about the linux-rpi-kernel