[opensuse-arm] (Untested) RPI3 image - testers wanted
Hi, http://download.opensuse.org/repositories/devel:/ARM:/Factory:/Contrib:/Rasp... (yeah, I know its the Pi2 path, I was lazy) contains an untested raspberrypi3 image. I already know that serial is broken, that seems to be an upstream issue (due to the changed clock frequencies). I haven't tested it further yet, need to buy some HDMI capable screen first. Let me know your findings. Greetings, Dirk -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On 03/03/2016 08:18 PM, Dirk Müller wrote:
Hi,
http://download.opensuse.org/repositories/devel:/ARM:/Factory:/Contrib:/Rasp...
(yeah, I know its the Pi2 path, I was lazy) contains an untested raspberrypi3 image. I already know that serial is broken, that seems to be an upstream issue (due to the changed clock frequencies).
I haven't tested it further yet, need to buy some HDMI capable screen first. Let me know your findings.
I have a patched u-boot version that can use for serial output if you like. In a nutshell, the downstream kernel crashes when used with device tree. Without device tree, it boots successfully (with start.elf). With device tree, it crashes the same way on both start.elf and loaded via u-boot. Below is a kernel log dump. I can't really make sense of it yet. There's probably code missing to deal with failed allocations. But I don't see why there would be any at that early stage of the boot. Alex [ 0.000000] Booting Linux on physical CPU 0x0 [ 0.000000] Initializing cgroup subsys cpuset [ 0.000000] Initializing cgroup subsys cpu [ 0.000000] Initializing cgroup subsys cpuacct [ 0.000000] Linux version 4.1.18-2-rpi2 (geeko@buildhost) (gcc version 5.3.1 20151207 [gcc-5-branch revision 231355] (SUSE Linux) ) #1 SMP Thu Mar 3 23:41:53 UTC 2016 (7ddb93e) [ 0.000000] CPU: ARMv7 Processor [410fd034] revision 4 (ARMv7), cr=10c5383d [ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache [ 0.000000] Machine model: Raspberry Pi 3 Model B Rev 1.2 [ 0.000000] cma: Reserved 8 MiB at 0x36400000 [ 0.000000] Memory policy: Data cache writealloc [ 0.000000] [bcm2709_smp_init_cpus] enter (94a0->f3003010) [ 0.000000] [bcm2709_smp_init_cpus] ncores=4 [ 0.000000] PERCPU: Embedded 13 pages/cpu @b6fad000 s22284 r8192 d22772 u53248 [ 0.000000] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 223300 [ 0.000000] Kernel command line: 8250.nr_uarts=1 dma.dmachans=0x7f35 bcm2708_fb.fbwidth=1824 bcm2708_fb.fbheight=984 bcm2709.boardrev=0xa02082 bcm2709.serial=0xfa0ea512 smsc95xx.macaddr=B8:27:EB:0E:A5:12 bcm2708_fb.fbswap=1 bcm2709.uart_clock=48000000 sdhci-bcm2708.emmc_clock_freq=250000000 vc_mem.mem_base=0x3dc00000 vc_mem.mem_size=0x3f000000 console=ttyAMA0,115200 kgdboc=ttyAMA0,115200 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 rootwait [ 0.000000] PID hash table entries: 4096 (order: 2, 16384 bytes) [ 0.000000] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) [ 0.000000] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) [ 0.000000] Memory: 865476K/901120K available (7573K kernel code, 770K rwdata, 2648K rodata, 528K init, 959K bss, 27452K reserved, 8192K cma-reserved, 0K highmem) [ 0.000000] Virtual kernel memory layout: [ 0.000000] vector : 0xffff0000 - 0xffff1000 ( 4 kB) [ 0.000000] fixmap : 0xffc00000 - 0xfff00000 (3072 kB) [ 0.000000] vmalloc : 0xb7800000 - 0xff000000 (1144 MB) [ 0.000000] lowmem : 0x80000000 - 0xb7000000 ( 880 MB) [ 0.000000] pkmap : 0x7fe00000 - 0x80000000 ( 2 MB) [ 0.000000] modules : 0x7f000000 - 0x7fe00000 ( 14 MB) [ 0.000000] .text : 0x80008000 - 0x80a036f4 (10222 kB) [ 0.000000] .init : 0x80a04000 - 0x80a88000 ( 528 kB) [ 0.000000] .data : 0x80a88000 - 0x80b48b88 ( 771 kB) [ 0.000000] .bss : 0x80b4b000 - 0x80c3ad44 ( 960 kB) [ 0.000000] Hierarchical RCU implementation. [ 0.000000] RCU dyntick-idle grace-period acceleration is enabled. [ 0.000000] RCU restricting CPUs from NR_CPUS=16 to nr_cpu_ids=4. [ 0.000000] RCU: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=4 [ 0.000000] NR_IRQS:608 [ 0.000000] Offload RCU callbacks from all CPUs [ 0.000000] Offload RCU callbacks from CPUs: 0-3. [ 0.000000] Architected cp15 timer(s) running at 19.20MHz (phys). [ 0.000000] clocksource arch_sys_counter: mask: 0xffffffffffffff max_cycles: 0x46d987e47, max_idle_ns: 440795202767 ns [ 0.000006] sched_clock: 56 bits at 19MHz, resolution 52ns, wraps every 4398046511078ns [ 0.000019] Switching to timer-based delay loop, resolution 52ns [ 0.000458] Console: colour dummy device 80x30 [ 0.001266] console [tty1] enabled [ 0.001309] Calibrating delay loop (skipped), value calculated using timer frequency.. 38.40 BogoMIPS (lpj=192000) [ 0.001358] pid_max: default: 32768 minimum: 301 [ 0.001545] Security Framework initialized [ 0.001649] AppArmor: AppArmor initialized [ 0.001858] Mount-cache hash table entries: 2048 (order: 1, 8192 bytes) [ 0.001889] Mountpoint-cache hash table entries: 2048 (order: 1, 8192 bytes) [ 0.002734] Initializing cgroup subsys blkio [ 0.002771] Initializing cgroup subsys memory [ 0.002811] Initializing cgroup subsys devices [ 0.002841] Initializing cgroup subsys freezer [ 0.002876] Initializing cgroup subsys net_cls [ 0.002905] Initializing cgroup subsys perf_event [ 0.002974] CPU: Testing write buffer coherency: ok [ 0.003043] ftrace: allocating 26364 entries in 52 pages [ 0.043589] missing device node for CPU 1 [ 0.043653] missing device node for CPU 2 [ 0.043677] missing device node for CPU 3 [ 0.043701] CPU0: update cpu_capacity 1024 [ 0.043722] CPU0: thread -1, cpu 0, socket 0, mpidr 80000000 [ 0.043743] [bcm2709_smp_prepare_cpus] enter [ 0.043894] Setting up static identity map for 0x8240 - 0x8298 [ 0.047435] [bcm2709_boot_secondary] cpu:1 started (0) 18 [ 0.047622] [bcm2709_secondary_init] enter cpu:1 [ 0.047665] CPU1: thread -1, cpu 1, socket 0, mpidr 80000001 [ 0.048195] [bcm2709_boot_secondary] cpu:2 started (0) 18 [ 0.048321] [bcm2709_secondary_init] enter cpu:2 [ 0.048339] CPU2: thread -1, cpu 2, socket 0, mpidr 80000002 [ 0.048814] [bcm2709_boot_secondary] cpu:3 started (0) 18 [ 0.048927] [bcm2709_secondary_init] enter cpu:3 [ 0.048944] CPU3: thread -1, cpu 3, socket 0, mpidr 80000003 [ 0.048997] Brought up 4 CPUs [ 0.049049] SMP: Total of 4 processors activated (153.60 BogoMIPS). [ 0.049069] CPU: All CPU(s) started in HYP mode. [ 0.049087] CPU: Virtualization extensions available. [ 0.049665] devtmpfs: initialized [ 0.061808] VFP support v0.3: implementor 41 architecture 3 part 40 variant 3 rev 4 [ 0.062212] clocksource jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns [ 0.062746] pinctrl core: initialized pinctrl subsystem [ 0.063746] NET: Registered protocol family 16 [ 0.068116] DMA: preallocated 4096 KiB pool for atomic coherent allocations [ 0.087705] cpuidle: using governor ladder [ 0.097706] cpuidle: using governor menu [ 0.098071] bcm2709.uart_clock = 48000000 [ 0.102054] bcm2709: Mini UART enabled [ 0.102797] No ATAGs? [ 0.102831] hw-breakpoint: found 5 (+1 reserved) breakpoint and 4 watchpoint registers. [ 0.102872] hw-breakpoint: maximum watchpoint size is 8 bytes. [ 0.103035] Serial: AMBA PL011 UART driver [ 0.103108] uart-pl011 3f201000.uart: could not find pctldev for node /soc/gpio@7e200000/uart0_pins, deferring probe [ 0.103260] bcm2835-mbox 3f00b880.mailbox: mailbox enabled [ 0.139466] bcm2708-dmaengine 3f007000.dma: DMA legacy API manager at f3007000, dmachans=0xf35 [ 0.139521] bcm2708-dmaengine 3f007000.dma: Initialized 7 DMA channels (+ 1 legacy) [ 0.140233] bcm2708-dmaengine 3f007000.dma: Load BCM2835 DMA engine driver [ 0.140258] bcm2708-dmaengine 3f007000.dma: dma_debug:0 [ 0.142521] SCSI subsystem initialized [ 0.142931] usbcore: registered new interface driver usbfs [ 0.143009] usbcore: registered new interface driver hub [ 0.143108] usbcore: registered new device driver usb [ 0.143596] raspberrypi-firmware soc:firmware: Attached to firmware from 2016-02-01 17:51 [ 0.170054] NetLabel: Initializing [ 0.170074] NetLabel: domain hash size = 128 [ 0.170092] NetLabel: protocols = UNLABELED CIPSOv4 [ 0.170153] NetLabel: unlabeled traffic allowed by default [ 0.170602] Switched to clocksource arch_sys_counter [ 0.222255] FS-Cache: Loaded [ 0.222534] CacheFiles: Loaded [ 0.222697] AppArmor: AppArmor Filesystem Enabled [ 0.232901] NET: Registered protocol family 2 [ 0.233545] TCP established hash table entries: 8192 (order: 3, 32768 bytes) [ 0.233646] TCP bind hash table entries: 8192 (order: 4, 65536 bytes) [ 0.233795] TCP: Hash tables configured (established 8192 bind 8192) [ 0.233892] UDP hash table entries: 512 (order: 2, 16384 bytes) [ 0.233940] UDP-Lite hash table entries: 512 (order: 2, 16384 bytes) [ 0.234132] NET: Registered protocol family 1 [ 0.234502] RPC: Registered named UNIX socket transport module. [ 0.234524] RPC: Registered udp transport module. [ 0.234543] RPC: Registered tcp transport module. [ 0.234561] RPC: Registered tcp NFSv4.1 backchannel transport module. [ 0.234779] Trying to unpack rootfs image as initramfs... [ 2.649423] Freeing initrd memory: 5916K (8a000000 - 8a5c7000) [ 2.649827] NetWinder Floating Point Emulator V0.97 (extended precision) [ 2.650114] hw perfevents: enabled with armv7_cortex_a7 PMU driver, 7 counters available [ 2.651777] futex hash table entries: 1024 (order: 4, 65536 bytes) [ 2.651857] Initialise system trusted keyring [ 2.651975] audit: initializing netlink subsys (disabled) [ 2.652051] audit: type=2000 audit(2.629:1): initialized [ 2.652968] zpool: loaded [ 2.652991] zbud: loaded [ 2.653208] VFS: Disk quotas dquot_6.6.0 [ 2.653274] VFS: Dquot-cache hash table entries: 1024 (order 0, 4096 bytes) [ 2.653592] FS-Cache: Netfs 'nfs' registered for caching [ 2.653803] NFS: Registering the id_resolver key type [ 2.653845] Key type id_resolver registered [ 2.653865] Key type id_legacy registered [ 2.653897] nfs4filelayout_init: NFSv4 File Layout Driver Registering... [ 2.654375] Key type big_key registered [ 2.655271] Key type asymmetric registered [ 2.655300] Asymmetric key parser 'x509' registered [ 2.655397] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 252) [ 2.655538] io scheduler noop registered [ 2.655566] io scheduler deadline registered [ 2.655614] io scheduler cfq registered (default) [ 2.656925] ------------[ cut here ]------------ [ 2.656957] WARNING: CPU: 0 PID: 1 at ../arch/arm/mm/ioremap.c:301 __arm_ioremap_pfn_caller+0xf8/0x1d0() [ 2.656989] Modules linked in: [ 2.657015] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.1.18-2-rpi2 #1 [ 2.657035] Hardware name: BCM2709 [ 2.657072] [<80025598>] (unwind_backtrace) from [<800201a0>] (show_stack+0x1c/0x28) [ 2.657111] [<800201a0>] (show_stack) from [<80733d5c>] (dump_stack+0xd4/0x118) [ 2.657151] [<80733d5c>] (dump_stack) from [<80036b48>] (warn_slowpath_common+0x9c/0xdc) [ 2.657192] [<80036b48>] (warn_slowpath_common) from [<80036c54>] (warn_slowpath_null+0x24/0x2c) [ 2.657233] [<80036c54>] (warn_slowpath_null) from [<8002dd3c>] (__arm_ioremap_pfn_caller+0xf8/0x1d0) [ 2.657273] [<8002dd3c>] (__arm_ioremap_pfn_caller) from [<8002de68>] (__arm_ioremap_caller+0x54/0x5c) [ 2.657315] [<8002de68>] (__arm_ioremap_caller) from [<803fa360>] (brcmvirt_gpio_probe+0xac/0x1a8) [ 2.657356] [<803fa360>] (brcmvirt_gpio_probe) from [<804757dc>] (platform_drv_probe+0x58/0xcc) [ 2.657395] [<804757dc>] (platform_drv_probe) from [<804736fc>] (driver_probe_device+0x220/0x44c) [ 2.657434] [<804736fc>] (driver_probe_device) from [<80473a38>] (__driver_attach+0xa4/0xa8) [ 2.657471] [<80473a38>] (__driver_attach) from [<804715a0>] (bus_for_each_dev+0x78/0xb8) [ 2.657508] [<804715a0>] (bus_for_each_dev) from [<80472af4>] (bus_add_driver+0x178/0x234) [ 2.657544] [<80472af4>] (bus_add_driver) from [<804742dc>] (driver_register+0x88/0x10c) [ 2.657582] [<804742dc>] (driver_register) from [<80009734>] (do_one_initcall+0xdc/0x250) [ 2.657622] [<80009734>] (do_one_initcall) from [<80a04f2c>] (kernel_init_freeable+0x218/0x2c0) [ 2.657663] [<80a04f2c>] (kernel_init_freeable) from [<807306e0>] (kernel_init+0x14/0xfc) [ 2.657701] [<807306e0>] (kernel_init) from [<8001ba28>] (ret_from_fork+0x14/0x2c) [ 2.657745] ---[ end trace 5fbbadbce5bed846 ]--- [ 2.657769] brcmvirt-gpio soc:virtgpio: Failed to map physical address [ 2.657799] brcmvirt-gpio: probe of soc:virtgpio failed with error -2 [ 2.658923] BCM2708FB: allocated DMA memory f6800000 [ 2.658956] BCM2708FB: allocated DMA channel 0 @ f3007000 [ 2.681115] Console: switching to colour frame buffer device 228x61 [ 2.693226] Serial: 8250/16550 driver, 1 ports, IRQ sharing disabled [ 2.693904] Serial: AMBA driver [ 2.694076] STMicroelectronics ASC driver initialized [ 2.694955] Non-volatile memory driver v1.3 [ 2.695161] vc-cma: Videocore CMA driver [ 2.695215] vc-cma: vc_cma_base = 0x00000000 [ 2.695274] vc-cma: vc_cma_size = 0x00000000 (0 MiB) [ 2.695339] vc-cma: vc_cma_initial = 0x00000000 (0 MiB) [ 2.695567] vc-mem: phys_addr:0x00000000 mem_base=0x3dc00000 mem_size:0x3f000000(1008 MiB) [ 2.707229] brd: module loaded [ 2.713257] loop: module loaded [ 2.714073] vchiq: vchiq_init_state: slot_zero = 0xb6880000, is_master = 0 [ 2.716335] Loading iSCSI transport class v2.0-870. [ 2.717164] libphy: Fixed MDIO Bus: probed [ 2.717229] dwc_otg: version 3.00a 10-AUG-2012 (platform bus) [ 2.917496] Core Release: 2.80a [ 2.917545] Setting default values for core params [ 2.917624] Finished setting default values for core params [ 3.117950] Using Buffer DMA mode [ 3.117999] Periodic Transfer Interrupt Enhancement - disabled [ 3.118070] Multiprocessor Interrupt Enhancement - disabled [ 3.118138] OTG VER PARAM: 0, OTG VER FLAG: 0 [ 3.118215] Dedicated Tx FIFOs mode [ 3.118557] WARN::dwc_otg_hcd_init:1047: FIQ DMA bounce buffers: virt = 0xb6814000 dma = 0xf6814000 len=9024 [ 3.118688] FIQ FSM acceleration enabled for : [ 3.118688] Non-periodic Split Transactions [ 3.118688] Periodic Split Transactions [ 3.118688] High-Speed Isochronous Endpoints [ 3.118915] WARN::hcd_init_fiq:412: FIQ on core 1 at 0x80558a1c [ 3.118992] WARN::hcd_init_fiq:413: FIQ ASM at 0x80558d9c length 36 [ 3.119071] WARN::hcd_init_fiq:438: MPHI regs_base at 0xb78e0000 [ 3.122719] dwc_otg 3f980000.usb: DWC OTG Controller [ 3.126332] dwc_otg 3f980000.usb: new USB bus registered, assigned bus number 1 [ 3.129930] dwc_otg 3f980000.usb: irq 32, io mem 0x00000000 [ 3.133512] Init: Port Power? op_state=1 [ 3.137007] Init: Power Port (0) [ 3.140627] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002 [ 3.144103] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [ 3.147544] usb usb1: Product: DWC OTG Controller [ 3.150957] usb usb1: Manufacturer: Linux 4.1.18-2-rpi2 dwc_otg_hcd [ 3.154357] usb usb1: SerialNumber: 3f980000.usb [ 3.158409] hub 1-0:1.0: USB hub found [ 3.161765] hub 1-0:1.0: 1 port detected [ 3.165784] usbcore: registered new interface driver usb-storage [ 3.169263] mousedev: PS/2 mouse device common for all mice [ 3.175570] bcm2835-cpufreq: min=600000 max=840000 [ 3.180550] sdhci: Secure Digital Host Controller Interface driver [ 3.185040] sdhci: Copyright(c) Pierre Ossman [ 3.189739] sdhost: log_buf @ b6813000 (f6813000) [ 3.270639] mmc0: sdhost-bcm2835 loaded - DMA enabled (>1) [ 3.277241] mmc-bcm2835 3f300000.mmc: mmc_debug:0 mmc_debug2:0 [ 3.281588] mmc-bcm2835 3f300000.mmc: DMA channels allocated [ 3.320721] sdhci-pltfm: SDHCI platform and OF driver helper [ 3.325324] ledtrig-cpu: registered to indicate activity on CPUs [ 3.329643] hidraw: raw HID events driver (C) Jiri Kosina [ 3.334388] Initializing XFRM netlink socket [ 3.338714] NET: Registered protocol family 10 [ 3.343878] NET: Registered protocol family 17 [ 3.347730] mmc0: host does not support reading read-only switch, assuming write-enable [ 3.350196] mmc0: new high speed SDHC card at address aaaa [ 3.356559] Key type dns_resolver registered [ 3.361286] Registering SWP/SWPB emulation handler [ 3.366382] Loading compiled-in X.509 certificates [ 3.368446] mmc1: queuing unknown CIS tuple 0x80 (2 bytes) [ 3.369996] mmc1: queuing unknown CIS tuple 0x80 (3 bytes) [ 3.370755] Indeed it is in host mode hprt0 = 00021501 [ 3.371658] mmc1: queuing unknown CIS tuple 0x80 (3 bytes) [ 3.374438] mmc1: queuing unknown CIS tuple 0x80 (7 bytes) [ 3.394694] Loaded X.509 cert 'devel:ARM OBS Project: 66c92fde8dc978d5cad342136dd9cb44e1d3cc5c' [ 3.399024] registered taskstats version 1 [ 3.403377] AppArmor: AppArmor sha1 policy hashing enabled [ 3.407700] vc-sm: Videocore shared memory driver [ 3.411940] [vc_sm_connected_init]: start [ 3.416722] [vc_sm_connected_init]: end - returning 0 [ 3.423603] 3f201000.uart: ttyAMA0 at MMIO 0x3f201000 (irq = 83, base_baud = 0) is a PL011 rev2 [ 3.464917] mmc1: new high speed SDIO card at address 0001 [ 3.550645] usb 1-1: new high-speed USB device number 2 using dwc_otg [ 3.550793] Indeed it is in host mode hprt0 = 00001101 [ 3.720935] usb 1-1: New USB device found, idVendor=0424, idProduct=9514 [ 3.720945] usb 1-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0 [ 3.721824] hub 1-1:1.0: USB hub found [ 3.721924] hub 1-1:1.0: 5 ports detected [ 4.000636] usb 1-1.1: new high-speed USB device number 3 using dwc_otg [ 4.100900] usb 1-1.1: New USB device found, idVendor=0424, idProduct=ec00 [ 4.100910] usb 1-1.1: New USB device strings: Mfr=0, Product=0, SerialNumber=0 [ 4.180636] usb 1-1.2: new low-speed USB device number 4 using dwc_otg [ 4.398436] usb 1-1.2: New USB device found, idVendor=04d9, idProduct=1603 [ 4.398445] usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [ 4.398451] usb 1-1.2: Product: USB Keyboard [ 4.398458] usb 1-1.2: Manufacturer: [ 4.942071] console [ttyAMA0] enabled [ 4.952350] Freeing unused kernel memory: 528K (80a04000 - 80a88000) [ 4.983289] random: systemd urandom read with 67 bits of entropy available [ 4.998923] systemd[1]: systemd 228 running in system mode. (+PAM +AUDIT +SELINUX -IMA +APPARMOR -SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ -LZ4 +SECCOMP +BLKID -ELFUTILS +KMOD +IDN) [ 5.022360] systemd[1]: Detected architecture arm. [ 5.031812] systemd[1]: Running in initial RAM disk. [ 5.057261] systemd[1]: Set hostname to <nohostname>. [ 5.380997] systemd[1]: Listening on Journal Audit Socket. [ 5.397124] systemd[1]: Listening on Journal Socket. [ 5.412204] systemd[1]: Reached target Timers. [ 5.426984] systemd[1]: Started Dispatch Password Requests to Console Directory Watch. [ 5.445254] systemd[1]: Reached target Local File Systems. [ 5.462842] systemd[1]: Created slice System Slice. [ 5.478167] systemd[1]: Reached target Slices. [ 5.496526] systemd[1]: Starting Load Kernel Modules... [ 5.513089] systemd[1]: Reached target Swap. [ 5.528487] systemd[1]: Listening on udev Kernel Socket. [ 5.547367] systemd[1]: Starting Create list of required static device nodes for the current kernel... [ 5.568224] systemd[1]: Listening on Journal Socket (/dev/log). [ 5.585228] systemd[1]: Listening on udev Control Socket. [ 5.601519] systemd[1]: Reached target Sockets. [ 5.620655] systemd[1]: Starting dracut cmdline hook... [ 5.637439] systemd[1]: Reached target Paths. [ 5.656390] systemd[1]: Starting Journal Service... [ 5.682339] systemd[1]: Started Load Kernel Modules. [ 5.699045] audit: type=1130 audit(5.669:2): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-modules-load comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' [ 5.724350] systemd[1]: Started Create list of required static device nodes for the current kernel. [ 5.746348] audit: type=1130 audit(5.719:3): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=kmod-static-nodes comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' [ 5.771776] systemd[1]: Started Journal Service. [ 5.790381] audit: type=1130 audit(5.759:4): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-journald comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' [ 5.903816] audit: type=1130 audit(5.879:5): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-tmpfiles-setup-dev comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' [ 5.940311] audit: type=1130 audit(5.909:6): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-sysctl comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' [ 6.113097] audit: type=1130 audit(6.089:7): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=dracut-cmdline comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' [ 6.193556] audit: type=1130 audit(6.169:8): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-udevd comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' [ 6.501085] audit: type=1130 audit(6.479:9): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-udev-trigger comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' [ 6.530908] mmcblk0: mmc0:aaaa SE16G 14.8 GiB [ 6.556473] mmcblk0: p1 p2 p3 p4 [ 6.607601] input: USB Keyboard as /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.2/1-1.2:1.0/0003:04D9:1603.0001/input/input0 [ 6.691055] hid-generic 0003:04D9:1603.0001: input,hidraw0: USB HID v1.10 Keyboard [ USB Keyboard] on usb-3f980000.usb-1.2/input0 [ 6.792267] input: USB Keyboard as /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.2/1-1.2:1.1/0003:04D9:1603.0002/input/input1 [ 6.829762] Unable to handle kernel paging request at virtual address fff01ff4 [ 6.844550] pgd = 8a698000 [ 6.854700] [fff01ff4] *pgd=36ffa821, *pte=00000000, *ppte=00000000 [ 6.868512] Internal error: Oops: 817 [#1] SMP ARM [ 6.871112] hid-generic 0003:04D9:1603.0002: input,hidraw1: USB HID v1.10 Device [ USB Keyboard] on usb-3f980000.usb-1.2/input1 [ 6.871262] usbcore: registered new interface driver usbhid [ 6.871265] usbhid: USB HID core driver [ 6.924850] Modules linked in: usbhid mmc_block sg [ 6.937327] CPU: 0 PID: 211 Comm: loadkeys Tainted: G W 4.1.18-2-rpi2 #1 [ 6.952838] Hardware name: BCM2709 [ 6.963885] task: b3d5ca80 ti: 8a68a000 task.ti: 8a68a000 [ 6.976958] PC is at bcm2835_sdhost_dma_complete+0x154/0x188 [ 6.990287] LR is at kmap_atomic+0x12c/0x16c [ 7.002137] pc : [<805af308>] lr : [<8002fa34>] psr: 000d0193 [ 7.002137] sp : 8a68bee0 ip : 00000000 fp : 00000002 [ 7.028694] r10: 00000018 r9 : b5970050 r8 : b3e73b00 [ 7.041400] r7 : 8002c4f8 r6 : 8a43ba14 r5 : a00d0113 r4 : b3e73b00 [ 7.055418] r3 : b78e2000 r2 : fff01ff8 r1 : fff01ff4 r0 : ffeff000 [ 7.069428] Flags: nzcv IRQs off FIQs on Mode SVC_32 ISA ARM Segment user [ 7.084163] Control: 10c5383d Table: 0a69806a DAC: 00000015 [ 7.097427] Process loadkeys (pid: 211, stack limit = 0x8a68a218) [ 7.111044] Stack: (0x8a68bee0 to 0x8a68c000) [ 7.122916] bee0: 00000000 8a68bf00 00200200 805af1b4 8a68bf00 00200200 00100100 80417e44 [ 7.138700] bf00: 8a68bf00 8a68bf00 8a68bf1c b597007c b5970080 00000000 80a82310 00000000 [ 7.154506] bf20: 00000007 8003bcb4 80a8b098 00000006 00000040 00000100 8a68a000 8003afa4 [ 7.170348] bf40: 954fd9c2 00000001 80a8b080 8a68bf40 80b4c300 0000000a ffff8d79 80aa7900 [ 7.170361] bf60: 00400100 00000001 00000000 80a84e98 00000000 00000000 00000000 00000000 [ 7.170373] bf80: 0003b230 7eda6d18 00000002 8003b578 80a84e98 800919a8 76e7de40 400d0010 [ 7.170384] bfa0: f300b200 10c5383d 10c5387d 80739f7c 7edab3b8 7edc0b80 00000208 0000002c [ 7.170394] bfc0: 7edab1b0 00000015 fffffffc 7edab3b8 00000000 0003b230 7eda6d18 00000002 [ 7.170405] bfe0: 7edab5c0 7eda6c14 0001725c 76e7de40 400d0010 ffffffff aaaaaaaa aaaaaaaa [ 7.170441] [<805af308>] (bcm2835_sdhost_dma_complete) from [<80417e44>] (vchan_complete+0x120/0x130) [ 7.170460] [<80417e44>] (vchan_complete) from [<8003bcb4>] (tasklet_action+0x78/0x118) [ 7.170474] [<8003bcb4>] (tasklet_action) from [<8003afa4>] (__do_softirq+0x178/0x364) [ 7.170486] [<8003afa4>] (__do_softirq) from [<8003b578>] (irq_exit+0xe0/0x144) [ 7.170500] [<8003b578>] (irq_exit) from [<800919a8>] (__handle_domain_irq+0xa0/0x104) [ 7.170516] [<800919a8>] (__handle_domain_irq) from [<80739f7c>] (__irq_usr+0x3c/0x140) [ 7.170529] Code: e2812004 e5943004 e593c040 f57ff04f (e581c000) [ 7.170539] ---[ end trace 5fbbadbce5bed848 ]--- [ 7.170545] Kernel panic - not syncing: Fatal exception in interrupt [ 7.170555] CPU3: stopping [ 7.170567] CPU: 3 PID: 0 Comm: swapper/3 Tainted: G D W 4.1.18-2-rpi2 #1 [ 7.170570] Hardware name: BCM2709 [ 7.170593] [<80025598>] (unwind_backtrace) from [<800201a0>] (show_stack+0x1c/0x28) [ 7.170608] [<800201a0>] (show_stack) from [<80733d5c>] (dump_stack+0xd4/0x118) [ 7.170622] [<80733d5c>] (dump_stack) from [<800229d4>] (handle_IPI+0x228/0x244) [ 7.170636] [<800229d4>] (handle_IPI) from [<80739bf4>] (__irq_svc+0x34/0x12c) [ 7.170651] [<80739bf4>] (__irq_svc) from [<8001cbd4>] (arch_cpu_idle+0x30/0x50) [ 7.170669] [<8001cbd4>] (arch_cpu_idle) from [<8007a270>] (cpu_startup_entry+0x214/0x364) [ 7.170683] [<8007a270>] (cpu_startup_entry) from [<0000952c>] (0x952c) [ 7.170691] CPU1: stopping [ 7.170700] CPU: 1 PID: 0 Comm: swapper/1 Tainted: G D W 4.1.18-2-rpi2 #1 [ 7.170703] Hardware name: BCM2709 [ 7.170719] [<80025598>] (unwind_backtrace) from [<800201a0>] (show_stack+0x1c/0x28) [ 7.170731] [<800201a0>] (show_stack) from [<80733d5c>] (dump_stack+0xd4/0x118) [ 7.170744] [<80733d5c>] (dump_stack) from [<800229d4>] (handle_IPI+0x228/0x244) [ 7.170759] [<800229d4>] (handle_IPI) from [<80739bf4>] (__irq_svc+0x34/0x12c) [ 7.170772] [<80739bf4>] (__irq_svc) from [<8001cbd4>] (arch_cpu_idle+0x30/0x50) [ 7.170786] [<8001cbd4>] (arch_cpu_idle) from [<8007a270>] (cpu_startup_entry+0x214/0x364) [ 7.170799] [<8007a270>] (cpu_startup_entry) from [<0000952c>] (0x952c) [ 7.186214] CPU2: stopping [ 7.186224] CPU: 2 PID: 208 Comm: systemd-vconsol Tainted: G D W 4.1.18-2-rpi2 #1 [ 7.186227] Hardware name: BCM2709 [ 7.186243] [<80025598>] (unwind_backtrace) from [<800201a0>] (show_stack+0x1c/0x28) [ 7.186256] [<800201a0>] (show_stack) from [<80733d5c>] (dump_stack+0xd4/0x118) [ 7.186269] [<80733d5c>] (dump_stack) from [<800229d4>] (handle_IPI+0x228/0x244) [ 7.186282] [<800229d4>] (handle_IPI) from [<80739bf4>] (__irq_svc+0x34/0x12c) [ 7.186296] [<80739bf4>] (__irq_svc) from [<8008ffc0>] (console_unlock+0x3d8/0x5f0) [ 7.186312] [<8008ffc0>] (console_unlock) from [<804430bc>] (con_get_trans_old+0xa0/0xc4) [ 7.186328] [<804430bc>] (con_get_trans_old) from [<8043c1b8>] (vt_ioctl+0x8d8/0x1538) [ 7.186343] [<8043c1b8>] (vt_ioctl) from [<8042e664>] (tty_ioctl+0x430/0xd00) [ 7.186359] [<8042e664>] (tty_ioctl) from [<8019e544>] (do_vfs_ioctl+0x404/0x628) [ 7.186372] [<8019e544>] (do_vfs_ioctl) from [<8019e7fc>] (SyS_ioctl+0x94/0xa4) [ 7.186384] [<8019e7fc>] (SyS_ioctl) from [<8001b940>] (ret_fast_syscall+0x0/0x60) [ 7.805081] Rebooting in 90 seconds.. -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On 08.03.16 01:55, Alexander Graf wrote:
On 03/03/2016 08:18 PM, Dirk Müller wrote:
Hi,
http://download.opensuse.org/repositories/devel:/ARM:/Factory:/Contrib:/Rasp...
(yeah, I know its the Pi2 path, I was lazy) contains an untested raspberrypi3 image. I already know that serial is broken, that seems to be an upstream issue (due to the changed clock frequencies).
I haven't tested it further yet, need to buy some HDMI capable screen first. Let me know your findings.
I have a patched u-boot version that can use for serial output if you like. In a nutshell, the downstream kernel crashes when used with device tree.
Without device tree, it boots successfully (with start.elf). With device tree, it crashes the same way on both start.elf and loaded via u-boot.
Below is a kernel log dump. I can't really make sense of it yet. There's probably code missing to deal with failed allocations. But I don't see why there would be any at that early stage of the boot.
The current staging image works :). Yay! Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On Thu, 2016-03-03 at 20:18 +0100, Dirk Müller wrote:
Hi,
http://download.opensuse.org/repositories/devel:/ARM:/Factory:/Contrib:/Rasp...
(yeah, I know its the Pi2 path, I was lazy) contains an untested raspberrypi3 image. I already know that serial is broken, that seems to be an upstream issue (due to the changed clock frequencies).
I haven't tested it further yet, need to buy some HDMI capable screen first. Let me know your findings.
Greetings, Dirk
I have successfully installed this image: http://download.opensuse.org/repositories/devel:/ARM:/Factory:/Contrib:/Rasp... It has several issues with booting. Uboot issues messages for a while and eventually comes to a prompt. If I type "boot", it boots up. At some point I noticed in dmesg a complaint that the first partition was "dirty" and needed an fsck. It is a FAT filesystem and fsck.fat isn't installed. I installed "dosfstools" and checked the file system. One of the uboot messages complained that "usbethaddr" was not set. Every time it boots it chooses a new MAC address which causes the dhcp server to give it a new address every time. I set that variable and did a saveenv. I suppose that is supposed to happen somehow during the first boot. There are also messages about variables "bootfile" and "pxeuuid" being missing. Variable "scan_dev_for_efi" is a script that tries to set variable "boot_prefixes" but doesn't get it right. I will read u-boot documentation and try to figure it out but if somebody fixes it I can move on to something else. Thanks. Bill -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On 16.03.16 20:00, Bill Merriam wrote:
On Thu, 2016-03-03 at 20:18 +0100, Dirk Müller wrote:
Hi,
http://download.opensuse.org/repositories/devel:/ARM:/Factory:/Contrib:/Rasp...
(yeah, I know its the Pi2 path, I was lazy) contains an untested raspberrypi3 image. I already know that serial is broken, that seems to be an upstream issue (due to the changed clock frequencies).
I haven't tested it further yet, need to buy some HDMI capable screen first. Let me know your findings.
Greetings, Dirk
I have successfully installed this image:
http://download.opensuse.org/repositories/devel:/ARM:/Factory:/Contrib:/Rasp...
It has several issues with booting. Uboot issues messages for a while and eventually comes to a prompt. If I type "boot", it boots up. At
This is my fault again - as soon as the image got rebuilt with the fixed U-Boot package (that was stuck in Factory review for a week) this error should be gone.
some point I noticed in dmesg a complaint that the first partition was "dirty" and needed an fsck. It is a FAT filesystem and fsck.fat isn't
That's weird. Sounds like a flushing bug during build?
installed. I installed "dosfstools" and checked the file system.
One of the uboot messages complained that "usbethaddr" was not set.
I don't think we support the usb mac stuff quite yet. If you have great ideas how to make it work with upstream U-Boot, we're more than happy to see patches :).
Every time it boots it chooses a new MAC address which causes the dhcp server to give it a new address every time. I set that variable and did a saveenv. I suppose that is supposed to happen somehow during the first boot.
The way it works without U-Boot is that the RPi bootloader generates the mac address from the pi serial number. We should probably do the same in U-Boot. IIRC it then gets passed to the kernel using the kernel command line. That's a horrible interface, as it breaks any integration with boot loaders (like grub2). So if we want to move this to an efi based boot mechanism, we need to instead inject the mac address into the device tree. I'm not quite sure where though - usb is not described in dt.
There are also messages about variables "bootfile" and "pxeuuid" being missing. Variable "scan_dev_for_efi" is a script that tries to set variable "boot_prefixes" but doesn't get it right.
That's the bug that was fixed in u-boot and stuck in review. Basically the bootfile definition got included in the scan_dev_for_efi variable while it should've been its own variable. I simply forgot the null terminator.
I will read u-boot documentation and try to figure it out but if somebody fixes it I can move on to something else.
That leaves the mac address thing to fix :). Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On Wed, 2016-03-16 at 23:21 +0100, Alexander Graf wrote:
On 16.03.16 20:00, Bill Merriam wrote:
On Thu, 2016-03-03 at 20:18 +0100, Dirk Müller wrote:
Hi,
http://download.opensuse.org/repositories/devel:/ARM:/Factory:/Contrib:/Rasp...
(yeah, I know its the Pi2 path, I was lazy) contains an untested raspberrypi3 image. I already know that serial is broken, that seems to be an upstream issue (due to the changed clock frequencies).
I haven't tested it further yet, need to buy some HDMI capable screen first. Let me know your findings.
Greetings, Dirk
I have successfully installed this image:
http://download.opensuse.org/repositories/devel:/ARM:/Factory:/Contrib:/Rasp...
It has several issues with booting. Uboot issues messages for a while and eventually comes to a prompt. If I type "boot", it boots up. At
This is my fault again - as soon as the image got rebuilt with the fixed U-Boot package (that was stuck in Factory review for a week) this error should be gone.
some point I noticed in dmesg a complaint that the first partition was "dirty" and needed an fsck. It is a FAT filesystem and fsck.fat isn't
That's weird. Sounds like a flushing bug during build?
installed. I installed "dosfstools" and checked the file system.
One of the uboot messages complained that "usbethaddr" was not set.
I don't think we support the usb mac stuff quite yet. If you have great ideas how to make it work with upstream U-Boot, we're more than happy to see patches :).
Every time it boots it chooses a new MAC address which causes the dhcp server to give it a new address every time. I set that variable and did a saveenv. I suppose that is supposed to happen somehow during the first boot.
The way it works without U-Boot is that the RPi bootloader generates the mac address from the pi serial number. We should probably do the same in U-Boot.
IIRC it then gets passed to the kernel using the kernel command line. That's a horrible interface, as it breaks any integration with boot loaders (like grub2). So if we want to move this to an efi based boot mechanism, we need to instead inject the mac address into the device tree. I'm not quite sure where though - usb is not described in dt.
There are also messages about variables "bootfile" and "pxeuuid" being missing. Variable "scan_dev_for_efi" is a script that tries to set variable "boot_prefixes" but doesn't get it right.
That's the bug that was fixed in u-boot and stuck in review. Basically the bootfile definition got included in the scan_dev_for_efi variable while it should've been its own variable. I simply forgot the null terminator.
I will read u-boot documentation and try to figure it out but if somebody fixes it I can move on to something else.
That leaves the mac address thing to fix :).
Alex
The serial number is available in the One Time Programmable memory. http://elinux.org/RPI_vcgencmd_usage vcgencmd otp_dump |grep 28: |cut -b 4- The MAC address seems to be RPI's prefix b8:27:eb plus the last 3 bytes of the serial. Bill -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On 17.03.16 15:25, Bill Merriam wrote:
On Wed, 2016-03-16 at 23:21 +0100, Alexander Graf wrote:
On 16.03.16 20:00, Bill Merriam wrote:
On Thu, 2016-03-03 at 20:18 +0100, Dirk Müller wrote:
Hi,
http://download.opensuse.org/repositories/devel:/ARM:/Factory:/Contrib:/Rasp...
(yeah, I know its the Pi2 path, I was lazy) contains an untested raspberrypi3 image. I already know that serial is broken, that seems to be an upstream issue (due to the changed clock frequencies).
I haven't tested it further yet, need to buy some HDMI capable screen first. Let me know your findings.
Greetings, Dirk
I have successfully installed this image:
http://download.opensuse.org/repositories/devel:/ARM:/Factory:/Contrib:/Rasp...
It has several issues with booting. Uboot issues messages for a while and eventually comes to a prompt. If I type "boot", it boots up. At
This is my fault again - as soon as the image got rebuilt with the fixed U-Boot package (that was stuck in Factory review for a week) this error should be gone.
some point I noticed in dmesg a complaint that the first partition was "dirty" and needed an fsck. It is a FAT filesystem and fsck.fat isn't
That's weird. Sounds like a flushing bug during build?
installed. I installed "dosfstools" and checked the file system.
One of the uboot messages complained that "usbethaddr" was not set.
I don't think we support the usb mac stuff quite yet. If you have great ideas how to make it work with upstream U-Boot, we're more than happy to see patches :).
Every time it boots it chooses a new MAC address which causes the dhcp server to give it a new address every time. I set that variable and did a saveenv. I suppose that is supposed to happen somehow during the first boot.
The way it works without U-Boot is that the RPi bootloader generates the mac address from the pi serial number. We should probably do the same in U-Boot.
IIRC it then gets passed to the kernel using the kernel command line. That's a horrible interface, as it breaks any integration with boot loaders (like grub2). So if we want to move this to an efi based boot mechanism, we need to instead inject the mac address into the device tree. I'm not quite sure where though - usb is not described in dt.
There are also messages about variables "bootfile" and "pxeuuid" being missing. Variable "scan_dev_for_efi" is a script that tries to set variable "boot_prefixes" but doesn't get it right.
That's the bug that was fixed in u-boot and stuck in review. Basically the bootfile definition got included in the scan_dev_for_efi variable while it should've been its own variable. I simply forgot the null terminator.
I will read u-boot documentation and try to figure it out but if somebody fixes it I can move on to something else.
That leaves the mac address thing to fix :).
Alex
The serial number is available in the One Time Programmable memory. http://elinux.org/RPI_vcgencmd_usage
vcgencmd otp_dump |grep 28: |cut -b 4-
The MAC address seems to be RPI's prefix b8:27:eb plus the last 3 bytes of the serial.
This big problem is not how to fetch the 3 bytes. It's how to pass them all the way from u-boot via fdt to the kernel and have the kernel properly use it as the mac address for the usb ethernet adapter. Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Le 17/03/2016 15:40, Alexander Graf a écrit :
On Wed, 2016-03-16 at 23:21 +0100, Alexander Graf wrote:
On 16.03.16 20:00, Bill Merriam wrote:
On Thu, 2016-03-03 at 20:18 +0100, Dirk Müller wrote:
Hi,
http://download.opensuse.org/repositories/devel:/ARM:/Factory:/Contrib:/Rasp...
(yeah, I know its the Pi2 path, I was lazy) contains an untested raspberrypi3 image. I already know that serial is broken, that seems to be an upstream issue (due to the changed clock frequencies).
I haven't tested it further yet, need to buy some HDMI capable screen first. Let me know your findings.
Greetings, Dirk I have successfully installed this image:
http://download.opensuse.org/repositories/devel:/ARM:/Factory:/Contrib:/Rasp...
It has several issues with booting. Uboot issues messages for a while and eventually comes to a prompt. If I type "boot", it boots up. At This is my fault again - as soon as the image got rebuilt with the fixed U-Boot package (that was stuck in Factory review for a week) this error should be gone.
some point I noticed in dmesg a complaint that the first partition was "dirty" and needed an fsck. It is a FAT filesystem and fsck.fat isn't That's weird. Sounds like a flushing bug during build?
installed. I installed "dosfstools" and checked the file system.
One of the uboot messages complained that "usbethaddr" was not set. I don't think we support the usb mac stuff quite yet. If you have great ideas how to make it work with upstream U-Boot, we're more than happy to see patches :).
Every time it boots it chooses a new MAC address which causes the dhcp server to give it a new address every time. I set that variable and did a saveenv. I suppose that is supposed to happen somehow during the first boot. The way it works without U-Boot is that the RPi bootloader generates the mac address from the pi serial number. We should probably do the same in U-Boot.
IIRC it then gets passed to the kernel using the kernel command line. That's a horrible interface, as it breaks any integration with boot loaders (like grub2). So if we want to move this to an efi based boot mechanism, we need to instead inject the mac address into the device tree. I'm not quite sure where though - usb is not described in dt.
There are also messages about variables "bootfile" and "pxeuuid" being missing. Variable "scan_dev_for_efi" is a script that tries to set variable "boot_prefixes" but doesn't get it right. That's the bug that was fixed in u-boot and stuck in review. Basically the bootfile definition got included in the scan_dev_for_efi variable while it should've been its own variable. I simply forgot the null terminator.
I will read u-boot documentation and try to figure it out but if somebody fixes it I can move on to something else. That leaves the mac address thing to fix :).
Alex The serial number is available in the One Time Programmable memory. http://elinux.org/RPI_vcgencmd_usage
vcgencmd otp_dump |grep 28: |cut -b 4-
The MAC address seems to be RPI's prefix b8:27:eb plus the last 3 bytes of the serial. This big problem is not how to fetch the 3 bytes. It's how to pass them all the way from u-boot via fdt to the kernel and have the kernel
On 17.03.16 15:25, Bill Merriam wrote: properly use it as the mac address for the usb ethernet adapter.
You may ask on u-boot mailing list. I think u-boot is able to do it more or less automatically. Guillaume
Alex
-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On 17.03.16 15:48, Guillaume Gardet wrote:
Le 17/03/2016 15:40, Alexander Graf a écrit :
On Wed, 2016-03-16 at 23:21 +0100, Alexander Graf wrote:
On 16.03.16 20:00, Bill Merriam wrote:
On Thu, 2016-03-03 at 20:18 +0100, Dirk Müller wrote:
Hi,
http://download.opensuse.org/repositories/devel:/ARM:/Factory:/Contrib:/Rasp...
(yeah, I know its the Pi2 path, I was lazy) contains an untested raspberrypi3 image. I already know that serial is broken, that seems to be an upstream issue (due to the changed clock frequencies).
I haven't tested it further yet, need to buy some HDMI capable screen first. Let me know your findings.
Greetings, Dirk I have successfully installed this image:
http://download.opensuse.org/repositories/devel:/ARM:/Factory:/Contrib:/Rasp...
It has several issues with booting. Uboot issues messages for a while and eventually comes to a prompt. If I type "boot", it boots up. At This is my fault again - as soon as the image got rebuilt with the fixed U-Boot package (that was stuck in Factory review for a week) this error should be gone.
some point I noticed in dmesg a complaint that the first partition was "dirty" and needed an fsck. It is a FAT filesystem and fsck.fat isn't That's weird. Sounds like a flushing bug during build?
installed. I installed "dosfstools" and checked the file system.
One of the uboot messages complained that "usbethaddr" was not set. I don't think we support the usb mac stuff quite yet. If you have great ideas how to make it work with upstream U-Boot, we're more than happy to see patches :).
Every time it boots it chooses a new MAC address which causes the dhcp server to give it a new address every time. I set that variable and did a saveenv. I suppose that is supposed to happen somehow during the first boot. The way it works without U-Boot is that the RPi bootloader generates the mac address from the pi serial number. We should probably do the same in U-Boot.
IIRC it then gets passed to the kernel using the kernel command line. That's a horrible interface, as it breaks any integration with boot loaders (like grub2). So if we want to move this to an efi based boot mechanism, we need to instead inject the mac address into the device tree. I'm not quite sure where though - usb is not described in dt.
There are also messages about variables "bootfile" and "pxeuuid" being missing. Variable "scan_dev_for_efi" is a script that tries to set variable "boot_prefixes" but doesn't get it right. That's the bug that was fixed in u-boot and stuck in review. Basically the bootfile definition got included in the scan_dev_for_efi variable while it should've been its own variable. I simply forgot the null terminator.
I will read u-boot documentation and try to figure it out but if somebody fixes it I can move on to something else. That leaves the mac address thing to fix :).
Alex The serial number is available in the One Time Programmable memory. http://elinux.org/RPI_vcgencmd_usage
vcgencmd otp_dump |grep 28: |cut -b 4-
The MAC address seems to be RPI's prefix b8:27:eb plus the last 3 bytes of the serial. This big problem is not how to fetch the 3 bytes. It's how to pass them all the way from u-boot via fdt to the kernel and have the kernel
On 17.03.16 15:25, Bill Merriam wrote: properly use it as the mac address for the usb ethernet adapter.
You may ask on u-boot mailing list. I think u-boot is able to do it more or less automatically.
It does it automatically, but I can't find code that passes the internal usbethaddr variable on to Linux. Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Le 17/03/2016 15:48, Guillaume Gardet a écrit :
Le 17/03/2016 15:40, Alexander Graf a écrit :
On Wed, 2016-03-16 at 23:21 +0100, Alexander Graf wrote:
On 16.03.16 20:00, Bill Merriam wrote:
On Thu, 2016-03-03 at 20:18 +0100, Dirk Müller wrote:
Hi,
http://download.opensuse.org/repositories/devel:/ARM:/Factory:/Contrib:/Rasp...
(yeah, I know its the Pi2 path, I was lazy) contains an untested raspberrypi3 image. I already know that serial is broken, that seems to be an upstream issue (due to the changed clock frequencies).
I haven't tested it further yet, need to buy some HDMI capable screen first. Let me know your findings.
Greetings, Dirk I have successfully installed this image:
http://download.opensuse.org/repositories/devel:/ARM:/Factory:/Contrib:/Rasp...
It has several issues with booting. Uboot issues messages for a while and eventually comes to a prompt. If I type "boot", it boots up. At This is my fault again - as soon as the image got rebuilt with the fixed U-Boot package (that was stuck in Factory review for a week) this error should be gone.
some point I noticed in dmesg a complaint that the first partition was "dirty" and needed an fsck. It is a FAT filesystem and fsck.fat isn't That's weird. Sounds like a flushing bug during build?
installed. I installed "dosfstools" and checked the file system.
One of the uboot messages complained that "usbethaddr" was not set. I don't think we support the usb mac stuff quite yet. If you have great ideas how to make it work with upstream U-Boot, we're more than happy to see patches :).
Every time it boots it chooses a new MAC address which causes the dhcp server to give it a new address every time. I set that variable and did a saveenv. I suppose that is supposed to happen somehow during the first boot. The way it works without U-Boot is that the RPi bootloader generates the mac address from the pi serial number. We should probably do the same in U-Boot.
IIRC it then gets passed to the kernel using the kernel command line. That's a horrible interface, as it breaks any integration with boot loaders (like grub2). So if we want to move this to an efi based boot mechanism, we need to instead inject the mac address into the device tree. I'm not quite sure where though - usb is not described in dt.
There are also messages about variables "bootfile" and "pxeuuid" being missing. Variable "scan_dev_for_efi" is a script that tries to set variable "boot_prefixes" but doesn't get it right. That's the bug that was fixed in u-boot and stuck in review. Basically the bootfile definition got included in the scan_dev_for_efi variable while it should've been its own variable. I simply forgot the null terminator.
I will read u-boot documentation and try to figure it out but if somebody fixes it I can move on to something else. That leaves the mac address thing to fix :).
Alex The serial number is available in the One Time Programmable memory. http://elinux.org/RPI_vcgencmd_usage
vcgencmd otp_dump |grep 28: |cut -b 4-
The MAC address seems to be RPI's prefix b8:27:eb plus the last 3 bytes of the serial. This big problem is not how to fetch the 3 bytes. It's how to pass them all the way from u-boot via fdt to the kernel and have the kernel
On 17.03.16 15:25, Bill Merriam wrote: properly use it as the mac address for the usb ethernet adapter.
You may ask on u-boot mailing list. I think u-boot is able to do it more or less automatically.
Have a look at fdt_fixup_ethernet(...) function. Guillaume
Guillaume
Alex
-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Le 17/03/2016 15:55, Alexander Graf a écrit :
On 17.03.16 15:48, Guillaume Gardet wrote:
Le 17/03/2016 15:40, Alexander Graf a écrit :
On Wed, 2016-03-16 at 23:21 +0100, Alexander Graf wrote:
On 16.03.16 20:00, Bill Merriam wrote:
On Thu, 2016-03-03 at 20:18 +0100, Dirk Müller wrote: > Hi, > > http://download.opensuse.org/repositories/devel:/ARM:/Factory:/Contrib:/Rasp... > > > > (yeah, I know its the Pi2 path, I was lazy) contains an untested > raspberrypi3 image. I already know that serial is broken, that seems > to be an upstream issue (due to the changed clock frequencies). > > I haven't tested it further yet, need to buy some HDMI capable screen > first. Let me know your findings. > > Greetings, > Dirk I have successfully installed this image:
http://download.opensuse.org/repositories/devel:/ARM:/Factory:/Contrib:/Rasp...
It has several issues with booting. Uboot issues messages for a while and eventually comes to a prompt. If I type "boot", it boots up. At This is my fault again - as soon as the image got rebuilt with the fixed U-Boot package (that was stuck in Factory review for a week) this error should be gone.
some point I noticed in dmesg a complaint that the first partition was "dirty" and needed an fsck. It is a FAT filesystem and fsck.fat isn't That's weird. Sounds like a flushing bug during build?
installed. I installed "dosfstools" and checked the file system.
One of the uboot messages complained that "usbethaddr" was not set. I don't think we support the usb mac stuff quite yet. If you have great ideas how to make it work with upstream U-Boot, we're more than happy to see patches :).
Every time it boots it chooses a new MAC address which causes the dhcp server to give it a new address every time. I set that variable and did a saveenv. I suppose that is supposed to happen somehow during the first boot. The way it works without U-Boot is that the RPi bootloader generates the mac address from the pi serial number. We should probably do the same in U-Boot.
IIRC it then gets passed to the kernel using the kernel command line. That's a horrible interface, as it breaks any integration with boot loaders (like grub2). So if we want to move this to an efi based boot mechanism, we need to instead inject the mac address into the device tree. I'm not quite sure where though - usb is not described in dt.
There are also messages about variables "bootfile" and "pxeuuid" being missing. Variable "scan_dev_for_efi" is a script that tries to set variable "boot_prefixes" but doesn't get it right. That's the bug that was fixed in u-boot and stuck in review. Basically the bootfile definition got included in the scan_dev_for_efi variable while it should've been its own variable. I simply forgot the null terminator.
I will read u-boot documentation and try to figure it out but if somebody fixes it I can move on to something else. That leaves the mac address thing to fix :).
Alex The serial number is available in the One Time Programmable memory. http://elinux.org/RPI_vcgencmd_usage
vcgencmd otp_dump |grep 28: |cut -b 4-
The MAC address seems to be RPI's prefix b8:27:eb plus the last 3 bytes of the serial. This big problem is not how to fetch the 3 bytes. It's how to pass them all the way from u-boot via fdt to the kernel and have the kernel
On 17.03.16 15:25, Bill Merriam wrote: properly use it as the mac address for the usb ethernet adapter. You may ask on u-boot mailing list. I think u-boot is able to do it more or less automatically. It does it automatically, but I can't find code that passes the internal usbethaddr variable on to Linux.
I think it passes ethaddr, not usbethaddr. So, you may want to also set ethaddr. Guillaume
Alex
-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On 17.03.16 15:56, Guillaume Gardet wrote:
Le 17/03/2016 15:48, Guillaume Gardet a écrit :
Le 17/03/2016 15:40, Alexander Graf a écrit :
On Wed, 2016-03-16 at 23:21 +0100, Alexander Graf wrote:
On 16.03.16 20:00, Bill Merriam wrote:
On Thu, 2016-03-03 at 20:18 +0100, Dirk Müller wrote: > Hi, > > http://download.opensuse.org/repositories/devel:/ARM:/Factory:/Contrib:/Rasp... > > > > (yeah, I know its the Pi2 path, I was lazy) contains an untested > raspberrypi3 image. I already know that serial is broken, that seems > to be an upstream issue (due to the changed clock frequencies). > > I haven't tested it further yet, need to buy some HDMI capable > screen > first. Let me know your findings. > > Greetings, > Dirk I have successfully installed this image:
http://download.opensuse.org/repositories/devel:/ARM:/Factory:/Contrib:/Rasp...
It has several issues with booting. Uboot issues messages for a while and eventually comes to a prompt. If I type "boot", it boots up. At This is my fault again - as soon as the image got rebuilt with the fixed U-Boot package (that was stuck in Factory review for a week) this error should be gone.
some point I noticed in dmesg a complaint that the first partition was "dirty" and needed an fsck. It is a FAT filesystem and fsck.fat isn't That's weird. Sounds like a flushing bug during build?
installed. I installed "dosfstools" and checked the file system.
One of the uboot messages complained that "usbethaddr" was not set. I don't think we support the usb mac stuff quite yet. If you have great ideas how to make it work with upstream U-Boot, we're more than happy to see patches :).
Every time it boots it chooses a new MAC address which causes the dhcp server to give it a new address every time. I set that variable and did a saveenv. I suppose that is supposed to happen somehow during the first boot. The way it works without U-Boot is that the RPi bootloader generates the mac address from the pi serial number. We should probably do the same in U-Boot.
IIRC it then gets passed to the kernel using the kernel command line. That's a horrible interface, as it breaks any integration with boot loaders (like grub2). So if we want to move this to an efi based boot mechanism, we need to instead inject the mac address into the device tree. I'm not quite sure where though - usb is not described in dt.
There are also messages about variables "bootfile" and "pxeuuid" being missing. Variable "scan_dev_for_efi" is a script that tries to set variable "boot_prefixes" but doesn't get it right. That's the bug that was fixed in u-boot and stuck in review. Basically the bootfile definition got included in the scan_dev_for_efi variable while it should've been its own variable. I simply forgot the null terminator.
I will read u-boot documentation and try to figure it out but if somebody fixes it I can move on to something else. That leaves the mac address thing to fix :).
Alex The serial number is available in the One Time Programmable memory. http://elinux.org/RPI_vcgencmd_usage
vcgencmd otp_dump |grep 28: |cut -b 4-
The MAC address seems to be RPI's prefix b8:27:eb plus the last 3 bytes of the serial. This big problem is not how to fetch the 3 bytes. It's how to pass them all the way from u-boot via fdt to the kernel and have the kernel
On 17.03.16 15:25, Bill Merriam wrote: properly use it as the mac address for the usb ethernet adapter.
You may ask on u-boot mailing list. I think u-boot is able to do it more or less automatically.
Have a look at fdt_fixup_ethernet(...) function.
That only works for devices listed in device tree though, right? The eth adapter is attached to USB which doesn't list its devices in dt. Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Le 17/03/2016 15:59, Alexander Graf a écrit :
On 17.03.16 15:56, Guillaume Gardet wrote:
Le 17/03/2016 15:48, Guillaume Gardet a écrit :
Le 17/03/2016 15:40, Alexander Graf a écrit :
On Wed, 2016-03-16 at 23:21 +0100, Alexander Graf wrote:
On 16.03.16 20:00, Bill Merriam wrote: > On Thu, 2016-03-03 at 20:18 +0100, Dirk Müller wrote: >> Hi, >> >> http://download.opensuse.org/repositories/devel:/ARM:/Factory:/Contrib:/Rasp... >> >> >> >> (yeah, I know its the Pi2 path, I was lazy) contains an untested >> raspberrypi3 image. I already know that serial is broken, that seems >> to be an upstream issue (due to the changed clock frequencies). >> >> I haven't tested it further yet, need to buy some HDMI capable >> screen >> first. Let me know your findings. >> >> Greetings, >> Dirk > I have successfully installed this image: > > http://download.opensuse.org/repositories/devel:/ARM:/Factory:/Contrib:/Rasp... > > > It has several issues with booting. Uboot issues messages for a > while > and eventually comes to a prompt. If I type "boot", it boots up. At This is my fault again - as soon as the image got rebuilt with the fixed U-Boot package (that was stuck in Factory review for a week) this error should be gone.
> some point I noticed in dmesg a complaint that the first partition > was > "dirty" and needed an fsck. It is a FAT filesystem and fsck.fat > isn't That's weird. Sounds like a flushing bug during build?
> installed. I installed "dosfstools" and checked the file system. > > One of the uboot messages complained that "usbethaddr" was not set. I don't think we support the usb mac stuff quite yet. If you have great ideas how to make it work with upstream U-Boot, we're more than happy to see patches :).
> Every time it boots it chooses a new MAC address which causes the > dhcp > server to give it a new address every time. I set that variable > and did > a saveenv. I suppose that is supposed to happen somehow during the > first boot. The way it works without U-Boot is that the RPi bootloader generates the mac address from the pi serial number. We should probably do the same in U-Boot.
IIRC it then gets passed to the kernel using the kernel command line. That's a horrible interface, as it breaks any integration with boot loaders (like grub2). So if we want to move this to an efi based boot mechanism, we need to instead inject the mac address into the device tree. I'm not quite sure where though - usb is not described in dt.
> There are also messages about variables "bootfile" and "pxeuuid" > being > missing. Variable "scan_dev_for_efi" is a script that tries to set > variable "boot_prefixes" but doesn't get it right. That's the bug that was fixed in u-boot and stuck in review. Basically the bootfile definition got included in the scan_dev_for_efi variable while it should've been its own variable. I simply forgot the null terminator.
> I will read u-boot documentation and try to figure it out but if > somebody fixes it I can move on to something else. That leaves the mac address thing to fix :).
Alex The serial number is available in the One Time Programmable memory. http://elinux.org/RPI_vcgencmd_usage
vcgencmd otp_dump |grep 28: |cut -b 4-
The MAC address seems to be RPI's prefix b8:27:eb plus the last 3 bytes of the serial. This big problem is not how to fetch the 3 bytes. It's how to pass them all the way from u-boot via fdt to the kernel and have the kernel
On 17.03.16 15:25, Bill Merriam wrote: properly use it as the mac address for the usb ethernet adapter. You may ask on u-boot mailing list. I think u-boot is able to do it more or less automatically. Have a look at fdt_fixup_ethernet(...) function. That only works for devices listed in device tree though, right? The eth adapter is attached to USB which doesn't list its devices in dt.
Yes, I think so. Ask on u-boot ML, maybe people would have some idea. Guillaume
Alex
-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On Thu, 2016-03-17 at 16:02 +0100, Guillaume Gardet wrote:
Le 17/03/2016 15:59, Alexander Graf a écrit :
On 17.03.16 15:56, Guillaume Gardet wrote:
Le 17/03/2016 15:48, Guillaume Gardet a écrit :
Le 17/03/2016 15:40, Alexander Graf a écrit :
On Wed, 2016-03-16 at 23:21 +0100, Alexander Graf wrote: > On 16.03.16 20:00, Bill Merriam wrote: >> On Thu, 2016-03-03 at 20:18 +0100, Dirk Müller wrote: >>> Hi, >>> >>> http://download.opensuse.org/repositories/devel:/ARM:/Factory:/Contrib:/Rasp... >>> >>> >>> >>> (yeah, I know its the Pi2 path, I was lazy) contains an untested >>> raspberrypi3 image. I already know that serial is broken, that seems >>> to be an upstream issue (due to the changed clock frequencies). >>> >>> I haven't tested it further yet, need to buy some HDMI capable >>> screen >>> first. Let me know your findings. >>> >>> Greetings, >>> Dirk >> I have successfully installed this image: >> >> http://download.opensuse.org/repositories/devel:/ARM:/Factory:/Contrib:/Rasp... >> >> >> It has several issues with booting. Uboot issues messages for a >> while >> and eventually comes to a prompt. If I type "boot", it boots up. At > This is my fault again - as soon as the image got rebuilt with the > fixed > U-Boot package (that was stuck in Factory review for a week) this > error > should be gone. > >> some point I noticed in dmesg a complaint that the first partition >> was >> "dirty" and needed an fsck. It is a FAT filesystem and fsck.fat >> isn't > That's weird. Sounds like a flushing bug during build? > >> installed. I installed "dosfstools" and checked the file system. >> >> One of the uboot messages complained that "usbethaddr" was not set. > I don't think we support the usb mac stuff quite yet. If you have > great > ideas how to make it work with upstream U-Boot, we're more than > happy to > see patches :). > >> Every time it boots it chooses a new MAC address which causes the >> dhcp >> server to give it a new address every time. I set that variable >> and did >> a saveenv. I suppose that is supposed to happen somehow during the >> first boot. > The way it works without U-Boot is that the RPi bootloader > generates the > mac address from the pi serial number. We should probably do the > same in > U-Boot. > > IIRC it then gets passed to the kernel using the kernel command line. > That's a horrible interface, as it breaks any integration with boot > loaders (like grub2). So if we want to move this to an efi based boot > mechanism, we need to instead inject the mac address into the device > tree. I'm not quite sure where though - usb is not described in dt. > >> There are also messages about variables "bootfile" and "pxeuuid" >> being >> missing. Variable "scan_dev_for_efi" is a script that tries to set >> variable "boot_prefixes" but doesn't get it right. > That's the bug that was fixed in u-boot and stuck in review. Basically > the bootfile definition got included in the scan_dev_for_efi variable > while it should've been its own variable. I simply forgot the null > terminator. > >> I will read u-boot documentation and try to figure it out but if >> somebody fixes it I can move on to something else. > That leaves the mac address thing to fix :). > > > Alex The serial number is available in the One Time Programmable memory. http://elinux.org/RPI_vcgencmd_usage
vcgencmd otp_dump |grep 28: |cut -b 4-
The MAC address seems to be RPI's prefix b8:27:eb plus the last 3 bytes of the serial. This big problem is not how to fetch the 3 bytes. It's how to pass them all the way from u-boot via fdt to the kernel and have the kernel
On 17.03.16 15:25, Bill Merriam wrote: properly use it as the mac address for the usb ethernet adapter. You may ask on u-boot mailing list. I think u-boot is able to do it more or less automatically. Have a look at fdt_fixup_ethernet(...) function. That only works for devices listed in device tree though, right? The eth adapter is attached to USB which doesn't list its devices in dt.
Yes, I think so. Ask on u-boot ML, maybe people would have some idea.
Guillaume
Alex
In the version of boot.script (and boot.scr) that I have there is this long statement to set boot args to pass to the kernel. The MAC address for the ethernet adapter is set via "smsc95xx.macaddr" setenv bootargs "root=/dev/disk/by-id/mmc-SE32G_0xa82b1160-part3 loader=uboot disk=/dev/disk/by-id/mmc-SE32G_0xa82b1160 resume=/dev/disk/by-id/mmc-SE32G_0xa82b1160-part4 quiet splash=silen t plymouth.enable=0 dwc_otg.lpm_enable=0 console=ttyAMA0,115200n8 kgdboc=ttyAMA0,115200 rootflags=commit=120,data=writeback smsc95xx.macaddr=${usbethaddr} ${append}" I then set "usbethaddr" as an environment variable and it works nicely. I just used the last random address but I can set the right one that way. Bill -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
----- Bill Merriam
On Thu, 2016-03-17 at 16:02 +0100, Guillaume Gardet wrote:
Le 17/03/2016 15:59, Alexander Graf a écrit :
On 17.03.16 15:56, Guillaume Gardet wrote:
Le 17/03/2016 15:48, Guillaume Gardet a écrit :
Le 17/03/2016 15:40, Alexander Graf a écrit :
On 17.03.16 15:25, Bill Merriam wrote: > On Wed, 2016-03-16 at 23:21 +0100, Alexander Graf wrote: >> On 16.03.16 20:00, Bill Merriam wrote: >>> On Thu, 2016-03-03 at 20:18 +0100, Dirk Müller wrote: >>>> Hi, >>>> >>>> http://download.opensuse.org/repositories/devel:/ARM:/Factory:/Contrib:/Rasp... >>>> >>>> >>>> >>>> (yeah, I know its the Pi2 path, I was lazy) contains an untested >>>> raspberrypi3 image. I already know that serial is broken, that seems >>>> to be an upstream issue (due to the changed clock frequencies). >>>> >>>> I haven't tested it further yet, need to buy some HDMI capable >>>> screen >>>> first. Let me know your findings. >>>> >>>> Greetings, >>>> Dirk >>> I have successfully installed this image: >>> >>> http://download.opensuse.org/repositories/devel:/ARM:/Factory:/Contrib:/Rasp... >>> >>> >>> It has several issues with booting. Uboot issues messages for a >>> while >>> and eventually comes to a prompt. If I type "boot", it boots up. At >> This is my fault again - as soon as the image got rebuilt with the >> fixed >> U-Boot package (that was stuck in Factory review for a week) this >> error >> should be gone. >> >>> some point I noticed in dmesg a complaint that the first partition >>> was >>> "dirty" and needed an fsck. It is a FAT filesystem and fsck.fat >>> isn't >> That's weird. Sounds like a flushing bug during build? >> >>> installed. I installed "dosfstools" and checked the file system. >>> >>> One of the uboot messages complained that "usbethaddr" was not set. >> I don't think we support the usb mac stuff quite yet. If you have >> great >> ideas how to make it work with upstream U-Boot, we're more than >> happy to >> see patches :). >> >>> Every time it boots it chooses a new MAC address which causes the >>> dhcp >>> server to give it a new address every time. I set that variable >>> and did >>> a saveenv. I suppose that is supposed to happen somehow during the >>> first boot. >> The way it works without U-Boot is that the RPi bootloader >> generates the >> mac address from the pi serial number. We should probably do the >> same in >> U-Boot. >> >> IIRC it then gets passed to the kernel using the kernel command line. >> That's a horrible interface, as it breaks any integration with boot >> loaders (like grub2). So if we want to move this to an efi based boot >> mechanism, we need to instead inject the mac address into the device >> tree. I'm not quite sure where though - usb is not described in dt. >> >>> There are also messages about variables "bootfile" and "pxeuuid" >>> being >>> missing. Variable "scan_dev_for_efi" is a script that tries to set >>> variable "boot_prefixes" but doesn't get it right. >> That's the bug that was fixed in u-boot and stuck in review. Basically >> the bootfile definition got included in the scan_dev_for_efi variable >> while it should've been its own variable. I simply forgot the null >> terminator. >> >>> I will read u-boot documentation and try to figure it out but if >>> somebody fixes it I can move on to something else. >> That leaves the mac address thing to fix :). >> >> >> Alex > The serial number is available in the One Time Programmable memory. > http://elinux.org/RPI_vcgencmd_usage > > vcgencmd otp_dump |grep 28: |cut -b 4- > > The MAC address seems to be RPI's prefix b8:27:eb plus the last 3 bytes > of the serial. This big problem is not how to fetch the 3 bytes. It's how to pass them all the way from u-boot via fdt to the kernel and have the kernel properly use it as the mac address for the usb ethernet adapter. You may ask on u-boot mailing list. I think u-boot is able to do it more or less automatically. Have a look at fdt_fixup_ethernet(...) function. That only works for devices listed in device tree though, right? The eth adapter is attached to USB which doesn't list its devices in dt.
Yes, I think so. Ask on u-boot ML, maybe people would have some idea.
Guillaume
Alex
In the version of boot.script (and boot.scr) that I have there is this long statement to set boot args to pass to the kernel. The MAC address for the ethernet adapter is set via "smsc95xx.macaddr"
setenv bootargs "root=/dev/disk/by-id/mmc-SE32G_0xa82b1160-part3 loader=uboot disk=/dev/disk/by-id/mmc-SE32G_0xa82b1160 resume=/dev/disk/by-id/mmc-SE32G_0xa82b1160-part4 quiet splash=silen t plymouth.enable=0 dwc_otg.lpm_enable=0 console=ttyAMA0,115200n8 kgdboc=ttyAMA0,115200 rootflags=commit=120,data=writeback smsc95xx.macaddr=${usbethaddr} ${append}"
I then set "usbethaddr" as an environment variable and it works nicely. I just used the last random address but I can set the right one that way.
That works only on rpi downstream kernel. Since the smsc driver is modified to get this working. Guillaume
Bill
-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On 17.03.16 16:02, Guillaume Gardet wrote:
Le 17/03/2016 15:59, Alexander Graf a écrit :
On 17.03.16 15:56, Guillaume Gardet wrote:
Le 17/03/2016 15:48, Guillaume Gardet a écrit :
Le 17/03/2016 15:40, Alexander Graf a écrit :
On Wed, 2016-03-16 at 23:21 +0100, Alexander Graf wrote: > On 16.03.16 20:00, Bill Merriam wrote: >> On Thu, 2016-03-03 at 20:18 +0100, Dirk Müller wrote: >>> Hi, >>> >>> http://download.opensuse.org/repositories/devel:/ARM:/Factory:/Contrib:/Rasp... >>> >>> >>> >>> >>> (yeah, I know its the Pi2 path, I was lazy) contains an untested >>> raspberrypi3 image. I already know that serial is broken, that >>> seems >>> to be an upstream issue (due to the changed clock frequencies). >>> >>> I haven't tested it further yet, need to buy some HDMI capable >>> screen >>> first. Let me know your findings. >>> >>> Greetings, >>> Dirk >> I have successfully installed this image: >> >> http://download.opensuse.org/repositories/devel:/ARM:/Factory:/Contrib:/Rasp... >> >> >> >> It has several issues with booting. Uboot issues messages for a >> while >> and eventually comes to a prompt. If I type "boot", it boots >> up. At > This is my fault again - as soon as the image got rebuilt with the > fixed > U-Boot package (that was stuck in Factory review for a week) this > error > should be gone. > >> some point I noticed in dmesg a complaint that the first partition >> was >> "dirty" and needed an fsck. It is a FAT filesystem and fsck.fat >> isn't > That's weird. Sounds like a flushing bug during build? > >> installed. I installed "dosfstools" and checked the file system. >> >> One of the uboot messages complained that "usbethaddr" was not set. > I don't think we support the usb mac stuff quite yet. If you have > great > ideas how to make it work with upstream U-Boot, we're more than > happy to > see patches :). > >> Every time it boots it chooses a new MAC address which causes the >> dhcp >> server to give it a new address every time. I set that variable >> and did >> a saveenv. I suppose that is supposed to happen somehow during the >> first boot. > The way it works without U-Boot is that the RPi bootloader > generates the > mac address from the pi serial number. We should probably do the > same in > U-Boot. > > IIRC it then gets passed to the kernel using the kernel command > line. > That's a horrible interface, as it breaks any integration with boot > loaders (like grub2). So if we want to move this to an efi based > boot > mechanism, we need to instead inject the mac address into the device > tree. I'm not quite sure where though - usb is not described in dt. > >> There are also messages about variables "bootfile" and "pxeuuid" >> being >> missing. Variable "scan_dev_for_efi" is a script that tries to set >> variable "boot_prefixes" but doesn't get it right. > That's the bug that was fixed in u-boot and stuck in review. > Basically > the bootfile definition got included in the scan_dev_for_efi > variable > while it should've been its own variable. I simply forgot the null > terminator. > >> I will read u-boot documentation and try to figure it out but if >> somebody fixes it I can move on to something else. > That leaves the mac address thing to fix :). > > > Alex The serial number is available in the One Time Programmable memory. http://elinux.org/RPI_vcgencmd_usage
vcgencmd otp_dump |grep 28: |cut -b 4-
The MAC address seems to be RPI's prefix b8:27:eb plus the last 3 bytes of the serial. This big problem is not how to fetch the 3 bytes. It's how to pass
On 17.03.16 15:25, Bill Merriam wrote: them all the way from u-boot via fdt to the kernel and have the kernel properly use it as the mac address for the usb ethernet adapter. You may ask on u-boot mailing list. I think u-boot is able to do it more or less automatically. Have a look at fdt_fixup_ethernet(...) function. That only works for devices listed in device tree though, right? The eth adapter is attached to USB which doesn't list its devices in dt.
Yes, I think so. Ask on u-boot ML, maybe people would have some idea.
This really is a kernel problem, not a U-Boot one ;). So I asked on the #armlinux channel. Apparently someone else felt the same pain on other boards and so we have all the infrastructure in place soon to deal with this via device tree: http://www.spinics.net/lists/linux-usb/msg136469.html https://lkml.org/lkml/2016/2/3/621 With these (switching to upstream for RPi will only become realistic within the 4.6 time frame anyway) and the existing logic in U-Boot to write the mac address property for ethernet devices, all we need is a small device tree patch to explicitly list the usb ethernet adapter! Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On 17.03.16 20:26, Bill Merriam wrote:
On Thu, 2016-03-17 at 16:02 +0100, Guillaume Gardet wrote:
Le 17/03/2016 15:59, Alexander Graf a écrit :
On 17.03.16 15:56, Guillaume Gardet wrote:
Le 17/03/2016 15:48, Guillaume Gardet a écrit :
Le 17/03/2016 15:40, Alexander Graf a écrit :
On 17.03.16 15:25, Bill Merriam wrote: > On Wed, 2016-03-16 at 23:21 +0100, Alexander Graf wrote: >> On 16.03.16 20:00, Bill Merriam wrote: >>> On Thu, 2016-03-03 at 20:18 +0100, Dirk Müller wrote: >>>> Hi, >>>> >>>> http://download.opensuse.org/repositories/devel:/ARM:/Factory:/Contrib:/Rasp... >>>> >>>> >>>> >>>> (yeah, I know its the Pi2 path, I was lazy) contains an untested >>>> raspberrypi3 image. I already know that serial is broken, that seems >>>> to be an upstream issue (due to the changed clock frequencies). >>>> >>>> I haven't tested it further yet, need to buy some HDMI capable >>>> screen >>>> first. Let me know your findings. >>>> >>>> Greetings, >>>> Dirk >>> I have successfully installed this image: >>> >>> http://download.opensuse.org/repositories/devel:/ARM:/Factory:/Contrib:/Rasp... >>> >>> >>> It has several issues with booting. Uboot issues messages for a >>> while >>> and eventually comes to a prompt. If I type "boot", it boots up. At >> This is my fault again - as soon as the image got rebuilt with the >> fixed >> U-Boot package (that was stuck in Factory review for a week) this >> error >> should be gone. >> >>> some point I noticed in dmesg a complaint that the first partition >>> was >>> "dirty" and needed an fsck. It is a FAT filesystem and fsck.fat >>> isn't >> That's weird. Sounds like a flushing bug during build? >> >>> installed. I installed "dosfstools" and checked the file system. >>> >>> One of the uboot messages complained that "usbethaddr" was not set. >> I don't think we support the usb mac stuff quite yet. If you have >> great >> ideas how to make it work with upstream U-Boot, we're more than >> happy to >> see patches :). >> >>> Every time it boots it chooses a new MAC address which causes the >>> dhcp >>> server to give it a new address every time. I set that variable >>> and did >>> a saveenv. I suppose that is supposed to happen somehow during the >>> first boot. >> The way it works without U-Boot is that the RPi bootloader >> generates the >> mac address from the pi serial number. We should probably do the >> same in >> U-Boot. >> >> IIRC it then gets passed to the kernel using the kernel command line. >> That's a horrible interface, as it breaks any integration with boot >> loaders (like grub2). So if we want to move this to an efi based boot >> mechanism, we need to instead inject the mac address into the device >> tree. I'm not quite sure where though - usb is not described in dt. >> >>> There are also messages about variables "bootfile" and "pxeuuid" >>> being >>> missing. Variable "scan_dev_for_efi" is a script that tries to set >>> variable "boot_prefixes" but doesn't get it right. >> That's the bug that was fixed in u-boot and stuck in review. Basically >> the bootfile definition got included in the scan_dev_for_efi variable >> while it should've been its own variable. I simply forgot the null >> terminator. >> >>> I will read u-boot documentation and try to figure it out but if >>> somebody fixes it I can move on to something else. >> That leaves the mac address thing to fix :). >> >> >> Alex > The serial number is available in the One Time Programmable memory. > http://elinux.org/RPI_vcgencmd_usage > > vcgencmd otp_dump |grep 28: |cut -b 4- > > The MAC address seems to be RPI's prefix b8:27:eb plus the last 3 bytes > of the serial. This big problem is not how to fetch the 3 bytes. It's how to pass them all the way from u-boot via fdt to the kernel and have the kernel properly use it as the mac address for the usb ethernet adapter. You may ask on u-boot mailing list. I think u-boot is able to do it more or less automatically. Have a look at fdt_fixup_ethernet(...) function. That only works for devices listed in device tree though, right? The eth adapter is attached to USB which doesn't list its devices in dt.
Yes, I think so. Ask on u-boot ML, maybe people would have some idea.
Guillaume
Alex
In the version of boot.script (and boot.scr) that I have there is this long statement to set boot args to pass to the kernel. The MAC address for the ethernet adapter is set via "smsc95xx.macaddr"
setenv bootargs "root=/dev/disk/by-id/mmc-SE32G_0xa82b1160-part3 loader=uboot disk=/dev/disk/by-id/mmc-SE32G_0xa82b1160 resume=/dev/disk/by-id/mmc-SE32G_0xa82b1160-part4 quiet splash=silen t plymouth.enable=0 dwc_otg.lpm_enable=0 console=ttyAMA0,115200n8 kgdboc=ttyAMA0,115200 rootflags=commit=120,data=writeback smsc95xx.macaddr=${usbethaddr} ${append}"
I then set "usbethaddr" as an environment variable and it works nicely. I just used the last random address but I can set the right one that way.
As Guillaume mentioned this is a special hack for the downstream kernel that *should* already work. I'm surprised it doesn't. If you have some time on your hands, please try to debug down why usbethaddr doesn't get set automatically - the code for it is in U-Boot. Going forward, we will move to a more standard EFI based booting mechanism though, which means we can't access U-Boot variables in the kernel command line anymore. So we need a different mechanism to pass the mac address into the kernel. The "usual" way to get things from firmware into the kernel is device tree. The patches I pointed at in the other mail enable support for exactly what we need, so we're getting close to a clean solution. This should also help us on other boards that have ethernet attached via USB, such as the Arndale ones. Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Am 18.03.2016 um 09:59 schrieb Alexander Graf:
This really is a kernel problem, not a U-Boot one ;). So I asked on the #armlinux channel.
Apparently someone else felt the same pain on other boards and so we have all the infrastructure in place soon to deal with this via device tree:
http://www.spinics.net/lists/linux-usb/msg136469.html https://lkml.org/lkml/2016/2/3/621
With these (switching to upstream for RPi will only become realistic within the 4.6 time frame anyway) [...]
What's missing in 4.5? I tried and didn't get any serial output. Regards, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton; HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On 18.03.16 13:59, Andreas Färber wrote:
Am 18.03.2016 um 09:59 schrieb Alexander Graf:
This really is a kernel problem, not a U-Boot one ;). So I asked on the #armlinux channel.
Apparently someone else felt the same pain on other boards and so we have all the infrastructure in place soon to deal with this via device tree:
http://www.spinics.net/lists/linux-usb/msg136469.html https://lkml.org/lkml/2016/2/3/621
With these (switching to upstream for RPi will only become realistic within the 4.6 time frame anyway) [...]
What's missing in 4.5? I tried and didn't get any serial output.
Apparently sd card access, touchscreen support and rpi3 support are problematic areas: http://ht4u.net/news/31929_linux_45_mit_support_fuer_uefi_amd_und_raspberry_... 3d acceleration support is also supposed to get a significant boost with 4.6: http://www.phoronix.com/scan.php?page=news_item&px=Linux-4.6-RPi-Faster-3D So I think it's reasonable to provide an upstream based image for the RPi2, but we should hold back with a real switchover until 4.6. Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
participants (6)
-
Alexander Graf -
Andreas Färber -
Bill Merriam -
Dirk Müller -
Guillaume Gardet -
guillaume.gardet＠free.fr