/|\

Welcome to the Slackware Documentation Project

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
Last revision Both sides next revision
howtos:hardware:arm:toshiba_ac100_dynabook_az [2014/11/30 21:57 (UTC)]
louigi600 [Repackaging the boot image for Aboot]
howtos:hardware:arm:toshiba_ac100_dynabook_az [2015/10/20 15:05 (UTC)]
louigi600 [Building Newer 3.0 Kernel]
Line 4: Line 4:
  
  
-===== Preface =====+====== Preface ======
 The Slackware ARM userland can run on almost any ARM based hardware out there and the Toshiba AC100 is no exception to that rule of thumb. The Slackware ARM userland can run on almost any ARM based hardware out there and the Toshiba AC100 is no exception to that rule of thumb.
 The only impediment to going straight ahead is the kernel. I like to work around the problem by borrowing the kernel from some other distribution that has support for the AC100. currently you have 3 options to get reasonable support for the hardware: The only impediment to going straight ahead is the kernel. I like to work around the problem by borrowing the kernel from some other distribution that has support for the AC100. currently you have 3 options to get reasonable support for the hardware:
Line 14: Line 14:
 There are several places you can get the binary kernel images or the sources to compile them I generally look for Ubuntu first. There are several places you can get the binary kernel images or the sources to compile them I generally look for Ubuntu first.
 Initially I used the [[https://launchpad.net/ubuntu/+source/linux-ac100/|Ubuntu kernel]] version 2.6.38 but over time I upgraded to version 3.0.27. Initially I used the [[https://launchpad.net/ubuntu/+source/linux-ac100/|Ubuntu kernel]] version 2.6.38 but over time I upgraded to version 3.0.27.
 +
 +====== Hardware information ======
 +Here is some of the information I fetched on my AC100 before going into reflashing it with a different OS
 +
 +===== The original partition layout =====
 +<note important>These values are relative to my model (10G), other models (even if with the same size EMMC) may have a different layout. You should double check how your EMMC is layed out before you attempt flashing anything.
 +nvflash --getpartitiontable</note>
 +
 +Offsets show below are absolute ... while offsets seen in tegrapart (from the kernel boot args) seem off from these absolute values by -2048 (-0x800).
 +  part #  name    star sector size description remarks
 +  nvflash   sector
 +  2       BCT     0 15363 (3 MB)          boot config table
 +  3       PT      1536 256 (512 kB)        partition table
 +  4       EBT     1792 1024 (2 MB)          bootloader
 +  5       SOS     2816 2560 (5 MB)          recovery partition mmcblk0p1
 +  6       LNX     5376 4096 (8 MB)          linux kernel and initrd mmcblk0p2
 +  7       MBR     9472 512 (1 MB)          master boot record
 +  8       APP     9984 153600 (300 MB)        applications (/system) mmcblk0p3
 +  9       CAC     163584 204800 (400 MB)        cache (/cache) mmcblk0p4
 +  10      MSC     368384 1024 (2 MB)          misc (/misc) mmcblk0p5
 +  11      EM1     369408 256 (512 kB)
 +  12      UBA     369664 622320 (1215.5 MB)     user data (/data) mmcblk0p6
 +  13      EM2     1001984 256 (512 kB)
 +  14      UDB     1002240 6837504 (13354.5 )      user data (/storage) mmcblk0p7
 +All partitions have sectors of 2048 bytes and id 18.
 +
 +The tegrapart format is a coma separated list of items like this :
 +  <partition name>:<hex start sector>:<hex partition size in sectors>:<hex sector size in bytes>,...
 +that needs to be read out from /proc/cmdline while the AC100 is running the stock OS or needs to be manually created based on the info from the output of tegrapart (the latter is tricky as it is undocumented). 
 +
 +====== Booting Custom Images ======
 +In order to boot and run the Slackwate userland you need to prepare a bootable image for aboot. Threre is 2 possible ways of doing that:
 +  * via the rescue boot image
 +  * via the normal boot image
 +
 +Even if you manage to wreck both you can still rescue your device using nvflash but if you make backups and only flash one partition at a time you can use the other to put things right. You should keep the backups safe for any future use and/or restoring back the original OS.
 +I tried flashing the rescue image first and then I use that to flash the rest ... but you can keep using nvflash for both boot images and even for the root filesystem if you like the idea. There is a new rescue image that can be run from ram without actually flashing anything into the rescue partition, but it is handy to have a rescue partition that can be used to assist fixing the OS you are going to install (as the stock one is useless on anything but the stock OS).
  
 ===== Requirements ===== ===== Requirements =====
Line 24: Line 61:
   * A copy of the content of /proc/cmdline before you change kernel   * A copy of the content of /proc/cmdline before you change kernel
  
-===== Initrd =====+===== Backing Up ===== 
 +Before you actually go ahead it's a good idea to make a backup of the original rescue and boot images. It won't hurt if you also do this for all the partitions ... I'll leave that up to you. 
 +Start your device into recovery mode (POWER + ESC + CTRL) and then from the pc where you have the tegra-linux utils run the following com 
 +mands: 
 +  nvflash --bl harmony/fastboot.bin --sync 
 +  nvflash -r --read 5 original_part05_rescue.img 
 +  nvflash -r --read 6 original_part6_boot.img 
 + 
 +===== Creating An Initrd =====
 Although it is technically possible to boot without using an initrd I've not had the time to experiment that. If all you need is simple boot then the initrd only really needs busybox and a very simple script that mounts root and then switches root. Although it is technically possible to boot without using an initrd I've not had the time to experiment that. If all you need is simple boot then the initrd only really needs busybox and a very simple script that mounts root and then switches root.
  
-This is what my init script looks like in the initrd image:+I make a slight difference between the rescue init script and the boot init script, making the former always drop you into a shell prompt from the initrd system and the latter always attempt to switch root. 
 + 
 +This is what my boot init script looks like:
  
   #!/bin/sh   #!/bin/sh
Line 39: Line 86:
   mkdir /dev/pts   mkdir /dev/pts
   mount -t devpts -o noexec,nosuid,gid=5,mode=0620 none /dev/pts   mount -t devpts -o noexec,nosuid,gid=5,mode=0620 none /dev/pts
-  busybox mdev -s+  mdev -s
   sleep 5   sleep 5
   echo 0x0100 > /proc/sys/kernel/real-root-dev   echo 0x0100 > /proc/sys/kernel/real-root-dev
Line 52: Line 99:
   exec switch_root /root /sbin/init 3   exec switch_root /root /sbin/init 3
  
-You can extract the scriot from my rescue and boot images if you need: first use abootimg to extract the initrd.img then use zcat | cpio -idm to extract the content from the initrd image. +If you wish to alter the init scripts you can extract them from the rescue and boot images: first use abootimg to extract the initrd.img then use zcat | cpio -idm to extract the content from the initrd image. 
-Edit the above script to suit where you want to boot the miniroot from (in my case this is the internal EMMC drive biggest partition) and load any modules that are required for booting (my kernel configuration does not need to do that buy if you borrowed the binary kernel from somewhere you might need some modules for the FB console or for the mass storage). +Edit them to suit your desired setup (in my case root is on the internal EMMC biggest partition)load any modules required for switching root and then repackage the images.
-Make sure the minitoot fstab has the correct root device too.+
  
 +===== Repackaging The Boot Images For Aboot=====
 +You need to make sure the arguments passed to the kernel via cmdline are correct for your device so you need to disassemble the boot images anyway to check out the bootimg.cfg.
 +Do the in a separate folder for each image:
 +  abootimg -x <boot image>
  
- +If you made changes to the initrd or changed the kernel you need to repackage the boot images before going any further
-===== Repackaging the boot image for Aboot===== +
-If you made changes to the initrd you need to repackage that first.+
 From your initrd tree repackage the initrd image: From your initrd tree repackage the initrd image:
   find . | cpio -o -H newc |gzip -9c > ../initrd.img   find . | cpio -o -H newc |gzip -9c > ../initrd.img
Line 66: Line 114:
  
 Then repackage the image for aboot: Then repackage the image for aboot:
-  abootimg create slack.img -k zImage -f bootimg.cfg -r initrd.img+  abootimg -create rescue_new.img -k zImage -f bootimg.cfg -r initrd.img 
 + 
 +You are now theoretically ready to try your rescue image without actually flashing it.
  
-You are now ready to try your rescue image without actually flashing it.+Restart your device into recovery mode (POWER + ESC + CTRL) an load the rescue image into ram. I've not yet got round to prepare a ram rescue image (requires 3.8+ kernel, u-boot and other details prepended to the kernel and initrd images) but over at ac100.grandou.net they have it sorted out, so for the mean time you can try their ram loading sos-uboot-r5-alpha.bin image ... other wise skip this step and go to the one below.
  
-Before you actually go aheda it's a good idea to make a backup of the original rescue image. Start your device into recovery mode (POWER + ESC + CTRL) and then from the pc where you have the tegra-linux utils run the following commands: +  nvflash --bl sos-uboot-r5-alpha.bin --sync
-  nvflash --bl fastboot.stock.bin --go +
-  nvflash --resume --read 5 original_part05_rescue.img+
  
-Then restart your device into recovery mode (POWER + ESC + CTRL) an load the rescue image into ram: +Using traditional rescue system flashed to rescue partition. 
-  nvflash --bl rescue.img --sync+  nvflash --bl harmony/fastboot.bin --sync 
 +  nvflash -r --download 5 rescue_new.img  
 +And then boot into rescue (POWER + HOME) then select 1. 
  
-If the rescue image works fine you can use it to flash itself to the rescue partition.+If the rescue image works fine you can use it to flash the rest.
 On my device the rescue partition is /dev/mmcblk0p1 and the normal boot partition is /dev/mmcblk0p2.  On my device the rescue partition is /dev/mmcblk0p1 and the normal boot partition is /dev/mmcblk0p2. 
 You will use dd for the rescue and boot images and mk?fs/tar for the root filesystem. You will use dd for the rescue and boot images and mk?fs/tar for the root filesystem.
 Your images need to be on SD or usb mas storage so that you can read them from the rescue system. Your images need to be on SD or usb mas storage so that you can read them from the rescue system.
  
 +===== Flashing From The Rescue Initrd =====
 +I forgot to mention: you need to put the Slackware ARM miniroot tarball and the boor image(s) on SD or USB so that you can flash them from rge rescue image.
 +Once you're on the shell prompt from the rescue image mount the external media with the images
 +  mkdir /mnt
 +  mount /dev/<device> /mnt
  
 +Double check the partition layout on your dvice, it may differ from mine.
  
-===== Rebooting ===== +If you are running rescue from ram without having flashed it to EMMC 
-Your safest bet is probably to flash the rescue image first and then use that to do the rest, in doing this you will be forced to make sure the initrd is set up right for whatever you want to do. +  dd if=/mnt/rescue.img of=/dev/mmcblk0p1 bs=2048
  
-Boot while pressing HOME and then hit 1+If you are here you know the rescue image works so it's safe to flash the boot image too: 
 +  dd if=/mnt/boot.img of=/dev/mmcblk0p2 bs=2048
  
-You should get dropped into a shell. +Fprmat the root filesystem (yoyr's may be on /dev/mmcblk1p? or /dev/sda? 
-If you ruut will be on SD ot USB then you can probabbly prepare them from another PC but if you want to use the internal EMMC: +  mke2fs -t ext4 -j -m 1 -b 4096 -i 16384 -l root /dev/mmcblk0p7
-Format your target root partition mount it and extract the miniroot tarball to it. +
-Make sure you set up fstab on the root partition to match your system. +
-Mount the real root and try chroot to it to check all in in place.+
  
-Replicate the changes you made to the rescur image to the boot image too. Reboot again into rescue mode and flash the boot image to /dev/mmcblk0p2 (or where ever the boot image should be on your device). Reboot and enjoy. +Mount it so you can extract the tarball: 
- +  mkdir /root_fs 
-===== Managing the boot image from the AC100 ===== +  mount /dev/mmcblk0p7 /root_fs 
- +  tar xpf /mnt/slackwarearm<version>.tgz -C /root_fs/
-Once you have any sort of linux up and running on the AC100 (and the tegrapart command line sent to kernel is correct for your hardware) you can manage your boot images directly from the AC100. +
- +
-You can dump the raw images like this (this dumps the recovery partition boot image {partition 5 seen from nvflash} on my device) +
- +
-  dd if=/dev/mmcblk0p1 of=recovery.img +
- +
-You can then extract kernel and initrd with the unpack_bootimage, modify things and repackage it with the make_bootimage. the bootimage utils are available in source and can be compiled on you AC100 linux distro. +
- +
-Write back the image with dd again. +
-Once you're up the firs time you will need to complete the miniroot with all the other packages you need to make it into a desktop machine. The quickest way to do this is probably to install manually slackpkg and then use that to install the rest of the stuff.+
  
 +Make sure you set up fstab on the root partition to match your system.
 +Try chroot to it to check all in in place:
 +  chroot /root_fs
 +  
 +Reboot and enjoy.
  
 ====== Handy Workarounds ====== ====== Handy Workarounds ======
 Here are some little issues I worked around that other people might find handy Here are some little issues I worked around that other people might find handy
 +
 +===== Audio With The Newer Kernel =====
 +Finally the speakers are working but in order to get any audio out of the AC100 with 3.0 kernels you haveto do a few things:
 +  - use alsamixer to unmute everything (or at least selectively what you need)
 +  - run "alsaucm -c tegraalc5632 reset" to reset the audio hardware
 +  - use "alsactl store" to store the settings so that you can restore them at boot time 
 +
 +You can then add this to rc.local
 +  /usr/bin/alsaucm -c tegraalc5632 reset
 +  /usr/sbin/alsactl restore
  
 ===== MPlayer ===== ===== MPlayer =====
Line 151: Line 210:
 Although you cannot download it from adobe, Android has the blasted libflasplayer.so library but even if you hack it out of some apk you will run into trouble with incompatible libraries dew to the different instruction sets used in android and ARMedslack. In order to get some basic flash support in my ARMedslack AC100 I used swfdec: it will not play youtube videos as you get told that you need to update but it's better then nothing. I've been reported that the android libflasplayer.so works on Slackware ARM 14. Although you cannot download it from adobe, Android has the blasted libflasplayer.so library but even if you hack it out of some apk you will run into trouble with incompatible libraries dew to the different instruction sets used in android and ARMedslack. In order to get some basic flash support in my ARMedslack AC100 I used swfdec: it will not play youtube videos as you get told that you need to update but it's better then nothing. I've been reported that the android libflasplayer.so works on Slackware ARM 14.
  
-====== Hardware information ====== +===== Alternative Way To Boot Linux The First Time =====
-Here is some of the information I fetched on my AC100 before going into reflashing it with a different OS +
- +
-===== The original partition layout ===== +
-This is the layout on a 10G device, layout may be slightly different on other versions. +
-Retreave this by using nvflash --getpartitiontable: +
- +
-  part #  name    size    description       remarks +
-  2       BCT     3 145 728 (3 MB)          boot config table        +
-  3       PT      524 288 (512 kB)          partition table  +
-  4       EBT     2 097 152 (2 MB)          bootloader       +
-  5       SOS     5 242 880 (5 MB)          recovery partition       +
-  6       LNX     8 388 608 (8 MB)          linux kernel and initrd kernel starts at 0x800 initrd starts at 0x20E800 +
-  7       MBR     1 048 576 (1 MB)          master boot record       +
-  8       APP     314 572 800 (300 MB)      applications (/system)   +
-  9       CAC     419 430 400 (400 MB)      cache (/cache)   +
-  10      MSC     2 097 152 (2 MB)          misc (/misc)     +
-  11      EM1     524 288 (512 kB)         +
-  12      UBA     1 294 991 360 (1235 MB)   user data (/data)        +
-  13      EM2     524 288 (512 kB)         +
-  14      UDB     5 950 144 512 (5674.5 MB) user data (/storage) +
- +
-===== A possible way to boot linux the first time =====+
 If I remember correctly I think this is how I first got my custom image from my linux PC to the AC100 with the linux4tegra utilities. If I remember correctly I think this is how I first got my custom image from my linux PC to the AC100 with the linux4tegra utilities.
-I targeted the rescue partition so that if something went wrong I'd still have android working right from partition 6. 
-If you have a rooted android with a terminal you could possibly do this from android by using dd on the correct block device or alternatively try booting the image and ramdisk without actually writing the images to flash until you have tested them to work correctly. At the time I did it the nvflash tool was poorly documented so I did not attempt booting the image without writing it to flash. 
- 
 Start in Recovery mode  Start in Recovery mode 
  
Line 195: Line 229:
  
   $ fastboot flash:raw boot zImage init.img   $ fastboot flash:raw boot zImage init.img
- 
-===== Manipulating the boot image ===== 
-This is an example of how I manipulate the boot image: 
- 
-  # unpack a partition: 
-  $ ./unpack_bootimg part05.img 
-  kernel size = 2153760 
-  kernel addr = 10008000 
-  ramdisk size = 421004 
-  ramdisk addr = 11000000 
-  second size = 0 
-  second addr = 10f00000 
-  tags addr = 10000100 
-  page_size = 2048 
-  name = 
-  cmdline = 
-  id = 4ed00528 cb58acc7 f259f0eb 97d77baf e5bb19fd 00000000 00000000 00000000 
-  extracting kernel in zImage 
-  extracting ramdisk in initrd.img 
-   
-  # modifying a partition, updating the kernel and ramdisk 
-  $ ./make_bootimg part05.img zImage initrd.img 
-  kernel size = 2153760 
-  kernel addr = 10008000 
-  ramdisk size = 421004 
-  ramdisk addr = 11000000 
-  second size = 0 
-  second addr = 10f00000 
-  tags addr = 10000100 
-  page_size = 2048 
-  name = 
-  cmdline = 
-  id = 4ed00528 cb58acc7 f259f0eb 97d77baf e5bb19fd 00000000 00000000 00000000 
-  kernel size = 2153760 
-  ramdisk size = 421004 
-   
-  # updating the boot cmdline: 
-  $ ./make_bootimg part05.img -c "mem=448M@0M nvmem=64M@448M vmalloc=320M video=tegrafb console=ttyS0,115200n8 usbcore.old_scheme_first=1 tegraboot=sdmmc tegrapart=recovery:700:a00:800,boot:1100:1000:800,mbr:2100:200:800,system:2300:25800:800,cache:27b00:32000:800,misc:59b00:400:800,userdata:5a000:9a600:800" 
- 
-If you install the tools on the AC100 you can do this all from ARMedslack on the AC100. 
- 
-====== Onboard EMMC Layout ====== 
-<note important>These values are relative to my model, other models (even if with the same size EMMC) may have a different layout. You should double check how your EMMC is layed out before you attempt flashing anything.</note> 
- 
-Offsets show below are absolute ... while offsets seen in tegrapart (from the kernel boot args) seem off from these absolute values by -2048 (-0x800). 
- 
-The tegrapart format is a coma separated list od items like this : 
-  <partition name>:<hex start sector>:<hex partition size in sectors>:<hex sector size in bytes>,... 
- 
-Tere's the EMMC layout of my device: 
- 
-  PartitionId=2 
-  Name=BCT 
-  DeviceId=18 
-  StartSector=0 
-  NumSectors=1536 
-  BytesPerSector=2048 
-   
-  PartitionId=3 
-  Name=PT 
-  DeviceId=18 
-  StartSector=1536 
-  NumSectors=256 
-  BytesPerSector=2048 
-   
-  PartitionId=4 
-  Name=EBT 
-  DeviceId=18 
-  StartSector=1792 
-  NumSectors=1024 
-  BytesPerSector=2048 
-   
-  PartitionId=5 (seen as mmcblk0p1 recovery)  
-  Name=SOS 
-  DeviceId=18 
-  StartSector=2816 (0xb00) (but offsets in boot args seem to be off by -0x800 <2048> from this value) 
-  NumSectors=2560 
-  BytesPerSector=2048 (0x800) 
-   
-  PartitionId=6 (seen as mmcblk0p2) 
-  Name=LNX 
-  DeviceId=18 
-  StartSector=5376 (0x1500) 
-  NumSectors=4096 
-  BytesPerSector=2048 (0x800) 
-   
-  PartitionId=7 
-  Name=MBR 
-  DeviceId=18 
-  StartSector=9472 
-  NumSectors=512 
-  BytesPerSector=2048 (0x800) 
-   
-  PartitionId=8 (seen as mmcblk0p3 mbr) 
-  Name=APP 
-  DeviceId=18 
-  StartSector=9984 
-  NumSectors=153600 
-  BytesPerSector=2048 (0x800) 
-   
-  PartitionId=9 (seen as mmcblk0p4 system) 
-  Name=CAC 
-  DeviceId=18 
-  StartSector=163584 
-  NumSectors=204800 
-  BytesPerSector=2048 (0x800) 
-   
-  PartitionId=10 (seen as mmcblk0p5 cacche) 
-  Name=MSC 
-  DeviceId=18 
-  StartSector=368384 
-  NumSectors=1024 
-  BytesPerSector=2048 (0x800) 
-   
-  PartitionId=11 
-  Name=EM1 
-  DeviceId=18 
-  StartSector=369408 
-  NumSectors=256 
-  BytesPerSector=2048 (0x800) 
-   
-  PartitionId=12 (seen as mmcblkp6 misc) 
-  Name=UDA 
-  DeviceId=18 
-  StartSector=369664 
-  NumSectors=632320 
-  BytesPerSector=2048 (0x800) 
-   
-  PartitionId=13 
-  Name=EM2 
-  DeviceId=18 
-  StartSector=1001984 
-  NumSectors=256 
-  BytesPerSector=2048 (0x800) 
-   
-  PartitionId=14 (seen as mmcblkp7 userdata) 
-  Name=UDB 
-  DeviceId=18 
-  StartSector=1002240 
-  NumSectors=6837504 
-  BytesPerSector=2048 (0x800) 
  
 ====== Building Newer 3.0 Kernel ====== ====== Building Newer 3.0 Kernel ======
-<note important>This is work in progress, it boots nad basically works but it's not been tested extensively like 2.6.38</note>+<note important>This is work in progress, it boots and works but it's not been tested extensively like 2.6.38</note>
  
 There has been a lot of work done on mainstream kernel from 3.8 on, but I've not had the time to check out if it's functional enough to be used on the AC100 as a netbook and besides that there are also other issues that are holding me back on doing the testing on mainstream kernel:  There has been a lot of work done on mainstream kernel from 3.8 on, but I've not had the time to check out if it's functional enough to be used on the AC100 as a netbook and besides that there are also other issues that are holding me back on doing the testing on mainstream kernel: 
Line 346: Line 239:
 According to [[http://ac100.grandou.net/kerneldev#mainline_git_kernel|ac100.grangow.net]] form 3.15 on there is full support on mainstream kernel. According to [[http://ac100.grandou.net/kerneldev#mainline_git_kernel|ac100.grangow.net]] form 3.15 on there is full support on mainstream kernel.
  
-Native kernel build (in order to compile this native 512Mb arr not sufficient so you need to swap on something {SD,usb storage or internal emmc}: an extra 512Mb swap will suffice). +Native kernel build (in order to compile this native 512Mb are no longer sufficient so you need to swap on something {SD,usb storage or internal emmc}: an extra 512Mb swap will suffice). 
-It;s technically possible to work form marvin's kernel git but I've not been able to configure that kernel to boot correctly ... it hangs while attempting to read RTC, but it's probably just something wrong that I did in the configuration.+It's technically possible to work form marvin's kernel git but I've not been able to configure that kernel to boot correctly ... it hangs while attempting to read RTC, but it's probably just something wrong that I did in the configuration.
 #git clone --depth 1 -b chromeos-ac100-3.0 https://gitorious.org/~marvin24/ac100/marvin24s-kernel.git #git clone --depth 1 -b chromeos-ac100-3.0 https://gitorious.org/~marvin24/ac100/marvin24s-kernel.git
  
Line 358: Line 251:
   make modules_install INSTALL_MOD_STRIP=1   make modules_install INSTALL_MOD_STRIP=1
  
-====== Prepare The Image For Booting ======+===== Prepare The Image For Booting =====
 Once you've the modules in place you need to package the kenel in aboot format ... I previously did this with an old tool ... there's now a standard tool: "abootimg" Once you've the modules in place you need to package the kenel in aboot format ... I previously did this with an old tool ... there's now a standard tool: "abootimg"
  
Line 428: Line 321:
  
 Flash the new boot image back to the partition you decided ti target (with whatever method was used to extract it in the first place) and reboot. Flash the new boot image back to the partition you decided ti target (with whatever method was used to extract it in the first place) and reboot.
- 
-====== Audio With The Newer Kernel ====== 
-Finally the speakers are working but in order to get any audio out of the AC100 with 3.0 kernels you haveto do a few things: 
-  - use alsamixer to unmute everything (or at least selectively what you need) 
-  - run "alsaucm -c tegraalc5632 reset" to reset the audio hardware 
-  - use "alsactl store" to store the settings so that you can restore them at boot time  
- 
-You can then add this to rc.local 
-  /usr/bin/alsaucm -c tegraalc5632 reset 
-  /usr/sbin/alsactl restore 
  
 ====== Contacts ====== ====== Contacts ======
Line 454: Line 337:
 <!-- Please do not modify anything below, except adding new tags.--> <!-- Please do not modify anything below, except adding new tags.-->
 {{tag>howtos hardware arm author_louigi600}} {{tag>howtos hardware arm author_louigi600}}
 +
  

In Other Languages
QR Code
QR Code howtos:hardware:arm:toshiba_ac100_dynabook_az (generated for current page)