From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephen Warren Date: Fri, 24 Jul 2015 00:26:01 -0600 Subject: [U-Boot] [PATCH U-Boot] ARM: rpi_b: detect board revision In-Reply-To: References: <1416372021-17997-1-git-send-email-swarren@wwwdotorg.org> Message-ID: <55B1DA79.8060401@wwwdotorg.org> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On 11/24/2014 08:50 AM, Simon Glass wrote: > Hi Stephen, > > On 18 November 2014 at 21:40, 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 >> --- >> 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.