ARM: rpi_b: detect board revision
Subsystems (3)
PATCH 1/1 ARM: rpi_b: detect board revision
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.
---
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(-)
arch/arm/include/asm/arch-bcm2835/mbox.h +33 -0
@@ -119,6 +119,39 @@ struct bcm2835_mbox_tag_hdr {* }; */ +#define BCM2835_MBOX_TAG_GET_BOARD_REV 0x00010002 + +/* +* 0x2..0xf from: +* http://raspberryalphaomega.org.uk/2013/02/06/automatic-raspberry-pi-board-revision-detection-model-a-b1-and-b2/ +* http://www.raspberrypi.org/forums/viewtopic.php?f=63&t=32733 +* 0x10, 0x11 from swarren's testing +*/ +#define BCM2835_BOARD_REV_B_I2C0_2 0x2 +#define BCM2835_BOARD_REV_B_I2C0_3 0x3 +#define BCM2835_BOARD_REV_B_I2C1_4 0x4 +#define BCM2835_BOARD_REV_B_I2C1_5 0x5 +#define BCM2835_BOARD_REV_B_I2C1_6 0x6 +#define BCM2835_BOARD_REV_A_7 0x7 +#define BCM2835_BOARD_REV_A_8 0x8 +#define BCM2835_BOARD_REV_A_9 0x9 +#define BCM2835_BOARD_REV_B_REV2_d 0xd +#define BCM2835_BOARD_REV_B_REV2_e 0xe +#define BCM2835_BOARD_REV_B_REV2_f 0xf +#define BCM2835_BOARD_REV_B_PLUS 0x10 +#define BCM2835_BOARD_REV_CM 0x11 + +struct bcm2835_mbox_tag_get_board_rev { +struct bcm2835_mbox_tag_hdr tag_hdr; +union { +struct { + } req; +struct { +u32 rev; + } resp; + } body; +}; +#define BCM2835_MBOX_TAG_GET_MAC_ADDRESS 0x00010003struct bcm2835_mbox_tag_get_mac_address {
board/raspberrypi/rpi_b/rpi_b.c +119 -3
163 lines not on this page · raw message
include/configs/rpi_b.h +0 -1
@@ -176,7 +176,6 @@"pxefile_addr_r=0x00100000\0" \"kernel_addr_r=0x01000000\0" \"fdt_addr_r=0x02000000\0" \ -"fdtfile=bcm2835-rpi-b.dtb\0" \"ramdisk_addr_r=0x02100000\0" \ #define BOOT_TARGET_DEVICES(func) \
Signature · 1 line
1.9.1
PATCH 1/1 ARM: rpi_b: detect board revision
Quoted 14 lines · Stephen Warren
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...)
Quoted 3 lines
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.
BTW, I should have mentioned that I'm hoping the kernel people CC'd here will take a look at the DTB filenames this patch assumes, and comment on whether they seem reasonable. If so, we can formulate a patch for the kernel to actually create all those DTs in the nearish future.
PATCH 1/1 ARM: rpi_b: detect board revision
Am 19.11.2014 um 18:43 schrieb Stephen Warren:
Quoted 20 lines · Stephen Warren
Quoted 15 lines
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...)Quoted 3 lines
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.
Quoted 5 lines
BTW, I should have mentioned that I'm hoping the kernel people CC'd here will take a look at the DTB filenames this patch assumes, and comment on whether they seem reasonable. If so, we can formulate a patch for the kernel to actually create all those DTs in the nearish future.
The DTB filenames look good for me.
PATCH 1/1 ARM: rpi_b: detect board revision
In reply to Stephen WarrenHi Stephen,
Quoted 25 lines · Stephen Warren
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 <[email protected]>---
I'm considering renamingrpi_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.
Quoted 4 lines
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?
Anyway this doesn't seem to be related to this patch, so:
Regards,
Simon
PATCH 1/1 ARM: rpi_b: detect board revision
Quoted 33 lines · Simon Glass
Hi Stephen,
Quoted 25 lines · Stephen Warren
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 <[email protected]>---
I'm considering renamingrpi_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.Quoted 4 lines
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(-)
Quoted 7 lines
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?
Quoted 4 lines
Anyway this doesn't seem to be related to this patch, so:
Reviewed-by Simon Glass <[email protected]>Tested-by Simon Glass <[email protected]>
PATCH 1/1 ARM: rpi_b: detect board revision
Hi Stephen,
Quoted 37 lines · Stephen Warren
Quoted 36 lines · Simon Glass
Hi Stephen,
Quoted 25 lines · Stephen Warren
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 <[email protected]>---
I'm considering renamingrpi_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.Quoted 4 lines
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.
Quoted 8 lines
Quoted 4 lines
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.
Quoted 6 lines
Quoted 5 lines
Anyway this doesn't seem to be related to this patch, so:
Reviewed-by Simon Glass <[email protected]>Tested-by Simon Glass <[email protected]>
Regards,
Simon
PATCH 1/1 ARM: rpi_b: detect board revision
In reply to Simon GlassQuoted 33 lines · Simon Glass
Hi Stephen,
Quoted 25 lines · Stephen Warren
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 <[email protected]>---
I'm considering renamingrpi_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.Quoted 4 lines
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(-)
Quoted 7 lines
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:
http://lists.denx.de/pipermail/u-boot/2014-December/198471.html
[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.
PATCH 1/1 ARM: rpi_b: detect board revision
Hi Stephen,
Quoted 49 lines · Stephen Warren
Quoted 33 lines · Simon Glass
Hi Stephen,
Quoted 25 lines · Stephen Warren
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 <[email protected]>---
I'm considering renamingrpi_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.Quoted 4 lines
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(-)Quoted 7 lines
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:
http://lists.denx.de/pipermail/u-boot/2014-December/198471.html
[U-Boot] [PATCH] fs: fat: read: fix fat16 ls/read issue
Quoted 13 lines
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!
Regards,
Simon
Quoted 14 lines · Stephen Warren
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...)
Quoted 7 lines
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 <[email protected]>Reviewed-by Simon Glass <[email protected]>Tested-by Simon Glass <[email protected]>
Applied to u-boot/master, thanks!
Signature · 8 lines
Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: <http://lists.denx.de/pipermail/u-boot/attachments/20141208/5a618b91/attachment.pgp>