Author Topic: Hacking the Rigol MSO5000 series oscilloscopes  (Read 168339 times)

0 Members and 5 Guests are viewing this topic.

Offline Agne

  • Contributor
  • Posts: 10
  • Country: se
Hacking the Rigol MSO5000 series oscilloscopes
« on: December 02, 2018, 04:19:19 pm »
TL;DR This thread is only for hacking of the Rigol 5000 oscilloscope. I own a Rigol 5000 series oscilloscope and have tried the old (Rigol 1000z & 2000A series) trick of dumping the RAM using SCPI commands but unfortunate this does not appear to work on the 5000 series. Next step is trying the JTAG memory dumping method.

------------------------------------------------------------------------------------------------------------------
Since the previous thread about the Rigol 5000 series oscilloscope has been completely derailed from discussing the Rigol 5000 to arguing about A and B brands and if Lecroy and Tektronix are still A brands etc, I would like to start this new thread dedicated to hacking of the 5000 series.

To keep this thread clear from what made the previous thread unusable from a Rigol 5000 hackers perspective I would like to set some simple rules for it.

* This tread is only for hacking the Rigol 5000 series oscilloscope
* If you would like to discuss other things such as if you should buy the 5000 series or what is an A or B brand then please post that in a different thread.
-----------------------------------------------------------------------------------------------------------------------

With that over with lets discuss what hacking progress has been made so far.
I have tried on my 5000 series scope the SCPI memory dump command that was successfully used on the Rigol 1000z and 2000A series oscilloscopes. Unfortunately the command does not work on the 5000 series. When using the memory dump command with Netcat on my mac I get no reply from the scope and when using RigolBildschirmkopie I get “there was an error when sending the SCPI comand”. To verify that SCPI was working I tried the *IDN? , :SYSTEM:TIME? and the SYSTEM:DATE? commands and they worked with out issue.

Rigol appears to have either removed or changed the name of the SCPI command used to dump the memory on the older scopes. At this point I think using  JTAG to dump the memory is our best bet. I will post an update when I know more.
« Last Edit: December 04, 2018, 12:16:13 am by Agne »
 
The following users thanked this post: EEVblog, thm_w, Fungus, jjoonathan, Nx-1997, 2N3055, Jacon, imo

Offline Agne

  • Contributor
  • Posts: 10
  • Country: se
Re: Hacking the Rigol MSO5000 series oscilloscopes
« Reply #1 on: December 02, 2018, 08:31:44 pm »
I have now opened my Rigol 5000 series scope and looked for possible JTAG connectors. There appears to be spaces for two JTAG connectors on the board, one for the Zynq FPGA and one for the Spartan FPGA.

Unfortunately Rigol have not mounted the pin headers for the JTAG on the PCB.
This reduces there BOM cost by a few cents and makes connecting a JTAG programmer to the board more difficult.

I have attached below some images showing the inside of the scope and I have highlighted the possible location for the JTAG connectors. The connector that I am most interested in is small 9 pin one because it looks like the JTAG connector used to dump the memory on the Rigol 1000Z and 2000A series oscilloscopes.
 
The following users thanked this post: tcottle, jjoonathan, Daruosha

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 17869
  • Country: nl
    • NCT Developments
Re: Hacking the Rigol MSO5000 series oscilloscopes
« Reply #2 on: December 02, 2018, 09:09:37 pm »
I'd look at the unmarked 14 pin connector to the right.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 
The following users thanked this post: Jacon

Offline Agne

  • Contributor
  • Posts: 10
  • Country: se
Re: Hacking the Rigol MSO5000 series oscilloscopes
« Reply #3 on: December 02, 2018, 11:25:59 pm »
After looking for a simple solution to the problem of not having pin headers mounted on the JTAG connectors and not wanting to completely disassemble the scope to permanently solder in pin headers I found solderless press fit pin headers. I have ordered some and my hope is that I can push them in partially, just enough to make good contact while still being able to remove them when done.
 

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 17869
  • Country: nl
    • NCT Developments
