gmane.os.freebsd.devel.arm archive

7702 archived articles, newest first (page 74 of 78). Latest articles →

Re: 64-bit RPi4B u-boot hangup with modern rpi firmware: some information (but investigative-toolbox limited)
Wed, 14 Oct 2020 05:43:01 +0200
Klaus Cucinauomo via freebsd-arm <[email protected]> • #22624
64-bit RPi4B u-boot hangup with modern rpi firmware: some information (but investigative-toolbox limited)
Tue, 13 Oct 2020 18:13:08 -0700
Mark Millard via freebsd-arm <[email protected]> • #22623
Re: RPi4B: an example of what RAM u-boot reserves during operation [patches updated]
Tue, 13 Oct 2020 12:21:50 -0700
Mark Millard via freebsd-arm <[email protected]> • #22622
Re: RPi4B: modern firmware vs. Device tree loaded to 0x4000 (size 0xbe0c) [fails] vs. to 0x1f0000 (size 0xbd90) [works]?
Tue, 13 Oct 2020 04:27:55 +0200
Klaus Cucinauomo via freebsd-arm <[email protected]> • #22621
Re: RPi4B: an example of what RAM u-boot reserves during operation [patch included]
Mon, 12 Oct 2020 17:32:21 -0700
Mark Millard via freebsd-arm <[email protected]> • #22620
Re: RPi4B: modern firmware vs. Device tree loaded to 0x4000 (size 0xbe0c) [fails] vs. to 0x1f0000 (size 0xbd90) [works]?
Mon, 12 Oct 2020 21:04:58 +0000
Robert Crowston via freebsd-arm <[email protected]> • #22619
RPi4B: an example of what RAM u-boot reserves during operation (not necessarily matching what it reports to the next stage) vs. armstub8-gic.bin
Mon, 12 Oct 2020 11:19:50 -0700
Mark Millard via freebsd-arm <[email protected]> • #22618
Re: Adding a "-1" into https://reviews.freebsd.org/D25219 's code looks to make uefi/ACPI handle USB3 SSD reliably
Mon, 12 Oct 2020 10:45:28 -0700
Mark Millard via freebsd-arm <[email protected]> • #22617
Re: RPi4B: modern firmware vs. Device tree loaded to 0x4000 (size 0xbe0c) [fails] vs. to 0x1f0000 (size 0xbd90) [works]?
Mon, 12 Oct 2020 10:37:44 -0700
Mark Millard via freebsd-arm <[email protected]> • #22616
Re: RPi4B: modern firmware vs. Device tree loaded to 0x4000 (size 0xbe0c) [fails] vs. to 0x1f0000 (size 0xbd90) [works]?
Mon, 12 Oct 2020 13:35:53 +0200
Klaus Cucinauomo via freebsd-arm <[email protected]> • #22615
Re: FreeBSD 13 not support boot form USB-MSD on rpi4.
Mon, 12 Oct 2020 13:01:06 +0200
Klaus Cucinauomo via freebsd-arm <[email protected]> • #22614
Re: RPi4B: u-boot printenv shows: fdt_addr=4000 (input to u-boot) vs. fdt_addr_r=0x02600000 (output from u-boot): 4000 is used by FreeBSD?
Mon, 12 Oct 2020 01:30:24 -0700
Mark Millard via freebsd-arm <[email protected]> • #22613
Re: RPi4B: u-boot printenv shows: fdt_addr=4000 (input to u-boot) vs. fdt_addr_r=0x02600000 (output from u-boot): 4000 is used by FreeBSD?
Mon, 12 Oct 2020 01:05:16 -0700
Mark Millard via freebsd-arm <[email protected]> • #22612
RPi4B: u-boot printenv shows: fdt_addr=4000 (input to u-boot) vs. fdt_addr_r=0x02600000 (output from u-boot): 4000 is used by FreeBSD?
Mon, 12 Oct 2020 00:41:04 -0700
Mark Millard via freebsd-arm <[email protected]> • #22611
FreeBSD 13 not support boot form USB-MSD on rpi4.
Mon, 12 Oct 2020 15:20:36 +0800
ykla <[email protected]> • #22610
Re: RPi4B: modern firmware vs. Device tree loaded to 0x4000 (size 0xbe0c) [fails] vs. to 0x1f0000 (size 0xbd90) [works]?
Sun, 11 Oct 2020 23:41:15 -0700
Mark Millard via freebsd-arm <[email protected]> • #22609
RPi4B: an example of what dtdebug=1 in config.txt shows
Sun, 11 Oct 2020 22:53:53 -0700
Mark Millard via freebsd-arm <[email protected]> • #22608
Re: RPi4B: modern firmware vs. Device tree loaded to 0x4000 (size 0xbe0c) [fails] vs. to 0x1f0000 (size 0xbd90) [works]?
Sun, 11 Oct 2020 22:13:51 -0700
Mark Millard via freebsd-arm <[email protected]> • #22607
Re: Patches from ~gonzo/arm/rpi3-smp/u-boot-patches/ missing from u-boot upstream and from relevant sysutils/u-boot-* ports?
Sun, 11 Oct 2020 21:55:34 -0700
Mark Millard via freebsd-arm <[email protected]> • #22606
Patches from ~gonzo/arm/rpi3-smp/u-boot-patches/ missing from u-boot upstream and from relevant sysutils/u-boot-* ports?
Sun, 11 Oct 2020 19:23:36 -0700
Mark Millard via freebsd-arm <[email protected]> • #22605
Re: RPi4B: modern firmware vs. Device tree loaded to 0x4000 (size 0xbe0c) [fails] vs. to 0x1f0000 (size 0xbd90) [works]?
Sun, 11 Oct 2020 17:23:10 -0700
Mark Millard via freebsd-arm <[email protected]> • #22604
Re: RPi4B: modern firmware vs. Device tree loaded to 0x4000 (size 0xbe0c) [fails] vs. to 0x1f0000 (size 0xbd90) [works]?
Sun, 11 Oct 2020 17:13:52 -0700
Mark Millard via freebsd-arm <[email protected]> • #22603
Re: RPi4B: modern firmware vs. Device tree loaded to 0x4000 (size 0xbe0c) [fails] vs. to 0x1f0000 (size 0xbd90) [works]?
Sun, 11 Oct 2020 23:13:50 +0000
Robert Crowston via freebsd-arm <[email protected]> • #22602
Re: RPi4B: modern firmware vs. Device tree loaded to 0x4000 (size 0xbe0c) [fails] vs. to 0x1f0000 (size 0xbd90) [works]?
Sun, 11 Oct 2020 13:50:15 -0700
Mark Millard via freebsd-arm <[email protected]> • #22601
Re: RPi4B: modern firmware vs. Device tree loaded to 0x4000 (size 0xbe0c) [fails] vs. to 0x1f0000 (size 0xbd90) [works]?
Sun, 11 Oct 2020 22:29:05 +0200
Klaus Cucinauomo via freebsd-arm <[email protected]> • #22600
Re: RPi4B: modern firmware vs. Device tree loaded to 0x4000 (size 0xbe0c) [fails] vs. to 0x1f0000 (size 0xbd90) [works]?
Sun, 11 Oct 2020 13:21:10 -0700
Mark Millard via freebsd-arm <[email protected]> • #22599
Re: RPi4B: modern firmware vs. Device tree loaded to 0x4000 (size 0xbe0c) [fails] vs. to 0x1f0000 (size 0xbd90) [works]?
Sun, 11 Oct 2020 22:12:05 +0200
Klaus Cucinauomo via freebsd-arm <[email protected]> • #22598
Re: RPi4B: modern firmware vs. Device tree loaded to 0x4000 (size 0xbe0c) [fails] vs. to 0x1f0000 (size 0xbd90) [works]?
Sun, 11 Oct 2020 22:02:41 +0200
Klaus Cucinauomo via freebsd-arm <[email protected]> • #22597
Re: RPi4B: modern firmware vs. Device tree loaded to 0x4000 (size 0xbe0c) [fails] vs. to 0x1f0000 (size 0xbd90) [works]?
Sun, 11 Oct 2020 19:53:41 +0000
Robert Crowston via freebsd-arm <[email protected]> • #22596
Re: RPi4B: modern firmware vs. Device tree loaded to 0x4000 (size 0xbe0c) [fails] vs. to 0x1f0000 (size 0xbd90) [works]?
Sun, 11 Oct 2020 21:46:02 +0200
Klaus Cucinauomo via freebsd-arm <[email protected]> • #22595
Re: RPi4B: modern firmware vs. Device tree loaded to 0x4000 (size 0xbe0c) [fails] vs. to 0x1f0000 (size 0xbd90) [works]?
Sun, 11 Oct 2020 12:37:43 -0700
Mark Millard via freebsd-arm <[email protected]> • #22594
Re: RPi4B: modern firmware vs. Device tree loaded to 0x4000 (size 0xbe0c) [fails] vs. to 0x1f0000 (size 0xbd90) [works]?
Sun, 11 Oct 2020 21:06:25 +0200
Klaus Cucinauomo via freebsd-arm <[email protected]> • #22593
Re: RPi4B: modern firmware vs. Device tree loaded to 0x4000 (size 0xbe0c) [fails] vs. to 0x1f0000 (size 0xbd90) [works]?
Sun, 11 Oct 2020 17:01:54 +0000
Robert Crowston via freebsd-arm <[email protected]> • #22592
Re: RPi4B: modern firmware vs. Device tree loaded to 0x4000 (size 0xbe0c) [fails] vs. to 0x1f0000 (size 0xbd90) [works]?
Sun, 11 Oct 2020 11:05:40 -0500
Kyle Evans <[email protected]> • #22591
Re: RPi4B: modern firmware vs. Device tree loaded to 0x4000 (size 0xbe0c) [fails] vs. to 0x1f0000 (size 0xbd90) [works]?
Sun, 11 Oct 2020 15:50:21 +0000
Robert Crowston via freebsd-arm <[email protected]> • #22590
Re: RPi4B: modern firmware vs. Device tree loaded to 0x4000 (size 0xbe0c) [fails] vs. to 0x1f0000 (size 0xbd90) [works]?
Sun, 11 Oct 2020 16:23:15 +0200
Klaus Cucinauomo via freebsd-arm <[email protected]> • #22589
Re: RPi4B: modern firmware vs. Device tree loaded to 0x4000 (size 0xbe0c) [fails] vs. to 0x1f0000 (size 0xbd90) [works]?
Sun, 11 Oct 2020 16:10:02 +0200
Klaus Cucinauomo via freebsd-arm <[email protected]> • #22588
Re: RPi4B: modern firmware vs. Device tree loaded to 0x4000 (size 0xbe0c) [fails] vs. to 0x1f0000 (size 0xbd90) [works]?
Sun, 11 Oct 2020 13:44:57 +0000
Robert Crowston via freebsd-arm <[email protected]> • #22587
Re: RPi4B: modern firmware vs. Device tree loaded to 0x4000 (size 0xbe0c) [fails] vs. to 0x1f0000 (size 0xbd90) [works]?
Sun, 11 Oct 2020 13:38:39 +0000
Robert Crowston via freebsd-arm <[email protected]> • #22586
Re: RPi4B: modern firmware vs. Device tree loaded to 0x4000 (size 0xbe0c) [fails] vs. to 0x1f0000 (size 0xbd90) [works]?
Sun, 11 Oct 2020 14:22:41 +0100
Mark Murray <[email protected]> • #22585
Re: RPi4B: modern firmware vs. Device tree loaded to 0x4000 (size 0xbe0c) [fails] vs. to 0x1f0000 (size 0xbd90) [works]?
Sun, 11 Oct 2020 15:17:41 +0200
Klaus Cucinauomo via freebsd-arm <[email protected]> • #22584
Re: RPi4B: modern firmware vs. Device tree loaded to 0x4000 (size 0xbe0c) [fails] vs. to 0x1f0000 (size 0xbd90) [works]?
Sun, 11 Oct 2020 13:11:24 +0000
Robert Crowston via freebsd-arm <[email protected]> • #22583
Re: RPi4B: modern firmware vs. Device tree loaded to 0x4000 (size 0xbe0c) [fails] vs. to 0x1f0000 (size 0xbd90) [works]?
Sun, 11 Oct 2020 15:01:26 +0200
Klaus Cucinauomo via freebsd-arm <[email protected]> • #22582
Re: RPi4B: modern firmware vs. Device tree loaded to 0x4000 (size 0xbe0c) [fails] vs. to 0x1f0000 (size 0xbd90) [works]?
Sun, 11 Oct 2020 09:39:07 +0000
Robert Crowston via freebsd-arm <[email protected]> • #22581
Re: RPi4B: modern firmware vs. Device tree loaded to 0x4000 (size 0xbe0c) [fails] vs. to 0x1f0000 (size 0xbd90) [works]?
Sun, 11 Oct 2020 09:13:57 +0000
Robert Crowston via freebsd-arm <[email protected]> • #22580
Re: RPi4B: modern firmware vs. Device tree loaded to 0x4000 (size 0xbe0c) [fails] vs. to 0x1f0000 (size 0xbd90) [works]?
Sat, 10 Oct 2020 23:31:38 -0700
Mark Millard via freebsd-arm <[email protected]> • #22579
Re: RPi4B: emmc2bus dma-range handling does not track the boot-time-FDT (u-boot based booting)
Sun, 11 Oct 2020 05:38:42 +0200
Klaus Cucinauomo via freebsd-arm <[email protected]> • #22578
Re: RPi4B: modern firmware vs. Device tree loaded to 0x4000 (size 0xbe0c) [fails] vs. to 0x1f0000 (size 0xbd90) [works]?
Sun, 11 Oct 2020 05:03:46 +0200
Klaus Cucinauomo via freebsd-arm <[email protected]> • #22577
Re: RPi4B: modern firmware vs. Device tree loaded to 0x4000 (size 0xbe0c) [fails] vs. to 0x1f0000 (size 0xbd90) [works]?
Sun, 11 Oct 2020 02:21:16 +0200
Klaus Cucinauomo via freebsd-arm <[email protected]> • #22576
Re: RPi4B: emmc2bus dma-range handling does not track the boot-time-FDT (u-boot based booting)
Sat, 10 Oct 2020 21:09:03 +0200
Klaus Cucinauomo via freebsd-arm <[email protected]> • #22575
Re: RPi4B: emmc2bus dma-range handling does not track the boot-time-FDT (u-boot based booting)
Sat, 10 Oct 2020 00:14:32 -0700
Mark Millard via freebsd-arm <[email protected]> • #22574
RPi4B: modern firmware vs. Device tree loaded to 0x4000 (size 0xbe0c) [fails] vs. to 0x1f0000 (size 0xbd90) [works]?
Fri, 9 Oct 2020 23:53:57 -0700
Mark Millard via freebsd-arm <[email protected]> • #22573
Re: RPi4B: emmc2bus dma-range handling does not track the boot-time-FDT (u-boot based booting)
Fri, 9 Oct 2020 18:54:06 -0700
Mark Millard via freebsd-arm <[email protected]> • #22572
Re: RPi4B: emmc2bus dma-range handling does not track the boot-time-FDT (u-boot based booting)
Fri, 9 Oct 2020 18:46:20 -0700
Mark Millard via freebsd-arm <[email protected]> • #22571
Re: RPi4B: emmc2bus dma-range handling does not track the boot-time-FDT (u-boot based booting)
Sat, 10 Oct 2020 03:08:19 +0200
Klaus Cucinauomo via freebsd-arm <[email protected]> • #22570
Re: RPi4B: emmc2bus dma-range handling does not track the boot-time-FDT (u-boot based booting)
Fri, 9 Oct 2020 17:39:13 -0700
Mark Millard via freebsd-arm <[email protected]> • #22569
Re: RPi4B: emmc2bus dma-range handling does not track the boot-time-FDT (u-boot based booting)
Fri, 9 Oct 2020 17:21:52 -0700
Mark Millard via freebsd-arm <[email protected]> • #22568
Re: RPi4B: emmc2bus dma-range handling does not track the boot-time-FDT (u-boot based booting)
Sat, 10 Oct 2020 02:17:15 +0200
Klaus Cucinauomo via freebsd-arm <[email protected]> • #22567
Re: RPi4B: emmc2bus dma-range handling does not track the boot-time-FDT (u-boot based booting)
Sat, 10 Oct 2020 01:20:23 +0200
Klaus Cucinauomo via freebsd-arm <[email protected]> • #22566
Re: RPi4B: emmc2bus dma-range handling does not track the boot-time-FDT (u-boot based booting)
Fri, 9 Oct 2020 15:56:52 -0700
Mark Millard via freebsd-arm <[email protected]> • #22565
Re: RPi4B: emmc2bus dma-range handling does not track the boot-time-FDT (u-boot based booting)
Fri, 9 Oct 2020 15:48:30 -0700
Mark Millard via freebsd-arm <[email protected]> • #22564
Re: RPi4B: emmc2bus dma-range handling does not track the boot-time-FDT (u-boot based booting)
Sat, 10 Oct 2020 00:26:31 +0200
Klaus Cucinauomo via freebsd-arm <[email protected]> • #22563
Re: RPi4B: emmc2bus dma-range handling does not track the boot-time-FDT (u-boot based booting)
Sat, 10 Oct 2020 00:19:27 +0200
Klaus Cucinauomo via freebsd-arm <[email protected]> • #22562
Re: RPi4B: emmc2bus dma-range handling does not track the boot-time-FDT (u-boot based booting)
Fri, 9 Oct 2020 14:25:21 -0700
Mark Millard via freebsd-arm <[email protected]> • #22561
Re: RPi4B: emmc2bus dma-range handling does not track the boot-time-FDT (u-boot based booting)
Fri, 9 Oct 2020 22:28:42 +0200
Klaus Cucinauomo via freebsd-arm <[email protected]> • #22560
Re: RPi4B: emmc2bus dma-range handling does not track the boot-time-FDT (u-boot based booting)
Fri, 9 Oct 2020 12:25:25 -0700
Mark Millard via freebsd-arm <[email protected]> • #22559
Re: RPi4B: emmc2bus dma-range handling does not track the boot-time-FDT (u-boot based booting)
Fri, 9 Oct 2020 15:21:48 +0200
Klaus Cucinauomo via freebsd-arm <[email protected]> • #22558
Re: RPi4B: emmc2bus dma-range handling does not track the boot-time-FDT (u-boot based booting)
Fri, 9 Oct 2020 14:50:16 +0200
Klaus Cucinauomo via freebsd-arm <[email protected]> • #22557
Re: RPi4B: emmc2bus dma-range handling does not track the boot-time-FDT (u-boot based booting)
Fri, 9 Oct 2020 07:55:03 -0500
Kyle Evans <[email protected]> • #22556
Re: RPi4B: emmc2bus dma-range handling does not track the boot-time-FDT (u-boot based booting)
Fri, 9 Oct 2020 03:02:06 -0700
Mark Millard via freebsd-arm <[email protected]> • #22555
Re: RPi4B: emmc2bus dma-range handling does not track the boot-time-FDT (u-boot based booting)
Thu, 8 Oct 2020 23:49:01 -0700
bob prohaska <[email protected]> • #22554
Re: RPi4B: emmc2bus dma-range handling does not track the boot-time-FDT (u-boot based booting)
Thu, 8 Oct 2020 23:01:33 -0700
Mark Millard via freebsd-arm <[email protected]> • #22553
Re: RPi4B: emmc2bus dma-range handling does not track the boot-time-FDT (u-boot based booting)
Thu, 8 Oct 2020 21:29:25 -0700
Mark Millard via freebsd-arm <[email protected]> • #22552
Re: ARMv7 without VFP
Thu, 8 Oct 2020 22:19:21 -0600
Warner Losh <[email protected]> • #22551
Re: RPi4B: emmc2bus dma-range handling does not track the boot-time-FDT (u-boot based booting)
Thu, 8 Oct 2020 20:26:01 -0700
Mark Millard via freebsd-arm <[email protected]> • #22550
Re: RPi4B: emmc2bus dma-range handling does not track the boot-time-FDT (u-boot based booting)
Thu, 8 Oct 2020 20:06:05 -0700
Mark Millard via freebsd-arm <[email protected]> • #22549
Re: RPi4B: emmc2bus dma-range handling does not track the boot-time-FDT (u-boot based booting)
Thu, 8 Oct 2020 19:49:24 -0700
bob prohaska <[email protected]> • #22548
Re: RPi4B: emmc2bus dma-range handling does not track the boot-time-FDT (u-boot based booting)
Thu, 8 Oct 2020 21:27:22 -0500
Kyle Evans <[email protected]> • #22547
Re: RPi4B: emmc2bus dma-range handling does not track the boot-time-FDT (u-boot based booting)
Thu, 8 Oct 2020 19:18:55 -0700
bob prohaska <[email protected]> • #22546
ARMv7 without VFP
Fri, 9 Oct 2020 01:57:22 +0200
Marcin Wojtas <[email protected]> • #22545
Re: RPi4B: emmc2bus dma-range handling does not track the boot-time-FDT (u-boot based booting)
Thu, 8 Oct 2020 13:15:49 -0700
Mark Millard via freebsd-arm <[email protected]> • #22544
Re: RPi4B: emmc2bus dma-range handling does not track the boot-time-FDT (u-boot based booting)
Thu, 8 Oct 2020 14:32:09 -0500
Kyle Evans <[email protected]> • #22543
Re: RPi4B: emmc2bus dma-range handling does not track the boot-time-FDT (u-boot based booting)
Thu, 8 Oct 2020 12:28:21 -0700
Mark Millard via freebsd-arm <[email protected]> • #22542
RFC: allow first boot config from msdos partition
Thu, 8 Oct 2020 12:06:21 -0700
John-Mark Gurney <[email protected]> • #22541
Re: RPi4B: emmc2bus dma-range handling does not track the boot-time-FDT (u-boot based booting)
Thu, 8 Oct 2020 13:34:12 -0500
Kyle Evans <[email protected]> • #22540
Re: RPi4B: emmc2bus dma-range handling does not track the boot-time-FDT (u-boot based booting)
Thu, 8 Oct 2020 10:49:11 -0700
Mark Millard via freebsd-arm <[email protected]> • #22539
Re: RPi4B: emmc2bus dma-range handling does not track the boot-time-FDT (u-boot based booting)
Thu, 8 Oct 2020 12:38:15 -0500
Kyle Evans <[email protected]> • #22538
Re: RPi4B: emmc2bus dma-range handling does not track the boot-time-FDT (u-boot based booting)
Thu, 8 Oct 2020 11:33:45 -0500
Kyle Evans <[email protected]> • #22537
Re: RPi4B: emmc2bus dma-range handling does not track the boot-time-FDT (u-boot based booting)
Thu, 8 Oct 2020 15:27:49 +0200
Klaus Cucinauomo via freebsd-arm <[email protected]> • #22536
Re: FreeBSD-13.0-CURRENT on Helios64 Kobol NAS
Thu, 8 Oct 2020 14:15:42 +0300
Sleep Walker <[email protected]> • #22535
RPi4B: emmc2bus dma-range handling does not track the boot-time-FDT (u-boot based booting)
Thu, 8 Oct 2020 02:01:29 -0700
Mark Millard via freebsd-arm <[email protected]> • #22534
Re: BBB boot failure between r366365 and r366386
Wed, 7 Oct 2020 17:57:39 +0200
Emmanuel Vadot <[email protected]> • #22533
Re: BBB boot failure between r366365 and r366386
Wed, 7 Oct 2020 15:53:51 +0000 (UTC)
Oskar Holmlund via freebsd-arm <[email protected]> • #22532
Where is the rk3399-pinebook-pro.dtb ?
Wed, 07 Oct 2020 20:30:10 +0900
KIRIYAMA Kazuhiko <[email protected]> • #22531
Re: nanopi/allwinner i2c not working.
Wed, 7 Oct 2020 12:08:31 +0300
Daniel Braniss <[email protected]> • #22530
Re: nanopi/allwinner i2c not working.
Wed, 7 Oct 2020 12:06:28 +0300
Daniel Braniss <[email protected]> • #22529
Re: nanopi/allwinner i2c not working.
Wed, 7 Oct 2020 12:04:43 +0300
Andriy Gapon <[email protected]> • #22528
Re: nanopi/allwinner i2c not working.
Wed, 7 Oct 2020 11:59:08 +0300
Andriy Gapon <[email protected]> • #22527
Re: nanopi/allwinner i2c not working.
Wed, 7 Oct 2020 11:56:17 +0300
Daniel Braniss <[email protected]> • #22526
Re: nanopi/allwinner i2c not working.
Wed, 7 Oct 2020 11:33:16 +0300
Andriy Gapon <[email protected]> • #22525
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.