Hi Stephen,
On 24 November 2014 at 20:38, Stephen Warren swarren@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@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 partition...)
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@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?
That's really odd. Did it work fine with bcm2835-rpi-b.dtb before this patch? Perhaps this is just a short/long-filename issue, so it'll seem like it randomly works sometimes and not others?
It did work with the plain zImage, but not with the device tree, so I don't think it's related to your patch. It actually looks like a bug in fatload, particularly as I can load the file if I don't give the path.
And let me just say that the zImage with dtb appended is an abomination of nature.
Anyway this doesn't seem to be related to this patch, so:
Reviewed-by: Simon Glass sjg@chromium.org Tested-by: Simon Glass sjg@chromium.org
Regards, Simon