Re: [PATCH 1/4] board: beagle: beagleplay: Enable 32k crystal
On Mon, Feb 12, 2024 at 9:53 AM Nishanth Menon wrote: > > Enable the external 32k crystal similar to that found on other > production AM62X board. The trim settings for the crystal is board > dependent, so the sequences tend to be board specific. Since this is > a configuration that needs to be done prior to DM managing the system > and all other muxes get set, do the same from R5 context. > > Signed-off-by: Nishanth Menon Tested-by: Robert Nelson Yay, WiFi (wl18xx) now works on the BeaglePay with these 4 patches on top of v2024.01-rc1 debian@BeaglePlay-57:~$ dmesg | grep wl [1.892839] wlan_en: supplied by vdd_3v3 [8.437425] systemd[1]: Expecting device sys-subsystem-net-devices-wlan0.device - /sys/subsystem/net/devices/wlan0... [ 13.241739] wlcore: wl18xx HW: 183x or 180x, PG 2.2 (ROM 0x11) [ 13.246116] wlcore: WARNING Detected unconfigured mac address in nvs, derive from fuse instead. [ 13.246155] wlcore: WARNING This default nvs file can be removed from the file system [ 13.253088] wlcore: loaded [ 13.788451] wlcore: using inverted interrupt logic: 2 [ 13.842464] wlcore: PHY firmware version: Rev 8.2.0.0.243 [ 13.938371] wlcore: firmware booted (Rev 8.9.0.0.83) Regards, -- Robert Nelson https://rcn-ee.com/
Re: [PATCH] ARM: dts: am335x-pocketbeagle: choose tick-timer
On Wed, Aug 30, 2023 at 10:26 AM Trevor Woerner wrote:
>
> Commit 4b2be78ab66c ("time: Fix get_ticks being non-monotonic")
> requires '/chosen/tick-timer' in device-tree. Otherwise we get:
>
> U-Boot 2023.07.02 (Jul 11 2023 - 15:20:44 +)
>
> CPU : AM335X-GP rev 2.1
> Model: TI AM335x PocketBeagle
> DRAM: 512 MiB
> Core: 154 devices, 16 uclasses, devicetree: separate
> Could not initialize timer (err -19)
>
> resetting ...
>
> Suggested-by: Pierre Lebleu
> Signed-off-by: Trevor Woerner
Tested-by: Robert Nelson
> ---
> arch/arm/dts/am335x-pocketbeagle.dts | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm/dts/am335x-pocketbeagle.dts
> b/arch/arm/dts/am335x-pocketbeagle.dts
> index b379e3a5570d..02e3aac56064 100644
> --- a/arch/arm/dts/am335x-pocketbeagle.dts
> +++ b/arch/arm/dts/am335x-pocketbeagle.dts
> @@ -15,6 +15,7 @@
>
> chosen {
> stdout-path =
> + tick-timer =
> };
>
> leds {
> --
> 2.41.0.327.gaa9166bcc0ba
Thanks for posting this Trevor, I'm also running with this change..
Regards,
--
Robert Nelson
https://rcn-ee.com/
Re: [PATCH V4 8/8] doc: board: ti: Add BeaglePlay documentation
> > Just https://etcher.balena.io/ and flash an SD card with the official > > image here: https://www.beagleboard.org/distros/beagleplay-debian-11-flasher > > > > https://files.beagle.cc/file/beagleboard-public-2021/images/am625x-emmc-flasher-debian-11.6-xfce-arm64-2023-02-04-10gb.img.xz > > OK I tried that on an SD card, but it is still bricked. > Hi Simon, I've found the bootrom can be a little too quick and you'll get stuck on a failed eMMC bootloader. I find it best, with power applied, if you hold both the USR and RESET buttons down, then lift off the RESET button.. This will ensure the bootrom/sysboot will actually load the microSD's version of u-boot. If it's still failing, please grab this newer small August release: That's posted here: https://forum.beagleboard.org/t/arm64-debian-11-x-bullseye-monthly-snapshots-2023-08-05/32318 (updated monthly) Specifically this flasher file: https://rcn-ee.com/rootfs/release/2023-08-05/bullseye-minimal-arm64/beagleplay-emmc-flasher-debian-11.7-minimal-arm64-2023-08-05-4gb.img.xz Use Balena Etcher to write it directly to a microSD. Insert microSD in Apply Power (leds should turn on, if not hit the PWR button to wake up the TPS...) Next, hold both USR and RESET buttons Now, Lift off only the RESET button When even more leds turn on, lift up on the USR button. At this point the serial should be loading/booting linux, and then running the eMMC flasher in single user mode. Within 5 minutes or so, it should shutdown with a new image in the eMMC.. Regards, -- Robert Nelson https://rcn-ee.com/
Re: [RFC PATCH] board: ti: common: board_detect: Fix EEPROM read quirk for 2-byte
> >>> Tested on J721E, J7200, DRA7xx, AM64x > >> > >> I'll try to test this on the AM335x boards I have as soon as possible. > > > > I wonder if we should re-factor this code a bit and not have a single > > ti_i2c_eeprom_get but instead build for whichever sets of quirks a given > > family of boards has with their EEPROMs. I really worry that we're going > > to find that this change here breaks yet another different EEPROM than > > before. > > > > Yes that does make sense... considering a new behavior of EEPROM keeps > showing up. I will try refactoring the logic that way. Due to part shorages, sadly the BeagleBone AI64 (J721E) has both 1byte and 2byte eeproms in user hands today.. While I think most other previous designs have stuck with one type of eeprom throughout their production life. So just one big outlier that I personally know of.. Regards, -- Robert Nelson https://rcn-ee.com/
Re: [BISECTED] BeagleBone Black doesn't boot after a58147c2dbbf
On Fri, Aug 19, 2022 at 4:30 AM Nishanth Menon wrote:
>
> On 11:28-20220818, Matwey V. Kornilov wrote:
> > I've played a little and now I believe that the issue is that EEPROM read
> > addr
> > pointer is somehow corrupted due to 1-byte address write. The EEPROM is
> > definitely have two-byte read address accoring the datasheet.
> > I've failed to unravel exact rule what is happening when only one address
> > byte
> > is set, but was able to read random places of EEPROM.
> >
> >
> > However, the following diff makes the board bootable.
> >
> >
> > diff --git a/board/ti/common/board_detect.c b/board/ti/common/board_detect.c
> > index ed34991377..26edddccc6 100644
> > --- a/board/ti/common/board_detect.c
> > +++ b/board/ti/common/board_detect.c
> > @@ -86,7 +86,6 @@ __weak void gpi2c_init(void)
> > static int __maybe_unused ti_i2c_eeprom_get(int bus_addr, int dev_addr,
> > u32 header, u32 size, uint8_t
> > *ep)
> > {
> > - u32 hdr_read = 0xdeadbeef;
> > int rc;
> >
> > #if CONFIG_IS_ENABLED(DM_I2C)
> > @@ -113,10 +112,10 @@ static int __maybe_unused ti_i2c_eeprom_get(int
> > bus_addr, int dev_addr,
> > * We must allow for fall through to check the data if 2 byte
> > * addressing works
> > */
> > - (void)dm_i2c_read(dev, 0, (uint8_t *)_read, 4);
> > + rc = dm_i2c_read(dev, 0, ep, size);
> >
> > /* Corrupted data??? */
> > - if (hdr_read != header) {
> > + if (rc || (*((u32*)ep) != header)) {
> > /*
> > * read the eeprom header using i2c again, but use only a
> > * 2 byte address (some newer boards need this..)
> > @@ -125,16 +124,13 @@ static int __maybe_unused ti_i2c_eeprom_get(int
> > bus_addr, int dev_addr,
> > if (rc)
> > return rc;
> >
> > - rc = dm_i2c_read(dev, 0, (uint8_t *)_read, 4);
> > + rc = dm_i2c_read(dev, 0, ep, size);
> > if (rc)
> > return rc;
> > }
> > - if (hdr_read != header)
> > + if (*((u32*)ep) != header)
> > return -1;
> >
> > - rc = dm_i2c_read(dev, 0, ep, size);
> > - if (rc)
> > - return rc;
> > #else
> > u32 byte;
>
> This does work. I tested a few variations of boards to check this
> concept out.. but anyways.. on beaglebone black (element 14 boards):
>
> NOTE: This will improve detection times for 1 byte eeprom based boot,
> since there is no retry..
>
> However for boards with 2 byte addressing eeproms:
>
> master branch: https://pasteboard.co/n3P8yhSq6pem.png
> Time from first attempt to read eeprom to actual trigger of final eeprom
> read attempt: ~4ms
>
> With this patch: https://pasteboard.co/IVQzHwMuhc4p.png
> Time from first attempt to read eeprom to actual trigger of final eeprom
> read attempt: ~18ms
>
> IMHO, 14ms penalty is'nt a bad deal for dealing with variations of
> eeproms we are seeing in the wild.
>
> You can find the data (analog+digital capture) here:
> https://github.com/nmenon/data-captures/tree/main/i2c-eeprom-1byte-captures
> Tool used to capture (and view): https://www.saleae.com/downloads/
>
> Tom, Robert, folks: what do you folks think?
I'm okay with the delay. if we only had 'one' production run it would
be a different story.. But with 10 years of manufacturing, parts will
EOL and vary. Let's go with the safe slower route..
Regards,
--
Robert Nelson
https://rcn-ee.com/
Re: [BISECTED] BeagleBone Black doesn't boot after a58147c2dbbf
On Fri, Jul 29, 2022 at 12:07 PM Matwey V. Kornilov
wrote:
>
> пт, 29 июл. 2022 г. в 19:46, Tom Rini :
> >
> > On Fri, Jul 29, 2022 at 07:38:28PM +0300, Matwey V. Kornilov wrote:
> > > пт, 29 июл. 2022 г. в 19:32, Tom Rini :
> > > >
> > > > On Fri, Jul 29, 2022 at 07:20:11PM +0300, Matwey V. Kornilov wrote:
> > > >
> > > > > Hi,
> > > > >
> > > > > I've tried to build an am335x_evm_defconfig u-boot to use it on my
> > > > > BeagleBone Black board. Surprisingly, I've found that it doesn't work,
> > > > > I see the silent console: no messages even from SPL.
> > > > >
> > > > > Using bisect I've found that the following commit breaks the booting:
> > > > >
> > > > > a58147c2dbbf ("board: ti: common: board_detect: Do 1byte address
> > > > > checks first.")
> > > > >
> > > > > Could you please help me?
> > > >
> > > > Can you share some more details about which BeagleBone Black you have,
> > > > specifically the revision?
> > >
> > > It is an ordinary C revision. Unfortunately, I cannot remember who the
> > > producer was. As far as I know many companies made BeagleBone Black
> > > and EEPROM content can be different.
> >
> > OK, that'll help some. Can you see what the specific part number of the
> > EEPROM is? That might also help Nishanth figure out what to do here.
>
> Attached here is the EEPROM dump.
.U3.A335BNLT00C0
Ah, the "CO"... i'm pretty sure that board was made by Element14,
(they messed up the position of the "C") not that it really mattered
as the A335BNLT is only used..
Can you please take a quick snapshot of the eeprom, it should be...
24LC32AT-I/OT but maybe they used another variation..
Regards,
--
Robert Nelson
https://rcn-ee.com/
Re: [U-Boot] boot.bin on SD Card for SAMA5D3 Xplained
On Wed, Dec 5, 2018 at 8:37 AM wrote: > > > > On 05.12.2018 02:15, Daniel Evans wrote: > > Trying to get uboot SPL boot.bin to run on an SD card for the sama5d3 > > xplained board. All I get is RomBOOT and no other messages. I have tried > > throwing in a couple test pins to toggle in board_early_init_f but still > > not getting any debug. I can get at91bootstrap to produce a boot.bin that > > works on the sama5d3 xplained so I am assuming I don’t have a bad board. > > My boot partition is FAT16. To compile I just run the following on Debian > > Buster : > > > > make mrproper > > make sama5d3_xplained_mmc_defconfig > > make > > > > Cross Compiler is gcc-linaro-6.4.1-2018.05-x86_64_arm-linux-gnueabihf > > > > When finished compiling I just copy the boot.bin to my BOOT partition. > > > > Has to be something obvious that I am missing. Any insight is appreciated… > > Hello, > > Check the datasheet for sama5d3 SoC section 11.4.3. - Valid code > detection (my datasheet is dated 2 Feb 2016 if it helps) > > Basically the vector 6 needs to have hardcoded the binary size. Are you > doing that ? Otherwise the RomBOOT code will consider your binary as faulty. > > PS. make sure endianess is right, use a good hexeditor... > > Hope this helps, > Eugen Okay, just finished my git bisect, this turned out to be a miss-placed #endif when Wenyou did the "configs: at91: Remove CONFIG_SYS_EXTRA_OPTIONS assignment" patch: https://github.com/u-boot/u-boot/commit/5541543f686b43210fb92181003ff7175d4ab036#diff-651b6ffe22be4df459343a0d6d25154e => RomBOOT U-Boot spl 2019.01-rc1-00021-g2e2a2a5d4f-dirty (Dec 05 2018 - 14:30:22 -0600) Trying to boot from MMC1 U-Boot 2019.01-rc1-00021-g2e2a2a5d4f-dirty (Dec 05 2018 - 14:30:22 -0600) diff --git a/include/configs/sama5d3_xplained.h b/include/configs/sama5d3_xplained.h index d0d8087ca3..f87713319d 100644 --- a/include/configs/sama5d3_xplained.h +++ b/include/configs/sama5d3_xplained.h @@ -80,7 +80,6 @@ #elif CONFIG_NAND_BOOT #define CONFIG_SPL_NAND_DRIVERS #define CONFIG_SPL_NAND_BASE -#endif #define CONFIG_SYS_NAND_U_BOOT_OFFS0x4 #define CONFIG_SYS_NAND_5_ADDR_CYCLE #define CONFIG_SYS_NAND_PAGE_SIZE 0x800 @@ -91,3 +90,5 @@ #define CONFIG_SPL_GENERATE_ATMEL_PMECC_HEADER #endif + +#endif Before: #ifdef CONFIG_SYS_USE_MMC #define CONFIG_SYS_MMCSD_FS_BOOT_PARTITION 1 #define CONFIG_SPL_FS_LOAD_PAYLOAD_NAME "u-boot.img" #elif CONFIG_SYS_USE_NANDFLASH #define CONFIG_SPL_NAND_DRIVERS #define CONFIG_SPL_NAND_BASE #define CONFIG_SYS_NAND_U_BOOT_OFFS 0x4 #define CONFIG_SYS_NAND_5_ADDR_CYCLE #define CONFIG_SYS_NAND_PAGE_SIZE 0x800 #define CONFIG_SYS_NAND_PAGE_COUNT 64 #define CONFIG_SYS_NAND_OOBSIZE 64 #define CONFIG_SYS_NAND_BLOCK_SIZE 0x2 #define CONFIG_SYS_NAND_BAD_BLOCK_POS 0x0 #define CONFIG_SPL_GENERATE_ATMEL_PMECC_HEADER #endif After: #ifdef CONFIG_SD_BOOT #define CONFIG_SYS_MMCSD_FS_BOOT_PARTITION 1 #define CONFIG_SPL_FS_LOAD_PAYLOAD_NAME "u-boot.img" #elif CONFIG_NAND_BOOT #define CONFIG_SPL_NAND_DRIVERS #define CONFIG_SPL_NAND_BASE #endif <- WHY HERE #define CONFIG_SYS_NAND_U_BOOT_OFFS 0x4 #define CONFIG_SYS_NAND_5_ADDR_CYCLE #define CONFIG_SYS_NAND_PAGE_SIZE 0x800 #define CONFIG_SYS_NAND_PAGE_COUNT 64 #define CONFIG_SYS_NAND_OOBSIZE 64 #define CONFIG_SYS_NAND_BLOCK_SIZE 0x2 #define CONFIG_SYS_NAND_BAD_BLOCK_POS 0x0 #define CONFIG_SPL_GENERATE_ATMEL_PMECC_HEADER #endif Regards, -- Robert Nelson https://rcn-ee.com/ ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RFC] Make U-Boot log great again
On Fri, Feb 16, 2018 at 1:01 PM, Sam Protsenko
<semen.protse...@linaro.org> wrote:
> Hi guys,
>
> TL;DR This is a suggestion about fixing U-Boot log, which has got
> worse recently.
>
> Right now U-Boot and SPL logs are cluttered with bogus warnings like
> these (on X15 board, but I'm pretty sure it should appear on many
> others):
>
> Loading Environment from FAT...
> *** Warning - bad CRC, using default environment
> Failed (-5)
This one seems to cause the most confusion with end users. They like
to think it's a real bug, when in reality, "saveenv" and friends was
just never run from within u-boot or a separate environment partition
wasn't pre-programmed.
It's one of those bugs, users asked 10 years ago when the Beagle first
launched, yet users still ask from time to time..
>
> Those are the consequences of next commit:
>
> fb69464eae1e ("env: Allow to build multiple environments in Kconfig")
>
> Because of this commit, I can see following changes in my .config file:
>
> +CONFIG_ENV_IS_IN_FAT=y
> +CONFIG_ENV_FAT_INTERFACE="mmc"
> +CONFIG_ENV_FAT_DEVICE_AND_PART="0:1"
> +CONFIG_ENV_FAT_FILE="uboot.env"
>
> which led U-Boot to try and load the environment from different
> sources. I agree that it's good thing to do and can be useful, but the
> problem is that the code for loading the environment wasn't changed to
> handle errors properly.
>
> How I suggest to handle that case:
>
> 1. If we have two sources for the environment (e.g. FAT partition on
> SD card and some raw partition on eMMC), we shouldn't print error
> messages if we were unable to load the environment from one source
> 2. We should probably print some human-readable information that we
> didn't find the environment there, let's skip and look for next source
> (but don't print those warnings/failed messages)
> 3. And only print the error message in case when U-Boot environment
> wasn't found at all (on all possible sources).
>
> I don't have enough time to fix this by my own right now. But let's
> discuss how to approach this issue in a best way possible. And if
> someone wants to step forward and do that -- would be really nice. If
> no -- I can look into that later. But let's collect some opinions
> here, first.
I've also found, when you are dealing with multiple sources, it's nice
to print "where" you came from.
Otherwise, I've been known to make things way to verbose, but it's
easier to debug years later, when your adding a new family, or
overhauling when/how "overlays" are handled...
Regards,
--
Robert Nelson
https://rcn-ee.com/
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] mmc: Fix uninitialised priv member
On Fri, Feb 9, 2018 at 9:24 AM, Alex Kiernan <alex.kier...@gmail.com> wrote: > When using omap_hsmmc without the device model then the allocation > of mmc->priv ends up uninitialised. > > Signed-off-by: Alex Kiernan <alex.kier...@gmail.com> Awesome! This fixes: am335x_boneblack_defconfig Tested-by: Robert Nelson <robertcnel...@gmail.com> Regards, -- Robert Nelson https://rcn-ee.com/ ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] fs: btrfs: Fix unaligned memory accesses
On Thu, Jan 25, 2018 at 7:48 AM, Marek Behún <marek.be...@nic.cz> wrote: > Hi Alberto, > Thanks. I just forwarded this to Robert Nelson who encountered this > issue. > You can add Reviewed-by: Marek Behun <marek.be...@nic.cz> Weird, wonder how my email failed to go thru. Tested-by: Robert Nelson <robertcnel...@gmail.com> I've been running a few boards with btrfs/lzo enable this week, with this patch on top of v2018.01 and everythink looks great! Regards, -- Robert Nelson https://rcn-ee.com/ ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] fs: btrfs: Fix unaligned memory accesses
On Sat, Jan 20, 2018 at 1:17 AM, Alberto Sánchez Molero
<alsamol...@gmail.com> wrote:
> Loading files stored with lzo compression from a btrfs filesystem was
> producing unaligned memory accesses, which were causing a data abort
> and a reset on an Orange Pi Zero.
>
> The change in hash.c is not triggered by any error but follows the
> same pattern. Please confirm.
>
> Fixed according to doc/README.unaligned-memory-access.txt
Awesome!
Marek, this fixes the issue i was also seeing on the Beagle's with lzo
compression.
Tested-by: Robert Nelson <robertcnel...@gmail.com>
>
> Signed-off by: Alberto Sánchez Molero <alsamol...@gmail.com>
> ---
> fs/btrfs/compression.c | 5 +++--
> fs/btrfs/hash.c| 3 ++-
> 2 files changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/fs/btrfs/compression.c b/fs/btrfs/compression.c
> index a59ff5a..4e685a0 100644
> --- a/fs/btrfs/compression.c
> +++ b/fs/btrfs/compression.c
> @@ -9,6 +9,7 @@
> #include "btrfs.h"
> #include
> #include
> +#include
>
> static u32 decompress_lzo(const u8 *cbuf, u32 clen, u8 *dbuf, u32 dlen)
> {
> @@ -19,7 +20,7 @@ static u32 decompress_lzo(const u8 *cbuf, u32 clen,
> u8 *dbuf, u32 dlen)
> if (clen < 4)
> return -1;
>
> -tot_len = le32_to_cpu(*(u32 *) cbuf);
> +tot_len = le32_to_cpu(get_unaligned((u32 *) cbuf));
> cbuf += 4;
> clen -= 4;
> tot_len -= 4;
> @@ -32,7 +33,7 @@ static u32 decompress_lzo(const u8 *cbuf, u32 clen,
> u8 *dbuf, u32 dlen)
> res = 0;
>
> while (tot_len > 4) {
> -in_len = le32_to_cpu(*(u32 *) cbuf);
> +in_len = le32_to_cpu(get_unaligned((u32 *) cbuf));
> cbuf += 4;
> clen -= 4;
>
> diff --git a/fs/btrfs/hash.c b/fs/btrfs/hash.c
> index f8a50e5..1c75ea8 100644
> --- a/fs/btrfs/hash.c
> +++ b/fs/btrfs/hash.c
> @@ -8,6 +8,7 @@
>
> #include "btrfs.h"
> #include
> +#include
>
> static u32 btrfs_crc32c_table[256];
>
> @@ -34,5 +35,5 @@ u32 btrfs_csum_data(char *data, u32 seed, size_t len)
>
> void btrfs_csum_final(u32 crc, void *result)
> {
> -*((u32 *) result) = cpu_to_le32(~crc);
> +put_unaligned(cpu_to_le32(~crc), (u32 *) result);
> }
> --
> 2.16.0
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot
--
Robert Nelson
https://rcn-ee.com/
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] btrfs: data abort with lzo compression (armv7/am335x)
Hi Marek, On Fri, Dec 15, 2017 at 11:43 AM, Marek Behun <marek.be...@nic.cz> wrote: > Hi Robert, > can you upload somewhere the whole btrfs image of the partition so that > I can debug this? Thanks for offering to take a look at this: http://rcn-ee.online/builds/btrfs-lzo.img.xz Regards, -- Robert Nelson https://rcn-ee.com/ ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] btrfs: data abort with lzo compression (armv7/am335x)
Hi Marek, Having btrfs support in u-boot is awesome! With u-boot v2018.01-rc1 on our arm target (am335x) BeagleBone family, we are seeing a data abort with lzo compression. I'm wondering if you've seen something similar with your systems: ignore the "Failed to mount ext2 filesystem..." as we are using the genric "load" and extX support is built-in too.. loading /boot/vmlinuz-4.9.68-ti-r83 ... Failed to mount ext2 filesystem... data abort pc : [<9ff6eab8>]lr : [<>] reloc pc : [<80825ab8>]lr : [] sp : 9df28148 ip : 8202 fp : 0001f000 r10: 0d52 r9 : 9df28ed8 r8 : 82001000 r7 : 0001d12c r6 : 1000 r5 : 0001d2a6 r4 : 9df53fe2 r3 : 1000 r2 : 8200 r1 : 1000 r0 : Flags: nzCv IRQs off FIQs on Mode SVC_32 Resetting CPU ... resetting ... the other two options; no compress and zlib are working great in our single partition setup! Regards, -- Robert Nelson https://rcn-ee.com/ ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Makefile: Update minimum dtc version to 1.4.3
On Sat, Sep 23, 2017 at 8:49 PM, Bin Meng <bmeng...@gmail.com> wrote: > Hi Tom, > > On Sun, Sep 24, 2017 at 12:10 AM, Tom Rini <tr...@konsulko.com> wrote: >> On Sat, Sep 23, 2017 at 03:04:39PM +0200, Marek Vasut wrote: >>> On 09/23/2017 02:56 PM, Tom Rini wrote: >>> > On Sat, Sep 23, 2017 at 12:39:44PM +0200, Marek Vasut wrote: >>> >> On 09/22/2017 04:20 PM, Tom Rini wrote: >>> >>> On Fri, Sep 15, 2017 at 01:15:25PM -0400, Tom Rini wrote: >>> >>> >>> >>>> With support for overlays and calling the -@ flag to dtc we need to >>> >>>> have >>> >>>> at least 1.4.3 available now. >>> >>>> >>> >>>> Cc: Simon Glass <s...@chromium.org> >>> >>>> Reported-by: Stephen Warren <swar...@wwwdotorg.org> >>> >>>> Signed-off-by: Tom Rini <tr...@konsulko.com> >>> >>> >>> >>> Applied to u-boot/master, thanks! >>> >> >>> >> Debian still only has 1.4.2 even in unstable, so u-boot/master no longer >>> >> builds on any debian system. >>> > >>> > Then perhaps we need to mirror the kernel and provide / build dtc, but >>> > allow for people to override it. >>> >>> What about allowing old DTC version if DTOs are not in use ? >> >> If you can re-work the logic for that, sure, thanks! >> > > Ubuntu 16.04 LTS is still at dtc v1.4.0, so it's broken there too. Maybe it's just time to embed a copy of dtc into u-boot (like the kernel, especially since we use so many features...)? the device-tree-compiler package in debian (and thus ubuntu) doesn't get too much love: http://metadata.ftp-master.debian.org/changelogs/main/d/device-tree-compiler/unstable_changelog Regards, -- Robert Nelson https://rcn-ee.com/ ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, 1/2] board: ti: am57xx: Add dt support for BeagleBoard-X15 revC
On Mon, Aug 28, 2017 at 6:19 AM, Tom Rini <tr...@konsulko.com> wrote: > On Wed, Aug 23, 2017 at 11:39:06AM +0530, Lokesh Vutla wrote: > >> Add support for selecting proper dtb for >> am57xx BeagleBoard X15 revC u-boot from FIT >> >> Signed-off-by: Lokesh Vutla <lokeshvu...@ti.com> >> Reviewed-by: Tom Rini <tr...@konsulko.com> >> --- >> arch/arm/dts/Makefile | 1 + >> board/ti/am57xx/board.c | 3 +++ >> configs/am57xx_evm_defconfig| 2 +- >> configs/am57xx_hs_evm_defconfig | 2 +- >> 4 files changed, 6 insertions(+), 2 deletions(-) > > am57xx-beagle-x15-revc.dts isn't included, what series brings that in? > Thanks! it's pretty small, so got buried in: "arm: dts: dra7: sync DT with latest Linux" https://patchwork.ozlabs.org/patch/803942/ Regards, -- Robert Nelson https://rcn-ee.com/ ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 3/7] stm32: stm32f7: add spl build support
On Fri, Aug 18, 2017 at 4:28 PM, Vikas MANOCHA <vikas.mano...@st.com> wrote: > Hi Bo, > >> -Original Message- >> From: Bo Shen [mailto:voice.s...@gmail.com] >> Sent: Thursday, August 17, 2017 10:07 PM >> To: Robert Nelson <robertcnel...@gmail.com>; Vikas MANOCHA >> <vikas.mano...@st.com> >> Cc: U-Boot-Denx <u-boot@lists.denx.de>; Christophe PRIOUZEAU >> <christophe.priouz...@st.com>; Alexandre TORGUE >> <alexandre.tor...@st.com> >> Subject: Re: [U-Boot] [PATCH v2 3/7] stm32: stm32f7: add spl build support >> >> >> Hi Vikas, >>Try to remove this magic (press 'c' on the keyboard when at the boot >> time), > > It helps to select between U-Boot or OS booting. > >> I'd suggest to add a follow-up patch to move all the >> selected SPL related configuration from "arch/arm/mach-stm32/Kconfig" under >> STM32F7 to default configuration file (stm32f746- >> disco_defconfig). Then if the people want just boot up u-boot itself, what >> they need to do is just run "make menuconfig" and then de- >> select "Activate Falcon Mode" >> (SPL_OS_BOOT). Then everything will be fine. > > Yes, Agree. How about using "imply" instead of "select" for SPL_OS_BOOT to > make it configurable. Well, we really need a /doc/README.stm32 that explains this "different" default.. It's definitely different then omap/imx/tegra/atmel in this tree. But the processor is also more handicapped, so not wasting time in normal u-boot just booting the kernel via spl/falcon more makes sense. Regards, -- Robert Nelson https://rcn-ee.com/ ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 3/7] stm32: stm32f7: add spl build support
On Thu, Aug 10, 2017 at 1:10 PM, Vikas Manocha <vikas.mano...@st.com> wrote: > One other point, > > On 08/10/2017 11:07 AM, Vikas Manocha wrote: >> Hi Robert, >> >> On 08/10/2017 11:03 AM, Robert Nelson wrote: >>> Hi Vikas, >>> >>> On Sun, May 28, 2017 at 2:55 PM, Vikas Manocha <vikas.mano...@st.com> wrote: >>>> This commit supports booting from stm32 internal nor flash. spl U-Boot >>>> initializes the sdram memory, copies next image (e.g. standard U-Boot) >>>> to sdram & then jumps to entry point. >>>> >>>> Here are the flash memory addresses for U-Boot-spl & standard U-Boot: >>>> - spl U-Boot: 0x0800_ >>>> - standard U-Boot : 0x0800_8000 >>> >>> Is there another patchset missing on mainline for booting via spl? >> >> No, you just need to flash spl & next image at above mentioned addresses. By >> default spl expects kernel image. >> >> To boot u-boot, press keyboard character 'c'. >> you might need to keep on pressing 'c' it for some time as the keyboard >> entry acceptance & detection window is very small. >> >> Cheers, >> Vikas >> >>> >>> on mainline with the stm32f746-disco board: >>> >>> U-Boot SPL 2017.09-rc1-00177-gd529124fdc (Aug 10 2017 - 12:33:35) >>> Trying to boot from XIP >>> Hard fault >>> pc : 08008008lr : 08000adbxPSR : 2100 >>> r12 : 2004f338 r3 : 0005r2 : 081c >>> r1 : ff9ar0 : >>> Resetting CPU ... >>> >>> resetting ... >>> >>> I'm using openocd to program >>> >>> openocd -f board/stm32f7discovery.cfg \ >>> -c "init" \ >>> -c "reset init" \ >>> -c "flash probe 0" \ >>> -c "flash write_image erase ./spl/u-boot-spl.bin 0x0800" \ >>> -c "flash write_image erase ./u-boot.img 0x08008000" \ > > it should be u-boot-dtb.bin. Bingo! Thanks Vikas!! U-Boot SPL 2017.09-rc1-00177-gd529124fdc (Aug 10 2017 - 12:33:35) Trying to boot from XIP U-Boot 2017.09-rc1-00177-gd529124fdc (Aug 10 2017 - 12:33:35 -0500) Model: STMicroelectronics STM32F746-DISCO board DRAM: 8 MiB Flash: 1 MiB Using default environment In:serial@40011000 Out: serial@40011000 Err: serial@40011000 usr button is at LOW LEVEL Net: Warning: ethernet@40028000 (eth0) using random MAC address - 02:4a:de:c3:c8:80 eth0: ethernet@40028000 Hit SPACE in 3 seconds to stop autoboot. U-Boot > Regards, -- Robert Nelson https://rcn-ee.com/ ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 3/7] stm32: stm32f7: add spl build support
Hi Vikas, On Sun, May 28, 2017 at 2:55 PM, Vikas Manocha <vikas.mano...@st.com> wrote: > This commit supports booting from stm32 internal nor flash. spl U-Boot > initializes the sdram memory, copies next image (e.g. standard U-Boot) > to sdram & then jumps to entry point. > > Here are the flash memory addresses for U-Boot-spl & standard U-Boot: > - spl U-Boot: 0x0800_ > - standard U-Boot : 0x0800_8000 Is there another patchset missing on mainline for booting via spl? on mainline with the stm32f746-disco board: U-Boot SPL 2017.09-rc1-00177-gd529124fdc (Aug 10 2017 - 12:33:35) Trying to boot from XIP Hard fault pc : 08008008lr : 08000adbxPSR : 2100 r12 : 2004f338 r3 : 0005r2 : 081c r1 : ff9ar0 : Resetting CPU ... resetting ... I'm using openocd to program openocd -f board/stm32f7discovery.cfg \ -c "init" \ -c "reset init" \ -c "flash probe 0" \ -c "flash write_image erase ./spl/u-boot-spl.bin 0x0800" \ -c "flash write_image erase ./u-boot.img 0x08008000" \ -c "reset run" \ -c "shutdown" Regards, -- Robert Nelson https://rcn-ee.com/ ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] wandboard: Set fdt based on board_rev and board_name
On Mon, Jul 10, 2017 at 4:24 PM, Fabio Estevam <feste...@gmail.com> wrote: > On Mon, Jul 10, 2017 at 6:14 PM, Robert Nelson <robertcnel...@gmail.com> > wrote: > >> How do you guys want to do the revd1'? >> >> imx6<>-wandboard-revd1.dtb ? >> >> https://github.com/wandboard-org/linux/commit/e093a1186879eef78d91f22f1e47089565bde8e9 > > Looking at this dts it seems we only need to add a imx6qp variant. > > The other revd1 changes do not affect mainline as far as I can see. > > I don't have access to a imx6qp wandboard myself to mainline the dts. They added a real pmic, to the board: ;) https://github.com/wandboard-org/linux/commit/e093a1186879eef78d91f22f1e47089565bde8e9#diff-7ea50fb49a19acc65fa0f48cd855a153R328 I've recently picked up the quad/quadplus, but been to busy to test u-boot/kernel on it yet.. Regards, -- Robert Nelson https://rcn-ee.com/ ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] wandboard: Set fdt based on board_rev and board_name
On Mon, Jul 10, 2017 at 3:30 PM, Otavio Salvador <otavio.salva...@ossystems.com.br> wrote: > On Mon, Jul 10, 2017 at 5:14 PM, Fabio Estevam <feste...@gmail.com> wrote: >> On Mon, Jul 10, 2017 at 5:04 PM, Otavio Salvador >> <ota...@ossystems.com.br> wrote: >>> From: Fabio Berton <fabio.ber...@ossystems.com.br> >>> >>> New kernel linux-wandboard version 4.1.15_1.1.0_ga changed device tree >>> name adding board revision on file name. The new names are: >>> >>> - imx6dl-wandboard-revb1 >>> - imx6dl-wandboard-revc1 >>> - imx6q-wandboard-revb1 >>> - imx6q-wandboard-revc1 >>> >>> This fixes the Wandboard C1 revision device tree files. >>> >>> Signed-off-by: Fabio Berton <fabio.ber...@ossystems.com.br> >>> Signed-off-by: Otavio Salvador <ota...@ossystems.com.br> >>> --- >>> >>> include/configs/wandboard.h | 4 ++-- >>> 1 file changed, 2 insertions(+), 2 deletions(-) >>> >>> diff --git a/include/configs/wandboard.h b/include/configs/wandboard.h >>> index 2a6c6fbb70..4291be4068 100644 >>> --- a/include/configs/wandboard.h >>> +++ b/include/configs/wandboard.h >>> @@ -105,9 +105,9 @@ >>> "fi\0" \ >>> "findfdt="\ >>> "if test $board_name = C1 && test $board_rev = MX6Q ; then >>> " \ >>> - "setenv fdtfile imx6q-wandboard.dtb; fi; " \ >>> + "setenv fdtfile imx6q-wandboard-revc1.dtb; fi; " \ >> >> This breaks the usage of mainline kernel as there is no -revc1 suffix >> in the wandboard dtb files there. >> >> linux-wandboard needs to rename the dts files like mainline does: >> >> imx6q-wandboard.dtb (for rev C1) >> imx6q-wandboard-revb1.dtb >> imx6dl-wandboard.dtb (for rev C1) >> imx6dl-wandboard-revb1.dtb >> >> If they can't rename their dts, then they would need to carry this >> patch on their own U-Boot tree. > > No problem; I am sending it here so people can look and if there is > interest possibly help improving Wandboard kernel. We carry this on > u-boot-fslc fork so it is fine for me. How do you guys want to do the revd1'? imx6<>-wandboard-revd1.dtb ? https://github.com/wandboard-org/linux/commit/e093a1186879eef78d91f22f1e47089565bde8e9 (let's make sure we don't rename the dtb like we did in the revb1 -> revc1 era, that was shortsighted mess) Regards, -- Robert Nelson https://rcn-ee.com/ ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, v2, 4/4] arm: am33xx: Add support for mulitiple PLL input frequencies
On Fri, Jun 9, 2017 at 3:00 PM, Tom Rini <tr...@konsulko.com> wrote: > On Fri, Jun 09, 2017 at 02:45:32PM -0500, Robert Nelson wrote: >> > Ah, the problem with BBB is that it wants to boot from eMMC, not SD, >> > unless the button is pressed. It's possible, and I'd have to look at >> > the TRM and maybe the schematic, to see about changing the order, or >> > being able to remote boot it with a blank eMMC. >> >> The button is routed to the expansion header.. >> >> I've got a few hot-wired.. >> >> GND: P8_43 > > Ah, so if I wire P8_43 to ground, the button will always be pressed? > Neat, I need to go try that.. Correct! Then eMMC won't be even looked at: mmc1 mmc0 usart0 usb0 SPI0 mmc0 usb0 uart0 Regards, -- Robert Nelson https://rcn-ee.com/ ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, v2, 4/4] arm: am33xx: Add support for mulitiple PLL input frequencies
> Ah, the problem with BBB is that it wants to boot from eMMC, not SD, > unless the button is pressed. It's possible, and I'd have to look at > the TRM and maybe the schematic, to see about changing the order, or > being able to remote boot it with a blank eMMC. The button is routed to the expansion header.. I've got a few hot-wired.. GND: P8_43 Regards, -- Robert Nelson https://rcn-ee.com/ ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, v2, 4/4] arm: am33xx: Add support for mulitiple PLL input frequencies
On Wed, Jun 7, 2017 at 11:47 PM, Lokesh Vutla <lokeshvu...@ti.com> wrote:
>
>
> On Thursday 08 June 2017 12:20 AM, Emmanuel Vadot wrote:
>> On Fri, 12 May 2017 13:20:50 -0400
>> Tom Rini <tr...@konsulko.com> wrote:
>>
>>> On Fri, May 05, 2017 at 12:59:10PM +0530, Lokesh Vutla wrote:
>>>
>>>> am335x supports various sysclk frequencies which can be determined
>>>> using sysboot pins. PLLs should be configures based on this
>>>> sysclk frequency. Add PLL configurations for all supported
>>>> frequencies.
>>>>
>>>> Signed-off-by: Lokesh Vutla <lokeshvu...@ti.com>
>>>> Reviewed-by: Tom Rini <tr...@konsulko.com>
>>>
>>> Applied to u-boot/master, thanks!
>>>
>>> --
>>> Tom
>>
>> Hello,
>>
>> This appears to break beaglebone black support, reverting this commit
>> make u-boot works again.
>
> hmm..I see the problem. Here we are hard coding MPU freq to 1GHz even
> efuse say it is not supported(I am not sure why this is being done, may
> be Tom can give more details). Even in kernel I see that cpufreq is
> reading efuse to determine mpu frequency. Now that we have jitter
> optimized pll configurations, looks like unsupported freq is causing an
> issue. Can you see if the below patch helps?
>
> 8<--8<--
> From 519035c54cef3f9156303b70322c02f10ec69e00 Mon Sep 17 00:00:00 2001
> From: Lokesh Vutla <lokeshvu...@ti.com>
> Date: Thu, 8 Jun 2017 09:34:52 +0530
> Subject: [PATCH] board: am335x: Do not harcode mpu freq for beagleboneblack
>
> For all am335x boards the mpu frequency is determined by readin
> efuse. But for beagleboneblack it is hard coded to 1GHz
> irrespective of efuse settings. Due to which some boards
> fails to boot with not recommended frequency. Fix it to
> use efuse to determine mpu frequency.
>
> Signed-off-by: Lokesh Vutla <lokeshvu...@ti.com>
> ---
> board/ti/am335x/board.c | 10 --
> 1 file changed, 10 deletions(-)
>
> diff --git a/board/ti/am335x/board.c b/board/ti/am335x/board.c
> index 517965c0f0..4cf6617efb 100644
> --- a/board/ti/am335x/board.c
> +++ b/board/ti/am335x/board.c
> @@ -294,9 +294,6 @@ const struct dpll_params *get_dpll_mpu_params(void)
> if (bone_not_connected_to_ac_power())
> freq = MPUPLL_M_600;
>
> - if (board_is_bone_lt())
> - freq = MPUPLL_M_1000;
> -
> switch (freq) {
> case MPUPLL_M_1000:
> return _mpu_opp[ind][5];
> @@ -336,13 +333,6 @@ static void scale_vcores_bone(int freq)
> if (bone_not_connected_to_ac_power())
> freq = MPUPLL_M_600;
>
> - /*
> -* Override what we have detected since we know if we have
> -* a Beaglebone Black it supports 1GHz.
> -*/
> - if (board_is_bone_lt())
> - freq = MPUPLL_M_1000;
> -
> if (freq == MPUPLL_M_1000) {
> usb_cur_lim = TPS65217_USB_INPUT_CUR_LIMIT_1800MA;
> mpu_vdd = TPS65217_DCDC_VOLT_SEL_1325MV;
> --
> 2.11.0
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot
Tested-by: Robert Nelson <robertcnel...@gmail.com>
On my BBB A5A (2GB), PG 2.0 non-efused silicon..
***
U-Boot SPL 2017.07-rc1-00075-g156d64fa55-dirty (Jun 09 2017 - 12:31:11)
Trying to boot from MMC1
** Unable to use mmc 0:1 for loading the env **
Using default environment
U-Boot 2017.07-rc1-00075-g156d64fa55-dirty (Jun 09 2017 - 12:31:11 -0500)
CPU : AM335X-GP rev 2.0
Model: TI AM335x BeagleBone Black
DRAM: 512 MiB
NAND: 0 MiB
MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1
** Unable to use mmc 0:1 for loading the env **
Using default environment
ERROR: No USB device found
at drivers/usb/gadget/ether.c:2709/usb_ether_init()
not set. Validating first E-fuse MAC
Net: CACHE: Misaligned operation at range [9df32580, 9df32624]
eth0: ethernet@4a10
Hit any key to stop autoboot: 0
switch to partitions #0, OK
mmc0 is current device
SD/MMC found on device 0
** File not found boot.scr **
** Unrecognized filesystem type **
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
switch to partitions #0, OK
***
Regards,
--
Robert Nelson
https://rcn-ee.com/
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, v2, 4/4] arm: am33xx: Add support for mulitiple PLL input frequencies
On Wed, Jun 7, 2017 at 11:47 PM, Lokesh Vutla <lokeshvu...@ti.com> wrote: > > > On Thursday 08 June 2017 12:20 AM, Emmanuel Vadot wrote: >> On Fri, 12 May 2017 13:20:50 -0400 >> Tom Rini <tr...@konsulko.com> wrote: >> >>> On Fri, May 05, 2017 at 12:59:10PM +0530, Lokesh Vutla wrote: >>> >>>> am335x supports various sysclk frequencies which can be determined >>>> using sysboot pins. PLLs should be configures based on this >>>> sysclk frequency. Add PLL configurations for all supported >>>> frequencies. >>>> >>>> Signed-off-by: Lokesh Vutla <lokeshvu...@ti.com> >>>> Reviewed-by: Tom Rini <tr...@konsulko.com> >>> >>> Applied to u-boot/master, thanks! >>> >>> -- >>> Tom >> >> Hello, >> >> This appears to break beaglebone black support, reverting this commit >> make u-boot works again. > > hmm..I see the problem. Here we are hard coding MPU freq to 1GHz even > efuse say it is not supported(I am not sure why this is being done, may > be Tom can give more details). Even in kernel I see that cpufreq is > reading efuse to determine mpu frequency. Now that we have jitter > optimized pll configurations, looks like unsupported freq is causing an > issue. Can you see if the below patch helps? In the kernel, we are re-enabling the 1GHz option in the BoneBlack's device tree blob: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/arch/arm/boot/dts/am335x-boneblack.dts?h=v4.12-rc4=bc4b1736f246102e84ce6d3f1a32f614ae27d81f Regards, -- Robert Nelson https://rcn-ee.com/ ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, v2, 4/4] arm: am33xx: Add support for mulitiple PLL input frequencies
On Thu, Jun 8, 2017 at 7:45 PM, Tom Rini <tr...@konsulko.com> wrote: > On Thu, Jun 08, 2017 at 10:17:09AM +0530, Lokesh Vutla wrote: >> >> >> On Thursday 08 June 2017 12:20 AM, Emmanuel Vadot wrote: >> > On Fri, 12 May 2017 13:20:50 -0400 >> > Tom Rini <tr...@konsulko.com> wrote: >> > >> >> On Fri, May 05, 2017 at 12:59:10PM +0530, Lokesh Vutla wrote: >> >> >> >>> am335x supports various sysclk frequencies which can be determined >> >>> using sysboot pins. PLLs should be configures based on this >> >>> sysclk frequency. Add PLL configurations for all supported >> >>> frequencies. >> >>> >> >>> Signed-off-by: Lokesh Vutla <lokeshvu...@ti.com> >> >>> Reviewed-by: Tom Rini <tr...@konsulko.com> >> >> >> >> Applied to u-boot/master, thanks! >> >> >> >> -- >> >> Tom >> > >> > Hello, >> > >> > This appears to break beaglebone black support, reverting this commit >> > make u-boot works again. >> >> hmm..I see the problem. Here we are hard coding MPU freq to 1GHz even >> efuse say it is not supported(I am not sure why this is being done, may >> be Tom can give more details). Even in kernel I see that cpufreq is >> reading efuse to determine mpu frequency. Now that we have jitter >> optimized pll configurations, looks like unsupported freq is causing an >> issue. Can you see if the below patch helps? > > Well, in the kernel, did anyone poke the Beagleboard folks about this, > before pushing the change? There's BBB shipping with chips that did not > have their efuses set, hence the way things were structured in U-Boot. Part of the fun, most shipping BeagleBone and Varients have the proper efuse'ed silicon nowadays.. I think all my Rev B's (2GB eMMC which all 100% have the non-efused silicon) are in my up-time test farm at home. I might have an old one somewhere here at work. But yes, all BeagleBone am335x's where pinned at TI for 1Ghz support before TI started efuse'ing Regards, -- Robert Nelson https://rcn-ee.com/ ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] config: am335x_evm: detect Black Wireless using BWA
On Wed, Apr 5, 2017 at 11:50 AM, Robert Nelson <robertcnel...@gmail.com> wrote: > On Wed, Apr 5, 2017 at 11:14 AM, Peter Robinson <pbrobin...@gmail.com> wrote: >> "On Thu, Mar 30, 2017 at 8:29 PM, Robert Nelson <robertcnel...@gmail.com> >> wrote: >>> BeagleBone Black Wireless is clone of the BeagleBone Black (BBB) with >>> the Ethernet replaced by a TI wl1835 wireless module. >>> >>> This board can be indentified by the BWAx value after A335BNLT (BBB) >>> in the at24 eeprom: >>> BWAx [aa 55 33 ee 41 33 33 35 42 4e 4c 54 42 57 41 35 |.U3.A335BNLTBWA5|] >>> >>> http://beagleboard.org/black-wireless >>> https://github.com/beagleboard/beaglebone-black-wireless >>> >>> firmware: >>> https://github.com/beagleboard/beaglebone-black-wireless/tree/master/firmware >>> wl18xx mac address: >>> /proc/device-tree/ocp/ethernet@4a10/slave@4a100200/mac-address >>> >>> Signed-off-by: Robert Nelson <robertcnel...@gmail.com> >>> CC: Tom Rini <tr...@konsulko.com> >>> CC: Jason Kridner <jkrid...@beagleboard.org> >>> CC: Will Newton <wi...@resin.io> >>> --- >>> board/ti/am335x/board.c | 7 +++ >>> include/configs/am335x_evm.h | 2 ++ >> >> Shouldn't this also update "CONFIG_OF_LIST="am335x-evm am335x-bone >> am335x-boneblack am335x-evmsk am335x-bonegreen am335x-icev2"" in >> configs/am335x_evm_defconfig ans possibly other am33xx_ configs? > > Hi Peter, > > Currently these patches rely on "CONFIG_OF_CONTROL" being disabled > (non-device-tree boot, aka the old boot method), after we resync with > kernel.org's ti/omap device tree changes. We can go back and enable > device-tree boot for these new devices. and side note, with CONFIG_OF_CONTROL enabled with these patches, they'll still just use "am335x-boneblack.dtb" in spl/device-tree boot mode.. Since they share the black's eeprom base identifier. Regards, -- Robert Nelson https://rcn-ee.com/ ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] config: am335x_evm: detect Black Wireless using BWA
On Wed, Apr 5, 2017 at 11:14 AM, Peter Robinson <pbrobin...@gmail.com> wrote: > "On Thu, Mar 30, 2017 at 8:29 PM, Robert Nelson <robertcnel...@gmail.com> > wrote: >> BeagleBone Black Wireless is clone of the BeagleBone Black (BBB) with >> the Ethernet replaced by a TI wl1835 wireless module. >> >> This board can be indentified by the BWAx value after A335BNLT (BBB) >> in the at24 eeprom: >> BWAx [aa 55 33 ee 41 33 33 35 42 4e 4c 54 42 57 41 35 |.U3.A335BNLTBWA5|] >> >> http://beagleboard.org/black-wireless >> https://github.com/beagleboard/beaglebone-black-wireless >> >> firmware: >> https://github.com/beagleboard/beaglebone-black-wireless/tree/master/firmware >> wl18xx mac address: >> /proc/device-tree/ocp/ethernet@4a10/slave@4a100200/mac-address >> >> Signed-off-by: Robert Nelson <robertcnel...@gmail.com> >> CC: Tom Rini <tr...@konsulko.com> >> CC: Jason Kridner <jkrid...@beagleboard.org> >> CC: Will Newton <wi...@resin.io> >> --- >> board/ti/am335x/board.c | 7 +++ >> include/configs/am335x_evm.h | 2 ++ > > Shouldn't this also update "CONFIG_OF_LIST="am335x-evm am335x-bone > am335x-boneblack am335x-evmsk am335x-bonegreen am335x-icev2"" in > configs/am335x_evm_defconfig ans possibly other am33xx_ configs? Hi Peter, Currently these patches rely on "CONFIG_OF_CONTROL" being disabled (non-device-tree boot, aka the old boot method), after we resync with kernel.org's ti/omap device tree changes. We can go back and enable device-tree boot for these new devices. Regards, -- Robert Nelson https://rcn-ee.com/ ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] config: am335x_evm: detect Black Wireless using BWA
fyi: these are board only, SPL/device tree will need a bigger resync
on am33xx from kernel.rog
Regards,
On Thu, Mar 30, 2017 at 2:29 PM, Robert Nelson <robertcnel...@gmail.com> wrote:
> BeagleBone Black Wireless is clone of the BeagleBone Black (BBB) with
> the Ethernet replaced by a TI wl1835 wireless module.
>
> This board can be indentified by the BWAx value after A335BNLT (BBB)
> in the at24 eeprom:
> BWAx [aa 55 33 ee 41 33 33 35 42 4e 4c 54 42 57 41 35 |.U3.A335BNLTBWA5|]
>
> http://beagleboard.org/black-wireless
> https://github.com/beagleboard/beaglebone-black-wireless
>
> firmware:
> https://github.com/beagleboard/beaglebone-black-wireless/tree/master/firmware
> wl18xx mac address:
> /proc/device-tree/ocp/ethernet@4a10/slave@4a100200/mac-address
>
> Signed-off-by: Robert Nelson <robertcnel...@gmail.com>
> CC: Tom Rini <tr...@konsulko.com>
> CC: Jason Kridner <jkrid...@beagleboard.org>
> CC: Will Newton <wi...@resin.io>
> ---
> board/ti/am335x/board.c | 7 +++
> include/configs/am335x_evm.h | 2 ++
> 2 files changed, 9 insertions(+)
>
> diff --git a/board/ti/am335x/board.c b/board/ti/am335x/board.c
> index 8eaf3e9a5c..304ae34fb7 100644
> --- a/board/ti/am335x/board.c
> +++ b/board/ti/am335x/board.c
> @@ -651,6 +651,13 @@ int board_late_init(void)
> #ifdef CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG
> char *name = NULL;
>
> + if (board_is_bone_lt()) {
> + /* BeagleBoard.org BeagleBone Black Wireless: */
> + if (!strncmp(board_ti_get_rev(), "BWA", 3)) {
> + name = "BBBW";
> + }
> + }
> +
> if (board_is_bbg1())
> name = "BBG1";
> set_board_info_env(name);
> diff --git a/include/configs/am335x_evm.h b/include/configs/am335x_evm.h
> index 27126871f7..dcac2f5816 100644
> --- a/include/configs/am335x_evm.h
> +++ b/include/configs/am335x_evm.h
> @@ -138,6 +138,8 @@
> "setenv fdtfile am335x-bone.dtb; fi; " \
> "if test $board_name = A335BNLT; then " \
> "setenv fdtfile am335x-boneblack.dtb; fi; " \
> + "if test $board_name = BBBW; then " \
> + "setenv fdtfile am335x-boneblack-wireless.dtb; fi; " \
> "if test $board_name = BBG1; then " \
> "setenv fdtfile am335x-bonegreen.dtb; fi; " \
> "if test $board_name = A33515BB; then " \
> --
> 2.11.0
>
--
Robert Nelson
https://rcn-ee.com/
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 2/3] config: am335x_evm: detect Green Wireless using GW1
SeeedStudio BeagleBone Green Wireless (BBGW) is an expansion of the
SeeedStudio Green (BBG) with the Ethernet replaced by a TI wl1835
wireless module.
This board can be indentified by the GW1x value after A335BNLT (BBB)
in the at24 eeprom:
GW1x [aa 55 33 ee 41 33 33 35 42 4e 4c 54 47 57 31 41 |.U3.A335BNLTGW1A|]
http://beagleboard.org/green-wireless
http://wiki.seeed.cc/BeagleBone_Green_Wireless/
firmware:
https://github.com/beagleboard/beaglebone-black-wireless/tree/master/firmware
wl18xx mac address: Stored in at24 eeprom at address 5-16:
hexdump -e '8/1 "%c"' /sys/bus/i2c/devices/0-0050/eeprom | cut -b 5-16
Signed-off-by: Robert Nelson <robertcnel...@gmail.com>
CC: Tom Rini <tr...@konsulko.com>
CC: Jason Kridner <jkrid...@beagleboard.org>
CC: Will Newton <wi...@resin.io>
---
board/ti/am335x/board.c | 4
include/configs/am335x_evm.h | 2 ++
2 files changed, 6 insertions(+)
diff --git a/board/ti/am335x/board.c b/board/ti/am335x/board.c
index 304ae34fb7..54589638b3 100644
--- a/board/ti/am335x/board.c
+++ b/board/ti/am335x/board.c
@@ -656,6 +656,10 @@ int board_late_init(void)
if (!strncmp(board_ti_get_rev(), "BWA", 3)) {
name = "BBBW";
}
+ /* SeeedStudio BeagleBone Green Wireless */
+ if (!strncmp(board_ti_get_rev(), "GW1", 3)) {
+ name = "BBGW";
+ }
}
if (board_is_bbg1())
diff --git a/include/configs/am335x_evm.h b/include/configs/am335x_evm.h
index dcac2f5816..d90c5156d3 100644
--- a/include/configs/am335x_evm.h
+++ b/include/configs/am335x_evm.h
@@ -142,6 +142,8 @@
"setenv fdtfile am335x-boneblack-wireless.dtb; fi; " \
"if test $board_name = BBG1; then " \
"setenv fdtfile am335x-bonegreen.dtb; fi; " \
+ "if test $board_name = BBGW; then " \
+ "setenv fdtfile am335x-bonegreen-wireless.dtb; fi; " \
"if test $board_name = A33515BB; then " \
"setenv fdtfile am335x-evm.dtb; fi; " \
"if test $board_name = A335X_SK; then " \
--
2.11.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 3/3] config: am335x_evm: detect BeagleBone Blue using BLA
BeagleBone Blue is next grenation of boards from BeagleBoard.org, focusing
on robotics with a TI wl1835 wireless module for connectivity.
This board can be indentified by the BLAx value after A335BNLT (BBB)
in the at24 eeprom:
BLAx: [aa 55 33 ee 41 33 33 35 42 4e 4c 54 42 4c 41 30 |.U3.A335BNLTBLA2|]
http://beagleboard.org/blue
https://github.com/beagleboard/beaglebone-blue
firmware:
https://github.com/beagleboard/beaglebone-black-wireless/tree/master/firmware
wl18xx mac address:
/proc/device-tree/ocp/ethernet@4a10/slave@4a100200/mac-address
Signed-off-by: Robert Nelson <robertcnel...@gmail.com>
CC: Tom Rini <tr...@konsulko.com>
CC: Jason Kridner <jkrid...@beagleboard.org>
CC: Will Newton <wi...@resin.io>
---
board/ti/am335x/board.c | 4
include/configs/am335x_evm.h | 2 ++
2 files changed, 6 insertions(+)
diff --git a/board/ti/am335x/board.c b/board/ti/am335x/board.c
index 54589638b3..3e842d3187 100644
--- a/board/ti/am335x/board.c
+++ b/board/ti/am335x/board.c
@@ -660,6 +660,10 @@ int board_late_init(void)
if (!strncmp(board_ti_get_rev(), "GW1", 3)) {
name = "BBGW";
}
+ /* BeagleBoard.org BeagleBone Blue */
+ if (!strncmp(board_ti_get_rev(), "BLA", 3)) {
+ name = "BBBL";
+ }
}
if (board_is_bbg1())
diff --git a/include/configs/am335x_evm.h b/include/configs/am335x_evm.h
index d90c5156d3..5fbc1e3ff9 100644
--- a/include/configs/am335x_evm.h
+++ b/include/configs/am335x_evm.h
@@ -144,6 +144,8 @@
"setenv fdtfile am335x-bonegreen.dtb; fi; " \
"if test $board_name = BBGW; then " \
"setenv fdtfile am335x-bonegreen-wireless.dtb; fi; " \
+ "if test $board_name = BBBL; then " \
+ "setenv fdtfile am335x-boneblue.dtb; fi; " \
"if test $board_name = A33515BB; then " \
"setenv fdtfile am335x-evm.dtb; fi; " \
"if test $board_name = A335X_SK; then " \
--
2.11.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/3] config: am335x_evm: detect Black Wireless using BWA
BeagleBone Black Wireless is clone of the BeagleBone Black (BBB) with
the Ethernet replaced by a TI wl1835 wireless module.
This board can be indentified by the BWAx value after A335BNLT (BBB)
in the at24 eeprom:
BWAx [aa 55 33 ee 41 33 33 35 42 4e 4c 54 42 57 41 35 |.U3.A335BNLTBWA5|]
http://beagleboard.org/black-wireless
https://github.com/beagleboard/beaglebone-black-wireless
firmware:
https://github.com/beagleboard/beaglebone-black-wireless/tree/master/firmware
wl18xx mac address:
/proc/device-tree/ocp/ethernet@4a10/slave@4a100200/mac-address
Signed-off-by: Robert Nelson <robertcnel...@gmail.com>
CC: Tom Rini <tr...@konsulko.com>
CC: Jason Kridner <jkrid...@beagleboard.org>
CC: Will Newton <wi...@resin.io>
---
board/ti/am335x/board.c | 7 +++
include/configs/am335x_evm.h | 2 ++
2 files changed, 9 insertions(+)
diff --git a/board/ti/am335x/board.c b/board/ti/am335x/board.c
index 8eaf3e9a5c..304ae34fb7 100644
--- a/board/ti/am335x/board.c
+++ b/board/ti/am335x/board.c
@@ -651,6 +651,13 @@ int board_late_init(void)
#ifdef CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG
char *name = NULL;
+ if (board_is_bone_lt()) {
+ /* BeagleBoard.org BeagleBone Black Wireless: */
+ if (!strncmp(board_ti_get_rev(), "BWA", 3)) {
+ name = "BBBW";
+ }
+ }
+
if (board_is_bbg1())
name = "BBG1";
set_board_info_env(name);
diff --git a/include/configs/am335x_evm.h b/include/configs/am335x_evm.h
index 27126871f7..dcac2f5816 100644
--- a/include/configs/am335x_evm.h
+++ b/include/configs/am335x_evm.h
@@ -138,6 +138,8 @@
"setenv fdtfile am335x-bone.dtb; fi; " \
"if test $board_name = A335BNLT; then " \
"setenv fdtfile am335x-boneblack.dtb; fi; " \
+ "if test $board_name = BBBW; then " \
+ "setenv fdtfile am335x-boneblack-wireless.dtb; fi; " \
"if test $board_name = BBG1; then " \
"setenv fdtfile am335x-bonegreen.dtb; fi; " \
"if test $board_name = A33515BB; then " \
--
2.11.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] travis-ci: Temporarily disable using a newer device tree compiler
On Sun, Feb 26, 2017 at 11:29 PM, Heiko Schocher <h...@denx.de> wrote: > Hello Robert, > > Am 27.02.2017 um 05:34 schrieb Robert Nelson: >> >> On Sun, Feb 26, 2017 at 7:37 PM, Tom Rini <tr...@konsulko.com> wrote: >>> >>> On Sun, Feb 26, 2017 at 08:01:19PM -0500, Tom Rini wrote: >>> >>>> For a long while dtc has warned about various constructs. This is now >>>> leading to log file size being exceeded in travis, and as the majority >>>> of these errors need to be fixed in the kernel, switch to using the >>>> stock device-tree-compiler package. >>>> >>>> Signed-off-by: Tom Rini <tr...@konsulko.com> >>> >>> >>> Applied to u-boot/master, thanks! >>> >>> But I'm not happy to have to apply it, either. I do not wish to break >>> travis-ci, but sun7i is now exceeding the allowed stdout size. And >>> these are problems that need to be fixed in the kernel first, rather >>> than here first. The patches to fix u-boot local issues (such as x86 >>> never got picked up either, but likely need to be respun. I expect that >>> once the new DTC version is tagged and populated upstream in the kernel >>> as well, we will be able to re-enable the changes we had here. >> >> >> This was fixed (aka a hidden bandaid) in the linux kernel via: >> >> >> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/scripts/Makefile.lib?id=bc553986a2f7c56d0de811485d5312ea29692d5d > > > Heh... IIRC, I tried to fix a lot of this messages (in U-Boot), around > a year ago, and we decided to not apply them in u-boot, instead they > should go away via kernel resyncs, when the warnings are fixed in the > kernel! > > Also I think, I tried a similiar approach as the commit you mentioned... > Ah, yes, here: > http://lists.denx.de/pipermail/u-boot/2016-April/252408.html > > We decided (for u-boot) it would be better to fix the problems and > not supress the warning, but it seems, the problems get not really fixed > in the kernel ... > > I wasn;t aware of the above patch in the kernel... thanks for pointing! and i think by moving the kernel to disable that patch, it's slowed down the number of register fix patches.. ps, this just came in on kbuild list just a few minutes ago: https://marc.info/?l=linux-kbuild=148817429929267=2 one of the issues with bc553986a2f7c56d0de811485d5312ea29692d5d is that it breaks the build with older version of dtc that don't know what to do with the -Wno-unit_address_vs_reg flag.. Regards, -- Robert Nelson https://rcn-ee.com/ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] travis-ci: Temporarily disable using a newer device tree compiler
On Sun, Feb 26, 2017 at 7:37 PM, Tom Rini <tr...@konsulko.com> wrote: > On Sun, Feb 26, 2017 at 08:01:19PM -0500, Tom Rini wrote: > >> For a long while dtc has warned about various constructs. This is now >> leading to log file size being exceeded in travis, and as the majority >> of these errors need to be fixed in the kernel, switch to using the >> stock device-tree-compiler package. >> >> Signed-off-by: Tom Rini <tr...@konsulko.com> > > Applied to u-boot/master, thanks! > > But I'm not happy to have to apply it, either. I do not wish to break > travis-ci, but sun7i is now exceeding the allowed stdout size. And > these are problems that need to be fixed in the kernel first, rather > than here first. The patches to fix u-boot local issues (such as x86 > never got picked up either, but likely need to be respun. I expect that > once the new DTC version is tagged and populated upstream in the kernel > as well, we will be able to re-enable the changes we had here. This was fixed (aka a hidden bandaid) in the linux kernel via: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/scripts/Makefile.lib?id=bc553986a2f7c56d0de811485d5312ea29692d5d Regards, -- Robert Nelson https://rcn-ee.com/ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] configs/wandboard.h: fix dtb file name for findfdt.
Hi Adam,
On Mon, Jul 18, 2016 at 10:45 AM, Adam Duskett <adamdusk...@outlook.com>
wrote:
> With the release of kernel 4.1.15 for the imx6 line of processors,
> wandboard now uses imx6q-wandboard-revc1.dtb and
> imx6dl-wandboard-revc1.dtb.
> This patch fixes the naming convention to work with kernel 4.1.15
>
> Signed-off-by: Adam Duskett <adamdusk...@outlook.com>
> ---
> include/configs/wandboard.h | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/include/configs/wandboard.h b/include/configs/wandboard.h
> index 99f5c0c..d41b600 100644
> --- a/include/configs/wandboard.h
> +++ b/include/configs/wandboard.h
> @@ -135,9 +135,9 @@
> "setenv bootargs ${bootargs} ${fbmem}\0" \
> "findfdt="\
> "if test $board_name = C1 && test $board_rev = MX6Q ; then
> " \
> - "setenv fdtfile imx6q-wandboard.dtb; fi; " \
> + "setenv fdtfile imx6q-wandboard-revc1.dtb; fi; " \
> "if test $board_name = C1 && test $board_rev = MX6DL ;
> then " \
> - "setenv fdtfile imx6dl-wandboard.dtb; fi; " \
> + "setenv fdtfile imx6dl-wandboard-revc1.dtb; fi; " \
> "if test $board_name = B1 && test $board_rev = MX6Q ; then
> " \
> "setenv fdtfile imx6q-wandboard-revb1.dtb; fi; " \
> "if test $board_name = B1 && test $board_rev = MX6DL ;
> then " \
>
NAK, This breaks mainline:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/Makefile?id=refs/tags/v4.7-rc7#n338
imx6dl-wandboard.dtb \
imx6dl-wandboard-revb1.dtb \
imx6q-wandboard.dtb \
imx6q-wandboard-revb1.dtb \
Regards,
--
Robert Nelson
https://rcn-ee.com/
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Problem loading boot script from ext4 mmc on sunxi H3
On Wed, Jun 29, 2016 at 5:30 AM, Michal Suchanek <hramr...@gmail.com> wrote: > Hello, > > On 29 June 2016 at 10:45, Karsten Merker <mer...@debian.org> wrote: >> On Wed, Jun 29, 2016 at 09:30:33AM +0200, Michal Suchanek wrote: >> >>> I tried loading system with recent u-boot but it does not work. >>> >>> Trying some ext4ls shows there is some problem accessing the filesystem. >>> >>> Not sure if this should be attributed to the ext driver or to the mmc >>> driver or something else entirely. >> >> I haven't tested that myself, but I have seen reports on other >> platforms that the u-boot ext4 driver has problems with ext4 >> filesystems which use the "flex_bg" filesystem feature, as that >> causes certain changes to the on-disk layout compared to ext4 >> without this feature. From what people have reported, it appears >> that "flex_bg" is enabled by default on ext4 filesystems created >> with a recent mkfs.ext4 version. >> > > Reformatting without flex_bg does not seem to have any effect. > > However, ls seems to give some random stuff for directories other than > / so some similar remapping feature could cause this. it's csum/64bit, disable it: mkfs.ext4 -O ^metadata_csum,^64bit Regards, -- Robert Nelson https://rcn-ee.com/ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: mx6: Enable MMC FS boot support
On Wed, Apr 27, 2016 at 7:54 PM, Tom Rini <tr...@konsulko.com> wrote: > On Thu, Apr 28, 2016 at 02:02:05AM +0200, Marek Vasut wrote: > > On 04/28/2016 01:49 AM, Robert Nelson wrote: > [snip] > > > 1: > > > > > > Yeap, end users like to delete "MLO/u-boot.img" that was in the "fat" > > > boot partition in our production beaglebone images specifically > > > "2014-05-14" which was shipped by default on rev C. Thus > > > soft-bricking/etc boards.. > > > > OK, so because hypothetical user is an idiot, we should use sub-par > > solution ? User can also be an idiot and generate U-Boot which is over 1 > > MiB, in which case I will turn your argument around against you. Sorry, > > I am not buying this. > > No, real users. Lots of them. From nearly every "community" oriented > board ever. Which is why the distros also go for this method, point #2. > > > > http://beagleboard.org/latest-images > > > > > > Moving it under the 1MB location, has solved that problem. > > > > Until u-boot grows over 1 MiB. This only postponed the problem. > > Since there is filesystem support in the SPL, we should use that > > as a superior solution which doesn't suffer from this problem. > > I thought people were supposed to be aligning their first partitions > much higher these days, 4MiB? as the general case for being safe > regardless of the actual flash in the SD card. Setting aside sandbox > which I hope grows extremely large for testing purposes, I really hope > U-Boot + SPL can always stay under 1MiB. Our job is to boot the next > stage. If we get so large in our design of implementing things that we > forget this, we have a problem. > I've followed the 4kb convention and fdisk defaults to 1MB offset: (even thou we aren't dealing spinning disks) https://www.ibm.com/developerworks/library/l-linux-on-4kb-sector-disks/ I haven't looked at the latest eMMC spec, but the eMMC 'boot' sections on current silicon is only 1MB (x2) mmcblk1boot0 179:16 01M 1 disk mmcblk1boot1 179:24 01M 1 disk mmcblk1 179:80 1.8G 0 disk Regards, -- Robert Nelson https://rcn-ee.com/ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: mx6: Enable MMC FS boot support
On Wed, Apr 27, 2016 at 6:41 PM, Marek Vasut <ma...@denx.de> wrote: > On 04/28/2016 01:32 AM, Robert Nelson wrote: > > > > > > On Wed, Apr 27, 2016 at 6:28 PM, Marek Vasut <ma...@denx.de > > <mailto:ma...@denx.de>> wrote: > > > > On 04/28/2016 01:16 AM, Tom Rini wrote: > > > On Thu, Apr 28, 2016 at 01:06:07AM +0200, Marek Vasut wrote: > > > > > >> Enable support for booting U-Boot image from filesystem instead > of some > > >> random offset on the SD card. This makes the board usable by > putting the > > >> u-boot.img to first partition of the SD card and writing the SPL > this way: > > >> $ dd if=u-boot-with-spl.imx of=/dev/sdX seek=2 bs=512 > > > > > > Wait, you're still writing u-boot + SPL to the device and not just > SPL, > > > but it's still preferring the filesystem one over the appended one? > > > > > > > Ha, good point. I should've written the 'SPL' file instead, which is > > just the SPL without U-Boot. I don't want to install U-Boot to random > > offset on the SD card as it has the potential to corrupt data if the > > u-boot binary changes in size. > > > > If I install u-boot image to random offset 138 blocks from the start > of > > SD card, it will boot that, otherwise it will load from FS. > > > > I will update the commit message with the correct info, sorry. > > > > > > Oh, we went thru this last year... > > > > http://lists.denx.de/pipermail/u-boot/2015-August/222061.html > > > > If your serious about changing "one" i.mx6 board, you need to change > > them "all". > > No, I do not have to change and will not change any other boards I > cannot test. > Okay, so if you can't test, are you going to keep an updated database: boardx = boots this way? boardy = boots that way? Otherwise, keep like the other i.mx6's.. Or throw it under a "kconfig" so you can easily enable either mode. > > > Otherwise leave a 1MB hole on your mmc partition and dd spl/u-boot.img > > as that works for ti/imx/sunxi... > > No, this design is utterly broken. If U-Boot grows beyond 1 MiB, it will > corrupt my data, silently. I will not have this. I would much rather see > these broken designs go away and have everyone move to > SPL in random location as mandated by BootROM (unfortunately) and > u-boot.img on a filesystem. That way, u-boot.img can grow and shrink > either way, without endangering any surrounding data. > > Can you give me any argument why writing u-boot.img to random location > on the SD card is better than storing it on a filesystem ? > 1: Yeap, end users like to delete "MLO/u-boot.img" that was in the "fat" boot partition in our production beaglebone images specifically "2014-05-14" which was shipped by default on rev C. Thus soft-bricking/etc boards.. http://beagleboard.org/latest-images Moving it under the 1MB location, has solved that problem. 2: fedora/debian/ubuntu/yocto all expect this board to have these settings.. Regards, -- Robert Nelson https://rcn-ee.com/ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: mx6: Enable MMC FS boot support
On Wed, Apr 27, 2016 at 6:28 PM, Marek Vasut <ma...@denx.de> wrote: > On 04/28/2016 01:16 AM, Tom Rini wrote: > > On Thu, Apr 28, 2016 at 01:06:07AM +0200, Marek Vasut wrote: > > > >> Enable support for booting U-Boot image from filesystem instead of some > >> random offset on the SD card. This makes the board usable by putting the > >> u-boot.img to first partition of the SD card and writing the SPL this > way: > >> $ dd if=u-boot-with-spl.imx of=/dev/sdX seek=2 bs=512 > > > > Wait, you're still writing u-boot + SPL to the device and not just SPL, > > but it's still preferring the filesystem one over the appended one? > > > > Ha, good point. I should've written the 'SPL' file instead, which is > just the SPL without U-Boot. I don't want to install U-Boot to random > offset on the SD card as it has the potential to corrupt data if the > u-boot binary changes in size. > > If I install u-boot image to random offset 138 blocks from the start of > SD card, it will boot that, otherwise it will load from FS. > > I will update the commit message with the correct info, sorry. > Oh, we went thru this last year... http://lists.denx.de/pipermail/u-boot/2015-August/222061.html If your serious about changing "one" i.mx6 board, you need to change them "all". Otherwise leave a 1MB hole on your mmc partition and dd spl/u-boot.img as that works for ti/imx/sunxi... Regards, -- Robert Nelson https://rcn-ee.com/ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] BeagleBone Black: u-boot 2016.03-rc2 worng fdt detection
On Mon, Mar 7, 2016 at 8:55 AM, Robert Nelson <robertcnel...@gmail.com> wrote: > On Mon, Mar 7, 2016 at 4:50 AM, Matwey V. Kornilov > <matwey.korni...@gmail.com> wrote: >> Hello, >> >> I am running u-boot 2016.03-rc2 on BeagleBone Black and it is >> incorrectly detected as BeagleBone Green. >> >> fdtfile=am335x-bonegreen.dtb >> >> => print board_name >> board_name=A335BNLT >> => print board_rev >> board_rev=t >> ue >> >> >> Similar issue was here on 2016.01. > > CC'ing Steven, > > as he's rewritten the eeprom patchset: > > https://patchwork.ozlabs.org/patch/587572/ > > Steven, here's the magical eeprom values this board needs: > > https://gist.github.com/RobertCNelson/21f44591c78daed7c637 > > I've had no luck tracking down another copy of this unique board in > the field for purchase. and here's the older thread: http://lists.denx.de/pipermail/u-boot/2015-December/237604.html The 'test' operator: http://git.denx.de/?p=u-boot.git;a=blob;f=include/configs/am335x_evm.h;h=6ebe0b3866f9b137472cc080c9eb8f1e38233186;hb=HEAD#l185 is chocking on the 0x0a character.. Regards, -- Robert Nelson https://rcn-ee.com/ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] BeagleBone Black: u-boot 2016.03-rc2 worng fdt detection
On Mon, Mar 7, 2016 at 4:50 AM, Matwey V. Kornilov <matwey.korni...@gmail.com> wrote: > Hello, > > I am running u-boot 2016.03-rc2 on BeagleBone Black and it is > incorrectly detected as BeagleBone Green. > > fdtfile=am335x-bonegreen.dtb > > => print board_name > board_name=A335BNLT > => print board_rev > board_rev=t > ue > > > Similar issue was here on 2016.01. CC'ing Steven, as he's rewritten the eeprom patchset: https://patchwork.ozlabs.org/patch/587572/ Steven, here's the magical eeprom values this board needs: https://gist.github.com/RobertCNelson/21f44591c78daed7c637 I've had no luck tracking down another copy of this unique board in the field for purchase. Regards, -- Robert Nelson https://rcn-ee.com/ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] At start of autoboot check, flush any pending RX bytes
On Tue, Jan 19, 2016 at 10:35 PM, Simon Glass <s...@chromium.org> wrote: > Hi, > > On 18 January 2016 at 23:46, Craig McQueen <craig.mcqu...@innerrange.com> > wrote: >>> Tom Rini wrote: >>> >>> On Mon, Jan 11, 2016 at 09:59:18AM -0700, Simon Glass wrote: >>> > Hi Craig, >>> > >>> > On 20 December 2015 at 19:07, Craig McQueen >>> > <craig.mcqu...@innerrange.com> wrote: >>> > > This is to avoid the boot sequence halting due to initial "junk" >>> > > received on serial input. >>> > > >>> > > Signed-off-by: Craig McQueen <craig.mcqu...@innerrange.com> >>> > > --- >>> > > I have found that on the BeagleBone Black, U-Boot occasionally halts >>> > > at the U-Boot prompt at boot-up, whether power-up, warm external >>> > > reset or software reset. I have seen other people report the same issue. >>> > > >>> > > This seems to be due to U-Boot receiving "junk" data on the serial >>> > > console. The BeagleBone Black has a pull-down resistor which was >>> > > apparently added to try to mitigate this issue, but it doesn't >>> > > entirely fix it. >>> > >>> > I wonder if this can be fixed for that board only? >>> >>> No, and it's not -exactly- a that board only problem. It's a HW design >>> issue >>> that can show up elsewhere too. I _think_ however in this case the answer >>> would be to migrate to perhaps CONFIG_AUTOBOOT_KEYED_CTRLC as that's >>> one of the reason various other boards use that set of options. >>> >>> I would suggest bringing this up on the beaglebone list to see what the >>> various people that ship and support these boards think, thanks! >> >> Other options such as CONFIG_AUTOBOOT_KEYED_CTRLC sound like a work-around >> of the problem, rather than a fix of the root-cause. But maybe that's just >> my opinion. Simon Glass' suggestion (clear out the UART input buffer when >> the driver is probed) sounded reasonable, but I haven't tried it. > > Since it seems like a hardware bug, we can only have a workaround. A > real fix would involve fixing the root cause, i.e. fixing the > hardware. > >> >> I think BeagleBone Black definitely needs _some_ sort of fix -- currently >> BBB can randomly fail to boot, which isn't good. If my patch isn't wanted, >> then please implement a suitable alternative. > > How about what Tom suggested? Ctrl-C is not likely to happen by accident. This should be good enough for everyone, it'll look for an exact match over serial "" otherwise it'll ignore everything else: http://lists.denx.de/pipermail/u-boot/2016-January/241286.html Regards, -- Robert Nelson https://rcn-ee.com/ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] At start of autoboot check, flush any pending RX bytes
On Thu, Jan 14, 2016 at 11:51 AM, Tom Rini <tr...@konsulko.com> wrote: > On Thu, Jan 14, 2016 at 11:48:07AM -0600, Robert Nelson wrote: > > On Thu, Jan 14, 2016 at 11:31 AM, Tom Rini <tr...@konsulko.com> wrote: > > > > > On Mon, Jan 11, 2016 at 09:59:18AM -0700, Simon Glass wrote: > > > > Hi Craig, > > > > > > > > On 20 December 2015 at 19:07, Craig McQueen > > > > <craig.mcqu...@innerrange.com> wrote: > > > > > This is to avoid the boot sequence halting due to initial "junk" > > > > > received on serial input. > > > > > > > > > > Signed-off-by: Craig McQueen <craig.mcqu...@innerrange.com> > > > > > --- > > > > > I have found that on the BeagleBone Black, U-Boot occasionally > halts at > > > > > the U-Boot prompt at boot-up, whether power-up, warm external > > > > > reset or software reset. I have seen other people report the same > > > issue. > > > > > > > > > > This seems to be due to U-Boot receiving "junk" data on the serial > > > > > console. The BeagleBone Black has a pull-down resistor which was > > > > > apparently added to try to mitigate this issue, but it doesn't > entirely > > > > > fix it. > > > > > > > > I wonder if this can be fixed for that board only? > > > > > > No, and it's not -exactly- a that board only problem. It's a HW design > > > issue that can show up elsewhere too. I _think_ however in this case > > > the answer would be to migrate to perhaps CONFIG_AUTOBOOT_KEYED_CTRLC > as > > > that's one of the reason various other boards use that set of options. > > > > > > I would suggest bringing this up on the beaglebone list to see what the > > > various people that ship and support these boards think, thanks! > > > > > > > I actually enabled this feature this week by default for beagleboard.org > : > > > > diff --git a/configs/am335x_evm_defconfig b/configs/am335x_evm_defconfig > > index 27cb881..8699953 100644 > > --- a/configs/am335x_evm_defconfig > > +++ b/configs/am335x_evm_defconfig > > @@ -3,7 +3,10 @@ CONFIG_TARGET_AM335X_EVM=y > > CONFIG_SPL_STACK_R_ADDR=0x8200 > > CONFIG_SPL=y > > CONFIG_SPL_STACK_R=y > > -CONFIG_SYS_EXTRA_OPTIONS="NAND" > > +CONFIG_AUTOBOOT_KEYED=y > > +CONFIG_AUTOBOOT_PROMPT="Press SPACE to abort autoboot in %d seconds\n" > > +CONFIG_AUTOBOOT_DELAY_STR="d" > > +CONFIG_AUTOBOOT_STOP_STR=" " > > # CONFIG_CMD_IMLS is not set > > # CONFIG_CMD_FLASH is not set > > CONFIG_CMD_GPIO=y > > > > It'll take time to replace older images but on target users can just: > > > > cd /opt/scripts/tools/developers/ > > git pull > > sudo ./update_bootloader.sh > > > > U-Boot SPL 2016.01-1-g4eb802e (Jan 13 2016 - 11:14:31) > > Trying to boot from MMC > > bad magic > > > > > > U-Boot 2016.01-1-g4eb802e (Jan 13 2016 - 11:14:31 -0600), Build: > > jenkins-github_Bootloader-Builder-313 > > > >Watchdog enabled > > I2C: ready > > DRAM: 512 MiB > > Reset Source: Global external warm reset has occurred. > > Reset Source: Power-on reset has occurred. > > MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1 > > Using default environment > > > > Net:not set. Validating first E-fuse MAC > > cpsw, usb_ether > > Press SPACE to abort autoboot in 2 seconds > > => > > Space eh? OK. Now would be the time to push this upstream as the merge > window just opened :) > That seemed like the most common when i looked at it.. grep -R "AUTOBOOT_PROMPT" configs/*defconfig Do you want me to hit all 3 bbb related configs? beagleboard.org uses: am335x_evm_defconfig I know some users use: am335x_boneblack_defconfig am335x_boneblack_vboot_defconfig Regards, -- Robert Nelson https://rcn-ee.com/ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] At start of autoboot check, flush any pending RX bytes
On Thu, Jan 14, 2016 at 11:31 AM, Tom Rini <tr...@konsulko.com> wrote: > On Mon, Jan 11, 2016 at 09:59:18AM -0700, Simon Glass wrote: > > Hi Craig, > > > > On 20 December 2015 at 19:07, Craig McQueen > > <craig.mcqu...@innerrange.com> wrote: > > > This is to avoid the boot sequence halting due to initial "junk" > > > received on serial input. > > > > > > Signed-off-by: Craig McQueen <craig.mcqu...@innerrange.com> > > > --- > > > I have found that on the BeagleBone Black, U-Boot occasionally halts at > > > the U-Boot prompt at boot-up, whether power-up, warm external > > > reset or software reset. I have seen other people report the same > issue. > > > > > > This seems to be due to U-Boot receiving "junk" data on the serial > > > console. The BeagleBone Black has a pull-down resistor which was > > > apparently added to try to mitigate this issue, but it doesn't entirely > > > fix it. > > > > I wonder if this can be fixed for that board only? > > No, and it's not -exactly- a that board only problem. It's a HW design > issue that can show up elsewhere too. I _think_ however in this case > the answer would be to migrate to perhaps CONFIG_AUTOBOOT_KEYED_CTRLC as > that's one of the reason various other boards use that set of options. > > I would suggest bringing this up on the beaglebone list to see what the > various people that ship and support these boards think, thanks! > I actually enabled this feature this week by default for beagleboard.org: diff --git a/configs/am335x_evm_defconfig b/configs/am335x_evm_defconfig index 27cb881..8699953 100644 --- a/configs/am335x_evm_defconfig +++ b/configs/am335x_evm_defconfig @@ -3,7 +3,10 @@ CONFIG_TARGET_AM335X_EVM=y CONFIG_SPL_STACK_R_ADDR=0x8200 CONFIG_SPL=y CONFIG_SPL_STACK_R=y -CONFIG_SYS_EXTRA_OPTIONS="NAND" +CONFIG_AUTOBOOT_KEYED=y +CONFIG_AUTOBOOT_PROMPT="Press SPACE to abort autoboot in %d seconds\n" +CONFIG_AUTOBOOT_DELAY_STR="d" +CONFIG_AUTOBOOT_STOP_STR=" " # CONFIG_CMD_IMLS is not set # CONFIG_CMD_FLASH is not set CONFIG_CMD_GPIO=y It'll take time to replace older images but on target users can just: cd /opt/scripts/tools/developers/ git pull sudo ./update_bootloader.sh U-Boot SPL 2016.01-1-g4eb802e (Jan 13 2016 - 11:14:31) Trying to boot from MMC bad magic U-Boot 2016.01-1-g4eb802e (Jan 13 2016 - 11:14:31 -0600), Build: jenkins-github_Bootloader-Builder-313 Watchdog enabled I2C: ready DRAM: 512 MiB Reset Source: Global external warm reset has occurred. Reset Source: Power-on reset has occurred. MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1 Using default environment Net:not set. Validating first E-fuse MAC cpsw, usb_ether Press SPACE to abort autoboot in 2 seconds => Regards, -- Robert Nelson https://rcn-ee.com/ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] am335x: BeagleBones enable CONFIG_AUTOBOOT_KEYED
On startup, the BeagleBone family of boards can occationally halt at the U-Boot prompt. Due to U-Boot receiving random data on the usart. Migrate BeagleBone based boards to use CONFIG_AUTOBOOT_KEYED, user will now have to enter the key to get to U-Boot prompt Signed-off-by: Robert Nelson <robertcnel...@gmail.com> CC: Craig McQueen <craig.mcqu...@innerrange.com> CC: Tom Rini <tr...@konsulko.com> --- configs/am335x_boneblack_defconfig | 4 configs/am335x_boneblack_vboot_defconfig | 4 configs/am335x_evm_defconfig | 4 3 files changed, 12 insertions(+) diff --git a/configs/am335x_boneblack_defconfig b/configs/am335x_boneblack_defconfig index 3030a95..8803da5 100644 --- a/configs/am335x_boneblack_defconfig +++ b/configs/am335x_boneblack_defconfig @@ -4,6 +4,10 @@ CONFIG_SPL_STACK_R_ADDR=0x8200 CONFIG_SPL=y CONFIG_SPL_STACK_R=y CONFIG_SYS_EXTRA_OPTIONS="EMMC_BOOT" +CONFIG_AUTOBOOT_KEYED=y +CONFIG_AUTOBOOT_PROMPT="Press SPACE to abort autoboot in %d seconds\n" +CONFIG_AUTOBOOT_DELAY_STR="d" +CONFIG_AUTOBOOT_STOP_STR=" " # CONFIG_CMD_IMLS is not set # CONFIG_CMD_FLASH is not set CONFIG_CMD_GPIO=y diff --git a/configs/am335x_boneblack_vboot_defconfig b/configs/am335x_boneblack_vboot_defconfig index ad40b07..5dcb942 100644 --- a/configs/am335x_boneblack_vboot_defconfig +++ b/configs/am335x_boneblack_vboot_defconfig @@ -8,6 +8,10 @@ CONFIG_FIT=y CONFIG_FIT_VERBOSE=y CONFIG_FIT_SIGNATURE=y CONFIG_SYS_EXTRA_OPTIONS="EMMC_BOOT,ENABLE_VBOOT" +CONFIG_AUTOBOOT_KEYED=y +CONFIG_AUTOBOOT_PROMPT="Press SPACE to abort autoboot in %d seconds\n" +CONFIG_AUTOBOOT_DELAY_STR="d" +CONFIG_AUTOBOOT_STOP_STR=" " # CONFIG_CMD_IMLS is not set # CONFIG_CMD_FLASH is not set CONFIG_CMD_GPIO=y diff --git a/configs/am335x_evm_defconfig b/configs/am335x_evm_defconfig index 27cb881..7753ab5 100644 --- a/configs/am335x_evm_defconfig +++ b/configs/am335x_evm_defconfig @@ -4,6 +4,10 @@ CONFIG_SPL_STACK_R_ADDR=0x8200 CONFIG_SPL=y CONFIG_SPL_STACK_R=y CONFIG_SYS_EXTRA_OPTIONS="NAND" +CONFIG_AUTOBOOT_KEYED=y +CONFIG_AUTOBOOT_PROMPT="Press SPACE to abort autoboot in %d seconds\n" +CONFIG_AUTOBOOT_DELAY_STR="d" +CONFIG_AUTOBOOT_STOP_STR=" " # CONFIG_CMD_IMLS is not set # CONFIG_CMD_FLASH is not set CONFIG_CMD_GPIO=y -- 2.6.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] u-boot 2016.01-rc2 detects BeagleBone Black incorrectly
>> ah, it's tripping on the "." = "0a" character.. >> >> Do you happen to remember where you purchased it and what it was >> called.. (for git commit) >> >> This patch should work: >> >> https://gist.github.com/RobertCNelson/21f44591c78daed7c637 >> > > The patch works good. > But could you please explain me? I thought the problem was in 'test' operator. > Unlikely > test '\0x74\0x0a\0x75\0x65' = BBG1 > should be true. I saw this when i first booted the Green with the production eeprom, "test" doesn't seem to like non printable characters.. Sorry i didn't look into "test" much further.. Instead i just worked around it with the Green.. Regards, -- Robert Nelson https://rcn-ee.com/ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] u-boot 2016.01-rc2 detects BeagleBone Black incorrectly
On Thu, Dec 17, 2015 at 11:54 AM, Matwey V. Kornilov <matwey.korni...@gmail.com> wrote: > 2015-12-17 3:53 GMT+03:00 Robert Nelson <robertcnel...@gmail.com>: >> Hi Matwey >> >> On Sat, Dec 12, 2015 at 3:14 AM, Matwey V. Kornilov >> <matwey.korni...@gmail.com> wrote: >>> Hello, >>> >>> I am running 2016.01-rc on BBB (Embest replica) >>> >>> printenv shows the following: >>> >>> findfdt=if test $board_name = A335BONE; then setenv fdtfile >>> am335x-bone.dtb; fi; if test $board_name = A335BNLT; then if test >>> $board_rev = BBG1; then setenv fdtfile am335x-bonegreen.dtb; else setenv >>> fdtfile am335x-boneblack.dtb; fi; fi; if test $board_name = A33515BB; >>> then setenv fdtfile am335x-evm.dtb; fi; if test $board_name = A335X_SK; >>> then setenv fdtfile am335x-evmsk.dtb; fi; if test $fdtfile = undefined; >>> then echo WARNING: Could not determine device tree to use; fi; >>> >>> after findfdt has been run, >>> >>> fdtfile=am335x-bonegreen.dtb >>> >>> But it is not correct. My $board_rev is the following, I have no idea >>> why does it contain line break. >>> >>> board_name=A335BNLT >>> board_rev=t\ >> >> Yuck, another variation! Can you do me a favor and dump the eeprom: >> >> https://github.com/beagleboard/image-builder/blob/master/readme.md >> >> Download and run: >> >> wget >> https://raw.githubusercontent.com/RobertCNelson/boot-scripts/master/device/bone/tester/show-eeprom.sh >> >> sudo /bin/bash show-eeprom.sh > > # sudo /bin/bash show-eeprom.sh > eeprom: [�U3�A335BNLTt > ue] > eeprom raw: [ aa 55 33 ee 41 33 33 35 42 4e 4c 54 74 0a 75 > 65 |.U3.A335BNLTt.ue|] ah, it's tripping on the "." = "0a" character.. Do you happen to remember where you purchased it and what it was called.. (for git commit) This patch should work: https://gist.github.com/RobertCNelson/21f44591c78daed7c637 Please test, and i've added it to our table: https://github.com/RobertCNelson/omap-image-builder/commit/620ebf627d3df8c693845bef07af232aa289ff41 Regards, -- Robert Nelson https://rcn-ee.com/ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] u-boot 2016.01-rc2 detects BeagleBone Black incorrectly
Hi Matwey On Sat, Dec 12, 2015 at 3:14 AM, Matwey V. Kornilov <matwey.korni...@gmail.com> wrote: > Hello, > > I am running 2016.01-rc on BBB (Embest replica) > > printenv shows the following: > > findfdt=if test $board_name = A335BONE; then setenv fdtfile > am335x-bone.dtb; fi; if test $board_name = A335BNLT; then if test > $board_rev = BBG1; then setenv fdtfile am335x-bonegreen.dtb; else setenv > fdtfile am335x-boneblack.dtb; fi; fi; if test $board_name = A33515BB; > then setenv fdtfile am335x-evm.dtb; fi; if test $board_name = A335X_SK; > then setenv fdtfile am335x-evmsk.dtb; fi; if test $fdtfile = undefined; > then echo WARNING: Could not determine device tree to use; fi; > > after findfdt has been run, > > fdtfile=am335x-bonegreen.dtb > > But it is not correct. My $board_rev is the following, I have no idea > why does it contain line break. > > board_name=A335BNLT > board_rev=t\ Yuck, another variation! Can you do me a favor and dump the eeprom: https://github.com/beagleboard/image-builder/blob/master/readme.md Download and run: wget https://raw.githubusercontent.com/RobertCNelson/boot-scripts/master/device/bone/tester/show-eeprom.sh sudo /bin/bash show-eeprom.sh It uses hexdump and compatible with bb.org' 3.8/4.1/etc.. The green should only trigger on: 0x1a 0x00 0x00 0x00 http://git.denx.de/?p=u-boot.git;a=blobdiff;f=board/ti/am335x/board.c;h=f56d17ec58e17a6532b5df649249b4038b475897;hp=f0cb1e204ad550622df7848a993f1eb2f173bc43;hb=dfd1bb4ec89e8b1e87f0605af2345ad6dcf777da;hpb=e4aa8edb6e5cae256a5c5a3c5cd30e05e8f5a2b4 Regards, -- Robert Nelson https://rcn-ee.com/ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] omap4_panda: Convert to config_distro_bootcmd.h
On Thu, Dec 10, 2015 at 3:46 PM, Tom Rini <tr...@konsulko.com> wrote: > Based on the am335x_evm conversion, switch to config_distro_bootcmd for > mmc and pxe. Tested with Fedora 23. > > Signed-off-by: Tom Rini <tr...@konsulko.com> > --- > include/configs/ti_omap4_common.h | 51 > - > 1 file changed, 27 insertions(+), 24 deletions(-) > > diff --git a/include/configs/ti_omap4_common.h > b/include/configs/ti_omap4_common.h > index 08130eb..8b6c065 100644 > --- a/include/configs/ti_omap4_common.h > +++ b/include/configs/ti_omap4_common.h > @@ -82,6 +82,32 @@ > /* > * Environment setup > */ > +#define BOOTENV_DEV_LEGACY_MMC(devtypeu, devtypel, instance) \ > + "bootcmd_" #devtypel #instance "=" \ > + "setenv mmcdev " #instance"; "\ > + "setenv bootpart " #instance":2 ; "\ > + "run mmcboot\0" > + > +#define BOOTENV_DEV_NAME_LEGACY_MMC(devtypeu, devtypel, instance) \ > + #devtypel #instance " " > + > +#define BOOTENV_DEV_NAME_NAND(devtypeu, devtypel, instance) \ > + #devtypel #instance " " > + > +#define BOOT_TARGET_DEVICES(func) \ > + func(MMC, mmc, 0) \ > + func(LEGACY_MMC, legacy_mmc, 0) \ > + func(MMC, mmc, 1) \ > + func(LEGACY_MMC, legacy_mmc, 1) \ I don't remember the panda having a 2nd mmc card slot, are there other omap4's with this feature? Regards, -- Robert Nelson https://rcn-ee.com/ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] omap4_panda: Convert to config_distro_bootcmd.h
On Thu, Dec 10, 2015 at 4:58 PM, Robert Nelson <robertcnel...@gmail.com> wrote: > On Thu, Dec 10, 2015 at 3:46 PM, Tom Rini <tr...@konsulko.com> wrote: >> Based on the am335x_evm conversion, switch to config_distro_bootcmd for >> mmc and pxe. Tested with Fedora 23. >> >> Signed-off-by: Tom Rini <tr...@konsulko.com> >> --- >> include/configs/ti_omap4_common.h | 51 >> - >> 1 file changed, 27 insertions(+), 24 deletions(-) >> >> diff --git a/include/configs/ti_omap4_common.h >> b/include/configs/ti_omap4_common.h >> index 08130eb..8b6c065 100644 >> --- a/include/configs/ti_omap4_common.h >> +++ b/include/configs/ti_omap4_common.h >> @@ -82,6 +82,32 @@ >> /* >> * Environment setup >> */ >> +#define BOOTENV_DEV_LEGACY_MMC(devtypeu, devtypel, instance) \ >> + "bootcmd_" #devtypel #instance "=" \ >> + "setenv mmcdev " #instance"; "\ >> + "setenv bootpart " #instance":2 ; "\ >> + "run mmcboot\0" >> + >> +#define BOOTENV_DEV_NAME_LEGACY_MMC(devtypeu, devtypel, instance) \ >> + #devtypel #instance " " >> + >> +#define BOOTENV_DEV_NAME_NAND(devtypeu, devtypel, instance) \ >> + #devtypel #instance " " >> + >> +#define BOOT_TARGET_DEVICES(func) \ >> + func(MMC, mmc, 0) \ >> + func(LEGACY_MMC, legacy_mmc, 0) \ >> + func(MMC, mmc, 1) \ >> + func(LEGACY_MMC, legacy_mmc, 1) \ > > I don't remember the panda having a 2nd mmc card slot, are there other > omap4's with this feature? ahh the omap4-sdp did, since this is ti_omap4_common.h that's fine.. Regards, -- Robert Nelson https://rcn-ee.com/ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-boot for AM5728
On Fri, Nov 20, 2015 at 11:56 PM, chandrashekar p <chanduec...@gmail.com> wrote: > Hello, > > I'm using AM5728 EVM board, to use u-boot boot loader i tried by > downloading the u-boot from other google link. > Their i didn't find the config file for AM5728. > > https://eewiki.net/display/linuxonarm/BeagleBoard-X15#BeagleBoard-X15-Bootloader:U-Boot > > I tried with the below link, it didn't get succeed, got the error. PLease > go through the error file & suggest me how i can come out of this issue. Those directions work fine if you actually follow them: https://gist.github.com/RobertCNelson/4aa9eb1d028237a895a1 > > Please send the link to download where i can get the latest u-boot boot > loader which support for AM5728 EVM board. Please double check what terminal commands you utilized. Regards, -- Robert Nelson https://rcn-ee.com/ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] board/ti/am335x: add support for BeagleBone Green
SeeedStudio BeagleBone Green (BBG) is clone of the BeagleBone Black (BBB) minus
the HDMI port and addition of two Grove connectors (i2c2 and usart2).
This board can be identified by the 1A value after A335BNLT (BBB) in the at24
eeprom:
1A: [aa 55 33 ee 41 33 33 35 42 4e 4c 54 1a 00 00 00 |.U3.A335BNLT|]
http://beagleboard.org/green
http://www.seeedstudio.com/wiki/Beaglebone_green
In Mainline Kernel as of:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=79a4e64c679d8a0b1037da174e4aea578c80c4e6
Patch tested on BeagleBone Black (rev C) and BeagleBone Green (production model)
Signed-off-by: Robert Nelson <robertcnel...@gmail.com>
CC: Tom Rini <tr...@konsulko.com>
CC: Jason Kridner <jkrid...@gmail.com>
---
board/ti/am335x/board.c | 12 +---
include/configs/am335x_evm.h | 7 ++-
2 files changed, 15 insertions(+), 4 deletions(-)
diff --git a/board/ti/am335x/board.c b/board/ti/am335x/board.c
index f0cb1e2..f56d17e 100644
--- a/board/ti/am335x/board.c
+++ b/board/ti/am335x/board.c
@@ -507,9 +507,15 @@ int board_late_init(void)
safe_string[sizeof(header.name)] = 0;
setenv("board_name", safe_string);
- strncpy(safe_string, (char *)header.version, sizeof(header.version));
- safe_string[sizeof(header.version)] = 0;
- setenv("board_rev", safe_string);
+ /* BeagleBone Green eeprom, board_rev: 0x1a 0x00 0x00 0x00 */
+ if ( (header.version[0] == 0x1a) && (header.version[1] == 0x00) &&
+(header.version[2] == 0x00) && (header.version[3] == 0x00) ) {
+ setenv("board_rev", "BBG1");
+ } else {
+ strncpy(safe_string, (char *)header.version,
sizeof(header.version));
+ safe_string[sizeof(header.version)] = 0;
+ setenv("board_rev", safe_string);
+ }
#endif
return 0;
diff --git a/include/configs/am335x_evm.h b/include/configs/am335x_evm.h
index d58816d..ed3fd34 100644
--- a/include/configs/am335x_evm.h
+++ b/include/configs/am335x_evm.h
@@ -186,7 +186,12 @@
"if test $board_name = A335BONE; then " \
"setenv fdtfile am335x-bone.dtb; fi; " \
"if test $board_name = A335BNLT; then " \
- "setenv fdtfile am335x-boneblack.dtb; fi; " \
+ "if test $board_rev = BBG1; then " \
+ "setenv fdtfile am335x-bonegreen.dtb; " \
+ "else " \
+ "setenv fdtfile am335x-boneblack.dtb; " \
+ "fi; " \
+ "fi; " \
"if test $board_name = A33515BB; then " \
"setenv fdtfile am335x-evm.dtb; fi; " \
"if test $board_name = A335X_SK; then " \
--
2.6.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] board/ti/am335x: beaglebone stop muxing i2c1_pin_mux
On the BeagleBone these i2c1 pins are routed to the expanasion header, where
they can be defined as either pr1_usart0_Xxd/pwm0/spi0/i2c1, dont assume i2c1
Fixes: https://e2e.ti.com/support/arm/sitara_arm/f/791/p/313894/1387696
Signed-off-by: Robert Nelson <robertcnel...@gmail.com>
Reported-by: Matthijs van Duin <matthijsvand...@gmail.com>
CC: Tom Rini <tr...@konsulko.com>
---
board/ti/am335x/mux.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/board/ti/am335x/mux.c b/board/ti/am335x/mux.c
index 680f656..fd3da58 100644
--- a/board/ti/am335x/mux.c
+++ b/board/ti/am335x/mux.c
@@ -317,7 +317,6 @@ void enable_board_pin_mux(struct am335x_baseboard_id
*header)
/* Do board-specific muxes. */
if (board_is_bone(header)) {
/* Beaglebone pinmux */
- configure_module_pin_mux(i2c1_pin_mux);
configure_module_pin_mux(mii1_pin_mux);
configure_module_pin_mux(mmc0_pin_mux);
#if defined(CONFIG_NAND)
@@ -356,7 +355,6 @@ void enable_board_pin_mux(struct am335x_baseboard_id
*header)
configure_module_pin_mux(mmc0_pin_mux_sk_evm);
} else if (board_is_bone_lt(header)) {
/* Beaglebone LT pinmux */
- configure_module_pin_mux(i2c1_pin_mux);
configure_module_pin_mux(mii1_pin_mux);
configure_module_pin_mux(mmc0_pin_mux);
#if defined(CONFIG_NAND) && defined(CONFIG_EMMC_BOOT)
--
2.6.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] mkimage: mxs (mx23_olinuxino) build regression
Hi Simon,
I've just finished bisecting a build error for the mx23_olinuxino platform.
git bisect points to:
http://git.denx.de/?p=u-boot.git;a=commit;h=92a655c326b22de58dcd5371ca1a62fdc57f8e04
to build:
make ARCH=arm CROSS_COMPILE=${CC} distclean
make ARCH=arm CROSS_COMPILE=${CC} mx23_olinuxino_defconfig
make ARCH=arm CROSS_COMPILE=${CC} u-boot.sb
Build error:
CFG spl/u-boot-spl.cfg
MKIMAGE u-boot.sb
./tools/mkimage: Can't open (null): Bad address
arch/arm/cpu/arm926ejs/mxs/Makefile:82: recipe for target 'u-boot.sb' failed
make[1]: *** [u-boot.sb] Error 1
Makefile:989: recipe for target 'u-boot.sb' failed
make: *** [u-boot.sb] Error 2
Reverting that commit and building show the target booting just fine:
HTLCLC
U-Boot 2015.10-rc2-00305-g8304793 (Sep 02 2015 - 14:40:06 -0500)
CPU: Freescale i.MX23 rev1.4 at 454 MHz
BOOT: SSP SD/MMC #0
DRAM: 64 MiB
MMC: MXS MMC: 0
*** Warning - bad CRC, using default environment
In:serial
Out: serial
Err: serial
Net: Net Initialization Skipped
No ethernet found.
Regards,
--
Robert Nelson
https://rcn-ee.com/
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] mkimage: mxs (mx23_olinuxino) build regression
On Wed, Sep 2, 2015 at 3:52 PM, Otavio Salvador <otavio.salva...@ossystems.com.br> wrote: > On Wed, Sep 2, 2015 at 4:48 PM, Robert Nelson <robertcnel...@gmail.com> wrote: >> I've just finished bisecting a build error for the mx23_olinuxino platform. >> >> git bisect points to: >> >> http://git.denx.de/?p=u-boot.git;a=commit;h=92a655c326b22de58dcd5371ca1a62fdc57f8e04 > > I think it has been fixed and merged today in master. Thanks you are right! The fix is in u-boot-imx.git master http://git.denx.de/?p=u-boot/u-boot-imx.git;a=shortlog;h=refs/heads/master so when u-boot.git master pushes that pull it'll be fine.. Regards, -- Robert Nelson https://rcn-ee.com/ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] udoo: Switch to SPL support
Just a quick comment, otherwise tested on my udoo quad/dual..
diff --git a/include/configs/udoo.h b/include/configs/udoo.h
index 910bf01..f93b67a 100644
--- a/include/configs/udoo.h
+++ b/include/configs/udoo.h
@@ -11,6 +11,10 @@
#include mx6_common.h
+#define CONFIG_SPL_MMC_SUPPORT
+#define CONFIG_SPL_FAT_SUPPORT
So ^ this forces use to include u-boot.img in a FAT partition..
For extX, you'd have to add:
#define CONFIG_SPL_EXT_SUPPORT
But, this also breaks if you had dd'ed SPL/u-boot.img..
U-Boot SPL 2015.10-rc1-1-gc195aa3 (Aug 03 2015 - 17:48:55)
spl_register_fat_device: fat register err - -1
spl_load_image_fat: error reading image u-boot.img, err - -1
spl: mmc: no boot mode left to try
### ERROR ### Please RESET the board ###
sudo dd if=./u-boot/SPL of=${DISK} seek=1 bs=1k
sudo dd if=./u-boot/u-boot.img of=${DISK} seek=69 bs=1k
Shouldn't we just not enable either and do like the wandboard and just
dd SPL/u-boot.img?
Regards,
--
Robert Nelson
https://rcn-ee.com/
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [ANN] U-Boot v2015.07 released
On Tue, Jul 14, 2015 at 3:24 PM, Nikolay Dimitrov picmas...@mail.bg wrote: Hi Tom, On 07/14/2015 11:14 PM, Peter Robinson wrote: Hi Tom, On Tue, Jul 14, 2015 at 6:56 PM, Tom Rini tr...@konsulko.com wrote: Hey all, I've pushed v2015.07 out to the repository and tarballs should exist soon. I don't see the release tag in git either by doing a pull from my checkout or via the web interface. Does it take time to sync? Peter Same here, the release tag is missing. The public repo is on a 6 hour cron job, give it a few more hours.. Regards, -- Robert Nelson https://rcn-ee.com/ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] mx6cuboxi: Add HDMI output support
On Wed, Apr 29, 2015 at 3:02 PM, Vagrant Cascadian vagr...@aikidev.net wrote: On 2015-04-27, Fabio Estevam wrote: Add HDMI output using PLL5 as the source for the IPU DI clocks, and accurate VESA timings. These settings are based on the patch from Soeren Moch sm...@web.de submitted for the tbs2910 mx6 based board. It allows the display to work properly at 1024x768@60. This should make the hdmi output signal compatible with most if not all modern displays. I wasn't able to test this as the HDMI TV I'm using doesn't support this resolution (it is admittedly ~9 years old, the closest resolution it does support is 1280x720@60). How complicated would it be to support multiple resolutions? There's edid support in the sunxi display driver.. live well, vagrant ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot -- Robert Nelson https://rcn-ee.com/ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] mx6cuboxi: Add HDMI output support
On Wed, Apr 29, 2015 at 3:02 PM, Vagrant Cascadian vagr...@aikidev.net wrote: On 2015-04-27, Fabio Estevam wrote: Add HDMI output using PLL5 as the source for the IPU DI clocks, and accurate VESA timings. These settings are based on the patch from Soeren Moch sm...@web.de submitted for the tbs2910 mx6 based board. It allows the display to work properly at 1024x768@60. This should make the hdmi output signal compatible with most if not all modern displays. I wasn't able to test this as the HDMI TV I'm using doesn't support this resolution (it is admittedly ~9 years old, the closest resolution it does support is 1280x720@60). How complicated would it be to support multiple resolutions? (Sorry about the double post.. gmail..) There's edid support in the sunxi_display driver: http://git.denx.de/?p=u-boot.git;a=blob;f=drivers/video/sunxi_display.c;hb=HEAD#l188 Could pull it out as a share it. Regards, -- Robert Nelson https://rcn-ee.com/ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] spl: mmc: Fix raw boot mode (related to commit 4c5bbc2328a24f5e1ee990c9a9527e48e5fb3b5f)
On Tue, Dec 16, 2014 at 5:00 AM, Guillaume GARDET guillaume.gar...@free.fr wrote: As reported by Robert Nelson, commit 4c5bbc2328a24f5e1ee990c9a9527e48e5fb3b5f may break MMC RAW boot mode. This patch fixes the check path to fix MMC Raw boot mode. Tested raw boot mode and FS boot mode on a pandaboard (rev. A3). Reported-by: Robert Nelson robertcnel...@gmail.com Signed-off-by: Guillaume GARDET guillaume.gar...@free.fr Cc: Tom Rini tr...@ti.com Cc: Robert Nelson robertcnel...@gmail.com Thanks Guillaume! Tested in raw fs mode on a beaglebone black (microSD eMMC) Regards, -- Robert Nelson http://www.rcn-ee.com/ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] spl: mmc: Fix raw boot mode (related to commit 4c5bbc2328a24f5e1ee990c9a9527e48e5fb3b5f)
On Tue, Dec 16, 2014 at 11:43 AM, Guillaume Gardet guillaume.gar...@free.fr wrote: Le 16/12/2014 18:16, Robert Nelson a écrit : On Tue, Dec 16, 2014 at 5:00 AM, Guillaume GARDET guillaume.gar...@free.fr wrote: As reported by Robert Nelson, commit 4c5bbc2328a24f5e1ee990c9a9527e48e5fb3b5f may break MMC RAW boot mode. This patch fixes the check path to fix MMC Raw boot mode. Tested raw boot mode and FS boot mode on a pandaboard (rev. A3). Reported-by: Robert Nelson robertcnel...@gmail.com Signed-off-by: Guillaume GARDET guillaume.gar...@free.fr Tested-by: Robert Nelson robertcnel...@gmail.com Cc: Tom Rini tr...@ti.com Cc: Robert Nelson robertcnel...@gmail.com Thanks Guillaume! Tested in raw fs mode on a beaglebone black (microSD eMMC) Thanks for testing it. :) You could add your tested by tag. I always forget. ;) Regards, -- Robert Nelson http://www.rcn-ee.com/ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] spl: if MMCSD_MODE_RAW fails, try MMCSD_MODE_FS, if available
On Tue, Nov 18, 2014 at 3:44 AM, Guillaume GARDET
guillaume.gar...@free.fr wrote:
In SPL MMC, boot modes are exclusive. So, if MMCSD_MODE_RAW fails, the board
hangs. This patch allows to
try MMCSD_MODE_FS then, if available.
It has been tested on a pandaboard (rev. A3).
HI Guillaume,
What mode did you test this is? (RAW or FS)
In Raw Mode with the omap5_uevm beaglebone black, i've had to revert
this. (I'm using RAW mode by default)
U-Boot SPL 2015.01-rc3-dirty (Dec 08 2014 - 20:04:01)
OMAP5432 ES2.0
SPL: Please implement spl_start_uboot() for your board
SPL: Direct Linux boot not active!
spl: wrong MMC boot mode
### ERROR ### Please RESET the board ###
Disk setup, I'm using
sudo dd if=/dev/zero of=${DISK} bs=1M count=10
sudo dd if=./u-boot/MLO of=${DISK} count=1 seek=1 conv=notrunc bs=128k
sudo dd if=./u-boot/u-boot.img of=${DISK} count=2 seek=1 conv=notrunc bs=384k
sudo sfdisk --in-order --Linux --unit M ${DISK} -__EOF__
1,,0x83,*
__EOF__
Regards,
--
Robert Nelson
http://www.rcn-ee.com/
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 13/13] ARM: atmel: sama5d4_xplained: enable spl support
a/configs/sama5d4_xplained_spiflash_defconfig b/configs/sama5d4_xplained_spiflash_defconfig index 3a4607c..755dd8b 100644 --- a/configs/sama5d4_xplained_spiflash_defconfig +++ b/configs/sama5d4_xplained_spiflash_defconfig @@ -1,3 +1,4 @@ +CONFIG_SPL=y CONFIG_SYS_EXTRA_OPTIONS=SAMA5D4,SYS_USE_SERIALFLASH +S:CONFIG_ARM=y +S:CONFIG_TARGET_SAMA5D4_XPLAINED=y diff --git a/include/configs/sama5d4_xplained.h b/include/configs/sama5d4_xplained.h index 996973d..6d70bc9 100644 --- a/include/configs/sama5d4_xplained.h +++ b/include/configs/sama5d4_xplained.h @@ -20,7 +20,9 @@ #define CONFIG_ARCH_CPU_INIT +#ifndef CONFIG_SPL_BUILD #define CONFIG_SKIP_LOWLEVEL_INIT +#endif #define CONFIG_BOARD_EARLY_INIT_F #define CONFIG_DISPLAY_CPUINFO @@ -66,8 +68,12 @@ #define CONFIG_SYS_SDRAM_BASE ATMEL_BASE_DDRCS #define CONFIG_SYS_SDRAM_SIZE 0x2000 +#ifdef CONFIG_SPL_BUILD +#define CONFIG_SYS_INIT_SP_ADDR0x21 +#else #define CONFIG_SYS_INIT_SP_ADDR \ (CONFIG_SYS_SDRAM_BASE + 4 * 1024 - GENERATED_GBL_DATA_SIZE) +#endif #define CONFIG_SYS_LOAD_ADDR 0x2200 /* load address */ @@ -221,4 +227,54 @@ /* Size of malloc() pool */ #define CONFIG_SYS_MALLOC_LEN (4 * 1024 * 1024) + +/* SPL */ +#define CONFIG_SPL_FRAMEWORK +#define CONFIG_SPL_TEXT_BASE 0x20 +#define CONFIG_SPL_MAX_SIZE0x1 +#define CONFIG_SPL_BSS_START_ADDR 0x2000 +#define CONFIG_SPL_BSS_MAX_SIZE0x8 +#define CONFIG_SYS_SPL_MALLOC_START0x2008 +#define CONFIG_SYS_SPL_MALLOC_SIZE 0x8 + +#define CONFIG_SPL_LIBCOMMON_SUPPORT +#define CONFIG_SPL_LIBGENERIC_SUPPORT +#define CONFIG_SPL_GPIO_SUPPORT +#define CONFIG_SPL_SERIAL_SUPPORT + +#define CONFIG_SPL_BOARD_INIT +#define CONFIG_SYS_MONITOR_LEN (512 10) + +#ifdef CONFIG_SYS_USE_MMC +#define CONFIG_SPL_LDSCRIPT arch/arm/cpu/at91-common/u-boot-spl.lds +#define CONFIG_SPL_MMC_SUPPORT +#define CONFIG_SYS_U_BOOT_MAX_SIZE_SECTORS 0x400 +#define CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR 0x200 +#define CONFIG_SYS_MMC_SD_FS_BOOT_PARTITION1 Hi Bo, You have an extra _ there: (MMC_SD) - (MMCSD), it should be: #define CONFIG_SYS_MMCSD_FS_BOOT_PARTITION 1 build error: common/spl/spl_mmc.c: In function ‘spl_mmc_load_image’: common/spl/spl_mmc.c:135:6: error: ‘CONFIG_SYS_MMCSD_FS_BOOT_PARTITION’ undeclared (first use in this function) CONFIG_SYS_MMCSD_FS_BOOT_PARTITION, ^ common/spl/spl_mmc.c:135:6: note: each undeclared identifier is reported only once for each function it appears in scripts/Makefile.build:275: recipe for target 'spl/common/spl/spl_mmc.o' failed make[2]: *** [spl/common/spl/spl_mmc.o] Error 1 scripts/Makefile.spl:212: recipe for target 'spl/common/spl' failed make[1]: *** [spl/common/spl] Error 2 make[1]: *** Waiting for unfinished jobs Regards, -- Robert Nelson http://www.rcn-ee.com/ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 12/13] ARM: atmel: sama5d4ek: enable SPL support
Same here: +#ifdef CONFIG_SYS_USE_MMC +#define CONFIG_SPL_LDSCRIPT arch/arm/cpu/at91-common/u-boot-spl.lds +#define CONFIG_SPL_MMC_SUPPORT +#define CONFIG_SYS_U_BOOT_MAX_SIZE_SECTORS 0x400 +#define CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR 0x200 +#define CONFIG_SYS_MMC_SD_FS_BOOT_PARTITION1 ^^ #define CONFIG_SYS_MMCSD_FS_BOOT_PARTITION1 Regards, -- Robert Nelson http://www.rcn-ee.com/ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 13/13] ARM: atmel: sama5d4_xplained: enable spl support
On Wed, Dec 10, 2014 at 7:29 PM, Bo Shen voice.s...@atmel.com wrote: Hi Robert Nelson, On 12/11/2014 09:21 AM, Bo Shen wrote: Hi Robert Nelson, On 12/11/2014 05:35 AM, Robert Nelson wrote: + +#ifdef CONFIG_SYS_USE_MMC +#define CONFIG_SPL_LDSCRIPT arch/arm/cpu/at91-common/u-boot-spl.lds +#define CONFIG_SPL_MMC_SUPPORT +#define CONFIG_SYS_U_BOOT_MAX_SIZE_SECTORS 0x400 +#define CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR 0x200 +#define CONFIG_SYS_MMC_SD_FS_BOOT_PARTITION1 Hi Bo, You have an extra _ there: (MMC_SD) - (MMCSD), it should be: #define CONFIG_SYS_MMCSD_FS_BOOT_PARTITION 1 build error: common/spl/spl_mmc.c: In function ‘spl_mmc_load_image’: common/spl/spl_mmc.c:135:6: error: ‘CONFIG_SYS_MMCSD_FS_BOOT_PARTITION’ undeclared (first use in this function) CONFIG_SYS_MMCSD_FS_BOOT_PARTITION, ^ common/spl/spl_mmc.c:135:6: note: each undeclared identifier is reported only once for each function it appears in scripts/Makefile.build:275: recipe for target 'spl/common/spl/spl_mmc.o' failed make[2]: *** [spl/common/spl/spl_mmc.o] Error 1 scripts/Makefile.spl:212: recipe for target 'spl/common/spl' failed make[1]: *** [spl/common/spl] Error 2 make[1]: *** Waiting for unfinished jobs Do you test this patch series based on u-boot master branch? I use git grep CONFIG_SYS_MMCSD_FS_BOOT_PARTITION, and don't find any information about it. Using git grep CONFIG_SYS_MMC_SD_FS_BOOT_PARTITION show many files use it. And the following commit introduced this name: ---8--- commit 205b4f33cfe58268df7d433f2da515fe660afd9c Author: Guillaume GARDET guillaume.gar...@free.fr Date: Wed Oct 15 17:53:11 2014 +0200 Rename some defines containing FAT in their name to be filesystem generic Rename some defines containing FAT in their name to be filesystem generic: MMCSD_MODE_FAT = MMCSD_MODE_FS CONFIG_SPL_FAT_LOAD_ARGS_NAME = CONFIG_SPL_FS_LOAD_ARGS_NAME CONFIG_SPL_FAT_LOAD_PAYLOAD_NAME = CONFIG_SPL_FS_LOAD_PAYLOAD_NAME CONFIG_SYS_MMC_SD_FAT_BOOT_PARTITION = CONFIG_SYS_MMC_SD_FS_BOOT_PARTITION Signed-off-by: Guillaume GARDET guillaume.gar...@free.fr Cc: Tom Rini tr...@ti.com ---8--- Sorry for the noise, just now, I fetch the u-boot master branch and find this name is changed again in the following commit: ---8--- commit e2ccdf89a0196b40b445700670777ebee231756d Author: Paul Kocialkowski cont...@paulk.fr Date: Sat Nov 8 23:14:55 2014 +0100 MMC SD fs boot partition config coding style and proper description CONFIG_SYS_MMC_SD_FS_BOOT_PARTITION ought to be called CONFIG_SYS_MMCSD_FS_BOOT_PARTITION to keep it consistent with other config options such as: CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR. In addition, it is not related to raw mode booting but to fs mode instead. Signed-off-by: Paul Kocialkowski cont...@paulk.fr Reviewed-by: Tom Rini tr...@ti.com ---8--- Thanks, I will rebase it to u-boot latest master branch and will fix it in v2 version. Ouch, i was just on master and didn't check git history... Wow two renames of that variable in master!!!. ;) Regards, -- Robert Nelson http://www.rcn-ee.com/ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] ti, am3517: errata 430973 workaround
On Mon, Dec 8, 2014 at 4:19 PM, Jeroen Hofstee jer...@myspectrum.nl wrote: Hi, A while ago [1], a RFC was posted to disable workaround for besides others, errata 430973. It is a bit unclear to me which revision actually need this workaround, but as suggested in [2] also enabling this workaround in Linux seem to make some weird problems go away in linux (signal 4, bad instruction, 11 segfaults etc). As said, I am a bit in doubt why this works. The board in question is a tam3517 derived one: cat /proc/cpuinfo Processor: ARMv7 Processor rev 7 (v7l) BogoMIPS: 397.57 Features: swp half thumb fastmult vfp edsp neon vfpv3 tls CPU implementer: 0x41 CPU architecture: 7 CPU variant: 0x1 CPU part: 0xc08 CPU revision: 7 Which makes this a r1p7 I assume, and hence the workaround of linux, CONFIG_ARM_ERRATA_430973, This option enables the workaround for the 430973 Cortex-A8 (r1p0..r1p2) erratum, should not be needed it seems. Digging thru my old beagle notes 430973 is also needed for r1p3 (dm3730/bb-xm), so that config option was never updated since the errata was first discovered in r1p2 devices.. Fixed in r2p1 sounds about right, as i know for sure it works fine in 'r3p2' (am335x/bbb) Regards, -- Robert Nelson http://www.rcn-ee.com/ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [ANN] U-Boot v2015.01-rc3 released
On Mon, Dec 8, 2014 at 3:44 PM, Tom Rini tr...@ti.com wrote: Hey all, I've pushed v2015.01-rc3 out to the repository and tarballs should exist soon. So, we're nearing the end now, relatively speaking, so things should start getting quieter. I'd like everyone to please build their respective areas and make sure everything is building right. As always, if anything else is broken please speak up. On mx53loco_defconfig I'm getting: drivers/built-in.o: In function `reset_sata': /var/lib/jenkins/jobs/github_Bootloader-Builder/workspace/scratch/u-boot/drivers/block/dwc_ahsata.c:611: undefined reference to `disable_sata_clock' /var/lib/jenkins/jobs/github_Bootloader-Builder/workspace/dl/gcc-linaro-arm-linux-gnueabihf-4.9-2014.09_linux/bin/arm-linux-gnueabihf-ld.bfd: BFD (crosstool-NG linaro-1.13.1-4.9-2014.09 - Linaro GCC 4.9-2014.09) 2.24.0.20140829 Linaro 2014.09 assertion fail /cbuild/slaves/oorts/crosstool-ng/builds/arm-linux-gnueabihf-linux/.build/src/binutils-linaro-2.24.0-2014.09/bfd/elf32-arm.c:7710 /var/lib/jenkins/jobs/github_Bootloader-Builder/workspace/dl/gcc-linaro-arm-linux-gnueabihf-4.9-2014.09_linux/bin/arm-linux-gnueabihf-ld.bfd: error: required section '.rel.plt' not found in the linker script /var/lib/jenkins/jobs/github_Bootloader-Builder/workspace/dl/gcc-linaro-arm-linux-gnueabihf-4.9-2014.09_linux/bin/arm-linux-gnueabihf-ld.bfd: final link failed: Invalid operation Makefile:1052: recipe for target 'u-boot' failed make: *** [u-boot] Error 1 Which has a fix: http://git.denx.de/?p=u-boot/u-boot-imx.git;a=summary Looks like we sata: fix reset_sata for dwc_ahsata Regards, -- Robert Nelson http://www.rcn-ee.com/ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [ANN] U-Boot v2015.01-rc3 released
On Mon, Dec 8, 2014 at 7:52 PM, Robert Nelson robertcnel...@gmail.com wrote: On Mon, Dec 8, 2014 at 3:44 PM, Tom Rini tr...@ti.com wrote: Hey all, I've pushed v2015.01-rc3 out to the repository and tarballs should exist soon. So, we're nearing the end now, relatively speaking, so things should start getting quieter. I'd like everyone to please build their respective areas and make sure everything is building right. As always, if anything else is broken please speak up. On mx53loco_defconfig I'm getting: drivers/built-in.o: In function `reset_sata': /var/lib/jenkins/jobs/github_Bootloader-Builder/workspace/scratch/u-boot/drivers/block/dwc_ahsata.c:611: undefined reference to `disable_sata_clock' /var/lib/jenkins/jobs/github_Bootloader-Builder/workspace/dl/gcc-linaro-arm-linux-gnueabihf-4.9-2014.09_linux/bin/arm-linux-gnueabihf-ld.bfd: BFD (crosstool-NG linaro-1.13.1-4.9-2014.09 - Linaro GCC 4.9-2014.09) 2.24.0.20140829 Linaro 2014.09 assertion fail /cbuild/slaves/oorts/crosstool-ng/builds/arm-linux-gnueabihf-linux/.build/src/binutils-linaro-2.24.0-2014.09/bfd/elf32-arm.c:7710 /var/lib/jenkins/jobs/github_Bootloader-Builder/workspace/dl/gcc-linaro-arm-linux-gnueabihf-4.9-2014.09_linux/bin/arm-linux-gnueabihf-ld.bfd: error: required section '.rel.plt' not found in the linker script /var/lib/jenkins/jobs/github_Bootloader-Builder/workspace/dl/gcc-linaro-arm-linux-gnueabihf-4.9-2014.09_linux/bin/arm-linux-gnueabihf-ld.bfd: final link failed: Invalid operation Makefile:1052: recipe for target 'u-boot' failed make: *** [u-boot] Error 1 Which has a fix: http://git.denx.de/?p=u-boot/u-boot-imx.git;a=summary (oh gmail and the evil cltr-enter shortcut...) This commit: http://git.denx.de/?p=u-boot/u-boot-imx.git;a=commit;h=dd1c8f1b5fb63a682fce62a53464108d8587b0a2 Regards, -- Robert Nelson http://www.rcn-ee.com/ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] Add option -r to env import to allow import of text files with CRLF as line endings
On Thu, Aug 14, 2014 at 10:49 AM, Stephen Warren swar...@wwwdotorg.org wrote: On 08/14/2014 02:25 AM, Alexander Holler wrote: Am 31.07.2014 21:57, schrieb Stephen Warren: Huh, I do see that now. I must have been looking at the content of common/cmd_nvedit.c from the wrong branch, which didn't include that patch. I could have sworn I checked git history too, but evidently not. It is indeed clearly there right before the patches which use it. Sorry for the noise. As I've just remembered where I did see your name before, the config for the rpi (as found in 2004.04) misses the uenvcmd. That's necessary to execute commands when using uEnv.txt. It's easily done with something like the following: env import -t -r $loadaddr $filesize; \ if test -n \$uenvcmd\; then \ echo \Running uenvcmd ...\; \ run uenvcmd; \ fi; \ My intention was that uEnv.txt be used to set up environment variables, not to allow its use for custom scripts. The check for if uenvcmd is set then run uenvcmd syntax, should really be pushed into the distro default stuff. As that syntax is used by default for a lot of different targets in u-boot. Most users who deal with u-boot (even if they don't want to) seem to understand it. Regards, -- Robert Nelson http://www.rcn-ee.com/ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] omap3_beagle: xM A/B validate new dtb exits in file system
On Fri, May 2, 2014 at 3:15 PM, robertcnelson robertcnel...@gmail.com wrote:
From: Robert Nelson robertcnel...@gmail.com
Fall back to previous dtb used when omap3-beagle-xm-ab.dtb doesn't exist in
file system
Signed-off-by: Robert Nelson robertcnel...@gmail.com
CC: Tom Rini tr...@ti.com
CC: Nishanth Menon n...@ti.com
---
include/configs/omap3_beagle.h | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/include/configs/omap3_beagle.h b/include/configs/omap3_beagle.h
index a1d38ff..06b9006 100644
--- a/include/configs/omap3_beagle.h
+++ b/include/configs/omap3_beagle.h
@@ -248,6 +248,12 @@
setenv fdtfile omap3-beagle-xm.dtb; fi; \
if test $fdtfile = undefined; then \
echo WARNING: Could not determine device tree to
use; fi; \0 \
+ validatefdt= \
+ if test $beaglerev = xMAB; then \
+ if test ! -e mmc ${bootpart} ${bootdir}/${fdtfile};
then \
+ setenv fdtfile omap3-beagle-xm.dtb; \
+ fi; \
+ fi; \0 \
bootenv=uEnv.txt\0 \
loadbootenv=fatload mmc ${mmcdev} ${loadaddr} ${bootenv}\0 \
importbootenv=echo Importing environment from mmc ...; \
@@ -263,7 +269,7 @@
rootfstype=${ramrootfstype}\0 \
loadramdisk=load mmc ${bootpart} ${rdaddr} ${bootdir}/${ramdisk}\0 \
loadimage=load mmc ${bootpart} ${loadaddr} ${bootdir}/${bootfile}\0
\
- loadfdt=load mmc ${bootpart} ${fdtaddr} ${bootdir}/${fdtfile}\0 \
+ loadfdt=run validatefdt; load mmc ${bootpart} ${fdtaddr}
${bootdir}/${fdtfile}\0 \
mmcboot=echo Booting from mmc ...; \
run mmcargs; \
bootm ${loadaddr}\0 \
--
1.9.2
Little git send-email failure here, I was trying to send this second
as patch as [RFC].
This is my first thoughts of keeping backward compatibility with less
then v3.15-rc3 kernels.
Thoughts?
Regards,
--
Robert Nelson
http://www.rcn-ee.com/
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [BeagleBone Black] AM335x CPU frequency
On Wed, Apr 9, 2014 at 6:59 AM, Xuebing Wang xbi...@gmail.com wrote: Hi community, Can someone confirm that in the latest u-boot code, by default BeagleBone Black CPU AM335x is using opp100 (dpll_mpu_opp100), and CPU runs at 1GHz? Thanks. http://git.denx.de/?p=u-boot.git;a=blob;f=board/ti/am335x/board.c;hb=HEAD#l280 Regards, -- Robert Nelson http://www.rcn-ee.com/ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] [PATCH] omap3_beagle: fdt: xMA/B set hsusb2_power_reg active-high
On Tue, Jan 28, 2014 at 5:31 PM, Robert Nelson robertcnel...@gmail.com wrote:
With the xM revision C, the DC control of the usb hub was inverted.
By adding the enable-active-high property to hsusb2_power_reg, mainline
omap3-beagle-xm.dtb
will now activiate properly activate the usb hub on older xMA/B varients.
Signed-off-by: Robert Nelson robertcnel...@gmail.com
CC: Tom Rini tr...@ti.com
---
include/configs/omap3_beagle.h | 4
1 file changed, 4 insertions(+)
diff --git a/include/configs/omap3_beagle.h b/include/configs/omap3_beagle.h
index c58bc91..d7d63ce 100644
--- a/include/configs/omap3_beagle.h
+++ b/include/configs/omap3_beagle.h
@@ -249,6 +249,9 @@
setenv fdtfile omap3-beagle-xm.dtb; fi; \
if test $fdtfile = undefined; then \
echo WARNING: Could not determine device tree to
use; fi; \0 \
+ fixfdt= \
+ if test $beaglerev = xMAB; then \
+ fdt addr ${fdtaddr}; fdt resize; fdt set
/hsusb2_power_reg enable-active-high; fi; \0 \
bootenv=uEnv.txt\0 \
loadbootenv=fatload mmc ${mmcdev} ${loadaddr} ${bootenv}\0 \
importbootenv=echo Importing environment from mmc ...; \
@@ -308,6 +311,7 @@
setenv bootfile zImage; \
if run loadimage; then \
run loadfdt; \
+ run fixfdt; \
run mmcbootz; \
fi; \
--
1.8.5.3
I've listed this as an RFC, as i'm not sure if there is a generic way
we should be doing device tree fixup's in u-boot.
I have thought about splitting omap3-beagle-xm.dtb into two variants
ab and c with just a simple one line delta:
https://github.com/RobertCNelson/armv7-multiplatform/blob/v3.13.x/patches/omap3_beagle_xm_rework/0002-ARM-dts-omap3-beagle-xm-ab-usb-host-is-active-high-t.patch
But it's just so trivial to just fix it in u-boot instead.
Thoughts?
Regards,
--
Robert Nelson
http://www.rcn-ee.com/
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] [PATCH] omap3_beagle: fdt: xMA/B set hsusb2_power_reg active-high
Well, we have per-platform fixups in the tree today. However this now means that only u-boot is going to provide a correct and fully functional tree for those revs, which isn't good imho for the beagleboard community use cases of older u-boots / distro support / non-u-boot bootloader support, so it'd probably be best to have per rev DTs and update findfdt to use the right one. Thanks Tom, The thing is, usb has been broken on the xMA/B's ever since we first setup findfdt to use the omap3-beagle-xm.dtb. Although the usb ehci port was finally fixed in v3.13-rcX, so nobody really noticed these pre-xMC's where broken in the first place. That's why I thought it made more sense to fix it in u-boot, as we then get mainline v3.13.x working out of the box for free. (if the distro upgrades u-boot) Otherwise all distro's need to carry a kernel patch for v3.13/v3.14 adding a new omap3-beagle-xm-ab.dtb variant. I can go either way, as i've been pushing out images with the *-ab.dtb / *-c.dtb variants running v3.12/v3.13 to the beagleboard community. But while updating my base image to v2014.01, i thought pushing it to u-boot might be better in the long run. Regards, -- Robert Nelson http://www.rcn-ee.com/ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Fwd: [ Uboot code understanding guide ]
On Tue, Jan 28, 2014 at 11:16 AM, Devarsh gadhia devarsh.gad...@gmail.com wrote: Hey wolfgang, I am trying to port uboot on beagle boneblack. Eventhogh uboot has support for beagle board(but not for BBB), I'd like to port uboot 2013.10 on BBB as 1 task of ubuntu porting on BBB. Ah why a 3rd port? there's always two configs you can use on the BBB.. am335x_evm which supports: AM335x GP EVM AM335x EVM SK Beaglebone White Beaglebone Black or the am335x_boneblack which is just a tweak of am335x_evm to support only the BBB Regards, -- Robert Nelson http://www.rcn-ee.com/ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [RFC] [PATCH] omap3_beagle: fdt: xMA/B set hsusb2_power_reg active-high
With the xM revision C, the DC control of the usb hub was inverted.
By adding the enable-active-high property to hsusb2_power_reg, mainline
omap3-beagle-xm.dtb
will now activiate properly activate the usb hub on older xMA/B varients.
Signed-off-by: Robert Nelson robertcnel...@gmail.com
CC: Tom Rini tr...@ti.com
---
include/configs/omap3_beagle.h | 4
1 file changed, 4 insertions(+)
diff --git a/include/configs/omap3_beagle.h b/include/configs/omap3_beagle.h
index c58bc91..d7d63ce 100644
--- a/include/configs/omap3_beagle.h
+++ b/include/configs/omap3_beagle.h
@@ -249,6 +249,9 @@
setenv fdtfile omap3-beagle-xm.dtb; fi; \
if test $fdtfile = undefined; then \
echo WARNING: Could not determine device tree to use;
fi; \0 \
+ fixfdt= \
+ if test $beaglerev = xMAB; then \
+ fdt addr ${fdtaddr}; fdt resize; fdt set
/hsusb2_power_reg enable-active-high; fi; \0 \
bootenv=uEnv.txt\0 \
loadbootenv=fatload mmc ${mmcdev} ${loadaddr} ${bootenv}\0 \
importbootenv=echo Importing environment from mmc ...; \
@@ -308,6 +311,7 @@
setenv bootfile zImage; \
if run loadimage; then \
run loadfdt; \
+ run fixfdt; \
run mmcbootz; \
fi; \
--
1.8.5.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] omap3_beagle: use omap3-beagle.dtb for the C4 revision
findftd is currently setting fdtfile to undefined for the beagle c4, select omap3-beagle.dtb instead Signed-off-by: Robert Nelson robertcnel...@gmail.com --- include/configs/omap3_beagle.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/include/configs/omap3_beagle.h b/include/configs/omap3_beagle.h index 1b566c0..c58bc91 100644 --- a/include/configs/omap3_beagle.h +++ b/include/configs/omap3_beagle.h @@ -241,6 +241,8 @@ setenv fdtfile omap3-beagle.dtb; fi; \ if test $beaglerev = Cx; then \ setenv fdtfile omap3-beagle.dtb; fi; \ + if test $beaglerev = C4; then \ + setenv fdtfile omap3-beagle.dtb; fi; \ if test $beaglerev = xMAB; then \ setenv fdtfile omap3-beagle-xm.dtb; fi; \ if test $beaglerev = xMC; then \ -- 1.8.5.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Question: booting Linux from ext4 mmc partition
On Mon, Jan 6, 2014 at 8:56 AM, nidalpres nidalp...@gmail.com wrote: Hi all! I was following instructions from http://eewiki.net/display/linuxonarm/iMX233-OLinuXino in order to get mainline kernel to boot off of my olinuxino micro board. I have created two partitions on my SD card: Device Boot Start End Blocks Id System /dev/sde12048 67583 32768 53 OnTrack DM6 Aux3 /dev/sde2 67584 7829503 3880960 83 Linux and installed everything as per instructions. However on boot this is what I get on console: HTLLCLC U-Boot 2013.10-dirty (Jan 05 2014 - 19:38:28) CPU: Freescale i.MX23 rev1.4 at 454 MHz BOOT: SSP SD/MMC #0 DRAM: 64 MiB MMC: MXS MMC: 0 *** Warning - bad CRC, using default environment In:serial Out: serial Err: serial Net: Net Initialization Skipped No ethernet found. Hit any key to stop autoboot: 0 mmc0 is current device SD/MMC found on device 0 221 bytes read in 149 ms (1000 Bytes/s) Importing environment from mmc (uEnv.txt)... Checking if uenvcmd is set ... Running default loadzimage ... MMC0: Data error with command 18 (status 0xf0302020)! ** ext4fs_devread read error - block = I couldn't find anywhere what ext4fs_devread read error - block means. Found message origin in ext4fs_devread() function in u-boot source after some time but I really can't get my head around on what it means just by reading code. I suspect it doesn't like block sizes or something, not sure. So I changed second partition to ext2 (instead of ext4) an changed env parameters to instruct uboot that it is ext2 partition, nothing changed. Then I changed source header file include/configs/mx23_olinuxino.h and removed #define CONFIG_CMD_EXT4 from it hoping it will remove ext4 support. I also changed hardcoded env parameters in same file from mmcrootfstype=ext4 to mmcrootfstype=ext2. Recompiled u-boot, dd it to sd card, rinse and repeat, got exactly the same response on console you see above. I give up for today after 3 hours of battling with it. I plan to make 3 partitions: amtrak, vfat (for kernel) and ext4 (for rootfs). But if ext4fs_devread persists to complain (and I apparently haven't removed it from code) I don't think it would work either. What is going on? Can anyone give me some pointers what to do next? Just for sanity sake, have you tried try a different (brand) microSD card? Regards, -- Robert Nelson http://www.rcn-ee.com/ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Question: booting Linux from ext4 mmc partition
On Tue, Jan 7, 2014 at 1:26 PM, nidalpres nidalp...@gmail.com wrote: Hi Robert! I have 4-5 microsd cards (Kingston, SanDisk, Samsung), 4 and 8GB in size, tried two, same thing. I also tried vfat partition and disabled support for ext2 AND ext4 completely in u-boot, and basically same thing happened. Then I tried to list/load files manually from vfat/ext4 partitions using u-boot command prompt. I can list vfat and ext4 partitions and load files from them into memory. However, once I load uImage file everything regarding mmc access and loading files breaks. I seems to me that loading one big file somehow corrupts something (hahah, very precise explanation). uImage is little over 4MB. So if it's a failing at 4MB, at what size does it work as you maybe over writing memory.. Regards, -- Robert Nelson http://www.rcn-ee.com/ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/5] port wandboards to use the generic distro configs
On Thu, Dec 5, 2013 at 8:18 PM, Dennis Gilmore den...@ausil.us wrote:
Signed-off-by: Dennis Gilmore den...@ausil.us
---
include/configs/wandboard.h | 40 +++-
1 file changed, 35 insertions(+), 5 deletions(-)
diff --git a/include/configs/wandboard.h b/include/configs/wandboard.h
index e9c7e64..02d8968 100644
--- a/include/configs/wandboard.h
+++ b/include/configs/wandboard.h
@@ -40,6 +40,9 @@
#define CONFIG_CONS_INDEX 1
#define CONFIG_BAUDRATE115200
+/* enable generic distro config */
+#define DISTRO_DEFAULTS 1
+
/* Command definition */
#include config_cmd_default.h
@@ -48,7 +51,6 @@
#define CONFIG_CMD_BMODE
#define CONFIG_CMD_SETEXPR
-#define CONFIG_BOOTDELAY 5
#define CONFIG_SYS_MEMTEST_START 0x1000
#define CONFIG_SYS_MEMTEST_END (CONFIG_SYS_MEMTEST_START + 500 *
SZ_1M)
@@ -65,6 +67,9 @@
#define CONFIG_CMD_MMC
#define CONFIG_GENERIC_MMC
#define CONFIG_BOUNCE_BUFFER
+
+#define CONFIG_BOOTDELAY 5
+
#define CONFIG_CMD_EXT2
#define CONFIG_CMD_FAT
#define CONFIG_DOS_PARTITION
@@ -74,6 +79,11 @@
#define CONFIG_CMD_DHCP
#define CONFIG_CMD_MII
#define CONFIG_CMD_NET
+
+#define CONFIG_OF_LIBFDT
+#define CONFIG_CMD_BOOTZ
+
+/* Ethernet Configuration */
#define CONFIG_FEC_MXC
#define CONFIG_MII
#define IMX_FEC_BASE ENET_BASE_ADDR
@@ -113,8 +123,30 @@
fdt_high=0x\0 \
initrd_high=0x\0 \
fdt_file= CONFIG_DEFAULT_FDT_FILE \0 \
- fdt_addr=0x1100\0 \
+ fdt_addr=0x1110\0 \
+ fdt_addr_r=0x1120\0 \
+ pxefile_addr_r=0x1130\0 \
+ scr_addr_r=0x1140\0 \
+ kernel_addr_r=0x1150\0 \
+ ramdisk_addr_r=0x1350\0 \
boot_fdt=try\0 \
+ bootcmd_setup=mmc rescan\0 \
+ bootcmd_pxe=setenv bootfile \\ ;dhcp; tftp ${fdt_addr}
/dtb/${fdt_file}; pxe get; pxe boot\0 \
+ bootcmd_disk_scr=ext2load ${boot_ifc} ${bootdevice} ${scr_addr_r}
boot.scr
Why all the non-generic ext2load's? use just load, then it'll work
with both fat, ext2/3/4 btrfs...
Regards,
--
Robert Nelson
http://www.rcn-ee.com/
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/5] port wandboards to use the generic distro configs
On Thu, Dec 5, 2013 at 11:01 PM, Dennis Gilmore den...@ausil.us wrote:
El Thu, 5 Dec 2013 21:47:43 -0600
Robert Nelson robertcnel...@gmail.com escribió:
On Thu, Dec 5, 2013 at 8:18 PM, Dennis Gilmore den...@ausil.us
wrote:
Signed-off-by: Dennis Gilmore den...@ausil.us
---
include/configs/wandboard.h | 40
+++- 1 file changed, 35
insertions(+), 5 deletions(-)
diff --git a/include/configs/wandboard.h
b/include/configs/wandboard.h index e9c7e64..02d8968 100644
--- a/include/configs/wandboard.h
+++ b/include/configs/wandboard.h
@@ -40,6 +40,9 @@
#define CONFIG_CONS_INDEX 1
#define CONFIG_BAUDRATE115200
+/* enable generic distro config */
+#define DISTRO_DEFAULTS 1
+
/* Command definition */
#include config_cmd_default.h
@@ -48,7 +51,6 @@
#define CONFIG_CMD_BMODE
#define CONFIG_CMD_SETEXPR
-#define CONFIG_BOOTDELAY 5
#define CONFIG_SYS_MEMTEST_START 0x1000
#define CONFIG_SYS_MEMTEST_END (CONFIG_SYS_MEMTEST_START +
500 * SZ_1M) @@ -65,6 +67,9 @@
#define CONFIG_CMD_MMC
#define CONFIG_GENERIC_MMC
#define CONFIG_BOUNCE_BUFFER
+
+#define CONFIG_BOOTDELAY 5
+
#define CONFIG_CMD_EXT2
#define CONFIG_CMD_FAT
#define CONFIG_DOS_PARTITION
@@ -74,6 +79,11 @@
#define CONFIG_CMD_DHCP
#define CONFIG_CMD_MII
#define CONFIG_CMD_NET
+
+#define CONFIG_OF_LIBFDT
+#define CONFIG_CMD_BOOTZ
+
+/* Ethernet Configuration */
#define CONFIG_FEC_MXC
#define CONFIG_MII
#define IMX_FEC_BASE ENET_BASE_ADDR
@@ -113,8 +123,30 @@
fdt_high=0x\0 \
initrd_high=0x\0 \
fdt_file= CONFIG_DEFAULT_FDT_FILE \0 \
- fdt_addr=0x1100\0 \
+ fdt_addr=0x1110\0 \
+ fdt_addr_r=0x1120\0 \
+ pxefile_addr_r=0x1130\0 \
+ scr_addr_r=0x1140\0 \
+ kernel_addr_r=0x1150\0 \
+ ramdisk_addr_r=0x1350\0 \
boot_fdt=try\0 \
+ bootcmd_setup=mmc rescan\0 \
+ bootcmd_pxe=setenv bootfile \\ ;dhcp; tftp
${fdt_addr} /dtb/${fdt_file}; pxe get; pxe boot\0 \
+ bootcmd_disk_scr=ext2load ${boot_ifc} ${bootdevice}
${scr_addr_r} boot.scr
Why all the non-generic ext2load's? use just load, then it'll work
with both fat, ext2/3/4 btrfs...
Regards,
the pxe code requires you specify the filesystem for the sysboot
command, and as /boot needs to be ext ive kept it consistent. Ive also
not narrowed down the option to enable load to work, in my testing it
did not work.
Ah, i see the issue, #define CONFIG_CMD_FS_GENERIC isn't defined yet
for the wandboard in mainline u-boot, as you don't set it either in
your patch, so of course a generic load won't work..
So if you add:
#define CONFIG_CMD_EXT4
#define CONFIG_CMD_FS_GENERIC
after:
#define CONFIG_CMD_EXT2
in your patch you can drop all the ext2load non-sense for generic loads.
I've been shipping ubuntu/debian images with '#define
CONFIG_CMD_FS_GENERIC' and 'load' for the wand since v2013.07 with no
issues..
Regards,
--
Robert Nelson
http://www.rcn-ee.com/
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/5] port wandboards to use the generic distro configs
Why all the non-generic ext2load's? use just load, then it'll work with both fat, ext2/3/4 btrfs... Regards, the pxe code requires you specify the filesystem for the sysboot command, and as /boot needs to be ext ive kept it consistent. Ive also not narrowed down the option to enable load to work, in my testing it did not work. having said that I just found CONFIG_CMD_FS_GENERIC which is not set, though cmd_pxe.c will need some patching to not require specifying a filesystem I can see fixing cmd_pxe.c could be done later. But as just a generic uEnv.txt user, I do like the idea of having a consistent variable naming setup for a bunch of boards. So i can easily convert my stuff to this setup, but the ext2load vs a generic load was the one big issue it was missing. Regards, -- Robert Nelson http://www.rcn-ee.com/ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] toolchain problems when building iMX6 mx6qsabreauto (and another bootloader tool)
On Fri, Nov 29, 2013 at 4:28 PM, Wolfgang Denk w...@denx.de wrote: Dear Christian Gmeiner, In message cah9nwweb6s+3s4o25d7cifob9y3_7jmhosjo6o78fijquwz...@mail.gmail.com you wrote: I am running into the same problem. Me wonders which patch/change triggers this problem. I am using the same toolchain since I started to work with u-boot and it fails with the latest rc. Maybe Linaro started using a hard-float configuration only recently? For what it's worth, i just ran a git bisect on this issue today, as this compiler worked fine with v2013.10 toolchain: arm-linux-gnueabihf-gcc (crosstool-NG linaro-1.13.1-4.8-2013.10 - Linaro GCC 2013.10) 4.8.2 20131014 (prerelease) 762a88ccf8540948fbf8c31b40a29d1e0684a25b is the first bad commit commit 762a88ccf8540948fbf8c31b40a29d1e0684a25b Author: Pierre Aubert p.aub...@staubli.com Date: Thu Sep 19 17:48:59 2013 +0200 mx6: compute PLL PFD frequencies rather than using defines Signed-off-by: Pierre Aubert p.aub...@staubli.com CC: Stefano Babic sba...@denx.de :04 04 c3dba1387015304c14486872c9776d008d9a3b03 1f16de9cee07af71e12f1a746dcd962c9eb84bb0 M arch git bisect log git bisect start # good: [183acb700378a8cfc5d50a01a65de93fb2c24586] Prepare v2013.10 git bisect good 183acb700378a8cfc5d50a01a65de93fb2c24586 # bad: [d19ad726bcd5d9106f7ba9c750462fcc369f1020] Prepare v2014.01-rc1 git bisect bad d19ad726bcd5d9106f7ba9c750462fcc369f1020 # good: [65ba7add0d609bbd035b8d42fafdaf428ac24751] time: add weak annotation to timer_read_counter declaration git bisect good 65ba7add0d609bbd035b8d42fafdaf428ac24751 # bad: [c3ebb8c38a5da5e40da2786c5d850d1f6555ff95] Merge branch 'master' of git://git.denx.de/u-boot-mpc85xx git bisect bad c3ebb8c38a5da5e40da2786c5d850d1f6555ff95 # bad: [3285d4ca197928a048d3dda86751b5d26e6e0e86] Merge branch 'u-boot-imx/master' into 'u-boot-arm/master' git bisect bad 3285d4ca197928a048d3dda86751b5d26e6e0e86 # good: [552998e5f7655ba8fd3acff400012bd651edff06] TI:armv7: Change CONFIG_SYS_SPL_ARGS_ADDR to a higher address git bisect good 552998e5f7655ba8fd3acff400012bd651edff06 # bad: [195d130da1c2705f96571b7265312bdfa8a83fee] Revert configs: imx: Make CONFIG_SYS_PROMPT uniform across FSL boards git bisect bad 195d130da1c2705f96571b7265312bdfa8a83fee # bad: [4867b634b7c0e5ede258b4998fa4b2710e7daacf] ARM: mx5: Enable L2 cache git bisect bad 4867b634b7c0e5ede258b4998fa4b2710e7daacf # bad: [0c5e26678b18e136c1514bf769a16060ae1b5ff8] udoo: Add initial support for mx6q udoo board git bisect bad 0c5e26678b18e136c1514bf769a16060ae1b5ff8 # bad: [6654f33c9b520bd4073c7f82a13044e79bc14898] ARM: mxs: tools: Use mkimage for BootStream generation git bisect bad 6654f33c9b520bd4073c7f82a13044e79bc14898 # bad: [762a88ccf8540948fbf8c31b40a29d1e0684a25b] mx6: compute PLL PFD frequencies rather than using defines git bisect bad 762a88ccf8540948fbf8c31b40a29d1e0684a25b # first bad commit: [762a88ccf8540948fbf8c31b40a29d1e0684a25b] mx6: compute PLL PFD frequencies rather than using defines using USE_PRIVATE_LIBGCC=yes causes another error.. arch/arm/cpu/armv7/mx6/built-in.o: In function `mxc_get_pll_pfd': /opt/github/u-boot/arch/arm/cpu/armv7/mx6/clock.c:126: undefined reference to `__aeabi_uldivmod' /opt/gcc/gcc-linaro-arm-linux-gnueabihf-4.8-2013.10_linux/bin/arm-linux-gnueabihf-ld.bfd: BFD (crosstool-NG linaro-1.13.1-4.8-2013.10 - Linaro GCC 2013.10) 2.23.2.20130610 Linaro 2013.10-4 assertion fail /cbuild/slaves/oorts/crosstool-ng/builds/arm-linux-gnueabihf-linux/.build/src/binutils-linaro-2.23.2-2013.10-4/bfd/elf32-arm.c:7687 /opt/gcc/gcc-linaro-arm-linux-gnueabihf-4.8-2013.10_linux/bin/arm-linux-gnueabihf-ld.bfd: error: required section '.rel.plt' not found in the linker script /opt/gcc/gcc-linaro-arm-linux-gnueabihf-4.8-2013.10_linux/bin/arm-linux-gnueabihf-ld.bfd: final link failed: Invalid operation make: *** [u-boot] Error 1 Regards, -- Robert Nelson http://www.rcn-ee.com/ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] toolchain problems when building iMX6 mx6qsabreauto (and another bootloader tool)
On Wed, Dec 4, 2013 at 9:35 AM, Måns Rullgård m...@mansr.com wrote: Robert Nelson robertcnel...@gmail.com writes: On Fri, Nov 29, 2013 at 4:28 PM, Wolfgang Denk w...@denx.de wrote: Dear Christian Gmeiner, In message cah9nwweb6s+3s4o25d7cifob9y3_7jmhosjo6o78fijquwz...@mail.gmail.com you wrote: I am running into the same problem. Me wonders which patch/change triggers this problem. I am using the same toolchain since I started to work with u-boot and it fails with the latest rc. Maybe Linaro started using a hard-float configuration only recently? For what it's worth, i just ran a git bisect on this issue today, as this compiler worked fine with v2013.10 toolchain: arm-linux-gnueabihf-gcc (crosstool-NG linaro-1.13.1-4.8-2013.10 - Linaro GCC 2013.10) 4.8.2 20131014 (prerelease) 762a88ccf8540948fbf8c31b40a29d1e0684a25b is the first bad commit commit 762a88ccf8540948fbf8c31b40a29d1e0684a25b Author: Pierre Aubert p.aub...@staubli.com Date: Thu Sep 19 17:48:59 2013 +0200 mx6: compute PLL PFD frequencies rather than using defines That commit introduces a 64-bit division without using the lldiv() function, which pulls in previously unused libgcc stuff. Try this patch: diff --git a/arch/arm/cpu/armv7/mx6/clock.c b/arch/arm/cpu/armv7/mx6/clock.c index 873d9d0..752b3c8 100644 --- a/arch/arm/cpu/armv7/mx6/clock.c +++ b/arch/arm/cpu/armv7/mx6/clock.c @@ -5,6 +5,7 @@ */ #include common.h +#include div64.h #include asm/io.h #include asm/errno.h #include asm/arch/imx-regs.h @@ -123,8 +124,8 @@ static u32 mxc_get_pll_pfd(enum pll_clocks pll, int pfd_num) return 0; } - return (freq * 18) / ((div ANATOP_PFD_FRAC_MASK(pfd_num)) - ANATOP_PFD_FRAC_SHIFT(pfd_num)); + return lldiv(freq * 18, (div ANATOP_PFD_FRAC_MASK(pfd_num)) + ANATOP_PFD_FRAC_SHIFT(pfd_num)); } static u32 get_mcu_main_clk(void) Thanks Måns! That fixed it... Regards, -- Robert Nelson http://www.rcn-ee.com/ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Sources for MLO on BeagleBone Black?
On Wed, Dec 4, 2013 at 2:34 PM, Satz Klauer satzkla...@googlemail.com wrote: Hi Tom, point is, I want to change some functionality of bootloader - thus I want to know where it is built from. It is nice when MLO file appears automagically but in my special case I like to know where it comes from exaclty. http://git.denx.de/?p=u-boot.git;a=blob;f=arch/arm/cpu/armv7/am33xx/config.mk#l7 Everything built inside CONFIG_SPL_BUILD for the particular TI/OMAP based target.. Regards, -- Robert Nelson http://www.rcn-ee.com/ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [[PATCH v2]pandaboard: 1/1] Modification of Elpida DDR2 RAM for Pandaboard-ES Rev B3
On Thu, Nov 14, 2013 at 4:06 AM, Hardik hardik.pa...@volansystech.com wrote:
From: Hardik Patel hardik.pa...@volansystech.com
Signed-off-by: Hardik Patel hardik.pa...@volansystech.com
---
arch/arm/cpu/armv7/omap4/sdram_elpida.c |2 +-
board/ti/panda/panda.c | 24
2 files changed, 25 insertions(+), 1 deletion(-)
diff --git a/arch/arm/cpu/armv7/omap4/sdram_elpida.c
b/arch/arm/cpu/armv7/omap4/sdram_elpida.c
index e4c8316..9fbdeea 100644
--- a/arch/arm/cpu/armv7/omap4/sdram_elpida.c
+++ b/arch/arm/cpu/armv7/omap4/sdram_elpida.c
@@ -123,7 +123,7 @@ static void emif_get_reg_dump_sdp(u32 emif_nr, const
struct emif_regs **regs)
*regs = emif_regs_elpida_200_mhz_2cs;
else if (omap4_rev == OMAP4430_ES2_3)
*regs = emif_regs_elpida_400_mhz_1cs;
- else if (omap4_rev OMAP4470_ES1_0)
+ else if (omap4_rev OMAP4470_ES1_0 !is_panda_es_rev_b3())
*regs = emif_regs_elpida_400_mhz_2cs;
else
*regs = emif_regs_elpida_400_mhz_1cs;
diff --git a/board/ti/panda/panda.c b/board/ti/panda/panda.c
index c104024..5a7f80a 100644
--- a/board/ti/panda/panda.c
+++ b/board/ti/panda/panda.c
@@ -122,6 +122,30 @@ int get_board_revision(void)
return board_id;
}
+/*
+* Routine: is_panda_es_rev_b3
+* Description: Detect if we are running on B3 version of ES panda board,
+* This can be done by reading the level of GPIO 171
+* and checking the processor revisions.
+* GPIO171: 1 = Panda ES Rev B3
+*/
+u8 is_panda_es_rev_b3(void)
+{
+int processor_rev = omap_revision();
+int ret = 0;
+
+if ((processor_rev = OMAP4460_ES1_0
+ processor_rev = OMAP4460_ES1_1)) {
+
+/* Setup the mux for the common board ID pins (gpio 171) */
+writew((IEN | M3), (*ctrl)-control_padconf_core_base +
UNIPRO_TX0);
+
+/* if processor_rev is panda ES and GPIO171 is 1, it is rev
b3 */
+ret = gpio_get_value(PANDA_BOARD_ID_2_GPIO);
+}
+return ret;
+}
+
/**
* @brief misc_init_r - Configure Panda board specific configurations
* such as power configurations, ethernet initialization as phase2 of
Nice, this works great on my Panda ES B3.
Tested-by: Robert Nelson robertcnel...@gmai.com
U-Boot SPL 2013.10-00339-g712d969 (Nov 14 2013 - 09:21:19)
OMAP4460 ES1.1
SPL: Please implement spl_start_uboot() for your board
SPL: Direct Linux boot not active!
reading u-boot.img
reading u-boot.img
U-Boot 2013.10-00339-g712d969 (Nov 14 2013 - 09:21:19)
CPU : OMAP4460 ES1.1
Board: OMAP4 Panda
I2C: ready
DRAM: 1 GiB
MMC: OMAP SD/MMC: 0
Using default environment
BTW, should be bump the system enviroment board_name, that way it
loads a different kernel *.dtb? (omap4-panda-es-b3.dtb)
As right now it'll load the omap4-panda-es.dtb which currently uses
both cs lines on the emif driver..
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/omap4-panda-common.dtsi#n373
Regards,
--
Robert Nelson
http://www.rcn-ee.com/
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Bad Linux ARM zImage magic
On Tue, Oct 22, 2013 at 11:11 PM, claus anders cytroni...@yahoo.de wrote: Due to this patch: 0001-omap3_beagle-uEnv.txt-bootz-n-fixes.patch, u-boot for my beagleboard seems to need always a zImage. Up to now, I used uImage just fine. Correct, that's exactly one of the features that my out of tree patch does.. If you'd like to use uImage, don't apply my patch. ;) (adding u-boot cc this time..) Regards, -- Robert Nelson http://www.rcn-ee.com/ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Revert am335x_evm.h: If mmcdev and bootpart switch to mmcdev 1, so should mmcroot.
On Tue, Oct 8, 2013 at 3:39 PM, Robert P. J. Day rpj...@crashcourse.ca wrote: On Tue, 8 Oct 2013, Tom Rini wrote: ... snip ... Applied to u-boot/master. dumb question but what does it mean to say Applied to u-boot/master when it clearly has not been applied to master? i can see posts like that, but doing a git pull produces nothing. i am on the u-boot mainline, and the master branch, so what am i misunderstanding? thanks. The public git/http server is only synced every 6hours... Regards, -- Robert Nelson http://www.rcn-ee.com/ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] beaglxm/bootz: kernel boot fail due to align err: cache handling issues?
On Fri, Aug 23, 2013 at 9:21 AM, Nishanth Menon n...@ti.com wrote:
Hi,
Noticed an interesting behavior where adding a dcache flush kernel boot
fail due to unaligned-accesses seems to go away.
Full details: http://pastebin.com/kVBRWsbE
Without dcache flush being added to my uenvcmd:
Kernel image @ 0x8020 [ 0x00 - 0x3e2690 ]
data abort
MAYBE you should read doc/README.arm-unaligned-accesses
pc : [9ff6f6b4] lr : [9ff6ef6c]
sp : 9fefaaf0 ip : 9fefe8ec fp :
r10: 9ffa6544 r9 : 9ffa5e5c r8 : 9fefaf30
r7 : 0f80 r6 : 9ffa6544 r5 : 9ffa65b0 r4 : 9ffa65b4
r3 : 0049 r2 : 0010 r1 : r0 : 0f80
Flags: nZCv IRQs off FIQs off Mode SVC_32
Resetting CPU ...
With dcache flush being added to my uenvcmd: complete boot
I think something of the form was highlighted here:
http://marc.info/?l=u-bootm=137276534624656w=2
Not sure if there was any conclusion to the effect.
There may still be an underline bug, but the bootz ${loadaddr} issue
i showed in that post was fixed very late in the v2013.07, i forget
the commit, it may have been a day or two right before.
So looking at your pastebin.com log: U-Boot
2013.07-rc2-00044-g1d28a6a it might be worthwhile to re-test with
v2013.07 final, specially since your using bootz...
(I've already been shipping a bootz enabled u-boot v2013.07 for the
beagle-xm to end users)..
Regards,
--
Robert Nelson
http://www.rcn-ee.com/
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] ARM: omap3: Implement dpll5 (HSUSB clk) workaround for OMAP36xx/AM/DM37xx according to errata sprz318e.
On Tue, Aug 20, 2013 at 5:15 AM, Andreas Naumann d...@andin.de wrote: Hi Roger, What are the symptoms you see when this issue triggers? The symptoms are erroneous USB transaction, seen with a USB port analyzer. These only sometimes (not always) stall the USB communication, e.g. a USB mass storage device cant be read any longer. What is the test case to trigger the error? Is it just running any USB I/O for long enough time? Our scenario to reproduce was rebooting a warmed up board (either let it run for 5min or heat up in climate chamber). However, the beagle probably uses a 26 MHz crystal oscillator (our board uses 19.2MHz), so the PLL5 dividers may be set in a way that the problem never occurs. The xM uses a 26Mhz, but the errata still applies, as a number of customer boards do show the issue.. http://www.ti.com/lit/er/sprz319e/sprz319e.pdf page 113 I have a beagle-xm (DM3730 ES1.2) with me and would like to reproduce the error. Roger, this only seems to effect a small number of xM's, as it seems to vary on pll drift. So if your xM is fine, i do have a spare xM C, that pretty reliably shows the issue after transferring a large amount of data over the usb port... I had traded a good xM with a customer such that i could keep re-basing our out of tree dpll5 tweak.. Regards, -- Robert Nelson http://www.rcn-ee.com/ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] ARM: omap3: Implement dpll5 (HSUSB clk) workaround for OMAP36xx/AM/DM37xx according to errata sprz318e.
On Fri, Aug 16, 2013 at 9:34 AM, Peter A. Bigot p...@pabigot.com wrote: On 08/16/2013 08:38 AM, Tom Rini wrote: On Wed, Aug 14, 2013 at 09:53:16PM -0500, Peter A. Bigot wrote: On 07/09/2013 02:43 AM, Naumann Andreas wrote: In chapter 'Advisory 2.1 USB Host Clock Drift Causes USB Spec Non-compliance in Certain Configurations' of the TI Errata it is recommended to use certain div/mult values for the DPLL5 clock setup. So far u-boot used the old 34xx values, so I added the errata recommended values specificly for 36xx init only. Also, the FSEL registers exist no longer, so removed them from init. Tested this on a AM3703 board with 19.2MHz oscillator, which previously couldnt lock the dpll5 (kernel complained). As a consequence the EHCI USB port wasnt usable in U-Boot and kernel. With this patch, kernel panics disappear and USB working fine in u-boot and kernel. Signed-off-by: Andreas Naumann anaum...@ultratronik.de While this patch works with Linux that has been patched for this erratum, it will cause problems with some unpatched versions of Linux. Right. So Linux also needs to be patched for the erratum. Yes. My point was that if you update u-boot alone, then try to use it to boot an unpatched Linux that assumes CM_CLKSEL5_PLL has its power-on value, USB will not work. I think it's dangerous to assume that the mixture of an unpatched Linux with a patched u-boot will never occur, and the cause of the failure that results is pretty subtle. So whatever gets merged would be safer if it restored the default setting of CM_CLKSEL5_PLL prior to handing off control to Linux. Agree, we should not apply this, till we also have an 'approved' patch for mainline linux posted. Right now we have a set of kernel hacks, but no agreed on method as the kernel maintainer did not have a board that suffered from the errata.. Regards, -- Robert Nelson http://www.rcn-ee.com/ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] ARM: omap3: Implement dpll5 (HSUSB clk) workaround for OMAP36xx/AM/DM37xx according to errata sprz318e.
On Fri, Aug 16, 2013 at 10:07 AM, Robert Nelson robertcnel...@gmail.com wrote: On Fri, Aug 16, 2013 at 9:34 AM, Peter A. Bigot p...@pabigot.com wrote: On 08/16/2013 08:38 AM, Tom Rini wrote: On Wed, Aug 14, 2013 at 09:53:16PM -0500, Peter A. Bigot wrote: On 07/09/2013 02:43 AM, Naumann Andreas wrote: In chapter 'Advisory 2.1 USB Host Clock Drift Causes USB Spec Non-compliance in Certain Configurations' of the TI Errata it is recommended to use certain div/mult values for the DPLL5 clock setup. So far u-boot used the old 34xx values, so I added the errata recommended values specificly for 36xx init only. Also, the FSEL registers exist no longer, so removed them from init. Tested this on a AM3703 board with 19.2MHz oscillator, which previously couldnt lock the dpll5 (kernel complained). As a consequence the EHCI USB port wasnt usable in U-Boot and kernel. With this patch, kernel panics disappear and USB working fine in u-boot and kernel. Signed-off-by: Andreas Naumann anaum...@ultratronik.de While this patch works with Linux that has been patched for this erratum, it will cause problems with some unpatched versions of Linux. Right. So Linux also needs to be patched for the erratum. Yes. My point was that if you update u-boot alone, then try to use it to boot an unpatched Linux that assumes CM_CLKSEL5_PLL has its power-on value, USB will not work. I think it's dangerous to assume that the mixture of an unpatched Linux with a patched u-boot will never occur, and the cause of the failure that results is pretty subtle. So whatever gets merged would be safer if it restored the default setting of CM_CLKSEL5_PLL prior to handing off control to Linux. Agree, we should not apply this, till we also have an 'approved' patch for mainline linux posted. Right now we have a set of kernel hacks, but no agreed on method as the kernel maintainer did not have a board that suffered from the errata.. btw: here's a version that seems to work on v3.11-rc5: https://raw.github.com/RobertCNelson/armv7-multiplatform/v3.11.x/patches/omap_sprz319_erratum_v2.1/0001-hack-omap-clockk-dpll5-apply-sprz319e-2.1-erratum-kernel-3.11-rc2.patch Regards, -- Robert Nelson http://www.rcn-ee.com/ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] wandboard: add pxe support, set default boot command like highbank
On Wed, Jul 31, 2013 at 6:01 PM, Rob Herring robherri...@gmail.com wrote:
Dennis,
On Thu, Jul 25, 2013 at 4:13 PM, dgilm...@fedoraproject.org wrote:
From: Dennis Gilmore den...@ausil.us
Signed-off-by: Dennis Gilmore den...@ausil.us
---
include/configs/wandboard.h | 42 +++---
1 file changed, 39 insertions(+), 3 deletions(-)
diff --git a/include/configs/wandboard.h b/include/configs/wandboard.h
index ee6bf21..a5052c5 100644
--- a/include/configs/wandboard.h
+++ b/include/configs/wandboard.h
@@ -58,6 +58,8 @@
#define CONFIG_LOADADDR0x1200
#define CONFIG_SYS_TEXT_BASE 0x1780
+#define CONFIG_SUPPORT_RAW_INITRD
+
/* MMC Configuration */
#define CONFIG_FSL_ESDHC
#define CONFIG_FSL_USDHC
@@ -72,6 +74,14 @@
#define CONFIG_CMD_FAT
#define CONFIG_DOS_PARTITION
+/* PXE support */
+#define CONFIG_BOOTP_PXE
+#define CONFIG_BOOTP_PXE_CLIENTARCH 0x100
+#define CONFIG_BOOTP_VCI_STRING U-boot.armv7.wandboard
+#define CONFIG_CMD_PXE
+#define CONFIG_MENU
+
+
/* Ethernet Configuration */
#define CONFIG_CMD_PING
#define CONFIG_CMD_DHCP
@@ -117,7 +127,32 @@
initrd_high=0x\0 \
fdt_file= CONFIG_DEFAULT_FDT_FILE \0 \
fdt_addr=0x1100\0 \
+ pxefile_addr_r=0x1200\0 \
+ kernel_addr_r=0x1300\0 \
+ ramdisk_addr_r=0x3200\0 \
+ fdt_addr_r=0x1100\0 \
boot_fdt=try\0 \
+ bootcmd_setup=mmc rescan\0 \
+ bootcmd_pxe=setenv bootfile \\ ;dhcp; pxe get; pxe boot\0 \
+ bootcmd_disk_scr=ext2load ${boot_ifc} ${bootdevice} ${scr_addr_r}
boot.scr source ${scr_addr_r}\0 \
+ bootcmd_disk_sysboot1=setenv bootfile /boot/extlinux/extlinux.conf;
sysboot ${boot_ifc} ${bootdevice} ext2\0 \
+ bootcmd_disk_sysboot2=setenv bootfile /extlinux/extlinux.conf;
sysboot ${boot_ifc} ${bootdevice} ext2\0 \
+ bootcmd_disk_uenv=ext2load ${boot_ifc} ${bootdevice} ${uenv_addr_r}
uEnv.txt; env import -t ${uenv_addr_r} ${filesize}; run bootcmd_uenv\0 \
+ bootcmd_disk_kernel=ext2load ${boot_ifc} ${bootdevice}
${kernel_addr_r} vmlinuz ext2load ${boot_ifc} ${bootdevice}
${ramdisk_addr_r} initrd.img bootz ${kernel_addr_r}
${ramdisk_addr_r}:${filesize} ${fdt_addr}\0 \
+ bootcmd_disk=run bootcmd_disk_sysboot1; run bootcmd_disk_sysboot2;
run bootcmd_disk_uenv; run bootcmd_disk_scr; run bootcmd_disk_kernel\0 \
+ bootcmd_sata=setenv boot_ifc scsi; scsi scan run bootcmd_disk\0
\
+ bootcmd_mmc=setenv boot_ifc mmc; mmc rescan run bootcmd_disk\0 \
+ bootcmd_default=run bootcmd_mmc; run bootcmd_sata; run
bootcmd_pxe\0 \
I really would not like to see this propagated to another board. I've
completely redone the env for highbank based on what Stephen Warren
did for Tegra. It would be good to come up with a common version
rather than duplicating for each board. This is now what the env looks
like for highbank in current firmware:
kernel_boot=echo Trying kernel...; ${fs}load ${devtype} ${devnum}
${kernel_addr_r} ${prefix}vmlinuz ${fs}load ${devtype} ${devnum}
${ramdisk_addr_r} ${prefix}initrd.img bootz ${kernel_addr_r}
${ramdisk_addr_r}:${filesize} ${fdt_addr}
script_boot=echo Trying script images...; for script in
${boot_scripts}; do ${fs}load ${devtype} ${devnum} ${script_addr}
${prefix}${script} echo Executing ${prefix}${script}... source
${script_addr}; done;
env_boot=echo Trying environment file...; ${fs}load ${devtype}
${devnum} ${script_addr} ${prefix}uEnv.txt Executing
${prefix}uEnv.txt... env import -t ${script_addr} ${filesize}};
Guys, this is just silly.. Your using both uEnv.txt/boot.scr scripts
by default, which you could use to hide all this extra stuff in a
text file on the boot drive, that way mainline u-boot doesn't have to
be patched for every little change. ;)
I know it's bikeshedding, but most boards can be converted to just:
#define CONFIG_BOOTCOMMAND \
mmc dev ${mmcdev}; \
if mmc rescan; then \
echo SD/MMC found on device ${mmcdev}; \
if run loadbootenv; then \
run importbootenv; \
fi; \
if test -n $uenvcmd; then \
echo Running uenvcmd ...; \
run uenvcmd; \
fi; \
if run loadsomefailsafedefault; then \
run mmcboot; \
fi; \
fi;
#endif
where:
loadbootenv=load mmc ${mmcdev}:${mmcpart} ${loadaddr} uEnv.txt\0 \
importbootenv=echo Importing environment from mmc (uEnv.txt)...; \
env import -t ${loadaddr} ${filesize}\0 \
Regards,
--
Robert Nelson
http://www.rcn-ee.com/
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/5] omap3_beagle: support findfdt and loadfdt for devicetree support
On Thu, Jul 11, 2013 at 11:06 PM, Nishanth Menon n...@ti.com wrote:
On 18:17-20130711, Robert Nelson wrote:
On Thu, Jul 11, 2013 at 5:17 PM, Nishanth Menon n...@ti.com wrote:
On 17:05-20130711, Robert Nelson wrote:
On Thu, Jul 11, 2013 at 5:03 PM, Nishanth Menon n...@ti.com wrote:
On 17:02-20130711, Robert Nelson wrote:
On Thu, Jul 11, 2013 at 4:52 PM, Nishanth Menon n...@ti.com wrote:
For folks not using concatenated device tree with uImage, having
an handy function to find and load device tree is very handy.
So introduce findfdt and loadfdt and run findfdt by default to make
it easier on user scripts.
Signed-off-by: Nishanth Menon n...@ti.com
---
include/configs/omap3_beagle.h | 17 +
1 file changed, 17 insertions(+)
diff --git a/include/configs/omap3_beagle.h
b/include/configs/omap3_beagle.h
index bdeee17..7833208 100644
--- a/include/configs/omap3_beagle.h
+++ b/include/configs/omap3_beagle.h
@@ -210,6 +210,8 @@
#define CONFIG_EXTRA_ENV_SETTINGS \
loadaddr=0x8020\0 \
rdaddr=0x8100\0 \
+ fdt_high=0x\0 \
+ fdtaddr=0x80f8\0 \
usbtty=cdc_acm\0 \
bootfile=uImage\0 \
ramdisk=ramdisk.gz\0 \
@@ -250,6 +252,19 @@
omapdss.def_disp=${defaultdisplay} \
root=${nandroot} \
rootfstype=${nandrootfstype}\0 \
+ findfdt= \
+ if test $beaglerev = AxBx; then \
+ setenv fdtfile omap3-beagle.dtb; fi; \
+ if test $beaglerev = Cx; then \
+ setenv fdtfile omap3-beagle.dtb; fi; \
+ if test $beaglerev = xMA; then \
+ setenv fdtfile omap3-beagle-xm.dtb; fi; \
+ if test $beaglerev = xMB; then \
+ setenv fdtfile omap3-beagle-xm.dtb; fi; \
There is no need for the xMB variant, as the gpio pins used for
identification where never changed from the xMA when the newer silcon
was used for the xMB (i guess if we look at the omap's es revision, we
could figure out which are xMB's, but right now that isn't done in
u-boot)
I suppose then the following is ok to do as well?
diff --git a/board/ti/beagle/beagle.c b/board/ti/beagle/beagle.c
index c686f40..6094b0f 100644
--- a/board/ti/beagle/beagle.c
+++ b/board/ti/beagle/beagle.c
@@ -369,16 +369,6 @@ int misc_init_r(void)
TWL4030_PM_RECEIVER_VAUX2_DEV_GRP,
TWL4030_PM_RECEIVER_DEV_GRP_P1);
break;
- case REVISION_XM_B:
- printf(Beagle xM Rev B\n);
- setenv(beaglerev, xMB);
- MUX_BEAGLE_XM();
- /* Set VAUX2 to 1.8V for EHCI PHY */
-
twl4030_pmrecv_vsel_cfg(TWL4030_PM_RECEIVER_VAUX2_DEDICATED,
-
TWL4030_PM_RECEIVER_VAUX2_VSEL_18,
-
TWL4030_PM_RECEIVER_VAUX2_DEV_GRP,
- TWL4030_PM_RECEIVER_DEV_GRP_P1);
- break;
case REVISION_XM_C:
printf(Beagle xM Rev C\n);
setenv(beaglerev, xMC);
Correct, as a cleanup we can nuke that xMB section..
For some bike shed paining we could rename:
Beagle xM Rev A - Beagle xM Rev A/B
Above that too. ;)
OK - I suspect and am not sure how dvi_pup will get handled in the
resultant diff, What do folks think of the following?
A quick review of all my old xM schematics i have access to and the
ones on https://github.com/CircuitCo/
For the dvi_pup function
GPIO_170 was only used on the pre-production xM's P8/P9, i doubt any
of them still operate (mine died)..
It was then switched to GPIO_129 for the xMA, however there where MMC
issues, so it was changed for xMA1 (and thus xMA2)
notes, top of this:
https://github.com/CircuitCo/BeagleBoard-xM-RevC/blob/master/BeagleBoard-xM_revC_SCH.pdf
TPS_GPIO_2: was then used on xMA3 - and all later generations...
So also looking at:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/mach-omap2/board-omap3beagle.c#n161
Looks like the original beagle needs GPIO_170..
So I'd just set GPIO_170 for:
case REVISION_AXBX:
case REVISION_CX:
case REVISION_C4:
and ignore all the pre-production xM P8/P8's/xMA..
Side note, I think 'first' customers just got the xMA2 and newer.. As
i was one of the first, and it's still running downstairs..
ok, here is how the code looks like with the V2 of my series:
Do we just default to none for XM_AB for dvi_pup?
static void beagle_dvi_pup(void)
{
uchar val;
switch (get_board_revision()) {
case REVISION_AXBX
Re: [U-Boot] [PATCH 4/5] omap3_beagle: support findfdt and loadfdt for devicetree support
On Thu, Jul 11, 2013 at 4:52 PM, Nishanth Menon n...@ti.com wrote:
For folks not using concatenated device tree with uImage, having
an handy function to find and load device tree is very handy.
So introduce findfdt and loadfdt and run findfdt by default to make
it easier on user scripts.
Signed-off-by: Nishanth Menon n...@ti.com
---
include/configs/omap3_beagle.h | 17 +
1 file changed, 17 insertions(+)
diff --git a/include/configs/omap3_beagle.h b/include/configs/omap3_beagle.h
index bdeee17..7833208 100644
--- a/include/configs/omap3_beagle.h
+++ b/include/configs/omap3_beagle.h
@@ -210,6 +210,8 @@
#define CONFIG_EXTRA_ENV_SETTINGS \
loadaddr=0x8020\0 \
rdaddr=0x8100\0 \
+ fdt_high=0x\0 \
+ fdtaddr=0x80f8\0 \
usbtty=cdc_acm\0 \
bootfile=uImage\0 \
ramdisk=ramdisk.gz\0 \
@@ -250,6 +252,19 @@
omapdss.def_disp=${defaultdisplay} \
root=${nandroot} \
rootfstype=${nandrootfstype}\0 \
+ findfdt= \
+ if test $beaglerev = AxBx; then \
+ setenv fdtfile omap3-beagle.dtb; fi; \
+ if test $beaglerev = Cx; then \
+ setenv fdtfile omap3-beagle.dtb; fi; \
+ if test $beaglerev = xMA; then \
+ setenv fdtfile omap3-beagle-xm.dtb; fi; \
+ if test $beaglerev = xMB; then \
+ setenv fdtfile omap3-beagle-xm.dtb; fi; \
There is no need for the xMB variant, as the gpio pins used for
identification where never changed from the xMA when the newer silcon
was used for the xMB (i guess if we look at the omap's es revision, we
could figure out which are xMB's, but right now that isn't done in
u-boot)
+ if test $beaglerev = xMC; then \
+ setenv fdtfile omap3-beagle-xm.dtb; fi; \
+ if test $fdtfile = undefined; then \
+ echo WARNING: Could not determine device tree to
use; fi; \0 \
bootenv=uEnv.txt\0 \
loadbootenv=fatload mmc ${mmcdev} ${loadaddr} ${bootenv}\0 \
importbootenv=echo Importing environment from mmc ...; \
@@ -265,6 +280,7 @@
rootfstype=${ramrootfstype}\0 \
loadramdisk=load mmc ${bootpart} ${rdaddr} ${bootdir}/${ramdisk}\0 \
loadimage=load mmc ${bootpart} ${loadaddr} ${bootdir}/${bootfile}\0
\
+ loadfdt=load mmc ${bootpart} ${fdtaddr} ${bootdir}/${fdtfile}\0 \
mmcboot=echo Booting from mmc ...; \
run mmcargs; \
bootm ${loadaddr}\0 \
@@ -281,6 +297,7 @@
userbutton_nonxm=gpio input 7;\0
/* run userbutton will return 1 (false) if pressed and 0 (true) if not */
#define CONFIG_BOOTCOMMAND \
+ run findfdt; \
mmc dev ${mmcdev}; if mmc rescan; then \
if run userbutton; then \
setenv bootenv uEnv.txt; \
--
Regards,
--
Robert Nelson
http://www.rcn-ee.com/
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/5] omap3_beagle: support findfdt and loadfdt for devicetree support
On Thu, Jul 11, 2013 at 5:03 PM, Nishanth Menon n...@ti.com wrote:
On 17:02-20130711, Robert Nelson wrote:
On Thu, Jul 11, 2013 at 4:52 PM, Nishanth Menon n...@ti.com wrote:
For folks not using concatenated device tree with uImage, having
an handy function to find and load device tree is very handy.
So introduce findfdt and loadfdt and run findfdt by default to make
it easier on user scripts.
Signed-off-by: Nishanth Menon n...@ti.com
---
include/configs/omap3_beagle.h | 17 +
1 file changed, 17 insertions(+)
diff --git a/include/configs/omap3_beagle.h
b/include/configs/omap3_beagle.h
index bdeee17..7833208 100644
--- a/include/configs/omap3_beagle.h
+++ b/include/configs/omap3_beagle.h
@@ -210,6 +210,8 @@
#define CONFIG_EXTRA_ENV_SETTINGS \
loadaddr=0x8020\0 \
rdaddr=0x8100\0 \
+ fdt_high=0x\0 \
+ fdtaddr=0x80f8\0 \
usbtty=cdc_acm\0 \
bootfile=uImage\0 \
ramdisk=ramdisk.gz\0 \
@@ -250,6 +252,19 @@
omapdss.def_disp=${defaultdisplay} \
root=${nandroot} \
rootfstype=${nandrootfstype}\0 \
+ findfdt= \
+ if test $beaglerev = AxBx; then \
+ setenv fdtfile omap3-beagle.dtb; fi; \
+ if test $beaglerev = Cx; then \
+ setenv fdtfile omap3-beagle.dtb; fi; \
+ if test $beaglerev = xMA; then \
+ setenv fdtfile omap3-beagle-xm.dtb; fi; \
+ if test $beaglerev = xMB; then \
+ setenv fdtfile omap3-beagle-xm.dtb; fi; \
There is no need for the xMB variant, as the gpio pins used for
identification where never changed from the xMA when the newer silcon
was used for the xMB (i guess if we look at the omap's es revision, we
could figure out which are xMB's, but right now that isn't done in
u-boot)
I suppose then the following is ok to do as well?
diff --git a/board/ti/beagle/beagle.c b/board/ti/beagle/beagle.c
index c686f40..6094b0f 100644
--- a/board/ti/beagle/beagle.c
+++ b/board/ti/beagle/beagle.c
@@ -369,16 +369,6 @@ int misc_init_r(void)
TWL4030_PM_RECEIVER_VAUX2_DEV_GRP,
TWL4030_PM_RECEIVER_DEV_GRP_P1);
break;
- case REVISION_XM_B:
- printf(Beagle xM Rev B\n);
- setenv(beaglerev, xMB);
- MUX_BEAGLE_XM();
- /* Set VAUX2 to 1.8V for EHCI PHY */
- twl4030_pmrecv_vsel_cfg(TWL4030_PM_RECEIVER_VAUX2_DEDICATED,
- TWL4030_PM_RECEIVER_VAUX2_VSEL_18,
- TWL4030_PM_RECEIVER_VAUX2_DEV_GRP,
- TWL4030_PM_RECEIVER_DEV_GRP_P1);
- break;
case REVISION_XM_C:
printf(Beagle xM Rev C\n);
setenv(beaglerev, xMC);
Correct, as a cleanup we can nuke that xMB section..
For some bike shed paining we could rename:
Beagle xM Rev A - Beagle xM Rev A/B
Above that too. ;)
Regards,
--
Robert Nelson
http://www.rcn-ee.com/
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/5] omap3_beagle: support findfdt and loadfdt for devicetree support
On Thu, Jul 11, 2013 at 5:17 PM, Nishanth Menon n...@ti.com wrote:
On 17:05-20130711, Robert Nelson wrote:
On Thu, Jul 11, 2013 at 5:03 PM, Nishanth Menon n...@ti.com wrote:
On 17:02-20130711, Robert Nelson wrote:
On Thu, Jul 11, 2013 at 4:52 PM, Nishanth Menon n...@ti.com wrote:
For folks not using concatenated device tree with uImage, having
an handy function to find and load device tree is very handy.
So introduce findfdt and loadfdt and run findfdt by default to make
it easier on user scripts.
Signed-off-by: Nishanth Menon n...@ti.com
---
include/configs/omap3_beagle.h | 17 +
1 file changed, 17 insertions(+)
diff --git a/include/configs/omap3_beagle.h
b/include/configs/omap3_beagle.h
index bdeee17..7833208 100644
--- a/include/configs/omap3_beagle.h
+++ b/include/configs/omap3_beagle.h
@@ -210,6 +210,8 @@
#define CONFIG_EXTRA_ENV_SETTINGS \
loadaddr=0x8020\0 \
rdaddr=0x8100\0 \
+ fdt_high=0x\0 \
+ fdtaddr=0x80f8\0 \
usbtty=cdc_acm\0 \
bootfile=uImage\0 \
ramdisk=ramdisk.gz\0 \
@@ -250,6 +252,19 @@
omapdss.def_disp=${defaultdisplay} \
root=${nandroot} \
rootfstype=${nandrootfstype}\0 \
+ findfdt= \
+ if test $beaglerev = AxBx; then \
+ setenv fdtfile omap3-beagle.dtb; fi; \
+ if test $beaglerev = Cx; then \
+ setenv fdtfile omap3-beagle.dtb; fi; \
+ if test $beaglerev = xMA; then \
+ setenv fdtfile omap3-beagle-xm.dtb; fi; \
+ if test $beaglerev = xMB; then \
+ setenv fdtfile omap3-beagle-xm.dtb; fi; \
There is no need for the xMB variant, as the gpio pins used for
identification where never changed from the xMA when the newer silcon
was used for the xMB (i guess if we look at the omap's es revision, we
could figure out which are xMB's, but right now that isn't done in
u-boot)
I suppose then the following is ok to do as well?
diff --git a/board/ti/beagle/beagle.c b/board/ti/beagle/beagle.c
index c686f40..6094b0f 100644
--- a/board/ti/beagle/beagle.c
+++ b/board/ti/beagle/beagle.c
@@ -369,16 +369,6 @@ int misc_init_r(void)
TWL4030_PM_RECEIVER_VAUX2_DEV_GRP,
TWL4030_PM_RECEIVER_DEV_GRP_P1);
break;
- case REVISION_XM_B:
- printf(Beagle xM Rev B\n);
- setenv(beaglerev, xMB);
- MUX_BEAGLE_XM();
- /* Set VAUX2 to 1.8V for EHCI PHY */
-
twl4030_pmrecv_vsel_cfg(TWL4030_PM_RECEIVER_VAUX2_DEDICATED,
- TWL4030_PM_RECEIVER_VAUX2_VSEL_18,
- TWL4030_PM_RECEIVER_VAUX2_DEV_GRP,
- TWL4030_PM_RECEIVER_DEV_GRP_P1);
- break;
case REVISION_XM_C:
printf(Beagle xM Rev C\n);
setenv(beaglerev, xMC);
Correct, as a cleanup we can nuke that xMB section..
For some bike shed paining we could rename:
Beagle xM Rev A - Beagle xM Rev A/B
Above that too. ;)
OK - I suspect and am not sure how dvi_pup will get handled in the
resultant diff, What do folks think of the following?
A quick review of all my old xM schematics i have access to and the
ones on https://github.com/CircuitCo/
For the dvi_pup function
GPIO_170 was only used on the pre-production xM's P8/P9, i doubt any
of them still operate (mine died)..
It was then switched to GPIO_129 for the xMA, however there where MMC
issues, so it was changed for xMA1 (and thus xMA2)
notes, top of this:
https://github.com/CircuitCo/BeagleBoard-xM-RevC/blob/master/BeagleBoard-xM_revC_SCH.pdf
TPS_GPIO_2: was then used on xMA3 - and all later generations...
So also looking at:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/mach-omap2/board-omap3beagle.c#n161
Looks like the original beagle needs GPIO_170..
So I'd just set GPIO_170 for:
case REVISION_AXBX:
case REVISION_CX:
case REVISION_C4:
and ignore all the pre-production xM P8/P8's/xMA..
Side note, I think 'first' customers just got the xMA2 and newer.. As
i was one of the first, and it's still running downstairs..
Regards,
--
Robert Nelson
http://www.rcn-ee.com/
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 5/5] bootm: Add the missing PREP stage to bootz and correct image handling
On Tue, Jul 9, 2013 at 2:00 PM, Simon Glass s...@chromium.org wrote:
Hi Tom,
On Tue, Jul 9, 2013 at 10:01 AM, Tom Rini tr...@ti.com wrote:
On Mon, Jul 08, 2013 at 10:22:13AM -0400, Tom Rini wrote:
On Mon, Jul 08, 2013 at 09:17:10AM -0500, Robert Nelson wrote:
On Mon, Jul 8, 2013 at 9:13 AM, Tom Rini tr...@ti.com wrote:
On Thu, Jul 04, 2013 at 01:26:11PM -0700, Simon Glass wrote:
In the recent bootm refactor, the PREP stage was missing in the
bootz
command. This causes unpredictable behaviour.
The use of a local variable means that the reset of cmd_bootm.c
does not
in fact use the same image structure, so remove this.
Also manually set the OS type to Linux, since this is the only
possibility
at present, and we need to select the right boot function.
Signed-off-by: Simon Glass s...@chromium.org
With the whole series applied, I still see a hang at:
Kernel image @ 0x8020 [ 0x00 - 0x3d44a0 ]
Starting kernel ...
Perhaps something to do with how my DDR is not at 0x0 - 256MiB but
0x8000 - 256MiB ?
Tom, which board is that?
These 5 patches just on top of v2013.07-rc2, the panda (non es) (board
file) works, but Wand (device tree) is still locking up for me...
Panda (Board file boot)
load mmc ${mmcdev}:${mmcpart} ${loadaddr} zImage
run mmcargs
bootz ${loadaddr}
Ah-ha! It's an appended dtb vs not problem now. I can boot my
beagelbone with with an appended dtb and bootz, but can't with separate.
OK, the BOOTM_STATE_FINDOTHER state code isn't working since we don't
have the rest of the header bits that the code checks for set. I've
taken a few stabs at reworking things, but it's not working yet. Simon,
do you have any ideas here? I'm starting to wonder if we don't need to
revert things afterall and sort this out post release.
Yes time is running short. I did post two reverts - I wonder if they are
effective for this problem?
Is the appended dtb with bootz the only problem remaining as far as we know?
If so then perhaps we are close.
Close.. It's the 'non appended dtb case'...
bootz ${loadaddr} - ${fdt_addr}
It's almost as if bootz doesn't have the location of the dtb binary in memory...
I will see if I can get a Beaglebone today or failing that I should be able
to try bootz with appeneded dtb on another ARM board.
Regards,
--
Robert Nelson
http://www.rcn-ee.com/
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 5/5] bootm: Add the missing PREP stage to bootz and correct image handling
On Tue, Jul 9, 2013 at 4:19 PM, Tom Rini tr...@ti.com wrote:
On Tue, Jul 09, 2013 at 01:04:58PM -0700, Simon Glass wrote:
Hi Tom,
On Tue, Jul 9, 2013 at 12:05 PM, Tom Rini tr...@ti.com wrote:
On Tue, Jul 09, 2013 at 12:00:00PM -0700, Simon Glass wrote:
Hi Tom,
On Tue, Jul 9, 2013 at 10:01 AM, Tom Rini tr...@ti.com wrote:
On Mon, Jul 08, 2013 at 10:22:13AM -0400, Tom Rini wrote:
On Mon, Jul 08, 2013 at 09:17:10AM -0500, Robert Nelson wrote:
On Mon, Jul 8, 2013 at 9:13 AM, Tom Rini tr...@ti.com wrote:
On Thu, Jul 04, 2013 at 01:26:11PM -0700, Simon Glass wrote:
In the recent bootm refactor, the PREP stage was missing in the
bootz
command. This causes unpredictable behaviour.
The use of a local variable means that the reset of cmd_bootm.c
does not
in fact use the same image structure, so remove this.
Also manually set the OS type to Linux, since this is the only
possibility
at present, and we need to select the right boot function.
Signed-off-by: Simon Glass s...@chromium.org
With the whole series applied, I still see a hang at:
Kernel image @ 0x8020 [ 0x00 - 0x3d44a0 ]
Starting kernel ...
Perhaps something to do with how my DDR is not at 0x0 - 256MiB
but
0x8000 - 256MiB ?
Tom, which board is that?
These 5 patches just on top of v2013.07-rc2, the panda (non es)
(board
file) works, but Wand (device tree) is still locking up for me...
Panda (Board file boot)
load mmc ${mmcdev}:${mmcpart} ${loadaddr} zImage
run mmcargs
bootz ${loadaddr}
Ah-ha! It's an appended dtb vs not problem now. I can boot my
beagelbone with with an appended dtb and bootz, but can't with
separate.
OK, the BOOTM_STATE_FINDOTHER state code isn't working since we don't
have the rest of the header bits that the code checks for set. I've
taken a few stabs at reworking things, but it's not working yet.
Simon,
do you have any ideas here? I'm starting to wonder if we don't need to
revert things afterall and sort this out post release.
Yes time is running short. I did post two reverts - I wonder if they are
effective for this problem?
Is the appended dtb with bootz the only problem remaining as far as we
know? If so then perhaps we are close.
I will see if I can get a Beaglebone today or failing that I should be
able
to try bootz with appeneded dtb on another ARM board.
I've got a fix locally now, and I'm working on cleaning it up further.
The problem is that BOOTM_STATE_FINDOTHER would never work since we
aren't the right image types, so passed ramdisk and/or dtb didn't
work. Another problem was that bootz was never consuming 'bootz', but
this was OK before. I'll post a patch shortly.
OK great, thanks for looking at this. I wonder if we can collect a set of
different use cases for bootz as a basis for test cases?
Well, what happens on sandbox when you try and boot a kernel? :) bootz
is any of:
kernel, kernel+ramdisk, kernel+ramdisk+fdt, kernel+fdt.
My biggest worry right now is, what might show up broken next? Anyone
out there easily able to boot a netbsd kernel or something?
Yes, I am not really comfortable with this. I will see if I can write some
sandbox tests for the other image types today and post my results. I guess
this bootm code has built up over a long time and it is hard to know all
the ways it is used.
Important, but I really want to see real-world booting in a case or two.
Unfortunately I don't have any ARM boards that work out of the box with
NetBSD.
There 'seems' to be a pre-built freebsd arm port...
https://wiki.freebsd.org/FreeBSD/arm/BeagleBone
Regards,
--
Robert Nelson
http://www.rcn-ee.com/
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 5/5] bootm: Add the missing PREP stage to bootz and correct image handling
Important, but I really want to see real-world booting in a case or two. Unfortunately I don't have any ARM boards that work out of the box with NetBSD. There 'seems' to be a pre-built freebsd arm port... https://wiki.freebsd.org/FreeBSD/arm/BeagleBone NM.. they are using the 'bootelf' command.. https://github.com/kientzle/crochet-freebsd/blob/master/board/BeagleBone/files/uboot_patch05.patch#L108 Regards, -- Robert Nelson http://www.rcn-ee.com/ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 5/5] bootm: Add the missing PREP stage to bootz and correct image handling
On Mon, Jul 8, 2013 at 9:13 AM, Tom Rini tr...@ti.com wrote:
On Thu, Jul 04, 2013 at 01:26:11PM -0700, Simon Glass wrote:
In the recent bootm refactor, the PREP stage was missing in the bootz
command. This causes unpredictable behaviour.
The use of a local variable means that the reset of cmd_bootm.c does not
in fact use the same image structure, so remove this.
Also manually set the OS type to Linux, since this is the only possibility
at present, and we need to select the right boot function.
Signed-off-by: Simon Glass s...@chromium.org
With the whole series applied, I still see a hang at:
Kernel image @ 0x8020 [ 0x00 - 0x3d44a0 ]
Starting kernel ...
Perhaps something to do with how my DDR is not at 0x0 - 256MiB but
0x8000 - 256MiB ?
Tom, which board is that?
These 5 patches just on top of v2013.07-rc2, the panda (non es) (board
file) works, but Wand (device tree) is still locking up for me...
Panda (Board file boot)
load mmc ${mmcdev}:${mmcpart} ${loadaddr} zImage
run mmcargs
bootz ${loadaddr}
Panda # load mmc ${mmcdev}:${mmcpart} ${loadaddr} zImage
reading zImage
3413152 bytes read in 161 ms (20.2 MiB/s)
Panda # run mmcargs
Panda # bootz ${loadaddr}
Kernel image @ 0x8200 [ 0x00 - 0x3414a0 ]
Starting kernel ...
Uncompressing Linux... done, booting the kernel.
[0.00] Booting Linux on physical CPU 0
[0.00] Initializing cgroup subsys cpuset
[0.00] Initializing cgroup subsys cpu
Wandboard (device tree boot)
load mmc ${mmcdev}:${mmcpart} ${loadaddr} zImage
load mmc ${mmcdev}:${mmcpart} ${fdt_addr} /dtbs/${fdt_file}
run mmcargs
bootz ${loadaddr} - ${fdt_addr}
Hit any key to stop autoboot: 0
= load mmc ${mmcdev}:${mmcpart} ${loadaddr} zImage
3464448 bytes read in 249 ms (13.3 MiB/s)
= load mmc ${mmcdev}:${mmcpart} ${fdt_addr} /dtbs/${fdt_file}
23571 bytes read in 253 ms (90.8 KiB/s)
= run mmcargs
= bootz ${loadaddr} - ${fdt_addr}
Kernel image @ 0x1200 [ 0x00 - 0x34dd00 ]
Starting kernel ...
lockup
Regards,
--
Robert Nelson
http://www.rcn-ee.com/
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [ANN] v2013.07-rc2
On Wed, Jul 3, 2013 at 8:52 AM, Simon Glass s...@chromium.org wrote:
Hi Robert.
On Tue, Jul 2, 2013 at 11:15 PM, Simon Glass s...@chromium.org wrote:
Hi Robert,
On Jul 2, 2013 8:41 PM, Robert Nelson robertcnel...@gmail.com wrote:
On Tue, Jul 2, 2013 at 2:39 AM, Simon Glass s...@chromium.org wrote:
Hi Robert,
On Tue, Jul 2, 2013 at 5:44 AM, Robert Nelson
robertcnel...@gmail.com
wrote:
On Fri, Jun 28, 2013 at 5:12 PM, Tom Rini tr...@ti.com wrote:
Hey all,
I've tagged and pushed v2013.07-rc2. A bit more over the place
than I
should have gone, but picked up a lot of things that have been
outstanding for a while. The big thing is a refactor of the boot
loop.
Everything should be working right now, but please test. Related
to
this is the ability to have crytpographically signed images. It's
like
secure boot in UEFI land, but hopefully without the kerfuffle.
If you've got changes outstanding still, please start gently poking
custodians with patchwork links. I've got a good bit of stuff I
need to
deal with myself still, but please prod me all the same.
So, the bootm refactor ( 35fc84fa1ff51e15ecd3e464dac87eb105ffed30 )
also broke bootz/zImage...
Got it to atleast get past the invalid OS message via:
diff --git a/common/cmd_bootm.c b/common/cmd_bootm.c
index 02a5013..a0b55ef 100644
--- a/common/cmd_bootm.c
+++ b/common/cmd_bootm.c
@@ -1744,6 +1744,12 @@ static int bootz_start(cmd_tbl_t *cmdtp, int
flag, int argc,
int ret;
void *zi_start, *zi_end;
+ memset(images, 0, sizeof(bootm_headers_t));
+
+ boot_start_lmb(images);
+
+ images-os.os = IH_OS_LINUX;
+
ret = do_bootm_states(cmdtp, flag, argc, argv,
BOOTM_STATE_START,
images, 1);
However it's still locking up at Starting Kernel ...
What board is this please? I have only tested on x86, but perhaps have
missed something here.
So far it looks like any arm board... I was working on specifically
the imx6 quad core wandboard bringup. But i've also verified it on
the Panda/Beagle too... Alll 3 of these boards worked fine with
v2013.07-rc1...
Wandboard:
Boot Sequence: (device tree boot)
load mmc ${mmcdev}:${mmcpart} ${loadaddr} zImage
load mmc ${mmcdev}:${mmcpart} ${fdt_addr} /dtbs/${fdt_file}
bootz ${loadaddr} - ${fdt_addr}
U-Boot 2013.07-rc2-1-g23c15c2-dirty (Jul 02 2013 - 06:33:59)
CPU: Freescale i.MX6Q rev1.2 at 792 MHz
Reset cause: POR
Board: Wandboard
DRAM: 2 GiB
MMC: FSL_SDHC: 0, FSL_SDHC: 1
*** Warning - bad CRC, using default environment
In:serial
Out: serial
Err: serial
Net: FEC [PRIME]
Warning: FEC using MAC address from net device
Hit any key to stop autoboot: 0
= load mmc ${mmcdev}:${mmcpart} ${loadaddr} zImage
4112496 bytes read in 307 ms (12.8 MiB/s)
= load mmc ${mmcdev}:${mmcpart} ${fdt_addr} /dtbs/${fdt_file}
22150 bytes read in 126 ms (170.9 KiB/s)
= bootz ${loadaddr} - ${fdt_addr}
Beagle xM:
Boot Sequence: (old board file boot)
fatload mmc ${mmcdev}:${mmcpart} ${loadaddr} zImage
bootz ${loadaddr}
OMAP3 beagleboard.org # fatload mmc ${mmcdev}:${mmcpart} ${loadaddr}
zImage
reading zImage
3421392 bytes read in 246 ms (13.3 MiB/s)
OMAP3 beagleboard.org # bootz ${loadaddr}
data abort
MAYBE you should read doc/README.arm-unaligned-accesses
pc : [9ff8bf20] lr : [9ff5d2a8]
sp : 9fef8bd8 ip : 9ff8 fp : 9fef9760
r10: 9ffa6314 r9 : 9ffa7710 r8 : 9fef8f30
r7 : 805434d0 r6 : 00020e61 r5 : ffafefff r4 : 9ff9c6e6
r3 : 00020e61 r2 : 003434d0 r1 : 8020 r0 : 9fef8cf0
Flags: nzcv IRQs off FIQs off Mode SVC_32
Resetting CPU ...
resetting ...
U-Boot SPL 2013.07-rc2-1-g7c2cb8a-dirty (Jul 02 2013 - 06:14:53)
Thanks for the details. I will take a look later today US time.
Unfortunately due to my current location I don't have access to a good ARM
bootz target. I believe I have found a problem, and will send out some
patches for you to try/debug, although with tidying up a few things.
However until I can test them (several days) they are for interest only.
Sure, no problem... Other then a long drive tonight, I'll have net
access over the 4th.. It's just 'too' easy to pack a beaglebone black
where ever i go. ;)
Regards,
--
Robert Nelson
http://www.rcn-ee.com/
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
