Re: [U-Boot] [PATCH U-Boot] ARM: rpi_b: detect board revision
Hi Stephen, On 24 July 2015 at 00:26, Stephen Warren swar...@wwwdotorg.org wrote: On 11/24/2014 08:50 AM, Simon Glass wrote: Hi Stephen, On 18 November 2014 at 21:40, Stephen Warren swar...@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 swar...@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: 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. I think I saw a patch from you go by so it looks like you figured it out! Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH U-Boot] ARM: rpi_b: detect board revision
On 11/24/2014 08:50 AM, Simon Glass wrote: Hi Stephen, On 18 November 2014 at 21:40, Stephen Warren swar...@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 swar...@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: 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. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH U-Boot] ARM: rpi_b: detect board revision
Hi Stephen, On 18 November 2014 at 21:40, Stephen Warren swar...@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 swar...@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? Anyway this doesn't seem to be related to this patch, so: Reviewed-by: Simon Glass s...@chromium.org Tested-by: Simon Glass s...@chromium.org Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH U-Boot] ARM: rpi_b: detect board revision
On 11/24/2014 08:50 AM, Simon Glass wrote: Hi Stephen, On 18 November 2014 at 21:40, Stephen Warren swar...@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 swar...@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? Anyway this doesn't seem to be related to this patch, so: Reviewed-by: Simon Glass s...@chromium.org Tested-by: Simon Glass s...@chromium.org ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH U-Boot] ARM: rpi_b: detect board revision
Hi Stephen, On 24 November 2014 at 20:38, Stephen Warren swar...@wwwdotorg.org wrote: On 11/24/2014 08:50 AM, Simon Glass wrote: Hi Stephen, On 18 November 2014 at 21:40, Stephen Warren swar...@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 swar...@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 s...@chromium.org Tested-by: Simon Glass s...@chromium.org Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH U-Boot] ARM: rpi_b: detect board revision
On 11/18/2014 09:40 PM, Stephen Warren 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. 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. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH U-Boot] ARM: rpi_b: detect board revision
Am 19.11.2014 um 18:43 schrieb Stephen Warren: On 11/18/2014 09:40 PM, Stephen Warren 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. 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. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH U-Boot] 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.
Signed-off-by: Stephen Warren swar...@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(-)
diff --git a/arch/arm/include/asm/arch-bcm2835/mbox.h
b/arch/arm/include/asm/arch-bcm2835/mbox.h
index 61f427d914cd..0289ba6a917e 100644
--- a/arch/arm/include/asm/arch-bcm2835/mbox.h
+++ b/arch/arm/include/asm/arch-bcm2835/mbox.h
@@ -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=63t=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 0x00010003
struct bcm2835_mbox_tag_get_mac_address {
diff --git a/board/raspberrypi/rpi_b/rpi_b.c b/board/raspberrypi/rpi_b/rpi_b.c
index 7445f5318ad2..aaded88b4ba0 100644
--- a/board/raspberrypi/rpi_b/rpi_b.c
+++ b/board/raspberrypi/rpi_b/rpi_b.c
@@ -42,6 +42,12 @@ struct msg_get_arm_mem {
u32 end_tag;
};
+struct msg_get_board_rev {
+ struct bcm2835_mbox_hdr hdr;
+ struct bcm2835_mbox_tag_get_board_rev get_board_rev;
+ u32 end_tag;
+};
+
struct msg_get_mac_address {
struct bcm2835_mbox_hdr hdr;
struct bcm2835_mbox_tag_get_mac_address get_mac_address;
@@ -60,6 +66,67 @@ struct msg_get_clock_rate {
u32 end_tag;
};
+/* See comments in mbox.h for data source */
+static const struct {
+ const char *name;
+ const char *fdtfile;
+} models[] = {
+ [BCM2835_BOARD_REV_B_I2C0_2] = {
+ Model B (no P5),
+ bcm2835-rpi-b-i2c0.dtb,
+ },
+ [BCM2835_BOARD_REV_B_I2C0_3] = {
+ Model B (no P5),
+ bcm2835-rpi-b-i2c0.dtb,
+ },
+ [BCM2835_BOARD_REV_B_I2C1_4] = {
+ Model B,
+ bcm2835-rpi-b.dtb,
+ },
+ [BCM2835_BOARD_REV_B_I2C1_5] = {
+ Model B,
+ bcm2835-rpi-b.dtb,
+ },
+ [BCM2835_BOARD_REV_B_I2C1_6] = {
+ Model B,
+ bcm2835-rpi-b.dtb,
+ },
+ [BCM2835_BOARD_REV_A_7] = {
+ Model A,
+ bcm2835-rpi-a.dtb,
+ },
+ [BCM2835_BOARD_REV_A_8] = {
+ Model A,
+ bcm2835-rpi-a.dtb,
+ },
+ [BCM2835_BOARD_REV_A_9] = {
+ Model A,
+ bcm2835-rpi-a.dtb,
+ },
+ [BCM2835_BOARD_REV_B_REV2_d] = {
+ Model B rev2,
+ bcm2835-rpi-b-rev2.dtb,
+ },
+ [BCM2835_BOARD_REV_B_REV2_e] = {
+ Model B rev2,
+ bcm2835-rpi-b-rev2.dtb,
+ },
+ [BCM2835_BOARD_REV_B_REV2_f] = {
+ Model B rev2,
+ bcm2835-rpi-b-rev2.dtb,
+
