GM MDI Info

Information and discussion of EFI hardware and specifications
Site Admin
User avatar
Posts: 5711
Joined: Sat Feb 28, 2009 8:34 pm

Re: GM MDI Info

Postby antus » Fri Feb 20, 2015 8:48 am

Protocol drivers are both, it looks like most of it is in the fpga but aldl, kwp (uart) and j1850 have their own kernel modules.

./input/etas-fpga-keys.ko
./rtc
./rtc/etas-rtc.ko
./sja1000
./sja1000/etas-sja1000.ko
./dac_adc
./dac_adc/etas-dac.ko
./power
./power/etas-supercap.ko
./kts-cable-detect.ko
./etas-simple-usb-trig-switch.ko
./etas-led.ko
./etas-speaker.ko
./ecp_lib.ko
./etas-fpga.ko
./etas-status.ko
./p-uart
./p-uart/etas-prot-driver.ko
./etas-irq.ko
./timers
./timers/etas-timers.ko
./j1850-core
./j1850-core/etas-j1850.ko
./video
./video/etas-st7528fb.ko
./mux
./mux/etas-mux.ko
./pwr_detect
./pwr_detect/etas-pwrdet.ko


The usb bus is connected to an on-board ethernet chip which talks to the embedded arm computer. So it is on USB bus, but your going to need the ethernet drivers (seems to install by default over the net in win7) to use it, and accessing it from the pc is done over ethernet whether or not your connected via ethernet or usb cable. Im thinking it'd be a great platform to just run apps on the MDI, but theres no details about how to interface with it from an application on the device (yet)... There is also a userland app on the pdi which provides the PDU end point for the pc software. So I guess you could talk PDU protocol over loopback on the device. And there is plenty of free space on the sdcard for bins, apps, logs or..... ?
Have you read the FAQ? For lots of information and links to significant threads see here: viewtopic.php?f=7&t=1396

User avatar
Posts: 1851
Joined: Thu May 17, 2012 8:53 pm
Location: WA

Re: GM MDI Info

Postby Tazzi » Tue Feb 24, 2015 7:10 pm

Been game enough for anymore tinkering? :thumbup:
Image

Posts: 14
Joined: Thu Jun 11, 2015 11:53 am

Re: GM MDI Info

Postby tek1229 » Wed Jan 06, 2016 6:26 am

Something here I started an someone else finished.. They found a way to re-write the serial number.. The problem arises when 2 clones are used on the same network wirelessly.. My shop has more than one clone and I didn't want to be hampered by this so I started working on it.. Way over my head, thankfully someone else chimed in.. I posted the instructions I retyped and saved below.. Might bring back some interest in this??? Would love to find an easier way to change the serial number but it is workable at least..

The serial number is in the 16mb on board flash memory - the intel chip on the computer sub-board.

You can get u-boot access by making up a serial cable. Signals are available on the 8 pin mini din on the outside of the MDI case. pin 1 goes to PC TX (MDI RX), pin 2 goes to PC RX (MDI TX). Pin 3 goes to ground.

Mount the sdcard parition 1 under linux, and rename telnetd.sh-disabled to telnet.sh in /bin. While there I also edited the init script and added this near the start to make the prompt nicer:
Quote:
export PS1='[\u@mdi \W]\$ '

Access u-boot (38400 baud), and at the prompt type:

Quote:
>>askenv setbootargsprimary

Please enter 'setbootargsprimary':run normalargs addinit addconsole addeth addprimary;setenv bootargs ${bootargs} mtdparts=flash0:256k(boot),128k(bootvars),1536k(linux1),6144k(initrd1),1536k(lin?ux2),6144k(initrd2),128k(linuxvars1),128k(linuxvars2),32k@16320k(serialnum),32k(?macaddress),128k@16256k(id);

>>boot

The MDI will boot and start a telnet server on its IP and have a new flash partition configured as /dev/mtd10 called 'id'. This will align with the erase block so can be updated. Check in /var/log/messages for the presence of 'id' without it being forced readonly.

Telnet in and rip a copy of mtd10 with dd, and send it to an ftp server you have setup on your lan.

Quote:
[root@mdi ~]# cd /tmp
[root@mdi tmp]# dd if=/dev/mtd10 of=mtd10.img
256+0 records in
256+0 records out
[root@mdi tmp]# ls -l mtd10.img
-rw-r--r-- 1 root root 131072 Jan 1 00:07 mtd10.img
[root@mdi tmp]# ftpput -u <user> -p <pass> <ip> mtd10.img mtd10.img

Now load up mtd10.img on your pc in HxD or Hexworkshop. The serial is at 0x10000 with a crc32 checksum of 0x10000->0x17FFB at 17FFC (LSB).

MAC is at 18000 with a crc32 checksum 0x18000->0x1FFFB at 1FFFC.