Re: Hacking the Rigol MSO5000 series oscilloscopes
« Reply #4 on: December 03, 2018, 07:35:34 am »
I wouldn't use press-fit connectors. You'll need to put way too much force on the board which might damage it. Ceramic capacitors don't like being bend. Just take it apart and solder a connector in.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Online TheSteve

  • Supporter
  • ****
  • Posts: 3012
  • Country: ca
  • GHz
Re: Hacking the Rigol MSO5000 series oscilloscopes
« Reply #5 on: December 03, 2018, 07:59:07 am »
I wouldn't use press-fit connectors. You'll need to put way too much force on the board which might damage it. Ceramic capacitors don't like being bend. Just take it apart and solder a connector in.

Agreed, solder a normal header in.

Or you could use pogo pins, but you'd need to find a way to maintain pressure on the pins.
VE7FM
 

Offline mikeselectricstuff

  • Super Contributor
  • ***
  • Posts: 12027
  • Country: gb
    • Mike's Electric Stuff
Re: Hacking the Rigol MSO5000 series oscilloscopes
« Reply #6 on: December 03, 2018, 09:12:46 am »
If you don't want to solder headers in, get a long pin header  - 10mm or more, then bend alternate pins. It can then be inserted such that the bent pins exert pressure on the sides of the holes.
Youtube channel:Taking wierd stuff apart. Very apart.
Mike's Electric Stuff: High voltage, vintage electronics etc.
Day Job: Mostly LEDs
 
The following users thanked this post: mauroh, bitseeker

Offline Fungus

  • Super Contributor
  • ***
  • Posts: 10103
  • Country: 00
Re: Hacking the Rigol MSO5000 series oscilloscopes
« Reply #7 on: December 03, 2018, 09:21:24 am »
If you don't want to solder headers in, get a long pin header  - 10mm or more, then bend alternate pins. It can then be inserted such that the bent pins exert pressure on the sides of the holes.

If you get square pins they might exert enough pressure to make contact all by themselves.
 

Offline mikeselectricstuff

  • Super Contributor
  • ***
  • Posts: 12027
  • Country: gb
    • Mike's Electric Stuff
Re: Hacking the Rigol MSO5000 series oscilloscopes
« Reply #8 on: December 03, 2018, 09:23:30 am »
If you don't want to solder headers in, get a long pin header  - 10mm or more, then bend alternate pins. It can then be inserted such that the bent pins exert pressure on the sides of the holes.

If you get square pins they might exert enough pressure to make contact all by themselves.
You need bent pins so each pin is independently spruing
Youtube channel:Taking wierd stuff apart. Very apart.
Mike's Electric Stuff: High voltage, vintage electronics etc.
Day Job: Mostly LEDs
 

Offline mrpackethead

  • Super Contributor
  • ***
  • Posts: 2825
  • Country: nz
  • D Size Cell
Re: Hacking the Rigol MSO5000 series oscilloscopes
« Reply #9 on: December 03, 2018, 09:42:20 am »
is the upgrade licence file encypted?
On a quest to find increasingly complicated ways to blink things
 

Offline glenenglish

  • Regular Contributor
  • *
  • Posts: 113
  • Country: au
  • AI6UM / VK1XX
Re: Hacking the Rigol MSO5000 series oscilloscopes
« Reply #10 on: December 03, 2018, 10:01:39 am »
how about I buy a 70 also and buy the upgrade to 100 in the same breath ? that should be useful.
I'll have mine in 2 weeks or so... am a Xilinx man...
 

Offline Fungus

  • Super Contributor
  • ***
  • Posts: 10103
  • Country: 00
Re: Hacking the Rigol MSO5000 series oscilloscopes
« Reply #11 on: December 03, 2018, 10:12:27 am »
is the upgrade licence file encypted?

In the programming guide it shows this example of installing a license key:



