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
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
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
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
.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
/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/am335
://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
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 repl
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:
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,
>>>
>>>
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"
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 ?
>&g
oard.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
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>
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 h
pping 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
* 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_INPU
n 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 op
on 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
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
gt; 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,
--
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
ng 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
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.
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
. 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
overh
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 <robertcn
- 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_BLO
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:
minutes or so,
it should shutdown with a new image in the eMMC..
Regards,
--
Robert Nelson
https://rcn-ee.com/
r 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/
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/
OM 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
tion 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@BeaglePl
101 - 134 of 134 matches
Mail list logo