Hi linuxdev,
You were right, I use one FTDI chip and it works.
I get this on the serial console:
U-Boot 2014.10-rc2-00006-g565af3f (Feb : MMC: Tegra SD/MMC: 0, Tegra SD/MMC: 1
a-pcie: prefetchable memory: 0x20000000-0x40000000
tegra-pcie: 2x1, 1x1 configuration
egra-pcie: probing port 0, using 2 lanes
tegra-pcie: probing port 1, using 1 lanes
In: serial
Out: serial
Eddress from net device
Hit any key to stop autoboot: 0
MMC: no card present
switch to partitions #0, OK
mmc0(part 0) is current device
Scanning mmc 0...
...
USB0: USB EHCI 1.10
scanning bus 0 for devices... or devices... 1 USB Device(s) found
scanning usb for device 0: unknown device
BOOTP broadcast 1
BOOTP broadcast 2
BOOTP broadcast 3
BOOTP broadcast 4
BOOTP broadcast 5
BOOTP broadcast 6
BOOTP broadcast 7
BOOTP broadcast 8
BOOTP broadcast 9
BOOTP broadcast 10
BOOTP broadcast 11
BOOTP broadcast 12
BOOTP broadcast 13
BOOTP broadcast 14
BOOTP broadcast 15
BOOTP broadcast 16
BOOTP broadcast 17
Retry time exceeded; starting again
The BOOTP broadcast is always been repeated. I make the test without connecting it to a monitor.
When I connect it to a monitor (HDMI cable), even when I restart the board nothing is shown in the console. When I remove the HDMI cable it restarts the BOOTP broadcast.
I don’t have any image on the screen coming from the HDMI cable.
It is odd that boot loader stage would have any effect from an attached HDMI device. It makes me wonder if there is an electrical failure (note that the EDID query works on monitors which are turned off because the HDMI connector itself powers the i2c circuitry within the monitor…the monitor itself does not apply that power…any short would short the Jetson power source and not the monitor’s…yet the monitor works for EDID query on other computers).
The most interesting part is that it shouldn’t be trying bootp. It seems like flash succeeded, but the files flashed were incomplete and did not include extlinux.conf (or it was flashed such that extlinux.conf is not available). In the host is a “Linux_for_Tegra” directory…this is the driver package. Within that is the “bootloader” subdirectory where system.img is created, then moved to name system.img.raw, and finally a compressed/sparse image created as system.img. Does your bootloader subdirectory have both system.img and system.img.raw? What is the exact byte size of the system.img.raw?
For the raw image, does the following test work from the bootloader directory?
sudo -s
mount -o loop ./system.img.raw /mnt
cd /mnt
# ls should show the root of a file system.
ls
ls ./boot
ls ./boot/extlinux/extlinux.conf
cd -
umount /mnt
Hi,
Before you answer I was searching a little bit on the internet and I found this https://devtalk.nvidia.com/default/topic/958328/jetson-tk1/need-help-updating-the-l4t-from-21-4-to-21-5-on-the-emmc-fails/6
I have installed using:
sudo ROOTFS_TYPE=ext3 ./flash.sh jetson-tk1 mmcblk0p1
And it worked well, now I have image
I really wish I could remember which defaults are changing on some new Linux distributions, but ext3 would be a viable workaround. Probably a better result would be mkfs.ext4 using a non-default set of options matching those of older distributions. This would definitely account for not finding the extlinux.conf file though if ext4 had an option u-boot was not set up to understand.
I have installed the last version that comes with the Jetpack but using the command line after the download and not the GUI installer.
Thanks for your support, I was almost giving up :)