The key's definitely a lot longer than a key for a DS1054Z.  :popcorn:

Does anybody have a license file? Can you look at it and see if the contents look like that?
« Last Edit: December 03, 2018, 10:14:57 am by Fungus »
 

Offline mikeselectricstuff

  • Super Contributor
  • ***
  • Posts: 12027
  • Country: gb
    • Mike's Electric Stuff
Re: Hacking the Rigol MSO5000 series oscilloscopes
« Reply #12 on: December 03, 2018, 10:34:59 am »
is the upgrade licence file encypted?

In the programming guide it shows this example of installing a license key:



The key's definitely a lot longer than a key for a DS1054Z.  :popcorn:

Does anybody have a license file? Can you look at it and see if the contents look like that?
Pretty sure Dave mentioned he had one
Youtube channel:Taking wierd stuff apart. Very apart.
Mike's Electric Stuff: High voltage, vintage electronics etc.
Day Job: Mostly LEDs
 

Offline EEVblog

  • Administrator
  • *****
  • Posts: 29892
  • Country: au
    • EEVblog
Re: Hacking the Rigol MSO5000 series oscilloscopes
« Reply #13 on: December 03, 2018, 10:46:10 am »
is the upgrade licence file encypted?

The license file is a single line of text as shown above.
"DS5000-2RL@" followed by 128 bytes of key data
Where 2RL seems to be the license type code
My license file didn't work though.
They need your serial number to generate the key.
« Last Edit: December 03, 2018, 10:48:42 am by EEVblog »
 

Offline tv84

  • Frequent Contributor
  • **
  • Posts: 908
  • Country: pt
Re: Hacking the Rigol MSO5000 series oscilloscopes
« Reply #14 on: December 03, 2018, 12:27:55 pm »
(128 bytes => 1024 bits)

It seems to me that we will be seeing asymmetric crypto  >:( . I think the MSO7000 will be the same.

As such, there won't be any licenses soon and the solution could be SW patches.

If the FW is signed, that is another ballgame (HW patch...  ::) ). 

Nonetheless, waiting for the memdump...  :popcorn:
 

Online Bud

  • Super Contributor
  • ***
  • Posts: 3531
  • Country: ca
Re: Hacking the Rigol MSO5000 series oscilloscopes
« Reply #15 on: December 03, 2018, 12:52:42 pm »
is the upgrade licence file encypted?

The license file is a single line of text as shown above.
"DS5000-2RL@" followed by 128 bytes of key data
Where 2RL seems to be the license type code

Then it seems the hex string is a 1024-bit digital signature of the license code.
Facebook-free life and Rigol-free shack.
 

Offline Fungus

  • Super Contributor
  • ***
  • Posts: 10103
  • Country: 00
Re: Hacking the Rigol MSO5000 series oscilloscopes
« Reply #16 on: December 03, 2018, 01:06:53 pm »
Then it seems the hex string is a 1024-bit digital signature of the license code.

Most likely the license type+the serial number.

If somebody can find the hash code in the ROM then it's easy to make a key generator.

The bad news would be if it's a 1024-bit signature of the license type+serial number+a secret salt value that's written to the flash memory at the same time as the serial number.

It would mean you need to get the salt value out and that might only be possible by opening it up and using JTAG.

Finger crossed that they didn't do that.

If this thing runs Linux then step (1) would be to get access to the file system and dump all the files. See if there's anything interesting in there.

Step (2) would be to dump all the files before/after installing an option and see what changes.

 

Offline Fungus

  • Super Contributor
  • ***
  • Posts: 10103
  • Country: 00
Re: Hacking the Rigol MSO5000 series oscilloscopes
« Reply #17 on: December 03, 2018, 01:40:44 pm »
Can anybody post all the RS232 logging messages from a bootup? Maybe there's useful info in there.


 

Offline TNorthover

  • Contributor
  • Posts: 42
  • Country: us