Update both (just change the last couple of numbers), and use the calculate checksum feature of the hexeditor to calculate crc32 the sums of of the ranges and save the new sums in the bin (remember to enter them in LSB format).

Now pull the files back to the mdi, and update flash:

Quote:
[root@mdi ~]# cd /tmp
[root@mdi tmp]# ftpget -u <user> -p <pass> <ip> mtd10-new.img mtd10-new.img
[root@mdi tmp]# cd /usr/local/mtd/
[root@mdi mtd]# ./flash_unlock /dev/mtd10
[root@mdi mtd]# ./flash_erase /dev/mtd10
Erase Total 1 Units
Performing Flash Erase of length 131072 at offset 0x0 done
[root@mdi mtd]# ./flashcp /tmp/mtd10-new.img /dev/mtd10
[root@mdi mtd]# dd if=/dev/mtd10 of=/tmp/mtd10-readback.img
256+0 records in
256+0 records out
[root@mdi mtd]# md5sum /tmp/mtd10-new.img /tmp/mtd10-readback.img
1a1f4fb7db878218c558b45c0db50c9f /tmp/mtd10-new.img
1a1f4fb7db878218c558b45c0db50c9f /tmp/mtd10-readback.img

Now reboot the MDI, and hold down the power button so it goes in to recovery mode. Use MDI manager to recover the device. Once completed it'll have the new serial and mac.

Posts: 1
Joined: Tue Dec 06, 2016 1:46 pm

Re: GM MDI Info

Postby Brianbri6 » Tue Dec 06, 2016 1:51 pm

great work so far!

Posts: 14
Joined: Thu Jun 11, 2015 11:53 am

Re: GM MDI Info

Postby tek1229 » Fri Jun 09, 2017 12:16 pm

Has anyone yet figured out why the serialnum and madaddress partitions error out with the doesn't start on an erase block boundary -- force read-only error? I am wondering if this can be fixed easily and the ability to change the serial number using serial or by the testmode webpage can be recovered..

I haven't yet but I am planning on trying to read the kernel messages of my genuine mdi and comparing.. don't know if it would be worth the effort?

Site Admin
User avatar
Posts: 5711
Joined: Sat Feb 28, 2009 8:34 pm

Re: GM MDI Info

Postby antus » Fri Jun 09, 2017 1:26 pm

This is a hardware feature of the chip. Block erase is a normal thing for electronic erase flash memory. In a traditional eeprom the block is the entire chip - you put it in a programmer and the programmer triggers the erase. The chips internal controller erases itself (sets all bits to 1) then the user supplies a programming voltage or signal and the new data is sent and written to the whole block. The bits which should be zero are flashed and become 0, the 1s remain and the result is the user's data on the chip. In the case of larger more modern flash memory the erase happens in blocks. This is so that you can have a bootloader or update firmware for recovery, and write a calibration or OS to another area in the same chip. Without this feature you'd require 2 or more physical chips, adding cost. To see where the blocks are, see the specific flash chip data sheet.

So, since you cant set a 0 to 1, only every bit in the block to a 1, you need to erase and re-write the whole block. Linux flash memory setup is designed so that the logical blocks match the physical blocks, and this works quite smoothly. When the blocks are misaligned in error it becomes impossible to erase a logical segment at the hardware level. This is to protect you, the user, from deleting a chunk of data from another filesystem. It'd be no good if you said 'erase mtd3' and the device deletes the bottom half of mtd2 and the top half of mtd3. Since this only applies to erase/write, it causes no problem for read only operation.

Theres a decent description of the electronic process here: http://computer.howstuffworks.com/flash-memory1.htm

Its interesting that is makes the point the block erase is done for speed. The erase is a slow process, so erasing all cells at the same time makes it seem pretty fast to humans. Doing it bit by bit or byte by byte would be technically possible but super slow to use. For many applications where flash memory is used block erase isnt a problem, and the price of the chip is attractive. If individual bytes need to be read and written quickly other technologies exist (Random Access Memory - RAM, or to hold content when main power is disconnected NonVolatile RAM or SRAM) and newer technology like FRAM too.
Have you read the FAQ? For lots of information and links to significant threads see here: viewtopic.php?f=7&t=1396

Posts: 14
Joined: Thu Jun 11, 2015 11:53 am

Re: GM MDI Info

Postby tek1229 » Fri Jun 09, 2017 8:25 pm

Thank you for the explanation, I kind of understand that albeit technically way over my head..

the reason I was wondering about this is that the genuine mdi let's you change the serial simply by renaming the init-testmode file to the init file and booting up in testmode.. this starts a web server and one option is to change the serial number and it fails on the clones I have but works great on the genuine mdi, and some clones.. I am expecting to find that the genuine mdi's don't load these partitions as read only? I haven't proven that yet?

Posts: 14
Joined: Thu Jun 11, 2015 11:53 am

