| Message ID | 1416372021-17997-1-git-send-email-swarren@wwwdotorg.org |
|---|---|
| State | Accepted |
| Delegated to: | Tom Rini |
| Headers | show |
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.
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.
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
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>
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
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!
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.
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
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) \
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(-)