Re: Hacking the Rigol MSO5000 series oscilloscopes
« Reply #18 on: December 03, 2018, 03:04:58 pm »
Most likely the license type+the serial number.

If somebody can find the hash code in the ROM then it's easy to make a key generator.

If it's an actual 1024-bit signature rather than a simple hash or something (as the size suggests) then no-one is going to be generating them any time soon. You also need Rigol's private key.
 

Offline tv84

  • Frequent Contributor
  • **
  • Posts: 908
  • Country: pt
Re: Hacking the Rigol MSO5000 series oscilloscopes
« Reply #19 on: December 03, 2018, 03:05:44 pm »
Fungus,

With asym crypto involved and the boot signed, there's no salt reading or flash dumps that can help.

The most one can do is obtain the public key. But that is useless to create new software.

Let's wait for the next steps.
 

Offline mikeselectricstuff

  • Super Contributor
  • ***
  • Posts: 12027
  • Country: gb
    • Mike's Electric Stuff
Re: Hacking the Rigol MSO5000 series oscilloscopes
« Reply #20 on: December 03, 2018, 04:38:38 pm »
If I wanted to make a product like this with good security, I'd include a random number stored in the device as part of the production process, with a factory database of this number versus serial number, and use that rather than the serial no. for authenticating/decrypting license keys, so the actual serial number bears no useable relationship to the license key.
Youtube channel:Taking wierd stuff apart. Very apart.
Mike's Electric Stuff: High voltage, vintage electronics etc.
Day Job: Mostly LEDs
 

Online maginnovision

  • Super Contributor
  • ***
  • Posts: 1194
  • Country: us
Re: Hacking the Rigol MSO5000 series oscilloscopes
« Reply #21 on: December 03, 2018, 04:41:00 pm »
Didn't the distributor generate the key though? I assume that means no asym crypto or the key isn't that safe.
 

Offline Fungus

  • Super Contributor
  • ***
  • Posts: 10103
  • Country: 00
Re: Hacking the Rigol MSO5000 series oscilloscopes
« Reply #22 on: December 03, 2018, 04:57:10 pm »
Didn't the distributor generate the key though? I assume that means no asym crypto or the key isn't that safe.

They generate them on the Rigol web site.

Rigol could have a private key on there.
 

Online maginnovision

  • Super Contributor
  • ***
  • Posts: 1194
  • Country: us
Re: Hacking the Rigol MSO5000 series oscilloscopes
« Reply #23 on: December 03, 2018, 05:03:49 pm »
Didn't the distributor generate the key though? I assume that means no asym crypto or the key isn't that safe.

They generate them on the Rigol web site.

Rigol could have a private key on there.


Oh right. The internet. I forgot about the internet.  :-//
 

Offline Fungus

  • Super Contributor
  • ***
  • Posts: 10103
  • Country: 00
Re: Hacking the Rigol MSO5000 series oscilloscopes
« Reply #24 on: December 03, 2018, 05:04:46 pm »
Dave posted the boot output in another thread.

Code: [Select]
U-Boot 2014.01.Rigolee.dirty (2018.06.12 - 12:12:01)

I2C:   ready
Memory: ECC disabled
DRAM:  448 MiB
DPU:   20170604
NAND:  OnDie ECC supported, 1024 MiB
zynq-In:    serial
zynq-Out:   serial
zynq-Err:   serial
Net:   Gem.e000b000
BootParam=0x0
Hit any key to stop autoboot:  0

NAND read: device 0 offset 0x4900000, size 0x3591fd
þ
NAND read: device 0 offset 0x4900000, size 0x8
 8 bytes read: OK

NAND read: device 0 offset 0x4500000, size 0x12c008
 1228808 bytes read: OK
Loading logo, x=310,y=247,width=404,height=89

