Debian on Dell Wyse T10 / T50
Posted by Koen
|
Koen
Debian on Dell Wyse T10 / T50 July 21, 2018 09:58AM |
Hi,
I picked up a Dell Wyse T10 / T50 from ebay since it seems to have similar specs as the HP T5325 and I thought it may be possible to run Debian on it. Serial connection works but doesn't show any output when booting and seems to be locked down. Connecting the box up to a monitor and keyboard allows you to login and explore the system and enable ssh. The operating system seems to be based on an old version of ubuntu 10 and runs kernel 2.6.32
info on the mounted file systems:
output from dmesg:
cpuinfo:
partitions:
files in /:
files in /boot/:
Searching online Dell / Wyse seem to use some remote management software to administer these devices so I'm not sure if the bootloader can be unlocked. However maybe someone else has an idea how to run Debian on this system?
Thanks,
Koen
-----
moderator edit: changed thread title to make it easier for users to find in searching.
Edited 1 time(s). Last edit at 09/01/2018 05:27PM by bodhi.
I picked up a Dell Wyse T10 / T50 from ebay since it seems to have similar specs as the HP T5325 and I thought it may be possible to run Debian on it. Serial connection works but doesn't show any output when booting and seems to be locked down. Connecting the box up to a monitor and keyboard allows you to login and explore the system and enable ssh. The operating system seems to be based on an old version of ubuntu 10 and runs kernel 2.6.32
admin@LWT008064aa7d6c:~$ uname -a Linux LWT008064aa7d6c 2.6.32-217-hedley #34hedley46-Ubuntu Wed Dec 14 07:47:31 UTC 2011 armv7l GNU/Linux
info on the mounted file systems:
admin@LWT008064aa7d6c:/$ mount /dev/sda3 on / type ext3 (rw,errors=remount-ro) proc on /proc type proc (rw,noexec,nosuid,nodev) none on /sys type sysfs (rw,noexec,nosuid,nodev) devtmpfs on /dev type devtmpfs (rw,mode=0755) none on /sys/kernel/debug type debugfs (rw) none on /sys/kernel/security type securityfs (rw) none on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=0620) none on /dev/shm type tmpfs (rw,nosuid,nodev) none on /tmp type tmpfs (rw,nosuid,nodev,mode=1777) none on /var/run type tmpfs (rw,nosuid,mode=0755) none on /var/lock type tmpfs (rw,noexec,nosuid,nodev) none on /var/log type tmpfs (rw,noexec,nosuid,nodev) none on /lib/init/rw type tmpfs (rw,nosuid,mode=0755) tmpfs on /home type tmpfs (rw) /dev/bus on /proc/bus type none (rw,bind) tmpfs on /var/wyse type tmpfs (rw) /dev/bus on /proc/bus type none (rw,bind)
output from dmesg:
admin@LWT008064aa7d6c:/$ dmesg Linux version 2.6.32-217-hedley (buildd@shedir) (gcc version 4.4.3 (Ubuntu 4.4.3-4ubuntu5) ) #34hedley46-Ubuntu Wed Dec 14 07:47:31 UTC 2011 (Ubuntu 2.6.32-217.34hedley46-hedley 2.6.32.41+drm33.18) CPU: Marvell PJ4 v7 Processor-wmmx [560f5815] revision 5 (ARMv7), cr=10c53c7f CPU: VIPT nonaliasing data cache, VIPT nonaliasing instruction cache Machine: WYSE Mimas Board Marvell Dove DRAM parameters found (version = 0x09080000) Machine: WYSE Mimas Board Memory policy: ECC disabled, Data cache writeback On node 0 totalpages: 204800 free_area_init_node: node 0, pgdat c0728790, node_mem_map c07ad000 Normal zone: 1200 pages used for memmap Normal zone: 0 pages reserved Normal zone: 152400 pages, LIFO batch:31 wait table c0fad020 HighMem zone: 400 pages used for memmap HighMem zone: 50800 pages, LIFO batch:15 wait table c0faf040 Built 1 zonelists in Zone order, mobility grouping off. Total pages: 203200 Kernel command line: root=/dev/sda3 pm_disable usb0Mode=host usb1Mode=host video=dovefb:lcd0:1024x768-32@60,lcd1:1024x768-32@60 clcd.lcd0_enable=1 clcd.lcd1_enable=1 clcd.lcd0_clk=3 clcd.lcd1_clk=1 splash no_console_suspend kb3310_disable=1 cpufreq_disable=1 vmalloc=384M quiet PID hash table entries: 4096 (order: 2, 16384 bytes) Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) Memory: 600MB 200MB = 800MB total Memory: 801856KB available (6684K code, 758K data, 180K init, 204800K highmem) Hierarchical RCU implementation. NR_IRQS:135 Console: colour dummy device 80x30 console [tty0] enabled Calibrating delay loop... 992.87 BogoMIPS (lpj=4964352) Security Framework initialized AppArmor: AppArmor initialized Mount-cache hash table entries: 512 CPU: Testing write buffer coherency: ok devtmpfs: initialized NET: Registered protocol family 16 Dove MV88AP510-?? (REV=7) SoC, TCLK = 167MHz DOVE_MC @ 0x280 is 010E0202 PLiao: DOVE_MC @ 0x510 is 01010101 Tauros2: Disabling L2 prefetch. Tauros2: Enabling L2 cache. Tauros2: L2 cache support initialised in ARMv7 mode. Setting gpu clock to 500000000 (divider: 4) Setting axi clock to 333000000 (divider: 5) Mimas DVT board detected Initializing USB0 Host Initializing USB1 Host LCD0 doesn't use PLL. LCD1 uses PLL. Turn on PLL accurate mode. Dove PCIe port 0: link down, ignoring Dove PCIe port 1: link down, ignoring bio: create slab <bio-0> at 0 SCSI subsystem initialized libata version 3.00 loaded. usbcore: registered new interface driver usbfs usbcore: registered new interface driver hub usbcore: registered new device driver usb Bluetooth: Core ver 2.15 NET: Registered protocol family 31 Bluetooth: HCI device and connection manager initialized Bluetooth: HCI socket layer initialized cfg80211: Calling CRDA to update world regulatory domain NetLabel: Initializing NetLabel: domain hash size = 128 NetLabel: protocols = UNLABELED CIPSOv4 NetLabel: unlabeled traffic allowed by default Switching to clocksource orion_clocksource AppArmor: AppArmor Filesystem Enabled NET: Registered protocol family 2 IP route cache hash table entries: 32768 (order: 5, 131072 bytes) TCP established hash table entries: 131072 (order: 8, 1048576 bytes) TCP bind hash table entries: 65536 (order: 6, 262144 bytes) TCP: Hash tables configured (established 131072 bind 65536) TCP reno registered NET: Registered protocol family 1 RPC: Registered udp transport module. RPC: Registered tcp transport module. RPC: Registered tcp NFSv4.1 backchannel transport module. Power Management for Marvell Dove. PMU Detected Frequencies CPU 1000Mhz, AXI 250Mhz, L2 500Mhz, DDR 500Mhz Dove hwmon thermal sensor initialized. [galcore] registerBase =0xf1840000, registerMemSize = 0x0003ffff, contiguousBase= 0x32000000, contiguousSize = 0x07ffffff [galcore] real contiguouSize = 0x07ffffff [galcore] chipModel=0x600,chipRevision=0x19,chipFeatures=0x87ecd,chipMinorFeatures=0x7 cesadev_modinit cesadev_probe cesadev_init(c006f66c) mvCesaInit: sessions=640, queue=64, pSram=fdb00000 audit: initializing netlink socket (disabled) type=2000 audit(0.240:1): initialized highmem bounce pool size: 64 pages squashfs: version 4.0 (2009/01/31) Phillip Lougher JFFS2 version 2.2. (NAND) © 2001-2006 Red Hat, Inc. msgmni has been set to 1167 alg: No test for cipher_null (cipher_null-generic) alg: No test for ecb(cipher_null) (ecb-cipher_null) alg: No test for digest_null (digest_null-generic) alg: No test for compress_null (compress_null-generic) alg: No test for stdrng (krng) io scheduler noop registered io scheduler anticipatory registered io scheduler deadline registered io scheduler cfq registered (default) Initializing ths8200_init dovedcon has been initialized. dovefb_display_init dovefb_display driver init ok. Serial: 8250/16550 driver, 2 ports, IRQ sharing disabled serial8250.0: ttyS0 at MMIO 0xf1012000 (irq = 7) is a 16550A serial8250.1: ttyS1 at MMIO 0xf1012100 (irq = 8) is a 16550A brd: module loaded loop: module loaded BMM Module Vmeta memroy start: 0x3a000000, size: 100663296 BMM init with size=96MB mvumi:2.0.4.9 Jan 22, 2008 sata_mv sata_mv.0: version 1.28 sata_mv sata_mv.0: slots 32 ports 1 scsi0 : sata_mv ata1: SATA max UDMA/133 irq 62 MV-643xx 10/100/1000 ethernet driver version 1.4 mv643xx_eth smi: probed net eth0: port 0 with MAC address 00:80:64:aa:7d:6c PPP generic driver version 2.4.2 tun: Universal TUN/TAP device driver, 1.6 tun: (C) 1999-2004 Max Krasnyansky <maxk@qualcomm.com> ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver orion-ehci orion-ehci.0: Marvell Orion EHCI orion-ehci orion-ehci.0: new USB bus registered, assigned bus number 1 orion-ehci orion-ehci.0: irq 24, io mem 0xf1050000 orion-ehci orion-ehci.0: USB 2.0 started, EHCI 1.00 usb usb1: configuration #1 chosen from 1 choice hub 1-0:1.0: USB hub found hub 1-0:1.0: 1 port detected orion-ehci orion-ehci.1: Marvell Orion EHCI orion-ehci orion-ehci.1: new USB bus registered, assigned bus number 2 orion-ehci orion-ehci.1: irq 25, io mem 0xf1051000 orion-ehci orion-ehci.1: USB 2.0 started, EHCI 1.00 usb usb2: configuration #1 chosen from 1 choice hub 2-0:1.0: USB hub found hub 2-0:1.0: 1 port detected usbcore: registered new interface driver usblp Initializing USB Mass Storage driver... usbcore: registered new interface driver usb-storage USB Mass Storage support registered. usbcore: registered new interface driver ums-datafab usbcore: registered new interface driver ums-freecom usbcore: registered new interface driver ums-jumpshot usbcore: registered new interface driver ums-sddr09 usbcore: registered new interface driver ums-sddr55 mice: PS/2 mouse device common for all mice rtc-mv rtc-mv: rtc core: registered rtc-mv as rtc0 IRQ 133/rtc-mv: IRQF_DISABLED is not guaranteed on shared IRQs i2c /dev entries driver eneec_probe with name = KB39XX, addr = 0x58, irq = 71 Driver for 1-wire Dallas network protocol. 1-Wire driver for the DS2760 battery monitor chip - (c) 2004-2005, Szabolcs Gyurko device-mapper: uevent: version 1.0.3 device-mapper: ioctl: 4.15.0-ioctl (2009-04-01) initialised: dm-devel@redhat.com Bluetooth: Generic Bluetooth USB driver ver 0.6 usbcore: registered new interface driver btusb cpuidle: using governor ladder cpuidle: using governor menu sdhci: Secure Digital Host Controller Interface driver sdhci: Copyright(c) Pierre Ossman sdhci: Requesting irq host->irq=36, host->irqn Registered led device: mmc0:: mmc0: SDHCI controller on sdhci-mv.1 [sdhci-mv.1] using DMA mv_xor_shared mv_xor_shared.0: Marvell shared XOR driver mv_xor_shared mv_xor_shared.1: Marvell shared XOR driver input: AT Translated Set 2 keyboard as /devices/platform/mv64xxx_i2c_exp.1/i2c-1/1-0058/serio0/input/input0 mv_xor mv_xor.0: Marvell XOR: ( xor cpy ) mv_xor mv_xor.1: Marvell XOR: ( xor fill cpy ) ata1: SATA link up 1.5 Gbps (SStatus 113 SControl F300) mv_xor mv_xor.2: Marvell XOR: ( xor cpy ) ata1.00: CFA: 1GB ATA Flash Disk, AD B612J, max UDMA/66 ata1.00: 2001888 sectors, multi 0: LBA ata1.00: configured for UDMA/66 scsi 0:0:0:0: Direct-Access ATA 1GB ATA Flash Di AD B PQ: 0 ANSI: 5 sd 0:0:0:0: [sda] 2001888 512-byte logical blocks: (1.02 GB/977 MiB) sd 0:0:0:0: [sda] Write Protect is off sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00 sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA sda: sda1 sda2 sda3 sd 0:0:0:0: [sda] Attached SCSI disk mv_xor mv_xor.3: Marvell XOR: ( xor fill cpy ) usbcore: registered new interface driver usbhid usbhid: v2.6:USB HID core driver Advanced Linux Sound Architecture Driver Version 1.0.21. usbcore: registered new interface driver snd-usb-audio asoc: RT5630 HiFi <-> mv88fx-i2s1 mapping ok ALSA device list: #0: Dove-I2S-RT5630 (RT5630) aufs 2-standalone.tree-20091207 marvell_mrvl_pj4_detect_pmu: detected arm/mrvl_pj4 PMU oprofile: using arm/mrvl_pj4 Netfilter messages via NETLINK v0.30. TCP cubic registered NET: Registered protocol family 10 IPv6 over IPv4 tunneling driver NET: Registered protocol family 17 Bluetooth: L2CAP ver 2.14 Bluetooth: L2CAP socket layer initialized Bluetooth: SCO (Voice Link) ver 0.6 Bluetooth: SCO socket layer initialized Bluetooth: RFCOMM TTY layer initialized Bluetooth: RFCOMM socket layer initialized Bluetooth: RFCOMM ver 1.11 Bluetooth: BNEP (Ethernet Emulation) ver 1.3 Bluetooth: BNEP filters: protocol multicast Bluetooth: HIDP (Human Interface Emulation) ver 1.2 lib80211: common routines for IEEE802.11 drivers lib80211_crypt: registered algorithm 'NULL' XScale iWMMXt coprocessor detected. VFP support v0.3: implementor 56 architecture 2 part 20 variant 9 rev 5 Dove FB driver: Initialize /proc/mv_dump_lcd0 use cat /proc/mv_dump_lcd0 to see reg settings dovefb dovefb.0: use ref clock IDT_CLK1 o Kernel parameter: 1024x768-32@60. ------------<GFX Layer 0 video mode database>----------- mode 0: <1920x1200@60> pico=5177 fb timings 336 128 38 1 208 3 xorg timings 1920 2048 2256 2592 1200 1201 1204 1242 mode 1: <1920x1080@60> pico=6734 fb timings 148 88 36 4 44 5 xorg timings 1920 2008 2052 2200 1080 1084 1089 1125 mode 2: <1650x1050@60> pico=6888 fb timings 288 104 33 1 184 3 xorg timings 1650 1754 1938 2226 1050 1051 1054 1087 mode 3: <1366x 768@60> pico=11659 fb timings 216 72 23 1 144 3 xorg timings 1366 1438 1582 1798 768 769 772 795 mode 4: <1280x1024@60> pico=9262 fb timings 248 48 38 1 112 3 xorg timings 1280 1328 1440 1688 1024 1025 1028 1066 mode 5: <1280x 720@60> pico=13468 fb timings 220 110 20 5 40 5 xorg timings 1280 1390 1430 1650 720 725 730 750 mode 6: <1024x 768@85> pico=10581 fb timings 208 48 36 1 96 3 xorg timings 1024 1072 1168 1376 768 769 772 808 mode 7: <1024x 768@70> pico=13346 fb timings 144 24 29 3 136 6 xorg timings 1024 1048 1184 1328 768 771 777 806 mode 8: <1024x 768@60> pico=15385 fb timings 160 24 29 3 136 6 xorg timings 1024 1048 1184 1344 768 771 777 806 mode 9: <1024x 600@60> pico=22401 fb timings 38 38 8 8 100 4 xorg timings 1024 1062 1162 1200 600 608 612 620 mode 10: < 800x 600@85> pico=17790 fb timings 152 32 27 1 64 3 xorg timings 800 832 896 1048 600 601 604 631 mode 11: < 800x 600@75> pico=20234 fb timings 160 16 21 1 80 2 xorg timings 800 816 896 1056 600 601 603 624 mode 12: < 800x 600@72> pico=20052 fb timings 64 56 23 37 120 6 xorg timings 800 856 976 1040 600 637 643 666 mode 13: < 800x 600@60> pico=25131 fb timings 88 40 23 1 128 4 xorg timings 800 840 968 1056 600 601 605 628 mode 14: < 800x 600@56> pico=26515 fb timings 128 32 14 1 128 4 xorg timings 800 832 960 1088 600 601 605 619 mode 15: < 640x 480@85> pico=27780 fb timings 112 32 25 1 48 3 xorg timings 640 672 720 832 480 481 484 509 mode 16: < 640x 480@75> pico=31746 fb timings 48 16 32 11 96 2 xorg timings 640 656 752 800 480 491 493 525 mode 17: < 640x 480@72> pico=32102 fb timings 128 24 28 9 40 3 xorg timings 640 664 704 832 480 489 492 520 mode 18: < 640x 480@60> pico=39758 fb timings 48 16 31 11 96 2 xorg timings 640 656 752 800 480 491 493 524 found <1024x768@60>, pixclock=15385 set clk 1 to 64998375 dividers found (in lookup table) for Fout = 64998375. n=234 d=5 odiv 18 YC pitch is 0.User program needs refine set clk 1 to 64998375 dividers found (in lookup table) for Fout = 64998375. n=234 d=5 odiv 18 Console: switching to colour frame buffer device 128x48 o dovefb: frame buffer device was successfully loaded. Dove FB driver: Initialize /proc/mv_dump_lcd1 use cat /proc/mv_dump_lcd1 to see reg settings dovefb dovefb.1: use ref clock accurate_LCDCLK o Kernel parameter: 1024x768-32@60. ------------<GFX Layer 1 video mode database>----------- mode 0: <1920x1200@60> pico=5177 fb timings 336 128 38 1 208 3 xorg timings 1920 2048 2256 2592 1200 1201 1204 1242 mode 1: <1920x1080@60> pico=6734 fb timings 148 88 36 4 44 5 xorg timings 1920 2008 2052 2200 1080 1084 1089 1125 mode 2: <1650x1050@60> pico=6888 fb timings 288 104 33 1 184 3 xorg timings 1650 1754 1938 2226 1050 1051 1054 1087 mode 3: <1366x 768@60> pico=11659 fb timings 216 72 23 1 144 3 xorg timings 1366 1438 1582 1798 768 769 772 795 mode 4: <1280x1024@60> pico=9262 fb timings 248 48 38 1 112 3 xorg timings 1280 1328 1440 1688 1024 1025 1028 1066 mode 5: <1280x 720@60> pico=13468 fb timings 220 110 20 5 40 5 xorg timings 1280 1390 1430 1650 720 725 730 750 mode 6: <1024x 768@85> pico=10581 fb timings 208 48 36 1 96 3 xorg timings 1024 1072 1168 1376 768 769 772 808 mode 7: <1024x 768@70> pico=13346 fb timings 144 24 29 3 136 6 xorg timings 1024 1048 1184 1328 768 771 777 806 mode 8: <1024x 768@60> pico=15385 fb timings 160 24 29 3 136 6 xorg timings 1024 1048 1184 1344 768 771 777 806 mode 9: <1024x 600@60> pico=22401 fb timings 38 38 8 8 100 4 xorg timings 1024 1062 1162 1200 600 608 612 620 mode 10: < 800x 600@85> pico=17790 fb timings 152 32 27 1 64 3 xorg timings 800 832 896 1048 600 601 604 631 mode 11: < 800x 600@75> pico=20234 fb timings 160 16 21 1 80 2 xorg timings 800 816 896 1056 600 601 603 624 mode 12: < 800x 600@72> pico=20052 fb timings 64 56 23 37 120 6 xorg timings 800 856 976 1040 600 637 643 666 mode 13: < 800x 600@60> pico=25131 fb timings 88 40 23 1 128 4 xorg timings 800 840 968 1056 600 601 605 628 mode 14: < 800x 600@56> pico=26515 fb timings 128 32 14 1 128 4 xorg timings 800 832 960 1088 600 601 605 619 mode 15: < 640x 480@85> pico=27780 fb timings 112 32 25 1 48 3 xorg timings 640 672 720 832 480 481 484 509 mode 16: < 640x 480@75> pico=31746 fb timings 48 16 32 11 96 2 xorg timings 640 656 752 800 480 491 493 525 mode 17: < 640x 480@72> pico=32102 fb timings 128 24 28 9 40 3 xorg timings 640 664 704 832 480 489 492 520 mode 18: < 640x 480@60> pico=39758 fb timings 48 16 31 11 96 2 xorg timings 640 656 752 800 480 491 493 524 found <1024x768@60>, pixclock=15385 set internal refclk divider to 31.0.(accurate mode) YC pitch is 0.User program needs refine o dovefb: frame buffer device was successfully loaded. rtc-mv rtc-mv: setting system clock to 2018-07-21 14:18:44 UTC (1532182724) kjournald starting. Commit interval 5 seconds EXT3-fs warning: maximal mount count reached, running e2fsck is recommended EXT3 FS on sda3, internal journal EXT3-fs: mounted filesystem with writeback data mode. VFS: Mounted root (ext3 filesystem) on device 8:3. devtmpfs: mounted Freeing init memory: 180K usb 1-1: new high speed USB device using orion-ehci and address 2 usb 1-1: configuration #1 chosen from 1 choice hub 1-1:1.0: USB hub found hub 1-1:1.0: 4 ports detected usb 1-1.1: new low speed USB device using orion-ehci and address 3 usb 1-1.1: configuration #1 chosen from 1 choice input: PixArt Microsoft USB Optical Mouse as /devices/platform/orion-ehci.0/usb1/1-1/1-1.1/1-1.1:1.0/input/input1 generic-usb 0003:045E:00CB.0001: input,hidraw0: USB HID v1.11 Mouse [PixArt Microsoft USB Optical Mouse] on usb-orion-ehci.0-1.1/input0 usb 1-1.4: new low speed USB device using orion-ehci and address 4 usb 1-1.4: configuration #1 chosen from 1 choice input: CHICONY USB Keyboard as /devices/platform/orion-ehci.0/usb1/1-1/1-1.4/1-1.4:1.0/input/input2 generic-usb 0003:04F2:0116.0002: input,hidraw1: USB HID v1.10 Keyboard [CHICONY USB Keyboard] on usb-orion-ehci.0-1.4/input0 wco.c:v0.01 10/02/2012 WriteCO Control Driver udev: starting version 151 ADDRCONF(NETDEV_UP): eth0: link is not ready set clk 1 to 64998375 dividers found (in lookup table) for Fout = 64998375. n=234 d=5 odiv 18 set internal refclk divider to 31.0.(accurate mode) set clk 1 to 148500148 dividers found (in lookup table) for Fout = 148500148. n=1188 d=25 odiv 8 DCON fb callback: blank... YC pitch is 0.User program needs refine YC pitch is 0.User program needs refine set clk 1 to 148500148 dividers found (in lookup table) for Fout = 148500148. n=1188 d=25 odiv 8 eth0: link up, 100 Mb/s, full duplex, flow control disabled ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready DCON fb callback: unblanking... eth0: link down eth0: link up, 100 Mb/s, full duplex, flow control disabled eth0: no IPv6 routers present eth0: link down Setting vmeta clock to 500000000 (divider: 4) eth0: link up, 100 Mb/s, full duplex, flow control disabled DCON fb callback: unblanking...
cpuinfo:
admin@LWT008064aa7d6c:/$ cat /proc/cpuinfo Processor : Marvell PJ4 v7 Processor-wmmx rev 5 (v7l) BogoMIPS : 992.87 Features : swp half thumb fastmult vfp edsp iwmmxt CPU implementer : 0x56 CPU architecture: 7 CPU variant : 0x0 CPU part : 0x581 CPU revision : 5 Hardware : WYSE Mimas Board Revision : 0000 Serial : 0000000000000000
partitions:
admin@LWT008064aa7d6c:/$ cat /proc/partitions major minor #blocks name 8 0 1000944 sda 8 1 17408 sda1 8 2 215040 sda2 8 3 766976 sda3
files in /:
admin@LWT008064aa7d6c:/$ ll total 54 drwxr-xr-x 24 root root 1024 2013-08-05 12:02 ./ drwxr-xr-x 24 root root 1024 2013-08-05 12:02 ../ drwxr-xr-x 2 root root 5120 2013-08-05 11:16 bin/ drwxr-xr-x 2 root root 1024 2013-08-05 11:08 boot/ drwxr-xr-x 2 root root 1024 2013-08-05 11:05 cdrom/ drwxr-xr-x 13 root root 4140 2018-07-21 15:18 dev/ drwxr-xr-x 110 root root 6144 2018-07-21 15:20 etc/ drwxrwxrwt 3 root root 60 2018-07-21 15:19 home/ drwxr-xr-x 2 root root 1024 2013-08-05 11:01 kernel/ drwxr-xr-x 12 root root 9216 2013-08-05 11:19 lib/ drwx------ 2 root root 12288 2013-08-05 11:01 lost+found/ drwxr-xr-x 2 root root 1024 2012-02-03 01:06 media/ drwxr-xr-x 2 root root 1024 2010-04-23 11:14 mnt/ drwxr-xr-x 3 root root 1024 2013-08-05 11:16 opt/ -rwxr-xr-x 1 root root 1944 2011-07-18 06:55 postpush.sh* -rwxr-xr-x 1 root root 784 2011-11-01 01:15 prepull.sh* dr-xr-xr-x 126 root root 0 1970-01-01 01:00 proc/ drwxr-xr-x 2 root root 1024 2013-08-05 11:01 recovery/ drwx------ 4 root root 1024 2013-08-05 11:22 root/ drwxr-xr-x 3 root root 5120 2013-08-05 11:15 sbin/ drwxr-xr-x 2 root root 1024 2009-12-07 13:32 selinux/ drwxr-xr-x 2 root root 1024 2012-02-03 01:06 srv/ drwxr-xr-x 12 root root 0 1970-01-01 01:00 sys/ drwxrwxrwt 11 root root 400 2018-07-21 15:32 tmp/ drwxr-xr-x 13 root root 1024 2013-08-05 11:14 usr/ drwxr-xr-x 15 root root 1024 2013-08-05 11:19 var/ lrwxrwxrwx 1 root root 13 2013-08-05 11:20 wfs -> /etc/wyseroot/ lrwxrwxrwx 1 root root 13 2013-08-05 11:19 wyse -> /etc/wyseroot/
files in /boot/:
admin@LWT008064aa7d6c:/boot$ ll total 7549 drwxr-xr-x 2 root root 1024 2013-08-05 11:08 ./ drwxr-xr-x 24 root root 1024 2013-08-05 12:02 ../ -rw-r--r-- 1 root root 281282 2011-12-14 08:31 abi-2.6.32-217-hedley -rw-r--r-- 1 root root 68229 2011-12-14 08:31 config-2.6.32-217-hedley lrwxrwxrwx 1 root root 28 2013-08-05 11:07 initrd.img -> initrd.img-2.6.32-217-hedley -rw-r--r-- 1 root root 2033754 2013-08-05 11:08 initrd.img-2.6.32-217-hedley -rw-r--r-- 1 root root 1639534 2011-12-14 08:31 System.map-2.6.32-217-hedley lrwxrwxrwx 1 root root 25 2013-08-05 11:07 vmlinuz -> vmlinuz-2.6.32-217-hedley -rw-r--r-- 1 root root 3665368 2011-12-14 08:31 vmlinuz-2.6.32-217-hedley
Searching online Dell / Wyse seem to use some remote management software to administer these devices so I'm not sure if the bootloader can be unlocked. However maybe someone else has an idea how to run Debian on this system?
Thanks,
Koen
-----
moderator edit: changed thread title to make it easier for users to find in searching.
Edited 1 time(s). Last edit at 09/01/2018 05:27PM by bodhi.
|
Koen
Re: Dell Wyse T10 / T50 July 21, 2018 10:24AM |
Hi,
activating ssh doesn't work since the standard config is not correct so I need to have a look at that first. I've also found some more recent firmware at the following location:
https://appservices.wyse.com/pages/serviceandsupport/support/dlOraFW.asp?which=158&model=T50%20MR/3030(Wyse%20Linux)
This has some fixes for security issues but seems to be based on the same old version of ubuntu so I'm not sure if it is worth trying to upgrade.
Koen
activating ssh doesn't work since the standard config is not correct so I need to have a look at that first. I've also found some more recent firmware at the following location:
https://appservices.wyse.com/pages/serviceandsupport/support/dlOraFW.asp?which=158&model=T50%20MR/3030(Wyse%20Linux)
This has some fixes for security issues but seems to be based on the same old version of ubuntu so I'm not sure if it is worth trying to upgrade.
Koen
|
Re: Dell Wyse T10 / T50 July 21, 2018 05:20PM |
Admin Registered: 13 years ago Posts: 19,224 |
Koen,
It is not at all similar to the T5325 which has Kirkwood SoC (ARMV5). It seems this box has Marvell Dove SoC, which is ARMV7. Similar to other ARMV7 boxes that I supported:
https://forum.doozan.com/read.php?2,32146
It is possible to run Debian on this box, with some more works. The Dove is already mainlined, so it would not be difficult.
I don't think it is locked down, given it is an old box running a very old kernel. However, we need to see u-boot log to know exactly which chip is this (looks like Dove, but could be Armada).
Even if it is locked down, you should be able to see u-boot log with serial console. So you should make sure your serial console works and get the log.
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
Edited 2 time(s). Last edit at 07/21/2018 06:25PM by bodhi.
It is not at all similar to the T5325 which has Kirkwood SoC (ARMV5). It seems this box has Marvell Dove SoC, which is ARMV7. Similar to other ARMV7 boxes that I supported:
https://forum.doozan.com/read.php?2,32146
It is possible to run Debian on this box, with some more works. The Dove is already mainlined, so it would not be difficult.
I don't think it is locked down, given it is an old box running a very old kernel. However, we need to see u-boot log to know exactly which chip is this (looks like Dove, but could be Armada).
Even if it is locked down, you should be able to see u-boot log with serial console. So you should make sure your serial console works and get the log.
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
Edited 2 time(s). Last edit at 07/21/2018 06:25PM by bodhi.
|
Re: Dell Wyse T10 / T50 July 21, 2018 08:32PM |
Admin Registered: 13 years ago Posts: 19,224 |
Looks like it is Armada 510. Same as HP Thin Client T5335z.
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
Edited 2 time(s). Last edit at 07/21/2018 10:59PM by bodhi.
Quote
Dove family (application processor)
-----------------------------------
Flavors:
88AP510 a.k.a Armada 510
Product Brief : http://www.marvell.com/application-processors/armada-500/assets/Marvell_Armada510_SoC.pdf
Hardware Spec : http://www.marvell.com/application-processors/armada-500/assets/Armada-510-Hardware-Spec.pdf
Functional Spec : http://www.marvell.com/application-processors/armada-500/assets/Armada-510-Functional-Spec.pdf
Homepage: http://www.marvell.com/application-processors/armada-500/
Core: ARMv7 compatible
Directory: arch/arm/mach-mvebu (DT enabled platforms)
arch/arm/mach-dove (non-DT enabled platforms)
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
Edited 2 time(s). Last edit at 07/21/2018 10:59PM by bodhi.
|
Koen
Re: Dell Wyse T10 / T50 July 22, 2018 09:02AM |
Hi,
This is the output from serial when booting. It doesn't how any u-boot type info but immediately starts uncompressing the kernel. So I'm not sure if this board uses u-boot as bootloader.
Koen
This is the output from serial when booting. It doesn't how any u-boot type info but immediately starts uncompressing the kernel. So I'm not sure if this board uses u-boot as bootloader.
Koen
koen@koen-ThinkPad-X220:~$ picocom -b 115200 /dev/ttyUSB0
picocom v2.2
port is : /dev/ttyUSB0
flowcontrol : none
baudrate is : 115200
parity is : none
databits are : 8
stopbits are : 1
escape is : C-a
local echo is : no
noinit is : no
noreset is : no
nolock is : no
send_cmd is : sz -vv
receive_cmd is : rz -vv -E
imap is :
omap is :
emap is : crcrlf,delbs,
Type [C-a] [C-h] to see available commands
Terminal ready
Uncompressing Linux........................................................................................................................................................................................................................................ done, booting the kernel.
|
Koen
Re: Dell Wyse T10 / T50 July 22, 2018 09:30AM |
Hi,
I've used the Dell Wyse software to generate a bootable USB stick for firmware upgrades. This stick can be booted by inserting it in the device and pressing the 'p' key while the device is being powered on. It allows you to either upgrade the firmware or extract a copy of the current firmware. So I decided to extract a copy of the current firmware to USB.
The following file listing shows the contents of the USB stick:
It seems that the firmware upgrade / extract tool is just a minimal linux system. The folder Ubuntu_TX0_1024_0 contains the extracted firmware images of the box. Its contents is as follows:
The mbr.img and cmos.img files make it look like the bios setup of a normal PC however there also is a bootLoader.img file. One of the small 8 pin chips on the board is marked with a sticker 'BIOS:W7.0_217'
So I'm not sure if this setup uses u-boot like most of the other devices that have been described on this forum .
Koen
I've used the Dell Wyse software to generate a bootable USB stick for firmware upgrades. This stick can be booted by inserting it in the device and pressing the 'p' key while the device is being powered on. It allows you to either upgrade the firmware or extract a copy of the current firmware. So I decided to extract a copy of the current firmware to USB.
The following file listing shows the contents of the USB stick:
koen@koen-ThinkPad-X220:~/Documents/DellWyse/USBstickCopyOriginalFiles$ ll total 64 drwxrwxr-x 8 koen koen 4096 Jul 22 15:12 ./ drwxrwxr-x 4 koen koen 4096 Jul 21 22:20 ../ -rw------- 1 koen koen 59 Jul 22 15:12 .directory drwxrwxr-x 2 koen koen 4096 Jul 21 20:20 grub/ drwxrwxr-x 3 koen koen 4096 Jul 21 20:20 initrd/ drwxrwxr-x 3 koen koen 4096 Jul 21 20:21 kernel/ -rw-r--r-- 1 koen koen 18758 Jul 21 19:28 kernelmsg.log -rw-r--r-- 1 koen koen 1120 Dec 19 2014 OS_PLATFORM drwxrwxr-x 2 koen koen 4096 Jul 21 20:21 template/ drwxrwxr-x 3 koen koen 4096 Jul 21 20:19 Ubuntu_TX0_1024_0/ -rw-r--r-- 1 koen koen 497 May 27 2014 wloader.cfg drwxrwxr-x 2 koen koen 4096 Jul 21 20:22 xmlfiles/
It seems that the firmware upgrade / extract tool is just a minimal linux system. The folder Ubuntu_TX0_1024_0 contains the extracted firmware images of the box. Its contents is as follows:
koen@koen-ThinkPad-X220:~/Documents/DellWyse/USBstickCopyOriginalFiles/Ubuntu_TX0_1024_0/Ubuntu_TX0_1024_0/Ubuntu_TX0_1024_0$ ll total 157396 drwxrwxr-x 2 koen koen 4096 Jul 22 15:06 ./ drwxrwxr-x 3 koen koen 4096 Jul 21 19:28 ../ -rw-r--r-- 1 koen koen 625834 Jul 21 19:30 bootLoader.img -rw-r--r-- 1 koen koen 630 Jul 21 19:30 cmos.img -rw-r--r-- 1 koen koen 5658 Jul 21 20:19 commandsXml.xml -rw------- 1 koen koen 59 Jul 22 15:06 .directory -rw-r--r-- 1 koen koen 149 Jul 21 19:30 mbr.img -rw-r--r-- 1 koen koen 26406 Jul 21 20:19 Merlin.log -rw-r--r-- 1 koen koen 3756526 Jul 21 19:30 par1.img -rw-r--r-- 1 koen koen 156728752 Jul 21 20:19 par3.img
The mbr.img and cmos.img files make it look like the bios setup of a normal PC however there also is a bootLoader.img file. One of the small 8 pin chips on the board is marked with a sticker 'BIOS:W7.0_217'
So I'm not sure if this setup uses u-boot like most of the other devices that have been described on this forum .
Koen
|
Koen
Re: Dell Wyse T10 / T50 July 22, 2018 10:13AM |
I've managed to get root access and SSH working so that makes it easier to interact with the box without having to keep hooking up a monitor, mouse and keyboard. In the root directory there is a script called 'prepull.sh' which I guess is run when the firmware gets extracted to USB. The script looks as folows:
It seems that a list of different boot devices is stored in spi. The output of /usr/sbin/spi-r is as follows:
This makes me think that it may be possible to change the boot order of the devices in spi such that it starts with USB at 0 and goes to HardDisk afterwards.
A way to test this would be to create a USB stick with a copy of the files of the internal memory and try to boot it. However I'm not sure how you would tell which of the devices has been used to boot once the system is running.
If that approach works you could in theory make a USB stick with a recent version of Debian. Although there still is the issue of how to create a kernel and DTB file for this box. Is it possible to extract that information from the current system?
Koen
root@LWT008064aa7d6c:/# cat prepull.sh
#!/bin/bash
#
# prepull.sh
# This script is to clear ethernet device(s) for Network Manager
#exec &>/tmp/prepull-$1.$$
# WDM is set as the first boot option when imaging for Triton using Hagent
# After that, either pull or push, HardDisk is set as the first boot option
# Here is to check and set HardDisk as the first boot option for postpush
bootDevices=$( $1/usr/sbin/spi-r -d )
bootDevRequest="name=HardDisk"
bootDevice=
if echo $bootDevices | grep -q $bootDevRequest ; then
bootDevice=${bootDevices%% $bootDevRequest*}
bootDevice=${bootDevice##* }
fi
if [ ! -z "$bootDevice" ] ; then
if [ $bootDevice -gt 0 ] ; then
$1/usr/sbin/spi-w -d 1 $bootDevice
fi
fi
touch $1/etc/wyse_first_init
rm -f $1/etc/udev/rules.d/70-persistent-net.rules
sync
exit 0
It seems that a list of different boot devices is stored in spi. The output of /usr/sbin/spi-r is as follows:
root@LWT008064aa7d6c:/# /usr/sbin/spi-r -d device 0 name=HardDisk device 0 URL= device 0 url_check=00000000 device 0 net=00000000 device 1 name=Recovery device 1 URL= device 1 url_check=00000000 device 1 net=00000000 device 2 name=Network device 2 URL= device 2 url_check=00000001 device 2 net=00000001 device 3 name=USB device 3 URL= device 3 url_check=00000000 device 3 net=00000000 device 4 name=Wyse WDM device 4 URL= device 4 url_check=00000000 device 4 net=00000001 device 5 name= device 5 URL= device 5 url_check=00000000 device 5 net=00000000 device 6 name= device 6 URL= device 6 url_check=00000000 device 6 net=00000000 device 7 name= device 7 URL= device 7 url_check=00000000 device 7 net=00000000 device 8 name= device 8 URL= device 8 url_check=00000000 device 8 net=00000000 device 9 name= device 9 URL= device 9 url_check=00000000 device 9 net=00000000
This makes me think that it may be possible to change the boot order of the devices in spi such that it starts with USB at 0 and goes to HardDisk afterwards.
A way to test this would be to create a USB stick with a copy of the files of the internal memory and try to boot it. However I'm not sure how you would tell which of the devices has been used to boot once the system is running.
If that approach works you could in theory make a USB stick with a recent version of Debian. Although there still is the issue of how to create a kernel and DTB file for this box. Is it possible to extract that information from the current system?
Koen
|
Koen
Re: Dell Wyse T10 / T50 July 22, 2018 02:07PM |
The spi-r and spi-w commands seem to allow you to read and modify the values which are stored in spi. These values seem to get passed onto the bootloader to actually start the device. I'm not sure what bootloader is used but it may not matter if the values in spi can be modified to allow booting from USB.
Dump of the current values in spi:
Similar for spi-w
The last bit of the description in spi-w -h indicates that it is indeed possible to adjust the boot order such that the USB drive is used as the primary boot device.
Sorry if these posts sound like I'm talking to myself. I'm just trying to keep a record of things that I have found out so more experienced embedded linux people can give feedback / tips.
Koen
root@LWT008064aa7d6c:/mnt/tmp# spi-r -h
This spi-r ver 1.12
Supports WLoader version (>=4.3) for 'string version number'
Supports WLoader version (>=4.4) for 'autopower'
Supports WLoader version (>=4.4) for showing all boot devices
supports WLoader (>= version 205) for 'disable_wol' and 'disable_wou'
supports WLoader (>= version 211_5) for reading data originally on eeprom moved into spi
supports WLoader (>= version 215) for accessing 4MB SPI flashes(MXIC/Winbond/PCT) and 8MB SPI flashes (MXIC/Winbond)
supports an option '-I' to show SPI flash ID and size
supports p-key password protection
added option -z to print out a list of supported SPI chips
added support for Winbond-DW and Micron Numonyx SPI chips
-----------------------------------------
Usage: spi-r [-vsmoctlLpniIkrwOduUhMNWSKCRgGH] [x]
-v | --version: read WLoader version number
-s | --size: read WLoader size
-m | --mode: read WLoader mode
-o | --confoverride: read WLoader configuration override state
-c | --confname: read WLoader configuration file name
-t | --autopower: read autopower setting
-l | --disable_wol:read disable_wol
-L | --disable_wou:read disable_wou
-p | --pathname: read WLoader configuration file path name
-n | --imagename: read image name
-i | --initrdname: read initrd name
-I | --id: read SPI flash ID and size
-k | --kernparam: read kernel parameters
-r | --recoverparam: read recovery parameters
-w | --password: read password
-O | --pkeypassword:read pkey password
-d x| --devices: read boot devices, x is optional
when no x: read all boot devices
when x=[0...9] read one of devices indexed
-u | --dump: dump WLoader dove_bios data structure
-U | --Dump: dump WLoader dove_bios data map
-P | --copy: copy 64k WLoader Configuration binary
and 256kb WTOS area to a file excluding ee_data
or copy num_blocks of data starting from start_block
to a file excluding ee_data if covering it
Ex: 'sudo spi-r -P path_file_name'
where default start_block=59 or 64+59 for 8MB SPI flash, default num_block=5, block is in 64kb
'sudo spi-r -P path_file_name 59 5'
where start_block=59, num_block=5, block is in 64kb
-z | --list: list supported SPI chips
The following options are for accessing data originally on EEPROM
-M | --mac: read eeprom mac[6] binary
-N | --length: read eeprom length binary
-W | --hwrevision: read eeprom HWRevision[4] ASCII
-S | --sn: read eeprom S/N[11] ASCII
-K | --securitykey: read eeprom SecurityKey[4] binary
-C | --crc: read eeprom CRC binary
-R | --readyforimage:read eeprom ReadForImage binary
-g | --dumping: dump eeprom dove_eeprom data structure
-G | --Dumping: dump eeprom data memory map
-h | --help: print out this usage
Dump of the current values in spi:
root@LWT008064aa7d6c:/mnt/tmp# spi-r -u
magic number=34717134
version= 7.0_218
size=00004000
mode=00000000
configuration Override=00000001
autopower=00000000
disable_wol=00000000
disable_wou=00000000
chksum=00002a64
configuration file Name=wloader.cfg
path Name=./;
image Name=uImage;
initrd Name=uInitrd;
kernel parameters=root=/dev/sda3 pm_disable usb0Mode=host usb1Mode=host video=dovefb:lcd0:1024x768-32@60,lcd1:1024x768-32@60 clcd.lcd0_enable=1 clcd.lcd1_enable=1 clcd.lcd0_clk=3 clcd.lcd1_clk=1 splash no_console_suspend kb3310_disable=1 cpufreq_disable=1 vmalloc=384M quiet
recovery parameters=rootdelay=5 root=/dev/ram0 rw ramdisk_size=136314880 usb0Mode=host usb1Mode=host video=dovefb:lcd0:1024x600-16@60-edid,lcd1:1024x768-16@60-edid clcd.lcd0_enable=1 clcd.lcd1_enable=1 pm_disable titan
password=Fireport
pkey password=Fireport
device 0 name=HardDisk
device 0 URL=
device 0 url_check=00000000
device 0 net=00000000
device 1 name=Recovery
device 1 URL=
device 1 url_check=00000000
device 1 net=00000000
device 2 name=Network
device 2 URL=
device 2 url_check=00000001
device 2 net=00000001
device 3 name=USB
device 3 URL=
device 3 url_check=00000000
device 3 net=00000000
device 4 name=Wyse WDM
device 4 URL=
device 4 url_check=00000000
device 4 net=00000001
device 5 name=
device 5 URL=
device 5 url_check=00000000
device 5 net=00000000
device 6 name=
device 6 URL=
device 6 url_check=00000000
device 6 net=00000000
device 7 name=
device 7 URL=
device 7 url_check=00000000
device 7 net=00000000
device 8 name=
device 8 URL=
device 8 url_check=00000000
device 8 net=00000000
device 9 name=
device 9 URL=
device 9 url_check=00000000
device 9 net=00000000
Similar for spi-w
root@LWT008064aa7d6c:/mnt/tmp# spi-w -h
This spi-w ver 1.13
1) moved what was done in ver 1.6 'dumping 64kb WLoader Configuration area
excluding eeprom data
2) added supporting copying a file into 64kb WLoader Configuration area and 256kb
WTOS area without affecting ee_data
supports WLoader (>= version 4.3) for 'string version number'
supports WLoader (>= version 4.4) for 'autopower'
supports INI Bootorder request while keeping the boot order of rest devices
extended Ver 1.2 for allowing multiple devices in bootOrder request like 'HUWNR'
(see option -d explanations for details)
supports WLoader (>= version 205) for 'disable_wol' and 'disable_wou'
supports WLoader (>= version 211_5) for accessing data originally on eeprom moved into spi
supports WLoader (>= version 215) for accessing 4MB SPI flashes(MXIC/Winbond/PCT) and 8MB SPI flashes (MXIC/Winbond)
supports p-key password protection
added option -z to print out a list of supported SPI chips
added support for Winbond-DW and Micron Numonyx SPI chips
added checksum before and after writing to SPI using -P option and removed showing checksum for WLoader Configure Area
-----------------------------------------
Usage: spi-w [-vsmotlLcpnikrwOduUPh] [x]data
-v data | --version: write WLoader version number
-s data | --size: write WLoader size
-m data | --mode: write WLoader mode
-o data | --confoverride: write WLoader configuration override state
-t data | --autopower: write autopower
-l data | --disable_wol: write disable_wol
-L data | --disable_wou: write disable_wou
-c data | --confname: write WLoader configuration file name
-p data | --pathname: write WLoader configuration file path name
-n data | --imagename: write image name
-i data | --initrdname: write initrd name
-k data | --kernparam: write kernel parameters
-r data | --recoverparam: write recovery parameters
-w data | --password: write password
-O data | --pkeypassword:write pkey password
-d data | --devices: write boot devices, see description below
-u | --dump: dump WLoader dove_bios data structure
-U | --Dump: dump WLoader dove_bios data map
-P | --copy: copy a binary file into 64kb WLoader Configuration
and into 256kb WTOS area without affecting ee_data
or copy a binary file into start_block of SPI flash for
num_block of data (or file size of data if num_block is
not specified) without affecting ee_data
Ex: 'sudo spi-w -P path_file_name'
where default start_block=59 or 64+59 for 8MB SPI flash, default num_block=5, block is in 64kb
Ex: 'sudo spi-w -P path_file_name 0'
where start_block=0, num_block is resolved from file size
Ex: 'sudo spi-w -P path_file_name 59 5'
where start_block=59, num_block=5, block is in 64kb
Note: the sum of 'start_block' and 'num_block'
should be less than or equal to 64 or 128 for 8MB SPI flash
-z | --list: list supported SPI chips
-----------------------------------------------------------------
For option -d there are two kinds of operations:
Method 1 (mainly for prioritizing the boot devices)
Move the designated boot devices (index numbers) up to the highest level
while keeping the order of rest boot devices
Ex: Assuming current boot devices have order: H(0), U(1), W(2), N(3), R(4)
Typing 'spi-w -d 1 10423' (3 parameters) moves 5 boot devices up as
U, H, R, W, N (USB, Harddisk, Recovery, Wyse WDM, Network)
Typing 'spi-w -d 1 10' (3 parameters) moves 2 devices specified up and
leave rest devices untouched behind the specified boot devices:
U, H, W, N, R (USB, Harddisk, Wyse WDM, Network, Recovery)
Method 2 (mainly for modifying/adding/deleting a boot device)
Write all new fields for boot device[index] (7 parameters)
Type 'spi-w -d 2 device_index device_name URL url_check(integer) net(integer)'
-h | --help: print out this usage
The last bit of the description in spi-w -h indicates that it is indeed possible to adjust the boot order such that the USB drive is used as the primary boot device.
Sorry if these posts sound like I'm talking to myself. I'm just trying to keep a record of things that I have found out so more experienced embedded linux people can give feedback / tips.
Koen
|
Re: Dell Wyse T10 / T50 July 22, 2018 03:29PM |
Admin Registered: 13 years ago Posts: 19,224 |
Koen,
There are quite a bit of info to digest! I'm busy right now, will take a look at your posts and fill in my observation in this post.
- This is an ARM box so there should be no BIOS.
- Apparently serial console is working. I need to recall what key sequence that might work when the secure boot is implemented.
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
There are quite a bit of info to digest! I'm busy right now, will take a look at your posts and fill in my observation in this post.
- This is an ARM box so there should be no BIOS.
- Apparently serial console is working. I need to recall what key sequence that might work when the secure boot is implemented.
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
|
Koen
Re: Dell Wyse T10 / T50 July 22, 2018 03:36PM |
The root file system is mounted on /dev/sda3 however blkid shows other partitions as well:
So I've decided to mount them and see what is in those partitions:
contents of sda1:
Serial console didn't show an u-boot prompt but it still seems to use u-boot as bootloader
/dev/sda2 seems to be a storage partition used during firmware extraction / upgrades.
root@LWT008064aa7d6c:/# blkid /dev/sda1: SEC_TYPE="msdos" UUID="2FA8-8ED1" TYPE="vfat" /dev/sda2: SEC_TYPE="msdos" UUID="8A92-5CDA" TYPE="vfat" /dev/sda3: UUID="e28d24f3-3f4e-45e2-9388-a2c7dea2f7bf" TYPE="ext3"
So I've decided to mount them and see what is in those partitions:
root@LWT008064aa7d6c:/# mount /dev/sda1 /mnt/temp1 root@LWT008064aa7d6c:/# mount /dev/sda2 /mnt/temp2
contents of sda1:
root@LWT008064aa7d6c:/mnt/temp1# ll total 7178 drwxr-xr-x 2 root root 16384 1970-01-01 01:00 ./ drwxr-xr-x 5 root root 1024 2018-07-22 21:08 ../ -rwxr-xr-x 1 root root 211 2015-07-06 09:06 boot-normal.scr* -rwxr-xr-x 1 root root 211 2015-07-06 09:05 boot-normal.scr.bak* -rwxr-xr-x 1 root root 3665432 2015-07-06 09:06 uImage* -rwxr-xr-x 1 root root 3665432 2015-07-06 09:05 uImage.bak*
Serial console didn't show an u-boot prompt but it still seems to use u-boot as bootloader
root@LWT008064aa7d6c:/mnt/temp1# file uImage uImage: u-boot/PPCBoot image
root@LWT008064aa7d6c:/mnt/temp1# cat boot-normal.scr 'V���U�E��Lx�Normal boot script�echo Starting Ubuntu... fatload ide 0:1 0x200000 /uImage setenv bootargs pm_disable root=/dev/sda3 vmalloc=384M mimas quiet bootm 0x200000
/dev/sda2 seems to be a storage partition used during firmware extraction / upgrades.
root@LWT008064aa7d6c:/mnt/temp2# ll total 21777 drwxr-xr-x 3 root root 16384 1970-01-01 01:00 ./ drwxr-xr-x 5 root root 1024 2018-07-22 21:08 ../ drwxr-xr-x 2 root root 4096 2018-07-21 20:38 Image/ -rwxr-xr-x 1 root root 79 2018-07-21 20:38 ImageStatus.log* -rwxr-xr-x 1 root root 19019 2018-07-21 20:34 kernelmsg.log* -rwxr-xr-x 1 root root 3072920 2018-07-21 20:34 uImage* -rwxr-xr-x 1 root root 19177196 2018-07-21 20:34 uInitrd*
root@LWT008064aa7d6c:/mnt/temp2/Image# ll total 163064 drwxr-xr-x 2 root root 4096 2018-07-21 20:38 ./ drwxr-xr-x 3 root root 16384 1970-01-01 01:00 ../ -rwxr-xr-x 1 root root 625834 2018-07-21 20:33 bootLoader.img* -rwxr-xr-x 1 root root 651 2018-07-21 20:33 cmos.img* -rwxr-xr-x 1 root root 3362 2018-07-21 20:34 Image.rsp* -rwxr-xr-x 1 root root 148 2018-07-21 20:33 mbr.img* -rwxr-xr-x 1 root root 50884 2018-07-21 20:38 Merlin.log* -rwxr-xr-x 1 root root 3756533 2018-07-21 20:33 par1.img* -rwxr-xr-x 1 root root 162501707 2018-07-21 20:34 par3.img*
|
Koen
Re: Dell Wyse T10 / T50 July 22, 2018 04:37PM |
OK cool. In the mean time I've changed the boot order in spi to start with USB. This has worked since it now starts the firmware upgrade USB stick without pressing the p key. When I remove the USB stick and reboot it still boots to the normal kernel on the harddrive / internal memory.
Koen
Koen
|
Koen
Re: Dell Wyse T10 / T50 July 22, 2018 05:13PM |
/dev/sda1 and /dev/sda2 are present but do not get mounted during normal operation.
/dev/sda1 is where the uboot image is stored:
/dev/sda2 is used as storage during firmware extraction / upgrade
/dev/sda1 is where the uboot image is stored:
root@LWT008064aa7d6c:/mnt/temp1# ll total 7178 drwxr-xr-x 2 root root 16384 Jan 1 1970 ./ drwxr-xr-x 4 root root 1024 Jul 22 23:04 ../ -rwxr-xr-x 1 root root 211 Jul 6 2015 boot-normal.scr* -rwxr-xr-x 1 root root 211 Jul 6 2015 boot-normal.scr.bak* -rwxr-xr-x 1 root root 3665432 Jul 6 2015 uImage* -rwxr-xr-x 1 root root 3665432 Jul 6 2015 uImage.bak*
root@LWT008064aa7d6c:/mnt/temp1# cat boot-normal.scr 'V���U�E��Lx�Normal boot script�echo Starting Ubuntu... fatload ide 0:1 0x200000 /uImage setenv bootargs pm_disable root=/dev/sda3 vmalloc=384M mimas quiet bootm 0x200000
root@LWT008064aa7d6c:/mnt/temp1# file uImage uImage: u-boot/PPCBoot image
/dev/sda2 is used as storage during firmware extraction / upgrade
root@LWT008064aa7d6c:/mnt/temp2# ll total 21777 drwxr-xr-x 3 root root 16384 Jan 1 1970 ./ drwxr-xr-x 4 root root 1024 Jul 22 23:04 ../ drwxr-xr-x 2 root root 4096 Jul 21 20:38 Image/ -rwxr-xr-x 1 root root 79 Jul 21 20:38 ImageStatus.log* -rwxr-xr-x 1 root root 19019 Jul 21 20:34 kernelmsg.log* -rwxr-xr-x 1 root root 3072920 Jul 21 20:34 uImage* -rwxr-xr-x 1 root root 19177196 Jul 21 20:34 uInitrd*
root@LWT008064aa7d6c:/mnt/temp2/Image# ll total 163064 drwxr-xr-x 2 root root 4096 Jul 21 20:38 ./ drwxr-xr-x 3 root root 16384 Jan 1 1970 ../ -rwxr-xr-x 1 root root 3362 Jul 21 20:34 Image.rsp* -rwxr-xr-x 1 root root 50884 Jul 21 20:38 Merlin.log* -rwxr-xr-x 1 root root 625834 Jul 21 20:33 bootLoader.img* -rwxr-xr-x 1 root root 651 Jul 21 20:33 cmos.img* -rwxr-xr-x 1 root root 148 Jul 21 20:33 mbr.img* -rwxr-xr-x 1 root root 3756533 Jul 21 20:33 par1.img* -rwxr-xr-x 1 root root 162501707 Jul 21 20:34 par3.img*
|
Re: Dell Wyse T10 / T50 July 22, 2018 05:53PM |
Admin Registered: 13 years ago Posts: 19,224 |
Ok. It is very promising. However, boot-normal.scr is not what used when the kernel was actually booted.
After booted, can you SSH in? if you can then get:
- The content of the USB drive rootfs, is it the same as the SATA rootfs.
- Output of
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
root@LWT008064aa7d6c:/mnt/temp1# cat boot-normal.scr fatload ide 0:1 0x200000 /uImage setenv bootargs pm_disable root=/dev/sda3 vmalloc=384M mimas quiet bootm 0x200000
Kernel command line: root=/dev/sda3 pm_disable usb0Mode=host usb1Mode=host video=dovefb:lcd0:1024x768-32@60,lcd1:1024x768-32@60 clcd.lcd0_enable=1 clcd.lcd1_enable=1 clcd.lcd0_clk=3 clcd.lcd1_clk=1 splash no_console_suspend kb3310_disable=1 cpufreq_disable=1 vmalloc=384M quiet
Quote
OK cool. In the mean time I've changed the boot order in spi to start with USB. This has worked since it now starts the firmware upgrade USB stick without pressing the p key. When I remove the USB stick and reboot it still boots to the normal kernel on the harddrive / internal memory.
After booted, can you SSH in? if you can then get:
- The content of the USB drive rootfs, is it the same as the SATA rootfs.
- Output of
dmesg mount cat /proc/mtd cat /etc/fw_env.config fw_printenv
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
|
Koen
Re: Dell Wyse T10 / T50 July 22, 2018 06:12PM |
I can't ssh to the box when it is running the minimal kernel from USB stick unfortunately. I can't even ping the device so I assume that the system to do firmware upgrades does not have networking enabled / configured.
I'm not sure if this is useful but this is the output when the system is booted normally from the internal memory.
I'm not sure if this is useful but this is the output when the system is booted normally from the internal memory.
root@LWT008064aa7d6c:~# cat /proc/mtd dev: size erasesize name root@LWT008064aa7d6c:~# cat /etc/fw_env.config # MTD device offset size erase_size /dev/mtd0 0xc0000 0x10000 0x10000
|
Koen
Re: Dell Wyse T10 / T50 July 22, 2018 06:28PM |
The standard operating system doesn't have the fw_printenv command. However it does contain the command fconfig which seems to be related to redboot. Could it be that the system uses the redboot bootloader instead of uboot?
root@LWT008064aa7d6c:/mnt/temp1# fconfig -h Read, write or list Redboot configuration usage: fconfig [-r|-w|-l] -d dev -o offset -n nickname -x value 'dev' may be a char device, block device or a file 'offset' is the offset in bytes on the device Supported types: - empty - bool - int - string - script - ip - esa - netport Additional switches: -v: Verbose mode, use more to increase verbosity -s: Silent mode, absolutely no messages printed Low verbosity messages are printed. Read, write or list Redboot configuration usage: fconfig [-r|-w|-l] -d dev -o offset -n nickname -x value 'dev' may be a char device, block device or a file 'offset' is the offset in bytes on the device Supported types: - empty - bool - int - string - script - ip - esa - netport Additional switches: -v: Verbose mode, use more to increase verbosity -s: Silent mode, absolutely no messages printed
|
Re: Dell Wyse T10 / T50 July 22, 2018 06:28PM |
Admin Registered: 13 years ago Posts: 19,224 |
> I'm not sure if this is useful but this is the
> output when the system is booted normally from the
> internal memory.
>
>
It means u-boot is on mtd0. But the kernel did not enumerate the SPI mtd parttion(s).
The next step:
- look for why the bootargs is different from the boot_normal.scr and the actual bootargs. IOW, are the actual parameters hard coded in the kernel or somehow was changed on top of the boot script.
- Change boot script to make it slightly different, such as
Rebuild boot script, copy it to /dev/sda1 (is where the uboot image is stored). I'll be back late this evening PST to post this command if you have not found out how to do it.
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
> output when the system is booted normally from the
> internal memory.
>
>
> root@LWT008064aa7d6c:~# cat /proc/mtd > dev: size erasesize name > root@LWT008064aa7d6c:~# cat /etc/fw_env.config > # MTD device offset size erase_size > /dev/mtd0 0xc0000 0x10000 0x10000 >
It means u-boot is on mtd0. But the kernel did not enumerate the SPI mtd parttion(s).
The next step:
- look for why the bootargs is different from the boot_normal.scr and the actual bootargs. IOW, are the actual parameters hard coded in the kernel or somehow was changed on top of the boot script.
- Change boot script to make it slightly different, such as
setenv bootargs pm_disable root=/dev/sda3 vmalloc=384M mimas quiet rootday=10
Rebuild boot script, copy it to /dev/sda1 (is where the uboot image is stored). I'll be back late this evening PST to post this command if you have not found out how to do it.
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
|
Re: Dell Wyse T10 / T50 July 22, 2018 06:29PM |
Admin Registered: 13 years ago Posts: 19,224 |
Quote
The standard operating system doesn't have the fw_printenv command. However it does contain the command fconfig which seems to be related to redboot. Could it be that the system uses the redboot bootloader instead of uboot?
It could be. But not likely.
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
Edited 1 time(s). Last edit at 07/22/2018 06:30PM by bodhi.
|
Re: Dell Wyse T10 / T50 July 23, 2018 12:56AM |
Admin Registered: 13 years ago Posts: 19,224 |
The next step:
- look for why the bootargs is different from the boot_normal.scr and the actual bootargs. IOW, are the actual parameters hard coded in the kernel or somehow was changed on top of the boot script.
- Change boot script to make it slightly different
cat boot-normal.txt
Rebuild boot script:
Save /dev/sda1/boot-normal.scr and replace it with the new boot-normal.scr. Reboot and observe the new bootargs, see if it successful taken by the kernel.
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
- look for why the bootargs is different from the boot_normal.scr and the actual bootargs. IOW, are the actual parameters hard coded in the kernel or somehow was changed on top of the boot script.
- Change boot script to make it slightly different
cat boot-normal.txt
fatload ide 0:1 0x200000 /uImage setenv bootargs pm_disable root=/dev/sda3 vmalloc=384M mimas quiet rootday=10 bootm 0x200000
Rebuild boot script:
mkimage -A ARM -T script -C none -n 'boot-normal.scr' -d boot-normal.txt
Save /dev/sda1/boot-normal.scr and replace it with the new boot-normal.scr. Reboot and observe the new bootargs, see if it successful taken by the kernel.
cat /proc/cmdline
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
|
Koen
Re: Dell Wyse T10 / T50 July 23, 2018 07:37AM |
Hi Bodhi,
I'm not sure if it is needed to do these steps. It looks to me that the bootargs are stored in spi.
and modifying them can be done using the spi-w command but I'm happy to do the steps you suggest when I'm back home this evening.
Koen
I'm not sure if it is needed to do these steps. It looks to me that the bootargs are stored in spi.
root@LWT008064aa7d6c:/# spi-r -k kernel parameters=root=/dev/sda3 pm_disable usb0Mode=host usb1Mode=host video=dovefb:lcd0:1024x768-32@60,lcd1:1024x768-32@60 clcd.lcd0_enable=1 clcd.lcd1_enable=1 clcd.lcd0_clk=3 clcd.lcd1_clk=1 splash no_console_suspend kb3310_disable=1 cpufreq_disable=1 vmalloc=384M quiet
and modifying them can be done using the spi-w command but I'm happy to do the steps you suggest when I'm back home this evening.
Koen
|
Re: Dell Wyse T10 / T50 July 23, 2018 06:07PM |
Admin Registered: 13 years ago Posts: 19,224 |
Koen,
So we know where the bootargs was taken from.
Now we need to see the boot sequence to make sure we know how to boot the Debian USB. Information you posted so far seems to point to the boot-normal.scr as a way to change the boot sequence.
So that's important to try to make sure you can use boot-normal.scr to script the USB boot. Changing it in some ways that you can see the change takes effect (it seems bootargs was overwritten, so different envs might be needed)
Create the new Debian USB rootfs
You can try booting with Debian-4.12.4-mvebu-tld-1-rootfs-bodhi.tar.bz2 in the release thread:
https://forum.doozan.com/read.php?2,32146
Try this DTB as it is the most likely to boot. This needs to be appended to uImage.
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
Edited 1 time(s). Last edit at 07/23/2018 06:19PM by bodhi.
Quote
- look for why the bootargs is different from the boot_normal.scr and the actual bootargs. IOW, are the actual parameters hard coded in the kernel or somehow was changed on top of the boot script.
So we know where the bootargs was taken from.
Now we need to see the boot sequence to make sure we know how to boot the Debian USB. Information you posted so far seems to point to the boot-normal.scr as a way to change the boot sequence.
So that's important to try to make sure you can use boot-normal.scr to script the USB boot. Changing it in some ways that you can see the change takes effect (it seems bootargs was overwritten, so different envs might be needed)
Create the new Debian USB rootfs
You can try booting with Debian-4.12.4-mvebu-tld-1-rootfs-bodhi.tar.bz2 in the release thread:
https://forum.doozan.com/read.php?2,32146
Try this DTB as it is the most likely to boot. This needs to be appended to uImage.
-rw-r--r-- 1 root root 13635 May 4 22:32 dove-dove-db.dtb
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
Edited 1 time(s). Last edit at 07/23/2018 06:19PM by bodhi.
|
Koen
Re: Dell Wyse T10 / T50 July 24, 2018 06:37PM |
OK I've created the rootfs USB and tried to boot it but it doesn't work yet. It is difficult to know what is happening without serial console output. There is a quick message on screen before it boots the internal memory. It seems that uboot expects a certain USB file system label and file structure to load the minimal linux system from. The rootfs has a different file structure and so it skips to the 2nd boot device which is the internal memory. I'm thinking of re-creating the Dell firmware upgrade USB stick to have a look at what file system and label it uses.
I've not started changing the boot-normal.scr file since I don't know enough about uboot yet. It would be nice if I could tell uboot to do a printenv during the startup to get an idea what all the settings are but I'm not sure if that is possible.
Koen
I've not started changing the boot-normal.scr file since I don't know enough about uboot yet. It would be nice if I could tell uboot to do a printenv during the startup to get an idea what all the settings are but I'm not sure if that is possible.
Koen
|
Re: Dell Wyse T10 / T50 July 24, 2018 07:35PM |
Admin Registered: 13 years ago Posts: 19,224 |
Koen,
BTW, it is best if you can find GPL for this Dell FW. They must provide it somewhere as legally required. When we see GPL, we'll know for sure what to do.
> OK I've created the rootfs USB and tried to boot
> it but it doesn't work yet. It is difficult to
> know what is happening without serial console
> output.
True.
> There is a quick message on screen before
> it boots the internal memory. It seems that uboot
> expects a certain USB file system label and file
> structure to load the minimal linux system from.
That's the basic Debian armhf rootfs I released. All u-boot from circa 2011 till now can boot it (except when the manufactor intentionally disable USB).
> The rootfs has a different file structure and so
> it skips to the 2nd boot device which is the
> internal memory.
The u-boot envs determine how u-boot load the kernel files on the rootfs. Its default envs set up to boot in a certain way.
> I've not started changing the boot-normal.scr file
> since I don't know enough about uboot yet. It
> would be nice if I could tell uboot to do a
> printenv during the startup to get an idea what
> all the settings are but I'm not sure if that is
> possible.
The idea is because serial console does not show anything, the only way to know if boot-normal.scr is used during booting is to tweak an env such as bootargs to be able to see changes. printenv would not print anything if the other commands did not show.
However, since bootargs was overwritten (hopefully is the case) by SPI definition, you would have to tweak another env.
Here is another approach. If u-boot disabled the std in/out/err internally, then this would hopefully turn it back on:
cat boot-normal.txt
Note that I would not recommend you change any envs using spi command! when serial console does not work fully, the risk of being locked out is high. Unless you can experiment with a Dell stock USB recovery that can restore your system fully, we should not change u-boot envs permanently.
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
BTW, it is best if you can find GPL for this Dell FW. They must provide it somewhere as legally required. When we see GPL, we'll know for sure what to do.
> OK I've created the rootfs USB and tried to boot
> it but it doesn't work yet. It is difficult to
> know what is happening without serial console
> output.
True.
> There is a quick message on screen before
> it boots the internal memory. It seems that uboot
> expects a certain USB file system label and file
> structure to load the minimal linux system from.
That's the basic Debian armhf rootfs I released. All u-boot from circa 2011 till now can boot it (except when the manufactor intentionally disable USB).
> The rootfs has a different file structure and so
> it skips to the 2nd boot device which is the
> internal memory.
The u-boot envs determine how u-boot load the kernel files on the rootfs. Its default envs set up to boot in a certain way.
> I've not started changing the boot-normal.scr file
> since I don't know enough about uboot yet. It
> would be nice if I could tell uboot to do a
> printenv during the startup to get an idea what
> all the settings are but I'm not sure if that is
> possible.
The idea is because serial console does not show anything, the only way to know if boot-normal.scr is used during booting is to tweak an env such as bootargs to be able to see changes. printenv would not print anything if the other commands did not show.
However, since bootargs was overwritten (hopefully is the case) by SPI definition, you would have to tweak another env.
Here is another approach. If u-boot disabled the std in/out/err internally, then this would hopefully turn it back on:
cat boot-normal.txt
setenv stderr serial setenv stdin serial setenv stdout serial printenv fatload ide 0:1 0x200000 /uImage setenv bootargs pm_disable root=/dev/sda3 vmalloc=384M mimas quiet bootm 0x200000
Note that I would not recommend you change any envs using spi command! when serial console does not work fully, the risk of being locked out is high. Unless you can experiment with a Dell stock USB recovery that can restore your system fully, we should not change u-boot envs permanently.
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
|
Re: Dell Wyse T10 / T50 July 25, 2018 12:32AM |
Registered: 9 years ago Posts: 466 |
bodhi Wrote:
-------------------------------------------------------
> BTW, it is best if you can find GPL for this Dell
> FW. They must provide it somewhere as legally
> required. When we see GPL, we'll know for sure
> what to do.
>
Good luck with that, my success rate is pretty low. Some manufacturers such as Netgear and D-Link are pretty good about having a central website where you can download images for almost all their hardware. Other manufacturers like to make it difficult as hell. Dell doesn't seem to even want to acknowledge the existence of the Dell Kace M300. I've posted to the Dell forums attempting to locate source for the Dell Kace M300 and the Dell Wyse 3010 Thin Client. I did get a response regarding the Kace M300 directing me to Quest at itninja.com. Apparently Dell sold the Kace product line to them, however I believe that Dell should still be obligated to provide the appropriate source. I've left a message at itninja.com and am awaiting a response.
Ray
-------------------------------------------------------
> BTW, it is best if you can find GPL for this Dell
> FW. They must provide it somewhere as legally
> required. When we see GPL, we'll know for sure
> what to do.
>
Good luck with that, my success rate is pretty low. Some manufacturers such as Netgear and D-Link are pretty good about having a central website where you can download images for almost all their hardware. Other manufacturers like to make it difficult as hell. Dell doesn't seem to even want to acknowledge the existence of the Dell Kace M300. I've posted to the Dell forums attempting to locate source for the Dell Kace M300 and the Dell Wyse 3010 Thin Client. I did get a response regarding the Kace M300 directing me to Quest at itninja.com. Apparently Dell sold the Kace product line to them, however I believe that Dell should still be obligated to provide the appropriate source. I've left a message at itninja.com and am awaiting a response.
Ray
|
Re: Dell Wyse T10 / T50 July 25, 2018 01:51AM |
Admin Registered: 13 years ago Posts: 19,224 |
rayknight Wrote:
-------------------------------------------------------
> bodhi Wrote:
> -------------------------------------------------------
>
> > BTW, it is best if you can find GPL for this
> Dell
> > FW. They must provide it somewhere as legally
> > required. When we see GPL, we'll know for sure
> > what to do.
> >
>
> Good luck with that, my success rate is pretty
> low. Some manufacturers such as Netgear and
> D-Link are pretty good about having a central
> website where you can download images for almost
> all their hardware. Other manufacturers like to
> make it difficult as hell. Dell doesn't seem to
> even want to acknowledge the existence of the Dell
> Kace M300. I've posted to the Dell forums
> attempting to locate source for the Dell Kace M300
> and the Dell Wyse 3010 Thin Client. I did get a
> response regarding the Kace M300 directing me to
> Quest at itninja.com. Apparently Dell sold the
> Kace product line to them, however I believe that
> Dell should still be obligated to provide the
> appropriate source. I've left a message at
> itninja.com and am awaiting a response.
>
> Ray
Thanks for trying Ray! I hate to threaten them with report;) but if that’s what needs to get GPL, we would want to do it.
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
-------------------------------------------------------
> bodhi Wrote:
> -------------------------------------------------------
>
> > BTW, it is best if you can find GPL for this
> Dell
> > FW. They must provide it somewhere as legally
> > required. When we see GPL, we'll know for sure
> > what to do.
> >
>
> Good luck with that, my success rate is pretty
> low. Some manufacturers such as Netgear and
> D-Link are pretty good about having a central
> website where you can download images for almost
> all their hardware. Other manufacturers like to
> make it difficult as hell. Dell doesn't seem to
> even want to acknowledge the existence of the Dell
> Kace M300. I've posted to the Dell forums
> attempting to locate source for the Dell Kace M300
> and the Dell Wyse 3010 Thin Client. I did get a
> response regarding the Kace M300 directing me to
> Quest at itninja.com. Apparently Dell sold the
> Kace product line to them, however I believe that
> Dell should still be obligated to provide the
> appropriate source. I've left a message at
> itninja.com and am awaiting a response.
>
> Ray
Thanks for trying Ray! I hate to threaten them with report;) but if that’s what needs to get GPL, we would want to do it.
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
|
Koen
Re: Dell Wyse T10 / T50 July 25, 2018 01:59AM |
I do think that modifying spi without serial is going to result in a brick which is why I have not done that. There is a little jumper next to the CMOS chip but I've not touched that either since it may clear the CMOS and lock me out.
So I'll try the boot-normal.src file this evening and see if that works. I'll also email Dell but I'm not expecting any response from them.
Is there a way to get any additional info from deconstructing the .img files I've extracted from the device? Or is that not possible?
Koen
So I'll try the boot-normal.src file this evening and see if that works. I'll also email Dell but I'm not expecting any response from them.
Is there a way to get any additional info from deconstructing the .img files I've extracted from the device? Or is that not possible?
Koen
|
Re: Dell Wyse T10 / T50 July 25, 2018 03:25AM |
Admin Registered: 13 years ago Posts: 19,224 |
Koen
> Is there a way to get any additional info from
> deconstructing the .img files I've extracted from
> the device? Or is that not possible?
There is no value in doing that. This kernel is too old, so nothing in there would be of interest. We already know the SoC, and the kernel DTB that will boot this SoC.
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
> Is there a way to get any additional info from
> deconstructing the .img files I've extracted from
> the device? Or is that not possible?
There is no value in doing that. This kernel is too old, so nothing in there would be of interest. We already know the SoC, and the kernel DTB that will boot this SoC.
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
|
Koen
Re: Dell Wyse T10 / T50 July 25, 2018 02:59PM |
I've created a boot-normal.txt file with the following content: (changed rootday to rootdelay since I assumed that was a typo and changed the value to 13 to make it stand out more)
executed the following command to create a uboot script
which results in the following:
The first line is a bit different from the original but I guess that is OK:
Reboot the system but the kernel boot parameters do not seem to get used but instead get overruled by the values stored in spi.
I'll try the activation of serial / uart next.
fatload ide 0:1 0x200000 /uImage setenv bootargs pm_disable root=/dev/sda3 vmalloc=384M mimas quiet rootdelay=13 bootm 0x200000
executed the following command to create a uboot script
mkimage -A ARM -T script -C none -n 'boot-normal.scr' -d boot-normal.txt boot-normal.scr
which results in the following:
root@LWT008064aa7d6c:/mnt/sda1# cat boot-normal.scr 'V}�s�[X�M�<O�boot-normal.scr�fatload ide 0:1 0x200000 /uImage setenv bootargs pm_disable root=/dev/sda3 vmalloc=384M mimas quiet rootdelay=13 bootm 0x200000
The first line is a bit different from the original but I guess that is OK:
root@LWT008064aa7d6c:/mnt/temp1/sda1# cat bkup-boot-normal.scr 'V���U�E��Lx�Normal boot script�echo Starting Ubuntu... fatload ide 0:1 0x200000 /uImage setenv bootargs pm_disable root=/dev/sda3 vmalloc=384M mimas quiet bootm 0x200000
Reboot the system but the kernel boot parameters do not seem to get used but instead get overruled by the values stored in spi.
root@LWT008064aa7d6c:/# cat proc/cmdline root=/dev/sda3 pm_disable usb0Mode=host usb1Mode=host video=dovefb:lcd0:1024x768-32@60,lcd1:1024x768-32@60 clcd.lcd0_enable=1 clcd.lcd1_enable=1 clcd.lcd0_clk=3 clcd.lcd1_clk=1 splash no_console_suspend kb3310_disable=1 cpufreq_disable=1 vmalloc=384M quiet
I'll try the activation of serial / uart next.
|
Koen
Re: Dell Wyse T10 / T50 July 25, 2018 03:18PM |
Created a new boot-normal.scr using the same method above which looks like this:
Rebooting the system multiple times does not result in output on serial unfortunately.
At the moment I'm not sure what else to try so I'm open to suggestions.
Koen
root@LWT008064aa7d6c:/mnt/sda1# cat boot-normal.scr 'Vȩ!�[X���x�boot-normal.scr�setenv stderr serial setenv stdin serial setenv stdout serial printenv fatload ide 0:1 0x200000 /uImage setenv bootargs pm_disable root=/dev/sda3 vmalloc=384M mimas quiet bootm 0x200000
Rebooting the system multiple times does not result in output on serial unfortunately.
koen@koen-ThinkPad-X220:~$ picocom -b 115200 /dev/ttyUSB0 picocom v2.2 port is : /dev/ttyUSB0 flowcontrol : none baudrate is : 115200 parity is : none databits are : 8 stopbits are : 1 escape is : C-a local echo is : no noinit is : no noreset is : no nolock is : no send_cmd is : sz -vv receive_cmd is : rz -vv -E imap is : omap is : emap is : crcrlf,delbs, Type [C-a] [C-h] to see available commands Terminal ready Uncompressing Linux........................................................................................................................................................................................................................................ done, booting the kernel. Uncompressing Linux........................................................................................................................................................................................................................................ done, booting the kernel. Uncompressing Linux........................................................................................................................................................................................................................................ done, booting the kernel.
At the moment I'm not sure what else to try so I'm open to suggestions.
Koen
|
Koen
Re: Dell Wyse T10 / T50 July 25, 2018 03:55PM |
Tried one more time with a whole bunch of settings from the uboot manual but still no luck.
root@LWT008064aa7d6c:/mnt/sda1# cat boot-normal.scr 'V�0�[X���T)��boot-normal.scr�setenv silent setenv autostart no setenv bootdelay 10 setenv stderr serial setenv stdin serial setenv stdout serial printenv fatload ide 0:1 0x200000 /uImage setenv bootargs pm_disable root=/dev/sda3 vmalloc=384M mimas quiet bootm 0x200000
|
Koen
Re: Dell Wyse T10 / T50 July 26, 2018 04:37PM |
It seems that I've reached a dead end for now. If I have time I will try to read the spi chip using a raspberry pi this weekend. If that works I can write new kernel boot parameters to spi using the spi-w command and use the raspberry pi to restore the spi if it ends up locking me out of the device.
Koen
Koen