Re: GM MDI Info

Postby tek1229 » Fri Jun 09, 2017 10:26 pm

I'm going to keep on researching this, looks like it might be different hardware? can you even change the erase block size? lol..
edited to add.. This is from a genuine MDI where it's very easy to change the serial..

mtd8 erase size.JPG
mtd8 erase size.JPG (86.89 KiB) Viewed 6033 times

Site Admin
User avatar
Posts: 5711
Joined: Sat Feb 28, 2009 8:34 pm

Re: GM MDI Info

Postby antus » Fri Jun 09, 2017 10:56 pm

Sure, its purely logical, thats the gist of the above.
Have you read the FAQ? For lots of information and links to significant threads see here: viewtopic.php?f=7&t=1396

Posts: 14
Joined: Thu Jun 11, 2015 11:53 am

Re: GM MDI Info

Postby tek1229 » Sat Jun 10, 2017 5:55 am

ok.. I really have no idea what I'm, doing, but....

the test below is part of the kernel messages of a genuine MDI..

Jan 1 00:00:07 (none) user.notice kernel: cfi_cmdset_0001: Erase suspend on write enabled
Jan 1 00:00:07 (none) user.debug kernel: erase region 0: offset=0x0,size=0x20000,blocks=127
Jan 1 00:00:07 (none) user.debug kernel: erase region 1: offset=0xfe0000,size=0x8000,blocks=4
Jan 1 00:00:07 (none) user.info kernel: KARO flash: CFI device at 0x00000000, 16MiB, 16-bit
Jan 1 00:00:07 (none) user.notice kernel: 10 cmdlinepart partitions found on MTD device flash0
Jan 1 00:00:07 (none) user.notice kernel: KARO flash: using dynamic partition definition
Jan 1 00:00:07 (none) user.notice kernel: Creating 10 MTD partitions on "flash0":
Jan 1 00:00:07 (none) user.notice kernel: 0x00000000-0x00040000 : "boot"
Jan 1 00:00:07 (none) user.notice kernel: 0x00040000-0x00060000 : "bootvars"
Jan 1 00:00:07 (none) user.notice kernel: 0x00060000-0x001e0000 : "linux1"
Jan 1 00:00:07 (none) user.notice kernel: 0x001e0000-0x007e0000 : "initrd1"
Jan 1 00:00:07 (none) user.notice kernel: 0x007e0000-0x00960000 : "linux2"
Jan 1 00:00:07 (none) user.notice kernel: 0x00960000-0x00f60000 : "initrd2"
Jan 1 00:00:07 (none) user.notice kernel: 0x00f60000-0x00f80000 : "linuxvars1"
Jan 1 00:00:07 (none) user.notice kernel: 0x00f80000-0x00fa0000 : "linuxvars2"
Jan 1 00:00:07 (none) user.notice kernel: 0x00ff0000-0x00ff8000 : "serialnum"
Jan 1 00:00:07 (none) user.notice kernel: 0x00ff8000-0x01000000 : "macaddress"

Below is the messages from a clone.. I got the genuine messages by cd'ing into the folder and using cat to display them.. On the clone I used dmesg.. They look like the same messages??? Anyways, the clone has the erase regions backwards?

<5>cfi_cmdset_0001: Erase suspend on write enabled
<7>erase region 0: offset=0x0,size=0x8000,blocks=4
<7>erase region 1: offset=0x20000,size=0x20000,blocks=127
<6>KARO flash: CFI device at 0x00000000, 16MiB, 16-bit
<5>10 cmdlinepart partitions found on MTD device flash0
<5>KARO flash: using dynamic partition definition
<5>Creating 10 MTD partitions on "flash0":
<5>0x00000000-0x00040000 : "boot"
<5>0x00040000-0x00060000 : "bootvars"
<5>0x00060000-0x001e0000 : "linux1"
<5>0x001e0000-0x007e0000 : "initrd1"
<5>0x007e0000-0x00960000 : "linux2"
<5>0x00960000-0x00f60000 : "initrd2"
<5>0x00f60000-0x00f80000 : "linuxvars1"
<5>0x00f80000-0x00fa0000 : "linuxvars2"
<5>0x00ff0000-0x00ff8000 : "serialnum"
<4>mtd: partition "serialnum" doesn't start on an erase block boundary -- force read-only
<5>0x00ff8000-0x01000000 : "macaddress"
<4>mtd: partition "macaddress" doesn't start on an erase block boundary -- force read-only
<7>PM: Adding info for No Bus:usbmon0
<7>PM: Adding info for No Bus:mice


Is this what's causing the issue of the serialnum abd macaddress partitions not starting on an erase block boundary? Is this fixable? I am enjoying the challenge, lol.. but boy is this outta my league...

PreviousNext

Return to Hardware

Who is online

Users browsing this forum: No registered users and 1 guest