View Full Version : [VU+ Uno] Compiling VIX from src
Hi,
I have an issue in that I had a bad nand in my uno (http://www.world-of-satellite.com/showthread.php?43959-Nand-gone-band-gutted). I've replaced the nand with a Spansion chip (S34ML01G100TFI000) as the original Samsung were no longer available. Turns out whilst its supposed to be a drop in replacement, its not. I need to tweak the build script for the changes, this is the blocksize, peb size, etc.
Now, I am able to cross compile openvuplus on my linux box. However, I'd like to compile openvix from source but cant see where to git clone from?. All i see on the git web is enigma2 and some plugins but nothing for the actual image.
I have tried many prebuilt images and only old ones seem to work (an old stock one and an old BH 1.6.X one). So I know the nand is good as the box boots up all the way and i can play in the menus etc, the DVB card finds nothing in a scan, but i've had this before and believe its outdated/old drivers. A new image in the past resolved this issue, which is why i am trying to build a new image from src.
Can someone please point me in the right direction?. "all" i need to do is edit the make file with the right values so that the kernal can mount the rootfs.
You can see from here its almost working with the latest stock image from VU, but it fails mounting the rootfs.
BrcmNAND mfg 1 f1 SPANSION_S30ML01GP_08 128MB on CS0
Found NAND on CS0: ACC=f7ff1010, cfg=35142200, flashId=01f1001d, tim1=5363444f, tim2=00000fc6
BrcmNAND version = 0x0302 128MB @00000000
B4: NandSelect=40000101, nandConfig=35142200, chipSelect=0
brcmnand_read_id: CS0: dev_id=01f1001d
After: NandSelect=40000101, nandConfig=35142200
Found NAND flash on Chip Select 0, chipSize=128MB, usable size=128MB, base=0
brcmnand_scan: B4 nand_select = 40000101
brcmnand_scan: After nand_select = 40000101
page_shift=11, bbt_erase_shift=19, chip_shift=27, phys_erase_shift=19
Brcm NAND controller version = 3.2 NAND flash size 128MB @18000000
ECC layout=brcmnand_oob_bch4_4k
brcmnand_scan: mtd->oobsize=64
brcmnand_scan: oobavail=50, eccsize=512, writesize=2048
brcmnand_scan, eccsize=512, writesize=2048, eccsteps=4, ecclevel=15, eccbytes=3
-->brcmnand_default_bbt
brcmnand_default_bbt: bbt_td = bbt_main_descr
Creating 8 MTD partitions on "brcmnand.0":
0x000000000000-0x000007200000 : "rootfs"
ata1.00: 234441648 sectors, multi 0: LBA48 NCQ (depth 0/32)
0x000007200000-0x000007600000 : "kernel"
0x000007600000-0x000007a00000 : "boot"
0x000007a00000-0x000007c00000 : "splash"
0x000007c00000-0x000007d00000 : "cfe"
0x000007d00000-0x000007d80000 : "mac"
0x000007d80000-0x000007e00000 : "env"
0x000007e00000-0x000007f00000 : "nvm"
PM: CP0 COUNT/COMPARE frequency depends on divisor
UBI: attaching mtd0 to ubi0
ata1.00: configured for UDMA/133
scsi 0:0:0:0: Direct-Access ATA FUJITSU MHW2120B 0093 PQ: 0 ANSI: 5
sd 0:0:0:0: [sda] 234441648 512-byte logical blocks: (120 GB/111 GiB)
sd 0:0:0:0: Attached scsi generic sg0 type 0
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
sda: sda1
sd 0:0:0:0: [sda] Attached SCSI disk
UBI: scanning is finished
UBI error: vtbl_check: too large reserved_pebs 572, good PEBs 228
UBI error: vtbl_check: volume table check failed: record 0, error 9
Volume table record 0 dump:
reserved_pebs 572
alignment 1
data_pad 0
vol_type 1
upd_marker 0
name_len 6
name rootfs
crc 0x7089bf6d
UBI error: ubi_attach_mtd_dev: failed to attach mtd0, error -22
UBI error: ubi_init: cannot attach mtd0
ALSA device list:
No soundcards found.
ata2: SATA link down (SStatus 4 SControl 300)
UBIFS error (pid 1): ubifs_mount: cannot open "ubi0:rootfs", error -19
VFS: Cannot open root device "ubi0:rootfs" or unknown-block(8,1): error -19
Please append a correct "root=" boot option; here are the available partitions:
1f00 116736 mtdblock0 (driver?)
1f01 4096 mtdblock1 (driver?)
1f02 4096 mtdblock2 (driver?)
1f03 2048 mtdblock3 (driver?)
1f04 1024 mtdblock4 (driver?)
1f05 512 mtdblock5 (driver?)
1f06 512 mtdblock6 (driver?)
1f07 1024 mtdblock7 (driver?)
0800 117220824 sda driver: sd
0801 117218268 sda1 00000000-01
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(8,1)
Rebooting in 180 seconds..
edit:
just found this link, will try it
http://www.world-of-satellite.com/showthread.php?25107-Development-environment
That should do for the build plus this http://wiki.openpli.org/developer-information should help on your linux (Ubuntu) config requirements plus the one mentioned early on in the link.
I currently run with Ubuntu 15.04 without issues..
That should do for the build plus this http://wiki.openpli.org/developer-information should help on your linux (Ubuntu) config requirements plus the one mentioned early on in the link.
I currently run with Ubuntu 15.04 without issues..
Hi,
I am able to compile the image without issue now on my machine. The problem I have is i am unable to mount the rootfs. The reason I cant mount it because i have too few PEBs available. The image is compiled with 562 and I have 228
UBI: attaching mtd0 to ubi0
UBI: scanning is finished
UBI error: vtbl_check: too large reserved_pebs 562, good PEBs 228
UBI error: vtbl_check: volume table check failed: record 0, error 9
Volume table record 0 dump:
reserved_pebs 562
alignment 1
data_pad 0
vol_type 1
upd_marker 0
name_len 6
name rootfs
crc 0x9e1e0a05
ata2: SATA link down (SStatus 4 SControl 300)
UBI error: ubi_attach_mtd_dev: failed to attach mtd0, error -22
What determines how many PEB you have available?. is it how the flash is installed?, is it something else?
Sorry way beyond my level of expertise:) if you don,t get an answer here try the OpenPli forums
box recovered! :)
The issue was the kernel. all sorted, latest vix up and running, happy days!
box recovered! :)
The issue was the kernel. all sorted, latest vix up and running, happy days!
Glad you sorted it .. out of interest, can you explain the issue/fix - probablyl worth PM'ing me rather than directly here :)
post it here for others to see.
I've built Vix from scratch (but never used the result - just wanted to find out how it was done), so here are my brief notes in case anyone arrives here looking to see how to do it.
The inihdx part refers to the architecture of my OpenVix box (which is selected using curses menu display at the start of running the script). The build takes 20GB.
(removed this bit sorry)
do NOT follow birdmans guide. Thats wrong because you are downloading someone elses tarball, what you need to do is download from source, that way you know there are no nasty surprises in the code.
This is what you have to do, warning this will be a long post :)
There are two aspects to this fix, software and hardware, this is because your hardware is bad but you need to load up an os and vix on the replacement hardware before it will work.
Setting up your software side first.
You need to be able to produce a usb flashable image (NFI can be done but not needed). For this I use Linux because its what I know, sorry this is all going to be linux based. The good thing is if you are on windows, you can run the Linux machine in a virtual machine without paying a cent, its all freeware :)
I'm going to assume you have a running Linux machine setup and running, google this step its pretty common and there are millions of guides telling you how to do this. You then need to get the openvix distribution from the source (NOT SOME RANDOM FORUM like birdman said). Lucky for you someone has gone to the trouble of spelling out what is needed to down. You can find the steps in this post http://www.world-of-satellite.com/showthread.php?25107-Development-environment&p=187945&viewfull=1#post187945
Just in case that post is deleted, it boils down to these commands
mkdir openvix
cd openvix
git clone git://github.com/oe-alliance/build-enviroment.git oe-alliance
cd oe-alliance
MACHINE=vuuno DISTRO=openvix make update
This will downloads loads of stuff like bitbake and other stuff thats going to be used. I found that as it ran, it cried about loads of missing stuff, also it wanted specific versions of Python and I only had an old version installed. I couldn't "just" upgrade it as the OS required the old version, but I'm a veteran on Linux and I wasn't going to let something this simple stop me ;)
Once you have all the dependacies in place you need to test making an image, this will take a long time. As I was on a real (not virtual) machine it didn't take too long, around 10 mins to compile everything and spit me out a USB image that I'd simply unpack to a usb PEN and flash.
cd openvix
cd oe-alliance
MACHINE=vuuno DISTRO=openvix make image
Once this is done you'll get an image that you can flash. It wont actually work for you unless you've managed to install a chip thats the same as the one you took out AND you've flashed the CFE to the blank chip you bought, more on that next :)
if you are in the dir where the source files are, the above commands produce an image in the following location
builds/openvix/release/vuuno/tmp/deploy/images/vuuno/openvix-3.2.004.release-vuuno_usb.zip
The bit in bold changes as thats the version of the software you are building, keep this in mind and dont assume yours will be the same file name, though it WILL be in the same place so just have a gander in there once the compile is done and see what was produced.
Now there are gotchas to compiling the source code, I was having CONSTANT git errors about CONNECTION TIMEOUT, they looked like this, dont worry about the exact command I typed up, i'll cover that later, whats important is that it was part of the process of recovery and I will cover it as part of this write up.
[linuxUser@server vuuno]$ bitbake -c cleansstate virtual/kernel
NOTE: Your conf/bblayers.conf has been automatically updated.
Loading cache: 100% |################################################# ################################################## #########################################| ETA: 00:00:00
Loaded 3044 entries from dependency cache.
ERROR: ExpansionError during parsing /home/oe-alliance/meta-oe-alliance/meta-oe/recipes-oe-alliance/enigma2-plugins/e2openplugins/enigma2-plugin-extensions-streaminterface.bb: Failure expanding variable SRCPV, expression was ${@bb.fetch2.get_srcrev(d)} which triggered exception FetchError: Fetcher failure: Fetch command failed with exit code 128, output:
fatal: unable to connect to github.com:
github.com[0: 192.30.252.131]: errno=Connection timed out
NOTE: Error during finalise of /home/oe-alliance/meta-oe-alliance/meta-oe/recipes-oe-alliance/enigma2-plugins/e2openplugins/enigma2-plugin-extensions-shootyourscreen.bb
Summary: There was 1 ERROR message shown, returning a non-zero exit code.
[linuxUser@server vuuno]$ git config --global -l
user.name=LinuxUser
user.email=linuxUser@gmail.com
[linuxUser@server vuuno]$ git config --global http.proxy http://127.0.0.1:3128
[linuxUser@server vuuno]$ bitbake -c cleansstate virtual/kernel
NOTE: Your conf/bblayers.conf has been automatically updated.
Loading cache: 100% |################################################# ################################################## #########################################| ETA: 00:00:00
Loaded 3044 entries from dependency cache.
ERROR: ExpansionError during parsing /home/oe-alliance/meta-oe-alliance/meta-oe/recipes-oe-alliance/enigma2-plugins/e2openplugins/enigma2-plugin-extensions-streaminterface.bb: Failure expanding variable SRCPV, expression was ${@bb.fetch2.get_srcrev(d)} which triggered exception FetchError: Fetcher failure: Fetch command failed with exit code 128, output:
fatal: unable to connect to github.com:
github.com[0: 192.30.252.128]: errno=Connection timed out
Summary: There was 1 ERROR message shown, returning a non-zero exit code.
[linuxUser@server vuuno]$ bitbake -c cleansstate virtual/kernel
NOTE: Your conf/bblayers.conf has been automatically updated.
Loading cache: 100% |################################################# ################################################## #########################################| ETA: 00:00:00
Loaded 3044 entries from dependency cache.
NOTE: Error during finalise of /home/oe-alliance/meta-oe-alliance/meta-brands/meta-gigablue/recipes-transcode/gb-transtreamproxy.bb################# | ETA: 00:00:03
ERROR: ExpansionError during parsing /home/oe-alliance/meta-oe-alliance/meta-brands/meta-gigablue/recipes-transcode/gb-transtreamproxy.bb: Failure expanding variable S: ExpansionError: Failure expanding variable SRCPV, expression was ${@bb.fetch2.get_srcrev(d)} which triggered exception FetchError: Fetcher failure: Fetch command failed with exit code 128, output:
fatal: unable to connect to github.com:
github.com[0: 192.30.252.129]: errno=Connection timed out
NOTE: Error during finalise of /home/oe-alliance/meta-oe-alliance/meta-oe/recipes-multimedia/gstreamer1.0/gstreamer1.0-plugin-dvbmediasink.bb
Summary: There was 1 ERROR message sh..
Its probably worth pointing out the path I used for storing the source code, I hit a bug/limit in my shell while I first compiled the source code becaues I was running out environment space for the scripts when they ran. I'd see expansion errors spat out, like the errors above. What I had to do was move the source code up to "/home" from "/home/linuxuser/" and that was enough. I actually moved it to / but that was messy and it was fine one level up, so if you see errors about paths move the source code up a level in the hierarchy and see if it helps.
If you are able to build an image then you are able to try it. This is only to see if you are producing images that boot, thing is you got a box with a bad chip in it and we need to deal with that first, so now I jump to hardware setup, we will return to the software side of things once the hardware is sorted.
The hardware side of things (or the really difficult stuff) :D
Right so your NAND has gone bad, but what exactly is the nand and whats it look like?. Well the box of tricks you own is a mini computer, it needs somewhere for the operating system to live when you power it off. This is where the nand comes in , its a chip that in the case of the VU UNO is 128MB (megabytes) or 1Gib (Gigabit) in size. That's pretty small but big enough for what need, these chips are written and read to all the time, the reads dont really cause an issue, the writes however cause wear and its this wear that caused my problem. The number of times you can write to the chip is finite and once you've exceed the limit you got problems. Of course the vendors of the chips know this will happen and they also know these chips will go bad in parts, so they've divided this chip into blocks. You dont use all the blocks on a chip and some are kept spare for blocks that go bad. In my case all the spare blocks were used and more went bad, so the chip was bustificated and needed to be replaced. Unfortnatly this was the first clanger, they don't make that chip anymore, and you cant buy it.
So whats it look like?. here is a pic of my actual chip, this little SOB was the cause of my problems and needed to be replaced.
44728
....cont.
So we've identified the chip we need to replace and need to get on with it, but what if we dont know what chip to replace?, well thats not really a problem because you can usually use a little google-fu and find out and if thats not something you can do because your search skills are lacking there is another way, the serial cable. The VU UNO has a serial port on the back (well my original box does) and you can use whats called a null-modem cable to connect that to your PC. You need a serial port on your PC or a usb to serial adaptor.
Once connected you'll see a ton of things but the important bit will be a section about your NAND chip and what model it is. So you know the model but you need a replacement, I tried in vein to get the exact same one but its impossible to do so. I ordered chips from Ebay from AliExpress and what they sent was ALWAYS K9F1G08U0E. I'd always ask them was it the D variant and they would say yes and I'd get the E version. At first I didnt even notice the E and installed the chip bit it didnt work. I found via google other people that the chip wouldnt work as someone else had the same issue, guess they changed the chip too much (for the worse) and at the very least it was slower for some operations, button line it was a dud.
Now someone on another forum suggested I try a Spansion chip which was claimed to be compatible, this is that exact post and I hope its OK to post as I want to give credit in this write up where and when I've been helped (https://www.digitalworldz.co.uk/vu-uno-receivers-596/420476-where-can-i-buy.html#post2510603)
I was a little hesitant to buy that chip as I'd already spent considerable time and effort getting the Samsung chips that all were wrong but in for a penny in for a pound right?. So whats needed to replace the chip?, more hardware and a willingness to lose the box (if you've never done this before)
To remove the old chip will require the following
Hot air rework station
solder
soldering iron
solder
Flux
I bought a 858D from fleabay (item 331330745304) , cost me £28.98. I had some solder as I've done simple stuff with a soldering iron in the past, but considering I was using a hot air rework I knew from reading around you can buy solder that's like a paste (item 121275877627) and that's what you use when you fit the chip. flux is always a good idea and I had some flux gel, but I also bought some liquid no clean flux (ebay item 121054733532).
That's what you need to remove the chip, but you need a few more items for your shopping list, you need replacement chips and you need to be able to program those replacement chips.
So the replacement chip
To program the chip you can use an external programmer (expensive), or you do what I did and can use your PC to talk to the SoC on the STB, and get that to program the chip for you for a cost of £4.50 for the USB programmer and a few quid for 4 jumper wires to connect the programmer to the pin header on the motherboard. If you put this into fleabay "EZ-USB FX2LP CY7C68013A-56 USB2.0" you'll see the programmer. There are a billion guides out there on how to use it and how to wire it up , google it or you can ask me if you get stuck.
What you could do before you change anything is wire up the programmer to the box and DUMP the existing contents of the nand to a file. This will provide you with the CFE and the nvram with the config for the network card (MAC etc). Personally I did dump but didnt bother restoring it in the end. its a slow process and I did restore to the "E" chips above but couldnt be bothered with the final (spansion) chips, I only did the CFE so I could boot the box and use USB to program the rest of the nand.
The CFE is the bare minimum you need on a new chip as it sets up the USB ports and supports flashing the box with an image from USB, you need this much at the very least. As for the CFE I didnt bother using mine, I could have but i'm too last as I already had one from here http://www.vuplus-community.net/board/threads/vu-uno-flash-boot.3928/page-2#post-36220
You can use your own as as long as its not corrupt of course... should be fine as when you update things on the box and a block goes bad, it will be blocks in the rootfs NOT in the CFE which you never touch so that should be fine, i'm lazy sue me LOL.
So you removed the old chip and installed the replacement, wait the replacement what to use?, well according to this PDF we have a perfect can
http://www.spansion.com/Support/Application%20Notes/Migrate_Samsung_K9F1G08U0D_to_S34ML01G1_AN.pdf
That's right a spansion S34ML01G1 which IS available from places like RS or Mouser. They are cheap too, RS sell 7 for around 12 squid, you cant buy singles.
How do you fit the chip?, plenty of videos on youtube ask me if you need advice.
So the chip was installed, we programmed the CFE using that USB programmer and a program called "Broadcom studio 3". we downloaded openvix and the CFE recognized our new image flashed it and........it wont work :(
so we flash our newly compiled image from the software section about and.....same problem box does not boot. This is where you use the serial cable and watch the box boot to see if you can spot the problem, and eventually you see the problem
....lots of info, eventually we get to here ..
BI: scanning is finished
UBI error: vtbl_check: too large reserved_pebs 572, good PEBs 228
UBI error: vtbl_check: volume table check failed: record 0, error 9
Volume table record 0 dump:
reserved_pebs 572
alignment 1
data_pad 0
vol_type 1
upd_marker 0
name_len 6
name rootfs
crc 0x7089bf6d
UBI error: ubi_attach_mtd_dev: failed to attach mtd0, error -22
UBI error: ubi_init: cannot attach mtd0
ALSA device list:
No soundcards found.
ata2: SATA link down (SStatus 4 SControl 300)
UBIFS error (pid 1): ubifs_mount: cannot open "ubi0:rootfs", error -19
VFS: Cannot open root device "ubi0:rootfs" or unknown-block(8,1): error -19
Please append a correct "root=" boot option; here are the available partitions:
1f00 116736 mtdblock0 (driver?)
1f01 4096 mtdblock1 (driver?)
1f02 4096 mtdblock2 (driver?)
1f03 2048 mtdblock3 (driver?)
1f04 1024 mtdblock4 (driver?)
1f05 512 mtdblock5 (driver?)
1f06 512 mtdblock6 (driver?)
1f07 1024 mtdblock7 (driver?)
0800 117220824 sda driver: sd
0801 117218268 sda1 00000000-01
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(8,1)
Rebooting in 180 seconds..
WTF is going on?.. this line is the key
UBI error: vtbl_check: too large reserved_pebs 572, good PEBs 228
For some reason our drop in chip is not so drop in, we need to fix this but its hard to fix it when we dont know how to. I tried for a laugh some old NFI images over serial and some old (2) images worked, one was an old vuplus image and the other was an arabic BH 1.6 image, both were JFFS2 based. Which I would have stuck with and used only the didnt work with the tuner in my uno, I had seen this before with old images not working but didnt give up, the old images booted and they system worked in that i could telnet into it and it responded. I've attached the boot log from the arabic image so you can see what I saw. It was also not really an option as who knows what they had put in their "custom" arabic blackhole image, i needed to get a working image from vix/pli directly or compile my own, i wanted to compile my own.
So at least I knew the nand chip was fitted right as I could boot from an image, an ancient one granted but one that proved the chip was fitted right. Also if you check that log you can see it detects the spansion chip so i was very happy at this point BUT i needed a new image, so I set about working out what was wrong. The pre-compiled images all complained about the number of PEB (physical erase blocks), I only had 228 available and I needed 497. I didnt know at the time but this value is based on other values, what I needed to do was make an image that was happy with 228, a word of warning this was the wrong approach but I didnt know that at the time, all part of learning.
So booting the old NFI based images I started to interrogate the nand to find out what the working OS on the old images was doing, here is what I saw
root@vuuno:~# cat /proc/mtd
dev: size erasesize name
mtd0: 07200000 00080000 "rootfs"
mtd1: 00400000 00080000 "kernel"
mtd2: 00400000 00080000 "boot"
mtd3: 00200000 00080000 "splash"
mtd4: 00100000 00080000 "cfe"
mtd5: 00080000 00080000 "mac"
mtd6: 00080000 00080000 "env"
mtd7: 00100000 00080000 "nvm"
root@vuuno:~# mtd_debug info /dev/mtd0
mtd.type = MTD_NANDFLASH
mtd.flags = MTD_WRITEABLE
mtd.size = 119537664 (114M)
mtd.erasesize = 524288 (512K)
mtd.writesize = 2048 (2K)
mtd.oobsize = 64
regions = 0
Now to me I could see a problem here, the line in bold was the problem because I knew from reading the chip specs that was not the same as the original (128K), so perhaps this chip wasn't exactly the same ?. I read the datasheet for the new chip and was confused because the PDF above said it should work and it was the same spec
gonna have a quick bite to eat the back on to this
right so here is where i started doubting myself. The PDF from spansion a big company not some mom and pop operation tell me if should mostly work. I'm seeing issues, so i checked the datasheet for the spansion chip and I see this page
44731
I checked what I ordered and its 100% using an 8bit interface and should work. At this point I start emailing people and spansion because i'm out of my depth, well more out of my depth than I already am LOL. They are extremely helpful surprisingly as I'm just a random home user on the internet and they engage and try and help, major Kudos to Spansion here!.
I was talking to the guy and he confirmed my chip uses 128k pages and not 512K, even though some random guy on the internet told me some chips can work in x16 mode (which would have been bad for me), that page above clearly shows that my chip was X8, also the original ONLY works in x8 so it had to match. One conclusion, the openvix kernel is getting it wrong, time to get down dirty and start hacking the Linux kernel. Now I am a programmer by trade but not in C or C++. The last time I did any was years ago at Uni, these days i rock Java but its similar enough that I can trace where its working out how to talk to the NAND. I cross reference the messages I see on the serial with the kernel source that the openvix uses (see the software part of my post at the top) and I find where its setting the page size for the nand. This is how i did the dirty hack
The file to edit is /home/oe-alliance/builds/openvix/release/vuuno/tmp/work-shared/vuuno/kernel-source/drivers/mtd/brcmnand/brcmnand_base.c
This is the diff, and line numbers (software people will understand this)
[linuxuser@server oe-alliance]$ diff /home/oe-alliance/builds/openvix/release/vuuno/tmp/work-shared/vuuno/kernel-source/drivers/mtd/brcmnand/brcmnand_base.c /home/oe-alliance/builds/openvix/release/vuuno/tmp/work-shared/vuuno/kernel-source/drivers/mtd/brcmnand/brcmnand_base.c.bak
7530c7530
< chip->blockSize = 128 << 10;
---
> chip->blockSize = 512 << 10;
7559c7559
< chip->blockSize = 128 << 10;
---
> chip->blockSize = 512 << 10;
[linuxuser@server oe-alliance]$
What I essentially did was, where the chip sets up the page size to be 512K, I told it to use 128K. After compiling the kernel I tried the image and it didn't work, it was still detected as 512K. I then ask on a forum, cant remember which one where someone told me to ask in the OpenPLI forums for help.
http://forums.openpli.org/topic/38877-does-openpli-support-x16-nand-access-i-dont-think-so/
I did this and the response was quite abrupt and harsh. However one user betacentauri was the one who show'd me how to mess with the kernel and how to persist that change. his steps were
http://forums.openpli.org/topic/38877-does-openpli-support-x16-nand-access-i-dont-think-so/#entry505089
Try this
cd oe-alliance/builds/openvix/release/vuuno
MACHINE=vuuno
MACHINEBUILD=vuuno
DISTRO=openvix
source env.source
bitbake -c cleansstate virtual/kernel
bitbake -c patch virtual/kernel
Now change the file in the tmp/work/.... directory. I don't think its in tmp/work-shared, but I'm not 100% sure.
Then execute
bitbake virtual/kernel
This should build new kernel Ipk with the changed sources.
I did this and ALL is well in the world. The box fully booted and nothing was crashing, the box was restored. The nand reported 128K block size so openvix was happy (it has hardcoded values and expects things to be exactly right).
I hope I didnt miss anything but if you need me to elaborate on anything please ask, also while this is a short port, this whole process took me around 7 months to get sorted, lots of learning, lots of reading, lots of being ignored and a few good people helping. Hope this helps someone who is in a similar jam.
Finally the guys at Spansion did comment on the issue and they have some VERY interesting points regarding that from that works with the nand, I'd be happy to share this with anyone on the vix team, cant share personal details on here out of respect. Would there be someone on the vix who is willing to listen to bug reports?, even though the file is from broadcom (the the kernel sources). Its doing stuff thats wrong and breaking the kernel for compatible fixes. Perhaps they can fix this upstream that way me and others like me dont need to have a custom kernel. No biggie if they dont want to get involved I'll spin my own, but it would be nice if they could?. The alternative is vu use an updated SDK for broadcom OR they fix their dodgy detection code (if they changed the original broadcom code).
Hope you are still awake after that long read! :)
Above my IQ, but still very interesting. Not surprised about one of the push backs ... I think they have a NIH intellectual issue.... However Betacentauri works across images and is always helpful :)
Sounds like the kernel could be improved from your comments.:)
I can see a queue of people coming to you in future for receiver repair advice!
He and athoik are legends, we need more people like that who help rather than the frosty response from the other guys. Still it is a fact, were it not for them and openvix there would be 0% chance of a fix, they released the code that we modify to work, so bottom line Kudus to all teams that produce images and release the code.
I have very limited knowledge as all I know is in the context of me fixing this box, but I'm happy to help anyone I can and share what i've learnt on this journey. Karma has a way of catching up with you if you are a ahole... better be the good guy :thumbsup:
do NOT follow birdmans guide. Thats wrong because you are downloading someone elses tarball, what you need to do is download from source, that way you know there are no nasty surprises in the code. The only thing downloaded from that forum is a script.
It downloads the sources with:
if [ ! -d "oe-alliance" ]; then
git clone git://github.com/oe-alliance/build-enviroment.git oe-alliance
fi
if [ ! -d ssh-enigma2 ]; then
git clone git://github.com/OpenViX/enigma2.git ssh-enigma2
fi
The script then does all of the things your posts mention without you needing to run them by hand.
It's just a front-end script to those commands (although, as I look at it in more detail, it didn't actually contain the option for inihdx - I had to edit it in, so I suspect it may not know of some newer hardware types).
Thats all it contains for now, who knows in the future. Considering its simple enough to do it properly, then forget that script and it right. Feed a man to fish and all that :thumbsup:
also going to leave this attachment here (in case spansion or samsung remove them, which they did to a few docs i wanted!)
Finally some more pics (of my actual chips I personally took) for those people who just need a little more help :)
Useless NAND ebayers, and sellers on alibaba sent me time and time again (avoid!!!)
44734
The good (spansion) one that you want to buy for uno boxes.
44735
also when you boot your box and have the serial cable attached, you can set the MAC address of the ethernet port if you know what it is. Otherwise a random one is used, which is no biggie tbh but if you want to get back as close as it was this is how to you it. Let box start to boot, CTRL+C and type
CFE>setenv -p ETH0_HWADDR XX:XX:XX:XX:XX:XX
CFE>reboot
Where the XX is the MAC address obviously. I know what mine was because I had the dhcp server logs capture it months ago and i kept a record of it. again probably not important but why not if you have the info?. Also the beauty of this is if you have IP reservation based on MAC as I do, the IP is picked up again exactly as it was, makes it easier to find on the network.
Considering its simple enough to do it properly, then forget that script and it right.The right way to do any task like this is by scripting it.
That way you can
ensure that all steps are done, and in a right order.
use the script as documentation for what is being done (that's what comment lines are for)
get it to do sanity checks for you on the way through, and to stop when they fail.
set it off in the background (or as a batch job) then come back to it a few hours later and see how it got on. No need to baby-sit it to be able to give it the occasional feed.
I used to do things like this (linear compute tasks) as my job. The first time I'd do it by hand, then second time I would cut&paste the lines from the notes I took the first time and the third and all successive occasions I'd use the script I'd written on the second run.
A principle that is useful when some of those tasks end up running a few hundred jobs over several servers using a few dozen processors between them. Submit one command and wait for the final mail message to arrive a week later. All control scripted.
Lets agree to disagree because what you posted makes no sense whatsoever
"ensure that all steps are done, and in a right order."
Thats EXACTLY what the buildscript does, the script you linked to does NOTHING.
"use the script as documentation for what is being done (that's what comment lines are for)"
erm, what?.
"get it to do sanity checks for you on the way through, and to stop when they fail."
Thats the build script again, NOTHING to do with your wrapper that you mentioned.
"get it to do sanity checks for you on the way through, and to stop when they fail."
The script you mentioned does nothing to do with this. this is NOT how you run thing in the background, as a vetran of over 20 years of Linux administration I can assure you the scripts you linked to dont help in any way. If you want to know how to properly run things in the background I'd be happy to teach you how. I dont mean that as a jibe or attack, its an offer of help if you want/need it.
I too would tasks by hand, BUT I'd make sure I wrote the script, if I used someone elses I'd make sure I understood it. There is a WORLD of difference between running a script from people like OpenVIX who I trust 100% to some random guy off the internet. It also makes NO SENSE to tell someone to go to some random site on the internet if only to "script" up 1 line. You dont need to script up anything, in linux you can just rerun the command from history. Openvix and the other teams have made things have put a lot of effort into the build, the ONLY thing you need to do is type in one line. Even then you only do it once EVER, why send people to download some "wrapper" that they might not understand. Not everyone has your knowledge or mine when it comes to Unix/Scripting.
Lets agree to disagree, its all good fun and we're all here to learn and help each other /highfive
Thats EXACTLY what the buildscript does, the script you linked to does NOTHING.The one I linked to prompts you for which machine to build for, downloads the sources then runs the command to build it. This means that I don't have to remember which environment variable to have to set to what, nor where to go for the download.
"use the script as documentation for what is being done (that's what comment lines are for)"
erm, what?.I like to remember where I get the information from and why a particular piece of code is doing what it is, and why it is written that way. So I use comments in the code (i.e. right where the information is needed).
"get it to do sanity checks for you on the way through, and to stop when they fail."
Thats the build script again, NOTHING to do with your wrapper that you mentioned.Agreed - but I was talking about the principle of scripting in general.
as a vetran of over 20 years of Linux administration I can assure you the scripts you linked to dont help in any wayThey helped me.
If you want to know how to properly run things in the background I'd be happy to teach you how.Again, I wasn't meaning that this script was such an example. For a start - it's interactive...
I too would tasks by hand, BUT I'd make sure I wrote the script, if I used someone elses I'd make sure I understood it.
As I did.
You dont need to script up anything, in linux you can just rerun the command from history.My command line history doesn't extend back 6 months - and even if it did how would I know what to look for? if I knew then I wouldn't need the history.
Openvix and the other teams have made things have put a lot of effort into the build, the ONLY thing you need to do is type in one line.No. You need to download and/or update the source tree first - which is what this script does.
Even then you only do it once EVERSo you'd never rebuild when the source code is updated?
Lets agree to disagree, its all good fun and we're all here to learn and help each other /highfiveWe probably don't disagree all that much.
Lets cut to the chase, you're happy to run that script, great I'm happy it works for you. I'm not happy having my hand held because when things don't work its more one thing thats in the mix and might the cause of the issue :)
Also if I'm thrown in the deep end, I learn whats going on and am in a better position to fix things. Learning how to do things is the very reason I posted this thread, most people would have given up and thrown the towel in, being the stubborn bugger that I am, I educated myself and managed from what could have been a dead end. Maybe it wont help anyone to see the things I wrote, maybe it will help that 1 person years from now. Who knows, point is I'm just an average joe and I got my box working again, perhaps it might encourage someone else to have a go. The way I saw it the box was broken, what was I going to do?, break it again? ;)
http://www.world-of-satellite.com/showthread.php?25107-Development-environment&p=187945&viewfull=1#post187945
You keep rocking with what you feel comfortable doing, I'd strongly recommend people do it the "hard way", you'll learn how to do it, cut and paste that link above into a text file, write to where you checked out the code, refer to it when needed, bish bosh, job done.
If you want to discuses it further i'm happy to do so, probably not worth derailing this thread anymore so feel free to start a new one if you want.
Powered by vBulletin® Version 4.2.5 Copyright © 2024 vBulletin Solutions Inc. All rights reserved.