NAND read: device 0 offset 0x5100000, size 0xd8ebf0
 14216176 bytes read: OK
 ## Loading kernel from FIT Image at 03000000 ...
   Using 'rootfs@1' configuration
   Trying 'kernel@1' kernel subimage
     Description:  Kerstrel Linux kernel
     Type:         Kernel Image
     Compression:  uncompressed
     Data Start:   0x030000f8
     Data Size:    3302448 Bytes = 3.1 MiB
     Architecture: ARM
     OS:           Linux
     Load Address: 0x00100000
     Entry Point:  0x00100000
     Hash algo:    sha1
     Hash value:   bece162e8cad943c68714d8eb8020d68e1db896b
   Verifying Hash Integrity ... sha1+ OK
 ## Loading ramdisk from FIT Image at 03000000 ...
   Using 'rootfs@1' configuration
   Trying 'ramdisk@1' ramdisk subimage
     Description:  kerstrel-Update-Ramdisk
     Type:         RAMDisk Image
     Compression:  gzip compressed
     Data Start:   0x03328c5c
     Data Size:    10901113 Bytes = 10.4 MiB
     Architecture: ARM
     OS:           Linux
     Load Address: unavailable
     Entry Point:  unavailable
     Hash algo:    sha1
     Hash value:   55bdcbebccba845da403130143793ee0135e53a1
   Verifying Hash Integrity ... sha1+ OK
 ## Loading fdt from FIT Image at 03000000 ...
   Using 'rootfs@1' configuration
   Trying 'fdt@1' fdt subimage
     Description:  Flattened Device Tree blob
     Type:         Flat Device Tree
     Compression:  uncompressed
     Data Start:   0x0332661c
     Data Size:    9597 Bytes = 9.4 KiB
     Architecture: ARM
     Hash algo:    sha1
     Hash value:   da2d17ba0d5a71b5897deec4cb026014f3132185
   Verifying Hash Integrity ... sha1+ OK
   Booting using the fdt blob at 0x332661c
   Loading Kernel Image ... OK
   Loading Ramdisk to 1b099000, end 1bafe679 ... OK
   Loading Device Tree to 1b093000, end 1b09857c ... OK

Starting kernel ...

Uncompressing Linux... done, booting the kernel.
Booting Linux on physical CPU 0x0
Linux version 3.12.0-xilinx (rigolee[member=167213]Jim[/member]) (gcc version 4.8.1 (Sourcery CodeBench Lite 2013.11-53) ) #43 SMP PREEMPT Sat Jul 28 12:14:01 CST 2018
CPU: ARMv7 Processor [413fc090] revision 0 (ARMv7), cr=18c5387d
CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
Machine: Xilinx Zynq Platform, model: Xilinx Zynq
Memory policy: Data cache writealloc
PERCPU: Embedded 8 pages/cpu @c09f1000 s8384 r8192 d16192 u32768
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 113792
Kernel command line: console=ttyPS0,115200 no_console_suspend, root=/dev/ram rw
PID hash table entries: 2048 (order: 1, 8192 bytes)
Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
Memory: 437416K/458752K available (4197K kernel code, 255K rwdata, 1716K rodata, 176K init, 179K bss, 21336K reserved, 0K highmem)
Virtual kernel memory layout:
    vector  : 0xffff0000 - 0xffff1000   (   4 kB)
    fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)
    vmalloc : 0xdc800000 - 0xff000000   ( 552 MB)
    lowmem  : 0xc0000000 - 0xdc000000   ( 448 MB)
    pkmap   : 0xbfe00000 - 0xc0000000   (   2 MB)
    modules : 0xbf000000 - 0xbfe00000   (  14 MB)
      .text : 0xc0008000 - 0xc05ce880   (5915 kB)
      .init : 0xc05cf000 - 0xc05fb0c0   ( 177 kB)
      .data : 0xc05fc000 - 0xc063bd78   ( 256 kB)
       .bss : 0xc063bd84 - 0xc06689a4   ( 180 kB)
Preemptible hierarchical RCU implementation.
        Dump stacks of tasks blocking RCU-preempt GP.
        RCU restricting CPUs from NR_CPUS=4 to nr_cpu_ids=2.
