[U-Boot] [PATCH U-Boot] ARM: rpi_b: detect board revision

[U-Boot] [PATCH U-Boot] ARM: rpi_b: detect board revision

[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 <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(-)

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=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	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",
+	},
+	[BCM2835_BOARD_REV_B_PLUS] = {
+		"Model B+",
+		"bcm2835-rpi-b-plus.dtb",
+	},
+	[BCM2835_BOARD_REV_CM] = {
+		"Compute Module",
+		"bcm2835-rpi-cm.dtb",
+	},
+};
+
+u32 rpi_board_rev = 0;
+
 int dram_init(void)
 {
 	ALLOC_ALIGN_BUFFER(struct msg_get_arm_mem, msg, 1, 16);
@@ -79,13 +146,27 @@ int dram_init(void)
 	return 0;
 }
 
-int misc_init_r(void)
+static void set_fdtfile(void)
+{
+	const char *fdtfile;
+
+	if (getenv("fdtfile"))
+		return;
+
+	fdtfile = models[rpi_board_rev].fdtfile;
+	if (!fdtfile)
+		fdtfile = "bcm2835-rpi-other.dtb";
+
+	setenv("fdtfile", fdtfile);
+}
+
+static void set_usbethaddr(void)
 {
 	ALLOC_ALIGN_BUFFER(struct msg_get_mac_address, msg, 1, 16);
 	int ret;
 
 	if (getenv("usbethaddr"))
-		return 0;
+		return;
 
 	BCM2835_MBOX_INIT_HDR(msg);
 	BCM2835_MBOX_INIT_TAG(&msg->get_mac_address, GET_MAC_ADDRESS);
@@ -94,11 +175,18 @@ int misc_init_r(void)
 	if (ret) {
 		printf("bcm2835: Could not query MAC address\n");
 		/* Ignore error; not critical */
-		return 0;
+		return;
 	}
 
 	eth_setenv_enetaddr("usbethaddr", msg->get_mac_address.body.resp.mac);
 
+	return;
+}
+
+int misc_init_r(void)
+{
+	set_fdtfile();
+	set_usbethaddr();
 	return 0;
 }
 
@@ -126,8 +214,36 @@ static int power_on_module(u32 module)
 	return 0;
 }
 
+static void get_board_rev(void)
+{
+	ALLOC_ALIGN_BUFFER(struct msg_get_board_rev, msg, 1, 16);
+	int ret;
+	const char *name;
+
+	BCM2835_MBOX_INIT_HDR(msg);
+	BCM2835_MBOX_INIT_TAG(&msg->get_board_rev, GET_BOARD_REV);
+
+	ret = bcm2835_mbox_call_prop(BCM2835_MBOX_PROP_CHAN, &msg->hdr);
+	if (ret) {
+		printf("bcm2835: Could not query board revision\n");
+		/* Ignore error; not critical */
+		return;
+	}
+
+	rpi_board_rev = msg->get_board_rev.body.resp.rev;
+	if (rpi_board_rev >= ARRAY_SIZE(models))
+		rpi_board_rev = 0;
+
+	name = models[rpi_board_rev].name;
+	if (!name)
+		name = "Unknown model";
+	printf("RPI model: %s\n", name);
+}
+
 int board_init(void)
 {
+	get_board_rev();
+
 	gd->bd->bi_boot_params = 0x100;
 
 	return power_on_module(BCM2835_MBOX_POWER_DEVID_USB_HCD);
diff --git a/include/configs/rpi_b.h b/include/configs/rpi_b.h
index 7bf2bfe09a0b..841169cb6c97 100644
--- a/include/configs/rpi_b.h
+++ b/include/configs/rpi_b.h
@@ -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) \
-- 
1.9.1

[U-Boot] [PATCH U-Boot] ARM: rpi_b: detect board revision

[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.

[U-Boot] [PATCH U-Boot] ARM: rpi_b: detect board revision

[Matthias Klein]

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] [PATCH U-Boot] ARM: rpi_b: detect board revision

[Simon Glass]

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?

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

[U-Boot] [PATCH U-Boot] ARM: rpi_b: detect board revision

[Stephen Warren]

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?

> 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>

[U-Boot] [PATCH U-Boot] ARM: rpi_b: detect board revision

[Simon Glass]

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

[U-Boot] [U-Boot,U-Boot] ARM: rpi_b: detect board revision

[Tom Rini]

On Tue, Nov 18, 2014 at 09:40:21PM -0700, 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.
> 
> Signed-off-by: Stephen Warren <swarren@wwwdotorg.org>
> Reviewed-by: Simon Glass <sjg@chromium.org>
> Tested-by: Simon Glass <sjg@chromium.org>

Applied to u-boot/master, thanks!

-- 
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>

[U-Boot] [PATCH U-Boot] ARM: rpi_b: detect board revision

[Stephen Warren]

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?

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] [PATCH U-Boot] ARM: rpi_b: detect board revision

[Simon Glass]

Hi Stephen,

On 24 July 2015 at 00:26, 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?
>
> 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