NR_IRQS:16 nr_irqs:16 16
ps7-slcr mapped to dc802000
Zynq clock init
sched_clock: 32 bits at 100 Hz, resolution 10000000ns, wraps every 4294967286ms
Console: colour dummy device 80x30
Calibrating delay loop... 1725.23 BogoMIPS (lpj=8626176)
pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 512
CPU: Testing write buffer coherency: ok
CPU0: thread -1, cpu 0, socket 0, mpidr 80000000
Setting up static identity map for 0xc03fa6b8 - 0xc03fa710
L310 cache controller enabled
l2x0: 8 ways, CACHE_ID 0x410000c8, AUX_CTRL 0x72360000, Cache size: 512 kB
CPU1: Booted secondary processor
CPU1: thread -1, cpu 1, socket 0, mpidr 80000001
Brought up 2 CPUs
SMP: Total of 2 processors activated.
CPU: All CPU(s) started in SVC mode.
devtmpfs: initialized
VFP support v0.3: implementor 41 architecture 3 part 30 variant 9 rev 4
regulator-dummy: no parameters
NET: Registered protocol family 16
DMA: preallocated 256 KiB pool for atomic coherent allocations
gpio->base_addr is:0xdc84e000
The gpio irq num is:52
zynq_gpio e000a000.ps7-gpio: gpio at 0xe000a000 mapped to 0xdc84e000
hw-breakpoint: found 5 (+1 reserved) breakpoint and 1 watchpoint registers.
hw-breakpoint: maximum watchpoint size is 4 bytes.
zynq_ocm f800c000.ps7-ocmc: ZYNQ OCM pool: 256 KiB @ 0xdc880000
bio: create slab <bio-0> at 0
vgaarb: loaded
SCSI subsystem initialized
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
pps_core: LinuxPPS API ver. 1 registered
pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti[member=183778]linux[/member].it>
PTP clock support registered
EDAC MC: Ver: 3.0.0
NET: Registered protocol family 2
TCP established hash table entries: 4096 (order: 3, 32768 bytes)
TCP bind hash table entries: 4096 (order: 3, 32768 bytes)
TCP: Hash tables configured (established 4096 bind 4096)
TCP: reno registered
UDP hash table entries: 256 (order: 1, 8192 bytes)
UDP-Lite hash table entries: 256 (order: 1, 8192 bytes)
NET: Registered protocol family 1
RPC: Registered named UNIX socket transport module.
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
RPC: Registered tcp NFSv4.1 backchannel transport module.
Trying to unpack rootfs image as initramfs...
rootfs image is not initramfs (no cpio magic); looks like an initrd
Freeing initrd memory: 10644K (db099000 - dbafe000)
hw perfevents: enabled with ARMv7 Cortex-A9 PMU driver, 7 counters available
NTFS driver 2.1.30 [Flags: R/W].
msgmni has been set to 875
io scheduler noop registered
io scheduler deadline registered
io scheduler cfq registered (default)
DPU:Map vRam to 0xdca00000
DPU:Map iReg to 0xdcc00000
DPU:Ver=0x20170711
dma-pl330 f8003000.ps7-dma: unable to set the seg size
dma-pl330 f8003000.ps7-dma: Loaded driver for PL330 DMAC-2364208
dma-pl330 f8003000.ps7-dma:     DBUFF-128x8bytes Num_Chans-8 Num_Peri-4 Num_Events-16
e0000000.serial: ttyPS0 at MMIO 0xe0000000 (irq = 59, base_baud = 6249999) is a xuartps
console [ttyPS0] enabled
xuartps e0001000.serial: failed to get alias id, errno -19
e0001000.serial: ttyPS1 at MMIO 0xe0001000 (irq = 82, base_baud = 6249999) is a xuartps
brd: module loaded
loop: module loaded
xspips e0006000.ps7-spi: master is unqueued, this is deprecated
xspips e0006000.ps7-spi: at 0xE0006000 mapped to 0xDC858000, irq=58
libphy: XEMACPS mii bus: probed
xemacps e000b000.ps7-ethernet: pdev->id -1, baseaddr 0xe000b000, irq 54
ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
ehci-pci: EHCI PCI platform driver
ULPI transceiver vendor/product ID 0x0424/0x0009
ULPI integrity check: passed.
ULPI transceiver vendor/product ID 0x0424/0x0009
ULPI integrity check: passed.
xusbps-ehci xusbps-ehci.1: Xilinx PS USB EHCI Host Controller
xusbps-ehci xusbps-ehci.1: new USB bus registered, assigned bus number 1
xusbps-ehci xusbps-ehci.1: irq 76, io mem 0x00000000
xusbps-ehci xusbps-ehci.1: USB 2.0 started, EHCI 1.00
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 1 port detected
usbcore: registered new interface driver usb-storage
mousedev: PS/2 mouse device common for all mice
i2c /dev entries driver
rtc-rx8010sj 0-0032: Update timer was detected
rtc-rx8010sj 0-0032: rtc core: registered rtc-rx8010sj as rtc0
input: Goodix-TS as /devices/virtual/input/input0
xi2cps e0004000.ps7-i2c: 90 kHz mmio e0004000 irq 57
zynq-edac f8006000.ps7-ddrc: ecc not enabled
sdhci: Secure Digital Host Controller Interface driver
sdhci: Copyright(c) Pierre Ossman
sdhci-pltfm: SDHCI platform and OF driver helper
usbcore: registered new interface driver usbhid
usbhid: USB HID core driver
ONFI param page 0 valid
ONFI flash detected
NAND device: Manufacturer ID: 0x2c, Chip ID: 0xd3 (Micron MT29F8G08ADADAH4), 1024MiB, page size: 2048, OOB size: 64
Bad block table found at page 524224, version 0x01
Bad block table found at page 524160, version 0x01
13 ofpart partitions found on MTD device pl353-nand
Creating 13 MTD partitions on "pl353-nand":
0x000000000000-0x000000040000 : "Env"
0x000000100000-0x000004100000 : "DATA"
0x000004100000-0x000004500000 : "Bmp"
0x000004500000-0x000004900000 : "Bmp1"
0x000004900000-0x000005100000 : "Bit1"
0x000005100000-0x000007100000 : "Sys1"
0x000007100000-0x00000d500000 : "App1"
0x00000d500000-0x00000d900000 : "Bmp2"
0x00000d900000-0x00000e100000 : "Bit2"
0x00000e100000-0x000010100000 : "Sys2"
0x000010100000-0x000016500000 : "App2"
0x000016500000-0x00001a800000 : "Reserved"
0x00001a800000-0x000040000000 : "User"
TCP: cubic registered
NET: Registered protocol family 17
Registering SWP/SWPB emulation handler
rtc-rx8010sj 0-0032: setting system clock to 2018-11-10 12:15:08 UTC (1541852108)
RAMDISK: gzip image found at block 0
VFS: Mounted root (ext2 filesystem) on device 1:0.
devtmpfs: mounted
Freeing unused kernel memory: 176K (c05cf000 - c05fb000)
Starting rcS...
++ Mounting filesystem
++ Setting up mdev
++ Starting ftp daemon
rcS Complete
<root@rigol>rpcbind: cannot create socket for udp6
rpcbind: cannot create socket for tcp6
2018-11-10 12:15:21: (log.c.166) server started
7 2048 16 2 "/dev/fb0"
Mount user space to:/user
default setting by user set
Rigol Device gadget: Rigol Device ready
usbcore: registered new interface driver usbtmc


I don't know anything about that world, does anybody know if Xilinx do a complete secure boot process?

(and can you tell if they're using it from that output?)

« Last Edit: December 03, 2018, 05:06:52 pm by Fungus »
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf